Massive sip attack?

[ashcortech]

Anyone else seeing a massive amount of nefarious SIP connection attempts since yesterday? My Fail2Ban notifications are off the chart.

[wifx]

No more than usual here, it comes in waves here, some days it’s a lot, some days less.

[PitzKey (Itzik)]

Use APIBAN to limit known bad actors from reaching your servers. It is super easy to set up.

Integrating apiban.org with FreePBX

The last few Open Source Lounge sessions have seen conversation around apiban.org, with last night’s session getting a detailed presentation by Fred Posner on how it all works. The apiban.org project is a SIP blacklist compiled from honeypots with a simple API that allows you to dynamically update iptables rules with known current attackers. Generally I’m not a fan of blacklists on principle, but there are obviously situations where whitelisting won’t work. If one is working with this constraint…

[dicko]

If you don’t listen on UDP/5060 you will get very few ‘attacks’

AFAIK APIBan only concerns itself with such traffic, much as VOIPBL does and similarly is only granular at the originating /32 host.

In the real world, once one ‘sniffer’ finds such a port open, then very soon a whole bunch of ‘sniffers’ are now aware of your vulnerability, (like it or not SIP over UDP/5060 is a huge vulnerability ), mostly from the same ASN, but they are quite clever, and Palestinians apparently talk to Belorussians

If you insist on listening to UDP/5060 ( go figure that one . . .) , then you will often see many other ‘sniffers’ located in that ASN .

So a couple of questions . . . .

Why does anyone still listen on UDP/5060 in 2022 ?, talking of 22, what is your ssh server listening on and do you allow passwords there?
If more than a couple of ‘sniffers’ show up in the same ASN, why not consider dropping that whole ASN

True, that might drop the whole of COX or Microsoft or DigitalOcean . . ., so be picky, but a decent blacklist would be better identifying rogue ASN’s and not get bogged down on individual IP addresses you should previously whitelisted known ‘good-guys’ .

Any way you figure it, 100000’s of iptables rules will impact your QOS, even a reduced ipsets based on ASN’s is not good. Using only TLS for all your extensions will almost always result in a MayTag like quiet filter . . .

JM2CWAE

[ashcortech]

@dicko

If you don’t listen on UDP/5060 you will get very few ‘attacks’

I never use 5060, haven’t for years. yet attacks still come. It is what it is. I tightened up the VM firewall on this install as much as possible and that seems to have quelled it.

[dicko]

Please briefly describe the nature of these massive attacks,

Is your port ‘well-known’ i.e. between 5000 and 5999 ? this significantly reduce the surface
,
Have you tried TCP ? this will further reduce the surface

Have you tried TLS ? this will virtually eliminate all but malicious insiders.

Don’t confuse inbound traffic on UDP/5060 with an attack, using sngrep, if the ‘session’ has only one ‘message’, you are not at risk, the only way to prevent this noise is with an upstream firewall blocking such traffic. A good use for the VULTR/DO type firewall rules.

[BlazeStudios (Tom Ray)]

I’m just going to say that while not using 5060 can be helpful, it’s not a rock solid answer or solution. Can it lower the amount of scans/attacks? Sure. Does it completely stop the scans/attacks? Not at all. Let’s keep in mind it’s been about 20 years of people on public forums telling everyone “don’t use 5060, it will stop those attacks” and bad actors pay attention.

There is also the fact that 10-15 years ago scanning a massive amount of IPs and ranges over those IPs was costly to those doing it in regards to resources and bandwidth. Today? Doing massive port range scans and scanning massive amounts of IPs (like /64’s and /56’s on IPv6) are much easier to do and the resources/bandwidth isn’t a negative factor like it used to be.

As for the TCP/TLS part, again you need to pay attention to the big picture. Over the last 5 years or so there has been a massive push to TLS for VoIP. That hasn’t gone unnoticed nor has it ever been free of attacks. You can have TLS and still be compromised due to weak passwords, etc… There is also the fact that using TCP/TLS opens you up to an attack vector that doesn’t exist with UDP. TCP/TLS require connections to be established. There will be a handshake process, until that handshake is completed (accepted/denied) or reaches a timeout that connection stays. So if you are hit with a flood of 2,000 requests over TCP/TLS, you are waiting for 2,000 handshakes to be processed unlike 2,000 UDP requests and just get dropped and killed.

Just like anything this is a Pro v. Con situation and you always have to make sure that while there are nice Pros to using TCP/TLS on non-standard ports. There are also Cons for doing the same. You need to make sure both are known and addressed.

When those attacks happened last September and Bandwidth got hit. My voice (UDP) barely saw an impact (less than 10% issues over a week) but during that attack any of their services I used over TCP/TLS such as messaging APIs or other API base services where completely dead in the water or sporadically worked. Any of the customers using TLS based voice or their programmable voice platform (all HTTPS API calls) where seeing the same issue. Either not working or barely working.

[ashcortech]

@dicko

Don’t confuse inbound traffic on UDP/5060 with an attack, using sngrep, if the ‘session’ has only one ‘message’, you are not at risk, the only way to prevent this noise is with an upstream firewall blocking such traffic. A good use for the VULTR/DO type firewall rules.

yeah, that’s been the solution, to put in a firewall at the vultr level and I have a api script that does that pretty easily. It’s just not appropriate for all situations especially if the PBX has remote workers or people traveling using softphones.

By massive attack it’s hundreds of blocked IP’s in a day all to sip.