Glad this is at the top. The linked Reddit thread demonstrates a common but fundamental misunderstanding of SIP.
Port 5060 is used for call control and is very low traffic. At most you may have timed OPTIONS messages but a “standard” SIP deployment is at most a handful of (small) packets per second per call setup and tear down with occasional REGISTER messages on an interval measured in seconds. Very low traffic and very low bandwidth. Obviously with more devices you get multiples of these numbers but still very low. 15 kbps is a pretty significant amount of SIP traffic.
This is most likely targeting VoIP abuse from tools like sipvicious. In a nutshell they scan the internet looking for open SIP ports. They then try to brute force credentials to place calls.
Why? Toll fraud. The scam works like this:
1) Setup an international toll charge number in some country. Let’s say it charges $5/min. For those that don’t know calls to these numbers get charged to the person placing the call from their phone company and end up on their phone bill with the amount getting paid out (less a cut) to the operator of the number.
2) Compromise a bunch of random exposed SIP implementations on the internet.
3) Place calls to your (or a partners) toll number.
4) Get paid from the toll charges.
5) Some time later the owner of the compromised system gets a huge bill depending on fraud detection systems at the carrier, how fast you could pump calls, etc.
It’s gotten so bad many VoIP providers block international calls by default and now (apparently) might be blocking 5060 traffic in some way.
This isn’t that different to what’s happened with SMTP over the years. To combat spam many last mile ISPs started blocking outbound TCP port 25 so compromised machines couldn’t directly send spam. This is where port 465/587 for SMTP “submission” came from.
The real abuse of course is $5 a minute toll line. The ability to rack up that kind of charge should be opt-in, there’s basically no legitimate use case.
Ah, yes. The classic "all our customers are morons" approach, with no opt-out for those 0.1% who, in fact, are not. Very typical among ISPs/Telcos.
Where I am, we used to have a different, "nerdy" ISP [0], where customer was allowed to bring their own modem; they also provided real IPv4/v6 dual-stack since forever, easy to request a /29, tech-support that's realistic to reach, and staffed with people who know what they are talking about, no bulk-firewalling port-25, etc... All for a modest 2x price increase over market average. Alas, they're out of business now.
My guess is that the 2x price increase Xs4all was charging for their plan was a bridge too far for most customers. It's important to keep in mind that the vast majority of people rent their modem, don't know or care what a /29 is, and is calling tech support because the plug is loose or the modem needs a power cycle. Bulk-blocking SMTP happened because open ports are botnet ports, and the average customer does not know how to identify and shut down zombies on their network.
[0] Assuming your provider isn't stupidly committed to "you can't have business class because you're in a residential area, WFH doesn't exist, and the zoning code is gospel, all hail Robert Moses"
> Where I am, we used to have a different, "nerdy" ISP [Xs4all]
I remember Xs4all, sorry to hear they went under.
I also miss the brief moment when we had line sharing on copper telco networks in the United States. Most people were perfectly happy with the standard offerings from their local telco, but those of us who wanted more could connect with an ISP who offered service via a dry pair DSL connection. I loved my time on Speakeasy, for example.
I remember all of the flaws with the line sharing system, too, but it actually worked for the short time we had it, in spite of the problems. Asking a niche ISP to build its own facilities-based network is an exercise in futility for many deployments. Of course, cities or counties or public utility districts could do it but the incumbent providers don't like that.
Yeah, running SIP on a standard port without some serious firewall based rate limiting for unknown traffic is almost impossible.
I tried running a PBX on UDP 5060 and got >4GiB of logged register attempts in a few hours after opening the port, while asterisk was running at 100% CPU just rejecting the registration attempts the whole time.
It's insane compared to any other public service I run.
Have you tried fail2ban[0]? It can take log output from Asterisk and automatically insert iptables DROP rules for the source IP to block the traffic in the kernel. It still shows up on your interface and uses your bandwidth but dropping the packet in the kernel is much more efficient than Asterisk dealing with it (not to mention safer). It should also cause the bad actor to eventually give up on you and move elsewhere.
I'm not running my own service. I'm using www.iptel.org, they offer a free sip account. Under the hood they use the Kamailio sip server. It is pretty darn reliable for a free service.
Every few months iptel.org goes down for a few hours and I get 408 request timeouts. When Spectrum blocked 5060 UDP, I got 408 request timeouts for a week. It finally dawned on me to try my iptel account on my VPS and my SIP register succeeded. That's when I knew Spectrum had shut 5060 UDP. I tried 5060 TCP and that didn't work either.
I wrote a script that monitors the asterisk log and uses iptables to block any IP with a failed request. Problem solved. Sometimes I check how many IPs are blocked, it's astonishing.
That doesn't make what they're doing okay. To see why, imagine that they instead blocked access to all email services except their own, since spam is a big problem.
That's basically what domestic ISPs do. You will probably find that outbound traffic on port 25 is blocked, because all of your pwn3d inadequately-patched Windows machines are spam cannons now.
I’ve come to treat residential ISPs as basically a transit for HTTP. As someone else in the thread pointed out that’s all that 99.99% of customers care about, and unfortunately you’re talking about a lowest common denominator here.
kkielhofner|3 years ago
Port 5060 is used for call control and is very low traffic. At most you may have timed OPTIONS messages but a “standard” SIP deployment is at most a handful of (small) packets per second per call setup and tear down with occasional REGISTER messages on an interval measured in seconds. Very low traffic and very low bandwidth. Obviously with more devices you get multiples of these numbers but still very low. 15 kbps is a pretty significant amount of SIP traffic.
This is most likely targeting VoIP abuse from tools like sipvicious. In a nutshell they scan the internet looking for open SIP ports. They then try to brute force credentials to place calls.
Why? Toll fraud. The scam works like this:
1) Setup an international toll charge number in some country. Let’s say it charges $5/min. For those that don’t know calls to these numbers get charged to the person placing the call from their phone company and end up on their phone bill with the amount getting paid out (less a cut) to the operator of the number.
2) Compromise a bunch of random exposed SIP implementations on the internet.
3) Place calls to your (or a partners) toll number.
4) Get paid from the toll charges.
5) Some time later the owner of the compromised system gets a huge bill depending on fraud detection systems at the carrier, how fast you could pump calls, etc.
It’s gotten so bad many VoIP providers block international calls by default and now (apparently) might be blocking 5060 traffic in some way.
This isn’t that different to what’s happened with SMTP over the years. To combat spam many last mile ISPs started blocking outbound TCP port 25 so compromised machines couldn’t directly send spam. This is where port 465/587 for SMTP “submission” came from.
TheWoodsy|3 years ago
Don't get me started on the bajillion 3G+ modems here with default passwords.
tinus_hn|3 years ago
unknown|3 years ago
[deleted]
devwastaken|3 years ago
nousermane|3 years ago
Where I am, we used to have a different, "nerdy" ISP [0], where customer was allowed to bring their own modem; they also provided real IPv4/v6 dual-stack since forever, easy to request a /29, tech-support that's realistic to reach, and staffed with people who know what they are talking about, no bulk-firewalling port-25, etc... All for a modest 2x price increase over market average. Alas, they're out of business now.
[0] https://en.wikipedia.org/wiki/Xs4all
kmeisthax|3 years ago
My guess is that the 2x price increase Xs4all was charging for their plan was a bridge too far for most customers. It's important to keep in mind that the vast majority of people rent their modem, don't know or care what a /29 is, and is calling tech support because the plug is loose or the modem needs a power cycle. Bulk-blocking SMTP happened because open ports are botnet ports, and the average customer does not know how to identify and shut down zombies on their network.
[0] Assuming your provider isn't stupidly committed to "you can't have business class because you're in a residential area, WFH doesn't exist, and the zoning code is gospel, all hail Robert Moses"
techsupporter|3 years ago
I remember Xs4all, sorry to hear they went under.
I also miss the brief moment when we had line sharing on copper telco networks in the United States. Most people were perfectly happy with the standard offerings from their local telco, but those of us who wanted more could connect with an ISP who offered service via a dry pair DSL connection. I loved my time on Speakeasy, for example.
I remember all of the flaws with the line sharing system, too, but it actually worked for the short time we had it, in spite of the problems. Asking a niche ISP to build its own facilities-based network is an exercise in futility for many deployments. Of course, cities or counties or public utility districts could do it but the incumbent providers don't like that.
jorams|3 years ago
[0]: https://www.freedom.nl/
water8|3 years ago
[deleted]
megous|3 years ago
I tried running a PBX on UDP 5060 and got >4GiB of logged register attempts in a few hours after opening the port, while asterisk was running at 100% CPU just rejecting the registration attempts the whole time.
It's insane compared to any other public service I run.
kkielhofner|3 years ago
[0] - https://github.com/fail2ban/fail2ban/
another_comment|3 years ago
Every few months iptel.org goes down for a few hours and I get 408 request timeouts. When Spectrum blocked 5060 UDP, I got 408 request timeouts for a week. It finally dawned on me to try my iptel account on my VPS and my SIP register succeeded. That's when I knew Spectrum had shut 5060 UDP. I tried 5060 TCP and that didn't work either.
jacob019|3 years ago
josephcsible|3 years ago
Gordonjcp|3 years ago
chrismeller|3 years ago
im3w1l|3 years ago
3np|3 years ago