logging TCP flags

Question

I use nftables for my rules.

my question: How can I log the tcp flags ?

this is my rule :

nft add rule filter input tcp dport 22 ct state new tcp flags \& \(fin\|syn\) ==\( fin \| syn\) accept

the result that I am getting always :

Dec 6 13:40:19 my_host my_FIN IN=eth0 OUT=eth1 MAC= SRC=x.1.1.1 DST=x.2.2.2 LEN=40 TOS=00 PREC=0x00 TTL=127 ID=17695 DF PROTO=TCP SPT=54049 DPT=422SEQ=2558094232 ACK=0 WINDOW=8192 SYN URGP=0 MARK=0

EDIT my rule:

 chain FORWARD {
 ip saddr 1.1.1.1 ip daddr . tcp dport @myset tcp flags & (fin | syn) == fin | syn counter packets 0 bytes 0 log prefix " myprefix " group 1 accept 

}

Answer 1

Netfilter's conntrack, for the TCP case, has extra consistency checks between its internal states and equivalent TCP states. This netdev 2.1 PDF document (sorry I couldn't find its netdev url, this is from author's site instead) tells about it:

L4 trackers attempt to keep state, e.g. tcp: tracks state, checks sequence numbers. Example:

• new tcp packet? SYN bit set?
• tcp sequence number in expected window?
• unacknowledged data? → adjust timeout
• rst? fin? → delete connection and/or adjust timeout

The conntrack NEW state matches a TCP SYN_SENT or TCP SYN_RECEIVED state. If you select the NEW state condition in your rules, using ct state new, it will never match any FIN packet, since there is never a FIN packet involved in establishing a new TCP connection.

Try again after removing ct state new.

UPDATE: there's a second problem I didn't see initially. this expression:

tcp flags & (fin | syn) == fin | syn

will simply never match with the FIN flag, since there's never both FIN+SYN found (except some random invalid attempts). The correct expression should be:

tcp flags & (fin | syn) != 0

which will match whenever FIN or SYN are set. Actually nftables simplifies it and only this is displayed or required:

tcp flags fin,syn

So taking both adjustments in account (ct state new must still be removed), the rule becomes:

nft add rule filter FORWARD 'tcp dport 22 tcp flags fin,syn log prefix " my_FIN " group 1 accept

or in the complete chain set:

 chain FORWARD {
 type filter hook forward priority 0; policy accept;
 ip saddr 1.1.1.1 ip daddr . tcp dport @myset tcp flags fin,syn counter log prefix " myprefix " group 1 accept 
 }

Once you can actually detect FIN packets with this rule above, if your intention is to filter some TCP attacks (do you really need?), note that netfilter will probably consider first seing a TCP FIN in a TCP connection's first packet as INVALID state: you could be interested in logging those states (ct state invalid). There are netfilter sysctl toggles which can alter results about INVALID state: enabling nf_conntrack_tcp_be_liberal which wouldn't classify this as invalid, and disabling nf_conntrack_tcp_loose which would stop recovering an established TCP connection, ie stop having a state NEW without SYN. This recovery should happen only after having lost connection tracking: after firewalling router's reboot or having flushed conntrack states with conntrack -F, but who knows, it's possible to choose paranoia here.

• binakh: Thanks for your Answer . I used many flags, but I don't get FIN flag. Like 'add rule filter mychain ip saddr 1.1.1.1 ip daddr . tcp dport @myset ct state new , established related tcp flags & (fin|syn) == fin|syn log prefix \"my_log \" group 1 accept I Will try with ct state invalid.
• binakh: I enable the module nf_conntrack_tcp_be_liberal and I write Invalid in my rule . I am getting the same result. In my case. I want to know the time between the SYN and FIIN. Also I want to know how long the TCP connexion
• binakh: thanks for your explanaition..I edit the post in adding the forward Chain. I remove ct state established related accept at the top of chain Forward . I can't acces my destination IP. If I know the FIN flag, the time between SYN and FIN is the proximatly long of TCP connection
• A.B: My bad I found the error (that I didn't correct in my answer) I will edit it
• A.B: no, forget it, I thought that was a separate different rule