Linux kernels as of version 2.3.15 support a new framework designed for packet filtering called “netfilter” which must be compiled into the kernel. This is done by selecting “Networking options -->” which brings you to the “Networking options” page. Enabling the option “Network packet filtering” sets CONFIG_NETFILTER to “Y” and adds the “IP: Netfilter Configuration -->” option to the page. Selecting this option takes you to the “IP: Netfilter Configuration” page. You should at least enable the “Connection tracking (CONFIG_IP_NF_CONNTRACK)” and the “IP tables support (CONFIG_IP_NF_IPTABLES)”. The latter adds a lot of options from which you should at least enable “Connection state match support (CONFIG_IP_NF_MATCH_STATE)”, “Packet Filtering (CONFIG_IP_NF_FILTER)” and “Full NAT (CONFIG_IP_NF_NAT)”.

The user space tool iptables is used to tell the “netfilter” code in the kernel which packets to filter.

As the figure above shows, netfilter supports five different hooks in the protocol stack. Imagine for a moment that packets pass through a tube. A hook is a part in the tube, where an additional piece of tube can be inserted. In this piece of tube works a little man who examines and changes when needed, every passing packet based on his job description, the so called “rules”. The little man reports to his boss, netfilter, what to do with the packet.

By default five chains and three tables are supported. As the figure below shows, certain chains are only valid for certain tables.

The filter table is used for filtering packets. The filter table contains three chains. The INPUT chain is used for all packets that are for the firewall. The FORWARD chain is used for all packets that come from outside the firewall and are destined for another machine. The OUTPUT chain is used for all packets generated by the firewall.

The nat table is used for Network Address Translation. The nat table contains three chains. The PREROUTING chain is the first used to alter packets. The OUTPUT chain is used to alter packets generated by the firewall. The POSTROUTING chain is the last chain where packets can be altered as they leave the firewall.

The mangle table is used to mangle packets. We can change several things but we can't do masquerading or network address translation here. The mangle table contains two chains. The PREROUTING chain is the first chain alter packets. The OUTPUT chain is used to alter packets generated by the firewall.

Firewalls that are able to do connection tracking are called Stateful Firewalls. What it comes down to is that connections are tracked by remembering what (type of) packets have been received and sent.

Incoming packets in response to a ping, for instance, can be accepted by the firewall because the firewall knows that we've caused this ourselves by doing the ping in the first place.

The iptables option used for connection tracking is the “--state” option.

Conntrack hooks in at PREROUTING, FORWARD, OUTPUT and POSTROUTING.

Putting what we've discussed so far into one picture:

We all remember The Firm's network from the previous section. Let's visit it again. The picture below shows The Firm's network and the possible combinations of traffic initiation/destination.

We are running a DNS on the Firewall that needs to be able to consult other DNSes on the Internet (which use the UDP protocol and listen to PORT 53). We want to be able to use ssh (which uses the TCP protocol and port 22) to connect to other systems on the Internet. We are participating in a distributed.net project RC564 cracking and are running a proxy server on the Firewall (which uses the TCP protocol and PORT 2064 to communicate with the keyserver). We want to be able to ping hosts on the Internet (ping uses the ICMP protocol and message type “ping”). The Firewall communicates with the Internet through interface eth1. Taking all this into consideration, the iptables commands we need are:

iptables -t filter -A OUTPUT -o eth1 -p udp  --destination-port dns        \
-m state --state NEW -j ACCEPT  
iptables -t filter -A OUTPUT -o eth1 -p tcp  --destination-port ssh        \
-m state --state NEW -j ACCEPT
iptables -t filter -A OUTPUT -o eth1 -p tcp  --destination-port 2064       \
-m state --state NEW -j ACCEPT
iptables -t filter -A OUTPUT -o eth1 -p icmp --icmp-type ping              \
-m state --state NEW -j ACCEPT
          

These four iptables commands tell the firewall to allow outgoing connection-initialization packets for dns, ssh, RC564 cracking and ping.

We want to be able to use ssh, which uses the TCP protocol and port 22, to connect to our Firewall from other systems on the Internet. The iptables commands we need are:

iptables -t filter -A INPUT  -i eth1 -p tcp --destination-port ssh         \
-m state --state NEW -j ACCEPT
          

This iptables command tells the firewall to allow incoming connection initialization packets for ssh.

We want to be able to use ssh, which uses the TCP protocol and port 22, to connect to one of our internal machines from our Firewall. The iptables commands we need are:

iptables -t filter -A OUTPUT -o eth0 -p tcp --destination-port ssh         \
-m state --state NEW -j ACCEPT
          

This iptables command tells the Firewall to allow outgoing SSH connection initialization packets destined for a machine on the Internal Network.

The machines on the internal network, using the dns of the firewall, must be able to connect to the firewall using ssh, are processing RC564 keys, must be able to talk to the proxy on the firewall using port 2064 and must be able to ping the Firewall for system administrative purposes. The iptables commands we need are:

iptables -t filter -A INPUT  -i eth0 -p udp --destination-port dns         \
-m state --state NEW -j ACCEPT
iptables -t filter -A INPUT  -i eth0 -p tcp --destination-port ssh         \
-m state --state NEW -j ACCEPT
iptables -t filter -A INPUT  -i eth0 -p tcp --destination-port 2064        \
-m state --state NEW -j ACCEPT
iptables -t filter -A INPUT  -i eth0 -p icmp --icmp-type ping              \
-m state --state NEW -j ACCEPT
          

These four iptables commands tell the Firewall to allow incoming connection-initialization packets for dns, ssh, RC564 cracking and ping.

Every connection from a machine on the internal network to a machine on the Internet is allowed. The iptables commands we need are:

iptables -t filter -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT
          

This iptables command tells the Firewall to allow ALL outgoing connection initialization packets.

This does not occur because our local network uses private IP addresses that can't be used on the Internet. Our local machines aren't visible from the Internet.

What we could do to make one of our machines available on the Internet is to let people connect to a certain port on the firewall and use NAT to redirect them to a port on one of the machines on the Internal Network.

Suppose Machine 2 has a web-server (or some other program) running which listens to port 2345 and people from the outside must be able to connect to that program. Since The Firm is using private IP addresses for their Internal Network, Machine 2 is not visible on the Internet. The solution here is to tell Machine 4 that all data from the outside that is aimed at port 80 should be routed to port 2345 on Machine 2. The iptables commands we need are:

iptables -t nat -A PREROUTING -i eth1 -p tcp --destination-port 80         \
-j DNAT --to-destination 192.168.0.11:2345
iptables -t filter -A FORWARD -i eth1 -p tcp --destination-port 2345       \
-m state --state NEW -j ACCEPT
          

The first line changes the destination address and port. Since this then becomes traffic aimed at another machine, the traffic must pass the FORWARD filter. The second line sees to it that that happens.

So far, we've only specified that connection initiation traffic is allowed, but that is not enough. We also must allow ESTABLISHED and RELATED traffic.

Let's tell the firewall that all ESTABLISHED and RELATED traffic, regardless of type, interface etc. is allowed. We must also allow the initiation of traffic on the firewalls lo interface because otherwise some services, such a a caching DNS server, will not work. We need the following iptables commands to realize this:

iptables -t filter -A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A OUTPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT   -m state --state NEW -i lo           -j ACCEPT
          

Remember that this can't be a problem because the packets are a result of the fact that we've accepted the initiation of the connection in the first place.

Adding stuff to start with a clean sheet and telling the firewall to masquerade packets from the internal network aimed at the Internet can be accomplished with the following commands:

################################################################################
# FLUSH ALL RULES IN THE MANGLE, NAT AND FILTER TABLES
################################################################################
iptables -t mangle -F
iptables -t nat    -F
iptables -t filter -F

################################################################################
# DELETE ALL USER-DEFINED (NOT BUILT-IN) CHAINS IN THE TABLES
################################################################################
iptables -t mangle -X
iptables -t nat    -X
iptables -t filter -X

################################################################################
# SET ALL POLICIES FOR ALL BUIL-IN CHAINS TO DROP
################################################################################
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  DROP

