cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3908
Views
10
Helpful
8
Replies

Regular Expressions with Call Policy on VCSe

swestra01
Level 1
Level 1

Hi Guys,

  I am working on firming up the call policy on my VCS Expressway to try to better intercept the SIP spam requests it is getting from internet ip numbers. Right now those spam requets are getting rejected by the loop detection but I want to intercept them before they even do a search on the Expressway. It seems that the call policy rules I create without regular expressions are functioning fine but I don't think I have the syntax correct for the regular expressions.

The goal of this rule is to reject any incoming SIP request that has a destination alias format of 7 to 17 digits followed by an @VCSe_IP. so for example it would reject the following attempts: 0123456@VCSe_IP and 0123456789101112@VCSe_IP with one rule.

The policy I created is this: source pattern: unauthenticated user, Destination pattern: \d{7,17}@xx\.xx\.xx\.xx (where xx is the individual octets of the VCSe IP address), Action: reject  

However the above policy does not seem to be rejecting the calls before they do a search. I have checked the above expression with the check pattern tool on the VCSe and it comes up with a sucessful match when I try the destination alias of a request that made it through, hence my confusion. Any help you guys could provide would be appreciated.

Thanks,

Steven                

8 Replies 8

awinter2
Level 7
Level 7

Steven,

if you are creating this rule on the VCS Configuration > Call Policy > Rules page, and assuming your Default Zone is configured as 'Do not check credentials', meaning that incoming calls are considered non-authenticated, the 'Source pattern' field for your rule should be blank/empty, since the source pattern for an unauthenticated call will be non-present.

- Andreas

I do leave the source pattern empty when I created the rule. It just auto populates "unathenticated user" after the rule is created. I have the default zone set to "do not check credentials". Under the SIP section of the default zone, there is a use default access rules drop down that is currently selected to "No". Do I have to change that to "yes"?

Steven,

Default Zone access rules do not relate to this at all and you can keep those set to 'No'.

How exactly are you placing the test calls when attempting to verify this?

I created the following CPL rule on my X7 VCS (With 10.10.10.10 being the IP address of my VCS):

Source pattern:

Destination pattern: \d{7,17}@10\.10\.10\.10

Action: Reject

I then proceeded with placing a SIP call from an unregistered C20, calling the URI '1234567@10.10.10.10' while running a diagnostics log on my VCS with Network log level set to 'DEBUG', and captured the following in that log:

Incoming INVITE:

2013-02-22T16:03:36+01:00 vcs02 tvcs: UTCTime="2013-02-22 15:03:36,598" Module="network.sip" Level="INFO":  Src-ip="10.x.x.x"  Src-port="5060"   Detail="Receive Request Method=INVITE, Request-URI=sip:1234567@10.10.10.10, Call-ID=9dd19ad75b1063ecf716461b149e9e2a"

2013-02-22T16:03:36+01:00 vcs02 tvcs: UTCTime="2013-02-22 15:03:36,598" Module="network.sip" Level="DEBUG":  Src-ip="10.x.x.x"  Src-port="5060"

SIPMSG:

|INVITE sip:1234567@10.10.10.10 SIP/2.0

Call processing logic, showing CPL matching:

2013-02-22T16:03:36+01:00 vcs02 tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="10.x.x.x" Dst-alias-type="SIP" Dst-alias="sip:1234567@10.10.10.10" Call-serial-number="0886391c-7d01-11e2-adf5-0050569a08fd" Tag="08863aac-7d01-11e2-bd2e-0050569a08fd" Detail="searchtype:INVITE" Level="1" UTCTime="2013-02-22 15:03:36,601"

