2

I've encountered some iptables configuration with incoming rules starting with a rule that allows all TCP packets with ACK flag, followed by all the obvius service port rules. Why is that? The server still responds with this rule disabled. Is there a useful acceptance of ACK for other ports then the served services ones?

dronus
  • 1,178
  • 1
  • 13
  • 15

1 Answers1

0

The person that engineered the firewall is probably the best person to answer the why is this here? question.

If I take a stab at finding a useful use case:

Premise: TCP packets with the ACK flag are common

Premise: Will stop evaluating at the matching first ACCEPT, DROP, REJECT, etc.. rule

Assumption: ACK packets are largely harmless

#Accept any TCP Acknowlegements and let the OS / Service handle any issues
-A INPUT -m tcp -p tcp --tcp-flags ACK -j ACCEPT

-A INPUT -m tcp -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m tcp -p tcp -m state --state NEW --dport 80 -j ACCEPT
...
...
-A INPUT -j DROP

Conclusion: The ACK statements may have been added to increase Firewall performance.

I don't have any benchmarking to back up such an assumption.

Daniel Widrick
  • 3,488
  • 2
  • 13
  • 27
  • Well, the engeneer is possible 'seen that somewhere in the internet' in this case I guess. However, your explanation give me the feeling that there is no magic effects in this and this is simply for performance as you said, or maybe a relic. – dronus Feb 27 '14 at 19:45
  • @dronus That "ACK packets are largely harmless" isn't really a valid assumption. This creates a hole in the firewall big enough to portscan through; nmap even has a flag to do an ACK scan which this rule will permit. – Michael Hampton Feb 27 '14 at 20:55
  • So the config done that way out of what reason whatever, is flawed and should not be used? – dronus Feb 27 '14 at 21:01
  • It is not inherently 'flawed'. It depends on the use case. If performance is a higher priority than security, it may have merits. If security is important, it has flaws. The world will never be black and white. – Daniel Widrick Feb 27 '14 at 23:45