1

On several server systems, I encountered two dominant styles of iptables firewall configurations:

The first one is blocking every INPUT except the ports of provided services like HTTP.

The second one is blocking every INPUT except packets for connections in NEW state for several services, with elaborate settings and all packets for connections in ESTABLISHED state. It is also blocking all OUTPUT packets except those of connections in ESTABLISHED state.

What kind of security does the latter provide that the first simple solution does not manage?

Of course it may be useful to block users using outgoing ports for their reason, but if I do not need to protect the server from it's own users, but only from outside threats, are both methods identical, or will the second still provide benefits?

dawud
  • 14,918
  • 3
  • 41
  • 61
dronus
  • 1,128
  • 1
  • 13
  • 15

2 Answers2

9

The first type of firewall you have described is stateless. It is simplistic and does not keep track of connections; it just checks the given rules as fast as it can. This is not generally recommended anymore except in circumstances where firewall performance is a significant bottleneck, as it allows significantly more traffic than is obvious from first glance. Particularly, traffic which isn't associated with a legitimate connection can pass through such a firewall.

The second type of firewall is stateful. It is capable of tracking connection states, determining whether a particular packet is associated with a known-good connection, and accepting or rejecting it. It is much better at catching invalid traffic than a stateless firewall. Without some overriding concern, all firewalls should be stateful for maximum possible security.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • What may happen if invalid pakets, not caught by an 'stateful' firewall, hit an application? The TCP/IP stack is managed by the OS I guess and would be resiltent to invalid traffic like the one that would be denied by the firewall as well? – dronus Feb 20 '14 at 01:01
  • I could send an ACK packet to your port 80 instead of a SYN, and it would go right through. Of course that's no way to start a TCP connection so it would send back an RST. This means, among other things, I can portscan you even through your "firewall". A stateful firewall could drop the INVALID packet. – Michael Hampton Feb 20 '14 at 01:10
  • So the default handling of 'bad' connections of the TCP/IP stack is not configurable and does not compete with iptables rules? Or is this both the same and iptables are integrated in the stack, just modifying the default behaveour? – dronus Feb 20 '14 at 02:10
  • How protocols are supposed to react to invalid packets is defined in their respective RFCs. The whole point of a firewall is to keep things out, in part so that a malicious person cannot exploit bugs or security issues in the implementation. – Michael Hampton Feb 20 '14 at 03:08
  • Does 'protocol' mean http has to handle bad packets? Aren't they denied at the TCP/IP level, the same thing iptables operate on? – dronus Feb 20 '14 at 03:32
  • 2
    Stop. [Go read the RFCs](http://serverfault.com/a/477468/126632) for TCP and IP. Learn how they work. A comment thread is really not a good place to explain basic stuff like this. – Michael Hampton Feb 20 '14 at 03:33
0

It generally comes down to poor planning on the former description. Reactive security resolution/putting out fires. I.e., "Oh shit, they're hammering us on 123, lock it down!" or more appropriately, blacklisting. The latter is a form of whitelisting(best practice) and usually comes down to locking things down through implicit exclusion and opening up what you need as required.

Which one you chose usually comes down to your environment/style.

Publiccert
  • 1,110
  • 1
  • 8
  • 22