Re: Internet SYN Flooding, spoofing attacks

On Fri, 11 Feb 2000, Paul Ferguson wrote:

> Vijay,
>
> We (at least cisco, anyways) already have a knob for this:
>
>   [no] ip verify unicast reverse-path
>
> We call it Unicast RPF.
This only works on single homed customers. Due to asymmetric routing, the
customer can source _valid_ ip addresses from an ip source address that is
not routed over that interface.  I too would prefer some sort of magic
unicast RPF, but the best compromise is the built-in access filter.  The
solution must be general enough to work for multihomed, defaulting out
customers with blocks from n providers,

/vijay


> See also:
>
> Craig Huegen's very useful web page on minimizing the effects
> of DoS attacks:
> http://users.quadrunner.com/chuegen/smurf.cgi
>
> Cisco: Distributed Denial of Service (DDoS) News Flash,
> February 9, 2000
> http://www.cisco.com/warp/public/707/newsflash.html
>
> Dave Dittrich's (University of Washington) very good
> analysis of the recent DDoS attack tools.
> http://www.washington.edu/People/dad/
>
> NIPC (National Infrstructure Protection Center),
> TRINOO/Tribal Flood Net/tfn2k stuff:
> http://www.fbi.gov/nipc/trinoo.htm
>
> "Handling A Distributed Denial of Service Trojan
> Infection: Step-by-Step."
> http://www.sans.org/y2k/DDoS.htm
>
> CERT (Computer Emergency Response Team at CMU)
> http://www.cert.org/
>
> Cisco: Internet Security Advisories
> http://www.cisco.com/warp/public/707/advisory.html
>
> Characterizing and Tracing Packet Floods Using
> Cisco Routers
> http://www.cisco.com/warp/public/707/22.html
>
> Cisco Product Security Incident Response (PSIRT)
> http://www.cisco.com/warp/public/707/sec_incident_response.shtml
>
> "Essential IOS" - Features Every ISP Should Consider
> http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip
>
> Know your enemy: Script Kiddies
> http://www.enteract.com/~lspitz/enemy.html
>
> Cisco Flow Logs and Intrusion Detection at the Ohio
> State University
> http://www.usenix.org/publications/login/1999-9/osu.html
>
>
> If anyone else has useful links (it doesn't matter who
> is the vendor, whatever), please let me know.
>
> - paul
>
> At 09:01 PM 02/11/2000 -0500, Vijay Gill wrote:
>
> > CC'd to NANOG, maybe we can move this there.
> >
> > On Fri, 11 Feb 2000, Paul Ferguson wrote:
> >
> > > It would allow the attacks to be traced back to the zombies (in
> > > the case of these DDoS attacks), and the perpetrators to be traced
> > > back and identified.
> > To make that easier, what is needed is something associated with a
> > downstream interface that is a part of the configuration itself, not a
> > separate access-list.  This makes it much easier to track on a large box
> > with many hundreds of customer links and so forth.
> >
> > Something like so:
> >
> > interface XXXm/n/p.q
> > description whatever customer
> > encaps ...
> > ip address x y
> > ip allow-source blocks-that-are-valid
> > ip allow-source ...more-blocks-
> >
> > so on and so forth.
> >
> > /vijay
Vijay Gill                         |The (paying) customer is always right.
wrath(_at_)cs(_dot_)umbc(_dot_)edu, vijay(_at_)umbc(_dot_)edu  |                
  - Piercarlo Grandi
http://www.gl.umbc.edu/~vijay      | Eagles may soar, but weasels don't get
These are my opinions only.        | sucked into jet engines.