| Introduction If you host a Web site, you've most likely run into situations where someone attempted to modify your site, force it to crash, or tried to access unauthorized pages. One of the most effective ways of dealing with these situations is to log them and then block hackers' access by preventing their IP addresses from passing through your company's firewall. However, while I've always been a strong advocate of firewall security, Internet Information Services (IIS) 5.0 has its own built-in security measures for weeding out undesirables. This article will discuss ways to control access through IIS. IP Packet Filtering When someone attempts to access an IIS server, the first security check that IIS performs is an IP filter check (assuming that the user has already passed through the firewall successfully). The IP filter is designed to allow or deny access to the IIS server based on IP address or domain name. To configure IP packet filtering, open the Internet Information Services console and navigate through the console tree to the Web site that you want to control access to. Next, right click on the Web site and select the Properties command from the resulting context menu. When you do, you'll see the Web site's properties sheet. Next, select the properties sheet's Directory Security tab and click the Edit button in the tab's IP Address and Domain Name Restrictions section. When you do, you'll see the IP Address and Domain Name Restrictions dialog box shown in Figure A 
Figure A
As you can see in the figure, if you choose to use IP filtering, you must either grant or deny access to everyone and then create exceptions to the grant or denial. For example, suppose that you had a confidential Web site that you wanted to make sure that no one had access to unless they were employees of a few carefully selected companies. In a case like this, you'd deny access to everyone and then list the domain names of the privileged few companies in the exceptions list. On the other hand, if you had a public Web site, you would normally grant access to everyone and then use the exceptions list to deny access to individuals or domains that you consider to be a threat. The possibilities here are endless. For example, I recently saw one company (who shall remain nameless) that used IP filtering to make sure that one of their competitors couldn't access their Web site. Normally, unless you want to block access to an entire domain, you're better off blocking access to individual IP addresses. For example, if a hack attempt came from the address 147.100.100.99 (this is a fictitious address), then you'd probably want to block this address rather than blocking the hacker's entire domain. Unfortunately, there's one big issue to consider when blocking an individual IP address. If someone accesses your Web site from a corporate network, then there's a really good chance that the IP address that they're using isn't their own IP address, but rather the IP address of a proxy server at their company. Blocking a proxy server's IP address denies access to anyone who might be passing through that proxy server to access your Web site. Therefore, blocking access to a proxy server's IP address has a similar effect to blocking the company's entire domain (unless the company uses multiple proxy servers). The other thing that you need to consider when blocking IP addresses is that if the hacker is using dial up access to the Internet, then they will almost always be using a dynamic IP address. This means that the next time that they access the Internet, their IP address will have likely changed and your block will be completely ineffective. If the person that you're trying to block is using a cable modem or a DSL connection, then they are probably still using a dynamic IP address. However, the IP addresses that are associated with these types of broadband connections tend to be semipermanent. Many ISPs allow broadband customers to continuously renew the lease on their IP addresses for as long as the connection exists. If the connection is dropped or the user reboots, then the user runs the risk of getting a different IP address. However, for all practical purposes, blocking the IP address of someone who's using this type of connection tends to be effective, at least for a while. As you can see, filtering based on IP address doesn't always work the way that you want it to. Factors such as proxy servers and dynamic IP addresses can really complicate things. Even if everyone in the world had a static IP address, there are still reasons why IP address filtering wouldn't be completely effective. For example, once blocked, a hacker could spoof someone else's IP address or just borrow a friend's computer. My point is that IP address filtering is good as a first line of defense, but it shouldn't be your only line of defense. Fortunately, there are several additional security barriers that you can configure to prevent unauthorized access to your Web server.
Is the User Permitted? Assuming that IIS has been configured to allow the IP address that the user is attempting to connect from, Windows 2000 and IIS begin checking a number of other criteria. The next item on the checklist is user access control. User access control involves checking to see if the user in question has supplied a valid username and password. Of course the majority of Web sites don't require the user to enter a username or password, and rely on anonymous authentication instead. The only real difference between standard authentication and anonymous authentication is that standard authentication requires a user to enter a username and password. Anonymous authentication doesn't require the user to enter any sort of login credentials, but instead uses a username and password that has been supplied by the system. You can view the anonymous logon credentials by opening the Internet Services Manager and right clicking on the Web site that you want to control access to. Next, select the Properties command from the context menu. When the Web site's Properties sheet appears, select the Directory Security tab. Finally, click the Edit button in the Anonymous Access and Authentication Control section of the Directory Security tab. Doing so will reveal the Authentication Methods dialog box that allows you to enable or disable anonymous access and control which username and password should be associated with anonymous access. Once a user has entered their login credentials, Windows confirms the password and then checks to make sure that the login is permitted. Some examples of situations in which a correct username and password is entered, but the login isn't permitted would be cases in which the password has expired, it's outside the permitted time of day, or the account has been disabled or locked out. In addition to the criteria that I just mentioned, Windows also checks to make sure that the user has access to the server via the Logon Locally or the Access This Computer From The Network permission. Normally, only members of the Administrators group have permission to Logon Locally. However, according to the Internet Information Services 5.0 Resource Guide, if WWW basic authentication or FTP is used, then IIS attempts to log the user on locally. Therefore, if you're having trouble getting users authenticated, you might check the Logon Locally permission.
IIS Access So far in the validation process, IIS has screened the IP address and domain name. Windows has then validated the username, password, and login criteria. The next step in the process is for IIS to implement its own access control. The basic premise behind IIS access control is that it controls what a user is able to do once they reach the Web site in question. For example, if your Web site used the WWW service, you could assign the Read, Write, Execute, or Script Action permissions to a user. For example, if you wanted visitors to your site to be able to view content, but not to make modifications, you could assign the Read permission and nothing else.
NTFS Access The final part of the access-control process is the NT File System (NTFS) permissions. Remember that IIS 5.0 rides on top of Windows 2000 Server and is therefore subjected to any access-control rules imposed by Windows. For example, suppose for a moment that IIS was configured to allow anyone, including anonymous logins, to have full Read and Write permissions to the Web site. Now suppose that the directory that contained the Web site existed on an NTFS partition and that the NTFS permissions were set to give everyone Read access, but to only give Write access to administrators. When IIS and NTFS permissions contradict, the NTFS permissions are considered to be authoritative and are therefore the permissions that are used. In this particular case, it would mean that regardless of how IIS was configured, only the administrators would have Write access to the directory containing the Web site. The fact that NTFS permissions override IIS permissions begs the question of why you should even bother setting IIS permissions. Keep in mind that while theoretically, NTFS permissions could be used to solely control access to your Web site, IIS intends for the NTFS permissions to be the last line of defense, not the only line of defense. Many hacker utilities exist that can foil NTFS security. Therefore, if NTFS is your only line of defense and a hacker decides to use one of these utilities against your Web site, your entire site can quickly be compromised. There's no surefire way to keep hackers from tampering with your Web server, but using all of the available security mechanisms is a big step in the right direction. While it's true that any of the security mechanisms that I've talked about can be beaten, the more security mechanisms that you use, the tougher a hacker's job will be. Most casual hackers will move on to an easier target if they think that your Web server will be too much work to break into. Obviously, there are some hackers that aren't deterred by a little hard work, but the harder that a hacker has to work, the longer a hack will take, and the longer that the hack takes, the better your chances are of catching the hack in progress and being able to do something about it.
Conclusion As you can see, IP filtering is a great tool for keeping known hackers at bay. However, IP filtering by itself isn't enough. Instead, of relying solely on IP filtering, you should make use of the other access-control mechanisms.
About the Author Brien Posey is the executive vice president of research at Relevant Technologies, Inc. Brien is an MCSE and a renowned technology journalist. He was recently voted the most popular server author on CNET's TechProGuild portal. Brien can be reached at brien@brienposey.com. Due to the high volume of messages that Brien receives, it's impossible for him to respond to all of them, although he does read them all.
|
