05-31-2018 12:55 AM - edited 03-18-2019 02:08 PM
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.
Solved! Go to Solution.
05-31-2018 07:18 AM
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:
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.
05-31-2018 06:01 AM - edited 05-31-2018 06:10 AM
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.
05-31-2018 07:48 AM
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.
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.
05-31-2018 07:18 AM
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:
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.
05-31-2018 11:14 AM
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.
Page 44, Task 21
Restricting Access to ISDN Gateways
Hope this helps
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide