Don’t forget about fail2ban which will scan the logs for activity too and react off that. Because again even a trusted IP can have a compromised device on it and this is another way to monitor patterns from IPs.
Got it. I understand your scenario and what you’re trying to prevent.
It’s just that using a firewall based on numbers of AUTH packets to prevent that is a bad idea. I mean, there’s no reason that I can’t have 100 nomadic devices that end up at the same hotel and registering from a single IP… And the way you are suggesting this is coded would preclude that possibility. Hacked SIP creds are a remote possibility, brute force attacks are far more common and the resulting DOS that comes from all these bots are what most of us are trying to prevent with responsive firewall, not setting call limits for malicious authorized devices… There are better mechanisms in place for that already outside of a firewall.
Well I do hotels for like 95% of my business. Hosted at that. I have 1 hotel out of over 100 using dynamic wan. It is a dive hotel. I have had other dive hotels in the past, same issue. They also had one thing in common, non-branded and independent. Which meant they refused to spend money and do things properly.
A proper hotel has at least a static IP.
I’m talking about non stationary devices. Let’s say I send 20 employees of mine to a conference at a hotel. They call me after 2 hours frantic that their phones aren’t working.
We’re talking here about a hotel I don’t manage… I don’t care if they have a static IP or dynamic, it’s not my issue. I have no interest in being a firefighter. A firewall should not block traffic when there hasn’t been a single malicious packet sent from that IP.
It’s dumb to set call limits or auth limits with a firewall. A firewall is to block illegitimate traffic. Call limits on trunks and extensions are far better suited to prevent the type of attack you are referencing.
So if you have 20 users going to a hotel and you know that, you plan for it. You open up that IP for them while they are there. Simple.
I would also classify a device that was compromised and sending fraud calls out illegitimate traffic regardless of being from a trusted IP.
Almost 20 years at providers/carriers. Compromised PBXes are common and the first complaint from said compromised customer “couldnt you tell our traffic was strange? When do we send 15 calls at once? Why didnt you stop this before we got a $2500 bill?”
The answer “It came from a trusted source” doesnt answered why it wasn’t stopped due to suspicious activity and patterns.
BTW, there is a thread on DSLReports right now about an analog PBX being compromised over a DISA exploit and they got a $33K usage bill. A hard copper line is basically a trusted line.
The biggest fault of the carrier? Not reacting to unusual and suspicious call activity.
I guess we’ll have to agree to disagree. As I said, rate limits on each trunk/extension are the correct mechanism to prevent this type of fraud.
Biy regardless of this discussion, I still see this as a bug in the code. The affected IP isn’t being added to a blacklist, it’s being removed from the good list by the line referenced above, without any event preceding it. Whatever is calling that function isn’t passing the good IP properly so it stays on the whitelist.
For my cases - Yes. Single Yealink IP phone coming from one IP. The provider changes the public IP (PPPoE connections) and the phone registration drops. And remains dropped untill I add the new IP. Sometimes this happens so often that I have to add a whole /24 IP block so I dont have to do it every day… Its a pain.
Bingo. Nailed it. The guys at FreePBX/Sangoma need to sit down and recode this. The responsive Firewall has been around for a long time and looks like nothing has changed in its code. I’d rather have a good working responsive Firewall then some new fancy feature in FreePBX15
I dont have any issues with remote phones or mobile softphones getting banned. Been using them for over a year now without issue…Groundwire on Samsung Galaxy and now for the past month Sangoma Connect and both Ubiquiti and S705’s…no VPN. No whitelisting IPs…
That’s just not a reasonable solution.
It’s an OK work around after the fact, but assuming the phone/IT tech is going to get notice anytime a few employees congregate is ludicrous.
Yes I do.
As indicated here, the biggest issue are phones behind dynamic IPs. I can’t recall many issues many behind a static when I used the Firewall module, unless there was a phone with bad credentials.
Most common scenario seemed to be when the IP the phone is behind changes, the phone continues to send packets without realizing it needs to re-register (and therefore clear the IP by the responsive firewall). By the time is re-registers, the IP has been blocked. Particularly a problem if there are multiple BLFs generating a lot of packets, or if there are multiple phones behind the IP, or both.
Increasing the fail2ban retry limit may help, but the freepbx firewall rate-limit/attacker checks may also block the traffic. Unfortunately those limits aren’t tunable.
Mobile softphones on mobile data are generally aware of when their IP changes and register pretty quickly. A crude workaround can be limiting the softphone to mobile data so it is always aware of IP changes, and (mostly) eliminate the multiple phones behind one wifi IP problem.
Notice? It is a planned company trip. This would be part of the planning.
We are covering all possibilities… Let’s think unplanned trip.
Well for a single employee, this is what VPNs are for. More secure too.
Most common scenario seemed to be when the IP the phone is behind changes, the phone continues to send packets without realizing it needs to re-register (and therefore clear the IP by the responsive firewall). By the time is re-registers, the IP has been blocked. Particularly a problem if there are multiple BLFs generating a lot of packets, or if there are multiple phones behind the IP, or both Increasing the fail2ban retry limit may help
This. Just… It’s not fail2ban. It’s PHP code listed above. I’m seeing that even without IP changes I have problems every so often, but you’re correct that I’m approaching the code from the wrong vantage point. Having a known IP bypass the RFW is important but won’t solve the issue we’re all having.
I think that the first step to any of this is to enable better logging of what packets are tripping the RFW.
OK, I had an idea and made changes to the firewall code, but cannot test it because the file is not signed and the firewall won’t start.
Dev team - how are community members supposed to test firewall code?
I don’t know the proper answer, I just hacked around it when I was doing the certman firewall fixes.
I pointed incron at a bash wrapper script to handle the firewall hooks and passed anything else through to sysadmin_manager.
IIRC, I also had to self sign the module, but standard self-signing didn’t work. I had to copy the signatures from /etc/freepbx.security over the module folder’s sig file or some such nonsense. It’s hazy now and I didn’t make notes.
It was an ugly hack, but was functional enough I was comfortable submitting the PR without waiting for a real answer (or even asking - I guess I should have).
I hope there’s an easier, proper way.