According to Certicom, they expected the challenge to take 90 million machine-days to complete. But The Winners say they took 547 days, with 10308 members. They don't list how many machine days they got (presumably it ramped up as they went along), but that multiplies out to ~5.5 million machine-days.
So where's the discrepancy? Did we get really lucky and hit the answer 5% of the way through the search? Do the "10308 members" really represent 10 machines each? Did the initial estimate assume 500MHz machines and by 547 days later, most people were running 1.5GHz machines? Or did the implementers do some good programming hacks to make a much faster search program? Or was one of the implementors using Pixar's rendering cluster at night in between movies?
Not everybody uses Kerberos, but this is one of the most important implementations, and makes it possible for a cracker to give himself permissions on all your machines. Basically, you'd better move your zig and fix this. It's especially likely to be used at universities, which turn into big zombie farms if kerberos gets cracked.
By the way, this interacts with the Quantum Computing discussion threads, because if it's possible to factor big numbers, public-key crypto no longer works, so the fallback for authentication is to use symmetric-key systems like kerberos.
MS only runs on a much more uniform set of hardware, and vendors do often provide MS with better driver support than they provide Linux. And most installs do work most of the time. But even then they don't correctly install everything - if you've got newer hardware, you need to install driver disks for it, and if you're running one of the Administrator-oriented OSs, such as Win2000Pro, you can get into issues with user permissions - either you can't install something as a regular user, or you become Administrator to install it and the permissions get set in a way that you can't use it later when you're logged in as your regular user account again.
According to SETI Stats by Country, there are 212334 Canadian PCs running SETI@Home. I don't know how real these stats are (lots of these may be people who ran the thing once in the past, or who don't run it full time, and obviously this includes lots of computers slower than what you'd build into a modern Beowulf cluster, but it's still quite a bit larger than the network these guys are building. While some of the SETI@HOME network is still listening for space aliens, it's also running a number of earthbound projects like studying protein folding and searching for cancer drugs.
There are real benefits for Canadian research that can come from this project - certainly there are a number of problems that are numerical and parallelizable, so there can be a lot of future to it if they do enough coordination, but most of Canada's academic supercomputing is currently driven by SETI. Besides scientific research, the other traditional users of supercomputers are weather prediction, oil exploration, and sometimes financial modelling - Canada may have more total supercomputer-based supercomputing than anybody realizes, in addition to SETI. However, the June 2002 top500.org list doesn't show anything in Canada above #227.
Other results from the Top500.org list - SETI@Home is still about 7 times as large as the largest single machine on the list , Japan's NEC Earth Simulator, which is about 5 times as large as the #2 machine, LLNL's ASCII White.
While there are some physicists who'd do that, it's much more likely to be some computer science major who fixes the 1ppm roundoff error that the physicists' code was making (or some math jock who's neither one.) I was an Operations Researcher in college, and later at Bell Labs I was running a computer center used by some of our physicists to do some network simulations. I found that they were using a linear linked list to handle the event list, and converted it to a heap - and was disappointed to find that it only sped the whole program up by a factor of 3-4 instead of 5-10:-)
On the other hand, their code basically jumped around in a large matrix, without much locality, because that matched what the real system they were modelling would do. They needed 12-14 MB of table space for the system they were modelling, and our VAX 11/780 only had 4MB of RAM, so I played with a number of virtual memory operating systems (4.1BSD, SVR2.0p, various tunings) to get something that would survive being thrashed to death, and helped them do a lot of work on checkpointing their code, because their standard run took a week, and even if something else didn't cause the machine to crash, we'd get power hits during summer thunderstorms. After about two years of this, the price of RAM dropped to the point that we could afford to upgrade the machine to 16MB, which made our run time drop to about an hour....
Meanwhile, that Cray-1 of yours was mostly similar in performance to a Pentium 133, and some of the recent graphics chips have really immense memory bandwidth, though they're mostly running fixed-point or at best single-precision floating point rather than double-precision or quadruple-precision, so they're not *quite* a Cray-replacement even though they're faster at many things.
Not everybody's against global warming, eh? I once got yelled at by a Canadian ex-pat for wearing a Greenpeace t-shirt, because I was clearly an enemy of Canada.
Actually, climate change has been a real problem for the ecosystem of the north coast, with a lot of ice melt and more open water than usual. One of the effects is that seals have more of the year, or in some places year-round, that they can find open water instead of making breathing holes in the ice. Polar bears and the traditional Inuit hunting methods both depend on catching seals at their breathing holes, so their hunting is much less effective.
On computer-related topics - laptop batteries really don't like background CPU-burners. I used to run the GIMPS Great Internet Mersenne Prime Search, and I used to commute by train, with about an hour of battery time each way. NiMH batteries don't have the same failure behavior as NiCD, and they're nowhere near as nasty a toxic waste disposal problem, but they really don't like this kind of treatment. To compound matters, for some of that time period, I was running Windows NT 3.51, which was much more stable than Win95, but it insisted on being a *server* operating system that didn't need laptop power management drivers, so when it got a hardware low-power shutdown signal, instead of going into hibernation mode (see, the polar bears *were* relevant), it would blue-screen and die. I had to stop running the prime search.
I wasn't sure if the poster was using TiVO or just using a capture card in his PC (my guess was the latter), but hard disks are not only faster and more useful than CD-RW, they're cheaper. Typical IDE prices are $80 for 80GB, which is $1.00 per GB, or $0.70 per 700MB CD-equivalent. (I just paid $10 for 10 CD-RWs at Fry's last week, so this is slightly cheaper.) Plus you don't need to worry about whether the video exactly fits on one disk. And if you're burning it on a disk, CD-Rs are about $0.10-0.15 for cheap stuff.
The one exception I can see to this is if you're using the CD as a data transport mechanism, between your PC in the office with the fast data connection and your DVD player in the living room.
This Anoto pen wants to be your friend every page you send we know end to end we'll be watching you.
Every word you write every pen you bite every thing you draw that's what we just saw we'll be watching you
every check you sign it knows just what time when you draw a line all your base are mine we'll be watching you.
Maybe it's gotten better, but the initial Anoto documentation indicated that they handled coordination of everything written using Anoto. It's closely related to the fact that Anoto has a global data space for their paper - each piece is unique, and which lets them build interesting and special applications if they can see all the data, and part of their business plan was to sell off pieces of the map to companies who wanted to do things with it. There was some encryption stuff build in, but no real documentation on what information was available to whom. For most applications, that's not necessary - the user's PC could do most applications standalone, using the address space to do relative calculations (using x and y distance from the starting point, if the algorithms support that without central processing.)
I couldn't tell from the web page whether.NET was used just as a bunch of libraries (e..g for communicating with the pen via USB) or if it was also used to talk to Anoto themselves, or to Logitech - does anybody have more information?
No thanks - the back covers were enough. What's surprising is that "The Eye of Argon" appears to date from 1970, which is early enough that the author probably hadn't read the Gor books at the time; it looks like the earliest one of them was 1969 or so.
When I had a DSL system in my lab with Win95 and RedHat6.x machines exposed to the wild internet, it used to really annoy me that it was always the Linux boxes that got cracked. This was partly because there wasn't much you could do with the Win95 machine (it did have a web server, but it wasn't a really common one so there probably weren't any well-known exploits), and partly because Linux systems are much more useful to crack, besides having well-known exploits for out-of-the-box distributions. RedHat 7.x was a lot cleaner; I don't think any of those boxes got cracked before we reconfigured the network, plus we weren't running WUFTPD. On the other hand, if you've cracked a machine thoroughly enough, and don't mind having your changes be visible, it's really easy to turn Windows into a useful scripting engine - a couple megabytes of UMSDOS file system, LILO, and yer up and running.
The more serious attacks using Windows would be easier to implement with a wetware-propagated Trojan Horse, such as a popular Kazaa-replacement client, or else with Yet Another Windows Outlook Email Virues. I'm sending you this DDOS client in order to have your advice.
There aren't many people who have a good reason to be sending ICMP traffic to a root server, especially since traceroute is supposed to be UDP. It's probably not something that the people who administer them should be leaving on routinely unless it's filtered to only allow authorized addresses to use it. Besides ping, most of the redirects and similar features are probably inappropriate here, and Source Quench may be something appropriate for the root servers to tell other machines, but not the other way around.
Of course, the next attack won't be something dumb like ICMP - they'll try something new, either because they learned a lesson from the people who did this one, or because they suspect they'll get their butts kicked if they try this method. For instance, I'd really rather *not* see the next Outlook Email Virus mail stuff to the root servers, or to randomized non-existent 2LD.COM addresses... I'm sending you this DNS request in order to have your advice
You don't need to charge for it, or at least don't need to charge big bucks for it, though it'd be an interesting alternative to ICANN's current funding practices. But you could restrict access and enforce technical requirements, e.g. if you want to connect, you need to maintain your own distributed caching servers. DNS is important, but the lookup-related parts of the.com/.org/..net 2LD database (as opposed to the whois and billing records and other registrar stuff) aren't that big - probably 100-300MB, most of it expiring in ~7 days. You could also use push mechanisms to distribute it to big sites, or even (gasp!) Usenet!
If you wanted to be a bit more democratic about access, you could provide priority service (or push service) to the big ISPs' main servers, and volume-restricted service to the free-use crowd. It's most important that the ~20 Tier 1 ISPs have good copies, because most of the smaller ISPs get connectivity from one or more Tier 1s, so they could get DNS as well.
A fun side-effect of making direct DNS access expensive would be that it would encourage more people to use the alternate root providers, who used to have about 0.5% of the market, except I think some of the cable modem companies were using alternate roots to have more options for selling namespace to their customers.
There's been a lot of interesting work done on how to trap and trace forged traffic, though it's easier when it's one location creating lots of it rather than lots of locations creating lots of it. You can play games with BGP or even static routes to grab traffic from your different peering points that's addressed to the target and hand it off to dedicated routers using GRE tunnels, etc.
Also, some of the press about the attack said it was using ICMP rather than UDP, and it's much easier to go around squashing ICMP than trying to figure out which correctly-formed queries for foo.com are real and which are DDOS.
It's probably not Earthlink/Mindspring/Netcom/Borg's best name server, but I memorized it years ago because I had to keep typing in the bloody thing any time I reconfigured Windoze, and when my internet connection wasn't working right the first step was to ping and traceroute the name server to make sure it was behaving.
I won't post the addresses to avoid slashdotting them, but several of the root-servers have graphs for response-times as well as traffic-levels. On some of the servers, the response-time went up, but on a number of them it went to zero for an hour or so, which I assume means no response rather than infinitely-fast response. Somebody set them up the bomb.
The first time a given technique gets used, it may be sophisticated, but after that it's often just script kiddiez. Some attacks are pretty crude, just borrowing a few thousand 0wned machines and slashdotting a victim, but some DOS attacks really do use some insight and then use the distributed attack as a lever, or as a way to hide the source of the attack. The clever attacks look for the critical resources on the target machine and tie those up. Sometimes that's something like the TCP SYN attacks which create half-open sessions to clog tables, but those can be easier to block, and they often depend on forged source addresses, which can be traced by a persistent ISP. Other attacks look more like brute force - find the asymmetrically resource-intensive part of a real transaction (like doing CPU-burning digital signatures, or downloading a really big file or causing some thrashy database lookup) and flooding that with lots of real transactions from your zombies, which is harder to block without also blocking real transactions from real users. In some cases, the crude attacks also work well because the fix requires applications programming so it's not something your ISP or router can just block for you.
But, yeah, some of the attacks aren't much different than using a loudspeaker to announce "Free Beer at Victim.com"
I never played much with those little 5ESS things, though we did use them for PBXs on one project:-) The 4ESS used to be powered by the 3B20 Duplex computer running DMERT, though I think they eventually replaced it with Tandems. All of the big switches were distributed-architecture machines - the CPU's job was mainly to control configurations and make sure all the parts were happy, but many of the cards had their own processors.
The 3B20 was a bit-slice architecture that predated the WE-32000 and 32100 microprocessor chips in the 3B2/3B5/3B15 series. It was roughly a VAX-780 class machine, i.e. about 1 MIPS and two refrigerators for the main computer plus another for the UPS (4 truck batteries...) The 3B20 Duplex machines had two CPUs running two halves of an operating system (which was DMERT rather than UNIX, but had a UNIX layer on top of it) - you could upgrade the OS while the thing was running.
It's not just caching the pointers from . to.com or.zr, it's the caches of the 2LD names in.com that matter. (.org and.net are important, but.com is the really annoying failure. And country-code name service gets handled elsewhere, though taking down.co.uk might be a target also.)
For the most common 2LD names, any major ISP will have cached the addresses for them, and won't need to hit the.com server until the typical 1-week or 24-hour cache timeout periods. If your nameserver is ns.bigisp.net, somebody there will have looked up google.com in the last 2 seconds, even though nobody at your ISP has looked up really-obscure-domain.com this week - but even that one may be in the cache because some spammer was out harvesting addresses. An obvious scaling/redundancy play for the root servers and for the major ISPs would be to have them cache full copies of the root server domains to keep down the load and reduce dependency. It's not really that much data - 10 million domains averaging 30 characters for name and IP addresses is only half a CD-ROM. An interesting alternative trick would be for the Tier 1 ISPs to have some back-door access to root-level servers for recursive querying.
The attack only lasted an hour or so, didn't affect all the servers, and if most of the sites you were looking at were in your ISP's DNS caches, you wouldn't have hit the root servers anyway. If you're looking for google.com, your ISP's cache has it because somebody else looked at it 2 seconds ago - it's when you want really-obscure-domain.com that you need to hit the root servers.
100 meters isn't very big. It'd be cheaper to ship that much stuff uphill ourselves rather than lassoing this one. Other nearby asteroids, such as Cruithne, would be more interesting possibilities, though I'd hate to have to fill out the Environmental Impact Report for potential hazards of mistakes....
I haven't seen the particular tripe you're referring to (I'm assuming you're talking about a particular instantiation of Donaldson's Law* as opposed to the whole SF genre), but there have been a number of SF stories and novels using the "planet on the other side of the Sun where we can't see it" plot device. Sometimes it's named Nemesis, though that name has been used more seriously for Sol's hypothetical relatively-dark companion star.
Beethoven's been dead for a long time, but you seldom listen to a pre-Steamboat-Willie performance of Beethoven's music. Usually what you listen to is some modern orchestra that performed and recorded the music in the late 20th century, either under modern copyright laws or under pre-Berne US copyright laws. So you're buying a Deutsche Grammophon recording of Furtw"angler's 1929 Berlin Philharmonic performance of Beethoven's 5th(that one's listed as "dubious") or EMI's 1954 recording of the same piece with Furtw"angler conducting the Vienna Philharmonic, possibly in a form remastered by somebody else and printed by the El Cheapo Classical CD Society in 1998. Piracy's not unknown even in classical circles...More dubious recordings
Slashdot Mirror
So where's the discrepancy? Did we get really lucky and hit the answer 5% of the way through the search? Do the "10308 members" really represent 10 machines each? Did the initial estimate assume 500MHz machines and by 547 days later, most people were running 1.5GHz machines? Or did the implementers do some good programming hacks to make a much faster search program? Or was one of the implementors using Pixar's rendering cluster at night in between movies?
By the way, this interacts with the Quantum Computing discussion threads, because if it's possible to factor big numbers, public-key crypto no longer works, so the fallback for authentication is to use symmetric-key systems like kerberos.
MS only runs on a much more uniform set of hardware, and vendors do often provide MS with better driver support than they provide Linux. And most installs do work most of the time. But even then they don't correctly install everything - if you've got newer hardware, you need to install driver disks for it, and if you're running one of the Administrator-oriented OSs, such as Win2000Pro, you can get into issues with user permissions - either you can't install something as a regular user, or you become Administrator to install it and the permissions get set in a way that you can't use it later when you're logged in as your regular user account again.
There are real benefits for Canadian research that can come from this project - certainly there are a number of problems that are numerical and parallelizable, so there can be a lot of future to it if they do enough coordination, but most of Canada's academic supercomputing is currently driven by SETI. Besides scientific research, the other traditional users of supercomputers are weather prediction, oil exploration, and sometimes financial modelling - Canada may have more total supercomputer-based supercomputing than anybody realizes, in addition to SETI. However, the June 2002 top500.org list doesn't show anything in Canada above #227.
Other results from the Top500.org list - SETI@Home is still about 7 times as large as the largest single machine on the list , Japan's NEC Earth Simulator, which is about 5 times as large as the #2 machine, LLNL's ASCII White.
On the other hand, their code basically jumped around in a large matrix, without much locality, because that matched what the real system they were modelling would do. They needed 12-14 MB of table space for the system they were modelling, and our VAX 11/780 only had 4MB of RAM, so I played with a number of virtual memory operating systems (4.1BSD, SVR2.0p, various tunings) to get something that would survive being thrashed to death, and helped them do a lot of work on checkpointing their code, because their standard run took a week, and even if something else didn't cause the machine to crash, we'd get power hits during summer thunderstorms. After about two years of this, the price of RAM dropped to the point that we could afford to upgrade the machine to 16MB, which made our run time drop to about an hour....
Meanwhile, that Cray-1 of yours was mostly similar in performance to a Pentium 133, and some of the recent graphics chips have really immense memory bandwidth, though they're mostly running fixed-point or at best single-precision floating point rather than double-precision or quadruple-precision, so they're not *quite* a Cray-replacement even though they're faster at many things.
Actually, climate change has been a real problem for the ecosystem of the north coast, with a lot of ice melt and more open water than usual. One of the effects is that seals have more of the year, or in some places year-round, that they can find open water instead of making breathing holes in the ice. Polar bears and the traditional Inuit hunting methods both depend on catching seals at their breathing holes, so their hunting is much less effective.
On computer-related topics - laptop batteries really don't like background CPU-burners. I used to run the GIMPS Great Internet Mersenne Prime Search, and I used to commute by train, with about an hour of battery time each way. NiMH batteries don't have the same failure behavior as NiCD, and they're nowhere near as nasty a toxic waste disposal problem, but they really don't like this kind of treatment. To compound matters, for some of that time period, I was running Windows NT 3.51, which was much more stable than Win95, but it insisted on being a *server* operating system that didn't need laptop power management drivers, so when it got a hardware low-power shutdown signal, instead of going into hibernation mode (see, the polar bears *were* relevant), it would blue-screen and die. I had to stop running the prime search.
The one exception I can see to this is if you're using the CD as a data transport mechanism, between your PC in the office with the fast data connection and your DVD player in the living room.
Prices vary a lot, but there's often a sale for $7 per 50 CD-Rs.
This Anoto pen
wants to be your friend
every page you send
we know end to end
we'll be watching you.
Every word you write
every pen you bite
every thing you draw
that's what we just saw
we'll be watching you
every check you sign
it knows just what time
when you draw a line
all your base are mine
we'll be watching you.
Maybe it's gotten better, but the initial Anoto documentation indicated that they handled coordination of everything written using Anoto. It's closely related to the fact that Anoto has a global data space for their paper - each piece is unique, and which lets them build interesting and special applications if they can see all the data, and part of their business plan was to sell off pieces of the map to companies who wanted to do things with it. There was some encryption stuff build in, but no real documentation on what information was available to whom. For most applications, that's not necessary - the user's PC could do most applications standalone, using the address space to do relative calculations (using x and y distance from the starting point, if the algorithms support that without central processing.)
I couldn't tell from the web page whether .NET was used just as a bunch of libraries (e..g for communicating with the pen via USB) or if it was also used to talk to Anoto themselves, or to Logitech - does anybody have more information?
No thanks - the back covers were enough. What's surprising is that "The Eye of Argon" appears to date from 1970, which is early enough that the author probably hadn't read the Gor books at the time; it looks like the earliest one of them was 1969 or so.
The more serious attacks using Windows would be easier to implement with a wetware-propagated Trojan Horse, such as a popular Kazaa-replacement client, or else with Yet Another Windows Outlook Email Virues. I'm sending you this DDOS client in order to have your advice.
Of course, the next attack won't be something dumb like ICMP - they'll try something new, either because they learned a lesson from the people who did this one, or because they suspect they'll get their butts kicked if they try this method. For instance, I'd really rather *not* see the next Outlook Email Virus mail stuff to the root servers, or to randomized non-existent 2LD.COM addresses... I'm sending you this DNS request in order to have your advice
If you wanted to be a bit more democratic about access, you could provide priority service (or push service) to the big ISPs' main servers, and volume-restricted service to the free-use crowd. It's most important that the ~20 Tier 1 ISPs have good copies, because most of the smaller ISPs get connectivity from one or more Tier 1s, so they could get DNS as well.
A fun side-effect of making direct DNS access expensive would be that it would encourage more people to use the alternate root providers, who used to have about 0.5% of the market, except I think some of the cable modem companies were using alternate roots to have more options for selling namespace to their customers.
Also, some of the press about the attack said it was using ICMP rather than UDP, and it's much easier to go around squashing ICMP than trying to figure out which correctly-formed queries for foo.com are real and which are DDOS.
It's probably not Earthlink/Mindspring/Netcom/Borg's best name server, but I memorized it years ago because I had to keep typing in the bloody thing any time I reconfigured Windoze, and when my internet connection wasn't working right the first step was to ping and traceroute the name server to make sure it was behaving.
I won't post the addresses to avoid slashdotting them, but several of the root-servers have graphs for response-times as well as traffic-levels. On some of the servers, the response-time went up, but on a number of them it went to zero for an hour or so, which I assume means no response rather than infinitely-fast response. Somebody set them up the bomb.
But, yeah, some of the attacks aren't much different than using a loudspeaker to announce "Free Beer at Victim.com"
The 3B20 was a bit-slice architecture that predated the WE-32000 and 32100 microprocessor chips in the 3B2/3B5/3B15 series. It was roughly a VAX-780 class machine, i.e. about 1 MIPS and two refrigerators for the main computer plus another for the UPS (4 truck batteries...) The 3B20 Duplex machines had two CPUs running two halves of an operating system (which was DMERT rather than UNIX, but had a UNIX layer on top of it) - you could upgrade the OS while the thing was running.
For the most common 2LD names, any major ISP will have cached the addresses for them, and won't need to hit the .com server until the typical 1-week or 24-hour cache timeout periods. If your nameserver is ns.bigisp.net, somebody there will have looked up google.com in the last 2 seconds, even though nobody at your ISP has looked up really-obscure-domain.com this week - but even that one may be in the cache because some spammer was out harvesting addresses. An obvious scaling/redundancy play for the root servers and for the major ISPs would be to have them cache full copies of the root server domains to keep down the load and reduce dependency. It's not really that much data - 10 million domains averaging 30 characters for name and IP addresses is only half a CD-ROM. An interesting alternative trick would be for the Tier 1 ISPs to have some back-door access to root-level servers for recursive querying.
...if they'd looked up their favorite pr0n and warez sites first, so the names were in their DNS caches and their ISP's caches.
The attack only lasted an hour or so, didn't affect all the servers, and if most of the sites you were looking at were in your ISP's DNS caches, you wouldn't have hit the root servers anyway. If you're looking for google.com, your ISP's cache has it because somebody else looked at it 2 seconds ago - it's when you want really-obscure-domain.com that you need to hit the root servers.
100 meters isn't very big. It'd be cheaper to ship that much stuff uphill ourselves rather than lassoing this one. Other nearby asteroids, such as Cruithne, would be more interesting possibilities, though I'd hate to have to fill out the Environmental Impact Report for potential hazards of mistakes....
* Donaldson's Law: Sturgeon was an optimist.
*Windows* crashes.....
Beethoven's been dead for a long time, but you seldom listen to a pre-Steamboat-Willie performance of Beethoven's music. Usually what you listen to is some modern orchestra that performed and recorded the music in the late 20th century, either under modern copyright laws or under pre-Berne US copyright laws. So you're buying a Deutsche Grammophon recording of Furtw"angler's 1929 Berlin Philharmonic performance of Beethoven's 5th(that one's listed as "dubious") or EMI's 1954 recording of the same piece with Furtw"angler conducting the Vienna Philharmonic, possibly in a form remastered by somebody else and printed by the El Cheapo Classical CD Society in 1998.
Piracy's not unknown even in classical circles... More dubious recordings