Securing Debian HOWTO
Chapter 6 Before the compromise

6.1 Set up Intrusion Detection.

FIXME: Write more about this.

Debian includes some tools for Intrusion Detection which you might want to setup (if truly paranoid of if your system is really critical).

Always be aware that in order 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).

6.1.1 Network based intrusion detection: Using snort

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

6.1.2 Host based detection

Tiger is an old intrusion detection tool which has been ported to Debian since woody. Tiger provides check of common issues related to security breakins, 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.

Other audit tools, on-site, like logcheck, portsentry or any of the filesystem integrity checkers (see Checking filesystem integrity, Section 4.21) can be quite useful in order to set up detection of anomalies in a secured environment.

6.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:

• OpenWall patch by Solar Designer. This is a useful set of kernel restrictions, like restricted links, FIFOs in /tmp, restricted /proc, special file descriptor handling, non-executable user stack area and some more. Homepage: http://www.openwall.com/linux/
• LIDS — Linux intrusion detection system by Huagang Xie & Philippe Biondi. This patch makes the process of creating a hardened Linux system easier. You can restrict every process, give it rights to write or read files, or remove, by default, the ability to read files. Furthermore you can also set capabilities for certain processes. Even though it is still in the beta phase, it is almost a must for the paranoid system administrator. Homepage: http://www.lids.org
• POSIX Access Control Lists (ACLs) for Linux This patch adds access control lists, an advanced method for restricting access to files, to the linux kernel. Homepage: http://acl.bestbits.at/
• Linux trustees. This patch adds a decent advanced permissions system to your Linux kernel. All the objects are stored in the kernel memory, which allows fast lookup of all permissions. Homepage: http://www.braysystems.com/linux/trustees.html
• International kernel patch. This is a crypt-oriented kernel patch, therefore you have to pay attention to your local laws regarding the use of cryptography. It basically adds the possibility of using encrypted file systems. Homepage: http://www.kerneli.org
• SubDomain. A kernel extension to create a more secure and easier to setup chroot environment. You can specify the files needed for the chrooted service manually and do not have to compile the services statically. Homepage: http://www.immunix.org/subdomain.html
• UserIPAcct. This is not really a security related patch, but it allows you to create quotas for the traffic on your server per user. And you can fetch statistics about the user traffic. Homepage: http://rsmeyers.3ti.org/useripacct
• FreeS/WAN. If you want to use IPSec with Linux, you need this patch. You can create VPNs with this quite easily, even to Windows machines, as IPSec is a common standard. Homepage: http://www.freeswan.org

6.3 Avoiding rootkits

6.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 rootkits (knark and adore) to install backdoors for GNU/Linux systems.

LKM rootkits can hide processes, files, directories and even connections without modifying the source code of binaries.

6.3.1.1 The adore rootkit

You can find it at http://packetstorm.securify.com/groups/teso/adore-0.38.tar.gz. See the README for compiling and configuring adore. Once you have already ran ./startadore you can run ./ava. The startadore script load the lkm rootkit and make it invisible on lsmod command. Now you are free to use adore, the usage of ava is very easy to understand. Just take a look at the output from ./ava.

     Usage: ./ava {h,u,r,R,i,v,U} [file, PID or dummy (for U)]
     
     	h hide file
     	u unhide file
     	r execute as root
     	R remove PID forever
     	U uninstall adore
     	i make PID invisible
     	v make PID visible

6.3.1.2 The knark rootkit

You can find it at http://packetstorm.securify.com/UNIX/penetration/rootkits/knark-0.59.tar.gz Get the source code from the address above, then compile it typing "make". So you are ready to load the lkm rootkits, use

     insmod knark.o

A hidden directory /proc/knark is created, which includes some files that will define what things will be hidden from the system, strings in /proc/net, files, pids, redirects..

6.3.1.3 The rkit toolkit

You can find it at http://packetstorm.securify.com/UNIX/penetration/rootkits/Rkit-1.01.tgz Put your UID in the rkit.c "#define magik_UID" statement as in:

     #define magik_UID 500

