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
Intrusion Detection Checklist
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
Portsentry is another interesting package that can tip
you off when a scan is made to your site. Other tools like
iplogger will also detect some IP (TCP and ICMP) attacks, even
if they do not provide advanced techniques for detecting network attacks (like
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.
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
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
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.
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:
/proc, special file descriptor handling, non-executable user stack area and some more. Homepage:
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,
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
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.
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:
kernel-patch-2.4-lsm- LSM is the Linux Security Modules framework.
lcap- A user friendly interface to remove capabilities (kernel-based access control) in the kernel, making the system more secure. Running lcap CAP_SYS_MODULE  will remove module loading capabilities (even for the root user). 
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
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 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
/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?
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.
/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.tarto 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
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
install on various sorts of system binaries. On the other hand it also
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
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.
syslog-ngto send the logs from the honeypot to a remote syslog server machine.
snortto setup capture of all the incoming network traffic to the honeypot and detect the attacks.
oshwhich could be used to setup a restricted shell with logging (see Lance Spitzner's article below).
dtkif you want to use the honeynet also as an intrusion detection service.
tct) to do post-attack audits.
You can read more about building honeypots in Lanze Spitzner's excellent
Build a Honeypot (from the Know your Enemy series), or David
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).
Securing Debian Manual2.5 (beta) 29 augusti 2002Sat, 17 Aug 2002 12:23:36 +0200