What firewalls can do?

Firewalls can do a lot for your site’s security. In fact, some advantages of using
firewalls extend even beyond security, as described in the sections below:

A firewall is a focus for security decisions

A firewall can be thought of as a choke point. All traffic in and out must pass this
single narrow choke point. A firewall gives you an enormous amount of leverage
for network security because it lets you concentrate your security measures on
this choke point: the point where your network connects to the internet.

Focusing your security in this way is far more efficient than spreading security
decisions and technologies around. Concentrating a security is certainly more
effective and less expensive than having inadequate security.

A firewall can enforce a security policy

Many of the services that people want from the internet are inherently insecure.
The firewall is the traffic cop for these services. It enforces the site’s security
policy allowing only “approved” services to pass through and those only within
the rules set up for them.

For example, one site’s management may decide that certain services are simply
too risky to be used across the firewall, no matter what the system tries to run
them or what user wants them. The firewall will keep potentially dangerous
services strictly inside the firewall. Another site might decide that only one
internal system can communicate with the outside world. Still another site might
decide to allow access from all the systems of a certain type, or belonging to a
certain group. The variation in site security policies is endless.

A firewall may be called upon to help enforce more complicated policies. For
example, perhaps only certain systems within the firewall are allowed to transfer
files to and from the internet; by using other mechanisms to control which users
have access to those systems, you can control which users have these
capabilities. Depending on the technologies you choose to implement your
firewall, a firewall may have a greater or lesser ability to enforce such policies.

A firewall can log internet activity efficiently

Because all traffic passes through the firewall, the firewall provides a good place
to collect information about the system and network use – and misuse. As a
single point of access, the firewall can record what occurs between the protected
network and the external network.
A firewall limits exposure

Sometimes firewall will be used to keep one section of the network separate from
the another section. By doing this, you keep problems that impact one section
from spreading through the entire network. This may be done in cases when one
section is more trusted that the other. The existence of firewall thus limits the
damage that a network security problem can do to the overall network.

What firewalls cannot do?

A firewall cannot protect against malicious insiders

A firewall might keep a system user from being able to send proprietary
information out of the organization over a network connection. But that same
user could copy the data onto disk, tape, or paper and carry it out of the building.

If the attacker is already inside the firewall – a firewall can do virtually nothing.
Inside users can steal the data, damage hardware and software, and subtly
modify programs without ever coming near the firewall. Inside attacks require
internal security measures, such as host security and user education.

A firewall can’t protect against connections that don’t go through it

A firewall can effectively control the traffic that passes through it; however, there
is nothing can do about the traffic that doesn’t pass through it. For example, if the
site allows dial-in-access to internal systems behind the firewall, the firewall has
absolutely no way to prevent an intruder from getting in through such a modem.

Sometimes technically expert users or system administrators setup their own

“back doors” into the network (such as dial-up modem connection), either
temporarily or permanently, because they chafe at the restrictions that the
firewall places upon them at their systems. The firewall can do nothing about this.
It’s really a people management problem, not a technical problem.

A firewall can’t fully protect against viruses

Firewalls can’t keep computer viruses out a network. Its true that all firewalls
scan incoming traffic to some degree, and some firewalls even offer virus
protection. However, firewalls don’t offer very good virus protection.

Detecting a virus in a random packet of data passing through a firewall is very

difficult; it requires:

• Recognizing that the packet is part of a program

• Determining what the program should look like
• Determining that a change in the program is because of a virus
Most firewalls are protecting machines of multiple types with different executable
formats. A program may be a compiled executable or a script, and many
machines support multiple, compiled executable types. Furthermore, most
programs are packaged for transport and are often compressed as well.
Packages being transferred via email or Usenet news will also have been
encoded into ASCII in different ways.

For all these reasons, users may end up bringing viruses behind the firewall, no
matter how secure that firewall is. Nothing is done about the viruses coming
through other sources: software downloads, from dial-up bulletin-board systems,
software brought in floppies and even software that comes pre-infected from
manufacturers.

The most practical way to address the virus problem is through the host-based
virus protection software, and user education concerning the dangers of viruses
and precaution to take against them. Virus filtering on the firewall may be useful
adjunct to this sort of precaution, but it will never completely solve the problem.

A firewall can’t set itself up correctly

