Attachment #32785 for bug #52393

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




  <mail link="blubber@gentoo.org">Tiemo Kieft</mail>
</author>
<author title="Editor">
        <mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
</author>
<author title="Editor"><!-- dmargoli@speed.seas.upenn.edu -->
  Dan Margolis
</author>

<abstract>
This guide is step-by-step guide for hardening Gentoo Linux.
</abstract>

<license/>

<body>

<p>
No matter how many safeguards you implement, all can easily be circumvented if
the attacker can gain physical access to your box.  Make sure your hardware is 
not casually accessible. For example, you may want to place your box
in a locked server closet.  Locking cases is a good idea too.  For the highest 
level of security set your BIOS to restrict booting to your hard drive only.
Disable booting from the floppy and CD-ROM drives.  For the paranoid, enabling 
the BIOS password is a good idea.  BIOS passwords are also a good idea for 
laptop users.
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>
<title>Daemon/Service Planning</title>
<body>

<p>
Document what services the machine should run or is supposed to run. This will 
help you compose a better partition scheme for the system.  It can also make 
your intrusion detection strategy much easier. Of course you should not document
this if you only have one or a few computers and you are the only one using 
them e.g. if the computer is going to act as a firewall it should not run 
<e>any</e> services except perhaps sshd.
</p>

<p>
Document this and the current version of sshd - it will help you keep track of 
which system to upgrade in case someone finds a security hole in sshd. This 
will also aid in determining who should have access to the system.
</p>

</body>

<body>

<p>
Golden rules:
</p>

<ul>
<li>
  Any directory tree a user should be able to write to (<path>/home</path> and 
  <path>/tmp</path> <path>/var</path>), should be on a separate partition and 
  use disk quotas. Portage uses <path>/var/tmp</path> to compile files so that 
  partition should be large. This reduces the risk of a user filling up your 
  <path>/</path> mount point.
</li>
<li>
  Any directory tree where you want to install non-distribution software 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>
  Try to move static data to its own partition, and mount that partition in 
  read-only mode. If you're really paranoid you could try storing static data 
  on read-only media like CDROMs.
</li>
</ul>


<body>

<p>
The user 'root' is the most vital user on the system and should not be used for
anything except if it is necessary. If an attacker gains root access you can no
longer trust your system, so reinstall.
</p>

<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 su to root.
</li>
<li>
  Never run X or any other user application as root
  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. It's possible to trick root
  into running a different application rather than the one meant to be ran. For 
  example if someone tampered with the PATH and root su's without using 
  <c>su -</c>. Then root will use the path of the user.
  root into runninga different application rather than the one meant to be
  run. If root's <c>PATH</c> is protected or root only uses absolute paths, wecan
  be sure this won't happen.
</li>
<li>
  If a user only needs a few commands instead of everything that root normally 
  can do, consider using <c>sudo</c>, but be careful with this!
  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 general protection against normal users, trying to <c>su</c>. The 
default PAM setting states that a users has to be a member of wheel in order 
to be able to su.
</p>

</body>
</section>
<section>
<title>Security policies</title>
<body>

<p>
There are several reasons why security policies are needed.
network.
</p> 

<ul>
<li>
  You cannot claim to have a secure network without a definition of what you 
  think is secure
</li>
<li>
  It is almost impossible to catch potential attackers, resolve network 
  problems, or conduct audits, without spying on network traffic or looking in 
  private home directories. And spying without the users agreement is illegal 
  in most countries. And since about 60% of all attacks currently come from 
  inside the organization, it is important that you keep an open eye.
</li>
<li>
  You cannot expect your users to think about security, if you never explained 
  why it was important or how they should protect themselves and their 
  colleagues.
  print, and making users aware of this, such actions may actually be illegal
  and put <e>you</e> in legal jepeordy.
</li>
<li>
  Good guidelines and network documentation always pays off, no matter what
  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>
  Police or federal law enforcement can not help you catch the attacker, if 
  they do not know your network configuration or the services that you provide.
</li>
<li>
  What will you do when there has been an attack? You need to define what you 
  are going to do and who you are going to tell about it. Are you just going 
  to call the police/a CERT team on every occasion? They won't take you serious!
</li>
</ul>

