Hyper-V: Security between VMs

W

Wolf-R1

[H]ard|Gawd
Joined
Aug 30, 2004
Messages
2,005
I suppose this is a question to be posed for any VM host but specifically my question is for Hyper-V. In a nutshell, is it regarded as 'safe' to put a VM that is directly attached to the Internet on a host with VMs that are protected via other means?

For example, I have a Win2k8 R2 H-V host with three internal domain attached VMs. We have need for an external DNS server that will be Linux. It will run its own security and will be outside the primary firewalls protecting the rest of the org. It will also have its own dedicated NIC with cable plugged into Internet switch.

I cannot find any real documentation on Hyper-V virtual switch security. Planning for potentials necessitates that I dig around in the hopefully unlikely event that the Linux machine is compromised, the rest of the VMs and the host itself cannot be penetrated.
 
Hmm...the DDOS potential alone brings me back to independent hardware for Internet connected servers.

Thanks, I haven't found anything remotely like those two links yet. Perhaps my Google-fu is weak. LOL
 
Hyper-v dmz
Hyper-v dmz concerns
hyper-v dmz best practices

Those were what I used.
 
We have both internal and external guests on the same Hyper-V host. I wouldn't attempt it if DDOS is a significant concern or without fairly robust routing infrastructure. It's secure, if that's what you are wondering. There's no (known) way for an attacker to break out of a Hyper-V container and get to the host or other VMs, but depending on how your host is configured, an attack on a particular guest could steal resources needed by other VMs or saturate the network controller. Make sure that you grant the external VMs explicit resource allotments to keep them from taking too much from other VMs in an emergency, and make sure you have the infrastructure to null-route or otherwise mitigate an attack to the best of your abilities.
 
CEpeep said:
We have both internal and external guests on the same Hyper-V host. I wouldn't attempt it if DDOS is a significant concern or without fairly robust routing infrastructure. It's secure, if that's what you are wondering. There's no (known) way for an attacker to break out of a Hyper-V container and get to the host or other VMs, but depending on how your host is configured, an attack on a particular guest could steal resources needed by other VMs or saturate the network controller. Make sure that you grant the external VMs explicit resource allotments to keep them from taking too much from other VMs in an emergency, and make sure you have the infrastructure to null-route or otherwise mitigate an attack to the best of your abilities.
Click to expand...

This is good info, thanks. I've been trying to get this kind of info. One of MS' best practice sheets suggests putting similar security concerns with each other and segregating by hardware. I am still giving serious consideration to putting at least one Linux DNS server onto a VM and letting it run with lower resources.
 
DDOS issues should be handled by your ISP anyways in all honesty. DDOS isn't an intrusion into your servers but simply using as much of the bandwidth up as possible with false packets to prevent anyone from sending or receiving legit data.

The only attacks that could be used for intrusion but resemble DDOS are synflood attacks. Those are setup to specifically hit a potentially vulnerable ports with specific code to attempt to bypass username/password checks. But there are few intrusion experts that work on those now. Most are nothing more than script kiddies that use and modify scripts to suit their needs instead of creating original works of art.
 
Draugauth said:
The only attacks that could be used for intrusion but resemble DDOS are synflood attacks. Those are setup to specifically hit a potentially vulnerable ports with specific code to attempt to bypass username/password checks.
Click to expand...
You are confusing synflood with bruteforce.

A synflood attack has nothing to do with passwords. A synflood is deisgned to fill up the server's resources by trying to establish a connection (SYN) to which the server replies (SYN+ACK) but then not completing the connection (ACK) but keep it lingering.

Compared to the bandwidth used, the resources on the server are used up pretty quickly because every OS has a set limit for half-open connections. When that is reached, no new connections can be established. Service is basically denied without filling up the bandwidth.

A counter-measure to that is OpenBSD's packet filter which supports synproxy states.
 
TCM said:
You are confusing synflood with bruteforce.

A synflood attack has nothing to do with passwords. A synflood is deisgned to fill up the server's resources by trying to establish a connection (SYN) to which the server replies (SYN+ACK) but then not completing the connection (ACK) but keep it lingering.
Click to expand...

That is what SPI is for; so you don't have a half responsed SYN. I believe OpenSSL also supports the packet filer that OpenBSD's has. (Because OpenBSD wrote OpenSSL.)
 
You must log in or register to reply here.
Back
Top