cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2029
Views
0
Helpful
8
Replies

Call Policy on a VCS

Anthony Thomson
Level 3
Level 3

I'm trying to forbid some probing attacks on a VCS Expressway.

The calls come in from unknown@(various IP addresses), and go to either sip:(string of 12-17 numbers)@(ip address of VCS express), or the same thing without the SIP: prefix (as an H323 setup request), or the latter prefixed with a '+'.

I thought that putting in a Local CPL to reject calls from unknown@.* going to .* would work.  The Locate tool on the VCS indicates that it does; it comes back with a Forbidden response.  Yet, in practice, these call attempts are not Rejected.  They are passed to the Control and back, when the are stopped as a Loop.

Does anyone know why my CPL isn't working, and how to make it work?

8 Replies 8

awinter2
Level 7
Level 7

Anthony,

are you writing your own CPL or are you using the CPL rule generator page on the VCS?

Assuming that these probing calls are coming in on the DefaultZone on the VCS, and that the DefaultZone is set to 'Do not check credentials', these incoming calls will be non-authenticated.

In order to use CPL to match non-authenticated calls, you have to use the 'unauthenticated-origin' CPL parameter rather than 'origin', and this can not be achieved by using the CPL rule generator page (Which only creates 'origin'-based CPL statements.

For a non-authenticated call, 'origin' will be an empty string, while 'unauthenticated-origin' will be a string containing the source alias of the call. This is described in more detail in the CPL reference section of the VCS Admin guide.

If you could paste the CPL snippets which you are using and which you think should be matching these incoming calls, it would probably be easier to assist you.

Regards

Andreas

I am using the CPL rule generator page on the VCS, and thus I now understand why it's not working.  The DefaultZone is set to 'Do not check credentials'.

So, it looks like I either manually write the CPL, or potentially I change the Authentication Policy on the Default Zone.

If I change it to 'Treat as authenticated', does that change it so that the origin string has the source alias?  What other ramifications of doing this would there be?  This VCS Express is currently used for registrations for Movi/Jabber and a few endpoints.  I expect that Movi would still work since it is already an authenticated endpoint, but that authentication credentials would have to be added to endpoints for them to continue working.

Here's a snippet of the code:

Please use "treat as authenticated" only if you know what you are doing :-)

We had a thread about this before, see my posting at 19.07.2011 15:46:

https://supportforums.cisco.com/message/3394817#3394806

For unauthenticated calls you have to use: taa:rule unauthenticated-origin=

Please remember to rate helpful responses and identify

Anthony,

I wouldn't recommend setting the DefaultZone to 'Treat as authenticated' as that would automatically authenticate all incoming provisioning requests (SUBSCRIBE messages) without validating the username and password.

A better approach would probably be to set the DefaultZone to 'Do not check credentials' or 'Check credentials', depending on how and where you authenticate your provisioning users, and use 'unauthenticated-origin' in your CPL instead or in addition to your existing CPL, to catch the incoming unauthenticated calls.

Regards

Andreas

Any chance you could tell me how to use the cpl to block the " Value " of an unauthenticated call

Have this very annoying caller trying to do toll fraud.

  • Source (1)
    • Authenticated: False
    • Aliases (1)
      • Alias (1)
        • Type: Url
        • Origin: Unknown

Value: 300@our domain

Tried this but I know I have to specify the value and not the originJust haven't found anything on the internet that works.

<taa:rule destination=".*" origin="300@our domain">
<reject reason="Releasing the hounds" status="403"/>

 

 

Use "unauthenticated-origin" for unauthenticated calls.
If you're running X8.8.2, you can use the web interface to configure CPL rules. In previous versions of VCS/Expressway you'd have to write your own CPL file, as unauthenticated rules added via the web interface was actually added as authenticated (origin), this has been corrected in X8.8.2 where an unauthenticated call now gets entered as unauthenticated-origin in the CPL.

There is a CPL reference chapter in the VCS Admin Guides that goes over the different sections and fields within a CPL script.

Thanks for the response, I've upgraded to the newest versions but still don't see the possibility to edit the policy on the box locally.



Do you have an example of how the policy line should be formatted to block any unauthorized requests which exceed 7 digits in the prefix?



I think that is all I really need to accomplish the task at the moment.




CPL rules can be added under Configuration > Call Policy > Rules, then enabled by setting the Call Policy Mode to "Local CPL" under Configuration > Call Policy > Configuration.

One way you can write a CPL rule that would based on 8 characters or more is:

\d{7}\d+@domain

\d{7} will match any digit (numeric character) up to 7 times, and \d+ will match any digit (numeric character) 1 or more times, so with those two combined, the prefix must be 8 digits or more for a successful match.