From: Erik A. Onnen (eonnen@entessa.com)
Date: Sat Jan 15 2005 - 13:19:05 EST
Faisal Khan wrote:
>
> Well I agree we are not helpless, we personally use the Top Layer box
> and its worked wonders.....have a half a dozen of them deployed (the IPS
> 100 that is). We are now looking into a HA/LB setup of the IPS 5500.
>
> The only thing that gets to me is when large DDoS attacks come in - even
> with GigaE connectivity, sometimes the setup rates are so high - the
> boxes have a hard time keeping up with it. In this respect the Foundry's
> ServerIron 850 is amazing. It has something called the Transaction Rate
> Limiting, which we have configured for Port 80. If too many transactions
> from a specific IP happen in a defined period (all parameters are set by
> us), the device will instantly block the IP. For inquiring minds - the
> maximum we've experienced in a DDoS attack was about 240Mbps sustained
> coming in from what seemed to be a gazillion IPs. The attack lasted
> about 2-3 days. Thank God for Foundry, which saved the day.
>
> What is truly frustrating is that the defences are at our perimeter -
> getting to the source I guess is just a Herculean task - I read
> somewhere that there are between 60 Million to 120 Million zombies out
> there - cannot recall the source, but that's what I read.
>
> There are still many features that all the DDoS mitigation OEM have not
> applied, that we have experienced and passed on as comments or as
> "wish-list" to the OEMs - I guess sooner or later someone will take care
> of them.
>
A sophisticated DDoS attempts to starve resources at two levels, network
*and* server.
The first level attempts to starve your upstream network bandwidth such
that incoming traffic can't make it to the destination. This is the
level that everyone has been looking so far and in general I agree with
the appliance approach as a tool but it's just that, not a solution.
Be careful with your policies for instantly blocking the incoming
traffic based on simple rate rules. If an attacker is able to derive
your rules (say they use one of their zombies to syn flood you and
realize that they stop getting syn-acks), it would be trivial for them
to use your rules against you by forging the source address of millions
of machines thereby cutting off legitimate IPs and depending on the
purposes of that web site you mention, cutting off customers. As long as
an attacker can forge a source IP, it's nearly impossible to pinpoint
the true origin of your attack. Even of you find a machine that is
generating spoofed packets working with ISPs, it's likely just a node,
then you need to find where it's getting instructions from which is
likely an anonymous IRC channel and a dead end.
Depending on budget, another tool to combat starvation of network
resources is increasing the size of the upstream pipe to your servers.
This one of the reasons that one of the largest pipes in the world flows
into Redmond, to make it difficult to clog the pipe and prevent
legitimate traffic from getting in.
The best way to combat spoofed IP-based DDoS attacks is not something
you have control over. The most effective way to fight these types of
attacks is to prevent spoofing of source IPs all together through
enforcing egress routing policies thereby making it possible to pinpoint
and ban actual offenders. This needs to happen at the ISP and SAs level.
Unfortunately few do enforce these policies, even less so on a global
scale. If, in an ideal world all ISPs and SAs did enforce egress routing
(I'm sure everyone on this list has implemented such a policy as a
responsible security professional, right? :) ), you could then ban
offending machines based on IPs knowing that traffic was coming from
where it advertises and not a spoofed source. Microsoft attempted to
mitigate this at the host level with XP2 by not allowing you direct
socket access, but attackers can get around this easily by directly
writing ethernet frames and skipping sockets all together.
I haven't seen anyone mention host starvation on this thread which is
also important. Some DDoS attacks can still deny legitimate users access
to your service by SYN flooding you at a low transfer rate (bypassing
rate rules on devices) from a myriad of spoofed IPs eating up all the
available sockets on a server. You can guard against this by increasing
the number of possible open sockets or even better by using SYN cookies
if your host OS supports it. There are limits to their effectiveness but
basically they allow you to have a half open TCP handshake without using
as many system resources and starving the number of open sockets. Some
firewalls can do this as well, it depends on your network configuration
whether or not this another tool for you to look at.
-erik
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:13 EDT