Networking

Prepare your system before installing BorderManager 3.7

Deploying a firewall on your network is no small task. Before you even think about starting the installation, you have to do some serious planning. In this Daily Feature, Ron Nutter shows you how to get ready to deploy BorderManager 3.7.


When you're connecting a network to the Internet for the first time or putting up your own firewall, you don’t want to dive in and start installing software without looking at a few things first. Without careful consideration, your firewall won’t work the way it should. You might wind up leaving giant security holes in your network or, even worse, a misconfiguration could block all traffic on your network, preventing anyone from doing anything. In this Daily Feature, I’ll show you what you need to know before you run BorderManager 3.7’s installation program.

Getting ready for the firewall
There are four key areas you have to double-check before installing BorderManager 3.7. These areas include:
  • Physical connectivity
  • IP addressing
  • Software considerations
  • Hardware considerations

Let’s look at these areas individually to understand how each is affected by your firewall deployment and what you should do in advance.

Software considerations
You run BorderManager 3.7 on either NetWare 5.1 or NetWare 6. NetWare 5.1 has a smaller memory footprint than NetWare 6, so if you won’t be able to put a lot of memory in the server, you can leave more memory for BorderManager by using NetWare 5.1.

If memory constraints are an issue for your server, do a base installation of NetWare. Don’t install any of the extra services like Web servers, management servers, and the like. But do be sure to apply the latest service pack for the OS on the server.

Hardware considerations
The amount of memory you put in a server running BorderManager depends in part on the number of users that will go through the server. BorderManager’s memory usage is directly proportional to the number of users who connect to it. The amount of memory your server should have goes by these guidelines:
  • 20 users or less: 256 MB
  • 21 to 100 users: 512 MB
  • 100+ users: 1024 MB (1GB)

Keep in mind that these are general numbers to use as a starting point. The precise amount of RAM you’ll need will depend as well on other services your server may be running. Use MONITOR.NLM to watch how busy the processor(s) in the server stay and note your available cache buffers figure. The higher the number of available cache buffers, as a general rule, the better the server will be able to perform the tasks assigned to it.

TCP/IP addressing
Without planning, one thing that can get you into trouble is not properly handling your TCP/IP address usage. A company that I have done some work for dealt with this problem. Before they realized it, they had used up all their external addresses. Because external TCP/IP addresses are so hard to come by, you must manage them carefully. Only assign external addresses as necessary.

As a rule, try to minimize the number of addresses and ports that BorderManager allows. The fewer TCP/IP addresses you have on the public (external) side of BorderManager and the fewer TCP/IP ports you allow to pass through BorderManager, the fewer chances potential hackers will have to attack your network.

Make sure TCP/IP is running on your server before installing BorderManager. Bind TCP/IP to the card and make sure it can ping devices on your network. You should also run INETCFG.NLM and make sure that RIP 2 is turned on for the network card. Once you have this up and running, you can install the second network card and give it a public TCP/IP address.

Physical connections
Finally, you need to decide how your network infrastructure should work. Check how you’re going to make the connection between your internal LAN and the Internet/WAN. You will have one connection to your network on the private side of BorderManager and at least one connection to the public side. There are three possible configurations you can set for BorderManager when using it as a firewall. The basic difference between the versions is the number of network cards you use.

The first configuration is a single network card implementation. In this configuration, a single network card serves as the public and private interface. The users connect to this server as both a default gateway and a departure point to access other services on and off the network. With this configuration there is only one way for data to travel in and out of the server. While it is, conceptually, the simplest configuration, it’s not the best choice, because this single network card can quickly be overloaded by network traffic.

The more common configuration is the dual network card configuration. With this configuration, each interface has its own network card: one for the internal network and one for the external network. If you don’t have any servers—such as e-mail or Web servers—that need to be publicly accessible on the Internet, this configuration is the best option.

The downside to this particular configuration becomes apparent if you do need to provide such access. Then you would need to add a secondary TCP/IP address to the public network card and statically map it to an internal TCP/IP address on your network. In order to allow traffic to get to these servers unimpeded, next you will need to grant static packet filter exceptions to allow traffic from any TCP/IP address on the Internet to a specific address on your internal network.

While this is not an uncommon configuration, you will need to take extra precautions with the servers that are being accessed from the Internet. Make sure they have the latest patches for the operating system and applications that are installed on the server. You should also make sure you have locked down or disabled any services that aren’t absolutely necessary. This is important because someone could get to the server and then use it as a jumping-off point to systems on your internal network.

The remaining configuration involves the use of three network cards. This is similar to the two-card implementation that I just covered, but the third card sets up a demilitarized zone (DMZ). This is an area where you put servers that need to be publicly accessible so that they can be seen on the Internet, while giving your network the most protection possible.

In this case, you will put static packet filter exceptions in places that allow traffic to come directly to these servers. While you could use general packet filter exceptions to allow the traffic from the Internet to go to these servers, I would still recommend that you only open up the ports that you absolutely must have open to these servers. You need to leave the door open a little so that others can get in, but you don’t have to leave the door wide open. For the private interface, you should block all incoming packet requests that are trying to reach the private interface card using the packet filter exception tool that has already been discussed.

If you need to provide access to internal resources from external sources, this configuration is your best choice. It takes a little extra work and costs a little more, but it also provides the best balance between access and security.

Beyond the network card configurations, you need to concern yourself with the physical connections to your server. Take a label maker or some type of marking device and label each of the network cards, indicating which is connected to the external network and which is connected to the internal network. Doing so will make it easier to track down cables later.

Although you can get by with using a crossover cable, I would recommend putting a hub between the external interface card in your BorderManager server and the router. Putting a hub between the two will allow you to put a protocol analyzer outside the firewall. You can use the protocol analyzer to test and troubleshoot your network when setting up new packet filter exceptions and when debugging problems incurred by sending mail to another domain. Make sure you use a simple hub and not a switch. Using a switch will prevent the protocol analyzer from being able to see anything other than broadcast traffic, unless you do some type of port mirroring, which only the more expensive switches will be able to do.

Ready? Set? Go!
The first step in successfully deploying BorderManager 3.7 is making sure your network is ready to handle it. Decide what you want your firewall to do and plan your configurations appropriately. Once you get your hardware, software, and infrastructure ducks in a row, then you can tackle the job of the actual installation.

Editor's Picks

Free Newsletters, In your Inbox