<title>Enhancements for Next Release of this Guide:</title>

<title>Enhancements for future releases of this Guide:</title>

<title>/etc/make.conf</title>

<title>USE flags</title>

The make.conf file contains all the options and extra libraries that you want to have support for when building ebuilds. In this file you must make sure that if the ebuild supports any security library like PAM (Pluggable Authentication Modules), tcp wrappers or SSL (Secure Socket Layer) it will add support for it. Your global USE variable should contain pam, tcpd and ssl.

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 pam (Pluggable Authentication Modules), tcp (TCP wrappers) and ssl (Secure Socket Layer). These are all in the default USE flags.

</p>

<p>

So add something like this:

</p>

It can log by program name, urgency, program name,by facility (like syslogd) and comes with regular expression matching and it can launch external scripts when specific patterns are found. It is very good for taking action when needed.

<p>

It can log by program name or by facility (like syslogd) and comes with regular expression matching and execution of commands. Very good for taking action when needed.

This is basically a standard configuration with a few modifications, like a minimum logging level at 7, which means that everything will be logged.

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

pwdfail.sh for postfix.

For postfix:

<pre caption = "postfix' pwdfail.sh">

<pre caption = "/usr/local/sbin/mail_pwd_failures.sh for postfix">

pwdfail.sh for qmail.

For qmail:

<pre caption = "qmail's pwdfail.sh">

<pre caption = "/user/local/sbin/mail_pwd_failures.sh for qmail">

More information can be found in the <uri link="http://metalog.sourceforge.net">metalog</uri> website.

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

</p>

<p>

Then uncomment the command line under Password failures in metalog.conf like:

Here we set the default settings and a specific setting for the user <e>kn</e>. Limits are part of the shadow package and only applies for the shadow login program. It is not necessary to set any limitations in this file, if you have set the PAM setting in your make.conf and configured PAM properly.

Here we set the default settings and a specific setting for the user <e>kn</e>. Limits are part of the shadow package and only apply to the shadow login program. It is not necessary to set any limitations in this file if you haven't disable pam in your <path>make.conf</path> and configured PAM properly.

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

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

If you have added ssl to 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 ssl 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.

People often think that a firewall is the ultimate security, but they are wrong. In most cases a mis configured firewall gives worse security than not having one at all. A firewall is also a piece of software and should be treated the same way as any other service, because is just as likely to have bugs (security holes).

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

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.

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.

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 it's destination. Every packet contains information on how and where is should be delivered. And these information is exactly what a packing filtering firewall uses. Filtering is based on:

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:

<li>Allow or disallow packets according to protocol.</li>

<li>Allow or disallow packets based on protocol.</li>

<li>Allow or disallow packets according to flags within a specific protocol</li>

<li>Allow or disallow packets based on flags within a specific protocol.</li>

Basically filtering on all data within the header of a packet and not it's content.

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

<li>Address information in a packet can potentially be a bogus address or as we say <e>spoofed</e> by the sender</li>

<li>Address information in a packet can potentially be a bogus IP address or as we say <e>spoofed</e> by the sender.</li>

<li>Data or requests within the allowed packet may contain unwanted data that the attacker can use to exploit known bugs in the services on or behind the firewall</li>

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

<li>Usually single point of failure.</li>

<li>Simple and easy to implement</li>

<li>Simple and easy to implement.</li>

<li>Can give warnings on a possible attack before they happened (by detecting portscans)</li>

<li>Can give warnings of a possible attack before it happens (ie. by detecting portscans).</li>

<li>Good for stopping SYN attacks</li>

<li>Good for stopping SYN attacks.</li>

Or circuit level gateways is a firewall that validates connections before allowing data to be exchanged. This means that is simply does not allow or deny packets based based on the header of the packet but determines whether the connection between both ends is valid according to configurable rules before it opens a session and allows data to and from the allowed source address. Filtering is based on:

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:

<li>Source/destination IP address</li>

<li>Source/destination IP address.</li>

<li>Source/destination port</li>

<li>Source/destination port.</li>

<li>A period of time</li>

<li>A period of time.</li>

<li>Protocol</li>

<li>Protocol.</li>

<li>User</li>

<li>User.</li>

<li>Password</li>

<li>Password.</li>

All traffic is validated, monitored and traffic without is disallowed.

All traffic is validated, monitored and unwanted traffic can be dropped.

The application level gateway is a proxy for application, exchanging data with remote systems on behalf of the clients. It is kept away from the public safely behind a DMZ or firewall with no connection from the outside. Filtering is based on:

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:

