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

Swaroop Potdar Swaroop.Potdar at Corliant.com
Mon Oct 2 17:40:30 EDT 2006


Well its the easiest to flame a reply.
 
We are missing the whole picture here, Drew had a point regarding the specific 
statement made, and thats the reasoning for that, and thats how its done.
 
If Drew had a implementation question, the reply would have been inline
I see the reply jumping to the assumption that the Guard is onsite, 
and as if we are discussing IOS, GRE/BGP/LAN, Tuning the thresholds,
or adding signatures. :-)
 
HTH-Cheers,
Swaroop

	-----Original Message----- 
	From: Jared Mauch [mailto:jared at puck.nether.net] 
	Sent: Tue 10/3/2006 3:02 AM 
	To: Swaroop Potdar 
	Cc: Drew Weaver; cisco-nsp at puck.nether.net 
	Subject: Re: [c-nsp] Cisco Guard & the detection/mitigation modules for the 6500
	
	

	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