Category Archives: 4553

Clustering IIS and SQL on the Same Boxes


That pretty much summarizes my feelings on this topic.

I have seen this proposed as a configuration before many times. The web guys say they need HA SQL for their web site data and then they figure that since they are getting a cluster that they can use it for IIS, too. No, don’t do it. While at first glance it makes some sense, if you start thinking big picture, then you start seeing the problems. First off, the big picture for an HA website with HA SQL backend should look like this:

  1. Clients connect to the Internet to access the web site.
  2. The client then connects to the web site through the firewall. The firewall protects the IIS servers in the web site. This is where best practices start to kick in. Using NLB with IIS provides a scalable and highly available web platform.
  3. The IIS server communicates with the SQL MSCS cluster behind another firewall. Again, a best practice to keep the SQL data from being compromised in the event the web server is compromised.

The result?

  • IIS is protected, scalable, and highly available
  • SQL is extremely well protected and highly available

The alternative solution (meant to save money) is to use one MSCS cluster to host SQL and IIS. In this solution:

  1. Clients connect to the Internet to access the web site
  2. The client then connects to the web site through the firewall. The firewall protects the IIS servers in the web site.
  3. The IIS server communicates with SQL on the same cluster perferrably on the same node at the same time.

The problems with this configuration are:

  • SQL is not as well protected
  • IIS is no longer scalable
  • IIS 6.0 is not MSCS cluster aware

In order to make it work (IIS and SQL on the same MSCS cluster), you need to:

  1. Create a resource group
  2. Use the generic resource script for IIS 6.0
  3. Create your SQL instance in the same resource group

Since SQL and IIS are in the same resource group, they will failover together and be on the same node all of the time. You will want to do this because if there are problems with a node causing one of the resources to fail, you probably will want all of the resources to fail, too.

However, again, I strongly recommend against putting IIS and SQL on the same MSCS implementation.

Hardening IP for IIS Servers – Original Posted Apr 5, 2005

Aahh, the joys of meeting SOX requirements…


Tonight, I am having fun whipping together a script to apply to servers to meet SOX audit recommendations. This particular task is to harden IP on all IIS 6.0 server per KB 324270.  I had been tasked with applying changes to IIS 6.0 servers working with others on a team. I volunteered to create the script to handle many of the registry changes required to meet the audit requirements (yeah, I am stupid that way…). They get the joy of testing and deploying the script in production.


My first step was to create the script itself. Afterwards, I had the joy of creating the .ini files that I will use in conjunction with regini. The commands in the script are pretty simple once the .ini files are created, and they are pretty simple, too.


First the script, a very basic command line script (yes, I sanitized it to protect the innocent, and I also removed many lines and simplified it for ease of understanding):


@echo off



rem Apply IP Hardening registry info

ECHO Implementing IP Hardening registry entries

regini SynAttackProtect.ini

regini EnablePMTUDiscovery.ini

regini EnableDeadGWDetect.ini

regini KeepAliveTime.ini

regini NoNameReleaseOnDemand.ini


I created this very simple script (damn, it sure looks easy, doesn’t it?), and then I created the individual .ini files. They are simple text files as follow (note, the italicized text is the content of each file):









                                     SynAttackProtect = REG_DWORD 0x1









                                     EnablePMTUDiscovery = REG_DWORD 0x0









                                     EnableDeadGWDetect = REG_DWORD 0x0









                                     KeepAliveTime = REG_DWORD 0x493e0









                                     NoNameReleaseOnDemand = REG_DWORD 0x1

Yeah, I am done. How are the other team members going to deploy the script?  I am not sure, but I am out of the office for the rest of the week.

A point that I would like to note; I don’t think a script is the best way to deploy these changes. These entries scream for other ways to get them to all of the servers. I gave my recommendation and was out voted. I am practicing a special “I told you so” dance when they realize that I was right. I think I hurt myself, but I should be healed enough to do the dance when I get back in the office.  🙂

