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.
------------------------------------------------------------------------
