<!-- CVS revision of this document "$Revision: 1.24 $" -->

<chapt>Before the compromise

<sect id="keep-secure">Keep your system secure

<p>You should strive to keep your system secure by monitoring its
usage and also the vulnerabilities that might affect it, patching
them as soon as patches are available. Even though you might have
installed a really secure system initially you have to remember that
security in a system degrades with time, security vulnerabilities
might be found for exposed system services and users might expose
the system security either because of lack of understanding
(e.g. accessing a system remotely with a clear-text protocol or using easy to
guess passwords) or because they are actively trying to subvert the system's
security (e.g. install additional services locally on their accounts).

<sect1 id="track-vulns">Tracking security vulnerabilities

<p>Although most administrators are aware of security vulnerabilities
affecting their systems when they see a patch that is made available you can
strive to keep ahead of attacks and introduce temporary countermeasures
for security vulnerabilities by detecting when your system is vulnerable.
This is specially true when running an exposed system (i.e. connected
to the Internet) and providing a service. In such case the system's
administrators should take care to monitor known information sources to be the
first to know when a vulnerability is detected that might affect a critical
service.

<p>This typically includes subscribing to the announcement mailing lists,
project websites or bug tracking systems provided by the software developers
for a specific piece of code. For example, Apache users should regularly
review Apache's <url id="http://httpd.apache.org/security_report.html" 
name="lists of security vulnerabilities"> and subscribe to the
<url id="http://httpd.apache.org/lists.html#http-announce" name="Apache Server
Announcements"> mailing list.

<p>In order to track known vulnerabilities affecting the Debian distribution,
the Debian Testing Security Team provides a 
<url id="http://security-tracker.debian.net/" name="security tracker"> that lists
all the known vulnerabilities which have not been yet fixed in Debian packages.
The information in that tracker is obtained through different public channels
and includes known vulnerabilities which are available either through security
vulnerability databases or <url id="http://www.debian.org/Bugs/" name="Debian's
Bug Tracking system">. Administrators can search for the known security
issues being tracked
for
<url id="http://security-tracker.debian.net/tracker/status/release/stable" name="stable">,
<url id="http://security-tracker.debian.net/tracker/status/release/oldstable" name="oldstable">,
<url id="http://security-tracker.debian.net/tracker/status/release/testing" name="testing">,
or 
<url id="http://security-tracker.debian.net/tracker/status/release/unstable" name="unstable">.

<p>The tracker has searchable interfaces (by <url id="http://cve.mitre.org/"
name="CVE"> name and package name) and some tools (such as <package>debsecan</package>, see <ref id="debsecan">) use that database to
provide information of vulnerabilities affecting a given system
which have not yet been addressed (i.e. those who are pending a fix).

<p>Concious administrators can use that information to determine which security
bugs might affect the system they are managing, determine the severity of the
bug and apply (if available) temporary countermeasures before a patch is
available fixing this issue.

<p>Security issues tracked for releases supported by the Debian Security Team
should eventually be handled through Debian Security Advisories (DSA) and will
be available for all users (see <ref id="keep-up-to-date">). Once security
issues are fixed through an advisory they will not be available in the tracker,
but you will be able to search security vulnerabilities (by CVE name) using the
<url id="http://www.debian.org/security/crossreferences" name="security cross
references table"> available for published DSAs.

<p>Notice, however, that the information tracked by the Debian Testing Security
Team only involves disclosed vulnerabilities (i.e. those already public). In
some occasions the Debian Security Team might be handling and preparing DSAs
for packages based on undisclosed information provided to them (for example,
through closed vendor mailing lists or by upstream maintainers of software). So
do not be surprised to find security issues that only show up as an advisory
but never get to show up in the security tracker.

<sect1 id="keep-up-to-date">Continuously update the system

<p>You should conduct security updates frequently. The vast majority
of exploits result from known vulnerabilities that have not been
patched in time, as this <url
id="http://www.cs.umd.edu/~waa/vulnerability.html" name="paper by
Bill Arbaugh"> (presented at the 2001 IEEE Symposium on Security and
Privacy) explains. Updates are described under <ref
id="security-update">.

