- NANOG - lists.nanog.org

09 Feb '00

I'm wondering if there are any mailing lists or other resources concerning building, designing, and maintaining Data Centers. I've found some vaguely helpful resources from netsearches, but so far I've been pretty disappointed with the amount and level of the available information. Are there any books? Any respected "authorities"? Is everyone learning as they go, or are all of the new Internet DC's being built by old-school mainframe/datawarehouse types? Any related information would be appreciated. Use private email unless you enjoy being spanked by the nanog.police (I'm sure someone will think Data Centers have nothing to do with network operations). -Brian

1 0

Re: Yahoo offline because of attack (was: Yahoo network outage)
by George Herbert 09 Feb '00

09 Feb '00

Scott Crowby wrote: >George Herbert wrote: >> Assume there's 40k of data in the homepage. >> How many bytes of SYN-SYNACK-ACK-GET / HTTP/1.0\n does it take >> to do a TCP connect and request? I just tested, I show 160 bytes. >> That's a 250:1 leverage for the attacker. To fill 1 GBPS worth >> of outbound trunking you only need to generate 4 MBPS (32 Mbps) >> worth of input. 50ish systems with T-1 connectivity gets there >> with margins. > >I don't have posting privledges on NANOG, so forward if you think it is >appropriate... But this is false, >Yes, you can send 160 bytes and the HTTPD will attempt to send 40kb, but >the TCP stack won't actually send it all unless it gets ACK's from the >reciever, which means that the reciever has to be able to accept at least >some of that traffic. If there is sufficient congestion to keep the >traffic from arriving and ACK's being sent, the sender will slowdown. >So this type of attack would be throttled on the initiator's side through >TCP slowdown and missed ACK's. I missed this when I origionally posted last night, but not completely. If attacker has raw socket or TCP stack manipulation on the attacking box then they can "cheat" and pre-send ACKs for data not actually received yet once the connection opens up. This is explained in detail in several articles in the ACM SIGCOMM journal over the last year and other sources. It requires a bit more work by the attacker but forces the victim to send all the data (most of which is then discarded silently by routers somewhere upstream of the attacker due to congestion, and not noticed by the victim because of the faked ACKs). In reality the technique hits statistical limits due to that congestion losing the SYN/SYNACK/ACK/HTTP GET packets needed to set up the connections in the first place, although all of those are re-sent if not properly acknowledged the throughput of TCP drops through the floor as loss rates increase as high as they will when doing this type of attack. But if bigger packets are more likely to get dropped (typical attack total packet 60 bytes, response 1k) then you can get a fair leverage out of it even so. -george william herbert gherbert(a)crl.com

1 0

RE: Yahoo offline because of attack (was: Yahoo network outage)
by Declan McCullagh 09 Feb '00

09 Feb '00

At 10:37 2/9/2000 -0800, Patrick Greenwell wrote: >It would make one hell of an excuse for those wishing more government(s) >involvement/control.... Even though I live in DC, I'm not that conspiratorial. Though I do note that the attack started the same day the president introduced his budget, which has a big increase in "cyberterrorism" defense and a HUGE increase in wiretappability funding :) More: http://www.wired.com/news/politics/0,1283,34164,00.html -Declan

1 0

etrade+zdnet reported attacks
by Jared Mauch 09 Feb '00

09 Feb '00

cnn.com reports more attacks. are folks locking down their source-filtering this week? please do. I understand this will not help with all attacks, but it should continue to help. - jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE |

1 0

Congestion or regression testing DDoS
by Sean Donelan 09 Feb '00

09 Feb '00

After finding out more about the current round of denial of service attacks, I think I have an answer for several of the periods of congestion different providers experienced during the last couple of weeks of January. In January there were several reports of unusually large amounts of traffic. This caused congestion problems at several different places, but no provider or company made any public reports. With 20/20 hindsight it appears someone was testing how well their DDoS tool worked on less noticable sites. The engineers I spoke with indicated they saw heavy congestion on certain links for a few hours, but it would stop on its own accord. Later, they would see the same congestion, and again it would stop. If you think of it as "congestion" instead of a DoS, are there any tools we use to control congestion which could be adapted to lessen the effects of a DoS? Would RED(and RED variations), rate limiting, or any of the many QoS knobs help?

3 2

Re: Yahoo offline because of attack (was: Yahoo network outage)
by George Herbert 09 Feb '00

09 Feb '00

Roeland wrote: >I smell denial here. The compromised systems (only 52?) had to have access >to pipes at least 1 Gbps in size, in order to carry out this attack (do the >math yourself). Either there were many more systems participating (in itself >a scarey thought) or many of these large and professionally run systems are >owned and their operators don't know it. The only other alternative is the >conspiracy theory from hell. No, they don't. Assume there's 40k of data in the homepage. How many bytes of SYN-SYNACK-ACK-GET / HTTP/1.0\n does it take to do a TCP connect and request? I just tested, I show 160 bytes. That's a 250:1 leverage for the attacker. To fill 1 GBPS worth of outbound trunking you only need to generate 4 MBPS (32 Mbps) worth of input. 50ish systems with T-1 connectivity gets there with margins. [Note that this is an a priori analysis; I haven't bothered to find the attack codes in question and see if that's what they're doing, nor am I involved in any of the current operational response] Back in Nov 1996 when Sun was pushing WebNFS initially with the Solaris 2.6 release, I wrote up a vulnerability analysis white paper using the UDP NFS functionality and this leverage approach and sent it in to Sun. I suspect the ultimate inability to secure against it was one reason WebNFS died on the vine. With full HTTP, you need more request bytes and a valid origionating IP address since it's TCP... you need the SYN, SYNACK, ACK to work before you send the request. But there's enough leverage anyways with modern pagesizes (8k was big then, it's nothing now... 40k worth of html is typical) for it to work anyways. The only downside to doing it in HTTP is that all the attacking systems are clearly identified since they have to use real routed IP addresses. -george william herbert gherbert(a)crl.com

3 2

Re: NANOG meeting subject of attack? Hmmmm....
by Paul Ferguson 09 Feb '00

09 Feb '00

At 01:25 AM 02/09/2000 -0500, Bino Gopal wrote: >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: I was attempting humor. The linkage was Exodus, who hosted this NANOG (and they did a great job of noth connectivity at NANOG, as well as mitigating the DDoS attacks on ther customers). - paul

1 0

NANOG meeting subject of attack? Hmmmm....
by Paul Ferguson 09 Feb '00

09 Feb '00

See: http://news.cnet.com/news/0-1007-200-1544910.html?dtn.head - paul

7 7

RE: Yahoo! Lessons Learned
by Ron Buchalski 09 Feb '00

09 Feb '00

Ken writes: >From: "K. Graham" <kgraham(a)ican.net> >To: nanog(a)merit.edu >Subject: RE: Yahoo! Lessons Learned >Date: Tue, 08 Feb 2000 09:47:58 -0700 > <snip> >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. It's an interesting coincidence that, at roughly the same time that the attack was taking place, we were sitting in the NANOG meeting listening to a presentation on Distributed Denial of Service attacks. It's definitely a major threat... -rb ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Strange announcements for www.cisco.com
by Neil J. McRae 09 Feb '00

09 Feb '00

To QWEST NOC PEOPLE Folks, You appear to be announcing 198.133.219.0, which is the network that www.cisco.com lives on, whats strange is that you are then transiting this route onto GTEI [AS1] to deliver the traffic. This is fairly sub-optimal and I'm sure incorrect. kenny>sh ip bgp 198.133.219.25 BGP routing table entry for 198.133.219.0/24, version 23258497 Paths: (4 available, best #1, advertised over IBGP) 3356 209 209.244.160.57 from 209.244.160.57 (209.244.2.210) Origin IGP, metric 4401, localpref 100, valid, external, best 3356 209, (received-only) 209.244.160.57 from 209.244.160.57 (209.244.2.210) Origin IGP, metric 4401, localpref 100, valid, external 1 109 4.1.74.105 from 4.1.74.105 (4.0.4.8) Origin IGP, metric 11340, localpref 100, valid, external Dampinfo: penalty 492, flapped 1 times in 00:00:23 1 109, (received-only) 4.1.74.105 from 4.1.74.105 (4.0.4.8) Origin IGP, metric 11340, localpref 100, valid, external kenny>traceroute www.cisco.com Type escape sequence to abort. Tracing the route to www.cisco.com (198.133.219.25) 1 serial4-0-3.hsa1.nyc1.Level3.net (209.244.160.57) [AS 3356] 0 msec 0 msec 0 msec 2 hsipaccess2.Denver1.Level3.net (209.244.2.61) [AS 3356] 48 msec 48 msec 48 msec 3 hsipaccess2.Seattle1.Level3.net (209.244.2.23) [AS 3356] 76 msec 72 msec 76 msec 4 209.0.227.130 [AS 3356] 76 msec 200 msec 148 msec 5 sea-core-01.inet.qwest.net (205.171.26.53) [AS 209] 76 msec 72 msec 76 msec 6 sfo-core-02.inet.qwest.net (205.171.5.105) [AS 209] 84 msec 84 msec 84 msec 7 sjo-core-01.inet.qwest.net (205.171.5.121) [AS 209] 80 msec 80 msec 80 msec 8 sjo-edge-05.inet.qwest.net (205.171.22.46) [AS 209] 84 msec 84 msec 80 msec 9 a5-0-1.sanjose1-nbr1.bbnplanet.net (4.24.145.1) [AS 1] 84 msec 84 msec 84 msec 10 p4-0.paloalto-nbr2.bbnplanet.net (4.0.1.1) [AS 1] 84 msec 84 msec 84 msec 11 p0-0-0.paloalto-cr18.bbnplanet.net (4.0.3.86) [AS 1] 84 msec 84 msec 84 msec 12 * * * 13 pigpen.cisco.com (192.31.7.9) [AS 109] 88 msec 88 msec 88 msec 14 www.cisco.com (198.133.219.25) [AS 209] 88 msec 84 msec 88 msec A fix/explanation would be useful. Regards, Neil. -- Neil J. McRae C O L T I N T E R N E T neil(a)COLT.NET

1 0