I have been seeing many people using the ESTABLISHED and RELATED flags together to ACCEPT traffic through once a connection was previously accepted (see Allowing Established Sessions).
Say I setup my firewall with the following rules:
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -d x.x.x.x --syn -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp -s x.x.x.x --dport 22 -d x.x.x.x --syn -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED,RELATED -m tcp ! --syn -d x.x.x.x -j ACCEPT
-A INPUT -i all -p all -j REJECT
I expect any new connections to be blocked by the last rule unless it is to port 80 or port 22. However, for port 22, I limit connections to one input IP address (say my home office).
Then I expect the rule with --state ESTABLISHED,RELATED
to only accept traffic that previously connected using the rule with port 80 or port 22.
From what I can see in my firewall counters, though, it feels like if I have both ESTABLISHED and RELATED, any traffic on TCP can be sent to the server...
In my tests, say I have another HTTP server on port 8080, I first connect to the clearly allowed port 80, then, somehow I can connect and send a GET and receive the respond on port 8080, even though it is not open.
Similarly, if I connect on port 22, then any other TCP port currently open and listening on 0.0.0.0 is accessible. My concern is that this means someone who connects to port 80 now has access to port 22 since the RELATED allows it (assuming port 80 is opened, then a new connection is made to port 22).
Am I correct? I was thinking to change the rule to this instead:
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED -m tcp ! --syn -d x.x.x.x -j ACCEPT
(i.e. no RELATED state, only ESTABLISHED)
I also thought that the ! --syn
would block new connections from being established using that rule, but that too seems incorrect...
Let me suppose the following 3 things in your setup :
-A INPUT -i all -p all -j REJECT
is 0AFAIK the
-i
parameter does not have a key word likeall
, so it is considered as an interface name. There is no error while loading this rule because it is legal to create rules on interfaces that do not exist yet, or that are not up. So your last rule does not catch anything, and as your default policy isACCEPT
, all packets that do not match any rule are accepted.If you want what you expect, do not mention any interface, and then the rule will be applied to all available interfaces :
This is also a good example for setting a default policy of DROP on the table (but at least whitelist yourself before, of course) :
Hope this will solve your problem. Let us know if the packet counter or the default policy is not as I supposed.