Slashdot Mirror

EG, NNTP may still be a huge amount of some ISPs traffic (eg, see this paper, http://www.icir.org/vern/papers/imc102-maier.pdf [icir.org] ) but it is almost ALL binary transfers.

Huge compared to the amount of spam email transiting their network?

Usenet is pretty much dead except for piracy, subsumed by specialty web forums for those who are after communication rather than warez. And if you still want it for communication, Google Groups offers a free gateway IIRC.

EG, NNTP may still be a huge amount of some ISPs traffic (eg, see this paper, http://www.icir.org/vern/papers/imc102-maier.pdf ) but it is almost ALL binary transfers.

So its not a shock that Cox is getting rid of its Usenet servers, whats only shocking is that it took them so long.

considering the amount of data Google processes on a regular basis, a 9 Month backlog isn't that unreasonable.

Sure it is. Why? Because they are collecting data continuously and if it takes a long time to process what they've collected, more data is backlogged, and it keeps spiraling out of control. In fact, if it takes more than 24 hours to process 1 day of data, the backlog will increase without limit. The proper thing to do is to apply proper anonymization to the information immediately so you don't have to worry about it. There are plenty of methods that allow you to anonymize important information while retaining enough data for analysis. Here's one paper [Warning: PDF] on the subject.

Mike Perry did a great public service by making this tool and making it available.

This attack also works against yahoo mail, hotmail, etc. Just Yahoo, hotmail, etc don't even OFFER SSL, so well, if you use them, your FSCKed.

And Google has known about this problem for a LONG time. EG, see my blog post from last february!.

Google waited for a year before even giving users the OPTION to be protected when SSL is used, and notice that it was only after they found out about Mike Perry's talk that the option was even added.

Also, as I argue, they got it wrong. The checkbox is good, but most users don't know about it. But if a user MANUALLY enters https://mail.google.com/ I argue that google should INFER that the user wants to be SSL-only, at least until they explicitly log out.

• CBQ and other hierarchical queing disciplines (HTB, WRED, etc.);
• Stochastic Fair Queuing;
• Stochastic Fair Blue (Linux implementation).
• ...and many others.

While approximately fair is not quite as good as fair, avoiding hard state makes for a cheaper and more reliable network, which allows you to more easily over-provision your link capacity. Unless, of course, you're in the business of selling routers that implement hard state...

just do this

I'm sure the WOOT conference would have been happy to publish "How to 0wn the Internet in Your Spare Time," which, incidentally, has to be the best academic paper title ever.

Not much yet - there's a bit of a chicken-and-egg issue. You need stable implementations of a transport protocol before anyone will use it, but there's not much demand for the implementations before applications are asking for it. So, these sort of changes deploy rather slowly. We'll get there though - the Linux DCCP code is just starting to get stable now.

Lets of information about DCCP is here if you're interested.

- Mark (one of the author of DCCP)

http://www.cs.ucr.edu/~tkarag/papers/BLINC.pdf
http://guh.nu/projects/ta/safeweb/safeweb.html
http://www.ir.bbn.com/~krash/unpubs/TM1321.pdf
http://www.icir.org/vern/papers/stepping/

Speaking as an Evil Genius with standards, and one who's read the Warhol Worm paper, I'd say any "decent" botnet doesn't take orders from just any old Bill, Fred, or Otto who wanders by waving an executable at it. A "decent" bot wouldn't run code handed to it unless the executable was cryptographically signed with a private key matching the public key it knows belongs to its One True Beloved Master.

So, all of your plans should work just fine... once you determine how to recover a GPG private key of the 4096-bit keypair needed to sign the RUNME code, using the public key taken from the sample bot.

HANGE. (Have A Nice Geologic Epoch.)

(Note: I have better projects to occupy my Evil Genius than botnets.)

The worms you are thinking of are Warhol worms and flash worms, first published in a paper by Staniford and Weaver which use hitlists to find targets and can spread to 95% of vulnerable hosts in about 15 minutes or under 30 seconds for a flash worm. A varient of the flash worm also proposed by Weaver in a later paper in 2004 and had a theoretical flash worm spread in 510ms, unfortunately I can't find the paper at the moment.

I would call Slammer a 'polite' worm as it did no harm other than flooding networks.

Thats quite a generous optinion of the slammer worm considering it basically ground sections of the internet to a holt by the amount of traffic it generated.

It's certainly possible to write an impolite worm. One that doesn't just spread itself, but after 20 minutes of attempting to spread itself decides to stop all of your services and then wipe the data off your hard drive.

I've always wondered why peoples immediate thought of a worst case senario is loss of data. There are far worst things you could do if you had access to someones machine: stealing confidential information for blackmail, sending out emails in that persons name from their machine damaging that persons reputation, downloading kiddie porn to the machine, removing yourself and then informing the authorities.. data can be recovered by various mechanisims but reputations or finances are a lot harder to rebuild.

We should all be thankful the attackers hadn't read How to 0wn the Internet in Your Spare Time, or thought up the idea of a slow client/server worm themselves - or really large numbers of users/websites could've been infected.

• NUMA - Non-Uniform Memory Access, a step beyond symmetric multiprocessing allowing for more processors and memory local to each processor
• HostAP - appears to be a driver for certain wireless chipsets that allows your computer to act as an access point
• FUSE - Filesystem in User Space, rather than kernel space
• relayfs - a common mechanism for getting large chunks of data out of the kernel safely, apparently for thing like tracing
• securityfs - apparently another pseudo-filesystem that is meant to unify things that are being handled in different ways now.
• DCCP - Datagram Congestion Control Protocol, apparently part-way between TCP and UDP, DCCP provides congestion control without TCP's reliability guarantees. Meant for streaming media, MMORPGs, and other apps that need UDPs timeliness but don't want to blindly flood links

• Released October 27, 2005 changelog

• Numa-aware slab allocator: It creates slabs on multiple nodes and manages slabs in such a way that locality of allocations is optimized. Each node has its own list of partial, free and full slabs. All object allocations for a node occur from node specific slab lists (commit - benchmarks)

• Lazy page table copies in fork() for VMAs without anonymous pages (the ones with anonymous pages are still copied): Defer copying of ptes until fault time when it is possible to reconstruct the pte from backing store, speeding up fork() greatly specially for processes using lots of shared memory (commit)

• Add /proc/$PID/smaps: This file will shows how much memory is resident in each mapping. Useful for people who want to perform memory consumption analysis (commit)

• Add /proc/$PID/numa_maps: This file will show on which nodes pages reside (commit)

• Lock-free file descriptor look-up (commit) - (commit)

• Four-level page table support for the ppc64 architecture: extends the usable user address range to 44 bits (16T). (commit)

• Support hotplug cpu on 32-bit SMP powermacs: When a cpu is off-lined, it is put into sleep mode with interrupts disabled. It can be on-lined again by asserting its soft-reset pin, which is connected to a GPIO pin (commit)

• Add TASK_NONINTERACTIVE task state bit to the cpu scheduler: It can be used by blocking points to mark the task's wait as "non-interactive". This does not mean the task will be considered a CPU-hog - the wait will simply not have an effect on the waiting task's priority - positive or negative alike (commit)

• PPTP (Point-to-Point Tunneling Protocol) support: RFC 2637. Used to implement VPN products (notably, Microsoft in all the Windows versions). Wikipedia article (commit)

• DCCP: "Datagram Congestion Control Protocol". Datagram protocol (like UDP), but with a congestion control mechanism. (LWN article) Currently a RFC draft (commit)

• Implement SKB fast cloning: Protocols that make extensive use of SKB cloning, for example TCP, eat at least 2 allocations per packet sent as a result. To

You may find this of interesting reading

The paper "How to 0wn the internet in your spare time" has a good overview of rapid-spreading techniques:

http://www.icir.org/vern/papers/cdc-usenix-sec02/

I agree that we are being lazy and letting NAT taking care of addressing (as opposed to IPv6).

I would think that rather than virtual circuits what we need is effective flow control (but maybe that is what you mean....).

The big problem here in many ways is the unsuitability of UDP to cope with multimedia flows as it has no built-in congestion control and apps like Skype to some degree abuse this.

I am working away with a protocol that is meant to help solve this (DCCP) which is at draft RFC state at present. If interested have a look at:http://www.icir.org/kohler/dcp/

There is also work under way to approach this sort of issue using a new protocol called DCCP. DCCP sits on top of IP rather than UDP or TCP so is at a lower level. DCCP stands for Dynamic Congestion Control Protocol and has some reasonably interesting people behind it. Here are some links referencing it: http://www.icir.org/kohler/dcp/ http://www.ietf.org/html.charters/dccp-charter.htm l I'm actually looking to do a PhD in research on DCCP shortly so this discussion is quite interesting!

I'd rather add a thin error checking addition and ask for a retransmission for the occasional dropped packets.

Congratulations, you have just re-invented TCP with selective acknowledgments (a.k.a. SACK, RFC 2018, published in October 1996).

For more discussion on this topic, see also: http://www.icir.org/floyd/sacks.html.

So others can have fun slashdotting other technologies, here are some websites. There are probably others, but this should keep those who do really want to move away from TCP happy.

• Actual sourcecode to transmit binaries by multicast
  
• IETF Reliable Multicast Transport - Charter + RFCs
  
• Introduction to Multicasting (a little old, doesn't cover things like IGMPv3)
  
• Lightweight Reliable Multicast Protocol
  
• Microsoft's Reliable Multicast
  
• SUN's Reliable Multicast system
  
• Navy Research Laboratory implementation
  
• Scalable Reliable Multicast
  
• Cooperative Reliable Multicast
  
• Reliable Multicast for Wireless environments
  
• Selectively Reliable Multicast
  

The hit list technique speeds up the initial phase of infection, which is normally slow and vulnerable to isolated failures. The list is compiled ahead of time by normal vulnerability scanning; the machines on the list are simultaneously infected to start the attack. Each copy of the worm then scans for and infects further vulnerable machines as quickly as possible, dividing the address space at each hop to avoid unnecessary overlaps (some redundancy might be desirable, but completely random scanning would be inefficient). The list can be divided in a topology-aware way to reduce congestion that might otherwise limit the rate of infection.

Check out ESM or YOID.

Yet highly destructive viruses can't spread easily if they kill their host machine before spreading!

That's where you're wrong, see for example How to 0wn the Internet in Your Spare Time. Someone could write a virus that infects all vulnerable hosts within MINUTES. If the virus could spread that rapidly, you could simply have it wipe the hard drives after x minutes. It would be fast, deadly and damn near impossible to prevent. When (not if, when) someone goes ahead and does something like this, we're all going to be fucked.

Speaking of Iomega website, it's not accessible for those of us who have the TCP ECN bit turned on. This has earned them an entry in the ECN Hall of shame listing. Their response? ... We can revisit this in several years. It isn't a big deal right now ... To be honest, I would be surprised if anybody had a problem talking to us because of ECN.

FYI, /proc/sys/net/ipv4/tcp_ecn is the switch that controls whether Linux uses the ECN option or not.

I've tried nearly every sniffer (open-source or commercial) that has been available for the past 10 or so years.
Having the right tools for the right job is so important. Here's my list of good vs. bad in the packet capture world:

Good:
1) Running 'tcpdump -vvens0 -w file.cap' will basically give anyone anything they need, period
2) arpwatch, just to have a nice list of MAC2IP's
3) argus (already mentioned here)
4) snort (although I suggest the commercial Sourcefire instead). However, `unified logging' in snort (e.g. mudpit or barnyard), along with cerebus and logtopcap can scale snort to large-installations
5) ourmon is the best pcap visualization tool out there. it's BPF+RRDTool, so it basically rules
6) After you gzip the pcap file, scp it to your Windows/Linux desktop and run Ethereal to analyze in-depth
7) NAI SnifferPro "Expert" mode is sometimes useful instead of Ethereal. However, it's not worth the money even if you have money to burn
8) tcptrace is VERY useful to run on your saved tcpdump pcap files
9) Bro, ngrep, and dsniff are well-written, albeit somewhat security-specific
10) iftop and tcpdstat ala ddittrich's preso's

Bad:
1) SnifferPro, Network Observer, Fluke, et al
2) ntop (although their website is very cool for info on packet capture)
3) ntop look-a-likes like darkstat
4) pastmon doesn't really work yet, but looks promising
5) Cisco Netflow and SPAN ports. I highly recommend Internap FCP, argus, or Bro instead of Netflow. I also highly recommend NetOptics port aggregator taps over SPAN ports, however SPAN is better than nothing

A lot of people were confusing packet creation with packet capture. For more information on packet creation, see packetfoo [PDF]

Read How to 0wn the Internet in Your Spare Time. It shows how someone with real knowledge of computer science and sufficient determination could create a virus far more destructive than anything seen to date.

Perhaps the reason it has not happened yet is that those with the necessary skill and knowledge would rather spend the effort on something more fulfilling and/or profitable instead of annoying others while risking legal consequences.

How to 0wn the Internet in Your Spare Time

Interesting topics: "Better" worms techniques

• Localized scanning--Code Red II
• Multi-vector worms--Nimda
• Hit-list Scanning
• Permutation Scanning
• Simulation of a Warhol Worm

"A combination of hit-list and permutation scanning can create what we term a Warhol worm, capable of attacking most vulnerable targets in well under an hour, possibly less than 15 minutes. "

That's SACK and it's a good idea but a lot of systems still don't implement it.

In case you were wondering what Brois.

http://www.icir.org/vern/bro.html

Most of Clyde`s story comes straight from the paper "how to own the internet in your spare time", only the paper has the idea in it that ever kid could apply the mentioned tricks to optimise his worm, while Clyde is thinking along the lines of "well-funded teams of hackers sponsored by countries or other organizations" ie "hollywood terrorist" with no real target but the internet.

