netfilter-hacking-howto.txt

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

        This function is used to check if an existing mapping puts us in
        the right range, and also to check if no manipulation is
        necessary at all.


     unique_tuple
        This function is the core of NAT: given a tuple and a range,
        we're to alter the per-protocol part of the tuple to place it
        within the range, and make it unique.  If we can't find an
        unused tuple in the range, return 0.  We also get a pointer to
        the conntrack structure, which is required for
        ip_nat_used_tuple().


        The usual approach is to simply iterate the per-protocol part of
        the tuple through the range, checking `ip_nat_used_tuple()' on
        it, until one returns false.


        Note that the null-mapping case has already been checked: it's
        either outside the range given, or already taken.


        If IP_NAT_RANGE_PROTO_SPECIFIED isn't set, it means that the
        user is doing NAT, not NAPT: do something sensible with the
        range.  If no mapping is desirable (for example, within TCP, a
        destination mapping should not change the TCP port unless
        ordered to), return 0.


     print
        Given a character buffer, a match tuple and a mask, write out
        the per-protocol parts and return the length of the buffer used.


     print_range
        Given a character buffer and a range, write out the per-protocol
        part of the range, and return the length of the buffer used.
        This won't be called if the IP_NAT_RANGE_PROTO_SPECIFIED flag
        wasn't set for the range.
  4.4.3.  New NAT Targets

  This is the really interesting part.  You can write new NAT targets
  which provide a new mapping type: two extra targets are provided in
  the default package: MASQUERADE and REDIRECT.  These are fairly simple
  to illustrate the potential and power of writing a new NAT target.


  These are written just like any other iptables targets, but internally
  they will extract the connection and call `ip_nat_setup_info()'.


  4.4.4.  Protocol Helpers

  Protocol helpers for connection tracking allow the connection tracking
  code to understand protocols which use multiple network connections
  (eg. FTP) and mark the `child' connections as being related to the
  initial connection, usually by reading the related address out of the
  data stream.


  Protocol helpers for NAT do two things: firstly allow the NAT code to
  manipulate the data stream to change the address contained within it,
  and secondly to perform NAT on the related connection when it comes
  in, based on the original connection.


  4.4.5.  Connection Tracking Helper Modules

  4.4.5.1.  Description

  The duty of a connection tracking module is to specify which packets
  belong to an already established connection. The module has the
  following means to do that:


  o  Tell netfilter which packets our module is interested in (most
     helpers operate on a particular port).

  o  Register a function with netfilter.  This function is called for
     every packet which matches the criteria above.

  o  An `ip_conntrack_expect_related()' function which can be called
     from there to tell netfilter to expect related connections.


  If there is some additional work to be done at the time the first
  packet of the expected connection arrives, the module can register a
  callback function which is called at that time.


  4.4.5.2.  Structures and Functions Available

  Your kernel module's init function has to call
  `ip_conntrack_helper_register()' with a pointer to a `struct
  ip_conntrack_helper'.  This struct has the following fields:


     list
        This is the header for the linked list. Netfilter handles this
        list internally. Just initialize it with `{ NULL, NULL }'.


     name
        This is a pointer to a string constant specifying the name of
        the protocol. ("ftp", "irc", ...)
     flags
        A set of flags with one or more out of the following flgs:

        o  IP_CT_HELPER_F_REUSE_EXPECTReuse expectations if the limit
           (see `max_expected` below) is reached.


     me A pointer to the module structure of the helper.  Intitialize
        this with  the `THIS_MODULE' macro.


     max_expected
        Maximum number of unconfirmed (outstanding) expectations.


     timeout
        Timeout (in seconds) for each unconfirmed expectation.  An
        expectation is deleted `timeout' seconds after the expectation
        was issued with the `ip_conntrack_expect_related()' function.


     tuple
        This is a `struct ip_conntrack_tuple' which specifies the
        packets our conntrack helper module is interested in.


     mask
        Again a `struct ip_conntrack_tuple'. This mask specifies which
        bits of tuple are valid.


     help
        The function which netfilter should call for each packet
        matching tuple+mask


  4.4.5.3.  Example skeleton of a conntrack helper module



  ______________________________________________________________________
  #define FOO_PORT        111

  static int foo_expectfn(struct ip_conntrack *new)
  {
          /* called when the first packet of an expected
             connection arrives */

          return 0;
  }

  static int foo_help(const struct iphdr *iph, size_t len,
                  struct ip_conntrack *ct,
                  enum ip_conntrack_info ctinfo)
  {
          /* analyze the data passed on this connection and
             decide how related packets will look like */

          /* update per master-connection private data
             (session state, ...) */
          ct->help.ct_foo_info = ...

          if (there_will_be_new_packets_related_to_this_connection)
          {
                  struct ip_conntrack_expect exp;

                  memset(&exp, 0, sizeof(exp));
                  exp.t = tuple_specifying_related_packets;
                  exp.mask = mask_for_above_tuple;
                  exp.expectfn = foo_expectfn;
                  exp.seq = tcp_sequence_number_of_expectation_cause;

                  /* per slave-connection private data */
                  exp.help.exp_foo_info = ...

                  ip_conntrack_expect_related(ct, &exp);
          }
          return NF_ACCEPT;
  }

  static struct ip_conntrack_helper foo;

  static int __init init(void)
  {
          memset(&foo, 0, sizeof(struct ip_conntrack_helper);

          foo.name = "foo";
          foo.flags = IP_CT_HELPER_F_REUSE_EXPECT;
          foo.me = THIS_MODULE;
          foo.max_expected = 1;   /* one expectation at a time */
          foo.timeout = 0;        /* expectation never expires */

          /* we are interested in all TCP packets with destport 111 */
          foo.tuple.dst.protonum = IPPROTO_TCP;
          foo.tuple.dst.u.tcp.port = htons(FOO_PORT);
          foo.mask.dst.protonum = 0xFFFF;
          foo.mask.dst.u.tcp.port = 0xFFFF;
          foo.help = foo_help;

          return ip_conntrack_helper_register(&foo);
  }

  static void __exit fini(void)
  {
          ip_conntrack_helper_unregister(&foo);
  }
  ______________________________________________________________________



  4.4.6.  NAT helper modules

  4.4.6.1.  Description

  NAT helper modules do some application specific NAT handling.  Usually
  this includes on-the-fly manipulation of data: think about the PORT
  command in FTP, where the client tells the server which IP/port to
  connect to.  Therefor an FTP helper module must replace the IP/port
  after the PORT command in the FTP control connection.


  If we are dealing with TCP, things get slightly more complicated.  The
  reason is a possible change of the packet size (FTP example: the
  length of the string representing an IP/port tuple after the PORT
  command has changed).  If we change the packet size, we have a syn/ack
  difference between left and right side of the NAT box. (i.e. if we had
  extended one packet by 4 octets, we have to add this offset to the TCP
  sequence number of each following packet).


  Special NAT handling of all related packets is required, too.  Take as
  example again FTP, where all incoming packets of the DATA connection
  have to be NATed to the IP/port given by the client with the PORT
  command on the control connection, rather than going through the
  normal table lookup.


  o  callback for the packet causing the related connection (foo_help)

  o  callback for all related packets (foo_nat_expected)


  4.4.6.2.  Structures and Functions Available

  Your nat helper module's `init()' function calls
  `ip_nat_helper_register()' with a pointer to a `struct ip_nat_helper'.
  This struct has the following members:


     list
        Just again the list header for netfilters internal use.
        Initialize this with { NULL, NULL }.


     name
        A pointer to a string constant with the protocol's name


     flags
        A set out of zero, one or more of the following flags:

        o  IP_NAT_HELPER_F_ALWAYSCall the NAT helper for every packet,
           not only for packets where conntrack has detected an
           expectation-cause.

        o  IP_NAT_HELPER_F_STANDALONETell the NAT core that this
           protocol doesn't have a conntrack helper, only a NAT helper.


     me A pointer to the module structure of the helper.  Initialize
        this using the `THIS_MODULE' macro.


     tuple
        a `struct ip_conntrack_tuple' describing which packets our NAT
        helper is interested in.


     mask
        a `struct ip_conntrack_tuple', telling netfilter which bits of
        tuple are valid.


     help
        The help function which is called for each packet matching
        tuple+mask.


     expect
        The expect function which is called for every first packet of an
        expected connection.


  This is very similar to writing a connection tracking helper.


  4.4.6.3.  Example NAT helper module



  ______________________________________________________________________
  #define FOO_PORT        111

  static int foo_nat_expected(struct sk_buff **pksb,
                          unsigned int hooknum,
                          struct ip_conntrack *ct,
                          struct ip_nat_info *info)
  /* called whenever the first packet of a related connection arrives.
     params:      pksb    packet buffer
                  hooknum HOOK the call comes from (POST_ROUTING, PRE_ROUTING)
                  ct      information about this (the related) connection
                  info    &ct->nat.info
     return value: Verdict (NF_ACCEPT, ...)
  {
          /* Change ip/port of the packet to the masqueraded
             values (read from master->tuplehash), to map it the same way,
             call ip_nat_setup_info, return NF_ACCEPT. */

  }

  static int foo_help(struct ip_conntrack *ct,
                      struct ip_conntrack_expect *exp,
                      struct ip_nat_info *info,
                      enum ip_conntrack_info ctinfo,
                      unsigned int hooknum,
                      struct sk_buff  **pksb)
  /* called for every packet where conntrack detected an expectation-cause
     params:      ct      struct ip_conntrack of the master connection
                  exp     struct ip_conntrack_expect of the expectation
                          caused by the conntrack helper for this protocol
                  info    (STATE: related, new, established, ... )
                  hooknum HOOK the call comes from (POST_ROUTING, PRE_ROUTING)
                  pksb    packet buffer
  */
  {

          /* extract information about future related packets (you can
             share information with the connection tracking's foo_help).
             Exchange address/port with masqueraded values, insert tuple