IIS 6.0 Security – System Files, Management, Samples, and Help Files – Original Posted Mar 14, 2005

Yes, these are still a problem. In IIS 5.0, many organizations would perform an installation of IIS 5.0 and totally miss some pretty ugly potential vulnerabilities. The biggest of these include:

  • Samples

  • Help Files

  • IIS Admin (HTML)

Some common sense should tell us that we need to get rid of these potential vulnerabilities in IIS 5.0. However, many of us forget that some of these still exist in IIS 6.0. Samples are samples. Why in the world would you ever want these on a production server? Maybe development, but certainly not in production. The same is true of help files. Why would a server need to refer to help files to keep production code running? Well, of course it doesn’t need to do that. A production server runs the code you give it, and it should not run anything else. Then there is the dreaded IIS administration web site. Um, in case you had not noticed, you can manage your servers using the MMC snap-in. It is easy to find, after all, it is called, “Internet Information Services (IIS) Manager.” Hmmm, I would bet, based on its name, that it could be used for mananaging Internet Information Services. Don’t use the HTML version of the admin tool. You should remove the HTML version of the tool in Control Panel\ Add or Remove Programs\ Add\ Remove Windows Components\ Application Server (Details)\ Internet Information Services (IIS) (Details)\ World Wide Web Service (Details)\ Remote Administration (HTML). Just because a tool exists does not mean you should use it.

Some non-common sense items related to security have to do with the NTFS permissions on many directories. These directories (OK, you can call them folders if it makes you feel better) should be secured so that administrators have full control, System has full control, and authenticated users have read access:

  • \InetPub

  • \InetPub\wwwroot

  • \InetPub\ftproot

  • \InetPub\mailroot

  • \Program Files\Common Files\Microsoft Shared\web server extensions\50

  • \InetPub\Scripts

These files should be secured so that administrators have full control, System has full control, and authenticated users have read and execute access:

  • \Program Files\Common Files\System

Make sure that the permissions for this folder (does that make you feel better?) is secured so that administrators have full control and System has full control.

  • \%systemroot%\help\iishelp

  • \InetPub\AdminScripts

  • \%systemroot%\system32\inetsrv

  • \%systemroot%\system32\inetsrv\History

There is much more than you can do to help secure IIS. For example there is a whole slew of information on hardening TCP/IP that I may write about in the near future.

IIS Required Services – Original Posted Mar 14, 2005

I am still working on the final bits of my IIS 6.0 Security presentation for TechMentor in April. One of the pieces that seems to have a great deal of conflicting information is what services are required by IIS 6. So, here goes:

Required Services include:

  • Event Log – My recommendation is to follow the suggested settings in the Threats and Countermeasures white paper in chapter 3.

  • IIS Admin Service – Without the admin service, you can’t provide Web, FTP, SMTP, or NNTP services.

  • HTTP SSL – Since I condone using SSL for all private communications involving customer data and proprietary information, this should be required.

  • MSDTC – This is only required when using the two phase commit feature of COM+. In many cases, it is recommended that MSDTC be use from another server in the environment.

  • Protected Storage – Used to mainatain certificate information like private  keys. A requirement for CAs. SSL and SMIME will not work unless Protected Storage is running.

  • Remote Procedure Call (RPC) – RPCs are used for many different components of Windows. RPC is a requirement for BITS, IISAdmin, COM+, Certificates, and so on.

  • Remote Procedure Call Locator – Used for named pipe connectivity.

  • Server – The server service is required to receive RPCs. Even though an IIS server does not need to act as a file server or print server, it still needs RPC support.

  • Workstation – The workstation service is needed to establish connections to remote systems, including named pipes connections. If your IIS server uses a back-end SQL server, then you will need to keep the workstation service running. The workstation service does not impact the use of IE or other browsers to make HTTP connections. This service is also vital if you are using UNC names to connect to content.

  • NTLM Security Support Provider – Provides security for all services and components that are not able to use Kerberos. This service is vital if the IIS server is not a member of a domain.

  • World Wide Web Publishing Service – Well, duh… Without this service, your server will not be able to respond to web requests.

