Hi,
On Wed, 10 Jul 2024, yyxRoy wrote:
On Mon, 8 Jul 2024 at 22:12, Florian Westphal <fw@xxxxxxxxx> 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@xxxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxx
Address: Wigner Research Centre for Physics
H-1525 Budapest 114, POB. 49, Hungary
