Re: altq and rate limiting (packets/sec)
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.
Re: altq and rate limiting (packets/sec)
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 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 -- 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.
altq and rate limiting (packets/sec)
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 -- 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.
