One of the hottest topics these days is how to properly secure a Web server. In previous issues of IIS Administrator, I've talked about how to tighten permissions; in the free email newsletter IIS Administrator UPDATE, I've talked about which patches and service packs you need. However, merely keeping your Web server up-to-date on the latest security holes is just part of the picture. The arduous task of securing the entire Web site is more complex. A properly configured firewall can go a long way toward keeping intruders out of your Web site.
Setting up your first firewall takes a commitment from your organization's management and IT department. You can't simply set up a firewall and declare it complete. Like your Web server, a firewall requires maintenance. Canvassing the logs for potential problems will become routine. Depending on how you use your firewall, you might not be able to perform administrative tasks on your Web server remotely. This month, I introduce you to firewalls and tell you about some of the theories behind using them.
How Firewalls Work
A commonly used term on the Internet is gateway. Every TCP/IP-based device on a network has a gateway, whether or not the device uses it. A gateway is a path (i.e., an opportunity) for reaching a different network. You might say that a gateway's basic function is to provide the means for packets to travel or route to another network. If you look at the history of the TCP/IP protocol (and even farther back through the history of the Internet), few people were concerned about intruders. They were more concerned about connecting large networks together. (For a great read about this notion and the troubles in connecting computers during the 1980s without firewalls, see Clifford Stoll, The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage, Pocket Books, 1995.) At that time, people were much more concerned with routing connections, not blocking them.
Setting up a secure firewall in front of your Web site and telling it not to route packets is easy and relatively secure. Similarly, unplugging your Web site from the network is also easy (it's also the most secure method). But firewalls often have more than just two interfaces. Firewalls have an inside network, an outside network, and one or more demilitarized zones (DMZs). Firewalls might also have other networks that connect to routers, VPNs, or other firewalls. They might have an extranet, which is a private network between your intranet and your business partner, customer, or vendor.
Assessing, Mitigating, and Accepting Risk
Firewalls create a (sometimes false) sense of security. Even though firewalls are on the job day in and day out, occasionally malicious users find a bug in the firewall or the OS and are able to exploit it and get past the security. More often, though, the administrator makes a mistake and leaves the server vulnerable. Firewalls are great at filtering packets, but they still can't filter mistakes.
Firewalls can also lure management into a false sense of security. When managers pay for that expensive firewall and software, they expect all security holes to disappear. When a security problem arises, they're on your doorstep asking why that expensive firewall didn't do its job.
You can prevent unrealistic expectations by explaining the risks involved in connecting corporate networks to the Internet. It's your responsibility to properly assess the risk and inform management. You can offer firewalls as a method to assuage part of that risk. Firewalls should be part of the networking strategy design to mitigate the assessed risk, but management must accept the rest of the risk.
Creating the Bastion Host (aka Firewall)
One of the simplest firewall scenarios is to turn your internal network into a fortress and block all packets that attempt to come in. The desired result is to let your users access whatever services they want. Internal hosts must be able to reach the outside external network without restriction while preventing outside hosts from touching assets on the internal network. You accomplish this objective through the use of a bastion host, more commonly known as a firewall.
This simple scenario creates two major potential implementation problems. First, many protocols, such as TCP and UDP, are based on a two-way exchange between hosts. When an internal host initiates a conversation with an external host, the firewall must be smart enough to look for return traffic from the outside host and deliver that traffic back to its originator on the internal network. This dynamic property is crucial to the proper operation of a firewall.
The second potential problem with this scenario is the possibility of allowing all traffic out of the firewall without restriction. Management is often uninterested in setting a policy on acceptable Internet uses, so users push the envelope, turning the lack of a policy into a network free-for-all and running small Internet client programs that host everything from doggie cams to Internet game tournaments. Meanwhile, management wonders why all the available bandwidth has dried up.
A firewall must protect both management and users. When a firewall allows anything and everyone out, it creates the potential for an internal host to be compromised or otherwise "trojaned" (i.e., infected with a Trojan horse program). See the sidebar "AOL's Firewall Woes" for a real-world example. You can use one of two methods to allow outbound traffic, both of which involve the use of a proxy server or some other caching server.
Figures 1 and 2 represent potential scenarios for a firewall. Figure 1 shows that you can have the proxy server and firewall in parallel. This scenario might be valuable if you have a lot of outbound Web traffic and are afraid that it will burden the firewall. Figure 2 represents a more secure solution. Placing the proxy server behind the firewall lets you restrict outbound traffic and protocols to one proxy server. In either case, browsers must go through the proxy server to retrieve their content.
An often-overlooked step in setting up a firewall is hardening the firewall's host machine. If you choose one of the software/OS firewall combinations, it's imperative that you follow the software maker's guidelines for hardening the firewall machine itself. In certain cases, the OS installation is stripped down to the barest essentials. In some cases, even the networking services, such as Workstation and Server services, are stripped out of the installation.
Choosing the Right Firewall for the Task
Many firewalls are on the market today, with a wide variety of pricing options. Options include hardware-based bundles that run on proprietary hardware systems and software based-bundles that run on commercially available OSs. Some versions are free, have little or no support, and are based on the UNIX and Linux platforms; some firewalls are expensive and run only on select OSs, such as Windows NT. Few commercial firewall manufacturers have ported (i.e., converted from one OS to another) their products to Windows 2000 because the OS is so new.
Any serious firewall supports two or more interfaces. In large environments, it's not unusual to see half a dozen or more interfaces on a firewall. Other options add features such as high availability, failover, and redundancy. Some even offer load-balancing features (a difficult feat to accomplish while trying to maintain current connections between multiple firewalls). A firewall could be as simple as running Microsoft Proxy Server 2.0.
Creating a DMZ
Using DMZs to protect Web assets is popular. Unfortunately, many people misunderstand what it takes to run a DMZ. First, let's define the term: A DMZ is a network that sits between the outside external network and the internal network. The DMZ often contains servers that provide services such as HTTP, DNS, and Proxy.
The goal of a DMZ is to provide services to external users but not let users initiate connections from the DMZ back to the inside. This goal also means that you must administer DMZ machines from the console. If you allow remote administration, it's not a true DMZ. (I've allowed such back doors as modems only so I would have a way to shut a Web server down in case someone defaced it, but that's as much as I feel comfortable with.)
You usually create DMZs by installing another NIC in a firewall and assigning an IP subnet to the space. When you've created the network, you can begin laying out rules for the DMZ. As you add servers to the DMZ, allow only the essential ports and services. For example, if you allow only HTTP and HTTP over Secure Sockets Layer (HTTPS) traffic in from the Internet, create a rule that allows only port 80 and port 443 to the rest of the world.
A rule of thumb for deciding what types of servers to place in the DMZ—whether Web servers or database servers—is this: Don't place a server in the DMZ that you don't want to see compromised. I've managed many high-profile Web servers in a DMZ. Not a day has gone by without one or more attempted intrusions.
Setting up Firewall Rules
In addition to not allowing just anything from the internal network to the external, you need to consider other restrictions. Some firewalls require a "drop everything" rule as the last rule in the firewall. This rule is a catch all that prevents any traffic some other rule has not previously defined or handled from passing.
Also consider limiting the types of traffic that can contact the firewall directly. Having the best firewall rules in the world means nothing if someone from the outside can take a firewall-management client, attach to your firewall, and help you configure it. At the very least, you'll expose to the outside world exactly what you're running, which lets the determined intruder work on an exploit to get past the firewall.
Most security administrators advise you not to allow Internet Control Message Protocol (ICMP) traffic behind your firewall. You can set up a rule to disallow ICMP traffic from crossing the firewall. Keep in mind, however, that this rule might prevent your IT staff from using such popular utilities as Ping and Traceroute to troubleshoot network problems.
If you're hiding your proxy or caching server behind the firewall, allow HTTP and HTTPS traffic from the proxy server or caching server only. In any case, don't allow carte blanche access to the Internet from your workstations.
The largest task to accomplish when you're managing a firewall is learning to say "no" to users who want to open a hole in the firewall to let through services or protocols. Opening even one port can lead to trouble. Evaluate each request thoroughly and fairly. If you're suspicious about something, track it down. The biggest mistake a security administrator can make is to assume (incorrectly) that everything is fine. Being paranoid is much better than glossing over a risk. If you've been accustomed to helping users and customers and making things happen, in the role of firewall administrator, you must learn to say "no." Inevitably, you make some people unhappy in this role.
Administering Your Firewall
You'll get a lot of requests to provide services and punch holes in your firewall. You can't avoid that. But with diligence, you can avoid making mistakes. Putting up a firewall goes a long way in securing your site. Unfortunately, it's more than just committing a server. You have to commit yourself to staying on top of vulnerabilities and to keeping up with the firewall. The commitment is a tough one, but you'll sleep a lot better at night knowing that you have a sentry at the gate.
