Opinions about firewall rules for vps [closed]

Question

I just switched to a new vps, which I installed Linux and I wish to harden it a bit by applying firewall rules using iptables. I use Firewall Builder to create my rules and I would like some suggestions or your opinion about it.

The vps comes with one NIC with public IP (marked as outside in the rules).

Specifically, I would like your opinion about:

• The order of rules
• About inclusion/exclusion of some private IP ranges (or maybe delete rule #1 at all)
• Whether the rules must be stateless or not (watch for new connections only)
• Rules #4 and #5 use the limit module of iptables to mitigate flood of RST packets and DOS attacks. Whatever I tried, rule #5 does not seem work and is disabled as shown by the red X in the rule number. I used the Apache bench tool to create hundreds of connections to the server and they all come through, so I suppose the rules does not work. Rule #4 might also not work for the same reason.
• Anything else you might seem important to include or delete

The compiled rule #5 is:

$IPTABLES -N In_RULE_5
$IPTABLES -A INPUT -i eth0  -p tcp -m tcp   --tcp-flags ACK,RST,SYN,FIN SYN  -m limit --limit 3/second --limit-burst 5 -j In_RULE_5
$IPTABLES -A In_RULE_5  -j LOG  --log-level info --log-prefix "SYN FLOOD: "
$IPTABLES -A In_RULE_5  -j ACCEPT

This is the screenshot of the policy rules as shown in Firewall Builder.

Answer 1

1) The order of rules:

Looks pretty ok; there's not that many, probably doesn't make that much difference.

2) About inclusion/exclusion of some private IP ranges (or maybe delete rule #1 at all)

Specifically I wouldn't exclude 127.0.0.0/8. It will have no effect AFAIK (I'd expect the kernel to drop any packets with that source address arriving on an actual external network interface), and just confuses things a bit. Dropping the others is fine, IFF your VPS only has a public IP, and isn't (like AWS, for example) on an RFC1918 network, with NAT doing magic to give the appearance of a public IP.

3) Whether the rules must be stateless or not (watch for new connections only):

A fascinating question. Short answer: probably not, because then you'll need to pair each inbound rule with an outbound rule allowing the reply packets to make it out (also a stateless rule, but with the source port being,, for example to match your Rule 7, ports 22, 80, and 443. However: stateful rules for inbound traffic can be considered harmful under high traffic scenarios, where the firewall state tracking becomes a bottleneck. If you are only ever expecting low-medium traffic, and are ok with it all falling down under a DoS (which is likely anyway in a single-server situation, where a DoS could easily find the limiting factor to be CPU/memory, not concurrent connections), then don't worry too much about going stateless. I wish I could find a citation for this (there's an epic rant about it somewhere, but it's not coming to hand)

4) Rule #5 (and presumably #4 also) That rule is being hit, and up to the rate limit, the packets are being accepted. After the rate limit is exceeded, that rule is not hit, so processing proceeds to the later rules in the chain, which then hits Rule 7, permitting the traffic. I think what you want is to have another rule immediately after rule #5 that then drops any packets with just SYN set. If the rate limit rule is exceeded, processing will hit that rule and the packet will be dropped. I recommend you try this carefully first, perhaps adding port 80/443 as destination services as well to those rules, so you don't lose SSH access if you get it wrong :)

5) Other comments:

Maybe put the ICMP together, or rather use the built-in "Useful ICMP" group instead of the drop of bad ones and the allow of "any ICMP".