On Fri, 17 Mar 2000, Lars Marowsky-Bree wrote:
> > There is another option with Linux however. The QoS system
> > can be used to control *any* IP packets. It is fairly simple to limit
> > SYN rates on a site wide or per server bases. Even per server per
> > service.
>
> Then you are _rate limiting_. This is different from a SYN protection
> like PIX does.
lmb,
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
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
