If you have ever wondered how to configure and run a secure open source firewall, look no further. This book excerpt is from chapter three of Open Source Security Tools by Tony Howlett, ISBN 0321194438, copyright 2004. All rights reserved. It is reprinted with permission from Addison-Wesley Professional.

So now that you have a fairly secure operating system and know a few basic tricks, let’s get into using some more complex security tools. This chapter describes how to configure and run a secure open source firewall. If you already have a firewall, you may still want to read this chapter if you need a refresher or primer on how firewalls function. This will come in handy in later chapters that discuss port scanners and vulnerability scanners.

A firewall is a device that acts as the first line of first defense against any incoming attacks or misuses of your network. It can deflect or blunt many kinds of attacks and shield your internal servers and workstations from the Internet. A firewall can also prevent internal LAN machines from being accessed from outside your network. With the growing use of random scanners and automated worms and viruses, keeping your internal machines shielded from the Internet is more important than ever. A properly configured firewall will get you a long way towards being safe from outside attacks. (Protecting yourself from inside attacks is a different thing altogether and is a subject of Chapters 4 through 7.)

Chapter Overview

Concepts you will learn:

• Basic concepts of TCP/IP networking
• How firewalls operate
• The philosophy of firewall configuration
• Business processes for firewalls
• Sample firewall configurations

Tools you will use: Iptables, Turtle Firewall, and SmoothWall

It’s pretty much a given these days that firewalls are an essential part of any secure infrastructure. There are many very viable commercial alternatives available: Cisco, NetScreen, SonicWALL, and Checkpoint are just a few of the vendors making high-end, commercial firewall solutions. These products are built to handle large corporate networks and high traffic volumes

Linksys (now owned by Cisco), D-Link, and NETGEAR are some of the vendors making low-end consumer-grade firewalls. These devices generally don’t have much configurability or expandability; they basically act as a packet filter, blocking incoming TCP and UDP connections and as a NAT appliance. They are usually marketed for DSL and cable-type connections and may buckle under heavier loads.

The higher end firewalls will do just about anything you want them to do. However, that comes at a price: most of them start at several thousand dollars and go up from there. And they often require you to learn a new syntax or interface in order to configure them. Some of the newer models, like SonicWALL and NetScreen, are going to a Web-based configuration interface, but that usually comes at the expense of less depth in the configuration options.

The little known and rarely advertised secret of some commercial firewalls is that they have open source software just underneath the hood. What you are really paying for is the fancy case and the technical support line. This may be worth it for companies that need the extra support. However, if you are going to have to learn yet another interface, and if they are using the same technologies that are available to you for free, why not create your own firewall with the open source tools provided in this book and save your firm thousands of dollars? Even if you don’t want to throw out your commercial firewall, learning more about firewall basics and what happens behind the scenes will help you keep your firewall more securely configured.

Before we dive into the tools, I want to go over the basics of what a firewall does and how it works with the various network protocols to limit access to your network. Even if you are not planning to use open source software for your firewall, you can still benefit from knowing a little more about what is really going on inside that black box.

{mospagebreak title=Network Architecture Basics}

Before you can truly understand network security, you have to first understand network architecture. Although this book is not intended to serve as a network primer, this section is a quick review of network concepts and terms. I will be referring to these terms often and it will help you to have a basic understanding of the TCP/IP protocol. If you are already well-schooled in network topologies, then you can skip over this section and jump straight into the tools.

As you may know, every network design can be divided into seven logical parts, each of which handles a different part of the communication task. This seven-layered design is called the OSI Reference Model. It was created by the International Standards Organizations (ISO) to provide a logical model for describing network communications, and it helps vendors standardize equipment and software. Figure 3.1 shows the OSI Reference Model and gives examples of each layer.

OSI Layer NumberLayer Name Sample Protocols
Layer 7ApplicationDNS, FTP, HTTP, SMTP, SNMP, Telnet
Layer 6PresentationXDR
Layer 5SessionNamed Pipes, RPC
Layer 4TransportNetBIOS, TCP, UDP
Layer 3NetworkARP, IP, IPX, OSPF
Layer 2Data LinkArcnet, Ethernet, Token Ring
Layer 1PhysicalCoaxial, Fiber Optic, UTP

Figure 3.1 The OSI Reference Model


This layer is the actual physical media that carries the data. Different types of media use different standards. For example, coaxial cable, unshielded twisted pair (UTP), and fiber optic cable each serve a different purpose: coaxial cable is used in older LAN installations as well as Internet service through cable TV networks, UTP is generally used for in-house cable runs, while fiber optic is generally used for long-haul connections that require a high load capacity.

Data Link

This layer relates to different pieces of network interface hardware on the network. It helps encode the data and put it on the physical media. It also allows devices to identify each other when trying to communicate with another node. An example of a data link layer address is your network card’s MAC address. (No, the MAC address doesn’t have anything to do with Apple computers; it’s the Medium Access Control number that uniquely identifies your computer’s card on the network.) On an Ethernet network, MAC addresses are the way your computer can be found. Corporations used many different types of data link standards in the 1970s and 80s, mostly determined by their hardware vendor. IBM used Token Ring for their PC networks and SNA for most of their bigger hardware, DEC used a different standard, and Apple used yet another. Most companies use Ethernet today because it is widespread and cheap.


This layer is the first part that you really see when interacting with TCP/IP networks. The network layer allows for communications across different physical networks by using a secondary identification layer. On TCP/IP networks, this is an IP address. The IP address on your computer helps get your data routed from place to place on the network and over the Internet. This address is a unique number to identify your computer on an IP-based network. In some cases, this number is unique to a computer; no other machine on the Internet can have that address. This is the case with normal publicly routable IP addresses. On internal LANs, machines often use private IP address blocks. These have been reserved for internal use only and will not route across the Internet. These numbers may not be unique from network to network but still must be unique within each LAN. While two computers may have the same private IP address on different internal networks, they will never have the same MAC address, as it is a serial number assigned by the NIC manufacturer. There are some exceptions to this (see the sidebar Follow the MAC), but generally the MAC address will uniquely identify that computer (or at least the network interface card inside that computer).

Howlett Flamey the Tech Tip: Follow the MAC
MAC addresses can help you troubleshoot a number of network problems. Although the MAC address doesn’t identify a machine directly by name, all MAC addresses are assigned by the manufacturer and start with a specific number for each vendor. Check out for a comprehensive list. They are also usually printed on the card itself.

By using one of the network sniffers discussed in Chapter 6, you can often track down the source of troublesome network traffic using MAC addresses. Mac addresses are usually logged by things like a Windows DHCP server or firewalls, so you can correlate MAC addresses to a specific IP address or machine name. You can also use them for forensic evidence—amateur hackers often forge IP addresses, but most don’t know how to forge their MAC address, and this can uniquely identify their PCs.


This level handles getting the data packet from point A to point B. This is the layer where the TCP and UDP protocols reside. TCP (Transmission Control Protocol) basically ensures that packets are consistently sent and received on the other end. It allows for bitlevel error correction, retransmission of lost segments, and fragmented traffic and packet reordering. UDP (User Datagram Protocol) is a lighter weight scheme used for multimedia traffic and short, low-overhead transmissions like DNS requests. It also does error detection and data multiplexing, but does not provide any facility for data reordering or ensured data arrival. This layer and the network layer are where most firewalls operate.


The session layer is primarily involved with setting up a connection and then closing it down. It also sometimes does authentication to determine which parties are allowed to participate in a session. It is mostly used for specific applications higher up the model.


This layer handles certain encoding or decoding required to present the data in a format readable by the receiving party. Some forms of encryption could be considered presentation. The distinction between application and session layers is fine and some people argue that the presentation and application layers are basically the same thing.


This final level is where an application program gets the data. This can be FTP, HTTP, SMTP, or many others. At this level, some program handling the actual data inside the packet takes over. This level gives security professionals fits, because most security exploits happen here.

{mospagebreak title=TCP/IP Networking}

The TCP/IP network protocol was once an obscure protocol used mostly by government and educational institutions. In fact, it was invented by the military research agency, DARPA, to provide interruption-free networking. Their goal was to create a network that could withstand multiple link failures in the event of something catastrophic like a nuclear strike. Traditional data communications had always relied on a single direct connection, and if that connection was degraded or tampered with, the communications would cease. TCP/IP offered a way to “packetize” the data and let it find its own way across the network. This created the first fault-tolerant network.

However, most corporations still used the network protocols provided by their hardware manufacturers. IBM shops were usually NetBIOS or SNA; Novell LANs used a protocol called IPX/SPX; and Windows LANs used yet another standard, called NetBEUI, which was derived from the IBM NetBIOS. Although TCP/IP became common in the 1980s, it wasn’t until the rise of the Internet in the early 90s that TCP/IP began to become the standard for data communications. This brought about a fall in the prices for IP networking hardware, and made it much easier to interconnect networks as well.

TCP/IP allows communicating nodes to establish a connection and then verify when the data communications start and stop. On a TCP/IP network, data to be transmitted is chopped up into sections, called packets, and encapsulated in a series of “envelopes,” each one containing specific information for the next network layer. Each packet is stamped with a 32-bit sequence number so that even if they arrive in the wrong order, the transmission can be reassembled. As the packet crosses different parts of the network each layer is opened and interpreted, and then the remaining data is passed along according to those instructions. When the packet of data arrives at its destination, the actual data, or payload, is delivered to the application.

It sounds confusing, but here is an analogy. Think of a letter you mail to a corporation in an overnight envelope. The overnight company uses the outside envelope to route the package to the right building. When it is received, it will be opened up and the outside envelope thrown away. It might be destined for another internal mailbox, so they might put in an interoffice mail envelope and send it on. Finally it arrives at its intended recipient, who takes all the wrappers off and uses the data inside. Table 3.1 shows how some network protocols encapsulate data.

As you can see, the outside of our data “envelope” has the Ethernet address. This identifies the packet on the Ethernet network. Inside that layer is the network information, namely the IP address; and inside that is the transport layer, which sets up a connection and closes it down. Then there is the application layer, which is an HTTP header, telling the Web browser how to format a page. Finally comes the actual payload of packet—the content of a Web page. This illustrates the multi-layered nature of network communications.

There are several phases during a communication between two network nodes using TCP/IP (see Figure 3.2). Without going into detail about Domain Name Servers (DNS) and assuming we are using IP addresses and not host names, the first thing that happens is that the machine generates an ARP (Address Resolution Protocol) request to find the corresponding Ethernet address to the IP it is trying to communicate with. ARP converts an IP address into a MAC address on an Ethernet network.

Table 3.1 Sample TCP/IP Data Packet



EthernetMAC address Datalink
IPIP address Network
TCPTCP header Transport
HTTPHTTP header Application
Application DataWeb page Data



Now that we can communicate to the machine using IP, there is a three-way communication between the machines using the TCP protocol to establish a session. A machine wishing to send data to another machine sends a SYN packet to synchronize, or initiate, the transmission. The SYN packet is basically saying, “Are you ready to send data?” If the other machine is ready to accept a connection from the first one, it sends a SYN/ACK, which means, “Acknowledged, I got your SYN packet and I’m ready.” Finally, the originating machine sends an ACK packet back, saying in effect, “Great, I’ll start sending data.” This communication is called the TCP three-way handshake. If any one of the three doesn’t occur, then the connection is never made. While the machine is sending its data, it tags the data packets with a sequence number and acknowledges any previous sequence numbers used by the host on the other end. When the data is all sent, one side sends a FIN packet to the opposite side of the link. The other side responds with a FIN/ACK, and then the other side sends a FIN, which is responded to with a final FIN/ACK to close out that TCP/IP session.

Because of the way TCP/IP controls the initiation and ending of a session, TCP/IP communications can be said to have state, which means that you can tell what part of the dialogue is happening by looking at the packets. This is a very important for firewalls, because the most common way for a firewall to block outside traffic is to disallow SYN packets from the outside to machines inside the network. This way, internal machines can communicate outside the network and initiate connections to the outside, but outside machines can never initiate a session. There are lots of other subtleties in how firewalls operate, but basically that’s how simple firewalls allow for one-way only connections for Web browsing and the like.

There are several built-in firewall applications in Linux: these are known as Iptables in kernel versions 2.4x, Ipchains in kernel versions 2.2x, and Ipfwadm in kernel version 2.0. Most Linux-based firewalls do their magic by manipulating one of these kernel-level utilities.

All three applications operate on a similar concept. Firewalls generally have two or more interfaces, and under Linux this is accomplished by having two or more network cards in the box. One interface typically connects to the internal LAN; this interface is called the trusted or private interface. Another interface is for the public (WAN) side of your firewall. On most smaller networks, the WAN interface is connected to the Internet. There also might be a third interface, called a DMZ (taken from the military term for Demilitarized Zone), which is usually for servers that need to be more exposed to the Internet so that outside users can connect to them. Each packet that tries to pass through the machine is passed through a series of filters. If it matches the filter, then some action is taken on it. This action might be to throw it out, pass it along, or masquerade (“Masq”) it with an internal private IP address. The best practice for firewall configuration is always to deny all and then selectively allow traffic that you need (see the sidebar on firewall configuration philosophy).

