Erroneous Calls

[wpetilli]

I have a CM with legacy PRI's and it looks like these were somehow compromised during a period of time the other day where calls were made to a few sketchy countries. The carrier noticed the pattern and blocked international calling. Our team has been trying to track the chain of events but aren't having any luck. Can anyone recommend some areas to look and/or even simulate where someone could have gotten access to dial tone and made those calls?

We thought it was potentially breaking out via voicemail, but that doesn't prove to be possible. Our CDR reports show the calls, but what's happening to make the calls isn't included. Without being able to prove, it seems as if whomever was able to get additional dial tone somehow, which we are stumped. For now we have done a few things:
1. disabled dial access on the TG
2. disabled trunk to trunk xfer in sys features
3. blocked the country code in ars

Not even sure if any of those have made a difference.

 

[wpetilli]

Well, what we have now found are tons and tons of messages in the SBC logs with these malicious phone numbers listed. How I do not know because we aren't using SIP trunks. This SBC was stood up not too long ago and was just in testing to deploy remote workers. How would someone be able to pass through that and get a call out the trunks? For now I've shut the B interfaces.

 

[ZeroZeroOne]

If you have built Users for SIP stations and had Remote Worker enabled on the SBC, then someone likely found your public IP Address was accepting login attempts and so they tried and got lucky. When I had our network open up a public IP Address, it took less than an hour for random login attempts to start popping up.

Check the Communication Profile Passwords and make sure you are not using the extension as the password - especially for 4-digit extensions. That seems to be the most common issue.
Some administrators like to build Users for all stations - analogs, digital, etc., to keep administration in one place. While the legacy station types don't really need a User and the Session Manager /SIP portion, it doesn't really hurt EXCEPT it allows for that station to be logged in as SIP as a Remote Worker. So if your unauthorized user was a fax or modem, that could be the reason.

Basically, increase the complexity of your passwords.

For other access to your outbound trunks, check any Auto-Attendants that allow for direct digit dialing. If unchecked, it is possible to guess a trunk access code and find dial tone. Simply adding two lines to check for allowed digits solves this problem:

10 collect 4 digits after announcement 1234 for none
[COLOR=#EF2929]11 goto step 20 if digits >= 4000
12 goto step 20 if digits <= 2000[/color]
13 route-to number digits cov y if unconditionally

Now only digits between 2001 and 3999 are allowed.

 

[wpetilli]

I read about creating URI groups.. other than just creating one and adding a reg string, does it need to get applied anywhere else in the SBC or will it start working?

I have tons of SIP stations created. I'd have to figure out how to bulk change the communication profile pwrds.

 

[biglebowski]

There's a good guide for hardening the SBC and another for setting up remote workers.

We use a regex string in the User Agent to block anything except the Workplace client and version we currently have deployed.

Our 3x pairs of HA SBCs are currently getting around 40,000 hacking attempts per day

 

[kyle555]

https://download.avaya.com/css/public/documents/101065050

If you setup the DOS protection on server profiles and enable the scrubber packages you end up getting a setup that refuses to pass along the register messages from the internet bad guys.