1

I'm looking for a program that takes the output of iptables -S and converts it to a breadth-first listing.

Why? I'm doing some work on a router using VyOS where several layers of tables are pre-installed, so it is difficult to trace back all the rules connect to INPUT, FORWARD, and OUTPUT.


As per @JeffSchaller 's [request], here is sample output that needs to be parsed:

$ sudo iptables -S 
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N LAN1_IN
-N MINIUPNPD
-N UBNT_FW_IN_SUSPEND_HOOK
-N UBNT_PFOR_FW_HOOK
-N UBNT_PFOR_FW_RULES
-N UBNT_VPN_IPSEC_FW_HOOK
-N UBNT_VPN_IPSEC_FW_IN_HOOK
-N VYATTA_FW_IN_HOOK
-N VYATTA_FW_LOCAL_HOOK
-N VYATTA_FW_OUT_HOOK
-N VYATTA_POST_FW_FWD_HOOK
-N VYATTA_POST_FW_IN_HOOK
-N VYATTA_POST_FW_OUT_HOOK
-N WAN_IN
-N WAN_LOCAL
-N WAN_OUT
-A INPUT -j UBNT_VPN_IPSEC_FW_HOOK
-A INPUT -j VYATTA_FW_LOCAL_HOOK
-A INPUT -j VYATTA_POST_FW_IN_HOOK
-A FORWARD -j MINIUPNPD
-A FORWARD -j UBNT_VPN_IPSEC_FW_IN_HOOK
-A FORWARD -j UBNT_PFOR_FW_HOOK
-A FORWARD -j UBNT_FW_IN_SUSPEND_HOOK
-A FORWARD -j VYATTA_FW_IN_HOOK
-A FORWARD -j VYATTA_FW_OUT_HOOK
-A FORWARD -j VYATTA_POST_FW_FWD_HOOK
-A OUTPUT -j VYATTA_POST_FW_OUT_HOOK
-A LAN1_IN -m comment --comment LAN1_IN-10 -m state --state INVALID -j LOG --log-prefix "[LAN1_IN-10-D]"
-A LAN1_IN -m comment --comment LAN1_IN-10 -m state --state INVALID -j DROP
-A LAN1_IN -p udp -m comment --comment LAN1_IN-20 -m udp --dport 53 -m set --match-set dnsaddr dst -j RETURN
-A LAN1_IN -p udp -m comment --comment LAN1_IN-30 -m set --match-set dnsaddr src -m udp --dport 53 -j RETURN
-A LAN1_IN -m comment --comment LAN1_IN-60 -m state --state NEW -j RETURN
-A LAN1_IN -m comment --comment LAN1_IN-70 -m state --state RELATED -j RETURN
-A LAN1_IN -m comment --comment LAN1_IN-80 -m state --state ESTABLISHED -j RETURN
-A LAN1_IN -m comment --comment "LAN1_IN-10000 default-action drop" -j LOG --log-prefix "[LAN1_IN-default-D]"
-A LAN1_IN -m comment --comment "LAN1_IN-10000 default-action drop" -j DROP
-A VYATTA_FW_IN_HOOK -i eth0 -j WAN_IN
-A VYATTA_FW_IN_HOOK -i eth1 -j LAN1_IN
-A VYATTA_FW_LOCAL_HOOK -i eth0 -j WAN_LOCAL
-A VYATTA_FW_OUT_HOOK -o eth0 -j WAN_OUT
-A VYATTA_POST_FW_FWD_HOOK -j ACCEPT
-A VYATTA_POST_FW_IN_HOOK -j ACCEPT
-A VYATTA_POST_FW_OUT_HOOK -j ACCEPT
-A WAN_IN -m comment --comment WAN_IN-10 -m state --state ESTABLISHED -j RETURN
-A WAN_IN -m comment --comment WAN_IN-20 -m state --state RELATED -j RETURN
-A WAN_IN -m comment --comment WAN_IN-30 -m state --state INVALID -j LOG --log-prefix "[WAN_IN-30-D]"
-A WAN_IN -m comment --comment WAN_IN-30 -m state --state INVALID -j DROP
-A WAN_IN -m comment --comment "WAN_IN-10000 default-action drop" -j DROP
-A WAN_LOCAL -m comment --comment WAN_LOCAL-10 -m state --state ESTABLISHED -j RETURN
-A WAN_LOCAL -m comment --comment WAN_LOCAL-20 -m state --state RELATED -j RETURN
-A WAN_LOCAL -m comment --comment WAN_LOCAL-30 -m state --state INVALID -j LOG --log-prefix "[WAN_LOCAL-30-D]"
-A WAN_LOCAL -m comment --comment WAN_LOCAL-30 -m state --state INVALID -j DROP
-A WAN_LOCAL -m comment --comment "WAN_LOCAL-10000 default-action drop" -j LOG --log-prefix "[WAN_LOCAL-default-D]"
-A WAN_LOCAL -m comment --comment "WAN_LOCAL-10000 default-action drop" -j DROP
-A WAN_OUT -m comment --comment WAN_OUT-10 -m state --state NEW -j RETURN
-A WAN_OUT -m comment --comment WAN_OUT-20 -m state --state RELATED -j RETURN
-A WAN_OUT -m comment --comment WAN_OUT-30 -m state --state ESTABLISHED -j RETURN
-A WAN_OUT -m comment --comment WAN_OUT-40 -m state --state INVALID -j LOG --log-prefix "[WAN_OUT-40-D]"
-A WAN_OUT -m comment --comment WAN_OUT-40 -m state --state INVALID -j DROP
-A WAN_OUT -m comment --comment "WAN_OUT-10000 default-action drop" -j LOG --log-prefix "[WAN_OUT-default-D]"
-A WAN_OUT -m comment --comment "WAN_OUT-10000 default-action drop" -j DROP


