Firewalls, together with other hosts on the network, need to be configured correctly to work well. by Graeme K Le Roux

The firewall is probably one of the most misunderstood, misused and wrongly configured element of networks today. Much of it has to do with how the industry presents the concept of firewalls, which is essentially a picture of a wall guarding a "protected" network on the other side.

Now, this is not only simplistic, it is also misleading. Firewalls are simply devices with two network interfaces. It does not discriminate between "public" or "private" networks. And a properly-configured firewall protects the public network from the private just as much as it protects the private network from the public one. A better way to think of firewalls is the use of them as secure "zones".

Firewall definitions
A firewall governs access between its interfaces by allowing or disallowing connections or data packets flowing over them. A basic model firewall makes decisions about whether or not to allow a connection from one network interface to another based on a simple set of rules contained in a static table. Such devices usually have two simple rules: Rule 1-disallow any connections from the Internet to the local LAN and, Rule 2-allow any connection from the local LAN to the Internet.

Note that Rule 1 does not necessarily imply Rule 2 and vice versa. Also note that in most cases, Rule 1 will be superfluous as firewalls generally assume everything is disallowed unless explicitly told otherwise. These types of firewall are usually referred to as "filter-based" firewall, where the filters are defined by Rules 1 and 2.

Of course, one can filter on criteria other than where a connection originates. For example, one can filter on IP address. You might do this if you wanted to make sure that only selected hosts on your company network have Internet access.

One can also filter based on TCP/IP port number. You can do this if you have an Intranet mail server through which you want to send SMTP mail to the Internet but do not want it to have any other Internet access. Additionally, you may not want any other hosts on your network to have Internet access.

How does one assert control over such a mail server-for example, mailhost.company.com?
If you have a firewall with two interfaces (called external for the Internet and internal for Intranet), you can write the following rule: mailhost.company.com on internal, TCP port 25, to * on external-allowed.

By configuring TCP port 25 for SMTP, it means that the mailhost can make a connection to anyone on the Internet using SMTP. Note that the "*" is a wildcard which means all hosts; some firewalls use "all" or the more formal "0.0.0.0".

But such a filter does not allow external hosts to send mail into the mailhost. And this state is rather useless as it means nobody can send mail. To correct this situation we would add the following rule: * on external, TCP port 25, to mailhost.company.com-allowed.

But this last rule also allows an external host to Telnet to our mail host via TCP port 25. This is one of the oldest tricks in the book and a basic way of testing an SMTP server.

We handle this problem in one of two ways: either we set the firewall to be aware of the difference between SMTP and Telnet by looking at the packet header (which most firewalls do), or we make sure the mail host cannot understand telnet.

Having constrained our firewall or mail host to respond only to SMTP on TCP port 25, we still have three problems. Firstly, there is a class of attacks which a malicious host may make on our mail server that exploit weaknesses in the SMTP protocol and various implementations of it, known as "SendMail" attacks. Secondly, valid SMTP messages can contain all sorts of viruses or trojans. And thirdly, you may still be the victim of Denial of Service (DoS) attacks in which someone simply overloads your server with, for example, connection attempts.

Many filter-based firewalls have adaptive logic in them which allows them to recognize common forms of attacks by the attacks' characteristic traffic patterns, with DoS-type attacks being commonly among them. In such cases, these firewalls will simply block all traffic from the source of a recognized attack. This will stop your mail server from being overloaded and subsequently crashing, but it will not stop the attack. You can do that by having your ISP set their routers to filter such traffic before it gets to the firewall.

Stopping protocol-based attacks like SendMail requires a different form of firewall a proxy-based firewall. Proxy-based firewalls are purpose-built hosts which run a series of protocol-specific proxy services, such as SMTP and HTTP.

The proxy firewall is in fact a stripped-down SMTP server with a carefully-limited command set designed to defeat common types of attack. Proxy-based firewalls are generally slower than filter-based devices and they are often more expensive as well, but they are arguably more secure.

Sans firewall
But do you really need a firewall here? In most cases, your mail server is likely to be sitting behind a standard router which is quite capable of filtering all connections other than those made to or from a specific host (i.e. your mail server in this instance). For that, you can configure the mail host with two network interfaces; connect one directly to the Internet and the other to your Intranet. In most cases, it is relatively simple to configure the mail host's external interface to respond only to connections on TCP port 25.

In most Unix (or Linux) SendMail implementations, you can also limit the SMTP commands your server supports and remove telnet, ftp, etc. services from the host. In fact, your host will run much faster if you do. You can also remove any routing capability so that the host cannot route traffic between its interfaces and any remote execution support (the "r" series of commands in Unix). You then bind POP3 and IMAP4 services to your host's internal interface only and SMTP to both its interfaces.

Presumably you would use reserved addresses on your host's internal interface. The result? An Internet mail service which is just as secure as the firewall-based solution but at a fraction of the cost and complexity. If you want to give your users full Internet access, you can use more or less the same approach with a caching Web proxy. If you want to run a public website, as opposed to having your ISP host one for you, the same approach applies.

Insurance
These days most companies want to provide an Internet e-mail connection, Internet access for all employees and setup some form of public website. In most cases, the solution is to pick a reputable ISP to host the website and act as a secondary mail server and DNS, then configure an SMTP server and Web proxy server as discussed above, perhaps with the added insurance of a "firewall" appliance rather than a simple router.

Among popular firewall appliances are Cisco's PIX family, 3Com's OfficeConnect Internet Firewalls, SonicWall and Watchguard. Most of them are filter-based devices aimed at either networks with less than 100 users or larger enterprises which need to deploy multiple firewalls, or wish for a rack mount format. In the latter, firewall management is via a network-based application interface, while with the former, management is generally spawned from an embedded Web server.

In both types of appliance, users can write simple rules using pre-defined protocols such as SMTP, HTTP, etc. In most cases, users can also add their own protocol definitions to cope with such things as VPN pass-through.

This feature may be absent in devices intended to protect home users with permanent Internet connections via broadband services such as cable or ADSL. Most firewall appliances also provide an Internet-based update facility that works in much the same way as antivirus software updates do.

That said, using a firewall appliance in most cases is simply just an insurance against something being overlooked in a properly-configured host.

In fact, you may not need firewalls at all. There are situations in which firewalls are required some sort of security is always required but do figure out just what you are trying to secure before you spend stacks of money on a firewall which you may not need at all. It may not do what you think it will.

Graeme K. Le Roux is the director of Morsedawn (Australia), a company which specialises in network design and consultancy and writes for Network Computing-Asian Edition.