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.