The Lab Guys Install a Firewall

Much of the pain is gone

Not too long ago, installing a firewall was a painful process requiring arcane technical knowledge. The Windows NT Magazine Lab Guys recently had the opportunity to install a firewall in the Lab. We discovered that although the installation process isn't painless, it has become much easier, particularly if your firewall needs lean toward the basic end of the spectrum.

The Lab network was always part of a larger company network. We were behind a router, which allowed for packet filtering, but we relied on the larger corporate security strategy to protect our network from unwanted intrusion. But recently our corporate network strategies changed, and the old facilities our company used to protect the corporate network were no longer sufficient to provide adequate protection. The company decided to restructure the network, placing more restrictions on incoming traffic. In addition, the company took steps to protect internal systems from attacks by Trojan horse programs. Those strategies are good strategies, but they're too restrictive for some parts of the Lab network. The Lab sometimes must give outside reviewers Internet access to certain systems we're testing. Doing so is counter to the new corporate security policy and understandably worrisome to our MIS department, which is responsible for preventing outsiders from accessing systems within the corporate network.

Arriving at a solution to this problem wasn't difficult. The Lab Guys decided to contract with an ISP for a separate Internet connection so we could grant access that the company policy wouldn't typically allow. We needed to provide some protection for the systems on the separate network, so we went looking for a firewall. We decided to use SonicWALL Plus DMZ from Sonic Systems. You can read a Web-exclusive review of SonicWALL Plus DMZ on the Windows NT Magazine Web site at http://www.winntmag.com.

We chose the SonicWALL firewall because it supports two internal networks: a demilitarized zone (DMZ) for public access and a protected network SonicWALL calls the LAN. Initially, we placed a Web server and our LabCam host on the DMZ zone, and file servers and domain controllers on the LAN segment. Using a pair of 3Com SuperStack II 10Base-T Ethernet switches, we created the two network segments and were ready to install the firewall. Installation was straightforward and relatively simple.

By default, the SonicWALL firewall allows all WAN traffic into the DMZ—and no traffic into the LAN. Because we wanted tighter security in the DMZ, we decided to set up packet-filtering rules to augment SonicWALL's stateful-inspection methods. We began by blocking all WAN traffic to TCP/UDP ports 137, 138, and 139, which NT uses extensively. The SonicWALL firmware predefines several specific protocol/port combinations it uses for packet filtering; additional service definitions are easy to add. After enabling logging to a syslog server, we could monitor the connections we allowed through the SonicWALL firewall and set up services to block additional ports. We let this configuration run for a while, tweaking it for specific access needs.

Blocking specific ports gave us a sense of how the firewall would work without our having to drastically restrict traffic. But a much more robust approach begins by blocking all traffic. Then, when you have an idea of what traffic needs to pass through the firewall, you can punch holes to direct traffic to specific ports on specific systems, and—where appropriate—to allow access to traffic that comes from specific outside systems. The Lab ended up following this strategy: We opened port 80 to Web servers, port 53 to a DNS server, and precious little else.

Although I'm certain this won't be the last time we need to consider security in the Lab, seeing this chapter end on such a positive note was nice. The Lab's experience confirms that network appliances are an attractive security option that confers cost benefits both in purchase price and in ease of installation and maintenance.