Every firewall needs some amount of configuration. Every site is slightly different
and it’s just not possible for a firewall to magically work correctly when you take it
out of the box. Correct configuration is absolutely essential. A misconfigured
firewall may be providing only the illusion of security. Unfortunately, many people
have firewalls that are in the end no more effective than that, because they have
been configured with fundamental problems. A firewall is not a magical protective
device that will fix your network security problems no matter what is done with it,
and treating it as if it is such a device will merely increase your risk.

Security Through Obscurity:

Security through obscurity is the principle of protecting things by hiding them.

In computer terms, all of the following are examples of security through obscurity:

• Putting a machine on the internet and figuring nobody will try to break into
it because you haven’t told anybody it’s there.
• Developing a new encryption algorithm and not letting anybody look at it.
• Running a server on a different port number from the one it normally uses.
• Setting up your firewall so that outsiders don’t see the same information
about your hostnames that insiders do.

In fact, obscurity is a perfectly valid security tactic; it’s just not a very strong one.
Security through obscurity is bad when:

• It’s the only security there is

 • There isn’t any real obscurity involved
• It prevents people from accurately determining what level of security a
product provides.
• It gives people irrational confidence.

For instance, making a machine internet accessible, not securing it, and hoping
nobody notices because you aren’t advertising it isn’t security through obscurity.
It’s complete insecurity through almost no obscurity. You are protecting
something important with absolutely nothing but obscurity, and the obscurity isn’t
very good. Not advertising something is not the same as hiding it. This is like
protecting your self being locked out by locking the front door but leaving the
back door open, figuring that nobody will bother to go around and check it.

Least Privilege

Perhaps the most fundamental principle of security is that of least privilege. The
principle of least privilege means that any object should have only the privileges
the object needs to perform its assigned tasks – and no more. Least privilege is
an important principle for limiting the exposure to attacks and for limiting the
damage caused by particular attacks.
Every user probably doesn’t need to access every internet service. Every user
probably doesn’t need to know the machine’s administrative password. Every
system probably doesn’t need to know the administrative passwords for all the
systems. Every system administrator probably doesn’t need to know the
administrative passwords for all systems. Every system probably doesn’t need to
access every other system’s files.

Defense in depth

Another principle of security is defense in depth. Don’t depend on just one

security mechanism, however strong it may seem to be; instead, install multiple
mechanisms to totally compromise your security. Your firewall itself will probably
have multiple layers. For example, one architecture has multiple packet filters; it’s
set up that way because two filters need do different things, but its quite common
to set up the second one to reject packets that the first one is supposed to have
rejected already. If the first filter is working properly, those packets will never
reach the second; however if there is some problem with the first, then with any
luck, protection will be still provided by the second. In situations in which the cost
is low, you should always employ redundant defenses. If the defenses are
redundant they mostly provide protection against failures of one level of defense.

Choke Point

A choke point forces attackers to use a narrow channel, which can be monitored
and controlled. In network security, the firewall between the site and the Internet
is such a choke point; anyone who’s going to attack the site from the internet is
going to come through this channel, which should be defended against such
attacks. A choke point is useless if there’s an effective way for an attacker to go
around. The attacker will not bother penetrating through the firewall when dozens
or hundreds of unsecured dial-up lines could be attacked more easily and
probably more successfully. The remedy is to split the attention among many
avenues of attacks and implement necessary security system.

Weakest Link

A fundamental tenet of security is that a chain is only as strong as its weakest

link and a wall is only strong as its weakest point. Smart attackers seek out that
weakest link and concentrate their attention there. One needs to be aware of the
weak points of the defense so that necessary steps can be taken to eliminate the
same. Attention should be paid equally to all aspects of security and the defense
height at all points should be maintained at an equal height.
However there will always be a weakest link in a security system. The need is to
identify that link and make it stronger. For example, its not proper to neglect a an
FTP service and concentrate more on the telnet service. As the attacker can use
the FTP service for an attack if it remains as a weak link in the security
implementation.

Digging for worms

E-mail isn’t the only way that viruses and worms spread, but it’s one of the most
common. If the user runs susceptible software, a filter is needed for incoming e-
mail. The outgoing emails should also be filtered.

One approach is to screen each piece of the incoming mail on each desktop.
That’s a good idea even if other measures are adopted as defense in depth
always pays. But desktops are often behind in updates, and getting a new
pattern files to them can be difficult.

It’s a good idea to use a different brand of virus scanner for the gateway than for
the desktop. It’s also better to get a good scanner from a vendor who delivers
new patterns rapidly. In some cases it may be required to add our own patterns
There are some legal worms – spam actually, but “legal” because the users
consented to their spread by not decrypting the legalese in the license.

