limit extension

limit extension

[Michael Schachtebeck]

Hi,

I'm trying to redirect some people on my router once a day to a local
apache to show them a status page.

I'm using the following iptables rule to redirect them:

/sbin/iptables -t nat -I PREROUTING -p tcp -s $IP -i $LAN_DEV --sport
1024: --dport 80 --syn -m limit --limit 1/d --limit-burst 1 -j REDIRECT
--to-port 5000

At first, I thought everything was fine: I got redirected when trying to
open the first page in my browser, and after that, I could surf normally
without being redirect. But after about 30 minutes, I got redirected
again, and iptables -t nat -vnL PREROUTING said that the rule had
matched twice.

What am I doing wrong? Why was I redirect a second time? In my opinion,
the second redirection should not have happened then, but 1 day (24
hours) later...

Any hint is welcome...

Michael.
-- 
PGP Public Key:  http://www.num.math.uni-goettingen.de/schachte/key.asc
Key fingerprint: C474 8B85 17C0 0232 E439 0FBF 2451 E452 293C D798

Re: limit extension

[Jan Engelhardt]

>I'm using the following iptables rule to redirect them:
>
>/sbin/iptables -t nat -I PREROUTING -p tcp -s $IP -i $LAN_DEV --sport
>1024: --dport 80 --syn -m limit --limit 1/d --limit-burst 1 -j REDIRECT
>--to-port 5000

You could use dstlimit with --dstlimit-mode srcip-dstip
and probably save some rules.

With dstlimit, you also get an overview of which connections are currently 
limited, and their burst status, in /proc/net/ipt_dstlimit/DSTLIMIT_NAME
It's because I think some burst math allows to have a second packet sneak in.

>What am I doing wrong? Why was I redirect a second time? In my opinion,
>the second redirection should not have happened then, but 1 day (24
>hours) later...



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: limit extension

[Michael Schachtebeck]

Hi.

Am 07/19/2005 10:13 PM schrieb Jan Engelhardt:

> You could use dstlimit with --dstlimit-mode srcip-dstip
> and probably save some rules.
> 
> With dstlimit, you also get an overview of which connections are currently 
> limited, and their burst status, in /proc/net/ipt_dstlimit/DSTLIMIT_NAME
> It's because I think some burst math allows to have a second packet sneak in.

Won't I have the same problem with it?

According to

http://www.netfilter.org/patch-o-matic/pom-obsolete.html#pom-obsolete-dstlimit,

it's deprecated by hashlimit, but on

http://www.netfilter.org/patch-o-matic/pom-submitted.html#pom-submitted-hashlimit,

I can't find any information on how to use it in my case... Do you know
where to look for it or do you have an example for how to redirect a
single host or a bunch of hosts once a day to the local apache when
trying to make their first http connection, similar to

/sbin/iptables -t nat -I PREROUTING -p tcp -s $IP -i $LAN_DEV --sport
1024: --dport 80 --syn -m limit --limit 1/d --limit-burst 1 -j REDIRECT
--to-port 5000

Michael
-- 
PGP Public Key:  http://www.num.math.uni-goettingen.de/schachte/key.asc
Key fingerprint: C474 8B85 17C0 0232 E439 0FBF 2451 E452 293C D798

Re: limit extension

[Jan Engelhardt]

>> You could use dstlimit with --dstlimit-mode srcip-dstip
>> and probably save some rules.
>> 
>> With dstlimit, you also get an overview of which connections are currently 
>> limited, and their burst status, in /proc/net/ipt_dstlimit/DSTLIMIT_NAME
>> It's because I think some burst math allows to have a second packet sneak in.
>
>Won't I have the same problem with it?

Probably, but it helps to diagnose the problem thanks procfs.

>http://www.netfilter.org/patch-o-matic/pom-obsolete.html#pom-obsolete-dstlimit,
>it's deprecated by hashlimit, but on

According to the hashlimit POMng help file and netfilter website

|The idea is to have something like 'limit', but either per 
|destination-ip or per (destip,destport) tuple.

it does not look like it can handle (srcip,dstip) tuples. Though, the codebase 
has flags for SIP, SPT, DIP and DPT, so I guess it maybe can. Someone 
enlighten me?

>/sbin/iptables -t nat -I PREROUTING -p tcp -s $IP -i $LAN_DEV --sport
>1024: --dport 80 --syn -m limit --limit 1/d --limit-burst 1 -j REDIRECT
>--to-port 5000

-m dstlimit --dstlimit 1/d --dstlimit-burst 1
  --dstlimit-mode srcip-dstip --dstlimit-name trafficcontrol



Jan Engelhardt
-- 

Re: limit extension

[Michael Schachtebeck]

Am 07/19/2005 08:07 PM schrieb Michael Schachtebeck:

> /sbin/iptables -t nat -I PREROUTING -p tcp -s $IP -i $LAN_DEV --sport
> 1024: --dport 80 --syn -m limit --limit 1/d --limit-burst 1 -j REDIRECT
> --to-port 5000
> 
> At first, I thought everything was fine: I got redirected when trying to
> open the first page in my browser, and after that, I could surf normally
> without being redirect. But after about 30 minutes, I got redirected
> again, and iptables -t nat -vnL PREROUTING said that the rule had
> matched twice.

