Brute force attackers seem to switch targets rapidly if you block them

July 11, 2024

Like everyone else, we have a constant stream of attackers trying brute force password guessing against us using SSH or authenticated SMTP, from a variety of source IPs. Some of the source IPs attack us at a low rate (although there can be bursts when a lot of them are trying), but some of them do so at a relatively high rate, high enough to be annoying. When I notice such IPs (ones making hundreds of attempts an hour, for example), I tend to put them in our firewall blocks. After recently starting to pay attention to what happens next, what I've discovered is that at least currently, most such high volume IPs give up almost immediately. Within a few minutes of being blocked their activity typically drops to nothing.

Once I thought about it, this behavior feels like an obvious thing for attackers to do. Attackers clearly have a roster of hosts they've obtained access to and a whole collection of target machines to try brute force attacks against, with very low expectations of success for any particular attack or target machine; to make up for the low success rate, they need to do as much as possible. Wasting resources on unresponsive machines cuts down the number of useful attacks they can make, so over time attackers have likely had a lot of motivation to move on rapidly when their target stops responding. If the target machine comes back some day, well, they have a big list, they'll get around to trying it again sometime.

The useful thing about this attacker behavior is that if attackers are going to entirely stop using an IP to attack you (at least for a reasonable amount of time) within a few minutes of it being blocked, you only need to block attacker IPs for those few minutes. After five or ten or twenty minutes, you can remove the IP block again. Since the attackers use a lot of IPs and their IPs may get reused later for innocent purposes, this is useful for keeping the size of firewall blocks down and limiting the potential impact of a mis-block.

(A traditional problem with putting IPs in your firewall blocks is that often you don't have a procedure to re-assess them periodically and remove them again. So once you block an IP, it can remain blocked for years, even after it gets turned over to someone completely different. This is especially the case with cloud provider IPs, which are both commonly used for attacks and then commonly turn over. Fast and essentially automated expiry helps a lot here.)


Comments on this page:

I've found that blocking just a few large network blocks from APNIC goes a long way to keeping the SSH bots out; from my iptables:

Chain block (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 213K   13M DROP       tcp  --  *      *       180.0.0.0/8          0.0.0.0/0           tcp dpt:22 flags:0x02/0x02 
 8316  497K DROP       tcp  --  *      *       218.0.0.0/8          0.0.0.0/0           tcp dpt:22 flags:0x02/0x02 
  180 10188 DROP       tcp  --  *      *       157.0.0.0/8          0.0.0.0/0           tcp dpt:22 flags:0x02/0x02 
 4333  260K DROP       tcp  --  *      *       43.0.0.0/8           0.0.0.0/0           tcp dpt:22 flags:0x02/0x02 
  366 20176 DROP       tcp  --  *      *       170.0.0.0/8          0.0.0.0/0           tcp dpt:22 flags:0x02/0x02 
 1556 92492 DROP       tcp  --  *      *       103.0.0.0/8          0.0.0.0/0           tcp dpt:22 flags:0x02/0x02 

These are all the really dumb ones that keep trying over and over again. For others, I have in place a real-time blocker that will append a rule to a separate ssh-block chain I have that only blocks SYN packets to TCP port 22 to prevent a blanket ban on an IP address.

Chain INPUT (policy ACCEPT 19M packets, 2479M bytes)
 pkts bytes target     prot opt in     out     source               destination         
  19M 2499M block      all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 155K 9017K ssh-block  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 flags:0x02/0x02 

I'll periodically flush this chain if I feel it gets too large, although that could be automated as well. Right now I have around 2000 entries in this chain; it's was a lot higher before I added the above permanent block chain.

By Arnaud Gomes at 2024-07-12 05:18:35:

One pattern that I have observed in hostile web crawlers (things like claudebot, which at least has an explicit user-agent, or target-specific brute-force thingies) is that they tend to change source address when you block them. Look for a user agent in your logs, detect a new source IP, block it and 30 to 60 seconds later this source goes silent and a new one appears at the same time.

I don't know if the same applies to generic SSH or SMTP probes.

By Duncan at 2024-07-12 07:40:20:

Is fail2ban not a trivial automation of this? It certainly used to be a number of years ago when I ran my own internet connected servers. I'm sure they're are a dozen similar tools

It's clear to me that SSH shouldn't be exposed to the Internet at all. The constant security problems don't help. I'll eventually put mine behind WireGuard, solving the issue once and forever.

Written on 11 July 2024.
« Fedora 40 probably doesn't work with software RAID 0.90 format superblocks
Network switches aren't simple devices (not even basic switches) »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Thu Jul 11 22:27:17 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.