System Admin >Intrusion Detection

What would the setting be to Ban someone forever?

When it comes to my networks I am cold blooded. None of this 3 strikes and your out thing. If the system bans an IP it is for a reason and I don’t want the system to stop banning them until an Admin has a chance to review the situation.

Can this setting be 0 meaning forever?

Also what about adding known IP addresses of abuse. Over the years I have collected IP address of known hostile machines. Can this be added here?

Also ranges of IP addresses. Again I know of entire subnets that have no business in my systems.

FreePBX and for that matter Asterisk do not do any type of intrusion detection or banning.

Two common strategies exist for intrusion detection. Fail2Ban and APF with Brute Force Detection.

You can modify the rules to suit you preference. Keep in mind if you have 1 invalid registration from a legitimate extension then you will have to release that IP from the jail.

Both APF and iptables that Fail2Ban uses have geo banning and ban list options.

Sorry I wasn’t clear in my question.

I understand completely how it works and where to go to edit APF and Fail2Ban manually.

This is directly related to the 2.9 distro and menu option.

System Admin >Intrusion Detection

What is the value for the setting “Ban Time” to forever? Would it be Zero to represent forever?

It would be nice to have more details in the hover over.

We also can’t seem to manually add IP addresses from the GUI. Again this is just pertaining to the new 2.9 GUI.

Was the intent for this page to be information or actual settings to be changed at will.

This module is designed to let you change all settings except the banned list. That will show you which IP’s are banned at anytime. I do not know of any way to manually ban a IP forever. You can always setup iptables rules to do that.

Remember all fail2ban does it setup iptables rules. When a IP has been banned you can do iptables -L and see all your rules and you will see the blocked IP. If you want it blocked forever than go and setup a iptables rule.

There might be a way for fail2ban to block them forever but I am not aware of any at this time.

No worries. I have bash command script we currently use with Fail2ban that does that for us. I was hoping for a gui. Its all good.

Side question - Why Fail2ban vs APF

Because we at Schmooze have been using it for years and its part of our sysadmin module already. Thats the short and easy answer.

Most of the things in the distro are in there because we are jsut taking our existing commercial product and stripping our parts to make the open source one.

Also the GUI allows you to manage your basic fail2ban settings. The only real issue you have is you want to ban someone forever which is not part of fail2ban as far as I can find. We are looking at releasing a iptables GUI management at some point but right now that is not part of the open source distro.

In the current freepbx distro iptables is launched by a script so we cannot webmin to edit rules. do we just do a -a for a new rule and then an “iptable save” to make it persistent across reboots? I want to block all SSH but a small group of known IPs for example. or allow sip and rtp only from another group of IPs.

disable fail2ban, do your firewall rules, re-enable fail2ban, it is a set of chains that are added to iptables on invocation.

Thanks… Will try it out.

I usually edit /etc/sysconfig/iptables directly (using vi :wink: and then restart iptables which loads the rules in /etc/sysconfig/iptables. fail2ban then just appends and deletes rules dynamically.

Fail2ban will as you say append it’s chains, it will not do so if iptables is restarted, how will it know ?

But either way, vi or webmin, both will work if you do as I suggest

An easy easier solution, use CSF or similar, it makes it all way easier for application specific firewalls, for CSF there is even a webmin plugin, so just edit /etc/csf/ (and the same post) to control Fail2ban appropriately and you are hunky-dory.

(and a cell phone interace for on the go for re-allowing an errant client who stumble fingered)

I’m still trying to figure things out but found that if I stop fail2ban and add iptables entries, then save tehn start fail2ban, I get the default configuration as if I had done nothing. on the other hand, if I add rules while fail2ban is running, those rules are applied. Now to figure out how to make them survive a reboot. These are typed at the CLI:
iptables -I INPUT 1 -i lo -j ACCEPT
iptables -I OUTPUT 1 -o lo -j ACCEPT
iptables -I INPUT 2 -p udp -s --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT
iptables -I INPUT 3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT 4 -p tcp -s IPADDRESSITRUST -m multiport --dports 21,22,80,81,443,4445,5038,9001,9022 -j ACCEPT
iptables -I INPUT 5 -p udp -s IPADDRESSITRUST -m multiport --dports 69,4569,5060,10000:20000 -j ACCEPT
iptables -A INPUT -j DROP
an “iptables -L --line-numbers” shows the result.

I’d appreciate comments on the above as I must confess to be a neophyte when it comes to Linux and IPTables.
Also note that I have a lot of ports open that need not be open to all IP Addresses you may want to include. this was mostly for testing/learning. The IP address of your sip provider only needs UDP 5060 and RTP ports is using SIP. Enpoints outside the the LAN also need those ports and SSH should only he allowed from your management network. Fail2ban is still there but doing a lot less. Again, please comment/correct my assumptions. Thanks.

CSF/LFD will do all that for you and more after you RTFM.

There are two scripts available and , is run before csf and there you can save any iptables state you care and perhaps stop fail2ban if running for cleanness, as starting csf will flush your iptables. is run after CSF has done it’s dirty work and is the ideal place to start fail2ban as a service whereby those chains are added to CSF’s in an orderly fashion, also any other rules that csf can’t do of which there would be very few.

Actually you could create a file with your firewall rules in it and read it into the fail2ban process. This way your not altering IPtables or the work that Schmooze has done with their System Admin. When freePBX gets restarted or you updated your settings it would get included in the IPtable rules. You would edit it by using putty or winscp. Port editing really doesn’t happen often so there really is not need to put a gui on it.

It would work much like a Black list. Let me see if I still have those scripts.
We messed this this a few years ago and had it working quite nicely. We have since moved to much different aggressive edge configuration and have taken the burden of this off of freePBX. Let FreePBX and Asterisk do their thing and process calls. Handle security before it ever gets to your IPBX.

Oh to answer my original question from 2011. The answer is -1 is the setting for ban forever. But if the system ever gets restarted or updated those bans get removed from IP tables. Our solution was to write the bans to a txt files and recall them when fail2ban refreshes or update. We also went so far as to sync the ban file to a sql sever to update all of our systems.

That sounds like what I was aiming for… I thought a script that would run on schedule or at restart. I do not know where in the freepbx distro (4.211.64-7) fail2ban script to call the file though. will have to do some digging in the startup scripts. I keep a test install for that as I’m learning.

Snooper1, please explain how you would “read it into the fail2ban process” as far as I have read there is no mechanism to do that within fail2ban. it creates chains for iptables on top of what is there, no?

been using this exact method for some time - works great