banning, was Re: Non-user logins?

[Dave McGuire]

On 1/8/22 12:12 PM, John Fawcett wrote:
> 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.

   Well thanks for that, but perhaps you should re-read what you sent 
that prompted my (admittedly rather sour) reply.

           -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA