netfilter Operation: Part Five

netfilter operationSimulating the Windows Firewall

Now it’s time to configure the firewall. The built-in firewall on Windows XP/Vista/7/8 is enabled by default (on XP Service Pack 2 or better). The standard configuration is to allow outbound connections from the host system and deny inbound connections unless they are explicitly configured. The Windows firewall also allows any traffic that is a reply to traffic that the host originally generated. After you execute the iptables -F command to flush out all the previously configured rules, the following commands would configure the Linux host similarly:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

The –state extensions track the current status of the connections. By specifying ESTABLISHED or RELATED, the firewall allows packets that are starting a new session, but where the session is related to an existing session (such as an FTP data session). If you were hosting a service on this system, such as a Web server, you would need to configure the INPUT chain appropriately. This configuration would afford any Linux system a minimum level of firewall security with virtually no impact to its overall functionality.

Simulating a Consumer-Grade Home Router

With the basics of iptables configuration out of the way, let’s consider a more practical example. For a typical firewall, there is very little traffic destined to or from the firewall itself. In general, the only traffic that would fit this profile would be administrative sessions to configure the firewall itself. The vast majority of a firewall’s traffic is passing through the firewall, and will thus be checked against the FORWARD chain. The following examples would configure the Linux firewall with the same access controls as a typical home network router such as a Linksys or Netgear router/firewall. This example assumes that is the internal network on interface eth0 and the external interface is eth1.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -s -i eth0 –dport 80 -j ACCEPT

iptables -A FORWARD -s -i eth0 -0 eth1 -j ACCEPT

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

One important element is to always remember that if you have configured the default policy for a chain to DROP (for example, iptables -P FORWARD DROP) that you will need to include an explicit rule to permit the return traffic. This can be done by using the following command:

iptables -A -m state –state ESTABLISHED,RELATED -j ACCEPT

So if you wanted to permit the return traffic for a FORWARD chain, you would enter:

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

Many hours of troubleshooting Linux firewalls have been spent by overlooking a rule that permits the return traffic.

We will continue our look at netfilter firewall configuration in the next article.

External Links:

Simulating windows firewall with iptables at

netfilter Operation: Part Four

netfilter operationPermitting Firewall Traffic

In the previous article, we set up netfilter with a default policy of DENY. Now that we have done that, we want to make sure that management traffic is permitted to the firewall itself. This is done first, because once you have enabled the firewall with a default policy of DENY, you will not be able to manage the firewall remotely until you have configured the firewall rules to permit the management traffic. This traffic is processed against the INPUT chain, because the destination is the netfilter host itself. To allow secure shell (SSH) connections to the firewall, use the following command:

iptables -A INPUT -p tcp -s –dport 22 -j ACCEPT

In this example, you are appending (-A) a rule to the INPUT chain to allow traffic from the network to a destination port of TCP 22. With no other configurations, all other traffic through or to the firewall would be dropped. This will show up in the rule listing as follows:

iptables -L INPUT
Chain INPUT (policy DROP)

Target prot opt source destination
ACCEPT tcp — anywhere tcp dpt:ssh

Although the aforementioned rules will permit the inbound SSH session, there is currently no rule to permit the reply traffic for the SSH session. If you were to change the default policy for the OUTPUT chain to ACCEPT, this would permit the reply packet, but we will instead address this more securely in the next few examples.

If you wanted to allow access to the firewall with a destination of TCP port 80, you could use the same syntax with -A to append the rule, which would put the new rule for port 80 after the rule for port 22. You could also use -I for insert, as in the iptables -I INPUT 1 -p tcp -s -dport 80 -j ACCEPT command. This would insert the new rule in the INPUT chain as rule #1, meaning the rule for port 80 would come before the rule for port 22. Remember, this is still permitting only half the conversation; you still need to permit the outbound reply packets. It is sometimes useful to list the chains with rule numbers using the iptables -L (or –line-numbers) command.

