Does The Spam Ever Stop?

random_nerd

New Member
Sep 30, 2025
1
0
0
48
Hi all. I'm new to freeswitch. I have some basic setup in place, including using mod_signalwire, mod_callcenter, routing calls with lua, connecting vagents via secure web sockets, etc. Overall I THINK everything is in a pretty good place...

HOWEVER, when I watch logs roll through in fscli, I see hundreds of malicious invites/sip connection attempts from random ip addresses around the World.

Nothing has gotten through (it's all just brute force/dialplans are set to auto hang up), but it does create quite a bit of clutter... is there some form of best practice out there that would lock things down a bit more?

PS. I considered locking the signaling ports to only allow incoming requests from signalwire servers, however their IP addresses don't seem to be publicly available, and they say they often rotate/check domain instead.

Thank You!
 
One thing you can do that will have a big impact immediately is to change your SIP ports to more obscure numbers. This makes it harder for SIP scanners to access you. You can also block unwanted traffic using tools like SBC, SIP proxy, or Fail2Ban.
 
  • Like
Reactions: pbxnerd
Another thing, if you are able to do it, is stop using UDP, if you can get rid of UDP you will see hardly anything.
 
  • Like
Reactions: pbxnerd
Just a PS to that.....

If I spin up a new server and it doesn't get hit within 20 minutes I start to check if everything is working correctly :)

A few years ago I did some testing with honeypot type of thing. I had about 13 random VPS around the world. They were effectively invisible from the sip side of things in that they did not respond at all to sip packets. They just grabbed them and logged them without reply.

The hackers infrastructure is huge.

I have seen EXACTLY the same invite hit 6 of those honeypots in the space of 5 seconds, I couldn't quite believe my eyes but it was true.
 
  • Like
Reactions: babak and pbxnerd
Hi all. I'm new to freeswitch. I have some basic setup in place, including using mod_signalwire, mod_callcenter, routing calls with lua, connecting vagents via secure web sockets, etc. Overall I THINK everything is in a pretty good place...

HOWEVER, when I watch logs roll through in fscli, I see hundreds of malicious invites/sip connection attempts from random ip addresses around the World.

Nothing has gotten through (it's all just brute force/dialplans are set to auto hang up), but it does create quite a bit of clutter... is there some form of best practice out there that would lock things down a bit more?

PS. I considered locking the signaling ports to only allow incoming requests from signalwire servers, however their IP addresses don't seem to be publicly available, and they say they often rotate/check domain instead.

Thank You!
I solved this by using Telnyx for SIP trunking. They publish a small set of static IP addresses for both SIP signaling and RTP media (which is uncommon). That lets you lock down your PBX to accept traffic only from Telnyx’s IPs plus your phones’ static IPs. As long as your phones are on static IPs you can allowlist on the PBX, and you set your PBX admin dashboard to only be accessible from a static IP, you have no ports on the PBX accessible from the open internet. The logs are glorious.
 
Last edited:
Back in the day I tried all sorts to 'close' my pbx to the world, some of which were more successful than others.

One I had was were I ran a kamailio instance on a totally different ip, probably a small vps somewhere.

The main pbx had its ports 5060, 5080 etc closed to the world.

I had the carriers whitelisted.

On the ip phones I had a separate line configured that registered to the kamailio. When the kamailio received a valid registration it would then whitelist the source ip of the phone in iptables on the main pbx, the phone would suddenly appear registered on the main pbx now it was allowed in by iptables.

That worked quite well. It was much more sophisticated in that it would remove the whitelisting etc after a certain amount of time.
 
Back in the day I tried all sorts to 'close' my pbx to the world, some of which were more successful than others.

One I had was were I ran a kamailio instance on a totally different ip, probably a small vps somewhere.

The main pbx had its ports 5060, 5080 etc closed to the world.

I had the carriers whitelisted.

On the ip phones I had a separate line configured that registered to the kamailio. When the kamailio received a valid registration it would then whitelist the source ip of the phone in iptables on the main pbx, the phone would suddenly appear registered on the main pbx now it was allowed in by iptables.

That worked quite well. It was much more sophisticated in that it would remove the whitelisting etc after a certain amount of time.
That's impressive @DigitalDaz . You seem to refer to this in past tense - do you still carry it out this way? And if not, why not?
 
Another option is to lock down the PBX and whitelist the providers, and basic IP addresses for the building where the phones are. Then implement an OpenVPN server and use it for remote and roving workers. This makes the PBX almost invisible on the internet and eliminates the continual probes and break-in attempts.
 
  • Like
Reactions: pbxnerd
Another option is to lock down the PBX and whitelist the providers, and basic IP addresses for the building where the phones are. Then implement an OpenVPN server and use it for remote and roving workers. This makes the PBX almost invisible on the internet and eliminates the continual probes and break-in attempts.
How about running the OpenVPN server on its own separate VPS, and using it essentially as a proxy server, so that connecting phones get that server's WAN IP. Then whitelist that WAN IP in the PBX. This allows the PBX to still be 100% locked down as far as external IPs and ports and avoids having to run OpenVPN on the same server the PBX runs on - as whatever server OpenVPN runs on would still need the OpenVPN ports to be open to the world to allow for phones at locations with a non static IP.
 
Another thing I thought of doing and this was only a thought, I never implemented it......

This is not hiding the pbx, this is more an additional auth factor for a phone....

So, on most sip phones, grandstream excluded, we have a registration expiry time that we can usually set in seconds.

In the sip registration this sets the expire time. In FusionPBX, by default we override this and set it to 120.

It did occur to me that we could perhaps use it as a 'pin' that we then checked. eg set the expires to 123456, we then check when registering that the expires matches that extensions pin, if it does we register and and then override the expires in the usual way in the 200OK. If it doesn't match, we reject and block.