On Thu, Oct 24, 2002 at 06:01:44PM +0000, Kelly J. Cooper wrote:
1999?! Doesn't anybody remember the massive SYN attack against Panix in 1995? Or that tfreak released smurf.c in July of 1997? (And was it fraggle or papasmurf that came the summer of the following year? Whichever one it was, the other came out within six months after that.)
Not to mention that the tools being publically available is much different than being known by a certain community (covert IRC blackhat communities differ slightly from EFNet which differs even moreso from CERT, etc). I recall working at GoodNet, and smurf attacks affecting customer networks the first week of May, 1997. There is speculation that the root name servers attacks were from a modified tool of a current well-known tool. How does that fit into the equation? Information needs to pass quickly and correctly. BUGTRAQ has typically been the best forum for this, and NANOG as well. However, Internet operators will continue to lag behind the times even if we have a more intelligent infrastructure capable of handling these problems. I see this being done on a organization-by-organization basis, but no real consistent community. The correct plan is to have one person dedicated to packet capture infrastructure, another person dedicated to packet-to-tool identification and reverse engineering, and finally a large group dedicated to filtering/moving the traffic with open or proprietary (including home-grown) solutions (proactively and upon peer/customer notification), e.g.: rfc2827, rfc3013 (ingress and egress filtering) rfc1750, rfc1858, rfc1948, rfc2196, rfc3128, rfc3365 rfc2142 (and draft-vixie-ops-stdaddr-01.txt), rfc1173, rfc1746, rfc2350 draft-ymbk-obscurity-00.txt, draft-ietf-grip-isp-expectations-05.txt draft-moriarty-ddos-rid-01.txt, draft-jones-netsec-reqs-00.txt draft-turk-bgp-dos-01.txt, draft-dattathrani-tcp-ip-security-00.txt http://www.secsup.org/Tracking/ http://www.secsup.org/CustomerBlackHole/ http://www.cymru.com/ http://www.tcpdump.org All of this information needs to be in one place, and organizations need to understand that working together on these problems in the only way to fix them (this goes doubly for hardware/software vendors). I'm sure I left out a ton of information, and the list could become exhaustive very quickly and easily. The ideas and the strategies all stay the same, and the end result is hopefully a more secure, resilient infrastructure. In some ways, you and your organization either get it or you don't. And there is no way to force people into understanding the concept - let alone the importance of these issues. How do you solve that problem? -dre