Le dimanche 28 février 2010 à 11:23 -0700, Tim Gardner a écrit : > > I realize there are manual methods for removing entries, but I argue > that manual methods are insufficient in a dynamic environment. > > Let me explain one of my use cases. One of the companies that I work for > is an ISP. Our primary bridge/firewall uses iptables as a first line of > defense. One of the methods to detect attackers is by using a port scan > detection filter (PSD), which is a bit memory and CPU intensive. Once > PSD identifies an attacker, then that source IP is added to a 'recent' > filter instance with an X second timeout, and the PSD entry flushes > after some timeout. 'recent' continues to block _all_ traffic from that > source IP until it stops sending packets for at least X seconds, at > which time I would like 'recent' to release the entry. > > Here is a rule snippet that implements this behavior: > > IRAW="iptables -t raw" > $IRAW -N DROPIP > $IRAW -A PREROUTING -m recent --name psd --update --seconds 3600 -j DROP > $IRAW -A PREROUTING -m psd --update --seconds 600 -J DROPIP > $IRAW -A DROPIP -m recent --name psd --set -j DROP > > As long as '-m recent --name psd --update --seconds 3600' drops entries > older then 3600 seconds, then nothing external is required to recover > those entries. > > As for your fast path comment, how about scaling the frequency with > which the reaper is run using a module parameter ? See attached patch. > > rtg OK but as pointed by Jan Engelhardt, same table can be used with different matches and different delays, so your patch is not good. You should add a parameter (--reap or some flag) to iptables rule to ask for this reap, and not let it happen in general case. iptables -A ... -m recent --name foo --seconds 60 -j DOTHAT iptables -A ... -m recent --name foo --seconds 3600 --reap -j ELSE Also, I am convinced your reap pointer is not good, because it can point to an entry that is renewed once per second for example, and reaper will be frozen. You should use lru_list.next only, because this one is guaranted to point to the oldest entry in table -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
