Enabling packet filtering in BorderManager 3.x

As you know by now, the best way to connect your NetWare network to the Internet is by using BorderManager. BorderManager does more than provide simple proxy or firewall services and can be quite complicated to configure. In this Daily Drill Down, I’ll show you how to increase security on your Internet connection by using packet filtering with BorderManager.

Packet what?
There are two ways that you can control access into and out of your network when using BorderManager: access rules and packet filtering. Access rules are used primarily for controlling access out of the network. You can configure your access rules right down to a particular IP address or NDS username and/or group.

Packet filtering is best suited for controlling the kind of traffic—such as HTTP, FTP, or POP—that will be allowed to enter your network. You can also use it to control the kind of traffic that can leave your network. The problem with using packet filtering on outbound traffic is that the filters affect all the traffic. You can’t make exceptions based on the NDS user or container name accessing the Internet.

Deciding on the traffic to pass through the filters
Don’t try to jump in and turn on packet filtering. You will be in for a very rude awakening if you do. Setting up filtering on BorderManager is part art and part science. The science part comes in when you decide what traffic to allow from the Internet onto your network and what traffic to allow back out. The art component comes in when you start implementing the filters and getting the traffic where you want it to go, then troubleshooting when the filters don’t seem to be working as expected.

The number of network cards in your BorderManager server dictates what traffic will be allowed to pass through BorderManager and where it can go. The more advanced implementations involve three network cards, even on the simplest of networks. Initial implementations of BorderManager consist of a public network card and a private network card. This setup is fine for most situations until you start using additional services, such as an in-house mail server, in-house DNS servers, and a Web server to provide information to your company’s customers or potential customers.

Once you add these services, you will need another network card. The additional card will allow you to set up a DMZ, or Demilitarized Zone, where access from the outside world is directed when it isn’t requested from a workstation on your local network. The DMZ prevents unwelcome traffic from the outside world from entering your network.

When you plan the filters on your network, you may want to start by creating a diagram of your BorderManager server. The drawing should include the BorderManager server, the network cards inside it, and the servers running the services that you want the filters to handle. The diagram will be a great help later when you need to make changes to the packet-filtering configuration. It will also help you put together better documentation on what the filters do and why.

You can document the current filter configuration in BorderManager using filtcfg.nlm. However, you may find that the text file that is created as a result of that process leaves a bit to be desired. In this case, having a diagram of your configuration and plans on paper may be a great help.

BorderManager allows you to use two types of filters—static and stateful. Static packet filtering involves examining each packet that goes through BorderManager. Static packet filters parse the header field of each packet to identify a particular set of characteristics. These characteristics then determine whether the packet should be forwarded according to your outbound and inbound rules.

Unfortunately, static filtering isn’t very flexible. For example, because a static filter checks only the header of a packet, it can’t tell whether the packet is the first packet from an external client to an internal server or a response from an external server to an internal client. The level of protection provided by this type of filtering is limited. However, because static filtering checks only the header, it’s extremely fast.

Stateful packet filtering, sometimes also known as dynamic filtering, overcomes some of the limitations of static packet filtering. Stateful packet filtering tracks the outgoing packets it has allowed to pass. It then allows back in only those packets that are in response to the packets it allowed out in the first place. When the first packet goes through BorderManager, it dynamically creates a reverse filter to allow the response packet to return. BorderManager allows only incoming packets that are from the host and port to which the outbound packet was sent.

Stateful packet filtering supports both connection and connectionless protocols, such as TCP, UDP, and ICMP. Stateful filters are very flexible because they allow you to do such things as block traffic originating from a particular port number and address while at the same time allowing returning traffic from that same port number and address.

Because stateful packet filtering is more secure and flexible than static filtering, you’ll probably want to use it instead. It potentially can mean less work in setting up filters because BorderManager will automatically handle inbound traffic in direct response to traffic that left your network.

You can use the BorderManager access rules to control what your users are allowed to send off the network. You can configure different rules based on the direction in which the filter is intended to be used (inbound or outbound). If you are running any services on your BorderManager server that need to be available to the outside world, you will need to take an additional step when setting up the packet filters. If you specify both a public interface and a private interface, the traffic covered by the filter will do exactly what you tell it to do and bypass whatever service is running on BorderManager that you need to cover by the packet filters you are working with.