<sect2>Manually checking which security updates are available

<p>Debian does have a specific tool to check if a system needs to
be updated but many users will just want to manually check if any security
updates are available for their system. 

<p>If you have configured your system as described in 
<ref id="security-update"> you just need to do:

<example>
# apt-get update
# apt-get upgrade -s
[ ... review packages to be upgraded ... ]
# apt-get upgrade 
# checkrestart
[ ... restart services that need to be restarted ... ]
</example>

<p>And restart those services whose libraries have been updated if any.
Note: Read <ref id="security-update"> for more information on library
(and kernel) upgrades.

<p>The first line will download the list of packages available from your
configured package sources. The <tt>-s</tt> will do a simulation run, 
that is, it will <em>not</em> 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:
<example>
# 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)
</example>

<p>In this example, you can see that the system needs to be updated
with new <package>cvs</package> and <package>cupsys</package> packages which are being retrieved from
<em>woody's</em> security update archive. If you want to understand
why these packages are needed, you should go to 
<url id="http://security.debian.org"> and check which recent Debian Security
Advisories have been published related to these packages. In this case,
the related DSAs are
<url id="http://www.debian.org/security/2003/dsa-233" name="DSA-233"> (for <package>cvs</package>)
and
<url id="http://www.debian.org/security/2003/dsa-232" name="DSA-232"> (for <package>cupsys</package>).

<p>Notice that you will need to reboot your system if there has been a kernel
upgrade.

<sect2 id="update-desktop">Checking for updates at the Desktop

<p>Since Debian 4.0 <em>lenny</em> Debian provides and installs in a default
installation <package>update-notifier</package>. This is a GNOME application
that will startup when you enter your Desktop and can be used to keep
track of updates available for your system and install them. It uses
<package>update-manager</package> for this.

<p>In a stable system updates are only available when a security patch is
available or at point releases. Consequently, if the system is properly
configured to receive security updates as described in <ref
id="security-update"> and you have a cron task running to update the
package information you will be notified through an icon in the desktop
notifcation area.

<p>The notification is not intrusive and users are not forced to
install updates. From the notification icon a desktop user (with the
administrator's password) can access a simple GUI to show available updates
and install them.

<p>This application works by checking the package database and comparing
the system with its contents.  If the package database is updated periodically
through a <prgn>cron</prgn> task then the contents of the database will
be newer than the packages installed in the system and the application will
notify you.

<p><prgn>Apt</prgn> installs such a task (<file>/etc/cron.d/apt</file>) which
will run based on Apt's configuration (more specifically
<em>APT::Periodic</em>).  In the GNOME environment this configuration value can
be adjusted by going to System &gt; Admin &gt; Software origins &gt; Updates,
or running <prgn>/usr/bin/software-properties</prgn>.

<p>If the system is set to download the packages list daily but not download
the packages themselves your <file>/etc/apt/apt.conf.d/10periodic</file> should
look like this:

<example>
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
</example>

<p>You can use a different cron task, such as the one installed by 
<package>cron-apt</package> (see <ref id="cron-apt">).  You can also just
manually check for upgrades using this application. 

<p>Users of the KDE desktop environment will probably prefer to
install <package>adept</package> and <package>adept-notifier</package> instead
which offers a similar functionality but is not part of the standard
installation.

<sect2 id="cron-apt">Automatically checking for updates with cron-apt

<p>Another method for automatic security updates is the use of 
<package>cron-apt</package>. This package provides a tool to update the system
at regular intervals (using a cron job), and can also be configured
to send mails to the system administrator using the local mail transport agent.
It will just update the package list and download new packages by default
but it can be configured to automatically install new updates.

<p>Notice that you might want to check the distribution release,
as described in <ref id="check-releases">, if you intend to 
automatically updated your system (even if only downloading
the packages). Otherwise, you cannot be sure that the downloaded
packages really come from a trusted source.

<p>More information is available at the
<url id="http://www.debian-administration.org/articles/162"
name="Debian Administration site">.

<sect2 id="debsecan">Automatically checking for security issues with debsecan

<p>The <prgn>debsecan</prgn> program evaluates the security status of by
reporting both missing security updates and security vulnerabilities.
Unlike <package>cron-apt</package>, which only provides information related to
security updates available, but this tool obtains information from the security
vulnerability database maintained by the Debian Security Team which includes
also information on vulnerabilities which are not yet fixed through a security
update. Consequently, it is more efficient at helping administrators
track security vulnerabilities (as described in <ref id="track-vulns">).

<p>Upon installing the Debian package <package>debsecan</package>, and
if the administrator consents to it, it will generate a cron task that will
make it run and send the output to a specific user whenever it finds a
vulnerable package. It will also download the information from the Internet.
The location of the security database is also part of the questions ask on
installation and are later defined <file>/etc/default/debsecan</file>, it can
be easily adjusted for systems that do not have Internet access so that they
all pull from a local mirror so that there is a single point that access the
vulnerability database.

<p>Notice, however, that the Security Team tracks many vulnerabilities
including low-risk issues which might not be fixed through a security update
and some vulnerabilities initially reported as affecting Debian might, later
on, upon investigation, be dismissed.  <prgn>Debsecan</prgn> will report on all
the vulnerabilities, which makes it a quite more verbose than the other tools
described above.

<p>More information is available at the
<url id="http://www.enyo.de/fw/software/debsecan/"
name="author's siste">.


<sect2>Other methods for security updates

<p>There is also the <package>apticron</package>, which, similarly to
<package>cron-apt</package> will check for updates and send mails to
the administrator.  More information on apticron is available at the
<url id="http://www.debian-administration.org/articles/491"
name="Debian Administration site">.


<P>You might also want to take a look at 
<url id="http://clemens.endorphin.org/secpack/" name="secpack"> which
is an unofficial program to do security updates from security.debian.org
with signature checking written by Fruhwirth Clemens.
Or to the Nagios Plugin
<url id="http://www.unixdaemon.net/nagios_plugins.html#check_debian_packages"
name="check_debian_updates.sh"> written by Dean Wilson.


<sect1>Avoid using the unstable branch

<p>Unless you want to dedicate time to patch packages yourself when a
vulnerability arises, you should <em>not</em> use Debian's unstable
branch for production-level systems. The main reason for this is that
there are no security updates for <em>unstable</em> (see <ref
id="sec-unstable">).

<p>The fact is that some security issues might appear in unstable and
<em>not</em> in the <em>stable</em> 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 thoroughly tested.

<p>In order to do security upgrades in the <em>unstable</em> 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 <em>stable</em> branch. The main idea being that between updates,
<em>no new code</em> should be added, just fixes for important issues.

<p>Notice, however, that you can use the security tracker (as described
in <ref id="track-vulns">) to track known security vulnerabilities
affecting this branch.

<sect1 id="security-support-testing">Security support for the testing branch

<p>If you are using the <em>testing</em> branch, there are some issues
that you must take into account regarding the availability of security
updates:

<list>

<item>When a security fix is prepared, the Security Team backports the
patch to <em>stable</em> (since stable is usually some minor or major
versions behind). Package maintainers are responsible for preparing
packages for the <em>unstable</em> branch, usually based on a new
upstream release. Sometimes the changes happen at nearly the same
time and sometimes one of the releases gets the security fix before.
Packages for the <em>stable</em> distribution are more thoroughly
tested than <em>unstable</em>, since the latter will in most cases
provide the latest upstream release (which might include new, unknown
bugs).

<item>Security updates are available for the <em>unstable</em> branch
usually when the package maintainer makes a new package and for the
<em>stable</em> branch when the Security Team make a new upload and publish a
DSA. Notice that neither of these change the <em>testing</em> branch.

<item>If no (new) bugs are detected in the <em>unstable</em> version
of the package, it moves to <em>testing</em> after several days. The
time this takes is usually ten days, although that depends on the
upload priority of the change and whether the package is blocked from
entering <em>testing</em> by its dependency relationships. Note that if the
package is blocked from entering testing the upload priority will not
change the time it takes to enter.

