Hi Guys
Just recently after an update to the firewall module I’ve had one of our users, who are on a Dyanamic IP service, get blocked by the Responsive Firewall.
They have a copy of X-Lite that is logging into our FreePBX server and when his IP changes it’s getting blocked by the Firewall. I then go in and allow his IP and all works okay.
PBX Details
FreePBX: 13.0.192.8
System Firewall: 13.0.45
PBX Firmware: 10.13.66-20
@xrobau Any ideas why he may be getting blocked?
For users that are coming in through dynamic addresses, a good work-around (some would argue the preferred workaround) is to regster the machine in question through DynDNS and use the hostname of the machine. This way, you can whitelist the machine and still use the Adaptive Firewall.
Can you white list on a FQDN?
Yep, you can. As long as the DDNS is updated quickly, it’ll be automatically whitelisted
Thanks @xrobau, I’ve now implemented a FQDN against this user and I’m using that in the firewall rules. Working well.
Thanks @cynjut I’ve done what you suggested and it’s all working well.
@xrobau I’ve had a second staff member have this same problem with getting blocked at the firewall. They are on a Dynamic IP address also using Bria 4.8.1 Build 84929 Authenticating with valid user credentials. This staff member is based in the USA this time.
I’m going to apply the same fix for this staff member but thought I’d mention it here again as I’ve only just started having to do this and never had this problem in the past. Not sure it’s because of an update in Bria or a change in the firewall module.
I don’t understand how this is even an issue.
The whole point of the responsive firewall (as I understand it), is to allow a limited amount of registration attempts from any incoming VoIP connection. If the registration attempt is successful, the remote host is then allowed. Shouldn’t this take care of the Dynamic IP changes?
I agree, and the whole process was working fine up until recently, then I started getting staff members telling me they couldn’t make calls. I would checked the blocked hosts list and their new IP address was being blocked. I would then manually unblock them and all was good, until their IP changed. Something has changed, be it what Bria is doing with registration attempts or the firewall has changed.
Bria could be the common thread, but there could also be a “total number of attempts” problem. If Bria drops the call then picks it back up again for some reason, it might explain it. It’s also possible that Bria is doing something with a “saved” password that’s the wrong password.
Digging into your /var/log/asterisk/full logs might give you more insight into the process that’s leading up to the lock-out.
I have a client with a similar problem. They have about 12 desk phones (Grandstream) that all connect to FreePBX (Cloud hosted) They have solid connections, and the system works great. However, what seems to be every Friday, their ISP changes their IP address. When this happens, they immediately get blocked on the Responsive Firewall. The only way to get them back online is to add that new IP to the Trusted list in the firewall.
Is there a reason this is happening? Could it be addressed in the Responsive Firewall, or do we need to get a static IP address for this location?
Use a ddns provider and place that URL into your whitelist. As long as you have the ddns app running somewhere on that network so that when the ip does change it is reported back you will be good.
@frankb - even if using DynDNS (or other DDNS service), the time granularity can come back and bite you on the butt. If you have several extensions, they could be connecting from the “new” IP, but the DDNS only updates every “X” minutes (where I think X is about 15 minutes).
For sure, DDNS will help a lot, but there might still need to be some tweaking that has to happen.
Do you need one? No, but I’m a strong advocate of using a static IP address. It would make your configuration simpler and get rid of this pain point.
This particular location has a router capable of notifying a DDNS service, when the IP changes on the router. However, I don’t know if it happen immediately, or every 15 minutes. Either way, I agree that a static IP address would be best, and I am trying to get one for that location asap. Until then, I think I will try t he DDNS service.
We constantly have this issue with the FreePBX Responsive Firewall randomly blocking real users. It will be fine for weeks or months and than the user calls me their phone is offline. Sure enough, the firewall blocked them. Most are on GrandStream desk phones.
This just happened today with one of my own remote people.
Can you look at the logs and see why the IP was denied? The likely culprits are too many logins per hour, or too many failed attempts in the period of watching for that.
I finally had the time to look at logs regarding this. I have checked the asterisk/full logs and /tmp/firewall.log. I then greped all the logs I could find for the blocked IP address. I was not able to find any correlation to the block in the logs.
This is still an ongoing issue with our softphone users. It also occurs frequently on the softphone on my mobile phone.
I think there needs to be a way to change the settings as needed to be less sensitive. Also, there needs to be more detailed logging.
Further there is also a need for a better functional description. How does it hook Asterisk? What is it examining to do its business?
This just occurred again today with a Grandstream user. We have this happen frequently with softphone users at their homes.
My softphone on my mobile phone gets locked out all the time as well. I am really frustrated with this. I am ready to just disable it or hack it and fix the settings.
Once marked as an Attacker, a single request in 24 hour period continues you being marked as an Attacker
fpbxattacker all – anywhere anywhere recent: CHECK seconds: 86400 hit_count: 1 name: ATTACKER side: source mask: 255.255.255.255
If you make more than a 100 requests in a 24 hour period you are labeled as a REPEAT
fpbxattacker all – anywhere anywhere recent: CHECK seconds: 86400 hit_count: 100 name: REPEAT side: source mask: 255.255.255.255
50 attempts in an hour also marks you as REPEAT
fpbxattacker all – anywhere anywhere recent: CHECK seconds: 3600 hit_count: 50 name: REPEAT side: source mask: 255.255.255.255
10 requests in 60 seconds, so one every 6 seconds, will get you a shortblock as a REPEAT.
fpbxshortblock all – anywhere anywhere recent: CHECK seconds: 60 hit_count: 10 name: REPEAT side: source mask: 255.255.255.255
Here is how the traffic is filtered:
Chain fpbxfirewall (1 references)
target prot opt source destination
ACCEPT all – anywhere anywhere
ACCEPT tcp – anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp – anywhere anywhere
ACCEPT all – anywhere 255.255.255.255
ACCEPT all – anywhere anywhere PKTTYPE = multicast
ACCEPT udp – anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc
fpbx-rtp all – anywhere anywhere
fpbxblacklist all – anywhere anywhere
fpbxsignalling all – anywhere anywhere
fpbxsmarthosts all – anywhere anywhere
fpbxregistrations all – anywhere anywhere
fpbxnets all – anywhere anywhere
fpbxhosts all – anywhere anywhere
fpbxinterfaces all – anywhere anywhere
fpbxreject all – anywhere anywhere
fpbxrfw all – anywhere anywhere mark match 0x2/0x2
ACCEPT udp – anywhere anywhere state RELATED,ESTABLISHED
fpbxlogdrop all – anywhere anywhere
Basically, despite being in the “registrations” or other allowed lists they still have to go through the rate limiting. If user X is compromised and hacker A connects with their creds then hacker A’s IP is now in the “good lists” and they can reach the UCP, etc. If they starting blasting calls at you then skipping those rate limit checks would allow them to just send calls through you at a high rate with nothing to stop them unless you’re monitoring how many calls.
This could have so many implications outside of just fraud charges. They could slow down your PBX. They could put you at capacity with your provider(s) and start having valid calls rejected. They could get you banned by your provider(s).
Just keep that in mind when you’re thinking about ripping this out and doing your own.
Thanks for the info Tom.
There seems to be something inherently wrong with the methodology or algorithms. I am not the only one who sees these blocking problems. I can reproduce this on my mobile phone by going between 4G and my corporate WiFi for instance. Remote Grandstream phones just seem to randomly get locked out without any correlating log entries on the pbx. There seems to be nothing in the Asterisk logs.
Having to log into the pbx and unblock an endpoint is inconvenient at best. I was on a long car trip recently and became locked out. I was not in a position to log into the pbx and fix it. I can tell you first hand, all I wanted to do was rip out the firewall.
The whole point of the firewall is to be able to have remote users safely and conveniently. If I want safe and inconvenient, I can use a vpn or other methods.
I have been working with Asterisk since version 1.2, many years. I know how much probing and hacking goes on. I would like to have better protection. It likely should be built into the Asterisk core. It is just not usable in it’s current state without continuous frustration.
At a minimum, there needs to be logging to ascertain the cause of lockouts and there needs to be settings to control the aggressiveness.