Abnormal Calling History on Expressway

[Mingjia Zhang]

Greeting everyboby,

Recently, I find that there are too much abnormal calling history on expressway, as shown follow.

The status is showing "Internal Server Error" , because this expressway is running the B2B Call

and now I have set the B2B sip trunk to "No Servise" . Otherwise, it will traversal outside sometimes.

What I am confusing in is the url 1000@xxx.xxx, because I have confirmed that this url is not in the user list on CUCM. Where is the 1000@xxx.xxx from?

Beside, the called party is an array of disorder number I never meet.

Does somebody know what happen it is?  Am I attacked? How could I deal with it?

Thank you.

[PJMack]

This is a hack attempt, very common over the last few years. Basically they are trying to find a path out of a gateway to make long distance (generally international from my experience) calls at your expense. 

You can't prevent the attempt, all you can do is make sure they can't succeed. If you check your Expressway E I'm sure you are seeing these same calls, the fact that they are getting to the C indicates you can do some things on the E to block them. Call policy script, more specific search rules, things like that. For example, the part you have grayed out is your public IP for the E, correct? Do you need to allow @ip addresses inbound, or are all of your legitimate inbound calls @domain? If the latter, don't allow @ip.

[Mingjia Zhang]

Hi PJMack,

Thanks for your answer.

Accroding to what you say,  I think the crux is the B2B call setting. Because the B2B call was deployed two weeks ago and before the B2B call deployment, there had never been such this situation.

Actually, I followed the CVD guide to finish the B2B call deployment and this guide is  shown below. Except for some individual information, such as domain name, other setting is as same as the CVD guide.

https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/midmarket/Oct2015/CVD-CollabEdgeUsingBE6000.pdf?dtid=osscdc000283

May I ask how I change the configuration to achieve the specific inbound/outbound calling in order to realize what you say, blocking the illegal caling from expressway-e to expressway-c? Would you mind to give me some guidance?

Thank you very much.

[Anthony T · Accepted solution]

Yes, you need to be sure that the attackers can't get to what they want (PSTN access), in the event this actually possible in your environment, or that they can't cause other issues like hung calls on endpoints and call license exhaustion.

One of the things you can specifically do is basically sanitize incoming calls on the VCS-E. It requires that your internal aliases have a specific and regular pattern.

For example, if all internal endpoint alias are 7 numeric digits, then you can create a couple of Call Policy rules on the VCS-E that prevent calls from going through when they are trying to connect with anything that isn't a 7-digit numeric alias.

Source type: from address

Rule applies to: Unauthenticated callers

Source pattern: .*

Destination pattern: (sip:)?[0-9+%*#]{8,32}@(%localdomains%|%ip%|<VCS-E DNS A Record>)

Action: Reject

This will reject any call attempt to an alias that:

1. May or may not be prefixed with "sip:"
2. Has an alias with any numeric character 0-9, or '+', '%', '*', or '#', and has between 8 and 32 of these characters.
3. Has a destination (portion after the @ symbol) of either one of the domains configured on the VCS-E, or the IP address of the VCS-E, or the DNS A record (hostname) of the VCS-E.

The net result of these will give you Forbidden results in the Search logs instead of the Internal Server Errors you currently see.

Since the attackers are looking for long distance access, the minimum number of digits I've seen them attempt to dial is 12, so you could replace the 8 with 12, but I feel it's best practise to disallow calls that can't get through to anything anyway.  Your mileage may vary.

Hope that helps.

[Randy Valverde Rojas]

Hi!,

This is rather common and considered "Toll Fraud", its just people trying to get PSTN international calls to connect, once they identify a pattern that connect, they will start selling them to other people using your infrastructure.

Some easy workarounds are mentioned above but there is also a section on the deployment guides specifically for this.

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-10/Cisco-Expressway-Basic-Configuration-Deployment-Guide-X8-10.pdf

Page 44, Task 21

Restricting Access to ISDN Gateways

Hope this helps