Once you become familiar with the process of setting up filters, you can begin the process of tightening down the filters so that they will allow only the minimum amount of external traffic onto the network. It’s a good idea to keep some type of logbook to keep track of the filter exceptions you create in BorderManager, along with what they do and why you created a particular filter exception. Keep in mind that with each filter exception you set up, you are opening up a potential hole for intruders to get into your network.

Getting ready to implement packet filtering
Before setting up packet filtering in BorderManager, there are a few housekeeping tasks you should do in preparation. I’ll assume for the purposes of this Daily Drill Down that you are running BorderManager 3.x on a NetWare 5.x server. You should first make sure that your NetWare 5 server has the latest support pack available.

The only time that I would take exception to this statement is if the support pack in question has just been released within the past couple of weeks. If the support pack is very new, then I suggest using the NetWare support pack released just prior to the one currently available. In recent years, Novell has gone the extra mile in testing before allowing a support pack to go out, but sometimes problems don’t show up until they hit the “real” world.

The next step involves applying the latest BorderManager support pack and any individual patches Novell may have released, such as the patch for BorderManager’s proxy server. It is important that the BorderManager patches be applied after the NetWare support pack, because it is possible that a file in the NetWare support pack may be older than the one in the BorderManager support pack. Because the files need to be at a certain level, BorderManager may not work correctly if there are older files in place.

If you are using Compaq hardware as your platform for BorderManager, you will need to take one additional step—downloading and applying the latest NSSD (Novell System Support Disk) from Compaq’s Web site. To make sure that everything is loading correctly, down the server and restart it before continuing.

After you’ve double-checked the support pack versions on your server, you will need to go into your old trusty friend INETCFG.NLM. There you must enable filter support in order for the filters you’ll be creating to work correctly. To do so, load INETCFG.NLM, then select Protocols and press [Enter]. Next, on the Protocol Configuration screen, select TCP/IP and press [Enter].

When the TCP/IP Protocol Configuration screen appears, move the cursor down to the line that says Filter Support. It should currently show Disabled. Select Disabled, press [Enter], and change it to read Enabled. Press [Esc], select Yes, and press [Enter] to update the current TCP/IP configuration on your NetWare 5 server. As you exit INETCFG.NLM, you’ll be prompted to type reinitialize system to activate the configuration change you just made.

Although no disruption in service should occur on your BorderManager service when you do this, it would be a good idea to wait to perform this step until either all the users are off the network or when a minimum number of users are on the network.

One small step that you can take to ease the process of creating packet exception filters is to change the board names assigned to the network card drivers when they load. Although NetWare assigns a default name to the card, it might be easier to track if you change the name to match the function the board actually provides in BorderManager.

For example, for the card that connects to the router that ties you into the Internet, use the board name of PUBLIC. For the private card that connects BorderManager to your network, use the board name of PRIVATE. If your configuration uses more than one private interface for BorderManager, you can use such names as PRIVATE_1, PRIVATE_2, and so forth to help distinguish the different network cards.

If you will be using a DMZ to protect the servers that need to be reached from the outside world and prevent unwanted traffic from getting onto your private network, use a board name of DMZ to signify the special purpose of this segment. For this Daily Drill Down, we’ll have only two network cards—one for the public interface to the Internet and one for the private interface connecting BorderManager to our network.

Finally, review the notes you made earlier about the type of filters that you want to create. Once you are satisfied that you have everything covered, you are ready to start creating packet filters in BorderManager.

Creating a packet filter
To create a packet filter, start by loading FILTCFG.NLM from the console prompt of the server that BorderManager is running on. Once the Filter Configuration screen appears, select Configure TCP/IP Filters and press [Enter].

When the TCP/IP screen appears, you will have several options to work with. There are two selections for RIP (Routing Information Protocol) filters, which control which routes are advertised by your router (in this case, the BorderManager server). Since you will probably use one of the three private IP ranges available when running a firewall such as BorderManager, you probably won’t want to use either of the RIP filter options. That’s because there’s no benefit to advertising a private IP address or range that no one would be able to reach directly over the Internet.

You will also see filter options for EGP and OSPF. You will use these only if you are talking to an upstream router that is using either EGP or OSPF to handle the routing of your traffic.

The Global IP Logging option records information about those packets that match the filters or records exception definitions if logging for that filter or exception is enabled. While this option is a good tool for verifying that what you have is working correctly or is useful as a debugging tool when you think there is a problem, you should keep it turned off to minimize the overhead on the BorderManager server. For the purposes of this Daily Drill Down, we’ll be working with the Packet Forwarding Filters option. Select this option and press [Enter] to continue.

