FAQ TOC | Previous Section | Next Section

A Some Commercial Products and Vendors

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 eventual 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

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?

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?

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?

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?

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?

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 or 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

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?

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?

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

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.

About this document ...

Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The translation was initiated by Matt Curtin on 12/3/2000

Footnotes

FAQ TOC | Previous Section | Next Section