################################################################################
# (1) TRAFFIC INITIATED BY THE FIREWALL DESTINED FOR THE INTERNET
#     DNS, SSH, RC564, PING
################################################################################
# ALLOW INITIATION BY THE FIREWALL
iptables -t filter -A OUTPUT -o eth1 -p udp  --destination-port dns        \
-m state --state NEW -j ACCEPT
iptables -t filter -A OUTPUT -o eth1 -p tcp  --destination-port ssh        \
-m state --state NEW -j ACCEPT
iptables -t filter -A OUTPUT -o eth1 -p tcp  --destination-port 2064       \
-m state --state NEW -j ACCEPT
iptables -t filter -A OUTPUT -o eth1 -p icmp --icmp-type ping              \
-m state --state NEW -j ACCEPT
# ALLOW INCOMING RESPONSES 
iptables -t filter -A INPUT  -i eth1                                       \
-m state --state ESTABLISHED,RELATED -j ACCEPT

################################################################################
# (2) TRAFFIC INITIATED BY THE OUTSIDE DESTINED FOR THE FIREWALL
#     SSH
################################################################################
# ALLOW INITIATION
iptables -t filter -A INPUT  -i eth1 -p tcp  --destination-port ssh        \
-m state --state NEW -j ACCEPT
# ALLOW RESPONSE
iptables -t filter -A OUTPUT -o eth1 -p tcp  --destination-port ssh                     \
-m state --state ESTABLISHED,RELATED -j ACCEPT

################################################################################
# (3) TRAFFIC INITIATED BY THE FIREWALL DESTINED FOR THE INTERNAL NETWORK
#     SSH
################################################################################
# ALLOW INITIATION
iptables -t filter -A OUTPUT -o eth0 -p tcp  --destination-port ssh        \
-m state --state NEW -j ACCEPT
# ALLOW RESPONSE
iptables -t filter -A INPUT  -i eth0 -p tcp  --destination-port ssh        \
-m state --state ESTABLISHED,RELATED -j ACCEPT

################################################################################
# (4) TRAFFIC INITIATED BY THE INTERNAL NETWORK DESTINED FOR THE FIREWALL
#     DNS, SSH, RC564, PING
################################################################################
# ALLOW INITIATION
iptables -t filter -A INPUT  -i eth0 -p udp  --destination-port dns        \
-m state --state NEW -j ACCEPT
iptables -t filter -A INPUT  -i eth0 -p tcp  --destination-port ssh        \
-m state --state NEW -j ACCEPT
iptables -t filter -A INPUT  -i eth0 -p tcp  --destination-port 2064       \
-m state --state NEW -j ACCEPT
iptables -t filter -A INPUT  -i eth0 -p icmp --icmp-type ping              \
-m state --state NEW -j ACCEPT
# ALLOW RESPONSE 
iptables -t filter -A OUTPUT -o eth0                                       \
-m state --state ESTABLISHED,RELATED -j ACCEPT

################################################################################
# (5) TRAFFIC INITIATED BY THE INTERNAL NETWORK DESTINED FOR THE OUTSIDE
#     EVERYTHING WE CAN INITIATE IS ALLOWED
################################################################################
# ALLOW INITIATION OF EVERYTHING
iptables -t filter -A FORWARD -i eth0 -o eth1                              \
-m state --state NEW -j ACCEPT
# ALLOW RECEPTION
iptables -t filter -A FORWARD -i eth1 -o eth0                              \
-m state --state ESTABLISHED,RELATED -j ACCEPT

################################################################################
# (6) TRAFFIC INITIATED BY THE OUTSIDE DESTINED FOR THE INTERNAL NETWORK
#     ALL FORBIDDEN, EXCEPT WEBSERVER FORWARDING TO INTERNAL MACHINE
################################################################################
# ALLOW DESTINATION NAT FROM FIREWALL:80 TO INTERNAL MACHINE:2345
iptables -t nat -A PREROUTING -i eth1 -p tcp --destination-port 80         \
-j DNAT --to-destination 192.168.0.11:2345
iptables -t filter -A FORWARD -i eth1 -p tcp --destination-port 2345       \
-m state --state NEW -j ACCEPT

