Blackened Network Monitorsby Kenneth R. van Wyk
Picture the following scenario: It is 3 a.m., and you are busy trying to track down an unauthorized user on your company's network. You've been preparing to track the miscreant for a few days now, after being alerted to some suspicious happenings by an alert and concerned employee. But the suspect is no ordinary intruder; she's one of the company's own systems administrators, and it is strongly believed that the suspect is doing things that she ought not to do.
For example, she is believed to be selling highly proprietary information to a competitor corporation where her fiancé works, as well as installing "back door" software in some of the company's most vital business information-processing computer systems. As a result, you've gotten the appropriate authorization to do whatever it takes to catch her in the act so that legal action can be taken.
Your game plan has been to set up a computer system to monitor the suspect's network activity, in effect a surveillance camera on the data network. To do this, you've purchased a state-of-the-art commercial software package for several thousand dollars as well as some removable hard disks that you plan to use to archive copies of any and all data collected. The computer system has been set up with a modem to automatically page you whenever the suspect logs in.
You've even gone to the extent of following all the procedures and regulations for treating the information that you log as though it may be used in a court of law at some later date. The entire operation has been handled within the company with the utmost of discretion in order to not alert the suspect that she is being monitored. Only the people who are directly involved in running the investigation know the sensitive information.
So here you sit at 3 a.m. after receiving a page from your monitoring computer alerting you to the fact that the suspect is on the network. Then it happens. She logs in to one of the computers that she is suspected of sabotaging and runs a "ping sweep" map of her network segment and she sees the IP address of the system that you are using to monitor. Being the administrator of that network, she knows that machine shouldn't be there, so she takes a closer look and finds that you are running a network monitor. The next day she calls her boss to resign--effective immediately--and she's never heard from again. And you're left with no hard evidence, no information on what back doors may or may not exist on the systems, and a very difficult story to tell your boss.
How could this situation have been avoided? The answer is to use a monitoring system that is not detectable, at least electronically, to the person being monitored. We refer to this process as "blackening" the monitoring system because it makes the system electronically undetectable. Unfortunately, most current network-monitoring software--commercial and freeware--is designed solely to monitor a network for intrusions, not to avoid detection. To use these tools for incident-response operations requires that some additional precautions be taken, such as ensuring that the target of any investigation cannot detect the monitoring activity.
In my incident-response experience, I've worked with various techniques for doing this. The techniques chosen for any given operation depend on several issues, including the type of physical network medium that needs to be monitored, the architecture of the network itself, the operating system of the machine doing the monitoring, and the time and tools available at the time of the operation.
For example, on some networks it is sufficient to disconnect the "transmit" wire so as to prevent the monitoring system from transmitting data, while on others, such as a coax (10-based 2) network, cutting a transmit wire is not physically an option. Additionally, a switched network requires special network-monitoring ports or configurations, so that the monitoring system can see all of the necessary network data. Most switched networks allow for a monitoring port, either physically or logically.
Regardless of the method used, there are several ground rules that must not ever be broken. The ground rules are as follows, in no particular order:
- The monitoring software must not be run on an existing computer on the target network. Even if monitoring software is currently installed on a computer on the target network, it must not be used for the incident-response operation at hand. The rationale for this is two-fold: first, it leaves absolutely no footprints that the monitoring is taking place on any existing systems and second, it helps to ensure that the system doing the monitoring has itself not been compromised by an intruder.
- No software or data on any computer on the target network should be altered or otherwise manipulated during the monitoring operation.
- No monitoring computer may, under any circumstances, transmit even a single packet or byte onto the target network.
Of course, these ground rules apply only to the monitoring activity itself. The actual incident-response operation is far more complex and has its own issues that need to be dealt with. For example, in our scenario above, I only discuss hiding the monitoring system electronically. Since the suspect is a system administrator, great care must also be taken to hide the system physically. Those issues are beyond the scope of this article, but will be covered in my upcoming O'Reilly book, Incident Response.
This article presents a broad overview of the techniques we have found work best when configuring a blackened, or undetectable, network monitor. These techniques include hardware methods such as cutting certain network cables to prevent data from being transmitted as well as software methods for use on various operating systems. The nature of incident response, however, is one of adapting to ever-changing and unexpected situations. As such, having an arsenal of every currently available blackened network monitor configuration is important. But rest assured, new requirements are just around the corner.
Kenneth R. van Wyk is an internationally known incident-response and antivirus expert, and he is an active member of the computer security community. He has worked on and managed numerous incident-response teams, including Carnegie Mellon University's famous CERT/CC, the U.S. Department of Defense's ASSIST incident-response team, and SAIC. He is cofounder and chief technology officer for Para-Protect, Inc., a company that specializes in incident response and other operational security services.