Firewalling with Linux

Many companies — and certainly those who we work with - have an historical problem lurking in the wings. When they first developed and deployed their internal networks, they chose IP addressing schemes that conflict with those assigned to machines connected to the Internet. To use the common term, they are using "illegal" network addresses. This is not usually a problem until there is a need to connect to the Internet - when it becomes a severe nuisance. Amongst the practical problems caused are the need for address translation or a proxy on the firewall. Unfortunately this is not enough by itself.

Imagine that you have chosen a network address internally of 2.0.0.0 — a class A address. You install a proxying system between your network and the Internet, as in the picture. The host is dual-homed, one side seeing the 2.0.0.0 network and the other the Internet. This works most of the time, but since the host can see the 2.0.0.0 network, anything on the outside world which uses that address will be inaccessible because the host will have the wrong routing. In other words - it is not a solution.

It is a poor solution from the security point of view too; if anyone compromises the single host then your entire internal network is potentially accessible to them. This solution is weak whether it involves the use of proxies or address translation.

Although there are a number of ways to solve the problem, ours has many merits. It is simple, cheap and easy to configure. It also works and does not need much maintenance — essentially it is fit-and-forget.

We use a twin-proxy firewall configuration. At the point marked `P' a reserved private address is used (we usually pick 192.168.0.0 unless there is a reason not to). This is one of the range of addresses guaranteed never to be allocated for public use. The inner proxy host sees only the unauthorised network and the private address `P'. The outer proxy only sees `P' addresses and the outside world. There are no routing problems.

This approach also makes it more difficult to compromise your internal network security. With two hosts needing to be attacked it is very difficult for unauthorised access to be gained from the public network — anyone serious about intruding is much more likely to employ non-technical methods to obtain entry.

Using a configuration like this it is simple to set up and control web access for staff inside the firewall — they simply point their browsers at the proxy on the inner firewall machine. This setup also provides an excellent email service if wanted. Using any one of a number of mail programs such as the free Eudora or Microsoft Mail (which comes as standard with Win95 etc.) and by setting up mailboxes on the firewall, full email access for the whole business can be served from the inner host for populations of up to many hundreds of users, including mailing list expansion and servicing multiple email domain names. Some organisations also choose to run the Samba software so that the inner system can provide file and print sharing services for Windows PCs.

The external connection to the Internet can be via ISDN dial-up, using either a slot-in card on the outer proxy host or a separate external router. If the usage grows to the point where a permanent connection is required, there is no need to go to the extra expense of purchasing a leased-line router; an X.21 card can be plugged into the host instead.

The system is based on two machines running Linux from Red Hat (Release 5.1). Each machine contains two Ethernet cards, and runs both sendmail and Squid. The inner of the two machines will accept only telnet, FTP, mail and web requests (via Squid). It will only accept such connections from the machines on the internal network or (optionally) from the outer machine. Telnet and FTP requests are handled by the standard Linux telnet and FTP daemons. Web requests are only accepted if they are directed to the squid proxy on the inner machine. This squid has been told that it is behind a firewall and that it must forward all requests to the squid running on the outer machine. Since the outer firewall machine is not visible to any of the machines on the internal network web requests are forced to go through the squid on the inner machine. In addition to acting as a proxy, the inner machine's squid acts as a cache, which speeds up requests to commonly visited sites and cuts down on bandwidth usage. This squid can also be configured to log and control access based on user ID and destination site (though most users choose not to do so). Comprehensive access logs are maintained so that undesirable use — such as access to unsavoury websites - can be monitored. The outer of the two machines will accept only mail delivery requests from the outside world, thus providing protection against unwanted connections. It will accept FTP and telnet connections from the inner firewall machine, allowing remote maintenance of the machine. It will also handle web requests via its own copy of squid, thus providing web access. Mail is handled in a similar waterfall fashion. The proxy (sendmail) on the outer machine accepts mail for the relevant domains, but simply forwards it to the proxy running on the inner firewall machine. In turn, this sends the mail on to the machine(s) on the internal network that actually handle the mail. At a modest reduction in security protection it can alternatively provide full mail servicing facilities itself. Outward bound mail is handled similarly with the mail machine on the internal network forwarding outward bound mail to the inner firewall machine. This in turn sends it to the outer firewall machine which sends it on to a relevant mail host, for example an ISP's mail host or the eventual recpient system. All of the software used in this system is available free of charge and most of it is covered by the GPL public licence allowing free copying, distribution and modification subject to some conditions (see the Gnu website). This is software which is in use in thousands of mainstream Internet Service Provider organisations throughout the world. Unlike most proprietary software, it is open-source (i.e. the source code is available) and as a consequence is extremely well supported, proving to be the most reliable and secure software available for this type of application.