install updates in vm?

[ultimate99]

Do you guys install windows updates in a virtual machine?

 

[threetonesun]

... ?

 

Like, if you're running Windows, do I install them in a VM before installing them on my main computer? No, that seems a bit nutty. I usually let someone else vet the big ones (like 8.1) for a month or so before installing them though.

[Max Norris]

Sure, just like a real machine, keep the thing up to date and all that.  Do the same with any other OS in a VM too. 

 

Unless you mean testing them first, just in case.  In that case, nah, I have backups for that, I create a mirror before patch Tuesday.  If there's a bad one, I can just roll it back.  A VM wouldn't be the same as my real setup anyway in both hardware and software.. one could kersplode while the other behaves normally.

[Skiver Veteran]

I guess my question back would be, what is the purpose of your virtual machine? Normally people run VM's to test things and sometimes hotfixes, SP's etc can change behaviours etc of an OS so in that sense yes, I would recommend it and do recommend that the users in the company I work for do as frequently as possible.

[zeke009]

Do you guys install windows updates in a virtual machine?

It depends on the purpose of the VM. If it is for general use, then yes I would install the updates. If it is for specific trouble shooting or limited to a certain function, it may make sense to pass on the updates to control that environment.

[ultimate99]

I see. I thought they might be not necessary if I use vm to play with sql server or programming....

[threetonesun]

I see. I thought they might be not necessary if I use vm to play with sql server or programming....

 

Ah, for that, I'd always keep it updated. If it's like an XP VM to test IE8 on, no, that I would never update, for obvious reasons.

 

If you're worried about an update breaking something, just make a snapshot.

[RevitXman]

I have 3 VMs that run CentOS that run Nessus, a SCP Server and a test box. I also have VM for RemoteApps, and a RDP Windows 7 box for testing software.
 

I'm running an HP DL 160 G6 with 92GB of RAM inside Hyper-V

 

You can "snapshot" the VM and if you break it just revert to the snapshot and its good to go again.

[+theblazingangel MVC]

The quick, simple and best practice answer is yes, you should always install updates on a VM. A better answer is: it's more complicated than a simple yes/no, there are multiple factors that need to be considered including the network configuration of the vm, the presence of a software firewall on the host, and various aspects of the LAN the host is connected to, including firewalls, NAT, and what other computers may be connected to the network (via either ethernet or WiFi).

Below I will explore this topic further, but first let's understand and recognise the following:

• VMs do NOT automatically and magically inherit protection from the host OS simply by being a VM running within an application within the host OS. A better understanding of what level of protection is given (and what is not given) can be gained from insight into VM network adapter configuration, which I will cover below.
• There is more than one option relating to network adapter configuration when creating/modifying a vm.
• An attacker, either manually or automatically via malware, can use one compromised machine/VM as a launchpad for connecting to and attacking other machines/VMs.
• In many cases the contents of a VM are not valuable, while the contents of the host OS are, but in other cases, particularly in the corporate world, this is not the case, a VM may have incredibly vital/valuable content.
• Software patching for security reasons should obviously not be limited to the operating system, but should include application software too, including the vm software. It is vital to keep the VM software itself up to date because a vulnerability in the VM software could allow malware or an attacker to break out of the guest OS, through the VM software, compromising the host OS.

Now, let's take a look at the different types of network adapter configurations available for VMs...

 

VM Network Adapter Option Overview:

(Applicable directly to VMware player; other VM software will have similar/same).

When configuring a VM you may have the following options to choose from.

