|
| |
Firewall FAQ II
* 4 Various Attacks
o 4.1 What is source routed traffic
and why is it a threat?
o 4.2 What are ICMP redirects and
redirect bombs?
o 4.3 What about denial of service?
o 4.4 What are some common attacks,
and how can I protect my system
against them?
+ 4.4.1
SMTP Server Hijacking (Unauthorized Relaying)
+ 4.4.2
Exploiting Bugs in Applications
+ 4.4.3
Bugs in Operating Systems
* 5 How Do I...
o 5.1 Do I really want to allow
everything that my users ask for?
o 5.2 How do I make Web/HTTP work
through my firewall?
o 5.3 How do I make SSL work through
the firewall?
o 5.4 How do I make DNS work with a
firewall?
o 5.5 How do I make FTP work through
my firewall?
o 5.6 How do I make Telnet work
through my firewall?
o 5.7 How do I make Finger and whois
work through my firewall?
o 5.8 How do I make gopher, archie,
and other services work through
my firewall?
o 5.9 What are the issues about X11
through a firewall?
o 5.10 How do I make RealAudio work
through my firewall?
o 5.11 How do I make my web server
act as a front-end for a database
that lives on my private
network?
o 5.12 But my database has an
integrated web server, and I want to
use that. Can't I just
poke a hole in the firewall and tunnel that
port?
o 5.13 How Do I Make IP Multicast
Work With My Firewall?
* A Some Commercial Products and Vendors
* B Glossary of Firewall-Related Terms
* C TCP and UDP Ports
o C.1 What is a port?
o C.2 How do I know which application
uses what port?
o C.3 What are LISTENING ports?
o C.4 How do I determine what service
the port is for?
o C.5 What ports are safe to pass
through a firewall?
o C.6 The behavior of FTP
o C.7 What software uses what FTP
mode?
o C.8 Is my firewall trying to
connect outside?
o C.9 The anatomy of a TCP connection
* References
4 Various Attacks
4.1 What is source routed traffic and why is it a threat?
Normally, the route a packet takes from its source to its destination is
determined by the routers between the source and destination. The packet
itself only says where it wants to go (the destination address), and nothing
about how it expects to get there.
There is an optional way for the sender of a packet (the source) to include
information in the packet that tells the route the packet should take to get
to its destination; thus the name ``source routing''. For a firewall, source
routing is noteworthy, since an attacker can generate traffic claiming to be
from a system ``inside'' the firewall. In general, such traffic wouldn't
route to the firewall properly, but with the source routing option, all the
routers between the attacker's machine and the target will return traffic
along the reverse path of the source route. Implementing such an attack is
quite easy; so firewall builders should not discount it as unlikely to
happen.
In practice, source routing is very little used. In fact, generally the main
legitimate use is in debugging network problems or routing traffic over
specific links for congestion control for specialized situations. When
building a firewall, source routing should be blocked at some point. Most
commercial routers incorporate the ability to block source routing
specifically, and many versions of Unix that might be used to build firewall
bastion hosts have the ability to disable or ignore source routed traffic.
4.2 What are ICMP redirects and redirect bombs?
An ICMP Redirect tells the recipient system to over-ride something in its
routing table. It is legitimately used by routers to tell hosts that the
host is using a non-optimal or defunct route to a particular destination,
i.e. the host is sending it to the wrong router. The wrong router sends the
host back an ICMP Redirect packet that tells the host what the correct route
should be. If you can forge ICMP Redirect packets, and if your target host
pays attention to them, you can alter the routing tables on the host and
possibly subvert the security of the host by causing traffic to flow via a
path the network manager didn't intend. ICMP Redirects also may be employed
for denial of service attacks, where a host is sent a route that loses it
connectivity, or is sent an ICMP Network Unreachable packet telling it that
it can no longer access a particular network.
Many firewall builders screen ICMP traffic from their network, since it
limits the ability of outsiders to ping hosts, or modify their routing
tables.
Before you decide to completely block ICMP, you should be aware of how the
TCP protocol does ``Path MTU Discovery'', to make certain that you don't
break connectivity to other sites. If you can't safely block it everywhere,
you can consider allowing selected types of ICMP to selected routing
devices. If you don't block it, you should at least ensure that your routers
and hosts don't respond to broadcast ping packets.
4.3 What about denial of service?
Denial of service is when someone decides to make your network or
firewall
useless by disrupting it, crashing it, jamming it, or flooding it. The
problem with denial of service on the Internet is that it is impossible to
prevent. The reason has to do with the distributed nature of the network:
every network node is connected via other networks which in turn connect to
other networks, etc. A firewall administrator or ISP only has control of a
few of the local elements within reach. An attacker can always disrupt a
connection ``upstream'' from where the victim controls it. In other words,
if someone wanted to take a network off the air, they could do it either by
taking the network off the air, or by taking the networks it connects to off
the air, ad infinitum. There are many, many, ways someone can deny service,
ranging from the complex to the brute-force. If you are considering using
Internet for a service which is absolutely time or mission critical, you
should consider your fall-back position in the event that the network is
down or damaged.
TCP/IP's UDP echo service is trivially abused to get two servers to flood a
network segment with echo packets. You should consider commenting out unused
entries in /etc/inetd.conf of Unix hosts, adding no ip small-servers to
Cisco routers, or the equivalent for your components.
4.4 What are some common attacks, and how can I protect my system against
them?
Each site is a little different from every other in terms of what attacks
are likely to be used against it. Some recurring themes do arise, though.
4.4.1 SMTP Server Hijacking (Unauthorized Relaying)
This is where a spammer will take many thousands of copies of a message and
send it to a huge list of email addresses. Because these lists are often so
bad, and in order to increase the speed of operation for the spammer, many
have resorted to simply sending all of their mail to an SMTP server that
will take care of actually delivering the mail.
Of course, all of the bounces, spam complaints, hate mail, and bad PR come
for the site that was used as a relay. There is a very real cost associated
with this, mostly in paying people to clean up the mess afterward.
The Mail Abuse Prevention System <URL:http://maps.vix.com/>
Transport
Security Initiative <URL:http://maps.vix.com/tsi/>
maintains a
complete description of the problem, and how to configure about every
mailer on the planet to protect against this attack.
4.4.2 Exploiting Bugs in Applications
Various versions of web servers, mail servers, and other Internet service
software contain bugs that allow remote (Internet) users to do things
ranging from gain control of the machine to making that application crash
and just about everything in between.
The exposure to this risk can be reduced by running only necessary services,
keeping up to date on patches, and using products that have been around a
while.
4.4.3 Bugs in Operating Systems
Again, these are typically initiated by users remotely. Operating systems
that are relatively new to IP networking tend to be more problematic, as
more mature operating systems have had time to find and eliminate their
bugs. An attacker can often make the target equipment continuously reboot,
crash, lose the ability to talk to the network, or replace files on the
machine.
Here, running as few operating system services as possible can help. Also,
having a packet filter in front of the operating system can reduce the
exposure to a large number of these types of attacks.
And, of course, chosing a stable operating system will help here as well.
When selecting an OS, don't be fooled into believing that ``the pricier, the
better''. Free operating systems are often much more robust than their
commercial counterparts
5 How Do I...
5.1 Do I really want to allow everything that my users ask for?
It's entirely possible that the answer is ``no''. Each site has its own
policies about what is and isn't needed, but it's important to remember that
a large part of the job of being an organization's gatekeeper is education.
Users want streaming video, real-time chat, and to be able to offer services
to external customers that require interaction with live databases on the
internal network.
That doesn't mean that any of these things can be done without presenting
more risk to the organization than the supposed ``value'' of heading down
that road is worth. Most users don't want to put their organization at risk.
They just read the trade rags, see advertisements, and they want to do those
things, too. It's important to look into what it is that they really want to
do, and to help them understand how they might be able to accomplish their
real objective in a more secure manner.
You won't always be popular, and you might even find yourself being given
direction to do something incredibly stupid, like ``just open up ports foo
through bar''. If that happens, don't worry about it. It would be wise to
keep all of your exchanges on such an event so that when a 12-year-old
script kiddie breaks in, you'll at least be able to separate yourself from
the whole mess.
5.2 How do I make Web/HTTP work through my firewall?
There are three ways to do it.
1. Allow ``established'' connections out via a router, if you are
using
screening routers.
2. Use a web client that supports SOCKS, and run SOCKS on your
bastion
host.
3. Run some kind of proxy-capable web server on the bastion host.
Some
options include Squid <URL:http://squid.nlanr.net/>,
Apache
<URL:http://www.apache.org/docs/mod/mod_proxy.html>,
Netscape
Proxy <URL:http://home.netscape.com/proxy/v3.5/index.html>,
and
http-gw from the TIS firewall toolkit. Most of these
can also proxy
other protocols (such as gopher and ftp), and can cache
objects
fetched, which will also typically result in a
performance boost for
the users, and more efficient use of your connection to
the Internet.
Essentially all web clients (Mozilla, Internet
Explorer, Lynx, etc.)
have proxy server support built directly into them.
5.3 How do I make SSL work through the firewall?
SSL is a protocol that allows secure connections across the Internet.
Typically, SSL is used to protect HTTP traffic. However, other protocols
(such as telnet) can run atop SSL.
Enabling SSL through your firewall can be done the same way that you would
allow HTTP traffic, if it's HTTP that you're using SSL to secure, which is
usually true. The only difference is that instead of using something that
will simply relay HTTP, you'll need something that can tunnel SSL. This is a
feature present on most web object caches.
You can find out more about SSL from Netscape
<URL:http://developer.netscape.com/docs/manuals/security/sslin/contents.htm>.
5.4 How do I make DNS work with a firewall?
Some organizations want to hide DNS names from the outside. Many experts
don't think hiding DNS names is worthwhile, but if site/corporate policy
mandates hiding domain names, this is one approach that is known to work.
Another reason you may have to hide domain names is if you have a
non-standard addressing scheme on your internal network. In that case, you
have no choice but to hide those addresses. Don't fool yourself into
thinking that if your DNS names are hidden that it will slow an attacker
down much if they break into your firewall. Information about what is on
your network is too easily gleaned from the networking layer itself. If you
want an interesting demonstration of this, ping the subnet broadcast address
on your LAN and then do an ``arp -a.'' Note also that hiding names in the
DNS doesn't address the problem of host names ``leaking'' out in mail
headers, news articles, etc.
This approach is one of many, and is useful for organizations that wish to
hide their host names from the Internet. The success of this approach lies
on the fact that DNS clients on a machine don't have to talk to a DNS server
on that same machine. In other words, just because there's a DNS server on a
machine, there's nothing wrong with (and there are often advantages to)
redirecting that machine's DNS client activity to a DNS server on another
machine.
First, you set up a DNS server on the bastion host that the outside world
can talk to. You set this server up so that it claims to be authoritative
for your domains. In fact, all this server knows is what you want the
outside world to know; the names and addresses of your gateways, your
wildcard MX records, and so forth. This is the ``public'' server.
Then, you set up a DNS server on an internal machine. This server also
claims to be authoritative for your domains; unlike the public server, this
one is telling the truth. This is your ``normal'' nameserver, into which you
put all your ``normal'' DNS stuff. You also set this server up to forward
queries that it can't resolve to the public server (using a ``forwarders''
line in /etc/named.boot on a Unix machine, for example).
Finally, you set up all your DNS clients (the /etc/resolv.conf file on a
Unix box, for instance), including the ones on the machine with the public
server, to use the internal server. This is the key.
An internal client asking about an internal host asks the internal server,
and gets an answer; an internal client asking about an external host asks
the internal server, which asks the public server, which asks the Internet,
and the answer is relayed back. A client on the public server works just the
same way. An external client, however, asking about an internal host gets
back the ``restricted'' answer from the public server.
This approach assumes that there's a packet filtering firewall between these
two servers that will allow them to talk DNS to each other, but otherwise
restricts DNS between other hosts.
Another trick that's useful in this scheme is to employ wildcard PTR records
in your IN-ADDR.ARPA domains. These cause an an address-to-name lookup for
any of your non-public hosts to return something like
``unknown.YOUR.DOMAIN'' rather than an error. This satisfies anonymous FTP
sites like ftp.uu.net that insist on having a name for the machines they
talk to. This may fail when talking to sites that do a DNS cross-check in
which the host name is matched against its address and vice versa.
5.5 How do I make FTP work through my firewall?
Generally, making FTP work through the firewall is done either using a
proxy server such as the firewall toolkit's ftp-gw or by permitting incoming
connections to the network at a restricted port range, and otherwise
restricting incoming connections using something like ``established''
screening rules. The FTP client is then modified to bind the data port to a
port within that range. This entails being able to modify the FTP client
application on internal hosts.
In some cases, if FTP downloads are all you wish to support, you might want
to consider declaring FTP a ``dead protocol'' and letting you users download
files via the Web instead. The user interface certainly is nicer, and it
gets around the ugly callback port problem. If you choose the FTP-via-Web
approach, your users will be unable to FTP files out, which, depending on
what you are trying to accomplish, may be a problem.
A different approach is to use the FTP ``PASV'' option to indicate that the
remote FTP server should permit the client to initiate connections. The PASV
approach assumes that the FTP server on the remote system supports that
operation. (See ``Firewall-Friendly FTP'' [1].)
Other sites prefer to build client versions of the FTP program that are
linked against a SOCKS library.
5.6 How do I make Telnet work through my firewall?
Telnet is generally supported either by using an application proxy such
as
the firewall toolkit's tn-gw, or by simply configuring a router to permit
outgoing connections using something like the ``established'' screening
rules. Application proxies could be in the form of a standalone proxy
running on the bastion host, or in the form of a SOCKS server and a modified
client.
5.7 How do I make Finger and whois work through my firewall?
Many firewall admins permit connections to the finger port from only
trusted machines, which can issue finger requests in the form of: finger
user@host.domain@firewall. This approach only works with the standard Unix
version of finger. Controlling access to services and restricting them to
specific machines is managed using either tcp_wrappers or netacl from the
firewall toolkit. This approach will not work on all systems, since some
finger servers do not permit user@host@host fingering.
Many sites block inbound finger requests for a variety of reasons, foremost
being past security bugs in the finger server (the Morris internet worm made
these bugs famous) and the risk of proprietary or sensitive information
being revealed in user's finger information. In general, however, if your
users are accustomed to putting proprietary or sensitive information in
their .plan files, you have a more serious security problem than just a
firewall can solve.
5.8 How do I make gopher, archie, and other services work through my
firewall?
The majority of firewall administrators choose to support gopher and
archie through web proxies, instead of directly. Proxies such as the
firewall toolkit's http-gw convert gopher/gopher+ queries into HTML and vice
versa. For supporting archie and other queries, many sites rely on
Internet-based Web-to-archie servers, such as ArchiePlex. The Web's tendency
to make everything on the Internet look like a web service is both a
blessing and a curse.
There are many new services constantly cropping up. Often they are
misdesigned or are not designed with security in mind, and their designers
will cheerfully tell you if you want to use them you need to let port xxx
through your router. Unfortunately, not everyone can do that, and so a
number of interesting new toys are difficult to use for people behind
firewalls. Things like RealAudio, which require direct UDP access, are
particularly egregious examples. The thing to bear in mind if you find
yourself faced with one of these problems is to find out as much as you can
about the security risks that the service may present, before you just allow
it through. It's quite possible the service has no security implications.
It's equally possible that it has undiscovered holes you could drive a truck
through.
5.9 What are the issues about X11 through a firewall?
The X Windows System is a very useful system, but unfortunately has some
major security flaws. Remote systems that can gain or spoof access to a
workstation's X display can monitor keystrokes that a user enters, download
copies of the contents of their windows, etc.
While attempts have been made to overcome them (E.g., MIT ``Magic Cookie'')
it is still entirely too easy for an attacker to interfere with a user's X
display. Most firewalls block all X traffic. Some permit X traffic through
application proxies such as the DEC CRL X proxy (FTP crl.dec.com). The
firewall toolkit includes a proxy for X, called x-gw, which a user can
invoke via the Telnet proxy, to create a virtual X server on the firewall.
When requests are made for an X connection on the virtual X server, the user
is presented with a pop-up asking them if it is OK to allow the connection.
While this is a little unaesthetic, it's entirely in keeping with the rest
of X.
5.10 How do I make RealAudio work through my firewall?
RealNetworks maintains some information about how to get RealAudio
working through your firewall <URL:http://www.real.com/firewall/>.
It
would be unwise to make any changes to your firewall without
understanding what the changes will do, exactly, and knowing what
risks the new changes will bring with them.
5.11 How do I make my web server act as a front-end for a database that
lives on my private network?
The best way to do this is to allow very limited connectivity between
your
web server and your database server via a specific protocol that only
supports the level of functionality you're going to use. Allowing raw SQL,
or anything else where custom extractions could be performed by an attacker
isn't generally a good idea.
Assume that an attacker is going to be able to break into your web server,
and make queries in the same way that the web server can. Is there a
mechanism for extracting sensitive information that the web server doesn't
need, like credit card information? Can an attacker issue an SQL select and
extract your entire proprietary database?
``E-commerce'' applications, like everything else, are best designed with
security in mind from the ground up, instead of having security ``added'' as
an afterthought. Review your architecture critically, from the perspective
of an attacker. Assume that the attacker knows everything about your
architecture. Now ask yourself what needs to be done to steal your data, to
make unauthorized changes, or to do anything else that you don't want done.
You might find that you can significantly increase security without
decreasing functionality by making a few design and implementation
decisions.
Some ideas for how to handle this:
* Extract the data you need from the database on a regular basis so
you're not making queries against the full database,
complete with
information that attackers will find interesting.
* Greatly restrict and audit what you do allow between the web
server and
database.
5.12 But my database has an integrated web server, and I want to use that.
Can't I just poke a hole in the firewall and tunnel that port?
If your site firewall policy is sufficiently lax that you're willing to
manage the risk that someone will exploit a vulnerability in your web server
that will result in partial or complete exposure of your database, then
there isn't much preventing you from doing this.
However, in many organizations, the people who are responsible for tying the
web front end to the database back end simply do not have the authority to
take that responsibility. Further, if the information in the database is
about people, you might find yourself guilty of breaking a number of laws if
you haven't taken reasonable precautions to prevent the system from being
abused.
In general, this isn't a good idea. See question 5.11 for some ideas on
other ways to accomplish this objective.
5.13 How Do I Make IP Multicast Work With My Firewall?
IP multicast is a means of getting IP traffic from one host to a set of
hosts without using broadcasting; that is, instead of every host getting the
traffic, only those that want it will get it, without each having to
maintain a separate connection to the server. IP unicast is where one host
talks to another, multicast is where one host talks to a set of hosts, and
broadcast is where one host talks to all hosts.
The public Internet has a multicast backbone (``MBone'') where users can
engage in multicast traffic exchange. Common uses for the MBone are streams
of IETF meetings and similar such interaction. Getting one's own network
connected to the MBone will require that the upstream provider route
multicast traffic to and from your network. Additionally, your internal
network will have to support multicast routing.
The role of the firewall in multicast routing, conceptually, is no different
from its role in other traffic routing. That is, a policy that identifies
which multicast groups are and aren't allowed must be defined and then a
system of allowing that traffic according to policy must be devised. Great
detail on how exactly to do this is beyond the scope of this document.
Fortunately, RFC 2588 [2]
discusses the subject in more detail. Unless your
firewall product supports some means of selective multicast forwarding or
you have the ability to put it in yourself, you might find forwarding
multicast traffic in a way consistent with your security policy to be a
bigger headache than it's worth.
A Some Commercial Products and Vendors
We feel this topic is too sensitive to address in a FAQ, however, an
independently maintained list (no warranty or recommendations are implied)
can be found online. <URL:http://www.thegild.com/firewall/>
B Glossary of Firewall-Related Terms
Abuse of Privilege
When a user performs an action that they should not
have, according to
organizational policy or law.
Access Control Lists
Rules for packet filters (typically routers) that
define which packets
to pass and which to block.
Access Router
A router that connects your network to the external
Internet.
Typically, this is your first line of defense against
attackers from
the outside Internet. By enabling access control lists
on this router,
you'll be able to provide a level of protection for all
of the hosts
``behind'' that router, effectively making that network
a DMZ instead
of an unprotected external LAN.
Application-Layer Firewall
A firewall system in which service is provided by
processes that
maintain complete TCP connection state and sequencing.
Application
layer firewalls often re-address traffic so that
outgoing traffic
appears to have originated from the firewall, rather
than the internal
host.
Authentication
The process of determining the identity of a user that
is attempting to
access a system.
Authentication Token
A portable device used for authenticating a user.
Authentication tokens
operate by challenge/response, time-based code
sequences, or other
techniques. This may include paper-based lists of
one-time passwords.
Authorization
The process of determining what types of activities are
permitted.
Usually, authorization is in the context of
authentication: once you
have authenticated a user, they may be authorized
different types of
access or activity.
Bastion Host
A system that has been hardened to resist attack, and
which is
installed on a network in such a way that it is
expected to potentially
come under attack. Bastion hosts are often components
of firewalls, or
may be ``outside'' web servers or public access
systems. Generally, a
bastion host is running some form of general purpose
operating system
(e.g., Unix, VMS, NT, etc.) rather than a ROM-based or
firmware
operating system.
Challenge/Response
An authentication technique whereby a server sends an
unpredictable
challenge to the user, who computes a response using
some form of
authentication token.
Chroot
A technique under Unix whereby a process is permanently
restricted to
an isolated subset of the filesystem.
Cryptographic Checksum
A one-way function applied to a file to produce a
unique
``fingerprint'' of the file for later reference.
Checksum systems are a
primary means of detecting filesystem tampering on
Unix.
Data Driven Attack
A form of attack in which the attack is encoded in
innocuous-seeming
data which is executed by a user or other software to
implement an
attack. In the case of firewalls, a data driven attack
is a concern
since it may get through the firewall in data form and
launch an attack
against a system behind the firewall.
Defense in Depth
The security approach whereby each system on the
network is secured to
the greatest possible degree. May be used in
conjunction with
firewalls.
DNS spoofing
Assuming the DNS name of another system by either
corrupting the name
service cache of a victim system, or by compromising a
domain name
server for a valid domain.
Dual Homed Gateway
A dual homed gateway is a system that has two or more
network
interfaces, each of which is connected to a different
network. In
firewall configurations, a dual homed gateway usually
acts to block or
filter some or all of the traffic trying to pass
between the networks.
Encrypting Router
see Tunneling Router and Virtual Network Perimeter.
Firewall
A system or combination of systems that enforces a
boundary between two
or more networks.
Host-based Security
The technique of securing an individual system from
attack. Host based
security is operating system and version dependent.
Insider Attack
An attack originating from inside a protected network.
Intrusion Detection
Detection of break-ins or break-in attempts either
manually or via
software expert systems that operate on logs or other
information
available on the network.
IP Spoofing
An attack whereby a system attempts to illicitly
impersonate another
system by using its IP network address.
IP Splicing / Hijacking
An attack whereby an active, established, session is
intercepted and
co-opted by the attacker. IP Splicing attacks may occur
after an
authentication has been made, permitting the attacker
to assume the
role of an already authorized user. Primary protections
against IP
Splicing rely on encryption at the session or network
layer.
Least Privilege
Designing operational aspects of a system to operate
with a minimum
amount of system privilege. This reduces the
authorization level at
which various actions are performed and decreases the
chance that a
process or user with high privileges may be caused to
perform
unauthorized activity resulting in a security breach.
Logging
The process of storing information about events that
occurred on the
firewall or network.
Log Retention
How long audit logs are retained and maintained.
Log Processing
How audit logs are processed, searched for key events,
or summarized.
Network-Layer Firewall
A firewall in which traffic is examined at the network
protocol packet
layer.
Perimeter-based Security
The technique of securing a network by controlling
access to all entry
and exit points of the network.
Policy
Organization-level rules governing acceptable use of
computing
resources, security practices, and operational
procedures.
Proxy
A software agent that acts on behalf of a user. Typical
proxies accept
a connection from a user, make a decision as to whether
or not the user
or client IP address is permitted to use the proxy,
perhaps does
additional authentication, and then completes a
connection on behalf of
the user to a remote destination.
Screened Host
A host on a network behind a screening router. The
degree to which a
screened host may be accessed depends on the screening
rules in the
router.
Screened Subnet
A subnet behind a screening router. The degree to which
the subnet may
be accessed depends on the screening rules in the
router.
Screening Router
A router configured to permit or deny traffic based on
a set of
permission rules installed by the administrator.
Session Stealing
See IP Splicing.
Trojan Horse
A software entity that appears to do something normal
but which, in
fact, contains a trapdoor or attack program.
Tunneling Router
A router or system capable of routing traffic by
encrypting it and
encapsulating it for transmission across an untrusted
network, for
eveMindPrideal de-encapsulation and decryption.
Social Engineering
An attack based on deceiving users or administrators at
the target
site. Social engineering attacks are typically carried
out by
telephoning users or operators and pretending to be an
authorized user,
to attempt to gain illicit access to systems.
Virtual Network Perimeter
A network that appears to be a single protected network
behind
firewalls, which actually encompasses encrypted virtual
links over
untrusted networks.
Virus
A replicating code segment that attaches itself to a
program or data
file. Viruses might or might not not contain attack
programs or
trapdoors. Unfortunately, many have taken to calling
any malicious code
a ``virus''. If you mean ``trojan horse'' or ``worm'',
say ``trojan
horse'' or ``worm''.
Worm
A standalone program that, when run, copies itself from
one host to
another, and then runs itself on each newly infected
host. The widely
reported ``Internet Virus'' of 1988 was not a virus at
all, but
actually a worm.
C TCP and UDP Ports
by Mikael Olsson
This appendix will begin at a fairly ``basic'' level, so even if the first
points seem childishly self-evident to you, you might still learn something
from skipping ahead to something later in the text.
C.1 What is a port?
A ``port'' is ``virtual slot'' in your TCP and UDP stack that is used to
map a connection between two hosts, and also between the TCP/UDP layer and
the actual applications running on the hosts.
They are numbered 0-65535, with the range 0-1023 being marked as
``reserved'' or ``privlileged'', and the rest (1024-65535) as ``dynamic'' or
``unprivileged''.
There are basically two uses for ports:
* ``Listening'' on a port.
This is used by server applications waiting for users
to connect, to
get to some ``well known service'', for instance HTTP
(TCP port 80),
Telnet (TCP port 21), DNS (UDP and sometimes TCP port
53).
* Opening a ``dynamic'' port.
Both sides of a TCP connection need to be identified by
IP addresses
and port numbers. Hence, when you want to ``connect''
to a server
process, your end of the communications channel also
needs a ``port''.
This is done by choosing a port above 1024 on your
machine that is not
currently in use by another communications channel, and
using it as the
``sender'' in the new connection.
Dynamic ports may also be used as ``listening'' ports in some applications,
most notably FTP.
Ports in the range 0-1023 are almost always server ports. Ports in the range
1024-65535 are usually dynamic ports (i.e., opened dynamically when you
connect to a server port). However, any port may be used as a server port,
and any port may be used as an ``outgoing'' port.
So, to sum it up, here's what happens in a basic connection:
* At some point in time, a server application on host 1.2.3.4
decides to
``listen'' at port 80 (HTTP) for new connections.
* You (5.6.7.8) want to surf to 1.2.3.4, port 80, and your browser
issues
a connect call to it.
* The connect call, realising that it doesn't yet have local port
number,
goes hunting for one. The local port number is
necessary since when the
replies come back some time in the future, your TCP/IP
stack will have
to know to what application to pass the reply. It does
this by
remembering what application uses which local port
number. (This is
grossly simplified, no flames from programmers,
please.)
* Your TCP stack finds an unused dynamic port, usually somewhere
above
1024. Let's assume that it finds 1029.
* Your first packet is then sent, from your local IP, 5.6.7.8, port
1029,
to 1.2.3.4, port 80.
* The server responds with a packet from 1.2.3.4, port 80, to you,
5.6.7.8, port 1029.
* This procedure is actually longer than this, read on for a more
in-depth explanation of TCP connect sequences.
C.2 How do I know which application uses what port?
There are several lists outlining the ``reserved'' and ``well known''
ports, as well as ``commonly used'' ports, and the best one is:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. For those of you
still reading RFC 1700 to
find out what port number does what, STOP DOING
IT. It is horribly out of date, and it won't be less so tomorrow. Now, as
for trusting this information: These lists do not, in any way, constitute
any kind of holy bible on which ports do what.
Wait, let me rephrase that: THERE IS NO WAY OF RELIABLY DETERMINING WHAT
PORT DOES WHAT SIMPLY BY LOOKING IN A LIST.
C.3 What are LISTENING ports?
Suppose you did ``netstat -a'' on your machine and ports 1025 and 1030
showed up as LISTENing. What do they do?
Right, let's take a look in the assigned port numbers list.
blackjack 1025/tcp
network blackjack
iad1
1030/tcp BBN IAD
Wait, what's happening? Has my workstation stolen my VISA number and decided
to go play blackjack with some rogue server on the internet? And what's that
software that BBN has installed?
This is NOT where you start panicking and send mail to the firewalls list.
In fact, this question has been asked maybe a dozen times during the past
six months, and every time it's been answered. Not that THAT keeps people
from asking the same question again.
If you are asking this question, you are most likely using a windows box.
The ports you are seeing are (most likely) two listening ports that the RPC
subsystem opens when it starts up.
This is an example of where dynamicly assigned ports may be used by server
processes. Applications using RPC will later on connect to port 135 (the
netbios ``portmapper'') to query where to find some RPC service, and get an
answer back saying that that particular service may be contacted on port
1025.
Now, how do we know this, since there's no ``list'' describing these ports?
Simple: There's no substitute for experience. And using the mailing list
search engines also helps a hell of a lot.
C.4 How do I determine what service the port is for?
Since it is impossible to learn what port does what by looking in a list,
how do i do it?
The old hands-on way of doing it is by shutting down nearly every
service/daemon running on your machine, doing netstat -a and taking note of
what ports are open. There shouldn't be very many listening ones. Then you
start turning all the services on, one by one, and take note of what new
ports show up in your netstat output.
Another way, that needs more guess work, is simply telnetting to the ports
and see what comes out. If nothing comes out, try typing some gibberish and
slamming Enter a few times, and see if something turns up. If you get binary
garble, or nothing at all, this obviously won't help you. :-)
However, this will only tell you what listening ports are used. It won't
tell you about dynamically opened ports that may be opened later on by these
applications.
There are a few applications that might help you track down the ports used.
On Unix systems, there's a nice utility called lsof that comes preinstalled
on many systems. It will show you all open port numbers and the names of the
applications that are using them. This means that it might show you a lot of
locally opened files aswell as TCP/IP sockets. Read the help text. :-)
On windows systems, nothing comes preinstalled to assist you in this task.
(What's new?) There's a utility called ``Inzider'' which installs itself
inside the windows sockets layer and dynamically remembers which process
opens which port. The drawback of this approach is that it can't tell you
what ports were opened before inzider started, but it's the best that you'll
get on windows (to my knowledge).
http://ntsecurity.nu/toolbox/inzider/.
C.5 What ports are safe to pass through a firewall?
ALL.
No, wait, NONE.
No, wait, uuhhh... I've heard that all ports above 1024 are safe since
they're only dynamic??
No. Really. You CANNOT tell what ports are safe simply by looking at its
number, simply because that is really all it is. A number. You can't mount
an attack through a 16-bit number.
The security of a ``port'' depends on what application you'll reach through
that port.
A common misconception is that ports 25 (SMTP) and 80 (HTTP) are safe to
pass through a firewall. *meep* WRONG. Just because everyone is doing it
doesn't mean that it is safe.
Again, the security of a port depends on what application you'll reach
through that port.
If you're running a well-written web server, that is designed from the
ground up to be secure, you can probably feel reasonably assured that it's
safe to let outside people access it through port 80. Otherwise, you CAN'T.
The problem here is not in the network layer. It's in how the application
processes the data that it receives. This data may be received through port
80, port 666, a serial line, floppy or through singing telegram. If the
application is not safe, it does not matter how the data gets to it. The
application data is where the real danger lies.
If you are interested in the security of your application, go
subscribe to bugtraq <URL:http://www.securityfocus.com>
or try
searching their archives.
This is more of an application security issue rather than a firewall
security issue. One could argue that a firewall should stop all possible
attacks, but with the number of new network protocols, NOT designed with
security in mind, and networked applications, neither designed with security
in mind, it becomes impossible for a firewall to protect against all
data-driven attacks.
C.6 The behavior of FTP
Or, ``Why do I have to open all ports above 1024 to my FTP server?''
FTP doesn't really look a whole lot like other applications from a
networking perspective.
It keeps one listening port, port 21, which users connect to. All it does is
let people log on, and establish ANOTHER connection to do actual data
transfers. This second connection is usually on some port above 1024.
There are two modes, ``active'' (normal) and ``passive'' mode. This word
describes the server's behaviour.
In active mode, the client (5.6.7.8) connects to port 21 on the server
(1.2.3.4) and logs on. When file transfers are due, the client allocates a
dynamic port above 1024, informs the server about which port it opened, and
then the server opens a new connection to that port. This is the ``active''
role of the server: it actively establishes new connections to the client.
In passive mode, the connection to port 21 is the same. When file transfers
are due, the SERVER allocates a dynamic port above 1024, informs the client
about which port it opened, and then the CLIENT opens a new connection to
that port. This is the ``passive'' role of the server: it waits for the
client to establish the second (data) connection.
If your firewall doesn't inspect the application data of the FTP command
connection, it won't know that it needs to dynamically open new ports above
1024.
On a side note: The traditional behaviour of FTP servers in active mode is
to establish the data session FROM port 20, and to the dynamic port on the
client. FTP servers are steering away from this behaviour somewhat due to
the need to run as ``root'' on unix systems in order to be able to allocate
ports below 1024. Running as ``root'' is not good for security, since if
there's a bug in the software, the attacker would be able to compromise the
entire machine. The same goes for running as ``Administrator'' or ``SYSTEM''
(``LocalSystem'') on NT machines, although the low port problem does not
apply on NT.
To sum it up, if your firewall understands FTP, it'll be able to handle the
data connections by itself, and you won't have to worry about ports above
1024.
If it does NOT, there are four issues that you need to address:
* Firewalling an FTP server in active mode
You need to let your server open new connections to the
outside world
on ports 1024 and above
* Firewalling an FTP server in passive mode
You need to let the outside world connect to ports 1024
and above on
your server. CAUTION!!!! There may be applications
running on some of
these ports that you do NOT want outside people using.
Disallow access
to these ports before allowing access to the 1024-65535
port range.
* Firewalling FTP clients in active mode
You need to let the outside world connect to ports 1024
and above on
your clients. CAUTION!!!! There may be applications
running on some of
these ports that you do NOT want outside people using.
Disallow access
to these ports before allowing access to the 1024-65535
port range.
* Firewalling FTP clients in passive mode
You need to let your clients open new connections to
the outside world
on ports 1024 and above.
Again, if your firewall understands FTP, none of the four points above apply
to you. Let the firewall do the job for you.
C.7 What software uses what FTP mode?
It is up to the client to decide what mode to use; the default mode when
a
new connection is opened is ``active mode''.
Most FTP clients come preconfigured to use active mode, but provide an
option to use ``passive'' (``PASV'') mode. An exception is the windows
command line FTP client which only operates in active mode.
Web Browsers generally use passive mode when connecting via FTP, with a
weird exception: MSIE 5 will use active FTP when FTP:ing in ``File
Explorer'' mode and passive FTP when FTP:ing in ``Web Page'' mode. There is
no reason whatsoever for this behaviour; my guess is that someone in Redmond
with no knowledge of FTP decided that ``Of course we'll use active mode when
we're in file explorer mode, since that looks more active than a web page''.
Go figure.
C.8 Is my firewall trying to connect outside?
My firewall logs are telling me that my web server is trying to connect
from port 80 to ports above 1024 on the outside. What is this?!
If you are seeing dropped packets from port 80 on your web server (or from
port 25 on your mail server) to high ports on the outside, they usually DO
NOT mean that your web server is trying to connect somewhere.
They are the result of the firewall timing out a connection, and seeing the
server retransmitting old responses (or trying to close the connection) to
the client.
TCP connections always involve packets traveling in BOTH directions in the
connection.
If you are able to see the TCP flags in the dropped packets, you'll see that
the ACK flag is set but not the SYN flag, meaning that this is actually not
a new connection forming, but rather a response of a previously formed
connection.
Read point 8 below for an in-depth explanation of what happens when TCP
connections are formed (and closed)
C.9 The anatomy of a TCP connection
TCP is equipped with 6 ``flags'', which may be ON or OFF. These flags
are:
FIN
``Controlled'' connection close
SYN
Open new connection
RST
``Immediate'' connection close
PSH
Instruct receiver host to push the data up to the
application rather
than just queue it
ACK
``Acknowledge'' a previous packet
URG
``Urgent'' data which needs to be processed immediately
In this example, your client is 5.6.7.8, and the port assigned to you
dynamically is 1049. The server is 1.2.3.4, port 80.
You begin the connection attempt:
5.6.7.8:1049 -> 1.2.3.4:80 SYN=ON
The server receives this packet and understands that someone wants to form a
new connection. A response is sent:
1.2.3.4:80 -> 5.6.7.8:1049 SYN=ON ACK=ON
The client receives the response, and informs that the response is received
5.6.7.8:1049 -> 1.2.3.4:80 ACK=ON
Here, the connection is opened. This is called a three-way handshake. Its
purpose is to verify to BOTH hosts that they have a working connection
between them.
The internet being what it is, unreliable and flooded, there are provisions
to compensate for packet loss.
If the client sends out the initial SYN without receiving a SYN+ACK within a
few seconds, it'll resend the SYN.
If the server sends out the SYN+ACK without receiving an ACK in a few
seconds, it'll resend the SYN+ACK packet.
The latter is actually the reason that SYN flooding works so well. If you
send out SYN packets from lots of different ports, this will tie up a lot of
resources on the server. If you also refuse to respond to the returned
SYN+ACK packets, the server will KEEP these connections for a long time,
resending the SYN+ACK packets. Some servers will not accept new connections
while there are enough connections currently forming; this is why SYN
flooding works.
All packets transmitted in either direction after the three-way handshake
will have the ACK bit set. Stateless packet filters make use of this in the
so called ``established'' filters: They will only let packets through that
have the ACK bit set. This way, no packet may pass through in a certain
direction that could form a new connection. Typically, you don't allow
outside hosts to open new connections to inside hosts by requiring the ACK
bit set on these packets.
When the time has come to close the connection, there are two ways of doing
it: Using the FIN flag, or using the RST flag. Using FIN flags, both
implementations are required to send out FIN flags to indicate that they
want to close the connection, and then send out acknowledgements to these
FINs, indicating that they understood that the other end wants to close the
connection. When sending out RST's, the connection is closed forcefully, and
you don't really get an indication of whether the other end understood your
reset order, or that it has in fact received all data that you sent to it.
The FIN way of closing the connection also exposes you to a
denial-of-service situation, since the TCP stack needs to remember the
closed connection for a fairly long time, in case the other end hasn't
received one of the FIN packets.
If sufficiently many connections are opened and closed, you may end up
having ``closed'' connections in all your connection slots. This way, you
wouldn't be able to dynamically allocate more connections, seeing that
they're all used. Different OSes handle this situation differently.
References
1 Steven M. Bellovin.
Firewall-friendly FTP.
RFC
1579.
2 R. Finlayson.
Ip multicast and firewalls.
RFC
2588, May 1999.
3 Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and
E. Lear.
Address allocation for private internets.
RFC
1918, February 1996.
4 R. Thayer, N. Doraswamy, and R. Glenn.
IP Security Document Roadmap.
RFC
2411, November 1998.
|
US
