Attachment #60255 for bug #71211

View | Details | Raw Unified | Return to bug 71211 | Differences between
Collapse All | Expand All




<?xml version='1.0' encoding='UTF-8'?>
<!-- $Header: /var/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/gentoo-security.xml,v 1.81 2005/05/23 19:34:03 swift Exp $ -->

<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link = "/doc/en/gentoo-security.xml">
<title>Gentoo Linux Security Guide</title>
<author title="Author">
  <mail link="kn@insecurity.dk">Kim Nielsen</mail>
</author>
<author title="Editor"><!-- zhen@gentoo.org -->
  John P. Davis
</author>
<author title="Editor">
  <mail link="stocke2@gentoo.org">Eric R. Stockbridge</mail>
</author>
<author title="Editor">
  <mail link="carl@gentoo.org">Carl Anderson</mail>
</author>
<author title="Editor">
  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
</author>
<author title="Editor">
  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
</author>
<author title="Editor">
  <mail link="bennyc@gentoo.org">Benny Chuang</mail>
</author>
<author title="Editor">
  <mail link="jaervosz@itu.dk">Sune Jeppesen</mail>
</author>
<author title="Editor">
  <mail link="blubber@gentoo.org">Tiemo Kieft</mail>
</author>
<author title="Editor">
        <mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
</author>
<author title="Editor">
  <mail link="krispykringle@gentoo.org">Dan Margolis</mail>
</author>

<abstract>
Deprecated.
</abstract>

<license/>

<version>0.4.48</version>
<date>2005-05-23</date>

<chapter>
<title>Introduction</title>
<section>
<body>

<p>
This guide has been deprecated in favor of the 
<uri link="/doc/en/security/index.xml">Gentoo Linux Security Handbook</uri>
</p>

<note>
If you are interested in even more Gentoo security stuff after reading this
guide then have a look at the <uri link="http://www.gentoo.org/proj/en/hardened/">Hardened Gentoo Project</uri>
</note>

</body>
</section>

<!-- 
<section>
<title>Enhancements for future releases of this Guide:</title>
<body>

<p>
In version 0.6 (Backup)
</p>
<ul>
<li>Arpwatch</li>
<li>Full system backup using Systemimager</li>
<li>Partial backup using tar</li>
<li>Backing up postgres</li>
</ul>


<p>
In version 0.8 (Penetration testing)
</p>
<ul>
<li>Remote audits</li>
<li>Network audits</li>
<li>Host audits</li>
<li>Software audits</li>
</ul>

<p>
In version 1.0 (After a compromise)
</p>
<ul>
<li>How to report an incident</li>
<li>Forensics analysis</li>
<li>Creating an image of the system without destroying evidence (Using dd)</li>
<li>Trap and trace (Using tcpdump)</li>
<li>.. More to come ..</li>
<li>Restoring system</li>
</ul>

<note>
Please note that each version concentrates on one subject at a time.  This is for
quality assurance purposes.
</note>

</body>
</section>
-->
</chapter>

<chapter>
<title>Pre-Installation Concerns</title>
<section>
<title>Physical Security</title>
<body>

<p>
No matter how many safeguards you implement, they can all be easily circumvented
by an attacker with physical access to your computer. Despite this, there are
at least some measures that can be taken to provide a degree of security against
an attacker with physical access to your machine. Putting your hardware in a
locked closet prevents an attacker from simply unplugging it and carting it
off. Locking your computer's case is also a good idea, to make sure that an
attacker cannot simply walk away with your hard drive. To prevent an attacker
from booting from another disk, nicely circumventing your permissions and login
restrictions, try setting the hard drive as the first boot device in your BIOS,
and setting a BIOS password. It is also important to set a LILO or GRUB boot
password, to prevent a malicious user from booting into single-user mode and
gaining complete access to your system. This is covered in more detail in
Chapter 3, under <uri link="#passwording_GRUB">Setting a GRUB password</uri>
and <uri link="#passwording_LILO">Setting a LILO password</uri>.
</p>

</body>
</section>
<section>
<title>Daemon/Service Planning</title>
<body>
<p>
Start by documenting what services this machine should run. This will help you
compose a better partition scheme for your system, and allow you to better plan
your security measures. Of course, this is unnecessary if the machine serves a
single simple purpose, such as a desktop, or a dedicated firewall. In those
cases, you should not be running <e>any</e> services, except perhaps sshd.
</p>
<p>
This list can also be used to aid system administration. By keeping a current
list of version information, you will find it much easier to keep everything up
to date if a remote vulnerability is discovered in one of your daemons.
</p>

</body>
</section>
<section>
<title>Partitioning Schemes</title>
<body>

<p>
Partitioning rules:
</p>

<ul>
<li>
  Any directory tree a user should be able to write to (e.g. <path>/home</path>, 
  <path>/tmp</path>) should be on a separate partition and use disk quotas. This
  reduces the risk of a user filling up your whole filesystem. Portage
  uses <path>/var/tmp</path> to compile files, so that partition should be large.
</li>
<li>
  Any directory tree where you plan to install non-distribution software on should
  be on a separate partition. According to the <uri link="http://www.pathname.com/fhs/">File Hierarchy Standard</uri>, this
  is <path>/opt</path> or <path>/usr/local</path>.  If these are separate
  partitions, they will not be erased if you have to reinstall the system.
</li>
<li>
  For extra security, static data can be put on a separate partition that is
  mounted read-only. For the truly paranoid, try using read-only media like
  CD-ROM.
</li>
</ul>

</body>
</section>
<section>
<title>The root user</title>
<body>

<p>
The user 'root' is the most vital user on the system and should not be
used for anything except when absolutely necessary. If an attacker gains root
access, the only way to ever trust your system again is to reinstall.
</p>

<p>
Golden rules about 'root'
</p>

<ul>
<li>
  Always create a user for everyday use and if this user needs to have root
  access, add the user to the group 'wheel'. This makes it possible for a normal
  user to <c>su</c> to root.
</li>
<li>
  Never run X or any other user application as root. root should only be used when
  absolutely necessary; if a vulnerability exists in an application running as a
  user, an attacker can gain user level access. But if that application is running
  as root, the attacker gains root access.
</li>
<li>
  Always use absolute paths when logged in as root (or always use <c>su -</c>,
  which replaces the environmental variables of the user with those of root,
  while being sure root's <c>PATH</c> only includes protected directories
  like <path>/bin</path> and <path>/sbin</path>). It's possible to trick
  root into running a different application rather than the one meant to be
  run. If root's <c>PATH</c> is protected or root only uses absolute paths, we can
  be sure this won't happen.
</li>
<li>
  If a user only needs to run a few commands as root, instead of everything that
  root normally can do, consider using <c>sudo</c> instead. Just be careful who
  you give this access to, as well!
</li>
<li>
  Never leave the terminal when you are logged in as root.
</li>
</ul>

<p>
Gentoo has some default protection against normal users trying to <c>su</c> to
root. The default PAM setting requires that a user be a member of the group
"wheel" in order to be able to <c>su</c>.
</p>

</body>
</section>
<section id="security_policies">
<title>Security policies</title>
<body>

<p>
There are several reasons to draft a security policy for your system(s) and
network.
</p> 

<ul>
<li>
  A good security policy allows you to outline security as a "system", rather
  than simply a jumble of different features. For example, without a policy an
  administrator might decide to turn off telnet, because it transmits
  unencrypted passwords, but leave on FTP access, which has the same weakness. A
  good security policy allows you to identify which security measures are
  worthwhile, and which are not.
</li>
<li>
  In order to diagnose problems, conduct audits, or track down intruders, it may
  be necessary to intercept network traffic, inspect the login and command
  history of users, and look in home directories. Without outlining this in
  print, and making users aware of this, such actions may actually be illegal
  and put <e>you</e> in legal jeopardy.
</li>
<li>
  Hijacked user accounts pose one of the most common threats to system
  security. Without explaining to users why security is important, and how to
  practice good security (such as not writing passwords on a Post-It note on
  their desks), it is unlikely you will have any hope of secure user accounts.
</li>
<li>
  A well-documented network and system layout will aid you, as well as law
  enforcement forensics examiners, if need be, in tracing an intrusion and
  identifying weaknesses after the fact. A security policy "issue" banner,
  stating that your system is a private network and all unauthorized access is
  prohibited, will also help ensure your ability to properly prosecute an
  intruder, once he is caught.
</li>
</ul>

<p>
The need for a good security policy is hopefully now more than clear.
</p>

<p>
The policy itself is a document, or several documents, that outlines the network
and system features (such as what services are provided), acceptable use and
forbidden use, security "best practices", and so forth. All users should be made
aware of your security policy, as well as changes you make to keep it up to
date. It is important that you take the time to help users understand your
policy and why that policy needs to be signed or what will happens if they act
directly against the policy (the policy should also state this). This should be
repeated at least once a year, since the policy can change (but also as a
reminder to the user of the policy itself).
</p>

<note>
Create policies that are easy to read and be very precise on every subject.
</note>

<p>
A security policy should at least contain the following subjects:
</p>

<ul>
<li>Acceptable use
  <ul>
  <li>Screen savers</li>
  <li>Password handling</li>
  <li>Software download and installation</li>
  <li>Information stating if the users are being monitored</li>
  <li>Use of anti-virus software</li>
  </ul>
</li>
<li>Handling of sensitive information (any written form, paper or digital)
  <ul>
  <li>Clean desk and locked up classified information</li>
  <li>PC shutdown before leaving</li>
  <li>Use of encryption</li>
  <li>Handling of keys to trusted co-workers</li>
  <li>Handling of confidential material when traveling</li>
  </ul>
</li>
<li>Handling of computer equipment when traveling
  <ul>
  <li>Laptop handling during travels and hotel stays</li>
  </ul>
</li>
</ul>

<p>
Different users may require different levels or types of access, and as such
your policy may vary to accommodate them all.
</p>

<p>
The security policy can become huge, and vital information can easily be
forgotten. The IT-staff's policy could contain information that is confidential
for the ordinary user, so it is wise to split it up into smaller policies;
e.g. Acceptable Use Policy, Password policy, Email policy and Remote Access
policy.
</p>

<p>
You can find example policies at <uri link="http://www.sans.org/resources/policies/">The SANS Security Policy
Project</uri>. If you have a small network and think these policies are too much
you should look at the <uri link="ftp://ftp.isi.edu/in-notes/rfc2196.txt">Site Security
Handbook</uri>.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Tightening security during and after installation</title>
<section>
<title>USE flags</title>
<body>

<p>
The <path>make.conf</path> file contains user defined USE flags and
<path>/etc/make.profile/make.defaults</path> contains the default USE flags for
Gentoo Linux. For this guide's purposes, the important flags are <c>pam</c>
(Pluggable Authentication Modules), <c>tcpd</c> (TCP wrappers), and <c>ssl</c>
(Secure Socket Layer). These are all in the default USE flags.
</p>

</body>
</section>
<section id="passwording_GRUB">
<title>Password protecting GRUB</title>
<body>

<p>
GRUB supports two different ways of adding password protection to your boot
loader. The first uses plain text, while the latter uses md5+salt encryption.
</p>

<pre caption="/boot/grub/grub.conf">
timeout 5
password changeme
</pre>

<p>
This will add the password <c>changeme</c>. If no password is entered at boot,
GRUB will simply use the default boot setting.
</p>

<p>
When adding an md5 password, you must convert your password into crypt format,
which is the same format used in <path>/etc/shadow</path>. For more information
see <c>man crypt</c>. The encrypted password <e>changeme</e>, for example, could
look like this: <c>$1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs</c>.
</p>

<p>
You can encrypt your password directly at the GRUB shell:
</p>

<pre caption="md5crypt in grub shell">
#<i>/sbin/grub</i>

GRUB version 0.92 (640K lower / 3072K upper memory)

   [ Minimal BASH-like line editing is supported. For the first word, TAB lists
     possible command completions. Anywhere else TAB lists the possible
     completions of a device/filename. ]

grub&gt; <i>md5crypt</i>

Password: <i>********</i>
<comment>(Typed changeme at the prompt)</comment> 
Encrypted: $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.

grub&gt; <i>quit</i>
</pre>

<p>
Then, cut and paste your password to <path>/boot/grub/grub.conf</path>.
</p>

<pre caption="/boot/grub/grub.conf">
timeout 5 
password --md5 $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.
</pre>

<p>
The 5 seconds timeout becomes handy if the system is remote and should be able
to reboot without any keyboard interaction. Learn more about GRUB passwords by
executing <c>info grub</c>.
</p>

</body>
</section>
<section id="passwording_LILO">
<title>Password protecting LILO</title>
<body>

<p>
LILO also supports two ways of handling passwords: global and per-image, both in
clear text.
</p>

<p>
The global password is set at the top of the configuration file, and applies to
every boot image:
</p>

<pre caption="/etc/lilo.conf">
password=changeme 
restricted 
delay=3
</pre>

<p>
The per-image password is set as below:
</p>

<pre caption="/etc/lilo.conf">
image=/boot/bzImage 
      read-only 
      password=changeme 
      restricted
</pre>

<p>
If the <c>restricted</c> option is not entered, it will prompt for a password
every time.
</p>

<p>
In order to store the new information in <path>lilo.conf</path>, you must run
<c>/sbin/lilo</c>.
</p>

</body>
</section>
<section>
<title>Restricting Console Usage</title>
<body>

<p>
The <path>/etc/securetty</path> file allows you to specify which <c>tty</c>
(terminal) devices root is allowed to login in from.
</p>

<p>
We suggest that you comment out all lines except <c>vc/1</c>. This will ensure
that root only can login once and only on one terminal.
</p>

<note>
Users in the group "wheel" can still <c>su -</c> to become root on other TTYs.
</note>

<pre caption="/etc/securetty">
vc/1
</pre>

</body>
</section>
</chapter>

<chapter>
<title>More logging</title>
<section>
<body>

<p>
Extra logging should be added to catch warnings or errors that might indicate
an ongoing attack or a successful compromise. Attackers often scan or probe
before attacking.
</p>

<p>
It's also vital that your log files are easily readable and manageable. Gentoo
Linux lets you choose between 3 different loggers when installing.
</p>

