What are the "to-do" on protecting Windows server facing the web?

I currently begin to deploy Windows servers facing the web.

And I would like to know what are you way of protecting your servers ? What softwares are you using ?

On Linux, i'm using Fail2ban to prevent bruteforce and Logwatch to get daily reports about what's going on on my servers. Are there any equivalents of those softwares on Windows ? If not, what do you recommend to use to protect the server ?

Solution 1:

First of all you need to think about your network design. It would be good to use at least one DMZ in oder to protect the internal network. A good Windows system for beeing public would be Windows Server 2008 R2 if you do not want to purchase the new 2012 Server. We have at least four windows based webservers which work perfectly as webservers, all based on 2008 R2. Just be sure to do the following:

• Use the DMZ (1 or 2)
• Do not install unused server roles
• Be sure to stop services you will not need
• Be sure to open RDP port (if needed) only into the internal network
• Be sure to keep all unused ports closed
• Use a proper Firewall solution like Cisco, Juniper or Checkpoint in front of the server
• Keep your server up to date (at least monthly updates)
• Make it redundant (use at least two servers, one for backup)
• Good monitoring: Nagios (I like it ;-))

(optional) Use Hyper-V for your webserver and it's backup system. Much easier to update and check whether your updates do not interfer with the webservice in some way. In that case you will need two identical hardware machines to have redundancy in case of an hardware fault. But that's pretty expensive maybe.

Hope it helps you!

Solution 2:

We could give you a more detailed answer if you tell us what service you want to provide on this public facing Windows box. e.g. IIS, OWA, DNS, etc?

To lock the box itself down, start with vlad's answer by removing (or not installing to begin with) any additional services/roles on the box that won't be needed. This includes any 3rd party software (no acrobat reader, flash, etc) that should not be used on a server. Any of course keep things patched.

Configure your firewall policies to only allow traffic to the appropriate ports for the services you are running

Configure an IDS/IPS with rules associated with the services you're running.

Depending on the risk/value of the asset, consider installed a host-based IPS in addition to your perimeter IPS preferably from another vendor.

Assuming the primary purpose is to host a website, locking down IIS is significantly less trouble with 7.5 (2008 R2) though you should still make sure that you do a few things such as:

• Store website files on a different volume from OS files
• Grab a XML security template from Microsoft, NSA, etc as a baseline
• Remove or lock down via NTFS all scripts in \InetPub\AdminScripts
• Lock down dangerous exe's such as appcmd, cmd.exe, etc
• Use IPSec to control traffic between the DMZ and authorized internal hosts
• If you need AD, use a separate forest in your DMZ than your internal network
• Make sure all sites require host header values (helps prevent automated scanning)
• Enable windows auditing of all failed and successfull events except the following successful events: Director Service Access, Process Tracking and System Events.
• Use NTFS auditing on the filesystem to log failed actions by the Everyone group and be sure to increase the size of your security log to an appropriate size based on backups (500Mb or so)
• Enable HTTP logging for the root folder
• Don't give unnecessary rights to user accounts that are running app pools.
• Get rid of ISAPI and CGI modules if you don't need them.

I don't want to make this too long so if you need/want more info on a particular bullet, please leave a comment.

Solution 3:

The existing answers here are good but they miss one crucial aspect. What happens when your server does get compromised?

The answer here on ServerFault when people ask that is nearly always to close the question as a duplicate of My server's been hacked EMERGENCY! The instructions in the top answer there describe how to find the cause/method of the compromise and how to restore from a backup.

To follow those instructions, you must have extensive logging and regular backups. You must have enough logging that you can use it to determine what the attacker did and when. For this, you need a way of correlating the log files from different machines, and this necessitates NTP. You'll probably also want some sort of log correlation engine.

Both the logging and the backups should be generally unavailable from the machine that was compromised.

Once you know your server has been compromised, you take it offline and start investigating. Once you know when and how the attacker got it, you can patch the flaw on the spare machine and bring it online. If the spare machine has compromised data as well (because it is being synchronised from the live machine) then you need to restore the data from a backup older than the compromise before bringing it online.

Work your way through the above linked answer and see if you can actually perform the steps, and then add/change things until you can.

Solution 4:

Run the SCW (Security Configuration Wizard) after you've installed, configured and tested the roles/applications for this server.