There were three initial items that this aper looked to address:
As you have read, there is nothing very mystical about a filtering firewall. It is just an intelligent filter that takes a policy and compares each and every packet to what is allowed for both incoming and outgoing packets. If a packet violates this rule, then it is trashed. You have seen where in a packet the information that is reviewed by a filtering firewall's policy in the section where we decompose a Network, and Transport layer packet for the TCP/IP suite of protocols.
The most complex part of setting up a firewall comes in understanding the risks associated with different kinds of servers and the default applications used to provide those services. For example, "sendmail" is a program often run on servers to provide the ability to receive mail on a server. This server is always on, and waits for incoming mail to be delivered, then it accepts the mail if it knows the user, or may proxy the mail to a different box, or reject it, or discard it. Sendmail was also notoriously flawed from a security point of view. Malicious crackers could remotely exploit security holes in sendmail to gain administrative (root) access to many servers that ran sendmail. Without this knowledge, you may not worry about a mail server being placed on your LAN. With this knowledge, you may decide to run a different mail server like qmail, and then locate it by itself outside the firewall, and have another server connect up to this mail server outside your firewall to transfer all of the mail from the outside mail server to an internal POP server every 10 minutes or so for your local users to read e-mail.
A risk with using a firewall, is caused by your employees. Employees think to themselves, "gee, we have a firewall, so I do not need to be security conscious" and this may lead to more problems. If an exploit is found to pierce your firewall, and the users in your network use passwords with one character like "a" then your internal network may be at serious risk. Use of plain-text authentication systems like telnet and ftp, for shell access and transfer of files respectively, may pace you at further risk after firewall penetration from session hijacking (where someone picks up your authenticated session in telnet), or 'snarfing' of username and password pairs with a sniffer.
A firewall is not a replacement for internal security, and should not be expected to keep a network safe from attack. A firewall is a tool to aid in making access to your resources more difficult to obtain from unauthorized users. Granted it can be a powerful tool, there is a risk that it may lull users into a false sense of security causing them to become sloppy with their own personal security. A filtering firewall is not a complex thing, and neither is the operation, but the understanding of what services are at risk, and how they function is a non-trivial task. A great deal of memorization an experience helps a network administrator to properly create a policy to limit access to internal LAN resources.
A firewall can be thought of as more than just a single box you buy off the shelf (and should not be evaluated in this way.) Often a firewall includes not only the box, but the policies for filtering traffic, and the internal political policies as dictated by management for employees. Logging of information related to session passing through a firewall can also be accomplished in many cases to include logging attempts made to gain unauthorized access to your network resources. It also includes remaining up to date on new security problems with services and operating systems.
If you have questions or comments about the information, you should be able to locate my IP address at the bottom of this document, as well as all of the documents in this paper. I do not take a hostile stand towards people that correct my mistakes, or mis-understandings; it helps to keep everyone else informed that may visit this paper.