Senior Project

Windows Server 2012 R2: A Basic Hardening

Last Edited: 4/25/2017

Resources used in this project:

  • Virtual Box
  • Windows Server 2012 R2
  • Microsoft Security Essentials
  • Windows EMET 5.5

In this project, what I have done is taken a Windows Server 2012 R2 System and hardened it.  To harden a server is to take into account various needs to security for a system and then make changes to it with the system tools, 3rd party applications, both or one.

For this project, I took a relatively generic approach to hardening the server. To accomplish my task I used Virtual Box to make a virtual environment for not only the server I would be setting up, but to also set up a domain client to interact with the server.

In the real world; if this server were to be used for actual ‘work’, you would want to set a scope of what the server will be fully intended for.  Then using that scope, you would begin the process of slowly securing and testing your results to completion.

As I mentioned this is a generic approach to the hardening of a server.  Which will just allow for an idea of the different Windows built-in services you can use to secure a server and additional third party software you may want to use.  For all intensive purposes, this is a demonstration that gives you a great start to how to begin the process of Hardening. Every server will require its own configuration, based on need and sometimes preferences.

For this step, I went with Windows Emet 5.5 and Microsoft Security Essentials. If you’re not familiar with Windows Emet, I suggest reading up on it.  It is unfortunately soon to be discontinued.  But while there is still Microsoft Support for it, it is an invaluable tool that goes beyond what a basic Anti-Virus software would do.  It hooks itself into your system to monitor changes in Applications and DLL’s.  To verify their integrity and that they work as they should, without manipulation from a malicious party or software.

Second I went forward to install Windows Security Essentials. Albeit WSE is not intended for Windows Server 2012 R2, or any Windows Server.  It took some finagling to make it work for Windows Server, but using it is merely for demonstration and not because this is a recommended practice.

There isn’t too much to discuss when it comes to the need for an anti-virus solution.  It is a recommended practice to have an anti-virus on any computer system, let alone while hardening a Windows Server.

Also,  make sure to verify that all third party software comes from a reliable and authentic source. Never introduce third party applications to your server, that could bring in potential malicious software, or vulnerabilities.

My next step was a simple one, I updated Windows Server 2012 R2.  In a best practice scenario, you are only going to want to apply the updates that are necessary in protecting your system.  Being choosy as to what you need and do not need.  Any of the “Security Updates” may be included, but some updates may have a negative impact on your system.  On occasion Microsoft can and does release bad updates, which are typically resolved quickly. In my case, I just updated my entire system.  Every “Important Update” was downloaded and installed.  If you were to go ahead and Harden a Server for a true purpose,  you may want to go ahead and do research into what is safe and what is not, with current (and of course future) updates.  After this stage, you would typically disable automatic updates.

What I did after installing third party tools and updating my system, may seem backwards to some. It really comes down to preference here and personally I like getting my installs and updates out of the way first.

Next I configured base system information, I set up my static IP address (which in this case was I chose my Computer Name, made sure Windows Error Reporting was ‘Off’, IE Enhanced Security Configuration was On, Firewall was turned on and that I was in the right network space. Checked my Time Zone…

After all of this was complete I went forward with setting up my servers function.  Which for me, was Active Directory Services and RDP Gateway.

If you need information on either of these steps, please see:

Active Directory Installation

Windows RDP Gateway Installation

The purpose here, was to create domain clients that could access the server remotely, while also denying other clients from doing the same. Now that doesn’t mean that this is what you’ll want for your server.  However these two roles/services are relatively basic and widely used on Windows Server Systems.

After I got my roles installed, I setup a few accounts, a few GPO’s and setup my RDP Gateway. For the sake of Hardening, the reason I went with an RDP Gateway was so that I could have a custom SSL Certificate to be provided to my clients.

To complete the RDP Gateway security, I accessed it through the Server Manager > Tools > Terminal Services > RDP Gateway Manager.

Here I opened up the properties of the profile for MekkelsenServer and chose to create a Certificate under SSL Certificate.

Then went to Server Farm and added my server to the list of Farms.

Finally I made a Connection Authorization Policy for a group in my domain. I also adjusted the time-out feature.  So that no remote connection may remain idle for longer than 15 minutes, with out being disconnected

Now that I finished up my needs for RDP, I went ahead and tested it against accounts in an authorized group and unauthorized group.  Not only to verify that my policy was working properly, but also that I could connect in general. This is important in any steps when making changes to your system, especially when dealing with security.  You want to make your changes, verify you took the necessary steps, then test your end result.

So at this stage, I now have set-up my anti-virus and mitigation software, I have run my security updates and installed all the roles I need and want. What occurs next is to run the

Security Configuration Wizard, make a few tweaks based on testing against your changes and also tool around with the firewall to complete what you need that the Security Configuration Wizard may not have done for you.

The Security Configuration Wizard is your go-to tool built into Windows Server.  It allows you to quickly go through and make changes, that manually may be time consuming to do. To access the Wizard, you’ll go to your Server Manager > Tools > Security Configuration Wizard.  Once run you’ll start to be prompted.

As with any Wizard, you follow along with the prompts.  In this case your first real questions will be to Create a New, Edit and Exisiting,  Apply an Existing, or Roll Back the Last Applied Security Policy.

Of course not having a current policy, I followed a long with creating a new one (which was followed by editing, a few times later). Then you choose the server you are making the policy for, then greeted with a warning about how the world will end if you mess something up (this is why we test).

Your next series of windows will include prompts.  The first will be for Roles on your server.  What roles will you be using? Which one’s will you not be using? By checking the box for roles you will be using, it allows the SCW to know how to make changes to the firewall and start-up to allow for the roles to continue operating.  Anything left unchecked will either not start up, or be disabled access to the network.  So making sure you have all the right roles checked is important!! The default check(s) are assumed Roles you’ll be using based on the current configuration of the Server.

After Roles, you’re given a similar prompt for Features and then again for Options and then Additional Services.

Once you’ve got through all your check boxes, we get to a new series of questions. Such as how to handle the Start Up of Services.

This allows for a bit more discretion of services that may start up, that are not actually in the list of check boxes you went through.  In my case, I chose to make no changes.  Depending on the situation, you may want to turn this on. Helping to eliminate services that may themselves create issues with the security of your server.

The screen next, is one to let you know what changes up to this point (if any) have been made due to changes by the wizard.

The next section is Network Specific, again it will be another series of check boxes.

These check boxes will allow the SCW to know what Rules you want to have applied to the server, based on changes you made to Roles/Features/Options. So the same concept applies, check the boxes for what you need/want and uncheck the ones that don’t apply to your situation.

The next section is for Registry.  Which is going to say, what System Requirements are required to connect to your server.  Also which type of accounts may authenticate with the server.

Very straight forward, what kind of computer system may connect and type of accounts may connect also.

The next step in the SCW is to decide on your Auditing Policy.  This is a key piece to hardening a server.  Not only do you need to create protections in the hardening of a server, but you also need monitoring.  You need to be able todevelop some sort of log of activity.  Your Anti-Virus creates a log, your mitigation software creates a log and now your Security Configuration will also aid in a log.

Because knowing what your system is doing and what activities are being attempted, your best choice is “Audit Successful and Unsuccessful Activities”. It will take more resources from your system to log all events, but it would be a best practice to use this option. That way you can maintain accountability of what users may be doing on your system, or integrity of how the system is actually working within the confines of your new security policy.

The last piece is the wrap up, another view of changes you’ve made.  Then naming your security policy (which will be saved as an XML) and either Applying or Applying later.  Applying later will save your new policies for editing, or applying with the SCW at another time.

Now here’s where we come back to the whole test everything idea.  After you’ve applied your security settings, be sure to go through your server and verify that every Role, every Service, every Feature is running precisely as it should before logging out of your server.

For me, I found that the SCW doesn’t quite know how to handle RDP Gateway. It locked out all remote access for me, which defeated what I set out to harden my server for.  I had to go back through; after some research, and identify what the SCW did that I needed to edit to allow for RDP to work.  Not only did I have to add another check box in SCW features, but I had to make some changes to Windows Firewall with Advanced Security.

I had to go through the process of enabling a few RDP Rules.

This of course is not a difficult task, to enable or disable existing rules in the Firewall Settings.

While in the firewall settings though, I wanted to create some level of stealth for my server that would be on a network.  While there are many different rules you can create to eliminate the ability to find the server on the network. I chose to eliminate the ability for the server to be pinged on the network.

I then of course tested my new rule against it with my client machine.  As I said though, there are many rules you may set up to prevent all sorts of network activity being able to reach your server.

For me, this was my stopping point.  This is where it ends with my desired level of security on my server.  This is as hard as I need my server to be.

There are more changes, as I mentioned I applied a few GPO’s for local and domain to increase the security behind Password Policies and System Configuration access for the users outside the Domain Admin.

Through my process, I had researched a number of checklists to harden a server. In my case despite how lite of a hardening I have completed, I certainly touched on each of the requirements to securing a server.  With each step I completed, you can imagine that you could expound on even more ideas in locking down a system to fit exactly what you need.

This is why its important to create a scope before continuing with the process of Hardening a Windows Server or any type of server for that matter.  Sure, your servers needs may evolve over time or you may need to go back to make changes.  This is why even the most basic of Hardening may give you the relative experience you need to take it further, or adjust to newer demands.

For more information on some of what I’ve covered, or for a deeper understanding,  please check out the links below. I found them invaluable for putting this project together.

Links / Resources:

Baseline Server Hardening

Password Policy

Using Windows Security Configuration Wizard

Server Hardening: Windows Server 2012

Why You Should Avoid Manual Hardening

Windows Server 2012 R2 Hardening Checklist