That’s what APIban is. It’s not perfect, but it’s very good. But really, moving your signaling ports to a high random number together with fail2ban is good enough. I see a couple ips banned a year with this setup.
1 Like
Thank you for the suggestion.
My only concern is that my trunks all use the standard ports and I can’t change the provider’s signalling ports - or am I understanding it wrong and changing signalling ports only affects the extensions (which i can then configure the sip/iax clients to listen on different ports).
That’s why I haven’t changed them still but your suggestion makes me think that I’ve understood it wrong.
edit: I did install APIban but had little or no effect - and @VoIPTek analysis show there are a significant number of ip’s shared that were probably not in APIban list. Does APIban receive input from all freepbx instances to compile their list?
The signalling ports at the two ends can differ. That would be a common case for IP phones.
Thank you for your help!
You mean I can have different signalling ports on my freepbx and my clients (SIP phones and SIP app)? In any case, I can edit the signalling ports on those, I just can edit them on the provider’s side.
I probably understood it all wrong - I will try and change the signalling ports on my freepbx and the SIP clients I use, and check if the trunks keep working.
Thank you all for your help!
In pjsip.conf terms, the port in the bind setting is your signalling port and the port in the contact setting is the other parties. When phones register with you, part of the information they provide is their signalling port.
1 Like
When I mentioned country blocking at the firewall level, you are correct, not the FreePBX firewall.
For internal servers, we block with the location firewalls, with hosted PBX’s, we use as an example AWS, and we utilize their tools to block countries, maybe the VPS or Internet access providers used may also have similar functionality.
In respect to the shared list, the one thing is that the list would be huge, and not sure if we would have to utilize and RBL method to make it work better, but it would add overhead time, and not sure about resource utilization. Maybe a FreePBX team member could elaborate if they feel thats an issue.
I will point out that ‘blocking by country’ is largely futile, the cost of a proxy in another country is cheap, ‘Chinese universities’ and other ‘well known’ bad guys now host on DigitalOcean or Azure.
Over the last week or so seen an uptick of attempts intally from NordVPN and then Surfshark and this week Azure hosting world wide.
we do add ranges to the black Blacklist as well as blocking known ‘bad’ user agents , but they are getting cunning now and using ‘phone useragents’ lately Polycom and Avaya as well as only allowing registration to the configured FQDN and not just IP address, doesn’t stop it all but the vast majority.
TBH it would be nice if the like of the hosting companies could do more to police their egress traffic, but thats never going to happen
I’m very surprised that this isn’t 100% effective against automated attacks. There should be no easy way for a random (automated) attacker to discover your ‘secret’ domain name. Possibilities include:
-
Having a reverse DNS record mapping the IP address to the name. This is easy to fix – just use a name different from the ‘normal’ name for the IP.
-
Using a name that’s easy to guess, e.g. sip.yourcompany.com. Also easy to fix; choose an obscure name e.g. pbx24783.yourcompany.com.
-
If you have a certificate for the name, the attacker could have found it via certificate transparency. This might not be easy to fix. Solutions include a sub-domain issued by your own CA, or name covered by a wildcard certificate. Of course, if you are doing SIP over UDP or TCP, you could use a name for which there is no cert.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.