When the Packet Forwarding Filters screen appears, you’ll need to enable this option in order for it to do the work you need. The word Disabled should be selected just to the right of the Status field. Press [Enter] to bring up the Configuration Option list, then select Enabled. You should see a warning message that this option will block all IP traffic until you grant the appropriate filter exceptions. Select Continue Anyway, and press [Enter] to continue. When you return to the Packet Forwarding Filters screen, you should notice that the text to the right of the Action field has changed from Permit Packets In Filter List to Deny Packets In Filter List.

Since no packet filters or exceptions are currently configured, no traffic can get through. By initially starting out with no filters defined and allowing traffic to pass only by granting exceptions, you are minimizing the number of holes created in BorderManager that allow unwanted traffic into your network.

In our case, we want to make sure that HTTP requests can get out through BorderManager and that the return traffic can get back in. We will start by first granting the exception to allow HTTP traffic to get out. Select List Of Packets Always Permitted in the Exceptions field. When the Exceptions: Packets Always Permitted screen appears, press [Insert] to begin the packet filter exception rule process.

Leave the Source Interface Type field at the default value of Interface. If you have more than one private interface on your BorderManager server and if the private interfaces are placed in a common group, you might be able to take advantage of having one filter cover multiple private interfaces. For now, however, go with the KISS (Keep It Simple, Stupid) principle until things are up and running.

The Source Interface field will start out with a value of All Interfaces. You can leave this option set at the default value. Even if you have only one private network card, it is possible that one or more of the NLMs running on the BorderManager server may generate an HTTP request. If you specifically select the private interface, you’ll run the risk of preventing that NLM from being able to generate the request. BorderManager will block the request since there is no filter exception that will allow it to pass. Leave the Destination Interface Type option set at the default value of Interface. Highlight All Interfaces beside the Destination Interface option and change it to Public. This will tell the filter that this packet filter exception will govern all traffic running on any interface on your server to the public interface.

Select the Any option beside the Packet Type field and press [Enter]. When the Defined TCP/IP Packet Types screen appears, press [Insert]. The cursor should be on the text (Unspecified) beside the Name field. Type HTTP Request and press [Enter]. The highlight bar should now be on (Unspecified) beside the Protocol field. Press [Insert] to get a list of Internet protocols, select TCP (it may appear as TCP(6) in your list), and press [Enter]. Press the down arrow to highlight the All option beside the Source Port(s) field. Type 1024-65535 and press [Enter].

You need to enter this range of numbers because you will have no idea which outgoing IP port a workstation will use to talk to a remote Web server. The highlight bar should now be on All beside the Destination Port(s) field. Type 80 and press [Enter]. You have the option of automatically allowing inbound traffic that is coming in response to an outbound request sent through BorderManager by using either the ACK Bit Filtering or Stateful Filtering option.

We won’t use these options for now, but as you become more comfortable with using filters in BorderManager, you may want to come back and consider implementing one of these options to make your firewall administrative work potentially a little easier. Use the down arrow key to select the (Unspecified) option beside the Comment field.

Here you should enter a comment, however brief, about each filter exception that you create. This will help you remember why you created each filter exception and for what purpose. For this filter, type HTTP Request and press [Enter].

Press [Esc] to save the packet type definition that you just created. Now highlight this packet definition and press [Enter]. You should now see the information from the packet filter definition on the Define Exception screen that you have been working on. Press [Esc], select Yes, and press [Enter] to save the packet filter exception that you just created. When you return to the Exceptions: Packets Always Permitted screen, you should see the exception filter you just created in the list.

You now have a way for the HTTP request to go from your private network out to the Internet, but no way for it to get back in. You’ll need to create a packet filter exception for the returning traffic to get back to the requester. Press [Insert] to start the filter-creation process. When the Define Exception screen appears, highlight the All Interfaces option beside Source Interface, press [Enter], and select your public network card.

Using the down arrow key, highlight (Select for List) or Any beside the Packet Type option and press [Enter]. Press [Insert] to open the Define TCP/IP Packet Type box. In the Name field, currently containing the text (Unspecified), type HTTP Response and press [Enter].

The highlight bar should now be over the (Unspecified) option beside the Protocol field. Press [Insert], select TCP, and press [Enter]. Using the down arrow key, highlight the All option beside the Source Port(s) field, type 80, and press [Enter].

