On Wed, Jan 26, 2005 at 09:48:06AM -0500, [EMAIL PROTECTED] wrote:
> On Tue, 25 Jan 2005, Christopher Linn wrote:
>
> >i am interested 9in using altq to limit the outflow from an rfc1918
> >NAT'd network to alleviate the possibility of e.g. DDoS attacks
> >originating from within the NAT.
> >
> >one of our security guys (who is not familiar with pf) mentioned to
> >me that i should look for something to rate-limit (packets/sec)
> >outgoing, since for example a DDoS SYN flood pointed at a webserver
> >port 80/443 just spews little packets at a high rate. but the
> >closest thing i see to this is the "qlimit" parameter for max
> >packets queued.. doesn't really seem like it would be the same thing.
> >
> >am i missing something? has this issue been discussed?
> >
> >i suspect i am missing something..
> >
> >cheers,
> >
> >chris linn
> >
>
> ASAIK pf rate-limits based on bits per second, not packets per second.
> qlimit controls depth of queues, not how fast they are emptied.
>
> You could have two queues, one for syn packets and one for other traffic.
> The syn packet queue can be rate limited to X bits/second which can be
> based on known small syn packet size.
>
> Mike
as i read this i said to myself, D'OH! we're _queueing_ here!.. ;*)
daniel also gave me this advice, which seems like it might even be more
apropriate:
"... but i wouldn't limit that with altq at all, use max-src-state or
similar to limit the number of concurrent _states_ a client can create
which limits syn floods (any connection flood, actually) nicely. if
you limit a client to 100 concurrent connections, he can start nmap
or his favorite syn flood tool, but pf will only create the first 100
states, passing 100 syns, then block until old connections are
closed/time out."
also to clarify myself, i wasn't specifically worried about SYN flood,
but rather any possible flooding that anyone might think up, therefor
i was thinking in terms of a more general solution. seems like the
use of max-src-state (see pf.conf(5) under STATEFUL TRACKING OPTIONS)
fits this nicely. thnaks daniel ;*>
cheers,
chris
--
Christopher Linn, (celinn at mtu.edu) | By no means shall either the CEC
Staff System Administrator | or MTU be held in any way liable
Center for Experimental Computation | for any opinions or conjecture I
Michigan Technological University | hold to or imply to hold herein.
