Controlling the Process Identity
One of the cardinal rules of server security is that all processes have a security context, which means that every program running on the server runs as an entity. That entity might be the logged-on user or a built-in account (e.g., System), but every process has an identity. As a security-conscious IIS administrator, you should always know the identity of the process that hosts your Web application. Table 1 provides details about the IIS process model and associated identities.
A hacker can use several methods to gain access to the process identity. A buffer-overflow attack on your application or Web server might provide the attacker with the security context of the process identity. Another method takes advantage of the RevertToSelf function that an executable can call. If the hacker can invoke such an executable, the application will then run as the process identity. Note in Table 1 that in Internet Information Services (IIS) 5.0 and Internet Information Server (IIS) 4.0, Inetinfo runs as the System account. Consequently, from a security perspective, you should avoid running applications "in process" (i.e., running in the Inetinfo process as much as possible). In IIS 6.0, Web applications don't run with the System identity unless you explicitly configure them to do so or you've configured the server to run in IIS 5.0 mode.
As an administrator, you can't prevent a program from using the process identity, but you can inspect a binary to determine whether it calls RevertToSelf. To inspect an executable, you can use the DumpBin utility, which comes with most development languages. Use the following command:
dumpbin /imports executable name | find "RevertToSelf"
For more information about validating executable content, see the Secure Internet Information Services 5 Checklist.
Port Filtering
Although the subject of port filtering is beyond the scope of this article, you need to be aware of some basics. For example, the only port that IIS requires to function is port 80—anything else is for additional functionality. You'll likely require TCP port 443 for Secure Sockets Layer (SSL) security, TCP/UDP port 53 for DNS, TCP port 25 for SMTP, and possibly other ports to support your business needs. You should allow communications only for services that you require and never expose the Microsoft networking ports (TCP/UDP ports 137, 138, 139, and 445) to an untrusted network. The networking ports, in particular, and the related services that use them provide a veritable cornucopia of attack surfaces. When you're configuring IIS, I suggest that you start with port 80 and a determined attitude that you won't open any other ports unless you have a bona fide business reason to do so. Of course, many sites rely on firewalls for port filtering, but I prefer to configure IIS servers in the demilitarized zone (DMZ) as if a hacker had penetrated the firewall. Host-based defense, as it's sometimes called, is an important layer in an in-depth security strategy.
My favorite tool for port filtering is the IP Security (IPSec) utility—it works well, it's free, and you can run it from a command line. IPSec's main purpose isn't port filtering but rather creating point-to-point mutually authenticated and encrypted connections. For example, let's say you create an IPSec connection between IIS and an Internet Security and Acceleration (ISA) Server 2000 firewall and create anther connection from the ISA Server 2000 firewall to a Microsoft SQL Server system. You can configure these connections to mutually authenticate with certificates and encrypt all traffic. If a hacker gains access to a computer in the DMZ, the hacker won't be able to contact the SQL Server machine, which requires that a certificate stored on the IIS server be set to the SQL Server machine from the IIS servers' IP address and won't be able to sniff the encrypted traffic. IPSec provides strong protection, and I recommend that you check it out.
IPSec can also implement state-aware port filtering. For example, if your IIS server address is 1.1.1.1 and that server connects to your SQL Server machine on 1.1.1.2, you can configure 1.1.1.1 to talk only to 1.1.1.2 and use only port 1433—for more details, see the Microsoft article "INF: TCP Ports Needed for Communication to SQL Server Through a Firewall" (http://support.microsoft.com/?kbid=287932). Similarly, you can configure the IIS public IP address to use only port 80 and any other required ports. IPSec is smart enough to allow outbound connections in response to requests on port 80. IPSec also lets you block port 80 outbound traffic so that you can't use Microsoft Internet Explorer (IE) to browse from the IIS server, a common security precaution.
Although the IPSec user interface requires some study, the Microsoft article "Building and Configuring More Secure Web Sites" (http://msdn.microsoft.com/
library/en-us/dnnetsec/html/openhack.asp) provides a detailed description. Joel Scambray and Stuart McClure also provide a good explanation of the benefits of using IPSec with IIS in their book Hacking Exposed Windows 2000 (McGraw-Hill Osborne, 2001).
Prev. page
1
[2]
3
next page 
