cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1180
Views
30
Helpful
5
Replies

Placing the VCS-E Starter Pack outside of a firewall

William Bell
VIP Alumni
VIP Alumni

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

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

1 Accepted Solution

Accepted Solutions

Martin Koch
VIP Alumni
VIP Alumni

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

Please remember to rate helpful responses and identify

View solution in original post

5 Replies 5

Martin Koch
VIP Alumni
VIP Alumni

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

Please remember to rate helpful responses and identify

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

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Tomonori Taniguchi
Cisco Employee
Cisco Employee

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
Level 1
Level 1

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.

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

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: