[c-nsp] Cisco Guard & the detection/mitigation modules for the 6500

Jared Mauch jared at puck.nether.net
Mon Oct 2 17:32:49 EDT 2006


On Mon, Oct 02, 2006 at 04:17:54PM -0500, Swaroop Potdar wrote:
> Well for the statement used, 
>  
> "over buying bandwidth is not a proper solution to the problem of DDoS
> attacks."
>  
> For this to be achieved the detection modules need to be deployed in a distributed manner,
> And the Guard could be in a centralized place. So ideally what happens is when the detectors 
> sense a Traffic Anomaly they plug in a route towards the Guard and the Guard examines it further with its inbuilt 
> anomaly signatures. If the traffic has some matches its black holed. And if its good traffic it gets sent back to the original destination.
>  
> In this effectively we are diverting the traffic from the affected site, hereby reducing oversubcription of bandwdith on the link towrds that PoP or site. And by centrally examining that traffic first before sending it to the original destination.
>  

	Um, this kinda misses Drew's points in the original question and
sounds like sales marketing drivel to me.


	1) The module for the "76k" series of devices really requires SXF6
to work properly if you're going to deliver traffic back via GRE.
	2) Are you using the guard with any outside detection software?
(eg: arbor networks, etc..?)
	3) What are you "diverting" to the guard?

	The guard mostly does an ok job.  Depending on how it's
configured and the type of traffic diverted, you're likely to see
reasonable performance for most general applications.  You may need
to tune it for your enviroment.

	The overbuying bandwidth statement depends on who you are
and how you use the device.  The largest of these devices currently
only handles about a gig of traffic (today).  If you're seeing
a multi-gig attack, you either need multi-gigs of bandwidth with
multiple guard devices or to have your upstream(s) perform
the mitigation for you.  Obviously attacks can vary and just
hose a single upstream provider, even if you have a 10g link
to them.  If you have a 40g (oc768), i'd not expect to see
this problem today or in the semi-near future.

	If folks are determined enough, they'll fill up all your
bandwidth.  if what you want to do is mitigate a reasonable sized
attack, the guard can be a viable choice.  If they're really
trying to get you, you're SOL.  They'll make legit web requests and
not just send a syn/rst flood at you.

	- Jared

> 	-----Original Message----- 
> 	From: Drew Weaver [mailto:drew.weaver at thenap.com] 
> 	Sent: Tue 10/3/2006 2:38 AM 
> 	To: cisco-nsp at puck.nether.net 
> 	Cc: 
> 	Subject: [c-nsp] Cisco Guard & the detection/mitigation modules for the 6500
> 	
> 	
> 
> 	    Hi there, I am looking for first hand experience on the Cisco Guard
> 	products, as well as any opinions on the anomaly line of service cards
> 	for the 6500 series switch.
> 	
> 	I've read the cisco marketing on the products and it states that "over
> 	buying bandwidth is not a proper solution to the problem of DDoS
> 	attacks." However, I am not certain how any hardware is going to prevent
> 	transit lines from being flooded before it reaches your edge interface.
> 	
> 	Does anyone have any idea how and if these products work?
> 	
> 	Thanks,
> 	-Drew
> 	
> 	_______________________________________________
> 	cisco-nsp mailing list  cisco-nsp at puck.nether.net
> 	https://puck.nether.net/mailman/listinfo/cisco-nsp
> 	archive at http://puck.nether.net/pipermail/cisco-nsp/
> 	
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.


More information about the cisco-nsp mailing list