No Longer in Denial

Security experts coping with a new form of denial-of-service hacker attack are contemplating ways to change the way the Internet works

This is part of IEEE Spectrum's special report: Always On: Living in a Networked World.

When the Internet passed from government and academic realms to the public sector a decade ago, it brought along a laissez-faire attitude about security. A whole hacker industry developed to find ways to do mayhem until, today, it is not clear which side--the hackers or the system security administrators--is winning.

The world was made rudely aware of the battle last February when public access to the sites of Amazon, eBay, Yahoo!, and other dot-coms was cut off by a new method of attack called distributed denial of service (DDoS). To block the sites, one or more hackers sneaked into the computers of several unsuspecting users connected to the Net, and used these widely dispersed machines as drones to launch a barrage of false messages. [See "View to a Site Kill"]

More to come

The attacks have rallied widespread support for countermeasures, so that the next few years may see significant changes in how the Internet works. But before it does, things may get worse. Rapidly rising use of always-on digital subscriber line (DSL) and cable modems simplifies the task of recruiting drones, according to Sam Curry, security architect at McAfee.com Corp., Sunnyvale, Calif., a leading supplier of security software.

"It's easier to sneak in [with broadband] because intrusion causes relatively less communication overhead than with dial-up; it's less noticeable," he told IEEE Spectrum. Further, broadband lets hackers send out more packets in less time, so they eagerly search out such devices, according to both Curry and Charles Palmer, head of encryption and overall network security research at IBM Corp.'s Thomas J. Watson Research Center in Yorktown Heights, N.Y. Palmer recalled a security-expert friend who installed broadband access one evening and awakened the next morning to find his system had been scanned six times by hackers, probably in preparation for installing drone software. While there are legitimate, non-malicious reasons for system scanning, the expert, who had special scan-detecting software, was able to ascertain that such was not the case this time.

Security experts are planning to fight the war with DDoS hackers on many fronts--from the Web-server vanguard through to the personal computers in the trenches. In the wake of the February attack, their first act has been to try to establish lines of communications among Web site operators, Internet service providers (ISPs), and legal authorities.

Accordingly, the RFC2827 working group of experts was formed within the Internet Engineering Task Force (IETF) to share attack information. (The group is known somewhat less formally as RFC2267 Plus, for the original Request for Comment number assigned by the IETF.) Included in the working group are representatives from companies that were originally attacked, as well as vendors of security software and systems, ISPs, and legal authorities. Their head is Henry Teng, senior manager of the information risk management group at KPMG LLP, Mountain View, Calif.


Distributed denial of service is a network problem because it abuses the network's resources; so the solution has to be in the network

The group began by working with ISPs to set up procedures they all should follow in the event of an attack, so they could share information. Cisco Systems Inc., the San Francisco-based leader in router technology, recommended procedures for tracing the attack traffic back to its source. The procedures were quite detailed, Teng said, but "were so manually intensive that they would be really hard to implement." Two of the ISPs, AboveNet Communications, San Jose, Calif., and Sprint Corp., Westwood, Kan., worked out their own procedures and shared them with their customers. But the working group found it impossible to devise a process that all ISPs could share collectively.

The stumbling block was the risk of divulging proprietary information while ISPs and site operators communicated about an on-going attack. So the goal is a common data-sharing format. IBM's Palmer, working with Teng, devised a filter that would mask sensitive information for a particular site while an attack was in progress. While this filter format was only good for this particular case, Teng would like to come up with a format that everyone could use. "Hopefully we can get to that stage," he said. So his group will continue to work on the problem.

Tracking the attacker

Another IETF group is working on improving security by tracking the flow of data packets through the Net, that is, IP traceback. Today, the packet's path as it hops from router to router in an attempt to reach its final goal is not recorded.

The approach involves a new messaging protocol, referred to as itrace, which would have routers send a message ahead to a packet's final destination saying, "I've seen this particular packet." Thus when a denial-of-service attack did occur, its target could quickly determine where the packets started from, and contact the one or more ISPs through which the attack is coming to try to stop the flow. This method overcomes any attempt by a hacker to disguise the origin of a message by putting in a phony Internet address, referred to as spoofing.