################################################################################
# (!) TRAFFIC AS A RESULT OF INITIATED TRAFFIC
#     ALL ALLOWED
################################################################################
# ALLOW ALL PACKETS RESULTING FROM ALLOWED CONNECTIONS
iptables -t filter -A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A OUTPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT   -m state --state NEW -i lo           -j ACCEPT

################################################################################
# MASQUERADE PACKAGES FROM OUR INTERNAL NETWORK DESTINED FOR THE INTERNET
# THIS IS SNAT (SOURCE NAT)
################################################################################
iptables -t nat    -A POSTROUTING -i eth0 -o eth1 -s 192.168.0.0/24 -j MASQUERADE

################################################################################
# ENABLE FORWARDING
################################################################################
echo 1 > /proc/sys/net/ipv4/ip_forward
          

DoS attackers misuse the fact that resources on the Internet are limited and that services can be disrupted by taking away (one of) their resources: storage-capacity, bandwith or processor-capacity. This is done by “packet flooding”.

Packet flooding can be done with TCP, ICMP and UDP.

When using TCP mostly the SYN, ACK and RST flags are used.

When using ICMP, the message types echo request and echo reply are used. This is called “ping-flooding”.

When using UDP, the chargen and echo UDP services are used.

Also, two systems can be played out against each other by a third system. The third system changes the source IP-address of the packages it sends to the first system to that of the second system. The first system then thinks the packets came from the second system and starts sending replies to the second system. This method is called “DoS with IP address spoofing”.

Check the site http://www.cert.org/ for a complete history of DoS and DDos (Distributed DoS) attacks. And have a look at RFC2827 which describes Network Ingress Filtering, a method to prevent IP address spoofing. This doesn't prevent DoS attacks but makes it possible to trace the real IP address of the offender.

It is not possible to fully prevent DoS attacks without disconnecting from the Internet. What you can do to minimize the effects of DoS and DDoS attacks is apply some packet filtering and rate limiting rules to the firewall.

routed is a program that can automatically adjust routing tables based on changes in the network.

If there are multiple possible paths to a certain destination, and you want an alternate route to that destination to be selected automatically (in case the default route to that destination is not usable for some reason) the routed program can do this for you automatically.

PortSentry is part of the Abacus Project suite of security tools. It is a program designed to detect and respond to port scans against a target host in real-time. Some of its more useful features include:

After you've downloaded the correct version, and untarred it, you've got a directory portsentry-x.y which contains the portsentry files and some README files. The information below comes from those README files.

The first thing to do is verify (and change if appliccable) the contents of the portsentry_config.h file:

The second thing to do is verify (and change if appliccable) the contents of the portsentry.conf file:

The third thing to do is to pull the portsentry.ignore file into your editor and add any host you want ignored if it connects to a tripwired port. This should always contain at least the localhost (127.0.0.1) and the IP's of the local interfaces. It is *not* recommended to put in every machine IP on your network, but you can use a netmask to do this. The format for this is:

<IP Address>/<Netmask Bits>

192.168.2.0/24
192.168.0.0/16
etc.
          

It is not recommended to ignore too much. It may be important for you to see who is connecting to you, even if it is a “friendly” machine. This can help you detect internal host compromises faster. To answer your question: yes, this does happen, and there have been cases of administrators ignoring too much and getting hacked by their own machines as a result.

The fourth thing to do is compile the package. Type make and pick your system type and allow it to build and install. The default directory is /usr/local/psionic/portsentry. If you don't like this directory just edit the Makefile and make sure your portsentry.conf and portsentry_config.h files reflect the new path.

Type make install after the build to have it copy files to your install directory.

The fifth thing to do is start up PortSentry. PortSentry has six modes of operation. Only one protocol mode type can be started at a time (i.e., one TCP mode and one UDP mode). The available modes are:

Now we're ready to test the installation: Tail the local log and you should see several PortSentry initialization messages. A successful startup looks like this:

Oct  9 09:11:35 nemesis portsentry[1644]: adminalert: portsentry is starting.
Oct  9 09:11:36 nemesis portsentry[1644]: adminalert: Going into listen mode on
TCP port: 143
. . .
Oct  9 09:11:37 nemesis portsentry[1644]: adminalert: PortSentry is now active 
and listening.
          

The last line indicates the PortSentry is properly initialized, If you don't see this then something has failed.