Some antivirus software annoys as much as it protects. A number of packages, if

they detect a virus on a piece of incoming mail, will send an alert to the sender
and all the intended recipients of that mail. It seems to be civic- minded, but it
isn’t as big help as it seems to be. The method can be used by an attacker to
introduce worms by using some forged addresses.
Filtering Services

The decision about what services to filter is based on a desired policy. Some
general rules are specified under these policies. The topic discusses what to filter
and why. A summary of a service from security point of view can be shown as
follows:

protocol Out In Comment

PROT X Y Optional
comment

In this table, legal values for x and y are as follows:

allow -- let it through

block – don’t let it through
filter – an application level proxy should make the decision
tunnel – block the port for PROT, but allow users to tunnel it with more secure
protocol

The out column refers to the decision about outbound traffic for port PROT. For
TCP packets, “outbound” is straightforward; it refers to connections initiated from
inside. “Inbound” refers to connections initiated from the outside.
The meaning is less clear for UDP, because the protocol itself is connectionless.
Furthermore some of the protocols of interest are not simply query/response
services. For query/response services, we can speak of an “inbound query”,
which elicits an “outbound response”; similarly, “outbound queries” elicit “inbound
responses”. For protocols that do not fit this model, we can speak only of inbound
and outbound packets.

Responsible Services to Filter

DNS:
DNS represents a dilemma for the network administrator. We need information
from the outside, but we don’t trust the outside. Thus, when we get host name-to-
IP address mappings from the outside, it is best not to base any security –
related decisions on them. To be more precise, we absolutely must not trust such
information for internal purposes, though we may have to rely on it for something
like sending sensitive e-mail to external partners.

This has some consequences. Although under some circumstances it might be

okay to do name-based authentication for internal machines, it is never
acceptable for external machines. We must also ensure that no other internal-to-
internal trust relationship depends on any information learned from the outside.
The basic threat is simple: Outsiders can contaminate the DNS cache, notably by
including extraneous information in their responses. The rules for outbound DNS
queries can be summarized as follows:

protocol Outbound Query Inbound Query Comment

DNS Allow Filter Block internal
info

The best way to filter DNS is to use a DNS proxy that does two things. First, it
redirects queries for internal information to internal DNS servers. Second it
censors inbound responses to ensure that no putatively internal information is
returned.

Inbound queries are simpler: Put the DNS server in DMZ. The rule can be given
as follows:

protocol Outbound Query Inbound Query Comment

DNS Allow DMZ

Dealing with the DNS is one of the more difficult problems in setting up a firewall,
especially if you use a simple packet filter. It is utterly vital that the gateway
machine use it, but it poses many risks.

Web

It is a good idea to use proxy filtering to scan for hostile applets and viruses.
Depending on the security policies you may want to block some Activex controls
as well. The firewall should not allow incoming HTTP traffic, except to your
official Web servers. Of course the web server should be in DMZ. The rule as
allows:

protocol Outbound Query Inbound Query Comment

Web Allow Block Put web server in DMZ

An alternative ruleset, if you require insiders to use an internal Web proxy. In this
case the rule will be:

protocol Outbound Query Inbound Query Comment

Web Filter Block Put web server in DMZ
FTP

FTP is a tricky protocol. Because by default FTP uses PORT mode, which
requires a separate, incoming connection, many stateful firewalls open a hole
allowing incoming connections to an internal machine. This has been shown as
perilous. A better idea is to require PASV FTP for outbound connections. Most
browsers run in passive mode. Do not allow inbound FTP connections, and place
the FTP server in DMZ. The rule is as follows:

protocol Outbound Query Inbound Query Comment

FTP Passive Block Put FTP server in DMZ

In order to handle PORT mode, even dynamic packet filters need an application
proxy. Some of them try to get away with looking at just one packet at a time,
rather than reassembling the TCP stream. Looking at a single packet can break
things, if the sender has split data across multiple packets.

TCP

Although the insiders might be trusted, it is not always certain that the code they
are running is behaving properly. Applets running on users’ machines are
considered insiders. Signed applets can be granted privileges by naïve users;
these allow the applets to talk to the file system and connect to arbitrary places
on the network. The TCP connections from these applets come from the inside.