Of course, if every router were to send a message for every packet it received, they would swamp the destination server more effectively than any DDoS attack. So the router sends a message, not for every packet it receives, but for one out of every 20 000 packets. Working group chair Steven M. Bellovin of AT&T Laboratories, Florham Park, N.J., explains that, at maximum, a packet will make about 20 hops, so at most traffic will rise only 0.1 percent with this protocol. "You're not going to even notice it," he said, "but under a DDoS attack, you'll get enough to see where it's coming from."

While itrace theory has been worked out, other issues remain. For instance, as Bellovin pointed out, the attacker might "fake you out by sending large numbers of phony itrace packets. "This entails somehow authenticating that an itrace message is indeed coming from a particular router. One way would be to have the router place a digital signature on each itrace, but computing such a signature for every message would incur an overhead. Since they already have their hands full simply moving packets as quickly as possible, "routers don't have CPU cycles to spare," Bellovin notes, and admits that "authenticating these packets is the hardest part of the problem."

Then, too, how will the router go about randomly selecting the packet? For the sake of speed, routers are essentially hardwired to pass along messages, and it has yet to be worked out how they would randomly select a package for which to generate an itrace message. The computing power of new network processors could make performance of such a task simple [see "The New Chips on the Block"], but those seeking security may not want to wait until the chips are widely deployed. So there is still much work to be done on itrace. "Clearly, it's at the engineering stage," Bellovin said.

At the same time, researchers are developing theories for even newer approaches to IP traceback. Among those working on the problem are Stefan Savage, David Wetherall, Anna Karlin, and Tom Anderson at the University of Washington, Seattle, and Dawn Song and Adrian Perrig 0f the University of California, Berkeley.

Still, the IETF working group's hope is to present a final draft of the basic protocol early this year for consideration as a standard, so that work on the details of implementation can proceed quickly. For AT&T Labs' Bellovin, taking action at the Net level makes the most sense. "This is really a network problem, because the network's resources [such as routers] are being abused; so the solution has to be in the network," he said.

Stopping at the edges

For the time being, the only tools for dealing with DDoS target the edges of the Internet: the servers and the computers of on-line users. One approach is to install a hardware/software system that sits between a site's servers and the Net. The system watches the flow of packets into the server to see which packets are associated and what their intent is.

Start-up Top Layer Networks Inc., Westboro, Mass., has developed such a system, called Flowswitch. While it does not stop an attack, it does allow site operators to divert traffic from the server so the server can handle legitimate requests. Geff Ambrose, director of technical marketing for Top Layer, notes that his company is now working with other software vendors on how to analyze the unwanted packets automatically; it is also joining the RPC2827 working group to see if Top Layer's technology can help share attack information.

Other software vendors like Symantec Corp., Cupertino, Calif., and McAfee are offering personal firewall software that users can install on their PCs to protect them from unwanted intrusions like those referred to by McAfee's Curry and IBM's Palmer. By following a menu, the user can specify what kinds of traffic, such as e-mail with attached programs, to bar from his or her system, or from whom to accept such e-mails.

Alerting PC users to the need for such software is one thing, getting them to install it is another, Curry admits. However, McAfee is working to have ISPs deliver the software to their customers. One thing that may prompt such action, according to Top Layer's Ambrose, is that ISPs are beginning to worry about liability. "We're starting to see some companies looking into legal action against the launch sites," he said. Still, IBM's Palmer remains pessimistic about DDoS attacks: "You're not going to be able to stop denial of service--the best thing you can do is reduce its impact."

To Probe Further

The Internet Engineering Task Force (IETF) gives visitors to its site (http://www.ietf.org) information on the charters and status of its various working groups. RFC 2827 is found at http://www.ietf.org/rfc/rfc2827.txt. Archives containing records of the IETF's itrace working group's current deliberations can be found at http://www.research.att.com/lists/ietf-itrace. The group also has a mailing list; for information on how to join it, visit http://www.ietf.org/html.charters/itrace-charter.html.

Go to introduction

Advertisement
Advertisement