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

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: iptables wishes

[Michael Klinteberg]

---------- Original Message ----------------------------------
From: Joel Newkirk <netfilter@newkirk.us>
Reply-To: netfilter@newkirk.us
Date: Tue, 1 Apr 2003 03:41:48 -0500

>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.
I also want this feature.

>
>2 - completely separate netfilter logging from kernel log
streams.  (not
>just redirecting infrequently-used kernel streams, but actual
dedicated
>netfilter streams)
Ohh yes!!! This is also "a must have". An extended to this yould
be to log to diffrent files for diffrent rules. Something like
iptables -A INPUT -s bad.host.net --log-
file /var/log/netfilter/bad.hosts -j LOG

>
>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.
This is also god :-)


Another thing to the wishlist (for me, that is)
When listing(-L) with verbose (-v) I wish to remove some fileds.
Today I must use the awk command to do this. Resulting in very
long command.
Something like:
iptables -L -v -opt -source +REM
would remove the opt and source fields and; add the REM field if
not default when listing with verbose.
>
>
>j
>
/Klintan

________________________________________________________________
Sent med Stib Webmail, en tjänst på klintan.se

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: 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 --]

iptable / packet flow

[Scott MacKay]

I think someone pointed to a good graphical site
depicting the flow of a packet and where iptable rules
are applied.  Would anyone know where that is?

-Scott

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com

Re: iptable / packet flow

[Scott MacKay]

Nm...just saw the email with the frozentux tutorial...


-Scott

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com

Re: iptables wishes

[Joel Newkirk]

On Tuesday 01 April 2003 04:58 am, Michael Klinteberg wrote:
> ---------- Original Message ----------------------------------
> From: Joel Newkirk <netfilter@newkirk.us>
> Reply-To: netfilter@newkirk.us
> Date: Tue, 1 Apr 2003 03:41:48 -0500

> >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

> >2 - completely separate netfilter logging from kernel log
> > streams.  (not
> >just redirecting infrequently-used kernel streams, but actual
> >dedicated netfilter streams)
>
> Ohh yes!!! This is also "a must have". An extended to this yould
> be to log to diffrent files for diffrent rules. Something like
> iptables -A INPUT -s bad.host.net --log-
> file /var/log/netfilter/bad.hosts -j LOG

That can be 'fudged' right now by using --log-level debug and --log-level 
notice, for instance, then redirecting kern.=debug to one file and 
kern.=notice to another from /etc/syslog.conf.  Both streams usually 
have very little traffic.

j

Re: iptables wishes

[Ivano Proietti Mucci]

like most peaple, i have a gateway to internet, and the thing is: how to
limit bandwidth per internal-ip?

thanks,
Ivano

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

Re: iptables wishes

[Joel Newkirk]

On Tuesday 01 April 2003 09:32 am, Ivano Proietti Mucci wrote:
> like most peaple, i have a gateway to internet, and the thing is: how
> to limit bandwidth per internal-ip?
>
> thanks,
> Ivano

This can be achieved with advanced routing.  The LARTC HowTo has some 
sections relating to this at:
http://lartc.org/howto/lartc.cookbook.html

If the bandwidth allocation policy is strictly IP-based then the solution 
is routing.  If the policy depends on connection type as well (IE, bulk 
transfers like P2P prioritized lower than interactive connections) then 
the solution incorporates the TOS or MARK targets in iptables, in the 
mangle-PREROUTING and mangle-OUTPUT chains.

Very powerful stuff, but I've yet to find a how-to on it that is both 
clear AND thorough.  (with a subject so complex, that combination is 
extremely difficult to achieve...)

j

RE: iptables wishes

[Alex McCubbin]

My wish would be for the --proto to allow for multiple protocols being set
at the same time.

As an example...

$IPTABLES --table filter --append log_and_drop --proto ! tcp,udp,icmp --jump
LOG --log-level 5 --log-prefix "OTHER Drop "

I want to log explicitly log tcp, udp and icmp as specific logs and then
catch all others with a different log message hence the OTHER log command
you see above.  I can think of other situations as well...

Maybe this has already been addressed since I last brought it up last
September and I missed it, but I don't think so...

Cheers, Alex.

-----Original Message-----
From: Joel Newkirk [mailto:netfilter@newkirk.us] 
Sent: Tuesday, April 01, 2003 12:42 AM
To: netfilter@lists.netfilter.org
Subject: iptables wishes


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