Poor Man's Firewall

You can never be too careful about Internet security. The number of sophisticated hacking tools available on the Internet these days is amazing (and sometimes frightening). For the most part, using these tools doesn't require much expertise in protocols and operating systems (OSs). This situation contrasts with the hacking environment of the late 1970s and early 1980s, when hackers needed a deep understanding of an OS to compromise it. Then, hackers wrote their own tools. Today, a 12-year-old can find the source code or executables for NewTear (Bonk), Teardrop, GetAdmin, and other Windows NT-based hacking tools and use those tools to wreak havoc on NT servers.

Because of this reality, viewing the Internet with a bit of trepidation is healthy for businesses, especially businesses that are considering plugging their corporate network in to it. When your company connects to the Internet, you must decide how to secure your network from intruders.

Most companies use a firewall, a device that sits between your internal network and the Internet and monitors communications between the two. A properly configured commercial firewall package is the best solution most organizations can choose to secure their network's Internet connection. When I consult with clients who want to connect their networks to the Internet, I always recommend a firewall first.

However, commercial firewalls cost more than some companies can justify spending. If you can't justify paying for a full-blown firewall, you can use Microsoft's Routing and Remote Access Service (RRAS­formerly Steelhead) to make your network more secure than it would be if it had no security mechanism in place. (For more information about RRAS, see "Related Articles in Windows NT Magazine.")

The Mantra of Internet Security The most important principle to keep in mind when you consider Internet security is that you must minimize unsolicited inbound connections. Repeat Minimize unsolicited inbound connections to yourself daily; this phrase needs to be your mantra. You must allow some inbound connections, such as incoming email or responses to your users' Web page requests. But you want to keep out every other connection.

If you use an NT server as an Internet router, you can use RRAS as a packet filter for your internal network to keep out unwanted connections. Packet filtering is a basic firewall capability that lets you control which packets pass through your network interfaces. Packet filtering limits access to your NICs to packets with certain characteristics. RRAS lets you configure filters to allow or deny packets entry to your network based on the packets' source IP address or network, target IP address or network, protocol, or source or destination port. You can combine these criteria to tightly control what type of traffic passes through your router.

As an example, I'll build a set of rules that let internal users browse external Web sites but that restrict external users from browsing internal Web sites. To do this, I need to let users send Web site requests to external servers and let those servers' responses into my network. For my example, I'll use a nonroutable 10.x.x.x network as my internal network, as Figure 1 depicts, and I'll assume that all other IP addresses are external.

Installing RRAS Before you install RRAS, you must set up an NT server as an Internet router. This process is complex. For a good walk-through of the process, see Mark Minasi, "Steelhead Swims into the Mainstream," August 1997. The only difference between the router setup in my example and the router setup in the Minasi article is the computers' Internet connection. The Minasi article discusses setting up an NT machine to route Internet traffic via a dial-up modem. The router in my example is a PC with two NICs. One NIC connects to the internal network, and the other connects directly to an Internet Web server.

After you set up an NT server to route your Internet traffic, you're ready to install RRAS on your system. If you don't already have Service Pack 3 (SP3) installed, install it. Then, download the RRAS installation executable MPRI386 (for Intel CPUs) or MPRALPHA (for Alphas) from http://www.microsoft.com/communications. Run the installation routine, and when RRAS Setup prompts you to select components to install, select the LAN routing option, as Screen 1 shows.

After you install RRAS, launch the Routing and RAS Admin program from the Start menu. Select Programs, Administrative Tools, then Start Router. Starting Routing and RAS Admin enables RRAS functionality on your system. To configure RRAS to start automatically in the future, select Control Panel, Services; double-click the Routing and Remote Access service; and select the Automatic option button.

Configuring Filtering When Routing and RAS Admin opens, you'll see a window with two panes, as Screen 2 shows. Click the IP Routing folder in the left pane to expand it (double-click the folder if necessary). Select the folder's Summary item. Routing and RAS Admin will list each of your LAN adapters in the right pane.

While you have Summary selected, select Configure IP Parameters from the Actions drop-down menu. (The Actions menu is context-sensitive; its options vary depending on which item you select.) In the IP Configuration dialog box that appears, select the Enable packet-filtering check box, as Screen 3 shows.

For my example, I first need to configure my internal NIC to let devices within my network communicate with Web servers on the Internet. In Routing and RAS Admin's right pane, I select my routing server's internal NIC. I right-click the card and select Configure Interface. Routing and RAS Admin opens an IP Configuration dialog box for the NIC, as Screen 4 shows. I click Input Filters to create my rule. The IP Packet Filters Configuration dialog box opens. I click Add to open the Add/Edit IP Filter dialog box, which Screen 5, page 174, shows.

In the Add/Edit IP Filter dialog box, I create a filter that lets devices within my 10.x.x.x network (the Source network) communicate with port 80 of any IP address (the entire Internet). I leave the Destination network section of the dialog box empty; the filter will ignore this section's criteria. Because computers can initiate Web requests from any port between 1024 and 65,535, I also leave the Source port field blank. I click OK, then select the Drop all except listed below option button in the IP Packet Filters Configuration dialog box. This option tells the filter I just created to prevent all packets it receives that don't meet the filter's criteria from exiting my network.

This rule limits my internal NIC's outgoing traffic to my users' Web requests, but my external NIC isn't secure. RRAS lets all traffic that arrives at my router into my network. To prevent all external traffic except responses to users' Web requests from entering my network, I need to set up a filter on the external NIC that will serve as a counterpart to the internal NIC's rule.

I right-click the external NIC in Routing and RAS Admin and select Configure Interface. I click Input Filters and create a new filter that drops all packets from any source network to the destination network (10.x.x.x) except those that come from source port 80. Screen 6 shows this filter of incoming traffic.

I also try to establish Web and FTP sessions to the same device on an external network. I know I built my rules correctly because the Web session works but the FTP session doesn't.

Building Custom Packet Filters To develop RRAS filters that let packets other than users' Web requests out of your network and packets other than Web servers' responses into your network, follow the steps I described but configure your filters to permit traffic to and from ports other than port 80. Use Table 1's list of common ports to develop rules for packet filters that suit your company's needs. Then, build a set of filters on each of your router's NICs to allow only the traffic that you want into your network and to keep all other packets out.

