February 2000 - Test - lists.nanog.org

Re: Does Anyone Care?
by Bjorn Carlsson 11 Feb '00

11 Feb '00

Hi, Not sure I follow. schnell.ebone.net is actually an interface of Sprint icm-bb1-pen which connects to a FDDI ring in Pennsauken built for multicast. The name/address (schnell.ebone.net) is there for historial reasons and should be changed to something-else.icp.net. As for directed broadcast it is long since turned off on all EBONE routers. --BC > Ok, here's some more stuff on the directed broadcast out of the > Sprint NAP in Pennsauken, NJ. > > 1) Directed broadcasts weren't disabled at the Spokane, WA router and > whoever was doing this attack was aware of that fact. I managed to > disable it and write that change to memory. > > If you decided to check that router anytime soon (spn-brdr-01) check > the counters on the Fddi1/1/0 interface that links to the Pennsauken > NAP. You'll see that 99% of the traffic coming through are directed > broadcasts. > > 2) If you decided to restore the configuration on that router, I suggest > you go back in and disable directed broadcasts on the Ebone interface > (Fddi1/1/0) because it wasn't disabled when I initally logged in and > the directed broadcast still appears to be active (4:28pm EST, > February 10, 1999). > > traceroute to schnell.ebone.net (192.36.137.1): 1-30 hops, 38 byte packets > 1 vdi-dialup.vdi.net (209.201.95.2) [AS3951 - NETBLK-ICON-NET5] 109 ms 130 ms 110 ms > 2 router.vdi.net (209.3.31.1) [AS3951 - NETBLK-ICON-NET4] 110 ms 130 ms 120 ms > 3 Hssi3-0-0.border2.teb1.IConNet.NET (209.3.187.253) [AS3951 - NETBLK-ICON-NET4] 120 ms 139 ms 120 ms > 4 POS10-0-0.core1.teb1.IConNet.NET (204.245.71.201) [AS3951 - ICon CMT Corp.] 120 ms 149 ms 120 ms > 5 205.171.4.217 (205.171.4.217) [AS3909 - Colorado Supernet, Inc.] 119 ms 149 ms 120 ms > 6 205.171.4.134 (205.171.4.134) [AS3909 - Colorado Supernet, Inc.] 140 ms 158 ms 120 ms > 7 schnell.ebone.net (192.36.137.1) 230 ms (ttl=244!) 259 ms (ttl=244!) * > > Notice the latency jump at the last hop, five other traceroutes showed > similar data. > > 3) Check the NYC core router (nyc-core-01) and look at the Teleglobe and > Spokane interfaces, earlier that day, there was approximately 75mbps > coming in on the Teleglobe interface (POS0/0) and the same amount being > output to the Spokane-bound interface. > > 4) I shutdown the Sprint interface (Fddi2/1/0) on the Spokane border > router for about 30 seconds, and there was approximately a 5mbps > decrease in the directed broadcasts coming from Ebone at the Pennsauken > NAP. > > 5) I then shutdown the Ebone interface (Fddi1/1/0) on the Spokane border > router for about 30 seconds, and there was approximately a 10mbps > decrease in the outgoing traffic of the Sprint interface (Fddi2/1/0). > > 6) The interface statistics on the Sprint interface (Fddi2/1/0) showed > there were some broadcasts being sent, but not as numerous as the Ebone > the interface, I would advise you check the other side of that > interface for abnormal activity. > > 7) If you normally keep track of all your customers' bandwidth > utilization, look for excessive peaks in the incoming and outgoing > paths along with for anything that has jumped excessively in the past > three days. > > Omachonu Ogali > Intranova Networking Group >

1 0

Re: Fair Queuing combats DDoS? [was Re: Yahoo! Lessons Learned ]
by Alex Bligh 11 Feb '00

11 Feb '00

alex(a)genesyslab.com said: > No, the key issue is _frauded src addresses_. All others can be > remedied easily. In my opinion the issue is allowing the clueful to scalably protect their networks against those of the clueless or fallible who do not and will not deploy RPF nor secure their servers any time near now. In the mean time, those who want to survive in the market place better put their clue to use and work out how to protect their networks without relying on the actions of others. This is roughly equivalent to saying "lock your door" when you leave your house, rather than complaining that "the *real* problem is actually thieves, and this is what we need to fix". In the words of Mr Bush, I want something for clueful people to be able to type after "conf t". Asking people who probably aren't on this mailing list and almost certainly don't understand the problem to fix *their* network does not cut the mustard. -- Alex Bligh VP Core Network, Concentric Network Corporation (formerly GX Networks, Xara Networks)

3 2

ASO mailing list announcement/reminder
by Kim Hubbard 10 Feb '00

10 Feb '00

Reminder: ICANN ASO - Website and Discussion Lists This is an announcement to all parties with interests in management of Internet Address space and related resources. The Address Supporting Organisation of ICANN (the Internet Corporation for Assigned Names and Numbers) was established last year, and has assumed its responsibilities under the ICANN Bylaws for coordination of global policy development in relation to Internet Addresses and related resources. The nine-member Address Council has also been established, in accordance with the ASO MoU and ICANN Bylaws. Since its establishment, the ASO has established mailing lists and a website to ensure that its processes are open and transparent, and accessible to all parties with an interest in Internet resource management issues. Three ASO mailing lists are now available for public access to ASO information, and for input into the ASO process: aso-announce - for announcements and other information relating to the ASO (read only list) aso-policy - for open discussion on policy and other ASO matters (open subscription list) aso-comment - for comment and input of any kind (no subscription necessary) The ASO website is also now available, at http://www.aso.icann.org, and carries information relating to the ASO, Address Council, and policy matters which may be under consideration; as well as complete archive of the above mailing lists. At this time the Address Council is seeking participants in the ASO process, and encourages all interested parties to subscribe to the mailing lists above. For information on how to subscribe, please visit the ASO website. We look forward to your participation! Paul Wilson for the Address Council and ASO Secretariat.

1 0

Re: Yahoo! Lessons Learned
by Vadim Antonov 10 Feb '00

10 Feb '00

Just a thought - strict RPF at all ingress points, in combination with Fair Queueing keyed on something like 24 high-order bits of source IP address in transit routers would render any high-rate flooding attack pretty much harmless. --vadim

13 12

Re: Yahoo! Lessons Learned
by Sean Donelan 10 Feb '00

10 Feb '00

On Thu, 10 February 2000, Vijay Gill wrote: > Of course, given that we can get netflow type packet histories, plotting > the src/dest pairs for a while and then if there is a _large_ change (some > n std dev) from the norm for some particular dst (nominally the one under > attack), and then raising an alarm on that router/pipe, would make it > trivial to trace these type of attacks. With history storage, it would > make it easier to trace back after the fact. I've wondered what type of statistical sampling could be used to find these attacks, but not require huge amounts of storage. The theory is these are very large traffic flows which congest the pipe and push other traffic out of the way. If you sample 1% of the traffic, and 99% of the sample is the same src/dest pair, something may be fishy.

3 2

Re:FBI / NIPC released a DDoSD detection tool? (Look in the binary)
by mpotter＠atpco.com 10 Feb '00

10 Feb '00

At 10:44 AM 02/10/2000 -0600, you wrote: > >I'm not sure if this is news or not, but looking at >http://www.fbi.gov/nipc/trinoo.htm - it seems the NIPC has released this has been out about since late Dec >binaries, (no source code, the jerks), for tools to detect if a box has >trin00, tribal flood net, tfn2k and some other DDoSD's on it. Heh, who in their right mind installs something w/o source.... Especially from the FBI ;)They are the ones that want to BACKDOOR every crypto product... It looks like a packet sniffer that just looks for the fingerprints of these attacks. Nothing really special. It even looks like it has the exploit compiled in(strings , nm -Du, ldd the binary), probably cut and paste work. The fact that they have it only for Solaris(SPARC and x86) and Red Hat tells you those are the only types of boxes they have, or the only thing they could get it to work on. Matt

