21.4 Small Networks

Since corporations often have their own endless tomes of security "best practices" governing incident response (however inadequate they may be, due to the policies being out-of-date, not promoted, or simple not followed), we'll first focus on incident response for home systems or small businesses.

What are the ideal requirements of a small home office LAN or home system security response? Keep in mind that few users are excited about reviewing their system logfiles. Even fewer collect attack statistics from home systems (unless they are members of the http://www.dshield.org distributed intrusion detection project). Still fewer care about failed attacks (like CodeRed on a system with no web server or on a Unix machine). While collecting such data might make for scintillating conversation for experts, the average user probably does not care how many CodeRed hits his personal firewall blocked. In Windows environments, it is more practical for the average user to simply clean viruses in case of infection than to save them for future dissection and cataloging. While readers of this book might well be interested in dissecting Windows malware (see Chapter 2), most end users are not likely to have such a hobby.

An important consideration in a small network is that there's usually no administrative requirement to keep audit trails for evidence ”so most people do not keep them. Such neglect complicates incident response in comparison with corporate systems. While it is becoming more popular to report port-scanning kiddies to their ISPs, the endeavor often proves futile, especially when the suspected attack comes from a remote country. In fact, many apparent "attack attempts" actually come from worms trying to penetrate systems on random IP addresses, without regard to available vulnerable services.

Note that this heightened user transparency shouldn't undermine the efficiency of security measures: the fact that users do not notice security measures should not undermine their efficiency against threats the measures are designed to counter.

Home security should serve to stop casual attackers from abusing the system, block popular automated attack tools such as worms, and (depending upon the individual security requirements) prevent some sophisticated intrusions as well. If the system is compromised, there should be enough data logged to learn what happened . This helps prevent recurrence , but it's probably not enough to build a solid court case.

Before we dive into the area of response, let's briefly return to prevention, since it falls within the preparation part of incident response, according to the SANS six-step model. Here are some of the examples of best practices for securing a small home LAN or a single Unix/Linux system:

1. Remove all network services that are not used (NFS, NIS, web server, etc.).

2. Set the host firewall (Linux iptables, ipchains, FreeBSD, NetBSD, or ipf or OpenBSD's newer pf code) to drop or reject all incoming connections from the outside. If you can live with these restrictions, it will prevent all network hacking almost as well as being disconnected from the Internet: limiting outbound connections can be useful for a home network and can protect against a Trojan rooted inside.

3. Use a strong password or long passphrase. (If you do allow remote access, it makes sense to make password guessing more difficult.)

4. Use some form of automated backup (i.e., hard drive mirroring via script or similar provision).

Some elements considered "good security" (such as patching regularly) are conspicuously absent from this list. The reason is that the above measures simply need to be enabled once and require no maintenance, while contributing a great deal to security.

The incident response plan for smaller systems will likely be aimed at putting the system back as it was and preventing repeat attacks. The recovery stage of the response framework is perceived as much more important than follow-up. Dissecting the attack or seeking prosecution is usually impractical , outside of trying to prevent recurrence. Reporting to law enforcement might be appropriate for the larger company, but the smaller administrator usually elects to forgo such a labor- intensive endeavor. Still, even for smaller companies and individuals, knowing what to do in case of a malicious hacker break-in is important. An advanced preparation stage often saves a lot of grief during the actual break-in. You need an incident response plan that is created during the preparation stage of the incident process. Even though you might not think of it in terms of a formal response plan (as companies do), thinking ahead and having a plan prevents panic and other destructive reactions . Panic occurs when we encounter the unknown ”and getting hacked constitutes the unknown for many users. However, wide availability of broadband and the still-miserable state of home/small office network security is changing that for many people. Moreover, while not everyone is hacked, viruses hit almost everyone, especially if you have to administer Windows systems.

So what is your response plan? If you think you are being hacked, the first step is to disconnect from the Internet. Simply pull the Ethernet plug, or turn off your cable or DSL modem. That's it ”you are safe for now. (This advice is not always applicable in corporate situations, where security administrators might want to monitor the hacker ”if for no other reason than to collect enough evidence to build a court case.) Now, is it safe to plug the system back in? Not necessarily . If an attacker installed a backdoor or provided other means for returning, connecting the system before doing a cleanup is harmful . Similarly, rebooting the system probably won't help.

Look around for suspicious signs. Are any files missing or new applications running? Is your antivirus product (if you have one) complaining? What about your personal firewall? In Windows 95/98/ME, there's not a lot you can do. Apart from looking at running programs using the Task Manager (called by Ctrl-Alt-Del) or running Microsoft System Information, there is not much diagnostic power. However, you can search the Web to find WinTop, an old Microsoft PowerToy for Windows 95 that still works fine. Figure 21-1 shows WinTop running on a Windows ME machine.

Figure 21-1. WinTop diagnostic utility

WinTop shows all the processes running on Windows and identifies some classes of backdoors and hidden servers. Windows NT/2000/XP uses the built-in Task Manager to identify running services and processes. The Windows NT/2000 Resource Kit from Microsoft also contains several useful tools to kill processes and monitor users accessing the system remotely. In addition, many third-party utilities are available for Windows NT/2000 incident response, such as tools from SysInternals (see Chapter 2). These tools identify running hidden processes, discover network connections (and the processes that initiated them), and reveal connected users. Windows NT/2000/XP also has much better system logging support (Event Log) than Windows 95/98/ME (which has barely any). Having a disk with a trusted version of these utilities can really help, since you will know that hackers have not compromised the versions of the programs you are using.

Malware (such as Trojans and worms) can hide from these process viewers . Some utilities (such as those from SysInternals) provide a more in-depth view. Having system integrity software such as Tripwire helps, but the Windows version is not free. In addition, Tripwire is not designed for end users, but for corporate security departments.

On Unix/Linux, the trusty old /bin/ps command helps, as shown in Figure 21-2.

Figure 21-2. Screenshot of /bin/ps

Malicious software (like rootkits, evil kernel modules, and network backdoors) can hide from /bin/ps . For Linux experts, looking in the /proc directory will help, as shown in Figure 21-3. (In Figure 21-3, ll is an alias for ls -l , common on Linux systems.)

Figure 21-3. Examining the /proc directory

How can you use the /proc directory to look for signs of malicious activity? In the above ps output, the process with ID number 818 is "named" ”the Unix DNS daemon. Pretend for a second that it is a malicious "named" started by hackers and it hides from the ps command (e.g., by modifying the /bin/ps binary, as some older rootkits do). Then we can compare the process IDs shown by /bin/ps with the contents of the /proc directory. In this case, we would see that all process IDs shown by ps have their own entries in /proc , but there is another entry for "818" that is not in the process list. By simply performing the following:

 cd /proc/818 ; ls -l 

we can see all the processes (listed in Figure 21-4).

Figure 21-4. Process list

The process with this ID is indeed "named" (see the "exe" entry above for the process name ). To get more details, look at various entries such as "cmdline" or "status". For example, "cat status" produces a nice summary of process behavior (Figure 21-5).

Figure 21-5. Status output

There are special programs that look for similar signs of malicious activity, such as chkrootkit for Linux/Unix, which looks for traces of well-known hidden hacker tools.

Overall, using /proc provides a nice alternative to using tools such as lsof and also shows more of the system internals (always handy to learn).

Depending on what we found by looking at our system, we take our next step. While backup of important data is best done periodically rather than when disaster strikes (When it's too late), now is a good time to make sure all the important data is saved elsewhere. In the case of a Windows virus attack, take extra steps to avoid backing up viruses with user files. Cases of virus reinfection from backup media are common. Writable CD-ROMs, CD-RWs, Zip disks, or even another hard drive (that is then taken out of the machine) can be used as backups. Networked backups are also useful (although probably better suited for the Unix world). Tools such as rsync can be used to securely replicate all the machine data over the network.

Now that you are sure your data is safely backed up, you can spend more time snooping around. If you have not found any apparent signs of malicious activity and your antivirus product is silent, there is not much that can be done on a typical Windows system. If you want to be sure that your system is safe, rebuild it from scratch: format the disks, install the operating system, and restore your files from backup media.

Install and update your antivirus scanner and personal firewall, and avoid using especially dangerous programs such as Outlook (or at the very least, configure them securely). For example, restrict various forms of active content in messages (JavaScript and especially ActiveX) and limit the network addresses that they can access. The bugs in such programs (they are legion) might still bite you. A third-party email client such as Netscape is safer, if you don't mind losing some of the bells and whistles of Outlook.

What if this incident proceeds along a more ominous path ? What if you discover your machine was erased completely or rendered unbootable with corrupted disks? Investigation is still possible, but reinstallation with recovery from backups will invariably be the last step.

If you are responsible for Windows machines in a home office or small office environment, consider reading Windows Internet Security: Protecting Your Critical Data by Seth Fogie and Cyrus Peikari (Prentice Hall, 2001). It shows security newcomers how to diagnose and treat hacker or virus attacks on Windows machines. On Unix, you can go much farther. We cover some of the available tools in the next sections.

Overall, the incident response process for a small network is aimed more at putting the system back as it was than at in-depth investigation and prosecution.