There are other ways that bad things can originate from the inside. Assume that
the mail filter is weeding out viruses and worms. That only works if users obtain
their mail via POP3 or IMAP. If mail is read through a web-based server (such as
hotmail), there is little to prevent the poor user from infection via these vectors.
Once hit, the inside machine may generate problematic outgoing TCP
connections.

Disallowing outgoing TCP is draconian, and represents a restriction that is

probably too strong. Conversely, highly sensitive government sites may have
confidentiality requirements on their data that justify such policy.

Incoming TCP connections should not be allowed. If there is a strong need for
access to an internal machine from the outside, this should be handled via a
dedicated proxy, often from a machine on the DMZ. If possible use
cryptographically enhanced services such as ssh. It is also best to limit the sets
of machines that can be reached; and, if possible, the set of machines that can
initiate access. The filtering rule for TCP can be summarized as follows:
protocol Outbound Query Inbound Query Comment
TCP Allow Block Generally trust insiders

SMTP/Mail:

There are two common reasons to restrict outbound SMTP traffic. In the old days
of the internet, badly formatted e-mail messages were common, and an outgoing
filter could clean up or reject incorrect message formats. You may also wish to
check outgoing mail for viruses, strange attachments, or even corporate secrets.
An alarm for virus in outgoing mail may be your first clue that a virus is running
around your intranet. Mail programs have been notorious for security problems,
so be sure to keep up with the latest security alerts and patches for your mail
software.
Some organizations try to scan outbound mail for secrets and dirty words. ISPs
have another reason to block outgoing SMTP service, even if they block nothing
else. Spammers find open hosts (“open relays”) or use dial-up access and send
thousands of unwanted e-mail messages from them. Proactive ISPs suppress
this activity that has messy user populations. Of course, legitimate users may be
blocked from accessing their home SMTP servers. If none of these issues is a
concern, then outbound SMTP can be allowed, unfiltered. The rule is as follows:

protocol Outbound Query Inbound Query Comment

SMTP Allow filter

POP3/IMAP
Inbound POP3 and IMAP are used by outsiders attempting to get mail that is on
the inside. These protocols should be blocked. There is almost certainly sensitive
internal content that shouldn’t be exposed to prying eyes. Its not a good idea to
allow internal users to access external POP3/IMAP servers.
The rule looks as follows:

protocol Outbound Query Inbound Query Comment

POP3/IMAP Filter Tunnel Block active content

Filtering By Service

Blocking incoming forged packets, as discussed previously, is just about the only
common use of filtering solely by address. Most other uses of packet filtering
involve filtering service, which is somewhat more complicated.

Packet filtering with respect to Telnet can be explained as given below:

OUTBOUND Telnet Service:

In this a local client is talking to a remote server. The outgoing packets for this
outbound service contain the users’ keystrokes and have the following
characteristics:

• The IP source address of the outgoing packets is the local host’s IP

address.
• The IP destination address is the remote host’s IP address.
• Telnet is a TCP based service, so the IP packet type is TCP.
• The TCP destination port is 23; that’s the well-known port number Telnet
servers’ use.
• The TCP source port number (Y) is some seemingly random number
greater than 1023.
• The first outgoing packet, establishing the connection, will not have the
ACK bit set; the rest of the outgoing packets will.

The incoming packets for this outbound service contain the data to be displayed
on the user’s screen and have the following characteristics:

• The IP source address of the incoming packets is the remote host’s IP

address.
• The IP destination address is the local host’s IP address.
• The IP packet type is TCP.
• The TCP source port is 23; that’s the port the server uses.
• The TCP destination port is the same “Y” we used as source port for the
outgoing packets.
• All incoming packets will have the ACK bit set

INBOUND Telnet Service:

In this a remote client communicates with a local Telnet server. Both the
incoming and outgoing packets need to be handled.

• The IP source address of the outgoing packets is the remote host’s

address.
• The IP destination address is the local host’s IP address.
• Telnet is a TCP based service, so the IP packet type is TCP.
• The TCP source port number (Z) is some seemingly random number
greater than 1023.
• The TCP destination port is 23.
• The first incoming packet, establishing the connection, will not have the
ACK bit set; the rest of the incoming packets will.
The outgoing packets for this outbound service contain the data to be displayed
on the user’s screen and have the following characteristics:

• The IP source address is the local host’s IP address.

• The IP destination address is the remote host’s IP address.
• The IP packet type is TCP.
• The TCP source port is 23; that’s the port the server uses.
• The TCP destination port is the “Z” that was used as source port for
inbound packets.
• All outgoing packets will have the ACK bit set.