- 1 Overview
- 2 Ensure That the Software Used to Examine Systems Has Not Been Compromised
- 3 Monitor and Inspect Network Activities
- 4 Monitor and Inspect System Activities
- 5 Inspect Files and Directories for Unexpected Changes
- 6 Investigate Unauthorized Hardware Attached to the Network
- 7 Look for Signs of Unauthorized Access to Physical Resources
- 8 Review Reports of Suspicious System and Network Behavior and Events
- 9 Take Appropriate Actions
- Chapter 6 Checklist
This chapter is from the book
This chapter is from the book
This chapter is from the book
6.2 Ensure That the Software Used to Examine Systems Has Not Been Compromised
When you look for signs of intrusions on your systems, and when you examine your systems in general, you should use a verified, reference set of software—one that contains only trusted copies of software that have not been modified—and perform a clean boot (start the system from a known, virus-free image of the operating system). In addition to executable programs, the verified set of software must include all the operating system kernel, system libraries, configuration and data files, and system utilities on which the programs depend. You should avoid relying on software that resides on systems being examined (unless you can verify that the software and its supporting libraries, configuration files, and data files have not been modified).
Intrusion detection depends heavily on the reliability of the information you gather about the state and behavior of your systems. Therefore, it is essential that you use only software that you know to be reliable and accurate in its reporting of such information.
Intruders often replace software that would reveal their presence with substitutes that obscure or remove such information. Intruders are known to have replaced programs, libraries, and other utilities called by the programs. If a program used in detecting intrusions has been tampered with or replaced with a substitute, obviously you cannot rely on its output.
Ensuring that you are using only verified software may be very difficult. Intruders can make extremely devious system modifications that make things appear normal when in fact they are not. They can create, substitute, modify, and damage files on systems to which they have gained access. For example an intruder can use the rootkit tool set1 to replace the ps command on a UNIX system with one that does not display the intruder's process; similarly, an editor can be replaced with one that reads a file other than the one specified, which the intruder may have hidden and replaced with another version. Intruders modify system log files to remove traces of their activities and may modify software that is executed at system boot and shutdown, complicating your ability to take a system safely offline for more detailed analysis. Viruses often do this. By masking their presence on a compromised system, intruders prolong the time they have to use that system for their purposes. In several notable cases, the presence of intruders on compromised systems was not discovered until many months after the initial intrusion occurred.
The guiding principle for this practice is that you maintain a certain level of suspicion. Question everything you observe, and be able to answer these questions:
- What software is producing this output?
- What other software does it rely on?
- What software can I trust?
You can use five different approaches to achieve the goal of using a verified set of software. In all cases, the verified software should be located on physically write-protected media (e.g., CD-ROM or write-protected disk), so that it cannot be modified by a user or by software running on the system being examined. Each approach listed below has advantages and disadvantages, so you should choose a method appropriate to your current circumstances.
Move the disk from the system suspected of having been compromised to a write-protected, verified system, and examine the disk's contents using the software on the verified system.
The advantage of this method is that you do not need to rely on the integrity of any part of the operating system or the hardware on the suspect system. The method is effective and reasonable when you suspect that a particular system has been compromised and you want to analyze it. However, it may not be practical for automated procedures or for checking a large number of systems.
Be careful when shutting down the suspect system, since this act may in and of itself cause the evidence you are seeking to be hidden or lost. Before shutting down the suspect system, look at any programs that will run at shutdown for signs that they were modified (for example in some UNIX operating systems, the /etc/shutdown program should be examined). However, be aware that just looking at the file may be misleading, since you are relying on the suspect system's software. You may want to execute verified copies of shutdown programs and their data files (taking care to save the original files for later analysis). Other alternatives are to execute the shutdown from external media, force the system to halt immediately, or just pull the plug.
Attach to the suspect system a write-protected, verified system disk that contains the operating system and all necessary software, and then reboot the system using the verified operating system. This method has advantages and disadvantages similar to those of method 1 but relies on the trustworthiness of the suspect system's hardware.
Generate an image of the suspect system disk, mount it on a verified system, and examine it there. This method is acceptable if you have a verified system that you can use to examine the suspect system disk. This approach has the advantage of not affecting the operational environment of the suspect system (because what you're examining is an image of it on another system) and preserving the original evidence for subsequent legal proceedings.
Use external media containing a verified set of software to examine the suspect system.
To use this method, you need to use a CD-ROM or a write-protected disk containing verified software when examining the suspect system. A significant concern with this approach is that you will still be using the suspect system's operating system (e.g., the UNIX kernel), and it is highly unlikely that you have provided every needed operating system program, utility, and library on the CD-ROM or write-protected disk. As a result, the outcome of such analysis is suspect.
Verify the software on the suspect system first, then use the verified software to examine the suspect system.
This method requires you to compare the software on the suspect system with a reference copy (either complete files or cryptographic checksums as described in Section 5.3). However, take care to use a verified comparison program or cryptographic checksumming program. The program used to verify the software should be located on physically write-protected media. This approach has the same problem as that noted in method 4 with respect to using the suspect system's operating system.
6.2.1 Policy Considerations
Your organization's networked systems security policy should specify the level of verification that is required when examining each class of data and service provided by the organization's systems.
6.2.2 Additional Information
Some operating systems have the ability to make files immutable, that is, unchangeable by any process on the system, including system and administrative processes. All operating system files that don't need to be modified when a system is running should be made immutable wherever possible.
When you are examining your system through a remote access connection, make sure that you have established a secure channel to the system (as described in Section 2.13). Configure servers for secure remote administration and use of SSH (as described in Section A.3), so that only authorized personnel use the channel and nothing is changed or revealed in transit.