Although we are not qualified to do it, the fact is a lot of the time we are the technical people in our shops and are the ones who have to setup a new server. Because we can't know everything we can sometimes leave some things insecure. Here is some of what I do to harden a stand alone web server:

Reduce The Attack Surface

The fewer entrances into a building means the fewer points an attacker can enter.

  • Disable any unnecessary services
  • If possible limit access to services by IP address (i.e. if you only remote desktop from home then have that as the only allowed IP ..... as long as your IP address at home is a static IP address of course)
  • Add only the services that you need on a server. If it is a web server it should have IIS and (if required) FTP installed. No active directory, DNS services, SQL, etc. Move those onto other servers or run them as virtual servers but keep the number of ways in low.
  • I would also recommend to disable the default website in IIS as that is a known location (almost always [drive]\Inetpub\wwwRoot\) to put files into and then access via your IP address
  • Remove any protocols or language features you do not use from IIS


Stay Up To Date

This is probably the most obvious one but keep all your software fully patched and up to date. Windows update is fairly good for this but will not update third party components you have installed so it is important to check those out. Also windows update will not install a service pack without operator interaction.

Ensure Lockout Policies

One thing that a lot of service manufactures do not include is a lockout mechanism. If a user fails their authentication to a service more than a threshold amount, their account should be locked out. If your service does not do this then find another service.

It is fair to note that the default Administrator account on windows can not get locked out. This is because the administrator is the only person that can unlock accounts. It is also fair to say that the Administrator account can do anything to a box and therefore is the most target account to try and get!

Change The Administrator Account

One thing I do is to add a brand new Administrator account with a different name and then disable the original Administrator account. The reason that I do this is that even if you rename the Administrator account it still has the same userId number in the database (500 on Windows NT to 2000, I am not sure about 2003 and higher but I assume it has not changed). The default Administrator user can no longer be attacked and the newly created administrator account can now be locked out on login failures. IF you do lockout your new account you can unlock it by rebooting the server in safe mode and using the Administrator account (the disabled account becomes undisabled in safe mode) and then unlock the account. It is a bit of a pain, especially if your server is not easily accessible but as I stated earlier the Administrator account is the most attacked and sought after account and the security gains are worth it.

Security By Obscurity Helps (It should not be your only defence though)

So many people cringe when they hear this phrase but it is another defence. By making it difficult for an attacker to determine what is going on makes it harder to execute an attack.

  • Move services to non-standard ports if at all possible. Things like SQL, FTP, and Remote Desktop are perfect things to move. Almost every script that people are running that just brute force these services (and there are a lot) just look for the standard port. By moving it off these attacks usually fall to zero. If someone does attack you they really are targeting you specifically and this is pretty rare.
  • Don't reveal information in service headers. For instance IIS will let people know over HTTP that it is IIS or that you have ASP running. FTP servers will usually report the product name and version number. Turn these things off!
  • Even blocking ICMP pings can be helpful (although most attackers are onto this). By turning off ICMP pings means that an attacker can not ping your server and may assume it is a dead IP address. Some port scanners, when scanning a range of IP addresses will ping the addresses first to even determine if they are open.

Read / Tools

There are lots of hardening guides out there. Go check them out! There are also some tools out there like the Security Configuration Wizard from Microsoft amongst many others.

Put Up A Fence

By fence I mean firewall. It is a great way to stop inbound attacks to services that listen on tcp ports by default. It also allows you to control who has access to what.

A fence can work both ways. It can stop someone from getting in or something from getting out. It does take a lot of time but it is possible to setup a firewall to control both traffic flow into and out of a server. This limits what an attacker can do once they get onto a system. For example if you disallow outgoing SMTP then they can not use you as a spam bot or if you disable TFTP then an attacker will have a hard time pulling down other files. This technique takes a lot of time to get right though but it is an option.

Verify Security

Before you put the server into production, ensure that it is secure.

  • Ensure that you can lockout accounts by failing logins
  • Do a port scan to see what the firewall is letting through
  • Telnet to the open ports and see what information is disclosed
  • Check that the latest of everything is installed (and that there are no known vulnerabilities in that version too)
  • Also verify that your services still work. I have sometimes oversecured something that prevented a service from functioning properly
  • Try attacking the server. You know it the best so try and get in. It may lead you to something that you have missed

Monitor Security

It is really important to monitor your log files and do a periodic security scan of your server. Adding on things like SNORT that detect and log hack attempts can also be beneficial if not eye opening. The number of attempted attacks a day you receive may just shock you. Sometimes I will just run a packet sniffer on my server in production and filter out the known good ports to look for suspicious traffic but that may be a little overboard for some people.