Re: Internet SYN Flooding, spoofing attacks

Vijay,

We (at least cisco, anyways) already have a knob for this:

 [no] ip verify unicast reverse-path

We call it Unicast RPF.

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