Probably bug in netfilter hashlimit extension

Probably bug in netfilter hashlimit extension

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Recently I tried to mitigate some slow attacks via netfilter rule
utilizing hashlimit target. I used the following specification:

   -A DETECT_INVALID -m hashlimit --hashlimit-upto 10/hour --hashlimit-mode srcip --hashlimit-name attack_invalid -j RETURN

Now I seen some strange stuff. The counter in
/proc/net/ipt_hashlimit/attack_invalid only counts from 60 back to 0 and
then the entry disappears. Than means that a rate of 10/hour will never
ever be detected at all.

On that box I use kernel 3.16.0 from debian backport to oldstable Which
seems to be somewhat equal to 3.16.7. So maybe that bug has beed find
earlier or is even fixed upstream. I have no easy way to upgrade that
kernel short term as the box is productive.

Shorter times like 30/hour with a slightly bigger burst (10 instead of
the default 5) seems to work as expected but is not able to detect the
attacks due to the slow rate.

Am I the only who seen that behaviour or is that a known limitation? I
find no such notes anywhere that there is a limit here. (Although I
would believe that there is a high limit somewhere. But then I would
expect them to be returend with some errno when trying to set a to high
value.)

Please keep me in Cc as I do not monitor this List that often.

Regards
   Klaus
- -- 
Klaus Ethgen                              http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQGcBAEBCgAGBQJVUHZ/AAoJEKZ8CrGAGfasiOQMAJC5FATdWhstS+60vIwn+Iyp
6/dprBI9zppfS9FtKvjCEYbrzmDKpTCfST5jtC7F6VRdfMeqgfFZ9wpdOk4VGJ6c
PgpUTGN8tUrD3oLlWtd+uPIeQ5U02h2Y6Lh5YNc+iAd2fExCqixM6vExdD+5ayWy
jcG/h7rC3rm332VTQNbAso7XLeMqiUVLwGn5CpbvW+A5kyePlVfjrONQ+fgBME7v
xlEH4GbLgr/K2GYrJLbGcXbIAXuYHi1NyykKE3YkJIptIdTHLZmJXA79h4gGpvNj
JoatHhMi3WpjxHNFSc8NXnmszJd+60PSNRu3hgGW5nkJQh6tFArGOsru2gIYLKt0
HJcO0H+gHi3sYgXRl4MxzN7GxrQjJcEL/wg+kNH8MUXZVhy4wprZoxsDiSEsmyFa
il9ZSbzbDX9ipCqeLb6fq+5XmQ+KkzGnzV0RZAbV372kDL+r2ck4K1tI+plDch/y
3ivFycT6NDtmPyPW1bJ2whHsLaRG1uu9VgWcEnLoFg==
=SvVH
-----END PGP SIGNATURE-----

Probably bug in netfilter hashlimit extension

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Resend to netfilter-devel@vger.kernel.org, posted first to lkml.

Recently I tried to mitigate some slow attacks via netfilter rule
utilizing hashlimit target. I used the following specification:

   -A DETECT_INVALID -m hashlimit --hashlimit-upto 10/hour --hashlimit-mode srcip --hashlimit-name attack_invalid -j RETURN

Now I seen some strange stuff. The counter in
/proc/net/ipt_hashlimit/attack_invalid only counts from 60 back to 0 and
then the entry disappears. Than means that a rate of 10/hour will never
ever be detected at all.

On that box I use kernel 3.16.0 from debian backport to oldstable Which
seems to be somewhat equal to 3.16.7. So maybe that bug has beed find
earlier or is even fixed upstream. I have no easy way to upgrade that
kernel short term as the box is productive.

Shorter times like 30/hour with a slightly bigger burst (10 instead of
the default 5) seems to work as expected but is not able to detect the
attacks due to the slow rate.

Am I the only who seen that behaviour or is that a known limitation? I
find no such notes anywhere that there is a limit here. (Although I
would believe that there is a high limit somewhere. But then I would
expect them to be returend with some errno when trying to set a to high
value.)

Please keep me in Cc as I do not monitor this List that often.

Regards
   Klaus
