February 2000 - Test - lists.nanog.org

RE: Yahoo! Lessons Learned
by K. Graham 10 Feb '00

10 Feb '00

On 8 Feb 2000, Sean Donelan wrote: > Date: 8 Feb 2000 03:25:36 -0800 > From: Sean Donelan <sean(a)donelan.com> > To: nanog(a)merit.edu > Subject: Yahoo! Lessons Learned > > > 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? Possibly. > > Was there something Yahoo!, GlobalCeneter or other providers could > have done, either individually or in cooperation, to prevent the problem? > Yes. One of the emails sent in, mentioned that a network they work with or for was being utilized as an amplifier. Each network that have gateway routers should ensure that they disallow IP broadcasts. It was mentioned that this was a co-ordinated attack. That meant a bit of planning and access to various machines. As to the number of attackers only Yahoo's internal people may know. Even then it may have only been one individual with a script that accessed many locations at one time and initiated the commands. There is the ability to do such an attack. The reality of "stay connected 24/7" at the household level with highspeed internet, makes the possibility of this attack more of a multi level victom attack. Home users do not know that they are leaving the door open to exploitation with simple Window's shares. Savy people gain access to the cable and dsl modem user's PCs and then launch their attacks. Small utilities are put in place to make it easier to find the exploited machines. Thus creating a network of available attack, harder to track connections. Education is a tool that can be used to inform customers. If each node on the Internet takes care of it's own doors then there will be less available launching pads. Thus making it a bit simpler to track an attack. Who or what will do the education is a question. Who are the responsible parties if no education is taken or given? To me, the responsiblity question is a nitemare at best. I just hope Yahoo's unfortunate incident opens some eyes, some lines of communication and education. K. Graham Network Analyst, CCNA kim(a)penguin-power.com

6 6

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

10 Feb '00

Daniel Senie <dts(a)senie.com> wrote: > While implementing these measures may not directly benefit your network, > doing so may thwart an attack against someone else's net. Tomorrow, the > roles could be reversed. As with many areas of managing the Internet, > cooperation is key. Yep. Actually, tier-1 ISPs can write the requirement for reverse-path source IP address verification on customer access circuits into their peering agreements. An enforcement can take a form of penalties per verified incident of forged source address attack originating in peer's network. (The adversarial IP perfix filtering was needed to institute such prefix-reduction policies as aggregation and address allocation out of ISP blocks. I remember that purely voluntary efforts were pretty much derailed by negligience of some ISPs (why AS 174 comes to the mind? :) I do not expect reverse path filtering to be any different in terms of deployment problems.) --vadim

6 5

Yahoo network outage
by Declan McCullagh 10 Feb '00

10 Feb '00

As much as I hate to derail a rollicking good Bob Allisat conversation, I was wondering whether anyone has some insight into what happened with Yahoo. The main site (although not all properties) has been offline since 10:30 am pt Monday. It doesn't *appear* to be Global Crossing's problem, though I can't be sure. GC is mum on the phone. -Declan

13 15

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

10 Feb '00

On Wed, 09 February 2000, Rodney Caston wrote: > It's because people are being very closed mouthed with this, the corps > either have no idea what is going on or do not wish to share what they > know, and those involved with the attacks have done a good job of keeping > silent. Besides comparing Morris's worm to what is going on now is hardly > fair, the net was a very different place then, and his cpu cycle hog of a > program was alot easier to deal with and detect. In past cases, the "crackers" have eventually been caught not by closed-mouth corps and law enforcement, but by "civilians." The closed-mouthness just seems to be extending the list of victims because the later ones didn't know how to protect themselves until after they got hit. Then after a few hours of downtime, they figure out which filters to install. Wouldn't it be nice to know what filters to install to protect your web site before it gets hit?

5 4

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

10 Feb '00

On Wed, 09 February 2000, Rodney Caston wrote: > I spoke with a person that claimed to understand the attacks that are > going on, while I have no proof, I offer this as an example of what to > look for on your own systems. So I am presenting this only as a possible > example of what has taken place, and until proven correct I concede this > is only a "rumor." Has anyone else noticed the dearth of technical information about these attacks? Although some of the largest web sites, and networks have been hit, I still haven't read a confirmed description of exactly what is happening. Its been three days. After the Morris Worm, by this point in time I had seen several technical descriptions and even portions of decompiled code. And I was just an interested Internet user in those days. In this case I still haven't seen confirmation if it was trino, tfn, something new, or what. Or even confirmation if it was a series of HTTP GETs or random packets, or some interesting corruption of a packet. Or if confirmation the attacks are coming from the same set of hosts or different ones for each attack. If it is the same set of IP addresses, could we RBL (or create a new RBL) them? Maybe I'm just on the wrong mailing lists.

3 2

Info on the DoS attacks.
by Rodney Caston 10 Feb '00

10 Feb '00

