Home > Focus: Firewall Configuration
 Print Friendly Page ||  Email this story
Firewalling: Plan before you leap

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 "".

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.

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.

Useful books:
Hacker Exposed by McClure, by Scambray and Kurtz and the associated website at www.osborne.com/hacking
Building Internet Firewalls, by Chapman and Zwicky, published by O'Reilly. Good practical guide to the subject.
Network Security by Kaufman, by Perlman and Speciner, published by Prentice Hall. An excellent book on security concepts and issues.

Jack of all trades, master of none
Firewalls don't come alone these days. In the last few months, established and upstart hardware companies have introduced multi-function Web devices that combine several functions into a single box-including load balancing, encryption acceleration, caching and firewalling. Their ostensible appeal arises from the fact that they reduce the total number of devices and vendors that a Web infrastructure staff must manage. Also, by bundling several functions into a single package, these products can usually offer more technology at a lower price than can be had by buying separate devices.

However, while reducing complexity and getting better value are worthy goals for network buyers, there are several factors to consider before you enroll in the Swiss Army knife school of infrastructure provisioning.

Firstly, if you invest in a multi-function device, then you're trusting the supplier of that device to maintain some degree of technological parity with other vendors who specialize in each of those functions.

If your chosen supplier falls too far behind or fails to support a new standard, you may question your decision down the road. It's also possible that a new type of device may emerge or that your company's requirements may change to necessitate an additional Web function. If that happens and you will still wind up having to add a device from another vendor, the benefits of consolidation will largely evaporate.

Then there's the question of whether it really is easier to manage a single, complex multi-function device than it is to manage several separate single-purpose devices.

After all, if a multi-function device has poorly designed management software, indecipherable documentation, and weak technical support, it doesn't matter that it bundles lots of functions in a tight little hardware package. If, on the other hand, you buy several separate devices that provide highly-intuitive software tools and great online technical assistance, your management headaches may be few and far between. Integration doesn't automatically translate into ease of ownership.

Another issue is division of labor. A networking team's ability to solve infrastructure problems is often dependent on its expertise and experience with underlying technologies not its ability to administer a box. That's why corporate technology managers try to develop specific technical expertise among their team members.

Also, infrastructure management tends to be highly territorial. Servers in a given department or certain types of switches usually become a specific technician's "property". Multi-function devices create a conflict between these two cultural imperatives of IT. Do you really want several pairs of hands messing with the device, depending on whether a site performance or security problem is being addressed? Or do you want to give "ownership" of the box to one person and have that person delegate issues outside his or her area of expertise to someone else?

Eggs in one basket
For small companies that have a few generalists taking care of their entire infrastructure, the convenience and economy of a multi-function device may be quite appealing. But such companies usually use a simple colocation service combined with some kind of third-party management support. For these companies, the question is whether their management partner-of-choice has any competency on such non-standard devices.

Service providers build their value proposition on the commonality of their customers' technical requirements. The use of an exotic multi-function device may well disqualify a company from participating in that value proposition.

The bottom line is that corporate buyers should be careful about putting too many of their eggs into one vendor's basket. Managing multiple devices from multiple vendors is definitely hard work, but it also reduces the risk.

For information on types of attack, go to the Computer Emergency Response Task Force website at www.cert.org

For RFD's on SMTP and other protocols which you may need to secure, go to the Internet Engineering Task Force Web site at www.IETF.org

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.

- <Back to Top>-  

Copyright 2001: Indian Express Group (Mumbai, India). All rights reserved throughout the world. This entire site is compiled in Mumbai by The Business Publications Division of the Indian Express Group of Newspapers. Site managed by BPD