# monitor ip traffic
tcpdump -n -i vlan99 host 192.168.1.0
tcpdump -i eth1 -n port 8888 or port 7777 and host 192.168.x.x
tcpdump -n -i any host 192.168.1.100 or host 192.168.1.200 and not port 22
tcpdump -n -i any host 192.168.1.100 or host 192.168.1.200 and not port 22 and not net 192.168.3.100/26
tcpdump -n -i any host 192.168.1.100 or host 192.168.1.200 and not port 22 and not net 192.168.3.100/26 and not host 192.168.1.1 and not host 192.168.2.1 and not port 1215 and not port 1212
tcpdump -n -i any -s 1500 -w test_dump_file.dump host 192.168.1.100 or host 192.168.1.200 and not port 22 and not net 192.168.3.100/26 and not host 192.168.1.1 and not host 192.168.2.1 and not port 1215 and not port 1212

chmod u+s … set the permissions to “-rwsr-xr-x”, or similar (note the “s” replacing the usual “x”). That means that you can run certain commands with the permissions of a different user (typically root).

If you are running your Linux system on a USB flash key, there are a number of things you might want to do in order to reduce the wear and tear on the underlying flash device (as it only supports a limited number of writes).

The ext3 filesystem per default writes metadata changes every five seconds to disk. This can be increased by mounting the root filesystem with the commit=N parameter which tells the kernel to delay writes to every N seconds.

The kernel writes a new atime for each file that has been read which generates one write for each read. This can be disabled by mounting the filesystem with the noatime option.

Both of the above can be done by adding e.g. noatime,commit=120,… to /etc/fstab. This can also be done on an already mounted filesystem by running the command:

mount -o remount,noatime,commit=120 /

The system will run updatedb every day which creates a database of all files on the system for use with the locate command. This will also put some stress on the filesystem, so you might want to disable it by addingexit 0
early in the /etc/cron.daily/find script.

syslogd will in the default installation sync a lot of log files to disk directly after logging some new information. You might want to change /etc/syslog.conf so that every filename starts with a – (minus) which means that writes are not synced immediately (which increases the risk that some log messages are lost if your system crashes). For example, a line such as:

kern.* /var/log/kern.log

would be changed to:

kern.* -/var/log/kern.log

You also might want to disable some classes of messages altogether by logging them to /dev/null instead, see syslog.conf(5) for details.
In addition, syslogd likes to write -- MARK -- lines to log files every 20 minutes to show that syslog is still running. This can be disabled by changing SYSLOGD in /etc/default/syslogd so that it reads

SYSLOGD="-m 0"

After you’ve made any changes, you need to restart syslogd by running/etc/init.d/syslogd restart

If you have a swap partition or swap file on the flash device, you might want to move it to a different part of the disk every now and then to make sure that different parts of the disk gets hit by the frequent writes that it can generate. For a swap file this can be done by creating a new swap file before you remove the old one.
If you have a swap partition or swap file stored on the flash device, you can make sure that it is used as little as possible by setting /proc/sys/vm/swappiness to zero.

The kernel also has a setting known as laptop_mode, which makes it delay writes to disk (initially intended to allow laptop disks to spin down while not in use, hence the name). A number of files under /proc/sys/vm/ controls how this works:

/proc/sys/vm/laptop_mode: How many seconds after a read should a writeout of changed files start (this is based on the assumption that a read will cause an otherwise spun down disk to spin up again).

/proc/sys/vm/dirty_writeback_centisecs: How often the kernel should check if there is “dirty” (changed) data to write out to disk (in centiseconds).

/proc/sys/vm/dirty_expire_centisecs: How old “dirty” data should be before the kernel considers it old enough to be written to disk. It is in general a good idea to set this to the same value as dirty_writeback_centisecs above.

/proc/sys/vm/dirty_ratio: The maximum amount of memory (in percent) to be used to store dirty data before the process that generates the data will be forced to write it out. Setting this to a high value should not be a problem as writeouts will also occur if the system is low on memory.