Now the highlight bar should be over the All option beside the Destination Port(s) field. Type 1024-65535 and press [Enter]. As with the first packet filter exception that you created, leave the ACK and Stateful Filtering fields set to Disabled. Using the down arrow key, select the (Unspecified) option beside the Comment field, enter a comment such as HTTP Response, and press [Enter].

Press [Esc] to save the filter exception you just created. Then select the filter exception and press [Enter] to insert the packet type definition into the exception filter you’re working on. Press [Esc], select Yes, and press [Enter] to save the exception. At this point, you have opened up BorderManager just enough that HTTP requests can go out to the Internet and the returning information can pass back through.

Depending on whether you’re using the DNS Proxy functionality of BorderManager, you may also need to create a DNS exception filter so that the workstations can resolve a Web site host name to an IP address. Since some Web sites use SSL (Secure Socket Layer) for certain functions (you can tell this by a small lock icon appearing on the bottom of your browser screen or seeing HTTPS: in the URL line), you will also need to grant a separate exception filter for port 443, because HTTPS traffic doesn’t run over port 80.

Each time you create, change, or delete a packet filter exception, the filter doesn’t immediately take effect. To make the filter take effect, you must unload several NLMs and reinitialize your server. To do so, first type unload ipflt at the server console and press [Enter] twice. Finally, reinitialize your server by typing reinitialize system at the server console and pressing [Enter]. Doing so reloads the NLMs in the correct order and forces a reread of the filter database.

If you’re passing IPX through BorderManager, you’ll also need to unload ipxflt so that any changes for IPX will be processed as well. If you plan to add several filters at one time, I strongly suggest instead that you add one filter at a time, unload and reload the filter-related NLMs, and then test to see that the filter exceptions you just entered are working and that the previously working filter exceptions are still working as expected.

Take a few extra minutes to document the filters as you create them. There are several ways that you can do this. One is by using the Save Filters To A Text File option in Filtcfg.nlm. This will give you a base text file to help in documenting your filter configuration. Depending on how often you make additions or changes to your packet filter configuration, you might want to take the documentation process one step further by using screen captures to help document the screens as you fill them out. This additional step will use a few more pieces of paper but should help you avoid any data entry errors in the event that the packet filter database file becomes corrupted and you have to re-create the filters from scratch.

Other packet filter reference material
Novell realizes that creating packet exception filters can be a frightening task for those who have little or no experience in setting up that type of functionality. Table A shows a list of the various technical information documents (TIDs) that are currently available from Novell to help you in this area. It may take a little bit of trial and error to get a filter to do exactly what you want, depending on your particular BorderManager configuration.

Craig Johnson, one of the Novell Support Connection SysOps, compiled all of the questions he had been answering on the BorderManager forum into a PDF document that is for sale on Caledonia for a very reasonable price. One thing that really impressed me about this document was that it shows the difference between stateful and ACK bit filters and how best to use them. Craig’s electronic book brings out an important point about why you probably don’t want to use ACK bit filters—they work only on TCP packets. This is one reference that should be in your collection of BorderManager tools. Craig presented an excellent session at BrainShare 2000 that was well worth the time it took to cover all the material he went over.

Conclusion
Packet filters should be viewed as just one part of the defense strategy for your network. Although they can control the traffic leaving your network, they’re primarily meant to control the traffic entering your network. Using the other tools in BorderManager such as Single Sign-on, Access Rules, and the various proxies, you can take several reasonable precautions to protect your network. Filters are not a simple drag-and-drop type of function to implement. However, if you take care when working with filters, you will have a strong defense for protecting the users and systems on your network from unwelcome intrusion.

Ronald Nutter is a senior systems engineer in Lexington, KY. He’s an MCSE, a Novell Master CNE, and a Compaq ASE. Ron has worked with networks ranging in size from single servers to multiserver/multi-OS setups, including NetWare, Windows NT, AS/400, 3090, and UNIX. He’s also the help desk editor for Network World. If you’d like to contact Ron, send him an e-mail. (Because of the large volume of e-mail that he receives, it’s impossible for him to respond to every message. However, he does read them all.)

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Daily Tech Insider Newsletter

Stay up to date on the latest in technology with Daily Tech Insider. We bring you news on industry-leading companies, products, and people, as well as highlighted articles, downloads, and top resources. You’ll receive primers on hot tech topics that will help you stay ahead of the game.

Delivered Weekdays

Sign up today