That will return your CN on port 443, I’m suggesting that TLS NOT use that domain’s certificate.
Preaching to the choir. But FreePBX needs to be reasonably secure and trouble free for the unenlightened.
It’s an academic discussion for me personally. I have my own practices and firewall rules - probably more secure than anything FreePBX could ever publish, not not easily generalized.
1 Like
Just change the port to 5061 or whatever obscure port you’re on.
I enforce SNI on all ports used.
On the ip you will get a
139876961207424:error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:…/ssl/record/rec_layer_s3.c:1544:SSL alert number 112
unable to load certificate
140502306256000:error:0909006C:PEM routines:get_name:no start line:…/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
What’s the config option?
In haproxy it’s strict-sni on the bound port, but not easily generalized 
Exactly, that is the purpose of this entire exercise. It’s 100% true that TLS securing of SIP is essential but not everyone wants to put in the legwork for every small environment to configure it correctly.
Yes, there should, but how does F2B help that? Once SIP creds are compromised, and they see packets are being dropped from one IP, so they’ll just move to another IP. The only real help with F2B is for brute-forcing of additional creds on the same server. By the point you lost one device you’re already screwed.
And if we really want to get off-topic, how about changing the FPBX password generation mechanism to not be limited to hex? It’s real nice that the password looks nice and long, but it’s limited to only 16 characters. Once we get a SIP user-agent, any attacker knows how long and what the valid characters for the password are.
We’re not here to discuss every vulnerability, just to fix DoS that RFW and F2B are causing for legit traffic.
But almost certainly ’ they’ll just move to another IP.’ with the same BGP Prefix.
OK, thought I was missing something in asterisk.
Not really an option for the distro.
But good for this Forum “FreePBX Security” we all should have firewalls of course, and it certainly an option for FreePBX, it would work on a Pi also
Perhaps it could be spliced into the webserver
https://cwiki.apache.org/confluence/display/HTTPD/NameBasedSSLVHostsWithSNI
Exactly, using ignoreip will allow the brute force attack to continue indefinitely.
Entirely possible there is a bad actor in addition to a valid user behind an IP. Or even with one set of creds, you want to limit and be alerted of bad actors.
A flat out ignore/unban is too much. An option to allow, ignore, or alert for errors from registered IPs would be about right.
Even with a complete ignore/unban from the firewall, I don’t see any way for a complete fix as long as f2b in its current state sits in front the firewall daemon. A flood of traffic can cause f2b to block the IP before the firewall code has a chance to allow it.
Increasing f2b thresholds will help, but only to a point. Newer versions of F2B might make it easier with better options for incremental banning, but the old version in the distro is problematic.
1 Like
I use the Clearly anywhere module for my mobile devices and I never add IPs for those in the firewall, I move around alot from tower to tower, wifi to wifi.
I do agree though I tend to get some clients get locked out if their IP changes (dhcp changes due to a rebooted modem or PPPoE connection) but thats only from desk phone perspective.
The Groundwire derivatives and other push capable devices are the least problematic because there is no persistent connection between the phone and FreePBX. With Groundwire/ClearlyAnywhere/SangomaConnect it’s the Groundwire servers maintaining a connection to FreePBX.
Even non-push mobile softphones are generally OK. They are aware when the IP changes due to roaming or switching to wifi and re-register before there is an issue. Still, if the wifi external IP changes they have the potental, particularly in the multiple phones behind an IP scenario.
Exactly. Desktop phones are generally clueless about potential IP changes. Add in a few BLFs or more than one phone for an IP and the odds of a lockout escalate.
1 Like
I know practically nothing about UI development and haven’t tested this code at all, but I will try later. I updated the repo in the link above to pass this as a UI option, so we can all be happy. Choice is good.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
You can run ./voipfirewalld manually through the ssh console though.