AW: iptables wishes

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

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

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

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

[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