Placing the VCS-E Starter Pack outside of a firewall

[William Bell]

I have what I hope is a quick question. My customer did not purchase the DNI option for their VCS Starter Pack. So, this means I have to assign a public IP address. Further, the way their firewall is provisioned I need to consider putting the VCS outside of the firewall. So, it is in the wild as they say. I have read solutions where the VCS-E (and I assume the Starter Pack follows suit) is essentially a security device.

I am wondering if people have done this before and if anyone had any thoughts on how secure (or insecure) the prospective configuration is?

-Bill

[Martin Koch · Accepted solution]

Hi Wiliam!

Nice to see you here again, how are you?

I would not recomend that. Besides Either get the DNI to put it in a DMZ with a private ip

or just have it in a DMZ with a public ip, that works great as well.

Even if you so not have a real DMZ as long as you have access to the router you might

be able to only allow traffic to required ports via an access list.

Especially the management should be blocked away, there can always be bugs in the different

components (like the ssh server, the web server, ...) or the password gets hacked, ...

so why keep them open to the public.

This is a list of open ports on a quite default starter pack vcs:

tcp        0      0 192.168.1.100:5060     0.0.0.0:*               LISTEN      4863/app            
tcp        0      0 192.168.1.100:5061     0.0.0.0:*               LISTEN      4863/app            
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      6140/httpd          
tcp        0      0 0.0.0.0:4369            0.0.0.0:*               LISTEN      4180/epmd           
tcp        0      0 0.0.0.0:4372            0.0.0.0:*               LISTEN      4134/beam.smp       
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      3610/sshd           
tcp        0      0 192.168.1.100:2776     0.0.0.0:*               LISTEN      4863/app            
tcp        0      0 192.168.1.100:1720     0.0.0.0:*               LISTEN      4863/app            
tcp        0      0 192.168.1.100:2777     0.0.0.0:*               LISTEN      4863/app            
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      6140/httpd          
udp        0      0 192.168.1.100:123      0.0.0.0:*                           5395/ntpd           
udp        0      0 0.0.0.0:123             0.0.0.0:*                           5395/ntpd           
udp        0      0 0.0.0.0:161             0.0.0.0:*                           3629/snmpd          
udp        0      0 0.0.0.0:4371            0.0.0.0:*                           4134/beam.smp       
udp        0      0 192.168.1.100:500      0.0.0.0:*                           3636/racoon         
udp        0      0 192.168.1.100:5060     0.0.0.0:*                           4863/app            
udp        0      0 192.168.1.100:1719     0.0.0.0:*                           4863/app            
udp        0      0 192.168.1.100:2776     0.0.0.0:*                           4863/app            
udp        0      0 192.168.1.100:2777     0.0.0.0:*                           4863/app            
udp        0      0 192.168.1.100:3478     0.0.0.0:*                           4863/app            

I wonder why on a non clustered VCS needs some of these services listen on the ethernet interface (beam, empd, racon, ...) but yea, thats one more reason why I would not keep it without a firewall :-)

A highly not supported and not reboot and upgrade aware way can also be to

login to the box as root and use the iptables of the unerlaying linux to allow the required

and block away everything else. (iptables is the firewall tool for most linux versions)

You will find a lot of resources about that on the internet, this was just a first hit via google:

http://edgis-security.org/operating-system-and-software/iptables-tutorial-series-01-introduction/

Guess something more userfirendly will come in X7.2, see Andreas posting here:

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

Another thing worth noting is that for the upcoming X7.2 release for the  VCS, we are looking at including a basic built-in firewall on the VCS  itself which could also be used to only permit access to certain  services from certain hosts or subnets. It is however not currently  certain whether or not this feature will actually make it into X7.2, so  you will just have to wait and see.

But even then I would recomend using a proper firewall upfront.

Martin

[William Bell]

Hey Martin,

Yeah, I have been absent from the forums for a little while. It has been pretty hectic in my neck of the woods! But being busy is a good thing. How have you been?

-Bill

[Tomonori Taniguchi]

Cisco recommendation is place VCS-E and VCS-E Starter Pack behind firewall so administrator has control of what packet/traffic may permit or deny.

However many customers deploy VCS-E on public network without any firewall today and using it every day.

As Martin link other post URL about Andrea's feedback, we are planning to support basic firewall capability in next software release.

This capability allows configuring permit and denying list based on IP address range and port range.

Same as standard firewall concept, VCS will look though firewall list and process once have matched ACL (ACL configure with priority parameter).

[Garvan Long]

I have seem implementations like this in the past but as Tomo indicated that it recommended to put the VCS on a publicly routalbe DMZ interface of a firewall.

If you do place it on the outside you can also put a layer 2 firewall inline so as to block unathorised acceess, most layer 2 firewalls have the ability for you to put an Ip address on them for management so you can access remotley to manage the configed Layer3 and 4 rules.  Assuming the VCSSP will have a default GW that you control you can place access restrictions on return traffic on this gateway ( router) from the VCS such as only permitting response to admin session from listed IP address, block admin access from all other IP address and permit responses for VC traffic.

[William Bell]

Martin/Garvan/Tomonori,

Thanks for the replies. They all line up with my personal opinion on the matter. I just wish I was involved in the initial hardware quote so I could have pushed the DNI option. The built-in FW option sounds viable but it isn't here and now. Personally, I think the DNI option should just be built into the VCS-SPack. I am certainly going to tell all of our sales people to include it in all VCS-SPack quotes moving forward.

Thanks again.

Regards,

Bill

twitter:@ucguerrilla