netdev - Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 12 Apr 2009 14:30:26 +0200
From:	Harald Welte <laforge@...filter.org>
To:	david@...g.hm
Cc:	Kyle Moffett <kyle@...fetthome.net>,
	David Miller <davem@...emloft.net>, jengelh@...ozas.de,
	paulmck@...ux.vnet.ibm.com, torvalds@...ux-foundation.org,
	mingo@...e.hu, laijs@...fujitsu.com, shemminger@...tta.com,
	jeff.chua.linux@...il.com, dada1@...mosbay.com, kaber@...sh.net,
	r000n@...0n.net, linux-kernel@...r.kernel.org,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: iptables very slow after commit
	784544739a25c30637397ace5489eeb6e15d7d49

Hi all,

On Sat, Apr 11, 2009 at 05:54:41PM -0700, david@...g.hm wrote:
>> Almost all of the standard firewall tools (such as shorewall, etc) are
>> already using iptables-restore command to load firewall rules,
>> primarily because using separate iptables commands was *already* way
>> too slow.  There's also the serious race-condition of doing a firewall
>> restart that way where you only have half your rules loaded for a bit.
>> The "iptables" command is fine for fiddling around with the command
>> line and making minor tweaks, but it simply doesn't cut it for
>> large-scale rules.
>
> what are the userspace level tools that I am supposed to use in place of  
> my current process? (which is to have a script that 1. stops traffic, 2.  
> executes the iptables commands to create the rules that I want, then 3.  
> enables traffic)
>
> iptables-restore only works if you are actually restoring the old set of  
> rules. if you need to change the rules that doesn't work.

That's what I implemented as "iptables-restore --noflush" a number of years
ago. It doesn't flush the current uleset and swaps in a new one, but 
reads the current rules from kernel, applies any number of changes and swaps
the new ruleset in.

The syntax of iptables-restore is almost identical to iptables commands, you
just specify the table in a different way.  So you would just create your
desired changes in that format, and echo that into iptables-restore.  If it's
an entire new ruleset, you use no '--noflush' and it does automatic flushing
of all old rules.  If your stdin-file contains only incremental changes, you
use --noflush.

In the netfilter project, we knew for many years that the 'swap the entire
table atomically in' is a bad design choice.  This is what various developers
have been trying to address at different times, and which finally resulted
in the nftables implementation of Patrick McHardy.  So for the mid- to long
term there is a clear design that moves away from that.

But so far, we have to live with the API and its semantics.  iptables userspace
has been improved a number of times, and things like iptables-restore with or
without --noflush can be used as an intermediate solution - and have been used
by many systems out there.

-- 
- Harald Welte <laforge@...filter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)