Interesting.
I decided to check out your website, so I went to rohms.com, but there is
nothing there.
Wayne Sallee
wa...@waynesallee.com
http://www.WayneSallee.com
-------- Original Message --------
*Subject: * [Fail2ban-users] Fwd: Re: When to decide that fail2ban is not a
good solution
*From: * Mike <t...@rohms.com>
*To: * Fail2ban-users <fail2ban-users@lists.sourceforge.net>
*CC: *
*Date: * 2019-9-23 12:50 PM
I'm working on a system that I hope to share with users of this mailing list soon. What I've done is create an
iptables top level blacklist, a special ipset list that sits underneath fail2ban. I've used this system to block 90%
of the hack/probe attempts.
This is not new. Other people here have been doing this as well, but the difference is I'm trying to create the
smallest blacklist possible - not using a GEO-IP database which may have tens of thousands of IP addresses. I've been
going over my logs identifying the largest blocks where attacks are coming from and compiling my own list.
Using iptables and ipset, I create a blacklist of Class A and Class B IP address space - in my case, my servers are in
the USA. I don't have any clients overseas that need to login to my systems. So I create an IPTABLES command that
blocks all ports open to login: 20,21,22,110,143,587,989,990,993,994,995,4190,3659, and I apply an IPSET blocklist to
that to log and then drop packets originating from a small set of class A/B IP space. My blacklist basically limits
the lion's share of IP space in China, Korea, Indonesia, Russia, Africa, Brasil, and various other areas. I also
choose to block cloud hosting providers that I don't do business with that are known to host a lot of compromised
servers, such as Digital Ocean, OVH, and others.
The end result is that fail2ban has a LOT less work to do. I filter out the big blocks and leave it to do the rest.
Server memory usage is much less and the systems run even better.
If anybody is interested in my code, let me know - I'm still working on it but plan to put it up on Github to share.
It will consist of a set of shell scripts to set iptables, and then another set of shell scripts to add different
regions, ISPs, etc., to the blacklist.
What's cool about this blacklist, is it doesn't interfere with mail. It just restricts ports where people can login.
If you disable smtp auth on port 25, you can shield your system from the lion's share of login attacks.
If anybody wants a list of my blocked netspace, let me know. Right now I have 1075 entries in ipset, only using 10k of
memory. And it stops 90+% of my system probes.
- Mike
If you have thousands of blocked IP address, fail2ban's ipset action is
desirable.
Some attacks initiate tens of connections at the same time so that although
fail2ban
bans the address, your system has to handle all of them because they have
already
connected.� You can mitigate this by limiting the number of connections within
a
certain time frame.� Look into iptable's rate limiting.
ACCEPT .... multiport dports 25,465,587 limit: up to 10/min burst 4 mode srcip
/* mail - unknown */
followed by a DROP of those ports.
Another approach is to limit the addresses allowed to connect with iptable's
GeoIP.
For example, only allow SSH connects from your country.� Or conversely, drop
all traffic
from known bad countries.
You could block one or more entire subnets (93.184.216.0/24) in iptables.
_______________________________________________
Fail2ban-users mailing list
Fail2ban-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
_______________________________________________
Fail2ban-users mailing list
Fail2ban-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
