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:

• Disallowing incoming packets with the "SYN" flag set. (This can break some sessions from remote devices if they wish to synchronize.)
• Disallowing passing of fragmented packets:
  • This could include just dropping all fragmented packets (which is not the nicest way to be social with people on other networks that may have larger IP packets that must be fragmented to get to yours.)
  • It can also include automatically de-fragmenting all packets from either side of the firewall before sending them on.

    Eliminating fragmented packets from both sides of the interface can help to protect your machines and others from many Denial of Service (DoS) attacks that have become popular as of recent that take advantage of TCP/IP stacks and implementations that did not consider a packet that was purposefully fragmented in such a way as to make its re-assembly impossible with the given information.

  • As an example, we can look at the often used carrier pigeon system that is used to describe how data you send may be sent over the Internet.

    1. You want to send a car to a friend of yours by carrier pigeon.
    2. A car is too heavy for a single pigeon to carry, so you disassemble the car into smaller parts, each of which can be carried by a single pigeon.
    3. You attach each part to one pigeon, and label each part with a number and instructions to what parts that part is supposed to be connected.
    4. You then open the cage and send all of the pigeons on their way to their pre planned destination.
    5. Along the way, some pigeons die from collisions with other birds, and aircraft. Some birds are intentionally shot out of the sky by evil users (I mean hunters) and some just get lost or try to make a break for it! There are also some pigeons that have mid-flight problems, and forget how to fly. These pigeons drop out of the sky and many land where the recipient can fetch them, but are often damaged. The damage does not only include them, but also their payload. However, most of the birds get to their destination with their packages in excellent condition.
    6. The receiver now takes the parts from the birds, and reads the labels to see how each part is supposed to be connected to other parts, and writes "I received message number" with the numbers corresponding to the messages the receiver received for each part that was received in good condition.
    7. The messages are attached to birds and then sent on back to the original sender to let them know which parts were received.
    8. On the trip back, a few more birds get whacked. This time, some are assassinated by gun fire from the grassy knoll, and the book depository, while others are strangely killed by a magic bullet that is able to change direction in mid flight to hit more birds.
    9. The original sender now looks to see which parts were received by the receiver. For each acknowledgment of receipt by the receiver, the sender marks those parts as having been received.
    10. Now the sender looks to see what parts that were sent before did not manage to make it, and then follows the procedure above to re-send those parts back using the same method as before, but only re-sending the parts for which the original sender did not get an acknowledgement. (Notice that even though some acknowledgements did not make it back to the original sender, the pigeons that brought the original automotive parts did successfully delivery the automotive parts. A group of second parts is being sent by pigeon even though some of the first pigeons sent actually made it and do not need to be re-sent.)
    11. More birds are killed, fly away, develop dimensional portals and are sucked into space for aliens to eat on the way back, but most arrive back to the receiver.
    12. When the receiver gets these pigeons, they notice that some parts he acknowledged before as being received are documented by him as having been received. These parts he toss away into the bit bucket, or the recycling bin since he knows that he has those already. The rest he adds to the car that is being re-constructed.
    13. The receiver then re-acknowledges all of the parts that were re-sent to him that made it in tact and offers a single acknowledgement for the newly arrives pigeons carrying parts that had not successfully made the previous trip.
    14. Now the receiver sends this flock of pigeons back to the sender to let them know what parts the receiver has received which are complete.
    15. The above procedure continues until the sender sees that all of the parts that were supposed to be sent, have been positively acknowledged. At this point, both the sender and receiver agree that all of the parts that are needed for re-assembling the car made it to their destination, and the car has been transmitted.

    Now let us assume that The birds may fly through the sky, but the skys over certain countries do not permit objects that are too large from traveling over head. Using the above scenario, birds entering into these special countries are fragmented (not to be confused with the disassembly above) into parts of pigeons, with information included in the pigeon on how the pigeon fragments must be re-assembled.

    • The receiver also knows how to deal with these partial pigeons that arrive by truck in parts, but all of the parts are included, and the part also has instructions on how it can be de-fragmented. The receiver then puts the pigeon back together along with the parts, and then uses the same acknowledgement procedure listed above as usual.
    • Since acknowledgments are not very heavy (quite unlike the various automotive parts that were being send by the sender), smaller pigeons can be used to send back the acknowledgments back to the original sender that will not need to be fragmented when flying over certain backwards countries with fascist laws about the size of flying objects.

    Here is where we make the sender into an evil and malicious user.

    • This user takes some perfectly nice pigeons and car parts from many different cars and not only disassembles the parts for the pigeons to carry, but also pre-fragments the pigeons.
    • Now this malicious user has decided to be mean to the receiver and confuse them, and add some extra parts to some pigeons that do not belong there (like parts from cows and a few hippos) and to some pigeons, he removes parts.
    • Now this evil user write instructions on how to de-fragment these "pigeons" and their payload, but write the instructions in such a way so as to make the assembled pigeon either way too large for a valid pigeon and part, or way to small for a valid pigeon with or without a part.
    • Now the user delivers these "pigeons" by truck, because the certainly cannot fly on their own anymore.
    • When the receiver gets the pigeons, he dutifully tries to assemble them following the instructions given to him. however, he will find that a pigeon once properly assembled does not look like a pigeon at all. This confuses him so much that he has a heart attack, and dies. Then the system administrator arrives in an ambulance, give CPR and reboots the receiver. (Similar event occurs when the receiver tries to assemble a pigeon and get something more than a pigeon that is not a real pigeon, and CPR is again needed.)

    Now the system administrator may look to see if he has instructions on how to build a new receiver of messages. If his receiver is an "Open-Source" receiver or was created under the GPL license, then the system administrator can make a brand new receiver that understands to throw away pigeons that are too small, or too large, or cow and hippo parts pretending to be pigeons. Once this new one is made, then the system administrator can replace the old receiver with the new and improved on that is better at coping with these problems.

    If the system administrator does not have a receiver created under the GPL or Open-Source, then the receiver must wait until the original creator has time to rebuild a newer and improved receiver, assuming the original creator can be found and is still alive...

    Using the above description on the fragmentation of pigeons, you might be able to draw you own parallels on packet fragmentation. Packets traveling on some networks must be made smaller in order to pass through them. Most of these networks are either out of date, or specialized, or run by incompetent users, or many other reasons. The end result is that the packets traveling through their network must be fragmented for them to be allowed to pass.

    As a side note, fragmentation does not exist in IPV6 (the next official version of IP). During the set up and conversation, a discovery is performed to find the largest packet size that can be pushed through all of the networks and nodes from sender to receiver, and then set all packets to use a maximum of that size of a packet.

    Apologies to those of you that feel the above section was too grotesque or violent.

