Firewalls and Tardis∗
January 19, 2004
Firewalls are being used to mediate traﬃc between most organisations
and the Internet, and increasingly between home computers and the
This talk aims to give an overview of ﬁrewalls and our use of Linux
ﬁrewalls in the Tardis project, in particular the recent ﬁrewall related
Note that I am not an expert in ﬁrewalls. Sorry.
The aim of a ﬁrewall is to enforce a given policy (i.e. a set of rules)
on network traﬃc crossing it.
This helps to protect internal services from unauthorised external use
and prevent accidental exposure of services or information to the
Users can often see ﬁrewalls as too restrictive. Tension leads to
protocols designed to bypass ﬁrewalls (e.g. SOAP). . .
Limitations of ﬁrewalls
Firewalls are not an absolute solution to network security problems.
There are various ways for information to pass through or around
them (laptops, virtual networks / tunneling). Preventing covert com-
munications between an insider and the outside world is far beyond
the scope of ﬁrewalling.
Tradeoﬀs between complexity, performance and functionality are nec-
essary. We will see this happening with some protocols later.
Firewalls in networks
Firewall (arbiter of packet justice)
Local Network (poor, vulnerable, innocent)
A simple setup partitions networks in two, controlling only traﬃc
passing to and from the Internet.
Firewalls in networks 2
Firewalls let lots through, even when working properly.
Firewalls in networks 3
Web server Mail server
More complex setups further partition to allow ﬁner control. The clas-
sic setup is a ‘demilitarized zone’ (DMZ) where hosts which provide
external services live.
All Internet traﬃc is carried in packets according to the
Internet Protocol (IP). Lowest common layer; all the
TCP ICMP UDP
other protocols are built on it. IP addresses are carried
in this layer.
(IP packets can become fragmented during transmis-
sion, and usually need to be reassembled before apply-
ing the ﬁrewall rules. This is typically automatic.)
User Datagram Protocol (UDP) provides simple packet transmission.
Usually used where the application requires low overhead or timely-
TCP/IP overview 2
Traﬃc Control Protocol (TCP) forms a ‘virtual circuit’ (i.e. stream)
connection, handling all the reassembly and retransmission for the
Both UDP and TCP have ‘port’ numbers to identify the ends of the
connections. IANA maintains the oﬃcial allocations of port numbers
where services can be expected to be found (e.g. HTTP on port 80),
although clients can typically come from any port.
The Internet Control Message Protocol provides services relating to
IP (e.g. destination unreachable). Be very careful about blocking
ICMP packets, as it may have subtle consequences.
Simple ﬁrewalls examine each packet in isolation. So to block TCP
connections the (SYN) packets which initiate the connection are con-
trolled. All other TCP packets pass through.
Other protocols are more diﬃcult. Is that UDP packet a response
to something we asked? Also, higher level protocols (e.g. FTP) may
use multiple connections.
Stateful ﬁrewalls remember details about connections, and so can
cope with these situations. Also useful for features like Network Ad-
dress Translation (NAT). (So we trade greater complexity for more
In Linux, this is called connection tracking.
Actions on errant packets
Dropping (discarding) packets is generally safe, but is a nusiance and
makes problems more diﬃcult to diagnose. (Has the machine died,
or is it just dropping our packets?)
Rejecting packets (with an ICMP message) makes the response clear,
but produces more network traﬃc.
Logging packets is extremely useful for diagnosing problems and notic-
ing abuse. However, logs can grow large unexpectedly.
Rate limiting of log messages helps prevent this. Rate limiting packets
can also be useful.
Our router currently hosts too many services. One being compro-
mised would allow all the internal and external network traﬃc to be
Worse: the ﬁrewall rules allowed external access to all those services!
Due to the holiday only remote access was available—all of which
goes through the ﬁrewall. However, there is a failsafe mechanism to
allow recovery after two minutes.
Linux on Sparc is a minority platform.
What should I have done?
I put the ﬁrewall script under the Revision Control System (RCS) so
that changes would be recorded and could be backed out.
I tightened up the rules to reject by default.
After applying the rules, everything appeared to continue normally.
Forgot to disable the failsafe, so reapplied the rules after two minutes,
without the failsafe this time.
After several more minutes all the network traﬃc stop responding.
What went wrong?
What went wrong?
A daemon on the ﬁrewall machine maintains a table of routes to
other networks based on information from the Informatics network.
Old routes are removed if they have not been seen for some time.
This information passes through the ﬁrewall.
But there was no rule explicitly allowing it through, so the tightened
ﬁrewall rejected it.
What should I have done?
What should I have done?
I should have checked which services the machine was running.
I should have checked the rejected packets on trial runs before dis-
abling the failsafe mechanism.
I should have set up the new router earlier.
Network Address Translation (NAT) allows addresses and port num-
bers to be rewritten on the ﬂy. Useful for sharing a single IP address
or redirecting a service.
Application proxies provide a useful alternative or supplement to ﬁre-
walls. They often provide better separation of networks.
‘Personal’ ﬁrewalls have become popular, providing per-machine con-
trol. Better yet, many provide per-application control. (Some Unix-
like systems provide features which essentially ﬁrewall processes from
the rest of the system, e.g. systrace and SE Linux.)
Related topics 2
Intrusion detection systems watch network traﬃc for dodgy data.
Reading the ﬁrewall logs is a poor-man’s version of intrusion detec-
Firewalls can also change the contents of packets. More usefully, they
can set ﬂags in packet headers indicating priority, etc.
Traﬃc shaping (rate limiting) can keep bandwidth use under control.
We might get a Cisco ﬁrewall/router/toaster at some point, in which
case someone will have to set it up. This would be good experience,
especially given that it’s much harder to obtain than Linux/ipﬁlter/etc
Play machines (or virtual machines) could probably be made available
if people want to try this stuﬀ out.
You can look at, comment on, and help out with the Tardis ﬁrewall
The Linux netﬁlter web pages, in particular the Packet Filtering
RFC 2267, Ferguson and Senie, Network Ingress Filtering. Why
you should enforce the right IP addresses from network interfaces.
Other RFCs deﬁne most of the standards for Internet network com-
munication. (IP, ICMP, TCP, UDP, DNS, HTTP, SMTP, FTP, . . . )
IANA (http://www.iana.org/) hold oﬃcial protocol lists.
CERT Security Improvement Module Deploying Firewalls. A dry
overview, but decent looking references.