INTRODUCTION
IT infrastructure security is a number one priority, whether it be bare-metal or virtual infrastructure. The matter of safety in a Hyper-V environment, in particular, is one of those things that require attention first and foremost. However, whereas the fundamental aspects of covering the question of protection are widely known, there are always tiny details nobody really pays any attention to. Even experienced IT administrators tend to pass them by. This article takes focus on such issues. Either in a highly virtualized environment or private cloud, every one of them can become crucial.
Admittedly, establishing security baselines in the Hyper-V environment is a sink-or-swim scenario. The primary user concern is the host operating system (OS) and network hardware: you simply cannot maintain security on a proper level with only one product active. The safety of the Hyper-V environment requires a complex set of measures, including but not limited to constant monitoring of services and equipment.
All your virtual machines (VMs) and resources are dependent on the hypervisor. If someone takes control of it, you can say goodbye to all your data. That is why Hyper-V security is essential. Check out potentially dangerous mistakes listed in this article while setting up and maintaining network hardware, host OS, and your Hyper-V environment so that it won’t be infected with ransomware.
Please, remember: all the facts below are for general information and educational purposes.
Let’s take a look at the most common examples:
- Host OS choice: the fewer the better fare
- Patches and updates
- Reckless patching and updating
- Passwords
- Backup and Disaster Recovery
- Checkpoints cannot replace Backup
- Additional roles on the Hyper-V host
- Installing additional software on the Hyper-V host
- Firewalls
- Opening more firewall ports than Hyper-V requires
- Trust, but verify
- Antivirus software
- Role-based access control
- Creating a new VM
- BitLocker
- Alerts
- Nota bene (NB)
HOST OS CHOICE: THE FEWER THE BETTER FARE
Few simple attack surface reduction tips can help prevent malware from infecting your Hyper-V environment. For instance, when installing Microsoft Windows Server Core or Microsoft Windows Serve Nano, you are going with the ‘minimal install’ option, namely choosing only roles and software required for task completions.
More specifically, in said OSs, avoid installing the Graphical user interface (GUI) to reduce vulnerabilities it is accompanied by. However, in Windows Server 2012/R2, you can turn GUI on and off. Configuring and maintenance are executed through the command-line interface. You can also achieve this via remote machine connection, performed with Remote Server Administration Tools, PowerShell, or the Microsoft Management Console (MMC).
Additionally, you can have your cake and eat it too! Not only does this version reduce the danger, but it also frees up your disk space, resources, and requires much less hardware capacity than the full version of Windows server. You can see how your working process can become more stable.
PATCHES AND UPDATES
As far as it goes, a lot of administrators may probably think that after you have installed OS, this is it. You don’t need any updates or additional patches. Nobody and nothing can get in. As it often happens, they couldn’t be more wrong.
In fact, you actually do need updates. Moreover, Windows updates are not enough, cause the apps in use can have critical mistakes that obviously won’t be gone after OS update. In a perfect world, there should be a list of software in use, according to which you can conduct searching vendor sites looking for patches and updates.
The main danger is coming from the network worms, that scan IPs and spread within unpatched systems. It makes no difference if you use a home lab without any particular confidential data.
To conclude, the smartest thing to do is download updates or patches directly from software vendors. Domain spoofing is a thing, so it never hurts to be cautious and use your own DNS server. To connect with root domain servers via TCP protocol, install the DNS server and block port 53/UDP to cut off fake DNS responses. Task Scheduler will help a great deal, whether it will be OS or software updates.
RECKLESS PATCHING AND UPDATING
Administrators usually install patches at the production server without giving second a thought about what effects can it have, not even mentioning updating the BIOS firmware.
In the best-case scenario, it will result in numerous small conflicts inside the system. At worst, the system will just stop loading. Under such circumstances, the critical applications from the side vendors will most likely stop working. That’s why Windows usually releases patches with the following instruction for conflict elimination.
To avoid all this hassle, try installing patches and updates at the staging server (a copy of the core server). If the full testing life cycle doesn’t show any severe side effects, you can now safely install the software at the production server. However, a virtual machine works in the virtual environment, so it is not always capable of recognizing potential conflicts. Just to make sure, don’t forget to back up your production servers before installing an update/patch, whether it was tested or not.
PASSWORDS
People often overestimate password safety, especially in local environments. Administrators in such cases tend to apply the simplest passwords imaginable. Both local and domain admins use almost identical account passwords for setting up workstations, VMs, and servers. Nobody says that each VM or server ought to have a separate complex password, but it at least must contain letters, numbers, and special characters.
Don’t forget renewing administrator accounts passwords! Ironically, it turns out that the “password never expires” option has an expiration date since the password you thought to be temporary usually ends up being permanent.
BACKUP AND DISASTER RECOVERY
In the backup and disaster recovery matters, there are three primary stages of enlightenment. At first, you don’t back up data at all. Then, you do. Finally, you are not only doing backups, but you also check whether a recovery is possible.
Unfortunately, there are always such cases when even the most elaborate backup strategy doesn’t save you from losing your cool, data, and time. The most experienced administrator still won’t be able to predict each disastrous outcome. All in all, to merely back up is not enough. You need to check out how your VMs or servers will be acting after recovering, native hardware or not.
CHECKPOINTS CANNOT REPLACE BACKUP
The principles of what backup is and how does it work are general knowledge facts. The administrator can back up files, folders, the whole OS, and even disk volumes (each volume separately).
Checkpoints, on the other hand, is a whole different deal. Checkpoint takes a snapshot of a file or directory at the present moment. This Hyper-V service is designed for saving the existing state of a VM in a way so that the VM can revert to its previous state. The VM can be turned on, shut down, or paused during Checkpoints work. When you create a Checkpoint through Hyper-V Manager, VM pauses, and the changes are stored in a differencing disk as a dependency tree. Usually, Checkpoints are intended for use in development and test scenarios and allow the VM to revert to its original state. Checkpoints service does not make a complete copy though: it merely creates a differencing *.avhdx disk placed in the same folder as its parent *.vhdx disk. So, if software or hardware failure were to occur, you won’t be able to complete backup and recovery.
Backup is a copy of data, stored in a separate system or medium, that can be recovered in the event of a primary data failure. Unlike Checkpoints, a backup copy is not dependent on VM files and can be easily stored in the cloud, tape, or remote storage.
You must remember that even a full backup copy won’t help you in case of a primary failure if it is stored in the same storage! If you are running an incremental copy, keep in mind that losing an intermediate archive file will compromise the whole backup.
ADDITIONAL ROLES ON THE HYPER-V HOST
On the Hyper-V host, Hyper-V should be the only enabled role. Occasionally, administrators may assign additional tasks to their Hyper-V hosts, but this is a wrong approach. You aren’t supposed to use Hyper-V hosts either for your domain controllers or as FTP servers. Any external service is a liability. An FTP server or a web server can let an intruder transfer a malicious file to a sensitive location.
INSTALLING ADDITIONAL SOFTWARE ON THE HYPER-V HOST
Installing any additional software on the Hyper-V host (that isn’t required) is highly unwelcome. You shouldn’t run any performance testing, office apps, browsers, or games on the Hyper-V host if it’s not necessary.
FIREWALLS
Beginners usually configure a firewall on managed routs and switches, while neglecting servers, group policies, working computers, and VMs. Moreover, incorrect configuration of software firewalls can bring more damage than any antivirus software.
A hardware firewall can greatly reduce the risk of virus infection if any network violation were to occur because it monitors the state input and output traffic. A software firewall, in turn, protects the system from the inside, if the threat is coming from a malicious employee. To conclude, combining hardware and software firewalls can significantly increase security in a local network.
OPENING MORE FIREWALL PORTS THAN HYPER-V REQUIRES
You should only open ports to those services that are required to run your hypervisors. Running RDP on your firewall ports and opening RDP access to all local or domain users are the most common mistakes made. You should always check your ports and block them by necessity.
You must have a robust firewall in place to monitor the traffic coming to and from you Hyper-V. Monitoring is essential because you want to keep an eye on who is accessing Hyper-V at all times. Determining the type of traffic that is flowing through your hypervisor and VMs is also a must-have.
Keep in mind that changing software firewall configuration might have several negative consequences, such as network vulnerability or host becoming unreachable.
TRUST, BUT VERIFY
Many applications installed on the server are installed by default with administrative or even system privileges, accessing as many files as there are. As a result, any server configuration error, any script defect, or any server security vulnerability can allow an intruder to access the data or even destroy it.
To avoid this danger, run the server or applications from a limited user account with the access only to the required files. You would be surprised how much separation of privilege at the file system level reduces the level of potential damage! You shouldn’t forget that too many files are accessible by default, which is why it’s up to the administrator to distribute access rights carefully, deciding who has the right to read/write each critical file.
Is it possible for an intruder to bypass access restrictions? Of course it is. However, in this specific case, a potential intruder needs to find a loophole granting core privileges or allowing to elevate privileges to administrative. Such loopholes do exist, but there are very few of them, and Microsoft usually fixes them real fast.
ANTIVIRUS SOFTWARE
There is a quite popular opinion suggesting that a robust software firewall and NAT (Network Address Translation) should replace antivirus software since the latter is prone to slowing the whole system down. Of course, some admins still tend to install highly dubious antivirus software that not only lacks efficiency but interferes with the overall functioning of the system.
Whereas Microsoft is not officially commenting on whether installing antivirus software on Hyper-V is harmful or not, it does provide instructions on what to do if said software was already installed.
ROLE-BASED ACCESS CONTROL
The best practice, in this case, is to give any user that could potentially need to access Hyper-V only a limited set of permissions required to do their job. Remote management tools provide many user registration and authentication features that prevent unauthorized configuration changes, software installations, and other potentially malicious activities. Remember, it is a matter of utmost importance to make sure that the user can’t move a virtual machine, turn on or shut down the server, or mistakenly remove any important file. Besides, you should also have policies in place for who can access Hyper-V, for hypervisor access should always be minimized.
CREATING A NEW VM
Since virtual machines are much simpler and faster to create than bare-metal ones, there is a great danger that you can start running VMs that are not fully updated or configure. If you want to avoid the risks, it’s better to use the same methods and procedures for updating and configuring VMs that you use for updating bare-metal servers and machines.
In other words, no new VM should join your network or become accessible without setting the predefined policies in place first. Otherwise, recently added VMs might become vulnerable to malicious attacks the moment they come online. Moreover, an infected VM could potentially cross-contaminate other VMs inside the network.
BITLOCKER
Since BitLocker is built into Windows, its best to use it for those volumes where Hyper-V files and virtual servers are stored. BitLocker-based physical protection always works, whether the server is turned on or not. If the physical disk falls into the wrong hands, your data will remain safe. It doesn’t matter if the intruders are using different OSs or hacker software to access the content of the disk.
Note: BitLocker is for Hyper-V exclusively. Don’t run it on virtual servers because they don’t support BitLocker.
ALERTS
Setting up security alerts is vital so that when a potential threat is detected, you can address it instantly. Alerts can indicate malicious attacks, viruses, unauthorized access, critical changes, etc. These alerts proactively notify you when problematic matters are found in your monitoring data. When creating an alert, check how it works.
NOTA BENE (NB)
Hardware firewalls have one significant disadvantage to mention. Usually, every single hardware firewall has a reset button, which can reset a hardware firewall to factory defaults. One malicious employee can disrupt the whole organization’s security by pushing just one button or even leave it without internet access. The problem is, to reset firewall you don’t need qualification, just to know where this button is. On the other hand, to change the configuration of the software firewall, you’ll need at least to get administrative privileges. Therefore, when using a hardware firewall, make sure it is entirely secure.
The protection of information systems from unauthorized access should be the most complex you can get. That includes software and hardware firewalls, antivirus software, system configuration, LAN card software update, employee education program, etc.
Checkpoints per se cannot guarantee system safety, but you can use them for test and problem searching purposes. However, if there are too many Checkpoints created, it may reflect poorly on VM performance and resource intensity. Checkpoints, storage, virtualization, and backup together can guarantee the quality of information system backup and recovery.
If you aren’t 100% sure of your actions, then you shouldn’t be checking what happens if you enable/disable this or that parameter. It’s really better to first find relevant information about solutions or settings that interest you. In case that doesn’t help, see the most precise way to express what you want to know and ask a more experienced admin for help. Why doing so? The more accurate the question is, the more profound is the answer.
If none of these options works, then get on with your home lab, do all the testing you need, and, well, – see what happens!
