Tip

Five steps for beating back the bots

Miscreants are hijacking and linking thousands of compromised computers, called botnets, to launch coordinated attacks. Large enterprises may have hundreds of compromised hosts being used by a single attacker. And numerous attackers are likely using multiple sets of computers. Defending against botnet attacks is challenging and complex. Here are five practical steps for identifying and ridding your network of bot infection.

Bots (short for "robot") are programs that listen and respond to commands on Internet Relay Chat (IRC) channels. A group of bots acting in concert forms a botnet. Bots can be found running on any OS, although they are more commonly found on computers running Windows.

1. Scan hosts and network traffic for the telltale signs of bot infection.

Many bots are part of

    Requires Free Membership to View

blended threat kits, which include the bot, FTP file servers, proxies, ident servers and back doors. The bot is used for remote control of the computer and for serving files (e.g., pirated software). The FTP server is often used to transfer files into the system, or to serve files. Proxies serve to anonymize attacker connections by bouncing them through intermediary hosts, or to bypass antispam filters. The ident servers provide AUTH protocol responses that identify (falsely, in this case) the account associated with an incoming connection, which is required by some IRC servers. Back doors enable a remote connection to the computer for controlling it, bypassing normal login access control and accounting sub-systems.

Some bots implement all these features in a single program. Bot hosts will often exhibit listening behavior on network ports to find those that respond or are open to more in-depth probing. Monitoring for anomalous network connections, such as a desktop system receiving incoming HTTP or FTP connections (i.e., acting like a server), or performing service enumeration scans of your internal network, will enable you to detect compromised hosts or patterns of activity from many systems (e.g., a dozen computers suddenly all listening on the same port). Also, border-level flow analysis or packet content analysis can allow you to detect and react to the recruitment phase of botnet attacks and find active bots. For example, a dozen computers on your network communicating with an IRC server in an eastern European country, or your DNS server showing obvious IRC chat traffic on a high-numbered TCP port, are obvious signs confirming suspicion about the integrity of hosts on your network. Knowing what kind of communication is normal and legitimate for a given host and comparing observations about what is really happening can quickly advance your investigation. You can then selectively block connections to deny an attacker continued access to your hosts, or remove infected hosts that are actively propagating malware to third-party sites.

2. Tune routers, firewalls and intrusion-detection/prevention systems to detect and block botnet traffic.

IDSes/IPSes are designed to detect attacks (usually by signature and possibly through anomaly detection), and then report on or block these hosts. For example, signs of an incoming attack to a host using a Web vulnerability, which is later followed by signs of outbound attacks using the same or other attacks, can indicate the presence of a worm or bot. Firewall access control lists can be used to block attacks, which can also be logged. For example, if you are following best practice and isolating services, you could block all Internet access except UDP and TCP port 53 to your DNS servers, limiting attacks on other services, like SSH, RPC, etc. Most enterprises have a variety of these network security defenses in place. Even without a border-level firewall to restrict incoming or outgoing connections, you can tune an IDS/IPS to watch for telltale signs of bot command and control on standard IRC ports or on non-standard ports. Of course, you must know what to look for in order to tune these systems to find it. That would mean using signatures for various malware with your IDS. These can be obtained from open source rules databases, e-mail lists or analyses of malware (e.g., the analyses of Trinoo and Stacheldraht produced in 1999/2000 included Snort rules to detect their command and control). On the down side, the encryption capabilities in newer bots will render such detection useless so don't count on it finding everything.

3. Secure hosts against botnet exploit.

Some commonly used and inexpensive software can effectively secure host systems against botnet exploit. For example, system integrity checking, encryption software, personal firewalls and antivirus/antispyware tools can help harden user desktops. Similar software exists for servers. These measures decrease the chances that host systems will end up running bot malware, but will do very little to protect your network against a massive denial-of-service attack. Since bots these days integrate SMTP proxy and direct delivery features that are used for spamming and phishing attacks, employing antispam filters may help to eliminate scams and phishing e-mails, but will likely not stop all of it. An often overlooked and relatively inexpensive defense is user education. Having savvy users, who understand their role in maintaining integrity and confidentiality in your information systems, as well as understanding how attackers will try to trick them, can minimize the risk of these social engineering attacks.

4. Apply reverse engineering to bot code.

Reverse engineering is an advanced discipline that requires detailed knowledge of programming languages, compilers/linkers/loaders, software engineering and debugging. Due to the advanced skill requirement and time required to perform the many manual steps involved, most enterprises don't have resources to do full reverse engineering of all malware found on their hosts. Knowing the basics of malware analysis, however, helps in understanding how attackers use your hosts, how malware may be identified on hosts and even how to disable an active botnet. For example, it was possible to extract the handler IP addresses from Stacheldraht DDoS agents if you knew enough about using a disassembler, identifying subroutine call setup in assembler and doing decimal-to-ASCII conversion.

5. Work with law enforcement to help prosecute botnet creators.

Regardless of how your hosts are involved in a botnet attack -- as an intermediary, exhibiting command and control or stepping-stone behavior, or as a final target, seeing an incoming flood of traffic or site-wide attempts to determine passwords through dictionary attacks on login services -- it's in your interest to collect and preserve at least some evidence of the attack. Where and how you gather evidence depends on the role your hosts play in the botnet attack. For example, the victim of a flooding attack need only gather samples of attack traffic from the network, or router statistics indicating the type, severity and duration of a DDoS attack. Sites with handlers (rogue IRC servers) or agents (bots) will have both command and control traffic on the network that should be sampled, as well as malware installed on hosts internally that should be imaged and preserved.

Law enforcement needs properly preserved evidence, along with reports giving precise details of attack activity (e.g., source IP addresses and site contact information, IP<->DNS mappings and time when they were determined, logs showing all hosts at your site that were affected, etc.). It is important to note the date, time and time zone of each event, and whether the time is in sync with trusted time sources (or to provide the clock skew when comparing the system clock with a trusted time source). Use Network Time Protocol to synchronize clocks. Not all logs contain all attributes, so correlating multiple log sources can provide the added detail required to produce an accurate attack timeline.

Law enforcement must prioritize their resources so another important factor is accurate damage estimation. This can include time spent by your team coordinating the incident response, system administrators' time for restoring systems to a trustworthy state, the lost productivity of your workers and lost customer revenue.

The future outlook isn't promising -- bot-affected software is growing more powerful and stealthy, making it harder to find and return to a secured state. The pressure is on computer users to become savvier about security and on organizations to spend more money on proactive defenses, and detection and reaction capabilities. Law enforcement will also need to deal with an increasing number of crimes that involve potentially thousands of computers at a time.


MORE INFORMATION:

About the author
David Dittrich is an Information Assurance researcher at the University of Washington Information School, and has over 20 years of programming, system administration and information security-related experience. Dittrich is also a founding member of the Honeynet Project and co-author of "Internet Denial of Service: Attack and Defense Mechanisms."


This was first published in March 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.