Denial-of-service victims share lessons learned
SAN FRANCISCO -- When online news service ZDNet was hit with a ferocious denial-of-service attack in February, its server was overwhelmed with 50% to 100% more data traffic than its peak load, rendering three-quarters of the site inaccessible for almost three hours. Site managers discovered there was little they could do to halt the first of two attacks that consumed all their available bandwidth.
"When the attacker decided it was over, it was over," said Alex Wellen, a producer at ZDNet TV who spoke at a panel discussion at the NetSec 2000 computer security conference this week. Wellen and other panelists from Cisco Systems Inc. and Stanford University who have also weathered denial-of-service attacks offered lessons learned from the incidents and strategies for effective defense.
A rash of distributed denial-of-service attacks against e-commerce sites in February used floods of data packets to overwhelm servers and choke access to the sites. Attackers scanned remote machines for vulnerabilities and secretly loaded software that used the compromised machines as agents in attack networks that were harnessed against targeted sites.
But these attacks were well-known risks before February. Cisco was hit by a denial-of-service attack in October while participating in an online benefit concert. Panelist Eliot Lears, a consulting engineer at Cisco, said the company had already prepared by working with its Internet service provider and setting its intrusion-detection system to identify the signature for that type of denial-of-service "smurf" attack. Such attacks use Internet Control Message Protocol (ICMP) packet traffic.
"We had our ISP rate limit the amount of traffic ICMP could send," said Lears. "You want to establish close coordination with your ISP before an attack."
Lears also noted that Cisco routers can be set up to create an access list that logs the source address of malicious packets and helps service providers track them to the source. David Brumley, an engineer with the Sanford University security team, said targeted sites can ask their service providers to trace the machine address of the packets through each router on their network and contact other providers if the packets jump network boundaries.
A Stanford University computer was used in a 700M bit/sec. smurf-type denial-of-service attack against eBay in February, which was investigated by the FBI, he said.
"Luckily we had a logging mechanism in place beforehand and could go back to logs and contact the sites where the smurf was coming from," said Brumley. "Law enforcement is well-prepared, but you have to give them a case they can prosecute, you have to give them logs."
Brumley added that many machines don't keep logs, and attacks that spoof packet addresses are difficult to trace unless data is collected during the attack. He also warned that many Internet service providers aren't willing to trace packets and get data in real time unless it is a big attack. Companies should develop contacts with law enforcement and be prepared to quantify financial losses to overburdened investigators.
All the panelists agreed that if more network managers installed a type of filtering known as RFC2267 to their I/O interfaces, it would be more difficult to launch attacks with spoofed packet addresses. As the packet leaves the router, these filters apply a set of rules making sure the packet complies with an internal source address before it is sent. This would prevent a compromised machine from being used by an attacker to send a flood of packets with inaccurate addresses against a target. The panelists noted that it would be especially effective for service providers to install these filters. "If everyone did this, source address spoofing would not work," said Lears.
Other tips from panelists on preventing denial-of-service attacks:
- Monitor your own network to make sure your machines aren't being compromised for a denial-of-service attack network.