Preparing for a Denial Strike

SAN MATEO (06/12/2000) - I remember a favorite prank from my university days that involved wedging a locked door's bolt against the frame by cramming pennies in the gap between door and frame. This ensured that the rightful occupant couldn't turn the key in the lock, which seemed incredibly funny, until it happened to me. That was a primitive form of a denial of service.

Of course, in the enterprise business environment, DoS (denial of service) carries much higher stakes. Today, DoS attacks are a constant concern for IT executives and managers, particularly those who hold responsibility for high-profile sites that are critical to the success of corporate strategies.

A number of apologists have tried to excuse the actions of DoS perpetrators by equating their attacks with innocuous childhood pranks, such as doorbell ditch or crank telephone calls. The distinction is that I have the choice to ignore the doorbell or telephone (and I often do). An Internet server has no choice but to respond to network queries, and its unavailability can literally spell death for a company.

DoS attacks are scary because you usually don't know who the enemy is and you often don't know how compromised your systems are. But perhaps worse is that you're now torn between the need to protect your company's business and plug that leak and the equally compelling need to collect enough evidence to nail the punk, particularly if you want a case that will stand up in court.

The best way to avoid that dilemma is to prevent DoS attackers from getting that far in the first place. Preventing their success requires a solid defensive strategy that considers internal as well as external threats.

Knowing your attacker

Of course, not all DoS problems are attacks. Some accidents are inevitable in a decentralized environment such as the Internet, where a corrupt routing table can wreak havoc in a matter of minutes.

Internal networks face similar problems, although a well-designed enterprise network will partition traffic in such a way that problems can be easily isolated.

Actual attacks, of course, can come from either inside or outside the enterprise. Although this discussion focuses on the external adversary, any plan to mitigate the effects of a DoS incident must allow for the possibility of an internal threat as well.

But despite the risk of attack from within, the greatest threat to the security of companies using the Internet remains the roguery of the teenage male.

(Although interest in and understanding of computer network operations has grown among young women, statistics still indicate that computer hacking is a predominantly male pastime.) The truly unfortunate thing is that today, tools exist that allow relatively unsophisticated computer users to launch attacks from the family den. The "script kiddies" grow in number with every day, so DoS is likely to get a lot worse before it gets better.

The ABCs of DoS

DoS attacks encompass an extremely broad range of methods. Among these, three of the most popular involve disabling services, monopolizing or usurping resources, and sabotaging data.

Drastic DoS attacks involve configuration changes or physical assault of the attached network devices. The physical threat is usually the easiest to defend against; traditional "gates, guards, and guns" security principles usually work well in this instance.

Network-borne DoS attacks have gained ground in the last year or so, aided by a new method of distributing the attack among several hosts. This increases the likelihood of a successful penetration by using the cumulative processing power and network resources of the hijacked hosts. These DDoS (distributed denial of service) attacks became familiar in 1999 when attackers used the "Stacheldraht" (a German word for "barbed wire") and Tribe FloodNet tools to bring down some of the most popular Internet destinations, including Yahoo Inc. and eBay Inc.

In both cases, the tools use the massed attack approach to overwhelm targeted hosts.

Of course, in one form or another, DoS attacks have been with us for a while: radar and radio "jamming" are classic examples. But as the Internet becomes a mainstay of economic prosperity, any disruption in its traffic acts as a hand clutching the windpipe. Here are some of the most common ways that DoS vandals like to grab your throat.

"Hogging" is a classic attack method that usually involves bypassing normal operating system controls to run a program on a host that consumes system resources until the OS fails and crashes the host.

The Robert Morris Internet worm of 1988 provides a good example of hogging, despite the fact that it is generally classified as a Trojan horse by virtue of its exploitation of the sendmail bug. Morris had intended for his program to run undetected over a period of days or weeks, but a gross design flaw caused it to replicate too quickly, thus overwhelming its mail server targets in a manner of minutes.