/proc/sys/vm/dirty_background_ratio: The lower amount of memory (in percent) where a writeout of dirty data to disk is allowed to stop. This should be quite a bit lower than the above dirty_ratio to allow the kernel to write out chunks of dirty data in one go.

All of the above kernel parameters can be tuned by using a custom init script, such as this example script. Store it to e.g. /etc/init.d/kernel-params, make it executable with

chmod a+x /etc/init.d/kernel-params

and make sure it is executed by running

update-rc.d kernel-params defaults

Note

Most of these settings reduce the number of writes to disk by increasing memory usage. This increases the risk for out of memory situations (which can trigger the dreaded OOM-killer in the kernel). This can even happen when there is free memory available (for example when the kernel needs to allocate more than one contiguous page and there are only fragmented free pages available).

As with any tweaks, you are advised to keep a close eye on the amount of free memory and adapt the tweaks (e.g. by using less aggressive caching and increasing the swappiness) depending on your workload.

If anyone is interested in helping maintain this information or has feedback / changes / updates / or other suggestions please send me a PM on these forums ~ bodhi.zazen
I am writing this guide as a concerned member of the Ubuntu Community. Security is a concern for us all and in welcoming new (and experienced) users to Ubuntu I would like to demystify the complexities of security that come with your new OS.

Disclaimer : I am not an expert in security. This document is intended as a security overview for new users. This thread is not intended as an all inclusive how-to or discuss the merits of any particular security measure. I offer no guarantee that by running Ubuntu with any or all of these suggestions your security will be foolproof or that you will never be cracked.

I would like to direct any general security discussions to the Servers & Security and any comments on this introductory sticky here.

I would like to thank the Ubuntu Staff, especially jdong and compiledkernel for their review and suggestions.

The two most common cracks posted on these forums are ssh and vnc, both running with password authentication.

If you wish to run these services, please secure them.

In the case of ssh, use keys (and disable password authentication) and either configure iptables or use a service such as denyhosts or fail2ban (both are in the repositories).

Introduction: Security is an ongoing process and, like an onion, it has layers and stinks. The best defense you have is to read and learn how to secure your OS.

Alas, there is no single action you can take to achieve absolute security (the only safe computer is one that is turned off, disconnected from the Internet, and in a locked vault) and security concerns and “ease of use” are sometimes competing concerns.

Clarification of terms:

The “Windows Mindset” is intended as exactly that. I assume most new users are coming from Windows and the issues under this section are both most familiar to them and areas of FAQ on the forums (how often do we see questions from the “Ubuntu Mindset” on ABT?).

The “Ubuntu Mindset” is thus likely new information for most new users.

Those divisions/titles are intended to divide security information into familiar/unfamiliar territory (assuming the reader comes from a Windows background) or to lighten up an otherwise dry topic. Specifically it is my intention that the “Windows mindset” will help users new to Linux (Ubuntu) feel more at home by starting with familiar themes. These titles or divisions are certainly not intended to convey more or less importance to any particular issue, those decisions I leave for “self determination”.Summary: There is no such thing as “security in a box ™”. Information security is an active job — it is not installing some product on the system and sitting back and relaxing.

The good news ~ Ubuntu (Linux) is fairly secure “out of the box”.

How to proceed: Prepare to read, read, read … do not expect to get through this document in one session.

Contents:

1. Intro

Basics

2. Windows mindset

Antivirus

Wine

Firewall

Adware

3. Ubuntu mindset

Permissions and Encryption

GPG

Truecrypt

Installation into an Encrypted Partition

Root kits

Intrusion detection

compiledkernel’s suggested applications

Secure servers

Hardened kernels

Logs

How to perform a hardened installation

Screening your system for potential security holes

4. Forensics

5. References

Basics

This advice is fairly generic and applies to almost any OS. These simple steps offer a solid foundation that you should be able to implement almost immediately.

Social engineering is a collection of techniques used to manipulate people into performing actions or divulging confidential information.[1] While similar to a confidence trick or simple fraud, the term typically applies to trickery for information gathering or computer system access and in most cases the attacker never comes face-to-face with the victim.

