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
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.
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.
There are also a number of log audit tools, on-site, like
logcheck
. This tools can be quite useful if properly customised
to alert the administrator on unusual events in the local filesystem.
Logcheck
can be fully customised so that it can send mails from
events recovered from the logs that are worthy of attention. The default
installation includes profiles for ignored events and policy violations for
three different setups (workstation, server and paranoid). The Debian package
includes a configuration file /etc/logcheck/logcheck.conf
, sourced
by the program, that defines which user are the checks send to. It also
provides a way for packages that provide services to implement new policies in
the directories: /etc/logcheck/hacking.d/_packagename_
,
/etc/logcheck/violations.d/_packagename_
,
/etc/logcheck/violations.ignore.d/_packagename_
,
/etc/logcheck/ignore.d.paranoid/_packagename_
,
/etc/logcheck/ignore.d.server/_packagename_
, and
/etc/logcheck/ignore.d.workstation/_packagename_
. However, not
many packages currently do so. If you have a policy that can be useful for
other users, please send it as a bug report for the appropiate package. See
For more information read /usr/share/doc/logcheck/README.Debian
Also, any of the filesystem integrity checkers (see Checking filesystem integrity, Section 4.12.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:
http://www.openwall.com/linux/
http://www.lids.org
http://acl.bestbits.at/
http://trustees.sourceforge.net/
http://www.kerneli.org
http://www.immunix.org/subdomain.html
http://ramses.smeyers.be/useripacct
.
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. 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.
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 security, the proactive and reactive.
The advantage of this defense is that its prevents that some lkm rootkit 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
- Removes 'capabilities' in the kernel, making the system
more secure
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 rootkits, 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
.
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 rootkits in Debian can be accomplished with
chkrootkit
. This program checks for signs of rootkits on the
local system and tells whether the target computer is infected with a rootkit.
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?
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.
/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
.
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.8) so that you can take appropiate measures and terminate the compromise as soon as you fill you've seen enough.
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).
dtk
if 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
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).
Securing Debian Manual
v2.2 27 april 2002Tue, 23 Apr 2002 20:56:15 +0200jfs@computer.org