Webspace Sponsored by:

Version 0.0.0 @ 03:55/08.07.2000

Adding Theory to Previously Documented Information


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:

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.


Comments and/or suggestions for this?: Email me at: dugan@passwall.com
Attempts have been made to make the tables appear as they should for LYNX users by forcing a common field width for fields being used by padding them with other printable characters. This is meant to allow for LYNX users to see the tables much like the Netscape and other web browser worlds might show them. However, from personal experience, some versions of LYNX still manage to munge the tables, making them use up several pages. It seems to be a problem with how earlier versions of LYNX dealt with tables, but the problem has not been entirely isolated.
Some have asked why this collection of on-line documents is so lacking of graphic content. To them I answer: faster downloads. Many of these pages are smaller than some pictures on many commercial web sites. You do not come here to look at my pictures. You come here to read content. Also, LYNX users benefit from this, and by using ALL text, people with ADA issues are able to use speech recognition software on the text to hear the words.
Copyright (C) 1999, 2000, 2001, 2002 by Michael Egan: All rights reserved.
A Special License: No part of this document may be used for profit without the consent of the author Michael Egan in writing. Content may be duplicated for retransmission for non-profit purposes as long as the copyright and license remain included in their entirety. The content is provided "as-is" and I take no responsibility on the content's truthfulness or consistency. Errors may exist in these documents, but acting upon these errors is left up to the reader to verify by a third party that will take responsibility for fact verification. When notified of errors or inconsistencies, attempts will be made to rectify the errors.
In plan English this is meant to do many things: This copyright is meant to exist so that others may not profit from this work as published in paper form, or by duplicating the content to place advertisements over it and generate income. It is also meant to exist to prevent people from publishing this work as their own and receiving profit from this process on research they did not perform. It is not meant to stop a professor from running off copies to use in their classes for their students. It is also not meant to stop the student from printing up copies for their own education. How depressing it would be to find your work published in book form without your permission, or compensation. Another reason for this Copyright is to limit the effect of the mistakes I have made within this document before I was able to complete it. It would be even sadder to notice my mistakes in print and criticized before I could resolve them. Eventually, after I finish this work, I may retain copyright, but eliminate the license.