For outbound traffic (i.e. traffic generated by the firewall), you need to create rules in the OUTPUT chain. To enable syslog traffic from the firewall to a remote syslog server (, you would enter the following:

iptables -A OUTPUT -p udb -d –dport 514

This assumes you are using the default UDP syslog port of 514. Because syslog over UDP is a one-way conversation, you will not need to permit any inbound replies for permitted traffic that you allowed inbound in the preceding examples. You could create rules to permit SSH and HTTP specifically, but there is also a way to permit all traffic that is a reply to a permitted session. You can enter:

iptables -A OUTPUT -m state –state RELATED, ESTABLISHED -j ACCEPT

This will instruct netfilter to permit any outbound traffic that is part of an established session (ESTABLISHED). The RELATED keyword is similar, but is for traffic that is part of a different session, but where the session is related to an established session. Some protocols will open additional ports (such as FTP) as part of their normal behavior. For those that netfilter understands, it can see the request for the additional port and permit that new session.

External Links:

Simple Firewall Configuration Using NetFilter/iptables at

pfSense 2.1.1 Pre-Release Snapshots Available

pfSense 2.1.1 pre-release snapshots are available via’s snapshot server, at

A list of changes between 2.1 and 2.1.1 can be found here:

netfilter Operation: Part Three

The firewall GUI in Fedora.

The firewall GUI in Fedora.

The next step is to demonstrate how to configure the netfilter firewall. This is a critical step and the firewall should only be installed and configured after the underlying OS has been installed, updated, and hardened. We assume here that you are working with an otherwise secure system and now need to configure the firewall’s functionality.

To make sure the firewall is enabled, you can run chkconfig –list, which lists all of the services and the run levels they are configured to start in. For example, you may get the following output:

chkconfig –list | grep iptables

iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off

This output tells you that iptables will start in run levels 2-5. You can set it to run in run levels 2-5 by using the chkconfig -level 2345 iptables on command. If you are using a GUI window manager, you probably have another graphical application to see this information. For example, in Fedora, you can navigate to System -> Administration -> Security Level and Firewall.

You can enable or disable the firewall by going to the Firewall Options tab and selecting Enabled or Disabled. The interface in Fedora allows you to perform limited configurations of the firewall rules (e.g., by checking the Trusted Service SSH, a rule would be added to allow inbound connections on TCP port 22). Because any graphical interface provided will likely vary from one distribution to another, we use the command line to configure the firewall.

netfilter Operation: Deleting Rules and Chains

With many Linux distributions, the netfilter firewall will become enabled, but with an empty ruleset. In others, it might come with the firewall enabled and a very liberal ruleset in place. We can start configuring a Linux firewall by deleting any default rules that are present. You can use iptables -L (or –list) to list the current rules. An empty default ruleset should look like this:

iptables -L
Chain INPUT (policy ACCEPT)
Target prot opt source destination

Chain FORWARD (policy ACCEPT)
Target prot opt source destination

Chain OUTPUT (policy ACCEPT)
Target prot opt source destination

If there are any default rules present, they can be deleted using the iptables -F command. The -F option means to flush, which is equivalent to using -flush. This will clear all rules out of any existing chains. If distribution has any additional chains created beyond the default, you can delete a custom chain by using the iptables -N customchain command. In addition to the individual rules within a chain, the built-in chains have a default policy associated with them. This policy tells netfilter what to do if a packet reaches the end of the chain without finding a match. While the default policy is to ACCEPT, it is better to change this to DROP by using the -P option, which sets the default policy for that chain, as follows:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

We will continue our look at netfilter configuration in the next article.

External Links:

Basic Fedora Linux Firewall Configuration at

netfilter Operation: Part Two

netfilter operationNow that we have covered the various tables and chains, we can discuss the overall packet flow. The key to remember is that not all packets traverse all chains. To further complicate matters, packets will traverse different chains depending on whether they are sourced from the netfilter host, destined for the netfilter host, or just passing through the netfilter host. Knowing this will save you time when troubleshooting your firewall rules in the future.

Targets are the actions that should be taken when a packet matches a given rule. A target is specified using the -j syntax (for jump). The primary targets used for a firewall are ACCEPT and DENY.

  • ACCEPT: The packet is accepted and processed by the rest of the TCP/IP stack.
  • DENY: The packet is dropped and no notice is given to the sender. While this does not honor the TCP/IP protocol specifications, it is considered the most secure option, because it denies a hacker useful information about the firewall. This behavior also has a negative side effect, which is if a system is trying to initiate a connection to a port that is blocked by a firewall, the connection attempt must time out before the initiating host gives up. If you use REJECT, the Internet Control Message Protocol (ICMP) port will allow the initiating system to abort the connection attempt immediately.
  • LOG: This allows you to perform kernel logging, which appears in the syslog log. Further options allow you to specify the log level and a descriptive prefix for the log entry.
  • RETURN: Processing continues in the previous chain at the rule just after the last rule processed in that chain.
  • QUEUE: This is a special target that will hold (or queue) a packet for processing by a userspace process.

Unlike some firewalls, netfilter allows you to apply multiple rulesets (chains) to the same interface. Although it may seem minor, this option creates a lot of powerful possibilities. For example, suppose you have an ACL and you want to permit all packets originating on the network except those from, which is a host that a third party uses and is not a completely trusted system. You want packets sourced from with a destination port of 22, 25, 53, 80 and 443 to be permitted, while all other packets are to be blocked.

Using netfilter and iptables, you can create a rule to implement this policy:

1 somerule
2 iptables -A FORWARD -p tcp -s -j CUSTOM
2.1 iptables -A CUSTOM -p tcp -s –dport 22 -j ACCEPT
2.2 iptables -A CUSTOM -p tcp -s –dport 25 -j ACCEPT
2.3 iptables -A CUSTOM -p tcp -s –dport 53 -j ACCEPT
2.4 iptables -A CUSTOM -p tcp -s –dport 80 -j ACCEPT
2.5 iptables -A CUSTOM -p tcp -s –dport 443 -j ACCEPT
2.6 iptables -A CUSTOM -p ip -s -j DROP
2.7 iptables -A CUSTOM -j RETURN
3 iptables -A FORWARD -p ip -s -j ACCEPT
4 somerule

Using netfilter and iptables, we created rule #2, which says that the source address is for processing the CUSTOM chain. You can create the CUSTOM chain with the iptables -N CUSTOM command. Within the CUSTOM chain, you check for the five permitted destination ports (rules 2.1-2.5) and then reject everything else (rule 2.6). Rule #2.7 has no matching criteria and will therefore match on nay packet and instruct the packet to return to the FORWARD chain where processing can continue. FORWARD chain rule #3 permits all other packets from the network. This means that packets not sourced from only have to be checked against rule #2 and can then move through the chain(s) instead of being checked against all the rules.

External Links:

Using Custom Chains in iptables at

netfilter Operation: Part One

netfilter operationBefore covering some of the specific commands used to configure the Linux firewall, I will cover some basic Linux firewall vocabulary and some of the basics of netfilter operation. netfilter contains the firewall logic, and iptables is the program that is used to modify the rules that the firewall uses. These rules (or ACLs) define the rules used to permit or deny packets and how to react to denied packets. The current iptables use both tables and chains. Tables are the blocks of processing where various actions are performed on the packets. Different tables process different chains. Chains are a set of rules (or ACLs). There are four built-in tables that help define netfilter operation: nat, mangle, filter and raw, each of which processes different chains.

netfilter Operation: Tables and Chains

The following tables and chains are not listed in any particular order, as a given packet may be impacted by multiple tables and chains as it is processed. The primary built-in chains are INPUT, OUTPUT, and FORWARD. In addition to these, you can create your own user-defined chains to customize netfilter operation.

  • Nat Table: In netfilter operation, this table is referenced with a packet that is used to create a new connection.
    • PREROUTING: This chain is processed as soon as a packet is received and before any routing decisions are made.
    • POSTROUTING: This chain is processed before a packet is sent to an interface but after any routing decisions have been made.
    • OUTPUT: This chain is processed for packets generated locally.
  • Filter Table: This is the default table that is used when the iptables command is used to modify the rules and do not specify an alternate table. This is where the bulk of a firewall’s processing is consumed.
    • INPUT: This chain is processed for packets destined for the local system.
    • FORWARD: This chain is processed for processed for packets passing through the local system.
    • OUTPUT: This chain is processed for packets generated by local system.
  • Mangle Table: This table is used for any specialized packet alterations that are needed. Examples are performing Network Address Translation (NAT) or manipulating various bits within the packet.
    • PREROUTING: This chain is processed on incoming packets before a routing decision is made.
    • POSTROUTING: This chain is processed last before a packet is sent to an interface.
    • OUTPUT: This chain is processed before a routing decision is made for packets generated locally.
    • INPUT: This chain is processed for packets destined for the local system.
    • FORWARD: This chain is processed for packets passing through the local system.
  • Raw Table: This table is primarily used for packets that are exempt from connection tracking, and if required, are called before any other netfilter table.
    • PREROUTING: This chain is processed as soon as a packet is received.
    • OUTPUT: This chain is processed for packets generated locally.

Now that we have reviewed all the various tables and chains, we can continue our look at netfilter operation by discussing the overall packet flow, which we will do in the next article.

External Links:

Netfilter Overview at

How the netfilter System Works at

Linux Firewall Installation Media

Linux firewallOne of the more interesting features that Linux has over Windows is that it can be run from a variety of media. While Windows is notoriously difficult to configure to run from a CD-ROM (but still possible: see for the Ultimate Boot CD for Windows), there are Linux distributions that are capable of running off a traditional hard disk install, CD-ROM, a Universal Serial Bus (USB) drive, or even a floppy disk. Each media type offers some security pros and cons, and not every distribution will be available on every media type. If you need the features of a specific distribution that doesn’t come on the media you prefer, you may need to make a compromise. You will need to research the different media options and choose one that fits in your environment. We will review some of the pros and cons of each for Linux firewall installations.

Linux Firewall: Hard Disk Installation

The full install is the traditional install to a system’s hard disk. Much like Windows, you boot up an install CD and walk through a guided install process. Most of the Linux distributions installed on the hard disk offer graphical user interface (GUI) install programs that walk you through the installation steps. There is no great advantage to using this type of distribution other than that the size of the hard disk allows you to install a lot of extra software. For a firewall, you generally want to keep the software running to a minimum to enhance security, so this shouldn’t be a very big consideration. This type of installation also has the advantage that it will be easy to modify and alter the configuration if needed.

On the down side, this type of installation has all of the same disadvantages of a Windows bastion host: the entire system is sitting on the hard drive, and if a hacker manages to compromise the root account, they will be able to install a virus or Trojan on the system that can survive future reboots. This type of install isn’t any better or worse than if you were using Windows for your bastion host OS. Despite these concerns, it is the most common type of Linux firewall installation, and most versions of Linux install the firewall components by default. This means if you download a version of Linux you like and install it to a hard disk, you will have a firewall waiting to be configured when you’re done.

Linux Firewall: CD-ROM Installation

While you can get Windows running off of a bootable CD-ROM or live CD, it takes a lot more work than it does with Linux. There are many versions of Linux designed specifically to run from a CD-ROM, allowing you to turn virtually any machine into a Linux firewall, router, or general-purpose PC. There is an obvious security advantage to having all of your configuration information on read-only media media. Even if a hacker manages to compromise the system, all it takes is a reboot and it can be restored to its previous condition. The system can still fall victim to a hardware failure such as a failed central processing unit (CPU), all you would need to do to restore your firewall would be to move the CD to a new system and reboot.

The primary advantage to a CD-ROM-based Linux firewall installation is also the primary disadvantage. If you burn the entire OS and configuration settings to a CD, any time you need to make adjustments you would need to burn a new CD-ROM. The cost of the CD media should not be an issue, but such a configuration may hinder your ability to remotely administer the system, which would be limited to making changes to the running configuration. Changes that remained after a reboot would require someone local to insert the CD-ROM containing the new configuration. If you needed to implement and test changes that required a reboot to take effect, this type of setup would make things more difficult. Finally, due to simple space limitations on a CD-ROM, you may not be able to fit all of the needed software or functionality on a CD-ROM. That being said, if the firewall rules are relatively static and don’t require frequent adjustment, a live CD could be a very attractive option.

Linux Firewall: USB Drive Installation

If the space limitations are acceptable, a Linux firewall booting from a USB disk may offer the best compromise in security and flexibility. Having the operating systems and firewall software on a pen drive offers the same type of flexibility that a CD-ROM-based system provides, with increased storage capacity over that of a CD-ROM. If you purchase a USB disk that includes a physical write protect switch, you can make changes on the fly, like a live system, and then write protect the disk against modification when you are done. As the storage capacity of USB drives increases, you will be able to use a USB-based distribution that includes increasingly greater functionality. One key consideration with this type of media is that not all systems will support booting from a USB disk. While almost all newer systems support this option, some of the older systems that you may wish to install a free firewall on do not.

Linux Firewall: Floppy Disk Installation

Although the functionality is typically very limited, there are many versions of Linux that can fit on a 3.5-inch disk, and that can be used for Linux firewalls. The primary advantage of these distributions is their low resource requirements. Often, the systems only require 8 or 16 megabytes of memory and a 486 to function. The ability to toggle the write-protect switch on the floppy can also provide a high degree of configuration flexibility and security. Considering the unreliable nature of floppy disks, it probably wouldn’t be appropriate for use if an outage cannot be tolerated. At the very least you should have duplicate floppy disks available in the event of a failure. Another disadvantage to these is functionality. Generally, these floppy-based distributions are single purpose devices and lack much in the way of functionality. Another consideration is that due to the space restrictions on a floppy disk, these floppy-based distributions are almost always command line only, with no GUI for configuration or management.

Now that we’ve covered installation media for Linux firewalls, we can cover the operation of a Linux firewall, which we will in the next article.

External Links:

Ultimate Boot CD for Windows site

Devil-Linux – a distribution which boots and runs completely from a CD-ROM or USB flash drive

Damn Small Linux – the original Linux on a CD-ROM/USB drive distro

Firewall Implementation: Part One

firewall implementationWhen it comes to firewall implementation there are a host of factors to consider. For commercial offerings there is the up front cost in addition to ongoing maintenance costs, which in some cases can be considerable. Some commercial offerings run their own base system. The underlying Linux system has been so heavily modified it is now considered proprietary. In the case of a Linux firewall, you also have the option of installing the firewall software on a CD-ROM or pen drive. These steps are discussed in more detail in the following sections, along with specific configuration examples for setting up a free firewall on both Linux and Windows.

Firewall Implementation: Hardware-Based Firewalls vs. Software-Based Firewalls

Another consideration in firewall implementation is whether the firewall decision-making logic is run as software that sites on top of another functional system, or if the firewall is a dedicated piece of hardware. In the case of a Cisco PIX firewall, the smallest models are the size of a small cigar box and there is no OS other than the PIX software. This is a dedicated hardware device used to perform the firewall function, also called a firewall appliance. The other alternative is that the firewall is not a dedicated box, but a software component. Many popular firewalls take this approach as well, such as a checkpoint firewall that can be installed on top of a Windows system. Of these two approaches, if you want a free solution the choice is made for you: since there is no free hardware-based firewall, you will be using a software-based firewall.

Firewall Implementation: netfilter

When it comes to Linux-based firewall, there is only one choice, which is netfilter. This is partially because it was the best option available for the longest time. Since version 2.4, however, netfilter has been built into the Linux kernel. Even many commercial firewalls are running a modified Linux OS with netfilter inside their own custom case. netfilter is the underlying software that makes up the built-in firewall on Linux systems. It is the netfilter component that reads the contents of the network packet and permits or denies network traffic. Often people incorrectly refer to the firewall as iptables or ipchains. In fact, iptables is the software command that is used to configure the rules that netfilter uses to make decisions to permit or deny traffic and ipchains is the previous version of iptables. Even after you have settled on using Linux as your base OS for your firewall, there are some additional choices to make before you start any configuring.

Firewall Implementation: Choosing a Linux Distro

While all versions of Linux share some characteristics, there will be differences. Depending on the specific Linux distribution, the differences could be significant and each distribution will likely offer some different sets of software packages. Because there are so many free versions of Linux available, it doesn’t cost anything but the time to download and install several different versions and see which one you like. I tend to use Fedora, because it is the community version of Red Hat, one of the oldest and most well-established Linux distributions. However, Fedora has fallen out of favor with many Linux users over the years, and your mileage may vary. Ubuntu is also very popular, although power users may find it annoying. Most likely you will want to try out the Live CD version of a distribution (if one is available) before you make up your mind. When it comes to choosing the specific version of Linux you want to use, this decision must be made in parallel with choosing an installation media, because not all versions are supported on all media.

In the next article, we will continue our look at firewall implementation, including the choice of distribution media.

External Links:

netfilter at Wikipedia

Distrowatch – a good site for information and links to various Linux distributions

Firewall Architecture

firewall architectureThe most securely configured firewall in existence will not provide much protection if a network was not designed properly. For example, if the firewall was installed into an environment that allows an alternate network path that bypasses the firewall, the firewall would only be providing a false sense of security. This is an firewall architecture error that would render the firewall useless. Thus, where the firewall is implemented is every bit as important as how it is implemented. The first step to installing anything is always planning. What follows in this article is a discussion of the most common firewall architectures, in increasing order of security.

Firewall Architecture: Screened Subnet

A screened subnet is the simplest and most common firewall architecture implementation. Most small businesses and homes use this type of firewall. This design places the firewall on the edge of your network, dividing everything (from the firewall’s point of view) into internal and external, with nothing in between.

The screened subnet firewall (or edge firewall) is a straightforward as you can get. Internet users who need access to an internal server must traverse the firewall to do so. Internal users needing access to those same servers would able to access them directly. Internet traffic not destined for any server the admin does not want to provide access to would be blocked at the firewall to prevent attacks on internal systems. All internal users must also traverse firewalls to access the Internet. This is the same type of firewall you would have at home with a small network behind, say, a Linksys or Netgear router. This configuration has several advantages. The primary advantage is simplicity. With only two interfaces, the Access Control Lists (ACLs) – the filters that define the criteria for permitting or denying traffic – are much simpler.

Although this configuration is cost effective and simple to implement, it is not without its drawbacks. In this arrangement, the hacker has several chances to penetrate your network. If they can find a security hole in the firewall, or if the firewall is improperly configured, the hacker might be able to gain access to the internal network. Even if the firewall is executed flawlessly, the hacker has a second opportunity to gain access. If the hacker can compromise any available web-based services and take control of the servers, they would have an internal system from which to launch additional attacks. Finally, if the servers are critical to the business function, by allowing the internal users to access them without going through the firewall, you may lose some audit capability that the firewall might otherwise offer. By far the biggest security weakness in the configuration is that if you are exposing any web-based services: the servers hosting those services will be attacked frequently, and a compromise of one of those servers may expose your entire network. Thus, we are led to consider other forms of firewall architecture: the one-legged DMZ and true DMZ.

Firewall Architecture: One-Legged DMZ

The one-legged demilitarized zone (DMZ) still has the advantage of cost, because you are building a DMZ using only a single firewall. Commonly, the firewall interfaces are called Internal or Inside, External or Outside, and DMZ.

With this type of firewall architecture you get to keep the low-cost benefit, but add some isolation to your Internet-based servers. Internal users must traverse the firewall to access the servers or the Internet. External users must traverse the firewall to access the Web-based services. The real strength of this type of configuration is that if the servers that are hosting the web-based services are compromised, the hacker still needs to contend with the firewall to continue attacking the internal network. As an added feature, because all users (internal and external) must traverse the firewall to access the web-based servers, you may gain a higher degree of auditing from the firewall logs. If you wanted to provide even further isolation, assuming you have the available interfaces on the firewall, you could implement a separate DMZ for each web-based server you needed.

The only real disadvantages to this configuration are complexity, and to a small degree, cost. As you add interfaces to the firewall, the configuration will become more complex. not only does this complexity add to the time and labor for configuration and maintenance, it also increases the chance that an error could be made in the configuration. As you add interfaces there will often be additional costs associated with them. In most cases this cost will be minor and far less than an additional firewall, but with some high-speed interfaces, they can become very costly. Lastly, with this configuration, if the firewall itself is defeated, the entire network is open to attack.

Firewall Architecture: True DMZ

The true DMZ is generally considered the most secure of firewall architectures. With this design, there is an external and internal firewall. Between the two is sandwiched any Internet accessible devices.

Internet traffic is only permitted to a server in the SMZ, and only on the port that server is listening on. For example, if you had a web server in the DMZ and an FTP server in the DMZ, traffic with a destination port of 80 would only be permitted to the web server. For users accessing the same servers, the same rules would apply. Internal users would have to have permission through both firewalls to access the Internet. Obviously, this type of design costs more, typically double, but that cost buys you increased security. In a true DMZ, if the web server is compromised the hacker is still trapped between two firewalls. For those who want to go the extra mile, the inside and outside firewalls can be of different types. In this way, a hacker that finds a security hole in one firewall is unlikely to be able to apply the same techniques to the other firewall.

Firewall Architecture: Conclusion

Now that we have covered the basics of firewall architecture, you should be in a better position to make a decision about proposing and implementing a firewall solution for your network. In the next article, we will cover firewall implementation.

External Links:

DMZ at Wikipedia

SolutionBase: Strengthen Network Defenses by Using a DMZ at

Four Tips for Securing a Network DMZ at

Designing and Using DMZ Netwroks to Protect Internet Servers at

What Is a Firewall – Answered

What Is a Firewall

What Is a Firewall?

What is a firewall? A firewall is basically any component (software or hardware) that restricts the flow of network traffic. This is a sufficiently broad definition to allow for all of the various ways people have chosen to implement firewalls. Some firewalls are notoriously limited in capability and others are extremely easy to use. The question of “what is a firewall” has evolved over time as the capabilities of firewalls have increased.

Within the realm of firewalls there are many different ways to restrict network traffic. Most of these methods vary in the level of intelligence that is applied to the decision-making process. For example, to permit or deny traffic based on which network device is the sender or recipient, you would use a packet-filtering firewall. In reality, even the simplest packet-filtering firewalls can typically make decisions based on the source Internet Protocol (IP) address, the destination IP address, and the source and/or destination port number. While this type of firewall may sound overly simplistic, consider the case where you have a server running a web site for use on the Internet. In all likelihood, the only traffic that you need to allow to the server uses a destination port of TCP (Transmission Control Protcol) 80 or 443. As a result, you could configure your firewall to permit only that traffic. Because the server is available for the Internet, you can’t filter traffic based on the source address or source port, which will be different for each connection.

The primary drawback with a simple packet filter is that the packet filtering firewall has to rely on very primitive means to determine when traffic should be allowed (e.g. synchronous [SYN] or acknowledgement [ACK] bits being set). While this was adequate in the early data of the Internet when security was not as big of a concern, it won’t work anymore. It is trivial to set the bits on the packet using freely available software to make the traffic look like it is a reply to another connection.

What Is a Firewall: Stateful Firewalls (Second Generation)

Thus the stateful inspection firewall was born of necessity. Developed initially at AT&T Bell Laboratories in 1989-90, this type of firewall performs the work of their first-generation predecessors but operates up to layer 4 (transport layer) of the OSI model. It monitors all connections (inbound or outbound), and as the connection is permitted (based on the firewall’s rules), it enters the connection into a table. When the reply to this connection comes back, even if the reply uses a port that the firewall was not previously configured to permit, it can intelligently realize the traffic is a response to a permitted session and permit the traffic.

Unfortunately, even as the firewalls get better, so do the methods hackers use to circumvent them. Suppose you have configured your firewall perfectly and there are no holes: every permitted port is one you expressly want to allow. Using the previous example, no traffic is allowed to the web server except web traffic. This sounds like a solid policy, but the problem is even if the firewall is completely secure, the server might not be. Flaws in the web server software could allow the attacker to send the server an HTTP request that is 10,000 characters long, overflowing the buffers and allowing the attacker to execute the code of his choice. The packets used to transport the 10,000-character HTTP request are all legal TCP packets as far as the firewall is concerned: therefore, it would permit them to pass through to the web server. The next step in firewall evolution serves to combat this type of attack: application gateways, or layer 7 firewalls. The first transparent application level firewall was Gauntlet, an outgrowth of Toolkit, developed by Marcus Ranum, Wei Xu, and Peter Churchyard.

What Is a Firewall: Application Layer Firewalls (Third Generation)

This type of firewall not only filters network traffic based on the standard network parameters, but they also understand the higher layer protocol information contained within the packet. In this example, the firewall would be looking for HTTP requests. The firewall knows what a legitimate HTTP request looks like and can out a malformed or malicious request even though, from a network perspective, it might otherwise be a permitted packet. There is a down side to this type of approach: the firewall must be programmed with all the same intelligence needed to filter normal traffic, plus the firewall must fully understand the protocols it is inspecting. This means additional programming for any protocol you want the firewall to understand. Most of the major commercial application gateways offer support for the major protocols such as HTTP, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP).

Generally speaking, you can find many free varieties of firewalls that perform some type of stateful inspection. Application layer gateways are not really available for free. In reality, few organizations have the funds to use application gateways extensively. One ramification of not using an application gateway is that you need to ensure that the service that is exposed to untrusted traffic is configured as securely as possible and that the server itself is hardened against attack. Keeping the service patches up-to-date will help reduce the odds that an application-level attack will be successful.

External Links for “What Is a Firewall – Answered”:

Firewall (computing) at Wikipedia

What Is a Firewall at Indiana University Information Technology Services Knowledge Base

What Is a Firewall at

What Is a Firewall? at Netgear Support

© 2013 David Zientara. All rights reserved. Privacy Policy