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

Securing Debian Manual
Chapter 9 - Before the compromise


9.1 Set up Intrusion Detection.

Debian includes some tools for Intrusion Detection which you might want to setup to defend you local system (if truly paranoid of if your system is really critical) or to defend other systems in the same network.

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, so don't use Intrusion Detection if you are not going to alert anyone (i.e. don't waste your time configuring things you will not use later on).

Most of the intrusion detection tools will either log against syslog or send emails to the root user (most of them can be configured to mail instead another user) regarding the particular attack that has been detected. An administrator has to properly configure them so that false positives do not send alerts and so that alerts are take proper care of. Alerts can indicate an ongoing attack and might not be useful, say, one day later, since the attack might have been already successful. So be sure that there is a proper policy on handling alerts and that the technical mechanisms to implement it are in place.

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


9.1.1 Network based intrusion detection

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 has a real-time alerting capability. This is a tool which should be installed on every router to keep an eye on your network. Just install it via apt-get install snort, follow the questions and watch it log.

Snort in Debian is enabled with many security checks which you might want; however, you should customize the setup to take into account the particular services you run on your system. You might also want to retrieve additional checks specific to these services.

You can use snort both to establish network intrusion detection for a range of hosts in your network as well as to detect network attacks against your own host.

There are other tools that can be used to detect network attacks (albeit more simpler). Portsentry is another interesting package that can tip you off when a scan is made to your site. Other tools like ippl or iplogger will also detect some IP (TCP and ICMP) attacks, even if they do not provide advanced techniques for detecting network attacks (like snort does).

You can test any of these tools with the idswakeup program, a false-positive generator to alert NIDSs with plenty of common attack signatures available in Debian.


9.1.2 Host based detection

Tiger is an old intrusion detection tool which has been ported to Debian since the woody distribution. Tiger provides check of common issues related to security break-ins, checks passwords strength, filesystem problems, communicating processes... The Debian version includes new security checks Debian-specific: MD5sums of provided binaries, and checks of installed and vulnerable packages. The default installation makes tiger run each day and generate a report that is sent to the superuser. The generated reports can give away information of a successful compromise of the system.

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

Also, any of the filesystem integrity checkers (see Checking filesystem integrity, Section 4.16.3) can be quite useful in order to set up detection of anomalies in a secured environment. An effective intrusion will, most surely, modify files in the local filesystem in order to circumvent local security policy, install trojans, create users... this events can be detected with them.


9.2 Useful kernel patches

FIXME: This section needs to cover how these specific patches can be installed in Debian using the kernel-2.x.x-patch-XXX packages.

There are some kernel patches, which significantly enhance system security. Here are a few of them:


9.3 Avoiding root-kits


9.3.1 LKM - Loadable Kernel Modules

LKM (Loadable Kernel Modules) are files containing dynamically loadable kernel components. They are dynamically loadable in kernel to run assigned tasks. On the GNU/Linux they are used to expand the functionality of kernel. Several advantages can be taken using LKMs, as we saw, they can dynamically be loadabled without recompiling the entire kernel, can be used to specify devices drivers (or filesystems) and other hardware drivers like soundcards, networkcards. But some crackers might use LKMs for root-kits (knark and adore) to install backdoors for GNU/Linux systems.

LKM root-kits can hide processes, files, directories and even connections without modifying the source code of binaries. For example, ps might have get processes information from /proc, a malicious LKM can subvert the kernel to hide specific processes from procfs, so not even a known good copy of the binary ps could list all the correct proccesses information.


9.3.2 Detecting root-kits

The detection work can be simple and painless, or difficult and tiring, depending the measure that you choose. There are two measure of defenses regarding LKM (Linux Kernel Modules) security, the proactive and reactive.


9.3.2.1 Proactive defense

The advantage of this defense is that its prevents that some lkm root-kit damages the system. The most used proactive defense is getting there first, that is loading a designed LKM to protect the system to be damaged by a malicious designed LKM. Another measure is to remove capabilities in the kernel, making the system more secure. For example, you can remove the capability to stop the loading and unloading of kernel modules.

On Debian systems you can find some packages that are a proactive tool:

If you don't really need these many kernel features on your GNU/Linux system you might want disable loadable modules support during kernel configuration. It prevents LKM root-kits, but you couldn't use the kernel module features on your GNU/Linux. Look that disabling loadable modules you can overload the kernel, sometimes it is not necessary.

To disable loadable module support, just set CONFIG_MODULES=n on .config.


9.3.2.2 Reactive defense

The advangate of reactive defense is that it has low overload the system's resources. It works comparing the system call table with known clean copy in a disk file (System.map). The most obvius desavantage is that its tell to administrator only when the system have already be compromised.

Detection of root-kits in Debian can be accomplished with chkrootkit. The Chkrootkit program checks for signs of root-kits on the local system and tells whether the target computer is infected with a root-kit.

You can also use KSTAT (Kernel Security Therapy Anti Trolls) by the S0ftproject group. KSTAT checks the kernel memory area (/dev/kmem) for information about the target host, this information includes the installation of Loadable Kernel Modules.

FIXME: Add info on how to compile the kernel w/o lkm support?


9.4 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. Following here you will find some ideas — it depends on the point of view whether you say they are genius, paranoid, crazy or secure — to increase your security rapidly but you will not come unscathed out of it.


9.4.1 Building a honeypot

FIXME: More Content specific to Debian needed.

If you wish (and can also implement it and dedicate time to it) you can set a full honeypot using a Debian GNU/Linux system. You have all the tools needed in order to setup all the honeynet (i.e. the network, the honeypot is just the fake server): the firewall, the network intrusion detector and the fake server. Be careful, however, you have to be pretty sure that you will be alerted in time (see The importance of logs and alerts, Section 4.11) so that you can take appropiate measures and terminate the compromise as soon as you fill you've seen enough.

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 is dedicated to building honeypots and auditing attacks made to them, there is valuable information there on howto setup a honeypot and howto audit the results of an attack (check out the contest).


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

Securing Debian Manual

2.5 (beta) 29 augusti 2002Sat, 17 Aug 2002 12:23:36 +0200
Javier Fernández-Sanguino Peña jfs@computer.org