I am selecting @LL3 's answer as correct, first past the post. @LL3 's answer has since been modified to be able to read stdin so I remove the patch doing same

<patch removed>

Kudos to perl-master @JeffSchaller 's (slightly later) complete answer showing both a breadth-first listing and separately a graphviz output.

  • 1
    How would some sort of graphviz diagram strike you? – Jeff Schaller Apr 4 at 1:36
  • 1
    If you can post (sanitized if necessary) iptables -S output for Answerers to work with, that'd be great! The more complex, the better! – Jeff Schaller Apr 4 at 1:53
  • @JeffSchaller - That's very interesting and useful information. For this task I think that would be useful for visualizing the jump statements and table names (although not all of the other rules and conditions). – Craig Hicks Apr 4 at 8:08
  • @JeffSchaller - I placed sample output in the question. Thanks's for your interest. – Craig Hicks Apr 4 at 8:15
  • 1
    Do you have any feedback on the layout of this sample image? – Jeff Schaller Apr 4 at 10:06
1

Some time ago I needed to flatten breadth-first the tree of rules of a custom firewall and have them all out on a file. Not VyOS but iptables anyway. I came up with the following script, see if it helps you.

Please note that this script requires at least Bash v4

#!/bin/bash -

declare -A all_chains=()
declare -A queued_chains=()

builtin_chains_as_regexp='INPUT|OUTPUT|FORWARD|PREROUTING|POSTROUTING'
queue_list=""
prepend_chain=""
show_chain_heading=false
one_go=false
uniquify=true

_print_usage() {
   cat <<- EOF
        Usage: $0 [-npofh] <starting-chain>

        -n    shows chain's creation command as heading, useful for spotting empty chains
        -p    prepends chain's name to each rule
        -o    read everything in one go, 10x quicker when many small chains
        -f    expand all references to a same chain, but beware of chain loops or chains referenced hundreds of times
        -h    shows this help
EOF
}