Potentially Required Services

  • Certificate Authority – This service is required if you plan on the IIS server running as a CA.

  • Index – Used to build and maintain an index that can be used by a search component on the web server.

  • FTP Publishing Service – Used to provide access to the server using FTP. This service should be hosted on its own server where it can be highly secured as it has many vulnerabilities associated with it.

  • NNTP Service – This service should be installed if you intent to make content available via news readers.

  • SMTP Service – This service should only be enabled if there is no other available SMTP server available for use by the web server. If this service is used, it should be secured.

  • Plug and Play – This service is used to identify new/changed hardware, install the drivers, and activate the hardware. It should only be used if required to install and maintain the server hardware.

  • Uninterruptible Power Supply (UPS) – Only needed if you have a UPS, which you should, to support your web server.

Not Required by Most Installations – Most of these following services have several vulnerabilities associated with them. I strongly encourage turning these services off when possible, which should be almost all of the time.

  • Alerter
  • ClipBook Server
  • Computer Browser
  • DHCP Client
  • Messenger
  • NetBIOS Interface
  • Net Logon
  • Network DDE & Network DDE DSDM
  • Network Monitor Agent
  • NWLink NetBIOS
  • NWLink IPX/SPX Compatible Transport (not required unless you don’t have TCP/IP or another transport)
  • Simple TCP/IP Services
  • Spooler
  • TCP/IP NetBIOS Helper
  • WINS Client (TCP/IP)

<updated because Neil MacMurchy caught something that I missed>

IIS 6.0 Security – Original Posted Jan 28, 2005

Wow, there is a great deal of confusion on this subject. I asked a few people what they thought this topic is in their minds. I heard several differing views regarding what it means to secure IIS 6.0. So, what is it? Is it securing the server? Is it securing the service? Is it securing the application or site?

I tend to lean towards the definition including securing the application or site more than anything else. The goal is to make sure the website and any applications available through the website is available to users. Now, that goal does include securing the server and securing the service, but if you include the website content/applications then you are adding another level to the issue.

So, we secure the server doing such fun tasks as turning off unused services and basically locking down the operating system. We put the server in a well protected DMZ. We can also perform such tasks as enabling IP filtering and configuring filters on the firewall(s) to help protect the server from unauthorized port access. We can turn off ICMP ping responses to make the server and its IP address a black hole to script kiddies. We should install antivirus software and anti spyware software. There are so many things we can do and should do.

Some tasks that I am not hearing when it comes to securing IIS 6.0 include using tools to republish the site on a regular basis and moving the actual content to servers inside the LAN. If your site is defaced by some incredibly industrious hacker, you can write right back over it with your approved content using several different applications or home grown scripts. The hacker gets the joy of defacing your site for a few minutes and *poof* it is right back to the way it should be in a matter of moments. they can’t even brag to their friends that they did it because it is back to normal so quickly. One of my favorite methods of securing content and applications is to have the actual content and the application data inside the LAN. The server can sit in the DMZ, but we can use the features of IIS to redirect requests for content and data back through the inside firewall to internal servers. Even if the IIS server is somehow compromised, they still don’t have access to the data in many cases.

Security really isn’t that difficult to implement. I think the key is to keep the basic security concepts in mind when designing your IIS 6.0 solution. Don’t allow more access than is required to view the content or run the applications. Don’t allow developers any access to the production box. After all, they are supposed to develop in a development environment, test in a test environment and then turn it over to the systems engineer to deploy the final solution in a production environment. Keep in mind the many different levels of security available to you. Watch the site constantly (or monitor it using good products) and be prepared to repair as necessary. Work closely with the others involved such as the network team and the end users to make sure we do everything we can to keep the solution secure.

By the way, I didn’t even talk about SSL yet.

Stay tuned, there is more to follow on this subject as I flesh it out. I need to do this soon as I am supposed to present a session on IIS 6.0 Security at TechMentor in Orlando this April.