I get notifications from fail2ban for a number of my servers whenever the various services running (email, form logins, ssh, etc) - normally I get two to three notifications a day; nothing crazy.<p>These last three days I've been getting 30-60 SSH bruteforce attempts per day, which is way more then usual and way more in sequence then I've ever seen.<p>They're all from Google Cloud IP addresses, and they all look like the standard mass-bruteforce attacks we've seen before. This isn't a coordinated attack, since different IPs attempt the same usernames repeatedly.<p>I'm curious if any other sysadmins have noticed the same thing - and have any foresight into why Google Cloud VMs have become so popular for this kind of attack.
I have dropped quite a few Google Cloud ranges, as has APIBan. Abuse reports are useless with Google Cloud from what I've seen.<p>Most systems will never need to access anything in Google Cloud, it's okay just to drop them at the edge rather than have the CPU load of running fail2ban on a steady stream of logs.
I see bot activity cycle up and down based on new groups deploying new C&C/malware. They come and go as malware networks come and go.<p>For what it's worth, one can quiet down fail2ban by using generalization rules to knock out many of the bots. For example, many of the bots do not set MSS at all or have odd MSS values because they are traversing proxies/vpn's. Another interesting feature of some of these bots is their source port ephemeral range is set to 1-65535 I assume so they can open many connections.<p>Verify your connections and legit connections are using an MSS of 1460:<p><pre><code> tcpdump -p -i any -NNnnt -c100 proto 6 and 'tcp[13] == 2'
</code></pre>
So after verifying that all your legit connections to SSH are using say mss 1460, then drop anything outside of that. One can always insert rules above to allow lower MSS for specific subnets or IP addresses. I've noticed most of the bots coming from Asia have an MSS of 1398 and Russia 1424. Some Cisco VPNs are 1454. One could add <i>! -s your.home.ip.address</i> to exclude your home while testing this. Using the raw table keeps these hits off your state-table and lowers CPU usage.<p><pre><code> iptables -t raw -I PREROUTING -m tcp -p tcp --dport 22 -tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 1460 -j DROP
</code></pre>
Or if your cell phone uses a lower MSS to reach your server, maybe 1424 and you dont want to explicitly trust that network, then widen the rule with:<p><pre><code> iptables -t raw -I PREROUTING -m tcp -p tcp --dport 22 -tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 1424:1460 -j DROP
</code></pre>
Using low ports in the ephemeral range is not a violation but tells me these are not normal people so I nuke them as well. This isn't for everyone.<p><pre><code> # allow 4 connections per /16 to ssh that have a normal ephemeral port range.
# insert rules above this for trusted networks with a higher limit. Adjust as required.
iptables -I INPUT -i eth0 -p tcp -m tcp --sport 1024:65535 --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-upto 4 --connlimit-mask 16 --connlimit-saddr -j ACCEPT
</code></pre>
To further remove noise, move sshd to a high port. This is not a security feature but a noise removal feature. It won't stop a targeted attack but will stop 99%+ of the noise. Not in 20 years has anyone hit my ssh port with exception to my public SFTP servers.<p>If you want to watch the bot activity and see the lack of MSS on most of the connections, use:<p><pre><code> tcpdump -p -i any -NNnnt -c800 proto 6 and 'tcp[13] == 2'</code></pre>