71–80 of 95 posts
Earlier quoted context omitted.
It's worth noting that there's a spiritual successor to XS4ALL called Freedom[0]. [0]: https://www.freedom.nl/
And... they're still just as expensive as XS4ALL was. It's nice the option exists for people willing to pay the premium, though.
Earlier quoted context omitted.
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…
Not the ISP's responsibility.
and if their IP blocks are getting added to "likely scammer" lists because of SIP scams originating on their network, then it's in their best interest to do something do discourage those scams. the people working to defeat scammers aren't necessarily making distinctions between port numbers.
Earlier quoted context omitted.
Not the ISP's responsibility.
I’d argue that a reasonable network limitation with a minimal blast ratio is responsible. For example, I use SIP over 5060 on Spectrum without issue. Not having their network used by bots to inflict untold financial damage is being responsible. Would you argue that implementation of BCP38 to cut down on bots used in DDoS attacks is “not the ISP’s responsibility”? Plus, they get the abuse reports from the victims and…
Yes, do some flood detection, but the problem is that the SIP provider should be, as another commenter put, block international calls or otherwise detect/reject calls to toll systems. Who the heck uses toll numbers anymore anyway?
My ISP breaks traceroute outside of the network. Their transit is cut out of my traceroutes. Full technical story at https://blog.habets.se/2022/05/Another-way-MPLS-breaks-trace...
They are probably trying to reduce SIP abuse. It's a big problem.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
From the wikipedia net neutrality page it looks like the FCC's stance has historically depended on the administration in power. There was the much celebrated 2015 change to title II, which was undone in 2017 i.e. the start of the ajit pai era. Now he is finally gone, but not before casting his vote in a 3-2 decision in 2020 to keep net neutrality dismantled. The new chair is pro-nn and working to undo the damage but…
Lol... I laugh everytime I see Republicans undo things in a matter of weeks and then 3 years later Democrats are like.. we wish we could do something but it takes time.
Earlier quoted context omitted.
I’d argue that a reasonable network limitation with a minimal blast ratio is responsible. For example, I use SIP over 5060 on Spectrum without issue. Not having their network used by bots to inflict untold financial damage is being responsible. Would you argue that implementation of BCP38 to cut down on bots used in DDoS attacks is “not the ISP’s responsibility”? Plus, they get the abuse reports from the victims and…
Nah, just like port 25 outbound being blocked is shitty. How can we have a decentralized net when consumer ISPs make people call in or beg to have full network access? Yes, do some flood detection, but the problem is that the SIP provider should be, as another commenter put, block international calls or otherwise detect/reject calls to toll systems. Who the heck uses toll numbers anymore anyway?
The alternative (today) is the literally millions of compromised PCs, IoT devices, etc that inflict incredible amounts of damage and make even more decentralizing services like CloudFlare essentially a necessity to make sure whatever you're hosting can deal with the possibility of terabits of traffic from a botnet showing up at any second (or SPAM, or VoIP fraud, etc, etc). As it stands now we have both and there is still an incredible amount of trash traffic - see other comments in this thread about people trying to host their own Asterisk instance and having it use 100% CPU just processing all of the malicious trash traffic showing up.
I mentioned blocking international calls by default in another comment. So now you need to contact your provider just to call someone in another country? Unfortunately, yes, that has been the case for many VoIP enabled systems for almost a decade now.
In NANPA (North American Numbering Plan) the international call prefix is 011. This is trivial to put behind a flag. However, after that detecting toll numbers is much more difficult because you're dealing with the entire world at that point and the numbering schemes, etc for toll numbers are all over the place. Additionally, in many countries there isn't any rhyme or reason to their toll numbering and unscrupulous network operators and jurisdictions that don't have a functioning legal system capitalize on all of this. It's been a while but I even remember some destinations in the caribbean taking advantage of having a +1 country code so not even the "international" call prefix block works in that case.
In my past life I was the CTO for a VoIP service provider with hundreds of thousands of business VoIP systems. This issue is very vast and complex while looking from the outside like yet another HN "Why don't you just do X" or "I could solve that in a weekend".
Earlier quoted context omitted.
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 elsewher…
I don't really like the fail2ban approach.
Earlier quoted context omitted.
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…
Not the ISP's responsibility.