Stolen credit card numbers, hacked federal computer systems and other high-profile online assaults have put many users on their guards and focused the attention of security managers on high-level intrusion-detection systems, chains of firewalls and other high-level defenses. But many forget that, no matter how hard they try to secure a site, vulnerabilities built into the fabric of the Internet still leave them at risk - even though measures to shut down the most glaringly common vulnerabilities are easily available.
Simple functions like the ability to request a connection between two machines can create openings that are to blame in about 15% of the attacks that are reported each year, says Fred Baker, chairman of the Internet Engineering Task Force. That's because TCP/IP hasn't changed much since the days of its acceptance as the Arpanet transport protocol.
"[Internet Protocol] was originally written among a cohesive community that had significant internal trust. By default, IP applications assume they should trust people," Baker says.
Denial-of-service and data hijacking attacks using functions of TCP/IP can be prevented using security functions that can be turned on in most server operating systems, filters built into routers or a new version of IP (Version 6), which is a standard for the public-key infrastructure IPSec protocol.
But those security measures are often ignored.
Take the TCP attack that was "rediscovered" in March by security services firm Guardent Inc. in Waltham, Mass. Guardent researchers figured out a new way to exploit an old problem with TCP: the ability of a hacker to hijack a session if he can guess the random initial sequence number (ISN) that two machines use to start a sequence of packets.
Once an attacker guesses the ISN, he can redirect the packets or inject anything into the data stream. Software vendors were thought to have averted this problem with random packet sequence generators. Turns out those random sequences aren't so random after all and actually contain patterns that make the ISN easy to guess, says Jerry Brady, vice president of research and development at Guardent.
Another ancient exploit, spoofing IP addresses, is also common today, says Paul Raines, head of global information risk management at Barclays Capital, an investment bank in New York.
"Classic TCP/IP attacks such as IP spoofing and denial-of-service attacks using buffer overflows are still out there," he says. "Take the [distributed denial-of-service] attack executed by Mafia Boy last year. He planted Trojan horses in unsuspecting servers. Those servers then flooded e-commerce sites with a load of service requests that contained bogus-source IP addresses. The e-commerce sites couldn't keep up. That caused many of their servers to crash."
Non-IP attacks typically go after vulnerable ports, services in server software or functions like address books and automailers.
Traditional attacks against TCP/IP fall into two categories: denial of service and data hijacking, says Frank Heidt, managing security architect at security consulting firm @stake Inc. in Cambridge, Mass.
In the 1980s, dozens of types of attacks against TCP/IP ravaged the Arpanet. Of those that still exist today, the most common include:
1. Smurf attacks: A denial-of-service attack named after the colorful cartoon characters, a smurf attack takes advantage of the ability in most servers to broadcast requests to many other machines at once. The attacker forges a legitimate IP address and then broadcasts requests for a reply to the address of the victim to all the servers on the network. Because the packets appear to be legitimate requests from a known address, all systems in the amplifying network reply to that address, overwhelming the legitimate machine and causing denial of service.
2. SYN Floods: denial-of-service attacks in which the attacker uses spoofed IP addresses to send multiple connection (SYN) requests to the target. The target system then sends acknowledgements and waits for replies. Because the forged IP addresses don't belong to any actual machine, there is no reply, leaving connections open and blocking legitimate traffic.
3. Source route manipulation: a denial-of-service and data-hijacking attack in which an attacker manipulates routing table entries (usually at the border router) to redirect traffic intended for one site to a different one, where the information can be intercepted, or to nowhere.
Blocking and Filtering
Disabling "broadcast" at the border router can block Smurf attacks. Timing out incomplete SYN requests at intervals of three seconds or less usually wards off SYN floods. And IP route packet filtering can catch hijacking attempts. In fact, filtering is what TCP/IP protections are all about, say IT professionals.
For example, many victims of recent distributed denial-of-service attacks are now filtering traffic at their Internet service providers rather than waiting for the flood to hit their own machines. Some have also configured their operating systems to time out SYN requests faster and are changing the IP address of a server under a denial-of-service attack to move it out of harm's way, Raines says.
Bill Hancock, chief security officer at Exodus Communications Inc. in Santa Clara, Calif., says that, in addition to firewalls and intrusion detection, his organization uses the following filtering techniques:
• Edge-router filters to block traffic from bogus addresses or SYN attacks at the edge of the network.
• Rate-limiting filters to stop incoming connection requests to protect against high volume attacks.
• Traffic-flow analysis to detect inbound connections that match known attacks or to backtrack to source for prosecution.
• Traffic and Domain Name System (DNS) redirection to redirect attacks coming at them via high speed hardware aimed at the DNS server.
• Host-based firewalls to protect against direct denial-of-service attacks by filtering out known types of attacks.
But organizations like Hancock's are the exception rather than the norm.
"These security features aren't in the default configuration. IT people don't turn them on because they're too busy . . . or they just don't know about them," says Ian Poynter, president of Jerboa Inc., a security services firm in Cambridge, Mass. "Or they're afraid filtering is going to slow them down. But these features don't create much of a performance hit."
For example, Cisco Systems Inc.'s routers contain a feature called unicast reverse-path forwarding check, a reverse IP lookup capability that has been part of Cisco's Internetworking Operating System (IOS) since the release of Version 10 three years ago. The function can detect forged traffic by checking upstream routing tables to see if packets are coming from the IP address they claim.
Barbara Fraser, a consulting engineer at Cisco, says that while these technologies are almost ubiquitous, "People just aren't using them."
Concerns over performance problems are also to blame for the new threat to ISN guessing, according to Brady. The vendor community had a chance in 1996 to adopt a more robust random sequence generator, penned in a standards modification titled RFC1946 by Steve Bellovin, a fellow at AT&T Labs in Florham Park, N.J. But "most vendors didn't want to move to RFC1948 because it was more costly in terms of CPU usage," says Brady.
Also being widely ignored is IPSec, a subset of IPV6, which is designed to use public keys to authenticate machines before making a connection, says Baker. These enhanced security features, both of which were published in 1998, would help solve many of the TCP/IP security problems, including the issue of ISN guessing, say Baker and Brady.
"Everybody [in the vendor community] has IPSec on its road map, but nothing's available today," adds Patrick Grossetete, Cisco's IOS product manager.
Poynter and Raines suggest that the business community hasn't seen a compelling reason to move forward with IPSec or IPV6, especially with virtual private network tunneling performing pretty much the same function as IPSec.
Besides, upgrading to IPV6 presents the classic chicken-and-egg problem, adds Poynter. Everyone would have to upgrade to IPV6 at the same time. Otherwise those that migrate first will lose access to parts of the Internet due to compatibility issues.
But sometime soon, there will be an unavoidable business driver to upgrade to IPV6: a need for more IP addresses, says Mark Himelstein, vice president of engineering at Sun Microsystems Inc.
IPV4 can support 4.3 billion addresses, but V6 can support an almost unlimited number. And with wireless Internet appliances sweeping in, the need for address space will soon explode. With the larger IP addresses in the V6 standard, Himelstein adds, "there'd be enough IP addresses for every molecule on the planet."
The need for deeper filtering and IP security will also explode, Himelstein says. Otherwise, any Internet-connected device, even Grandma's fridge, could someday hack the world.