Fail2Ban Guide for servers on the internet

Hey Wazo Enthusiast,
why do attackers have interest to attack your PBX? Making money is the biggest I guess, dialing expensive foreign country or service numbers etc. They try to find out which extensions are enabled with spamming INVITEs.

When I started off and accessed the asterisk console (asterisk -rvc, pjsip set logger on), I got several malicious invites per second.
My first ban attempts got me lists of 50+ IP addresses on ban. The attackers also try different methods.

I did a lot of research to secure my server with fail2ban without using a proxy and want to share with you a compact set of results.

Let’s tighten our firewall. I use fail2ban in conjunction with iptables. First thing you want to do is adding extra security output into the log:

In “/etc/asterisk/logger.d/01-wazo.conf” add “security” output to fail2ban like this:
fail2ban => notice,security

Now open “/etc/fail2ban/filter.d/asterisk-wazo.conf” and extend the failregex = with following line:

SecurityEvent="ChallengeSent".AccountID="<unknown>".\/UDP\/<host>\/.*,Challenge=""

Registrated users have valid AccountIDs so when it is unknown, somebody attempts to guess himself in.

If we have “true friends”, we can also enable the recidive jail.
/etc/fail2ban/jail.d/recidive.conf
[recidive]
enabled = true

Now from time to time there is a false positive which forces you to unban manually. This is no option with production servers, so I decided to get a whitelist in place. Whenever a user logs in successfully, his IP will be whitelisted for a day (ignorelist on fail2ban). We need several files for that. On windows please check twice, that you use LF for Line-Breaks when you copy paste from here, otherwise fail2ban will fail.

/etc/fail2ban/filter.d/wazo-whitelist.conf
[Definition]
failregex = SecurityEvent=“SuccessfulAuth”.AccountID="[a-z0-9]{8}"./UDP//.*,UsingPassword=“1”
ignoreregex =

/etc/fail2ban/action.d/ipwhitelist.conf
[Definition]
actioncheck = iptables -nL | grep -q ‘f2b-ASTERISK[ \t]’

actionban = fail2ban-client set <name> addignoreip <ip>
                    #fail2ban-client set recidive addignoreip <ip>

actionunban = fail2ban-client set <name> delignoreip <ip>
                        #fail2ban-client set recidive delignoreip <ip>

[Init]
name = default
chain = INPUT

/etc/fail2ban/jail.d/wazo-whitelist.conf
[wazo-whitelist]
enabled = true
port = all
action = ipwhitelist[name=asterisk-wazo]
logpath = /var/log/asterisk/fail2ban
maxretry = 1
bantime = 1d

When you are done and saved everything,
fail2ban-client restart
wazo-service restart

I hope I got everything important covered. Otherwise please ask. Enjoy the silence

1 Like

Nice!

THank you for the detailed instructions; I’ll try this out.

I was working with fail2ban and was not getting the results I wanted until I read that fail2ban does not add itself to the iptables list until it is triggered (ie someone violated a fail2ban setting). SO I forced a ssh failed login 5 times and then the sshd module loaded and showed in my iptables listing.

Have you figured a way to force all fail2ban enabled modules to load into iptables without there being a violation in the module?

\It is not required but it does help me when setting things up to confirm the settings are working.

This is the perfect place to ask that because in fact I am doing this here: A whitelisting is de facto a “ban” in a perfectly good situation (successful login). However we do not execute the action “ban” but “ignoreip”.

The way I would go about your question is setting up your filter the other way around. Say you want to find if somebody violates your condition the findregex would be something like = login.*IP.*failed you can just reverse that by recognizing the success attempts = login.*IP.*success to find out if it works. Now, depending on the setup you should swap the action. Either you ban of course but risk to logout yourself. Or you whitelist or you can even setup a custom action with something like log into a file or sendmail, too. You can basically use any bash commands in the “action”.

When it comes to ssh you have to be very careful, because you risk a permanent lockout. Dont mess too much with the jails (which have good default configs by the way). Consider using a ssh publickey authentication, which renders the firewall almost obsolete anyways. You can also limit the number of login attempts in ssh configs. If you have another server with a permanent IP, consider permanently whitelisting that for the emergency case of self-lockout.
In practice, my ssh jail is almost always empty because of pubkey auth I think.

If however you have locked yourself out, try login on a cellphone hotspot, via proxy or via the emergency server mentioned above.

PS: If you post details of what you are trying to do, we can figure the best way out here. Just post your Failregex and your Action.