Firewalls can filter packets at several different levels. They can look at IP addresses and block traffic coming from certain IP addresses or networks, check the TCP header and determine its state, and at higher levels they can look at the application or TCP/UDP port number. Firewalls can be configured to drop whole categories of traffic, such as ICMP. ICMP-type packets like ping are usually rejected by firewalls because these packets are often used in network discovery and denial of service. There is no reason that someone outside your company should be pinging your network. Firewalls will sometimes allow echo replies (ping responses), though, so you can ping from inside the LAN to the outside.

{mospagebreak title=Security Business Processes}

At some point, preferably before you start loading software, you should document in writing a business process for your firewall(s). Not only will this be a useful tool for planning your installation and configuration, but it may also help if you have to justify hardware purchases or personnel time to your boss. Documenting your security activities will make you look more professional and emphasize the value you add to the organization, which is never a bad thing. It also makes it easier for anyone who comes after you to pick up the ball.

This plan documents the underlying processes and procedures to make sure that you get a business benefit from the technology. Installing a firewall is all well and good, but without the proper processes in place, it might not actually give the organization the security it promises. The following steps outline a business process for firewall implementation and operation.

1. Develop a network use policy. There may already be some guidelines in your employee manual on proper computer use. However, many computer use polices are intentionally vague and don’t specify which applications count as misuse. You may have to clarify this with your manager or upper management. Are things like instant messengers allowed? Do you want to follow a stringent Web and e-mail only outbound policy? Remember that it is safer to write a rule for any exceptions rather than allowing all types of activity by default. Getting the answers to these questions (hopefully in writing) is crucial before you start writing rules.

2. Map out services needed outward and inward. If you don’t already have a network map, create one now. What servers need to be contacted from the outside and on which ports? Are there users who need special ports opened up for them? (Hint: technical support staff often need FTP, Telnet, and SSH.) Do you want to set up a DMZ for public servers or forward ports to the LAN from the outside? If you have multiple network segments or lots of public servers, this could take longer than the firewall setup itself. Now is the time to find out about these special requests, not when you turn on the firewall and it takes down an important application.

3. Convert the network use policy and needed services into firewall rules. This is when you finally get to write the firewall rules. Refer to your list of allowed services out, required services in, and any exceptions, and create your firewall configuration. Be sure to use the “deny all” technique described in the sidebar to drop anything that doesn’t fit one of your rules.

4. Implement and test for functionality and security. Now you can turn on your firewall and sit back and wait for the complaints. Even if your rules conform exactly to policy, there will still be people who didn’t realize that using Kazaa to download movies was against company policy. Be ready to stand your ground when users ask for exceptions that aren’t justified. Every hole you open up on your firewall is a potential security risk.

Also, once your firewall is operating to your users’ satisfaction, make sure that it is blocking what it is supposed to be blocking. By using two tools discussed later in this book together, you can run tests against your firewall: A port scanner on the outside and a network sniffer on the inside will tell you which packets are getting through and which ones aren’t. This setup can also be useful for troubleshooting applications that are having problems with the firewall.

5. Review and test your firewall rules on a periodic basis.
Just because your firewall is working great today doesn’t mean it will be tomorrow. New threats may evolve that require new rules to be written. Rules that were supposed to be temporary, just for a project, may end up being left in your configuration. You should review your rules periodically and compare them with the current business requirements and security needs. Depending on the size and complexity of your configuration and how often it changes, this may be as infrequently as once a year for firewalls with a small rule set (20 or fewer rules), or once a month for very complex firewalls. Each review should include an actual test using the scanner/sniffer setup mentioned above using the tools in Chapters 4, 5, and 6 to verify that the rules are indeed doing what they are supposed to be.

Designing and using a business process such as this will help ensure you get a lot more out of your firewall implementation, both professionally and technically. You should also develop plans for the other technologies discussed in this book, such as vulnerability scanning and network sniffing.

 Howlett Flamey the Tech Tip:
“Deny all!” When It Comes to Firewall Rules

There are two ways set up a firewall: You can start with an “allow all” stance and then add the behavior you want blocked, or start with a “deny all” statement and then add what you want to allow (permissible user behavior). The overwhelmingly preferred method is starting with “deny all.” By beginning with this statement, you automatically block all traffic unless it is specifically allowed in the configuration. This method is both more secure and easier to maintain securely than the other route.

Most commercial firewalls use this philosophy. The idea behind it is that if you have to define what is bad behavior, you will be continually behind as the Internet changes and evolves. You cannot predict what form the next new attack might take, so you will be vulnerable until it is published and you can add a new line to your firewall configuration. By using the “deny all” approach, you categorically deny anything that isn’t known good activity.

The “allow all” type of configuration might make sense in a extremely permissive environment where the overhead of adding lines for allowed items overrides the value of the information on the network, for example, on a nonprofit or purely informational site. But for most sites the “deny all” approach is much safer. However, just because you use this approach doesn’t mean your network is totally secure. Attacks can still come in via any holes you’ve created, such as for the Web and e-mail. Also, keep in mind that even when the “deny all” statement is used, you have to be careful not to negate it with an overly permissive statement higher up in your configuration.

Iptables: A Linux Open Source Firewall   

Author/primary contact: Paul “Rusty” Russell
Web site:          
Platforms:                   Most Linux
License:                      GPL
Version reviewed:         1.2.8
Netfilter mailing lists:
Netfilter-announce       General announcement list for news of new releases and updates. Subscribe at:

Netfilter-users            General questions about using Netfilter/Iptables. Post general discussion topics and questions here. Subscribe at:

Netfilter-devel            Development and contributor discussions. Subscribe at:

This section describes how to configure a firewall with Iptables, which is the firewall/ packet filter utility built into most Linux systems with kernel version 2.4 and later. This utility lets you create a firewall using commands in your operating system. Iptables evolved from earlier attempts at firewalls on Linux. The first system, called Ipfwadm, could be used to create a simple set of rules to forward or deny packets based on certain criteria. Ipchains was introduced in kernel 2.2 to overcome the limitations of Ipfwadm. Ipchains worked pretty well and was modular in architecture. However, with the growing number of people using their firewalls for multiple functions (for example, proxy server and NAT device), Ipchains also became insufficient. Iptables represents an update to these programs and allows for the multiple uses that today’s firewalls are expected to perform. (Note that the concepts and terms for Iptables are pretty much the same for Ipchains.)

Iptables is a powerful but complex tool, and is usually recommended for users who are familiar with firewalls and the art of configuring them (see the sidebar on writing shell scripts). If this is your first firewall, I suggest using one of the autoconfiguration tools discussed later in the chapter to create your firewall configuration, at least at first. These tools use Iptables (or its predecessor, Ipchains) to create a firewall by using your input. However, it is good to have a basic understanding of what is going on “under the hood” with Iptables before start configuring with one of the graphical tools.

{mospagebreak title=Installing Iptables}

Most Linux systems on kernel 2.4 or higher will have Iptables built right in, so you don’t have to install any additional programs. (If your system is earlier than kernel 2.4, it will use Ipchains or Ipfwadm. These are similar systems, but they are not reviewed in this book.) You can issue Iptables statements from the command line or via a script (see the sidebar). To double-check that Iptables is installed, type iptables – L and see if you get a response. It should list your current rule set (which is probably empty if you haven’t configured a firewall yet).

If your system doesn’t have Iptables or if you want to get the latest version of the code, go to and download the RPM for your operating system. You can also get it from the CD-ROM that comes with this book.

If you don’t have a Webmin RPM on your installation disks, check www. to see if there is a version of Webmin available for your operating system. Webmin is required for the Turtle Firewall, and there are specific versions for each distribution and operating system. If there isn’t one for your particular operating system, then you can’t use Turtle Firewall, but the list of supported systems is quite large. Click on the RPM file in X-Windows and it will install automatically.

Using Iptables

The idea behind Iptables and Ipchains is to create pipes of input and process them according to a rule set (your firewall configuration) and then send them into pipes of output. In Iptables, these pipes are called tables; in Ipchains, they are called chains (of course!). The basic tables used in Iptables are:

  • Input
  • Forward
  • Prerouting
  • Postrouting
  • Output

The general format of an Iptables statement is

iptables command rule-specification extensions

where command, rule-specification, and extensions are one or more of the valid options. Table 3.2 lists the Iptables commands, and Table 3.3 contains the Iptables rule specifications.

Table 3.2 Iptables Commands

Commands Descriptions
-A chainAppends one or more rules to the end of the statement.
-I chain rulenumInserts chain at the location rulenum. This is useful when you want a rule to supercede those before it.
-D chainDeletes the indicated chain.
-R chain rulenumReplaces the rule at rulenum with the provided chain.
-LLists all the rules in the current chain.
-FFlushes all the rules in the current chain, basically deleting your firewall configuration. This is good when beginning a configuration to make sure there are no existing rules that will conflict with your new ones.
-Z chainZeros out all packet and byte counts in the named chain.
-N chainCreates a new chain with the name of chain.
-X chainDeletes the specified chain. If no chain is specified, this deletes all chains.
-P chain policySets the policy for the specified chain to policy.


Table 3.3 Iptables Rule Specifications

Rule SpecificationsDescriptions
-p protocolSpecifies a certain protocol for the rule to match. Valid protocol types are icmp, tcp, udp, or all.
-s address/mask!portSpecifies a certain address or network to match. Use standard slash notation to designate a range of IP addresses. A port number or range of port numbers can also be specified by putting them after an exclamation point.
-j targetThis tells what to do with the packet if it matches the specifications. The valid options for target are:
DROP   Drops the packet without any further action.
REJECT  Drops the packet and sends an error packet in return.
LOG      Logs the packet to a file.
MARK    Marks the packet for further action.
TOS    Changes the TOS (Type of Service) bit.
MIRROR   Inverts the source and destination addresses and sends them back out, essentially “bouncing” them back to the source.
SNAT       Static NAT. This option is used when doing Network Address Translation (NAT). It takes the source address and converts it into another static value, specified with the switch –to-source.
DNAT        Dynamic NAT. Similar to above but using a dynamic range of IP addresses.
MASQ        Masquerades the IP using a public IP.
REDIRECT   Redirects the packet.

There are other commands and options but these are the most common operations. For a full listing of commands, refer to the Iptables man page by typing man iptables at any command prompt.
Creating an Iptables Firewall

The best way to learn is to do, so let’s walk through a couple of commands to see how they are used in practical application. Here is an example of how to create a firewall using Iptables. You can enter these commands interactively (one at a time) to see the results right away. You can also put them all into a script and run it at boot time to bring your firewall up at boot time (see the sidebar on writing scripts). Remember to type them exactly as shown and that capitalization is important.

{mospagebreak title=Writing Shell Scripts}

Often you will need to automate a process or have a single command initiate a number of statements. In the firewall example, you will generally want to have all your firewall commands executed when your system boots. The best way to do this is to write a shell script. A shell script is a simple text file that contains a command or list of commands. The shell editor executes the commands when it is invoked by a user typing the name of the script.

1. To create a shell script, first open a text editor such as vi or EMACS and type in your command(s).

2. Make sure you put a line at the very top that looks like this:

#! /bin/bash
This tells the script which shell to use to execute the command. You must have that shell on your OS, and the commands you put in your script will have to be valid commands for that shell. This example is for the bash shell location on Mandrake Linux. You can use a different shell, for example, Tcsh or Csh. Just put the path to it on this line. Then save your file.

3. Make the file executable so the shell can run it as a program. You do this with the chmod command. Type:

chmod 700 script_name

where you replace script_name with your file name. This makes the permissions on the file readable, writable, and executable.

To run the script, type the file’s name in the command line. (In the bash shell, you need to add a ./ before the file name to run the script from your local directory.) When you press Enter, the commands in your script should run.

You have to be in the same directory as the file or type the path in the command line statement when you run it. Alternatively, you could add the directory for the script to your PATH statement so it will run from anywhere or put the script in one of your PATH directories.

The example in the following procedure assumes that your local LAN subnet is –, that the eth1 interface is your local LAN connection, and that the eth0 interface is your Internet or WAN connection.

1. Start by eliminating any existing rules with a Flush command:

 iptables -F FORWARD

This flushes all rules for the FORWARD chain, which is the main “funnel” for any packets wanting to pass through the firewall.

2. Flush the other chains:

iptables -F INPUT
iptables -F OUTPUT

This flushes any rules to your local machine and your output chain.

3. Put your standard “deny all” statement right up front.

 iptables -P FORWARD DROP
 iptables -A INPUT -i eth0 -j DROP

4. To accept fragmented packets in Iptables, this must be done explicitly.

iptables -A FORWARD -f -j ACCEPT

