Re: [PATCH] netfilter: conntrack: tcp: do not lower timeout to CLOSE for in-window RSTs

[Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>]

Hi,

On Wed, 10 Jul 2024, yyxRoy wrote:

> On Mon, 8 Jul 2024 at 22:12, Florian Westphal <fw@strlen.de> wrote:
>> We can track TTL/NH.
>> We can track TCP timestamps.
>>
>> But how would we use such extra information?
>> E.g. what I we observe:
>>
>> ACK, TTL 32
>> ACK, TTL 31
>> ACK, TTL 30
>> ACK, TTL 29
>>
>> ... will we just refuse to update TTL?
>> If we reduce it, any attacker can shrink it to needed low value
>> to prevent later RST from reaching end host.
>>
>> If we don't, connection could get stuck on legit route change?
>> What about malicious entities injecting FIN/SYN packets rather than RST?
>>
>> If we have last ts.echo from remote side, we can make it harder, but
>> what do if RST doesn't carry timestamp?
>>
>> Could be perfectly legal when machine lost state, e.g. power-cycled.
>> So we can't ignore such RSTs.
>
> I fully agree with your considerations. There are indeed some challenges 
> with the proposed methods of enhancing checks on RSTs of in-window 
> sequence numbers, TTL, and timestamps.

Your original suggestion was "Verify the sequence numbers of TCP packets 
strictly and do not change the timeout of the NAT mapping for an in-window 
RST packet." Please note, you should demonstrate that such a mitigation

- does not prevent (from conntrack point of view) currently
   handled/properly closed traffic to be handled with the mitigation as
   well
- the mitigation actually does not pose an easier exhaustion of the
   conntrack table, i.e. creating an easier DoS vulnerability against it.

> However, we now have known that conntrack may be vulnerable to attacks 
> and illegal state transitions when it receives in-window RSTs with 
> incorrect TTL or data packets + RSTs. Is it possible to find better 
> methods to mitigate these issues, as they may pose threats to Netfilter 
> users?

The attack requires exhaustive port scanning. That can be prevented with 
proper firewall rules.

> Note: We have also tested other connection tracking frameworks (such as 
> FreeBSD/OpenBSD PF). Also playing the roles as middleboxes, they only 
> change the state of the connection when they receive an RST with the 
> currently known precise sequence number, thus avoiding these attacks. 
> Could Netfilter adopt similar measures or else to further mitigate these 
> issues?

I find it really strange that those frameworks would match only the exact 
SEQ of the RST packets.

Best regards,
Jozsef
-- 
E-mail : kadlec@netfilter.org, kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
Address: Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary