How To Install A Firewall
If your Internet connection is not protected by a firewall you should probably consider implementing one. We discuss how to install and configure this vital piece of kit to provide an effective solution.
By Neil Briscoe
our new firewall needs to be physically located near the router that connects you to the Internet (or other service that you’re firewalling). The reason for this is that you will connect one of the interfaces on the firewall directly to the router’s Ethernet port via a cross-over cable. With no intervening hub, there is no way for any other machine to sit on the subnet between the router and the firewall.
Most firewalls need to know which interface is the external interface and which is internal. The one you connect to the router is the external interface, and it will have to be given an IP address from the block of addresses allocated to you by your Internet provider. The router’s Ethernet address will consume another address from this block. Later, after you’ve installed the firewall software, you will need to configure the firewall so that the router’s Ethernet address is its default route. Your firewall should have at least a second, and possibly a third, interface. The second one is used to connect to your corporate LAN, so you connect it to the network hub using a standard straight cable. The address that you assign to this interface should be on the same subnet as that used by all the other machines on your internal network. In most firewall installations, this means either that the network is running on a set of addresses as defined in RFC1918, or that the firewall is being used to hide the addresses that have “always been
in use on the network” because it would take too long to renumber all the devices. In either case, the firewall needs to provide either proxy capability or network address translation (NAT) in order to hide these addresses from the Internet. In the third case, where you are using validly assigned public addresses on the internal network, then unless the firewall permits routing protocols to be transmitted (some do, or can be made to, and some will not and cannot be coerced to do so) you will need to arrange for the Internet-facing router to route all traffic for the internal network via the external interface on the firewall. Furthermore, since you are using public addresses on the external side, you will have to have considered subnetting your allocated address space, such that the subnet in use by the firewall’s external interface and the router
is different to that in use on the internal network. In any of the above cases, all devices on the internal network need to consider the firewall’s internal interface as their default router. You might be using a third interface for a number of reasons. The most likely is so that you can offer public services, such as a Web server, over your link. Public servers should never reside on the same LAN as your corporate network. If you’re only running a single public server, you can use a cross-over cable to connect it to the firewall’s third interface. Otherwise, use straight cabling and a second hub.
Now that the firewall is connected you will need to install the software (unless it’s a hardware-based firewall) and then configure it.
“Care should be taken over which protocols you install. You need to install the Microsoft TCP/IP stack, since it sets certain entries in the registry, but you should not install any other protocols. On no account should you allow the installer to install IIS or the Internet Explorer.” PC Network Advisor
Issue 113 (December 1999) Page 13
“For Unix-based firewalls, you should look for a bootable CD supplied by the firewall vendor, with no requirement to rely on a boot disk from the vendor of your Unix software. Furthermore, the firewall software should not be based on the latest version of the Unix vendor’s software.”
Most firewalls which are based on NT require you to install NT Server first. You should install it as normal; however, care should be taken over which protocols you install. You need to install the Microsoft TCP/IP stack, since it sets certain entries in the registry, but you should not install any other protocols. On no account should you allow the installer to install IIS or the Internet Explorer. It will be interesting to see how firewall vendors get around this last point when they start basing their products on Windows 2000. I strongly suspect NT-based firewalls will be based on NT4S for some time to come. Take advice from your firewall vendor about which, if any, service packs should be installed. You may have to consider the order in which you apply them depending upon whether or not your firewall is shipped with a replacement IP stack. For Unix-based firewalls, you should look for a bootable CD supplied by the firewall vendor, with no requirement to rely on a boot disk from the vendor of your Unix software. Furthermore, the firewall software should not be based on the latest version of the Unix vendor’s software. For example, at time of writing Solaris 2.7 is current. You should look for your firewall to be based on nothing higher than Solaris 2.6. The reason for this is that your firewall vendor needs time to ensure they have a hardened kernel, and when they receive the new source code from the Unix vendor they have to apply all the same hardenings they applied to the earlier version.
The order isn’t important, but nothing will work until all three are in place: 1 Set up an Internal DNS server. As a minimum, you need to set it up with an SOA (Start of Authority) record, an NS (NameServer) record, an A record containing the internal IP address of the DNS server, an A record containing the IP address of the internal mail server, and an MX (Mail eXchanger) record for the domain. Generally, when setting up an internal DNS to work with this sort of firewall, you do not want secondary MX records which point to servers on the far side of the firewall, such as your ISP’s fallback server. The reason for this is that, if your internal mail machine dies, the firewall will pick up the mail as it’s delivered from the Internet, attempt to relay it, find that it cannot, and relay it instead to the ISP fallback. This will use the ISP’s DNS to check where it should go, and it’ll aim it straight back at the firewall. After about 15 or so iterations of this, the mail will get bounced with a “Too many hops” error. With no secondary MX records in your internal DNS, the firewall receives the mail, finds it can’t relay it, and has no option but to keep it in its own mail spool. In effect, the firewall acts as an invisible MX backup. Finally, configure your DNS server
Now that you have installed your firewall, of whatever stripe, you need to configure it to permit those protocols you do want to pass between your network and the Internet.
Email The first requirement is generally to get email working. To do this you have to arrange for both SMTP and DNS to pass through the firewall. Many firewalls will intercept all incoming SMTP connections and spool the mail, then relaying it to an internal mail server a few minutes later. To allow this to work, you need to arrange for the following three tasks to occur.
“Many firewalls will allow you to set up rules permitting access if the users can authenticate themselves. All such firewalls support the standard Unix-like authentication, normally out of the box, but you can also arrange to use one of the Token authentication schemes if you wish.” PC Network Advisor
Issue 113 (December 1999) Page 14
“Generally, when setting up an internal DNS to work with this sort of firewall, you do not want secondary MX records which point to servers on the far side of the firewall, such as your ISP’s fallback server.”
with a forwarder’s directive or two - instructing it to ask your ISP’s name servers for domains for which it is not authoritative (most of them). 2 Arrange to have your ISP run Primary Name Service for your domain as it is viewed by the rest of the world. Have them add an A record called mail that has the IP address of the external interface on the firewall, and set the MX record to point to it. There is no reason why they shouldn’t add a secondary MX pointing at their fallback server. That way, if your leased line, router or firewall fails, and mail cannot be delivered to the firewall, it gets stored on the fallback mail server until things are back online again. 3 Configure the firewall to use your internal DNS for name lookups. Also set it to allow outgoing connections on port 53 (DNS) and to allow both outgoing and incoming connections on port 25 (SMTP). With all that done, you should find that mail destined for you will be intercepted and then relayed to your internal server, and that outgoing mail is intercepted and then relayed outwards by the firewall. Web servers you might be running on your intranet. This is because firewalls use rule sets, determining from where, to where, and which service is being permitted. With most firewalls on the market you can configure users, user groups, addresses and address groups so that, rather than putting in a rule for each address you might be permitting access to, you put in one rule that says users can visit the addresses listed in the address group. Then, if you need to add or remove an address from the list, just add or remove the address in the address group, and the firewall will adjust its view of the world accordingly. If you’d rather not have to do this manually, there are special versions of software such as WebSense that will work with the more popular makes of firewall. Configure WebSense as normal, configure the firewall to permit the WebSense server to contact the subscription update server, and then configure a rule on the firewall indicating that the firewall should defer to WebSense to determine whether or not to permit the access. In general, you should never need to apply a deny rule on a firewall, since it should be denying anything it hasn’t been explicitly told to allow. However, there are times when you might need them. This might be because you are configuring a complicated rule set allowing users in a group to have access, but, at the same time, you want to deny a single user who happens to be a member of that group, at a specific time of day. You need one rule permitting access for that group of users, and an explicit deny rule for that individual dictating the time of day he is not permitted access. This will only work if your firewall supports a suitable algorithm that sets preferences against all rules selected by a particular packet. It should construe that a rule relating to an individual has a higher preference than one relating to a group. If it does, then the deny rule for the individual will be selected at the times of day you’ve specified, but won’t be selected outside those times. There is one other case where you might want to set a deny rule, but only if your firewall allows you to set “Do not log” on the rule. If you have an NT network, then each and every machine on the network will send out, approximately every 13 minutes or so, a stream of UDP packets on port 137. Firewall logs get filled up with a load of entries relating to denied transmissions of these packets, making it much harder to view the logs for information
Web Access Most other services are considerably more simple to configure, should you wish to allow them. It’s perfectly possible, with most modern firewalls, to allow your users to access the Web, whilst disallowing any attempt on the part of outsiders to gain access to any
“Configure the firewall to use your internal DNS for name lookups. Also set it to allow outgoing connections on port 53 (DNS) and to allow both outgoing and incoming connections on port 25 (SMTP).” PC Network Advisor
Issue 113 (December 1999) Page 15
about denials that are of much greater concern. If your firewall permits, set up a deny rule for these packets, and set the “Do not log” flag. Now, the packets are still denied, keeping them from streaming onto the Internet, but the firewall’s logs are beautifully clear of all the “noise” and you can go hunting in the logs for more important entries showing where packets were denied.
Authentication Finally, many firewalls will allow you to set up rules permitting access if the users can authenticate themselves. All such firewalls support the standard Unix-like authentication, normally out of the box, but you can also arrange to use one of the Token authentication schemes if you wish, so that the passwords are not transmitted over the network in the clear, and are not re-usable. Applying authentication schemes on rules for most services is not much of a bind. The user will be queried once, and connected if authentication is successful. Since the protocol opens a single socket and keeps it open for the duration of the session, the user is not prompted again until he reconnects for his next session. Now, consider the Web. The normal run of events is that you visit the first page. Your browser may open five or six sockets (depending upon page content) to the target server, the page is downloaded, and all sockets are closed. Now you click on a hyperlink, and your browser fires off some more sockets to download the next page. Now consider this scenario through a firewall which is enforcing authentication. Use of the Web would be a
“Some firewalls manage to provide a compromise between security and user ease of use, should you wish to provide a level of user authentication to a server on the other side of the firewall. It’s a concept the vendors call transparency.”
nightmare and, secure or not, the firewall administrator will find that he has an angry user base. Alienating users is best avoided because they look for ways to subvert security, such as adding modems to their workstations. Some firewalls manage to provide a compromise between security and user ease of use, should you wish to provide a level of user authentication to a server on the other side of the firewall. It’s a concept the vendors call transparency. It works by requiring an authentication on the initial connection. Providing the user successfully achieves this, the firewall then keeps a record of the fact that the user has done so, and from which host they connected to the server from. Then, for a certain length of time (as configured by the Administrator) after this initial connection, further connections from the user’s workstation to the server in question will be granted without further authentication. As you can see, this is clearly a compromise between security and ease of use. Having authenticated, should a user leave his workstation unattended during the “transparency period”, any other user could come along and connect from that machine to the server without being challenged. The vendor ensures, therefore, that allowing transparency on a rule is a fairly complicated thing to configure. Namely, you have to set the transparency flag in each of four places, on the user record, on both the source and destination address records, and on the rule itself.
Installing a firewall may be a fiddly procedure, but getting it right can be invaluable in preventing attack from outside your network, and for controlling your users’ use of the Internet.
“For Unix-based firewalls, you should look for a bootable CD supplied by the firewall vendor, with no requirement to rely on a boot disc from the vendor of your Unix software.”
Neil Briscoe is a network consultant and can be contacted as [email protected]
PC Network Advisor
Click here for more free networking guides
Issue 113 (December 1999) Page 16