fail2ban started banning vitelity

I’ve been using vitelity for a while now and have had no issues. All of the sudden today, fail2ban bans vitelity’s ip address. Of course this means no calls can come in. I had to whitelist vitelity’s ip address. Anyone know why this would happen? What is fail2ban checking for? Here are the messages fail2ban sent me…

The IP 66.241.99.208 has just been banned by Fail2Ban after
4 attempts against recidive on xxxxx.

The IP 66.241.99.208 has just been banned by Fail2Ban after
4 attempts against SIP on xxxxx.

Same thing happened to me. No idea why it happened. But I think it has something to do with the most recent update to the new firewall module. I disabled, flushed iptables and whitelisted Vitelity’s inbound and outbound IP’s and was able to get back to normal. One issue I confirmed with vitelity is that accounts are being assigned to specific inbound servers. I had been using inbound28.vitelity.net for all of my Vitelity accounts, but now you have to make sure that the inbound IP you are using is the one assigned to your Vitelity account. That and the above got me back to normal, but the new Firewall module seems to still be FUBAR. Every time I enable it with eth0 placed in the “external” zone everything goes haywire. To get back to normal i have to disable the firewall and flush iptables.

I got the new firewall module and even though I don’t use it, I went to system admin only to be told it was now running (forcing it on us mandatory even though I have a real firewall???). I hit abort, but it loaded with the default set of rules which kicked everything off.

Disabling it didnt do anything because those iptables rules were already written (service iptables stop verified this), so I started up iptables and ran the firewall wizard and opened everything on my LAN side, then I disabled the module to stop this from happening again.

Who decided to force the firewall on?

It shouldn’t be! The only time it’s turned on is when you hit the final ‘yes’, or, you go in there and actually turn it on.

Which version was that? 13.0.6?

Yes .06. All I did was click on System Admin and I got a big prompt about how the Firewall is now on. I hit abort after the second config screen and suddenly all of our phones lost connection.

PBX’s don’t need software firewalls, at least not in general. This should be a disabled module by default and only turned on as needed. If we’re using this thing in enterprise we have our own firewalls, vlans, etc. Those who absolutely need a software firewall should learn iptables anyway.

Also the big nag red text about the system firewall being off on the dashboard is absolutely not needed either.

It also started banning Integra SIP switch, as well. Very randomly, as well. What the heck is going on???

I don’t see it under intrusion detection (“Banned IP’s No Banned IP’s”), but I do see it in fail2ban.log.
Also, under intrusion detection, I have it in the whitelist there, as well as in ignore ip in the jail.conf file. In addition, it’s an IP that is allowed in iptables chain.

I have piaf servers that aren’t doing this, it seems it’s only the freepbx distro that this is happening to (as far as I can tell).

That’s interesting. There’s nothing in the code, anywhere, that turns on firewall until you click Yes. Line 21 (not highlighted) is triggered when you click abort, and as you can see, it doesn’t turn on the firewall.

That’s the explicit piece of code there. So I’m guessing that you had already turned it on, and had forgotten about it.

That’s wrong.

That’s right. Sort of. It’s not active, but it’s enabled. There’s a difference.

That’s 100% incorrect, and you’re only saying that because you’re not in IRC trying to help people with firewall problems every. single. day.

That’s because you’ve installed the Firewall module. If you don’t want it to complain about it not being active, then you should uninstall the module.

Fail2ban is really dumb. It looks for failed authorization attempts from remote hosts, and then bans them. So I’m guessing that, for some reason, they’re trying to authenticate to you with invalid credentials, fail2ban is picking that up, and blocking them.

Firewall is much smarter, and doesn’t do that. Sadly, fail2ban is really annoying about jumping in front of Firewall and blocking things that it shouldn’t. It’s on my list of things to care about.

Have you made any changes to iptables from the default setting? I’m trying to figure out what is the same between our setups.

Is everyone else fixed or something?