5. There are two types of common attacks that you should block right away. One is what is known as spoofing, which is when someone forges the IP packet headers to make it look like an outside packet has in internal address. By doing this, someone could route onto your LAN even if you have private IP addresses. The other type of attack is done by sending a stream of packets to the broadcast address of the LAN to overwhelm the network. This is called a smurf attack (although I’m not sure what this has to do with little blue cartoon characters). You can block these types of attacks with two simple statements.

iptables -A FORWARD -s -I eth0 -j DROP
iptables -A FORWARD -p icmp –i eth0 –d –j DENY

The first statement drops any packets coming from the Internet interface eth0 with the internal address By definition, no packets should be coming from the untrusted interface with an internal, private source address. The second statement drops any packets of protocol ICMP coming from the outside address to the inside.

6. You generally do want to accept incoming traffic based on connections initiated from the inside, for example, someone surfing a Web page. As long as the connection is ongoing and it was initiated internally, then it is probably okay. You can, however, limit the type of traffic allowed in. Let’s say that you only want to allow employees Web and e-mail access. You can specify the types of traffic to allow through and only if it is on an already-initiated connection. You can tell if it is an existing connection by seeing that the ACK bit has been set, that is, that the TCP three-way handshake has occurred. The following statements allow HTTP and Web traffic based on this criteria.

iptables –A FORWARD –p tcp –i eth0 –d –
www,smtp –tcp-flags SYN,ACK –j ACCEPT
iptables –A FORWARD –p tcp –i eth0 –d -sports
www,smtp –tcp-flags SYN,ACK –j ACCEPT

The -dport statement says to only allow e-mail and Web, and the –tcp flags statement says you only want packets with the ACK field set.

7. To be able to accept incoming connections from the outside only on certain ports, such as e-mail coming into your mail server, use a statement like this:

iptables –A FORWARD –m multiport –p tcp –i eth0 –d
–dports smtp –syn –j ACCEPT

The -m multiport flag tells Iptables that you will be issuing a match statement for ports. The -syn statement tells it to allow SYN packets, which means to initiate TCP connections. And the -dports flag allows only the SMTP mail traffic.

8. You can allow outgoing connections to be initiated by your users, but only on the protocols you want them using. This is where you can prevent your users from using FTP and other nonessential programs. The all-zero IP address is shorthand for saying “any address.”

iptables –A FORWARD –m multiport –p tcp –i eth0 –d –dports www,smtp –syn –j ACCEPT

9. You need to allow certain incoming UDP packets. UDP is used for DNS, and if you block that your users won’t be able to resolve addresses. Because they don’t have a state like TCP packets, you can’t rely on checking the SYN or ACK flags. You want to allow UDP only on port 53, so you specify domain (a built-in variable for port 52) as the only allowable port. You do that with these statements.

iptables –A FORWARD –m multiport –p udp –i eth0 –d –dports domain –j ACCEPT

iptables –A FORWARD –m multiport –p udp –i eth0 –s –sports domain –j ACCEPT

iptables –A FORWARD –m multiport –p udp –i eth1 –d –dports domain –j ACCEPT

iptables –A FORWARD –m multiport –p udp –i eth1 –s –sports domain –j ACCEPT

10. The first two statements allow the incoming UDP datagrams, and the second two allow the outbound connections. You also want to do this for ICMP packets. These are the network information packets discussed in Chapter 2. You want to allow all types of internal ICMP outwards, but only certain types such as echo-reply inwards. This can be accomplished with the following statements.

iptables –A FORWARD –m multiport –p icmp –I eth0 –d –dports 0,3,11 –j ACCEPT

iptables –A FORWARD –m multiport –p icmp –I eth1 –d
–dports 8,3,11 –j ACCEPT

11. Finally, you want to set up logging so you can look at the logs to see what is being dropped. You will want to view the logs from time to time even if there isn’t a problem, just to get an idea of the kinds of traffic being dropped. If you see dropped packets from the same network or address repeatedly, you might be being attacked. There is one statement to log each kind of traffic.

iptables –A FORWARD –m tcp –p tcp –j LOG
iptables –A FORWARD –m udp –p udp –j LOG
iptables –A FORWARD –m udp –p icmp –j LOG


That’s it! This will provide you with firewall protection from the most common attacks from the Internet.

{mospagebreak title=IP Masquerading with Iptables}

When the Internet was originally designed, several large blocks of addresses were set aside for use on private networks. These addresses will not be routed by the Internet and can be used without worrying that they will conflict with other networks. The private address ranges are: – – –

By using these addresses on your internal LAN and having one external, routable IP on your firewall, you effectively shield your internal machines from outside access. You can provide this additional layer of protection easily with Iptables using IP masquerading. The internal IP header is stripped off at the firewall and replaced with a header showing the firewall as the source IP. The data packet is then sent out to its destination with a source IP address of the public interface of the firewall. When it comes back, the firewall remembers which internal IP it goes to and re-addresses it for internal delivery. This process is also known as Network Address Translation (NAT). You can do this in Iptables with the following statements.

iptables –t nat –P POSTROUTING DROP
iptables –t nat –A POSTROUTING –o eth0 –j MASQUERADE

The MASQUERADE flag can be abbreviated to MASQ. One of the improvements of Iptables over previous systems like Ipchains and Ipfwadm is the way that it handles secondary tasks like NAT.

So now you know how to build a basic firewall. This is just a simple configuration; the possible variations are endless. You can forward certain ports to internal servers so they don’t have to have a public IP address. You can put another network card in your firewall box and make it a DMZ interface for servers with public addresses. There are entire books on advanced firewall configuration and many mailing lists. One of the better lists is firewall-wizards. To subscribe to this list, send an e-mail with “subscribe” in the body to:

The firewall-wizards list hosts discussions about all levels of firewall configuration and is vendor agnostic, that is, all firewall brands are discussed, from open source to commercial.

If you want to build a quick firewall without entering all those Iptables statements and remembering the syntax, there is tool that builds the firewall statements using a graphical interface—so it’s all done for you in the background.

Turtle Firewall: An lptables-based Firewall with a Graphical User Interface

Turtle Firewall

Author/primary contact:     Andrea Frigido
Web site:              

Platforms:  Most Linux-compatibles that support Iptables
License:     GPL 2.0
Contact information:
System requirements: Linux operating system with kernel 2.4 or newer
Perl with expat library
Webmin server

