Dr. Michael Weller <[EMAIL PROTECTED]> wrote:
> > Certain Firewalls (say a Cisco PIX, to name one) can protect a network
> > before certain attacks (say SYN flooding) by first establishing the TCP
> > protocol with the foreign host and only after successful TCP parameter
> > negotiation initiating the actual TCP connection to the client. [Afaik,
> > the PIX (for example) even allows randomization of Packet Sequence Numbers
> > (in the outbound direction) of the watched TCP connections.]
> >
> > I'm under the impression that I cannot achieve protection against such
> > denial of service attacks with a linux firewall.
>
> Right. Linux can't do that.
Linux when used with the virtual server clustering system has
this effect (with certain config types), but it does not do this in a
transparent mode for non clustered servers like the PIX does.
In other words, for certain cluster types the cluster
controllers SYN cookie mech kicks in, as well as the linux firewall
doing the randomization of Packet Sequence Numbers.
> This is something which better takes place on the servers themselves, where
> Linux does implement it - see SYN/RST cookies in the networking section of the
> kernel options.
This is correct, it is much better handled with SYN cookies on
the host. Linux supports SYN cookies (and has since ~96 IIRC (though
there have been 2 diff versions)), and allows tuning of the params for
when they kick in.
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.
End all, systems like the PIX suck, they cause a double action for
every connection, form a wonderful SPOF, and may screw things with
interesting IP stacks (they *MUST* be the entry/exit for that
network...). They behave like a mutant NAT box without the address
rewriting...
Linux as a firewall can easily rate limit SYNs (or anything else), so
I can for example limit server A to no more than 350 SYNs/sec.
The proper way to handle it is...
Rate limit SYNs to something way higher than expected ABSMAX expected
from traffic (you want to set a sane cap to protect against a SYN
attack so large it could eat all your bandwidth, but not kick in for a
smaller attack), do this at the border for site wide. For example do
not allow more than 30% of your pipes to be SYNs. This is sane, as
there is *no* realistic way that those micro sized packets could
consume this much during normal ops.
Do proper SYN cookies on the servers.
This way, get hit by a minor attack, the servers cookie it,
and precede as usual. You get a massive attack the router trims it to
levels the servers can handle, and as ~ 99% of the SYN traffic at this
point is attack few of the valid customer packets will be shed, but
otherwise the site continues as normal.
I cannot say enough evil about the PIX crap, you are basicly
doing the equiv if a netpipe port forward + magic address rewriting.
Ick, load issues, SPOF issues, etc.....
---
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]
