Now the technical stuff: How to fill your table with rules.
First of all, you need a 2.4 kernel and netfilter support. Next you should off course install iptables itself, and load the module into kernelspace. If it isn’t already compiled in to the kernel it self, you can load in with “modprobe IP_tables”
One thing you should realize before beginning to create and test your firewall is what kind of default policy you would like to implement. The default policy states what to do with a packet whenever a packet does not match any rule in the firewall.
You should set a default policy on every chain you intend to use usually FORWARD,INPUT and OUTPUT, for example:
Iptables �P FORWARD DROP
Now I think it is easiest to explain the rest by giving an example:
Iptables -A FORWARD -s 192.168.1.1 -d 192.168.2.1 -j DROP
This command adds a rule ( on the end of the table ) to the FORWARD chain which states to DROP (discard ) all packets that traverse the linux firewall from 192.168.1.1 to 192.168.2.1. Matching a range of ip addresses instead of just one, can be done by simply including de subnetmask or the number of netmaskbits behind the network address:
Iptables -A forward -s 192.168.1.0/255.255.255.0 -j drop
Iptables -A forward -s 192.168.1.0/24 -j drop
If you would like to insert a rule instead of adding it to the end, use -I and the rule number. Replacing is like inserting, but using -R as parameter instead of -I.
So now we are going to dig a bit deeper.
In the previous example I dropped packets based on source and destination IP addresses. Now let’s filter on base of protocol. This can be done by adding -p and after that the protocol ( like TCP,UDP,ICMP ). To even filter deeper by port, add behind -p TCP -sport to filter on source port or -dport to filter on destination port and after that the port number.
A short example:
Iptables -A INPUT -p TCP -dport 80 ACCEPT
By now you probably onderstood what this thing does: It accepts all traffic on port 80 destined for the pc running iptables.
So you now know enough to create a basic firewall with IPtables. Want more?
Sure, just read on!
This next step is to my opinion pretty important.
A pc which uses TCP uses a 3-way handshake to create a connection between two pcs who would like to communicate which each other. This is done by setting a flag in the first, second and third package of the handshake. A hackers first package to a pc he would like to hack must too (not always, but that’s out of the scoop of this document ) shake hands with the attacker PC. But what if you could just filter on the these packets? Not just letting connect anyone to the pc, except when the communication has been started from the inside?

That�s just what IP tables can do for you, and it�s called: Connection tracking!
So, how do we implement this?
Easy:
iptables -A INPUT -p tcp –sport 80 -m state –state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o -p tcp –dport 80 -m state –state NEW,ESTABLISHED -j ACCEPT
This creates a rule which allows only established traffic from the outside in, and allows new and established traffic from the inside out.
The -m state option is used to load the functionality to use the -state option; it isn’t loaded by default.
Some protocols need a little more attention, because they are more complex then standard TCP connections. For example: Active FTP.
Active FTP clients uses port 21 as the control channel. It sends commands to the FTP server. When a transfer is being made, the client tells the server on which ip address and port number to connect to transfer the data.
But the firewall doesn�t know this, and blocks the data from the server. To overcome this problem, the firewall has to “open” the packages at the control channel to see which port is being assigned to the server to connect, and this port should then be dynamically opened up.
Therefore there are connection helpers created, which can be loaded into kernelspace.
In this example, this should be: “modprobe ip_conntrack_ftp”.
More helpers for different protocols exist, but are out of the scoop of this article.
Another nice feature is the ability to log packages. This way you can create some stats about the amount of packages travels to your firewall, bounced an accepted packages, ip options etc. You create a rule like this:
Iptables -A INPUT -p tcp -j LOG -log-level {DEBUGLEVEL}
Where DEBUGLEVEL is the level that IPtables and Syslog are going to use. Usually there a vast number of logging priorities:
- Debug
- Info
- Notice
- Warning
- Err (error)
- Critical
- Emerg(panic)
When using this feature, all messages appear in the syslog log ( usually /var/log ), and thus will probably contain also other kernel messages.
Getting stats out of the logs is this way a problem; how would you know which message came from IPtables?
Luckily the developers thought of this. By adding -log-prefix “{STRING}” you can add a prefix to every logged message in the log file so you can filter these easily out.