Firewall Rules using IPTables/NetFilter for a Host with Web and Mail Services
Host firewalls are intended to limit the exposure of a machine to risks in the internet. Similar to a building firewall that prevents the spread of fire from one building to another, a computer firewall prevents risks that are inherent in running applications to reach other programs or parts of the operating system. Many modern operating systems shipped with a firewall program and IPTables/NetFilter is the default firewall used in GNU/Linux systems.
This firewall consists of two major parts: (1) IPTables is the user space application that system administrators use to control the firewall, while (2) NetFilter is the kernel hook that handles the actual filtering, forwarding and manipulating of packets that are received to or sent from the host machine (Russell 2002). For this report, we shall refer to both parts simply as IPTables since we will only be using the user space commands to control the firewall.
The firewall that we specify here is for a machine with two major services: web and mail services. Sytem administration can be done accessing the machine via SSH and Telnet.
There are some commands that have been specified. Some of these commands were rewritten to reduce ambiguity between similar services, and some for completeness.
# Delete redhat default firewall chains
iptables -F RH-Firewall-1-INPUT 2 /dev/null
iptables -X RH-Firewall-1-INPUT 2 /dev/null
# For your own safety, stop users logging in from other VMs
iptables -A INPUT -i eth0 -p tcp –dport 22 -s 10.0.0.0/16 -j DROP
iptables -A INPUT -i eth0 -p tcp –dport 23 -s 10.0.0.0/16 -j DROP
The next command was rewritten to specify that we will not accept any HTTP (TCP, port 80) requests from the VM network (10.0.0.0/16). In the original command, the network was not specified, and thus will lead to confusion in debugging since we would like to receive HTTP requests, except those requests that came from the VM network.
iptables -A INPUT -i eth0 -p tcp –dport 80 -s 10.0.0.0/16 -j DROP
We also do not want to accept any TCP traffic from another VM network (22.214.171.124/24).
iptables -A INPUT -i eth0 -p tcp -s 126.96.36.199/24 -j DROP
We also accept ICMP packets as recommended by RFC 1574 (Hares 1994). This will ease any debugging that we may do so in the future. However, we also want to limit the number of ICMP packets that we want to respond to, in the case of an DOS attack via ping. We record these “excess” ping requests, and drop them from the queue.
iptables -A INPUT -p icmp –icmp-type echo-request -m limit –limit 1/second -j ACCEPT
iptables -A INPUT -p icmp –icmp-type echo-request -j LOG
iptables -A INPUT -p icmp –icmp-type echo-request -j DROP
As the machine has only one network connection, we will pass this argument to all incoming and outgoing packets.
We also assume that the machine has an IP address (188.8.131.52). We will specify this to avoid any ambiguity in making the firewall commands.
As previously mentioned, we want to administer this machine using SSH (port 22). We use a dynamic rule so that we no longer need to specify a separate rule to take care of the return packets (Purdy 2004).
iptables -A INPUT -i eth0 -p tcp -d 184.108.40.206 –dport 22 -m state –state NEW,ESTABLISHED -j ACCEPT
Given that there will only be one or a few system administrators for a single machine, we may want to limit the number of connections.
iptables -A INPUT -i eth0 -p tcp -d 220.127.116.11 –dport 22 -m connlimit –connlimit-above 2 -j ACCEPT
As an alternative to SSH, we also allow administration via Telnet (port 23), however, Telnet should not be used because it is insecure (Barret 2004).
iptables -A INPUT -i eth0 -p tcp -d 18.104.22.168 –dport 23 -m state –state NEW,ESTABLISHED -j ACCEPT
As an email server, we should allow the machine to have access and to be accessed from the SMTP port (port 25). There will be two commands using stateful firewall rules. One for incoming SMTP connections, and another for outgoing network connections. We use stateful firewall rules using the -m state argument. NEW and ESTABLISHED refer to the state of the connection flags that will be accepted (Russell 2008).
iptables -A OUTPUT -i eth0 -p tcp -s 22.214.171.124 –sport 1024:65535 -d 0/0 –dport 25 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -s 0/0 –sport 25 -d 126.96.36.199 –dport 1024:65535 -m state –state NEW,ESTABLISHED -j ACCEPT
We will be running the web server using the apache user id. As such, we do not want the apache user to generate HTTP requests to other networks. This is done by specifying the process owner using -m owner and –uid-owner apache (Russell 2008).
iptables -A INPUT -i eth0 -p tcp -s 188.8.131.52 –dport 80 -m owner –uid-owner apache -j DROP
While we do not allow the apache user to access other HTTP servers via port 80, we do allow other users (especially the administrators) to access the Internet via port 80 (Russell 2008).
iptables -A INPUT -i -p tcp -s 184.108.40.206 –dport 80 -m state –state NEW,ESTABLISHED -j ACCEPT
After we have excluded the apache user from sending HTTP requests to other HTTP servers via port 80, we now add the rules that allow it to accept and respond to HTTP requests (Russell 2008).
iptables -A INPUT -i eth0 -p tcp -d 220.127.116.11 –dport 80 -m state –state NEW, ESTABLISHED -j ACCEPT
We also allow the machine to make DNS lookups. This is essential, especially if we do not access the Internet using a proxy. By default, DNS uses UDP, but we will also allow alternative access via TCP. We specify two rules for the UDP (one for incoming, another for outgoing) because it has no state, and thus we cannot make any rules regarding its state.
iptables -A OUTPUT -i eth0 -p udp -s 18.104.22.168 –dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p udp -d 22.214.171.124 –sport 53 -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp -s 126.96.36.199 –dport 53 -m state –state NEW,ESTABLISHED -j ACCEPT
Lastly, we log all packets that do not conform to the rules that we have declared above, so that we may study it for future use (Russell 2008).
iptables -A INPUT -j LOG
iptables -A OUTPUT -j LOG
iptables -A FORWARD -j LOG
After recording the non-conformant packets, we drop them (full egress and ingress filtering) (Russell 2008).
iptables -A INPUT -j DROP
iptables -A OUTPUT -j LOG
iptables -A FORWARD -j LOG
We should remember that Telnet does not encrypt the traffic, as well as the login credentials that are being used. We should discourage all users in this machine to avoid using Telnet and use SSH instead. For a more secure system, Telnet access should be disabled and all users compeled to use SSH. We recommend that the IPTables command pertaining to Telnet access should be uncommented, and that Telnet (port 23) be blocked.
In addition, we have used dynamic rules in order to reduce the verbosity of the firewall rules, and hence, increase the human readability of the said rules.
Barret, D.J., 2004. Linux pocket guide, O’Reilly Media, Inc.
Bauer, M.D., 2005. Linux server security, O’Reilly Media, Inc.
Bauer, M.D. & Oram, A., 2002. Building secure servers with Linux, O’Reilly & Associates, Inc. Sebastopol, CA, USA.
Cheswick, W.R., Bellovin, S.M. & Rubin, A.D., 2003. Firewalls and Internet security: repelling the wily hacker, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA.
Convery, S., 2004. Network security architectures, Pearson Higher Education.
Flickenger, R., 2003. Linux server hacks, O’Reilly Media, Inc.
Hares, S. & Wittbrodt, C., 1994. Essential tools for the OSI Internet. Request for Comments (RFC), 1574.
Jang, M., 2006. Mastering Fedora Core 5, Sybex.
Jang, M., 2007. RHCE Red Hat Certified Engineer Linux Study Guide, McGraw-Hill Osborne Media.
Kirch, O. & Dawson, T., 2000. Linux network administrator’s guide, O’Reilly & Associates, Inc. Sebastopol, CA, USA.
McCarty, B. & Cox, M.J., 2002. Red Hat Linux Firewalls, John Wiley & Sons, Inc. New York, NY, USA.
Northcutt, S. et al., 2005. Inside Network Perimeter Security (Inside), Sams Indianapolis, IN, USA.
Purdy, G.N., 2004. Linux iptables pocket reference, O’Reilly.
Russell, R. & Netfilter Core Team, Netfilter/Iptables, Available at: www.netfilter.org.
Russell, R., Boucher, M., Kadlecsik, J., Welte, H., & Netfilter Core Team, 2008. Man page of IPTABLES,. Available at: http://ipset.netfilter.org/iptables.man.html
Russell, R. & Welte, H., 2002. Linux netfilter hacking HOWTO. Disponivel em http://www. netfilter. org/documentation/HOWTO//netfilter-hacking-HOWTO. letter. ps (Junho de 2005).
Shinder, T., 2007. The Best Damn Firewall Book Period, Syngress.
Siever, E., Figgins, S. & Weber, A., 2003. Linux in a Nutshell, O’Reilly & Associates, Inc.