• Another method for filtering packets includes looking at the payload or data portion of a packet. It is possible to tunnel IP inside of IP to break a firewall as well. An example for IP traffic over IP could be considered a VPN (Virtual Private Network) over the Internet. IP can be tunneled within other application layer protocols such as ssh, or 8-bit telnet with ppp and proper escape characters. For examination of the data in the body of the packet a firewall or filtering service has to have some understanding of application layer data. If there is a desire to prevent people from web browsing off site, then the filtering firewall may (in some cases) be set up (depending upon vendor) to examine the data portion and then filter out packets not only based on head information but also payload information too.
• Some firewalls allow you to have accounting for packets that you are thinking about filtering to see what kind of packets your new test policy will effect. (Useful to notice what services might be broken by a new policy you plan to use.)
• Another method to use in addition to, or instead of filtering based on header and possibly body information destined for the application layer include examination the state of connections.
  • This newer method examines the sequence number, and destination addresses, as well as if the connection is an attempted incoming connection or outgoing connection. The state oriented firewall keeps track of outgoing packets' destination addresses and other information about the outgoing connection request. Then when a remote machine appears to respond, the firewall examines the incoming packet to see if the "signature" of the returning packet matches any of the outgoing connection requests that came from behind the firewall. An examination process might look a little like this:
  • If:
    1. A connection is being created from a machine's with an IP address from inside the firewall
    2. This packet is also coming from the same interface that shares the network with the protected machine
    3. There is a returning response from the machine that was included in the destination address.
    4. This returning response packet is destined for the original machine behind the firewall
    5. The state table shows there was a pending request for connection request from the internal firewalled machine
    6. The returning request has a 32-bit acknowledgement number that matches the expected value based on the original machine-behind-the-firewall's sequence number in the original SYNcronize request (part of the "fingerprint" mentioned above.)

    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.)

    • This can be described like this: a user sends out an HTTP request to port 80 on a remote machine (You would expect the return response to be HTTP...)
      • If the return response is HTTP, or what you would expect from a web server, then great! Let that packet through!
      • If however, the response is an SSH or telnet response or something else that you would not expect to see coming from a web server, then something is wrong, and maybe it would be a good idea to not let this connection continue.
      • If instead the response is RealAudio, then maybe it would be OK to let it pass... Then again, if you want to be a fascist network admin, you may choose that a better policy would be to inconvenience the users who should not be listening to music when they are on the job anyway...
• A specialized (network layer) proxy server could also be used with a firewall and also use any one of the range of private IP addresses. (Sometimes called IP Masquerading, or one to many NAT.)
  (Frequently, "proxy server" is used to refer to an application layer relay, but as IP Masquerading also does some packet modification, it is also more like a proxy at the network layer than a router, but is more like a specialized router than an application layer proxy server.)

  (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...)

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.