Explanation of 2 Rules

Explanation of 2 Rules

[Thomas Luening]

Hello @ all

Can anybody help me to explain und understand this 2 statements?
nft add rule ip filter input "tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg drop"
nft add rule ip filter input "tcp flags & (fin|syn|rst|ack) != syn ct state new drop"

That's what I think I understood....


TCP-Header first statement:
Bit          11  12  13  14  15  16
Type        URG ACK PSH RST SYN FIN
               0   0   0   0   1   0

             URG ACK PSH RST SYN FIN
XMAS          1   1   1   1   1   1

tcp flags & (fin|syn|rst|psh|ack|urg)  111111   = All flags are set (?) in Packet-Header, because  of   '&' = AND
fin|syn|rst|psh|ack|urg                111111   = Comparison to preprocessor directives = combined with '|' = OR

The result must be 111111 == 111111 to drop. Is that correct?



The second statement:
             URG ACK PSH RST SYN FIN
syn-chk       0   1   0   1   1   1

tcp flags & (fin|syn|rst|ack)           010111  = To much flags are set...
syn ct state new                                = ...because syn-flag is set and ct-state = new

The result must be (10111 != 000010 and ct new) to drop. Is that correct?


Thank you, best regards
Tom

Re: Explanation of 2 Rules

[Thomas Luening]

Hi David,

Am 22.08.20 um 21:12 schrieb david@hajes.org:
 > why don't you simplify and just DROP INVALID?
 >
 > INVALID drops any possible incorrect combination. You don't need to write anymore as in iptables

thank you for your answer, but that makes it a little more complicated for me now. Now my question has 2 aspects.

The first one is still the syntax question. Detached from the logic (invalid) I would still like to know if I interpreted the 
syntax of the statement correctly.

The second (new) aspect is the ct-state "invalid". To help, I looked at 4 presentations by F. Westphal, 1 by P. Ayuso, 1 by R. 
Spenneberg, plus man-pages and lots of web sites. In fact, I can't find any better explanation of what marks a package as 
invalid than in linuxtopia:

https://www.linuxtopia.org/Linux_Firewall_iptables/x1347.html
"The INVALID state means that the packet can't be identified or that it does not have any state. This may be due to several 
reasons, such as the system running out of memory or ICMP error messages that do not respond to any known connections. 
Generally, it is a good idea to DROP everything in this state."

Well, why is an xmas packet invalid, if it can be identified and has a status (even several, depending on the view/query).

BTW, I've been using "invalid" for a long time, but at the moment I can't find out if "state invalid" actually marks xmas packages.

Best Regards, Tom

Re: Explanation of 2 Rules

[kfm]

On 24/08/2020 10:39, Thomas Luening wrote:
> Hi David,
> 
> Am 22.08.20 um 21:12 schrieb david@hajes.org:
>  > why don't you simplify and just DROP INVALID?
>  >
>  > INVALID drops any possible incorrect combination. You don't need to 
> write anymore as in iptables
> 
> thank you for your answer, but that makes it a little more complicated 
> for me now. Now my question has 2 aspects.
> 
> The first one is still the syntax question. Detached from the logic 
> (invalid) I would still like to know if I interpreted the syntax of the 
> statement correctly.

Your interpretation appears correct to me.

> 
> The second (new) aspect is the ct-state "invalid". To help, I looked at 
> 4 presentations by F. Westphal, 1 by P. Ayuso, 1 by R. Spenneberg, plus 
> man-pages and lots of web sites. In fact, I can't find any better 
> explanation of what marks a package as invalid than in linuxtopia:
> 
> https://www.linuxtopia.org/Linux_Firewall_iptables/x1347.html
> "The INVALID state means that the packet can't be identified or that it 
> does not have any state. This may be due to several reasons, such as the 
> system running out of memory or ICMP error messages that do not respond 
> to any known connections. Generally, it is a good idea to DROP 
> everything in this state."
> 
> Well, why is an xmas packet invalid, if it can be identified and has a 
> status (even several, depending on the view/query).

I am by no means a Netfilter hacker but I think that I can shed some 
light on this. I didn't see David's post but you should know that the 
TCP connection tracking code contains a TCP state transition table [1], 
as well as a table of valid flag combinations [2]. The first is harder 
to digest, so here are a few examples of how a decision can be made 
based on its contents. Consider the lines that read as follows:

