0

I have been reading all day about IP tables, how the rules work, sets of rules for basic webservers, etc. Now I`m trying to configure my webserver with IPtables using this thread as a starting point: Good iptables starting rules for a webserver?

Since I don't want to just copy paste anything that works I`m adding rule by rule and considering every rule as to why I would need it. I came to discover that I basically needed access via port 80, 443, 22, 587 (mailserver).

However, I cannot access my site via the domain after adding these rules. So I compared to the thread I mentioned and I discovered I did not have this rule:

# Allow traffic already established to continue 
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

So I added this rule to test things, and all of the sudden I could access my website. Then I thought, maybe that's because I already had been connecting to the website from this IP, but if I connect through other IP`s / networks I still can access my website, dependent on that rule.

Because I want to understand this, I don't really get why access to my site is dependent on that rule. There is already a rule allowing incoming traffic via port 80 (which is the port my webserver runs on) but appearantly just that rule is not enough? PS, this is the rule I have at the moment to open up port 80:

target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:http

I hope someone can shed some light about that rule and why I can access my site with that rule and not without.

EDIT: I do get why one would want to add this rule, I reckon it would speed up things as it does not have to go through all the other rules anymore but I just want to understand why in my case it is critical to have this rule in order to access my site..

Thanks!

Community
  • 1
Marcel
  • 119
  • 4
  • 1
    Rule order matters in `iptables`, so there is no point in showing us one rule and asking why it's not working. You will need to cut and paste the entire output of `iptables -L -n -v` into your question for us to help. – MadHatter May 24 '15 at 09:36
  • Hi, thanks for your comment! I now only have the rules for the ports I described (80, 443, 22, 587) as accept rules, and the last rule is the state established rule. There are no reject rules and no other rules at the moment. – Marcel May 24 '15 at 10:18
  • Don't tell us - *show* us. Showing us the failure you describe would be a good idea, too. – MadHatter May 24 '15 at 22:27
  • Alright, here's a pic: http://i57.tinypic.com/ra6x6g.jpg , please note policy is accept now and with that, it works. If I change policy to drop, it does not work. I already accepted an answer because I'm going for a statefull firewall and it works when I go with that, however I'm still not sure why the rules from the image won't work being a stateless firewall. But I think it has to do with me knowing too little about statefull vs stateless firewalls atm. If you got anything to add having this image as info, please share because I want to learn as much as possible about this! – Marcel May 25 '15 at 09:13
  • PS: not sure about what you mean with 'showing the failure'. Basically what happens is, I cannot access the site (after like 5 - 10 seconds of loading) and Chrome is saying 'Err, connection refused'. I can access the site fine changing the policy to accept or adding the statefull rule for established connections. PS2: as you can see in the image there are a few new rules now for ping and DNS purposes – Marcel May 25 '15 at 09:15
  • Since you've decided the question has been answered to your satisfaction, I won't say much more save to thank you for accepting an answer - the community hopes that all question authors will do that, but some don't get around to it. By *showing the failure*, I meant putting into your question an example of what you tried to do, what you expected to see, and what you actually got. Telling us these things is very helpful, as sometimes the wrong conclusions are drawn from a diagnostic; **showing** us these things is even more helpful, as sometimes people aren't testing what they think they are. – MadHatter May 25 '15 at 09:32
  • I see! Thanks mate. In my scenario the failure was pretty simple, opening a site and not seeing anything or opening a site and seeing the website, depending on a firewall rule :) Thanks for your time anyway since I`m going with the statefull firewall I have it up&running now. – Marcel May 26 '15 at 00:35

2 Answers2

3

iptables is a firewall statefull, as opposite as stateless which means it identifies connections as streams, associated with states. the connection is first initiated (NEW state), (SYN packet for tcp, or first packet for UDP). Then, a decision is taken (BLOCK, DROP, or ACCEPT). This is what you created before the ESTABLISHED rule. If a packet is accepted on a NEW state, the packets belonging to the same connection won't necessary be (it's not the NEW state anymore. For tcp, it would be a SYN-ACK, ACK, Push, Push-ACK, ... packets). These packets belong to the state ESTABLISHED. Usually, ESTABLISHED packets are accepted to make it work.

If you don't activate this rule, you will have a stateless firewall. To make it work, you would need to accept every packets corresponding to your chosen ports. This can lead to security issues (think at client firewalled trying to reach a webserver; every packets going to webserver port 80 or coming from webserver port 80 would be accepted (for the webserver answer). If someone spoof webserver IP address, then it completely bypass the firewall, as long as it tries connecting with source port 80.

RELATED is not necessary here. Its corresponds to traffic not belonging to the connection, but sometimes usefull:

  • when a port is closed, a ICMP-port unreachable is emitted, this packets does not belongs to the connection, but may be usefull
  • for protocols such as FTP whose data port is chosen inside control traffic; RELATED authorizes the data traffic, even if no explicit rule is associated to it.

More on that here

philippe
  • 2,131
  • 4
  • 30
  • 53
  • Wow, thanks so much for this information. It is a lot of new information to take in but it is definitely going to help me understand how it works and why it behaves as it is behaving right now. – Marcel May 24 '15 at 10:20
  • No worries :) glad it can help! – philippe May 24 '15 at 11:07
0

Confused me for so long, leave for future reference.

Quote from https://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html:

NAT: This table is slightly different from the `filter' table, in that only the first packet of a new connection will traverse the table: the result of this traversal is then applied to all future packets in the same connection.

So this --state ESTABLISHED,RELATED is not in effect in nat table.

And be aware if you use conntrack -D after setting up nat table, this will make iptables think next packet it sees is that "first packet of a new connection"(matchable by --state NEW), causing the middle of one connection to be NAT in reverse direction if you have relative rules which highly probably will break established connection.

imoc
  • 53
  • 4