On Tue, Apr 26, 2022 at 1:54 AM <pat...@patpro.net> wrote:
>
> Hello,
>
> This is off topic anyway but I think you're right. Fail2ban is not for the
> lazy, it's for people who have a lot of time to lose in an inefficient
> solution. Before cloud era F2B was a really great solution, but as it's been
> pointed out, current attackers can leverage 100s ou 1000s of IP addresses to
> evade detection / rate limiting control and obviously Fail2ban.
> Don't read me wrong, F2B and other similar protections are nice to have (I'm
> using blacklistd on FreeBSD for example), but their are being obsoleted by
> the change in attacks pattern. Thinking of F2B as a silver bullet is a lack
> of understanding infosec, to use your own words.
>
> The really lazy solution is the one that cost almost nothing, is light
> maintenance, and solve your problem once and for all. Allowing only client
> certificate for authentication can be a perfect and lazy solution, depending
> on your context. This is absolutely bullet-proof, 100% efficient against
> brute-force and can be low/medium maintenance. Obviously YMMV as it's highly
> dependent of your context (how many users, how you provide support for them,
> etc.).
>
Please explain how certificate authentication is, as you said,
100% efficient against brute-force attacks. Specifically, how
certificate authentication decreases the amount of resources tied down
to, as you said, 100s ou 1000s of IP addresses being used by attackers
to initiate connections with the mail server. Each of these
connections still require resources from the server, which needs to
answer the initial connection request, start TLS, wait for the login
request, decide it is not valid, and then close the connection.
If these 100s ou 1000s of IP addresses are sending each thousands of
connection requests a minute, isn't this a DDoS?
What a tool like fail2ban does is try to cut down the number of
connection attempts your server has to deal with. Nobody claimed it
was a panacea; it is just a protective layer, just a component in
something you are well experienced with: defense in depth. As you are
well aware of, it can integrate with the certificate (or MFA or
whatever) authentication: since not using this authentication
indicates an attack, you can increase the minimum interval between
failed attempts to account for someone trying to brute force in slowly
(maybe 3 attempts in an hour, or even just one attempt without using
approved authentication system suffices). But, at the end of the day
it is but one element in your defensive system, and it works better
when used in coordination with other tools.
You may have 100% efficient solutions; I set my goals much lower,
being satisfied in having my system secured just enough that an
attacker will move on and search for an easier target.
> patpro
>
> April 26, 2022 7:32 AM, "Antonio Leding" <t...@leding.net> wrote:
>
> I’ve been using F2B for over 4-5 years and it’s fantastic. F2B is just one of
> many very useful tools in the belt of any knowledgable infosec practitioner.
> To consider F2B as “only for the lazy” speaks more to a lack of truly
> understanding infosec than it does of the tool itself…
>
> ________________________________
>
> On 25 Apr 2022, at 0:07, Laura Smith wrote:
>
> ------- Original Message -------
> On Monday, April 25th, 2022 at 05:26, ミユナ al...@coakmail.com wrote:
>
> do you know how to stop passwords from being brute-forced for a
> mailserver? do you have any practical guide?
>
> Simple. You've got two options:
>
> a) Use strong passwords (and if you run an automated password changing
> system, enforce strong passwords)
>
> b) Use client-certificate authentication
>
> Stuff like fail2ban is for the lazy. You should be focusing on solving the
> underlying cause of the problem, i.e. using one of the two options above.
>
> The problem with stuff like fail2ban is that you are basically playing
> whack-a-mole. IP address blocking simply does not work 2022, attackers have
> too many options (i.e. they can hop between cloud providers, they can use
> IPv6 to give them massive ranges to play with etc. etc.).
>
>
>
