[cisco-voip] External call attempts to Expressway E

[Ryan Huff]

In full disclosure, I have not looked at the links you've referenced, just offering my thoughts on your questions. First, lets agree that preventing 100% of toll-fraud is a fool's errand; the only way to 100% prevent it is to power it off.

That said, making toll-fraud "less possible" in Expressway is more challenging than a traditional "CUBE" because unlike NANP, URI's can be damn well what the business pleases, and you also have to consider the calling scenarios (Example: Hybrid call connect could absolutely have "e164 at domain.call.ciscospark.com" calls coming inbound as source URIs). A system that will only ever have outbound calls to Webex CMRs can have a call policy written to prevent calls with source URIs matching the internal domain whereas a multi-national deployment of two separate systems (with the same doamian), not on-net and separated by the Internet may not be able to.

To that end, writing call policies for Expressway has (and always will be) something that is customized to the deployment.

I have found the following to be two good "reject" policies that tend not to interfere with most deployments (though they could if the internal URIs match the policy). Most organizations have Directory URIs that ultimately have been inherited from the user's email address or other corporate standardizations which these policies tend to avoid and also tend to deny routing to a surprising amount of obvious junk (typically, I apply CPL at the edge):


  *   ^[0-9,a-z,A-Z]{0,6}@.*
     *    The first 0-6 characters are made up of alphanumerics 0-9 and/or upper/lower case letters, “@“ anything
        *   Example: 123456 at domain.com
        *   Example: NoAuth at domian.com
        *   Example: 9999 at domain.com

  *   ^[0-9,a-z,A-Z]{0,6}$
     *   The first 0-6 characters are made up of alphanumerics 0-9 and/or upper/lower case letter and do not exceed the 6th character
     *   Example: 1000
     *   Example: 9999
     *   Example: NoAuth

Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional

________________________________
From: cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of Pawlowski, Adam <ajp26 at buffalo.edu>
Sent: Monday, April 29, 2019 1:13 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] External call attempts to Expressway E


All,



I know I’d asked here and elsewhere in the past regarding spam calls and call setup attempts, which seem to be part of the reality of being on the public internet. We see consistent call attempts from our own domain, as well as @google.com . More lately, I see them pop up with the from address of what appears to be another customer’s Expressway E. Not many, but a few.



When I set up CPL on our appliances I had referred initially to this blog post:



https://ciscoshizzle.blogspot.com/2016/05/hardening-your-cisco-vcs-expressway.html<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fciscoshizzle.blogspot.com%2F2016%2F05%2Fhardening-your-cisco-vcs-expressway.html&data=02%7C01%7C%7Cba259ed920cc480bce2908d6ccc61e5b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636921548609965133&sdata=nJTRYojsHwoCXwo9gb%2BRETRszZtbZc%2BlwPpqp9IviCw%3D&reserved=0>



Expressway was new to me and the documentation was (is) not such that you could simply open it and understand how to set it all up end to end without going through the process as the tasks are sort of split between documents. I wanted to note that in this blog they mention that they don’t make any attempt to block routing externally, such that you wouldn’t necessarily care to block calls from the default zone back out across DNS because they weren’t coming to your enterprise. I am assuming that it is possible to configure your search rules to allow this to happen.



I don’t understand the point of this, other than perhaps you could attempt calls through known hosts in case they happened to have some sort of trust relationship running, or to try and skirt (or poison) blacklists.



Is anyone else seeing that type of call attempt? Do you think it’s worth trying to reach out to groups that appear to be proxying these calls?



Best,



Adam Pawlowski

SUNYAB NCS


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190429/daf8a7fc/attachment.html>