Question

The test environment is:

2 Operating Systems ubuntu server 10.04 installed on VirtualBox

iptables v1.4.4

ip_conntrack module loaded

these are my test rules:

    $IPTABLES -A INPUT -p TCP -m state --state NEW -j LOG --log-prefix "[-IPT-]NEW:"
    $IPTABLES -A INPUT -p TCP -m state --state ESTABLISHED -j LOG --log-prefix "[-IPT-]ESTABLISHED:"
    $IPTABLES -A INPUT -p TCP -m state --state RELATED -j LOG --log-prefix "[-IPT-]RELATED:"
    $IPTABLES -A INPUT -p TCP -m state --state INVALID -j LOG --log-prefix "[-IPT-]INVALID:"

using

hping3 -c 1 192.168.0.1 -p 80 [flags combination]

I get:

no flag     INVALID
syn         NEW
ack         NEW
rst         INVALID
fin         INVALID
syn ack INVALID
syn rst INVALID
syn fin INVALID
ack rst INVALID
ack fin INVALID
rst fin INVALID
syn ack rst INVALID
syn rst fin INVALID
ack rst fin INVALID
syn ack rst fin INVALID

I’ve read more tutorials that say the first packet seen by netfilter has to be NEW(in the user land). I don’t understand if there is something in my computer that doesn’t work.

Then, on the internet, there are a lot of rules that filter considering both connection state and tcp flags. Are all these wrong? The reason is quite simple: if they are dropping packets that matches new and ! –syn, the result is painful…a lot of packets pass through the “firewall”(if it can be named so)

Is it possible that newer versions of iptables have a different behavior?

please, can you confirm me if you are getting the same result on yours computers?
thx, I’ll appreciate!

Answer 1

Looking at your results, they’re pretty much how I would have expected. Some of the decisions have been taken based on the conntrack module, others I believe based on allowed behaviour (i.e. flag combinations) in TCP RFC.

When there are no flags, that is completely invalid as per the RFC.

I believe that you know the reasonSYN is categorised as NEW and that’s very much as expected 🙂

ACK is categorised as new because the conntrack module (afaik) doesn’t begin tracking a connection until the third step of the 3-way handshake.

Both RST and FIN are only valid as part of a live, currenty TCP connection so this rejection is based on the conntrack module tracking the connection here.

When you combine the TCP flags, as a “new” packet, in some cases (e.g. the ere should be a previous connection) whereas in others they are all just plainly invalid combinations (again) as per the RFC. For example, a TCP segment should never have the RST and FIN flags set, for ACK and RST to be set there should be a current TCP connection already set up in order for something to be torn down ( again as you alluded to the conntrack module is tracking the connection here).

Have you tried running the same test on Ubuntu 12.04 or RHEL? I will see if I can try later but I believe your computer is working as expected. Nice test though 🙂

Then, on the internet, there are a lot of rules that filter considering both connection state and tcp flags. Are all these wrong?

I don’t believe so, I think everyone’s use case is different and by combining both, people are generally being cautious. However, most folk don’t do as much testing as you have (kudos) nor do all have the understanding.

Is it possible that newer versions of iptables have a different behavior?

No, not as far as I’m aware.