- -- 
Klaus Ethgen                              http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQGcBAEBCgAGBQJVUKdyAAoJEKZ8CrGAGfasMGQL/3BXsjHwkRp/THoc6sY22CeK
NfA42d0Yc05Jg0MNrvAZk8X7dnSuqpzyEju8/VsFEuwkE4oUkMMf5OCMYo8SpXuT
cC+hGslOOmF3NW/VvK+6q75c0XERFV91WFSgE5MwFJQHbLYTLcVGYxShSkhQhwMU
8gqzfBbOLmoI1FyU8tVZtMgyLbsp8U/TerHRs2RDgCE6PeAy3t6zukU/ld60RtFe
FVrn/oMVBTxrv5EPWUBeV93LC7t/HHiBW8yPxrzY11DfTUP/0OCzZnHcW5JOOzoU
AYcLKbt+VwVxpZQtLJT/FdZOsJuJT7rJna/RJvCgiZgkvF+mvQXTYOOYhac7o1C7
pylXEbs6CRKs8Ou1itLkkoCPR6j3PuDOUR9afiLbA9/wINOxHEr7uBTse3l6Vs+S
XRbESdTAjc1tMLO7BaCMf+5w9qSwzS/xz7cLDLmwPhN+W9B0u6eUHP8CTOmlZT6j
k6+KrE9c2xv8NwcNBZP/7yqbagaZL47W3qIhxrTGCw==
=aszC
-----END PGP SIGNATURE-----

Re: Probably bug in netfilter hashlimit extension

[Florian Westphal]

Klaus Ethgen <Klaus+lkml@ethgen.de> wrote:
> Resend to netfilter-devel@vger.kernel.org, posted first to lkml.
> 
> Recently I tried to mitigate some slow attacks via netfilter rule
> utilizing hashlimit target. I used the following specification:
> 
>    -A DETECT_INVALID -m hashlimit --hashlimit-upto 10/hour --hashlimit-mode srcip --hashlimit-name attack_invalid -j RETURN
> 
> Now I seen some strange stuff. The counter in
> /proc/net/ipt_hashlimit/attack_invalid only counts from 60 back to 0 and
> then the entry disappears. Than means that a rate of 10/hour will never
> ever be detected at all.

Can't reproduce this with 4.0 on x86_64, using iptables 1.4.21 (64bit):
3598 127.0.0.1:0->0.0.0.0:0 8119296 57600000 11520000

Re: Probably bug in netfilter hashlimit extension

[Cong Wang]