</body>
</section>
<section>
<title>Logging: Syslogd</title>
<body>

<p>
Syslogd is the most common logger for Linux and Unix in general. 
It has some log rotation facilities, but using 
<path>/usr/sbin/logrotate</path> in a cron job (logrotate is configured in
<path>/etc/logrotate.conf</path>) might prove to be more powerful as
<c>logrotate</c> has many features. How often 
log rotation should be done depends on the system load.
</p>

<p>
Below is the standard <path>syslog.conf</path> with some added features. We 
have uncommented the <c>cron</c> and <c>tty</c> lines and added a remote 
logging server. To further enhance security you could add logging to two places.
</p>

<pre caption="/etc/syslog.conf">
#  /etc/syslog.conf      Configuration file for syslogd.
#
#                       For more information see syslog.conf(5)
#                       manpage.
#                       This is from Debian, we are using it for now
#                       Daniel Robbins, 5/15/99

#
# First some standard logfiles.  Log by facility.
#

auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          /var/log/mail.log
user.*                          -/var/log/user.log
uucp.*                          -/var/log/uucp.log
local6.debug                    /var/log/imapd.log

#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

# Logging for INN news system
#
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice

#
# Some `catch-all' logfiles.
#
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

#
# Emergencies and alerts are sent to everybody logged in.
#
*.emerg                         *
*.=alert                        *

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
daemon,mail.*;\
       news.=crit;news.=err;news.=notice;\
       *.=debug;*.=info;\
       *.=notice;*.=warn       /dev/tty8

#Setup a remote logging server
*.*                        @logserver

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
# 
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
#daemon.*,mail.*;\
#       news.crit;news.err;news.notice;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       |/dev/xconsole

local2.*                --/var/log/ppp.log
</pre>

<p>
Attackers will most likely try to erase their tracks by editing or deleting log
files. You can make it harder for them by logging to one or more remote logging
servers on other machines. Get more info about syslogd by executing <c>man
syslog</c>.
</p>

</body>
</section>
<section>
<title>Metalog</title>
<body>

<p>
<uri link="http://metalog.sourceforge.net">Metalog</uri> by Frank Dennis is not
able to log to a remote server, but it does have advantages when it comes to
performance and logging flexibility. It can log by program name, urgency,
facility (like syslogd), and comes with regular expression matching with which
you can launch external scripts when specific patterns are found. It is very good
at taking action when needed.
</p> 

<p>
The standard configuration is usually enough.  If you want to be notified by
email whenever a password failure occurs use one of the following scripts.
</p>

<p>
For postfix:
</p>

<pre caption="/usr/local/sbin/mail_pwd_failures.sh for postfix">
#! /bin/sh
echo "$3" | mail -s "Warning (program : $2)" root
</pre>

<p>
For qmail:
</p>

<pre caption="/usr/local/sbin/mail_pwd_failures.sh for qmail">
#!/bin/sh
echo "To: root
Subject:Failure (Warning: $2) 
$3
" | /var/qmail/bin/qmail-inject -f root
</pre>

<p>
Remember to make the script executable by issuing <c>/bin/chmod +x 
/usr/local/sbin/mail_pwd_failures.sh</c>
</p>

<p>
Then uncomment the command line under "Password failures" in 
<path>/etc/metalog/metalog.conf</path> like:
</p>

<pre caption="/etc/metalog/metalog.conf">
command  = "/usr/local/sbin/mail_pwd_failures.sh"
</pre>

</body>
</section>
<section>
<title>Syslog-ng</title>
<body>

<p>
Syslog-ng provides some of the same features as syslog and metalog with a small
difference. It can filter messages based on level and content (like metalog),
provide remote logging like syslog, handle logs from syslogd (even streams from
Solaris), write to a TTY, execute programs, and it can act as a logging server.
Basically it is the best of both loggers combined with advanced configuration.
</p>

<p>
Below is a classic configuration file slightly modified.
</p>

<pre caption="/etc/syslog-ng/syslog-ng.conf">
options { long_hostnames(off); sync(0); };

#source where to read log
source src { unix-stream("/dev/log"); internal(); };
source kernsrc { file("/proc/kmsg"); };

#define destinations
destination authlog { file("/var/log/auth.log"); };
destination syslog { file("/var/log/syslog"); };
destination cron { file("/var/log/cron.log"); };
destination daemon { file("/var/log/daemon.log"); };
destination kern { file("/var/log/kern.log"); };
destination lpr { file("/var/log/lpr.log"); };
destination user { file("/var/log/user.log"); };
destination mail { file("/var/log/mail.log"); };

destination mailinfo { file("/var/log/mail.info"); };
destination mailwarn { file("/var/log/mail.warn"); };
destination mailerr { file("/var/log/mail.err"); };

destination newscrit { file("/var/log/news/news.crit"); };
destination newserr { file("/var/log/news/news.err"); };
destination newsnotice { file("/var/log/news/news.notice"); };

destination debug { file("/var/log/debug"); };
destination messages { file("/var/log/messages"); };
destination console { usertty("root"); };
destination console_all { file("/dev/tty12"); };
destination xconsole { pipe("/dev/xconsole"); };

#create filters
filter f_auth { facility(auth); };
filter f_authpriv { facility(auth, authpriv); };
filter f_syslog { not facility(authpriv, mail); };
filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_user { facility(user); };
filter f_debug { not facility(auth, authpriv, news, mail); };
filter f_messages { level(info..warn) 
        and not facility(auth, authpriv, mail, news); };
filter f_emergency { level(emerg); };

filter f_info { level(info); };
filter f_notice { level(notice); };
filter f_warn { level(warn); };
filter f_crit { level(crit); };
filter f_err { level(err); };
filter f_failed { match("failed"); };
filter f_denied { match("denied"); };

#connect filter and destination
log { source(src); filter(f_authpriv); destination(authlog); };
log { source(src); filter(f_syslog); destination(syslog); };
log { source(src); filter(f_cron); destination(cron); };
log { source(src); filter(f_daemon); destination(daemon); };
log { source(kernsrc); filter(f_kern); destination(kern); };
log { source(src); filter(f_lpr); destination(lpr); };
log { source(src); filter(f_mail); destination(mail); };
log { source(src); filter(f_user); destination(user); };
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };

log { source(src); filter(f_debug); destination(debug); };
log { source(src); filter(f_messages); destination(messages); };
log { source(src); filter(f_emergency); destination(console); };

#default log
log { source(src); destination(console_all); };
</pre>

<p>
Syslog-ng is very easy to configure, but it is also very easy to miss something
in the configuration file since it is huge. The author still promises some extra
features like encryption, authentication, compression and MAC (Mandatory Access
Control) control. With these options it will be a perfect for network logging,
since the attacker cannot spy on the log.
</p>

<p>
And syslog-ng does have one other advantage: it does not have to run as root!
</p>

</body>
</section>

<section>
<title>Log analysis with Logcheck</title>
<body>

<p>
Of course, keeping logs alone is only half the battle. An application such as
Logcheck can make regular log analysis much easier. Logcheck is a script,
accompanied by a binary called <c>logtail</c>, that runs from your cron daemon
and checks your logs against a set of rules for suspicious activity. It then
mails the output to root's mailbox.
</p>
<p>
Logcheck and logtail are part of the <c>app-admin/logsentry</c> package.
</p>
<p>
Logcheck uses four files to filter important log entries from the
unimportant. These files are <path>logcheck.hacking</path>, which contains known
hacking attack messages, <path>logcheck.violations</path>, which contains
patterns indicating security
violations, <path>logcheck.violations.ignore</path>, which contains keywords
likely to be matched by the violations file, allowing normal entries to be
ignored, and <path>logcheck.ignore</path>, which matches those entries to be
ignored.
</p>

<warn>
Do not leave <path>logcheck.violations.ignore</path> empty. Logcheck
uses <c>grep</c> to parse logs, some versions of which will take an empty file
to mean wildcard. All violations would thus be ignored.
</warn>
<!-- FIXME: Might want to add more details on logcheck here...I have to install
it on Gentoo to figure out how it's configured! -->
</body>
</section>

</chapter>

<chapter>
<title>Mounting partitions</title>
<section>
<body>

<p>
When mounting an <c>ext2</c>, <c>ext3</c>, or <c>reiserfs</c> partition, you
have several options you can apply to the file <path>/etc/fstab</path>. The
options are:
</p>

<ul>
<li>
  <c>nosuid</c> - Will ignore the SUID bit and make it just like an ordinary 
  file
</li>
<li>
  <c>noexec</c> - Will prevent execution of files from this partition
</li>
<li>
  <c>nodev</c> - Ignores devices
</li>
</ul>

<p>
Unfortunately, these settings can easily be circumvented by executing a
non-direct path. However, setting <path>/tmp</path> to noexec will stop the
majority of exploits designed to be executed directly from <path>/tmp</path>.
</p>

<pre caption="/etc/fstab">
/dev/sda1 /boot ext2 noauto,noatime 1 1
/dev/sda2 none swap sw 0 0
/dev/sda3 / reiserfs notail,noatime 0 0
/dev/sda4 /tmp reiserfs notail,noatime,nodev,nosuid,noexec 0 0
/dev/sda5 /var reiserfs notail,noatime,nodev 0 0
/dev/sda6 /home reiserfs notail,noatime,nodev,nosuid 0 0
/dev/sda7 /usr reiserfs notail,noatime,nodev,ro 0 0
/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
proc /proc proc defaults 0 0
</pre>

<warn>
Placing <path>/tmp</path> in <c>noexec</c> mode can prevent certain scripts
from executing properly.
</warn>

<note>
For disk quotas see <uri link="#doc_chap6_sect3">the Quotas section</uri>.
</note>

<note>
I do not set <path>/var</path> to <c>noexec</c> or <c>nosuid</c>, even if files
normally are never executed from this mount point. The reason for this is that
qmail is installed in <path>/var/qmail</path> and must be allowed to execute 
and access one SUID file. I setup <path>/usr</path> in read-only mode since I 
never write anything there unless I want to update Gentoo. Then I remount the 
file system in read-write mode, update and remount again.
</note>

<note>
Even if you do not use qmail, Gentoo still needs the executable bit set on 
<path>/var/tmp</path> since ebuilds are made here. But an alternative path can
be setup if you insist on having <path>/var</path> mounted in <c>noexec</c>
mode.
</note>

</body>
</section>
</chapter>

<chapter>
<title>User/group limitations</title>
<section id="limits_conf">
<title>/etc/security/limits.conf</title>
<body>

<p>
Controlling resource usage can be very effective when trying to prevent a local
Denial of Service or restricting the maximum allowed logins for a group or user.
</p>

<pre caption="/etc/security/limits.conf">
*    soft core 0
*    hard core 0
*    hard nproc 15
*    hard rss 10000
*    -    maxlogins 2
@dev hard core 100000
@dev soft nproc 20
@dev hard nproc 35
@dev -    maxlogins 10
</pre>

<p>
If you find yourself trying to set <c>nproc</c> or <c>maxlogins</c> to 0, maybe
you should delete the user instead. The example above sets the group <c>dev</c>
settings for processes, core file and <c>maxlogins</c>. The rest is set to a
default value.
</p>

<note>
<path>/etc/security/limits.conf</path> is part of the PAM package and will 
only apply to packages that use PAM.
</note>

</body>
</section>
<section>
<title>/etc/limits</title>
<body>

<p>
<path>/etc/limits</path> is very similar to the limit file 
<path>/etc/security/limits.conf</path>. The only difference is the format and
that it only works on users or wild cards (not groups). Let's have a look at a
sample configuration:
</p>

<pre caption="/etc/limits">
*   L2 C0 U15 R10000
kn L10 C100000 U35
</pre>

<p>
Here we set the default settings and a specific setting for the user kn.  Limits
are part of the sys-apps/shadow package. It is not necessary to set any limits
in this file if you have disabled <c>pam</c> in
<path>make.conf</path> or not configured PAM properly.
</p>

</body>
</section>
<section>
<title>Quotas</title>
<body>

<warn>
Make sure the file systems you are working with support quotas. In order to use
quotas on ReiserFS, you must patch your kernel with patches available from <uri link="ftp://ftp.namesys.com/pub/reiserfs-for-2.4/testing/quota-2.4.20">Namesys</uri>. User
tools are available from <uri link="http://www.sf.net/projects/linuxquota/">the Linux DiskQuota
project</uri>. While quotas do work with ReiserFS, you may encounter other
issues while trying to use them--you have been warned!
</warn>

<p>
Putting quotas on a file system restricts disk usage on a per-user or per-group
basis.  Quotas are enabled in the kernel and added to a mount point
in <path>/etc/fstab</path>. The kernel option is enabled in the kernel
configuration under <c>File systems-&gt;Quota support</c>. Apply the following
settings, rebuild the kernel and reboot using the new kernel.
</p>

<p>
Start by installing quotas with <c>emerge quota</c>. Then modify your
<path>/etc/fstab</path> and add <c>usrquota</c> and <c>grpquota</c> to the 
partitions that you want to restrict disk usage on, like in the example below.
</p>

<pre caption="/etc/fstab">
/dev/sda1 /boot ext2 noauto,noatime 1 1
/dev/sda2 none swap sw 0 0
/dev/sda3 / reiserfs notail,noatime 0 0
/dev/sda4 /tmp ext3 noatime,nodev,nosuid,noexec,usrquota,grpquota 0 0
/dev/sda5 /var ext3 noatime,nodev,usrquota,grpquota 0 0
/dev/sda6 /home ext3 noatime,nodev,nosuid,usrquota,grpquota 0 0
/dev/sda7 /usr reiserfs notail,noatime,nodev,ro 0 0
/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
proc /proc proc defaults 0 0
</pre>

<p>
On every partition that you have enabled quotas, create the quota files
(<path>aquota.user</path> and <path>aquota.group</path>) and place them in the
root of the partition.
</p>

<pre caption="Creating the quota files">
# <i>touch /tmp/aquota.user</i>
# <i>touch /tmp/aquota.group</i>
# <i>chmod 600 /tmp/aquota.user</i>
# <i>chmod 600 /tmp/aquota.group</i>
</pre>

<p>
This step has to be done on every partition where quotas are enabled. After
adding and configuring the quota files, we need to add the <c>quota</c> script
to the boot run level.
</p>

