RE: Denial of Service: Commercial Defense products

["Joel Friedman" <jfriedman () datapipe com>]

Matt,

It seems perhaps my requirements were different than yours, as well as my observations:

1)  The Detector can classify an attack.  The Detector can be put into learning mode where it learns what typical 
traffic is for a certain destination IP address.  Then it builds a profile utilizing thresholds which stipulate when 
the Guard should be activated.  This is the always on and automatic behavior your were describing, and it can be done 
without the use of Arbor's products.

2)  Yes, every SYN from a unique source address (non-verified with a valid ACK) is answered with a proxied SYN/ACK (aka 
SYN cookie).  This can double your bandwidth as you state.  However this is the only way which I am aware of to not 
drop any legitimate traffic.  As mentioned above it depends on your needs.  You state that at a certain point the 
TopLayer solution does not answer SYN requests, which means that potentially valid traffic will go answered.  In my 
implementation this is not acceptable.

3)  We saw no such performance hit.  The Riverhead (Cisco) device we utilize operates entirely on a single Broadcom 
PCI-X card with an embedded OS.  The host machine and OS do not deal with the network traffic at all.

> From what I recall from TopLayer's solution, they required a ridiculous amount of hardware in order to be  highly 
> available and handle the same amount of traffic as a single Riverhead box.  They required 2 load balancing TopLayer 
> boxes, then 2-4 additional boxes to mitigate the DDoS attack which put costs significantly higher.  Perhaps their 
> product has improved and this is no longer necessary.

With the Cisco devices this is not necessary because if one box goes down, the route will simply flap, and then a 
standby box can take over.

Keep in mind that inline products, when failed, bring down your entire network.  Because the Guard is only protecting 
the injected routes, it can only degrade traffic for those solutions.  And if the Guard goes down and the route goes 
away, it will be as if the Guard wasn't there at all.  It won't bring down the entire solution.


--Joel

-----Original Message-----
From: FinAckSyn [mailto:finacksyn () yahoo co uk] 
Sent: Sunday, November 27, 2005 1:13 PM
To: Roland Dobbins
Cc: Joel Friedman; focus-ids () securityfocus com
Subject: Re: Denial of Service: Commercial Defense products

Hi Roland,

Thanks for the reply.

We had problems using the Cisco Detector/Guard solution against a highly random source SYN Flood.  If my memory serves 
me correctly, these were the problems we ran into (you may have to help me out here!):

1)  The Detector itself cannot classify incoming SYN packets as bad, as it only sees each random source IP once.  It 
was up to the administrator to take note there was a DDOS attack going on, get out of bed, turn on the Guard, then stay 
up all night so he could turn it off once the attack subsided.  The Arbor solution was suggested as this offered some 
automation features, but our customer laughed at us when we told her how much it would be.  This immediately throws 
Cisco Guard out of the small/medium sized ISPs due to cost. 

2)  Once the Cisco Guard is in action, then for every SYN it receives, it doubles the bandwidth in use by sending a 
SYN/ACK back.  This meant the customer would had to invest in twice the amount of burtsable bandwidth to counter the 
maximum size of SYN Flood. 
As the ISP could only provide 1Gb, then this meant that using the Cisco Guard in theory could only deal with a 500Mb 
SYN Flood, unless investments upstream were made in 10Gb infrastructure (for example, so that a 750Mb SYN Flood could 
have 750Mb worth of SYN/ACKs sent back to each source).  Again, not ideal for a small ISP that only has a couple of Gig 
handoffs.

3)  We saw a performance hit on the Cisco Guard when under a large random source SYN Flood.  This had a knock-on effect 
on the customer's latency.
Latency is not ideal for certain applications.  It may be OK for HTTP/SMTP, but online poker sites and indexes cannot 
afford to take this hit.

That's why it wasn't suitable for our customer's gaming customer - they wanted a solution that would prevent DDOS from 
causing ANY performance or service degradation whatsoever, and preferably be 100% automated, always on, with minimal 
maintenance.  Oh, and cheap...  after all, it's always worth considering whether or not your should just stump up the 
cash for the exortion demands, rather than invest £££s in new equipment.

In the end, after a lot of hard work and late nights pushing the Cisco Guard solution, another reseller stepped in and 
sold them Toplayer.  This immediately addressed the DDOS Attack and concerns about latency (ASIC based), and as it was 
always on, the customer didn't have to worry about getting out of bed in the middle of the night.  The customer could 
also keep their 1Gb infrastructure, as the Toplayer didn't send back SYN/ACKs after a certain point (using some sort of 
DDOS Protection algorithm).  It was a pity we'd never heard of them before, otherwise it looked like just the right fit.

Don't get me wrong - I think Cisco/Arbor have great potential in the large carrier-class space where they have 24/7 
support and can afford the additional bandwidth and extra equipment, but cost- and efficiency-wise, it just doesn't 
scale down (even to fit round a 1Gb pipe!) and I really wouldn't recommend anyone short of a $250,000 budget should 
start looking at this.

Regards,

Matt


--- Roland Dobbins <rdobbins () cisco com> wrote:

> Actually, FinAckSyn; the Guard doesn't work that way.  Traffic headed 
> into zones under protection is routed into the Guard itself, and then 
> various forms of antispoofing and anomaly-detection are performed to 
> determine whether or not the traffic is valid.
> Invalid traffic is
> dropped by the Guard, while valid traffic is re-injected into the 
> network in order to continue towards its destination.
>
> The Guard is usually configured as an on-demand device; it's only 
> 'inline' when needed, the rest of the time, traffic follows its normal 
> course through the network.  This type of operation ensures that the 
> Guard is only examining traffic when such examination is required, and 
> also doesn't require the network to be re-engineered in order to 
> induce artificial symmetry.
>
> In the case of your SP using the Guard to protect your gaming servers, 
> it sounds to me as if some baselining is needed in order to fine-tune 
> the Guard's profiles of what constitute normal and valid traffic to 
> your gaming servers.
>
> For more information on the Guard, NetFlow, and Arbor, see this URL:
>
>       http://www.cisco.com/go/cleanpipes
>
>
> On Nov 24, 2005, at 10:58 AM, FinAckSyn wrote:
>
> > Hi Joel,
> >
> > Cisco Guard doesn't actually 'stop' SYN packets -
> it
> > tells routers where the bad traffic is coming
> from,
> > and gets the routers to block by blackholing the route.
> > So yes, may look great in a lab environment where
> your
> > Cisco 7200s are happily throwing SYN packets into oblivion, but in 
> > the real world, both the SYN
> Cookie
> > mechanism and routing manipulations cause a lot of problems with 
> > real world traffic.
> > This is where an inline device is so important - something that can 
> > understand both ends of the connection and work out whether it's 
> > valid or not before throwing it away.
> > Our ISP uses Cisco Guard, but we tell them to turn
> it
> > off, unless absolutely necessary to protect their
> own
> > peering points, as if it's left on always, it
> throws
> > our customer's customers out of their online
> gaming
> > sessions (which is bad news for them and us!).
> >
> > Regards,
> >
> > Matt
> >
> > --- Joel Friedman <jfriedman () datapipe com> wrote:
> >
> > > Riverhead (now Cisco Guard) is by far the best choice.  We had a 
> > > little in house shoot-out where we attacked multiple
> vendors'
> > > hardware and graphed
> > > their results into the millions of packets per second.  Due to 
> > > NDA's we are not allowed to disclose which vendors, nor their 
> > > results, but I can say that Riverhead successfully defended against 
> > > more than twice the load of its competitors...at the time it was 
> > > able to stop approximately 1.5 million SYN packets per second while 
> > > still allowing
> legitimate
> > > traffic.
> > >
> > > IMHO there is no other choice.
> > >
> > > --Joel
> > >
> > >
> > > -----Original Message-----
> > > From: Kyle Quest
> > > [mailto:Kyle.Quest () networkengines com]
> > > Sent: Wednesday, November 23, 2005 2:42 PM
> > > To: focus-ids () securityfocus com
> > > Subject: RE: Denial of Service: Commercial
> Defense
> > > products
> > >
> > > You should really look at Top Layer if you are serious about 
> > > defending against denial of service
> attacks.
> > > Don't even waste your time on Mazu or McAfee.
> > > Tipping Point is suppose to get better at it as well (they were 
> > > working on some news things the last time I had a chance to talk to 
> > > one of their top guys), but I don't know if it's already available.
> > >
> > > I would recommend looking at the NSS reports 
> > > (http://www.nss.co.uk/download/download.htm).
> > > Unfortunately, the online version of the report that includes Top 
> > > Layer review is no longer available, but you can still buy it for a 
> > > couple of bucks.
> > >
> > > Kyle
> > >
> > > -----Original Message-----
> > > From: Ogle [mailto:myinfosec () gmail com]
> > > Sent: Tuesday, November 22, 2005 4:44 AM
> > > To: focus-ids () securityfocus com
> > > Subject: Denial of Service: Commercial Defense products
> > >
> > >
> > > Hi,
> > > I have an ISP customer who want to protect their
> > > network and their
> > > subscriber's network.
> > > In "Internet Denial of Service: Attack and
> Defense
> > > Mecahnisms" book, I
> > > noticed 7 commercial products.
> > > 1. Mazu Enforcer by Mazu Networks
> > > 2. Peakflow by Arbor Networks
> > > 3. WS Series Apliances by Webscreen Technologies
> > > 4. Captus IPS by Captus Networks
> > > 5. MANAnet Shield by CS3
> > > 6. Cisco Traffic Anomaly Detector XT and Cisco
> Guard
> > > XT
> > > 7. StealthWatch by Lancope
> > >
> > > Since I'm new with this type of products, is
> there
> > > any reference out
> > > there to help me choose the right solution to my
> > > customer ?
> > > Is there any problem if I use IPS (ie:
> TippingPoint,
> > > McAfee) for this
> > > solution ?
> > >
> > > Thanks.
> >
> >
> >
> >             
___________________________________________________________
> > WIN ONE OF THREE YAHOO! VESPAS - Enter now! -
> http:// 
> > uk.cars.yahoo.com/features/competitions/vespa.html
----------------------------------------------------------------------
> > --
> > Test Your IDS
> >
> > Is your IDS deployed correctly?
> > Find out quickly and easily by testing it
> > with real-world attacks from CORE IMPACT.
> > Go to
http://www.securityfocus.com/sponsor/CoreSecurity_focus-
> > ids_040708
> > to learn more.
----------------------------------------------------------------------
> > --
--------------------------------------------------------------------
> Roland Dobbins <rdobbins () cisco com> // 408.527.6376
> voice
>
>   Algorithm agility is an essential feature in any
> Internet protocol.
=== message truncated ===



                
___________________________________________________________ 
Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/



------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
------------------------------------------------------------------------