<li>Allow or disallow based on source/destination IP address</li>

<li>Allow or disallow based on source/destination IP address.</li>

<li>Based on the packets content</li>

<li>Based on the packets content.</li>

<li>Can even alter the packet content on the fly</li>

<li>Limiting file access based on file type or extension.</li>

<li>Limiting file access based on file type or extension</li>

<li>Can cache files, increasing network performance</li>

<li>Can cache files, increasing network performance.</li>

<li>Detailed logging of all connections</li>

<li>Detailed logging of all connections.</li>

<li>Scales perfectly (some proxy servers can "share" the cached data)</li>

<li>Scales perfectly (some proxy servers can "share" the cached data).</li>

<li>No direct access from the outside</li>

<li>No direct access from the outside.</li>

<li>Can even alter the packet content on the fly.</li>

<li>The setup is complex</li>

<li>Configuration is complex.</li>

Application gateways are considered to be the most secure solution since it does not have to run as root and is not public to the Internet.

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.

In order to get iptables working, it has to be enabled in the kernel. I have added them as modules (the iptables command will load them as they are needed) and recompiled my kernel. After you have compiled it (or while compiling the kernel) you have to add the iptables commands. Just <c>emerge iptables</c> and it should work.

In order to get <c>iptables</c> 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 <c>iptables</c> look 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. Just <c>emerge iptables</c> and it should work.

Iptables is a stateful packet filter which means that it provides greater control and greater security than ipchains (Linux version 2.2) which is not stateful. You are properly asking yourself what is the stateful part? and what is the difference?

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 <c>iptables</c> is able to perform stateful packet filtering. With stateful packet filtering it is possible to keep track of each established TCP connection.

We all know that a TCP connection consists of a series of packets. Each packet contains information about source IP address, the destination IP address and a sequence number so the packets can be reassembled. And we all know that TCP is connection-oriented and UDP is connectionless right? these are the states that is stored .. now you are probably asking yourself and so what? Well I'm getting to that.

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.

Now imagine that you have a stateless firewall (ipchains) and do not want to allow external computers to originate a connection to your internal services but how can the firewall determine whether a packet is part of an ongoing connection or not? A stateless firewall cannot distinguish between an existing connection and one that is part of a new connection by looking at the SYN flag!. 

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.

Lets say an attacker is sending hand crafted packets (a packet created by the attacker) where he alters the SYN flags or any other flags. This is quite often what attackers do. Send packets right through the firewall altering routing tables or compromising services running on the firewall which are supposed to be safe behind a filter. A stateful firewall will keep track of all connections and can thus detect if a received packet does not belong to an existing connection. When a packet not belonging to any existing connection is found it is marked as invalid and can be discarded. This will also stop the possibility of "stealth scans" since the connection was invalid.

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.

I could probably find a dozen other reasons but I think you got the picture .. simple rules result in a smaller firewall configuration that is easier to maintain.

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.

Iptables provides several other features like rate limiting. This features is extremely useful when trying to prevent certain DoS (Denial of Service) attacks like a SYN attack. Now what is a SYN attack?

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.

Again .. when creating a connection with TCP it uses three-way handshake to establish the connection like this:

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 attack is when it only sends a SYN packet (header only contains SYN flag) and does not continue sending the last two packets to establish the connection. A SYN packet does not require a valid source IP address because it does not need a reply. So the connection will hang until it times out. Now if the attacker sends a lot of SYN packets with a bogus source IP address, the computer waits for the response, which never comes. Depending on the timeout settings in your system, this connection could stay open for 30-60 seconds (or longer). When the connection limit table is completely occupied and unable to communicate with anyone.

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

</p>

<p>

This is where the rate limit becomes handy. It is possible to limit the number of SYN packets from a single source but using the <c>-m limit --limit 1/s</c>. This will limit the SYN packets to one per source and therefor restricting the SYN flood on our resources.

When iptables is loaded in the kernel it has 5 hooks where you can place your rules. They are called INPUT, OUTPUT FORWARD, PREROUTING and POSTROUTING. These lists are called chains because they work by added a rules and checks the rules one at the time as they where added. If one rule deny a packet it will be dropped and does not continue down the chain.

When <c>iptables</c> is loaded in the kernel it has 5 hooks where you can place your rules. They are called INPUT, OUTPUT, FORWARD, PREROUTING and POSTROUTING. 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.

You can place rules directly to the 5 main chains or create chains and add them to as a rule to an existing chain. Lets see how this is done

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. <c>iptables</c> supports the following options.