The paper mentiones attacking from more then one point at once (For example by building a hitlist of vulnarable systems with big pipes and getting them first) but also mentiones the multi-vector aproach used by nimda and some other tricks as well as a way of predicting a worms infection speed.

In normal tort and contract law, there is a notion of 'reasonable' behavior and well understood 'duty.' Not so here. Thus, attempts at analogy do poorly.

In the 'real' world, it's clear who is supposed to do what. And if everyone is a good citizen, then everyone is pretty safe.

Example: If I sell you a sandwich, I have a duty to not poison it. I even have a duty to take reasonable steps to ensure that other people don't put poison into it. For example, if I saw someone lick it and put it back on the counter, it's reasonable to expect me to throw it away, and not resell it (and for me to get the perpetrator to pay me for it).

But that duty has reasonable limits. It is not reasonable to expect me to erect Fort Knox level security around my store, just to keep people from breaking in at night and adulterating the sandwiches.

These simple concepts apply to millions of practical applications, from product liability involving millions of consumers to simple traffic accidents. A few simple rules can actually implement a lot of what is required by 'common sense' or 'justice' or 'fairness' (thus, tort law is pretty efficient code).

But these concepts -- and our hence our analogies -- don't apply well to the internet, for two reasons. First, there is a notable lack of consensus as to what the duties of each party should be. Second, we have not identified what duties will actually protect us. As Graham and Staniford, Paxson, Weaver have pointed out, the pallative 'we all have a duty to keep everything patched' does not really help with fast worms. Even with a lot more patching going on, we remain very vulnerable to fast worms.

