Le 2020-07-08 18:29, Mike a écrit :
> On 7/8/20 3:29 PM, Mike wrote:
> As an aside, instead of using a recidive jail, I've been using a more
> permanent ban of login ports using this system
>
> https://github.com/dpsystems/login-shield
>
> This also includes logging of banned connections and some analysis reports.
> That is an original/unusual approach... The software seems to be merely a
> list of IP ranges that get blocked with iptables. I figure the list of IPs
> need to be updated somehow via git update ? this also means the list is
> updated by the (sole) maintainer ? also via git ?
>
> A more usual approach is to have a client/server architecture where each
> client that detects an offending IP uploads it to the server. All other
> clients will then recieve the new IP and add it to their block list (even if
> it hasn't tried to break in yet), sort of how some antivirus and some spam
> detection software work.
It's really not that unusual an approach. Most sysadmins maintain their
own blacklists or whitelists. This is somebody sharing theirs, and it
is regularly updated. And it's designed in such a way that you can
customize it. Obviously like any system of this sort, it has to be
maintained. I prefer this to say, the standard DNS-based blacklists,
but I use those too. But as a first line of defense, if for example,
you don't have any reason for people in China to be trying to check IMAP
or SSH credentials, you can just wholesale block the lion's share of
that IP space with no more than a dozen or two iptables rules. I think
it's much more efficient than maintaining a real time, shared blacklist.
And in either case, there's always a possibility of a false positive.
I've found this works much better in concert with F2B. I've reduced the
stress on F2B significantly.
Another issue is, if someone is operating a centrally located blacklist,
it can be an attack vector. Unless hackers want to DDOS github, this is
a way to implement blacklisting in a safer way.
I still rely on F2B but found this is a good compliment. Like others
here, I got tired of seeing repeat offenders. And the recidive function
is nice, but it's still way more granular and resource hogging as it
should be. With the ability, for example, to stop an entire class A or
B block of space with a single firewall command, that's really resource
efficient.
I'm also seeing botnets get much more sophisticated. I'm seeing them
learn the bantimes and maxtries variables and working around them
automatically. I'm seeing them execute coordinated attacks from a
diverse array if IPs that go uncaught by F2B.
It's not foolproof. Nothing is. But I've now been running this for
several months and it's been really impressive, like catching 98% of
most login attempts before they even get to F2B. I've seen similar
blacklists out there, for example, coving all cn or br IP space, but I
don't think you can catch all, and I'd rather use 20 block rules and
catch 98% than 400 block rules and catch 99%. I let F2B catch the stuff
left over.
_______________________________________________
Fail2ban-users mailing list
Fail2ban-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
Thank you Mike for such a beautiful dissertation. I have already set a
geofence with the xt_geoip kernel module and set shorewall to ban any
country other than mine and the US (for microsoft outlook users,
unfortunately...).
I still have to fix the postfix-sasl setup because it allows users to
authenticate on port 25, which is wrong, and is also why I'm having
attacks on that port. What I should do (this is outside of F2B topic) is
put a geofence on the submission port and disable authentication on port
25 and see where to go from there. I suspect this will significantly
reduce the number of attacks.
Yassine.
_______________________________________________
Fail2ban-users mailing list
Fail2ban-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