</list>

<p>This behavior might change based on the release state of the
distribution. When a release is almost imminent, the Security Team or
package maintainers might provide updates directly to testing.

<p>Additionally, the <url id="http://secure-testing-master.debian.net" name="Debian Testing Security Team"> can issue Debian Testing Security
Advisories (DTSAs) for packages in the <em>testing</em> branch if there
is an inmediate need to fix a security issue in that branch and cannot
wait for the normal procedure (or the normal procedure is being blocked
by some other packages).

<p>Users willing to take advantage of this support should add the following
lines to their <file>/etc/apt/sources.list</file> (instead of the lines
described in <ref id="security-update">):

<example>
    deb http://security.debian.org testing/updates main contrib non-free
# This line makes it possible to donwload source packages too
    deb-src  http://security.debian.org testing/updates main contrib non-free
</example>

<p>For additional information on this support please read the 
<url id="http://lists.debian.org/debian-devel-announce/2006/05/msg00006.html" name="announcement">. This support officially started
in 
<url id="http://lists.debian.org/debian-devel-announce/2005/09/msg00006.html" name="September 2005"> in a separate repository and was later integrated into the main security archive.</p>

<sect1>Automatic updates in a Debian GNU/Linux system

<p>First of all, automatic updates are not fully recommended, since
administrators should review the DSAs and understand the impact of any
given security update.

<p>If you want to update your system automatically you should:

<list>

<item>Configure <prgn>apt</prgn> so that those packages that you do
not want to update stay at their current version, either with
<prgn>apt</prgn>'s <em>pinning</em> feature or marking them as
<em>hold</em> with <prgn>dpkg</prgn> or <prgn>dselect</prgn>.

<p>To pin the packages under a given release, you must edit
<file>/etc/apt/preferences</file> (see <manref section="5"
name="apt_preferences">) and add:

<example>
  Package: *
  Pin: release a=stable
  Pin-Priority: 100
</example>
<p>FIXME: verify if this configuration is OK.

<item>Either use <package>cron-apt</package> as described in <ref id="cron-apt"> and enable
it to install downloaded packages or add a <prgn>cron</prgn> entry
yourself so that the update is run daily, for example:

<example>
  apt-get update && apt-get -y upgrade
</example>

<p>The <tt>-y</tt> option will have <prgn>apt</prgn> assume 'yes' for all
the prompts that might arise during the update. In some cases, you
might want to use the <tt>--trivial-only</tt> option instead of the
<tt>--assume-yes</tt> (equivalent to <tt>-y</tt>).<!--

--><footnote>You may also want to use the <tt>--quiet</tt> (<tt>-q</tt>)
option to reduce the output of <prgn>apt-get</prgn>, which will stop
the generation of any output if no packages are installed.</footnote>

<item>Configure <prgn>debconf</prgn> so no questions will be asked
during upgrades, so that they can be done non-interactively. <footnote>Note
that some packages might <em>not</em> use <prgn>debconf</prgn> and updates will
stall due to packages asking for user input during configuration.</footnote>

<item>Check the results of the <prgn>cron</prgn> execution, which will
be mailed to the superuser (unless changed with <tt>MAILTO</tt>
environment variable in the script).

</list>

<p>A safer alternative might be to use the <tt>-d</tt> (or
<tt>--download-only</tt>) option, which will download but not install
the necessary packages. Then if the <prgn>cron</prgn> execution shows
that the system needs to be updated, it can be done manually.

<p>In order to accomplish any of these tasks, the system must be
properly configured to download security updates as discussed in <ref
id="security-update">.

<p>However, this is not recommended for <em>unstable</em> 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. <em>Testing</em> is slightly more
<em>secure</em> 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 <em>no</em> security updates
available whatsoever).

<p>If you have a mixed distribution, that is, a <em>stable</em>
installation with some packages updated to <em>testing</em> or
<em>unstable</em>, you can fiddle with the pinning preferences as well
as the <tt>--target-release</tt> option in <prgn>apt-get</prgn> to
update <em>only</em> those packages that you have updated.<!--
--><footnote>This is a common issue since many users want to maintain a
stable system while updating some packages to <em>unstable</em> to
gain the latest functionality. This need arises due to some projects
evolving faster than the time between Debian's <em>stable</em>
releases.</footnote>