~ Quote from Wikipedia

The Windows Mindset

If you are coming from a Windows background you are used to terms like antivirus, spyware, and firewalls. Linux is different and these are not as important. They are discussed first because these are FAQ on the forums. Unfortunately, it is sometimes difficult for new users to wade through some of the FUD (some of which is produced by anti-virus companies) …Viruses

The fact of the matter is: viruses/worms take advantage of flaws or holes in the code. At this time of this writing, there are no significant Linux viruses “in the wild”. Linux boxes are no less targets than any other OS, many of the large (ie valuable) Internet sites run on *nix so there is no lack of motivation to crack into *nix.

Do not believe the suggestion that the Linux community is complacent or “behind the times” in terms of viruses, or any other security issue. Linux developers have not “ignored” viruses, rather the OS is built to be highly resistant to them and since the code is “Open” there are literally thousands of eyes watching …

This is an example of what it would take to install malware on an Ubuntu box :

For the most part, Linux anti-virus programs scan for Windows viruses which do not run on Linux. There are increasing reports, however, that Windows malware may run in wine, as such I added a section reviewing what I feel you should know about security if you choose to install and run wine (see below).

Please understand, anti-virus programs, and in fact most HIDS, are “reactive” in that they can only protect you from known viruses. They can only protect you against malware after it is developed and incroporated into HIDS, not before. Furthermore the “fix” will be to close any hole(s) in the code, these fixes will be available through security updates (which are more frequent in Linux then your previous OS if you are coming from Windows).

Reasons AGAINST antivirus on Ubuntu:

They scan primarily for Windows viruses.

There is a high rate of false positives.

Isolation/inoculation is poor.

And currently there are no known active Linux viruses (so there is essentially nothing to detect).

Reasons FOR antivirus on Ubuntu:

You are running a file or mail server with Windows clients.

You wish to scan files before transferring them, by email, flash drive, etc., to a Windows machine.

Running antivirus can make some sense if you are intending to “protect” Windows users, however, IMO, for a variety of reasons, it is best if Windows users learn to protect themselves.

Note: There have been many documented cases in Windows and Linux that a buffer overflow in an antivirus product has been an attack vector!

If you would like to run an antivirus program on Ubuntu you have several choices :

So what do you need to know about Windows viruses if you want to run wine?

1. First, the “golden rule” : DO NOT RUN WINE AS ROOT. If you are NOT running wine as root then wine will not have the necessary permissions to affect system files.

2. So, if you are running wine as a user, a Windows virus will be confined to your home directory.

3. You can further confine the “fake c drive” located at ~/.wine if you remove any symbolic links outside ~/.wine. With a default installation there is link with a default installation / configuration of wine :

~/.wine/dosdevices/z: -> links to /

A link from ~/.wine/dosdevices to the root directory ( / ) should concern you for obvious reasons.

You can remove it with :

Code:

unlink ~/.wine/dosdevices/z:

Do not worry, that command will not affect wine at all, I run it all the time

You may need to make a link in ~/.wine/dosdevices to your cdrom and/or you may be tempted to link to your home directory, but I advise against keeping using these links (beyond the time needed for actually installing applications).

I advise against any links to removable devices (it should not be *that* difficult to copy files needed to the appropriate location in ~/.wine/drive_c ).

4. Consider running an antivirus program and scanning ~/.wine and any removable devices or other locations you use outside of ~/.wine to store programs or data to be used with wine. Scan any data / applications you use with Windows.

5. Consider confining wine with Apparmor.

6. Be sure to file a bug report with the wine project as they have a very active security team (it is unrealistic, however, to expect the wine team to be able to protect you from all Windows viruses all the time). Wine Bug Reports

7. Take the same precautions with wine as you would with Windows. Do not install untrusted applications from untrusted sources.

If you follow the above advice, Windows viruses will be confined to ~/.wine and they do not have permission to change system files. This means to remove them you simply:

Code:

rm -rf ~/.wine

Please take care, this command deletes everything in your wine directory including all data and all applications.

You then need to restore your wine directory from a known good backup (you do keep backups ?).Firewall