(Cc'ing netdev and netfilter-devel)

On Mon, May 11, 2015 at 2:29 AM, Klaus Ethgen <Klaus+lkml@ethgen.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Recently I tried to mitigate some slow attacks via netfilter rule
> utilizing hashlimit target. I used the following specification:
>
>    -A DETECT_INVALID -m hashlimit --hashlimit-upto 10/hour --hashlimit-mode srcip --hashlimit-name attack_invalid -j RETURN
>
> Now I seen some strange stuff. The counter in
> /proc/net/ipt_hashlimit/attack_invalid only counts from 60 back to 0 and
> then the entry disappears. Than means that a rate of 10/hour will never
> ever be detected at all.
>
> On that box I use kernel 3.16.0 from debian backport to oldstable Which
> seems to be somewhat equal to 3.16.7. So maybe that bug has beed find
> earlier or is even fixed upstream. I have no easy way to upgrade that
> kernel short term as the box is productive.
>
> Shorter times like 30/hour with a slightly bigger burst (10 instead of
> the default 5) seems to work as expected but is not able to detect the
> attacks due to the slow rate.
>
> Am I the only who seen that behaviour or is that a known limitation? I
> find no such notes anywhere that there is a limit here. (Although I
> would believe that there is a high limit somewhere. But then I would
> expect them to be returend with some errno when trying to set a to high
> value.)
>
> Please keep me in Cc as I do not monitor this List that often.
>
> Regards
>    Klaus
> - --
> Klaus Ethgen                              http://www.ethgen.ch/
> pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen <Klaus@Ethgen.de>
> Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQGcBAEBCgAGBQJVUHZ/AAoJEKZ8CrGAGfasiOQMAJC5FATdWhstS+60vIwn+Iyp
> 6/dprBI9zppfS9FtKvjCEYbrzmDKpTCfST5jtC7F6VRdfMeqgfFZ9wpdOk4VGJ6c
> PgpUTGN8tUrD3oLlWtd+uPIeQ5U02h2Y6Lh5YNc+iAd2fExCqixM6vExdD+5ayWy
> jcG/h7rC3rm332VTQNbAso7XLeMqiUVLwGn5CpbvW+A5kyePlVfjrONQ+fgBME7v
> xlEH4GbLgr/K2GYrJLbGcXbIAXuYHi1NyykKE3YkJIptIdTHLZmJXA79h4gGpvNj
> JoatHhMi3WpjxHNFSc8NXnmszJd+60PSNRu3hgGW5nkJQh6tFArGOsru2gIYLKt0
> HJcO0H+gHi3sYgXRl4MxzN7GxrQjJcEL/wg+kNH8MUXZVhy4wprZoxsDiSEsmyFa
> il9ZSbzbDX9ipCqeLb6fq+5XmQ+KkzGnzV0RZAbV372kDL+r2ck4K1tI+plDch/y
> 3ivFycT6NDtmPyPW1bJ2whHsLaRG1uu9VgWcEnLoFg==
> =SvVH
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Probably bug in netfilter hashlimit extension

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

Am Mo den 11. Mai 2015 um 14:50 schrieb Florian Westphal:
> Klaus Ethgen <Klaus+lkml@ethgen.de> wrote:
> > Recently I tried to mitigate some slow attacks via netfilter rule
> > utilizing hashlimit target. I used the following specification:
> > 
> >    -A DETECT_INVALID -m hashlimit --hashlimit-upto 10/hour --hashlimit-mode srcip --hashlimit-name attack_invalid -j RETURN
> > 
> > Now I seen some strange stuff. The counter in
> > /proc/net/ipt_hashlimit/attack_invalid only counts from 60 back to 0 and
> > then the entry disappears. Than means that a rate of 10/hour will never
> > ever be detected at all.
> 
> Can't reproduce this with 4.0 on x86_64, using iptables 1.4.21 (64bit):
> 3598 127.0.0.1:0->0.0.0.0:0 8119296 57600000 11520000

- From your post I also tried and are not able to reproduce it on
localhost.

... And after flushing the table and reinstalling the filter, the
problem is gone completly.

I just think now, that it is not initializing the hashlimit correctly
when overwriting a table with iptables-restore that already has such a
hastable in use with the same name. I never removed entries, I always
replaced them with iptables-restore.

Thanks for the final hint and sorry to have brought that to the list.

Regards
   Klaus
- -- 
Klaus Ethgen                              http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQGcBAEBCgAGBQJVURpmAAoJEKZ8CrGAGfas3fkL/RWUXo6JF5AvpqFTT20vTiSL
tYjOYYo2/ar9kYxIk44kGy5xg+/mSMou8t6NUakMtY1D6Sgip4we9KgBuE3ljDCH
Je4AW232oVC9PP5F1fhP1asSKYsGfymMAeiZwFgm5rtgGjP5a+zhNRYhF/EL622I
g4qOrYJ2TKqqu718WkHiuy+YBPv05p1AdlMO+Tw1MQbtJlm7/0ltiVFEU2UZNBj+
U0o+m0mikgCXVchFZVywyl+2ADmKF5n4MW78Kk/VtM/6hFetM0ztFJ0tCCFz59se
Tr+hYu5Z24MpepLW5e7Jy1NFRCD+goubgnnQjX+KIh1oiwtWaFGkF0YrMI1I0bEV
kp0sjMSZS05P8XU5FrPusvHvMDfN+G9yKR6NDbcIIFpmqBXUI/5FHsKikBIUbCQR
CmPL6KY2kIQ43XezF/s+6ZknZRRakahZXmrXisGZVh5D6eztCYCl0o7yI/hYfsUl
C3kq+hv6HbGBhr2ll/8sc600Qo7V1iP1javE2REy3Q==
=Afco
-----END PGP SIGNATURE-----

Re: Probably bug in netfilter hashlimit extension

[Jan Engelhardt]

On Monday 2015-05-11 23:09, Klaus Ethgen wrote:
>> > Recently I tried to mitigate some slow attacks via netfilter rule
>> > utilizing hashlimit target. I used the following specification:
>> > 
>> >    -A DETECT_INVALID -m hashlimit --hashlimit-upto 10/hour --hashlimit-mode srcip --hashlimit-name attack_invalid -j RETURN
>> > 
>> > Now I seen some strange stuff. The counter in
>> > /proc/net/ipt_hashlimit/attack_invalid only counts from 60 back to 0 and
>> 
>> Can't reproduce this with 4.0 on x86_64, using iptables 1.4.21 (64bit):
>> 3598 127.0.0.1:0->0.0.0.0:0 8119296 57600000 11520000
>
>From your post I also tried and are not able to reproduce it on
>localhost.
>... And after flushing the table and reinstalling the filter, the
>problem is gone completly.
>
>I just think now, that it is not initializing the hashlimit correctly
>when overwriting a table with iptables-restore that already has such a
>hastable in use with the same name. I never removed entries, I always
>replaced them with iptables-restore.

Well of course, if you use restore, the hashlimit table survives,
because its reference count never goes to zero, itself a result of
the create-table-first-then-delete-old cycle.