I was looking to update iptables in our webserver which would prevent DoS attack to an extent.

1) Related to web traffic, below are the iptables rules i found.

iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m limit --limit 50/minute --limit-burst 200 -j ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit 50/second --limit-burst 50 -j ACCEPT

I am able to understand the first 2 rules. Can someone clarify the last 2 rules? Taking the last 2 rules, does the 1st one mean that only 50 new connections are accepted per minute? What does the limit-burst do? I tried to read about it. But not sure if I understood it clearly. Does it mean that once 200 new connections are accepted in a minute, then it puts a limit of only 50 new connections per minute. And any further new connection requests will be dropped. And when will it again go back allowing the burst of 200 new requests once again?

Now, what does the last rule mean? Only 50 users can be connected to my webserver per second? Why is the burst count here is again same 50? With these last 2 rules, are there chances that some legitimate traffic might get dropped?

2) I came across the below set of rules which was being referred in so many places to block portscan. Does it look right? can someone explain what this does? I am quite unsure about the logic and why dport is 139 in the last 4 rules.

# Attempt to block portscans
# Anyone who tried to portscan us is locked out for an entire day.
iptables -A INPUT   -m recent --name portscan --rcheck --seconds 86400 -j DROP
iptables -A FORWARD -m recent --name portscan --rcheck --seconds 86400 -j DROP

# Once the day has passed, remove them from the portscan list
iptables -A INPUT   -m recent --name portscan --remove
iptables -A FORWARD -m recent --name portscan --remove

# These rules add scanners to the portscan list, and log the attempt.
iptables -A INPUT   -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "Portscan:"
iptables -A INPUT   -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP

iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "Portscan:"
iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP

1 Answer 1


The limit extension implements a token bucket mechanism. Usually when a rule matches, netfilter jumps to the provided target, ACCEPT in this case. When you plug in the limit extension, netfilter has to remove a "token" from this rule's "bucket" before it is allowed to jump. If there aren't any tokens in the bucket, this extension prevents netfilter from jumping, even though the rule did match.

--limit 50/minute #tells netfilter to add 50 tokens per minute to the bucket
--limit-burst 200 #tells netfilter to use a bucket which holds up to 200 tokens

If there are 50 connection requests per minute (or more), your server will allow 50 new connections every minute. If there are less than 50 requests in a minute, the bucket will fill up (actually it starts out full). This means that if there are only a few requests in one minute, the server will accept more than 50 new requests in the next minute. To keep this from getting out of control, there is a cap on how many tokens the bucket can hold. 200 in this case. When the bucket is full, your server will accept the next incoming 200 connections, even when they hit your server at the same time. As this is more than 50, we call this a burst, where the number of accept connections spikes up to more than the 50 we want ON AVAERAGE.

The second rule means that this machine will accept 50 IP packets very second without further investigation, as long as they belong to a flow netfilter recognises. To gauge the effects of this rule, we would need to see the entire chain (and every chain it references and it is referenced by). However, I can tell you a few things that line up here:

  1. Netfilter counts the TCP connection initiator's ACK to complete the handshake as a RELATED packet. 50 successfully established connections per minute perfectly saturate the second rule you are having trouble with.

  2. Most common TCP implementations make four connection attempts before giving up. With 50 successfully established connections, you receive 200 connection requests, in the worst case.

  3. It doesn't matter how often an endpoint makes a specific connection request, only one has to be successful, within a reasonable amount of time, to establish the connection. Most implementations put 60 seconds as the default reasonable amount of time.

If the last rule were 50/minute, these four rules could be part of a really cool DoS protection framework. As it lacks the --dport 80 filter and is 50/second I can only guess:

a) You totally ripped this line out of context and it is not immediately related to the first three.

b) This is a general cap to slow down traffic.

c) It's a mistake and it should be 50/minute.

d) It's a trade off between securing the server against DoS attacks and keeping the service accessible during and immediately after a DoS attack.

To understand the second snipped, you first must drill into your head, that the recent extension uses and maintains knowledge about the source IP address.

The recent extension manages its knowledge in lists. The default list is named DEFAULT and it is used if no other list is provided. One provides another list using --name.

So the first two rules mean "drop this packet if the source IP has been put on the list portscan within the last 86400 seconds".

The second two rules mean "remove this IP address from the list portscan". Please not that this rule is only evaluated if the previous rule did not match. This rule exists to keep the list portscan short. Longer lists take longer to search.

The last four rules put source IPs on the portscan list, log about it and DROP the packet. --dport 139 is there because this behaviour is wanted only in this case. I am very sure these rules make much more sense when in context, because this is not a complete rule set to prevent port scanning.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .