Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

Blocking calls from 100@VSEIP

I see alot of sip calls on my VCSe where it is from 100@Vcse ip ADDRESS OR 101@VCSE OR 300@VCSE

I was searching through the forums and found

https://supportforums.cisco.com/message/3401571#3401571

Start time          Source          Destination          Protocol          Duration          Status          Peer          Type          Actions

2013-11-15 12:26:27          sip:300@vcseIP          sip:7011972543424881@vcseIP          SIP <-> SIP          32 seconds          408 / Request Timeout          Local          VCS          View

2013-11-15 12:26:23          sip:300@vcseIP          sip:99011972543424881@vcseIP          SIP <-> SIP          32 seconds          408 / Request Timeout          Local          VCS          View

2013-11-15 12:26:20          sip:300@vcseIP          sip:9011972543424881@vcseIP          SIP <-> SIP          32 seconds          408 / Request Timeout          Local          VCS          View

2013-11-15 12:26:16          sip:300@vcseIP          sip:011972543424881@vcseIP          SIP <-> SIP          32 seconds          408 / Request Timeout          Local          VCS          View

2013-11-15 12:26:13          sip:300@vcseIP          sip:00972543424881@vcseIP          SIP <-> SIP          32 seconds          408 / Request Timeout          Local          VCS          View

2013-11-15 12:06:56          sip:100@vcseIP          sip:8011972548710139@vcseIP          SIP <-> SIP          32 seconds          408 / Request Timeout          Local          VCS          View

2013-11-15 12:00:53          sip:101@vcseIP          sip:00448450041118@vcseIP          SIP <-> SIP          33 seconds          408 / Request Timeout          Local          VCS          View

2013-11-15 11:05:26          sip:100@vcseIP          sip:9011972548710139@vcseIP          SIP <-> SIP          32 seconds          408 / Request Timeout          Local          VCS          View

2013-11-15 10:14:14          sip:100@vcseIP          sip:011972548710139@vcseIP          SIP <-> SIP          32 seconds          408 / Request Timeout          Local          VCS          View

2013-11-15 10:08:32          sip:100@vcseIP          sip:20000011448708758506@vcseIP          SIP <-> SIP          32 seconds          408 / Request Timeout          Local          VCS          View

This is my current CPL

<cpl xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd">

<taa:routed>

     <taa:rule-switch>

          <taa:rule unauthenticated-origin="asterisk@.*" destination=".*"><reject status="403"/></taa:rule>

     </taa:rule-switch>

</taa:routed>

</cpl>

Would I now modify it to:

<?xml version="1.0" encoding="UTF-8"?>

<cpl xmlns="urn:ietf:params:xml:ns:cpl"  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">

<taa:routed>

  <!-- This CPL is intended to block scans / call attempts from asterisk@.* and 100@1.1.1.1 -->

  <!-- changes / addons might be needed in your setup -->

  <taa:rule-switch>

   <taa:rule unauthenticated-origin="asterisk@.*" destination=".*"><reject status="403"/></taa:rule>

   <taa:rule unauthenticated-origin="100@VCSEIP" destination=".*"><reject status="403"/></taa:rule>

   <taa:rule origin="asterisk@.*" destination=".*"><reject status="403" /></taa:rule>

   <taa:rule origin="100@VCSEIP" destination=".*"><reject status="403" /></taa:rule>

  </taa:rule-switch>

</taa:routed>

</cpl>

iS THIS CORRECT?

2 ACCEPTED SOLUTIONS

Accepted Solutions

Blocking calls from 100@VSEIP

It'll work, but you should have both unathenticated and authenticated calls covered.

Since all of your calls appears to be coming from @VCS_IP, then you can block all destinations by using * instead of specifying the address. Below is part of the CPL I use - and it works for me.

You can test whether CPL works or not by using the VCS-E "locate tool".

Also, you should disable SIP UDP on the VCS-E unless you really need it, as these scanners use UDP to find potential targets.

(Only time I've had to re-enable it is if I have to make a call using hostname where the VCS-E does a DNS A record lookup instead of using "normal" SRV records.

If you have ISDN Gateways deployed, then you should also seriously consider changing the prefixes you are using, i.e. adding # to the prefix will break the dialling string. I.e. if your prefix is 99 and you want to dial 9912345678, then you dial 99#12345678 instead.

Also see the deplyment guide for more information regarding these issues - Step 16, page 41 in particular

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Basic_Configuration_Cisco_VCS_Control_with_Cisco_VCS_Expressway_Deployment_Guide_X7-0.pdf

/jens

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

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

Blocking calls from 100@VSEIP

The question should be what you are having the issue with.

These scans are common on the net and the question is how to react on them.

Some say 403 are or, others prefer 404 or what ever else is returned to not give the remote site

more info then needed, ...

In general if you do not get call loops and eaten up call licenses and you do not have

any other resources to protect (like the ISDN gw) you do not need to worry that much, besides

that its just annoying in your logs.

For now the better way to go is to disable sip-udp (which is default on newer fresh vcs default configurations).

These scans are done by today on sip-udp. But sure that can change and rarely I have seen them

on h323 and sip-tcp as well.

Also worth checking is to see that unwanted remote sites can not register or use your setup as an open sip proxy.

If you would have an ISDN GW I would not recommend a prefix to be used from the outside, you should have

proper authentication or even better completely block isdn calls from the outside.

Please remember to rate helpful responses and identify helpful or correct answers.

Please remember to rate helpful responses and identify

3 REPLIES

Blocking calls from 100@VSEIP

It'll work, but you should have both unathenticated and authenticated calls covered.

Since all of your calls appears to be coming from @VCS_IP, then you can block all destinations by using * instead of specifying the address. Below is part of the CPL I use - and it works for me.

You can test whether CPL works or not by using the VCS-E "locate tool".

Also, you should disable SIP UDP on the VCS-E unless you really need it, as these scanners use UDP to find potential targets.

(Only time I've had to re-enable it is if I have to make a call using hostname where the VCS-E does a DNS A record lookup instead of using "normal" SRV records.

If you have ISDN Gateways deployed, then you should also seriously consider changing the prefixes you are using, i.e. adding # to the prefix will break the dialling string. I.e. if your prefix is 99 and you want to dial 9912345678, then you dial 99#12345678 instead.

Also see the deplyment guide for more information regarding these issues - Step 16, page 41 in particular

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Basic_Configuration_Cisco_VCS_Control_with_Cisco_VCS_Expressway_Deployment_Guide_X7-0.pdf

/jens

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

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

Blocking calls from 100@VSEIP

Thanks I dont have any ISDN calls and I will defnitely try this.

JQ

Blocking calls from 100@VSEIP

The question should be what you are having the issue with.

These scans are common on the net and the question is how to react on them.

Some say 403 are or, others prefer 404 or what ever else is returned to not give the remote site

more info then needed, ...

In general if you do not get call loops and eaten up call licenses and you do not have

any other resources to protect (like the ISDN gw) you do not need to worry that much, besides

that its just annoying in your logs.

For now the better way to go is to disable sip-udp (which is default on newer fresh vcs default configurations).

These scans are done by today on sip-udp. But sure that can change and rarely I have seen them

on h323 and sip-tcp as well.

Also worth checking is to see that unwanted remote sites can not register or use your setup as an open sip proxy.

If you would have an ISDN GW I would not recommend a prefix to be used from the outside, you should have

proper authentication or even better completely block isdn calls from the outside.

Please remember to rate helpful responses and identify helpful or correct answers.

Please remember to rate helpful responses and identify

789
Views
0
Helpful
3
Replies
CreatePlease to create content