Responsive Firewall blocking legitimate users

FreePBX
1

I’ve been using the responsive firewall module for about 3 months now, and more or less it seems to be working as it should. I have 8 home users who sign in intermittently from outside the firewall. Users are using Bria 4.4.0 79956 as the SIP client. The PBX itself sits on our internal network behind a Fortigate firewall, with the appropriate ports forwarded. (Off the top of my head, 5060 for CHAN_SIP, 5061 for PJSIP, 200 incoming ports specified in the SIP configuration for RTP media, and 443 for SSL.) The SIP ALG has been completely disabled on the firewall, and the firewall allows and NATs all outbound traffic from a public IP address that is expressly dedicated to that server and nothing else. STUN correctly detects the public IP address of the PBX. Most users also have a VPN connection into the internal network, however, I would much prefer that all of the SIP traffic not traverse the VPN. These users sometimes need to disconnect and connect to other tunnels while on phone calls, and setting the public IP address of the server allows them to stay connected to the server while changing network configurations. (This has been working this way for several years.)

I had an incident a few weeks ago where a single user got blocked by the Responsive Firewall after rebooting his cable modem, (and likely getting a new IP address) but I just wrote this off as a fluke. That user hasn’t reported any problems since that incident.

Monday, I had a different user report that he was unable to connect, with the same error. I was out of the office, and directed him to use the internal IP address over his VPN connection to connect to the server, and that temporarily resolved the problem. Today, he changed the domain back to the public IP address, and he was able to connect, I am assuming because the Responsive Firewall hadn’t detected him as a hacker. His IP address was listed in the “Registered Endpoints” section in the firewall. However, about an hour later, he reported being unable to connect again. There were no blocked hosts showing, and his address was still showing in the “Registered Endpoints,” however, the status page listed that there were currently 4 blocked hosts. It looked like there was either a display issue, or something wrong with the firewall.

I disabled the firewall and re-enabled it, but he was still listed in “Registered Endpoints” and not showing in the “Blocked Hosts.” SIP debug showed absolutely no traffic coming from his IP address, though, and he was not registered. I restarted the “Intrustion Detection” service under “System Admin” and his IP address was now showing in the blocked hosts tab. (I didn’t think to list the IPTABLES before doing this, though, although I imagine I would have seen him in the blocked list.)

I grepped his IP address within the /var/log/asterisk folder, and didn’t see anything interesting. The ./fail2ban log showed several successful “ChallengeSent” and “SuccessfulAuth” entries for his IP address, and the ./full log showed successful registrations, but nothing that looked like any reason he may have been blocked.

Both of the affected users are using the system defined CHAN_SIP port/driver to connect, in case that’s important. I’m slowly migrating some users to PJSIP, and our SIP trunk is currently using PJSIP.

What else can I check on my system to find out why the firewall is blocking his address? Might there be something in Bria that would cause the firewall to classify him as an attacker? Are there any settings that I could tweak in order to prevent users from being seen as attackers?

Any help would be greatly appreciated.

2

The first user just reported to me that he was on the blacklist as well. And the other user I was working with got on it again.

Could this be the result of any recent updates?

3

I am aware of one instance where legitimate SIP clients were getting blocked by FreePBX firewall, and that was due to the client registering and unregistering several times in succession, or repeatedly throughout the day. The Responsive FreePBX Firewall does not do any log parsing, it is merely counting sip registration attempts, and successful attempts look the same as failed attempts.

If you are unable to narrow down the cause of the repeated registrations or it is beyond your control, the solution is to add the user’s address to the Firewall whitelist. If the user is on a dynamic IP, you can use a dynamic DNS clinet and whitelist the FQDN.

4

There are no repeated registrations in the Asterisk logs. Both the ./full log and the ./fail2ban logs show normal and successful registration attempts around once every hour or so while they are active. The client has a SIP registration minimum of 20 seconds, and a maximum of 3600 seconds, so that all seems to make sense.

I could use the whitelist, but it seems like a bit of a kluge, and it’s something that will need to be set up and maintained on all of my outside users.

It’s also possible that this could be related to a Bria update. Is there anything in the “Intrusion Detection” engine that might be detecting these as false positives, which then get read in by the Responsive Firewall? (I’m still a little unclear about the distinction between the two different systems. I get users banned by both ID and RF seemingly independently.)

Thanks for the help!

5

