VMware Cloud Community
Ripper98
Contributor
Contributor
Jump to solution

Service Console Isolation Clarification

I have read the Security Hardening Guide but I have a few of questions about isolating the service console isolation.

1. What are the security risks? I found that logs are sent in clear test which is a risk but in a fully routed network once the logs leave the service console network they can be captured or read on the syslog network, unless a ipsec tunnel is created between teh two systems. Another risk I read is that if the service console is on the same vswitch or network as an internet type VM workstation the service console could be exposed to the internet. Any other risks?

2. If the service console is isolated on its own vswitch/network but the network outside of the vm environment has other systems not necessarily vm systems is this still considered a risk or does the physical environment also need to be isolated to only management traffic? To clarify if the service console is on a 192.168.1.0/24 network and that network have physical systems connected to that same 192.168.1.0/24 network is the service console at risk? Again what are the risks and does it matter that the physical network fully switched and uses port isolation? If a company has a fully routed network does the isolation really provide added security? To be compliant with the Security Guide is the key to keep the management network/traffic isolated from internet accesses?

For some reason I am having trouble getting this concept and the security risks. Thanks in advance for help in understanding service console isolation.

0 Kudos
1 Solution

Accepted Solutions
bwaterhouse
Enthusiast
Enthusiast
Jump to solution

Also remember if your service console is taken down you may loose the ability to manage all virtual machines that reside on that ESX host.

View solution in original post

0 Kudos
6 Replies
bwaterhouse
Enthusiast
Enthusiast
Jump to solution

I recommend that people keep the service console to its own dedicated vSwitch running on a management vlan. This way you can keep all management traffic on an out-of-band management network.

I generally setup a management network (vlan) for each datacenter or location and have things like service consoles, switch management interfaces, load balancer management etc all on this dedicated network, this management network may or may not have other workstations etc on it however these are all trusted management workstations.

Even though this management network is fully routable by separating it out you can use firewall rules on the gateway router to specify what management hosts have access to the management network rather than your whole network (which may be 100's of subnets) having open access to your management lan, which in turn would allow someone to attempt malicious activity on things like your service consoles.

Hope that helps.

-ben

Ripper98
Contributor
Contributor
Jump to solution

Thank you for the information. I didn't even consider the firewall blocking capability once the traffic is isolated. I was hoping to get some meat and potatoes risks that I could use to re-enforce the need for isolation. Thanks again for the input.

0 Kudos
bwaterhouse
Enthusiast
Enthusiast
Jump to solution

As for actual "meat and potatoes" risks. They way I think about it is this, having access to the service console on an ESX box is like have access to the hardware layer of every virtual machine that is running on it.

Imagine if somehow someone did use an exploit and gain access to your service console. They would instantly be able to power down any virtual machines or even worse delete VMs from the disk.

bwaterhouse
Enthusiast
Enthusiast
Jump to solution

Also remember if your service console is taken down you may loose the ability to manage all virtual machines that reside on that ESX host.

0 Kudos
TomHowarth
Leadership
Leadership
Jump to solution

The service console is the keys to the kingdom, more worrying that being able to power down or delete is the fact that you can issue a snap on your machines and copy off the original VMDK with you anybody knowing, then commit the snapshot and with our tracking nobody is none the wiser

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth VCP / vExpert

VMware Communities User Moderator

Blog: www.planetvm.net

Contributing author on "[VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment|http://www.amazon.co.uk/VMware-VSphere-Virtual-Infrastructure-Security/dp/0137158009/ref=sr_1_1?ie=UTF8&s=books&qid=1256146240&sr=1-1]”.

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
0 Kudos
Ripper98
Contributor
Contributor
Jump to solution

Thanks to everyone who helped clear the muddy waters for me. I think I have a better understanding of the risks and need to isolate the service console traffic.

0 Kudos