Attachment 34650 Details for Bug 52393 – updated

[patch] updated

gentoo-security.diff (text/plain), 123.80 KB, created by Dan Margolis (RETIRED) on 2004-07-02 08:14:44 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Dan Margolis (RETIRED)

Created: 2004-07-02 08:14:44 UTC

Size: 123.80 KB

patch

obsolete

>--- en/gentoo-security.xml	Sun Jun 6 14:44:04 2004
>+++ gentoo-security.xml	Fri Jul 2 11:11:25 2004
>@@ -35,9 +35,12 @@
> <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>
>-This guide is step-by-step guide for hardening Gentoo Linux.
>+This is a step-by-step guide for hardening Gentoo Linux.
> </abstract>
> 
> <license/>
>@@ -116,14 +119,20 @@
> <body>
> 
> 
>-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.
>+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
>+atleast some measures that can be taken to provide a degree of security against
>+anattacker with physical access to your machine. Putting your hardware in a
>+lockedcloset 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 a
>+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>.
> 
> 
> </body>
>@@ -131,20 +140,17 @@
> <section>
> <title>Daemon/Service Planning</title>
> <body>
>-
> 
>-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.
>+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.
> 
>-
> 
>-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.
>+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.
> 
> 
> </body>
>@@ -154,28 +160,27 @@
> <body>
> 
> 
>-Golden rules:
>+Partitioning rules:
> 
> 
> <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.
>+ Any directory tree a user should be able to write to (e.g. <path>/home</path>, 
>+ <path>/tmp</path>) should be on a seperate 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 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 
>+ Any directory tree where you plan on installing non-distribution software should
>+ be on a seperate 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.
>+ For extra security, static data can be put on a seperate partition that is
>+ mounted read-only. For the truly paranoid, try using read-only media like
>+ CD-ROM.
> </li>
> </ul>
> 
>@@ -186,9 +191,9 @@
> <body>
> 
> 
>-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.
>+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.
> 
> 
> 
>@@ -197,88 +202,98 @@
> 
> <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.
>+ 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
>+ 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. 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.
>+ 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 protecte directories
>+ like <path>/bin</path> and <path>/sbin</path>). It's possible to trick
>+ 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!
>+ 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
>+ Never leave the terminal when you are logged in as root.
> </li>
> </ul>
> 
> 
>-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.
>+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>.
> 
> 
> </body>
> </section>
>-<section>
>+<section id = "security_policies">
> <title>Security policies</title>
> <body>
> 
> 
>-There are several reasons why security policies are needed.
>+There are several reasons to draft a security policy for your system(s) and
>+network.
> 
> 
> <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.
>+ 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>
>- 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.
>+ 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 jepeordy.
> </li>
> <li>
>- Good guidelines and network documentation always pays off, no matter what
>+ 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>
>- 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!
>+ 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
>+ idetifying 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>
> 
> 
>-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.
>+The need for a good security policy is hopefully now more than clear.
> 
> 
> 
>-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.
>+The policy itself is a document, or several documents, that outline the network
>+and system features (such as what services are provided), acceptible 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).
> 
> 
> <note>
>@@ -286,11 +301,6 @@
> </note>
> 
> 
>-Most parts of a policy can be enforced directly in the operating system or 
>-through firewalls and others cannot.
>-
>-
>-
> A security policy should at least contain the following subjects:
> 
> 
>@@ -312,7 +322,7 @@
> <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>
>+ <li>Handling of confidential material when traveling</li>
> </ul>
> </li>
> <li>Handling of computer equipment when traveling</li>
>@@ -324,22 +334,24 @@
> </ul>
> 
> 
>-The policy for the IT-staff might be a bit different then the normal users.
>+Different users may require different levels or types of access, and as such
>+your policy may vary to accomodate them all.
> 
> 
> 
>-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.
>+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.
> 
> 
> 
>-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 
>+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="http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2196.html">Site Security
> Handbook</uri>.
> 
> 
>@@ -348,29 +360,28 @@
> </chapter>
> 
> <chapter>
>-<title>Tightening the security after/during installation</title>
>+<title>Tightening security during and after installation</title>
> <section>
> <title>USE flags</title>
> <body>
> 
> 
>-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.
>+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.
> 
> 
> </body>
> </section>
>-<section>
>-<title>GRUB password</title>
>+<section id = "passwording_GRUB">
>+<title>Password protecting GRUB</title>
> <body>
> 
> 
>-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.
>+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.
> 
> 
> <pre caption="/boot/grub/grub.conf">
>@@ -379,34 +390,34 @@
> </pre>
> 
> 
>-This will add the password <c>changeme</c> and if no password is entered simply 
>-use the default boot setting.
>+This will add the password <c>changeme</c>. If no password is entered at boot,
>+GRUB will simply use the default boot setting.
> 
> 
> 
>-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.
>+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 $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.
> 
> 
> 
>-Or this you can convert it directly in the grub shell:
>+You can encrypt your password directly at the GRUB shell:
> 
> 
> <pre caption="md5crypt in grub shell">
> #/sbin/grub
> 
>- GRUB version 0.92 (640K lower / 3072K upper memory)
>+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
>+ [ 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> md5crypt
> 
> Password: ********
>-<codenote>Typed changeme</codenote>
>+<codenote>Typed changeme at the prompt</codenote> 
> Encrypted: $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.
> 
> grub> quit
>@@ -417,55 +428,56 @@
> 
> 
> <pre caption="/boot/grub/grub.conf">
>-timeout 5
>+timeout 5 
> password --md5 $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.
> </pre>
> 
> 
>-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 
>+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>.
> 
> 
> </body>
> </section>
>-<section>
>-<title>LILO password</title>
>+<section id = "passwording_LILO">
>+<title>Password protecting LILO</title>
> <body>
> 
> 
>-LILO also supports two ways of handling passwords: global and per-image, both 
>-in clear text.
>+LILO also supports two ways of handling passwords: global and per-image, both in
>+clear text.
> 
> 
> 
>-The global one is set at the top of the configuration file:
>+The globalpassword is set at the top of the configuration file, and applies to
>+every boot image:
> 
> 
> <pre caption="/etc/lilo.conf">
>-password=changeme
>-restricted
>+password=changeme 
>+restricted 
> delay=3
> </pre>
> 
> 
>-Otherwise simply add it to an image.
>+The per-image pasword is set as below:
> 
> 
> <pre caption="/etc/lilo.conf">
>-image=/boot/bzImage
>- read-only
>- password=changeme
>+image=/boot/bzImage 
>+ read-only 
>+ password=changeme 
> restricted
> </pre>
> 
> 
>-If the <c>restricted</c> option is not entered, it will prompt for password, 
>+If the <c>restricted</c> option is not entered, it will prompt for a password
> every time.
> 
> 
> 
>-In order to store the new information in <path>lilo.conf</path> you need to run 
>+In order to store the new information in <path>lilo.conf</path>, you must run
> <c>/sbin/lilo</c>.
> 
> 
>@@ -476,17 +488,17 @@
> <body>
> 
> 
>-The <path>/etc/securetty</path> file allows you to specify which <c>tty</c> 
>+The <path>/etc/securetty</path> file allows you to specify which <c>tty</c>
> (terminal) devices root is allowed to login in from.
> 
> 
> 
>-We suggest that you comment out all lines except <c>vc/1</c>. This will ensure 
>+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.
> 
> 
> <note>
>-Users in the wheel group can still <c>su -</c> to become root on other TTYs.
>+Users in the group "wheel" can still <c>su -</c> to become root on other TTYs.
> </note>
> 
> <pre caption="/etc/securetty">
>@@ -503,13 +515,13 @@
> <body>
> 
> 
>-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.
>+Extra logging should be added to catch warnings or errors that might indicate
>+anongoing attack or a successful compromise. Attackers often scan or probe
>+before attacking.
> 
> 
> 
>-Its also vital that the log files are easy readable and manageable. Gentoo 
>+It's also vital that your log files are easily readable and manageable. Gentoo
> Linux lets you choose between 3 different loggers when installing.
> 
> 
>@@ -520,21 +532,21 @@
> <body>
> 
> 
>-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 
>+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 (logrotate is configured in
>+<path>/etc/logrotate.conf</path>). How often log rotation should be done depends
> on the system load.
> 
> 
> 
> 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.
>+logging server. To further enhance security you could add logging to two places.
> 
> 
> <pre caption="/etc/syslog.conf">
>-# /etc/syslog.conf Configuration file for syslogd.
>+# /etc/syslog.conf Configuration file for syslogd.
> #
> # For more information see syslog.conf(5)
> # manpage.
>@@ -612,14 +624,14 @@
> # *.=debug;*.=info;\
> # *.=notice;*.=warn |/dev/xconsole
> 
>-local2.* -/var/log/ppp.log
>+local2.* --/var/log/ppp.log
> </pre>
> 
> 
>-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>.
>+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>.
> 
> 
> </body>
>@@ -629,16 +641,16 @@
> <body>
> 
> 
>-<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.
>+<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.
> 
> 
> 
>-The standard configuration is basically enough. If you want to be notified by
>+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.
> 
> 
>@@ -646,7 +658,7 @@
> For postfix:
> 
> 
>-<pre caption = "/usr/local/sbin/mail_pwd_failures.sh for postfix">
>+<pre caption="/usr/local/sbin/mail_pwd_failures.sh for postfix">
> #! /bin/sh
> echo "$3" | mail -s "Warning (program : $2)" root
> </pre>
>@@ -655,7 +667,7 @@
> For qmail:
> 
> 
>-<pre caption = "/usr/local/sbin/mail_pwd_failures.sh for qmail">
>+<pre caption="/usr/local/sbin/mail_pwd_failures.sh for qmail">
> #!/bin/sh
> echo "To: root
> Subject:Failure (Warning: $2) 
>@@ -669,7 +681,7 @@
> 
> 
> 
>-Then uncomment the command line under Password failures in 
>+Then uncomment the command line under "Password failures" in 
> <path>/etc/metalog/metalog.conf</path> like:
> 
> 
>@@ -684,15 +696,15 @@
> <body>
> 
> 
>-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. 
>+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.
> 
> 
> 
>-A classic configuration file slightly modified.
>+Below is a classic configuration file slightly modified.
> 
> 
> <pre caption="/etc/syslog-ng/syslog-ng.conf">
>@@ -771,19 +783,52 @@
> </pre>
> 
> 
>-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.
>+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.
>+
>+
>+
>+And syslog-ng does have one other advantage: it does not have to run as root!
> 
> 
>+</body>
>+</section>
>+
>+<section>
>+<title>Log analysis with Logcheck</title>
>+<body>
>+
> 
>-And syslog-ng does have other advantages. It does not have to run as root!.
>+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.
>+
>+
>+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.
> 
> 
>+<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>
>+
> </body>
> </section>
>+
> </chapter>
> 
> <chapter>
>@@ -792,9 +837,9 @@
> <body>
> 
> 
>-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:
>+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:
> 
> 
> <ul>
>@@ -803,7 +848,7 @@
> file
> </li>
> <li>
>- <c>noexec</c> - Will prevent from executing files from this partition
>+ <c>noexec</c> - Will prevent execution of files from this partition
> </li>
> <li>
> <c>nodev</c> - Ignores devices
>@@ -811,10 +856,9 @@
> </ul>
> 
> 
>-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>.
>+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>.
> 
> 
> <pre caption="/etc/fstab">
>@@ -830,17 +874,17 @@
> </pre>
> 
> <warn>
>-Placing <path>/tmp</path> in <c>noexec</c> mode can prevent certain scripts 
>+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>.
>+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 
>+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 
>@@ -849,8 +893,9 @@
> 
> <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.
>+<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>
>@@ -859,37 +904,37 @@
> 
> <chapter>
> <title>User/group limitations</title>
>-<section>
>+<section id = "limits_conf">
> <title>/etc/security/limits.conf</title>
> <body>
> 
> 
>-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.
>+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.
> 
> 
> <pre caption="/etc/security/limits.conf">
>-* soft core 0
>-* hard core 0
>-* hard nproc 15
>-* hard rss 10000
>+* 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 hard core 100000
>+@dev soft nproc 20
>+@dev hard nproc 35
> @dev - maxlogins 10
> </pre>
> 
> 
>-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. 
>+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.
> 
> 
> <note>
> <path>/etc/security/limits.conf</path> is part of the PAM package and will 
>-only apply to packages that use PAM. 
>+only apply to packages that use PAM.
> </note>
> 
> </body>
>@@ -900,9 +945,9 @@
> 
> 
> <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:
>+<path>/etc/security/limits.conf</path>. The only difference is is the format and
>+that it only works on users or wild cards (not groups). Lets have a look at a
>+sample configuration:
> 
> 
> <pre caption="/etc/limits">
>@@ -911,9 +956,9 @@
> </pre>
> 
> 
>-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 
>+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.
> 
> 
>@@ -924,22 +969,28 @@
> <body>
> 
> <warn>
>-Make sure the file systems you are working with support quotas. ReiserFS is not 
>-one of them!
>+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>
> 
> 
>-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.
>+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->Quota support</c>. Apply the following
>+settings, rebuild the kernel and reboot using the new kernel.
> 
> 
> 
>-Start by installing quotas with <c>emerge quota</c>. Then modify your 
>+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.
>+partitions that you want to restrict disk usage on, like in the example below.
> 
> 
> <pre caption="/etc/fstab">
>@@ -955,8 +1006,8 @@
> </pre>
> 
> 
>-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 
>+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.
> 
> 
>@@ -968,7 +1019,7 @@
> </pre>
> 
> 
>-This step has to be done on every partition where quotas are enabled. After 
>+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.
> 
>@@ -978,8 +1029,8 @@
> </pre>
> 
> 
>-We will now configure the system to check the quotas once a 
>-week by adding the following line to <path>/etc/crontab</path>:
>+We will now configure the system to check the quotas once a week by adding the
>+following line to <path>/etc/crontab</path>:
> 
> 
> <pre caption="Adding quota check to crontab">
>@@ -987,10 +1038,10 @@
> </pre>
> 
> 
>-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.
>+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.
> 
> 
> <pre caption="Setting up quota's for user kn">
>@@ -1000,7 +1051,7 @@
> </pre>
> 
> 
>-For more detail read <c>man edquota</c> or the <uri 
>+For more detail read <c>man edquota</c> or the <uri
> link="http://www.tldp.org/HOWTO/mini/Quota.html">Quota mini howto</uri>.
> 
> 
>@@ -1011,11 +1062,11 @@
> <body>
> 
> 
>-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.
>+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.
> 
> 
> </body>
>@@ -1025,17 +1076,17 @@
> <body>
> 
> 
>-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.
>+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.
> 
> 
> <note>
>-These settings does not apply for root.
>+These settings do not apply for root.
> </note>
> 
> <pre caption="/etc/login.access">
>@@ -1044,20 +1095,19 @@
> </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.
>+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 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.
>+These settings does not apply to SSH, since SSH does not execute 
>+<c>/bin/login</c> by default. This can be enabled by setting <c>UseLogin yes</c>
>+in <path>/etc/ssh/sshd_config</path>.
> </note>
> 
> 
>-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.
>+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.
> 
> 
> </body>
>@@ -1071,12 +1121,12 @@
> <body>
> 
> 
>-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>.
>+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 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>.
> 
> 
> </body>
>@@ -1093,9 +1143,9 @@
> </pre>
> 
> 
>-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 
>+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.
> 
> 
>@@ -1106,21 +1156,20 @@
> <body>
> 
> 
>-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>.
>+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>qpkg -f</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>.
> 
> 
> <pre caption="Finding setuid files">
> # /usr/bin/find / -type f $ -perm -004000 -o -perm -002000 $ \ 
>- -exec ls -lg {} \; 2>/dev/null >suidfiles.txt
>+ -exec ls -lg {} \; 2>/dev/null >suidfiles.txt
> </pre>
> 
> 
>@@ -1151,21 +1200,23 @@
> </pre>
> 
> 
>-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.
>+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.
> 
> 
> 
>-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.
>+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.
> 
> 
> </body>
>@@ -1178,10 +1229,10 @@
> <body>
> 
> 
>-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.
>+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.
> 
> 
> <pre caption="Installing cracklib">
>@@ -1197,11 +1248,11 @@
> </pre>
> 
> 
>-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> 
>+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.
> 
> 
>@@ -1218,13 +1269,13 @@
> </pre>
> 
> 
>-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.
>+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.
> 
> 
> <pre caption="/etc/pam.d/other">
>@@ -1248,13 +1299,13 @@
> <body>
> 
> 
>-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.
>+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.
> 
> 
> <note>
>-The service should be executing tcpd in its server argument (in xinetd). See 
>-the chapter on xinetd for more information.
>+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">
>@@ -1267,20 +1318,20 @@
> </pre>
> 
> 
>-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.
>+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.
> 
> 
> 
>-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.
>+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.
> 
> 
> </body>
>@@ -1294,32 +1345,32 @@
> <body>
> 
> 
>-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.
>+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.
> 
> 
> 
>-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.
>+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.
> 
> 
> </body>
> </section>
> <section>
>-<title>/proc (kernel flags)</title>
>+<title>The proc filesystem</title>
> <body>
> 
> 
>-Many kernel parameters can be altered through the <path>/proc</path> file 
>-system or by using <c>sysctl</c>.
>+Many kernel parameters can be altered through the <path>/proc</path> file system
>+or by using <c>sysctl</c>.
> 
> 
> 
>-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.
>+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. 
> 
> 
> <pre caption="Drop ping packets">
>@@ -1327,13 +1378,14 @@
> </pre>
> 
> 
>-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.
>+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).
> 
> 
> <pre caption="Ignore broadcast pings">
>@@ -1341,11 +1393,11 @@
> </pre>
> 
> 
>-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.
>+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.
> 
> 
> <pre caption="Disable source routed packets">
>@@ -1353,11 +1405,11 @@
> </pre>
> 
> 
>-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.
>+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.
> 
> 
> <pre caption="Disable redirect acceptance">
>@@ -1365,8 +1417,8 @@
> </pre>
> 
> 
>-Disable ICMP redirect acceptance. ICMP redirects can be used to alter your 
>-routing tables, possibly to a bad end.
>+Do not accept ICMP redirect packets. ICMP redirects can be used to alter your
>+routing tables, possibly to a malicious end.
> 
> 
> <pre caption="Protect against bad error messages">
>@@ -1388,18 +1440,17 @@
> </note>
> 
> 
>-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.
>+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.
> 
> 
> <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.
>+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">
>@@ -1415,14 +1466,14 @@
> </pre>
> 
> 
>-Make sure that IP forwarding is turned off. We only want this for a multi-homed 
>-host.
>+Make sure that IP forwarding is turned off. We only want this for a
>+multi-homed host.
> 
> 
> 
>-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.
>+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.
> 
> 
> 
>@@ -1446,9 +1497,9 @@
> <body>
> 
> 
>-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
>+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.
> 
>@@ -1456,8 +1507,8 @@
> 
> 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>.
>+documentation available on the <uri link="http://www.grsecurity.net/">Grsecurity
>+homepage</uri>.
> 
> 
> </body>
>@@ -1467,15 +1518,14 @@
> <body>
> 
> 
>-<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.
>+<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.
> 
> 
> <warn>
>-The kerneli patch is currently not in a stable version for the latest kernel, 
>-so be careful when using it.
>+The kerneli patch is currently not in a stable version for the latest kernel, so
>+be careful when using it.
> </warn>
> 
> </body>
>@@ -1495,7 +1545,7 @@
> </ul>
> 
> 
>-And there is probably a lot more. 
>+And there are probably a lot more. 
> 
> 
> </body>
>@@ -1509,16 +1559,16 @@
> <body>
> 
> 
>-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:
>+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.
> 
> 
> 
>-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.
>+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.
> 
> 
> <pre caption="/etc/conf.d/apache">
>@@ -1541,14 +1591,14 @@
> 
> 
> 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 
>+<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>.
> 
> 
> 
>-One can find documentation at <uri>http://www.apache.org</uri>.
>+Documentation is available at <uri>http://www.apache.org</uri>.
> 
> 
> </body>
>@@ -1561,16 +1611,17 @@
> 
> 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
>+Consortium</uri>. The BIND 9 Administrator Reference Manual is also in
> the <path>doc/arm</path>.
> 
> 
> 
>-The newer BIND ebuilds support chrooting out of the box. After emerging <c>bind</c> follow these simple instructions:
>+The newer BIND ebuilds support chrooting out of the box. After
>+emerging <c>bind</c> follow these simple instructions:
> 
> <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 
>+<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>
>@@ -1581,10 +1632,10 @@
> <body>
> 
> 
>-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>.
>+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>.
> 
> 
> </body>
>@@ -1595,12 +1646,12 @@
> <body>
> 
> 
>-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.
>+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.
> 
> 
> </body>
>@@ -1610,14 +1661,17 @@
> <body>
> 
> 
>-If you only need local applications to access the <c>mysql</c> database uncomment the following line.
>+If you only need local applications to access the <c>mysql</c> database,
>+uncomment the following line.
> 
> <pre caption="Disable network access">
> skip-networking
> </pre>
> 
> 
>-Disable the command <c>LOAD DATA LOCAL INFILE</c>.
>+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.
> 
> 
> <pre caption="Disable LOAD DATA LOCAL INFILE in the [mysqld] section">
>@@ -1625,24 +1679,8 @@
> </pre>
> 
> 
>-The default <c>mysql</c> installation comes with an empty <c>root</c> password. 
>-
>-
>-<pre caption="Set root password">
>-/usr/local/mysql/bin/mysql -u root 
>-mysql> SET PASSWORD FOR root@localhost=PASSWORD('new_password');
>-</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>
>-
>-
>-Next, we must remove the sample database (test) and all accounts except the local <c>root</c> account. 
>+Next, we must remove the sample database (test) and all accounts except the
>+local <c>root</c> account.
> 
> 
> <pre caption="Removing sample database and all unnecessary users">
>@@ -1654,9 +1692,14 @@
> </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>
>@@ -1664,8 +1707,8 @@
> <body>
> 
> 
>-Proftpd has had several security problems, but they seem to have fixed most of 
>-them. Still apply some enhancements:
>+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:
> 
> 
> <pre caption="/etc/proftpd/proftpd.conf">
>@@ -1717,13 +1760,13 @@
> <body>
> 
> 
>-Pure-ftpd is an branch of the original trollftpd. Modified for security reasons 
>+Pure-ftpd is an branch of the original trollftpd, modified for security reasons
> and functionality by Frank Dennis.
> 
> 
> 
>-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 
>+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>. 
> 
> 
>@@ -1735,14 +1778,14 @@
> </pre>
> 
> 
>-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 
>+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>.
> 
> 
> <warn>
>-Do <e>not</e> use the <c>-w</c> or <c>-W</c> options! If you want to have a 
>+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>
> 
>@@ -1753,14 +1796,52 @@
> </body>
> </section>
> <section>
>+<title>Vsftpd</title>
>+<body>
>+
>+
>+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.
>+
>+
>+<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>
>+
>+
>+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.
>+
>+
>+</body>
>+</section>
>+<section>
> <title>Qmail</title>
> <body>
> 
> 
>-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!
>+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!
> 
> </body>
> </section>
>@@ -1769,8 +1850,8 @@
> <body>
> 
> 
>-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 
>+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.
> 
> 
>@@ -1789,7 +1870,7 @@
> #Enables user authentication 
> #(don't use the share mode)
> security = user
>- 
>+
> #Disallow privileged accounts
> invalid users = root @wheel
> 
>@@ -1806,14 +1887,14 @@
> </pre>
> 
> 
>-Make sure that permissions are set correct on every share and remember to read 
>+Make sure that permissions are set correct on every share and remember to read
> the <uri link="http://www.samba.org">documentation</uri>.
> 
> 
> 
>-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
>+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>.
> 
> 
> </body>
>@@ -1823,11 +1904,11 @@
> <body>
> 
> 
>-The only securing that OpenSSH needs is turning on a stronger authentication 
>-based on public key encryption. Too many sites (like 
>+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.
>+<uri>http://www.apache.org</uri>) have suffered unauthorized intrusion
>+due to password leaks or bad passwords.
> 
> 
> <pre caption="/etc/ssh/sshd_config">
>@@ -1862,8 +1943,8 @@
> </pre>
> 
> 
>-Now all that your users have to do, is create a key (on their machine they want 
>-to login from) with the following command
>+Now all that your users have to do is create a key (on the machine
>+they want to login from) with the following command:
> 
> 
> <pre caption="Create a DSA keypair">
>@@ -1871,7 +1952,7 @@
> </pre>
> 
> 
>-And type in a passphrase
>+And type in a passphrase.
> 
> 
> <pre caption="Output of ssh-keygen">
>@@ -1889,21 +1970,21 @@
> 
> 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 
>+<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.
> 
> 
> 
>-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).
>+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).
> 
> 
> 
>-For more information go to the <uri link="http://www.openssh.org">OpenSSH</uri> 
>-website.
>+For more information go to the <uri
>+link="http://www.openssh.org">OpenSSH</uri> website.
> 
> 
> </body>
>@@ -1913,18 +1994,18 @@
> <body>
> 
> 
>-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.
>+<c>xinetd</c> 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 provides extensive logging
>+capabilities, including server start time, remote host address, remote user
>+name, server run time, and actions requested.
> 
> 
> 
> 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:
>+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 still insist on using it,
>+here we will show you how to add some security to it:
> 
> 
> <pre caption="Install xinetd">
>@@ -1938,12 +2019,12 @@
> <pre caption="/etc/xinetd.conf">
> defaults
> {
>- only_from = localhost
>- instances = 10
>- log_type = SYSLOG authpriv info
>+ only_from = localhost
>+ instances = 10
>+ log_type = SYSLOG authpriv info
> log_on_success = HOST PID
> log_on_failure = HOST
>- cps = 25 30
>+ cps = 25 30
> }
> 
> # This will setup pserver (cvs) via xinetd with the following settings:
>@@ -1960,75 +2041,37 @@
> # 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
>+ 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
>+ disable = no
> }
> </pre>
> 
> 
>-For more information read the <c>man 5 xinetd.conf</c>.
>+For more information read <c>man 5 xinetd.conf</c>.
> 
> 
> </body>
> </section>
>-<section>
>-<title>Vsftpd</title>
>-<body>
>-
>-
>-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.
>-
>-
>-<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>
> 
>-
>-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.
>-
>-
>-</body>
>-</section>
> <section>
> <title>X</title>
> <body>
> 
> 
>-Per default XFree is configured to act as a Xserver. This can be dangerous 
>-since X uses unencrypted TCP connections and listens for xclients. 
>+By default XFree is configured to act as a Xserver. This can be dangerous since
>+X uses unencrypted TCP connections and listens for xclients.
> 
> 
> <impo>
>@@ -2037,22 +2080,24 @@
> 
> 
> 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>
>+<c>/usr/X11R6/bin/xhost</c> command with caution. This command allows clients
>+from other hosts to connect and use your display. This can be 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>
> 
> 
> <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.
>+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 your desktop. If you have to use it always
>+remeber to specify a host.
> </warn>
> 
> 
>-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. 
>+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.
> 
> 
> <pre caption="/usr/X11R6/bin/startx">
>@@ -2060,8 +2105,8 @@
> </pre>
> 
> 
>-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
>+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>:
> 
> 
>@@ -2101,30 +2146,40 @@
> <body>
> 
> 
>-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.
>+Chrooting a service is a way of limiting the service (or user) filesystem to a
>+subset of the real filesystem tree (<c>chroot</c> stands for "change root",
>+since it changes the filesystem root to an arbitrary point on the
>+filesystem). And by running the service as another user
>+(ie. <c>nobody</c>, <c>apache</c>, <c>named</c>), an attacker can only access
>+files and execute commands with the permissions for this user. This means that
>+an attacker cannot gain root access even if the services has a security flaw.
> 
> 
> 
>-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).
>+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
>+will have to figure out how to create your own chroot.
>+
>+
>+
>+
>+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).
> 
> 
> 
>-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):
>+First we will create the <path>/chroot</path> directory with <c>mkdir
>+chroot</c>. Now we must find what dynamic libraries <c>bash</c> is compiled
>+with.
> 
> 
>+<note>
>+If <c>bash</c> is compiled with the <c>static</c> USE flag this step is not
>+necessary.
>+</note>
>+
> 
>-The following command will create a list of libraries used by <c>bash</c>. 
>+The following command will create a list of libraries used by <c>bash</c>.
> 
> 
> <pre caption="Get listing of used libraries">
>@@ -2146,59 +2201,62 @@
> </pre>
> 
> 
>-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 
>+Next copy the files used by <c>bash</c> (<path>/lib</path>) to the
>+chrooted <path>lib</path> directory, and copy the <c>bash</c> executable 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>, you were
>+successful. Otherwise it will tell you what a file is missing. Some shared
> libraries depend on each other.
> 
> 
> 
>-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.
>+You will notice that inside the <c>chroot</c> nothing works
>+except <c>echo</c>. This is because we have no commands in our chroot
>+environment other than <c>bash</c>, and <c>echo</c> is built in to <c>bash</c>
> 
> 
> 
>-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> 
>+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 and 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 bash</c> 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 have nothing to do
>+with the service), <path>/dev/zero</path>, <path>/dev/log</path>
> and <path>/dev/random</path>.
> 
> 
>+<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>
>+<title>User Mode Linux</title>
> <body>
> 
> 
>-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.
>+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.
> 
> 
> 
>-Example of virtual servers:
>+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>.
> 
>-
>-<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>
>@@ -2211,16 +2269,16 @@
> 
> 
> People often think that a firewall provides the ultimate security, but they 
>-are wrong. In most cases a misconfigured firewall gives worse security than 
>+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 is just as likely 
>+treated the same way as any other piece of software, because it is just as likely 
> to contain bugs.
> 
> 
> 
>-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.
>+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.
> 
> 
> 
>@@ -2243,8 +2301,8 @@
> </ul>
> 
> 
>-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.
>+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.
> 
> 
> </body>
>@@ -2254,11 +2312,11 @@
> <body>
> 
> 
>-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:
>+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:
> 
> 
> <ul>
>@@ -2269,8 +2327,8 @@
> </ul>
> 
> 
>-Basically filtering is based on all data within the header of a packet and not 
>-its content.
>+In other words, this filtering is based on all the data within the header of a
>+packet and not its content.
> 
> 
> 
>@@ -2279,13 +2337,12 @@
> 
> <ul>
> <li>
>- Address information in a packet can potentially be a bogus IP address or as 
>- we say <e>spoofed</e> by the sender
>+ 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
>+ 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>
>@@ -2314,6 +2371,10 @@
> </li>
> <li><uri link="http://www.smoothwall.org">SmoothWall</uri></li>
> </ul>
>+
>+<note>
>+It is recommended that you use iptables. Ipchains is obsoleted. 
>+</note>
> 
> </body>
> </section>
>@@ -2322,11 +2383,11 @@
> <body>
> 
> 
>-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:
>+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:
> 
> 
> <ul>
>@@ -2339,7 +2400,7 @@
> </ul>
> 
> 
>-All traffic is validated, monitored and unwanted traffic can be dropped.
>+All traffic is validated and monitored, and unwanted traffic can be dropped.
> 
> 
> 
>@@ -2348,8 +2409,8 @@
> 
> <ul>
> <li>
>- Operates at the Transport Layer and may require substantial modification of 
>- the programming which normally provides transport functions
>+ Operates at the Transport Layer and may require substantial modification of the
>+ programs that normally provide transport functions.
> </li>
> </ul>
> 
>@@ -2360,16 +2421,16 @@
> <body>
> 
> 
>-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 
>+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:
> 
> 
> <ul>
> <li>Allow or disallow based on source/destination IP address</li>
>-<li>Based on the packets content</li>
>+<li>Based on the packet's content</li>
> <li>Limiting file access based on file type or extension</li>
> </ul>
> 
>@@ -2380,7 +2441,7 @@
> <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>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>
>@@ -2394,9 +2455,9 @@
> </ul>
> 
> 
>-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.
>+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.
> 
> 
> 
>@@ -2414,107 +2475,118 @@
> <body>
> 
> 
>-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. 
>+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.
> 
> 
> 
>-Now test that it works by running <c>iptables -L</c>. If it fails something is 
>+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.
> 
> 
> 
>-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.
>+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.
> 
> 
> 
>-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.
>+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.
> 
> 
> 
>-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 
>+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.
> 
> 
> 
>-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.
>+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 portscan in which the scanner sends packets
>+with flags that are far less likely to be logged by a firewall than ordinary SYN
>+packets.
> 
> 
> 
>-Iptables provides several other features like NAT (Network Address Translation) 
>-and rate limiting. Rate limiting is extremely useful when trying to prevent 
>+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.
> 
> 
> 
>-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.
>+A TCP connection is established by a "three-way handshake". When establishing a
>+TCP connection, the client 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.
> 
> 
> 
>-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.
>+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, thereby filling up the queue of half-open connections and preventing
>+other clients from establishing legitimate connections with the server.
> 
> 
> 
>-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.
>+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 limit the SYN
>+flood's effect on our resources.
> 
> 
>+<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>
>+
> 
> Now some practical stuff!
> 
> 
> 
>-When iptables is loaded in the kernel it has 5 hooks where you can place your 
>+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.
>+<c>PREROUTING</c> and <c>POSTROUTING</c>. Each of these is called a "chain" and
>+consists of a list of rules. Each rule contains a packet header and an action to
>+take for packets with matching headers. If the rule does not match the packet
>+the next rule in the chain is consulted.
> 
> 
> 
>-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.
>+You can place rules directly in the 5 main chains or create new chains and add
>+them as a rule to an existing chain. Iptables supports the following options:
> 
> 
> <table>
>@@ -2544,7 +2616,7 @@
> </tr>
> <tr>
> <ti>-F</ti>
>- <ti>Delete all rules in chain or all chains</ti>
>+ <ti>Delete all rules in chain or all chains</ti>
> </tr>
> <tr>
> <ti>-Z</ti>
>@@ -2629,8 +2701,8 @@
> </table>
> 
> 
>-First we will try to block all ICMP packets to our machine, just to get 
>-familiar with iptables.
>+First we will try to block all ICMP packets to our machine, just to get familiar
>+with iptables.
> 
> 
> <pre caption="Block all ICMP packets">
>@@ -2638,18 +2710,25 @@
> </pre>
> 
> 
>-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.
>+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.
> 
> 
>+<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>
>+
> 
>-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.
>+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.
> 
> 
> <pre caption="Flush all rules">
>@@ -2657,9 +2736,9 @@
> </pre>
> 
> 
>-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:
>+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:
> 
> 
> <pre caption="Accept packets that originate from an already established connection">
>@@ -2667,13 +2746,13 @@
> </pre>
> 
> 
>-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: 
>+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:
> 
> 
> <table>
>@@ -2707,12 +2786,12 @@
> </tr>
> <tr>
> <ti>unclean</ti>
>- <ti>Various random sanity checks on packets</ti><ti></ti>
>+ <ti>Various random sanity checks on packets</ti><ti/>
> </tr>
> </table>
> 
> 
>-Lets try to create a user defined chain and apply it to one of the existing 
>+Let's try to create a user defined chain and apply it to one of the existing
> chains:
> 
> 
>@@ -2729,28 +2808,29 @@
> </pre>
> 
> 
>-By applying the rule to the input chain we get the policy: All outgoing packets 
>-are allowed and all incoming packets are dropped.
>+By applying the rule to the input chain we get the policy that all outgoing
>+packets are allowed and all incoming packets are dropped.
> 
> 
> 
>-One can find documentation at <uri 
>+One can find documentation at <uri
> link="http://www.iptables.org/documentation/index.html#HOWTO">Netfilter/iptables documentation</uri>.
> 
> 
> 
>-Lets see a full blown example. In this case my firewall/gateway policy states:
>+Lets see a full blown example. In this case my firewall/gateway policy states
>+that:
> 
> 
> <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)
>+ 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.
>+ ICMP traffic can contain malicious payloads 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>
>@@ -2968,26 +3048,26 @@
> </pre>
> 
> 
>-Free advice when creating a firewall:
>+Some advice when creating a firewall:
> 
> 
> <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))
>+Know how each protocol works (read the relevent <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
>+Keep in mind that a firewall is just another piece of software running as root.
> </li>
> <li>Test your firewall</li>
> </ol>
> 
> 
>-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 
>+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.
> 
> 
>@@ -2998,18 +3078,18 @@
> <body>
> 
> 
>-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.
>+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 username, MIME type, and port number (protocol). I
>+probably forgot some features, but it can be hard to cover the entire list right
>+here.
> 
> 
> 
>-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.
>+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.
> 
> 
> 
>@@ -3018,17 +3098,20 @@
> 
> <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
>+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>
>- Download is not allowed (.exe, .com, .arj, .zip, .asf, .avi, .mpg, .mpeg etc)
>+We do not like banners, so they are filtered and replaced with a transparent gif
>+(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!)
>+All other connections to and from the Internet are denied.
> </li>
>-<li>All other connections to and from the Internet are not allowed</li>
> </ul>
> 
> 
>@@ -3104,8 +3187,9 @@
> </pre>
> 
> 
>-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.
>+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.
> 
> 
> <pre caption="/etc/squid/files.acl">
>@@ -3129,13 +3213,13 @@
> </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
>+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>
> 
> 
>-Next we add the regular expressions for identifying banners. You will probably 
>-be a lot more creative than me:
>+Next we add the regular expressions for identifying banners. You will probably
>+be a lot more creative than I:
> 
> 
> <pre caption="/etc/squid/banner-ads.acl">
>@@ -3191,22 +3275,22 @@
> </note>
> 
> 
>-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.
>+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.
> 
> 
> 
>-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.
>+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.
> 
> 
> 
>-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 
>+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.
> 
> 
>@@ -3215,8 +3299,8 @@
> </note>
> 
> 
>-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 
>+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:
> 
> 
>@@ -3225,10 +3309,17 @@
> # iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to proxyhost:3128
> </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>
>+<title>Lessons learned</title>
> <body>
> 
> 
>@@ -3237,27 +3328,25 @@
> 
> <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.
>+A firewall can be a risk in itself. A badly configured firewall is worse than
>+not having one at all.
> </li>
>-<li>How to prevent SYN attack</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>
>- Filtering HTTP traffic by removing offensive pictures and downloads of 
>- viruses
>+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
>+Combining packet filters and application gateways provides better control.
> </li>
> </ol>
> 
> 
>-Now, if you <e>really</e> need to, go create a firewall that matches your needs.
>+Now, if you <e>really</e> need to, go create a firewall that matches
>+your needs.
> 
> 
> </body>
>@@ -3271,14 +3360,21 @@
> <body>
> 
> 
>-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.
>+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.
> 
> 
> 
>-The configuration file is based on regular expressions, macros and rules for 
>-files and directories. We have the following macros: 
>+The configuration file is based on regular expressions, macros and rules for
>+files and directories. We have the following macros:
> 
> 
> <table>
>@@ -3319,22 +3415,23 @@
> </tr>
> <tr>
> <ti>endif</ti>
>- <ti>
>- Endif must be used after any of the above macros except define and undef
>- </ti>
>- <ti>@@endif</ti>
>+<ti>
>+Endif must be used after any of the above macros except define and undef
>+</ti>
>+<ti>@@endif</ti>
> </tr>
> </table>
> 
> 
>-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.
>+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.
> 
> 
> 
>-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.
>+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).
> 
> 
> <table>
>@@ -3421,31 +3518,31 @@
> </table>
> 
> 
>-And if AIDE is compiled with mhash support it does have a few other features:
>+And if AIDE is compiled with mhash support it supports a few other features:
> 
> 
> <table>
> <tr>
>- <th>Flag</th>
>- <th>Description</th>
>+<th>Flag</th>
>+<th>Description</th>
> </tr>
> <tr>
>- <ti>haval</ti>
>- <ti>haval checksum</ti>
>+<ti>haval</ti>
>+<ti>haval checksum</ti>
> </tr>
> <tr>
>- <ti>gost</ti>
>- <ti>gost checksum</ti>
>+<ti>gost</ti>
>+<ti>gost checksum</ti>
> </tr>
> <tr>
>- <ti>crc32</ti>
>- <ti>crc32 checksum</ti>
>+<ti>crc32</ti>
>+<ti>crc32 checksum</ti>
> </tr>
> </table>
> 
> 
> Now you can create you own rules based on the above flags by combining them 
>-like:
>+like this:
> 
> 
> <pre caption="Create a ruleset for AIDE">
>@@ -3454,29 +3551,29 @@
> </pre>
> 
> 
>-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.
>+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.
> 
> 
> <table>
> <tr>
>- <th>Flag</th>
>- <th>Description</th>
>+<th>Flag</th>
>+<th>Description</th>
> </tr>
> <tr>
>- <ti>!</ti>
>- <ti>Don't add this file or directory.</ti>
>+<ti>!</ti>
>+<ti>Don't add this file or directory.</ti>
> </tr>
> <tr>
>- <ti>=</ti>
>- <ti>Add this directory, but not recursive.</ti>
>+<ti>=</ti>
>+<ti>Add this directory, but not recursively.</ti>
> </tr>
> </table>
> 
> 
>-So lets watch a full blown example
>+So lets watch a full blown example:
> 
> 
> <pre caption="/etc/aide/aide.conf">
>@@ -3521,54 +3618,55 @@
> </pre>
> 
> 
>-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.
>+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.
> 
> 
> 
>-After editing the configuration you should create your db file by executing 
>+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.
> 
> 
> <note>
>-Depending on your cpu, disk access and the flags you have set on files, it can 
>-take some time.
>+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
>+0 3 * * * /usr/bin/aide -u
> </pre>
> 
> <note>
>-Remember to setup so you get roots mail. Otherwise you will never know what 
>-aide reports.
>+Remember to set an alias so you get roots mail. Otherwise you will never know
>+what AIDE reports.
> </note>
> 
> 
>-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!
>+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!
> 
> 
> 
>-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.
>+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.
> 
> 
> 
>-One can find information at the <uri 
>+One can find information at the <uri
> link="http://www.cs.tut.fi/~rammer/aide.html">AIDE</uri> projectpage.
> 
> 
>@@ -3579,7 +3677,7 @@
> <body>
> 
> 
>-Snort is a Network Intrusion Detection System (NIDS). To install and configure 
>+Snort is a Network Intrusion Detection System (NIDS). To install and configure
> it use the following examples.
> 
> 
>@@ -3694,11 +3792,43 @@
> </pre>
> 
> 
>-More information is at the <uri link="http://www.snort.org">Snort</uri> website.
>+More information is at the <uri
>+link="http://www.snort.org">Snort</uri> website.
>+
>+
>+</body>
>+</section>
>+
>+<section>
>+<title>Detecting malware with chkrootkit</title>
>+
>+<body>
>+
>+
>+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.
>+
>+
>+
>+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:
> 
> 
>+<pre caption="Schedule chkrootkit as a cronjob">
>+0 3 * * * /usr/sbin/chkrootkit
>+</pre>
>+
> </body>
> </section>
>+
> </chapter>
> 
> <chapter>
>@@ -3707,15 +3837,17 @@
> <body>
> 
> 
>-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. 
>+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.
> 
> 
> 
>-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.
>+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.
> 
> 
> <pre caption="Example output of glsa-check -l">
>@@ -3723,7 +3855,7 @@
> </pre>
> 
> <warn>
>-The <c>glsa-check</c> is still experimental so if security really is your top 
>+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>
> 
>@@ -3733,20 +3865,21 @@
> 
> 
> 
>-Some people still prefer to use <c>emerge packagename</c> instead of 
>+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>.
> 
> 
> 
> 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>.
>+<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>.
> 
> 
> 
>-Another great security resource is the <uri 
>-link="http://www.securityfocus.com/archive/1">Bugtraq mailinglist</uri>.
>+Another great security resource is the <uri
>+link="http://www.securityfocus.com/archive/1">Bugtraq
>+mailinglist</uri>.
> 
> 
> </body>

Actions: View | Diff

Attachments on bug 52393: 32269 | 32784 | 32785 | 32787 | 34650