<sect id="periodic-integrity">Do periodic integrity checks 

<p>Based on the baseline information you generated after installation
(i.e. the snapshot described in <ref id="snapshot">), you should be
able 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.

<p>Integrity checks should be, if possible, done offline.<!--
--><footnote>
An easy way to do this is using a Live CD, such as 
<url id="http://www.knoppix-std.org/" name="Knoppix Std"> which includes
both the file integrity tools and the integrity database for your system.
</footnote>
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.

<p>You can consider doing integrity checks online using any of the
filesystem integrity tools available (described in <ref
id="check-integ">) 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.

<P>Some of the tools mentioned in the integrity tools section, such as
<prgn>aide</prgn>, <prgn>integrit</prgn> or <prgn>samhain</prgn> are
already prepared to do periodic reviews (through the crontab in the
first two cases and through a standalone daemon in
<prgn>samhain</prgn>) and can warn the administrator through different
channels (usually e-mail, but <prgn>samhain</prgn> can also send pages, SNMP
traps or syslog alerts) when the filesystem changes.

<p>Of course, if you execute a security update of the system, the
snapshot taken for the system should be re-taken to accommodate the
changes done by the security update.

</sect>
<sect id="intrusion-detect">Set up Intrusion Detection

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

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

<p>When a particular attack has been detected, most intrusion
detection tools will either log the event with <prgn>syslogd</prgn> 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.

<p>An interesting source of information is
<url id="http://www.cert.org/tech_tips/intruder_detection_checklist.html"
name="CERT's Intrusion Detection Checklist">

<sect1>Network based intrusion detection

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

<p><package>snort</package> 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. <prgn>snort</prgn>
also has real-time alerting capability. You can use <prgn>snort</prgn>
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 <tt>apt-get install
snort</tt>, follow the questions, and watch it log. For a little broader
security framework, see <url id="http://www.prelude-ids.org" name="Prelude">.

<p>Debian's <package>snort</package> 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.

<p>There are other, simpler tools that can be used to detect network
attacks. <package>portsentry</package> is an interesting package that
can tip you off to port scans against your hosts. Other tools like
<package>ippl</package> or <package>iplogger</package> will also
detect some IP (TCP and ICMP) attacks, even if they do not provide the
kind of advanced techniques <prgn>snort</prgn> does.

<p>You can test any of these tools with the Debian package
<package>idswakeup</package>, a shell script which generates false
alarms, and includes many common attack signatures.

<sect1>Host based intrusion detection 

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

<p><package>tiger</package> is an older intrusion detection tool which
has been ported to Debian since the Woody branch. <prgn>tiger</prgn>
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
<prgn>tiger</prgn> to run each day, generating a report that is sent
to the superuser about possible compromises of the system.

<p>Log analysis tools, such as <package>logcheck</package> can also be
used to detect intrusion attempts. See <ref id="custom-logcheck">.

<p>In addition, packages which monitor file system integrity (see <ref
id="check-integ">) 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.

<sect>Avoiding root-kits

<sect1 id="LKM">Loadable Kernel Modules (LKM)

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

<p>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 <file>procfs</file>, so that even a known good copy of
the binary <prgn>ps</prgn> would not list accurate information about
the current processes on the system.

<sect1>Detecting root-kits

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

<sect2 id="proactive">Proactive defense

<p>The advantage of this kind of defense is that it prevents damage to
the system in the first place. One such strategy is <em>getting there
first</em>, that is, loading an 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 <file>/dev/kmem</file> (kernel memory) directly to make
themselves undetectable.

<p>Debian GNU/Linux has a few packages that can be used to mount a
proactive defense:

<list>