This neat little contraption, called Turtle Firewall, was created by Andrea Frigido. Turtle is basically a set of Perl scripts that do all the dirty work for you to set up an Iptables firewall. This program makes it much easier to see your rules and to make sure you are getting the statements in the right order. It runs as a service, so you don’t have to worry about initializing your firewall with a shell script. It uses the Linux Webmin service, which is a little Web server that allows you to make configuration changes to your server via a Web browser. While this might introduce some insecurity into your system by running a Web server on the firewall, it may be worth it for the ease of configuration it brings. Many commercial vendors now use a Web browser interface for configuration. A big benefit of this application is that you can reach the configuration screen from any Windows or UNIX machine.

For support, Andrea offers a commercial support option. For a mere 100 euros (don’t ask me to convert that to dollars exactly, but when this book was printed it was about $100.00), you can get 30 days of e-mail support so you can get help setting it up. It also might be worth subscribing if you have a problem with an existing installation that you can’t solve on your own.

{mospagebreak title=Installing Turtle Firewall}

Installing and setting up Turtle Firewall is very easy because it uses the Webmin administration module, which is available on most Linux platforms.

1. If you did not install the Webmin administration module during your OS installation, you will need to in order to use Turtle Firewall. Locate and run the RPM, which should be on most Linux distributions disks. Click on the RPM file and it will install automatically.

2. Once that is done, you should be able to log into your firewall’s configuration screen by putting its IP address in your browser window and pressing Enter.

3. Now you are ready to install Turtle Firewall. Download the packed distribution from or get it from the CD-ROM that comes with this book and unzip it.

4. Change to the turtlefirewall directory and type:


This runs an installation script that puts the Perl modules and other things that are needed in the right places.

5. Log into the Webmin server using a Web browser pointed at the IP address or host name the server is using. The Webmin interface will display.

6. Click the Module Index tab, and the Turtle Firewall Main screen displays (see Figure 3.3).


7. Click on the Firewall Items icon to begin configuring your firewall.

First you will need to define some basic things about your firewall (see Figure 3.4). Turtle Firewall uses the concept of zones to define trusted and untrusted networks. A trusted zone connects to a network with employees or people who should generally be trusted on it, such as your internal network. An untrusted zone is a network that could have anything on it, from employees to customers, vendors, or even people with malevolent intentions. Turtle calls them “good” and “bad,” but it is basically the same thing as trusted and untrusted.


Turtle also has an entry for a DMZ or “Demilitarized Zone” segment. A DMZ segment is used to put servers that need unfettered access to the untrusted zone. Put the interfaces for your good, bad, and DMZ (if any) interfaces here.

8. Next you need to define your internal network IP addresses in the Net box. Put the IP address range with subnet mask for your internal LAN to be protected by the firewall in the box provided (see Figure 3.4).

9. Next, define any internal or DMZ hosts that will need special consideration, such as your mail server or Web server. Do this in the Hosts box (see Figure 3.4).

10. Finally, you can define any special hosts that you want to treat differently, such as administrators, in the Group area. Now your firewall is up and running in basic mode.
There are probably some additional restrictions or permissions you will want to add, for example, the ability for someone from the outside to use SSH to get in. You can do this by writing a rule on the Firewall Rules tab. Click on that tab, and it will graphically walk you through writing a new firewall rule. You will notice the format is similar to Iptables (see Figure 3.5).


If you want to implement the Iptables Masquerade function using private IP addresses for your internal LAN, click on the NAT and Masquerading icon on the main screen. Here you can define what zone will be masqueraded (see Figure 3.6). Generally, it will be your “good” or trusted interface. You can also set up hosts to be “NAT’ed” here. Putting a host to be your virtual IP makes it act as the front for your real host, and the firewall will forward all packets through the virtual host to the real host. This provides an extra level of protection for your internal servers.

SmoothWall Express: A Complete Multi-Function Firewall

SmoothWall Express

Authors/primary contacts:     Lawrence Manning, Richard Morrell, Jon Fautley, and Tom Ellis (original authors)
SmoothWall Limited (current contact)

Web site:

Platform:    Linux
License:     GPL

Version reviewed: 2.0
Web forums:
IRC chat channels:
Use IRC server 6667.
Join the channel #help for SmoothWall questions and general chat.
Mailing lists:
For general/installation support, subscribe at:

The two programs discussed previously, Iptables and Turtle Firewall, offer an inexpensive way to set up a simple firewall. But if you need a DHCP server, you have to set that up separately. And if you want to be able to SSH into the machine, that is another program to install. SmoothWall is an open source firewall that offers a robust firewall package with all those features and more built in. It is designed by a company that offers both a free GPL version and a commercial version with some additional features and enhanced support. This is another example of how a product can take advantage of the power of open source and also reap commercial gains for a company. The free version is called SmoothWall Express and is currently on version 2.0; the commercial version is called SmoothWall Corporate Server version 3.0.


SmoothWall Express contains several options beyond Iptables that most companies would want in a fully functional firewall. Granted, you can cob most of these together with other programs and Iptables, but SmoothWall offers it all in one program in an easy to install package. Some of these features are:

 – VPN support: SmoothWall integrates an IPsec VPN with firewall capabilities. This allows people on the outside to securely access the local area network via an encrypted tunnel. This can be a fixed remote office or a roaming salesperson (nonstatic IP VPN is only supported in the corporate edition).

– DHCP client and server: The client allows the firewall to get a dynamic IP address for its WAN interface. This is common practice on DSL and cable modem ISP service. It also allows the firewall to act as a DHCP server for the internal LAN, handing out IP addresses according to a preset policy. Again, you can add these things to an Iptables firewall, but then you have two separate programs to install and manage.

– SSH and Web access to firewall: Secure access via command line and a Web browser. The Turtle Firewall gives this capability for Iptables but doesn’t allow SSH access. SmoothWall has both built in with no additional software to install.

– Web proxy server: The ability to set up a Web proxy so that all Web sites are accessed through a firewall. This provides some level of Web security, since any exploits would have to run on the firewall and not the local machine. It can also allow for further protection through a content filtering option available from SmoothWall Limited.

– Web caching server: This feature stores the most popular Web pages for local access so that access times are improved and bandwidth usage is lowered.

– Intrusion detection: SmoothWall offers some basic network intrusion detection capabilities.

– Graphs and reports: SmoothWall allows you to run some simple reports on firewall activity and generate graphs based on this data.

– Support for additional connection types: SmoothWall supports many types of interfaces including dial-up, cable, ADSL, ISDN, and Ethernet. Some of these interfaces require additional software and configuration when supported under Ipchains.

