Linux Firewalls - Michael Rash [9]
This book takes a highly applied approach. Concepts are better understood with real examples, and getting down into the guts of the source code or carefully examining packet traces are always excellent ways to understand what a computer is doing. It is my hope that after reading this book you will be armed with a strong working knowledge of how network attacks are detected and dealt with via iptables. Once again, I strongly encourage you to ask questions, and you can always reach me at mbr@cipherdyne.org.
Chapter 1. CARE AND FEEDING OF IPTABLES
In this chapter we'll explore essential aspects of properly installing, maintaining, and interacting with the iptables firewall on Linux systems. We'll cover iptables administration from the perspectives of both kernel and userland, as well as how to build and maintain an iptables firewall policy. A default policy will be constructed that will serve as a guide throughout several chapters in the book; a script that implements it and a network diagram are included for reference in this chapter. Many of the example attacks throughout this book will be launched from hosts shown in this network diagram. Finally, we'll cover testing the default iptables policy to ensure that it is functioning as designed.
iptables
The iptables firewall is developed by the Netfilter Project (http://www.netfilter.org) and has been available to the masses as part of Linux since the release of the Linux 2.4 kernel in January 2001.
Over the years, iptables has matured into a formidable firewall with most of the functionality typically found in proprietary commercial firewalls. For example, iptables offers comprehensive protocol state tracking, packet application layer inspection, rate limiting, and a powerful mechanism to specify a filtering policy. All major Linux distributions include iptables, and many prompt the user to deploy an iptables policy right from the installer.
The differences between the terms iptables and Netfilter have been a source of some confusion in the Linux community. The official project name for all of the packet filtering and mangling facilities provided by Linux is Netfilter, but this term also refers to a framework within the Linux kernel that can be used to hook functions into the networking stack at various stages. On the other hand, iptables uses the Netfilter framework to hook functions designed to perform operations on packets (such as filtering) into the networking stack. You can think of Netfilter as providing the framework on which iptables builds firewall functionality.
The term iptables also refers to the userland tool that parses the command line and communicates a firewall policy to the kernel. Terms such as tables, chains, matches, and targets (defined later in this chapter) make sense in the context of iptables.
Netfilter does not filter traffic itself—it just allows functions that can filter traffic to be hooked into the right spot within the kernel. (I will not belabor this point; much of the material in this book centers around iptables and how it can take action against packets that match certain criteria.) The Netfilter Project also provides several pieces of infrastructure in the kernel, such as connection tracking and logging; any iptables policy can use these facilities to perform specialized packet processing.
Note
In this book I will refer to log messages generated by the Netfilter logging subsystem as iptables log messages; after all, packets are only logged upon matching a LOG rule that is constructed by iptables in the first place. So as to not confuse things, I will use the term iptables by default unless there is a compelling reason to use Netfilter (such as when discussing kernel compilation options or connection-tracking capabilities). Most people associate Linux firewalls with iptables, anyway.
Packet Filtering with iptables
The iptables firewall allows the user to instrument a high degree of control over IP packets that interact with a Linux system; that control is implemented