• None: As in no adapter is setup during VM configuration. The guest OS is completely isolated (in terms of networking) from both the host OS and the LAN the host OS is connected to.
• Bridged: The VM software connects directly to the computer's physical adapter, bypassing the host OS's network stack. The guest OS's virtual adapter is linked to this direct connection. Thus the physical adapter is being shared. The host OS and the guest OS in sharing the network adapter in this way have separate (unique) IP addresses on the same network segment, and will appear to other host computers/devices/VMs on the network as though they were separate computers directly connected to the network. The guest VM is either assigned its IP address manually or retrieves it from the DHCP service for the physical LAN (which on a home network is likely provided by the gateway (aka router) device).
• Host-only: The VM software creates a virtual secondary LAN, including a virtual DHCP service. This virtual LAN has a different IP address segment to that of the physical LAN to which the host OS is connected. The VMnet1 virtual network adapter created in the host OS is the host OS's connection to this virtual secondary LAN and is given the first IP address in the IP segment it uses. The guest OS retrieves an IP address from the DHCP service on this virtual LAN (or could be assigned one manually of course). Crucially though, guest OS's do not get a 'default gateway' IP address configured, and so while guest OS's can connect to one another and to the host OS, they can't establish a connection out onto the physical LAN (or therefore the internet), hence "host-only".
• NAT: This very similar to 'host-only' but has a crucial difference. A secondary virtual LAN is created, though separate from the one used for 'host-only' (I believe). The VMnet8 virtual adapter in the host OS is the host OS's connection to this virtual LAN. The big difference to 'host-only' is the addition of a virtual NAT router and DNS relay device. This device is given the second IP address in the segment. The guest OS's virtual adapter is configured to set that IP address as both the 'default gateway' and 'DNS server'. When the guest OS needs to communicate outside of the virtual LAN, the communication is sent to this virtual NAT device. The NAT device takes the packet being sent by the guest OS and forwards it through the host OS; in forwarding it, the virtual NAT device modifies the source IP/port such that when going through and out of the host OS, as far as the host OS is concerned, the packet originated directly from the VM software, just the same as any other packet originating from any other application running within the host OS. Any responses are delivered by the host OS to the VM software, which hands them to the virtual NAT device process, which modifies the destination IP/port to that of the guest OS, and it is then delivered to the guest OS via the virtual LAN.

Note, obviously excluding the choice of 'none', it may be possible for a VM to be given multiple virtual adapters of different/same type.

Here's a good article on all of this!

Brief Overview of NAT Technology:

NAT, for those that don't already know, is a service which translates one IP address and/or one port to another. A typical home gateway will usually have one single public IP address assigned by an ISP and yet must allow multiple computers on the private LAN to share it. (Also, 'private' IP addresses are not allowed onto the public internet (public internet IP addresses must be unique)). With NAT on a home gateway, sharing a single public IP address, when a communication is received at the NAT service from a computer on the private LAN, it maps the original sending IP/port temporarily to a new IP/port (the public internet IP and a free port), modifying the packet in doing so, before the packet is then forwarded on its way. When the destination sends a reply, the NAT service translates the IP address/port back again before it's forwarded on its way to the true destination. This translation is maintained only temporarily, it will timeout after a certain period of inactivity.

NAT can help from a security perspective by ensuring that all incoming traffic can only be allowed through if it was addressed to a port for which a NAT translation exists to an IP address/port of a computer on the LAN (i.e. it has somewhere to send it). (Note, port forwarding/UPNP are other ways of creating a translation to allow communication through). Also note that an SPI firewall further improves security, which I'll mention below.

Security Concerns:

So, let's look at security concerns, taking the different network configurations into account...

It can be generally assumed that any compromise of the host OS can lead to compromise of any/all VMs, network connection types being irrelevant, and so I'll focus only on attacks of the VM itself and from VM to host (and beyond).

Isolated VMs (No adapter):

Note that this also applies where the adapter is configured but is disabled, perhaps by unchecking the 'connect at power on' option in VMware player.

With no network adapter (or with an adapter disabled) the guest OS, as described above, is completely isolated from a network stand point. You can therefore safely get away with forgetting patches (which you'd have to obtain via means other than windows update anyway, e.g. download them manually and stick them on a USB pen drive which you then connect to the VM). Being isolated from networks however obviously does not guarantee it's safety, malware could be delivered via a USB pen drive for example. Also, don't forget the crucial aspect of keeping the VM software patched, otherwise such malware could potentially break out of the guest OS, compromising the host OS, despite there being no network connection.

Semi-Isolated VM ('Host-only'):

With a host-only VM, the VM is largely (but not completely) isolated and several attack vectors are effectively neutralised:

• An attacker (or malware) cannot establish a direct remote connection through which to probe and attack.
• Other common attack vectors are neutralised such as malware infestation delivered via a website or email attachment (unless retrieved from off of the host OS itself, but let's ignore that).

Just like a completely isolated VM though, they are not impervious to attack. They are still vulnerable to malware infestation through non-network distribution means, such as a USB pen-drive. Worse than a VM with no network connection though, they have a network connection to the host OS, and thus have a means through which to probe and attack the host OS.

As applies generally, the protection of the host cannot be guaranteed simply by keeping it up to date with patches, a "zero day" vulnerability could be exploited. A software firewall running on the host OS (so long as it protects the virtual network adapters in just the same way as the proper physical adapter) would help (but again, no guarantee).

Furthermore, as described above, all host-only VMs share a common virtual LAN, and thus one can attack another.

Despite the potential for compromise of the VM with say malware on a USB pen drive though, potential attacks face serious limitations. Often an attacker or malware will make use of an internet connection, to download additional tools/exploits, to retrieve instructions (in the case of malware), and/or to transfer data to the attacker. None of that is possible here. With malware, it can only accumulate data hoping that you change the connection type to Bridged/NAT in the future, attempt to compromise the host OS, or wreak havoc, but all functionality/instructions/tools must be bundled within itself, since there's no internet connection. Further, the list of ways by which a piece of malware can end up being actually executed is smaller than normal since some of them, such as remote code execution exploits and malicious flash components in webpages aren't viable. It is possible though, for example via auto-run, the .lnk Windows Shell vulnerability (here, here), or malicious macros in a document.

Again, as with a completely isolated VM, with no internet connection you've got a problem actually getting the updates if you wanted them. The easiest option would be to change the adapter type temporarily. Other solutions include downloading from the website, transferring via pen drive and manually installing (or you could write a script); or AutoPatcher, if they're still going, a project which used to be hosted here on Neowin and which I used to be a part of (though when I last checked they seemed to have neglected to listed me as a veteran after moving to their own forum :/). WSUS might also be an excellent solution, though only applies I believe if the host OS is a server edition of Windows.

Non-Isolated VM - Bridged:

 

With a bridged connection, the guest OS is essentially as vulnerable as the host is, any difference stemming only from differences in software application packages installed/used and general configuration / user activity. All common attack vectors are applicable, such as malware from a webpage / email attachment, or an attacker or malware remotely probing and attacking over the network.

The VM can communicate with not only the host OS but all other Bridged/NAT connected VMs (with some restrictions to NAT VMs, explained shortly) on this machine and others, all other machines on the physical LAN, and also machines out on the internet.

A software firewall on the host OS would be wise to help protect it from a compromised VM.

Non-Isolated VM - NAT:

Concerns here are similar to that of Bridged, in that common attack vectors (such as malware from a webpage) are applicable, and if the VM is compromised, it can connect to and therefore be used to launch an attack against, the host OS, all other Bridged/NAT connected VMs on this machine and others (with NAT related restrictions described shortly, except within the same VM software instance on the machine where NAT connected VMs are on the same virtual LAN and thus may communicate freely with each other), and other hosts on the LAN and out on the internet.

A significant difference compared to the Bridged type is a big restriction on communications placed by the NAT service. (I described how NAT works above, so I won't repeat it here). Communications destined to a guest VM connected via NAT (unless from another NAT connected VM in the same virtual LAN) can only reach it via channels opened up through the NAT service, and thus can only reach certain ports (excluding any potential clever tricks an attacker may devise to say bounce a communication from one port to another). These channels expose a much more limited attack surface than with Bridged, but an attack surface never the less.

Note that packets inbound through a channel opened through NAT are not limited to replies to a communication sent out, nor even simply to any traffic sent from IPs traffic was sent to, that is the job of an SPI firewall; here the channel is completely open to any and all traffic, but it all goes to a specific port on the guest OS. That port could be hosting a vulnerable service. Note that using non-standard port numbers for things does very little to nothing to help protect you.

Note that a home gateway is not protected only by NAT, but also by an SPI firewall. Here, it is NAT only, unless you separately add/enable a software firewall on the guest VM (Discussed shortly).

Again, as with Bridged, a software firewall on the host OS would be wise to help protect it from a compromised VM.

Additional Environment (Gateway/LAN) Security Concerns:

Direct Threats from Other Machines:

As mentioned at the beginning of this post, one compromised machine can be used as a launchpad for attacks on other machines. You should consider how exposed your VMs might be to threats from other machines on your LAN. This includes:

• Having multiple machines on a home network, one of which is compromised, which could direct attacks towards your Bridged/NAT connected VM.
• Your friend/neighbour could pop round to see you and connect a compromised machine of theirs to your network.
• If your WiFi is insecure, anyone within range could connect to your LAN and start probing/attacking things (either as an attacker themselves or malware on their machine).

Similarly, if your computer is portable and you took it with you somewhere where you then connected to a public WiFi access point, you've lost the SPI/NAT protection of your home gateway and are extremely exposed.

The appropriate solution here, in addition to keeping software patched, would be to install an SPI software firewall on the host OS, and additionally on any Bridged connected VMs. Furthermore where connecting a portable device to a public WiFi access point, you should use a VPN. With Bridged VMs you would need to install/setup the VPN in them too.

Other machines on a private LAN also pose an indirect threat in the form of UPNP, as mentioned next.

UPNP

When a connection is needed between a software application on your local computer and another computer out on the internet, typically it will be the application on your local computer that initiates the connection. In such a case, the outbound communication results in NAT and SPI firewall features on the gateway device keeping a temporary channel open to allow the response to come back in. However, not all applications work this way; some applications, such as VOIP based applications like Skype, or a web server, need to constantly listen for incoming connections, with no idea when they might come, and without having sent anything out first (you can;t always know when someone will call, and many calls will be out of the blue). Such connections will obviously be blocked from passing through the gateway device by NAT/SPI, which presents a problem.

UPNP is a feature in a home gateway device which allows a computer to request that a port/channel be opened back to it, through which all incoming connections may freely pass, i.e. all ports addressed to a particular port on the gateway will be freely forwarded (via NAT) to a particular port on your local machine/VM.

It is obviously crucial to keep that application patched.

UPNP however is a horrendous technology from a security stand point. Absolutely any computer on the LAN can issue UPNP requests, and a temporary port forward request as described above (one of several possible UPNP) can be crafted from one machine to open a channel to another. Thus one machine on a LAN can pose an additional indirect threat to another by using UPNP to open a channel to it through the gateway, allowing access to it for an attacker/malware, bypassing the NAT/SPI protection that could otherwise block it.

Furthermore there are other means of exploiting UPNP, for example I remember reading about malicious flash files in webpages that are able to issue UPNP requests from the computer viewing the webpage, thus the simple act of viewing a webpage can open a hole in your gateway. There was a reported flaw in certain home gateways that allowed UPNP requests to be accepted from the internet side, which should never be allowed.

The smart thing to do is disable UPNP and instead manually open the required channels (permanently) by configuring static "port forwarding" rules in the gateway device configuration. Thus channels are permanently open to specific ports on which specific applications like Skype that need them are listening (when they're not running the ports simply reject all traffic sent to them, unless some other application uses it of course), and the threat posed of having other channels opened maliciously is gone.

-----

 

I see. I thought they might be not necessary if I use vm to play with sql server or programming....

Based on everything I've written above, does anything you do in the vm require internet access? If not, I'd advise using Host-only mode and forgetting the updates (unless you need to be certain that your code functions on a fully patched OS).