Because this sort of attack has been around for a long time, many operating systems have elementary safeguards in place. Unfortunately, as any Windows NT manager will confirm, adding features to an operating system increases the number of security holes, so you can't consider "hardening" a system to be a closed-end project.

"Hostile applets" are a form of DoS attacks that target users rather than servers. An applet-based attack will essentially hijack a computer through a Web browser that allows applets to run by default. Enterprises that can enforce a no-applet policy and make it stick have an edge against this type of attack, but that may not be worth forgoing the benefits of applet technology.

"Mail bombs" are simple and brutal: They overload a mail server with vast amounts of bogus traffic. Needless to say, even the biggest mail server has its limits, so no mail systems are immune to this type of attack. (Note to vandals:

In these cases, you may want to use filters to identify and reject suspicious traffic, but you take the risk of bouncing legitimate communications.

The "Ping of Death" exploits the PING (Packet Internet Groper) utility by sending an illegally sized test packet. Although this is most commonly seen in IP environments, there's nothing that prevents it from being executed over IPX, for example. The oversized packet can crash or induce network problems in unprotected systems.

"SYN flooding" is specific to TCP (Transmission Control Protocol) and attempts to usurp all possible network connections, thus denying legitimate traffic access to network services. This exploits the functions of the SYN (SYnchronize sequence Number) packet that initiates a conversation between two hosts.

By falsifying the identity of the packet sender and then sending a barrage of fake packets that the target server must respond to, the attacker ties up the server with the replies. The server is unavailable to regular users except those lucky few who slip through among the bogus requests.

"Zombies" are computers that have been compromised by an attacker and are being used (or held in reserve) for an attack. The DoS attacks that were so prominent last year used zombies to generate enough traffic to disrupt operations at the Internet's most-visited sites.

What can be done?

Unfortunately, many enterprises don't realize that they have a DoS vulnerability until the hoodlums are running amuck. Even if the assault is aimed strictly at your network connections and isn't attempting to penetrate sensitive company data, this is still too late to begin implementing a defense.

But a good offense is a bad idea. Retaliation is strongly discouraged, because you can't be certain in the heat of the moment that your attacker isn't using someone else's identity as a front and because any network-based counterattack is going to violate the same laws you want to use for a conviction, if it goes that far. This isn't a home invasion and you don't have the right to shoot back.

Obviously, there are some things you can do in advance to minimize your vulnerability. If you don't have a good, well-understood firewall in place, get one. The well-understood part is the key; too many shops install a firewall but fail to train key employees in its configuration and use.

Thankfully, any decent firewall available today will come configured to deny all traffic, reducing the problem to the traffic that you've explicitly enabled. Other devices on your network, such as switches, routers, and desktop computers, should also be checked to verify that they're only passing permitted types of traffic.

Other perimeter security measures you can take include e-mail filters and virus-detection software. These need to be maintained religiously to be effective but are useful in providing a defense behind the firewall.

Having baseline network traffic data can help distinguish traffic surges caused by legitimate transmission of rich media files from those caused by a swarm of hackers.

A new and interesting type of active defense is Recourse Technologies ManTrap, which provides a decoy Web environment that diverts hackers away from your crown jewels and into a secure "cage" where you can log their activities and gather an evidence trail for law enforcement.

One eye on the headlines

Staying informed is key to any good defensive strategy. Because of the global nature of the Internet, a problem that starts in the Philippines can be affecting servers in California in a matter of minutes.

Although the Web sites of the FBI and other government and industry watchdog organizations are a wealth of information, the mainstream news media is becoming cognizant of the importance of computers in today's economy and society and is usually a good source of real-time information regarding system assaults and computer virus outbreaks.

One step I cannot overemphasize is to keep current with application and OS patches. A difficulty here is walking the line between ensuring that patches won't destabilize a production system and having a secure configuration. Test your patches, but have a procedure in place that allows you to upgrade machines as soon as possible once your testing is complete.

Ensuring that machines, and not just computers, are configured to run only essential and necessary services is paramount. Although Web-based interfaces are certainly prettier than a Telnet console, Cisco users are finding out the hard way that adding management features to a router might raise more problems than it solves.

Shops using the software-based HTTP server in recent versions of the Cisco OS, which allows the router or switch to present data via a Web browser, were advised in mid-May that under certain circumstances the HTTP server could be compromised.

Reality check

Preparing for the worst is a grim task, but it saves a lot of shouting when the fertilizer hits the fan. One of the biggest mistakes companies make during a crisis is forcing people in the front lines to wait while upper management struggles to cope with the emergency.

An enterprise's emergency response team is designed to address this problem.

Determining in advance who has the authority to cut network connections, shut down or restart servers, or perform other drastic steps may cause some ruffled feathers but is worth it when time is a crucial element.

Another aspect of preparing for the worst is training. Simulating a DoS attack is the best way to determine where your organizational vulnerabilities exist and to familiarize staff with emergency procedures. Addressing these issues won't prevent your next attack, but drilling staff on critical tasks will make the correct reaction a matter of routine.

Some sort of external audit is also a good idea. Although "tiger teams" are available for hire to probe networks, I'd recommend against using any but the most reputable of firms for this kind of work.

You're probably better off looking for a professional auditing firm with network security experience as opposed to a consultant, because this is one of the instances where the auditor's training outweighs any technical issues.

Stealing thunder

Unfortunately, there's not a lot you can do to prevent a DoS attack, but you can make one difficult and unrewarding for the perpetrator.

Much of what I've outlined here is common sense, but it bears repeating: Don't enable services you aren't using, keep your systems patched, use the same game plan in practice that you will on game day, and you might survive the next one with your job and your data intact.

P.J. Connolly (pj_connolly@infoworld.com) is a merry prankster who covers networking and security issues for the InfoWorld Test Center.

The high price of manageability

Web-based management has been touted over the last few years as the greatest thing since sliced bread. Because all management data is presented in a well-understood format, shops have to deploy fewer management tools, users face a shallower learning curve, and even the starkest browser-based interfaces present data more effectively than a Telnet session.

But one hardware vendor is learning the hard way that adding Web services to hardware can leave customers vulnerable.

Cisco, one of the largest manufacturers of networking hardware devices, provided its customers with a nasty surprise in mid-May when the company confirmed the existence of a defect in multiple releases of Cisco's Internetwork Operating System (IOS), the core software component of much of the company's product line. The defect (a description is available online at www.cisco.com/warp/public/707/ioshttpserver-pub.shtml) can cause a switch or router to halt or reload, thus interrupting service.

According to documentation provided at Cisco's Web site, the defect "affects virtually all mainstream Cisco routers and switches running Cisco IOS software releases 11.1 through 12.1, inclusive." (That should get your attention.) Fortunately, as of mid-May Cisco had received no reports that the defect, first posted to the Bugtraq mailing list on April 27, had been maliciously exploited.

Essentially, the problem exists in the software-based HTTP server that presents the management information to a connected user, usually a member of a network management team. Browsing to the address http:///%% will crash the router or switch.

In rare instances, this may require a hardware restart to recover. At best, your device is down for at least two minutes.

There are some bright spots, as any Cisco device not running IOS is automatically immune. If you haven't enabled Web management on your routers and switches running the affected versions of IOS, you're still home free.

To check your devices, log in and issue the Show Version command, which will let you know if you're running an affected release of IOS. Cisco's defect description also includes a matrix of release versions and defect status.

Even if you are affected, there are things you can do. The easiest is to stop using the Web management features and disable the HTTP service on your routers and switches until you can deploy rebuilt versions of IOS, which are available now, to all devices on your network. Maintenance releases issued at the end of May or later will incorporate the fix, as will the current cycle of interim IOS releases.

Other temporary fixes you can implement include changing the device's access lists in a couple of ways. You can apply a standard access list to restrict use of the HTTP service itself or use an extended address list to block the traffic in the affected network path. Because the second method can have unexpected results in extremely complex configurations, you're better off trying a less elaborate approach.

Browser-based hardware management isn't a bad thing at all, but when it's implemented without regard for basic security principles, it can open up a world of vulnerabilities that customers may not be prepared for. Enhancing your management tools is a great thing, but don't cut yourself doing it.

Recourse baits the hook for crackers

Sometimes it's not enough to deter an assault on your enterprise; far better to actually catch a malicious attacker in the act. If your enterprise is attacked, you'll undoubtedly want to see the attacker prosecuted and convicted.

The good news is that the U.S. government and FBI are taking computer crime much more seriously than they did 10 years ago. The bad news is that the onus is usually on you to provide the evidence to catch those responsible.

That requires you to document a pattern of attacks, which means maintaining the cracker's interest while at the same time preventing him (or her, but in reality it usually is a him) from doing any damage to your systems.

That can be a hefty proposition, especially because your efforts will never make a dime for your company. On the other hand, the alternative -- being at a computer criminal's mercy -- doesn't fly.

So how do you protect your assets while trying to catch the brats who are disrupting your operations? Even more difficult, what if your attacker is coming from a trusted system belonging to your company or a partner? Classic deterrence techniques won't help you find the traitor in those cases.

The first move is usually to create a honey pot of false data, a classic example of which is documented in Cliff Stoll's book The Cuckoo's Egg. The trouble with honey pots is that they go stale, and these days the targets of choice aren't e-mail and file servers. Providing a tempting target for crackers requires that you put up other applications to simulate your e-commerce environment.

Recourse Technologies (recourse.com) has taken the honey pot to a new level with ManTrap, a host-based tool that creates a false operating environment that looks real to intruders.

ManTrap, priced at $5,495 per server, is a Solaris application for Intel or Sparc hardware running Solaris versions 2.6 or 7 that features browser-based management, a random content generator for maintaining e-mail honey pots, and the capability to work in a variety of environments.

ManTrap works by diverting suspicious traffic into a "cage" running on the ManTrap host, where you can capture keystrokes and log an attacker's behavior.

This gives you an idea of which defenses on your production systems need to be enhanced while providing the all-important documented evidence trail that will help you gain a conviction, or at least an arrest.

Although ManTrap can be used with a variety of applications to provide realistic "set dressing" for your cage, you'll have to supply most of the data.

How the issue of detecting and prosecuting DoS (denial of service) attackers will end is anyone's guess, but employing these digital gumshoes improves the odds that you will apprehend intruders, whether they're coming in from your network or from the opposite coast.

Unfortunately, because victims of crackers will have to do most of their own sleuthing for the foreseeable future, it's nice to know that there are at least some tools available to help you snag a crook without further compromising your security.

THE BOTTOM LINE

Denial of service preparation

Business Case: Whether launched from the inside or perpetrated by an external attacker, DoS attacks can bring your network systems to a screeching halt for a period of minutes to hours, to say nothing of the damage to your company's reputation in the eyes of customers and business partners. Preparing for the eventual likelihood of such an attack puts you in position to minimize the damage and get systems back on track quickly.

Technology Case: Many DoS attacks exploit systems that either lack the proper OS patches or are improperly configured. Addressing these issues will only solve part of the problem, because the skill level needed to carry out a DoS attack is pitifully low. Any enterprise where security drills don't include a DoS attack is asking for trouble when it does happen.

Pros:

+ Proper preparation can put you in position to detect an attack early+ Possibility of gathering an evidence trail for use in prosecutionCons:

- Forces companies to spend time beefing up security at the expense of business objectives- Requires constant vigilance, as OS updates and patches can open new holes.

Copyright 2018 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.