|
Protecting Your IIS Server and Web ApplicationOriginally Published October 2001 After the recent destruction of IIS based Web sites by the CodeRed and NIMBDA viruses, insuring security for Web applications has become everyone's job. This article gives a plan for recovering from virus attacks, securing the server and protecting from further attacks. It points the user directly resources that can speed the process. The outline of the plan is:
Throughout the article, I'll refer to various files that you can download from Microsoft. Since NIMBA, Microsoft has become more serious about security. They've instituted a new security program called the Strategic Technology Protection Program (STPP). It includes free technical support to recover from a virus attack and the Microsoft Security Toolkit. The toolkit is a collection of system upgrade files and protection tools including the tools discussed in this article. They also provide a blueprint for recovery and protection. Start at http://www.microsoft.com/security. I've ordered the CD and it's on backorder. It may be available by the time you read this. However you get the files, by CD or download, let's get started. Recover from Infection or RebuildIf you have an infected IIS Server, the first step is to pick between recovery and rebuilding. Recovery involves cleaning viruses from your system and repairing any damage. Rebuilding means starting from scratch using trusted media. Recovery is not insured and various authoritative sources (CERT, Microsoft, Symantec) recommend that servers that have been exposed to the public Internet be rebuilt from scratch. Yikes! They mean well but they don't have to do the work. Rebuilding isn't fun but it gives the best insurance that you’re not leaving problems on your system. In some cases, enough files in the operating system have been destroyed that rebuilding is the only course of action. I’ve done both a recovery and a rebuild and both seem to have worked. If you want to be safe, rebuild.
Assuming you decide to recover your the first step in protecting your system is to remove any infection. During this step clean the system of viruses and take some steps to preventing instant reinfection. These steps should be performed:
Whether you've cleaned your infection or rebuilt your system from scratch, you can proceed safely. Install Operating System Upgrades and PatchesThe best way to upgrade is by using Windows Update from the IE Tools menu. Be prepared for some long downloads and to reboot often. I suggest the following sequence of upgrades:
Verify that the System is Up to Date Once you’ve used Windows Update to install the critical fixes, verify that you’re up to date. While you can use Windows Update every day, there's a better tool: Network Security Hotfix Checker aka hfixchk.exe. Download it by starting at: http://support.microsoft.com/support/kb/articles/q303/2/15.asp Hfixchk.exe checks that you’ve installed available hot fixes for NT or W2K, IIS and IE. It can be used to check all the computers in a domain, a subject that is beyond the scope of this article. Run IE's Windows Update until hFixchk.exe shows that, “All necessary hot fixes have been applied.” Unfortunately, on NT 4 Server it isn't possible get hfixchk to report that are patches installed. Even after the latest critical update packages have been installed, the HFixChk continues to report specific patches that have not been applied. These have to be checked by hand. The following bullets may help you with the details of some of these hot fixes. The bulletins can be read at: http://www.microsoft.com/technet/security/bulletin/MSYY-XXX.asp Where YY-XXX is the year and number of the Bulletin.
Protect the system from Other Attacks, Old and NewURLScan: Don't leave home without it!This is a powerful tool for protecting your IIS. It examines every HTTP request before it is handed to IIS, which normally responds by returning the requested HTML file or running the requested ASP page. Before a request is allowed through to IIS, URLScan checks it for: · Malformed URLs such as binary data in the URL. · Attempts to run restricted file extensions such as EXE, HTA, IDA, etc. · Restricted HTTP Request types. Only GET, POST AND HEAD are needed by most sites. The default settings allow most HTML and ASP based applications to run without problems. Get URLScan at: http://www.microsoft.com/technet/security/urlscan.asp. Configuration is done using an INI file. Figure 1 shows how URLScan blocked a typical series of attacks from a NIMBDA infected system somewhere on the Internet. The IP addresses have been XXXed out for security reasons. There are plenty of infected computers out there on the net and I see a sequence like this every day. Figure 1 [Tue, Oct 09 2001 - 12:05:32] Client at XXX.XXX.XXX.XXX: Sent verb 'OPTIONS', which is not specifically allowed. Request will be rejected. [Wed, Oct 10 2001 - 11:08:53] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected. Raw URL='/download/win32/en/ie5setup.exe' [Thu, Oct 11 2001 - 09:53:58] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected. Raw URL='/scripts/root.exe' [Thu, Oct 11 2001 - 09:53:58] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected. Raw URL='/MSADC/root.exe' [Thu, Oct 11 2001 - 09:53:59] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected. Raw URL='/c/winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:01] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected. Raw URL='/d/winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:03] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected. Raw URL='/scripts/..%255c../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:04] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected. Raw URL='/_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:08] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected. Raw URL='/_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:09] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected. Raw URL='/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:09] Client at XXX.XXX.XXX.XXX: URL contains '.' in the path. Request will be rejected. Raw URL='/scripts/..%c1%1c../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:13] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected. Raw URL='/scripts/..%c0%2f../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:14] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected. Raw URL='/scripts/..%c0%af../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:18] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected. Raw URL='/scripts/..%c1%9c../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:19] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected. Raw URL='/scripts/..%%35%63../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:23] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected. Raw URL='/scripts/..%%35c../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:26] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected. Raw URL='/scripts/..%25%35%63../winnt/system32/cmd.exe' [Thu, Oct 11 2001 - 09:54:29] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected. Raw URL='/scripts/..%252f../winnt/system32/cmd.exe' Install LockDownIISLockDownIIS uses the existing facilities of NT and IIS to protect it from CodeRed, NIMBDA and other attacks, known and unknown. It does this by applying available security settings and installing a 404.dll file to protect from undesirable hits. Get it at http://www.microsoft.com/technet/security/tools/locktool.asp When run on Windows NT 4, LockDownIIS depends on the InetPub tree residing on a NTFS volume, so you haven't already converted to NTFS, start by converting all volumes on your system to NTFS. LockDownIIS is a rather blunt tool. If allowed to, it turns off everything dangerous. That includes all the useful stuff Microsoft has added to IIS over the last six years. Unless you're using just plain HTML pages, use the Custom Installation option and keep features that your application uses. For example, if you're using ASP pages in your site, be sure to allow ASP pages to be run. Many of the protections implemented by LockDownIIS overlap with those of URLScan, but there’s no harm in that. IIS Security Check ListMicrosoft provides an extensive security checklist that it recommends for sites that are exposed to the public Internet. It took about 6 hours to perform the 50-step list for IIS 4, test that the application still worked, and adjust the settings to allow the application to function. URLScan and LockDownIIS, referenced above, implement many of the steps, so you should run them first. However, many steps secure NT and IIS in additional ways, such as protecting individual registry keys. Having done it once, and given what I know of IIS attacks, I’m pretty sure that implementing the check list would have protected IIS from the CodeRed and NIMBDA viruses. Due to the number of steps, I can’t give step-by-step instructions here. Using the checklist requires knowledge of your server and your web applications. Some of my notes from the installation process are:
You can find the security checklist for your OS by following links from http://support.microsoft.com/support/kb/articles/Q282/0/60.asp Install a Firewall and set narrow rulesA properly configured firewall offers an enormous degree of protection from attacks against your IIS. It should be configured to allow access only to ports 80 (HTTP) and, if you are using it, port 443 (HTTPS aka SSL). Doing so blocks ICMP traffic, such as PING that is frequently used in attacks. As with TCP/IP filtering mentioned above, be sure to allow any legitimate traffic on other ports. If you're running an Extranet used by a limited number of business partners, consider restricting access to the IP address ranges of just those partners. Be sure to create rules to allow traffic to the backup servers. MonitoringVirus attacks and downed servers get attention and everyone knows that you have to fix them and protect from future attacks. Now comes the hard part: monitoring your server. It's hard because someone has to do it every day. Not every week. Every day. Anything less leaves gaps in coverage that are just to long. NIMBDA spread across the world in less than 24 hours. As you monitor you're going to look for unusual activity. What's unusual? To know what's unusual, you have to know what is usual. To know what's is usual you have to establish a baseline. I'll discuss creating your base line in each of the detail sections that follow. Virus CheckStart by checking to see if any viruses have been found in the last 24 hours. In addition to running the real-time virus protection, I schedule a complete virus scan every night around 1AM when system usage is low. For good measure, I run my virus scanner's update program to check for new virus definitions fifteen minutes before starting the scan. Your baseline for viruses is zero. There should be no viruses found. NT Event LogsAll three logs should be checked.
Is your System Software up to date?Not only is the world supplied with an abundance of hackers, it's also has an abundance of security consultants hunting for new vulnerabilities and publicizing them. Microsoft has been keeping up with new vulnerabilities by issuing a stream of Hot Fixes to Windows, IIS, IE and Office. You can't wait for a service pack to come out. There have been 52 security bulletins with fixes so far in 2001 with out a service pack. Recently Microsoft has also made an effort to get the security consultants to stop publicizing new vulnerabilities. As discussed above, there are two tools available for checking updates on a server:
Pick one or the other or both to do your daily monitoring. With Network Security Hotfix checker your baseline is the list of Bulletins that are reported as necessary but that you've determined are not needed, or don't show up as handled because their solution is manual. On Windows 2000, this list is usually nothing. On NT 4 Server, I always seem to have eight of these. To be able to monitor this every day, create a baseline report using the command line: hfixchk > HotFixBaseLine.log. Next, create a CMD file with these two lines: hfixchk > TodaysHotFix.log fc /L HotFixBaseLine.Log TodaysHotFix.Log Point a shortcut to the CMD file, run it, and you'll know in a few seconds if you're up-to-date. You'll have to update HotFixBaseLine.Log after any updates are applied. When using IE's Windows Update I always install everything in the Critical Update category and most things in the Recommended category. If you don't install them, they continue to show up in their respective list. The list can be customized so you aren't reminded to install support for the Hungarian language, etc. URLScan Log Check, Web Log CheckThese two logs go together because they're reporting on the same traffic, your HTTP hits to your web server. Start with URLScan. If a request is blocked by URLScan, it never gets to the web server. My baseline for URLScan entries is 15 entries for the day. URLScan adds all new entries to the end of one file URLSCAN.LOG. You have to open it up and jump down to the bottom to see the new entries. IIS logs every web request to a log file that you can configure using Internet Services Manager. Set it to create a new log file every day. A simple but effective baseline is the number of kilobytes in the log. Either a spike or a trough in the size of this file would be a signal for concern. Read the IIS log to get an idea about what's happening in your application and how your users use it. Some things to look for are application errors and visits to a login page without successful login. In the IIS log will be the probes by the bots, spiders, crawlers, and other programs trying to index the entire web. This type of probe is important for your site to show up in search engines and you may want to encourage it. On the other hand, if your application isn't open to the public you might want to discourage it entirely. Web indexing programs query a file named robots.txt in the root directory of your site. This is based on the Robot Exclusion Standard. Using robots.txt they can be directed to the files you want indexed. To turn off all indexing, put the following two lines into your robots.txt file: # Discourage all web indexing User-agent: * Disallow: / A through explanation of the robots.txt file can be found at http://www.robotstxt.org/wc/exclusion.html#robotstxt Another good explanation is available from: http://www.google.com/bot.html Performance Monitor AlertsNT's PerfMon and Windows 2000 can be set to create a log of activity instead of showing the current activity on the screen. By continuously gathering statistics about a system, unusual activity can be spotted. Alerts can also be configured and these alerts directed to the Event Log. This limits the need to examine the log every day. Just look in the Event Log. Start by logging processor usage, ASP, IIS and IP activity. You'll need to establish a baseline for your system before adding alerts. Once you're familiar with what's usual, add alerts that spot the unusual. Figures 2 and 3 show how alerts look in PerfMon and in the NT Event Viewer. These CPU alerts correspond to the nightly virus scans on that system. If IIS is compromised by a CodeRed type virus, its CPU usage shoots to the sky as your server is used to attack other systems. Figure 2
Figure 3
Database Log filesThis one is going to depend on the capabilities of your Database. For SQL Server 2000 all logins/logouts can be audited in the system log files. If you want to go even further, you can create a baseline using the Profiler to record all Audit events into a table that can be used later for comparison to a running system.
Even more important! Check that your database backups are performed as scheduled and that the database can be restored from the backup. Stay InformedReal-time security notificationsTo keep up to date with the most important developments in Internet security, subscribe to two mailing lists:
Web Resources Start with Microsoft’s site: http://www.microsoft.com/security There’s a good article about the top vulnerabilities of IIS web servers in http://www.infosecuritymag.com/articles/september01/features_IIS_security.shtml The site http://searchwebmanagement.techtarget.com/ has plenty of useful IIS administration information. Another one is http://www.iisfaq.com/ . In particular, http://www.iisfaq.com/Articles/339/ has extensive information and links about CodeRed and it’s variants. More Security information including the list of Top 20 Internet security holes can be found at http://www.sans.org/ I also get great explanations about how various attacks are performed and free tools to investigate security issues at Gibson Research's site: http://www.grc.com BooksDesigning Secure Web-Based Applications for Microsoft Windows 2000 By Michael Howard with Marc Levy and Richard Waymire. Published by Microsoft Press in 2000. ISBN 0-7356-0995-0 Hacking Exposed: Network Security Secrets & Solutions Second Edition by Joel Scambray, Stuart McClure and George Kurtz. Published by Osborne/McGraw-Hill in 2001. ISBN 0-07-212748-1 ConclusionAre you exhausted yet? I'm wearing out and I haven't even touched the subject of writing a secure application! That's a topic for another article some day. In the mean time I monitor my systems every morning, continue to read about security topics, and work to improve the security of my applications in every way possible. Unless the application developers and network administrators of the world are vigilant about security, the terrorists of the Internet will destroy the Internet's potential for improved productivity, convenient commerce, knowledge sharing and just plain fun. I for one don't want that to happen.
|
|
