together with other hosts on the network, need to be configured
correctly to work well. by Graeme K Le Roux
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".
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
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.
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
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.
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
Security by Kaufman, by Perlman and Speciner, published
by Prentice Hall. An excellent book on security
concepts and issues.
of all trades, master of none
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
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
If your chosen supplier falls too far behind or
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
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
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
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
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.