So, even if we are all good citizens, bad things can still happen (like expensive bandwidth being consumed by a fast worm). Thus, normal tort analogies will fall short. There are some extraordinary tort analogies that might work, like who pays for what after a tornado or other Act of God. (Your cow flew through my window, who pays?) But even those will rely on consensus views of what constitutes 'reasonable precautions' - views that have been forged over generations and generations. So that will take time.

In the meantime, we should consider new public services to protect society in ways that mere 'good citizens' cannot - like we do with epidemics, fires, and other Acts of God. Staniford, Paxson, Weaver have proposed a CDC of cyberspace. Seems like a very good idea.

In normal tort and contract law, there is a notion of 'reasonable' behavior and well understood 'duty.' Not so here. Thus, attempts at analogy do poorly.

In the 'real' world, it's clear who is supposed to do what. And if everyone is a good citizen, then everyone is pretty safe.

Example: If I sell you a sandwich, I have a duty to not poison it. I even have a duty to take reasonable steps to ensure that other people don't put poison into it. For example, if I saw someone lick it and put it back on the counter, it's reasonable to expect me to throw it away, and not resell it (and for me to get the perpetrator to pay me for it).

But that duty has reasonable limits. It is not reasonable to expect me to erect Fort Knox level security around my store, just to keep people from breaking in at night and adulterating the sandwiches.

These simple concepts apply to millions of practical applications, from product liability involving millions of consumers to simple traffic accidents. A few simple rules can actually implement a lot of what is required by 'common sense' or 'justice' or 'fairness' (thus, tort law is pretty efficient code).

But these concepts -- and our hence our analogies -- don't apply well to the internet, for two reasons. First, there is a notable lack of consensus as to what the duties of each party should be. Second, we have not identified what duties will actually protect us. As Graham and Staniford, Paxson, Weaver have pointed out, the pallative 'we all have a duty to keep everything patched' does not really help with fast worms. Even with a lot more patching going on, we remain very vulnerable to fast worms.

So, even if we are all good citizens, bad things can still happen (like expensive bandwidth being consumed by a fast worm). Thus, normal tort analogies will fall short. There are some extraordinary tort analogies that might work, like who pays for what after a tornado or other Act of God. (Your cow flew through my window, who pays?) But even those will rely on consensus views of what constitutes 'reasonable precautions' - views that have been forged over generations and generations. So that will take time.

In the meantime, we should consider new public services to protect society in ways that mere 'good citizens' cannot - like we do with epidemics, fires, and other Acts of God. Staniford, Paxson, Weaver have proposed a CDC of cyberspace. Seems like a very good idea.

-Fzz

After CodeRed a paper named How to 0wn the Internet in Your Spare Time was published. In part, it said that a worm could 0wn the internet in 30 seconds given the right conditions. 10 miniutes of Saphire seems like a pretty good proof of concept demonstration, given the limitations (only infected a database server with limited market, etc). Could be fun to go back and read some of the /. naysayers, anyone have links to /. discussion?

This is a hoax... At least partly.

It has the feel of a hoax. Citations like "First, all p2p-serving software on the machine is infected", "all media on the machine is cataloged, and the full list is sent back to the RIAA headquarters" and "Snort, RealSecure, Dragon, NFR, and all that other crap cannot detect this attack, or this type of attack." are clear signs of chain letters and hoaxing (or humor if you prefer).

Gobbles claim that 95% of all p2p-participating hosts are infected. To achieve that number, exploits must exist for Mac, Win and Linux clients. I'm sure that there are exploits available, but making them work on all platforms and avoiding detection by anti-virus programs would require far more than 17 full-time persons.

We can rest assured that not only RIAA but also Symantec, F-Secure and other anti-virus companies are keeping close track of the p2p traffic patterns. Anyone trying to collect complete information of the contents on something like 50 million hosts (check the number of downloads on Download.com if you don't belive this) would not escape anybodys attention. 50 bytes per file times 100 files per computer times 100 million hosts = 500 GB. The shear volume of traffic to RIAAs computers would be noticed even if RIAA used several hundred separate IP blocks to spread the traffic. And, as said, this would require more than 17 volonteers spread over the world. Somebody would leak...

However - as many have pointed out already - it may seem unlikely, but it is definitely possible to similar things and you should protect your computer even more after this. An essential read for anyone that is still in doubt about the possibilities of doing this is:

How to 0wn the Internet in your spare time. from the Proceedings of the 11th USENIX Security Symposium (Security '02)

Let's be careful out there!

• Chord from MIT.
• CANfrom ICSI.
• Pastry/Tapestry from UC Berkeley/Rice.
• Kademlia from NYU.

- Fzz

To Appear in the Proceedings of the 11th USENIX Security Symposium (Security '02)

The ability of attackers to rapidly gain control of vast numbers of Internet hosts poses an immense risk to the overall security of the Internet. Once subverted, these hosts can not only be used to launch massive denial of service floods, but also to steal or corrupt great quantities of sensitive information, and confuse and disrupt use of the network in more subtle ways.

We present an analysis of the magnitude of the threat. We begin with a mathematical model derived from empirical data of the spread of Code Red I in July, 2001. We discuss techniques subsequently employed for achieving greater virulence by Code Red II and Nimda. In this context, we develop and evaluate several new, highly virulent possible techniques: hit-list scanning (which creates a Warhol worm), permutation scanning (which enables self-coordinating scanning), and use of Internet-sized hit-lists (which creates a flash worm).

We then turn to the to the threat of surreptitious worms that spread more slowly but in a much harder to detect "contagion" fashion. We demonstrate that such a worm today could arguably subvert upwards of 10,000,000 Internet hosts. We also consider robust mechanisms by which attackers can control and update deployed worms.

In conclusion, we argue for the pressing need to develop a "Center for Disease Control" analog for virus- and worm-based threats to national cybersecurity, and sketch some of the components that would go into such a Center.

Also in PDF optimized for reading online, PDF optimized for printing

To Appear in the Proceedings of the 11th USENIX Security Symposium (Security '02)

The ability of attackers to rapidly gain control of vast numbers of Internet hosts poses an immense risk to the overall security of the Internet. Once subverted, these hosts can not only be used to launch massive denial of service floods, but also to steal or corrupt great quantities of sensitive information, and confuse and disrupt use of the network in more subtle ways.

We present an analysis of the magnitude of the threat. We begin with a mathematical model derived from empirical data of the spread of Code Red I in July, 2001. We discuss techniques subsequently employed for achieving greater virulence by Code Red II and Nimda. In this context, we develop and evaluate several new, highly virulent possible techniques: hit-list scanning (which creates a Warhol worm), permutation scanning (which enables self-coordinating scanning), and use of Internet-sized hit-lists (which creates a flash worm).

We then turn to the to the threat of surreptitious worms that spread more slowly but in a much harder to detect "contagion" fashion. We demonstrate that such a worm today could arguably subvert upwards of 10,000,000 Internet hosts. We also consider robust mechanisms by which attackers can control and update deployed worms.

In conclusion, we argue for the pressing need to develop a "Center for Disease Control" analog for virus- and worm-based threats to national cybersecurity, and sketch some of the components that would go into such a Center.

Also in PDF optimized for reading online, PDF optimized for printing

I would suggest the Orinoco RG-1000. It has dialup, ethernet, NAT, is hackable, can be flashed with the latest Airport Firmware, and if you know the right People, can be had for $50 or so.

I've got one, and I love it.