07-07-2011 05:53 AM - edited 03-17-2019 10:22 PM
Hi everyone,
I am receiving calls from asterisk@different ip addresses on my VCS Expressway trying to dial different numbers. I have enabled a local call policy rule to reject asterisk@.* to any destination .* but it does not work and I still get these call attempts.
Has anyone encountered this and knows how to stop these calls?
Thanks
Maciek
Solved! Go to Solution.
07-19-2011 02:13 PM
Maciej,
try replacing 'origin' with 'unauthenticated-origin' in your CPL, so that it looks as follows:
The CPL field 'origin' will have a value of 'not-present' if the message which the CPL is executed for is not authenticated.
You can find further information about the 'unauthenticated-origin' field in the VCS admin guide.
Hope this helps,
Andreas
07-10-2011 12:43 AM
Yes we get this too, we put a CPL script in place to block anything .asterix.
Sent from Cisco Technical Support iPad App
07-11-2011 03:27 AM
Hi David,
Could you share this CPL script?
Maciek
07-11-2011 05:44 AM
I have the same thing. I Reject asterisk@.* to any destination .*. This does not actually stop the call attempt, but it does Reject the call as Forbidden when one comes in.
07-11-2011 06:18 AM
Sure, here it is...
xmlns:taa="http://www.tandberg.net/cpl-extensions"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd">
07-11-2011 06:39 AM
Hei Maciek!
First off all you will not be able to stop the call attempts, as these are scans being done from the internet,
you can only try to limit the impact of these call attempts.
* what is your current impact, many scans aim for telephony prefixes like 9, 0, 00, ... some others just stupid call extension 100, sometimes changing the destination prefix/address makes sense
* have a cpl blocking specific sources. example:
(please look at the VCS admin guide, CPLs are explained there. Depending on your setup you might need or want
additional rules. There might be a cpl already in place, if so, you have to check how you can combine them)
* disable or change the 5060/udp port (you can still point a SRV record for the _SIP._UDP service to the other port if
its really needed), most video systems by today sill use h.323 or SIP TCP or SIP TLS. SIP UDP is mainly used for telephony and by todays scans)
* its the same with spam mails, if many people change something (like blocking src: asterisk@.*) you will see that
they will adopt as well, so never think that a one time change will solve the problem for ever.
* use authentication for calls to non public resources like isdn/telephony gateways and use secure passwords
* further block destinations towards the isdn gw which you do not call (cuba, somalia, ... are some typical fraud destinations)
also ask your telephony provider to block such destinations and have a rate limit on the lines.
* depending on your scenario there might be additional points or not all points might be suitable. like: some calls from asterisk@.* might actually be legit
Especially if a telephony gw. is used, do not base your security just on the src. info of the packet.
Use authentication and only allow authenticated calls towards a GW or to be protected resources.
Daily check the call and search history for unwanted calls.
Message was edited by: Martin Koch (updated CPL with "unauthenticated")
Please remember to rate helpful responses and identify
07-11-2011 06:58 AM
Martin,
thanks for a thorough answer.
I know I cannot block a call atempt or a search but what I was surprised to see was that even having the call policy reject rule - the same that Anthony has did not stop the calls. The status was not Forbidded but Loop detected (but the call actually did not loop).
07-11-2011 08:05 AM
How are your settings, how did you try to apply the rule, as your own CPL or via the web based "call policy rules"?
Things might be have different in different VCS releases, I always try to base it on the latest, in this case X6.1
Check that your call policy is actually turned on.
On the "Call Policy configuration"-Page, "Call Policy mode" shall be set to "Local CPL"
On the same page you can also display your CPL, could you paste the output of the option:
If it shows a call loop it will most likely have happened :-)
Most loops I have seen were towards other VCSs or DNS zones, often caused transforms or rewriting search rules.
You should be able to see in the search details what actually caused the loop.
To be honest, if I would be you, I would ask my Cisco partner or Cisco TAC to help me here. What in general
should at least be in place is the CPL, a xconfig xstatus of the VCS and a netlog 2 of a call that makes the problem.
Btw, please use the vote feature (the little star) on answers which you think are helpful.
Please remember to rate helpful responses and identify
07-14-2011 03:35 AM
Martin,
Ofcourse I have the call policy mode set to "Local CPL". I wouldn't have posted a thread if I didn't check the obviuos first I have created a rule with the web-based call policy rules. It results in a CPL file like this:
The search rule identtifies the loop detected status based on calls to unknown ip addresses:
And I want to leave the setting to "Direct". So what could resolve this issue?
07-17-2011 05:08 PM
like I said, to fully debug it a xconf, xstatus and a netlog 2 of the failing call would be interesting to see.
For now, could you try to create a cpl with the xml lines I posted above and see if this changes your behavior.
The search history you posted did not show the top part, expecially transforms and used aliases can be interesting here.
We use x6.1, from what I see in our call logs it seems to work.
2011-07-17 12:49:44 sip:asterisk@w.x.y.z sip:902342342341000@
Please remember to rate helpful responses and identify
07-18-2011 08:38 AM
Hi Martin,
it's really hard to get a netlog 2 for such a call attempt as you never know when it will occur
As for the VCS we are also using X6.1.
I actually get 2 attempts in the search history:
SIP (INVITE) | asterisk@203.86.239.140 | sip:900442070661000@ | Loop Detected | ||
SIP (INVITE) | asterisk@203.86.239.140 | sip:900442070661000@ | Loop Detected |
The first (the bottom one) is:
So nothing special before the fragment I have posted before.
Another search is just:
Any clues?
07-18-2011 05:09 PM
The part I wanted to see was:
I would have expected to see:
...
So my magic glass ball tells me there is something not matching where it shall match on the cpl
(or for example that you have a rule upfront which allows the call so the reject would not hit anymore).
So check on the order. Anyhow:
Please try to upload the cpl I made (you can add additional lines if you need customization)
instead of using the vcs call policy wizard and see if it changes the behavior.
Btw, you can use the Locate feature under Maintenance / Tools to simulate the call.
The intended behavior is that the search stops with the above shown "Action: Reject"
Please vote answers if you think they are helpful and mark a thread as answered if it is.
Please remember to rate helpful responses and identify
07-19-2011 01:27 PM
Hi Martin,
The call attempt was actually made after implementing your CPL so it doesn't make a difference if I create the rules using the web interface or I upload a CPL script.
When using the Locate tool it returns Reject when Authenticated is set to Yes. When set to No the result is Loop detected so exactly what I am experiencing.
Now this indicates the setting on the default zone, which in my case is Do not check credentials. I do not want to treat incoming requests as authenticated as this would cause Movi users being able to login with any passwords.
So it seems to be a problem, or am I missing something?
07-19-2011 02:13 PM
Maciej,
try replacing 'origin' with 'unauthenticated-origin' in your CPL, so that it looks as follows:
The CPL field 'origin' will have a value of 'not-present' if the message which the CPL is executed for is not authenticated.
You can find further information about the 'unauthenticated-origin' field in the VCS admin guide.
Hope this helps,
Andreas
07-19-2011 03:23 PM
Hei Andreas!
You are correct, as well as the admin guide describes it (I was just reading up on it
and trying it when you already had answered ,-) but I do not agree that the behavior is correct.
If I see it right the CPL the VCS is using is based on RFC3880 which defines some basics
and also allows "extensions". origin is part of the basic definition:
The CPL_EXTENSIONS_XSD_FILE on the VCS describes:
So wouldn't it be more suitable to use "origin" on no matter how the message hit the vcs,
and then have the two optional attributes handling if or if not it was authenticated?
to all:
On the system where I tested the CPL the "default zone" was set to treat as authenticated,
I should have seen that directly on the search listed here (for the ones interested, you can see that in
the listed search on the field: "Authenticated: False"
Here is an updated version of the CPL, I added both origin and the unauthenticated-orign to it.
You might be able to remove one of them, but you can also just keep it like it is.
If you use an ISDN or telephony GW you also want to block that from the outside!
If you have an IPGW or a Video switchboard and you do not want to loose calls the redirect
David posted is a good way to integrate as well.
And to make it more easy here a downloadable version of the cpl: http://pastebin.com/AAcgjNk4
Please remember to rate helpful responses and identify
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