Gecko [ v99win.today ]

Name	Size	Permission
NAT-HOWTO-1.html	1.13 KB	-rw-r--r--
NAT-HOWTO-10.html	2.47 KB	-rw-r--r--
NAT-HOWTO-11.html	910 B	-rw-r--r--
NAT-HOWTO-2.html	4.24 KB	-rw-r--r--
NAT-HOWTO-3.html	1.41 KB	-rw-r--r--
NAT-HOWTO-4.html	4.3 KB	-rw-r--r--
NAT-HOWTO-5.html	5.02 KB	-rw-r--r--
NAT-HOWTO-6.html	8.2 KB	-rw-r--r--
NAT-HOWTO-7.html	1.29 KB	-rw-r--r--
NAT-HOWTO-8.html	1.11 KB	-rw-r--r--
NAT-HOWTO-9.html	2.04 KB	-rw-r--r--
NAT-HOWTO.html	2.6 KB	-rw-r--r--
netfilter-extensions-HOWTO-1.h...	2.05 KB	-rw-r--r--
netfilter-extensions-HOWTO-2.h...	7.62 KB	-rw-r--r--
netfilter-extensions-HOWTO-3.h...	28.29 KB	-rw-r--r--
netfilter-extensions-HOWTO-4.h...	12.25 KB	-rw-r--r--
netfilter-extensions-HOWTO-5.h...	6.88 KB	-rw-r--r--
netfilter-extensions-HOWTO-6.h...	10.98 KB	-rw-r--r--
netfilter-extensions-HOWTO-7.h...	2.14 KB	-rw-r--r--
netfilter-extensions-HOWTO-8.h...	1021 B	-rw-r--r--
netfilter-extensions-HOWTO-9.h...	2.17 KB	-rw-r--r--
netfilter-extensions-HOWTO.htm...	7.1 KB	-rw-r--r--
netfilter-hacking-HOWTO-1.html	7.3 KB	-rw-r--r--
netfilter-hacking-HOWTO-2.html	1.68 KB	-rw-r--r--
netfilter-hacking-HOWTO-3.html	7.85 KB	-rw-r--r--
netfilter-hacking-HOWTO-4.html	52.09 KB	-rw-r--r--
netfilter-hacking-HOWTO-5.html	1.03 KB	-rw-r--r--
netfilter-hacking-HOWTO-6.html	2.96 KB	-rw-r--r--
netfilter-hacking-HOWTO-7.html	9.07 KB	-rw-r--r--
netfilter-hacking-HOWTO-8.html	5.11 KB	-rw-r--r--
netfilter-hacking-HOWTO-9.html	835 B	-rw-r--r--
netfilter-hacking-HOWTO.html	3.72 KB	-rw-r--r--
packet-filtering-HOWTO-1.html	1.85 KB	-rw-r--r--
packet-filtering-HOWTO-10.html	2.51 KB	-rw-r--r--
packet-filtering-HOWTO-11.html	3.65 KB	-rw-r--r--
packet-filtering-HOWTO-2.html	1.56 KB	-rw-r--r--
packet-filtering-HOWTO-3.html	5.64 KB	-rw-r--r--
packet-filtering-HOWTO-4.html	2.14 KB	-rw-r--r--
packet-filtering-HOWTO-5.html	1.61 KB	-rw-r--r--
packet-filtering-HOWTO-6.html	3.42 KB	-rw-r--r--
packet-filtering-HOWTO-7.html	34.78 KB	-rw-r--r--
packet-filtering-HOWTO-8.html	1.42 KB	-rw-r--r--
packet-filtering-HOWTO-9.html	2.28 KB	-rw-r--r--
packet-filtering-HOWTO.html	2.76 KB	-rw-r--r--

Code Editor : 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.82">
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
 <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>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>

<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>

<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>

${this.title}

Code Editor : netfilter-hacking-HOWTO-1.html