Difference between revisions of "Iptables (1.4)"

Revision as of 00:18, 3 May 2014

I use shell scripts to load my firewall, your mileage may vary on specifics.

I see a lot of people making 'strict' firewalls. Running two major forums with extremely committed userbases (i.e. people who let me know if things go wrong for themselves or their friends), I know for a fact that if your firewall is draconian, you will be blocking valid, perfectly harmless traffic from legitimate visitors to your website. This configuration still occasionally trips on valid users, but it is rare, they are still able to use the site, and the situation in prevents (opening a crazy number of connections) is a genuine problem that is worth addressing.

Important Notes

I explain some of these issues in the scripts proper, but I think they deserve more attention.

limit vs. hashlimit vs. connlimit

The short of it is, if you are using limit in your IPTables ruleset, you are probably doing it wrong, and it is not doing what you think it is doing. I have seen some people bragging about their rules, and limiting SYN packets to 20 per second - or less.

This means that, if any combination of hosts, anywhere on the Internet, sends the victim 20 SYN packets per second, no one else can open a TCP connection until the table holding that rule gets cleared. Limit is just that, a limit in total across the entirety of the system.

What most people think limit works like is a proper hashlimit declaration. I go into more detail in the script itself, but if you are only skimming to see what to grab for your own firewall rules, do not skip the hashlimit section. It will do you good.

For connlimit, while the documentation states that it is 'parallel connections', I have a suspicion that when IPTables breaks, what it considers to be a connection is not necessarily what the other side thinks is a connection. Be careful about setting it too low, even for a small site. The 256 to report/512 to block is based on what my members have managed to generate individually, and it was nothing special with how much they actually used my site, nor was it a lot of people behind a NAT or even one person using multiple browsers. One person, one browser, 300 conntrack entries. For awhile, AoL proxies were a problem, though this has not been an issue in years.

I tend to think of connlimit as a means to mitigate a single-user DOS. Better than nothing.

INVALID

Dropping all INVALID packets also drops a lot of packets from valid users of your services, and if someone has a poor connection to your website, this will make that problem even worse. The rules I've set cover the overwhelming majority of legitimate goofs that may crop up - please consider accepting these special NEW cases rather than dropping INVALID cases.

ICMP

For some reason, pings now have an established connection. I've accounted for this below, but outright accept RELATED ICMP incoming requests, which covers every non-ping ICMP request that you will see incoming.

UDP

Most UDP traffic gets dropped by default here. This includes traceroutes. Windows will fall back to ICMP, but you may need to let *nix users know they should use the -I switch. The ICMP rules have been loosened to make this go smoothly.

Preparation

The first thing you should do, is make a reset script that runs at a regular interval through cron or somesuch. This way, if (or rather when), you make a mistake, you only have to wait a short while rather than digging out KVM details. Or worse, paying your host for it if you do not have a virtual solution.

Adjust the path as needed, of course.

iptreset.sh

#!/bin/sh
/sbin/iptables -F
/sbin/iptables -X
/sbin/iptables -t raw -F
/sbin/iptables -t raw -X
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -P OUTPUT ACCEPT
/sbin/ip6tables -F
/sbin/ip6tables -X
/sbin/ip6tables -t raw -F
/sbin/ip6tables -t raw -X
/sbin/ip6tables -P INPUT ACCEPT
/sbin/ip6tables -P FORWARD ACCEPT
/sbin/ip6tables -P OUTPUT ACCEPT

Using these scripts

If you're not using the tools in e.g. CentOS to save/restore rules and the associated tracking entries, you will probably want to load them at bootup. Add

pre-up /root/firewall.sh

(or whatever you named/placed it) to your main ipv4 interface declaration in /etc/network/interfaces, and

pre-up /root/firewall6.sh

to your main ipv6 interface declaration, likewise.

@@ Line 9: / Line 9: @@
 === limit vs. hashlimit vs. connlimit ===
-The short of it is, if you are using ''limit'' in your IPTables ruleset, you are probably doing it wrong, and it is not doing what you think it is doing. I have seen some people bragging about their rules, and limiting SYN packets to 20 per second.
+The short of it is, if you are using ''limit'' in your IPTables ruleset, you are probably doing it wrong, and it is not doing what you think it is doing. I have seen some people bragging about their rules, and limiting SYN packets to 20 per second - or less.
 This means that, if any combination of hosts, anywhere on the Internet, sends the victim 20 SYN packets per second, no one else can open a TCP connection until the table holding that rule gets cleared. Limit is just that, a limit in total across the entirety of the system.
@@ Line 15: / Line 15: @@
 What most people think limit works like is a proper hashlimit declaration. I go into more detail in the script itself, but if you are only skimming to see what to grab for your own firewall rules, do not skip the hashlimit section. It will do you good.
-For connlimit, while the documentation states that it is 'parallel connections', I have a sneaking suspicion that when IPTables breaks, what it considers to be a connection is not necessarily what the other side thinks is a connection. Be careful about setting it too low, even for a small site. The 256 to report/512 to block is based on what my members have managed to generate individually, and it was nothing special with how much they actually used my site, nor was it a lot of people behind a NAT or even one person using multiple browsers. One person, one browser, 300 conntrack entries. For awhile, AoL proxies were a problem, though this hasn't been an issue in years.
+For connlimit, while the documentation states that it is 'parallel connections', I have a suspicion that when IPTables breaks, what it considers to be a connection is not necessarily what the other side thinks is a connection. Be careful about setting it too low, even for a small site. The 256 to report/512 to block is based on what my members have managed to generate individually, and it was nothing special with how much they actually used my site, nor was it a lot of people behind a NAT or even one person using multiple browsers. One person, one browser, 300 conntrack entries. For awhile, AoL proxies were a problem, though this has not been an issue in years.
 I tend to think of connlimit as a means to mitigate a single-user DOS. Better than nothing.