2 1

Yahoo! Lessons Learned
by Sean Donelan 10 Feb '00

10 Feb '00

As much as I enjoy finding out about Yahoo & GlobalCenter issues by reading the newswires, I wonder if there are any lessons we can learn from these events. Or was this not big enough to get attention of upper management? Was there something Yahoo!, GlobalCeneter or other providers could have done, either individually or in cooperation, to prevent the problem? Likewise, could they, individually or in cooperation with other providers, have shortened the duration or severity by doing something different? And finally, would they be more successfull in tracking the source the the problem by doing something different?

9 10

Re: Fair Queuing combats DDoS? [was Re: Yahoo! Lessons Learned ]
by Alex Bligh 10 Feb '00

10 Feb '00

Alexei Roudnev (alex(a)genesyslab.com) said: > [deploy WFQ and RPF universally] > Then , if someone want to kill yahoo (for example), he need a few > thousands different data streams to do it - which is impossible. Several thousand different data streams is exactly what DDoS is. Also there is a presumed high correlation with people who do not secure their servers adequately againts intrusion (and thus turning these things into DDoS clients) and people who do not run RPF right next to those servers. Therefore this is only 'impossible' if there are not more than 2000 servers sitting on clueless or fallible peoples network. Recent experiences with internet scaling suggest even if this were true now (which it isn't), it won't last long. -- Alex Bligh VP Core Network, Concentric Network Corporation (formerly GX Networks, Xara Networks)

1 0

Re: [Re: Which Part(s) Failed in the recent DOS Attacks?]
by Toplez Razer 10 Feb '00

10 Feb '00

Joe, Firewall-1 has the SynDefender and Cisco IOS 12.0 has TCP Intercept for stopping TCP DOS. Could these features stop massive TCP DOS attacks? Thanks, Audie Onibala ****************************** Joe Shaw <jshaw(a)insync.net> wrote: On 9 Feb 2000, Toplez Razer wrote: > 1. Was it the firewall DOS filter? With packet based DoS attacks, filters don't matter. Bandwidth and saturation are what matters. > 2. No firewall in Yahoo, EBay, ETrade, etc? Yes, there are, and no, they wouldn't have helped for the reason stated above. > 3. Firewall DOS filter worked, but the links were still clogged with massive > ACKs/NACKs? Not exactly, but fairly close. -- Joseph W. Shaw - jshaw(a)insync.net Computer Security Consultant and Programmer Free UNIX advocate - "I hack, therefore I am." ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1

3 3

Re: Info on the DoS attacks.
by Sean Donelan 10 Feb '00

10 Feb '00

On Wed, 09 February 2000, Joe Shaw wrote: > I'd be worried if they didn't have theories or know about the known DDoS > attacks, but not if they didn't have specifics. Tier1 NSP's seem to be > very tight lipped about these sorts of things when they are the > victim. I'm sure there are GC employees on this list, but none have come > forward to give any details. Could be a gag order, which wouldn't shock > me at all. Hopefully we'll know something eventually, but for now we're > all mushrooms when it comes to official information. I guess the techies reduced to reading the New York Times for technical details. Today's NYT has a description from GlobalCenter's PR person. The Yahoo attack was a large number of ICMP EchoReplies(PINGs) coming via GlobalCenter's 50 peering connections (about half of GlobalCenter's total peering connections). Which may explain the "50" number I've been hearing. The original ICMP EchoRequests listed Yahoo as the source address and were directed to other networks which replied to Yahoo. GlobalCenter installed rate-limits, but didn't know if they are effective in preventing attacks. Yahoo's spokesperson confirmed GlobalCenter's account. (free NYT registration required) http://www.nytimes.com/library/tech/00/02/biztech/articles/10attack.html Note: other people have sent me private mail saying it was actually a different method, but this appears to be the official statement out of GlobalCenter and Yahoo.

2 1