When your network's RRAS packet filters are up and running, you might discover that your Internet connection hosts types of traffic that you didn't consider when you configured your filters. For example, you can't use the ping command to resolve the status of external hosts unless you specifically allow ping packets to pass through your network. Name-resolution requests to your Internet Service Provider's (ISP's) Domain Name System (DNS) server fail unless you open the correct port. In addition, your users can't access Post Office Protocol 3 (POP3) mailboxes on your ISP's server or log on to America Online (AOL) across the Internet unless your packet filters permit these functions.

To avoid excluding necessary traffic from your network, you need to carefully plan the source ports and protocols from which your filters will let packets into your network. Understand exactly what types of traffic pass through your Internet connection before you prevent traffic from entering or leaving your network. If you have access to a network-sniffing utility such as Network Associates' Sniffer Basic (formerly NetXRay) that summarizes the types of traffic on your network, sample your network traffic before you configure your packet filter.

TABLE 1: Destination Ports for Requests for Common Services*

Port

Protocol

21

FTP

25

Simple Mail Transfer Protocol (SMTP)

70

Gopher

80

HTTP

110

POP3

119

Network News Transfer Protocol (NNTP)

*Source ports for requests for these protocols range from 1024 to 65,535.

Is RRAS for You? Your network will be much more secure if you set up packet filters to limit the types of traffic that can pass through your router's NICs. One of intruders' primary methods for gathering information about a target network is pinging or scanning the ports of a block of IP addresses. To get important clues about a network's topology, hackers monitor which ports on which devices respond to pings. RRAS packet filters prevent intruders from accessing this information. Packet filters also prevent outsiders from establishing direct NetBIOS connections to devices on your network.

RRAS is free and is often an effective solution for simple networks. However, if your network is large or if you have highly sensitive data to protect, you need to consider a commercial firewall package for your network.

Commercial firewalls provide much greater flexibility, and most include additional features such as comprehensive logging and monitoring. In addition, many commercial firewalls handle common-protocol requests via an application proxy, a strategy that lets you hide your internal IP addresses from Internet intruders. (See the sidebar "Common-Sense Security Suggestions" for systems administration tactics you can use to reduce intruders' damage to your network, regardless of the security solution you choose.)

Internet security is complex and difficult for administrators to keep up with. I view data theft across the Internet as similar to vehicle theft. You can put every possible security system on your vehicle, but if somebody really wants to steal it and has the necessary resources, that person will find a way to take your car. Likewise, network security solutions are never 100 percent effective. A successful security system convinces intruders that nothing on your network (or in your car) is worth the effort required to access it, so potential thieves move on to easier targets.

Discuss this Article 14

Stan George (not verified)

on Aug 6, 1999

I read the sidebar “Common-Sense Security Suggestions” in “Poor Man’s Firewall.” The author mentions a recent compromise to Microsoft FrontPage. I’ve searched the FrontPage Web site and Microsoft’s security bulletins but can find nothing. I’m concerned because I’m bringing an IIS 4.0 Web site online and plan to use FrontPage 98 to let departments edit and maintain the Web site. Do you have any information about this compromise that you can pass along.--Stan George

The mainstream media and the security alerts from Microsoft have not addressed FrontPage extension exploits. However, the news that FrontPage server extensions running on an NT or UNIX server can leave open a number of vulnerabilities seems to be common knowledge among hackers. For example, I recently downloaded a scanning tool that specifically scans blocks of IP addresses for FrontPage server extensions (among other things).
Depending on your security configuration, a significant problem is the readability of .pwd files on your FrontPage-enabled servers. If you’re familiar with FrontPage, you’re probably aware that these files store passwords for specific user accounts with assigned permissions on a FrontPage Web server. Apparently, if your security isn’t configured properly, anyone can read these files and decrypt them with the appropriate tools. I recommend you search old usenet posts via Deja News for more information.--Douglas Toombs

Unfortunately, the configuration you've described won't work. Here's why: When your workstation tries to access a Web site (e.g., http://www.microsoft.com), it presents itself and says, "Hello, my address is 192.168.1.x, and I'd like you to give me a copy of your home page." Then, the Web server sends a copy of the home page to the address you've specified.

The problem results because the 192.168.x.x range is considered "nonroutable"--­that is, no Internet routers will pass any traffic to those addresses whatsoever. So, even if the server running http://www.microsoft.com tries to send you its home page, the information won't get out onto the public Internet.

For this configuration, you need Microsoft Proxy Server. It will work well for your configuration, and (unlike other Microsoft products) it's not priced per user.

In “Common-Sense Security Suggestions” in “Poor Man’s Firewall,” the author mentions a recent compromise of the WinGate proxy server. However, the author doesn’t describe what that compromise is. Can you help me?
--Chris Falsone

For further information about WinGate vulnerabilities, check the CERT Web site at http://www.cert.org/vul_notes/VN-98.03.WinGate.html.--Douglas Toombs

I'm trying to set up RRAS for Web and email access on my network. I have a Windows NT server running DHCP with a scope of 192.168.1.x. The server has two NICs in it--­one for my LAN and one plugged into my Digital Subscriber Line (DSL) router via a crossover cable. I can surf the Web from my NT server, but I can't get my LAN machines to go outside. I can ping the second NIC from my workstation, but I can't ping the router. Is my configuration doomed because I'm using 192.168.1.x addresses?

“Poor Man’s Firewall” includes a table of popular destination ports. Where can I get some information about what source ports I should use for Post Office Protocol 3 (POP3), Simple Mail Transfer Protocol (SMTP), Network News Transfer Protocol (NNTP), File Transfer Protocol (FTP), Internet Control Message Protocol (ICMP) ping requests, and so forth. The table’s footnote says that the source ports range between 1024 to 65,535.
How do I configure source ports? For example, do I need to configure a specific port number for incoming SMTP mail, or can the source port be anything between 1024 and 65,535?
--Richard La Bella

For a comprehensive list of well-known ports, try RFC 1700 at ftp://ftp.isi.edu/in-notes/rfc1700.txt. For protocols that can have a source port anywhere from 1024 to 65,535, all you need to do is leave the source port information blank when defining a filter. In effect, this setting will ignore that criterion when applying the filter, allowing any value through. More robust firewall solutions such as Raptor (http://www.raptor.com) will let you specifically define a range of possible source ports.
--Douglas Toombs

Thanks for printing Douglas Toombs’ “Poor Man’s Firewall” (December 1998). However, I’m a bit confused: I thought that a packet from a host holding a 10.x.x.x address couldn’t be routed across the Internet. I can understand how to use Routing and Remote Access Service (RRAS) to filter outbound requests in the way the author describes, but I don’t understand how the packets find their way back to the firewall host if the return address is in the form 10.x.x.x. Unless RRAS uses some form of Network Address Translator (NAT), surely the process won’t work. If the example used a subnet of the 172.16.0.10 address range for the internal network, I could see it working.
--Clive Foster

You noticed something several people pointed out to me that I should have emphasized in the article. The 10.x.x.x network is nonroutable as far as the public Internet is concerned. The same Request for Comments (RFC) that mentions that fact also defines the 172.16.x.x range as a nonroutable block. My article presents a template to build a basic packet filter between two nonroutable networks—–all you need to do is plug in your valid, routable addresses in the appropriate locations, and you will be all set.
--Douglas Toombs

Microsoft takes network security seriously, and for this reason we discourage the use of routing filters as the sole means of addressing network security. Although Windows NT RRAS filters provide a modicum of protection, they are not a substitute for a true firewall.
Routing packet filters are intended to prevent packet forwarding to undesirable locations. This function is different from the function dynamic packet filters provide in true firewalls. Microsoft Proxy Server is a pragmatic and economical means to enhance network security, optimize network performance, and increase management control of Internet access. Proxy Server is the only Microsoft product you should use to ensure firewall-level security. To learn more about Proxy Server’s firewall capabilities and to get a trial copy, visit http://
microsoft.com/proxy.
--The Windows NT Communications Team

Related Articles

John Savill's Hyper-V Master Class

Join John Savill for 12 hours of comprehensive Hyper-V training. This master-level online training course will explore all the key aspects of a Hyper-V based virtualization environment covering both current capabilities in Windows Server 2012 R2 and looking at the future with Windows Server vNext.