Wild these guys weren’t force to seek bankruptcy protection from insurers. Don’t get me wrong: they should continue to exist. But shareholders should have been wiped out for the damage they did.

Are you thinking of Crowdstrike?

> Are you thinking of Crowdstrike?

Ha! Yes.

(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 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).

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

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.

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

Why do I find this so funny...

That looks like exactly what I did, but it was a pain trying to get random users to do run code as root.

They've given out a bot identification signal. Now botters are going to deliberately cancel 6% of their TCP connections ;)