banning, was Re: Non-user logins?

[John Fawcett]

On 08/01/2022 17:22, Dave McGuire wrote:
> On 1/8/22 8:57 AM, John Fawcett wrote:
>> yes, blocking on the first wrong password sounds like overkill. But 
>> it does depend on user base. For a small mail server with few known 
>> users it could be workable.
>
>   It may be overkill for your network, but it's not overkill for mine.
>
>> But even on small servers I'd recommend blocking for a small time 
>> (like up to an hour) after a small number of failures (example 3). 
>> Then if this pattern repeats (for example 3 times) within a longer 
>> period (for example up to a day), blocking for a longer period 
>> (example 1 week) using the recidive jail.
>
>   My mail server is a small one with about 135 users, a corporate 
> network.  NONE of them actually type their password when they're 
> checking their mail.  They type it exactly once when they set up the 
> account in their mail client(s), like everyone else in the world for 
> the past decade or more.
>
>> Mileage will vary depending on user base and number of support 
>> requests generated.
>>
>> The point about fail2ban is that it slows down attackers stopping 
>> infinite and fast repeating attacks from the same ip. That should be 
>> in combination with a good password policy which reduces the 
>> probability of any single attack guessing the password. It doesn't 
>> necessarily have to zero out attacks. As Dave has experimented, to 
>> bypass fail2ban all the attacker has to do is use a different ip. 
>> 10-15K blocks in place at any time seem very high compared to the few 
>> attacks I see.
>
>   Sigh.
>
>   I don't "experiment" with production networks.  I set up a banning 
> policy that works for the attack patterns that I see in my logs, and 
> that work with my user base.  As I explained to the other guy who 
> decided that how I run my network is wrong, I'm not new at this.
>
>   Any attack mitigation strategy has to begin with observation and 
> rational thought.  Network security is no place for guesswork or 
> assumptions.
>
>> I'd hazard a guess that the restrictive fail2ban policy is causing 
>> the attacker(s) to try immediately from a new ip and isn't generating 
>> a great deal more security than a slightly less restrictive policy 
>> which lures the attacker into trying a few times more from the same 
>> ip with longer intervals between the attempts.
>
>   I wasn't asking for a critique of my configuration; I explained my 
> approach to a new user who came here looking for help.
>
>   Which is the last time I'll do THAT on this list, by the way.
>
>   But since you brought it up, the attack pattern that I see most 
> frequently is a single IP address trying different, obviously 
> algorithmically-generated usernames at long intervals, many seconds to 
> many hours, and in some cases a day or more.  This started around 2014 
> or so, and has persisted and grown.  The approach that you describe 
> above seems to make sense on the surface, but looking at actual logs 
> doesn't support the idea.
>
>   The "attackers" in this case are almost exclusively little programs 
> thrown together by kids and run from zombie Windows boxes on clueless 
> users' home networks organized as botnets.  This pattern is visible 
> when the same sequences of generated usernames start appearing from 
> different IP addresses within hours of each other.
>
>   Some of the more advanced stuff has the adaptive behaviors that you 
> describe, but not many.  These script k1ddiez are trolling for 
> low-hanging fruit to get bank account info etc out of peoples' mail 
> accounts.  These are almost never focused attacks from one motivated, 
> knowledgeable person trying hard to get into one user's mail.
>
>   So, hazard all the guesses you like, I will continue to develop 
> banning strategies for my servers which fit the attacks that I observe 
> through direct analysis of my logs.
>
>   Now, please don't misunderstand, I actually do appreciate the 
> thought and intention behind your unsolicited advice.  But, for future 
> reference, don't assume that someone doesn't know what they're doing 
> just because their approach differs from either your approach for your 
> own network, or your guesses about theirs.
>
>            -Dave, pre-coffee
>
Dave

no one is telling you how to run your server or offering you unsolicited 
advice but on a public mailing list there can be multiple points of view 
about a topic and there may be not be a single right way to do 
something. There is no reason then to take this as someone telling you 
that how you run your network is wrong or to avoid participating in future.

John