Fail2ban : white list a FQDN and/or a CDIR

Following that page : https://blog.rimuhosting.com/2017/02/24/whitelist-your-own-computer-in-fail2ban/ it looks possible to whitelist a domain name instead of an IP.

However, nethserver’s UI (cockpit and server-manager) don’t accept FQDN. Is it wanted ?
That could really be useful to whitelist a dyndns address.

Also I’d like to know if Fail2ban takes the Trusted networks into account ? This can be useful for whitelisting the openvpn tunnelled traffic coming from a remote site.

Txs

Matt

1 Like

Yes it is wanted at least when I started first the dev, now things could change cc @giacomo @davidep

I never wanted to see a network that allows the whole internet here… It is against security

Relative to the dynamic domain name, it could be a hole in the security.

The IP could be used by someone else and your dyn dns has not been updated
The dyn dns could be used also by someone else

You never be sure, your IP is sure

2 Likes

I back Stéphane opinion. Still I will not raise any argument if we want to change it.

Mmmh. I see, but the update client needs a password to make changes… That password could be hacked or leaked but that’s the issue with all passwords…

DNS hostname can be “poisoned” via external cache poisoning. Ip address should presume something more difficult to achieve.

+1 on @stephdl opinion

1 Like

okokok :slight_smile:

2 Likes

Hi,

I’m back on that subject. My customer is really annoyed that it’s whole team (read : an IP shared by a cy) gets regularly blocked because of one guy forgetting it’s password or misconfiguring a client app that starts frantically trying to log over and over with a wrong password and gets the public IP kicked off because of recidive.

In my view the chance that one could exploit a dns poisoning weakness (read : OVH’s DNS server in my case !) or whatever to try to circumvent fail2ban and further breaking passwords by using bruteforce is really mitigated by the fact that such an attacker would have to know the right (dynamic) IP, and then have enough time to break in.

At least in my case I’m ready to take the risk in favour of the end user experience. People writing their password on a post-it are much more dangerous !

Another case that will inevitably trigger fail2ban is when a user legitimately wants (or have to) change its password : As soon as he changes his password using the GUI, all it’s client apps using caldav, IMAP, SMTP, Nextcloud sync client, or whatever protocol monitored by fail2ban will fail multiple times and will eventually block access before the user realise that he has to change the password everywhere. This is a real world observation !

So in my view, while whitelisting a CIDR could obviously be a bad idea, allowing a FQDN might actually improve the security by not discouraging users to change their password.

What about allowing FQDN’s provided the admin is warned that it could be a security issue and that (s)he has to know what he is doing ?

Txs for your attention

Matthieu

1 Like

Why to not make a custom template of the jail.local and put the whitelisted network?

:thinking:

because I’m a GUI addict ? :slight_smile:

Fail2ban is a core part and a security trick will be pushed to everybody, it not only concerns me but a lot more of people.

The good news now are that we are pushing new improvements…

What do you mean exactly ? :slight_smile:

I worry that we cannot cover your case, but we can help you to make a custom template and adapt your need to fail2ban

Edit: in short, your customer won’t see any differences and you will reach your goal @pagaille

I am at the nethesis event but saturday I could help you during my stopover at Munich

1 Like

So you will make a custom template of a file that I could possibly modify one day…keep it in mind. I have chosen a file that even if I modify it, you should have not much troubles

mkdir /etc/e-smith/templates-custom/etc/fail2ban/jail.local -p
cp /etc/e-smith/templates/etc/fail2ban/jail.local/01localaccess /etc/e-smith/templates-custom/etc/fail2ban/jail.local

and replace

$localAccess .= join ' ',
    map { s:/255.255.255.255::; $_ }
        @localAccess, @ip;

by

my @DynDns =  ('titi.it','tutu.tu');
$localAccess .= join ' ',
    map { s:/255.255.255.255::; $_ }
        @localAccess, @ip, @DynDns;

you can put how many dyndns you want, only respect the way the array is written

3 Likes

Including toto.com ? :slight_smile:

TXS Steph :blush:

That said, I wonder if I’m the only to setup a dedicated server outside an organisation’s premises with all the fail2ban nightmares that such a setup implies.

That said I imagined another way to achieve this : since there is an OpenVPN tunnel between the servers and the customer’s premises, I should have defined local DNS entries to point to local adresses to get the traffic directed through the VPN tunnel instead of the internet way.

Yes all local network as added as safe network