Compile the rkit.c and load the kernel module. All the processes made by the defined UID will be hidden from the system.

6.3.2 Detecting rootkits

Detection of rootkits in Debian can be accomplished with chkrootkit, which can detect some of them.

You can also use SKAT. SKAT 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?

6.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.

• Playing around with PAM. As said in the phrack 56 PAM article, the nice thing with PAM is that "You are limited only by what you can think of." It is true. Imagine root login only possible with fingerprint or eyescan or cryptocard (why did I do an OR conjunction and not AND here).
• Fascist Logging. I would say everything we talked about logging above is "soft logging". If you want to perform real logging, get a printer with fanfold paper and log everything hard by printing on it. Sounds funny, but it's reliable and it cannot be removed.
• CD distribution. This idea is very easy to realize and offers pretty good security. Create a hardened Debian distribution, with proper firewall rules, make an ISO image of it and burn it on CD. Make it bootable. This is a read-only distribution with about 600 MB space for services, and it is impossible for intruders to get read/write access on this system. Just make sure every data which should get written, gets written over the wires. Anyway, the intruder cannot change firewall rules, routing entries or start own daemons (he can, but reboot and he has to hack into your system again to change them).
• Switch module capability off. When you disable the usage of kernel modules at kernel compile time, many kernel based back doors are impossible to implement, since most of them are based on installing modified kernel modules.
• Logging through serial cable (contributed by Gaby Schilders). As long as servers still have serial ports, imagine having one dedicated log-machine disconnected from the net in the middle with a serial-port multiplexer (cyclades or the like). Now have all your servers log to their serial ports. Write only. The log-machine only accepts plain text as input on its serial ports and only writes it to a log-file. Hook up a cd/dvd-writer. When the log file nears 600MB it writes it to cd-rom. Now if only they would make writers with auto-changers... Not as hard-copy as the printer, but it can handle larger volumes and the cd's don't take as much storage-space.
• Set all stuff to immutable (taken from the Tips-HOWTO, written by Jim Dennis). Right after you install and configure your system go through the /bin, /sbin/, /usr/bin, /usr/sbin and /usr/lib (and a few of the other usual suspects and make liberal use of the chattr +i command. Also add that to the the kernel files in root. Now mkdir /etc/.dist/ copy everything from /etc/ on down (I do this in two steps using /tmp/etcdist.tar to avoid recursion) into that directory. (Optionally you can just create /etc/.dist.tar.gz) -- and mark that as immutable.

  The reason for all of this is to limit the damage that you can do when logged in as root. You won't overwrite files with a stray redirection operator, and you won't make the system unusable with a stray space in an rm -fr command (you might still do plenty of damage to your data — but your libs and bins will be safer.

  This also makes a variety of security and denial of service exploits either impossible or more difficult (since many of them rely on overwriting a file through the actions of some SUID program that isn't providing an arbitrary shell command).

  The only inconvenience of this is when building and doing your make install on various sorts of system binaries. On the other hand it also prevents the make install from over-writing the files. When you forget to read the Makefile and chattr -i the files that are to be overwritten (and the directories to which you want to add files) ‐ the make fails, you just use the chattr command and rerun it. You can also take that opportunity to move your old bin's, libs, or whatever into a .old/ directory or rename or tar them or whatever.

  Note that this also prevents you from upgrading your system's packages. Since the files that they provide cannot be overwritten, so you might want to have a mechanism to disable the immutable flag on all binaries right before doing an apt-get update.

6.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: 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.

• the firewalling technology you will need (provided by the Linux kernel).
• syslog-ng to send the logs from the honeypot to a remote syslog server machine.
• snort to setup capture of all the incoming network traffic to the honeypot and detect the attacks.
• osh which could be used to setup a restricted shell with logging (see Lance Spitzner's article below).
• of course, all the servers for your fake server honeypot you can imagine of (but do not harden the honeypot)).
• and also fake services, provided by dtk if you want to use the honeynet also as an intrusion detection service.
• Integrity checkers (see Checking filesystem integrity, Section 4.21) and The Coroner's Toolkit (tct) to do post-attack audits.

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 Proyect 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).