Internet Firewall Essentials
by Eric Hall
Additional Security Measures
Build Bi-Directional Filters
One potential solution to this problem is to build bi-directional filters
into your firewall. You may want to define the filters so that you only
allow packets that are from well-known services into your network, and reject
any packets that are not from specific applications. For example, if you
know that your users will be accessing World Wide Web servers, then you
could only allow packets that have a source port number of 80 into the network,
as illustrated below.
Unfortunately, there are a couple of problems with this solution as well.
First of all, you don't always know what port numbers the servers that you
are trying to access are running on. Modern day servers such as HTTP and
Gopher are completely configurabl
e in this manner, allowing you to run them
on any port that you want to. If you implement this type of filter, then
your users will not be able to access those sites that do not use the "standard"
port numbers that you expect them to.
Another security problem comes from the fact that there is no way for you
to know for sure that the packets coming into your network from port 80
are indeed response packets from a World Wide Web server. Some hacker may
have compiled their own network invasion tool that runs on port 80 on their
machine, thereby making their insidious data look perfectly harmless, at
least to your firewall anyway. If they can get into your network just by
setting their application's source port manually, then they can do whatever
they want with the vulnerable systems, and your firewall will be useless.
Check the ACK Bit
If you can't trust the source IP addresses, and you can't even trust the
source port numbers, then it doesn't seem like you can do much in the way
of protecting your network from intruders. However, there is one fool-proof
mechanism that you can use reliably, although only with TCP.
TCP is a "reliable" protocol that supports error-correction and
other robust capabilities. To achieve this reliability, every TCP connection
begins with a handshaking sequence that establishes specific parameters
of the connection. Also, every packet that gets sent must be responded to
with an acknowledgment before another packet will get sent.
Rather than generate special-purpose ACK packets for every TCP packet, a
special bit in the TCP header is used for just this purpose. Therefore,
whenever a response packet is generated, the ACK bit gets set, and a marker
is noted to indicate what packet the ACK is for. The very first packet in
a negotiation is not acknowledging anything, and so it does not have the
ACK bit set. However, every subsequent TCP packet in an exchange must have
the ACK bit set for the connection to be maintained.
For example, if the PC opens a connection with a remote World Wide Web server,
it generates a connection request packet that does not have the ACK bit
set. When the server responds to this request, it sends a packet with the
ACK bit set, and with the marker set to the number of bytes received from
the client. The client then responds to this packet with its own response
packet, which also has the ACK bit set and with its own marker also set
to the number of bytes of data received from the server. The figure above
illustrates this series of events visually.
By monitoring the ACK bit, you can limit the types of incoming data to only
response packets. This means that a remote system cannot initiate a TCP
connection at all, but can only respond to packets that have been sent to
it.
Nor can an outsider manually set the ACK bit for their first packet, thereby
blowing past your security. The receiving node will see that the packet
is an acknowledgment for a packet that it sent (referenced by the marker)
and will discard it, as it would not be able to recall any such packet ever
being sent.
This one trick by itself can go a long way towards protecting your network
from invasion. If you can configure your firewall so that it will only give
entrance visas to TCP packets that have the ACK bit set, then you are guaranteeing
that no packets that have not been explicitly requested will arrive on your
internal network.
This mechanism is not a panacea however, and is not usable in several situations.
For example, if you have an internal World Wide Web server or some other
data that you wish to provide on a public basis, then you would have to
open port 80 (or whatever ports were to be used) so that external requests
for connections could come into your network. Also, monitoring TCP packets
for the ACK bit doesn't help at all with UDP packets, as they don't have
any ACK bit. Some TCP applications are d
esigned so that they initiate some
connections, and these applications cannot work across a firewall that does
not allow incoming connections. One such program is FTP.
The Problem With FTP
Unlike most of the Internet services that use a single pair of port numbers
for all communications, FTP uses two pairs of port numbers during connections.
The first pair is used for the FTP "command channel" that provides
a communications line for logging in and executing commands, while the other
pair is used for the FTP "data channel" that is used for sending
files or directory listings between the client and server.
During a normal FTP session, the client will send a TCP connection request
to port 21 (the "command" channel) on the server, and then execute
commands such as LOGIN, DIR, and the like. Once the user requests that data
be sent, the FTP server uses its local port 20 (the "data" channel)
to initiate a connection to the client's "data" port. This presents
a spectacular problem. If the server is going to initiate a connection to
the client for the data transfer, then it will send a packet that does not
have the ACK bit set, meaning your firewall will reject it, and thus the
file transfer will never get started, much less finished. Only an advanced
firewall will recognize that the client does actually tell the external
server which port to use, and thus the firewall will allow incoming connections
for ports that it has seen the client tell the server to use.
There is a workaround for this scenario however. Many FTP clients and servers
support the use of "passive mode" file transfers (named after
the PASV command), which allow the client to initiate the file transfer
connection. Rather than the server using port 20, when it receives the PASV
command it allocates a port above 1023, and informs the client of its choice
(via the command channel). The client then initiates the TCP connection
to the port number provided, and the serve
r then begins to transfer data.
Not all clients or servers support the PASV command, so this won't work
in all situations, although it is becoming much more common. Almost all
Web browsers use PASV mode by default, and almost every FTP client worth
looking at supports it as well.
UDP Port Filtering
As I said earlier, monitoring the ACK bit in incoming TCP packets is a very
effective way to allow outbound TCP connections. However, UDP doesn't offer
this type of capability, since it does not have any ACK functionality. UDP
is designed for unreliable transmissions which do not require or benefit
from negotiated connections. These types of services generally include broadcasts,
routing protocols, and other "maintenance" packets that advertise
services. Unfortunately, there are lots of other services that use UDP as
well, including NFS, NTP, DNS, WINS, NetBIOS-over-TCP/IP, and NetWare/IP.
These types of services can be corrupted pretty easily, or used as launching
pads for additional attacks on your network.
One possible solution to this problem is to simply not allow any incoming
UDP connections. To enable this functionality, you need to be able to configure
your firewall so that it will forward UDP packets received from the internal
interface, but will not forward UDP packets received from the external interface.
While this will certainly prevent any incoming UDP connections, it will
not always be feasible.
For example, DNS name resolution requests use UDP, so if you are providing
your own DNS services, then you must allow at least some internal connection
requests to pass through your firewall. Also, there are client applications
like Archie and IRC which use UDP, and if you want to provide them to your
users you will need to let the appropriate response packets into your network.
You'll need to provide for some sort of UDP connectivity, whether it is
for end-user applications or for system level services like DNS. About the
only thing that you can do is to limit t
hese connections to somewhat "trusted"
sites. For example, you may want to filter DNS so that only UDP packets
between your internal DNS server and your ISP's DNS server are allowed to
cross the wire. Likewise, you could filter Archie packets so that only the
UDP packets from a specific Archie server were allowed into the network.
Talk, being a relatively uncontrollable application, is not easily configurable
for filtering, and would likely have to be cut off altogether.
There is a risk with allowing even well-known hosts to send packets into
your network, however. If a hacker can spoof the IP address of the host
that you have given clearance to, then they can take advantage of your internal
system, albeit to a limited degree. A new breed of packet-filtering routers
are becoming available that attempt to solve this problem by "remembering"
outbound UDP packets. If an incoming UDP packet matches the destination
address and port number of a recent outgoing UDP packet, then it is allowed
in. If no recent packet can be found in memory, the firewall will reject
the packet.
Again, the fundamental problem with this approach is that there is no way
of knowing for sure that the outside host generating the packet is indeed
the service that the internal client is expecting to communicate with. If
a hacker were to spoof the IP address of your ISP's DNS server, then they
could theoretically launch an attack from the UDP port associated with DNS.
However, this particular weakness would exist anyway if you were filtering
UDP packets so that only DNS queries and results from your ISP were allowed
into the network. Your situation is neither improved nor degenerated by
deploying these dynamic packet-filtering products.
Updated November 15, 1996
|
