Hello, I have a problem with UDP traffic and use of the 'recent' module. I've recently modified my firewall script to use the ipt_recent module to help block SSH dictionary attacks, as well as attacks on certain trigger ports targetted by vulnerability scanning scripts. An excerpt of my firewall script appears below. Notice that I am using two ipt_recent lists, one for SSH and one for 'scram' ports used in vulnerability scans. One of the ports I watch is UDP 1434, a Microsoft SQL Server port targetted by the SQL Slammer worm. When iptables detects a new connection to that port, it adds the source IP to the 'scram' list, and a rule near the top (just after allowing established/related) eliminates further traffic from that source IP until timeout. However, if I don't specify "-p tcp" in that enforcement rule just after established/related, it appears that all UDP traffic (even from source IPs not in the list) are dropped by those enforcement rules. I'm expecting that traffic on UDP 1434 to hit the trigger, further traffic from that source IP gets blocked by the 'scram' enforcement rule, and all other UDP traffic (like NTP) passes through to the rest of the rules. What is happening is that all UDP traffic is dropped. What can I do to make this work? I think it's more to do with UDP connection states rather than a bug, but I'm not sure how or if I can structure this to operate like I want. (Previously I was using a ulogd custom plugin to dynamically add mangle table rules, and a forked thread to clear them after timeout. It was goofy, but it worked.) I don't think the use of more than one list has anything to do with this, but I thought I should include it for completeness. I know I'm using the new re-written ipt_recent.c module (kernel is 2.6.18.8). Is this a bug or am I missing something silly? Thanks very much in advance for your assistance, all constructive comments are appreciated. --Roger Venable --Ann Arbor, Michigan Kernel: Linux 2.6.18.8-0.1-default #1 SMP Fri Mar 2 13:51:59 UTC 2007 i686 athlon i386 GNU/Linux iptables: v1.3.6 # some rules not pertaining to this example were cut # (and IP addresses changed to protect the innocent) # default drop iptables -P OUTPUT DROP iptables -P INPUT DROP iptables -P FORWARD DROP # accept established / related iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # SCRAM rules # if '-p tcp' not specified here, all UDP traffic gets dropped # even from source addresses that are not in a 'recent' list iptables -A INPUT -i eth0 -p tcp -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP iptables -A INPUT -i eth0 -p tcp -m recent --update --seconds 3600 --name SCRAM -j DROP # <SNIP> more rules... # SSH # dictionary attacks get lost # iptables -N In_RULE_13 iptables -A INPUT -i eth0 -p tcp -m tcp -d 192.168.1.68 --dport 22 -j In_RULE_13 iptables -A INPUT -i eth0 -p tcp -m tcp -d 192.168.1.69 --dport 22 -j In_RULE_13 iptables -A In_RULE_13 -j ULOG --ulog-nlgroup 1 --ulog-prefix "SSH RECENT " --ulog-qthreshold 1 iptables -A In_RULE_13 -m recent --name SSH --set -j ACCEPT # <SNIP> more rules... # scan triggers # when trigger ports hit by script kiddies, add to 'scram' recent table # iptables -N In_RULE_30 iptables -A INPUT -i eth0 -p tcp -m tcp --dport 1023:1029 -j In_RULE_30 iptables -A INPUT -i eth0 -p tcp -m tcp -m multiport --dports 1433,3128,1761,12345,2967,37,5900 -j In_RULE_30 iptables -A INPUT -i eth0 -p udp -m udp --dport 1025:1029 -j In_RULE_30 iptables -A INPUT -i eth0 -p udp -m udp -m multiport --dports 1434,500 -j In_RULE_30 iptables -A In_RULE_30 -j ULOG --ulog-nlgroup 1 --ulog-prefix "SCRAM " --ulog-qthreshold 1 iptables -A In_RULE_30 -m recent --name SCRAM --set -j DROP # <SNIP> more rules... # Here accept other UDP traffic, like NTP on UDP 123 # So, Grim, you reap around here, do you? iptables -N RULE_36 iptables -A OUTPUT -j RULE_36 iptables -A INPUT -j RULE_36 iptables -A RULE_36 -j ULOG --ulog-nlgroup 1 --ulog-prefix "DEATH " --ulog-qthreshold 1 iptables -A RULE_36 -j DROP # 601
