Well, of course! Who wouldn’t secure their most exposed servers, right? Well, here’s the situation which I’m very sympathetic to since it was my situation for many years. You’ve heard the slogan “do more with less”? Well that applies to people, too. In a typical mid-sized company an IT Admin may be faced with handling environments ranging from Directory, Email, Web, Database, Monitoring, Network equipment, etc, etc. These folks don’t need dozens of 500 page-long books detailing the inner workings of each technology. They need specific quick & dirty real-world guidance on how to get things done.
As promised, here’s my first attempt at helping the overworked IT Pro.
This article will not be all-inclusive of everything you need to know to be secure and highly available. It targets what I feel are the most beneficial things you can do to your IIS servers to achieve better security and availability. It assumes you’re familiar with basic OS and network security and builds from there. If you think I missed something really important, add a comment, this a community blog after all!
Summary:
· Use Security Configuration Wizard and normal process to create a secure web server baseline
· Locate website content on a non-system partition and audit NTFS permissions
· Regular Internal Security Scans & Audits
· Regular Log Analysis
· IIS 6.0
o Use Host Headers on all sites
o Use URL Scan
o If you have logins, enforce SSL site-wide
o Install only needed OS & IIS components
o Enable only needed Web Service Extensions
o Delete Default Web Site and C:\Inetpub
o Restrict use of Anonymous IIS Account
o Enable all IIS & SMTP extended logging properties
o Use custom error messages
· Web Farm
o Automate Website Content Replication
o Automate IIS Metabase replication
o Use a standard name for all IUSR_servername accounts
· General Web Infrastructure Design Considerations
· References
· Tools
Security Configuration Wizard (SCW)
Used in combination with a standard server build and configuration process, the SCW can produce dramatic results in reducing the attack surface and saving administrative time when compared with manual hardening. Additionally, the templates can be saved and used on other systems, rolled-back & deployed via Active Directory GPOs, (note: roll-back feature not available if deployed via GPO). Developing standard security settings is also needed to complete the security picture, such as Password Policies, NTFS security, etc.
Explanation: Security Configuration Wizard (SCW) is a tool for reducing the attack surface of computers running Microsoft® Windows Server™ 2003 with Service Pack 1 (SP1). It determines the minimum functionality required for a server's role or roles, and disables functionality that is not required. Specifically, SCW helps you author and deploy a security policy that:
· Disables unneeded services.
· Blocks unused ports.
· Allows additional address or security restrictions for ports that are left open.
· Prohibits unnecessary Internet Information Services (IIS) Web extensions, if applicable.
· Reduces protocol exposure to server message block (SMB), LAN Manager, and Lightweight Directory Access Protocol (LDAP).
· Defines a high signal-to-noise audit policy.
Website Content
Housing the content files on a non-system partition implies you’ll be pointing your website virtual directories also to this same location. This prevents such things as directory traversals, where an attacker can request system files.
Even more important is auditing the NTFS permissions of the content. This is what ultimately grants and restricts access to files and should be dumped and sent to the website content owners for review regularly.
Security Scanning & Auditing
Regularly scanning and auditing your own systems is a proactive measure to ensure you find any weaknesses before someone else does. It also can help maintain system configuration, user accounts, etc. Generally, you will need to audit the server and the website separately. Auditing the server can be done via MBSA and manual checks or scripts. The website or web application may have unique requirements, consider using a 3rd party vulnerability scanning tool designed for this.
Log Analysis
The idea here is that one is only guessing they’ve not been breached if they don’t regularly audit logs. The most secure way to do this is in real-time so that you don’t miss anything if someone covers their tracks by modifying logs. This can also be accomplished by pointing IIS Logging to a UNC share or other remote repository.
Parsing the logs can be challenging. Here are some examples of what to look for:
· Repeated Failed Logon attempts in a short period of time.
· Many 404 (page not found), 401 or 403 (access denied) errors in IIS Logs.
· Funky requests that are obviously not your website
Here’s a sample of an unsuccessful login to a SharePoint site as Administrator. First the IIS Log entry, then the Windows Event Log.
---------------------------------------------------------------------------------------------------------------------------------------
IIS Log
· 2006-08-09 21:00:46 W3SVC1371773545 IIS01 192.168.1.120 POST /_vti_bin/sitedata.asmx - 47451 - 192.168.1.120 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.42) - - iis01:47451 401 2 2148074254 1918 331 0
· 2006-08-09 21:00:46 W3SVC1371773545 IIS01 192.168.1.120 POST /_vti_bin/sitedata.asmx - 47451 - 192.168.1.120 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.42) - - iis01:47451 401 1 0 1946 382 0
Security Event Log
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 529
Date: 8/9/2006
Time: 1:59:28 PM
User: NT AUTHORITY\SYSTEM
Computer: IIS01
Description:
Logon Failure:
Reason: Unknown user name or bad password
User Name: administrator
Domain: IIS01
Logon Type: 8
Logon Process: Advapi
Authentication Package: Negotiate
Workstation Name: IIS01
Caller User Name: NETWORK SERVICE
Caller Domain: NT AUTHORITY
Caller Logon ID: (0x0,0x3E4)
Caller Process ID: 3372
Transited Services: -
Source Network Address: 192.168.1.120
Source Port: 1048
---------------------------------------------------------------------------------------------------------------------------------------
Host Headers
Host Headers basically tell the website to only respond when the header name is requested. This prevents the website from responding to any name other than the intended URL (i.e., IP scans, localhost spoofs, etc). Create a new Host Header for any and all URLs you want the site to be available from and certainly all registered DNS records that resolve to the web server (i.e. example.com, www.example.com, example.intranet.com, etc.)
This seems to be very commonly overlooked, maybe because the default website has a blank host-header upon install. Remember CodeRed? That nasty worm that propagated through the internet attacking IIS 5’s indexing service? Even you were still unpatched today, 5 years later, I’d bet if you used host headers you would never have been affected. Almost all worms propagate via IP scans and a server properly using host headers will not respond to them. Of course, I’m not at all advocated playing with fire like that, but consider the benefits of this simple measure.
URL Scan
UrlScan version 2.5 is a security tool that restricts the types of HTTP requests that Internet Information Services (IIS) will process. By blocking specific HTTP requests, the URL Scan security tool helps prevent potentially harmful requests from reaching the server. A good approach to this tool is if you know the website’s needed HTTP verbs (GET, POST, etc), just allow those and deny everything else. Same goes for file extensions.
Note: IISLockdown is no longer needed in IIS 6. All of the default security-related configuration settings in IIS 6.0 meet or exceed the security configuration settings made by the IIS Lockdown tool. Therefore, you do not need to run this tool on Web servers running IIS 6.0. However, if you are upgrading from a previous version of IIS, you should run the IIS Lockdown Tool before the upgrade to enhance the security of your Web server.
Enforcing site-wide SSL
Here's a small point I left out but see every day: IIS is using SSL, but it's optional!. Yes, there's a little checkbox that you don't want to miss if you want to ensure usernames, passwords, creditcards, etc are encrypted, check it! (Web Site Properties, Directory Security, Secure Communications, Edit, check Require secure channel (SSL), check Require 128-bit)
Web Content Replication
Automating the replication of the web content itself is that much more important in the case of a load-balanced, multi-tiered web farm. Publishing changes to the web application content across Dev, Test, Staging, and Production offers many opportunities for files and permissions to become out of synch. Automating this process eliminates any doubt that all data is the same, and intended changes are indeed being applied.
This also can allow for self-service publishing to the Production servers by way of allowing developer access to a Dev replication share, and automatically replicating that share to Staging, then Production on scheduled intervals.
IIS Metabase Replication
Replicating the IIS Metabase allows web site administration to be performed on only one server and automatically replicated to all the others. This ensures standard settings are applied uniformly and increases configuration compliance across all systems reducing the opportunity for human error.
Use a standard name for all IUSR_servername accounts
If you’ve enabled Anonymous access, you’re most likely using this account. In a web farm scenario, you can rename all local IIS_machinename accounts to IIS_whatever, change their passwords to be the same, and ACL the website content with the local account. Don’t worry, since the SID on these accounts is the same, if one account gets hosed you can just remove it from the farm and fix it while your site continues running happily.
General Web Infrastructure Design Considerations
Do not put your internet-facing web servers in your corporate Active Directory. Don’t laugh, this is very common. Removing an AD dependency may pose challenges from an infrastructure perspective, but generally speaking web servers should not be members of the corporate AD. If they simply must be in an AD, a separate AD DMZ Forest should be built, or if only authentication is required you may consider ADAM (Active Directory Authentication Mode). The number of ports required to be open from the DMZ to the corporate LAN is a key consideration here, as well as the fact that if a web server is compromised, so is your corporate AD. Because of their internet exposure, web servers should always be contained as much as possible, and not be joined to the corporate domain or use any domain accounts.
Do not use AD accounts to run IIS Anonymous Authentication. This has two problems, one being security and other being availability. If you have 3 load-balanced web servers, but they all use the same domain account you still have a single point of failure, the domain account. If the account is locked out, disabled, deleted, or AD is unavailable, so is the entire web farm. Also, any member of AD has default rights to do basic LDAP queries which potentially exposes your directory to the internet.
Consider real-time monitoring. There are several tools which can be used to monitor in real time account logons, event & IIS logs, server health & performance, etc. This is necessary for critical servers to proactively address issues before they become outages.
Application Pool Settings. The default Worker Process Recycling interval is every 1740 minutes. Is this appropriate? Consider using one Application Pool for each web application and a shared pool for websites with static content. Also, consider using multiple Worker Processes to service the same pool (Web Garden). This way, if one process is busy or hung, others are available to service requests.
Enable Logging Everywhere. It’s better to have logs and not need them than to need logs and not have them. Enable logging for SMTP, full extended properties. Enable all Success & Failure for logon events - Security Settings, Local Policies, Audit Policy.
Disable Internet Explorer. This way admins cannot use IE locally on servers. This also means you no longer have to patch IE monthly, you can patch during planned maintenance cycles. This can be done via either Security Settings, Software Restriction Policies or via a bogus Proxy Server defined in IE Internet Options.
Fingerprinting
Fingerprinting is whereby someone can identify the web server vendor, version, OS, etc. I have a hard time this one. If you’re paranoid you can reduce the ways in which someone can do this, however, even if you’re successful (which is difficult and in some cases impossible), if an attacker cannot identify the web server he’s likely just going to throw all popular exploits for all popular platforms at it, probably starting with IIS or Apache. In my opinion you don’t gain much from this, security though obscurity is not a good plan.
References