<p>
This should clearly state why it is important to create policies for systems 
with more than one user and why it is important to educate users.
</p>

<p>
A policy is a document (or several documents) with answers to questions like 
who, where, why and what. Every user on your system/network should read, 
understand and sign it. It is important that you take the time to help the 
users understand the policy and why the 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.
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>

</note>

<p>
Most parts of a policy can be enforced directly in the operating system or 
through firewalls and others cannot.
</p>

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


  <li>PC shutdown before leaving</li>
  <li>Use of encryption</li>
  <li>Handling of keys to trusted co-workers</li>
  <li>Handling of classified material when traveling</li>
  </ul>
</li>
<li>Handling of computer equipment when traveling</li>

</ul>

<p>
The policy for the IT-staff might be a bit different then the normal users.
your policy may vary to accomodate 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 classified 
for the ordinary user, so it is wise to split it up into smaller policies; i.e.
Acceptable Use Policy, Password policy, Email policy and Remote Access policy.
policy.
</p>

<p>
One 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="http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2196.html">Site Security 
Handbook</uri>.
</p>


</chapter>

<chapter>
<title>Tightening the security after/during 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 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>
<title>GRUB password</title>
<body>

<p>
Grub supports 2 different ways of adding password restriction to its 
configuration file (<path>/boot/grub/grub.conf</path>). One with plain text 
password and one with md5+salt encryption.
</p>

<pre caption="/boot/grub/grub.conf">

</pre>

<p>
This will add the password <c>changeme</c> and if no password is entered simply 
use the default boot setting.
</p>

<p>
When adding a md5 password, you need to convert the password into crypt format 
(<c>man crypt</c>) which is the same format as <path>/etc/shadow</path>. For 
more information see <c>man crypt</c>. The encrypted password <e>changeme</e> 
could look like this $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.
</p>

<p>
Or this you can convert it directly in 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> <i>md5crypt</i>

Password: <i>********</i>
<codenote>Typed changeme</codenote>
Encrypted: $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.

grub> <i>quit</i>

</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>
<title>LILO password</title>
<body>

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

<p>
The global one is set at the top of the configuration file:
every boot image:
</p>

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

<p>
Otherwise simply add it to an image.
</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 password, 
every time.
</p>

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


<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 wheel group can still <c>su -</c> to become root on other TTYs.
</note>

<pre caption="/etc/securetty">

<body>

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

<p>
Its also vital that the log files are easy readable and manageable.  Gentoo 
Linux lets you choose between 3 different loggers when installing.
</p>


<body>

<p>
Syslogd is the most common logger for Linux and Unix in general. It does not 
come with log rotation. This feature is handled by running 
<path>/usr/sbin/logrotate</path> in a cron job and configured in 
<path>/etc/logrotate.conf</path>. 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 logs in two places.
</p>

<pre caption="/etc/syslog.conf">
#  /etc/syslog.conf     Configuration file for syslogd.
#
#                       For more information see syslog.conf(5)
#                       manpage.

#       *.=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 the 
log files. You can make it harder for the attacker by logging to one or more 
logging servers on different machines. Get more info about syslogd by executing
<c>man syslog</c>.
</p>

</body>

<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 and it can 
launch external scripts when specific patterns are found. It is very good for 
taking action when needed.
</p> 

<p>
The standard configuration is basically enough. If you want to be notified by
email whenever a password failure occurs use one of the following scripts.
</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>

For qmail:
</p>

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

</p>

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


<body>

<p>
Syslog-ng provide 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 log 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>
A classic configuration file slightly modified.
</p>

<pre caption="/etc/syslog-ng/syslog-ng.conf">

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); };

</pre>

<p>
Very easy to configure but 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 other advantages. 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 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>

<body>

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

<ul>

  file
</li>
<li>
  <c>noexec</c> - Will prevent from executing files from this partition
</li>
<li>
  <c>nodev</c> - Ignores devices

</ul>

<p>
Unfortunately these settings can easily be circumvented by executing a 
non-direct path. However setting <path>/tmp</path> to noexec will stop about 
99% of all script kiddies since their exploits are designed to be executed 
directly from <path>/tmp</path>.
</p>

<pre caption="/etc/fstab">

</pre>

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

