(LinuxWorld) -- As I write this column, the world suffers infestation by yet another Internet worm, and again the worms are intended to attack Microsoft-based machines. Fortunately for my company, we don't run any Microsoft-based machines, but the Nimda worm still affects us.
Nimda eats our bandwidth since other companies sharing our subnet are running infectious Windows 98, NT, and 2000 machines. These diseased, ill-maintained beasts from the land of insufficient light are now trying to infest our stable, secure, long running, easy-to-use, well-behaved Linux machines. (Can you tell I'm a bit irritated?)
This has led me to start editing some of our firewall rules, and in the process, consider that, as we have recently migrated to the 2.4 kernel, some people may be interested in how to create a Linux 2.4 kernel-based firewall quickly.
The following examples do not create the perfect firewall. What I describe is designed to give a system administrator a little piece of mind by fortifying a machine from obvious attacks.
Why 2.4/iptables?
The 2.2 version of the Linux kernel used the ipchains application to control the firewall. For standard firewalling, ipchains is a decent solution. We still use it on some of our machines, and there is still a positive argument for 2.2 kernel-based firewalls, because the 2.4 kernel still has some stability issues under heavy load.
Those heavy load issues aside, the 2.4 kernel provides a wealth of networking capabilities 2.2 lacks. These include stateful firewalling and solid quality-of-service options. One could argue that the 2.4 kernel, and its iptables firewall code, enables a person to build intricate firewalls capable of competing with the likes of CheckPoint.
Using iptables
The command to execute iptables is simple: as root type iptables. The execution of the previous command should display output similar to the following:
[root@jd root]# /sbin/iptables
iptables v1.2.1: no command specified
Try `iptables -h' or 'iptables --help' for more information.
[root@jd root]#
If you would like an output of the available options when using the iptables you can pass the -h flag during program execution. The -h command will result in output similar to the following:
[root@jd root]# /sbin/iptables -h
iptables v1.2.1
Usage: iptables -[ADC] chain rule-specification [options]
iptables -[RI] chain rulenum rule-specification [options]
iptables -D chain rulenum [options]
iptables -[LFZ] [chain] [options]
iptables -[NX] chain
iptables -E old-chain-name new-chain-name
iptables -P chain target [options]
iptables -h (print this help information)Commands:
Either long or short options are allowed.
--append -A chain Append to chain
--delete -D chain Delete matching rule from chain
--delete -D chain rulenum
[...]
For this article, I am not going to go into exhaustive explanation of all the iptables options. If you want an advanced introduction, to iptables I suggest the Linux 2.4 Packet Filtering HOWTO (see resources below).
When developing a personal or desktop firewall I practice a very simple philosophy. If you aren't going to use it, don't open it. For example, if you are not hosting a Web site, do not open port 80. If you are not using telnet (and there is not a good reason on this Earth to use telnet), do not open port 23!
In an effort to follow my philosophy, the quickest way to port protection nirvana is the following iptables chain:
/sbin/iptables -A INPUT -p tcp --syn -j DROP
The previous statement will allow you to, as the user of the computer, performed all your normal Internet activities. You will be able to browse the Web, ssh out, or chat with a colleague on ICQ. On the other hand, the outside world, when trying to connect to your Linux box via TCP/IP, will simply be ignored. This is a reasonable solution for most Linux computers.
However, one of the benefits of Linux is its remote management capabilities. One of the more popular ways that people remotely manage Linux machines is via the SSH (see resources) suite. SSH typically operates on port 22 and thus, we would need to enable connections to port 22, while keeping the rest of the connections closed. This can be done with the following iptable chains:
/sbin/iptables -A INPUT -p tcp --syn --destination-port 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --syn -j DROP
It is probably not a good idea to let the world connect to your machine on port 22 unless you run a public server. Therefore, we can limit which machines can connect to port 22 by modifying the iptable chain, and adding the -s option. The -s in this example specifies what source address is allowed to connect to the server.
/sbin/iptables -A INPUT -p tcp --syn -s 192.168.1.110/32 --destination-port 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --syn -j DROP
The addition of the -s 192.168.1.110/32 will enable only the remote machine with the IP address of 192.168.1.110 to connect to your protected host.
When you create an iptables-based firewall, each chain (for simplicity's sake, each line) will be read sequentially. Thus, it is possible to have the previous configuration of only one machine having rights to connect via SSH, and to run a public Web server. This could be done with the following commands:
/sbin/iptables -A INPUT -p tcp --syn -s 192.168.1.110/32 --destination-port 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --syn --destination-port 80 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --syn -j DROP
This is just an introduction to iptables, but it does give a reasonable representation of the bare essentials for a firewall. If you are currently running Linux with kernel 2.4, it may be a good time to review what your firewall looks like. On a closing note, if you are still running kernel 2.2 and you are looking for a good firewall configuration utility, take a look at Guard Dog (see resources).
Subscribe to Linux Email News Alerts
Subscribe via RSS
