Fail2ban and alternatives

I recall reading a post by Dicko about the former limitations of fail2ban, and how it’s been improved upon lately. I also remember Dicko stating that their is a database somewhere, with over 200,000 IP addresses blacklisted.

Fail2ban seems to work fairly well, and so far, no problems. But seeing those fail2ban emails related to connection attempts constantly tends to weigh heavily on my thoughts. Curious if there is a method of connecting to that external database to utilize that list, or if there are any other methods of mitigating those attempts.

Also curious if anyone has used any form of Geo-ip fencing-I know this wouldn’t be a complete stand-alone security concept, but it may block a majority of attempts. Just curious if, like me, everyone is relying completely on fail2ban for their cloud deployments.

Thanks in advance for any insight

Much more effective soution is to only use TLS transport for your endpoints, failing that avoid UDP:5060 like is is covid.

This is a good blacklist. It’s constantly updated and has good install script examples including fail2ban config.

Thanks Dicko. I only have about ten cloud deployments now, and I’ve been contemplating switching all of them to TLS, just haven’t taken the time to do it while still installing more, and supporting m,y current base. I think I’m already halfway there, as I use Certs to secure all my VMs already. I’ve thought about changing from UDP port 5060, but that just seems sort of unnecessary if there is a better alternative. And, I have a couple of VMs supporting 30-40 phones, been sort of hesitant because of the anticipation of the server taking a hit in performance due to using TLS for transport. Those machines have 2Gb of RAM, and a shared CPU that is currently at about 10-12% usage. I will definitely look into theVoIP Blacklist, and as always, thanks for the info.

Agreed, skip the UDP bit, but as you are halsway there, I encourage you to not use the same cert for TLS as the one you use for UCP (same advice for the admin site or any provisioning)

Really?? I suppose that’s something you do from the CLI?? I don’t recall seeing more than one place to install a certificate, and I even just took a brief look at a version 16.0.41.24 deployment.

I can imagine, and have even considered, using a server for provisioning all phones, for all my servers, and in that case, I can understand how you could apply a different certificate to a provisioning serve.But different for the Admin GUI, Transport, and UDP??? Not sure how you’d achieve that? Shed some light on “How” and “why”. Thanks Dicko!!

I like APIBAN, and the fail2ban client works pretty smoothly with the FreePBX distro firewall

The trick is to use a ‘reverse proxy’ which is then the service that answers all connections you provision it to.

I use haproxy as my proxy and acme.sh as my ‘certificate bearer’,

haproxy has ‘front-ends’ to answer connections and ‘backends’ that describe the ultimate service that will react to connection attempts.

haproxy has two flavors, HTTP and TCP for front-end connections,

so an example front-end would ONLY answer to connections to ‘http(s)://switch.corporate.com/’ but would rewrite port 80 to port 443 and if the resultant certification is kosher, it will forward such connections (with the certificate stripped) to http://127.0.0.1/admin/ucp/, which is part of opensource FreePBX,

Perhaps another ‘front-end’ that ONLY answers to https://noneofyoureffingbusiness.link/’ and forward to a back-end that redirects to http://127.0.0.1:/admin/` which is also part of opensource FreePBX,

Now for TLS connections our TCP front-end only answers to zzyzzx.fart:5061 that forwards successful to a TCP transport on Asterisk running on 127.0.0.1:5060 (that transport’s 127.0.0.1 is awkward to construct in the gooey but can be done, the 5060 is just where TCP defaults to, (I guess you could use 0.0.0.0:5060 but that is just plain sloppy in this scenario and then needs all those blacklists and fail2ban ipsets, whatever as 0.0.0.0 includes ethx/enx/wifi ).

(provisioning similarly).

Now we can tune TLS bindings to get an A+ on sslabs for all three of these domains

If we add a ‘strict-sni’ ssl option to your front-ends then there is no sign that the external ip of your box is listening to IP based connection to TCP 80, 443, 5060 or 5061 and UDP is not responsive to any port to the drive-bys that are 99.9% cause of your current angst

Because none of your domain names will leak to an IP probe, having knowledge of one name is unlikely to leak other ones which kinda beats the remaining 0.01%, who are probably insiders anyway, into submission.

Now acme.sh is a lovely acme client written by Neil Pang that easily allows you to use one of 150 common ‘name services’ to issue as many certs as you want from various CA’s using API’s and acme’s DNS-01 protocol

that precludes any need to have your local web servers be involved with that process, there is no need for pinholes, reserved ports etc that HTTP-01 protocol requires.

acme.sh also has ‘deployment’ scripts for haproxy along with mikrotik, unify and . . . . lots

Now throw in SSH or HomeAssistjnt or Plex or most any TCP layer connection, all can be similarly protected

That should be the last time you need to get involved with certificates as a cron-job will efficiently track daily any need to renew.

To get incredibly funny but cheap domain names go to namecheap.com, Many cloud providers provide complementary ‘name service’ with API’s that acme.sh knows about and namecheap will easily let you change the NS destination of your $12/year domain.

Further haproxy is already part of ‘the distro’ so already installed

IWFM and my /etc/haproxy/haproxy.cfg is less than 200 lines

2 Likes

Wow!! Thanks for that info. You are the Champ Dicko!!

Thanks Lorne. Lots’ of good info. I appreciate your help and guidance.

1 Like