Are you the master of network security in your company or a candidate of Murphy's Law? Is your network the destination...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
address of ongoing security or a parking lot for a hacker convention? If your security is configured the wrong way, expect hackers to experiment with your network and Mr. Murphy to pay you a visit and test your "human acceleration tolerance."
We continue our three-part series on protecting your Web server. In this mini-series, we will focus on Internet Information Services (IIS) 5.0 security. Join me on a journey to continue to explore and identify the security vulnerabilities in your network.
Are you willing to sacrifice some server acceleration for more security? Imagine if you could keep a hacker from defacing your Web site, no matter how hard they tried [period]. It's possible to achieve more network security, while maintaining an acceptable level of server performance, see what I call, "Medina's Read-Only Content" (ROC) approach below.
When was the last time a hacker wrote to a read-only CD-ROM?
Medina's Read-Only Content (ROC) approach
If your Web site consists of mostly static pages and your Web server has a fast DVD or CD-ROM drive, record a CD-ROM with a complete build of your Web site structure. Go to the Home Directory tab to specify the location of your recorded content and then the Documents tab to specify your default document.
For example, to test this, I used Microsoft's Office CD "MSOFFSBE9" and the path:
"d:pfilescommonmssharedwebsrvex04serk1033"with default.htm as document. (Make sure you clear your browser's cache before testing.)
A slightly different approach is to continue using your local drive with a copy of your original Web site files available in your Web server's DVD or CD-ROM drive. Use a file copy program with synchronization and scheduling capabilities to compare your live Web site files (stored on your local drive) with the original files (stored on your CD-ROM).
Schedule file-checks using 5-minute intervals and if necessary, replace any compromised/modified file with its original file version.
If you anticipate content updates on a regular basis, consider either excluding these files from your file checks or updating your original Web site image on a regular basis, which can be used as part of your company's disaster recovery planning. Both approaches can be accomplished without using Windows sharing or IIS Web sharing. If you choose to use the first approach, consider increasing your CD-ROM cache and/or adding additional CD-ROM drives to handle your Web site traffic load, if necessary.
Now that you are familiar with Medina's ROC approach, let's go over some basic steps with a look at Execute Permissions and Application Protection of your default Web site.
Avoid using the "Scripts and Executables" permission for your Web site; make sure that execute permissions is set to "Scripts only" to prevent a hacker from using the execute permission against you.
Avoid using "Medium (Pooled)" for your protection level; make sure that application protection is set to "High (Isolated)" level. This is the highest level of operating system protection against a malfunctioning application.
Are your Web servers mapping unnecessary extensions and caching unwanted DLLs? When was the last time you modified Microsoft's default list of extension mappings and HTTP actions?
Upon installing IIS and a quick view of the Applications Mappings in the Configuration button on the Home Directory tab, you will noticed that "Cache ISAPI applications" is enabled, by default. Below, you will find a list of extensions (that is, DLLs) configured to be pre-loaded to improve the performance of your Web server by caching future page requests (I.E., index.asp.)
The problem with keeping Microsoft's default extension mappings is that DLLs used in extension mappings can potentially circumvent security through an existing or future vulnerability in the Internet Server Application Programming Interface (ISAPI) extension (I.E., msw3prt.dll used by printer extension, accepts input, and allows printing via HTTP.)
Ask yourself if you are:
- Utilizing the minimum extensions required for your Web servers to operate?
- Overlooking a security compromise by not minimizing the use of DLLs?
- Accepting Microsoft's generic values for your production server security?
- Defeating the purpose of improving performance by caching unused DLLs?
Before making modifications to your live network, make sure you have a successful backup of each server and test your changes before updating a live environment.
Consider reviewing the mapping list below, remove unnecessary extensions//DLLs; change the default executable path of DLLs; set the appropriate HTTP actions (avoid your application receiving all requests from users), and minimize the use of script actions (write permission).
Keep in mind, that DLLs defined in the mapping extensions can circumvent security through a bug in Internet Server Application Programming Interface (ISAPI), which can assist a hacker (e.g., unchecked buffer that can lead to local system privileges) with an attack on your server.
|.htw||Used by Index Server||Webhits.dll||GHP|
|.ida||Used by Index Server||idq.dll||GHP|
|.idq||Used by Index Server||idq.dll||GHP|
|.asp||Used by ASP for script handling||asp.dll||GHPT|
|.cer||Used by ASP for certificate request||asp.dll||GHPT|
|.cdx||Used by ASP for index files||asp.dll||GHPT|
|.asa||Used by ASP for example for globa.asa||asp.dll||GHPT|
|.htr||Used by IIS for resetting password||ism.dll||GP|
|.idc||Used by IIS for ODBC connections||httpodbc.dll||OGHPPDT|
|.shtm||Used by IIS for Server-side include||ssinc.dll||GP|
|.shtml||Used by IIS for Server-side include||ssinc.dll||GP|
|.stm||Used by IIS for Server-side include||ssinc.dll||GP|
|.printer||Used by IIS for Web printing||msw3prt.dll||GP|
GHPT = Get, Head, Post, Trace
GP = Get, Post
OGHPPDT = Options, Get, Head, Post, Put, Delete, Trace
Application and process options
Modify and test your IIS session timeout (default 20 minutes) and ASP Script timeout (default 90 seconds) and use realistic values that reflect your Web environment. Disable buffering and parent paths.
Modify and test the number of script engines (default 125), the number of ASP file cached (default 250), and CGI script timeout (default 300 seconds), again to reflect your Web environment. Enable unsuccessful client requests to event log.
Select "Do not cache ASP files" if you are not supporting ASP scripting on your Web server.
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 (www.medinasystems.com) 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 SearchNetworking.com's Ask-the-Expert section. Submit a security question to Luis here or view his previously answered Ask-the-Expert questions.