iptables visualization tool

I posted this to the apps devel group last week with no response. Perhaps
someone here would find this useful? I'd love to hear some feedback on
it. My ultimate objective is just to display the rule tree in a
hierarchical form so I can follow all the subchains. So each -J subchain
target would appears as a subtree in the hierarchy (possibly multiple
times if it's used by multiple rules in other chains).

I threw together a bit of Perl to parse the output of iptables-save into
a nested structure, posted inline below. Perhaps someone with nimbler
fingers would like to toss it up on the screen in a Tk::HList, with
color-coding for accept/reject/drop terminal conditions?

For Red Hat users, you can use:

iptables-display.pl < /etc/sysconfig/iptables

to dump the boot-time firewall.

For the in-memory firewall, use:

iptables-save | iptables-display.pl

--
Kenneth Porter
http://www.sewingwitch.com/ken/

Code follows:

#!/usr/bin/perl -w

use strict;
use Text::ParseWords;
use Data:umper;

my %main_table;
my $current_table;

while (<>) {
# remove trailing newline
chomp;

# split into fields on space, handling quoted strings in log lines
my @Entry = parse_line('\s+', 0, $_);

# first char of iptables-save format is one of:
# * main (-t) table name
# # comment
# : regular (-A) table name
# C COMMIT directive (end of main table)
# [ rule (start of counters)

my $firstchar = substr($Entry[0],0,1);
if ("*" eq $firstchar) {
# new major table
$current_table = substr($Entry[0],1);
} elsif (":" eq $firstchar) {
# new minor table, add it to the major table
$main_table{$current_table}{substr($Entry[0],1)} =
{ "policy" => $Entry[1], "rules" => [ ] };
} elsif ("[" eq $firstchar) {
# get rid of counters on front of list
shift(@Entry);
# fall through....
}
if ("-A" eq $Entry[0]) {
# new rule, append to minor table rules array
my $sub_table = $Entry[1];
# rule is hash indexed by iptables switch name
my %rule = splice(@Entry,2,-1);
push(@{$main_table{$current_table}{$sub_table}{"ru les"}},
\%rule);
}
# ignore all other lines
}

print Dumper(\%main_table);

(E-Mail Removed) said:
>I posted this to the apps devel group last week with no response.

I saw that there and thought "Nice, I'll get it from Google if I need
something like that". Now seeing your repost I thought it won't take that
long to run a quick test.

As of now it doesn't do much -- so, out of the original listing I just
get (almost) the same data as a lot longer listing. Though there still
might be some value in the idea of breaking the rules into components.
And using the Data:umper definitely was a nice idea.

>My ultimate objective is just to display the rule tree in a
>hierarchical form so I can follow all the subchains. So each -J
>subchain target would appears as a subtree in the hierarchy (possibly
>multiple times if it's used by multiple rules in other chains).

I think I don't agree with this idea: consider the subchains as subroutines
in programming: you "know" what your subroutines do, when reading a listing,
you don't want to expand the subroutines to replace every subroutine call.


Then to my main content for this message: you're not parsing correctly.
F.ex. the program fails for rules where there's more than one argument
for a single option - as is the case for --tcp-flags. Similarly, you're
not handling the possible ! preceding --syn.

Visualising the rulesets as a graph still is a good idea; perhaps the
old-fashioned flow chart would be good here.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Juha Laiho <(E-Mail Removed)> wrote in
news:bk4q4q$dgg$(E-Mail Removed)-int:

> I saw that there and thought "Nice, I'll get it from Google if I need
> something like that". Now seeing your repost I thought it won't take
> that long to run a quick test.

I hear you, I do the same.

> As of now it doesn't do much -- so, out of the original listing I just
> get (almost) the same data as a lot longer listing. Though there still
> might be some value in the idea of breaking the rules into components.
> And using the Data:umper definitely was a nice idea.

Thanks, my first waypoint was to get the basic parsing right, and you've
spotted a couple of problems I'll need to fix. I was using Dumper to test
my parsing.

>>My ultimate objective is just to display the rule tree in a
>>hierarchical form so I can follow all the subchains. So each -J
>>subchain target would appears as a subtree in the hierarchy (possibly
>>multiple times if it's used by multiple rules in other chains).
>
> I think I don't agree with this idea: consider the subchains as
> subroutines in programming: you "know" what your subroutines do, when
> reading a listing, you don't want to expand the subroutines to replace
> every subroutine call.

That's why I think a hierarchical display with collapsing nodes would be
useful, so I can see the "high-level" stuff and then expand the
subroutines to inspect what they do.

> Then to my main content for this message: you're not parsing
> correctly. F.ex. the program fails for rules where there's more than
> one argument for a single option - as is the case for --tcp-flags.
> Similarly, you're not handling the possible ! preceding --syn.

Yep, but being a newbie Perl programmer, I'm not sure where to go next to
parse this stuff correctly. I figured I might peak at the command line
parsing modules and see how they do this. Or look through the iptables
userspace source code to see how it parses this stuff, and try to adapt
it to Perl. That introduces another issue, how to represent the arguments
in the Perl structure. Maybe the value of the hash should be an array
reference, not a single string.

Someone else sent me another test case and it catches a problem with
isolated single quotes in comments (possessives) causing unterminated
strings in the Parse::Word stuff. I need to filter comments before
parsing the lines.

There's also arguments with no options, like -f to catch fragments.

> Visualising the rulesets as a graph still is a good idea; perhaps the
> old-fashioned flow chart would be good here.

Suggestions welcome!

--
Kenneth Porter
http://www.sewingwitch.com/ken/