1. 10 1月, 2014 1 次提交
    • J
      netfilter: introduce l2tp match extension · 74f77a6b
      James Chapman 提交于
      Introduce an xtables add-on for matching L2TP packets. Supports L2TPv2
      and L2TPv3 over IPv4 and IPv6. As well as filtering on L2TP tunnel-id
      and session-id, the filtering decision can also include the L2TP
      packet type (control or data), protocol version (2 or 3) and
      encapsulation type (UDP or IP).
      
      The most common use for this will likely be to filter L2TP data
      packets of individual L2TP tunnels or sessions. While a u32 match can
      be used, the L2TP protocol headers are such that field offsets differ
      depending on bits set in the header, making rules for matching generic
      L2TP connections cumbersome. This match extension takes care of all
      that.
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      74f77a6b
  2. 08 1月, 2014 1 次提交
  3. 04 1月, 2014 1 次提交
    • D
      netfilter: x_tables: lightweight process control group matching · 82a37132
      Daniel Borkmann 提交于
      It would be useful e.g. in a server or desktop environment to have
      a facility in the notion of fine-grained "per application" or "per
      application group" firewall policies. Probably, users in the mobile,
      embedded area (e.g. Android based) with different security policy
      requirements for application groups could have great benefit from
      that as well. For example, with a little bit of configuration effort,
      an admin could whitelist well-known applications, and thus block
      otherwise unwanted "hard-to-track" applications like [1] from a
      user's machine. Blocking is just one example, but it is not limited
      to that, meaning we can have much different scenarios/policies that
      netfilter allows us than just blocking, e.g. fine grained settings
      where applications are allowed to connect/send traffic to, application
      traffic marking/conntracking, application-specific packet mangling,
      and so on.
      
      Implementation of PID-based matching would not be appropriate
      as they frequently change, and child tracking would make that
      even more complex and ugly. Cgroups would be a perfect candidate
      for accomplishing that as they associate a set of tasks with a
      set of parameters for one or more subsystems, in our case the
      netfilter subsystem, which, of course, can be combined with other
      cgroup subsystems into something more complex if needed.
      
      As mentioned, to overcome this constraint, such processes could
      be placed into one or multiple cgroups where different fine-grained
      rules can be defined depending on the application scenario, while
      e.g. everything else that is not part of that could be dropped (or
      vice versa), thus making life harder for unwanted processes to
      communicate to the outside world. So, we make use of cgroups here
      to track jobs and limit their resources in terms of iptables
      policies; in other words, limiting, tracking, etc what they are
      allowed to communicate.
      
      In our case we're working on outgoing traffic based on which local
      socket that originated from. Also, one doesn't even need to have
      an a-prio knowledge of the application internals regarding their
      particular use of ports or protocols. Matching is *extremly*
      lightweight as we just test for the sk_classid marker of sockets,
      originating from net_cls. net_cls and netfilter do not contradict
      each other; in fact, each construct can live as standalone or they
      can be used in combination with each other, which is perfectly fine,
      plus it serves Tejun's requirement to not introduce a new cgroups
      subsystem. Through this, we result in a very minimal and efficient
      module, and don't add anything except netfilter code.
      
      One possible, minimal usage example (many other iptables options
      can be applied obviously):
      
       1) Configuring cgroups if not already done, e.g.:
      
        mkdir /sys/fs/cgroup/net_cls
        mount -t cgroup -o net_cls net_cls /sys/fs/cgroup/net_cls
        mkdir /sys/fs/cgroup/net_cls/0
        echo 1 > /sys/fs/cgroup/net_cls/0/net_cls.classid
        (resp. a real flow handle id for tc)
      
       2) Configuring netfilter (iptables-nftables), e.g.:
      
        iptables -A OUTPUT -m cgroup ! --cgroup 1 -j DROP
      
       3) Running applications, e.g.:
      
        ping 208.67.222.222  <pid:1799>
        echo 1799 > /sys/fs/cgroup/net_cls/0/tasks
        64 bytes from 208.67.222.222: icmp_seq=44 ttl=49 time=11.9 ms
        [...]
        ping 208.67.220.220  <pid:1804>
        ping: sendmsg: Operation not permitted
        [...]
        echo 1804 > /sys/fs/cgroup/net_cls/0/tasks
        64 bytes from 208.67.220.220: icmp_seq=89 ttl=56 time=19.0 ms
        [...]
      
      Of course, real-world deployments would make use of cgroups user
      space toolsuite, or own custom policy daemons dynamically moving
      applications from/to various cgroups.
      
        [1] http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdfSigned-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: cgroups@vger.kernel.org
      Acked-by: NLi Zefan <lizefan@huawei.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      82a37132
  4. 31 12月, 2013 1 次提交
    • E
      netfilter: nft_reject: support for IPv6 and TCP reset · bee11dc7
      Eric Leblond 提交于
      This patch moves nft_reject_ipv4 to nft_reject and adds support
      for IPv6 protocol. This patch uses functions included in nf_reject.h
      to implement reject by TCP reset.
      
      The code has to be build as a module if NF_TABLES_IPV6 is also a
      module to avoid compilation error due to usage of IPv6 functions.
      This has been done in Kconfig by using the construct:
      
       depends on NF_TABLES_IPV6 || !NF_TABLES_IPV6
      
      This seems a bit weird in terms of syntax but works perfectly.
      Signed-off-by: NEric Leblond <eric@regit.org>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      bee11dc7
  5. 28 12月, 2013 1 次提交
  6. 24 12月, 2013 1 次提交
  7. 08 12月, 2013 1 次提交
  8. 15 10月, 2013 2 次提交
    • T
      netfilter: nf_tables: Add support for IPv6 NAT · eb31628e
      Tomasz Bursztyka 提交于
      This patch generalizes the NAT expression to support both IPv4 and IPv6
      using the existing IPv4/IPv6 NAT infrastructure. This also adds the
      NAT chain type for IPv6.
      
      This patch collapses the following patches that were posted to the
      netfilter-devel mailing list, from Tomasz:
      
      * nf_tables: Change NFTA_NAT_ attributes to better semantic significance
      * nf_tables: Split IPv4 NAT into NAT expression and IPv4 NAT chain
      * nf_tables: Add support for IPv6 NAT expression
      * nf_tables: Add support for IPv6 NAT chain
      * nf_tables: Fix up build issue on IPv6 NAT support
      
      And, from Pablo Neira Ayuso:
      
      * fix missing dependencies in nft_chain_nat
      Signed-off-by: NTomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      eb31628e
    • P
      netfilter: nf_tables: add compatibility layer for x_tables · 0ca743a5
      Pablo Neira Ayuso 提交于
      This patch adds the x_tables compatibility layer. This allows you
      to use existing x_tables matches and targets from nf_tables.
      
      This compatibility later allows us to use existing matches/targets
      for features that are still missing in nf_tables. We can progressively
      replace them with native nf_tables extensions. It also provides the
      userspace compatibility software that allows you to express the
      rule-set using the iptables syntax but using the nf_tables kernel
      components.
      
      In order to get this compatibility layer working, I've done the
      following things:
      
      * add NFNL_SUBSYS_NFT_COMPAT: this new nfnetlink subsystem is used
      to query the x_tables match/target revision, so we don't need to
      use the native x_table getsockopt interface.
      
      * emulate xt structures: this required extending the struct nft_pktinfo
      to include the fragment offset, which is already obtained from
      ip[6]_tables and that is used by some matches/targets.
      
      * add support for default policy to base chains, required to emulate
        x_tables.
      
      * add NFTA_CHAIN_USE attribute to obtain the number of references to
        chains, required by x_tables emulation.
      
      * add chain packet/byte counters using per-cpu.
      
      * support 32-64 bits compat.
      
      For historical reasons, this patch includes the following patches
      that were posted in the netfilter-devel mailing list.
      
      From Pablo Neira Ayuso:
      * nf_tables: add default policy to base chains
      * netfilter: nf_tables: add NFTA_CHAIN_USE attribute
      * nf_tables: nft_compat: private data of target and matches in contiguous area
      * nf_tables: validate hooks for compat match/target
      * nf_tables: nft_compat: release cached matches/targets
      * nf_tables: x_tables support as a compile time option
      * nf_tables: fix alias for xtables over nftables module
      * nf_tables: add packet and byte counters per chain
      * nf_tables: fix per-chain counter stats if no counters are passed
      * nf_tables: don't bump chain stats
      * nf_tables: add protocol and flags for xtables over nf_tables
      * nf_tables: add ip[6]t_entry emulation
      * nf_tables: move specific layer 3 compat code to nf_tables_ipv[4|6]
      * nf_tables: support 32bits-64bits x_tables compat
      * nf_tables: fix compilation if CONFIG_COMPAT is disabled
      
      From Patrick McHardy:
      * nf_tables: move policy to struct nft_base_chain
      * nf_tables: send notifications for base chain policy changes
      
      From Alexander Primak:
      * nf_tables: remove the duplicate NF_INET_LOCAL_OUT
      
      From Nicolas Dichtel:
      * nf_tables: fix compilation when nf-netlink is a module
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      0ca743a5
  9. 14 10月, 2013 2 次提交
    • P
      netfilter: nf_tables: add netlink set API · 20a69341
      Patrick McHardy 提交于
      This patch adds the new netlink API for maintaining nf_tables sets
      independently of the ruleset. The API supports the following operations:
      
      - creation of sets
      - deletion of sets
      - querying of specific sets
      - dumping of all sets
      
      - addition of set elements
      - removal of set elements
      - dumping of all set elements
      
      Sets are identified by name, each table defines an individual namespace.
      The name of a set may be allocated automatically, this is mostly useful
      in combination with the NFT_SET_ANONYMOUS flag, which destroys a set
      automatically once the last reference has been released.
      
      Sets can be marked constant, meaning they're not allowed to change while
      linked to a rule. This allows to perform lockless operation for set
      types that would otherwise require locking.
      
      Additionally, if the implementation supports it, sets can (as before) be
      used as maps, associating a data value with each key (or range), by
      specifying the NFT_SET_MAP flag and can be used for interval queries by
      specifying the NFT_SET_INTERVAL flag.
      
      Set elements are added and removed incrementally. All element operations
      support batching, reducing netlink message and set lookup overhead.
      
      The old "set" and "hash" expressions are replaced by a generic "lookup"
      expression, which binds to the specified set. Userspace is not aware
      of the actual set implementation used by the kernel anymore, all
      configuration options are generic.
      
      Currently the implementation selection logic is largely missing and the
      kernel will simply use the first registered implementation supporting the
      requested operation. Eventually, the plan is to have userspace supply a
      description of the data characteristics and select the implementation
      based on expected performance and memory use.
      
      This patch includes the new 'lookup' expression to look up for element
      matching in the set.
      
      This patch includes kernel-doc descriptions for this set API and it
      also includes the following fixes.
      
      From Patrick McHardy:
      * netfilter: nf_tables: fix set element data type in dumps
      * netfilter: nf_tables: fix indentation of struct nft_set_elem comments
      * netfilter: nf_tables: fix oops in nft_validate_data_load()
      * netfilter: nf_tables: fix oops while listing sets of built-in tables
      * netfilter: nf_tables: destroy anonymous sets immediately if binding fails
      * netfilter: nf_tables: propagate context to set iter callback
      * netfilter: nf_tables: add loop detection
      
      From Pablo Neira Ayuso:
      * netfilter: nf_tables: allow to dump all existing sets
      * netfilter: nf_tables: fix wrong type for flags variable in newelem
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      20a69341
    • P
      netfilter: add nftables · 96518518
      Patrick McHardy 提交于
      This patch adds nftables which is the intended successor of iptables.
      This packet filtering framework reuses the existing netfilter hooks,
      the connection tracking system, the NAT subsystem, the transparent
      proxying engine, the logging infrastructure and the userspace packet
      queueing facilities.
      
      In a nutshell, nftables provides a pseudo-state machine with 4 general
      purpose registers of 128 bits and 1 specific purpose register to store
      verdicts. This pseudo-machine comes with an extensible instruction set,
      a.k.a. "expressions" in the nftables jargon. The expressions included
      in this patch provide the basic functionality, they are:
      
      * bitwise: to perform bitwise operations.
      * byteorder: to change from host/network endianess.
      * cmp: to compare data with the content of the registers.
      * counter: to enable counters on rules.
      * ct: to store conntrack keys into register.
      * exthdr: to match IPv6 extension headers.
      * immediate: to load data into registers.
      * limit: to limit matching based on packet rate.
      * log: to log packets.
      * meta: to match metainformation that usually comes with the skbuff.
      * nat: to perform Network Address Translation.
      * payload: to fetch data from the packet payload and store it into
        registers.
      * reject (IPv4 only): to explicitly close connection, eg. TCP RST.
      
      Using this instruction-set, the userspace utility 'nft' can transform
      the rules expressed in human-readable text representation (using a
      new syntax, inspired by tcpdump) to nftables bytecode.
      
      nftables also inherits the table, chain and rule objects from
      iptables, but in a more configurable way, and it also includes the
      original datatype-agnostic set infrastructure with mapping support.
      This set infrastructure is enhanced in the follow up patch (netfilter:
      nf_tables: add netlink set API).
      
      This patch includes the following components:
      
      * the netlink API: net/netfilter/nf_tables_api.c and
        include/uapi/netfilter/nf_tables.h
      * the packet filter core: net/netfilter/nf_tables_core.c
      * the expressions (described above): net/netfilter/nft_*.c
      * the filter tables: arp, IPv4, IPv6 and bridge:
        net/ipv4/netfilter/nf_tables_ipv4.c
        net/ipv6/netfilter/nf_tables_ipv6.c
        net/ipv4/netfilter/nf_tables_arp.c
        net/bridge/netfilter/nf_tables_bridge.c
      * the NAT table (IPv4 only):
        net/ipv4/netfilter/nf_table_nat_ipv4.c
      * the route table (similar to mangle):
        net/ipv4/netfilter/nf_table_route_ipv4.c
        net/ipv6/netfilter/nf_table_route_ipv6.c
      * internal definitions under:
        include/net/netfilter/nf_tables.h
        include/net/netfilter/nf_tables_core.h
      * It also includes an skeleton expression:
        net/netfilter/nft_expr_template.c
        and the preliminary implementation of the meta target
        net/netfilter/nft_meta_target.c
      
      It also includes a change in struct nf_hook_ops to add a new
      pointer to store private data to the hook, that is used to store
      the rule list per chain.
      
      This patch is based on the patch from Patrick McHardy, plus merged
      accumulated cleanups, fixes and small enhancements to the nftables
      code that has been done since 2009, which are:
      
      From Patrick McHardy:
      * nf_tables: adjust netlink handler function signatures
      * nf_tables: only retry table lookup after successful table module load
      * nf_tables: fix event notification echo and avoid unnecessary messages
      * nft_ct: add l3proto support
      * nf_tables: pass expression context to nft_validate_data_load()
      * nf_tables: remove redundant definition
      * nft_ct: fix maxattr initialization
      * nf_tables: fix invalid event type in nf_tables_getrule()
      * nf_tables: simplify nft_data_init() usage
      * nf_tables: build in more core modules
      * nf_tables: fix double lookup expression unregistation
      * nf_tables: move expression initialization to nf_tables_core.c
      * nf_tables: build in payload module
      * nf_tables: use NFPROTO constants
      * nf_tables: rename pid variables to portid
      * nf_tables: save 48 bits per rule
      * nf_tables: introduce chain rename
      * nf_tables: check for duplicate names on chain rename
      * nf_tables: remove ability to specify handles for new rules
      * nf_tables: return error for rule change request
      * nf_tables: return error for NLM_F_REPLACE without rule handle
      * nf_tables: include NLM_F_APPEND/NLM_F_REPLACE flags in rule notification
      * nf_tables: fix NLM_F_MULTI usage in netlink notifications
      * nf_tables: include NLM_F_APPEND in rule dumps
      
      From Pablo Neira Ayuso:
      * nf_tables: fix stack overflow in nf_tables_newrule
      * nf_tables: nft_ct: fix compilation warning
      * nf_tables: nft_ct: fix crash with invalid packets
      * nft_log: group and qthreshold are 2^16
      * nf_tables: nft_meta: fix socket uid,gid handling
      * nft_counter: allow to restore counters
      * nf_tables: fix module autoload
      * nf_tables: allow to remove all rules placed in one chain
      * nf_tables: use 64-bits rule handle instead of 16-bits
      * nf_tables: fix chain after rule deletion
      * nf_tables: improve deletion performance
      * nf_tables: add missing code in route chain type
      * nf_tables: rise maximum number of expressions from 12 to 128
      * nf_tables: don't delete table if in use
      * nf_tables: fix basechain release
      
      From Tomasz Bursztyka:
      * nf_tables: Add support for changing users chain's name
      * nf_tables: Change chain's name to be fixed sized
      * nf_tables: Add support for replacing a rule by another one
      * nf_tables: Update uapi nftables netlink header documentation
      
      From Florian Westphal:
      * nft_log: group is u16, snaplen u32
      
      From Phil Oester:
      * nf_tables: operational limit match
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      96518518
  10. 28 8月, 2013 2 次提交
  11. 31 7月, 2013 1 次提交
    • F
      netfilter: tproxy: remove nf_tproxy_core, keep tw sk assigned to skb · fd158d79
      Florian Westphal 提交于
      The module was "permanent", due to the special tproxy skb->destructor.
      Nowadays we have tcp early demux and its sock_edemux destructor in
      networking core which can be used instead.
      
      Thanks to early demux changes the input path now also handles
      "skb->sk is tw socket" correctly, so this no longer needs the special
      handling introduced with commit d503b30b
      (netfilter: tproxy: do not assign timewait sockets to skb->sk).
      
      Thus:
      - move assign_sock function to where its needed
      - don't prevent timewait sockets from being assigned to the skb
      - remove nf_tproxy_core.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      fd158d79
  12. 21 1月, 2013 1 次提交
  13. 18 1月, 2013 1 次提交
    • F
      netfilter: add connlabel conntrack extension · c539f017
      Florian Westphal 提交于
      similar to connmarks, except labels are bit-based; i.e.
      all labels may be attached to a flow at the same time.
      
      Up to 128 labels are supported.  Supporting more labels
      is possible, but requires increasing the ct offset delta
      from u8 to u16 type due to increased extension sizes.
      
      Mapping of bit-identifier to label name is done in userspace.
      
      The extension is enabled at run-time once "-m connlabel" netfilter
      rules are added.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      c539f017
  14. 21 9月, 2012 2 次提交
  15. 06 9月, 2012 1 次提交
  16. 03 9月, 2012 1 次提交
  17. 30 8月, 2012 6 次提交
  18. 19 6月, 2012 2 次提交
  19. 16 6月, 2012 1 次提交
    • P
      netfilter: add user-space connection tracking helper infrastructure · 12f7a505
      Pablo Neira Ayuso 提交于
      There are good reasons to supports helpers in user-space instead:
      
      * Rapid connection tracking helper development, as developing code
        in user-space is usually faster.
      
      * Reliability: A buggy helper does not crash the kernel. Moreover,
        we can monitor the helper process and restart it in case of problems.
      
      * Security: Avoid complex string matching and mangling in kernel-space
        running in privileged mode. Going further, we can even think about
        running user-space helpers as a non-root process.
      
      * Extensibility: It allows the development of very specific helpers (most
        likely non-standard proprietary protocols) that are very likely not to be
        accepted for mainline inclusion in the form of kernel-space connection
        tracking helpers.
      
      This patch adds the infrastructure to allow the implementation of
      user-space conntrack helpers by means of the new nfnetlink subsystem
      `nfnetlink_cthelper' and the existing queueing infrastructure
      (nfnetlink_queue).
      
      I had to add the new hook NF_IP6_PRI_CONNTRACK_HELPER to register
      ipv[4|6]_helper which results from splitting ipv[4|6]_confirm into
      two pieces. This change is required not to break NAT sequence
      adjustment and conntrack confirmation for traffic that is enqueued
      to our user-space conntrack helpers.
      
      Basic operation, in a few steps:
      
      1) Register user-space helper by means of `nfct':
      
       nfct helper add ftp inet tcp
      
       [ It must be a valid existing helper supported by conntrack-tools ]
      
      2) Add rules to enable the FTP user-space helper which is
         used to track traffic going to TCP port 21.
      
      For locally generated packets:
      
       iptables -I OUTPUT -t raw -p tcp --dport 21 -j CT --helper ftp
      
      For non-locally generated packets:
      
       iptables -I PREROUTING -t raw -p tcp --dport 21 -j CT --helper ftp
      
      3) Run the test conntrackd in helper mode (see example files under
         doc/helper/conntrackd.conf
      
       conntrackd
      
      4) Generate FTP traffic going, if everything is OK, then conntrackd
         should create expectations (you can check that with `conntrack':
      
       conntrack -E expect
      
          [NEW] 301 proto=6 src=192.168.1.136 dst=130.89.148.12 sport=0 dport=54037 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=192.168.1.136 master-dst=130.89.148.12 sport=57127 dport=21 class=0 helper=ftp
      [DESTROY] 301 proto=6 src=192.168.1.136 dst=130.89.148.12 sport=0 dport=54037 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=192.168.1.136 master-dst=130.89.148.12 sport=57127 dport=21 class=0 helper=ftp
      
      This confirms that our test helper is receiving packets including the
      conntrack information, and adding expectations in kernel-space.
      
      The user-space helper can also store its private tracking information
      in the conntrack structure in the kernel via the CTA_HELP_INFO. The
      kernel will consider this a binary blob whose layout is unknown. This
      information will be included in the information that is transfered
      to user-space via glue code that integrates nfnetlink_queue and
      ctnetlink.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      12f7a505
  20. 09 5月, 2012 1 次提交
  21. 08 3月, 2012 3 次提交
  22. 28 12月, 2011 1 次提交
  23. 25 12月, 2011 2 次提交
    • P
      netfilter: xtables: add nfacct match to support extended accounting · ceb98d03
      Pablo Neira Ayuso 提交于
      This patch adds the match that allows to perform extended
      accounting. It requires the new nfnetlink_acct infrastructure.
      
       # iptables -I INPUT -p tcp --sport 80 -m nfacct --nfacct-name http-traffic
       # iptables -I OUTPUT -p tcp --dport 80 -m nfacct --nfacct-name http-traffic
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      ceb98d03
    • P
      netfilter: add extended accounting infrastructure over nfnetlink · 94139027
      Pablo Neira Ayuso 提交于
      We currently have two ways to account traffic in netfilter:
      
      - iptables chain and rule counters:
      
       # iptables -L -n -v
      Chain INPUT (policy DROP 3 packets, 867 bytes)
       pkts bytes target     prot opt in     out     source               destination
          8  1104 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
      
      - use flow-based accounting provided by ctnetlink:
      
       # conntrack -L
      tcp      6 431999 ESTABLISHED src=192.168.1.130 dst=212.106.219.168 sport=58152 dport=80 packets=47 bytes=7654 src=212.106.219.168 dst=192.168.1.130 sport=80 dport=58152 packets=49 bytes=66340 [ASSURED] mark=0 use=1
      
      While trying to display real-time accounting statistics, we require
      to pool the kernel periodically to obtain this information. This is
      OK if the number of flows is relatively low. However, in case that
      the number of flows is huge, we can spend a considerable amount of
      cycles to iterate over the list of flows that have been obtained.
      
      Moreover, if we want to obtain the sum of the flow accounting results
      that match some criteria, we have to iterate over the whole list of
      existing flows, look for matchings and update the counters.
      
      This patch adds the extended accounting infrastructure for
      nfnetlink which aims to allow displaying real-time traffic accounting
      without the need of complicated and resource-consuming implementation
      in user-space. Basically, this new infrastructure allows you to create
      accounting objects. One accounting object is composed of packet and
      byte counters.
      
      In order to manipulate create accounting objects, you require the
      new libnetfilter_acct library. It contains several examples of use:
      
      libnetfilter_acct/examples# ./nfacct-add http-traffic
      libnetfilter_acct/examples# ./nfacct-get
      http-traffic = { pkts = 000000000000,   bytes = 000000000000 };
      
      Then, you can use one of this accounting objects in several iptables
      rules using the new nfacct match (which comes in a follow-up patch):
      
       # iptables -I INPUT -p tcp --sport 80 -m nfacct --nfacct-name http-traffic
       # iptables -I OUTPUT -p tcp --dport 80 -m nfacct --nfacct-name http-traffic
      
      The idea is simple: if one packet matches the rule, the nfacct match
      updates the counters.
      
      Thanks to Patrick McHardy, Eric Dumazet, Changli Gao for reviewing and
      providing feedback for this contribution.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      94139027
  24. 16 3月, 2011 1 次提交
  25. 03 2月, 2011 1 次提交
  26. 01 2月, 2011 2 次提交
    • J
      netfilter: xtables: "set" match and "SET" target support · d956798d
      Jozsef Kadlecsik 提交于
      The patch adds the combined module of the "SET" target and "set" match
      to netfilter. Both the previous and the current revisions are supported.
      Signed-off-by: NJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      d956798d
    • J
      netfilter: ipset: IP set core support · a7b4f989
      Jozsef Kadlecsik 提交于
      The patch adds the IP set core support to the kernel.
      
      The IP set core implements a netlink (nfnetlink) based protocol by which
      one can create, destroy, flush, rename, swap, list, save, restore sets,
      and add, delete, test elements from userspace. For simplicity (and backward
      compatibilty and for not to force ip(6)tables to be linked with a netlink
      library) reasons a small getsockopt-based protocol is also kept in order
      to communicate with the ip(6)tables match and target.
      
      The netlink protocol passes all u16, etc values in network order with
      NLA_F_NET_BYTEORDER flag. The protocol enforces the proper use of the
      NLA_F_NESTED and NLA_F_NET_BYTEORDER flags.
      
      For other kernel subsystems (netfilter match and target) the API contains
      the functions to add, delete and test elements in sets and the required calls
      to get/put refereces to the sets before those operations can be performed.
      
      The set types (which are implemented in independent modules) are stored
      in a simple RCU protected list. A set type may have variants: for example
      without timeout or with timeout support, for IPv4 or for IPv6. The sets
      (i.e. the pointers to the sets) are stored in an array. The sets are
      identified by their index in the array, which makes possible easy and
      fast swapping of sets. The array is protected indirectly by the nfnl
      mutex from nfnetlink. The content of the sets are protected by the rwlock
      of the set.
      
      There are functional differences between the add/del/test functions
      for the kernel and userspace:
      
      - kernel add/del/test: works on the current packet (i.e. one element)
      - kernel test: may trigger an "add" operation  in order to fill
        out unspecified parts of the element from the packet (like MAC address)
      - userspace add/del: works on the netlink message and thus possibly
        on multiple elements from the IPSET_ATTR_ADT container attribute.
      - userspace add: may trigger resizing of a set
      Signed-off-by: NJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      a7b4f989