/usr/share/doc/iptables-dev/html/netfilter-hacking-HOWTO-1.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.69">
 <TITLE>Linux netfilter Hacking HOWTO: Introduction</TITLE>
 <LINK HREF="netfilter-hacking-HOWTO-2.html" REL=next>

 <LINK HREF="netfilter-hacking-HOWTO.html#toc1" REL=contents>
</HEAD>
<BODY>
<A HREF="netfilter-hacking-HOWTO-2.html">Next</A>
Previous
<A HREF="netfilter-hacking-HOWTO.html#toc1">Contents</A>
<HR>
<H2><A NAME="intro"></A> <A NAME="s1">1.</A> <A HREF="netfilter-hacking-HOWTO.html#toc1">Introduction</A></H2>

<P>Hi guys.</P>

<P>This document is a journey; some parts are well-traveled, and in
other areas you will find yourself almost alone.  The best advice I
can give you is to grab a large, cozy mug of coffee or hot chocolate,
get into a comfortable chair, and absorb the contents before venturing
out into the sometimes dangerous world of network hacking.</P>

<P>For more understanding of the use of the infrastructure on top of
the netfilter framework, I recommend reading the Packet Filtering
HOWTO and the NAT HOWTO.  For information on kernel programming I
suggest Rusty's Unreliable Guide to Kernel Hacking and Rusty's
Unreliable Guide to Kernel Locking.</P>

<P>(C) 2000 Paul `Rusty' Russell.  Licenced under the GNU GPL.</P>

<H2><A NAME="ss1.1">1.1</A> <A HREF="netfilter-hacking-HOWTO.html#toc1.1">What is netfilter?</A>
</H2>

<P>netfilter is a framework for packet mangling, outside the normal
Berkeley socket interface.  It has four parts.  Firstly, each protocol
defines "hooks" (IPv4 defines 5) which are well-defined points in a
packet's traversal of that protocol stack.  At each of these points,
the protocol will call the netfilter framework with the packet and the
hook number.</P>

<P>Secondly, parts of the kernel can register to listen to the different
hooks for each protocol.  So when a packet is passed to the netfilter
framework, it checks to see if anyone has registered for that protocol
and hook; if so, they each get a chance to examine (and possibly
alter) the packet in order, then discard the packet
(<CODE>NF_DROP</CODE>), allow it to pass (<CODE>NF_ACCEPT</CODE>), tell
netfilter to forget about the packet (<CODE>NF_STOLEN</CODE>), or ask
netfilter to queue the packet for userspace (<CODE>NF_QUEUE</CODE>).</P>

<P>The third part is that packets that have been queued are collected (by
the ip_queue driver) for sending to userspace; these packets are
handled asynchronously.</P>

<P>The final part consists of cool comments in the code and
documentation.  This is instrumental for any experimental project.
The netfilter motto is (stolen shamelessly from Cort Dougan):</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
        ``So... how is this better than KDE?''
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>(This motto narrowly edged out `Whip me, beat me, make me use
ipchains').</P>

<P>In addition to this raw framework, various modules have been written
which provide functionality similar to previous (pre-netfilter)
kernels, in particular, an extensible NAT system, and an extensible
packet filtering system (iptables).</P>

<H2><A NAME="ss1.2">1.2</A> <A HREF="netfilter-hacking-HOWTO.html#toc1.2">What's wrong with what we had in 2.0 and 2.2?</A>
</H2>