<note>
Disk quotas see <uri link="#doc_chap6_sect3">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 


<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> in <c>noexec</c> mode.
mode.
</note>

</body>


<chapter>
<title>User/group limitations</title>
<section>
<title>/etc/security/limits.conf</title>
<body>

<p>
Controlling resource limitations can be very effective when trying to prevent 
a local DoS or handling 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>


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

<pre caption="/etc/limits">

</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 
limitations in this file if you have disabled <c>pam</c> in 
<path>make.conf</path> or not configured PAM properly.
</p>


<body>

<warn>
Make sure the file systems you are working with support quotas. ReiserFS is not 
one of them!
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 prevents users from filling up the disk or 
writing at all. Quotas are enabled in the kernel and added to a mount point. 
The kernel option is enabled in the kernel configuration under 
<c>File systems->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 like the example below.
</p>

<pre caption="/etc/fstab">

</pre>

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


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

</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">

</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 just for groups.
</p>

<pre caption="Setting up quota's for user kn">

</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>


<section>
<title>/etc/login.defs</title>
<body>
            
<p>
If the 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 also recommended that you use password aging since brute force methods will 
find any password, it is just a matter of time. We also encourage you to set 
<c>LOG_OK_LOGINS</c> to yes.
</p>

</body>

<body>

<p>
The <path>login.access</path> file is also part of the sys-apps/shadow package, 
which gives a login access control table. The table is used to control who can 
and cannot login based on user name, group name or host name. Per 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 does not apply for root.
</note>

<pre caption="/etc/login.access">

</pre>

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

<note>
These settings does not apply to SSH since SSH does not execute 
<c>/bin/login</c> per default. This can be enabled by using the <c>UseLogin 
yes</c> in <path>/etc/ssh/sshd_config</path>. It will make SSH use login and 
the settings will apply.
</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 safe then sorry.
</p>

</body>

<body>

<p>
Normal users should not have access to configuration files or passwords. An 
attacker can steal passwords from databases or websites and use them to deface 
or even worse, delete data. This is why it is important that the 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>

</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>

<p>
Files with the SUID or SGID bit set allows the files to 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 compromise (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 the files use 
<c>chmod 0</c> on them or unmerge the package they came from (check which 
package they belong to by using <c>qpkg -f</c>). If you do not already have it 
installed simply type <c>emerge gentoolkit</c> it). 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>/dev/null >suidfiles.txt</i>
</pre>

<p>

</pre>

<p>
By default Gentoo Linux does not have a lot of SUID files (it 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 
<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 will prevent you from 
su'ing and receiving mail. By removing the bit you remove the possibility of a 
normal user (or an attacker) to gain root access through any of these files.
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 access.
access afforded by SUID.
</p>

</body>

<body>

<p>
PAM is a suite of shared libraries that provide an alternative way of making 
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">

</pre>

<p>
This will add the cracklib which will ensure that the users use a minimum 
password length of 8 characters and it consists of minimum 2 digits, 2 others 
and there must be 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>

<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> rule. The default settings are 
set to <c>deny</c> as it should. But I like to have a lot of logs and that 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="#doc_chap6_sect1">/etc/security/limits.conf section</uri> for more on 
these settings.
</p>

<pre caption="/etc/pam.d/other">

<body>

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

</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 and they do 
not work in the same area of security. These settings only apply to services 
using tcp wrappers.
</p>

<p>
It is also possible to execute commands when a service is accessed (can be 
used when activating relaying for dial in users) but its 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 email 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 mails so don't do it!. Read 
the <c>man 5 hosts_access</c> for more information.
</p>

</body>

<body>

<p>
The basic rule when configuring the kernel is to remove everything, you do not 
need. This will 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 modules (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>/proc (kernel flags)</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 default in a standard 2.4 
kernel.
</p>

<pre caption="Drop ping packets">

</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 the 
ICMP message can contain payload with other information than you think. 
Administrators use ping as a diagnostic tool and often complain if they cannot 
ping. There is no reason for an outsider to be able to ping. But sometimes it 
can be handy for insiders to be able to ping. Then this can be solved by 
disabling ICMP type 0 messages in the firewall.
to use this tool).
</p>

<pre caption="Ignore broadcast pings">

</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 
flooding the spoofed host.
</p>

<pre caption="Disable source routed packets">

</pre>

<p>
Do not accept source routed packets. Attackers can use source routing to 
generate traffic pretending to originate from inside your network, but it 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 disable it.
</p>

<pre caption="Disable redirect acceptance">

</pre>

<p>
Disable ICMP redirect acceptance. ICMP redirects can be used to alter your 
routing tables, possibly to a bad end.
</p>

<pre caption="Protect against bad error messages">

</note>

<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.
</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">

</pre>

<p>
Make sure that IP forwarding is turned off. We only want this for a multi-homed 
host.
</p>

<p>
All these settings will be reset when the machine is rebooted. So 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>

<body>

<p>
The patch from <uri link="http://grsecurity.net">Grsecurity</uri> is standard 
in the Gentoo kernel sources but is disabled as 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 homepage</uri>.
</p>

</body>

<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 like: 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>

</ul>

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

</body>

<body>

<p>
Apache (1.3.26) comes with a pretty decent configuration file but again. We 
need to improve some things, like binding to one address and keep it from 
leaking information. These 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 a ssl enabled server. Just add 
the following line to enable it.
</p>

<pre caption="/etc/conf.d/apache">


<p>
Apache is compiled with <c>--enable-shared=max</c> and 
<c>--enable-module=all</c>. This will per 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>
One can find documentation at <uri>http://www.apache.org</uri>.
</p>

</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:
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\`"
<codenote>Before running the above command you might want to change the chroot 
directory in /etc/conf.d/named. Otherwise /chroot/dns will be used.</codenote>
<codenote>You might need to substitute the version number with the current version number </codenote>
</pre>

<body>

<p>
Djbdns is a DNS implementation of which the author is willing to bet
<uri link="http://cr.yp.to/djbdns/guarantee.html">money</uri> on how 
secure it is. 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>

<body>

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

</body>

<body>

<p>
If you only need local applications to access the <c>mysql</c> database uncomment the following line.
uncomment the following line.
</p>
<pre caption="Disable network access">
skip-networking
</pre>

<p>
Disable the command <c>LOAD DATA LOCAL INFILE</c>.
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">

</pre>

<p>
The default <c>mysql</c> installation comes with an empty <c>root</c> password. 
</p>

<pre caption="Set root password">
<i>/usr/local/mysql/bin/mysql -u root</i> 
mysql> <i>SET PASSWORD FOR root@localhost=PASSWORD('new_password');</i>
</pre>
<note>

It is good practice not to change passwords from the command line, for example, 
by using the <c>mysqladmin password</c> command. This is especially important when other 
users work on the server. In that case the password could be easily revealed, e.g. 
by using the <c>ps aux</c> command or reviewing history files (<path>~/.history</path>, 
<path>~/.bash_history</path> etc), when improper access rights are set to them. 
</note>

<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">

</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>

<body>

<p>
Proftpd has had several security problems, but they seem to have fixed most of 
them. Still apply some enhancements:
</p>

<pre caption="/etc/proftpd/proftpd.conf">

<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 it to <c>-lpuredb:/etc/pureftpd.pdb</c> and create your users by using 
<c>/usr/bin/pure-pw</c>. 
</p>


</pre>

<p>
And configure your <c>MISC_OTHER</c> setting for not allowing anonymous 
(<c>-E</c>), chroot everyone (<c>-A</c>), Users can not read or write 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>


</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 (like
virtual users) 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
and no default chroot action. 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 considered to be the most secure mail server. It is written with 
security (and paranoia) in mind. It does not allow relaying per default and 
have not had a security hole since 1996. Simply <c>emerge qmail</c> and go 
configure!
</p>
</body>
</section>

<body>

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


  #Enables user authentication 
  #(don't use the share mode)
  security = user
  
  #Disallow privileged accounts
  invalid users = root @wheel


</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 <path>/usr/bin/smbpasswd</path> with the 
parameter -a
</p>

</body>

<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 all suffered unauthorized intrusion to 
their systems due to password leaks or bad passwords.
</p>

<pre caption="/etc/ssh/sshd_config">

</pre>

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

<pre caption="Create a DSA keypair">

</pre>

<p>
And type in a passphrase
</p>

<pre caption="Output of ssh-keygen">

<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="#doc_chap2_sect5">password</uri> policy).
</p>

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

</body>

<body>

<p>
xinetd is a replacement for inetd (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 work we recommend not to use it. But if you want to use it anyway 
here how you can add some security to it:
</p>

<pre caption="Install xinetd">

<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:

# 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 the <c>man 5 xinetd.conf</c>.
</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 (like 
virtual users) 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 
and no default chroot action. But when it comes to anonymous settings it is 
quite good. Sometimes it can be nice to have a anonymous ftp server (for 
sharing open source) and vsftpd does a really good job at this.
</p>

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

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

<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. The syntax is <c>/usr/X11R6/bin/xhost +hostname</c>
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 control your desktop. If you have to use it 
always remeber 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. 
configuration.
</p>

<pre caption="/usr/X11R6/bin/startx">

</pre>

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


<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.
an attacker cannot gain root 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>

Let's see how to create a <c>chroot</c>. For a basic understanding of how
<c>chroots</c> work, we will test it with <c>bash</c> (an 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>

<note>
If <c>bash</c> is compiled with the <c>static</c> USE flag this step is not
necessary.
</note>

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

<pre caption="Get listing of used libraries">

</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</c>. If you get an prompt saying <path>/</path> it 
works! Otherwise it will properly tell you what a file is missing. Some shared 
successful. Otherwise it will 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>

<note>

In <c>portage</c> you can find <uri
link="http://www.jmcresearch.com/projects/jail/">jail</uri> which will setup a
chroot jail almost automatically.
</note>

</body>
</section>
<section>
<title>Virtual servers</title>
<body>

<p>
Another way of creating a more secure environment is by using a virtual server 
environment. This will create a copy of the existing Linux and boots it in a 
virtual mode. This means that if the server is compromised its only the virtual 
server that has been compromised and not the real installation.
that if the server running on the virtual machine is compromised, only the
virtual server is affected and not the parent installation.
</p>

<p>
Example of virtual servers:
<uri link="http://www.gentoo.org/doc/en/uml.xml">User Mode Linux
Guide</uri>.
</p>

<ul>
<li>
  <uri link="http://user-mode-linux.sourceforge.net">User-Mode Linux</uri> and 
  a howto about <uri link="http://www.gentoo.org/doc/uml.html">User-Mode 
  Linux</uri>.
</li>
</ul>

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


<p>
People often think that a firewall provides the ultimate security, but they 
are wrong. In most cases a misconfigured firewall gives worse 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 is just as likely 
to contain bugs.
</p>

<p>
So think before implementing one! 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>

</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 to be.
</p>

</body>

<body>

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

<ul>

</ul>

<p>
Basically filtering is based on all data within the header of a packet and not 
its content.
</p>

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

</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>

<body>

<p>
Or circuit level gateways is a firewall that validates connections before 
allowing data to be exchanged. This means that it simply does not 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>

</ul>

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

<p>


<ul>
<li>
  Operates at the Transport Layer and may require substantial modification of 
  the programming which normally provides transport functions
</li>
</ul>


<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 packets content</li>
<li>Limiting file access based on file type or extension</li>
</ul>


<ul>
<li>Can cache files, increasing network performance</li>
<li>Detailed logging of all connections</li>
<li>Scales perfectly (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>

</ul>

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

<p>

<body>

<p>
In order to get iptables working, it has to be enabled in the kernel. I have 
added them as modules (the <c>iptables</c> command will load them as they are 
needed) and recompiled my kernel. 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 have to add the <c>iptables</c> command. 
(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 it 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, sequence number so the packets can 
be reassembled and not to forget 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 to 
accept 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. 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" since such packets will not be part of an 
already established connection.
"stealth scans", a type of portscan 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 limitied 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 legitimate 
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 packetes 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>
<tr>
  <ti>-F</ti>
  <ti>Delete all rules in  chain or all chains</ti>
</tr>
<tr>
  <ti>-Z</ti>

</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">

</pre>

<p>
First we specify the chain it should be appended to next the protocol and then 
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>, <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>. It will not be able to get any response since 
iptables will drop all incoming ICMP messages. It will not be able to ping 
other machines either since the ICMP reply packet will be dropped. Now flush 
the chain to get ICMP flowing again.
</p>

<pre caption="Flush all rules">

</pre>

<p>
Now lets look at the stateful packet filtering in iptables. If we wanted to 
have a stateful inspection of packets incoming on eth0 we could enable it by 
issuing:
</p>

<pre caption="Accept packets that originate from an already established connection">

</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. This enables the stateful packet filtering in iptables 
by loading the extension state. If you wanted to allow others to connect to 
you machine you could use the <c>--state NEW</c>. Iptables contain some modules 
for different purposes. Some of them are: 
</p>

<table>

</tr>
<tr>
  <ti>unclean</ti>
  <ti>Various random sanity checks on packets</ti><ti></ti>
</tr>
</table>

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


</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:
that:
</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>

</pre>

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

<ol>
<li>Create your firewall policy before implementing it</li>
<li>Keep it simple</li>
<li>
  Know how the protocol works (read the <uri 
  link="http://www.ietf.org/">RFC</uri>(Request For Comments))
</li>
<li>
  Keep in mind that a firewall it 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>

<p>
Squid is a very powerful proxy server and it can filter traffic based on: time, 
regular expressions on path/URI, source and destination IP addresses, domain, 
browser, authenticated username, MIME type and port number (protocol). I 
probably forgot some features, but it can be hard to cover the entire feature 
list.
</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>


<ul>
<li>
  Surfing (HTTP/HTTPS) is allowed during work hours (mon-fri 8-17 and sat 8-13) 
  if they 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>
  Download is not allowed (.exe, .com, .arj, .zip, .asf, .avi, .mpg, .mpeg etc)
(this is where you get creative!).
</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 not allowed</li>
</ul>

<p>

</pre>

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

<pre caption="/etc/squid/files.acl">

</pre>

<note>
Please note the [] with upper and lowercase of every character. This is done so 
no one can fool it 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 me:
</p>

<pre caption="/etc/squid/banner-ads.acl">

</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 by 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>

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


# <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>Now what have we learned?</title>
<body>

<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 protocol you want do allow</li>
<li>
  That IP traffic does not always contain legitimate data ie. ICMP packets can 
  contain payload.
</li>
<li>How to prevent SYN attack</li>
<li>The key to a good firewall is to know the protocols you want do allow.</li>
<li>
  Filtering HTTP traffic by removing offensive pictures and downloads of 
  viruses
</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.
your needs.
</p>

</body>

<body>

<p>
AIDE is a host based intrusion detection system (free alternative to Tripwire). 
And if you already know Tripwire you should have no difficulties learning the 
configuration file for AIDE.
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>
<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 maybe 
even 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/checksums.
(i.e. checksums).
</p>

<table>

</table>

<p>
And if AIDE is compiled with mhash support it does have 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:
</p>

<pre caption="Create a ruleset for AIDE">

</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. Basically you just type the file or dir 
name and the rule. AIDE will add all files recursively unless you specify 
something else.
</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 recursive.</ti>
</tr>
</table>

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

<pre caption="/etc/aide/aide.conf">

</pre>

<p>
In the above example with some macros we specify 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 automatic overwrite the old db file. The option 
<c>report_URL</c> is not yet implemented. But the authors intention was that 
it should be able to email or maybe even execute script.
</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 and the flags you have set on files, it can 
take some time.
</note>

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

<note>
Remember to setup 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 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 yourself that made the changes or some attacker before you copy it!
</p>

<p>
Now there is some problems 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 a copy of the .db file and the aide binaries.
AIDE binaries.
</p>

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


<body>

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


</pre>

<p>
More information is at the <uri link="http://www.snort.org">Snort</uri> website.
link="http://www.snort.org">Snort</uri> website.
</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
intrudor's actions and allow him to retain his access--and scans your system for
likely traces of keyloggers and other "malware". While <c>chkrootkit</c> (and
alternatives like <c>rkhunter</c>) are useful tools, both for system
maintainance 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>

<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 and you have to 
keep your system up to date with the latest security patches. 
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.
</p>

<pre caption="Example output of glsa-check -l">

</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>

<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 a 
bunch of 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 mailinglist</uri>.
mailinglist</uri>.
</p>

</body>

Return to bug 52393