<item><package>lcap</package> - A user friendly interface to remove
<em>capabilities</em> (kernel-based access control) in the kernel,
making the system more secure. For example, executing <tt>lcap
CAP_SYS_MODULE</tt>
<footnote>
There are over 28 capabilities including:
<tt>CAP_BSET</tt>,
<tt>CAP_CHOWN</tt>,
<tt>CAP_FOWNER</tt>,
<tt>CAP_FSETID</tt>,
<tt>CAP_FS_MASK</tt>,
<tt>CAP_FULL_SET</tt>,
<tt>CAP_INIT_EFF_SET</tt>,
<tt>CAP_INIT_INH_SET</tt>,
<tt>CAP_IPC_LOCK</tt>,
<tt>CAP_IPC_OWNER</tt>,
<tt>CAP_KILL</tt>,
<tt>CAP_LEASE</tt>,
<tt>CAP_LINUX_IMMUTABLE</tt>,
<tt>CAP_MKNOD</tt>,
<tt>CAP_NET_ADMIN</tt>,
<tt>CAP_NET_BIND_SERVICE</tt>,
<tt>CAP_NET_RAW</tt>,
<tt>CAP_SETGID</tt>, 
<tt>CAP_SETPCAP</tt>,
<tt>CAP_SETUID</tt>,
<tt>CAP_SYS_ADMIN</tt>,
<tt>CAP_SYS_BOOT</tt>,
<tt>CAP_SYS_CHROOT</tt>,
<tt>CAP_SYS_MODULE</tt>,
<tt>CAP_SYS_NICE</tt>,
<tt>CAP_SYS_PACCT</tt>,
<tt>CAP_SYS_PTRACE</tt>,
<tt>CAP_SYS_RAWIO</tt>,
<tt>CAP_SYS_RESOURCE</tt>,
<tt>CAP_SYS_TIME</tt>, and
<tt>CAP_SYS_TTY_CONFIG</tt>. All of them can be de-activated to harden your
kernel.
</footnote>
will remove module loading capabilities (even for the root user).<!--
--><footnote>
You don't need to install <package>lcap</package> to do this, but it's
easier than setting <file>/proc/sys/kernel/cap-bound</file> by hand.
</footnote>
There is some (old) information on capabilities at
Jon Corbet's <url id="http://lwn.net/1999/1202/kernel.php3" 
name="Kernel development"> section on LWN (dated December 1999).

</list>

<p>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>.config</file> 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.

<sect2>Reactive defense

<p>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, <file>System.map</file>. Of course, a
reactive defense will only notify the system administrator after the
system has already been compromised.

<p>Detection of some root-kits in Debian can be accomplished with the
<package>chkrootkit</package> package. The <url name="Chkrootkit"
id="http://www.chkrootkit.org"> program checks for signs of several
known root-kits on the target system, but is not a definitive test.

<sect>Genius/Paranoia Ideas &mdash; what you could do

<p>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 &mdash; maybe
genius, paranoid, crazy or inspired depending on your point of view.

<list>

<item>Playing around with Pluggable Authentication Modules (PAM). As
quoted in the Phrack 56 PAM article, the nice thing about PAM is that
"You are limited only by what you can think of." It is true. Imagine
root login only being possible with fingerprint or eye scan or
cryptocard (why did I use an OR conjunction instead of AND?).

<item>Fascist Logging. I would refer to all the previous logging
discussion above as "soft logging". If you want to perform real
logging, get a printer with fanfold paper, and send all logs to
it. Sounds funny, but it's reliable and it cannot be tampered with or
removed.

<item>CD distribution. This idea is very easy to realize and offers
pretty good security. Create a hardened Debian distribution, with
proper firewall rules. Turn it into a boot-able ISO image, and burn it
on a CDROM. Now you have a read-only distribution, with about 600 MB
space for services. Just make sure all data that should get written is
done over the network. It is impossible for intruders to get
read/write access on this system, and any changes an intruder does
make can be disabled with a reboot of the system.

<item>Switch module capability off. As discussed earlier, when you
disable the usage of kernel modules at kernel compile time, many
kernel based back doors are impossible to implement because most are
based on installing modified kernel modules.