/*           sNO, sSS, sSR, sES, sFW, sCW, sLA, sTW, sCL, sS2   */
/*synack*/ { sIV, sIV, sSR, sIV, sIV, sIV, sIV, sIV, sIV, sSR },

Now imagine that nf_conntrack observes a SYN-ACK packet completely out 
of the blue. It has no relationship with any existing flow. As far as 
the state machine is concerned, the present conntrack state to be 
ascribed to the packet is NONE (sNO). The first element of the tuple has 
a value of sIV (INVALID), dictating that it is not possible to 
transition to any other legitimate state. Instead, the packet must be 
considered as invalid.

Now consider the second element. If the SYN-ACK packet can be associated 
with an existing conntrack table entry that is presently in a state of 
SYN_SENT (sSS), then, again, the packet may not incur a transition to 
some other legitimate state. Instead, it must be considered as invalid. 
Why? Because it is not legal for the peer to send SYN-ACK immediately 
after SYN.

And so it goes on. All of this is supplemented by a general check which 
prevents packets with obviously incorrect flag combinations from being 
accepted (before the state transition table is consulted).

> 
> BTW, I've been using "invalid" for a long time, but at the moment I 
> can't find out if "state invalid" actually marks xmas packages.
> 
> Best Regards, Tom

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_proto_tcp.c?h=v5.8#n110

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_proto_tcp.c?h=v5.8#n700

-- 
Kerin Millar

Re: Explanation of 2 Rules

[Thomas Luening]

Hi Kerin, hi David

Am 26.08.20 um 08:49 schrieb kfm@plushkava.net:
> Your interpretation appears correct to me.

Thank you for your Answer! :-)

> 
> /*           sNO, sSS, sSR, sES, sFW, sCW, sLA, sTW, sCL, sS2   */
> /*synack*/ { sIV, sIV, sSR, sIV, sIV, sIV, sIV, sIV, sIV, sSR },

That was a great help, but it is really heavy stuff. It's hard to work through these tables and to understand them in context. 
While testing I found that the xmas-statement is a rather weak protection, because it seems to check for an explicit match of 
all given flags. If I use the flags in various combinations...

nmap 10.0.1.200 --scanflags "URG ACK PSH RST SYN FIN" -p 631

...it is noticeable, that some Packages was not recognized at all. But the check for 'invalid' was always successful. 
Conclusion: The xmas-statement is not a good choice.

I believe that the problem can be closed. Thanks again for your help.

Best Regards, Tom

Re: Explanation of 2 Rules

[kfm]

Hi Thomas,

On 26/08/2020 17:01, Thomas Luening wrote:
> Hi Kerin, hi David
> 
> Am 26.08.20 um 08:49 schrieb kfm@plushkava.net:
>> Your interpretation appears correct to me.
> 
> Thank you for your Answer! :-)
> 
>>
>> /*           sNO, sSS, sSR, sES, sFW, sCW, sLA, sTW, sCL, sS2   */
>> /*synack*/ { sIV, sIV, sSR, sIV, sIV, sIV, sIV, sIV, sIV, sSR },
> 
> That was a great help, but it is really heavy stuff. It's hard to work 
> through these tables and to understand them in context. While testing I 
> found that the xmas-statement is a rather weak protection, because it 
> seems to check for an explicit match of all given flags. If I use the 
> flags in various combinations...
> 
> nmap 10.0.1.200 --scanflags "URG ACK PSH RST SYN FIN" -p 631
> 
> ...it is noticeable, that some Packages was not recognized at all. But 
> the check for 'invalid' was always successful. Conclusion: The 
> xmas-statement is not a good choice.

I forgot to say that there is a sysctl which, if enabled, will log 
invalid packets. You can enable it by running:

   sysctl -w net.netfilter.nf_conntrack_log_invalid=1

Packets that fail the general flag combination check will then trigger a 
message containing the substring "invalid tcp flag combination", whereas 
packets that violate the rules of the state machine will trigger 
messages containing substrings such as "invalid state". Just look for 
the word, invalid, in general.

> 
> I believe that the problem can be closed. Thanks again for your help.
> 
> Best Regards, Tom

-- 
Kerin Millar