North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: DNS issues various
- From: dre
- Date: Thu Oct 24 15:52:17 2002
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
rfc2827, rfc3013 (ingress and egress filtering)
rfc1750, rfc1858, rfc1948, rfc2196, rfc3128, rfc3365
rfc2142 (and draft-vixie-ops-stdaddr-01.txt), rfc1173, rfc1746, rfc2350
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?