Linux Firewalls Hold Up Under Application Layer Attacks

Printer-friendly version Email this CRN article

Connecting a system to the lifeblood that is the Internet today is a risky proposition, even with the latest patches and security updates applied.
Intrusion Detection Systems have proved their worth from a network security monitoring perspective, but there is no substitute for a good inline
mechanism to enforce policy. Typically, this means that you need a firewall,
but a firewall by itself is not enough. If IDS technology has proven anything,
it is that application layer decoding and inspection is critical to
maintaining a strong network security posture. Therefore, it's only natural
to build application layer inspection capabilities into tried and true inline
enforcement devices -- firewalls.

In the world of the Linux operating system and open source software, the iptables firewall provides a full featured and stable packet filtering
infrastructure. Commercial-grade capabilities such as protocol state tracking,
NAT, rate limiting, and comprehensive logging are all provided by iptables,
and excellent GUI management interfaces such as fwbuilder are also
freely available. However, the real icing on the cake offered by iptables is
its ability to detect and respond to application layer attacks. This feature
is made possible with the iptables string match extension, and the best part
is that if you are running Linux in your infrastructure, then you may already
have this capability deployed.

The term usually applied to application layer
inspection and enforcement mechanisms is "Intrusion Prevention System," but
adoption of IPS technology (such as Snort running in inline mode or other
commercial systems) has been slow. Network administrators are hesitant to
deploy additional inline devices out of concern for basic connectivity and
the need for low latency communications. This is where the stability of
iptables, which is tested on Linux systems across the globe, makes its mark.

A true IPS is always inline to the network data path so that malicious
packets can be dropped before they are forwarded to a targeted system. This is
not possible with a traditional IDS that passively monitors traffic from a
span port on a switch. Sure, even an IDS can knock down TCP connections with a spoofed RST, or interact with a remote firewall to block an attacker, but this
does not stop the initial portions of an attack from reaching a targeted
system. With iptables on your Linux systems, you basically have an IPS at your
disposal for free.

One piece is missing though: What are the specific attacks that iptables
can detect and thwart? To answer this, the best strategy is to turn to the
Snort rules community. This community reverse engineers the latest exploits,
attacks, and malware in order to provide detection rules to people who run the
Snort IDS, and free rules are available.

Next, you need a way to
automatically translate Snort rules into equivalent iptables rules, and this
is where the fwsnort project comes in. With fwsnort, you can build an
iptables policy that leverages the power of the Snort community to detect and
react to application layer attacks in real time. Significant coverage of
fwsnort can be found in
the new book
from No Starch Press entitled "Linux
Firewalls: Attack Detection and Response with iptables, psad, and fwsnort."

When it comes to network security, iptables is a robust and feature-full
firewall. It is time to take back the Internet from wrongdoers with strong
inline application layer inspection with Snort rule sets, iptables policies,
and fwsnort.

Michael Rash holds a Master's Degree in applied mathematics with a
concentration in computer security from the University of Maryland. He is the founder of, a website dedicated to open source
security software for Linux systems, and works professionally as a Security
Architect on the Dragon IDS/IPS for Enterasys Networks. He is the author of
the book "Linux Firewalls: Attack Detection and Response with iptables, psad,
and fwsnort," published by No Starch Press.

Printer-friendly version Email this CRN article