packets scan

[kakadu@earthlink.net.bbs]

Mr. Schaaf,

   IIRC, there are two knobs:

   Status: /proc/net/ip_queue
   Maximum queue length: /proc/sys/net/ipv4/ip_queue_maxlen

   You're also right about protecting yourself using the limit match to
prevent conntrack DoS. Thus, I suppose the final rules would look like
this:

   iptables -t mangle -A PREROUTING  -m state --state NEW -m limit 
--limit 3/s -j ACCEPT
   iptables -t mangle -A PREROUTING  -p tcp --sport 110 -j QUEUE
   iptables -t mangle -A POSTROUTING -p tcp --dport 110 -j QUEUE

Brad

Patrick Schaaf wrote:

> Mr. Chapman,
> 
> (I proposed REDIRECT, implying conntrack)
> 
>>    That's one of the advantages of using QUEUE. You don't need ip_conntrack.
>> I'm not bad-mouthing it, but the last thing you want is somebody to DoS your
>> conntrack module and block your virus scanner.
> 
> 
> If I remember context correctly, we are talking about POP3 connections
> from "inside" clients to "outside" mail servers. I can live with policing
> the "inside" user who DoSses my firewall. The other "inside" users usually
> help out a bit. So, conntrack exhaustion wouldn't be a great concern.
> 
> But on the general topic of conntrack exhaustion: it becomes really bad
> when the tracks are bidirectional. Oneway things are reaped preferentially,
> without the new connection noticing. Thus, the bad things happen when somebody
> DOSses an expected, open service ports, and only while a server answers.
> As all these cases will look just like the service that pays the bills,
> it is a bit hard to police them centrally. However, a good server process
> will terminate each inactive TCP connection eventually, and the conntrack
> then vanishes.
> 
> If this analysis is correct, only a sufficiently fast and wide attack
> will be able to exhaust a carefully chosen conntrack_max with bidirectional
> connections. If this is really true, there's a wonderful tool you already
> have, which provides the neccessary "upper bounds": the limit match.
> 
> If you figure out the possible maximum depth of the QUEUE in-flight
> skbuff list, you could apply that limit logic as well. Is there some
> /proc/*/ip_queue_max knob?
> 
> regards
>   Patrick
> 
> 
> 



--
¡° Origin: ·s¼ÒÀÀ¥@¬É ¡» Mail: kakadu@earthlink.net (Brad Chapman)