Dynamic Iptables Firewall

Firewalls are interesting, but what do you do when you need to make fast and complex changes to your firewall rules? Very simple. Use the Daniel Robbins Dynamic firewall script that is shown in this article. You can use these scripts to increase network security and responsiveness, and to inspire your own creative design.

The best way to understand the benefits of dynamic firewall scripting is to view them at run time. To do this, let's assume that I am a system administrator for an ISP, and I recently built a Linux based firewall to protect my customers and internal systems from malicious users on the Internet. To do this, my firewall uses the new Linux 2.4 iptables stateful feature to allow my clients and servers to establish new out-of-office connections, and of course allow new incoming connections, but only "public" services such as Web, FTP, SSH, and SMTP. Because I use the default reject design, any connection from the Internet to a non-public service such as a squid proxy cache or a Samba server is automatically rejected. Now, I have a very good firewall, which provides a very good protection for all of my company's customers.

In the first one weeks or so, the firewall was a great job, but then something nasty happened: My biggest opponent, Bob (who worked for another ISP, our competitor) decided to attack my network with a lot of information packets, trying to stop me from serving my customers. Unfortunately, Bob has studied my firewall carefully, and he knows that when I protect my internal services, ports 25 and 80 must be publicly accessible so that I can receive mail and respond to HTTP requests. Bob decided to take advantage of this and he wanted to use the bandwidth-sucking method to attack my Web and mail servers.

About a minute after Bob's attack, I noticed that the packets were gradually filling up the uplink. After looking at the tcpdump, I'm sure it was another attack that Bob implemented, and I calculated the IP address he used to launch the attack. Now that I've got this information, all I have to do is block these IP addresses, and I think that might solve the problem-a very simple solution.

Responding to attacks

I quickly used VI to open the firewall settings script, and began to change the iptables rules, modify the firewall, so that it can prevent those Bob sent malicious access packets. About a minute or so, I found the exact location of the add appropriate DROP rule and added these rules. Then I started the firewall, but stopped it immediately ... Hey, I made a little mistake in adding the rules. I mounted the firewall script again, corrected the problem, and after 30 seconds, the firewall was adjusted to prevent all attacks that Bob initiated within this month. At first it seemed to have succeeded in defeating the attack ... Until the phone call rang at the inquiry desk. Apparently, Bob has been interrupting my network for about 10 minutes, and now my client is calling to inquire about what happened. Worse, a few minutes later, I found that the uplink was full again. It appears that Bob used a new set of IP addresses to implement the attack. I also responded by immediately starting to modify the firewall script, but this time I was a little alarmed-perhaps my solution was not so perfect.