iptables-optimizer - optimize iptables filter-chains in kernel depending on
their usage counters
iptables-optimizer [-a] [-c] [-h] [-v[v]] [-w]
is used to sort iptables-rules in relation to the
values of their packet-counters. And of course, administrators artwork is
untouched. Sorting only happens in consecutive blocks of accept or drop
statements, never across their borders. Therefore these blocks are called
partitions and so they behave.
iptables-optimizer is shipped in three files, a shell wrapper, functions to be
sourced from it and a python exec. The sourced functions were neccessary
because of testing them with shunit2,
thanks to Karen Ward for this
wonderful tool. The wrapper is my tribute to the changing function of python
subprocess in different default python versions over some Debian releases.
It runs in four steps, working directory is /var/run, id=0 is neccessary:
is checked for read and exec
flags. If so, the file is used as input on running iptables-restore,
afterwards it is renamed. The renaming follows up a simple datetime strategy,
this action is logged as well. Thats my way of firing new rules into the
machine. They are copied using scp and after that marked as executable with
chmod through ssh.
2) iptables-save -t filter -c > iptables-optimizer-save-output
3) iptables_optimizer.py iptables-optimizer-save-output
4) iptables-restore [ -c ] iptables-optimizer-output
Of course, you might want to run it by cron every now and then.
- If given, it prevents the iptables-optimizer from handling
the file /var/cache/iptables-optimizer/auto-apply
- This option will prevent iptables-optimizer to reset
paket/byte counters on restoring the tables, i.e these counters will be
reloaded with the sorted rules. Intention is to support long term
debugging sessions, because the position of the rules to be obeyed will be
- Shows a brief help message about valid optional arguments
and exits 1
- Verbose logging, i.e. reporting the steps and the number of
rules. If given twice, the number of moves and the partitions as well.
- reports INPUT and OUTPUT chain only, useful on non
keeps all the new rulesets, incomig new
is renamed to f.e. auto-apply-20140818-091958
kept there. Feel free to clean up these files or keep them as you like it.
keeps the temporary files, their names all are beginning with
The handling of an executable file auto-apply
is reported always. At
least start and end of every program run is reported via syslog. Single
verbose flag shows the three steps and the corresponding number of iptables
commands. Two verbose flags additionally will show up the count of moves and
the partitions of the chains.
iptables-optimizer usually returns a value of 0. Accidentially in case of error,
f.e. if the iptables-restore fails, it returns the triggering error.
be compatible to any iptables implementations
out in the wild. If not, keep me informed, thanks. I'll do my very best.
iptables-optimizer has grown from first ideas over some more than two years and
many errors to a productive state. First tries to use subproces within the
python soon led into problems using different python versions on different
debian releases. So these tasks were done on shell level, python testing and
shell testing improved the solution.
GNU General Public License version 3 or any newer version applies to
Johannes Hubertz <firstname.lastname@example.org> wrote this in 2012 - 2016. Anytime
comments are welcome.