Firewalls are used to selectively limit what can pass through a network connection and log information about what the connection is used for, with the goal of enforcing certain security policies.
The basic idea, is to pass all traffic through the firewall, thus giving the administrator a single point where the desired policies can be enforced. This single point of control allows the administrator to "hide" characteristics of a private network and protect it from "attacks" from the outside (usually the Internet).
Also, since the IP addresses used on some private networks cannot be used for direct Internet access (see RFC....). Firewalling techniques (such as proxies and IP NAT) can be used to provide various degrees of access in spite of the limitations imposed by such "hidden" networks.
Of course, mere machines can only enforce a small part of most security policies - clever humans can invariably avoid restrictions imposed by a firewall, no matter how advanced it is.
The following basic concepts about IP (the Internet Protocol) must be understood, for a discussion about firewalls to make any sense.
IP address are 32-bit numbers which identify machines on a TCP/IP network. IP addresses are usually written as four positive integers, seperated by dots - the most significant first, and the least significant last.
Example: 10.123.44.98
Port numbers are 16-bit numbers which identify "ports" on a machine. Port numbers are used to differentiate between different data sessions and services which are active on the same machine (thus sharing the same IP address). Some common services, such as SMTP and DNS have standardized port numbers (SMTP=25, DNS=53), other services such as HTTP proxies can use any port number. Knowing what port a given service runs on is often critical for accessing it through a firewall. Port numbers are often appended to IP addresses, using a ':' as a delimiter.
Example: 10.123.44.98:53
(the DNS service on 10.123.44.98)
Data on a TCP/IP network is transmitted in IP packets. Both TCP and UDP packets contain data, status bits and two pairs of IP addresses and ports - one pair indicating where the packet comes from and the other where it is going. We are only interested in TCP packets, because both DCC and IRC use TCP connections.
A typical telnet session from 10.1.2.3 to 10.3.2.1 consists of a stream of TCP packets, where each one heading from the client to the server has the following information in it's header:
From 10.1.2.3:12423, To 10.3.2.1:23, Data
And the reply packets have a header like this:
From 10.3.2.1:23, To 10.1.2.3:12423, Data
There are three methods commonly used in firewalls to enforce the local security policy. The three methods are commonly used together, each complementing the others' weaknesses.
Note: The terms used in this section may be at odds with those used for the same concepts elsewhere. The goal of this section is to explain the underlying principles, not to define a vocabulary for communicating with networking professionals.
Packet filters operate on the IP level, scanning the headers of each IP packet crossing the firewall and comparing its characterisctics to a fixed set of rules. These rules determine whether the packet is allowed to pass unhindered or not.
Characteristics recognized by packet filters are the source and destination IP addresses, the source and destination port numbers, various status bits in the header, and the direction the packet is travelling accross the firewall.
Packet filters don't know anything about protocols above the TCP/IP layer - they are fast and simple, but not very flexible.
Application layer proxies are applications running on the firewall, which users on one or both sides of the firewall can communicate with.
The proxies forward the users' requests to the actual servers which can give a response, possibly imposing rules on what sort of traffic is acceptable. From the viewpoint of the "actual servers", it appears as if the firewall is making the requests - not the client. This can provide a modicrum of privacy and protection for the user behind the firewall.
Application layer proxies are in general the most flexible type of firewalling software, but they frequently require added configuration or skills from the user.
A common example of this is an HTTP proxy, which allows users to request web pages from anywhere but may refuse some requests or rewrite pages based on rules defined by the administrator. To make use of an HTTP proxy, you must enable and configure proxy support in your browser.
Tircproxy can function as an application layer proxy, and can hide the user's identity.
Network layer proxies are a cross between application layer proxies and packet filters. Like packet filters, they scan the headers of the IP packets crossing the firewall - but are able to respond in more ways than packet filters which generally only "accept" or "reject".
IP masquerading and IP NAT are simple network layer proxies, which merely replace the "hidden" network's IP addresses with an address from a list of "visible" ones, on a connection-by-connection basis. This way, machines on the hidden network can "borrow" visible IP addresses and/or source ports from the firewall itself, which can be used to communicate with the untrusted network.
To make these "dynamic tunnels" as narrow as possible, a list of active communication channels ( TCP, UDP, etc ..) is maintained, and only packets (from the "outside") which exactly match an active connection are "proxied" back into the hidden network. Only internal, trusted machines can open such a tunnel through the firewall.
In addition to this basic "translation" of network addresses and ports, some implementations contain built-in support for common protocols (such as FTP or IRC/DCC) which are dependant on external, untrusted hosts being able to initiate connections to the client. In general though, such protocols won't work through most firewalls based on these techniques.
Another type of network layer proxy is based on cooperation between specialized application proxies, and the operating system's network code. In addition to re-writing the IP addresses on the network packets, some packets may be passed for further processing to an application proxy on the firewall machine. This proxy can monitor and filter the flow of data between the client and the external server in a much more complicated (and therefore error-prone) manner than is usually allowed within an operating system's low level network code. These proxies are generally called transparent proxies, because they [can] operate in a manner completely invisible to the user.
Tircproxy can function as a transparent proxy, on some platforms.