<pre caption="Adding quota to the boot runlevel">
# <i>rc-update add quota boot</i>
</pre>

<p>
We will now configure the system to check the quotas once a week by adding the
following line to <path>/etc/crontab</path>:
</p>

<pre caption="Adding quota check to crontab">
0 3 * * 0 /usr/sbin/quotacheck -avug.
</pre>

<p>
After rebooting the machine, it is time to setup the quotas for users and
groups. <c>edquota -u kn</c> will start the editor defined in $EDITOR (default
is nano) and let you edit the quotas of the user kn. <c>edquota -g</c> will do
the same thing for groups.
</p>

<pre caption="Setting up quota's for user kn">
Quotas for user kn: 
/dev/sda4: blocks in use: 2594, limits (soft = 5000, hard = 6500) 
         inodes in use: 356, limits (soft = 1000, hard = 1500)
</pre>

<p>
For more detail read <c>man edquota</c> or the <uri link="http://www.tldp.org/HOWTO/mini/Quota.html">Quota mini howto</uri>.
</p>

</body>
</section>
<section>
<title>/etc/login.defs</title>
<body>
            
<p>
If your security policy states that users should change their password
every other week, change the value <c>PASS_MAX_DAYS</c> to 14
and <c>PASS_WARN_AGE</c> to 7. It is recommended that you use password
aging since brute force methods can find any password, given enough
time. We also encourage you to set <c>LOG_OK_LOGINS</c> to yes.
</p>

</body>
</section>
<section>
<title>/etc/login.access</title>
<body>

<p>
The <path>login.access</path> file is also part of the sys-apps/shadow package,
which provides a login access control table. This table is used to control who
can and cannot login based on user name, group name or host name. By default,
all users on the system are allowed to login, so the file consists only of
comments and examples. Whether you are securing your server or workstation, we
recommend that you setup this file so no one other than yourself (the admin) has
access to the console.
</p>

<note>
These settings do not apply for root.
</note>

<pre caption="/etc/login.access">
-:ALL EXCEPT wheel sync:console
-:wheel:ALL EXCEPT LOCAL .gentoo.org
</pre>

<impo>
Be careful when configuring these options, since mistakes will leave you 
with no access to the machine if you do not have root access.
</impo>

<note>
These settings do not apply to SSH, since SSH does not execute 
<c>/bin/login</c> per default. This can be enabled by setting <c>UseLogin 
yes</c> in <path>/etc/ssh/sshd_config</path>. 
</note>

<p>
This will setup login access so members of the wheel group can login locally 
or from the gentoo.org domain. Maybe too paranoid, but better to be safe than 
sorry.
</p>

</body>
</section>
</chapter>

<chapter>
<title>File permissions</title>
<section>
<title>World readable</title>
<body>

<p>
Normal users should not have access to configuration files or passwords. An
attacker can steal passwords from databases or web sites and use them to
deface--or even worse, delete--data. This is why it is important that your file
permissions are correct. If you are sure that a file is only used by root,
assign it with the permissions <c>0600</c> and assign the file to the correct
user with <c>chown</c>.
</p>

</body>
</section>
<section>
<title>World/Group writable</title>
<body>

<pre caption="Finding world-writable files and directories">
# <i>/usr/bin/find / -type f \( -perm -2 -o -perm -20 \) \ 
   -exec ls -lg {} \; 2&gt;/dev/null &gt;writable.txt</i>
# <i>/usr/bin/find / -type d \( -perm -2 -o -perm -20 \) \ 
   -exec ls -ldg {} \; 2&gt;/dev/null &gt;&gt;writable.txt</i>
</pre>

<p>
This will create a huge file with permission of all files having either write
permission set to the group or everybody. Check the permissions and eliminate
world writable files to everyone, by executing <c>/bin/chmod o-w</c> on the
files.
</p>

</body>
</section>
<section>
<title>SUID/SGID files</title>
<body>

<p>
Files with the SUID or SGID bit set execute with privileges of the <e>owning</e>
user or group and not the user executing the file. Normally these bits are used
on files that must run as root in order to do what they do. These files can lead
to local root compromises (if they contain security holes). This is dangerous
and files with the SUID or SGID bits set should be avoided at any cost. If you
do not use these files, use <c>chmod 0</c> on them or unmerge the package that
they came from (check which package they belong to by using <c>equery</c>; if
you do not already have it installed simply type <c>emerge
gentoolkit</c>). Otherwise just turn the SUID bit off with <c>chmod -s</c>.
</p>

<pre caption="Finding setuid files">
# <i>/usr/bin/find / -type f \( -perm -004000 -o -perm -002000 \) \ 
   -exec ls -lg {} \; 2&gt;/dev/null &gt;suidfiles.txt</i>
</pre>

<p>
This will create a file containing a list of all the SUID/SGID files.
</p>

<pre caption="List of setuid binaries">
/bin/su
/bin/ping
/bin/mount
/bin/umount
/var/qmail/bin/qmail-queue
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/crontab
/usr/bin/chage
/usr/bin/expiry
/usr/bin/sperl5.6.1
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/procmail
/usr/bin/suidperl
/usr/lib/misc/pt_chown
/usr/sbin/unix_chkpwd
/usr/sbin/traceroute
/usr/sbin/pwdb_chkpwd
</pre>

<p>
By default Gentoo Linux does not have a lot of SUID files (though this depends
on what you installed), but you might get a list like the one above. Most of the
commands should not be used by normal users, only root. Switch off the SUID bit
on <c>ping</c>, <c>mount</c>, <c>umount</c>, <c>chfn</c>, <c>chsh</c>, <c>newgrp</c>, <c>suidperl</c>, <c>pt_chown</c>
and <c>traceroute</c> by executing <c>chmod -s</c> on every file. Don't
remove the bit on <c>su</c>, <c>qmail-queue</c> or <c>unix_chkpwd</c>. Removing
setuid from those files will prevent you from <c>su</c>'ing and receiving
mail. By removing the bit (where it is safe to do so) you remove the possibility
of a normal user (or an attacker) gaining root access through any of these
files.
</p>

<p>
The only SUID files that I have on my system are <c>su</c>, <c>passwd</c>,
<c>gpasswd</c>, <c>qmail-queue</c>, <c>unix_chkpwd</c> and <c>pwdb_chkpwd</c>.
But if you are running X, you might have some more, since X needs the elevated
access afforded by SUID.
</p>
</body>
</section>
<section>
<title>SUID/SGID binaries and Hard links</title>
<body>

<p>
A file is only considered deleted when there are no more links pointing to it. 
This might sound like a strange concept, but consider that a filename like 
<path>/usr/bin/perl</path> is actually a link to the inode where the data is 
stored. Any number of links can point to the file, and until all of them are
gone, the file still exists.
</p>

<p>
If your users have access to a partition that isn't mounted with <c>nosuid</c>
or <c>noexec</c> (for example, if <path>/tmp</path>, <path>/home</path>, or 
<path>/var/tmp</path> are not separate partitions) you should take care to 
ensure your users don't create hard links to SUID or SGID binaries, so that 
after Portage updates they still have access to the old versions.
</p>

<warn>
if you have received a warning from portage about remaining hard links, and your 
users can write to a partition that allows executing SUID/SGID files, you 
should read this section carefully. One of your users may be attempting to 
circumvent your update by keeping an outdated version of a program. If your 
users cannot create their own SUID files, or can only execute programs using
the dynamic loader (partitions mounted <c>noexec</c>), you do not have to 
worry.
</warn>

<note>
Users do not need read access to a file to create a link to it, they only need 
read permission to the directory that contains it.
</note>

<p>
To check how many links a file has, you can use the <c>stat</c> command.
</p>