I spoke with a person that claimed to understand the attacks that are going on, while I have no proof, I offer this as an example of what to look for on your own systems. So I am presenting this only as a possible example of what has taken place, and until proven correct I concede this is only a "rumor." Basically it began by combining many scripts already in use for scanning system security holes, the script initially scans a range of IPs scanning each target system for various known exploits, once a system is compromised, the second half of the attack goes into effect. I believe it uses some form of remote execution via rcp once its been compromised to copy and execute what seems to be a specially made "DoS Daemon" to the host, once there it this daemon runs waiting to receive its orders from the people who put it there. Therefore, once enough systems were compromised in this fashion and enough systems on the net were unknowingly running this daemon, the attackers simply gave the order to hit the targets this week and their daemon's went to work. With this in mind we would need someone to find a box with this daemon on it so we can find a way to detect its existence on other systems. Logically, since the compromise of the systems was done with a script, this "DoS Daemon" would be setup the same way on every compromised system. Therefore, if someone can find it on one box, we will know exactly what to look for on other hosts. This of course will only help us if our own systems have been compromised and wouldn't be of any use at all for those boxes not within our control. One final note, a friend from Verio suggested that in the above scenario that this daemon would probaly be using TCP to be communicated with as UDP is more difficult for alot of people to code. Rodney L. Caston Southwestern Bell Internet Services

2 1

Re: NANOG meeting subject of attack? Hmmmm....
by robert＠UU.NET 09 Feb '00

09 Feb '00

> As Charles says, from what I've read of the CERT advisories, there is > nothing proactive one can really do for these DDos attacks, besides > securing machines from being hacked, correct? A site can use anti-spoofing filters on their router/firewall (even if the ISP can't or won't do it on their end) to make sure that their machines don't forge source addresses. This might stop any of their machines which have been compromised from really doing participating in the attack. (I say "might" because the slave daemons don't have to forge addresses.) Other misc. ideas are in: http://www.cert.org/reports/dsit_workshop.pdf (BTW, a "advisory" version of unicast RPF-type stuff would be immensely helpful in deploying URPF, "source validation," ingress filtering, or whatever you want to call it.)

1 0

Re: Yahoo! Lessons Learned
by robert＠UU.NET 09 Feb '00

09 Feb '00

> > i am rather amused at folk who fear dialup systems being used as ddos > slaves. > I'm more worried about a master being connected there. Remember, with at least one of the tools you can trigger the "slaves" via forged ICMP reply messages. It doesn't take a fat pipe to do that and it makes finding the perp that much harder, especially since dial connections are generally more anonymous. Yes, we have tested "source validation" in our live dial network. Yes, there is a performance impact. "Can do" or "Can't do" depends on how many dial customers you are trying to pile into one box, and what equipment you are using. Also, ingress filtering one-hop-up isn't necessarily so easy. Some of us will dynamically route prefixes other than /32 to certain dial customers. This complicates things.

2 1

Re: NANOG meeting subject of attack? Hmmmm....
by Bino Gopal 09 Feb '00

09 Feb '00

As Charles says, from what I've read of the CERT advisories, there is nothing proactive one can really do for these DDos attacks, besides securing machines from being hacked, correct? Also note that the link that Paul gave to the cnet story doesn't mention anything about NANOG (for those who were looking). That only came later tonight, by 8:30pm with this story: http://news.cnet/com/news/0-1005-200-1545456.html Also see CNN (as they got hit) at: http://cnnfn.com/2000/02/08/technology/yahoo/ Looks like the news organizations have picked up on the timing 'coincidence' (if it was one). Apologies if this is old news; I just didn't see any mention of it yet, and it seemed rather operational, given the nature of what happened. :) BINO On Tue, 8 Feb 2000, Charles Sprickman wrote: > On Tue, 8 Feb 2000, Christian Nielsen wrote: > > > > On Tue, 8 Feb 2000, Paul Ferguson wrote: > > > > > http://news.cnet.com/news/0-1007-200-1544910.html?dtn.head > > > > I guess the only way to 'protect' against something this big would be to > > follow Pauls RFC and/or have big, fat pipes sitting idle. > > It's my understanding that these recent attacks are DDoS attacks, which > really don't need to involve any address spoofing. The MO would look > similar to a smurf (many different source addresses bombarding you), but > here the negligent (call the lawyers?) party with the hacked Solaris boxes > running out-of-the-box configs would not be helped by said RFC, right? > > > This is a sad day for the internet. :( > > Just a reminder that we are working in a anarchic, non-cooperative > business, that's all :) > > Charles > > > Christian

2 1

IRR/RADB (was Re: Yahoo! Lessons Learned)
by Sean Donelan 09 Feb '00

09 Feb '00

On Wed, 09 February 2000, Henry Kilmer wrote: > Kai Schlichting writes: > >I recall that SprintLink had some, uhm, plans to put ingress (and > >egress?) filters on all interfaces facing dedicated customers that > >were not multi-homed. This came after realization that education of > > This becomes rather difficult to do properly when a large percentage > of an ISPs customer base are multihomed. The unicast RPF check knob > does not handle this situation so you are left generating access > lists which has different scaling issues to contend with. Still > doable but more difficult. I know this is in the category of beating a dead horse, but.... This sounds like the perfect application for the IRR/RADB.

1 0