The significance of building a reliable and secure environment in any server hemisphere cannot be undermined. Server hardening is an important part of the same.
An IT infrastructure may be large or small. It may involve the use of coding for deploying Windows servers, hundreds in number through the cloud. Hand building a physical server for a small business is just one example of smaller server infrastructure.
Out-of-the-box Windows servers come by as the need of the hour, because of the complex requirements that businesses have. But such servers are lagging in the requisite security measures. They are hence not fit to go in the production process.
Microsoft has nevertheless been improving the default configuration in every successive server version that they have come up with. But server hardening is a must for a server, irrespective of its version or configuration. It safeguards the servers against cyber-attacks.
A few of the steps are a must for a default checklist for server hardening. But the best practices are overall variable and situation-specific.
Here, we discuss some essential steps for server hardening that resolve more or less all issues encountered with server management. This will safeguard a server against the vast majority of threats that are presented over the internet. They are primarily focused on strengthening Windows servers.
Let us take a look at this checklist which helps accomplish the same:
It is important to ensure that the password of the local administrator account is secure. Similarly, one should disable the local administrator at all instances possible.
This account is of use in minimal situations. For a hacker, this makes it a preferred point of attack. When one disables the local administrator, the odds of it being attacked or exploited are diminished.
When the local administrator account is done away with, a user needs to set up an admin account for use. One has a choice at adding an appropriate domain account. In case your server is affiliated with an Active Directory (AD), then create a new local account. Then, one should add it to the administrator’s group.
Irrespective of the method chosen for the aforementioned step, one may want to use a non-administrator account for handling your business at all instances possible. For the same, one requests elevation using Windows Sudo equivalent. “Run as”, and enter the password for the administrative account when the prompt appears.
A user should make sure that the local guest account is disabled at all places where applicable. The security of built-in accounts is always questionable. Guest accounts are the least secure among them. So, one has to make sure that he closes up the path of attack.
Security groups should be double-checked. This ensures that all users are where they are supposed to be. An example of the same is to add domain accounts to remote desktop users’ group.
It is then important to safeguard the passwords as well. A strong password policy will ensure that the accounts over the server cannot be compromised.
In case your server is affiliated to an AD, the password policy will be set at the domain level, as the Default Domain Policy.
In case it is a standalone server that you are working upon, it may be set in the local policy editor. Either way, a good password policy will establish the length and complexity requirements, which will specify the strength of the password. It will further define password expiration, password history and account lockout configurations.
Production servers should use a static IP. When such is the case, clients can reliably find them. The IP should be in the format of a protected segment, safeguarded by a firewall.
At least two DNS servers should be configured for redundancy. The name resolution similarly should be double-checked using nslookup, from the command prompt.
A user then has to ensure that a server has a valid record in the DNS, with the name that you intend to use. A PTR should also be available for reverse lookups.
A time lag of several hours may occur before DNS changes propagate across the internet. Production addresses should hence be established a significant time before a go-live window.
Finally, in case the server would not be using any network services, such as IPv6, you should disable them. But this also depends on the environment, and any changes made at this point should be tested thoroughly prior to their implementation.
Windows Features and Roles Configuration
For using features and roles, Microsoft uses OS packages. Roles may be defined as a collection of features that have been made for a specific purpose. Roles are chosen in case a server can accommodate them. The features can be customized from that point on.
But a user has to ensure that everything is installed, which may include IIS or the .Net framework. In dearth of the requisite components, the application will cease to operate.
A user also has to make sure that he uninstalls all things that he does not require. An extraneous package will extend the attack surface, which is undesirable and should be safeguarded against at all instances feasible.
So, in case there are default applications installed over the server that won’t be used, they, too, should be removed. The design of servers should be necessity based. When servers are made to be lean, it will improve the functionality of the necessary parts.
The finest way of keeping a server secure is to keep it up to date. This is not too difficult. One does not have to apply updates and patches as soon as they are released with superficial testing only.
A little bit of a lag in applying the updates is acceptable. But one should not delay the application of updates for too long.
One has to try and make sure that the vulnerabilities that are easier to exploit are tackled first. The older a vulnerability is, the more likely it is to be exploited. So, in case you have a year-old vulnerability, you need to rework it first because hackers are more likely to exploit it.
So, for older vulnerabilities; check if updates are available. Then download them and install them, first in testing and then in production, if the results of the testing phase are reliable and positive. Similarly in some cases, one might get notifications about the available updates. It is prudent to never cease to act upon them.
Updates are of different types. Patches make a common category and address a single vulnerability. Roll-ups, similarly are a group of packages that address several vulnerabilities. The vulnerabilities addressed by roll-ups are related in most cases.
When we consider service packs, they are similar to updates but address a wider range of vulnerabilities.
After an update is released, you should take a look at the Microsoft user forums. This gives one an insight into the public experience of the update.
The OS version is also an update of sorts. When you use an older OS version, it does not augur positively for security. On the other hand, using the latest OS version keeps the server security levels relatively much higher.
In case you find time from your production schedule, configure automatic updates over the server. It is not favorable that many IT shops are lagging in manpower required for the review and testing of all patches. The problem arising from the same is stagnation in the installation of updates.
But the risks involved are even more, in case a production system stays unpatched, instead of being updated automatically. This becomes, even more, the case when we take critical patches into consideration.
Therefore, as soon as one gets access to updates, one should forward them to the test environments. While testing them, the teams will observe their behaviour. Optional updates are okay to do manually because they are meant for addressing minor issues.
Let us now consider the case of the remainder of MS software updates. A few of them are received through Windows Updates as well. In case one uses any MS server technology, such as SQL or Exchange, it is important to turn the updates on for other products. All applications should be regularly updated with testing.
Even if a time difference of merely five minutes occurs, Windows logons will be completely broken down. The same goes for a range of other functions that are reliant on Kerberos security.
The servers that are members of domains have their times synced automatically. A domain controller syncs their times, after joining the domain.
But standalone servers need NTP for syncing to an external source. This allows their clocks to stay accurate.
Ideally, in the case of domain servers, the time should be synced to a time server. This will ensure that the domain stays within the operational range of the actual time, throughout.
For building a web server, one requires web ports alone. Web ports 80 and 443 should be open and establish a connection between the server and the internet.
But in case an anonymous internet client talks to the server over other ports, it opens up an unnecessary security risk which will be huge.
In case your server has additional functions as well, such as RDP, which is Remote Desktop for management, they should be available over a VPN connection alone. This will ensure that unauthorized internet users will not have the liberty to freely exploit the port.
Windows firewall is a good built-in software firewall. Using the Windows firewall, we can control port-based traffic coming from within the OS. But when we take the case of a standalone server, or any server lagging in a hardware firewall ahead of it, Windows firewall will still provide some protection. This will be against network-based attacks. Henceforth, the attack surface is limited to the allowed ports.
Overall, a hardware firewall always makes a better choice. It will offload the traffic to another device. Hence, more options will be available for handling that traffic. The server is hence freed to focus on its core responsibilities.
Irrespective of the method that one uses, one of the primary targets is to restrict the traffic to necessary pathways alone.
Remote Access Configuration
In case one uses RDP, it should be accessible via VPN alone. This too is only in the case that the accessibility is possible at all.
When one leaves the RDP open, it gives hackers an additional pathway for attacking the server.
It is only authorized users who should be able to access the RDP. But by default, once RDP is enabled over the server, all administrators can use it. Additional users can also join the Remote Desktop Users group. After joining, they can access the RDP without becoming administrators.
Apart from RDP, SSH and Powershell are some other mechanisms for remote access. Whenever these mechanisms are used, they should be locked down carefully following use. It is only in a VPN environment that they should be made accessible.es
It is best to do away with the use of Telnet in entirety. It is insecure in several ways because it passes all information in plain text. FTP has the same case as well.
Therefore, SSH and SFTP should be used in all instances possible. They should be used in a VPN environment. Unencrypted communications are best avoided.
Over Windows server, a set of default services exist. Upon starting automatically, they run in the background.
Numerous among them are prerequisites for the operation of OS. Numerous are not prerequisites as well. So when one is not using a service, it is preferable to disable such a service.
The logic applied over here is the same as the logic applied over the firewall. A user attempts to minimize the vulnerabilities, which translates to the surface area of the server that can be attacked. So, while the primary functionality operates, the remainder of the functionality should be disabled.
MS servers are also advancing. The older servers had more vulnerabilities than the newer versions. So in case, one uses 2008 or 2003 servers, one has to be extra careful. It is overall recommendable to update the server as well.