IntroductionUp until now, we've looked at stateless and stateful firewalls. Remember, stateless firewalls only have thefeatures of a given packet to use as criteria for whether that packet should be passed, blocked, or logged. Witha stateful firewall, in addition to the fields in that packet, we also have access to the kernel's table of openconnections to use in deciding the fate of this packet.There's a problem, though. Picture an attacker that has launched attacks against almost every port on our webserver box for the past half hour. The firewall has successfully repelled all of them, but now the attacker turnsher attentions to port 80. All of the hostile overflow attempts are let through unhindered. Why? Because thefirewall ruleset allows all traffic to the web server through, and our firewall can't remember the fact that thisIP address has been pounding all the other ports on the system.What if we could tell the firewall to remember the IP address of attackers and block them for a short period oftime following their last attack? By remembering their past actions, we can block incoming web serverconnections that would otherwise have been allowed.Iptables modulesThe firewall code in the current Linux kernel ( http://www.netfilter.org ) is called Iptables or Netfilter (whilethere is a technical distinction, they're equivalent names for this discussion). The crucial feature of thisfirewall is its modular design. You have the ability to add new types of tests to perform on a packet andactions to take on it. These tests and action modules can be added to a running kernel.For example, lets say you want to discard all packets that have any ipv4 options set. The stock kernel doesn'thave a test for this. However, someone has written a firewall module that can perform this test. Once themodule is compiled for and inserted into the current kernel, the following firewall command:iptables −A INPUT −m ipv4options −−any−opt −j DROPwill discard these packets. Conveniently, there's even a new target module that can strip off these headers ifcompiled and invoked like so:iptables −t mangle −A PREROUTING −j IPV4OPTSSTRIPNote that the kernel, as booted, had neither the ability to recognize (the first command above) nor strip (thesecond command) ipv4 options. These capabilities were provided by the ipv4options and IPV4OPTSSTRIPloadable kernel modules (lowercase modules are tests and uppercase modules are targets, by convention).Categorizing attackers with the recent moduleWe're going to make use of the recent firewall module. We need to make use of this in two ways; first, toidentify the IP address of malicious attackers, and second, to punish them in some fashion.We're going to use the following tests to identify the malicious traffic.iptables −A INPUT −p tcp −d my.mail.server −−dport 25 −−tcp−flags ACK \ ACK −m string −−string "rcpt to: decode" \ −j LOG −−log−prefix " SID664 "Adaptive firewalls with iptablesIntroduction 1iptables −A INPUT −p tcp −d my.mail.server −−dport 25 −−tcp−flags ACK \ ACK −m string −−string "rcpt to: decode" \ −m recent −−name MAILPROBER −−setiptables −A INPUT −p tcp −d my.mail.server −−dport 25 −−tcp−flags ACK \ ACK −m string −−string "rcpt to: decode" \ −j REJECT −−reject−with tcp−reset# "SMTP sendmail 5.6.4 exploit" nocase−ignored arachnids,121 classtype:attempted−admin sid:664This rule is from the http://www.stearns.org/snort2iptables/ project which provides roughly equivalentiptables firewall rules from the Snort IDS ruleset.The first two lines of each command identify the malicious traffic. In this case, we have traffic header for thesmtp port on our mail server with the ACK flag set and the phrase "rcpt to: decode" in the packet. The firstrule simply logs the traffic to syslog. The second rule is the one that records the source address of this packetin a kernel table called MAILPROBERS. The final rule is the only one that actually decides the fate of thispacket; the packet is discarded and a tcp reset is sent back to the sender.The first and third rules are concerned with what to do with this packet. The second rule is solely interested inremembering the attackers IP address for future punishments. OK, let's punish them:iptables −A INPUT −m recent −−name MAILPROBER −j DROPThis one is placed near the top of the firewall, but after any "iptables −A INPUT −m state −−stateESTABLISHED,RELATED −j ACCEPT" rules. The rule sees if the source address of a new packet is in theMAILPROBER IP address list in the kernel. If it is, the packet is discarded. Here's the first time we've beenable to use someone's past actions to block their future connections.The above punishment is a little harsh, though. The fact that someone tried an old exploit 3 hours ago doesn'tmean that IP address should be blocked from any communication with anyone in our network forever, whichis the end result of the above DROP rule. If for no other reason, the attack might have come from a dialup IPaddress; the next person to acquire that address may simply want to retrieve a web page, and is now blockedbecause his predecessor was mildy hostile a while back.Lets tone down the punishment a little:iptables −A INPUT −m recent −−name MAILPROBER −−seconds 180 −j DROPWe'll ignore the attcker for 3 minutes, but after that we'll allow more packets in and see if they'll play niceagain.See the http://www.stearns.org/snort2iptables/ website and the psd port scan detector module for some moreideas of traffic to seed the attackers lists in recent. I'd strongly discourage using anything but established tcpsession traffic, even though a good portion of the snort2iptables ruleset is udp, icmp or other protocols asnon−tcp protocols are easier to spoof than tcp.The Marquis De Sade, or punishments galoreSo far we've put in a three minute block on this individual. Here are some other punishments to consider formore or less severe offenses. Simply replace the "−j DROP" above with one of the following. Note that onecan log any packet by simply putting in a a log rule (see above for an example) ahead of the rule that decidesAdaptive firewalls with iptablesThe Marquis De Sade, or punishments galore 2what to do with the packet.... −j REJECTLike DROP, but it lets the attacker know her connections are being shot down. In many ways, this ismore network−friendly as you're closing