netdev - Re: [PATCH nf-next v2] netfilter: conntrack: avoid sending RST to reply out-of-window skb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL+tcoCe6YFOWOYvdu1UH+kHRYPEmfphOJzB0BcVR-HER0GZ8g@mail.gmail.com>
Date: Sat, 23 Mar 2024 08:25:55 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
Cc: Pablo Neira Ayuso <pablo@...filter.org>, edumazet@...gle.com, 
	Florian Westphal <fw@...len.de>, kuba@...nel.org, pabeni@...hat.com, 
	David Miller <davem@...emloft.net>, netfilter-devel@...r.kernel.org, 
	coreteam@...filter.org, netdev@...r.kernel.org, 
	Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH nf-next v2] netfilter: conntrack: avoid sending RST to
 reply out-of-window skb

> I understand and appreciate your efforts. But please consider the case
> when one have to diagnose a failing connection and conntrack drops
> packets. What should be suspected? Firewall rules? One can enable TRACE
> and check which rules are hit - but because conntrack drops packet,
> nothing is shown there. Enable and check conntrack events? Because the
> packets are INVALID, checking the events does not help either. Only when
> one runs tcpdump and compares it with the TRACE/NFLOG/LOG entries can one
> spot that some packets "disappeared".
>
> Compare the whole thing with the case when packets are not dropped
> silently but can be logged via checking the INVALID flag. One can directly
> tell that conntrack could not handle the packets and can see all packet
> parameters.

Thanks for explaining such importance about why not drop silently. Now
I can see :)

In my first version, I didn't drop it directly but let it go without
clearing skb->_nfct fields and then let the TCP layer handle it. As
you said, the out-of-window case is just one of some INVALID cases
which could also cause RST behaviour, so it seems that the first
version doesn't handle it well either. It has to take all INVALID
cases into account...

Is there anything left I can do like particular tracepoints something
like this? No idea. I only hope somebody who encounters such an issue
can notice this behaviour effortlessly :)

Thanks,
Jason

>
> Best regards,
> Jozsef