02-22-2013 06:33 AM - edited 03-18-2019 12:38 AM
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
02-22-2013 06:42 AM
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
02-22-2013 06:54 AM
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"?
02-22-2013 07:14 AM
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:
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.
08-22-2014 09:29 AM
Did you ever get a resolution to this?
06-06-2015 08:52 PM
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
06-06-2015 09:47 PM
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.
06-07-2015 08:25 AM
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
06-07-2015 05:35 PM
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.
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