The operating system is of course the foundation for having any use for that fancy hardware you bought.

No matter how well you patch your applications and keep track, you still need to patch your operating system (and drivers / firmware for BIOS, disks etc ).
Since I work mostly with Windows environments (although I do dabble with Linux servers also) this is mostly about Windows servers.

In time, maybe I’ll write a post about Linux servers too.
Who knows.

There’s a few previous post on these matters here starting with the Physical aspects of a data center and networking aspects

None of these are the Gospel, they’re simply checklists or hints that I’ve just written down for my own amusement and hopefully someone will find them useful.

Server versions

If possible, do not use unsupported versions of operating systems
If you still need to use older server versions (due to old applications etc), make sure to have them secured from access by anyone not explicitly needing it.
Have it behind firewalls and VLANs etc

Drivers and firmware

For drivers and firmware, make sure to have a good documentation of what hardware your servers actually run on and always have a copy of the working versions available.

Few things f**k up your day as having a server lose it’s RAID controller or NICs because of a driver update and you realize you don’t have a functional one available anymore.

For Windows server you can use the often overlooked PowerShell command export-drives from time to time on servers that support it.

Patching

Depending on your environment and needs, there are different approaches here.

Personally, I’m a fan of manual patching when it comes to servers, simply due to the fact if something goes sideways, there’s someone to take care of it …. hopefully.

There are ways to automate server patching of course but it’s a bit of a nuisance if your servers were automatically patched during the night and something went horribly wrong and your users and customers no longer can access them.
It simply makes your morning very rough..

For Windows Servers, enable/use for instance a WSUS-server to keep track of how your servers are updated.
For Linux servers, script apt-get update && apt-get install etc

Local firewalls

In many environments, local firewalls are disabled out of pure laziness.
“We can’t be bothered troubleshooting why SQL traffic doesn’t work ..”
Have local firewalls enabled, enable logging so you can easily find what’s going on.
If you’re in a shared environment you’ll also get alerted about noisy neighbors .

Local firewalls also enables you to utilize a brute force prevention software and have those attacks mitigated, no matter where they come from.

If you want, I’ll happily help you out with getting a brute force prevention software in place.

Services

Go through all services started and make sure the ones they don’t use SYSTEM accounts etc unless they need to.
Should the service running contain a bug and someone manages to exploit that bug, they’ve got SYSTEM access to your server, meaning the entire server.

If you have service-users running services instead and those user are locked down, you’ll minimize the damage at least

When setting up the server, make sure to disable services not in use.
Both from a security point of view and for performance.
Windows for instance starts quite a few services that you probably don’t use nor need.

Network settings

Although not a service but if you’re not using IPv6, you might as well go ahead and disable it and also have a look at the various network settings for packet size, TCP chimney offload etc.

Verify your routes are ok and that you’re using the DNS servers you need.

Avoid WINS if possible.
It’s old, slow and can have terrible impact on a network.

File permissions

Have a look at file permissions.
NTFS and other file systems can give you a granular control of what is accessed and by whom.
A lot of these permission are set a bit loosely by default to make it fairly easy for systems administrators to install applications etc and grant access to users.
Usually they can be tightened to avoid users from starting applications or snooping around where they’re not supposed to.

Antivirus , backups

Install a good antivirus.
This should go without saying,
I like F Secure.

Install a good backup solution and make sure to have at least 3 copies offsite.
This too should go without saying.
Big fan of VytalVault here or build your own with for instance Syncrify.
Just be sure you’re happy with WHERE your backups are stored and make sure to test the in terms of Disaster Recovery.

I would also highly recommend using the built in VSS snapshots to be able to quickly recover files but , for the love of everything holy, do remember ,
VSS is NOT a substitute for backups.

Execution policies

Now, this is a bit tricky but it may very well be worth the trouble
There are fairly easy ways to implement executiion deny policies on servers ie only allowuing scripts and executables to be run from specific locations.
If you know all paths where scripts and executables will be frun from , why not turn that on ? That way you will restrict any weird executions from %temp% etc

Server access

Do not grant regular users access to the server via RDP (unless its and RDS server of course
Do not have a teamvivwer or any other kind of remote access software running unless you know it is secure and protected wioth a strong password

If you need to give users access (on a RDS server for instances) , make sure to disable access to Control Panel, Run command, Server Manager, Powershell , any unnecessary system information etc
I have a long list of stuff i deny access to in such setups.

Speaking of RDS and Citrix environments, pay close attention to what installed applications actually do.

Install them, click around menus etc and make sure users can’t open directories or access stuff they’re not supposed to.
Use NTFS permissions etc where applicable.
Hide drives users do not need to see etc

Installed services such as IIS, Apache, Exchange, FTP, WordPress etc

Whatever you’ll be using your server for. have a look at any information that it “bleeds”.

This could for instance be headers telling any attacker exactly what version of software you’re running.
If possible, try to hide such information. There’s no need for it to be visible and help a hacker find a way in.

Simple checks using telnet to the ports your services might reveal some interesting information .
Sadly, it’s not possible to remove all headers etc but you should give it a go and remove as many as possible

While on the subject, use SSL-certificates for any service where possible.
Also make sure to set it up correctly (disable weak ciphers, enable HSTS, set correct HTTP headers, set TLS correctly etc ) .

Have a look at Letsencrypt for instance for SSL certificates.
It’s free, supported by basically everyone and it’ll probably get the job done for you .
All you have to remember is to check that your certificates are renewed every three months.

Logging

Enable logging of login failures, access failures to operating system events etc. In short, log everything.
It’ll impact performance and use up disk but it’s useful for troubleshooting when the time comes.

Group policies

This way you won’t have to reinvent the wheel each time. Simply point the server to use your precooked GPOs to get a lot of stuff automated and set in place.

Server visibilty

Consider if you the server need to be visible for browsing or not ? Otherwise, “hide it” on the network using the “net config server hidden yes” command.

Also have a look at what you’re sharing with the “net share” command to make sure you’re not sharing stuff you didn’t mean to.

Disk space etc

Make sure to keep track of your disk space.
When you install your server , you’re good to go but over time applications etc may fill your system drive.

A way to try and minimize this is to install applications on other drives than the System drive.
Sadly that’s not foolproof since they may use %TEMP% or other hard coded paths pointing to for instance C:\ProgramData etc so you need to keep track of that before it’s too late.
Nobody wants to have a full System drive.

Documentation

Yep. Not that much fun no. It’s more fun to get stuff up and running and move on to the next task isn’t it?
Still, having a good documentation about what the server does, how it’s connected to other server and systems (ie dependencies) and the baseline configuration of it will make your life much easier.
Depending on the size of your environment , Spiceworks might be a good place to start