<pre caption="Stat command">
$ stat /bin/su    
  File: `/bin/su'
  Size: 29350           Blocks: 64         IO Block: 131072 regular file
Device: 900h/2304d      Inode: 2057419     Links: 1
Access: (4711/-rws--x--x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2005-02-07 01:59:35.000000000 +0000
Modify: 2004-11-04 01:46:17.000000000 +0000
Change: 2004-11-04 01:46:17.000000000 +0000
</pre>

<p>
To find the SUID and SGID files with multiple links, you can use <c>find</c>.
</p>

<pre caption="Finding multiply linked suid/sgid binaries">
$ find / -type f \( -perm -004000 -o -perm -002000 \) -links +1 -ls
</pre>

</body>
</section>
</chapter>

<chapter>
<title>PAM (Pluggable Authentication Modules)</title>
<section>
<body>

<p>
PAM is a suite of shared libraries that provide an alternative way providing
user authentication in programs. The <c>pam</c> USE flag is turned on by
default. Thus the PAM settings on Gentoo Linux are pretty reasonable, but there
is always room for improvement. First install cracklib.
</p>

<pre caption="Installing cracklib">
# <i>emerge cracklib</i>
</pre>

<pre caption="/etc/pam.d/passwd">
auth     required pam_unix.so shadow nullok
account  required pam_unix.so
password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=2 ocredit=2 
password required pam_unix.so md5 use_authtok
session  required pam_unix.so
</pre>

<p>
This will add the cracklib which will ensure that the user passwords are at
least 8 characters and contain a minimum of 2 digits, 2 other characters, and
are more than 3 characters different from the last password. This forces the
user to choose a good password (password policy). Check the <uri link="http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-6.html#ss6.3">PAM</uri>
documentation for more options.
</p>

<pre caption="/etc/pam.d/sshd">
auth     required pam_unix.so nullok 
auth     required pam_shells.so
auth     required pam_nologin.so
auth     required pam_env.so
account  required pam_unix.so
password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=2 ocredit=2 use_authtok
password required pam_unix.so shadow md5
session  required pam_unix.so
session  required pam_limits.so
</pre>

<p>
Every service not configured with a PAM file in <path>/etc/pam.d</path> will use
the rules in <path>/etc/pam.d/other</path>. The defaults are set to <c>deny</c>,
as they should be. But I like to have a lot of logs, which is why I
added <c>pam_warn.so</c>. The last configuration is <c>pam_limits</c>, which is
controlled by <path>/etc/security/limits.conf</path>. See <uri link="#limits_conf">/etc/security/limits.conf section</uri> for more on these
settings.
</p>

<pre caption="/etc/pam.d/other">
auth     required pam_deny.so 
auth     required pam_warn.so 
account  required pam_deny.so 
account  required pam_warn.so 
password required pam_deny.so 
password required pam_warn.so 
session  required pam_deny.so 
session  required pam_warn.so
</pre>

</body>
</section>
</chapter>

<chapter>
<title>TCP Wrappers</title>
<section>
<body>

<p>
This is a way of controlling access to services normally run by inetd (which
Gentoo does not have), but it can also be used by xinetd and other services.
</p>

<note>
The service should be executing tcpd in its server argument (in xinetd). See the
chapter on xinetd for more information.
</note>

<pre caption="/etc/hosts.deny">
ALL:PARANOID
</pre>

<pre caption="/etc/hosts.allow">
ALL: LOCAL @wheel
time: LOCAL, .gentoo.org
</pre>

<p>
As you can see the format is very similar to the one
in <path>/etc/login.access</path>. Tcpd supports a specific service; it does not
overlap with <path>/etc/login.access</path>. These settings only apply to
services using tcp wrappers.
</p>

<p>
It is also possible to execute commands when a service is accessed (this can be
used when activating relaying for dial-in users) but it is not recommended,
since people tend to create more problems than they are trying to solve. An
example could be that you configure a script to send an e-mail every time
someone hits the deny rule, but then an attacker could launch a DoS attack by
keep hitting the deny rule. This will create a lot of I/O and e-mails so
don't do it!. Read the <c>man 5 hosts_access</c> for more information.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Kernel security</title>
<section>
<title>Removing functionality</title>
<body>

<p>
The basic rule when configuring the kernel is to remove everything that you do
not need. This will not only create a small kernel but also remove the
vulnerabilities that may lie inside drivers and other features.
</p>

<p>
Also consider turning off loadable module support. Even though it is possible to
add root kits without this features, it does make it harder for normal attackers
to install root kits via kernel modules.
</p>

</body>
</section>
<section>
<title>The proc filesystem</title>
<body>

<p>
Many kernel parameters can be altered through the <path>/proc</path> file system
or by using <c>sysctl</c>.
</p>

<p>
To dynamically change kernel parameters and variables on the fly, you need
<c>CONFIG_SYSCTL</c> defined in your kernel. This is on by default in
a standard 2.4 kernel. 
</p>

<pre caption="Deactivate IP forwarding">
# <i>/bin/echo "0" &gt; /proc/sys/net/ipv4/ip_forward</i>
</pre>

<p>
Make sure that IP forwarding is turned off. We only want this for a
multi-homed host. It's advised to set or unset this flag before all other flags
since it enabled/disables other flags as well.
</p>

<pre caption="Drop ping packets">
# <i>/bin/echo "1" &gt; /proc/sys/net/ipv4/icmp_echo_ignore_all</i>
</pre>

<p>
This will cause the kernel to simply ignore all ping messages (also known as
ICMP type 0 messages). The reason for this is that an IP packet carrying an ICMP
message can contain a payload with information other than you think.
Administrators use ping as a diagnostic tool and often complain if it is
disabled, but there is no reason for an outsider to be able to ping. However,
since it sometimes can be handy for insiders to be able to ping, you can disable
ICMP type 0 messages in the firewall (allowing local administrators to continue
to use this tool).
</p>

<pre caption="Ignore broadcast pings">
# <i>/bin/echo "1" &gt; /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts</i>
</pre>

<p>
This disables response to ICMP broadcasts and will prevent Smurf attacks. The
Smurf attack works by sending an ICMP type 0 (ping) message to the broadcast
address of a network. Typically the attacker will use a spoofed source
address. All the computers on the network will respond to the ping message and
thereby flood the host at the spoofed source address.
</p>

<pre caption="Disable source routed packets">
# <i>/bin/echo "0" &gt; /proc/sys/net/ipv4/conf/all/accept_source_route</i>
</pre>

<p>
Do not accept source routed packets. Attackers can use source routing to
generate traffic pretending to originate from inside your network, but that is
actually routed back along the path from which it came, so attackers can
compromise your network. Source routing is rarely used for legitimate purposes,
so it is safe to disable it.
</p>

<pre caption="Disable redirect acceptance">
# <i>/bin/echo "0" &gt; /proc/sys/net/ipv4/conf/all/accept_redirects</i>
# <i>/bin/echo "0" &gt; /proc/sys/net/ipv4/conf/all/secure_redirects</i>
</pre>

<p>
Do not accept ICMP redirect packets. ICMP redirects can be used to alter your
routing tables, possibly to a malicious end.
</p>

<pre caption="Protect against bad error messages">
# <i>/bin/echo "1" &gt; /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses</i>
</pre>

<p>
Enable protection against bogus error message responses.
</p>

<pre caption="Enable reverse path filtering">
# <i>for i in /proc/sys/net/ipv4/conf/*; do
        /bin/echo "1" &gt; $i/rp_filter
done</i>
</pre>

<p>
Turn on reverse path filtering. This helps make sure that packets use legitimate
source addresses by automatically rejecting incoming packets if the routing
table entry for their source address does not match the network interface they
are arriving on. This has security advantages because it prevents IP spoofing.
We need to enable it for each <path>net/ipv4/conf/*</path> otherwise source
validation isn't fully functional.
</p>

<warn>
However turning on reverse path filtering can be a problem if you use asymmetric
routing (packets from you to a host take a different path than packets from that
host to you) or if you operate a non-routing host which has several IP addresses
on different interfaces.
</warn>

<pre caption="Log all spoofed, source routed and redirect packets">
# <i>/bin/echo "1" &gt; /proc/sys/net/ipv4/conf/all/log_martians</i>
</pre>

<p>
Log spoofed packets, source routed packets and redirect packets.
</p>

<p>
All these settings will be reset when the machine is rebooted. I suggest that
you add them to <path>/etc/sysctl.conf</path>, which is automatically sourced by
the <path>/etc/init.d/bootmisc</path> init script.
</p>

<p>
The syntax for <path>/etc/sysctl.conf</path> is pretty straightforward. Strip
off the <path>/proc/sys/</path> from the previously mentioned paths and
substitute <path>/</path> with <path>.</path>:
</p>

<pre caption="Translating to sysctl.conf">
<comment>(Manual using echo):</comment>
/bin/echo "0" &gt; /proc/sys/net/ipv4/ip_forward

<comment>(Automatic in sysctl.conf:)</comment>
net.ipv4.ip_forward = 0
</pre>

</body>
</section>
<section>
<title>Grsecurity</title>
<body>

<p>
The patch from <uri link="http://grsecurity.net">Grsecurity</uri> is standard in
the Gentoo kernel sources but is disabled by default. Configure your kernel as
you normally do and then configure the Grsecurity options. An in-depth
explanation on the available Grsecurity options (version 1.9) is available on
the <uri link="/proj/en/hardened">Gentoo Hardened</uri> project page.
</p>

<p>
Recent <c>grsec-sources</c> provide the 2.* version of Grsecurity. For more
information on this improved Grsecurity patch set, please consult the
documentation available on the <uri link="http://www.grsecurity.net/">Grsecurity
home page</uri>.
</p>

</body>
</section>
<section>
<title>Kerneli</title>
<body>

<p>
<uri link="http://www.Kerneli.org">Kerneli</uri> is a patch that adds encryption
to the existing kernel. By patching your kernel you will get new options such as
cryptographic ciphers, digest algorithms and cryptographic loop filters.
</p>

<warn>
The kerneli patch is currently not in a stable version for the latest kernel, so
be careful when using it.
</warn>

</body>
</section>
<section>
<title>Other kernel patches</title>
<body>

<ul>
<li><uri link="http://www.openwall.com">The OpenWall Project</uri></li>
<li><uri link="http://www.lids.org">Linux Intrusion Detection System</uri></li>
<li><uri link="http://www.rsbac.org">Rule Set Based Access Control</uri></li>
<li>
  <uri link="http://www.nsa.gov/selinux">NSA's security enhanced kernel</uri>
</li>
<li><uri link="http://sourceforge.net/projects/wolk/">Wolk</uri></li>
</ul>

<p>
And there are probably a lot more. 
</p>

</body>
</section>
</chapter>

<chapter>
<title>Securing Services</title>
<section>
<title>Apache</title>
<body>

<p>
Apache (1.3.26) comes with a pretty decent configuration file but again, we need
to improve some things, like binding Apache to one address and preventing it
from leaking information. Below are the options that you should apply the
configuration file.
</p>

<p>
If you did not disable <c>ssl</c> in your <path>/etc/make.conf</path> before
installing Apache, you should have access to an ssl enabled server. Just add the
following line to enable it.
</p>

<pre caption="/etc/conf.d/apache">
HTTPD_OPTS="-D SSL"
</pre>

<pre caption="/etc/apache/conf/apache.conf">
#Make it listen on your ip
Listen 127.0.0.1
BindAddress 127.0.0.1
#It is not a good idea to use nobody or nogroup - 
#for every service not running as root 
#(just add the user apache with group apache)
User apache
Group apache
#Will keep apache from telling about the version
ServerSignature Off
ServerTokens Prod
</pre>

<p>
Apache is compiled with <c>--enable-shared=max</c> and 
<c>--enable-module=all</c>. This will by default enable all modules, so you
should comment out all modules in the <c>LoadModule</c> section
(<c>LoadModule</c> and <c>AddModule</c>) that you do not use. Restart the
service by executing <c>/etc/init.d/apache restart</c>.
</p>

<p>
Documentation is available at <uri>http://www.apache.org</uri>.
</p>

</body>
</section>

<section>
<title>Bind</title>
<body>

<p>
One can find documentation at the <uri link="http://www.isc.org/products/BIND/bind9.html">Internet Software
Consortium</uri>. The BIND 9 Administrator Reference Manual is also in
the <path>doc/arm</path>.
</p>

<p>
The newer BIND ebuilds support chrooting out of the box. After emerging 
<c>bind</c> follow these simple instructions:
</p>

<pre caption="Chrooting BIND">
ebuild /var/db/pkg/net-dns/bind-9.2.2-r2/bind-9.2.2-r2.ebuild config\`"
<comment>(Before running the above command you might want to change the chroot 
directory in /etc/conf.d/named. Otherwise /chroot/dns will be used.)</comment>
<comment>(You might need to substitute the version number with the current version number )</comment>
</pre>
</body>
</section>
<section>
<title>Djbdns</title>
<body>

<p>
Djbdns is a DNS implementation on the security of which its author is willing to
bet <uri link="http://cr.yp.to/djbdns/guarantee.html">money</uri>. It is very
different from how Bind 9 works but worth a try.  More information can be
obtained from <uri>http://www.djbdns.org</uri>.
</p>

</body>
</section>

<section>
<title>FTP</title>
<body>

<p>
Generally, using FTP (File Transfer Protocol) is a bad idea. It uses unencrypted
data (ie. passwords are sent in clear text), listens on 2 ports (normally port
20 and 21), and attackers are frequently looking for anonymous logins for
trading warez. Since the FTP protocol contains several security problems you
should instead use <c>sftp</c> or HTTP. If this is not possible, secure your
services as well as you can and prepare yourself.
</p>

</body>
</section>
<section>
<title>Mysql</title>
<body>

<p>
If you only need local applications to access the <c>mysql</c> database, 
uncomment the following line in <path>/etc/mysql/my.cnf</path>.
</p>

<pre caption="Disable network access">
skip-networking
</pre>

<p>
Then we disable the use of the LOAD DATA LOCAL INFILE command. This is to
prevent against unauthorized reading from local files. This is relevant when new
SQL Injection vulnerabilities in PHP applications are found.
</p>

<pre caption="Disable LOAD DATA LOCAL INFILE in the [mysqld] section">
set-variable=local-infile=0
</pre>

<p>
Next, we must remove the sample database (test) and all accounts except the
local <c>root</c> account.
</p>

<pre caption="Removing sample database and all unnecessary users">
mysql&gt; <i>drop database test;</i>
mysql&gt; <i>use mysql;</i>
mysql&gt; <i>delete from db;</i>
mysql&gt; <i>delete from user where not (host="localhost" and user="root");</i>
mysql&gt; <i>flush privileges;</i>
</pre>

<warn>
Be careful with the above if you have already configured user accounts.
</warn>

<note>
If you have been changing passwords from the MySQL prompt, you should always
clean out <path>~/.mysql_history</path> and
<path>/var/log/mysql/mysql.log</path> as they store the executed SQL commands
with passwords in clear text.
</note>

</body>
</section>
<section>
<title>Proftpd</title>
<body>

<p>
Proftpd has had several security problems, but most of them seem to have been
fixed. Nonetheless, it is a good idea to apply some enhancements:
</p>

<pre caption="/etc/proftpd/proftpd.conf">
ServerName "My ftp daemon"
#Don't show the ident of the server
ServerIdent on "Go away"

#Makes it easier to create virtual users
RequireValidShell off

#Use alternative password and group file (passwd uses crypt format)
AuthUserFile "/etc/proftpd/passwd"
AuthGroupFile "/etc/proftpd/group"

# Permissions
Umask 077

# Timeouts and limitations
MaxInstances 30
MaxClients 10 "Only 10 connections allowed"
MaxClientsPerHost 1 "You have already logged on once"
MaxClientsPerUser 1 "You have already logged on once"
TimeoutStalled 10
TimeoutNoTransfer 20
TimeoutLogin 20

#Chroot everyone
DefaultRoot ~

#don't run as root
User  nobody
Group nogroup

#Log every transfer
TransferLog /var/log/transferlog

#Problems with globbing
DenyFilter \*.*/
</pre>

<p>
One can find documentation at <uri>http://www.proftpd.org</uri>.
</p>

</body>
</section>
<section>
<title>Pure-ftpd</title>
<body>

<p>
Pure-ftpd is an branch of the original trollftpd, modified for security reasons
and functionality by Frank Dennis.
</p>

<p>
Use virtual users (never system accounts) by enabling the <c>AUTH</c> option.
Set this to <c>-lpuredb:/etc/pureftpd.pdb</c> and create your users by using
<c>/usr/bin/pure-pw</c>. 
</p>

<pre caption="/etc/conf.d/pure-ftpd">
AUTH="-lpuredb:/etc/pureftpd.pdb"

## Misc. Others ##
MISC_OTHER="-A -E -X -U 177:077 -d -4 -L100:5 -I 15"
</pre>

<p>
Configure your <c>MISC_OTHER</c> setting to deny anonymous logins (<c>-E</c>),
chroot everyone (<c>-A</c>), prevent users from reading or writing to files
beginning with a . (dot) (<c>-X</c>), max idle time (<c>-I</c>), limit recursion
(<c>-L</c>), and a reasonable <c>umask</c>.
</p>

<warn>
Do <e>not</e> use the <c>-w</c> or <c>-W</c> options! If you want to have a
warez site, stop reading this guide!
</warn>

<p>
One can find documentation at <uri>http://www.pureftpd.org</uri>.
</p>

</body>
</section>
<section>
<title>Vsftpd</title>
<body>

<p>
Vsftpd (short for very secure ftp) is a small ftp daemon running a reasonably
default configuration. It is simple and does not have as many features as 
pureftp and proftp.
</p>

<pre caption="/etc/vsftpd">
anonymous_enable=NO
local_enable=YES

#read only
write_enable=NO

#enable logging of transfers
xferlog_std_format=YES

idle_session_timeout=20
data_connection_timeout=20
nopriv_user=nobody

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chrootlist

ls_recurse_enable=NO
</pre>

<p>
As you can see, there is no way for this service to have individual permissions,
but when it comes to anonymous settings it is
quite good. Sometimes it can be nice to have an anonymous ftp server (for
sharing open source), and vsftpd does a really good job at this.
</p>

</body>
</section>
<section>
<title>Qmail</title>
<body>

<p>
Qmail is often considered to be a very secure mail server. It is written with
security (and paranoia) in mind. It does not allow relaying by default and has
not had a security hole since 1996. Simply <c>emerge qmail</c> and go configure!
</p>
</body>
</section>
<section>
<title>Samba</title>
<body>

<p>
Samba is a protocol to share files with Microsoft/Novell networks and it
should <e>not</e> be used over the Internet. Nonetheless, it still needs
securing.
</p>

<pre caption="/etc/samba/smb.conf">
[global]
  #Bind to an interface
  interfaces = eth0 10.0.0.1/32

  #Make sure to use encrypted password
  encrypt passwords = yes
  directory security mask = 0700

  #allow traffic from 10.0.0.*
  hosts allow = 10.0.0.

  #Enables user authentication 
  #(don't use the share mode)
  security = user

  #Disallow privileged accounts
  invalid users = root @wheel

  #Maximum size smb shows for a share (not a limit)
  max disk size = 102400

  #Uphold the password policy
  min password length = 8
  null passwords = no

  #Use PAM (if added support)
  obey pam restrictions = yes
  pam password change = yes
</pre>

<p>
Make sure that permissions are set correct on every share and remember to read
the <uri link="http://www.samba.org">documentation</uri>.
</p>

<p>
Now restart the server and add the users who should have access to this
service. This is done though the command <path>/usr/bin/smbpasswd</path> with
the parameter <c>-a</c>.
</p>

</body>
</section>
<section>
<title>ssh</title>
<body>

<p>
The only securing that OpenSSH needs is turning on a stronger authentication
based on public key encryption. Too many sites (like
<uri>http://www.sourceforge.net</uri>, <uri>http://www.php.net</uri> and 
<uri>http://www.apache.org</uri>) have suffered unauthorized intrusion
due to password leaks or bad passwords.
</p>

<pre caption="/etc/ssh/sshd_config">
#Only enable version 2
Protocol 2

#Disable root login. Users have to su to root
PermitRootLogin no

#Turn on Public key authentication
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

#Disable .rhost and normal password authentication
RhostsAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no

#Only allow userin the wheel or admin group to login
AllowGroups wheel admin

#In those groups only allow the following users
#The @&lt;domainname&gt; is optional but replaces the 
#older AllowHosts directive
AllowUsers kn@gentoo.org bs@gentoo.org

#Logging 
SyslogFacility AUTH
LogLevel INFO

ListenAddress 127.0.0.1
</pre>

<p>
Also verify that you don't have <c>UsePAM yes</c> in your configuration file as
it overrides the public key authentication mechanism.
</p>

<p>
Now all that your users have to do is create a key (on the machine
they want to login from) with the following command:
</p>

<pre caption="Create a DSA keypair">
# <i>/usr/bin/ssh-keygen -t dsa</i>
</pre>

<p>
And type in a pass phrase.
</p>

<pre caption="Output of ssh-keygen">
Generating public/private dsa key pair.
Enter file in which to save the key (/home/kn/.ssh/id_dsa):<i>[Press enter]</i>
Created directory '/home/kn/.ssh'.
Enter passphrase (empty for no passphrase): <i>[Enter passphrase]</i>
Enter same passphrase again: <i>[Enter passphrase again]</i>
Your identification has been saved in /home/kn/.ssh/id_dsa.
Your public key has been saved in /home/kn/.ssh/id_dsa.pub.
The key fingerprint is:
07:24:a9:12:7f:83:7e:af:b8:1f:89:a3:48:29:e2:a4 kn@knielsen
</pre>

<p>
This will add two files in your <path>~/.ssh/</path> directory called 
<path>id_dsa</path> and <path>id_dsa.pub</path>. The file called 
<path>id_dsa</path> is your private key and should be kept from other people
than yourself. The other file <path>id_dsa.pub</path> is to be distributed to
every server that you have access to. Add the key to the users home directory
in <path>~/.ssh/authorized_keys</path> and the user should be able to login.
</p>

<p>
Now your users should guard this private key well. Put it on a media that they
always carry with them or keep it on their workstation (put this in the <uri link="#security_policies">password</uri> policy).
</p>

<p>
For more information go to the <uri link="http://www.openssh.org">OpenSSH</uri> web site.
</p>

</body>
</section>
<section>
<title>Using xinetd</title>
<body>

<p>
xinetd is a replacement for <c>inetd</c> (which Gentoo does not have), 
the Internet services daemon. It supports access control based on the address of
the remote host and the time of access. It also provide extensive logging 
capabilities, including server start time, remote host address, remote user 
name, server run time, and actions requested.
</p>

<p>
As with all other services it is important to have a good default configuration.
But since <c>xinetd</c> is run as root and supports protocols
that you might not know how they work, we recommend not to use it. But if you
want to use it anyway, here is how you can add some security to it:
</p>

<pre caption="Install xinetd">
# <i>emerge xinetd tcp-wrappers</i>
</pre>

<p>
And edit the configuration file:
</p>

<pre caption="/etc/xinetd.conf">
defaults
{
 only_from = localhost
 instances = 10
 log_type = SYSLOG authpriv info
 log_on_success = HOST PID
 log_on_failure = HOST
 cps = 25 30
}

# This will setup pserver (cvs) via xinetd with the following settings:
# max 10 instances (10 connections at a time)
# limit the pserver to tcp only
# use the user cvs to run this service
# bind the interfaces to only 1 ip
# allow access from 10.0.0.*
# limit the time developers can use cvs from 8am to 5pm
# use tpcd wrappers (access control controlled in 
# <i>/etc/hosts.allow</i> and <i>/etc/hosts.deny</i>)
# max_load on the machine set to 1.0
# The disable flag is per default set to no but I like having 
# it in case of it should be disabled
service cvspserver
{
 socket_type = stream
 protocol = tcp
 instances = 10
 protocol = tcp
 wait = no
 user = cvs
 bind = 10.0.0.2
 only_from = 10.0.0.0
 access_times = 8:00-17:00
 server = /usr/sbin/tcpd
 server_args = /usr/bin/cvs --allow-root=/mnt/cvsdisk/cvsroot pserver
 max_load = 1.0
 log_on_failure += RECORD
 disable = no
}
</pre>

<p>
For more information read <c>man 5 xinetd.conf</c>.
</p>

</body>
</section>

<section>
<title>X</title>
<body>

<p>
By default Xorg is configured to act as an Xserver. This can be dangerous since
X uses unencrypted TCP connections and listens for xclients.
</p>

<impo>
If you do not need this service disable it! 
</impo>

<p>
But if you depend on using your workstation as a Xserver use the 
<c>/usr/X11R6/bin/xhost</c> command with caution. This command allows clients 
from other hosts to connect and use your display. This can become handy if you 
need an X application from a different machine and the only way is through the 
network, but it can also be exploited by an attacker. The syntax of this
command is <c>/usr/X11R6/bin/xhost +hostname</c>
</p>

<warn>
Do not ever use the <c>xhost +</c> feature! This will allow any client to 
connect and take control of your X. If an attacker can get access to your X, 
he can log your keystrokes and take control over your desktop. If you have to 
use it always remember to specify a host.
</warn>

<p>
A more secure solution is to disable this feature completely by starting X with 
<c>startx -- -nolisten tcp</c> or disable it permanently in the configuration. 
</p>

<pre caption="/usr/X11R6/bin/startx">
defaultserverargs="-nolisten tcp"
</pre>

<p>
To make sure that <path>startx</path> does not get overwritten when emerging a
new version of Xorg you must protect it. Add the following line to
<path>/etc/make.conf</path>:
</p>

<pre caption="/etc/make.conf">
CONFIG_PROTECT_MASK="/usr/X11R6/bin/startx"
</pre>

<p>
If you use a graphical login manager you need a different approach.
</p>

<p>
For <c>gdm</c> (Gnome Display Manager)
</p>

<pre caption="/etc/X11/gdm/gdm.conf">
[server-Standard]
command=/usr/X11R6/bin/X -nolisten tcp
</pre>

<p>
For <c>xdm</c> (X Display Manager) and <c>kdm</c> (Kde Display Manager)
</p>

<pre caption="/etc/X11/xdm/Xservers">
:0 local /usr/bin/X11/X -nolisten tcp 
</pre>

</body>
</section>
</chapter>

<chapter>
<title>Chrooting and virtual servers</title>
<section>
<title>Chrooting</title>
<body>

<p>
Chrooting a service is a way of limiting a service (or user) environment to
only accessing what it should and not gaining access (or information) that
could lead to root access. By running the service as another user than
<c>root</c> (<c>nobody</c>, <c>apache</c>, <c>named</c>) an attacker can only
access files with the permissions of this user. This means that an attacker
cannot gain <c>root</c> access even if the services has a security flaw.
</p>

<p>
Some services like <c>pure-ftpd</c> and <c>bind</c> have features for
chrooting, and other services do not. If the service supports it, use it,
otherwise you have to figure out how to create your own. Lets see how to create
a chroot, for a basic understanding of how chroots work, we will test it with
<c>bash</c> (easy way of learning).
</p>

<p>
Create the <path>/chroot</path> directory with <c>mkdir chroot</c>. And find what 
dynamic libraries that <c>bash</c> is compiled with (if it is compiled with 
<c>-static</c> this step is not necessary):
</p>

<p>
The following command will create a list of libraries used by <c>bash</c>. 
</p>

<pre caption="Get listing of used libraries">
# <i>ldd /bin/bash</i>
  libncurses.so.5 =&gt; /lib/libncurses.so.5 (0x4001b000)
  libdl.so.2 =&gt; /lib/libdl.so.2 (0x40060000)
  libc.so.6 =&gt; /lib/libc.so.6 (0x40063000)
  /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x40000000)
</pre>

<p>
Now lets create the environment for <c>bash</c>.
</p>

<pre caption="Create chroot-environment for bash">
# <i>mkdir /chroot/bash</i>
# <i>mkdir /chroot/bash/bin</i>
# <i>mkdir /chroot/bash/lib</i>
</pre>

<p>
Next copy the files used by <c>bash</c> (<path>/lib</path>) to the chrooted
<path>lib</path> and copy the bash command to the chrooted <path>bin</path>
directory. This will create the exact same environment, just with less
functionality. After copying try it out: <c>chroot /chroot/bash /bin/bash</c>. 
If you get an prompt saying <path>/</path> it works! Otherwise it will properly
tell you what a file is missing. Some shared libraries depend on each other.
</p>

<p>
You will notice that inside the chroot nothing works except <c>echo</c>. This 
is because we have no other commands in out chroot environment than bash and 
<c>echo</c> is a build-in functionality.
</p>

<p>
This is basically the same way you would create a chrooted service. The only 
difference is that services sometimes rely on devices and configuration files 
in <path>/etc</path>. Simply copy them (devices can be copied with <c>cp 
-a</c>) to the chrooted environment, edit the init script to use chroot before 
executing. It can be difficult to find what devices and configuration files a 
services need. This is where the <c>strace</c> command becomes handy. Start 
the service with <c>/usr/bin/strace</c> bash and look for open, read, stat and 
maybe connect. This will give you a clue on what files to copy. But in most 
cases just copy the passwd file (edit the copy and remove users that has 
nothing to do with the service), <path>/dev/zero</path>, <path>/dev/log</path> 
and <path>/dev/random</path>.
</p>

</body>
</section>
<section>
<title>User Mode Linux</title>
<body>

<p>
Another way of creating a more secure environment is by running a virtual
machine. A virtual machine, as the name implies, is a process that runs on top
of your real operating system providing a hardware and operating system
environment that appears to be its own unique machine. The security benefit is
that if the server running on the virtual machine is compromised, only the
virtual server is affected and not the parent installation.
</p>

<p>
For more information about how to setup User Mode Linux consult the
<uri link="http://www.gentoo.org/doc/en/uml.xml">User Mode Linux
Guide</uri>.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Firewalls</title>
<section>
<title>A firewall</title>
<body>

<p>
People often think that a firewall provides the ultimate security, but they 
are wrong. In most cases a misconfigured firewall gives less security than 
not having one at all. A firewall is also a piece of software and should be 
treated the same way as any other piece of software, because it is just as likely 
to contain bugs.
</p>

<p>
So think before implementing a firewall! Do you really need one? If you think
you need one write a policy on how it should work, what type of firewall, and
who should operate it. But first read this guide.
</p>

<p>
Firewalls are used for two purposes:
</p>

<ul>
<li>To keep users (worms/attackers) out</li>
<li>To keep users (employees/children) in</li>
</ul>

<p>
Basically there are three types of firewalls:
</p>

<ul>
<li>Packet filtering</li>
<li>Circuit relay</li>
<li>Application gateway</li>
</ul>

<p>
A firewall should be a dedicated machine running no services (or <c>sshd</c> as
the only one) and secured the way this guide recommends it be.
</p>

</body>
</section>
<section>
<title>Packet filtering</title>
<body>

<p>
All network traffic is sent in the form of packets. Large amounts of traffic is
split up into small packets for easy handling and then reassembled when it
arrives at its destination. In the packet header every packet contains
information on how and where it should be delivered. And this information is
exactly what a packing filtering firewall uses. Filtering is based on:
</p>

<ul>
<li>Allow or disallow packets based on source/destination IP address</li>
<li>Allow or disallow packets based on source/destination port</li>
<li>Allow or disallow packets based on protocol</li>
<li>Allow or disallow packets based on flags within a specific protocol</li>
</ul>

<p>
In other words, this filtering is based on all the data within the header of a
packet and not its content.
</p>

<p>
Weaknesses:
</p>

<ul>
<li>
  Address information in a packet can potentially be a bogus IP address (or as we
  say <e>spoofed</e>) by the sender.
</li>
<li>
  Data or requests within the allowed packet may contain unwanted data that the
  attacker can use to exploit known bugs in the services on or behind the firewall
</li>
<li>Usually single point of failure</li>
</ul>

<p>
Advantages:
</p>

<ul>
<li>Simple and easy to implement</li>
<li>
  Can give warnings of a possible attack before it happens (ie. by detecting 
  port scans)
</li>
<li>Good for stopping SYN attacks</li>
</ul>

<p>
Examples of free packet filters on Linux:
</p>

<ul>
<li><uri link="http://www.iptables.org">Iptables</uri></li>
<li>
  <uri link="http://www.linuxdocs.org/HOWTOs/IPCHAINS-HOWTO.html">Ipchains</uri>
</li>
<li><uri link="http://www.smoothwall.org">SmoothWall</uri></li>
</ul>
<!--FIXME: should SmoothWall really be included, since it uses iptables?-->
<note>
It is recommended that you use iptables. Ipchains is obsoleted. 
</note>

</body>
</section>
<section>
<title>Circuit relay</title>
<body>

<p>
A circuit level gateway is a firewall that validates connections before allowing
data to be exchanged. This means that it does not simply allow or deny packets
based on the packet header but determines whether the connection between both
ends is valid according to configurable rules before it opens a session and
allows data to be exchanged. Filtering is based on:
</p>

<ul>
<li>Source/destination IP address</li>
<li>Source/destination port</li>
<li>A period of time</li>
<li>Protocol</li>
<li>User</li>
<li>Password</li>
</ul>

<p>
All traffic is validated and monitored, and unwanted traffic can be dropped.
</p>

<p>
Weakness:
</p>

<ul>
<li>
  Operates at the Transport Layer and may require substantial modification of the
  programs that normally provide transport functions.
</li>
</ul>

</body>
</section>
<section>
<title>Application gateway</title>
<body>

<p>
The application level gateway is a proxy for applications, exchanging data with
remote systems on behalf of the clients. It is kept away from the public safely
behind a DMZ (De-Militarized Zone: the portion of a private network that is
visible through the firewall) or a firewall allowing no connections from the
outside. Filtering is based on:
</p>

<ul>
<li>Allow or disallow based on source/destination IP address</li>
<li>Based on the packet's content</li>
<li>Limiting file access based on file type or extension</li>
</ul>

<p>
Advantages:
</p>

<ul>
<li>Can cache files, increasing network performance</li>
<li>Detailed logging of all connections</li>
<li>Scales well (some proxy servers can "share" the cached data)</li>
<li>No direct access from the outside</li>
<li>Can even alter the packet content on the fly</li>
</ul>

<p>
Weakness:
</p>

<ul>
<li>Configuration is complex</li>
</ul>

<p>
Application gateways are considered to be the most secure solution since they do
not have to run as root and the hosts behind them are not reachable from the
Internet.
</p>

<p>
Example of a free application gateway:
</p>

<ul>
<li><uri link="http://www.squid-cache.org/">Squid</uri></li>
</ul>

</body>
</section>
<section>
<title>Iptables</title>
<body>

<p>
In order to use iptables, it must be enabled in the kernel. I have added
iptables as modules (the <c>iptables</c> command will load them as they are
needed) and recompiled my kernel (but you may want to compile iptables in, if
you intend to disable Loadable Kernel Modules as discussed previously). For more
information on how to configure your kernel for iptables go to the <uri link="http://iptables-tutorial.frozentux.net/chunkyhtml/kernelsetup.html">Iptables
Tutorial Chapter 2: Preparations</uri>. After you have compiled your new kernel 
(or while compiling the kernel), you must add the <c>iptables</c> command.
Just <c>emerge iptables</c> and it should work.
</p>

<p>
Now test that it works by running <c>iptables -L</c>. If this fails something
is wrong and you have to check you configuration once more.
</p>

<p>
Iptables is the new and heavily improved packet filter in the Linux 2.4.x
kernel. It is the successor of the previous ipchains packet filter in the Linux
2.2.x kernel. One of the major improvements is that iptables is able to perform 
stateful packet filtering. With stateful packet filtering it is possible to
keep track of each established TCP connection.
</p>

<p>
A TCP connection consists of a series of packets containing information about
source IP address, destination IP address, source port, destination port, and a
sequence number so the packets can be reassembled without losing data. TCP is a
connection-oriented protocol, in contrast to UDP, which is connectionless.
</p>

<p>
By examining the TCP packet header, a stateful packet filter can determine if a
received TCP packet is part of an already established connection or not and
decide either to accept or drop the packet.
</p>

<p>
With a stateless packet filter it is possible to fool the packet filter into
accepting packets that should be dropped by manipulating the TCP packet headers.
This could be done by manipulating the SYN flag or other flags in the TCP header
to make a malicious packet appear to be a part of an established connection
(since the packet filter itself does not do connection tracking). With stateful
packet filtering it is possible to drop such packets, as they are not part of an
already established connection. This will also stop the possibility of
"stealth scans", a type of port scan in which the scanner sends packets
with flags that are far less likely to be logged by a firewall than ordinary SYN
packets.
</p>

<p>
Iptables provides several other features like NAT (Network Address Translation) 
and rate limiting. Rate limiting is extremely useful when trying to prevent 
certain DoS (Denial of Service) attacks like SYN floods.
</p>

<p>
A TCP connection is established by a so called three-way handshake. When 
establishing a TCP connection the client-side sends a packet to the server 
with the SYN flag set. When the server-side receives the SYN packet it 
responds by sending a SYN+ACK packet back to the client-side. When the SYN+ACK 
is received the client-side responds with a third ACK packet in effect 
acknowledging the connection.
</p>

<p>
A SYN flood attack is performed by sending the SYN packet but failing to 
respond to the SYN+ACK packet. The client-side can forge a packet with a fake 
source IP address because it does not need a reply. The server-side system will
add an entry to a queue of half-open connections when it receives the SYN 
packet and then wait for the final ACK packet before deleting the entry from 
the queue. The queue has a limited number of slots and if all the slots are 
filled it is unable to open any further connections. If the ACK packet is not 
received before a specified timeout period the entry will automatically be 
deleted from the queue. The timeout settings vary but will typically be 30-60 
seconds or even more. The client-side initiates the attack by forging a lot of 
SYN packets with different source IP addresses and sends them to the target IP 
address as fast as possible and thereby filling up the queue of half-open 
connections and thus preventing other clients from establishing a legitimate
connection with the server.
</p>

<p>
This is where the rate limit becomes handy. It is possible to limit the rate 
of accepted SYN packets by using the <c>-m limit --limit 1/s</c>. This will 
limit the number of SYN packets accepted to one per second and therefore 
restricting the SYN flood on our resources.
</p>

<note>
Another option for preventing SYN floods are <uri link="http://cr.yp.to/syncookies.html">SYN cookies</uri>, which allow your computer
to respond to SYN packets without filling space in the connection queue. SYN
cookies can be enabled in the Linux kernel configuration, but they are
considered experimental at this time.
</note>

<p>
Now some practical stuff!
</p>

<p>
When iptables is loaded in the kernel it has 5 hooks where you can place your 
rules. They are called <c>INPUT</c>, <c>OUTPUT</c>, <c>FORWARD</c>, 
<c>PREROUTING</c> and <c>POSTROUTING</c>. Each of these is called a chain and 
consists of a list of rules. Each rule says if the packet header looks like 
this, then here is what to do with the packet. If the rule does not match the 
packet the next rule in the chain is consulted.
</p>

<p>
You can place rules directly in the 5 main chains or create new chains and add 
them to as a rule to an existing chain. Iptables supports the following options.
</p>

<table>
<tr>
  <th>Option:</th>
  <th>Description:</th>
</tr>
<tr>
  <ti>-A</ti>
  <ti>Append</ti>
</tr>
<tr>
  <ti>-D</ti>
  <ti>Delete</ti>
</tr>
<tr>
  <ti>-I</ti>
  <ti>Insert</ti>
</tr>
<tr>
  <ti>-R</ti>
  <ti>Replace</ti>
</tr>
<tr>
  <ti>-L</ti>
  <ti>List</ti>
</tr>
<tr>
  <ti>-F</ti>
  <ti>Delete all rules in chain or all chains</ti>
</tr>
<tr>
  <ti>-Z</ti>
  <ti>Zero counters in chain or all chains</ti>
</tr>
<tr>
  <ti>-C</ti>
  <ti>Test this packet on chain</ti>
</tr>
<tr>
  <ti>-N</ti>
  <ti>Create a new user-defined chain</ti>
</tr>
<tr>
  <ti>-X</ti>
  <ti>Delete a user-defined chain</ti>
</tr>
<tr>
  <ti>-P</ti>
  <ti>Change policy on chain to target</ti>
</tr>
<tr>
  <ti>-E</ti>
  <ti>Change chain name</ti>
</tr>
<tr>
  <ti>-p</ti>
  <ti>Protocol</ti>
</tr>
<tr>
  <ti>-s</ti>
  <ti>Source address/mask</ti>
</tr>
<tr>
  <ti>-d</ti>
  <ti>Destination address/mask</ti>
</tr>
<tr>
  <ti>-i</ti>
  <ti>Input name (Ethernet name)</ti>
</tr>
<tr>
  <ti>-o</ti>
  <ti>Output name (Ethernet name)</ti>
</tr>
<tr>
  <ti>-j</ti>
  <ti>Jump (target for rule)</ti>
</tr>
<tr>
  <ti>-m</ti>
  <ti>Extended match (might use extension)</ti>
</tr>
<tr>
  <ti>-n</ti>
  <ti>Numeric output of addresses and ports</ti>
</tr>
<tr>
  <ti>-t</ti>
  <ti>Table to manipulate</ti>
</tr>
<tr>
  <ti>-v</ti>
  <ti>Verbose mode</ti>
</tr>
<tr>
  <ti>-x</ti>
  <ti>Expand numbers (display exact values)</ti>
</tr>
<tr>
  <ti>-f</ti>
  <ti>Match second or further fragments only</ti>
</tr>
<tr>
  <ti>-V</ti>
  <ti>Packet version</ti>
</tr>
<tr>
  <ti>--line-numbers</ti>
  <ti>Print line numbers when listing</ti>
</tr>
</table>

<p>
First we will try to block all ICMP packets to our machine, just to get familiar
with iptables.
</p>

<pre caption="Block all ICMP packets">
# <i>iptables -A INPUT -p icmp -j DROP</i>
</pre>

<p>
First we specify the chain our rule should be appended to, then the protocol of
the packets to match, and finally the target. The target can be the name of a
user specified chain or one of the special targets <c>ACCEPT</c>, <c>DROP</c>,
 <c>REJECT</c>, <c>LOG</c>, <c>QUEUE</c>, or <c>MASQUERADE</c>. In this case we
 use <c>DROP</c>, which will drop the packet without responding to the client.
</p>

<note>
The <c>LOG</c> target is what's known as "non-terminating". If a packet matches
a rule with the <c>LOG</c> target, rather than halting evaluation, the packet
will continue to be matched to further rules. This allows you to log packets
while still processing them normally.
</note>

<p>
Now try <c>ping localhost</c>. You will not get any response, since iptables
will drop all incoming ICMP messages. You will also not be able to ping other
machines, since the ICMP reply packet will be dropped as well. Now flush the
chain to get ICMP flowing again.
</p>

<pre caption="Flush all rules">
# <i>iptables -F</i>
</pre>

<p>
Now lets look at the stateful packet filtering in iptables. If we wanted to
enable stateful inspection of packets incoming on eth0 we would issue the
command:
</p>

<pre caption="Accept packets that originate from an already established connection">
# <i>iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT</i>
</pre>

<p>
This will accept any packet from an already established connection or related in
the INPUT chain. And you could drop any packet that is not in the state table by
issuing <c>iptables -A INPUT -i eth0 -m state --state INVALID -j DROP</c> just
before the previous command. This enables the stateful packet filtering in
iptables by loading the extension "state". If you wanted to allow others to
connect to your machine, you could use the flag <c>--state NEW</c>. Iptables
contains some modules for different purposes. Some of them are:
</p>

<table>
<tr>
  <th>Module/Match</th>
  <th>Description</th>
  <th>Extended options</th>
</tr>
<tr>
  <ti>mac</ti>
  <ti>Matching extension for incoming packets mac address.</ti>
  <ti>--mac-source</ti>
</tr>
<tr>
  <ti>state</ti>
  <ti>Enables stateful inspection</ti>
  <ti>--state (states are ESTABLISHED,RELATED, INVALID, NEW)</ti>
</tr>
<tr>
  <ti>limit</ti>
  <ti>Rate matching limiting</ti>
  <ti>--limit, --limit-burst</ti>
</tr>
<tr>
  <ti>owner</ti>
  <ti>Attempt to match various characteristics of the packet creator</ti>
  <ti>
    --uid-owner userid --gid-owner groupid --pid-owner processid --sid-owner 
    sessionid
  </ti>
</tr>
<tr>
  <ti>unclean</ti>
  <ti>Various random sanity checks on packets</ti><ti/>
</tr>
</table>

<p>
Lets try to create a user-defined chain and apply it to one of the existing 
chains:
</p>

<pre caption="Creating a user defined chain">
<comment>(Create a new chain with one rule)</comment>
# <i>iptables -X mychain</i>
# <i>iptables -N mychain</i>
# <i>iptables -A mychain -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT</i>
<comment>(The default policy is all outgoing traffic is allowed. Incoming is dropped.)</comment>
# <i>iptables -P OUTPUT ACCEPT</i>
# <i>iptables -P INPUT DROP</i>
<comment>(And add it to the INPUT chain)</comment>
# <i>iptables -A INPUT -j mychain</i>
</pre>

<p>
By applying the rule to the input chain we get the policy: All outgoing packets 
are allowed and all incoming packets are dropped.
</p>

<p>
One can find documentation at <uri link="http://www.iptables.org/documentation/index.html#HOWTO">Netfilter/iptables
documentation</uri>.
</p>

<p>
Lets see a full blown example. In this case my firewall/gateway policy states:
</p>

<ul>
<li>Connections to the firewall are only allowed through SSH (port 22)</li>
<li>
  The local network should have access to HTTP, HTTPS and SSH (DNS should also 
  be allowed)
</li>
<li>
  ICMP traffic can contain payload and should not be allowed. Of course we have 
  to allow some ICMP traffic.
</li>
<li>Port scans should be detected and logged</li>
<li>SYN attacks should be avoided</li>
<li>All other traffic should be dropped and logged</li>
</ul>

<pre caption="/etc/init.d/firewall">
#!/sbin/runscript
IPTABLES=/sbin/iptables
IPTABLESSAVE=/sbin/iptables-save
IPTABLESRESTORE=/sbin/iptables-restore
FIREWALL=/etc/firewall.rules
DNS1=212.242.40.3
DNS2=212.242.40.51
#inside
IIP=10.0.0.2
IINTERFACE=eth0
LOCAL_NETWORK=10.0.0.0/24
#outside
OIP=217.157.156.144
OINTERFACE=eth1

opts="${opts} showstatus panic save restore showoptions rules"

depend() {
  need net
}

rules() {
  stop
  ebegin "Setting internal rules"

  einfo "Setting default rule to drop"
  $IPTABLES -P FORWARD DROP
  $IPTABLES -P INPUT   DROP
  $IPTABLES -P OUTPUT  DROP

  #default rule
  einfo "Creating states chain"
  $IPTABLES -N allowed-connection
  $IPTABLES -F allowed-connection
  $IPTABLES -A allowed-connection -m state --state ESTABLISHED,RELATED -j ACCEPT
  $IPTABLES -A allowed-connection -i $IINTERFACE -m limit -j LOG --log-prefix \ 
      "Bad packet from ${IINTERFACE}:"
  $IPTABLES -A allowed-connection -j DROP

  #ICMP traffic
  einfo "Creating icmp chain"
  $IPTABLES -N icmp_allowed
  $IPTABLES -F icmp_allowed
  $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \ 
      time-exceeded -j ACCEPT
  $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \ 
      destination-unreachable -j ACCEPT
  $IPTABLES -A icmp_allowed -p icmp -j LOG --log-prefix "Bad ICMP traffic:"
  $IPTABLES -A icmp_allowed -p icmp -j DROP

  #Incoming traffic
  einfo "Creating incoming ssh traffic chain"
  $IPTABLES -N allow-ssh-traffic-in
  $IPTABLES -F allow-ssh-traffic-in
  #Flood protection
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ 
      ALL RST --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ 
      ALL FIN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ 
      ALL SYN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT

  #outgoing traffic
  einfo "Creating outgoing ssh traffic chain"
  $IPTABLES -N allow-ssh-traffic-out
  $IPTABLES -F allow-ssh-traffic-out
  $IPTABLES -A allow-ssh-traffic-out -p tcp --dport ssh -j ACCEPT

  einfo "Creating outgoing dns traffic chain"
  $IPTABLES -N allow-dns-traffic-out
  $IPTABLES -F allow-dns-traffic-out
  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS1 --dport domain \ 
      -j ACCEPT
  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS2 --dport domain \ 
     -j ACCEPT

  einfo "Creating outgoing http/https traffic chain"
  $IPTABLES -N allow-www-traffic-out
  $IPTABLES -F allow-www-traffic-out
  $IPTABLES -A allow-www-traffic-out -p tcp --dport www -j ACCEPT
  $IPTABLES -A allow-www-traffic-out -p tcp --dport https -j ACCEPT

  #Catch portscanners
  einfo "Creating portscan detection chain"
  $IPTABLES -N check-flags
  $IPTABLES -F check-flags
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -m limit \ 
      --limit 5/minute -j LOG --log-level alert --log-prefix "NMAP-XMAS:" 
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -m limit --limit \ 
      5/minute -j LOG --log-level 1 --log-prefix "XMAS:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG \ 
      -m limit --limit 5/minute -j LOG --log-level 1 --log-prefix "XMAS-PSH:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -m limit \ 
      --limit 5/minute -j LOG --log-level 1 --log-prefix "NULL_SCAN:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -m limit \ 
      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/RST:"
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit \ 
      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/FIN:"
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

  # Apply and add invalid states to the chains
  einfo "Applying chains to INPUT"
  $IPTABLES -A INPUT -m state --state INVALID -j DROP
  $IPTABLES -A INPUT -j icmp_allowed 
  $IPTABLES -A INPUT -j check-flags
  $IPTABLES -A INPUT -i lo -j ACCEPT
  $IPTABLES -A INPUT -j allow-ssh-traffic-in
  $IPTABLES -A INPUT -j allowed-connection

  einfo "Applying chains to FORWARD"
  $IPTABLES -A FORWARD -m state --state INVALID -j DROP
  $IPTABLES -A FORWARD -j icmp_allowed 
  $IPTABLES -A FORWARD -j check-flags
  $IPTABLES -A FORWARD -o lo -j ACCEPT
  $IPTABLES -A FORWARD -j allow-ssh-traffic-in
  $IPTABLES -A FORWARD -j allow-www-traffic-out
  $IPTABLES -A FORWARD -j allowed-connection

  einfo "Applying chains to OUTPUT"
  $IPTABLES -A OUTPUT -m state --state INVALID -j DROP
  $IPTABLES -A OUTPUT -j icmp_allowed
  $IPTABLES -A OUTPUT -j check-flags
  $IPTABLES -A OUTPUT -o lo -j ACCEPT
  $IPTABLES -A OUTPUT -j allow-ssh-traffic-out
  $IPTABLES -A OUTPUT -j allow-dns-traffic-out
  $IPTABLES -A OUTPUT -j allow-www-traffic-out
  $IPTABLES -A OUTPUT -j allowed-connection

  #Allow client to route through via NAT (Network Address Translation)
  $IPTABLES -t nat -A POSTROUTING -o $IINTERFACE -j MASQUERADE 
  eend $?
}

start() {
  ebegin "Starting firewall"
  if [ -e "${FIREWALL}" ]; then
    restore
  else
    einfo "${FIREWALL} does not exists. Using default rules."
    rules
  fi
  eend $?
}

stop() {
  ebegin "Stopping firewall"
  $IPTABLES -F
  $IPTABLES -t nat -F
  $IPTABLES -X
  $IPTABLES -P FORWARD ACCEPT
  $IPTABLES -P INPUT   ACCEPT
  $IPTABLES -P OUTPUT  ACCEPT
  eend $?
}

showstatus() {
  ebegin "Status"
  $IPTABLES -L -n -v --line-numbers
  einfo "NAT status"
  $IPTABLES -L -n -v --line-numbers -t nat
  eend $?
}

panic() {
  ebegin "Setting panic rules"
  $IPTABLES -F
  $IPTABLES -X
  $IPTABLES -t nat -F
  $IPTABLES -P FORWARD DROP
  $IPTABLES -P INPUT   DROP
  $IPTABLES -P OUTPUT  DROP
  $IPTABLES -A INPUT -i lo -j ACCEPT
  $IPTABLES -A OUTPUT -o lo -j ACCEPT
  eend $?
}

save() {
  ebegin "Saving Firewall rules"
  $IPTABLESSAVE &gt; $FIREWALL
  eend $?
}

restore() {
  ebegin "Restoring Firewall rules"
  $IPTABLESRESTORE &lt; $FIREWALL
  eend $?
}

restart() {
  svc_stop; svc_start
}

showoptions() {
  echo "Usage: $0 {start|save|restore|panic|stop|restart|showstatus}"
  echo "start)      will restore setting if exists else force rules"
  echo "stop)       delete all rules and set all to accept"
  echo "rules)      force settings of new rules"
  echo "save)       will store settings in ${FIREWALL}"
  echo "restore)    will restore settings from ${FIREWALL}"
  echo "showstatus) Shows the status" 
}
</pre>

<p>
Some advice when creating a firewall:
</p>

<ol>
<li>Create your firewall policy before implementing it</li>
<li>Keep it simple</li>
<li>
Know how each protocol works (read the relevant <uri link="http://www.ietf.org/">RFC</uri>(Request For Comments))
</li>
<li>
Keep in mind that a firewall is just another piece of software running as root.
</li>
<li>Test your firewall</li>
</ol>

<p>
If you think that iptables is hard to understand or takes to long to setup a
decent firewall you could use <uri link="http://www.shorewall.net">Shorewall</uri>. It basically uses iptables to
generate firewall rules, but concentrates on rules and not specific protocols.
</p>

</body>
</section>
<section>
<title>Squid</title>
<body>

<p>
Squid is a very powerful proxy server. It can filter traffic based on time,
regular expressions on path/URI, source and destination IP addresses, domain,
browser, authenticated user name, MIME type, and port number (protocol). I
probably forgot some features, but it can be hard to cover the entire list right
here.
</p> 

<p>
In the following example I have added a banner filter instead of a filter based
on porn sites. The reason for this is that Gentoo.org should <e>not</e> be
listed as some porn site. And I do not want to waste my time trying to find some
good sites for you.
</p>

<p>
In this case, my policy states:
</p>

<ul>
<li>
Surfing (HTTP/HTTPS) is allowed during work hours (mon-fri 8-17 and sat 8-13),
but if employees are here late they should work, not surf
</li>
<li>
Downloading files is not allowed (.exe, .com, .arj, .zip, .asf, .avi, .mpg,
.mpeg, etc)
</li>
<li>
We do not like banners, so they are filtered and replaced with a transparent gif
(this is where you get creative!).
</li>
<li>
All other connections to and from the Internet are denied.
</li>
</ul>

<p>
This is implemented in 4 <e>easy</e> steps.
</p>

<pre caption="/etc/squid/squid.conf">
# Bind to a ip and port
http_port 10.0.2.1:3128

# Standard configuration
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY

# Add basic access control lists
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255

# Add who can access this proxy server
acl localnet src 10.0.0.0/255.255.0.0

# And ports
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
acl purge method PURGE

# Add access control list based on regular
# expressions within urls
acl archives urlpath_regex "/etc/squid/files.acl"
acl url_ads url_regex "/etc/squid/banner-ads.acl"

# Add access control list based on time and day
acl restricted_weekdays time MTWHF 8:00-17:00
acl restricted_weekends time A 8:00-13:00

acl CONNECT method CONNECT

#allow manager access from localhost
http_access allow manager localhost
http_access deny manager

# Only allow purge requests from localhost
http_access allow purge localhost
http_access deny purge

# Deny requests to unknown ports
http_access deny !Safe_ports

# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports

# My own rules

# Add a page do be displayed when
# a banner is removed
deny_info NOTE_ADS_FILTERED url_ads

# Then deny them
http_access deny url_ads

# Deny all archives
http_access deny archives

# Restrict access to work hours
http_access allow localnet restricted_weekdays
http_access allow localnet restricted_weekends

# Deny the rest
http_access deny all
</pre>

<p>
Next fill in the files you do not want your users to download files. I have
added zip, viv, exe, mp3, rar, ace, avi, mov, mpg, mpeg, au, ra, arj, tar, gz
and z files.
</p>

<pre caption="/etc/squid/files.acl">
\.[Zz][Ii][pP]$
\.[Vv][Ii][Vv].*
\.[Ee][Xx][Ee]$
\.[Mm][Pp]3$
\.[Rr][Aa][Rr]$
\.[Aa][Cc][Ee]$
\.[Aa][Ss][Ff]$
\.[Aa][Vv][Ii]$
\.[Mm][Oo][Vv]$
\.[Mm][Pp][Gg]$
\.[Mm][Pp][Ee][Gg]$
\.[Aa][Uu]$
\.[Rr][Aa]$
\.[Aa][Rr][Jj]$
\.[Tt][Aa][Rr]$
\.[Gg][Zz]$
\.[Zz]$
</pre>

<note>
Please note the [] with upper and lowercase of every character. This is done so
no one can fool our filter by accessing a file called AvI instead of avi
</note>

<p>
Next we add the regular expressions for identifying banners. You will probably
be a lot more creative than I:
</p>

<pre caption="/etc/squid/banner-ads.acl">
/adv/.*\.gif$
/[Aa]ds/.*\.gif$
/[Aa]d[Pp]ix/
/[Aa]d[Ss]erver
/[Aa][Dd]/.*\.[GgJj][IiPp][FfGg]$
/[Bb]annerads/
/adbanner.*\.[GgJj][IiPp][FfGg]$
/images/ad/
/reklame/
/RealMedia/ads/.*
^http://www\.submit-it.*
^http://www\.eads.*
^http://ads\.
^http://ad\.
^http://ads02\.
^http://adaver.*\.
^http://adforce\.
adbot\.com
/ads/.*\.gif.*
_ad\..*cgi
/Banners/
/SmartBanner/
/Ads/Media/Images/
^http://static\.wired\.com/advertising/
^http://*\.dejanews\.com/ads/
^http://adfu\.blockstackers\.com/
^http://ads2\.zdnet\.com/adverts
^http://www2\.burstnet\.com/gifs/
^http://www.\.valueclick\.com/cgi-bin/cycle
^http://www\.altavista\.com/av/gifs/ie_horiz\.gif
</pre>

<p>
And as the last part we want this file to be displayed when a banner is removed.
It is basically a half html file with a 4x4 transparent gif image.
</p>

<pre caption="/etc/squid/errors/NOTE_ADS_FILTERED">
&lt;HTML&gt;
&lt;HEAD&gt;
&lt;META HTTP-EQUIV="REFRESH" CONTENT="0; URL=http://localhost/images/4x4.gif"&gt;
&lt;TITLE&gt;ERROR: The requested URL could not be retrieved&lt;/TITLE&gt;
&lt;/HEAD&gt;
&lt;BODY&gt;
&lt;H1&gt;Add filtered!&lt;/H1&gt;
</pre>

<note>
Do not close the &lt;HTML&gt; &lt;BODY&gt; tags. This will be done by squid.
</note>

<p>
As you can see, Squid has a lot of possibilities and it is very effective at
both filtering and proxying. It can even use alternative Squid proxies to scale
on very large networks. The configuration I have listed here is mostly suited
for a small network with 1-20 users.
</p>

<p>
But combining the packet filter (iptables) and the application gateway (Squid)
is probably the best solution, even if Squid is located somewhere safe and
nobody can access it from the outside. We still need to be concerned about
attacks from the inside.
</p>

<p>
Now you have to configure your clients browsers to use the proxy server. The
gateway will prevent the users from having any contact with the outside unless
they use the proxy.
</p>

<note>
In Mozilla this is done in Edit-&gt;Preferences-&gt;Advanced-&gt;Proxies.
</note>

<p>
It can also be done transparently by using iptables to forward all outbound
traffic to a Squid proxy. This can be done by adding a forwarding/prerouting
rule on the gateway:
</p>

<pre caption="Enable portforwarding to our proxyserver">
# <i>iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to proxyhost:3128</i>
# <i>iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to proxyhost:3128</i>
</pre>

<note>
If the proxy is running on the packet filtering host--though this is not
recommended, it may be necessary if you do not have enough spare machines--use
a <c>REDIRECT</c> target instead of <c>DNAT</c> (<c>REDIRECT</c> directs packets
to the localhost).
</note>

</body>
</section>
<section>
<title>Lessons learned</title>
<body>

<p>
We have learned that:
</p>

<ol>
<li>
A firewall can be a risk in itself. A badly configured firewall is worse than
not having one at all.
</li>
<li>How to setup a basic gateway and a transparent proxy.</li>
<li>The key to a good firewall is to know the protocols you want do allow.</li>
<li>
That IP traffic does not always contain legitimate data, e.g. ICMP packets,
which can contain a malicious payload.
</li>
<li>How to prevent SYN attack.</li>
<li>Filtering HTTP traffic by removing offensive pictures and downloads of viruses.</li>
<li>
Combining packet filters and application gateways provides better control.
</li>
</ol>

<p>
Now, if you <e>really</e> need to, go create a firewall that matches
your needs.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Intrusion detection</title>
<section>
<title>AIDE (Advanced Intrusion Detection Environment)</title>
<body>

<p>
AIDE is a Host-Based Intrusion Detection System (HIDS), a free alternative to
Tripwire (if you already know Tripwire you should have no difficulties learning
the configuration file for AIDE). HIDS are used to detect changes to important
system configuration files and binaries, generally by making a unique
cryptographic hash for the files to be checked and storing it in a secure
place. On a regular basis (such as once a day), the stored "known-good" hash is
compared to the one generated from the current copy of each file, to determine
if that file has changed. HIDS are a great way to detect disallowed changes to
your system, but they take a little work to implement properly and make good use
of.
</p>

<p>
The configuration file is based on regular expressions, macros and rules for
files and directories. We have the following macros:
</p>

<table>
<tr>
  <th>Macro</th>
  <th>Description</th>
  <th>Syntax</th>
</tr>
<tr>
  <ti>ifdef</ti>
  <ti>If definded</ti>
  <ti>@@ifdef "name"</ti>
</tr>
<tr>
  <ti>ifndef</ti>
  <ti>If not defined</ti>
  <ti>@@ifndef "name"</ti>
</tr>
<tr>
  <ti>define</ti>
  <ti>Define a variable </ti>
  <ti>@@define "name" "value"</ti>
</tr>
<tr>
  <ti>undef</ti>
  <ti>Undefine a variable</ti>
  <ti>@@undef "name"</ti>
</tr>
<tr>
  <ti>ifhost</ti>
  <ti>if "hostname"</ti>
  <ti>@@ifhost "hostname"</ti>
</tr>
<tr>
  <ti>ifnhost</ti>
  <ti>if not "hostname"</ti>
  <ti>@@ifnhost "hostname"</ti>
</tr>
<tr>
  <ti>endif</ti>
<ti>
Endif must be used after any of the above macros except define and undef
</ti>
<ti>@@endif</ti>
</tr>
</table>

<p>
These macros become very handy if you have more than one Gentoo box and want to
use AIDE on all of them. But not all machines run the same services or even have
the same users.
</p>

<p>
Next we have sets of flags to check for on files and directories. These are a
combination of permissions, file properties and cryptographic hashes
(i.e. checksums).
</p>

<table>
<tr>
  <th>Flag</th>
  <th>Description</th>
</tr>
<tr>
  <ti>p</ti>
  <ti>permissions</ti>
</tr>
<tr>
  <ti>i</ti>
  <ti>inode</ti>
</tr>
<tr>
  <ti>n</ti>
  <ti>number of links</ti>
</tr>
<tr>
  <ti>u</ti>
  <ti>user</ti>
</tr>
<tr>
  <ti>g</ti>
  <ti>group</ti>
</tr>
<tr>
  <ti>s</ti>
  <ti>size</ti>
</tr>
<tr>
  <ti>b</ti>
  <ti>block count</ti>
</tr>
<tr>
  <ti>m</ti>
  <ti>mtime</ti>
</tr>
<tr>
  <ti>a</ti>
  <ti>atime</ti>
</tr>
<tr>
  <ti>c</ti>
  <ti>ctime</ti>
</tr>
<tr>
  <ti>S</ti>
  <ti>check for growing size</ti>
</tr>
<tr>
  <ti>md5</ti>
  <ti>md5 checksum</ti>
</tr>
<tr>
  <ti>sha1</ti>
  <ti>sha1 checksum</ti>
</tr>
<tr>
  <ti>rmd160</ti>
  <ti>rmd160 checksum</ti>
</tr>
<tr>
  <ti>tiger</ti>
  <ti>tiger checksum</ti>
</tr>
<tr>
  <ti>R</ti>
  <ti>p+i+n+u+g+s+m+c+md5</ti>
</tr>
<tr>
  <ti>L</ti>
  <ti>p+i+n+u+g</ti>
</tr>
<tr>
  <ti>E</ti>
  <ti>Empty group</ti>
</tr>
<tr>
  <ti>&gt;</ti>
  <ti>Growing logfile p+u+g+i+n+S</ti>
</tr>
</table>

<p>
And if AIDE is compiled with mhash support it supports a few other features:
</p>

<table>
<tr>
<th>Flag</th>
<th>Description</th>
</tr>
<tr>
<ti>haval</ti>
<ti>haval checksum</ti>
</tr>
<tr>
<ti>gost</ti>
<ti>gost checksum</ti>
</tr>
<tr>
<ti>crc32</ti>
<ti>crc32 checksum</ti>
</tr>
</table>

<p>
Now you can create you own rules based on the above flags by combining them 
like this:
</p>

<pre caption="Create a ruleset for AIDE">
All=R+a+sha1+rmd160
Norm=s+n+b+md5+sha1+rmd160
</pre>

<p>
The last thing we need to create our own configuration file is to see how to add
a rule to a file or directory. To enter a rule, combine the file or directory
name and the rule. AIDE will add all files recursively unless you specify an
alternate rule.
</p>

<table>
<tr>
<th>Flag</th>
<th>Description</th>
</tr>
<tr>
<ti>!</ti>
<ti>Don't add this file or directory.</ti>
</tr>
<tr>
<ti>=</ti>
<ti>Add this directory, but not recursively.</ti>
</tr>
</table>

<p>
So lets watch a full blown example:
</p>

<pre caption="/etc/aide/aide.conf">
@@ifndef TOPDIR 
@@define TOPDIR /
@@endif

@@ifndef AIDEDIR 
@@define AIDEDIR /etc/aide
@@endif

@@ifhost smbserv
@@define smbactive
@@endif

# The location of the database to be read.
database=file:@@{AIDEDIR}/aide.db

# The location of the database to be written.
database_out=file:aide.db.new

verbose=20
report_url=stdout

# Rule definition
All=R+a+sha1+rmd160
Norm=s+n+b+md5+sha1+rmd160

@@{TOPDIR} Norm
!@@{TOPDIR}etc/aide
!@@{TOPDIR}dev
!@@{TOPDIR}proc
!@@{TOPDIR}root
!@@{TOPDIR}tmp
!@@{TOPDIR}var/log
!@@{TOPDIR}var/run
!@@{TOPDIR}usr/portage
@@ifdef smbactive
!@@{TOPDIR}etc/smb/private/secrets.tdb
@@endif
=@@{TOPDIR}home Norm
</pre>

<p>
In the above example we specify with some macros where the topdir starts and
where the AIDE directory is. AIDE checks the <path>/etc/aide/aide.db</path> file
when checking for file integrity. But when updating or creating a new file it
stores the information in <path>/etc/aide/aide.db.new</path>. This is done so it
won't automatically overwrite the old db file. The option
<c>report_URL</c> is not yet implemented, but the author's intention was that 
it should be able to e-mail or maybe even execute scripts.
</p>

<p>
After editing the configuration you should create your db file by executing
<c>aide -i</c> and then copy the file <path>/etc/aide/aide.db.new</path> to 
<path>/etc/aide/aide.db</path> and add the check to cron by executing 
<c>crontab -e</c> as root.
</p>

<note>
Depending on your CPU, disk access speed, and the flags you have set on files,
this can take some time.
</note>

<pre caption="Shedule aide as a cronjob">
0 3 * * * /usr/bin/aide -u
</pre>

<note>
Remember to set an alias so you get roots mail. Otherwise you will never know
what AIDE reports.
</note>

<p>
In this case it runs once at 3am. This is done since I do not want to disturb
the users when they are working. Note I am using the <c>-u</c> (Update) option
instead of the <c>-C</c> (Check). Since <c>-u</c> also checks the files and does
not overwrite the original db file it saves some time since all you need to do
is to copy a file when it detects some changes. Just check the changes to see if
it was you who made the changes instead of some attacker before you copy it!
</p>

<p>
Now there is some risk inherent with storing the db files locally, since the
attacker will (if they know that AIDE is installed) most certainly try to alter
the db file, update the db file or modify <path>/usr/bin/aide</path>. So you
should create a CD or other media and put on it a copy of the .db file and the
AIDE binaries.
</p>

<p>
One can find information at the <uri link="http://www.cs.tut.fi/~rammer/aide.html">AIDE</uri> project page.
</p>

</body>
</section>
<section>
<title>Snort</title>
<body>

<p>
Snort is a Network Intrusion Detection System (NIDS). To install and configure
it use the following examples.
</p>

<pre caption="Add a user snort to the system">
# useradd snort -d /var/log/snort -s /dev/null
# chown -R snort /var/log/snort
</pre>

<pre caption="/etc/conf.d/snort">
PIDFILE=/var/run/snort_eth0.pid
MODE="full"
NETWORK="10.0.0.0/24"
LOGDIR="/var/log/snort"
CONF=/etc/snort/snort.conf
SNORT_OPTS="-D -s -u snort -dev -l $LOGDIR -h $NETWORK -c $CONF"
</pre>

<pre caption="/etc/snort/snort.conf">
<comment>(Step 1)</comment>
var HOME_NET 10.0.0.0/24
var EXTERNAL_NET any
var SMTP $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var DNS_SERVERS [10.0.0.2/32,212.242.40.51/32]
var RULE_PATH ./

<comment>(Step 2)</comment>
preprocessor frag2
preprocessor stream4: detect_scans detect_state_problems detect_scans disable_evasion_alerts
preprocessor stream4_reassemble: ports all
preprocessor http_decode: 80 8080 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace
preprocessor rpc_decode: 111 32771
preprocessor bo: -nobrute
preprocessor telnet_decode

<comment>(Step 3)</comment>
include classification.config

<comment>(Step 4)</comment>
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/smtp.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/rservices.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/dns.rules
include $RULE_PATH/tftp.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-coldfusion.rules
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-frontpage.rules
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/x11.rules
include $RULE_PATH/icmp.rules
include $RULE_PATH/netbios.rules
include $RULE_PATH/misc.rules
include $RULE_PATH/attack-responses.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules
include $RULE_PATH/policy.rules
include $RULE_PATH/porn.rules
include $RULE_PATH/info.rules
include $RULE_PATH/icmp-info.rules
include $RULE_PATH/virus.rules
# include $RULE_PATH/experimental.rules
include $RULE_PATH/local.rules
</pre>

<pre caption="/etc/snort/classification.config">
config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
config classification: bad-unknown,Potentially Bad Traffic, 2
config classification: attempted-recon,Attempted Information Leak,2
config classification: successful-recon-limited,Information Leak,2
config classification: successful-recon-largescale,Large Scale Information Leak,2
config classification: attempted-dos,Attempted Denial of Service,2
config classification: successful-dos,Denial of Service,2
config classification: attempted-user,Attempted User Privilege Gain,1
config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1
config classification: successful-user,Successful User Privilege Gain,1
config classification: attempted-admin,Attempted Administrator Privilege Gain,1
config classification: successful-admin,Successful Administrator Privilege Gain,1

# NEW CLASSIFICATIONS
config classification: rpc-portmap-decode,Decode of an RPC Query,2
config classification: shellcode-detect,Executable code was detected,1
config classification: string-detect,A suspicious string was detected,3
config classification: suspicious-filename-detect,A suspicious filename was detected,2
config classification: suspicious-login,An attempted login using a suspicious username was detected,2
config classification: system-call-detect,A system call was detected,2
config classification: tcp-connection,A TCP connection was detected,4
config classification: trojan-activity,A Network Trojan was detected, 1
config classification: unusual-client-port-connection,A client was using an unusual port,2
config classification: network-scan,Detection of a Network Scan,3
config classification: denial-of-service,Detection of a Denial of Service Attack,2
config classification: non-standard-protocol,Detection of a non-standard protocol or event,2
config classification: protocol-command-decode,Generic Protocol Command Decode,3
config classification: web-application-activity,access to a potentially vulnerable web application,2
config classification: web-application-attack,Web Application Attack,1
config classification: misc-activity,Misc activity,3
config classification: misc-attack,Misc Attack,2
config classification: icmp-event,Generic ICMP event,3
config classification: kickass-porn,SCORE! Get the lotion!,1
</pre>

<p>
More information is at the <uri link="http://www.snort.org">Snort</uri> web site.
</p>

</body>
</section>

<section>
<title>Detecting malware with chkrootkit</title>

<body>

<p>
HIDS like AIDE are a great way to detect changes to your system, but it never
hurts to have another line of defence. <c>chkrootkit</c> is a utility that scans
common system files for the presence of rootkits--software designed to hide an
intruder's actions and allow him to retain his access--and scans your system for
likely traces of key loggers and other "malware". While <c>chkrootkit</c> (and
alternatives like <c>rkhunter</c>) are useful tools, both for system
maintenance and for tracking an intruder after an attack has occurred, they
cannot guarantee your system is secure.
</p>

<p>
The best way to use <c>chkrootkit</c> to detect an intrusion is to run it
routinely from <c>cron</c>. To start, emerge <path>app-admin/chkrootkit</path>. 
<c>chkrootkit</c> can be run from the command line by the command of the same
name, or from <c>cron</c> with an entry such as this:
</p>

<pre caption="Schedule chkrootkit as a cronjob">
0 3 * * * /usr/sbin/chkrootkit
</pre>

</body>
</section>

</chapter>

<chapter>
<title>Keeping up to date</title>
<section>
<body>

<p>
Once you have successfully installed your system and ensured a good level of
security you are not done. Security is an ongoing process; the vast majority of
intrusions result from known vulnerabilities in unpatched systems. Keeping your
system up-to-date is the single most valuable step you can take to greater
security.
</p>

<p>
If you have a recent version of <c>portage</c> installed, you can first sync
your portage tree with <c>emerge --sync</c> and then issue the command
<c>glsa-check --list</c> to check if your system is up to date security-wise.
<c>glsa-check</c> is part of <c>app-portage/gentoolkit</c>.
</p>

<pre caption="Example output of glsa-check -l">
# <i>glsa-check -l</i>
WARNING: This tool is completely new and not very tested, so it should not be
used on production systems. It's mainly a test tool for the new GLSA release
and distribution system, it's functionality will later be merged into emerge
and equery.
Please read http://www.gentoo.org/proj/en/portage/glsa-integration.xml
before using this tool AND before reporting a bug.

[A] means this GLSA was already applied,
[U] means the system is not affected and
[N] indicates that the system might be affected.

200406-03 [N] sitecopy: Multiple vulnerabilities in included libneon ( net-misc/sitecopy )
200406-04 [U] Mailman: Member password disclosure vulnerability ( net-mail/mailman )
.......
</pre>

<warn>
The <c>glsa-check</c> is still experimental, so if security really is your top
priority it would be wise to double check the list with other sources.
</warn>

<p>
All lines with a <c>[A]</c> and <c>[U]</c> can be almost safely ignored as the
system is not affected by this GLSA.
</p>

<p>
Some people still prefer to use <c>emerge packagename</c> instead of
<c>glsa-check -f</c> so all GLSAs are listed as <c>[N]</c>.
</p>

<p>
If you want an email each time a GLSA is released subscribe to the 
<c>gentoo-announce</c> mailing list. Instructions for joining it and many other
great mailing lists can be found <uri link="/main/en/lists.xml">Gentoo Linux
Mailing List Overview</uri>.
</p>

<p>
Another great security resource is the <uri link="http://www.securityfocus.com/archive/1">Bugtraq
mailing list</uri>.
</p>

</body>
</section>
</chapter>
</guide>

Return to bug 71211