Edit: I posted a series of 3 blogs introduction firewall configuration :

Discussions about firewalls often are passionate (just search the Ubuntu forums). By default, Ubuntu includes a firewall, iptables, but by default nothing is engaged. This is reasonable as a default Ubuntu install opens zero ports to the outside world, so a firewall is redundant. However, installing “server software” will cause ports to open, so some people like to use a firewall as a catch-all layer to find mistakes in their configuration.

Another use for firewalls is for the administrator to forcibly impose network policies on the user. For example, users may not talk to example.com, open up a listening port for remote connections, and so on.

Also, a periodic audit of the system for open ports is a good practice. For example, running the “nmap” command from another machine, or using one of many online port scanners:

The “problem” with iptables is that it is not particularly friendly to new users. Fortunately, there are several more user friendly interfaces available to allow you to manipulate your firewall (UFW, Firestarter, and Guarddog) :

A source of confusion sometimes occurs when users feel the need to be running firestarter/Guarddog for their firewall to be active. This is untrue ! Keep in mind that these applications are not firewalls, but rather configuration tools for ip tables. These applications should be run only to configure your firewall. Once configured, IP tables (the actual firewall) is active (at boot) without having to run firestarter/guarddog. firestarter will monitor traffic, but it runs as root and there are better monitoring programs, so configure you firewall, shut down firestarter/grauddog, and let IP tables do the rest .Browser / Spyware : Java/Flash/Ad-ware/Trackers/Cookies

This is where most users will have the most risk. We all want Java/Flash, but our Internet browser opens us to attacks.

I advise :

Deny all cookies and add trusted sites, allowing only for session.

Install NoScript. Again block all and add trusted sites to a white list.

Encryption is used as an additional layer of protection. One limit of encryption is that protection is only offered when mounting an encrypted partition (once the partition is mounted it is accessible/crackable just like any other file). The tools included with Ubuntu include GPG, LUKS, and ecryptfs.

The term rootkit (also written as root kit) originally referred to a set of recompiled Unix tools such as ps, netstat, w and passwd that would carefully hide any trace of the intruder that those commands would normally display, thus allowing the intruders to maintain root access (highest privilege) on the system without the system administrator even seeing them.

Note: Adding an intrusion detection system like Snort that analyzes network traffic for attack patterns, it can potentially introduce additional vulnerabilities. There have been documented examples of vulnerabilities in Snort’s preprocessor that granted hackers Snort user, or even root user, access to the system!

compiledkernel’s suggested applications (Nagios, ntop, and darkstat are in the Ubuntu Repositories, check the home page to see if newer versions are available):

Nagios ~ A host and service monitor designed to inform you of network problems.

ZenOSS ~ An open source IT monitoring product that delivers the functionality to effectively manage the configuration, health, performance of networks, servers and applications through a single, integrated software package.

ntop ~ A network traffic probe that shows the network usage, similar to what the popular top Unix command does.

darkstat ~ A packet sniffer that runs as a background process on a cable/DSL router, gathers all sorts of statistics about network usage, and serves them over HTTP.

Running Server(s)

Part of setting up a server is reading/learning how to secure it. Common servers include NFS, Samba, FTP, SSH, VNC, RDP, and HTTP. If the “how-to” you are following does not review security, you need to keep looking …“Desktops” become “Servers” if server software is installed.

Questions to ask yourself include:

What port(s) or services does this software provide?

Who will be able to connect to this? (i.e. is it restricted to a range of IP addresses Password protected?)

What level of access will the visitor have to the system? (i.e. does the server run under a restricted user, or the root acount? What can this restricted user do in a worst case scenario?)

Does this service expose any additional information that’s useful to a hacker? (i.e. does it allow users to transmit their passwords in cleartext? Does it have a ‘statistics’ view that reveals logged-in users, ip addresses, network configuration, or other potentially helpful information?)

What is the security history of this software? Does it have a history of vulnerability and patch after patch? Or has it had a relatively unmarred history?

Hardened kernels are modifications to the Linux kernel that add additional security measures. This could include:

The randomization of ports, memory addresses, process ID’s, and other information that is typically predictable. This can thwart off many types of common attacks.

Identify and prevent buffer overflow attacks from resulting in compromise by killing compromised processes (PaX bundled with grsecurity, or Redhat’s Exec-Shield combined with prelink randomization). Edgy and higher contain GCC stack protection enforced in most applications, but is unable to respond to several kinds of attacks that a kernel-layer enforcer could. Likewise, PaX and friends have weakness that GCC stack protection helps cover, so the two work great as a duo.

Hiding information that Linux usually allows everyone to see, including all running processes on the system, load averages, CPU info, IP addresses, etc. Obscuring this information can help keep attackers “in the dark” so to speak.

More aggressive enforcement of buffer overflow protection than what Ubuntu’s standard gcc stack protector can do.

Adding additional restrictions on the capabilities of regular users that prevent channels of attack.

Additional permissions systems that allow finer-grained tuning of various aspects of Linux.

These techniques combined have been shown to be very effective in the real world in guarding against unknown attacks. For example, many administrators of hardened kernel servers either report or even prove that their hardened systems were invulnerable to newly discovered security holes, or that the severity of a breach was significantly reduced.

The most common hardened kernel patch is called “grsecurity2” (http://grsecurity.org/), which does everything on this list. This requires, however, that you manually patch and recompile the kernel. SELinux and AppArmor do the “additional permissions systems” part. The basic theory is that by providing finer definitions of permissions than UNIX users and the “chmod” bits, even a successful attack against one service is virtually useless to attacking the rest of the system.

Note: AppArmor is installed by default as of Hardy, Ubuntu 8.04. There are , however, minimal profiles and they are set to complain mode.

All of these hardened systems, however, take effort on the administrator’s behalf to implement. They also take a lot of trial-and-error to find the correct balance of user functionality and security restrictions. Tightening the rules too much could cause various applications to stop working, and not tightening them enough could lead to a weaker security setup.

If you run a large multiuser system where you must grant people shell access, or run services that have that unfortunate long history of attacks, then it is highly recommended that you look into setting up a hardened kernel.Reading the Logs

Learn how to read your system logs and become familiar with “normal” activity. It should go without saying, your first introduction to system logs should *not* be when you suspect your system has been compromised.

You should also be aware that if someone has root access they can alter system logs. This is when it is most helpful to be aware of “normal” activity.

Thank you to Uwe Hermann for posting a How-to for the moderately paranoid and hermanzone for the How-to with the alternate CDScreening your system

There is a package, tiger, which will screen your system for potential security holes. While not complete it may be an excellent place to start (tiger does not check your firewall for example).

For an overview of tiger see man tiger , scroll to the bottom and you will see a listing and brief description of the tests performed (modules).

Install by any means, tiger john chkrootkit

Code:

sudo apt-get install tiger john chkrootkit

Run tiger from the command line with :

Code:

sudo tiger -H

The -H flag will produce a very nice HTML document.

The command tigexp can be used to explain the results.

$ /usr/sbin/tigexp pass014w

The listed login ID is disabled in some manner (‘*’ in passwd field, etc),

but the login shell for the login ID is a valid shell (from /etc/shells

or the system equivalent). A valid shell can potentially enable the

login ID to continue to be used. The login shell should be changed to

something that doesn’t exist, or to something like /bin/false.

Tiger should give you some ideas on things to research. As always there can be false positives so take care not to either panic or blindly make system changes without understanding what you are doing and how to undo your changes (ie make backups of system files before you edit them).

Forensics

What to do when you think you have been cracked :

Power off.

Disconnect/disable your Internet connectivity.

Now take a deep breath, re-boot, and read the logs. Ask for help if needed, but you really need to confirm that your system has been compromised.

If you have been compromised, and have the time and interest, boot a live CD and image your hard drive. This image can then be used for forensic analysis.

Re-install. Unfortunately, IMHO, there is no way to trust a compromised system.

When you install, be sure to install off line, use a stronger password, and research intrusion detection.