One major difference between SmoothWall and the programs mentioned earlier is that SmoothWall needs to run on a dedicated machine. When you install SmoothWall, it wipes everything off the hard disk and installs its own operating system. This is basically a stripped down and hardened version of Linux, but you don’t have to know anything about it to run your SmoothWall firewall. This means you won’t be able to run any other tools on that machine or use it for anything else (at least not without a lot of hassle and the potential of breaking the SmoothWall software), so it may not be the right fit for everyone. But if you are looking for a cheap and quick way to set up a turnkey firewall with a lot of features, SmoothWall may be right for you.

{mospagebreak title=SmoothWall Hardware Requirements}

As mentioned earlier, SmoothWall needs a dedicated machine to run on. The good news is that the requirements for this machine are quite low since it will be running only the firewall software. The minimum specifications required for SmoothWall are a Pentium-class Intel-compatible PC running at 200Mhz or higher with at least 32MB of RAM and 512MB of disk space. A more optimal configuration would be a 500Mhz processor with 64MB of RAM and 2GB of disk space. These specifications should be easy to meet on all but the oldest machines. You will also need a CD-ROM drive and at least one network card (typically two, if the WAN interface is Ethernet).
SmoothWall Express Versus SmoothWall Corporate

If you have a little money to spend and are considering other commercial alternatives, you might look at the SmoothWall Corporate edition. This firewall has all the benefits of the Express version with the following important differences:

  • Enhanced IDS support
  • Connection fail-over capabilities
  • VPN roaming support (dynamic IPs)
  • Additional graphs and reports
  • Enhanced graphical user interface
  • Certificate authentication support for VPN

You can see a complete list of the differences at
CorporateServer_vs_ Express_Comparison_20040113.pdf.

Pricing for the commercial version is quite reasonable (check the Web site for the latest prices). The cost is significantly less than what you’d pay to buy a server to run it on. SmoothWall also makes other software products for network monitoring and content filtering. Check out their full product line at

Installing SmoothWall

Caution: Remember, installing SmoothWall will erase any data on the hard disk and put its own operating system on it. Do not run this installation on a computer on which you have data or programs you need.

1. You must first create a bootable CD-ROM disk. To do this, use CD-writing software, such as Nero or Easy CD Creator, and create a disk from the .iso image file from the SmoothWall directory on the CD-ROM that accompanies this book. The disk it creates will be bootable.

2. Set your PC to boot from the CD-ROM first. Otherwise, it will search the hard drive and load the operating system it finds there. You usually do this in the BIOS settings of a PC accessed at boot-up before the OS loads. Many PCs use the F2 function key to enter this mode.

3. Boot the machine from the CD-ROM. A title screen displays some basic licensing and disclaimer information. Click on OK.

You have the choice of loading from the CD-ROM or HTTP. Remember, do not enter this mode unless you are ready for all the data on that hard disk to be erased and replaced with the SmoothWall software.

Choose CD-ROM, and the installation will begin.

You will see it formatting the disk and then probing your machine for its network interfaces. It should auto-detect any network interface cards (NICs). It lets you accept or skip each one and set them up as firewall interfaces. For example, if you have two NICs on your computer but only want to use one as a firewall interface on the firewall, you would define that here.

4. Define the attributes of each selected interface. Assign them an IP address and subnet mask. After this, SmoothWall installs some additional driver files and asks you to eject the CD-ROM. You have finished installing the program and will automatically enter setup mode.

5. In setup mode, you will be asked for a hostname for the SmoothWall. You can use the hostname to access the machine instead of using its LAN IP address.

6. Next it asks if you want to install the configuration from a backup. This nifty feature allows you to easily restore your firewall to its original configuration if the system crashes (assuming you made a backup, which is covered later in this section). Don’t select this unless you are in the process of restoring from a backup.

7. Assuming you chose to set up a new firewall (not from backup) in the previous step, you will be prompted to set up several network types:

  • ISDN: Leave this set to Disable if you aren’t using ISDN. If you are, then add the parameters appropriate for your IDSN line.

  • ADSL: This section is necessary only if you are using ADSL and actually have the ADSL modem in your computer. Leave this on Disable if you aren’t using ADSL service or if the provider gives you an external modem to plug into. Otherwise, click on the settings for your ADSL service.

  • Network configuration: SmoothWall divides its zones into three categories:

– Green: Your internal network segment to be protected or your “trusted” network.

– Red: The external network to be firewalled off from the LAN. The “untrusted” network, usually the Internet or everything that is not your LAN.

– Orange: This is an optional segment that can contain machines that you generally trust but need to be exposed to the Internet (the DMZ mentioned earlier). This protects your internal LAN, should one of the servers be compromised, since DMZ nodes don’t have access to the LAN by default, and also allows these machines to be accessed by the outside world.

Select the configuration that is appropriate for your network. Most simple networks will use Green (Red is for modems or ISDN), or Green and Red if you have two NIC cards in the machine.

8. Now it is time to set up the DHCP server. If you want your firewall to be responsible for handing out and managing dynamic IP addresses on your LAN, enable this feature. Otherwise leave it turned off. You can set the range to be assigned, and the DNS and lease times for the addresses given out.
9. You now set several passwords for different levels and methods of access. The “root” password is accessible from the console and command line interface and acts just like UNIX root in that you have total control over the box. You then assign a password for the “setup” user account. This user can also access the system from the console and command line. This user has more limited powers than “root” and can only run the setup utility program.

10. Finally, set up a Web interface user account. This isn’t a UNIX-type account and can’t be accessed from the command line. It is strictly used to control access to features from the Web interface.

11. Now reboot the machine and your SmoothWall firewall should be up and running. You can log into the machine from the console using either the root or setup user. You can also SSH into the box from a remote location and get the command line interface.

However, one of the truly nice things about this program is that there is a powerful and easy-to-use GUI accessible from any Web browser that makes administering the firewall a snap.

Administering the SmoothWall Firewall

The easiest way to manage the SmoothWall firewall is using the Web interface. This gives you a powerful tool for administering and adding other functionality to your firewall. You can access this interface two ways: via port 81 for normal Web communications or via port 441 for secured Web communications using SSL. Either way, you put the IP address or URL with the port number in the location window of a Web browser. For example, if your firewall LAN interface card has IP address, you would enter the following into the Web browser
for normal Web communications, or

for secure Web access.

This will display the SmoothWall opening screen. To access any of the other screens you will need to enter your user name and password. The default user name is admin and the password is the one you entered for the Web interface during the setup process. There are several main menus accessible from the main page (see Figure 3.7)


Figure 3.7. SmoothWall Main Menu

