Bringing insights into TCP resets and timeouts to Cloudflare Radar

My observation involved long-lived (much longer than typical for HTTP) TCP connections with low-but-nonzero traffic (there was an application-layer heartbeat). For at least some US residential IPs (some with effectively static allocation) connected to a datacenter, they would reliably get RST injected (to the client only, not the server) after being connected long enough (usually a couple hours, but not any obvious pattern).

Re: Bringing insights into TCP resets and timeouts to Cloudflare Radar

#6

Post by patrakov » Mon, Sep 09, 2024, 3:51 AM UTC

o11c wrote: post #5

(If the author is reading this: bad formatting for fin: and acknumdiff: ) Once again a discussion that covers RST injection attacks fails to consider the one case I actually saw in the wild ... My observation involved long-lived (much longer than typical for HTTP) TCP connections with low-but-nonzero traffic (there was an application-layer heartbeat). For at least some US residential IPs (some with effectively static…

Is the server on OVH? This is a known "feature" of their DoS protection that cannot be turned off.

Re: Bringing insights into TCP resets and timeouts to Cloudflare Radar

#7

Post by supriyo-biswas » Mon, Sep 09, 2024, 4:38 AM UTC

o11c wrote: post #5

(If the author is reading this: bad formatting for fin: and acknumdiff: ) Once again a discussion that covers RST injection attacks fails to consider the one case I actually saw in the wild ... My observation involved long-lived (much longer than typical for HTTP) TCP connections with low-but-nonzero traffic (there was an application-layer heartbeat). For at least some US residential IPs (some with effectively static…

In my very populous country, the largest ISP will inject resets if it's over IPv4 and idle for more than 10 seconds :)

These things are unfortunately rather common. This is also why I run SSH with a 5 second heartbeat duration, for example.

Re: Bringing insights into TCP resets and timeouts to Cloudflare Radar

#8

Post by accrual » Mon, Sep 09, 2024, 5:18 AM UTC

o11c wrote: post #5

(If the author is reading this: bad formatting for fin: and acknumdiff: ) Once again a discussion that covers RST injection attacks fails to consider the one case I actually saw in the wild ... My observation involved long-lived (much longer than typical for HTTP) TCP connections with low-but-nonzero traffic (there was an application-layer heartbeat). For at least some US residential IPs (some with effectively static…

Maybe a fun idea - run an application on both sides of a remote TCP connection that records but doesn't respond to TCP RST packets. Then see how many times you get "reset".

Re: Bringing insights into TCP resets and timeouts to Cloudflare Radar

#9

Post by [deleted] » Mon, Sep 09, 2024, 10:34 AM UTC

[deleted]

Re: Bringing insights into TCP resets and timeouts to Cloudflare Radar

#10

Post by geocar » Mon, Sep 09, 2024, 11:54 AM UTC

accrual wrote: post #8

o11c wrote: post #5

(If the author is reading this: bad formatting for fin: and acknumdiff: ) Once again a discussion that covers RST injection attacks fails to consider the one case I actually saw in the wild ... My observation involved long-lived (much longer than typical for HTTP) TCP connections with low-but-nonzero traffic (there was an application-layer heartbeat). For at least some US residential IPs (some with effectively static…

Maybe a fun idea - run an application on both sides of a remote TCP connection that records but doesn't respond to TCP RST packets. Then see how many times you get "reset".

You can just drop RST packets.

    iptables -I INPUT -p tcp --tcp-flags ALL RST,ACK -j DROP
    iptables -I INPUT -p tcp --tcp-flags ALL RST -j DROP