First we will try to block all ICMP packages to our machine, just to get familiar with iptables.

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

First we specify the chain it should be appended to. Next to specify the protocol and then the rule. The rule can be a ACCEPT, DROP, REJECT, LOG, QUEUE, MASQUERADE, a loaded module or a user defined chain. In this case we use DROP which will drop the packet without responding to the client.

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 ACCEPT, DROP, REJECT, LOG, QUEUE, MASQUERADE. In this case we use DROP which will drop the packet without responding to the client.

Now try <c>ping localhost</c>. It will not be able to get any response since it is blocking the entire ICMP protocol incoming to our machine. It will not be able to ping other machines either since it is not allowed to get the ICMP packets returning from the host. Now flush the chain to get ICMP flowing again.

Now try <c>ping localhost</c>. It will not be able to get any response since <c>iptables</c> 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 lets look at the stateful part 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 <c>iptables</c>. If we wanted to have a stateful inspection of packets incoming on eth0 we could enable it by issuing:

This will accept any packet already established 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 part in iptables by loading the extension state. If you wanted connection from the outside 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. This enables the stateful packet filtering in <c>iptables</c> 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: 

<pre caption="Creating a userdefined chain">

<pre caption="Creating a user defined chain">

  <li>Connections to the firewall is only allowed through SSH (port 22)</li>

  <li>Connections to the firewall are only allowed through SSH (port 22).</li>

  <li>The local network should have access to HTTP, HTTPS and SSH (DNS should also be allowed)</li>

  <li>The local network should have access to HTTP, HTTPS and SSH (DNS should also be allowed).</li>

  <li>Port scan should be detected and logged</li>

  <li>Port scans should be detected and logged.</li>

  <li>SYN attack should be avoided</li>

  <li>SYN attacks should be avoided.</li>

  <li>All other traffic should be dropped and logged</li>

  <li>All other traffic should be dropped and logged.</li>

  <li>Create your firewall policy before implementing it</li>

  <li>Create your firewall policy before implementing it.</li>

  <li>Keep it simple</li>

  <li>Keep it simple.</li>

  <li>Know how the protocol works (read the <uri link="http://www.ietf.org/">RFC (Request For Comments)</uri>)</li>

  <li>Know how the protocol works (read the <uri link="http://www.ietf.org/">RFC (Request For Comments)</uri>).</li>

  <li>Keep in mind that a firewall it just another piece of software running as root</li>

  <li>Keep in mind that a firewall it just another piece of software running as root.</li>

  <li>Test your firewall</li>

  <li>Test your firewall.</li>

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.

If you think that <c>iptables</c> 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 <c>iptables</c> to generate firewall rules, but concentrates on rules and not specific protocols.

Squid is a very powerful proxy server and it can filter traffic based on: time, regular expression 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 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.

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 <c>not</c> 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.

  <li>Surfing (HTTP/HTTPS) is allowed during work hours (mon-fri 8-17 and sat 8-13) if they are here late they should work, not surf</li>

  <li>Surfing (HTTP/HTTPS) is allowed during work hours (mon-fri 8-17 and sat 8-13) if they are here late they should work, not surf.</li>

  <li>Download 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).</li>

  <li>We don't 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!).</li>

  <li>Every other connection to and from the Internet is not allowed</li>

  <li>All other connections to and from the Internet are not allowed.</li>

And the last part. We want this file to be displayed when it removes a banner. It is basically a half html file with a 4x4 transparent gif image.

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

Don't close the <HTML> <BODY> tags. This will be done by squid.

Do not close the <HTML> <BODY> tags. This will be done by squid.

As you can see, squid has a lot of possibilities and it is very effective in 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 could access it from the outside. We still need to be concerned on attack from the inside.

But combining the packet filter (<c>iptables</c>) 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.

Now you have to add the proxy server into the settings of your clients browsers. The gateway will prevent the users from having any contact with the outside unless they use the proxy.

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.

It can also be done transparently by using iptables to forward all traffic out to a squid proxy. This can be done by adding a forwarding/prerouting rule on the gateway:

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

  <li>A firewall can be a risk itself. A badly configured firewall is worse than not having one at all.</li>

  <li>A firewall can be a risk in itself. A badly configured firewall is worse than not having one at all.</li>

  <li>That IP traffic does not always contain legitimate data. For an example ICMP packets with payload.</li>

  <li>That IP traffic does not always contain legitimate data ie. ICMP packets can contain payload.</li>

  <li>Combining packet filters and application gateways gives a better control.</li>

  <li>Combining packet filters and application gateways provides better control.</li>