_expand_chain() {
    local chain_to_expand="${1}"

    local rules=""
    # if one_go selected, work with in-memory cache of chains
    if $one_go ; then
        rules="${all_chains[${chain_to_expand}]}"
    # otherwise read in chain to consider
    else
        rules="$(iptables -S "${chain_to_expand}")"
    fi

    $show_chain_heading && \
        ! [[ "${chain_to_expand}" =~ ${builtin_chains_as_regexp} ]] && \
        echo "-N ${chain_to_expand}"
    while read -r cmd chain rule ; do
        case "${cmd}" in
        -A)
            set -- ${rule}
            # look for target option in rule
            while [ -n "${1}" ] && ! [[ "${1}" =~ -(j|g) ]] ; do shift ; done
            # a few sanity checks
            [ -n "${1}" ] || continue # a rule with no target, skip it
            shift
            [ -n "${1}" ] || { echo "what!? empty target in ${rule}" >&2 ; continue ; }
            if [ -n "${all_chains[${1}]}" ] ; then
                # if target is a chain
                # add to queued chains if uniquify *not* requested or if chain never queued
                if ! $uniquify || [ -z "${queued_chains[${1}]}" ] ; then
                    queue_list+="${1} "
                    queued_chains[${1}]="1"
                fi
            fi
            # show rule
            echo "${prepend_chain:+[${chain_to_expand}] }${cmd} ${chain} ${rule}"
        ;;
        esac
    done <<<"${rules}"
}

###
# ACTUAL EXECUTION STARTS HERE
#

# parse command options if any
while getopts nphfo option ; do
    case $option in
    n) show_chain_heading=true
    ;;
    p) prepend_chain="1"
    ;;
    h) _print_usage ; exit 0
    ;;
    o) one_go=true
    ;;
    f) uniquify=false
    ;;
    '?') exit 1
    ;;
    esac
done

[ -n "${!OPTIND}" ] || { _print_usage ; exit 1 ; }

# preparation step:
# if one_go selected, slurp everything in
if $one_go ; then
    # invoke explicit command only when stdin is the terminal
    [ -t 0 ] && exec 0< <(iptables -S)
    while read -r cmd chain rule ; do
        case "${cmd}" in
        -N)
            all_chains[${chain}]=" " # <<-- whitespace to make provision for empty chains
        ;;
        -A)
            # assign rule to its chain in cache
            all_chains[${chain}]+=$'\n'"${cmd} ${chain} ${rule}"
        ;;
        esac
    done
# otherwise read in chain names only
else
    while IFS= read -r chain ; do
        all_chains[${chain}]="1"
    done < <(iptables -S | sed -ne '/^-N /s///p')
fi

# expand starting chain
_expand_chain ${!OPTIND}

# breadth-first expand queued chains
# as long as queue is not empty
while [ "${#queue_list}" -gt 0 ] ; do
    # take next queued chain
    subchain="${queue_list%% *}"
    # expand it
    _expand_chain "${subchain}"
    # remove expanded chain from queue
    queue_list="${queue_list#${subchain} }"
    # queue gets updated by _expand_chain as needed
done

exit 0

Not very commented admittedly, but it shouldn’t be that tough to follow if you are familiar with Bash.

If you run it with no options it will show a help summary.

Note particularly that by default it expands each chain only once, even for chains that are referenced multiple times. You can request for a truly all-flattened output with -f option. I made it like that because I had a couple of chains referenced by thousands of other chains, and flattening all that would have taken hours (this script does not do parallel processing, of course). So keep that in mind if you have similar setups.

  • I've selected your answer, and provided a pacth to enable the script from stdin. That was necessary because bash4 is not available on the machine whose rules I am analyzing. (See edited question). – Craig Hicks Apr 4 at 22:15
  • @CraigHicks that’s nice thank you! But I’m afraid reading from stdin won’t save you from requiring v4. The script uses associative arrays. See the “declare -A” instructions at the beginning. Those are available in v4+ only, and I used them precisely for the one_go option. I probably can replace them with some other idiom but it will likely lose much of the speed gain. What Bash version are you using? Could you possibly dump your rules to a file and feed it to the script on a system that has Bash v4 ? – LL3 Apr 5 at 0:57
  • Exactly, I copied the output over from the router to my work platform and then piped it: e.g., cat iptables-S.txt | flatten.sh -inf INPUT. The -i option for reading stdin was added to make that possible. – Craig Hicks Apr 5 at 4:59
  • 1
    @CraigHicks Good, happy that helped. I’ve updated my script to make it read from stdin when doing “one_go” (-o option) processing. Only, I made it without duplicating the reading code block ;-) Also my updated script will automatically switch to stdin input when it detects a non-terminal stdin, so an additional option is not needed. I might edit your OP myself with this patch if it’s ok for you. Else I could just edit my own answer with the updated script but then your OP would be inconsistent.. Don’t know what the best approach is here on StackExchange.. – LL3 Apr 5 at 11:20
  • Yes, please go ahead and edit the answer to reflect your better patch. I will approve it the systems asks me. – Craig Hicks Apr 5 at 20:55