<P>
<OL>
<LI>No infrastructure established for passing packet to userspace:
<UL>
<LI>Kernel coding is hard</LI>
<LI>Kernel coding must be done in C/C++</LI>
<LI>Dynamic filtering policies do not belong in kernel</LI>
<LI> 2.2 introduced copying packets to userspace via netlink, but
reinjecting packets is slow, and subject to `sanity' checks.
For example, reinjecting packet claiming to come from an
existing interface is not possible.</LI>
</UL>

</LI>
<LI>Transparent proxying is a crock:

<UL>
<LI> We look up <B>every</B> packet to see if there is a socket
bound to that address
</LI>
<LI> Root is allowed to bind to foreign addresses
</LI>
<LI> Can't redirect locally-generated packets
</LI>
<LI> REDIRECT doesn't handle UDP replies: redirecting UDP named
packets to 1153 doesn't work because some clients don't like replies
coming from anything other than port 53.
</LI>
<LI> REDIRECT doesn't coordinate with tcp/udp port allocation: a
user may get a port shadowed by a REDIRECT rule.
</LI>
<LI>Has been broken at least twice during 2.1 series.
</LI>
<LI>Code is extremely intrusive.  Consider the stats on the number
of #ifdef CONFIG_IP_TRANSPARENT_PROXY in 2.2.1: 34 occurrences in 11
files.  Compare this with CONFIG_IP_FIREWALL, which has 10 occurrences
in 5 files.</LI>
</UL>

</LI>
<LI>Creating packet filter rules independent of interface addresses
is not possible:

<UL>
<LI>Must know local interface addresses to distinguish
locally-generated or locally-terminating packets from through
packets.
</LI>
<LI>Even that is not enough in cases of redirection or
masquerading.
</LI>
<LI>Forward chain only has information on outgoing interface,
meaning you have to figure where a packet came from using knowledge of
the network topography.</LI>
</UL>

</LI>
<LI>Masquerading is tacked onto packet filtering:
<P>Interactions between packet filtering and masquerading make firewalling
complex:
<UL>
<LI>At input filtering, reply packets appear to be destined for box itself</LI>
<LI>At forward filtering, demasqueraded packets are not seen at all</LI>
<LI>At output filtering, packets appear to come from local box</LI>
</UL>
</P>

</LI>
<LI>TOS manipulation, redirect, ICMP unreachable and mark (which can
effect port forwarding, routing, and QoS) are tacked onto packet
filter code as well.
</LI>
<LI>ipchains code is neither modular, nor extensible (eg. MAC
address filtering, options filtering, etc).
</LI>
<LI>Lack of sufficient infrastructure has led to a profusion of
different techniques:
<UL>
<LI>Masquerading, plus per-protocol modules</LI>
<LI>Fast static NAT by routing code (doesn't have per-protocol handling)</LI>
<LI>Port forwarding, redirect, auto forwarding</LI>
<LI>The Linux NAT and Virtual Server Projects.</LI>
</UL>

</LI>
<LI>Incompatibility between CONFIG_NET_FASTROUTE and packet filtering:
<UL>
<LI>Forwarded packets traverse three chains anyway</LI>
<LI>No way to tell if these chains can be bypassed</LI>
</UL>

</LI>
<LI>Inspection of packets dropped due to routing protection
(eg. Source Address Verification) not possible.
</LI>
<LI>No way of atomically reading counters on packet filter rules.
</LI>
<LI>CONFIG_IP_ALWAYS_DEFRAG is a compile-time option, making life
difficult for distributions who want one general-purpose kernel.
</LI>
</OL>
</P>

<H2><A NAME="ss1.3">1.3</A> <A HREF="netfilter-hacking-HOWTO.html#toc1.3">Who are you?</A>
</H2>

<P>I'm the only one foolish enough to do this.  As ipchains co-author and
current Linux Kernel IP Firewall maintainer, I see many of the
problems that people have with the current system, as well as getting
exposure to what they are trying to do.</P>

<H2><A NAME="ss1.4">1.4</A> <A HREF="netfilter-hacking-HOWTO.html#toc1.4">Why does it crash?</A>
</H2>

<P>Woah!  You should have seen it <B>last</B> week!</P>

<P>Because I'm not as great a programmer as we might all wish, and I
certainly haven't tested all scenarios, because of lack of time,
equipment and/or inspiration.  I do have a testsuite, which I
encourage you to contribute to.</P>

<HR>
<A HREF="netfilter-hacking-HOWTO-2.html">Next</A>
Previous
<A HREF="netfilter-hacking-HOWTO.html#toc1">Contents</A>
</BODY>
</HTML>
iptables-dev 1.4.21-1ubuntu1 / usr / share / doc / iptables-dev / html / netfilter-hacking-HOWTO-1.html
