Re: DoS/DDoS Attack

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