To create IPSec rules for Win2K, you can use the Ipsecpol command-line utility, which is available from Microsoft at http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/ipsecpol-o.asp. For example, to create a rule that allows only inbound traffic on port 80, you'd type
Ipsecpol \\servername —x —w REG —p
"Port80Only" —r "BlockEverything" —n
BLOCK —f 0+*
Ipsecpol \\servername —x —w REG —p
"Port80Only" —r "Allow80" —n PASS 0:80+*::TCP
If you use IPSec port filtering, make sure you read the Microsoft article "IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios" (http://support.microsoft.com/?kbid=811832) to see whether you should add the NoDefaultExempt registry setting on your server. If you don't add this setting and IPSec sees traffic coming from or going to port 88, the server will ignore your filters. This exempted behavior is designed to keep Kerberos working even if you specifically block the Kerberos ports. The registry setting, when present and set to 1, disables this exemption. I recently discovered that applying Win2K Service Pack 4 (SP4) installs this registry setting. For information regarding commonly used ports in Win2K, see the table titled Default Port Assignments for Common Services at http://www.microsoft.com/windows2000/techinfo/reskit/samplechapters/cnfc/cnfc_por_simw.asp.
Disabling WebDAV
Few topics are more confusing than using WebDAV with IIS. WebDAV is an Internet Engineering Task Force (IETF) Request for Comments (RFC) standard (http://www.ietf.org/rfc/rfc2518.txt) that lets you create a client-side Web folder that uses a URL to map to an IIS server. You can then drag content to the folder to publish information on the Web server. Both IIS 6.0 and IIS 5.0 support this functionality.
WebDAV first came into prominent view with Microsoft servers with the release of Win2K. Still, many administrators don't realize WebDAV's potential power and potential risks. Of course, any capability that offers as much functionality as WebDAV is ripe for exploitation. As a result, it's no surprise that numerous security fixes have emerged that involve httpext.dll, the HTTP extensions that implement WebDAV.
My primary complaint about WebDAV, as implemented on Win2K servers, is that it installs by default with IIS, leaving you no way to turn it off in the IIS UI. Although Win2K administrators must live with these shortcomings, Windows Server 2003 administrators who install IIS 6.0 will be glad to know that WebDAV is disabled by default and that you can enable or disable it by using the Web Service Extensions node of the IIS console.
Some confusion surrounds the specific techniques for enabling and disabling WebDAV in Win2K because Microsoft produced three different methods for disabling WebDAV over time, each with its own advantages and disadvantages. Still, Microsoft recommends all three methods in various publications.
Deny Everyone the Execute permission on httpext.dll. To address the first serious WebDAV exploits, Microsoft recommended denying the Execute permission on the httpext.dll file. The IIS Lockdown tool takes this approach to disable WebDAV. However, this approach introduces two concerns. First, you must deny the Execute permission on all servers and make this change when you create a new server. Second, denying the Execute permission doesn't entirely disable WebDAV, as documented in the Microsoft article "Locking Down WebDAV Through ACL Still Allows PUT and DELETE Requests" (http://
support.microsoft.com/?kbid=307934).
Add the DisableWebDAV registry setting. On a Win2K SP2 system or later, you can navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetServices\W3SVC\Parameters registry subkey, add the DisableWebDAV setting, and assign it a value of 1 to disable WebDAV. This is an effective solution, but you must make this change on all your systems.
Use URLScan to block WebDAV verbs. In terms of advanced IIS security, the strongest advice I can give is to implement the URLScan security tool on your IIS servers. This tool does much more than disable WebDAV, so let's take a closer look at URLScan.
Implementing URLScan
URLScan is an Internet Server API (ISAPI) filter that runs on IIS 6.0, IIS 5.0, and IIS 4.0. When you install the IIS Lockdown tool on IIS 5.0 or IIS 4.0, you can optionally install URLScan 2.0. However, I suggest that you update to version 2.5, which adds some capability. You can download various versions of URLScan from the Microsoft Web site. By the time you read this, Microsoft should have released the URLScan installer for IIS 6.0. You have less reason to use URLScan on IIS 6.0 because IIS 6.0 includes most of the protection that the utility offers.
URLScan compares the incoming URL with rules that you configure in urlscan.ini (located with the urlscan.dll in \%systemroot%\system32\inetsrv\urlscan) and allows or rejects the request according to those rules. For example, you can configure URLScan to allow only requests for files that end with file extensions that you specify. Such a simple rule would defeat many of the most famous IIS exploits.
You can also configure URLScan to reject all requests that contain certain HTTP headers, such as the WebDAV headers in the following urlscan.ini file segment (thanks to Mark Burnett for his enhancements to this list):
[DenyHeaders]
Translate:
DAV:
Depth:
Destination:
If:
Label:
Lock-Token:
Overwrite:
TimeOut:
TimeType:
DAVTimeOutVal:
Other:
URLScan can also deny URLs that
- contain high-order characters
- contain designated characters or character strings
- exceed a specific length
- contain client headers that exceed a specific length
- contain specific HTTP verbs
You can use URLScan to log all rejected requests to a log file, then parse the log with Log Parser Tool 2.0, which is available at http://www.microsoft.com/downloads, or Log Parser Tool 2.1, which comes with the Microsoft Windows Server 2003 Resource Kit; send all rejected requests to a custom .asp page for processing; accept requests but log specific events as if they were rejected requests; and remove or change the server banner that IIS sends to the client.
Regarding URLScan's ability to deny URLs that exceed a specific length, most IIS URLs are short when compared to the length of a URL required to successfully cause a buffer overflow. By studying the length of the URLs required for your Web sites and enforcing a URLScan rule that rejects all requests that exceed your requirements, you're substantially increasing the security of your server. This one rule can prevent many attacks because you're forcing the hacker to come up with a URL that meets certain requirements (e.g., ending with a particular file extension; containing only specified HTTP verbs; not containing components such as high-order bits, extra dots, or slashes; being less than 400 characters in length).
The list of URLScan's capabilities is impressive for a binary with such a small footprint, no known vulnerabilities, and a negligible effect on performance. Remember that aside from changing the server banner (and the potential effect on applications that rely on the banner), URLScan only rejects requests to the server—the utility doesn't interfere with your applications or suddenly cause your Web server to become unstable. You can easily remove URLScan or place it into monitor mode, which causes URLScan to record but not enforce rejections.
Defense, Defense, Defense
When you're defending your Web servers against would-be hackers, it's essential to understand process identity so that you know how your applications interact with your NTFS permissions. Port filtering at your firewalls is also crucial, but you can use IPSec to implement host-based defense in the event your firewall is misconfigured, breached, or another server in the DMZ is compromised. Also, controlling WebDAV access to your servers is important, and URLScan lets you configure rules to help lock down IIS. Of all these suggestions, implementing URLScan and restricting the length of the URL are the most useful defensive measures you can implement. With all these tools to work with, hackers are shifting their attacks from the Web server toward the applications they deliver—but that's another story.
End of Article
Prev. page
1
2
[3]
next page -->
