My call policy rules on my VCS-E do not seem to be working

[Eric Suter]

Hello all,

On my VCS-E I have some specific call policy rules set as such

Source     Dest     Action

cisco          .*         reject

cisco.*       .*         reject

My call history shows that a source of cisco to multiple destinations is constantly attempting calls.  The status of these calls is never rejected however.  It either ends in a status of "Interworked No permission", or "Subscriber absent Called party not registered".  I want this source of Cisco to be rejected immediately, but it is not happening.  Can someone please help me?  Let me 

VCS-E is currently running X8.1

[Patrick Sparkman]

Using the VCS web interface to create call policy rules won't work because the web interface uses "origin" for all calling sources, meaning that the source address would have to be authenticated before the CPL would even work, all external calls not registered to your VCS is unauthenticated.  You need to create a custom CPL yourself using "unauthenticated-origin".  Take a look at the CPL Reference in the VCS Admin Guide starting on pg 365 for more information on what both of those source types mean.

The simplest method is to go to the CPL configuration page of the VCS, download the current CPL that was generated by creating rules through the web interface, this can be done by clicking "Show Call Policy File".  Then edit the XML file and change origin to unauthenticated-origin.

Attached is the script I use to block these types of calls.  Even with a CPL script, they'll still show up in your VCS search history, but once the call begins the search, it will stop right there.

[Eric Suter]

wow thanks!  I will take a look at this.  Being handed a system I know nothing about has been a challenge.

[Anthony Thomson]

My own experience with these calls was such:

You can use the web interface to set call policy rules that will work, but you have to create them based on the Destination, not the Source.  Leave the Source field blank, which is equivalent to Unauthorized Source.  Take a good look at the Destinations being requested in your call logs.  I found that they followed a definite pattern, which had nothing to do with my own internal call patterns.  Therefore I could create rules that blocked them, usually destinations like \d{12,30}, or \d{12,30}@%ip%, or \d{12,30}@%localdomains%.

This does allow the calls to be attempted, they're just Rejected.

I eventually tired of my call logs being filled with all these Rejected attempts. They overwhelmed the real calls by a significant margin. So, I create a bunch of firewall rules on the VCS that block incoming call attempts from the IP blocks these are coming from.

If you look up the source IP addresses (from RIPE WhoIs, ARIN WhoIS, APNIC WhoIs, etc), you'll likely find what I did, and that is that all the source IP addresses are from cloud providers around the world.  The people who are doing this seem to be 'renting' machines from cloud providers (which allows them to switch IP sources regularly), and using them for the attacks.  So, I just block the IP address blocks assigned to those cloud providers.  There's a lot of them, but since I would never expect to actually receive a legitimate call from any of them, it works.  I think I ended up with about 150 rules.  You only need to block the H323 or SIP call setup destination port (as applicable).  For me it was mostly H323.

It takes a few weeks of regularly looking through the logs to catch them all, but to me it was worth it.  I have no more problems with these calls, and haven't for months.  They aren't using my traversal licenses, and they aren't filling my logs with garbage.

The unfortunate problem is that the firewall rules cannot be created through the API....so a person can't just backup the config from 1 VCS and transfer to another.

Also, if you go down this route, you might want to ensure you put some ALLOW rules at the top of the list as an insurance policy to make sure people/companies you DO want connections with don't get blocked.  Probably not necessary, but it may help you sleep at night, and do away with that niggling doubt that you may accidentally block someone you don't intend to.

[Patrick Sparkman]

Leave the Source field blank, which is equivalent to Unauthorized Source.

The VCS documentation does say that, however if you actually look at the CPL the web interface always uses "origin" for the source, which matches authenticated sources, so the CPL would never match unauthenticated sources if you wanted to specify an actual source address.  So one would need to use a custom CPL script, unless they'd want to block all unauthenticated calls, which if you're doing B2B calling, isn't recommended.

[Anthony Thomson]

Well, I'm not describing what the VCS documentation says, I'm describing what I actually did, and what actually worked.  This was a few revisions of VCS code ago, so it's possible that has changed, but it seems unlikely.  As long as you're specifying the destination address, you should be fine.  Have you tried it?