I am having fun playing with the slow syn flood of spoofed packets someone is sending. I appreciate them sending it. I like the variability in the TCP MSS, TTL, Window sizes they are sending.
Thus far I am letting some leak through it would seem.
100 SYN received in 15.03 seconds
100 SYN-ACK returned in 3 minutes and 22.03 seconds.
Thus far 2388 requests to this confused-bots file have been let through and 3226 have been assumed to be bots.
Eventually ran out of things to play with. Actions taken:
- Blackhole routed a few ASN's / data-centers. It's all spoofed packets but good to block data-centers regardless so we are not sending them syn-ack (good hygiene).
- Added a temporary rule when we encounter a syn-flood. [1]
End result: Input 20 packets in 17 seconds, Output syn-ack reply 20 packets in 4 minutes and 44 seconds. That should translate to an acceptable amount of syn-ack if we were actually attacked some day.
Impact: Before, we sent more syn-ack then I would have liked but there was overall no impact to Nginx as we use the "deferred" socket option [2]. Now we send far fewer syn-ack packets for good internet hygiene. Thank-you to the person using the syn flood tool.
On a funny side note, it seems that after blocking ASN's I ended up finding by coincidence this list of ASN's that are related in some way to StormWall [1]. Curious what that means. Perhaps they were trying to get me to add myself to a BGP GRE DDoS scrubbing list with the syn-ack packets. Well played if so! :-D
Paramiko v4.0.0 (the latest) gets past the version string, it seems, but dies instantly on failed KEX, which is another convenient incompatibility. It does mean that even legitimate SSH bots in Python will fail though.
That is likely from performing hardening in ssh-audit [1]. The way I used to block python, Go and libssh was to use a iptables string search but that capability does not exist at least natively in nftables.
I am having fun playing with the slow syn flood of spoofed packets someone is sending. I appreciate them sending it. I like the variability in the TCP MSS, TTL, Window sizes they are sending.
Thus far I am letting some leak through it would seem.
Thus far 2388 requests to this confused-bots file have been let through and 3226 have been assumed to be bots.Eventually ran out of things to play with. Actions taken:
- Blackhole routed a few ASN's / data-centers. It's all spoofed packets but good to block data-centers regardless so we are not sending them syn-ack (good hygiene).
- Added a temporary rule when we encounter a syn-flood. [1]
End result: Input 20 packets in 17 seconds, Output syn-ack reply 20 packets in 4 minutes and 44 seconds. That should translate to an acceptable amount of syn-ack if we were actually attacked some day.
Impact: Before, we sent more syn-ack then I would have liked but there was overall no impact to Nginx as we use the "deferred" socket option [2]. Now we send far fewer syn-ack packets for good internet hygiene. Thank-you to the person using the syn flood tool.
[1] - https://mirror.newsdump.org/nftables.txt
[2] - https://mirror.newsdump.org/nginx/http.d/11_bad_sni.conf.txt
On a funny side note, it seems that after blocking ASN's I ended up finding by coincidence this list of ASN's that are related in some way to StormWall [1]. Curious what that means. Perhaps they were trying to get me to add myself to a BGP GRE DDoS scrubbing list with the syn-ack packets. Well played if so! :-D
[1] - https://bgp.tools/as-set/RIPE::as-stormwall-set#reverse
Paramiko v4.0.0 (the latest) gets past the version string, it seems, but dies instantly on failed KEX, which is another convenient incompatibility. It does mean that even legitimate SSH bots in Python will fail though.
That is likely from performing hardening in ssh-audit [1]. The way I used to block python, Go and libssh was to use a iptables string search but that capability does not exist at least natively in nftables.
[1] - https://www.ssh-audit.com/