As I could not test the rules that Jan has suggested in his answer to my
postings (it's a production machine and I couldn't reboot it with a
patched kernel so far), I did some more testing and discovered a very
strange behaviour which I believe to be indeed a bug:

- I added the above rule to the firewall, got redirected exactly once,
  and could surf the web for about 40 minutes without being redirected
  again.
- A cron job deleted some rules from the PREROUTING chain and added
  some new rules to the PREROUTING chain.
- I got redirected again (exactly once), directly after the cron job had
  modified the PREROUTING chain.
- I could surf the web for exactly 60 minutes without being redirected
  again.
- The cron job ran again.
- I got redirected again (exactly once), directly after the cron job had
  modified the PREROUTING chain.
- I ran the cron job manually.
- I got redirected again (exactly once) and could surf the web normally
  after that.
- I ran the cron job manually again.
- I got redirected again (exactly once).
- ... (I repeated it some times, same result)
- I could surf the web for about one hour without being redirected,
  until... you guess it, until the cron job ran again and modified the
  PREROUTING chain.

The cron job did not touch the rule above I am using to do the
redirection, it only deleted some other rules in the PREROUTING chain
and added some new rules to the PREROUTING chain.

So this seems to be a bug in the kernel's iptables implementation, right?

I'm using a 2.6.12.2 vanilla kernel and iptables 1.2.11 (gentoo package
net-firewall/iptables-1.2.11-r3).

Cheers,

Michael.
-- 
PGP Public Key:  http://www.num.math.uni-goettingen.de/schachte/key.asc
Key fingerprint: C474 8B85 17C0 0232 E439 0FBF 2451 E452 293C D798

Re: limit extension

[Sven Schuster]

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


Hi Michael,

On Wed, Jul 20, 2005 at 04:15:44PM +0200, Michael Schachtebeck told us:
> As I could not test the rules that Jan has suggested in his answer to my
> postings (it's a production machine and I couldn't reboot it with a
> patched kernel so far), I did some more testing and discovered a very
> strange behaviour which I believe to be indeed a bug:
> 

... <testing snipped>

> 
> So this seems to be a bug in the kernel's iptables implementation, right?

I think this is "expected behaviour" and it behaves like that
because of the implentation of netfilter.

AFAIK, when you add, delete, replace a iptables rule, at first the
current rules are "downloaded" from kernel, the changes are made in
user space, then the ruleset is "uploaded" again to the kernel.
When uploading, I think that all the internal data structures for the
matches are deleted and then allocated freshly. That's why you see
this behaviour in your testing. When your cronjob runs (or you run
it manually) all the data structures get deleted and newly allocated,
thus the limit rule matches again.

Of course, anybody feel free to correct me if I'm wrong :-)


Regards,

Sven

> 
> I'm using a 2.6.12.2 vanilla kernel and iptables 1.2.11 (gentoo package
> net-firewall/iptables-1.2.11-r3).
> 
> Cheers,
> 
> Michael.

-- 
Linux zion 2.6.13-rc3-mm1 #6 PREEMPT Mon Jul 18 19:42:52 CEST 2005 i686 athlon i386 GNU/Linux
 16:40:37 up 1 day, 20:53,  1 user,  load average: 0.04, 0.01, 0.00

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

Re: limit extension

[Michael Schachtebeck]

Am 07/20/2005 04:45 PM schrieb Sven Schuster:

> AFAIK, when you add, delete, replace a iptables rule, at first the
> current rules are "downloaded" from kernel, the changes are made in
> user space, then the ruleset is "uploaded" again to the kernel.
> When uploading, I think that all the internal data structures for the
> matches are deleted and then allocated freshly. That's why you see
> this behaviour in your testing. When your cronjob runs (or you run
> it manually) all the data structures get deleted and newly allocated,
> thus the limit rule matches again.

But on the other hand, the counter correctly shows the number of packets
that matched the rule; iptables -t nat -vnL PREROUTING says:

9 540 REDIRECT tcp -- eth1 * 10.10.10.69 0.0.0.0/0 tcp spts:1024:65535
dpt:80 flags:0x16/0x02 limit: avg 1/day burst 1 redir ports 5000

So it would be very strange if the rules were extracted to user space,
rewritten/modified, "uploaded" to the kernel with the correct counters
for the remaining rules, and then, the rules do not look to this
counters. ;-)

Why then save and restore the counters, if they are not used by the rules?

Michael.
-- 
PGP Public Key:  http://www.num.math.uni-goettingen.de/schachte/key.asc
Key fingerprint: C474 8B85 17C0 0232 E439 0FBF 2451 E452 293C D798

Re: limit extension

[Sven Schuster]

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


sorry got the list wrong, this was intended for the netfilter mailing
list... :-(


Sven

On Wed, Jul 20, 2005 at 04:45:31PM +0200, Sven Schuster told us:
> ...


-- 
Linux zion 2.6.13-rc3-mm1 #6 PREEMPT Mon Jul 18 19:42:52 CEST 2005 i686 athlon i386 GNU/Linux
 16:56:44 up 1 day, 21:09,  1 user,  load average: 0.00, 0.03, 0.01

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

Re: limit extension

[Sven Schuster]

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


Hi Michael,

On Wed, Jul 20, 2005 at 04:15:44PM +0200, Michael Schachtebeck told us:
> As I could not test the rules that Jan has suggested in his answer to my
> postings (it's a production machine and I couldn't reboot it with a
> patched kernel so far), I did some more testing and discovered a very
> strange behaviour which I believe to be indeed a bug:

... <testing snipped>

> So this seems to be a bug in the kernel's iptables implementation, right?

I think this is "expected behaviour" and it behaves like that
because of the implentation of netfilter.

AFAIK, when you add, delete, replace a iptables rule, at first the
current rules are "downloaded" from kernel, the changes are made in
user space, then the ruleset is "uploaded" again to the kernel.
When uploading, I think that all the internal data structures for the
matches are deleted and then allocated freshly. That's why you see
this behaviour in your testing. When your cronjob runs (or you run
it manually) all the data structures get deleted and newly allocated,
thus the limit rule matches again.

Of course, anybody feel free to correct me if I'm wrong :-)


Regards,

Sven

> 
> I'm using a 2.6.12.2 vanilla kernel and iptables 1.2.11 (gentoo package
> net-firewall/iptables-1.2.11-r3).
> 
> Cheers,
> 
> Michael.

-- 
Linux zion 2.6.13-rc3-mm1 #6 PREEMPT Mon Jul 18 19:42:52 CEST 2005 i686 athlon i386 GNU/Linux
 16:59:48 up 1 day, 21:12,  1 user,  load average: 0.49, 0.21, 0.07

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

Re: limit extension

[Michael Schachtebeck]

Am 07/20/2005 04:45 PM schrieb Sven Schuster:

> AFAIK, when you add, delete, replace a iptables rule, at first the 
> current rules are "downloaded" from kernel, the changes are made in
> user space, then the ruleset is "uploaded" again to the kernel. 
> When uploading, I think that all the internal data structures for
> the matches are deleted and then allocated freshly. That's why you
> see this behaviour in your testing. When your cronjob runs (or you
> run it manually) all the data structures get deleted and newly
> allocated, thus the limit rule matches again.

But on the other hand, the counter correctly shows the number of packets
that matched the rule; iptables -t nat -vnL PREROUTING says:

9 540 REDIRECT tcp -- eth1 * 10.10.10.69 0.0.0.0/0 tcp spts:1024:65535
dpt:80 flags:0x16/0x02 limit: avg 1/day burst 1 redir ports 5000

So it would be very strange if the rules were extracted to user space,
rewritten/modified, "uploaded" to the kernel with the correct counters
for the remaining rules, and then, the rules do not look to this
counters.  ;-)

Why then save and restore the counters, if they are not used by the rules?

Michael.
-- 
PGP Public Key: http://www.num.math.uni-goettingen.de/schachte/key.asc
Key fingerprint: C474 8B85 17C0 0232 E439 0FBF 2451 E452 293C D798

Re: limit extension

[Jan Engelhardt]

>Why then save and restore the counters, if they are not used by the rules?

iptables-save done on a hourly/daily basis using cron is a nice way to find 
out statistics: how many bytes have been transferred to/from my httpd, etc.



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: limit extension

[Sven Schuster]

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


Hi Michael,

On Wed, Jul 20, 2005 at 04:55:02PM +0200, Michael Schachtebeck told us:
> But on the other hand, the counter correctly shows the number of packets
> that matched the rule; iptables -t nat -vnL PREROUTING says:
> 
> 9 540 REDIRECT tcp -- eth1 * 10.10.10.69 0.0.0.0/0 tcp spts:1024:65535
> dpt:80 flags:0x16/0x02 limit: avg 1/day burst 1 redir ports 5000
> 
> So it would be very strange if the rules were extracted to user space,
> rewritten/modified, "uploaded" to the kernel with the correct counters
> for the remaining rules, and then, the rules do not look to this
> counters. ;-)

I'm not that familiar with the iptables internals, but I suspect that
the counters (which are probably part of the "core" rule data structure)
are downloaded to userspace and get uploaded again untouched when just
adding or deleting a rule from an existing ruleset, but the limit-match
internal data structure will will get reallocated.

Maybe one of the developers reads this mail and can prove me wrong or
perhaps even right :-)



Sven

> 
> Why then save and restore the counters, if they are not used by the rules?
> 
> Michael.

-- 
Linux zion 2.6.13-rc3-mm1 #6 PREEMPT Mon Jul 18 19:42:52 CEST 2005 i686 athlon i386 GNU/Linux
 17:11:17 up 1 day, 21:23,  1 user,  load average: 0.00, 0.05, 0.05

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