<item>Logging through serial cable (contributed by Gaby Schilders). As
long as servers still have serial ports, imagine having one dedicated
logging system for a number of servers. The logging system is
disconnected from the network, and connected to the servers via 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 to a
log file. Connect a CD/DVD-writer, and transfer the log file to it
when the log file reaches the capacity of the media. Now if only they
would make CD writers with auto-changers... Not as hard copy as direct
logging to a printer, but this method can handle larger volumes and
CD-ROMs use less storage space.

<item>Change file attributes using <prgn>chattr</prgn> (taken from
the Tips-HOWTO, written by Jim Dennis). After a clean install and
initial configuration, use the <prgn>chattr</prgn> program with the
<tt>+i</tt> attribute to make files unmodifiable (the file cannot be
deleted, renamed, linked or written to). Consider setting this
attribute on all the files in <file>/bin</file>, <file>/sbin/</file>,
<file>/usr/bin</file>, <file>/usr/sbin</file>, <file>/usr/lib</file>
and the kernel files in root. You can also make a copy of all files in
<file>/etc/</file>, using <prgn>tar</prgn> or the like, and mark the
archive as immutable.

<p>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 <prgn>rm -fr</prgn> command (you might still do plenty of damage to
your data &mdash; but your libraries and binaries will be safer).

<p>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 <em>isn't providing an arbitrary shell command</em>).

<p>One inconvenience of this strategy arises during building and
installing various system binaries. On the other hand, it prevents the
<prgn>make install</prgn> from over-writing the files. When you forget
to read the Makefile and <prgn>chattr -i</prgn> the files that are to
be overwritten, (and the directories to which you want to add files)
&dash; the make command fails, and you just use the
<prgn>chattr</prgn> 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.

<p>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
<prgn>apt-get update</prgn>.

<item>Play with UTP cabling in a way that you cut 2 or 4 wires and
make the cable one-way traffic only. Then use UDP packets to
send information to the destination machine which can act as a secure log
server or a credit card storage system.

</list>

<sect1>Building a honeypot

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

<p>Debian GNU/Linux systems can easily be used to setup a honeynet, if
you dedicate the time to implement and monitor it. You can easily
setup the fake honeypot server as well as the firewall<footnote>You
will typically use a bridge firewall so that the firewall itself is
not detectable, see <ref id="bridge-fw">.</footnote> that controls the
honeynet 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 <ref id="log-alerts">) 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:

<list>

<item>The firewall technology you will use (provided by the Linux
kernel).

<item><package>syslog-ng</package>, useful for sending logs from the
honeypot to a remote syslog server.

<item><package>snort</package>, to set up capture of all the incoming
network traffic to the honeypot and detect the attacks.

<item><package>osh</package>, a SETUID root, security enhanced,
restricted shell with logging (see Lance Spitzner's article below).

<item>Of course, all the daemons you will be using for your fake
server honeypot. Depending on what type of attacker you want to
analyse you will or will <em>not</em> harden the honeypot and keep
it up to date with security patches.

<item>Integrity checkers (see <ref id="check-integ">) and The
Coroner's Toolkit (<package>tct</package>) to do post-attack audits.

<item><package>honeyd</package> and <package>farpd</package> to setup a
honeypot that will listen to connections to unused IP addresses and
forward them to scripts simulating live services. Also check out
<package>iisemulator</package>.

<item><package>tinyhoneypot</package> to setup a simple honeypot server
with fake services.

</list>

<p>If you cannot use spare systems to build up the honeypots and the
network systems to protect and control it you can use the
virtualisation technology available in <prgn>xen</prgn> or
<prgn>uml</prgn> (User-Mode-Linux). If you take this route you will
need to patch your kernel with either
<package>kernel-patch-xen</package> or
<package>kernel-patch-uml</package>.

<p>You can read more about building honeypots in Lanze Spitzner's
excellent article <url
id="http://www.net-security.org/text/articles/spitzner/honeypot.shtml"
name="To Build a Honeypot"> (from the Know your Enemy series).
Also, the <url id="http://project.honeynet.org/" name="Honeynet Project"> 
provides valuable information about building honeypots and auditing the 
attacks made on them.