Recently I've got a lot of small scale DoS attacks. I am wondering what iptables rules should I use to counter the most common DoS attacks, and generally secure my web server.

The web server sports Varnish -> nginx/php5 -> memcached -> mysql

I tried some generic receipts but they also block access to my database server which sits at a remote server, so I just flushed the suggested rules, and now feel a bit barehanded and volnurable when I see only fail2ban on iptables.

So appreciate your rules to block the most common attack vectors.

  • 1
    Depends on what attacks you're facing. All effective DoS attacks require either S/RTBH or content inspection, though, so iptables rules on the server under attack aren't going to be of any use. – womble Jul 24 '12 at 11:45
  • I modified the question to avoid misunderstanding. I simply look for rules to counter the most common DoS attacks . – alfish Jul 24 '12 at 12:11
  • You should know that many times the suspected "attacks" are actually bots that misbehave and are accessing too many URLs on your server at once and crash your server, the mod-status I mentioned in my reply should help identifying that. Very rarely someone has something to gain from intentionally attacking your server. Viruses and scripts might force access by FTP and SSH, I recommend limiting that. – adrianTNT Jul 24 '12 at 12:27
  • 1
    DROP All would seem to be the way to go to best do what you're asking. But it really does seem like you're not quite "getting it." You just can't block a DoS attack at the server. By the time it's reached you, you're already being DoSed. – HopelessN00b Jul 24 '12 at 12:34

Here are some rules I use:

# Reject spoofed packets
iptables -A INPUT -s -j DROP
iptables -A INPUT -s -j DROP
iptables -A INPUT -s -j DROP
iptables -A INPUT -i eth0 -s -j DROP

iptables -A INPUT -s -j DROP
iptables -A INPUT -d -j DROP
iptables -A INPUT -s -j DROP
iptables -A INPUT -d -j DROP
iptables -A INPUT -s -j DROP
iptables -A INPUT -d -j DROP
iptables -A INPUT -d -j DROP
iptables -A INPUT -d -j DROP

# Stop smurf attacks
iptables -A INPUT -p icmp -m icmp --icmp-type address-mask-request -j DROP
iptables -A INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP
iptables -A INPUT -p icmp -m icmp -j DROP

# Drop all invalid packets
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP

# Drop excessive RST packets to avoid smurf attacks
iptables -A INPUT -p tcp -m tcp --tcp-flags RST RST -m limit --limit 2/second --limit-burst 2 -j ACCEPT

# 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
| improve this answer | |
  • 4
    Bart, doesn't 'iptables -A INPUT -s -j DROP ' kill memcached? – alfish Jul 24 '12 at 13:24
  • 1
    I see you have the rfc1918 address, presumably not 192.168 because you are using it. You have link-local. You might add to your list TEST-NET( from rfc3330, benchmarktest(198.18.0/25) from rfc2544, protocol assignment(, testnet2(198.51.100/24) and testnet3(203.0.113/24) from rfc5736 and 5737 and finally carrier grade nat(100.64/10) from rfc6598 – jrwren Feb 24 '14 at 14:27

So appreciate your bullet-proof rules.

You should contact your ISP and have the traffic dropped on the backbone before it hits you. If you're at the point where your firewall has to drop the traffic, then it's already consuming your available bandwidth and using your system's resources.

That's the only "bulletproof" way.

| improve this answer | |
  • I don't care much about bandwidth consumption, as I have a dedicated port and the attacks are usually not so big, as I said. – alfish Jul 24 '12 at 11:57
  • 2
    Many common DoS attacks look to saturate a server's connection to the Internet. If you're seeing a different kind of attack, like one that aims at resource exhaustion, then you should be much more specific in your question and the answer likely still won't involve iptables. – MDMarra Jul 24 '12 at 12:01
  • 3
    This answer is perfectly valid, whoever marked this answer down hasn't got a clue what he's talking about. – Lucas Kauffman Jul 24 '12 at 12:37

I use IPtables in order to limit the access to FTP and SSH, I just allow my computer's IPs to connect to the server. I cannot say I had DOS attacks problems.

/sbin/iptables -A INPUT -p tcp --dport 22 -s -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -s -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j DROP

/sbin/iptables -A INPUT -p tcp --dport 21 -s -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 21 -s -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 21 -j DROP 

These rules allow access to ports 22 and 21 on two different IPs. You can probably add the MySQL port of your db server and that way block other clients from connecting directly to your server.

Edit: when server is overloaded I find it helpful to see Apache "mod-status" statistics, the output looks like this: http://www.apache.org/server-status you can see all site visitors , spiders, url requests, etc. Implementation takes under 1 minute: http://httpd.apache.org/docs/2.2/mod/mod_status.html

| improve this answer | |
  • How does this prevent a DoS attack? It'll help eliminate brute-force attacks on those protocols, but won't do much to stop a DoS. – MDMarra Jul 24 '12 at 12:32
  • It was more of a general or first-thing to do in order to secure the server (the ftp/ssh filter), then the server-status will help identify the "attack" (by http) because usually it is just a bad web crawler and not an attack. And an iptables rule should also help filtering/blocking his database port requests too. – adrianTNT Jul 24 '12 at 12:36

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