Sustained attack! Port 5061


I have a sustained attack on port 5061 which is open for Sangoma Connect Mobile access, the firewall shows:-

171176 [2022-05-17 07:41:05] NOTICE[154162] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘’ (callid: e5f4a146065662e4f7a) - Failed to authenticate

for several different IP’s and extensions (that don’t exist).

Do I:-

Trust in the firewall and fail to ban (which currently has a long blacklist due to this)

Do something else? Suggestions please!

Thanks in advance.


It would be easier if you can explain how you have configured your system. It looks as if your PBX is connected directly to the internet. In case it is not, it’s actually a bit simpler as you could configure the edge router.

I don’t know why an IP like can talk to your FreePBX. I guess it is a configuration issue. I personally never use Fail2Ban, or I leave it in the default configuration, but I don’t really rely on it. But I do have a personal black list for telephony (and other) services.

At the level of iptables/nftables I maintain blacklists, where entire countries and “bad players” are blocked. The “bad players” come from analyzing my log files at various locations and there are typically about 500-600 entries. The entries are actually subnets, which you can easily get from Maxmind’s GeoIP databases. In your case the (assuming that you have not changed the IP) is an older Spectrum address and it is (more or less generally) known that there are a couple compromised Spectrum routers with technically pretty good internet connections out there. I generally block all Spectrum (and other Charter Communications) IPs for European servers. There are a couple of other providers (internet and cloud) that should be treated similarly. I am not saying that these are bad companies, but you do get a lot of dubious traffic from some of their IPs. This ansatz filters more than 99% of the unwanted traffic.

BTW, the “bad players” list depends on the country. In the US you need to block different nets than in Europe.

Why do you have something other than TLS on 5061?

I use PFSense and NAT port 5061 to the PBX, I have used a blacklist firewall rule to block the bad players but they keep coming Thanks for your advise jgttgns I have just checked the IP’s against ipapi - Bulk IP Lookup Tool | Locate IP Address on a Map and the location is all over the globe. Not sure how to proceed.

Bad Players

5061 is too similar to 5060 not to get heavily attacked.

Do you actually need extensions to access you from random networks? If not set your firewall to only pass 5061 from networks used by you extensions and your ITSP.

If possible switch to TLS.

If possible change the port number to something completely different from 5060.

I’m using 5061 soley for the sangoma connect service, I don’t think I can customise this port. Please correct me if I’m wrong.

Well, I always use pfSense or opnSense myself. I am basically using URL aliases in the firewall section for ipv4 and separately for ipv6 (not much traffic yet). I am using a larger URL list to block ingress traffic from China, Russia and a few more, but I collect everything in a single list. pfBlockerNG would also work, but I don’t want to use complex tools for simple things.

For example, let’s look at, which belongs to in Paris and the associated subnet is (Maxmind geoip). So I would block The background is that you very frequently get attacks from the same subnet and/or service provider.

You seem to get a lot of attacks from Poland, France and Romania, but not much from Germany. I guess you are in Europe yourself, probably in the UK (if the initial address is right and based on the attack pattern). If you were in the US you’d see a lot more traffic from German servers, btw.

I hear what you’re saying. The users of sangoma connect are going to be from UK telco’s so perhaps I should have a UK whitelist followed by a deny all.

Can you or someone else explain what Sangoma Connect does in terms of net connections? I am not using it myself.

You may not need to have your PBX open to the world, they ask to allow certain IP addresses:

Source: Technical Details - Sangoma Connect - Documentation

1 Like

Whitelisting those IP is in addition to a proper path from Public WAN to PJSIP transport port…Sangoma Connrct uses TCP by default but you can change it to TCP, UDP or TLS… so if youre behind a NAT router…you need to forward that transport port to your PBX…

I use TLS for Sangoma Connect…

Yes I am using TLS which runs over TCP it seems. Once a call is placed to a mobile device the push notification wakes up the mobile which them contacts the PBX directly on port 5061. So it must be open.

I think perhaps a block of al countries exect UK is the way forward. I may get a performance hit on the firewall though.

The attack continues and fail2ban has been very active!!

Or you could use a default deny config (default setup for incoming traffic on pfSense) and then allow UK, possibly with some exceptions. Blocking is a lot cheaper than going into some protocol negotiations.

It is very unlikely that your attackers are using TCP. I think you have 5061/UDP enabled, for which I see no useful purpose.

Confirmed TCP only opened to 5061.
The attack continues and fail2ban has send me about 150 emails today with no two IP’s the same!
I can watch the asterisk logs files every few seconds another attempt made against it.

Should I be worried, the firewall and fail2ban is working!

IDK what is going on, but I also have seen a TON of attacks and Fail2ban emails on 5061 the last 24hours… I maybe saw 1 fail2ban email a month for the past few years. I wonder what changed/happened…

If you have exposed any signaling port to untrusted traffic, you will get fail2ban notices when intruders are banned. It’s working as expected. If you would prefer to get a few ban notifications a year instead of a minute, change the signaling port to some high random number in the 50k range. It’s not securing anything, but it will make the logs quieter.

Blacklists are pretty worthless IMO, but if you want to go that route suggest using something dynamic like APIBan.

1 Like

So I do use high random number 50k range signaling ports for everything but TLS… I was under the impression after working with support on my D80 that due to the D80 having to use FQDN and TLS that you had to use 5061?? Maybe I misunderstood that and you just had to use TLS but can change TLS transport to any port you want?? Same for Sangoma Connect TLS/SRTP??? That is the ONLY reason I have 5061 open in my firewall…All other ports are not open…

Asterisk isn’t normally configured to check the common name of the certificate, so it is possible that TLS is no longer a safe option, as the real point of certificates is to confirm that you are talking to the owner of a particular common name. The encryption only really protects against local wire tapping attacks.

Although people don’t seem to like “self signed” certificates, which often means really having a private CA, rather than actually self signing the working certificates, either that, or verifying common names are the only ways to really use TLS to prevent a SIP request getting through.

Nothing an stop attacks other than having no internet presence; it is just a question of at what point you detect and presumably, log them. You’d still be under a sustained attack, even if your router is catching them all. All you can do is reduce the number that get a chance to test a user password combination, or a source IP address.

Given that Freepbx WILL (by default ) “verify server”

Can you expound on your position?

More expansively, you could likely use self signed certs for your TLS phones (not wild cards) , but if you use the same self signed cert for your gooey, it probably won’t work so well

There is no technical reason to use the same cert for all your TLS services, and adding strict SNI checking to your various DNS names can pretty well deny DNS leaks on a preliminary HTTP 1 to your public URL thus any IP based connections to your PBX server or indeed to the ‘public’ https server, which uses another cert for VOIP’s TLS service would be unsuccessful