You should conduct security updates frequently. The vast majority of exploits
result from known vulnerabilities that have not been patched in time, as this
paper by Bill
Arbaugh (presented at the 2001 IEEE Symposium on Security and
Privacy) explains. Updates are described under Execute a security update, Section
Debian does have an specific tool to check if a system needs to be updated (see Tiger below) but many users will just want to manually check if any security updates are available for their system.
If you have configured your system as described in Execute a security update, Section 4.2 you just need to do:
# apt-get update # apt-get upgrade -s
The first line will download the list of packages available from your configured package sources. The -s will do a simulation run, that is, it will not download or install the packages but rather tell you which ones should be downloaded/installed. From the output you can derive which packages have been fixed by Debian and are available as a security update. Sample:
# apt-get upgrade -s Reading Package Lists... Done Building Dependency Tree... Done 2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable) Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable) Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable) Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
In this example, you can see that the system needs to be updated with new cvs
and cupsys packages which are being retrieved from woody's security
update archive. If you want to understand why this packages are needed, you
should go to
check which recent Debian Security Advisories have been published related to
these packages. In this case, the related DSAs are
DSA-233 (for cvs)
Another method for automatic security updates is the use of
cron-apt. This package provides a tool to update the system at
regular intervals (using a cron job). It will just update the package list and
download new packages by default. I can also be configured to send mails to
the system administrator.
Notice that you might want to check the distribution release, as described in Checking distribution releases, Section 7.4.2, if you intend to automatically updated your system (even if only downloading the packages). Otherwise, you cannot be sured that the downloaded packages really come from a trusted source.
If you're looking for a tool to quickly check and report system security
vulnerabilities, try the
tiger package. This package is a set of
Bourne shell scripts, C programs and data files used to perform security
audits. The Debian GNU/Linux package has additional enhancements oriented
toward the Debian distribution, providing more functionality than the Tiger
scripts provided by TAMU (or even TARA, a tiger version distributed by ARSC).
See the README.Debian file and the man page
tiger(8) for more
One of these enhancements is the deb_checkadvisories script. This script takes a list of DSA's and checks against the installed package base, reporting back any packages that are vulnerable according to the Debian Security Team. This is a slightly different, more general approach than is implemented by the Tiger check_signatures script, which checks MD5sums of known vulnerable programs.
Since Debian currently does not ship a list of MD5sums of known vulnerable programs (utilized by some other operating systems like Sun Solaris), the check-against-DSA approach is used. The DSA approach and the MD5sums approach both suffer from the problem that signatures have to be updated regularly.
This is currently solved by making new versions of the Tiger package, but the
package maintainer might not make a new version every time a DSA is announced.
A nice addition, which is not yet implemented, might be to do this proactively.
That is, download the DSAs from the web, make the list and then run the check.
The DSAs are currently updated from the maintainer's local CVS update of the
WML sources used to build
web server, that is).
A program to parse published DSAs, either received through e-mail or available
in security.debian.org, and then generate the file used by
'deb_checkadvisories' to confirm vulnerabilities would be appreciated. Send it
as a bug report for
The mentioned check is run through the standard program configuration once
# Check for Debian security measures every day at 1 AM # 1 * * deb_checkmd5sums deb_nopackfiles deb_checkadvisories #
There is an additional check that you might want to add, which is not yet part
of the standard
cron scripts. That check is the script
check_patches, which works in the following way:
If you are running a stable system and add the security.debian.org
apt source line to your
described in Execute a security update,
Section 4.2), this script will be able to tell you if there are new
packages that you need to install. Since the only packages changing in this
setup are security updates, then you have just what you wanted.
Of course, this will not work if you are running testing or sid/unstable, since currently, the new packages are probably much more than security updates.
You can add this script to the checks done by the
cron job (in the
above configuration file) and
tigercron would mail (to whomever
Tiger_Mail_RCPT was set to in
# Check for Debian security measures every day at 1 am # 1 * * deb_checkmd5sums deb_nopackfiles check_patches #
You might also want to take a look at
secpack which is an
unofficial program to do security updates from security.debian.org with
signature checking written by Fruhwirth Clemens.
Unless you want to dedicate time to patch packages yourself when a vulnerability arises, you should not use Debian's unstable branch for production-level systems. The main reason for this is that there are no security updates for unstable (see How is security handled for testing and unstable?, Section 11.3.7).
The fact is that some security issues might appear in unstable and not in the stable distribution. This is due to new functionality constantly being added to the applications provided there, as well as new applications being included which might not yet have been throughly tested.
In order to do security upgrades in the unstable branch, you might have to do full upgrades to new versions (which might update much more than just the affected package). Although there have been some exceptions, security patches are usually only back ported into the stable branch. The main idea being that between updates, no new code should be added, just fixes for important issues.
If you are using the testing branch, there are some issues that you must take into account regarding the availability of security updates:
This behaviour might change based on the release state of the distribution. When a release is almost inminent, the Security Team or package maintainers might provide updates directly to testing.
First of all, automatic updates are not fully recommended, since administrators should review the DSAs and understand the impact of any given security update.
If you want to update your system automatically you should:
aptso that those packages that you do not want to update stay at their current version, either with
apt's pinning feature or marking them as hold with
To pin the packages under a given release, you must edit
Package: * Pin: release a=stable Pin-Priority: 100
FIXME: verify if this configuration is OK.
cronentry yourself so that the update is run daily, for example:
apt-get update && apt-get -y upgrade
The -y option will have
apt assume 'yes' for all the
prompts that might arise during the update. In some cases, you might want to
use the --trivial-only option instead of the
--assume-yes (equivalent to -y). 
debconfwill not ask for any input during upgrades, that way they are done non-interactively. 
cronexecution, which will be mailed to the superuser (unless changed with MAILTO environment variable in the script).
A safer alternative might be to use the -d (or
--download-only) option, which will download but not install the
necessary packages. Then if the
cron execution shows that the
system needs to be updated, it can be done manually.
In order to accomplish any of these tasks, the system must be properly configured to download security updates as discussed in Execute a security update, Section 4.2.
However, this is not recommended for unstable without careful analysis, since you might bring your system into an unusable state if some serious bug creeps into an important package and gets installed in your system. Testing is slightly more secure with regard to this issue, since serious bugs have a better chance of being detected before the package is moved into the testing branch (although, you may have no security updates available whatsoever).
If you have a mixed distribution, that is, a stable installation with
some packages updated to testing or unstable, you can fiddle
with the pinning preferences as well as the --target-release
apt-get to update only those packages that you
have updated. 
Based on the baseline information you generated after installation (i.e. the snapshot descrived in Taking a snapshot of the system, Section 4.18), you should be albe to do an integrity check from time to time. An integrity check will be able to detect filesystem modifications made by an intruder or due to a system administrators mistake.
Integrity checks should be, if possible, done offline  . That is, without using the operating system of the system to review, in order to avoid a false sense of security (i.e. false negatives) produced by, for example, installed rootkits. The integrity database that the system is checked against should also be used from read-only media.
You can consider doing integrity checks online using any of the filesystem integrity tools available (described in Checking file system integrity, Section 4.16.3) if taking offline the system is not an option. However, precaution should be taken to use a read-only integrity database and also assure that the integrity checking tool (and the operating system kernel) has not been tampered with.
Some of the tools mentioned in the integrity tools section, such as
samhain are already
prepared to do periodic reviews (through the crontab in the first two cases and
through a standalone daemon in
samhain) and can warn the
administrator through different channels (usually e-mail, but samhain can also
send pages, SNMP traps or syslog alerts) when the filesystem changes.
Of course, if you execute a security update of the system, the snapshot taken for the system should be re-taken to accomodate the changes done by the security update.
Debian GNU/Linux includes tools for intrusion detection, which is the practice of detecting inappropriate or malicious activity on your local system, or other systems in your private network. This kind of defense is important if if the system is very critical or you are truly paranoid. The most common approaches to intrusion detection are statistical anomaly detection and pattern-matching detection.
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 in place. Intrusion detection is a waste of time if you are not going to alert anyone.
When a particular attack has been detected, most intrusion detection tools will
either log the event with
syslogd or send e-mail to the root user
(the mail recipient is usually configurable). An administrator has to properly
configure the tools so that false positives do not trigger alerts. Alerts may
also indicate an ongoing attack and might not be useful, say, one day later,
since the attack might have already succeeded. So be sure that there is a
proper policy on handling alerts and that the technical mechanisms to implement
this policy are in place.
An interesting source of information is
Intrusion Detection Checklist
Network based intrusion detection tools monitor the traffic on a network segment and use this information as a data source. Specifically, the packets on the network are examined, and they are checked to see if they match a certain signature.
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 also has real-time alerting capability. You
snort for a range of hosts on your network as well as for
your own host. This is a tool which should be installed on every router to
keep an eye on your network. Just install it with apt-get install
snort, follow the questions, and watch it log.
snort package has many security checks enabled by
default. However, you should customize the setup to take into account the
particular services you run on your system. You may also want to seek
additional checks specific to these services.
Note: The snort packages available in woody are rather out of date,
and might even be
you can retrieve backported (and signed) Snort packages provided by the
There are other, simpler tools that can be used to detect network attacks.
portsentry is an interesting package that can tip you off to port
scans against your hosts. Other tools like
iplogger will also detect some IP (TCP and ICMP) attacks, even if
they do not provide the kind of advanced techniques
You can test any of these tools with the Debian package
a shell script which generates false alarms, and includes many common attack
Host based intrusion detection involves loading software on the system to be monitored which uses log files and/or the systems auditing programs as a data source. It looks for suspicious processes, monitors host access, and may even monitor changes to critical system files.
Tiger is an older intrusion detection tool which has been ported
to Debian since the Woody branch.
Tiger provides checks of common
issues related to security break-ins, like password strength, file system
problems, communicating processes, and other ways root might be compromised.
This package includes new Debian-specific security checks including: MD5sums
checks of installed files, locations of files not belonging to packages, and
analysis of local listening processes. The default installation sets up
tiger to run each day, generating a report that is sent to the
superuser about possible compromises of the system.
Log analysis tools, such as
logcheck can also be used to detect
intrusion attempts. See Using and
logcheck, Section 4.12.1.
In addition, packages which monitor file system integrity (see Checking file system integrity, Section 4.16.3) can be quite useful in detecting anomalies in a secured environment. It is most likely that an effective intrusion will modify some files in the local file system in order to circumvent local security policy, install Trojans, or create users. Such events can be detected with file system integrity checkers.
Loadable kernel modules are files containing dynamically loadable kernel components used to expand the functionality of the kernel. The main benefit of using modules is the ability to add additional devices, like an Ethernet or sound card, without patching the kernel source and recompiling the entire kernel. However, crackers are now using LKMs for root-kits (knark and adore), opening up back doors in GNU/Linux systems.
LKM back doors are more sophisticated and less detectable than traditional
root-kits. They can hide processes, files, directories and even connections
without modifying the source code of binaries. For example, a malicious LKM
can force the kernel into hiding specific processes from
so that even a known good copy of the binary
ps would not list
accurate information about the current processes on the system.
There are two approaches to defending your system against LKM root-kits, a proactive defense and a reactive defense. The detection work can be simple and painless, or difficult and tiring, depending on the approach taken.
The advantage of this kind of defense is that it prevents damage to the system
in the first place. One such strategy is getting there first, that
is, loading a LKM designed to protect the system from other malicious LKMs. A
second strategy is to remove capabilities from the kernel itself. For example,
you can remove the capability of loadable kernel modules entirely. Note,
however, that there are rootkits which might work even in this case, there are
some that tamper with
/dev/kmem (kernel memory) directly to make
Debian GNU/Linux has a few packages that can be used to mount a proactive defense:
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. For example, executing lcap CAP_SYS_MODULE  will remove module loading capabilities (even for the root user).  For more information on capabilities you might want to check out an Jon Corbet's
Kernel developmentsection on LWN (december 1999)
If you don't really need many kernel features on your GNU/Linux system, you may
want to disable loadable modules support during kernel configuration. To
disable loadable module support, just set CONFIG_MODULES=n during the
configuration stage of building your kernel, or in the
file. This will prevent LKM root-kits, but you lose this powerful feature of
the Linux kernel. Also, disabling loadable modules can sometimes overload the
kernel, making loadable support necessary.
The advantage of a reactive defense is that it does not overload system
resources. It works by comparing the system call table with a known clean copy
in a disk file,
System.map. Of course, a reactive defense will
only notify the system administrator after the system has already been
Detection of some root-kits in Debian can be accomplished with the
chkrootkit package. The
Chkrootkit program checks for signs
of several known root-kits on the target system, but is not a definitive test.
Another helpful tool is
KSTAT (Kernel Security
Therapy Anti Trolls) by the S0ftproject group. KSTAT checks the kernel memory
/dev/kmem) for information about the target host to assist
the system administrator in finding and removing malicious LKMs.
This is probably the most unstable and funny section, since I hope that some of the "duh, that sounds crazy" ideas might be realized. The following are just some ideas for increasing security — maybe genius, paranoid, crazy or inspired depending on your point of view.
chattr. (taken from the Tips-HOWTO, written by Jim Dennis). After a clean install and initial configuration, use the
chattrprogram with the +i attribute to make files unmodifiable (the file cannot be deleted, renamed, linked or written to). Consider setting this attribute on all the files in
/usr/liband the kernel files in root. You can also make a copy of all files in
taror the like, and mark the archive as immutable.
This strategy will help 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 a
command (you might still do plenty of damage to your data — but your
libraries and binaries will be safer.)
This strategy also makes a variety of security and denial of service (DoS) exploits either impossible or more difficult (since many of them rely on overwriting a file through the actions of some SETUID program that isn't providing an arbitrary shell command).
One inconvenience of this strategy arises during building and installing
various system binaries. On the other hand, it prevents the
install from over-writing the files. When you forget to read the
chattr -i the files that are to be overwritten, (and
the directories to which you want to add files) - the make command fails, and
you just use the
chattr command and rerun it. You can also take
that opportunity to move your old bin's and libs out of the way, into a .old/
directory or tar archive for example.
Note that this strategy also prevents you from upgrading your system's
packages, since the files updated packages provide cannot be overwritten. You
might want to have a script or other mechanism to disable the immutable flag on
all binaries right before doing an
FIXME: More Content specific to Debian needed.
A honeypot is a system designed to teach system administrators how crackers probe for and exploit a system. It is a system setup with the expectation and goal that the system will be probed, attacked and potentially exploited. By learning the tools and methods employed by the cracker, a system administrator can learn to better protect their own systems and network.
A Debian GNU/Linux system can easily be setup as a honeypot, if you dedicate the time to implement and monitor it. Simply setup the fake server with a firewall and some sort of network intrusion detector, put it on the Internet, and wait. Do take care that if the system is exploited, you are alerted in time (see The importance of logs and alerts, Section 4.12) so that you can take appropriate measures and terminate the compromise when you've seen enough. Here are some of the packages and issues to consider when setting up your honeypot:
syslog-ng, useful for sending logs from the honeypot to a remote syslog server.
snort, to set up capture of all the incoming network traffic to the honeypot and detect the attacks.
osh, a SETUID root, security enhanced, restricted shell with logging (see Lance Spitzner's article below).
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 provides
valuable information about building honeypots and auditing the attacks made on
Securing Debian Manual2.99 18 April 2004Wed, 3 Mar 2004 09:18:54 +0100