netfilter-hacking-howto.txt

这是我对防火墙技术的一些见解

  Linux netfilter Hacking HOWTO
  Rusty Russell and Harald Welte, mailing list
  [e-mail]
  $Revision: 1.14 $ $Date: 2002/07/02 04:07:19 $

  This document describes the netfilter architecture for Linux, how to
  hack it, and some of the major systems which sit on top of it, such as
  packet filtering, connection tracking and Network Address Translation.
  ______________________________________________________________________

  Table of Contents



  1. Introduction
     1.1 What is netfilter?
     1.2 What's wrong with what we had in 2.0 and 2.2?
     1.3 Who are you?
     1.4 Why does it crash?

  2. Where Can I Get The Latest?
  3. Netfilter Architecture
     3.1 Netfilter Base
     3.2 Packet Selection: IP Tables
        3.2.1 Packet Filtering
        3.2.2 NAT
           3.2.2.1 Masquerading, Port Forwarding, Transparent Proxying
        3.2.3 Packet Mangling
     3.3 Connection Tracking
     3.4 Other Additions

  4. Information for Programmers
     4.1 Understanding ip_tables
        4.1.1 ip_tables Data Structures
        4.1.2 ip_tables From Userspace
        4.1.3 ip_tables Use And Traversal
     4.2 Extending iptables
        4.2.1 The Kernel
           4.2.1.1 New Match Functions
           4.2.1.2 New Targets
           4.2.1.3 New Tables
        4.2.2 Userspace Tool
           4.2.2.1 New Match Functions
           4.2.2.2 New Targets
        4.2.3 Using `libiptc'
     4.3 Understanding NAT
        4.3.1 Connection Tracking
     4.4 Extending Connection Tracking/NAT
        4.4.1 Standard NAT Targets
        4.4.2 New Protocols
           4.4.2.1 Inside The Kernel
        4.4.3 New NAT Targets
        4.4.4 Protocol Helpers
        4.4.5 Connection Tracking Helper Modules
           4.4.5.1 Description
           4.4.5.2 Structures and Functions Available
           4.4.5.3 Example skeleton of a conntrack helper module
        4.4.6 NAT helper modules
           4.4.6.1 Description
           4.4.6.2 Structures and Functions Available
           4.4.6.3 Example NAT helper module
     4.5 Understanding Netfilter
     4.6 Writing New Netfilter Modules
        4.6.1 Plugging Into Netfilter Hooks
        4.6.2 Processing Queued Packets
        4.6.3 Receiving Commands From Userspace
     4.7 Packet Handling in Userspace

  5. Translating 2.0 and 2.2 Packet Filter Modules
  6. Netfilter Hooks for Tunnel Writers
  7. The Test Suite
     7.1 Writing a Test
     7.2 Variables And Environment
     7.3 Useful Tools
        7.3.1 gen_ip
        7.3.2 rcv_ip
        7.3.3 gen_err
        7.3.4 local_ip
     7.4 Random Advice

  8. Motivation
  9. Thanks


  ______________________________________________________________________

  1.  Introduction

  Hi guys.


  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.


  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.


  (C) 2000 Paul `Rusty' Russell.  Licenced under the GNU GPL.


  1.1.  What is netfilter?

  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.


  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 (NF_DROP), allow
  it to pass (NF_ACCEPT), tell netfilter to forget about the packet
  (NF_STOLEN), or ask netfilter to queue the packet for userspace
  (NF_QUEUE).


  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.


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



               ``So... how is this better than KDE?''



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


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


  1.2.  What's wrong with what we had in 2.0 and 2.2?


  1. No infrastructure established for passing packet to userspace:

     o  Kernel coding is hard

     o  Kernel coding must be done in C/C++

     o  Dynamic filtering policies do not belong in kernel

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


  2. Transparent proxying is a crock:


     o  We look up every packet to see if there is a socket bound to
        that address

     o  Root is allowed to bind to foreign addresses

     o  Can't redirect locally-generated packets

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

     o  REDIRECT doesn't coordinate with tcp/udp port allocation: a user
        may get a port shadowed by a REDIRECT rule.

     o  Has been broken at least twice during 2.1 series.

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


  3. Creating packet filter rules independent of interface addresses is
     not possible:


     o  Must know local interface addresses to distinguish locally-
        generated or locally-terminating packets from through packets.

     o  Even that is not enough in cases of redirection or masquerading.

     o  Forward chain only has information on outgoing interface,
        meaning you have to figure where a packet came from using
        knowledge of the network topography.


  4. Masquerading is tacked onto packet filtering:

     Interactions between packet filtering and masquerading make
     firewalling complex:

     o  At input filtering, reply packets appear to be destined for box
        itself

     o  At forward filtering, demasqueraded packets are not seen at all

     o  At output filtering, packets appear to come from local box


  5. TOS manipulation, redirect, ICMP unreachable and mark (which can
     effect port forwarding, routing, and QoS) are tacked onto packet
     filter code as well.

  6. ipchains code is neither modular, nor extensible (eg. MAC address
     filtering, options filtering, etc).

  7. Lack of sufficient infrastructure has led to a profusion of
     different techniques:

     o  Masquerading, plus per-protocol modules

     o  Fast static NAT by routing code (doesn't have per-protocol
        handling)

     o  Port forwarding, redirect, auto forwarding

     o  The Linux NAT and Virtual Server Projects.


  8. Incompatibility between CONFIG_NET_FASTROUTE and packet filtering:

     o  Forwarded packets traverse three chains anyway

     o  No way to tell if these chains can be bypassed


  9. Inspection of packets dropped due to routing protection (eg. Source
     Address Verification) not possible.

  10.
     No way of atomically reading counters on packet filter rules.

  11.
     CONFIG_IP_ALWAYS_DEFRAG is a compile-time option, making life
     difficult for distributions who want one general-purpose kernel.


  1.3.  Who are you?

  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.


  1.4.  Why does it crash?

  Woah!  You should have seen it last week!


  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.


  2.  Where Can I Get The Latest?

  There is a CVS server on netfilter.org which contains the latest
  HOWTOs, userspace tools and testsuite.  For casual browsing, you can
  use the Web Interface <http://cvs.netfilter.org/>.

  To grab the latest sources, you can do the following:


  1. Log in to the netfilter CVS server anonymously:


       cvs -d :pserver:[e-mail]:/cvspublic login



  2. When it asks you for a password type `cvs'.

  3. Check out the code using:


       # cvs -d :pserver:[e-mail]:/cvspublic co netfilter/userspace



  4. To update to the latest version, use


       cvs update -d -P



  3.  Netfilter Architecture

  Netfilter is merely a series of hooks in various points in a protocol
  stack (at this stage, IPv4, IPv6 and DECnet).  The (idealized) IPv4
  traversal diagram looks like the following:



       A Packet Traversing the Netfilter System:

          --->[1]--->[ROUTE]--->[3]--->[4]--->
                        |            ^
                        |            |
                        |         [ROUTE]
                        v            |
                       [2]          [5]
                        |            ^
                        |            |
                        v            |



  On the left is where packets come in: having passed the simple sanity
  checks (i.e., not truncated, IP checksum OK, not a promiscuous
  receive), they are passed to the netfilter framework's
  NF_IP_PRE_ROUTING [1] hook.


  Next they enter the routing code, which decides whether the packet is
  destined for another interface, or a local process.  The routing code
  may drop packets that are unroutable.


  If it's destined for the box itself, the netfilter framework is called
  again for the NF_IP_LOCAL_IN [2] hook, before being passed to the
  process (if any).


  If it's destined to pass to another interface instead, the netfilter
  framework is called for the NF_IP_FORWARD [3] hook.