Problem solve Get help with specific problems with your technologies, process and projects.

Protecting your Web servers, part 1: Is your security pukka?

Protecting your Web servers, part 1: Is your security pukka?

Is your Web server security authentic or unauthorized? Are you clustering servers but cluttering security, or are your servers speaking in unity? If your border router or firewall could whisper, would your Web servers listen? If so, are you in danger of a server that welcomes a stranger? We begin a three-part series on protecting your Web server; in this mini-series, we will focus on Internet Information Services (IIS) security. Join me on a journey to explore and identify the security vulnerabilities in your network.

4th level of defense
Web servers are your company's fourth level of defense and reside behind your clustering devices (i.e., F5 Big IP), your firewalls (i.e., Cisco PIX), and your border routers (i.e., Cisco 3640), which are responsible for security and filtering traffic at the perimeter level. Off course, having an effective security policy in place and properly configured access control lists (ACLs), are essential to the fundamentals of network security. Read my previous articles for tips on securing your border router and firewall.

Underlying O/S security
Before we get started with tackling IIS security, you need to secure your operating system (that is, underlying layer -- in this case, Windows 2000). Make sure that you stop and set to manual state the services that I will include later in this article. As always, know your configuration and test each service before changing its state to disable.

Administration Web site
By now you should know that I do not recommend (under any circumstances, https or not) connecting over the Internet to any internal servers or routers for administration or troubleshooting purposes. Instead, set up a private VPN connection to your internal network and then from a trusted host, establish your session(s) and carry out your tasks.

Let's begin by disabling and removing the Administration Web site. Right-click on administration site and then stop the service. Next, remove the application listed in the Application Name field on the Home Directory tab in Properties. Change Execute Permission to None, remove Read, Log visits, and Index this resource. Then, replace the existing path of the Administration Web site with a temporary path (i.e., c:pm3t). (We'll change the path of your live Web site later in this article.)

You will notice that any attempts to connect to the administration Web site on default port 3061 will render an HTTP 403.2 (Forbidden) error or "The page cannot be displayed" message. You will get this message even if you start the administration Web site.

Deselect "Enable Default Document" from the Documents tab. Go to the inetsrv folder (found in winntsystem32) and delete the iisadmin and iisadmpwd (basically, any folder with *adm*). In IIS (via MMC), delete the iisadm and iishelp folders in the Administration Web Site, which is now just an empty site in "stopped" mode.

Test browsing to your default Web site to make sure that the site is still operational. Delete IISADMIN and then delete IISHELP and IISSamples after you remove the folders located in winnthelpiishelp and inetpubiissamples, respectively. You will need to stop the World Wide Web Publishing service in order to delete the iishelp folder. Remove the AdminScripts folder from the inetpub folder.

Pukka security for your Web server
If you have a public Web server, consider using remote control software (with session encryption, source IP address filtering, NT authentication, and the option to change the TCP/IP port) instead of using IIS Administration. Further secure your public Web server by locking down all other ports to that server in your border router ACL.

Enable TCP/IP or IPSec filtering in your Windows 2000 server. In addition, you can specify in the remote control software and the router the source IP address(es) that will be permitted to access your Web server(s). When selecting a remote control package, go with one that is not the most popular program -- your network doesn't need that kind of attention (hint, hint).

Replace the default Local Path of IIS on the Home Directory tab to a unique path. Make sure you check any dependencies (including your company's software) to the existing path before using the new path. Avoid granting the Write permission to your site; if you must grant it, then limit this to a single subfolder that is isolated from your main site. Make sure you log any write activities performed in any of your documents.

Some companies require the use of a public FTP server to enable users to download and/or upload files. If you must use FTP server for file transmission on your Web site, consider installing a dedicated server and using unique ports rather than the default ports of 20 (data) and 21 (control). Off course, you will need to implement the appropriate level of folder and file permissions.

Define a process that requires users to register (make sure you record their IP address, host name, etc.) with your company in order to use FTP services. Once they meet your criteria, provide them with your unique FTP ports. Not only will your process minimize misuse of FTP services, but it will require more effort on the part of a hacker. Consider changing FTP ports on a monthly basis.

Keep in mind that users (including hackers) will need to update their client FTP ports defined in the c:winntsystem32driversetcservices or c:windowsservices file (depending on the user's operating system) every time you change your FTP server's port. Remember to update your router's ACL and firewall's policy to reflect your unique TCP/IP (and UDP) ports.

IIS is NOT an FTP service
Don't even think about running FTP services on your Web server, especially a private Web server with Internet connectivity. Instead, set up a dedicated FTP server with security protection beginning in your perimeter router and firewall. Confirm that the FTP service is not running on your Web server. Stop the service (and any other unnecessary service) and set to manual state if running.

Make sure that you update the ACL on your router and firewall policy to only permit non-default FTP ports through to your dedicated FTP server(s). Block all the other TCP/IP ports and set a maximum connection limitation in your static route (or address translation entry) to your FTP server. Avoid using unlimited values for your maximum connections.

IP address and domain restrictions
An often-overlooked area is the restriction of IP address at the IIS server level. Usually if you have a public Web server, you typically want everyone to be able to visit your Web site(s). Therefore, the default setting of "All computers will be granted access" is accepted and never revisited to exclude IP addresses that you don't want to access your Website. Relying on Windows 2000 IP filtering is no excuse for not re-enforcing security at the IIS level. You will need to enable IP filtering in your border routers, firewalls, clustering devices, and all of your servers.

As soon as you discover from your logs IP addresses attempting to access your perimeter, exclude these addresses from accessing your IIS server. Of course, you can also check around for sites that offer a list of "offending IP addresses" and take a proactive approach toward security your network!

It's been my experience that some of these basic steps have often been overlooked by experienced IT professionals. If you're serious about security, you must pay attention to security details and leave no room for hackers.

In the absence of network security, exists an opportunity for intrusion.

Please write to me or visit my Web site ( and let me know if this article has brought to light any potential weak links in your network.

Luis Medina is the author of "The Weakest Link Series," which offers network managers an opportunity to identify ongoing network security issues. Luis also answers security questions in's Ask-the-Expert section. Submit a security question to Luis here or view his previously answered Ask the Expert questions.

This was last published in December 2002

Dig Deeper on Network Security Best Practices and Products

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.