We have covered basic information which include services with the information contained in IP and TCP packet headers. From this information we can create the theory for the operation of a filtering firewall with policy's.
Where on a network does a firewall get located? This question must be answered by each organization differently. Usually, an organization may place a few servers outside the firewall on the Internet without protection (like a Mail Server for delivery of mail, and maybe even DNS.) The filtering firewall is the placed between a LAN and the rest of the Internet. Any traffic going in or out of the LAN must pass through the this filtering firewall. It is the fact that all traffic going to and from this LAN must pass through the firewall which makes it an effective point for setting up filtering polices.
Nearly any type of data that you read about in the review of IP and TCP address headers can be examined by a firewall, and it can take steps to allow, or disallow a packet with those settings in packets you do not like to not be allowed to pass through, or be allowed to pass through. In this way, the firewall may permit outgoing traffic from the LAN to any IP address, but may disallow any connections from being created by any Internet based machines outside the firewall. Since IP addresses are assigned to organizations in sequential blocks, it is possible to know what range of IP addresses your organization will be using internally. It is possible to also know what IP addresses may be used by your off-site labs. You will notice that within the header of the IP packet you can see source IP address and Destination IP address.
Also within the IP header is the "protocol" field. In this field, you can know if an IP packet is carrying a UDP, TCP, ICMP, or IGMP packet in its payload or data area. From this, you can choose to block all incoming or both incoming and outgoing ICMP, or maybe block all UDP except for port 53 so that DNS requests may come back to clients in your LAN. (See a review of other kinds of packets carried by IP where many of the other protocols other than UDP, TCP, ICMP and IGMP are assigned their numbers for this "protocol" field.)
Another item that can be examined for filtering for incoming packets is destination port number. For example, Windows File sharing over IP uses port number 137,138, and 139. If you choose to block these incoming packets to your LAN at your firewall with destination port numbers of 137,138 and 139, then you have broken file sharing and browsing of Windows file shares in your LAN from outside users on the Internet. Macintosh machines may use AppleTalk over TCP/IP and use port 548 for AppleShare over IP while ports 201, 202, 204 and 206 (UDP and TCP) may be used for AppleTalk specific data. If you wish to prevent outside Internet users from mounting up your local AppleTalk network shares, then your firewall may block any packets with the destination port number as to being any of those. Any service mentioned in rfc1700.txt that has a specific port number assigned to it can be blocked from being allowed to enter into your LAN at the firewall as long. This does rely upon a service continuing to use the same port number however. It is possible on many UNIX boxes to set them up to have Apple Macintosh File shares, and Windows file shares run on different ports than the "standard" ports that are normally accepted. Then from the outside world, on a Mac you can specify the port number of the machines when connecting up to do file sharing. Other UNIX boxes may also be able to specify an alternative port number to try to mount windows based file shares over IP or even AppleTalk over IP based files hares. Because of this, the network and security administrators must also set a political policy as part of their firewall. This political policy includes notifying employees that their creation of services that purposefully pierce the firewall is unacceptable. All it takes is a single rogue user inside your network, such an employee for your company, and your logical security policy on the filtering firewall can be lost.
Though it is possible to filter incoming and outgoing packets on more than just IP addresses, protocol type and port numbers, frequently these are the only three items configured into a campus firewall policy.
Some examples on items that can be examined in the headers of packets also include:
Then the return response from the remote machine using TCP may be allowed to pass on to the original machine behind the firewall that attempted to initiate the request. If any of the above is not true, then the connection may be terminated by the firewall with the use of a FIN or RST since it knows the sequence numbers in use by both hosts. (This is an over-simplification, and not the best way to convey this. I am looking for a better explanation.)
If the state oriented firewall is well implemented and designed, it may also include some heuristics (not an algorithm) for examination of the payload or body of the TCP response to see if the content matches or is "related" to the service expected for that port number, and/or the content of the body of the TCP packet sent by the original host machine behind the firewall THEN (whew!) the packet may also be allowed. Really, this may be viewed as a specialized stateful firewall and proxy service as it would likely include application layer review and comparison to port information, source and destination. This can be added as an extra comparison in the above list, and just how strictly it is enforced could be scaled. (For example, if the body looks like it is RealAudio and the original outgoing requests was HTTP, but appeared as though it could have been an HTTP based request for a RealAudio session/stream, then maybe that would be okay. Or if you were strict, maybe you could tell the state-oriented plus proxy service firewall to only allow exact protocol matches and then this would not be allowed.)
(Neither Specialized Proxy Servers or IP Masquerading / One-to-many NAT will be covered in detail here, since it would lead to this document being too long. At some time in the future I may cover these in a separate section...)
Here is a sample logical policy written in english which could be used by a filtering firewall (not taken from a table on a firewall.)
Incoming packets:
Outgoing packets:
The above gives an pseudo policy written in English. It is not complete, but offers a view of the things that must be thought about when designing a firewall policy. In addition to the restrictions put into place for filtering, a firewall should also include an internal political policy on a network. For example, you should also notify your employees that they should not download anything from the Internet to install, or run locally on their machines. This can be the most difficult to implement, because people are curious by nature, and when they get an attachment from what appears to be a friend, which says something like "your Christmas card.exe" they tend to want to open it, and by doing so run it on their local machine. This is risky in that the program even if genuinely from the specified address, may have a virus attached, or may be a trojan like Back Orifice, or NetBus, or something that creates a service on their local machines that accepts requests for service over UDP at a specific port. In the later case, an evil user could pierce the above firewall by setting up their client to send its requests from port 53 (DNS) to the machine in your firewall, and now your internal network has been opened up for attack.
Seeing that the opening of port 53 can lead to break-in, allowing all machine on your network to be accessed if the incoming request appears to be from UDP port 53 may not be a great idea. Inclusion of a DNS internal to your site that performs all remote lookups but from within the firewall as proxied to the real, registered DNS with your domain name, and then only open port 53 for the internal firewall and no other machines by knowing the internal firewall's IP address may be an option...
Firewalls become complex for organizations when they must be set up with an eye for services, and the security of those services. Lately, BIND has been coming under attack, with security holes being found in it much like sendmail. Many of the attacks have been attacks that use DNS cache poisoning, and not for administrative access. As long as you do not use IP authentication, but use challenge response, and encryption for granting access to many of your internal resources, you better insulate yourself from being a victim of an exploit that uses a poisoned DNS cache to make you think that they, as a remote host, are trustworthy.