Hey, did you know that the home page on your Web site says, Hacked by Chinese?”
Getting an e-mail or a phone call to this effect is not how you want to find out that something has gone wrong with your Web server, but this is exactly how many site administrators were informed that their systems had become infected with the Code Red worm. These administrators then had to deal with the question, “What do I do now?”
Answering this question, and the many that will follow it, is the focus of Part 4 of eWeek Labs Special Series, 5 Steps to Enterprise Security. Responding to security breaches involves not only stopping attacks but also learning from the experience to prevent future attacks.
The technical steps required in response to an attack via worm, virus or dedicated cracker exploit will be essentially the same, no matter what the business or what the purpose of the attacked system is. Although it seems logical to react more aggressively to infection of mission-critical systems, such as databases or e-commerce systems, a seemingly innocuous system is just as dangerous, either as a host for more infections or as a launching point for hacker attacks on more vital systems.
Nontechnical responses to attacks will differ depending on the type of business. Government agencies, for example, will respond in a different way than private companies, which will respond differently than universities.
In any case, the following steps are essential in responding to an attack.
Stop It
An infected system needs to be taken off the Internet immediately to prevent the spread of a malicious program.
Say youve just received an e-mail alerting you to a problem, or maybe your IDS (intrusion detection system) detected a potential attack, or maybe you found unexplained files on a system. You may be tempted to leave the system up and running and connected while you fix it, but you must avoid this temptation—even if it means losing revenue. If its your organizations Web site or another crucial server, there is (or there should be) a backup system in place.
If youve been hit by a worm or cracker, every second the system stays connected is time that it could be infecting other systems in your network or possibly attacking systems at other companies. You dont want to become part of someone elses response strategy—they might not be as nice as you are.
This doesnt mean, however, that you have to shut down systems youre suspicious of; disconnecting them from the network will be enough.
Learn From It
You eventually have to clean up an infected system but not before finding out how the system was compromised.
Some worms, such as Code Red, are immediately obvious because they cause telltale Web defacements. However, other worms arent as apparent, and if a cracker has commandeered the system, it can be almost impossible to find out how.
An IDS can detect some illegal use of company systems, but crackers and worms can also hide in standard network traffic and on standard ports. Still, there are several steps that can be taken to find out what happened.
On Windows servers, a virus scanner may be able to find worms or Trojan backdoor programs. Administrators should look for new user accounts and new files (such as root.exe in the scripts directory or any number of Common Gateway Interface programs). Warez directories in your Web or FTP server are also a dead giveaway that your system has become someones playground.
System and application log files are a big help in detecting what happened. These files detail changes and let you know when these changes happened.
System snapshot tools such as Tripwire Inc.s Tripwire, (www.tripwire.com), can be extremely useful. Using these tools, administrators can take regular snapshots of system files and settings and can then easily see any changes that have been made to the system.
Gathering a combination of these system changes and entering the information on the search pages at sites such as www.sans.org, www.cert.org and www.securityfocus. com will often point you to the exact exploit that was used on your system or the hole that was abused.
Remove It
After youve figured out how a system was compromised, you need to remove worms or exploit programs and possibly even wipe the system clean.
Some worms can be removed by simply deleting a single file, but others, including Nimda, infect a large number of files on a system. A cracker looking to do as much harm as possible has probably loaded several backdoor programs, created and changed user accounts, and created new holes.
On Windows servers, an updated virus scanner will probably detect any worm or backdoor programs. For Unix and Linux systems, the security sites mentioned above offer details on how to clean systems.
However, its almost impossible to ever feel good about a system that was cracked or infected by a worm. The best course of action is often to wipe the system and reinstall the operating system and applications. Besides being sure that there arent any potential problems left behind, you can then implement stronger security from the ground up.
Use of disk-imaging tools such as Symantec Corp.s Norton Ghost can be helpful when restoring systems to default configurations or for backing up systems. However, it is extremely important to make sure that the images themselves are free from security problems and are fully patched, or poorly secured systems could continue to pop up down the road.
Fix It
The next step is to make sure that a problem doesnt recur—patches must be applied or workarounds implemented to prevent future attacks. Following the steps from Prevention, Part 2 of this series, is a good start. (See story at www.eweek.com/links.)
However, its important to remember that patches and workarounds are not cure-alls. A system in eWeek Labs that was infected by Code Red had been properly patched, but subsequent installation of an application on that system negated the patch.
This is a good time to increase the total security level of your systems. In addition to adding patches, remove all unused applications and extensions, and add additional layers of security, such as firewalls or trusted operating system programs such as Argus Systems Group Inc.s PitBull (www.argus-systems.com).
Free programs such as Microsoft Corp.s HFNetChk (support.microsoft. com/support/kb/articles/Q303/2/15.ASP), the Center for Internet Securitys security benchmarks (www. cisecurity.org) and the Bastille Linux hardening scripts (www.bastille-linux.org) will either find potential holes, suggest improved security measures or actually configure systems to be more secure.
For new security problems—especially for people and organizations unlucky enough to be the first affected by them—there will be no patch available. In these cases, a workaround will probably be available from security sites, but it may also be necessary to disable an application or service until the hole is addressed.
You should also consider changing the IP address of a compromised server, especially if it was used for warez or if its IP address has been passed around or added to lists used by script kiddies. In these cases, systems might be probed constantly, which—at the very least—will affect performance. Also keep in mind that worms and crackers rarely hit one system. You must check every system on your network to see if they have been affected by the worm or intruder.
React to It
Perhaps the most difficult part of the response process is dealing with the nontechnical issues that come up after an intrusion—specifically, how to deal with the attackers, internal management and external agencies involved.
IT administrators first response after an attack is often anger and frustration. The desire to strike back at attackers can be very strong.
There are programs that will launch denial-of-service attacks against attacking IP addresses, and honeypots have been used to attract crackers and then trap them. However, these kinds of retaliation or entrapment are a bad idea. For one thing, the odds are high that the IP address youre responding to is a zombie system, meaning that you are attacking another victim. At that point, you could be considered a malicious cracker and could be subject to legal action. And honeypots are best left to security experts and legal authorities, who are better equipped to deal with an angry cracker.
Every IT department should have a written policy on how intrusions are handled and who should be notified, from department heads to management to the legal department to law enforcement agencies—specifically, the FBI. This is especially important during this time of heightened risk.
Of course, many businesses may want or need to take legal action of their own. IDS programs and log files will usually provide the IP address of attackers, and standard tools such as traceroute and Whois make it possible to find out who is running that IP address.
However, this is a very gray area legally because the systems launching the attacks are likely zombies. While legal action may be necessary in cases where attacks are common and the owners refuse to address security issues, in most cases the best and most effective response is an e-mail to system administrators alerting them that there is a potential problem. This is probably the response that you would appreciate in cases where your own systems are turned against others.
This doesnt mean that there is nothing that can be done to fight back. At eWeek Labs, our favorite response is to run the free LaBrea application, which actually traps worms at virtual IP addresses and prevents them from spreading. (See the Labs review of LaBrea at www.eweek.com/links.) We expect LaBrea and proactive tools like it will become more common as the security community looks for ways to stop the spread of worms.
However, the best way to fight against crackers and worms is to practice good security. Life as a cracker or a worm becomes a lot more difficult once security administrators start closing all the open doors in their systems.
East Coast Technical Director Jim Rapoza can be reached at jim_rapoza@ziffdavis.com.