2013-02-22T16:03:36+01:00 vcs02 tvcs: Event="Call Attempted" Service="SIP" Src-ip="10.x.x.x" Src-port="5060" Src-alias-type="SIP" Src-alias="sip:10.x.x.x" Dst-alias-type="SIP" Dst-alias="sip:1234567@10.10.10.10" Call-serial-number="0886391c-7d01-11e2-adf5-0050569a08fd" Tag="08863aac-7d01-11e2-bd2e-0050569a08fd" Protocol="UDP" Auth="NO" Level="1" UTCTime="2013-02-22 15:03:36,601"

2013-02-22T16:03:36+01:00 vcs02 tvcs: UTCTime="2013-02-22 15:03:36,602" Module="network.cpl" Level="DEBUG":  Remote-ip="10.x.x.x"  Remote-port="5060"   Detail="CPL: "

2013-02-22T16:03:36+01:00 vcs02 tvcs: UTCTime="2013-02-22 15:03:36,602" Module="network.cpl" Level="DEBUG":  Remote-ip="10.x.x.x"  Remote-port="5060"   Detail="CPL:   "

2013-02-22T16:03:36+01:00 vcs02 tvcs: UTCTime="2013-02-22 15:03:36,602" Module="network.cpl" Level="DEBUG":  Remote-ip="10.x.x.x"  Remote-port="5060"   Detail="CPL: matched "

2013-02-22T16:03:36+01:00 vcs02 tvcs: UTCTime="2013-02-22 15:03:36,602" Module="network.cpl" Level="DEBUG":  Remote-ip="10.x.x.x"  Remote-port="5060"   Detail="CPL: "

VCS responds to INVITE with 403 Forbidden:

2013-02-22T16:03:36+01:00 vcs02 tvcs: UTCTime="2013-02-22 15:03:36,616" Module="network.sip" Level="DEBUG":  Dst-ip="10.x.x.x"  Dst-port="5060"

SIPMSG:

|SIP/2.0 403 Forbidden

As you can see, on my VCS everything seems to work as expected. I'd recommend you capture a similar diagnostics log on your own VCS to check what is different in your test call compared to the output above.


Did you ever get a resolution to this?

Christopher,

I can confirm that the pattern recommended below works 

In all the examples below, "authenticated-origin="""

xx = your IP address octets

Destination pattern: \d{7,17}@xx\.xx\.xx\.xx (Traps UDP Calls between 7 and 17 digits to your IP)

or

Destination pattern: \d{7,17}@yourdomain.com (Traps UDP Calls between 7 and 17 digits to your your domain)

or

Destination pattern: \d{7,17}@yourdomain.com.* (Traps TLS/TCP Calls between 7 and 17 digits to your your domain)

or

Destination pattern: \d{7,17}@xx\.xx\.xx\.xx.* (Traps TLC/TCP Calls between 7 and 17 digits to your your IP)

 

--Paul

Why not just turning off sip udp on the VCS-E? Works great for me, haven't seen a single sip scan hitting the VCS-E since doing that.

Would be really nice if we could something similar with all the h.323 spam calls which comes in waves, but at least a simple CPL blocks these.

/jens

Please rate replies and mark question(s) as "answered" if applicable.

Please rate replies and mark question(s) as "answered" if applicable.

Yes that works too.

Though i think it limits your range of legitimate incoming sip calls. 

I dont think you can tell everyone that wants to call in to use TLS/TCP.

--Paul

Haven't had a single issue with legitimate incoming sip call since doing that, well, nobody has complained - and we do a lot of videoconferencing.

Only limitation we have found is that we are unable to dial hostnames, i.e. fishtank.lifesize.com with sip udp turned off.

Turning off sip udp also reduces the time it takes to connect interworked calls quite dramatically as it doesn't have to sit there and wait and wait and wait when you are calling a H.323 system from a SIP client/end-point.

This delay is normally 30 seconds, thanks to the udp timeout, before the VCS-E tries H.323 - and before the called end-point starts ringing. In my experience, majority of end-users will have given up on the connection long before then.

/jens

Please rate replies and mark question(s) as "answered" if applicable.

Please rate replies and mark question(s) as "answered" if applicable.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: