Understanding iptables chains in linux (in socket terms)

Question

Is it true to say:

A) OUTPUT chain is for the packets that are "generated" by the machine itself i.e. OUTPUT chain affects connect() function.

B) INPUT chain is for packets that are "addressed to" and will end at the machine i.e INPUT chain affects bind() and listen() functions.

If yes, why would you want to control these features on a firewall? A firewall is not a web-server which listens to port 80 or a client which connects to that port.

Am I right to assume these chains exist only to address the needs of a multi-purpose machine (which is, say, firewall and web-server at the same time)?

Answer 1

Your statements are true, but they are imcomplete.

Just have a look at the whole picture: http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

This may answer your present and many futur questions.

Many people want a firewall because:
- the computer acts as a router, so blocking some streams is a desired function
- the computer is operated by humans. And humans are not perfect. So using a firewall is cool in case you forgot to uninstall some server, or in case a server is buggy (for example the "regular" ntpd which always want to listen to every interfaces, even when you ask him not to answer)
- netfilter can be used to redirect ports (to another port, or to another computer)
- netfilter can be used to allow only some IPs to access the web server, or to implement port-knocing, etc
- and a lot of other things

Answer 2

The INPUT and OUTPUT chains do work as you describe.

Even a firewall machine isn't a "multi purpose" computer it's good practice to set its INPUT and OUTPUT chains to only allow ingress and egress of explicitly desired traffic. If you have the discipline to use these chains on "multi purpose" computers, too, you gain an advantage when an attacker attempts to, for example, use an outbound HTTP connection to pull down 2nd-stage exploit code to a server he's attacking.

Answer 3

The INPUT/OUTPUT chains provide a large measure of security. Many applications dont have fine grained control over where they accept connections from (or where they can connect to), so we need a general purpose way of controlling this.

Additionally there are many attacks/exploits out there which iptables can mitigate. Say a very simple connection flooding attack comes in where someone opens up a ton of connections all at once. Your application's incoming connection queue could fill up causing legitimate connections to fail. Iptables can prevent this from happening.
There is a generally accepted minimum list of iptables rules that should be implemented on all servers for security. See here (there is a more 'official' source of these rules, but I cant remember where it is).

Answer 4

Well, instead of using OUTPUT chain you could "just" make sure that:

• none of software on your firewall is doing connect() out of your control
• but how would you make sure that also:
  • kernel is not responding when someone is trying to connect to a non-listening port
  • none of your software is sending raw/ICMP/IGMP/other packets out of your control

Instead of using INPUT chain you could "just" make sure that:

• none of software on your firewall is doing bind() or listen() out of your control
• but how would you make sure that also:
  • your software and your kernel is not processing malformed/ICMP/IGMP/other packets that you don't want them to process

TL;DR iptables provide you with a basic Mandatory Access Control (MAC) in the otherwise Discretionary Access Control (DAC), or even completely uncontrollable, field.