Actually, pouring through the logfiles even more, when I had the user set the domain to the internal address, I see two quick (successful) registration attempts from that address on the first registration. Here is a snippet of logfiles from today.

./full:[2016-03-23 06:16:29] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <EXTERNAL IP>:52220
./full:[2016-03-23 06:17:12] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <INTERNAL IP>:40097
./full:[2016-03-23 06:17:13] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <INTERNAL IP>:40097
./full:[2016-03-23 06:19:59] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <INTERNAL IP>:23104
./full:[2016-03-23 06:20:00] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <INTERNAL IP>:23104
./full:[2016-03-23 07:14:00] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <INTERNAL IP>:9726
./full:[2016-03-23 08:08:00] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <INTERNAL IP>:41955
./full:[2016-03-23 09:02:01] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <INTERNAL IP>:20796
./full:[2016-03-23 09:56:01] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <INTERNAL IP>:38177
./full:[2016-03-23 10:47:16] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <EXTERNAL IP>:58957
./full:[2016-03-23 11:42:13] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <INTERNAL IP>:28594
./full:[2016-03-23 11:42:13] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <INTERNAL IP>:28594
./full:[2016-03-23 11:48:01] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <EXTERNAL IP>:61098
./full:[2016-03-23 13:02:05] VERBOSE[4218] chan_sip.c: Registered SIP 'XXXX' at <EXTERNAL IP>:61098

You can see normal looking registrations. When it stops working, he changes his domain to point to the internal IP address. Both times he does this, there are two registrations in quick succession. Could this be causing the firewall to block him? Is there a way to relax this a little bit? (I’m not too worried about an attacker trying to attack twice. More worried about them attacking 100 times.)

Moreover, if the user has already successfully registered, isn’t he already supposed to be “whitelisted” automatically by the RF engine?

Thanks!

6

Many more of our legitimate users are now being blocked. I suspect that something changed in Bria, and whatever is angering the Responsive Firewall is increasing as users update their softphone clients.

Is there any place where I can dial the firewall settings back a little?

7

[quote=“cmhxaktsoft, post:6, topic:34009”]
Is there any place where I can dial the firewall settings back a little?
[/quote]No, there are no user settings for this.

I missed your last post where you show what you consider to be ‘normal looking registrations’. It is not the two attempts in quick succession that is blocking your user, it is the multiple attempts over the course of 24 hours. If the quoted obfuscated log lines are meant to show that a single extension unregistered and re-registered 14 times in a span of 7 hours, I would not consider that normal. As an example, here is a week’s worth of registration attempts for one of my external phones:

# grep " Registered SIP '2012'" /var/log/asterisk/full*
full-20160319:[2016-03-18 17:51:43] VERBOSE[1313] chan_sip.c: Registered SIP '2012' at <external_ip>
full-20160323:[2016-03-22 11:10:06] VERBOSE[31316] chan_sip.c:     -- Registered SIP '2012' at <external_ip>

I don’t know what is causing your frequent re-registration issue, perhaps that is normal for Bria, and if so that is something that may be of interest to the Firewall dev @xrobau, Unless you can rectify the frequent registration, you will continue to have this issue if you allow the extensions to register through the responsive firewall.

8

@cmhxaktsoft the info I’ve provided above is currently accurate, but there are now a number of open tickets relating to this issue that will probably be of interest to you. Watch for some activity in the next week or two.

http://issues.freepbx.org/browse/FREEPBX-11916
http://issues.freepbx.org/browse/FREEPBX-11917
http://issues.freepbx.org/browse/FREEPBX-11918

9

I believe those registrations to be a normal pattern. As Bria is a softphone application, it can be started and stopped. (And crashed - it’s not the best application…) I know that these users are not typically on the phone all of the time, so they may open their phone application only when necessary, or when their PC is restarted. (One of them is a developer, so I know he only turns on his phone when he wants to make a call. :smile: )

At any rate, I really appreciate the thought that went into the design of the Responsive Firewall, and I would rather not disable it. For the time being, I have added a dynamic DNS client to each of the users’ home firewalls, and a whitelist exception to this address both in the Responsive Firewall as well as the whitelist in the Sysadmin module. I haven’t received any reports lately, so I’m taking that as an optimistic sign that something is better, but I still plan to keep an eye on the issue, and will continue to comment if anything changes.

Thank you for all of your help!