Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am trying to create some simple iptables DOS protection rules for my web server. I was doing testing on the following rules:

iptables -N LOGDROP > /dev/null 2> /dev/null
iptables -F LOGDROP
iptables -A LOGDROP -j LOG --log-prefix "LOGDROP "
iptables -A LOGDROP -j DROP

iptables -I INPUT -p tcp --dport 8000 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 8001 -i eth0 -m state --state NEW -m recent --set

iptables -I INPUT -p tcp --dport 8000 -i eth0 -m state --state NEW -m recent --update --seconds 1 --hitcount 4 -j LOGDROP
iptables -I INPUT -p tcp --dport 8001 -i eth0 -m state --state NEW -m recent --update --seconds 1 --hitcount 4 -j LOGDROP

I created a simple script on a separate machine to do a wget and then sleep for .2 seconds. I launched this script at port 8000 and 8001, and as expected I saw drop messages start to appear in my /var/log/messages:

Jul 30 20:03:57 Server kernel: LOGDROP IN=eth0 OUT= MAC=08:00:27:d5:52:24:08:00:27:6d:cf:2f:08:00 SRC=192.168.56.102 DST=192.168.56.101 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=31049 DF PROTO=TCP SPT=44071 DPT=8000 WINDOW=14600 RES=0x00 SYN URGP=0
Jul 30 20:04:00 Server kernel: LOGDROP IN=eth0 OUT= MAC=08:00:27:d5:52:24:08:00:27:6d:cf:2f:08:00 SRC=192.168.56.102 DST=192.168.56.101 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63571 DF PROTO=TCP SPT=38876 DPT=8001 WINDOW=14600 RES=0x00 SYN URGP=0
Jul 30 20:04:00 Server kernel: LOGDROP IN=eth0 OUT= MAC=08:00:27:d5:52:24:08:00:27:6d:cf:2f:08:00 SRC=192.168.56.102 DST=192.168.56.101 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63984 DF PROTO=TCP SPT=44075 DPT=8000 WINDOW=14600 RES=0x00 SYN URGP=0

Everything appears to be great, except when I checked wireshark I found that the connection from source port 44071 was successful, meaning I saw a full tcp handshake, HTTP GET, and socket close. The other two entries in the log were successfully dropped, meaning I saw just a SYN packet in wireshark.

Anyone know why the connection on source port 38876 would be logged as denied but not actually dropped?

share|improve this question

migrated from stackoverflow.com Jul 31 '11 at 16:11

This question came from our site for professional and enthusiast programmers.

add comment

2 Answers

Your rule first jumps from the INPUT table to the LOGDROP table then to the LOG table, thus the last entry in the LOGDROP table never get's called as you've already moved the execution to the LOG table.

share|improve this answer
    
If that were the case, why would 2 of the connections above (ID 63571 and 63984) be logged and dropped? –  adam35413 Jul 31 '11 at 17:26
add comment

I noticed while looking at wireshark that I was indeed seeing blocked traffic, my script was just reusing the sockets. As a result, for any blocked socket entry in my log I would see multiple initial SYNs.

Also, to make the above rules work I needed to add a --name attribute to each of the iptable lines. Without --name, all connections from the same IP address apply against the hitcount regardless of what port it arrived on.

In summary, the issue has been resolved.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.