configuring firewall rules on VCS via xconfig command

[Stephan Bahl]

Hi,

we have every day some "bad People" how want to use our VCSE for calling PSTN numbers.

It is possible to configure the firewallrules via Xconfiguration or only over the web-page ???

thanks

Stephan

[Chris Swinney]

Hi Stephan,

I have been looking at this myself as we have 80+ VCS-C and VCS-E to update with firewall rules. Unfortunately (at least in x7.2.2) there appears  to be no easy way to do this. The rest of this info is submitted under  my own investigation and in no way should be deemed as a Cisco recommended practice - still it good to tinker

The rules are actually based on the IPTABLES command built into Linux which can be accessed from a root login. However, I have tried to run an 'iptables-save' on one box and and 'iptables-restore' on a Test VCS, and although I see the changes using 'iptables -L', they do not appear in the web interface and that are wiped on reboot.

It  looks as though the iptables command is manipulated through a Python  script called 'iptablesd.py' located in '/sbin' directory and a log is  written to '/mnt/harddisk/log'. You can even see where the User Firewall  rules are wrtien out to, which is  '/tandberg/persistent/user_firewall_ipv4.conf'. This file seems to be  read in on boot to build the IPTables rule list, but manipulating it  directly didn't appear to do much good either as it seems to be over  writen during the shutdown sequence.

I'm not sure if x8.1 makes up for this deficiency as  we havn't got around to testing it yet, but I will keep digging to see  if ther is a way to manipulate this.

Chris

[Chris Swinney · Accepted solution]

Actually, I just re-read your post and it seems that firewall rules are not what you are after, but rather Call Policy (CPL) Scripts. The Firewall rules, would be used to stop or allow specific IP address from connecting to a service running on your VCS - such as SSH or HTTPS, not really for call screening.

[Stephan Bahl]

Hi Chris,

Thanks for the Answer. That is what i want to do.  Block "bad" sip calls.

I Think that CPL was only for Call Manipoulation (Chaning the destination,....). (Never stop learning)

Now I go in the deep with the CPL´s to Block the "bad" SIP-calls

Stephan

[Chris Swinney]

No Worries Stephan,

Like Wayne said, more info is always useful. However, You might also find that turning OFF SIP UDP mode on the VCS might also solve your problem. A lot of SIP device (especially video) register and signal (call) either with SIP TCP (port 4060) or SIP TLS (5061). A lot of the Spam SIP attempts you might see will use SIP UDP. Unless you have a specific reason for NOT doing so, turning SIP UDP off might help (If I'm correct I believe this is now the default case for a new VCS install).

In our case, unfortunately we have a multitude of devices (Cisco 7960G IP Phone running a SIP image), that utilise SIP UDP for signaling. I have been browsing the web and it might be possible to force these to use TCP by fooling them into thinking that they are connecting with a Cisco Call Manager via a config file, but as yet I haven't attempted this. This means we have to switch SIP UDP on, although mainly on the VCS Control, which of course should be protected from SIP scanning in any case.

However, you will often see SIP spam calls being placed such the the destination address is something like 'sip:100@ip_address_vcse'. We personally don't have any rules setup to allow people to dial the VCS-E and be forwarded - we either use a domain name or the Global Dialling Scheme (GDS) with using E.164 number and a national gatekeeper for H.323 dialling. So, as a belt and braces approach, we block all calls that are dallied from an un-authenticated user to the any host at the IP address of the VCS-E, such that:

Unauthenticated User

.*@IP_add_VCS-E

Reject

To define an Unauthenticated user in the CPL rule, simply leave the source field blank.

Good Luck.

[Wayne DeNardi]

Hi Stephan,

Are you able to provide some more information on what you're experiencing?

At a quick glance, it sounds like you're getting lots of call generated by a SIPVicious tool/attack - A search for "SIPVicious" in these forums will provide a bunch of information on how to deal with these in different ways.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.