iptables wishes

iptables wishes

[Joel Newkirk]

I haven't started a new thread here in ages, and this is something I've 
been toying with for a while.  With the recent announcement of a 
feature-freeze on iptables 1.2.8, this seemed a reasonable time to start 
this thread.  (targeting later releases, obviously, and hoping to spark 
some constructive discussion :^)

I was curious to hear what people might have as a 'wishlist' for 
iptables/netfilter capabilities.  Every once in a while something comes 
up here that simply doesn't seem to have a good solution.

My hope is that many of our personal wishes may already be possible, and 
by voicing them someone who has a solution may post it.  And for any 
that don't presently have an answer, perhaps someone will be inspired to 
create one.

Personally I have four:

1 - revamped LOG entry format, especially cleaning up MAC.

2 - completely separate netfilter logging from kernel log streams.  (not 
just redirecting infrequently-used kernel streams, but actual dedicated 
netfilter streams)

3 - Ability to match "original DestinationIP" of a DNATted packet in 
subsequent chains.  Useful with a single physical interface but multiple 
IPs bound to it.

4 - addition of support for a REM field in rules.  Would do nothing 
whatsoever except print the specified REMark text at the end of the rule 
in -L listings.  Something like:
iptables -A INPUT -p tcp --dport 22 -s a.b.c.d -j ACCEPT -REM JoelSSH
So that a -L listing could be easier & quicker to decipher sometimes.  It 
would also allow "iptables -L -v -n | grep Joel" to list only rules, in 
all chains, with "Joel" in the comment.


j

Re: iptables wishes

[Martin Josefsson]

On Tue, 2003-04-01 at 10:41, Joel Newkirk wrote:

> Personally I have four:
> 
> 1 - revamped LOG entry format, especially cleaning up MAC.

see the next remark.

> 2 - completely separate netfilter logging from kernel log streams.  (not 
> just redirecting infrequently-used kernel streams, but actual dedicated 
> netfilter streams)

use ULOG
you can easily modify the format it uses for the logfile.
that part of the source isn't complicated at all.
 
> 3 - Ability to match "original DestinationIP" of a DNATted packet in 
> subsequent chains.  Useful with a single physical interface but multiple 
> IPs bound to it.

Already there, look at the conntrack match (ipt_conntrack)

iptables -A FORWARD -m conntrack --ctorigdst 1.1.1.1 -j ACCEPT

> 4 - addition of support for a REM field in rules.  Would do nothing 
> whatsoever except print the specified REMark text at the end of the rule 
> in -L listings.  Something like:
> iptables -A INPUT -p tcp --dport 22 -s a.b.c.d -j ACCEPT -REM JoelSSH
> So that a -L listing could be easier & quicker to decipher sometimes.  It 
> would also allow "iptables -L -v -n | grep Joel" to list only rules, in 
> all chains, with "Joel" in the comment.

Has been debated frequently, you can probably find some of the
discussions by using google.

-- 
/Martin

Re: iptables wishes

[Joel Newkirk]

On Tuesday 01 April 2003 05:17 am, Martin Josefsson wrote:
> On Tue, 2003-04-01 at 10:41, Joel Newkirk wrote:
> > Personally I have four:
> >
> > 1 - revamped LOG entry format, especially cleaning up MAC.
>
> see the next remark.
>
> > 2 - completely separate netfilter logging from kernel log streams. 
> > (not just redirecting infrequently-used kernel streams, but actual
> > dedicated netfilter streams)
>
> use ULOG
> you can easily modify the format it uses for the logfile.
> that part of the source isn't complicated at all.

Thanks.  Digging further into ULOG is something that's been on my to-do 
list for a while now.  I'm interested in setting up remote logging such 
as is possible with syslog.  If necessity doesn't drive me to it sooner, 
I'll probably attack this in a few months.

> > 3 - Ability to match "original DestinationIP" of a DNATted packet in
> > subsequent chains.  Useful with a single physical interface but
> > multiple IPs bound to it.
>
> Already there, look at the conntrack match (ipt_conntrack)

Wow.  Never found this before, but I see it in the source for the CVS 
version I just downloaded, and after looking again I found it in the 
Netfilter Extensions HowTo.  Thanks!

> iptables -A FORWARD -m conntrack --ctorigdst 1.1.1.1 -j ACCEPT

j

AW: iptables wishes

[Michael Schoen]

Hi Joel,

> 2 - completely separate netfilter logging from kernel log streams.
(not
> just redirecting infrequently-used kernel streams, but actual
dedicated
> netfilter streams)

What about including the ability to do a full datastream logging within
a fixed [rrd-database] size, e.g. the last 50 Kbyte sent through the
netfilter stack, at best also available as an per-connection stream?

Or statistics not only about the amount of connections within the
netfilter at a certain time, but also to build some averages.

Are there already any solutions?

Sincerely

  .\\ichael

AW: iptables wishes

[mailinglists]

> 4 - addition of support for a REM field in rules.  Would do nothing 
> whatsoever except print the specified REMark text at the end 
> of the rule 
> in -L listings.  Something like:
> iptables -A INPUT -p tcp --dport 22 -s a.b.c.d -j ACCEPT -REM JoelSSH
> So that a -L listing could be easier & quicker to decipher 
> sometimes.  It 
> would also allow "iptables -L -v -n | grep Joel" to list only 
> rules, in 
> all chains, with "Joel" in the comment.

Oh yes, that is a good idea. 

two wishes from me:

could it be possible to display the line number of a certain rule in iptables -L -n -v additional to -REM target?
I think this would very much help to find the rules quicker in the iptables scripts when editing with a text editor.

Generally I think this is a problem of too large rule sets. Is there a way to make containers of src/dst addresses? e.g. like this:

container_untrusted_dns="ip.addr.A, ip.addr.B, ip.addr.C"
container_trusted_dns"ip.addr.D, ip.addr.E"

iptables -A FORWARD -p 6 -m state -s $container_trusted_dns --sport 1024: -d $container_untrusted_dns --dport 53 -o $waneth --state NEW,ESTABLISHED -j ACCEPT



Thanks,
Philipp 

Re: AW: iptables wishes

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

* mailinglists (mailinglists@belfin.ch) wrote:
> Generally I think this is a problem of too large rule sets. Is there a way to make containers of src/dst addresses? e.g. like this:
> 
> container_untrusted_dns="ip.addr.A, ip.addr.B, ip.addr.C"
> container_trusted_dns"ip.addr.D, ip.addr.E"
> 
> iptables -A FORWARD -p 6 -m state -s $container_trusted_dns --sport 1024: -d $container_untrusted_dns --dport 53 -o $waneth --state NEW,ESTABLISHED -j ACCEPT

It's overkill for this but you can use ipt_recent for matching on many
disseperate addresses or ippool for faster matching on IP addresses in
small ranges.  ippool in netfilter currently uses a bitfield for it's
IP address storage so you have to specify the range ahead of time and if
the range is very large it takes up gobs of memory.  ipt_recent is meant
for doing matches on recently seen IP addresses but can also be used for
static lists without penalty if you use --rcheck for the check (and not
--update).  ipt_recent is implemented as a hash table and so you can
throw any address you want in it without concern for memory size beyond
the total number of IP addresses you want to be able to store at once
instead of their disparity.  More information on ipt_recent is available
in the netfilter extension FAQ and at the homepage
http://snowman.net/projects/ipt_recent/ .  ippool is documented as part
of netfilter.

	Stephen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]