1

Here's my interpretation of a BFS sort on iptables -S output; it reads in each rule and finds the target (or -P policy); once all the rules have been read in, it starts with the built-in targets and prints successive levels of rules.

iptables-bfs.pl

#!/usr/bin/perl -w
use strict;

# for now, a chain name has to match regex: [[:alnum:]_-]+

my %jumpsto = ();

while (<>) {
  chomp;
  next if /^#/;
  if (/-[AIR]\s+([[:alnum:]_-]+).*-j\s+([[:alnum:]_-]+)/) {
        unless (exists $jumpsto{$1}{$2}) {
                $jumpsto{$1}{$2}=$_;
        }
  } elsif (/-P ([[:alnum:]_-]+)\s+(ACCEPT|DROP)/) {
        unless (exists $jumpsto{$1}{$2}) {
                $jumpsto{$1}{$2}=$_;
        }
  }
}

my @queue = ();
push @queue, qw(INPUT OUTPUT FORWARD PREROUTING POSTROUTING);
my @nextqueue = ();
while (@queue) {
  my $item = shift @queue;
  foreach my $target (keys %{ $jumpsto{$item} }) {
    print $jumpsto{$item}{$target} . "\n";
    push @nextqueue, $target;
  }
  if (! @queue && @nextqueue) {
    @queue = @nextqueue;
    @nextqueue = ();
    print "---------------\n";
  }
}

On the sample input in the question, the output is:

-A INPUT -j UBNT_VPN_IPSEC_FW_HOOK
-P INPUT ACCEPT
-A INPUT -j VYATTA_POST_FW_IN_HOOK
-A INPUT -j VYATTA_FW_LOCAL_HOOK
-P OUTPUT ACCEPT
-A OUTPUT -j VYATTA_POST_FW_OUT_HOOK
-A FORWARD -j VYATTA_FW_IN_HOOK
-A FORWARD -j MINIUPNPD
-P FORWARD ACCEPT
-A FORWARD -j VYATTA_POST_FW_FWD_HOOK
-A FORWARD -j UBNT_VPN_IPSEC_FW_IN_HOOK
-A FORWARD -j UBNT_FW_IN_SUSPEND_HOOK
-A FORWARD -j UBNT_PFOR_FW_HOOK
-A FORWARD -j VYATTA_FW_OUT_HOOK
---------------
-A VYATTA_POST_FW_IN_HOOK -j ACCEPT
-A VYATTA_FW_LOCAL_HOOK -i eth0 -j WAN_LOCAL
-A VYATTA_POST_FW_OUT_HOOK -j ACCEPT
-A VYATTA_FW_IN_HOOK -i eth1 -j LAN1_IN
-A VYATTA_FW_IN_HOOK -i eth0 -j WAN_IN
-A VYATTA_POST_FW_FWD_HOOK -j ACCEPT
-A VYATTA_FW_OUT_HOOK -o eth0 -j WAN_OUT
---------------
-A WAN_LOCAL -m comment --comment WAN_LOCAL-30 -m state --state INVALID -j DROP
-A WAN_LOCAL -m comment --comment WAN_LOCAL-10 -m state --state ESTABLISHED -j RETURN
-A WAN_LOCAL -m comment --comment WAN_LOCAL-30 -m state --state INVALID -j LOG --log-prefix "[WAN_LOCAL-30-D]"
-A LAN1_IN -p udp -m comment --comment LAN1_IN-20 -m udp --dport 53 -m set --match-set dnsaddr dst -j RETURN
-A LAN1_IN -m comment --comment LAN1_IN-10 -m state --state INVALID -j DROP
-A LAN1_IN -m comment --comment LAN1_IN-10 -m state --state INVALID -j LOG --log-prefix "[LAN1_IN-10-D]"
-A WAN_IN -m comment --comment WAN_IN-30 -m state --state INVALID -j DROP
-A WAN_IN -m comment --comment WAN_IN-10 -m state --state ESTABLISHED -j RETURN
-A WAN_IN -m comment --comment WAN_IN-30 -m state --state INVALID -j LOG --log-prefix "[WAN_IN-30-D]"
-A WAN_OUT -m comment --comment WAN_OUT-40 -m state --state INVALID -j DROP
-A WAN_OUT -m comment --comment WAN_OUT-10 -m state --state NEW -j RETURN
-A WAN_OUT -m comment --comment WAN_OUT-40 -m state --state INVALID -j LOG --log-prefix "[WAN_OUT-40-D]"
---------------

My original misinterpretation was the following perl script, which converts the iptables -S into graphviz-compatible file. It creates a graph that links the source chains with their target chains.

iptables-dot.pl

#!/usr/bin/perl -w
use strict;

# for now, a chain name has to match regex: [[:alnum:]_-]+

print "digraph rules {\n";
print "\toverlap=scalexy;\n";

my %jumpsto = ();

while (<>) {
  chomp;
  next if /^#/;
  if (/-[AIR]\s+([[:alnum:]_-]+).*-j\s+([[:alnum:]_-]+)/) {
        unless (exists $jumpsto{$1}{$2}) {
                print "\"$1\" -> \"$2\";\n";
                $jumpsto{$1}{$2}=1;
        }
  } elsif (/-P ([[:alnum:]_-]+)\s+(ACCEPT|DROP)/) {
        unless (exists $jumpsto{$1}{$2}) {
                print "\"$1\" -> \"$2\";\n";
                $jumpsto{$1}{$2}=1;
        }
  }
}

print "}\n";

Given the sample input in the question, the resulting output is:

digraph rules {
        overlap=scalexy;
"INPUT" -> "ACCEPT";
"FORWARD" -> "ACCEPT";
"OUTPUT" -> "ACCEPT";
"INPUT" -> "UBNT_VPN_IPSEC_FW_HOOK";
"INPUT" -> "VYATTA_FW_LOCAL_HOOK";
"INPUT" -> "VYATTA_POST_FW_IN_HOOK";
"FORWARD" -> "MINIUPNPD";
"FORWARD" -> "UBNT_VPN_IPSEC_FW_IN_HOOK";
"FORWARD" -> "UBNT_PFOR_FW_HOOK";
"FORWARD" -> "UBNT_FW_IN_SUSPEND_HOOK";
"FORWARD" -> "VYATTA_FW_IN_HOOK";
"FORWARD" -> "VYATTA_FW_OUT_HOOK";
"FORWARD" -> "VYATTA_POST_FW_FWD_HOOK";
"OUTPUT" -> "VYATTA_POST_FW_OUT_HOOK";
"LAN1_IN" -> "LOG";
"LAN1_IN" -> "DROP";
"LAN1_IN" -> "RETURN";
"VYATTA_FW_IN_HOOK" -> "WAN_IN";
"VYATTA_FW_IN_HOOK" -> "LAN1_IN";
"VYATTA_FW_LOCAL_HOOK" -> "WAN_LOCAL";
"VYATTA_FW_OUT_HOOK" -> "WAN_OUT";
"VYATTA_POST_FW_FWD_HOOK" -> "ACCEPT";
"VYATTA_POST_FW_IN_HOOK" -> "ACCEPT";
"VYATTA_POST_FW_OUT_HOOK" -> "ACCEPT";
"WAN_IN" -> "RETURN";
"WAN_IN" -> "LOG";
"WAN_IN" -> "DROP";
"WAN_LOCAL" -> "RETURN";
"WAN_LOCAL" -> "LOG";
"WAN_LOCAL" -> "DROP";
"WAN_OUT" -> "RETURN";
"WAN_OUT" -> "LOG";
"WAN_OUT" -> "DROP";
}

... which results in the following graphic. Click once for a larger version; click again if your browser autoscales it down.

iptables chain targets

  • Very tight and elegant code. The inclusion of policy in the breadth-first listing is a plus, the dashed lines add clarity. Your original interpretation, offering the graphviz, reflects lateral thinking about what arguably (and also subjectively) would have been a better question. – Craig Hicks Apr 5 at 21:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.