Like Unix, Linux systems are impervious to the plethora of security breaches that specifically target Microsoft systems. What’s more, starting with all Linux distributions built on the v2.4.x kernel, Iptables is the user space tool for runtime configuration of the firewall subsystem provided by the kernel space netfilter project  The Iptables and netfilter combo provides for stateless and stateful packet filtering, destination and source Network Address Translation (NAT), and packet mangling. That alone has helped spotlight attention on Linux as the operating system of choice for guarding corporate networks from the crackers at the gates.

Nonetheless, writing scripts for rules in Iptables is an arcane art that is definitely not for amateurs. Even when equipped with the most user-friendly tool available, anyone charged with building a firewall needs to know how packet filtering works and what the potential security holes are. To jumpstart the process, an excellent place to start is the Linux Firewalls book by Robert L. Ziegler, published by New Riders. Moreover, all of the potential security holes are not restricted to networking issues alone. When building a firewall on a distribution designed to function as a general desktop system, a good understanding of Linux system management principles is a must, in order to lock all of the potential back doors that a knowledgeable cracker could exploit.

Naturally, the Mandrake distribution will recognize any number of Ethernet adapters plugged into the system’s backplane. If an “expert” installation is chosen, all of the devices will be shown available to the Linux kernel. The Mandrakesoft GUI interface to Shorewall, however, appears to be set to a hard limit of 4 devices and will not configure multiple virtual Ethernet addresses on a single device. All of these capabilities are standard features of the standard Shorewall package. Worse yet, when we manually created virtual device addresses at the consol using the ifconfig command, the Shorewall web interface was swept asunder.

For our tests, having just 4 Ethernet connections with the integrated Mandrake MNF package presented no stumbling block. We set up an internal trusted LAN on eth0, a DMZ supporting a web server sporting 2 domains and two distinct e-mail servers on eth1, and 2 WANs on eth2 and eth3. Typically we would have preferred to configure our two public web addresses as eth2:0 and eth2:1 on a single Ethernet card.

This is expeditiously handled by the zone configuration wizard on the web interface. What’s more, the simple act of associating zone type with each interface immediately sets into play the base configuration of rules and policies that have been predefined within MandrakeSecurity MNF. This default configuration includes the correct Iptable rules for web and e-mail access from within the secure LAN and restriction of network response from the firewall to the one default secure port on the internal administration LAN (eth0).

Following the first rule of network security, the default policies for each zone—including a special FW zone for rules that only affect the firewall itself—are to reject all packets. The WAN interfaces actually take this a step further and simply drop all inbound packets as a default policy. When packets are dropped no message of any type is sent back to the original sender who may simply be probing to see if there is anything there to crack at an address.

At some sites, all that is expected from a firewall is that it allows users to be safe from any and all attacks while connected to the Internet gathering e-mail and browsing the web. For this function, proxy servers are a good solution, however; proxy servers come in a number of flavors. One alternative is to configure each client to talk to a specific proxy server for Internet traffic. When this is done, desktop clients invoke a different protocol when interacting with the proxy, which in turn uses the standard web protocols to surf the web in behalf of the client.

Alternatively, the firewall can be configured to masquerade for the client. In this scenario, the client knows nothing about the firewall. The client sends normal web packets and the firewall routs them onto the Internet as if they were issued by the firewall. Under this scheme the client remains anonymous and can even have a non-routable public RFC 1597 address. To do this, however, an Iptables’ rule must be in place that overrides the fundamental firewall policy to reject all packets coming from clients on the LAN and drop all packets coming to the firewall from the Internet.

This scheme can be trivially implemented by calling up the masquerade wizard in MandrakeSecurity MNF. The masquerade wizard, like all of the other configuration wizards in MandrakeSecurity MNF, generates all of the necessary rules for Iptables needed to override the fundamental policies that reject or drop all packets at the firewall. Sites can also take this one-step further by turning on the Squid Internet caching server which is built into MandrakeSecurity MNF. Following the principle of masquerading, clients are oblivious to the existence of Squid, which sets up a local cache of frequently accessed Internet objects locally to significantly speed up retrieval from frequently accessed web sites.

Nonetheless, creating Iptables’ rules to protect web clients is about as easy as it gets when configuring a firewall. The tricky part is setting up the rules needed to protect web services, even when those services are just basic e-mail and website serving. This requires opening the kimono on your firewall to let some traffic pass onto the LAN. In general, this is not a good thing.

