Re: xt_TARPIT (was: ipt_account / iptables 1.3.8)

[Patrick McHardy <kaber@trash.net>]

Jan Engelhardt wrote:
> On Jul 9 2007 17:04, Patrick McHardy wrote:
> 
>>The difference is that this is a global ratelimit, while xrlim_allow
>>is a per dst_entry ratelimit.
>>
>>
>>>As far as I can see, that xrlim call is there for at least one case:
>>>
>>>tarpit sends ACKs with window=0, but client ignores the RFC-given delay for
>>>window=0 packets.
>>
>>I think its more to prevent flooding your upstream, especially with
>>asynchronous bandwidth. Same reason you would usually rate-limit
>>the REJECT target on a DSL line.
>>
> 
> REJECT is for rejecting. People who use it _do_ want that the RST/ICMP
> is sent out immediately; otherwise they could just use DROP IMO.


Speaking as "people", no. I want to reject packets since its a lot
nicer than silently dropping, but I don't want anyone to be able
to flood my upstream by sending lots of packets down my a lot faster
downstream to closed ports. So I ratelimit REJECTs using the limit
match.

> A user can combine REJECT with hashlimit if he desires so.
> I do not have any objection to remove all ratelimiting in TARPIT,
> and instead put the user in charge of combining TARPIT with hashlimit.


Yes, thats what I would prefer as well, but currently it only
ratelimits replies to ACKs, not to SYNs, so this would change
how it works. If that doesn't matter, I'm all in favour of this
change.