Each menu has a number of submenus underneath it.

  • Control: This is the firewall homepage and contains copyright and uptime information.

    About Your Smoothie: This has a number of useful submenus:
  • Status: This shows you the status of the various services on the SmoothWall.
  • Advanced: This screen contains detailed information about your system.

  • Graphs: This is one of the cooler features in SmoothWall. This enables you to create bandwidth graphs so you can analyze your network traffic on different interfaces at different times of the day and on different days. You can use this as a quick way to find network problems. If you notice huge bandwidth increases on the weekend or late at night without any known reason, you know that something is amiss (see Figure 3.8).


Figure 3.8. SmoothWall Traffic Graph

  • Services: This is where you configure various basic and optional services on the SmoothWall (see Figure 3.9).

  • Web Proxy: If you want to be able to set up your SmoothWall to act as a proxy for anyone surfing the Web, this function can be set up here.
  • DHCP: The built-in DHCP server is configured here.
  • Dynamic DNS: If your ISP assigns you a dynamic IP address but you still want to allow services in from the outside, you can set up the SmoothWall to update a DNS record automatically with its new IP address. It can be configured to use any one of several online services such as and
  • Remote Access: This section controls access to your SmoothWall from anywhere but the console. You can enable SSH (it is disabled by default) and control what specific addresses can get access.
  • Time: This configures the time settings on the machine. This can be very important if you are comparing its log files to other servers. You can set it up to get time from a public time server, which makes logs more accurate.


Figure 3.9 SmoothWall Services Screen

  • Networking: This is where you configure anything associated with the firewall and network functions of the SmoothWall. This includes adding, deleting, or modifying the rule sets and other functions:
  • Port Forwarding: You can forward a specific port or series of ports to an internal protected host.
  • Internal Service Access: Click here if you need access to an internal service from the outside.
  • DMZ Pinhole: This lets you set up access from a host on your DMZ to a host on your LAN. This is normally not allowed as part of the function of a DMZ.
  • PPP Settings: If you are using the SmoothWall to connect to the Internet via dialup, you set the various phone settings here such as number, modem commands, and so on.
  • IP Block: This is a nice feature that allows you to easily block an IP or range of IP addresses from your network without having to write any rules.
  • Advanced: Several miscellaneous network settings such as Universal Plug and Play (UpnP) support are found here.
  • VPN: Here is where you configure the SmoothWall to act as a VPN for secure remote access from another network. The details are covered later in this chapter.
  • Logs: Access to all the log files kept by the SmoothWall is facilitated through this screen. The interface allows you to easily scan different types of log files such as system and security.
  • Tools: There are several standard network tools here including ping, traceroute, and whois. They also include a nifty Java-based SSH client so you can access SSH servers from your Web browser.
  • Maintenance: This section is used for system maintenance activity and has several submenus.
  • Maintenance: This section keeps track of any patches to your SmoothWall operating system. It is important to keep the SmoothWall OS patched. Just like any operating system, there are security holes discovered from time to time that are fixed in the patches. New features or compatibility are added periodically as well.
  • Password: You can change any of the logins and passwords for the system here (assuming you have the old passwords).
  • Backup: You can make a backup of your SmoothWall configuration so that in the event of a crash you can easily restore it. You should make a backup as soon as you get the SmoothWall configured to your liking to save your settings.
  • Shutdown: This will safely shut down SmoothWall.

{mospagebreak title=Creating a VPN on the SmoothWall Firewall}

You can use SmoothWall to set up a secure connection to another network by creating a VPN tunnel with IPsec encryption.

1. To configure the VPN function on the firewall, click on the VPN item from the main menu. There are two submenus located there (see Figure 3.10).

Control: This is the main screen where you can start and stop your configured VPN sessions as well as get status information on them.

Connections: Here is where you configure new VPN connections. It gives you a pretty simple way to create new VPN connections. On SmoothWall Express (the free GPL version), both ends must have a static, public IP address. To create a new connection profile, go to the Connections tab off of the main VPN tab (see Figure 3.11).

2. Enter a name for this connection. Be sure to use a name that makes it obvious what is being connecting.

3. Define the “left” and “right” sides of the connection. (These names have nothing to do with direction, but are just used as references to differentiate the ends of a VPN. The local side is typically on the left.) Input the IP address and subnet for your local SmoothWall on the left side, and the IP address and subnet of the remote SmoothWall on the right side.


Figure 3.10 SmoothWall VPN Control Screen


Figure 3.11 VPN Connections Screen

4. Below that you enter the shared secret that is used to create the encryption. This secret has to be the same on both firewalls being connected. It should be protected and not passed through insecure means (for example, e-mail). Make your secret at least 20 characters long and comprised of lowercase, uppercase, and special characters to make your VPN as strong as it can be.

5. You can also click on the compression box to make your VPN data stream smaller. But keep in mind that this will eat processor cycles and might slow your VPN down more than the gain from less bandwidth.

6. Make sure you click on the Enable box and then click on Add to add your VPN connection. You will now see it on the main VPN Control page and it will come up immediately if the link it is associated with is up.

7. You can also export the VPN settings to another SmoothWall to make for easier configuration and avoid data entry error on configuring additional VPN endpoints. Simply click on Export and it will create a file called vpnconfig.dat. You can then take this to your remote machine and go to the same page and select import. SmoothWall will automatically reverse the entries for the remote end. Your VPN is now ready to go. Repeat this process for as many additional sites as you want to add.

Additional Applications with the SmoothWall

This section is only a cursory overview of the basic functions of the SmoothWall. There are other advanced functions covered in the documentation that accompanies SmoothWall.

For details on setting up the other special services, such as the Web proxy or dynamic DNS, consult the administration manual. All three documentation files are contained in the SmoothWall directory on this book’s CD-ROM in PDF format. If you have a spare machine to dedicate to your firewall, SmoothWall Express lets you go beyond simple firewall functionality and provides a full security appliance for your network.

Windows-Based Firewalls

None of the firewalls described in this chapter run on Windows. Regrettably, there is a lack of quality of firewall open source software for Windows. Because Windows code is itself not open, it isn’t easy for programmers to write something as complex as a firewall, which requires access to operating system–level code. With the addition of a basic firewall in Windows XP, there is even less motivation for coders to develop an open source alternative. This is unfortunate, because the firewall included with XP is fine for individual users, but it isn’t really up to the task of running a company gateway firewall. There are commercial options available for Windows from companies such as Checkpoint. However, even they are moving away from a purely Windows-based solution because of the underlying security issues with Windows. If you need to use a Windows-based firewall solution, you will probably have to go to a commercial firewall, as there isn’t a good open source firewall for Windows. This underscores the limitations and issues with closed source operating systems.


[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye