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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