To protect truly valuable corporate data, two internal LANs are normally configured. First there is a high-security LAN for clients and databases. Systems on this LAN can access the outside world, but the outside world is forever banned from entering into it.

Second there is a DMZ. This LAN is for servers that need to be accessed from the outside world. Like the client desktop systems in the secure LAN, the servers in the DMZ typically have a non-routable public RFC 1597 addresses, however, the DMZ is usually set up to have a different subnet from the secure LAN. The difficulty is to create Iptables’ rules that open the kimono just enough to let the outside world access these servers in the DMZ without compromising the security of the servers.

To script the rules manually, the first bit of information necessary is a complete list of the protocols being used. In the case of an e-mail server, the list is going to include protocols like SMTP, POP, LDAP, and maybe HTTP for web access. Next you’ll need to know the transport protocol: TCP or UDP for each e-mail protocol. Then you need the port numbers on which your e-mail server is listening for the transport protocol. At last, you are now ready to write the correct Iptables’ syntax that will allow each of these protocols to be accepted at the firewall and then routed to the e-mail server.

Fortunately there is an easier way. The rule wizards in MandrakeSecurity MNF greatly simplify matters by offering predefined services for dealing with e-mail, web, MySQL, and a host of other common services that might be offered on a server. This simplifies rule creation for common tasks to a simple two-step process. The first step is to create a rule by picking the interface and service to accept. The second step is to create a rule that routs that service from the firewall to the address of the appropriate server in the DMZ.

This makes the email and web server in the DMZ all accessible from the web. This scheme, however, leaves clients inside the firewall on the secure LAN going out to the web in order to get back into the DMZ and access the e-mail and web servers. To avoid this unnecessary round trip out to the web and back, Shorewall supports simple Proxy ARP rules and a MandrakeSecure MNF wizard takes distinct advantage of this fact. Proxy ARP is readily enabled, which makes the servers in the DMZ subnet directly addressable by the client systems in the secure LAN.

At any time in creating these rules, the network administrator can enhance security by hiding services using obscure port numbers. For example, web traffic by default is handled at port 80. Suppose there are separate web and e-mail servers behind the firewall that are both servicing the same Internet domain and the e-mail server provides clients with web access. It is likely that both servers will default to listening on port 80 for incoming web traffic. Nonetheless, odds are that you want the web server to be very public and the e-mail server very private. Just give users an obscure port number—say 7070—to use for web traffic on the e-mail server. Then with MNF, it is simply a matter of creating two modified web rules that use port 7070 on the firewall and route that traffic to port 80 on the e-mail server.

The MandrakeSecurity MNF rules wizard can also be used to filter content of URLs. In particular, a blacklist of IP addresses can be created and all packets from these addresses will be dropped. This ability to filter URLs can be used to block annoying pop-up ad windows. For the most part, these bothersome advertisements are generated by specialized servers at URLs such as doubleclick.com and unicast.com. Using Squid, however, simplifies the blocking of these URLs. That’s because Squid provides for blocking by domain name rather than IP address, which is much easier than manually looking up all of the IP addresses associated with a domain name.

If simplified rule development were not enough to gain attention, MandrakeSecurity MNF offers two additional bonuses that are sure to warm the heart of any network security manager. The firewall package includes two Open Source network intrusion detection systems: SnortSnarf and Prelude. SnortSnarf from Silicon Defense is a front-end analysis tool written in Perl that takes the alerts logged by the Snort Intrusion Detection System and produces a detailed analysis in HTML format. These network intrusion detection systems can detect probes, scans, and other anomalous network activity from any of the network interfaces.

Equally important for many sites, these intrusion detection systems can also serve to identify general network traffic patterns when troubleshooting network problems. Using MandrakeSecurity MNF, system administrators are also able to monitor the amount of bandwidth used by various types of network traffic to ensure that business-critical applications are not impacted by web surfing or other non-critical applications.

MandrakeSecurity MNF is available through two different licenses. There is the standard "Download" End-User License Agreement. Based on the GPL license, this license enables users to freely copy and adapt the code. In addition, there is a "Commercial" End-User License Agreement for companies wishing to build and commercially redistribute a derivative product. The Commercial License Agreement provides extended guaranties, extra levels of support, security updates (through subscription), rights to change the code, and access to use of MandrakeSoft's brand.