Re: feature request

Re: feature request

[`VL]

On Apr 8, 2005 4:00 PM, Timothy Earl <mehimx@gmail.com> wrote:
> Hi,
>
> I think to solve your problem you could work around it by using a series of
> awk grep and sed commands along with iptables -vL to test if your rule is
> loaded, presently that is how i get my current ip etc..
>
> man awk, man grep, man sed
>
> for example:
>
> EXTIP="`/sbin/ifconfig ppp0 | grep 'inet adr' | awk '{print $2}' | sed -e
> 's/.*$
>
> Regards,
>
> Tim

I do know that i can work around my problem with thousands of ways =)
. I was surprised that it is impossible with iptables just to test if
rule was loaded, i was sure option existed. One more question i have:
what is the reason to add rules, that already exists in chain more and
more? Why not return failure and say "rule already loaded?" It`s not a
critic, i just want to understand why i can need more than 1 same rule
for 1 chain.

Second, grepping & awking around output of iptables with certain
options doesn`t seem 'reliable' to me. I have to compare string like:

OUTPUT -o eth0 -p tcp -s 192.168.127.29 -d 192.168.127.30 -j ACCEPT
to:
0     0 ACCEPT     tcp  --  *      eth0    192.168.127.29
192.168.127.30

Not impossible, but not very pleasant. The more complex rule i will
have, the more pain. Additional parameters, for example mac addresses,
tcp flags - what will happen to my rule matching, based on shell, if i
add couple of new options to my rule?

So, i`d prefer to write something simular to init scripts, when i have
to remember state of each loaded rule: is it loaded or not. But here
there are other problems: what if i manually add/delete rule? this
should not happen if i have 'my super system', but it`s life... so
again i have to reinvent wheel.

And all of this can be solved by simple( well,i think so =))
modification. We can add -test option or we can return false while
trying to load rule, that already exists in the chain.

Re: feature request

[Taylor, Grant]

> more? Why not return failure and say "rule already loaded?" It`s not a
> critic, i just want to understand why i can need more than 1 same rule
> for 1 chain.

I'm just guessing here but I'd be willing to bet that the actual kernel space of IPTables is more like a database that gets traversed in kernel space.  The iptables command line tool is probably a user land space tool for listing, inserting, updating, and deleting entries in that database.  I'd say that to make things simpler the kernel does not do any checking to make sure that a rule is distinct as there is no harm in having multiple identical rules saver for the fact that it is an additional rule to traverse.  The iptables command line tool was not written to do any checking either as it is not required and this would probably complicate things quite a bit more.

> So, i`d prefer to write something simular to init scripts, when i have
> to remember state of each loaded rule: is it loaded or not. But here
> there are other problems: what if i manually add/delete rule? this
> should not happen if i have 'my super system', but it`s life... so
> again i have to reinvent wheel.

You might try taking a look at iptables-save and iptables-restore respectively.  From the output of iptables-save it looks like all the lines that it generates would go directly after the iptables command.  I.e. if you would normally type:

iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

You would see the following in the iptables-save output:

-A FORWARD -i eth0 -o eth1 -j ACCEPT

I'd be willing to bet that it is easier to parse this output than the normal iptables output for what you are doing.  Take a look at it and see if it will work for you.



Grant. . . .

Re: feature request

[Leonardo Rodrigues Magalhães]

    Guys, how about using the new comment module for making grepping 
easy ???? Instead of grepping the rules parameters, you can include an 
unique ID as a comment in your rule and simply grep for it !!! What do 
you think ??

iptables -I FORWARD -i eth0 -o ppp0 -p tcp -s 12.34.56.78 -d 10.20.30.40 
-m state --state NEW,ESTABLISHED -m time --timestart 08:00 --timestop 
15:45 --days Mon,Wed,Fri -m comment --comment "my_super_crazy_rule" -j 
ACCEPT

[root@correio ~]# iptables -nL FORWARD -v | grep my_super_crazy_rule | wc -l
1
[root@correio ~]# iptables -nL FORWARD -v | grep 
my_nonexistant_super_crazy_rule | wc -l    
0
[root@correio ~]#


    Sincerily,
    Leonardo Rodrigues

Taylor, Grant escreveu:

>> more? Why not return failure and say "rule already loaded?" It`s not a
>> critic, i just want to understand why i can need more than 1 same rule
>> for 1 chain.
>
>
> I'm just guessing here but I'd be willing to bet that the actual 
> kernel space of IPTables is more like a database that gets traversed 
> in kernel space.  The iptables command line tool is probably a user 
> land space tool for listing, inserting, updating, and deleting entries 
> in that database.  I'd say that to make things simpler the kernel does 
> not do any checking to make sure that a rule is distinct as there is 
> no harm in having multiple identical rules saver for the fact that it 
> is an additional rule to traverse.  The iptables command line tool was 
> not written to do any checking either as it is not required and this 
> would probably complicate things quite a bit more.
>
>> So, i`d prefer to write something simular to init scripts, when i have
>> to remember state of each loaded rule: is it loaded or not. But here
>> there are other problems: what if i manually add/delete rule? this
>> should not happen if i have 'my super system', but it`s life... so
>> again i have to reinvent wheel.
>
>
> You might try taking a look at iptables-save and iptables-restore 
> respectively.  From the output of iptables-save it looks like all the 
> lines that it generates would go directly after the iptables command.  
> I.e. if you would normally type:
>
> iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
>
> You would see the following in the iptables-save output:
>
> -A FORWARD -i eth0 -o eth1 -j ACCEPT
>
> I'd be willing to bet that it is easier to parse this output than the 
> normal iptables output for what you are doing.  Take a look at it and 
> see if it will work for you.
>
>
>
> Grant. . . .
>
>

Re: feature request

[Taylor, Grant]

> 
>    Guys, how about using the new comment module for making grepping easy 
> ???? Instead of grepping the rules parameters, you can include an unique 
> ID as a comment in your rule and simply grep for it !!! What do you 
> think ??

I've considered doing that my self for other projects.  But seeing as how I did not have any real solution / method for doing so already I did not want to propose it yet.  I'm thinking of using it for more of a ""system that would manage all your rules, not unlike SysV Init scripts, for you.  You would then go through that interface and work with iptables.  I know that what ever I end up coming up with I'll end up using some sort of numeric identifiers for the rules to be matched against so it is easier to machine parse.  I'll probably end up using a comment of something like this ':<numeric ID>:<free text comment>'.  This way the machine parseable identifier is there in the form of ':<numeric ID>:' where it will be easy to find on the line.  The <numeric ID> will be at the start of the comments and starting at about the same column on screen while still allowing for free text comments (
 or as free as comment will allow it's self, just a bit shorter) thus making it easier to 
search for a specific <numeric ID> visually, vs having it at the end of the comment which would make location of the <numeric ID> of the rule depend on the length of the free text.  Seeing as how comment is a relatively new match extension and not all systems have it in the kernel this system would be valid for new and patched kernels only.  Where as something that would parse the output of iptables(|-save) would be more backwards compatible.

I personally am EXTENSIVELY using the comment match extension, as well as planing on using TARPIT targets (that is a sticky subject un to it's self.  Pun intended.  :P  )



Grant. . . .