On Mon, 20 Mar 2000, jamal wrote:
> Not familiar with what PIX does. Any pointers?
>
> The ingress policing is actually not just a dumb rate limiter as you seem
> to imply. Take a look at the source. The rate is measured using a
> low-pass filter i.e it is not influenced by sudden bursts of SYN
> arrivals for the server. If there is a sustained SYN arrival at the
> firewall for a particular host (or more precisely firewall rule), you
> should be able to intelligently "detect" that and drop the extra
> noise. You can do a lot of other funky things like cascade rules etc. I
> have been meaning to submit a patch (infact did write it about a year
> ago) where you can cascade rules to say start random dropping if it
> exceeds 40 SYN/sec; more nasty random drops after 70SYNS/sec; total drops
> after 128 SYNs/sec (somehow matching whatever you want your syn processing
> queues to be on the server).
> Of interest is the fact you are not restricted to use ipchains/iptables
> for rule selection. You can use the gazillion other classifiers provided
> by the QoS subsystem.
>
> Granted, as Christopher pointed out, ingress policing alone might not be
> sufficient for thwarting DOS attacks. Syn Cookies at the server will help
> a lot If you are concerned about scalability issues.
> Stateful filtering (most likely to be done in user space for
> cleanliness) where you spoof response is definetely the least scalable;
>
> cheers,
> jamal
The problem with the PIX is it is not a stateless router w/
stateful filter, it is a stateful router with filters. I does a
double proxy with address magic, you don't connect through it, it
takes your connection, and if it like you connects to the far end and
then connects the 2 sessions internally... Should the PIX break,
*all* sessions are lost, evil. Think of it as bi-directional IP MASQ
+ stateful filtering.
This would be a nice patch as well. I simplified my setup a bit, I
play with u32 rules to send all incoming SYNs to a class, and then
assign to leaf classes on a per server bases. The overall SYN rate is
the sum of absolute max peak rate for all servers combined * 1.5, and
the per server is set to servermax * 2. This seems to do a good
job, and it seems smoother in testing to let the server kick in with
SYN cookies at about 50 - 75 % of where the CBQ limit is set, rhather
than setting the limit lower.
---
As folks might have suspected, not much survives except roaches,
and they don't carry large enough packets fast enough...
--About the Internet and nuclear war.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
