[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ next ]

Securing Debian Manual
Chapter 9 - Before the compromise


9.1 Continuously update the system

You should conduct security updates frequently. The vast majority of exploits result from known vulnerabilities that have not been patched in time, as this paper by Bill Arbaugh (presented at the 2001 IEEE Symposium on Security and Privacy) explains. Updates are described under Execute a security update, Section 4.2.


9.1.1 Manually checking which security updates are available

Debian does have an specific tool to check if a system needs to be updated (see Tiger below) but many users will just want to manually check if any security updates are available for their system.

If you have configured your system as described in Execute a security update, Section 4.2 you just need to do:

     # apt-get update
     # apt-get upgrade -s

The first line will download the list of packages available from your configured package sources. The -s will do a simulation run, that is, it will not download or install the packages but rather tell you which ones should be downloaded/installed. From the output you can derive which packages have been fixed by Debian and are available as a security update. Sample:

     # apt-get upgrade -s
     Reading Package Lists... Done
     Building Dependency Tree... Done
     2 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
     Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
     Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
     Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
     Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)

In this example, you can see that the system needs to be updated with new cvs and cupsys packages which are being retrieved from woody's security update archive. If you want to understand why this packages are needed, you should go to http://security.debian.org and check which recent Debian Security Advisories have been published related to these packages. In this case, the related DSAs are DSA-233 (for cvs) and DSA-232 (for cupsys)


9.1.2 Automatically checking for updates with cron-apt

Another method for automatic security updates is the use of cron-apt. This package provides a tool to update the system at regular intervals (using a cron job). It will just update the package list and download new packages by default. I can also be configured to send mails to the system administrator.

Notice that you might want to check the distribution release, as described in Checking distribution releases, Section 7.4.2, if you intend to automatically updated your system (even if only downloading the packages). Otherwise, you cannot be sured that the downloaded packages really come from a trusted source.


9.1.3 Using Tiger to automatically check for security updates

If you're looking for a tool to quickly check and report system security vulnerabilities, try the tiger package. This package is a set of Bourne shell scripts, C programs and data files used to perform security audits. The Debian GNU/Linux package has additional enhancements oriented toward the Debian distribution, providing more functionality than the Tiger scripts provided by TAMU (or even TARA, a tiger version distributed by ARSC). See the README.Debian file and the man page tiger(8) for more information.

One of these enhancements is the deb_checkadvisories script. This script takes a list of DSA's and checks against the installed package base, reporting back any packages that are vulnerable according to the Debian Security Team. This is a slightly different, more general approach than is implemented by the Tiger check_signatures script, which checks MD5sums of known vulnerable programs.

Since Debian currently does not ship a list of MD5sums of known vulnerable programs (utilized by some other operating systems like Sun Solaris), the check-against-DSA approach is used. The DSA approach and the MD5sums approach both suffer from the problem that signatures have to be updated regularly.

This is currently solved by making new versions of the Tiger package, but the package maintainer might not make a new version every time a DSA is announced. A nice addition, which is not yet implemented, might be to do this proactively. That is, download the DSAs from the web, make the list and then run the check. The DSAs are currently updated from the maintainer's local CVS update of the WML sources used to build http://security.debian.org (the web server, that is).

A program to parse published DSAs, either received through e-mail or available in security.debian.org, and then generate the file used by 'deb_checkadvisories' to confirm vulnerabilities would be appreciated. Send it as a bug report for tiger.

The mentioned check is run through the standard program configuration once installed (see /etc/tiger/cronrc):

     # Check for Debian security measures every day at 1 AM
     #
     1 * *   deb_checkmd5sums deb_nopackfiles deb_checkadvisories
     #

There is an additional check that you might want to add, which is not yet part of the standard cron scripts. That check is the script check_patches, which works in the following way:

If you are running a stable system and add the security.debian.org apt source line to your /etc/apt/sources.list (as described in Execute a security update, Section 4.2), this script will be able to tell you if there are new packages that you need to install. Since the only packages changing in this setup are security updates, then you have just what you wanted.

Of course, this will not work if you are running testing or sid/unstable, since currently, the new packages are probably much more than security updates.

You can add this script to the checks done by the cron job (in the above configuration file) and tigercron would mail (to whomever Tiger_Mail_RCPT was set to in /etc/tiger/tigerrc) the new packages:

     # Check for Debian security measures every day at 1 am
     #
     1 * *   deb_checkmd5sums deb_nopackfiles check_patches
     #

9.1.4 Other methods for security updates.

You might also want to take a look at secpack which is an unofficial program to do security updates from security.debian.org with signature checking written by Fruhwirth Clemens.


9.1.5 Avoid using the unstable branch

Unless you want to dedicate time to patch packages yourself when a vulnerability arises, you should not use Debian's unstable branch for production-level systems. The main reason for this is that there are no security updates for unstable (see How is security handled for testing and unstable?, Section 11.3.7).

The fact is that some security issues might appear in unstable and not in the stable distribution. This is due to new functionality constantly being added to the applications provided there, as well as new applications being included which might not yet have been throughly tested.

In order to do security upgrades in the unstable branch, you might have to do full upgrades to new versions (which might update much more than just the affected package). Although there have been some exceptions, security patches are usually only back ported into the stable branch. The main idea being that between updates, no new code should be added, just fixes for important issues.


9.1.6 Avoid using the testing branch

If you are using the testing branch, there are some issues that you must take into account regarding the availability of security updates:

This behaviour might change based on the release state of the distribution. When a release is almost inminent, the Security Team or package maintainers might provide updates directly to testing.


9.1.7 Automatic updates in a Debian GNU/Linux system

First of all, automatic updates are not fully recommended, since administrators should review the DSAs and understand the impact of any given security update.

If you want to update your system automatically you should:

A safer alternative might be to use the -d (or --download-only) option, which will download but not install the necessary packages. Then if the cron execution shows that the system needs to be updated, it can be done manually.

In order to accomplish any of these tasks, the system must be properly configured to download security updates as discussed in Execute a security update, Section 4.2.

However, this is not recommended for unstable without careful analysis, since you might bring your system into an unusable state if some serious bug creeps into an important package and gets installed in your system. Testing is slightly more secure with regard to this issue, since serious bugs have a better chance of being detected before the package is moved into the testing branch (although, you may have no security updates available whatsoever).

If you have a mixed distribution, that is, a stable installation with some packages updated to testing or unstable, you can fiddle with the pinning preferences as well as the --target-release option in apt-get to update only those packages that you have updated. [42]


9.2 Do periodic integrity checks

Based on the baseline information you generated after installation (i.e. the snapshot descrived in Taking a snapshot of the system, Section 4.18), you should be albe to do an integrity check from time to time. An integrity check will be able to detect filesystem modifications made by an intruder or due to a system administrators mistake.

Integrity checks should be, if possible, done offline [43] . That is, without using the operating system of the system to review, in order to avoid a false sense of security (i.e. false negatives) produced by, for example, installed rootkits. The integrity database that the system is checked against should also be used from read-only media.

You can consider doing integrity checks online using any of the filesystem integrity tools available (described in Checking file system integrity, Section 4.16.3) if taking offline the system is not an option. However, precaution should be taken to use a read-only integrity database and also assure that the integrity checking tool (and the operating system kernel) has not been tampered with.

Some of the tools mentioned in the integrity tools section, such as aide, integrit or samhain are already prepared to do periodic reviews (through the crontab in the first two cases and through a standalone daemon in samhain) and can warn the administrator through different channels (usually e-mail, but samhain can also send pages, SNMP traps or syslog alerts) when the filesystem changes.

Of course, if you execute a security update of the system, the snapshot taken for the system should be re-taken to accomodate the changes done by the security update.


9.3 Set up Intrusion Detection

Debian GNU/Linux includes tools for intrusion detection, which is the practice of detecting inappropriate or malicious activity on your local system, or other systems in your private network. This kind of defense is important if if the system is very critical or you are truly paranoid. The most common approaches to intrusion detection are statistical anomaly detection and pattern-matching detection.

Always be aware that in order to really improve the system's security with the introduction of any of these tools, you need to have an alert+response mechanism in place. Intrusion detection is a waste of time if you are not going to alert anyone.

When a particular attack has been detected, most intrusion detection tools will either log the event with syslogd or send e-mail to the root user (the mail recipient is usually configurable). An administrator has to properly configure the tools so that false positives do not trigger alerts. Alerts may also indicate an ongoing attack and might not be useful, say, one day later, since the attack might have already succeeded. So be sure that there is a proper policy on handling alerts and that the technical mechanisms to implement this policy are in place.

An interesting source of information is CERT's Intrusion Detection Checklist


9.3.1 Network based intrusion detection

Network based intrusion detection tools monitor the traffic on a network segment and use this information as a data source. Specifically, the packets on the network are examined, and they are checked to see if they match a certain signature.

Snort is a flexible packet sniffer or logger that detects attacks using an attack signature dictionary. It detects a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, and much more. Snort also has real-time alerting capability. You can use snort for a range of hosts on your network as well as for your own host. This is a tool which should be installed on every router to keep an eye on your network. Just install it with apt-get install snort, follow the questions, and watch it log.

Debian's snort package has many security checks enabled by default. However, you should customize the setup to take into account the particular services you run on your system. You may also want to seek additional checks specific to these services.

Note: The snort packages available in woody are rather out of date, and might even be buggy, you can retrieve backported (and signed) Snort packages provided by the maintainer at http://people.debian.org/~ssmeenk/snort-stable-i386/

There are other, simpler tools that can be used to detect network attacks. portsentry is an interesting package that can tip you off to port scans against your hosts. Other tools like ippl or iplogger will also detect some IP (TCP and ICMP) attacks, even if they do not provide the kind of advanced techniques snort does.

You can test any of these tools with the Debian package idswakeup, a shell script which generates false alarms, and includes many common attack signatures.


9.3.2 Host based intrusion detection

Host based intrusion detection involves loading software on the system to be monitored which uses log files and/or the systems auditing programs as a data source. It looks for suspicious processes, monitors host access, and may even monitor changes to critical system files.

Tiger is an older intrusion detection tool which has been ported to Debian since the Woody branch. Tiger provides checks of common issues related to security break-ins, like password strength, file system problems, communicating processes, and other ways root might be compromised. This package includes new Debian-specific security checks including: MD5sums checks of installed files, locations of files not belonging to packages, and analysis of local listening processes. The default installation sets up tiger to run each day, generating a report that is sent to the superuser about possible compromises of the system.

Log analysis tools, such as logcheck can also be used to detect intrusion attempts. See Using and customising logcheck, Section 4.12.1.

In addition, packages which monitor file system integrity (see Checking file system integrity, Section 4.16.3) can be quite useful in detecting anomalies in a secured environment. It is most likely that an effective intrusion will modify some files in the local file system in order to circumvent local security policy, install Trojans, or create users. Such events can be detected with file system integrity checkers.


9.4 Avoiding root-kits


9.4.1 Loadable Kernel Modules (LKM)

Loadable kernel modules are files containing dynamically loadable kernel components used to expand the functionality of the kernel. The main benefit of using modules is the ability to add additional devices, like an Ethernet or sound card, without patching the kernel source and recompiling the entire kernel. However, crackers are now using LKMs for root-kits (knark and adore), opening up back doors in GNU/Linux systems.

LKM back doors are more sophisticated and less detectable than traditional root-kits. They can hide processes, files, directories and even connections without modifying the source code of binaries. For example, a malicious LKM can force the kernel into hiding specific processes from procfs, so that even a known good copy of the binary ps would not list accurate information about the current processes on the system.


9.4.2 Detecting root-kits

There are two approaches to defending your system against LKM root-kits, a proactive defense and a reactive defense. The detection work can be simple and painless, or difficult and tiring, depending on the approach taken.


9.4.2.1 Proactive defense

The advantage of this kind of defense is that it prevents damage to the system in the first place. One such strategy is getting there first, that is, loading a LKM designed to protect the system from other malicious LKMs. A second strategy is to remove capabilities from the kernel itself. For example, you can remove the capability of loadable kernel modules entirely. Note, however, that there are rootkits which might work even in this case, there are some that tamper with /dev/kmem (kernel memory) directly to make themselves undetectable.

Debian GNU/Linux has a few packages that can be used to mount a proactive defense:

If you don't really need many kernel features on your GNU/Linux system, you may want to disable loadable modules support during kernel configuration. To disable loadable module support, just set CONFIG_MODULES=n during the configuration stage of building your kernel, or in the .config file. This will prevent LKM root-kits, but you lose this powerful feature of the Linux kernel. Also, disabling loadable modules can sometimes overload the kernel, making loadable support necessary.


9.4.2.2 Reactive defense

The advantage of a reactive defense is that it does not overload system resources. It works by comparing the system call table with a known clean copy in a disk file, System.map. Of course, a reactive defense will only notify the system administrator after the system has already been compromised.

Detection of some root-kits in Debian can be accomplished with the chkrootkit package. The Chkrootkit program checks for signs of several known root-kits on the target system, but is not a definitive test.

Another helpful tool is KSTAT (Kernel Security Therapy Anti Trolls) by the S0ftproject group. KSTAT checks the kernel memory area (/dev/kmem) for information about the target host to assist the system administrator in finding and removing malicious LKMs.


9.5 Genius/Paranoia Ideas — what you could do

This is probably the most unstable and funny section, since I hope that some of the "duh, that sounds crazy" ideas might be realized. The following are just some ideas for increasing security — maybe genius, paranoid, crazy or inspired depending on your point of view.


9.5.1 Building a honeypot

FIXME: More Content specific to Debian needed.

A honeypot is a system designed to teach system administrators how crackers probe for and exploit a system. It is a system setup with the expectation and goal that the system will be probed, attacked and potentially exploited. By learning the tools and methods employed by the cracker, a system administrator can learn to better protect their own systems and network.

A Debian GNU/Linux system can easily be setup as a honeypot, if you dedicate the time to implement and monitor it. Simply setup the fake server with a firewall and some sort of network intrusion detector, put it on the Internet, and wait. Do take care that if the system is exploited, you are alerted in time (see The importance of logs and alerts, Section 4.12) so that you can take appropriate measures and terminate the compromise when you've seen enough. Here are some of the packages and issues to consider when setting up your honeypot:

You can read more about building honeypots in Lanze Spitzner's excellent article To Build a Honeypot (from the Know your Enemy series), or David Raikow's Building your own honeypot. Also, the Honeynet Project provides valuable information about building honeypots and auditing the attacks made on them.


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ next ]

Securing Debian Manual

2.99 18 April 2004Wed, 3 Mar 2004 09:18:54 +0100

Javier Fernández-Sanguino Peña jfs@computer.org