Securing Debian HOWTO
Chapter 6 Before the compromise

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

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

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.

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

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.

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.

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) &dash; 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.

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.

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