Solved: Re: Calls from asterisk@different ip addresses

maciej_wilk · ‎07-07-2011

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

awinter2 · ‎07-19-2011

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

View solution in original post

David Anstee · ‎07-10-2011

Yes we get this too, we put a CPL script in place to block anything .asterix.

Sent from Cisco Technical Support iPad App

maciej_wilk · ‎07-11-2011

Hi David,

Could you share this CPL script?

Maciek

Anthony Thomson · ‎07-11-2011

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.

David Anstee · ‎07-11-2011

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">

Martin Koch · ‎07-11-2011

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)

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">

* 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

maciej_wilk · ‎07-11-2011

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).

- CallsToUnknownIPAddresses (3)
- - Mode: Direct
- - Found: True
- - Zone (1)
  - - Name: DefaultZone
  - - Type: Default
  - - Protocol: SIP
  - - Found: False
  - - Reason: Loop Detected
  - - Gatekeeper (1)
    - - Alias (1)
      - Type: Url
      - Origin: Unknown
      - Value: 00442070661000@81.219.199.154

Martin Koch · ‎07-11-2011

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:

Call policy file - CPL File - Show Call Policy File

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

maciej_wilk · ‎07-14-2011

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:

SubSearch (1)
- Type: Search Rules
- CallsToUnknownIPAddresses (3)
- - Mode: Direct
- - Found: True
- - Zone (1)
  - - Name: DefaultZone
  - - Type: Default
  - - Protocol: SIP
  - - Found: False
  - - Reason: Loop Detected
  - - Gatekeeper (1)
    - - Alias (1)
      - Type: Url
      - Origin: Unknown
      - Value: 011442035193347@ip address of vcs-e/

And I want to leave the setting to "Direct". So what could resolve this issue?

Martin Koch · ‎07-17-2011

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@ SIP <-> 0 seconds 403 / Forbidden 1 View

Please remember to rate helpful responses and identify

maciej_wilk · ‎07-18-2011

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:

Search (137)
- State: Completed
- Found: False
- Reason: Loop Detected
- Type: SIP (INVITE)
- CallSerial Number: 471ade68-b137-11e0-b8d9-0010f31d955e
- Tag: 471adf4e-b137-11e0-8827-0010f31d955e
- StartTime: 2011-07-18 14:13:00
- Duration: 0.03
- Source (1)
- - Authenticated: False
- - Aliases (1)
  - - Alias (1)
    - - Type: Url
    - - Origin: Unknown
    - - Value: asterisk@203.86.239.140
- - Zone (1)
  - - Name: DefaultZone
  - - Type: Default
- - Path (1)
  - - Hop (1)
    - - Address: 203.86.239.140:51183
- Destination (1)
- - Alias (1)
  - - Type: Url
  - - Origin: Unknown
  - - Value: sip:900442070661000@
- SubSearch (1)
- - Type: Transforms
- - Action: Not Transformed
- - ResultAlias (1)
  - - Type: Url
  - - Origin: Unknown
  - - Value: 900442070661000@
- - SubSearch (1)
  - - Type: Admin Policy
  - - Action: Proxy
  - - ResultAlias (1)
    - - Type: Url
    - - Origin: Unknown
    - - Value: 900442070661000@
  - - SubSearch (1)
    - - Type: FindMe
    - - Action: Proxy
    - - ResultAlias (1)
      - Type: Url
      - Origin: Unknown
      - Value: 900442070661000@
    - - SubSearch (1)
      - Type: Search Rules
      - CallsToUnknownIPAddresses (3)
        
        Mode: Direct
        
        Found: True
        
        Zone (1)
        
        Name: DefaultZone
        
        Type: Default
        
        Protocol: SIP
        
        Found: False
        
        Reason: Loop Detected
        
        Gatekeeper (1)
        
        Alias (1)
        
        Type: Url
        
        Origin: Unknown
        
        Value: 900442070661000@
      - SearchRule (1)
        
        Name: LocalZoneMatch
        
        Zone (1)
        
        Name: LocalZone
        
        Type: Local
        
        Protocol: SIP
        
        Found: False
        
        Reason: Not Found
        
        Gatekeeper (1)
        
        Address: :0
        
        Alias (1)
        
        Type: Url
        
        Origin: Unknown
        
        Value: 900442070661000@
        
        Zone (2)
        
        Name: LocalZone
        
        Type: Local
        
        Protocol: H323
        
        Found: False
        
        Reason: Not Found
        
        Gatekeeper (1)
        
        Address: :0
        
        Alias (1)
        
        Type: Url
        
        Origin: Unknown
        
        Value: 900442070661000@

So nothing special before the fragment I have posted before.

Another search is just:

Search (138)
- State: Completed
- Found: False
- Reason: Loop Detected
- Type: SIP (INVITE)
- CallSerial Number: 471df17a-b137-11e0-835a-0010f31d955e
- Tag: 471adf4e-b137-11e0-8827-0010f31d955e
- StartTime: 2011-07-18 14:13:00
- Duration: 0
- Source (1)
- - Authenticated: False
- - Aliases (1)
  - - Alias (1)
    - - Type: Url
    - - Origin: Unknown
    - - Value: asterisk@203.86.239.140
- - Zone (1)
  - - Name: DefaultZone
  - - Type: Default
- - Path (1)
  - - Hop (1)
    - - Address: :5060
  - - Hop (2)
    - - Address: 203.86.239.140:51183
- Destination (1)
- - Alias (1)
  - - Type: Url
  - - Origin: Unknown
  - - Value: sip:900442070661000@

Any clues?

Martin Koch · ‎07-18-2011

The part I wanted to see was:


SubSearch (1)
 

Type: Admin Policy


 

Action: Proxy


 

ResultAlias (1)
 

Type: Url


 

Origin: Unknown


 

Value: 900442070661000@

I would have expected to see:

Search (4)
- State: Completed
- Found: False
- Reason: Forbidden

...

- SubSearch (1)
- - Type: Admin Policy
- - Action: Reject

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

maciej_wilk · ‎07-19-2011

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?

awinter2 · ‎07-19-2011

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

Martin Koch · ‎07-19-2011

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.

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">

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