I added iptables rules to my freepbx server. I’m wondering if everyone else did the same, and maybe that screwed up?

*mangle
:PREROUTING ACCEPT [1103:1400664]
:INPUT ACCEPT [1102:1400632]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [656:59330]
:POSTROUTING ACCEPT [656:59330]
COMMIT
# Completed on Fri Mar  2 10:36:08 2012
# Generated by iptables-save v1.3.5 on Tue Apr  1 11:35:49 2014
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:fail2ban-APACHE - [0:0]
:fail2ban-ASTERISK - [0:0]
:fail2ban-BadBots - [0:0]
:fail2ban-SSH - [0:0]
:fail2ban-VSFTPD - [0:0]
...
-A fail2ban-APACHE -j RETURN
-A fail2ban-ASTERISK -j RETURN
-A fail2ban-BadBots -j RETURN
-A fail2ban-SSH -j RETURN
-A fail2ban-VSFTPD -j RETURN
COMMIT

I can run iptables without any issues as long as I have fail2ban stopped. Otherwise, I have isssues.

fail2ban IS an example of iptables.

I understand. The thing I’m wondering is that I added chains to accept 5060 only from my sip provider’s proxy. Since doing that it seems that fail2ban started blocking them (vitelity in one case, integra in the other). It’s odd to me, also, that fail2ban’s chain would override the accept chain that I configured in /etc/sysconfig/iptables

iptables -L

will show you show iptables’ “list” which is the order of rules/chains packets will traverse through

Not true… fail2ban is only sending commands to IP tables.

If he has issues he can white list his provider in the jail.local file so it will not get banned.

I disagree, iptables doesn’t use “commands” it uses rules, fail2ban adds them to iptables.

http://www.the-art-of-web.com/system/fail2ban/

Umm…it uses rules to determine violations. When a rule is violated it issues commands to iptables to block an ip address.

Sometimes it’s best to go to the horses mouth, as to how it does it’s stuff

http://www.fail2ban.org/wiki/index.php/Main_Page

the chains it builds are dynamically updated in iptables as intrusions are detected, those rules are constrained to the fail2ban chains, the rest of iptables is untouched, the order iptables processes packets ARE without doubt done in the order that iptables -L lists them, if you have rules in place before fail2ban is started then they should be honored, if you add them after fail2bans chains are started then they might conflict The order is important.

So get your iptables based firewall working as you want THEN start fail2ban, if you have a “perfect” firewall then nothing will ever get to fail2ban as it appends it’s chains to the extant ones, if you have used it to fully protect all your services then it can probably catch those clever bastards permitted by the “imperfect” firewall.

When running iptables -L the fail2 ban chains do come up first:

 iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
fail2ban-VSFTPD  tcp  --  anywhere             anywhere            tcp dpt:ftp
fail2ban-BadBots  tcp  --  anywhere             anywhere            multiport dports http,https
fail2ban-APACHE  tcp  --  anywhere             anywhere
fail2ban-ASTERISK  all  --  anywhere             anywhere
fail2ban-SSH  tcp  --  anywhere             anywhere            tcp dpt:ssh

The ip of the proxy was in the ignorelist, but it still banned it.

In my iptables file:

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:fail2ban-APACHE - [0:0]
:fail2ban-ASTERISK - [0:0]
:fail2ban-BadBots - [0:0]
:fail2ban-SSH - [0:0]
:fail2ban-VSFTPD - [0:0]
-A INPUT -p tcp -m tcp --dport 21 -j fail2ban-VSFTPD
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-BadBots
-A INPUT -p tcp -j fail2ban-APACHE
-A INPUT -j fail2ban-ASTERISK
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED -j ACCEPT

Where it starts out with *filter, and I place an -A INPUT before :INPUT DROP?

Perhaps you could document your methodology of exactly how you apply your various iptables rules.

I was a bit lazy with it and installed travelin man, which I’d never had issues with before using PIAF.