Re: [PATCH 1/1] netfilter: xt_recent: Add optional mask option for xt_recent

[Denys Fedoryshchenko]

Hi Pablo

On 2012-04-12 02:14, Pablo Neira Ayuso wrote:
> Hi Denys,
>
> On Tue, Mar 06, 2012 at 01:24:44PM +0200, Denys Fedoryshchenko wrote:
> > Use case for this feature:
> > 1)In some occasions if you need to allow,block,match specific 
> > subnet.
> > 2)I can use recent as a trigger when netfilter rule matches, with 
> > mask 0.0.0.0
> >
> > Example:
> >
> > If you ping 8.8.8.8, after that you can't ping 2.2.2.10
>
> Could you provide an useful example for this new feature?
>
> I also think you can make this with hashlimit, that allows you to
> set the network mask.

Yes, technically hashlimit can do a lot, but not everything. Especially 
because xt_recent can be "fine-grained" in steps, depends on timeline of 
event, and can be updated accordingly to time of reoccurred event. It is 
generally not related to mask option, but mask gives power to block 
subnets.
Why for example /24? Well, it is minimal mask for BGP announce :) It is 
very often, that requesting ip has more ip's in same subnet 
(load-balancing, or multiple ip's on dedicated server), and mask will be 
highly useful for that, to reduce number of entries and to tighten weak 
points (usually after ip blocked, they try from neighbor ip to check, if 
destination just blocked single ip). Plus rttl and hitcount another 
sweet things that are available in xt_recent, but aren't in hashlimit.

iptables -t mangle -N SIP
# If someone abuse our SIP, block him completely at least for 10 
seconds, if he try again, update and block for new 120 seconds
iptables -t mangle -A SIP -m recent --name X --update --seconds 10 
--mask 255.255.255.0 -j MARK --set-mark 0x1
# 120 - 600 seconds handle him over special relay (that will log his 
query, but wont pass him to real SIP server)
iptables -t mangle -A SIP -m recent --name X --rcheck --seconds 600 
--mask 255.255.255.0 -j MARK --set-mark 0x2

In this case i will log only invalid queries, but for example some DDoS 
or scanners that flood servers by packets will be silently ignored. 
Maybe if hitcount really bad, i will add them to ipset, and block 
permanently, by -m set --add-set.

For me personally it is useful, because i have around 140 NAS servers, 
and i give each of them /24 "gray" subnets, and in some cases i need to 
handle bad users, that are changing dynamic ip and attacking from new ip 
each time. I just block non-critical service for whole subnet then, till 
technician on duty will solve issue completely. And sure if attack are 
stopped, subnet will be unblocked "automagically".

Sure this feature not critical, or "a must", and if code are not good, 
it is up to you, if it should be added or not.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/