A Review of Honeypots:Tracking Hackers by Lance Spitzner
The Bee in the Honeypot
I read recently Honeypots: Tracking Hackers
by Lance Spitzner because I wanted to learn more about the technology
behind these "hackable" computers. Very little technical information has
ever been written on the subject. In fact, Lance is the first to
complete an in-depth study of honeypots since Clifford Stoll's The Cuckoo's Egg
in 1990. Overall, I was impressed with the detail of the book. Lance
went to great lengths to make his readers aware of just what honeypots
are. But I simply do not agree with the implementation of honeypots
within a secured network.
The basic concept is simple. First, you
build a computer with the purpose of allowing an attacker to compromise
it. Then, you throw in a bunch of interesting files to lure him in.
Finally, connect it to the internet with the least amount of security
possible and wait. When an attacker connects to this computer, his
attempts to compromise it are logged. The information collected during
the session is then used to pinpoint the hacker's location and possibly
serve as evidence in a criminal trial against him.
From this perspective a honeypot would seem like a formidable weapon in the battle against the elusive Blackhat hacker. However, Lance suggests inserting these systems directly into your internal network; placing them right beside the computers that you work so hard to keep secured. This is supposed to the give an attacker a more suitable target to compromise. The assumption is that the attacker will aim for the unsecured honeypot instead of the other, more sensitive computers within your network. The way I see it, assumptions are dangerous and working to build a secure network that's full of holes just don't add up.
Lance devotes a considerable amount of time in the book toward the proper placement of these systems. Basically, he suggests placing one honeypot per every zone of your internal network. This is not a logical security implementation. Opening a security hole in every zone of your network raises a number of issues. The first of which involves the chances of an attacker even compromising the honeypot once he has entered a particular zone.
For example, let's say that the DMZ zone of my home network consists of a file server, a web server, and a honeypot. The chances that an attacker will try to compromise the honeypot once he enters that zone are three to one. Not bad odds. Until you consider the level of security on the other two computers within that zone. The file and web servers are going to have as much security placed on them as possible, while the honeypot is left wide open to whatever threat comes its way. This is bound to raise suspicion within the hackers mind. Hackers are commonly perceived to be naïve script kiddies. In reality, they are meticulous in their art and are all too aware of the latest security defenses. The odds that a skilled hacker will just fall into any trap that has been placed in his path are slim to none. So, what's he going to do when he notices that unsecured honeypot sitting beside two highly secured servers? He's going to skip right over it and head straight for the goods.
Of course the chances are still good that he will try to compromise the honeypot, even though he knows it's a trap. Why? Because he knows that if he gains the honeypot computer, the he can use it to reach every other computer within that zone, unrestricted. Think about it. For the honeypot to be active in a particular zone, it must be able to communicate with the other computers that reside within that zone. For example, computer B must be able to accept connection requests to and from computer A in order to provide computer C with a stable network connection. So, gaining access to computer C could serve as a bridge to computers B and A.
What I found to be the most discouraging about the study was Lance's process for choosing a honeypot solution. He covers four of the most popular applications, including Back Officer Friendly, Specter, Honeyd, and Man Trap. There are many more available, but what they all seem to have in common is an overall lack of potential as a security solution. In fact, most of them offer services that only mimic those of other popular security applications. For example, let's take look at Back Officer Friendly.
Back Officer Friendly is a light weight honeypot solution designed to run as a watcher application on the Windows operating system. Lance includes a copy of the software on the accompanying cd-rom for evaluation. Once installed, it can be set up to emulate a variety services on your computer, including telnet, http, or smtp. When an attacker tries to connect to one of these services, the honeypot recognizes the attempt and takes over instead. The attacker will be greeted with a fake reply appropriate to the particular service and begins to interact with the honeypot as if it were the real thing. The user is then notified of the attack. Back Officer Friendly logs the attacker's ip address, as well as any passwords he uses to try to log into the system.
The drawback to this software is that it will only monitor services on your computer that are not being monitored or used by any other program. This means two things: 1) If you're using one of these services for any other purpose (for example, http to run a web server), then Back Officer Friendly cannot be employed to help secure it. 2) If you're not using one of these services and wish to have Back Officer Friendly monitor it for malicious activity, then you have to allow that service complete access through your firewall!
I don't know about you, but I'm not comfortable allowing a service as dangerous as telnet through my firewall. Further more, the thought of granting access to any service that allows an attacker to interact with it sends a shiver up my spine. A more logical solution would be to allow the firewall itself to monitor these services. Most good firewalls offer the same logging abilities as Back Officer Friendly and will monitor the same services whether they are being used or not. Further more, most of the software mentioned in the book is extremely expensive and each one is designed to run either on or for a particular operating system. If you're running a tight network with multiple operating systems, then you're going to be spending a considerable amount of money just to invite hackers to come and play on it.
The broad range of honeypot classifications adds yet another level of confusion to the decision making process. Lance classifies honeypots according to two main classifications, then three functionality classifications, and finally, two levels of interaction classifications. Lance defines the two main classifications like this, "...production honeypots provide value by protecting a specific resource or organization, such as acting like a burglar alarm and detecting attacks. Research honeypots are different; they add value by gaining information on a threat, such as capturing an attacker's keystrokes" (278). Fair enough. Let's move on to the three functionality classifications. They are prevention, detection and response.
Prevention honeypots are designed to deter an attacker's attempts to compromise the system. For example, by flashing a warning banner at him to let him know that you are aware of his presence and are monitoring his actions on the network. Detection honeypots are designed to detect attacks that have penetrated your firewall and identify the attacker who is responsible. For example, by logging his ip addresses, keystrokes, and hop points. Response honeypots are designed to capture and reveal new techniques and exploits that are being used by the Blackhat community. This helps to increase the security community's incident response time by learning how hackers do what they do.
This is where the confusion sets in. If the main goal of a production honeypot is prevention and detection, then what is the main goal of a production response honeypot? On the other hand, what would be the main goal of a research honeypot with the prevention and detection functions built into it? These three classifications seem absolutely redundant. In fact, they only exist to describe functions that are already present in the first two classifications. Let's look to the last two classifications for clarification.
These have to do with the level of interaction that the attacker has with the honeypot itself. In a low level of interaction honeypot, the attacker will be shown a simple logon prompt or an http error page upon successfully connecting with a service. Neither will let him go any farther, and both log his attempts to do so. A high level of interaction honeypot will do the same with the exception of actually allowing the attacker to use the logon prompt. This will give him physical access to the system. Or if he connects through http, he will be presented with a real website designed just for him to vandalize. Again, these are functions that can be found in the first two classifications.
This leads me to believe that there are only two classifications to choose from, production and research. A production honeypot is geared toward detecting and preventing attackers by limiting their level of interaction with the honeypot. A research honeypot is geared more toward understanding how attackers compromise computer systems by increasing their level of interaction with the honeypot. The other five classifications are simply functionalities that are contained within these two classifications. They are not separate entities that can be mixed and matched.
In concluding, I found the book to be very educational. It is easy to read and offers a pleasant change from the jargon riddled prose found in most technical writing. Subjects such as networking fundamentals and hacking methods are all covered in detail using language that even the layman can understand. However, I simply do not agree with Lance's implementation and placement of these systems. The assertion that a honeypot can add an extra layer of security to complex network environments defies common security logic. In fact, they may actually hinder the ability of other security implementations and compromise the integrity of the entire network.
From this perspective a honeypot would seem like a formidable weapon in the battle against the elusive Blackhat hacker. However, Lance suggests inserting these systems directly into your internal network; placing them right beside the computers that you work so hard to keep secured. This is supposed to the give an attacker a more suitable target to compromise. The assumption is that the attacker will aim for the unsecured honeypot instead of the other, more sensitive computers within your network. The way I see it, assumptions are dangerous and working to build a secure network that's full of holes just don't add up.
Lance devotes a considerable amount of time in the book toward the proper placement of these systems. Basically, he suggests placing one honeypot per every zone of your internal network. This is not a logical security implementation. Opening a security hole in every zone of your network raises a number of issues. The first of which involves the chances of an attacker even compromising the honeypot once he has entered a particular zone.
For example, let's say that the DMZ zone of my home network consists of a file server, a web server, and a honeypot. The chances that an attacker will try to compromise the honeypot once he enters that zone are three to one. Not bad odds. Until you consider the level of security on the other two computers within that zone. The file and web servers are going to have as much security placed on them as possible, while the honeypot is left wide open to whatever threat comes its way. This is bound to raise suspicion within the hackers mind. Hackers are commonly perceived to be naïve script kiddies. In reality, they are meticulous in their art and are all too aware of the latest security defenses. The odds that a skilled hacker will just fall into any trap that has been placed in his path are slim to none. So, what's he going to do when he notices that unsecured honeypot sitting beside two highly secured servers? He's going to skip right over it and head straight for the goods.
Of course the chances are still good that he will try to compromise the honeypot, even though he knows it's a trap. Why? Because he knows that if he gains the honeypot computer, the he can use it to reach every other computer within that zone, unrestricted. Think about it. For the honeypot to be active in a particular zone, it must be able to communicate with the other computers that reside within that zone. For example, computer B must be able to accept connection requests to and from computer A in order to provide computer C with a stable network connection. So, gaining access to computer C could serve as a bridge to computers B and A.
What I found to be the most discouraging about the study was Lance's process for choosing a honeypot solution. He covers four of the most popular applications, including Back Officer Friendly, Specter, Honeyd, and Man Trap. There are many more available, but what they all seem to have in common is an overall lack of potential as a security solution. In fact, most of them offer services that only mimic those of other popular security applications. For example, let's take look at Back Officer Friendly.
Back Officer Friendly is a light weight honeypot solution designed to run as a watcher application on the Windows operating system. Lance includes a copy of the software on the accompanying cd-rom for evaluation. Once installed, it can be set up to emulate a variety services on your computer, including telnet, http, or smtp. When an attacker tries to connect to one of these services, the honeypot recognizes the attempt and takes over instead. The attacker will be greeted with a fake reply appropriate to the particular service and begins to interact with the honeypot as if it were the real thing. The user is then notified of the attack. Back Officer Friendly logs the attacker's ip address, as well as any passwords he uses to try to log into the system.
The drawback to this software is that it will only monitor services on your computer that are not being monitored or used by any other program. This means two things: 1) If you're using one of these services for any other purpose (for example, http to run a web server), then Back Officer Friendly cannot be employed to help secure it. 2) If you're not using one of these services and wish to have Back Officer Friendly monitor it for malicious activity, then you have to allow that service complete access through your firewall!
I don't know about you, but I'm not comfortable allowing a service as dangerous as telnet through my firewall. Further more, the thought of granting access to any service that allows an attacker to interact with it sends a shiver up my spine. A more logical solution would be to allow the firewall itself to monitor these services. Most good firewalls offer the same logging abilities as Back Officer Friendly and will monitor the same services whether they are being used or not. Further more, most of the software mentioned in the book is extremely expensive and each one is designed to run either on or for a particular operating system. If you're running a tight network with multiple operating systems, then you're going to be spending a considerable amount of money just to invite hackers to come and play on it.
The broad range of honeypot classifications adds yet another level of confusion to the decision making process. Lance classifies honeypots according to two main classifications, then three functionality classifications, and finally, two levels of interaction classifications. Lance defines the two main classifications like this, "...production honeypots provide value by protecting a specific resource or organization, such as acting like a burglar alarm and detecting attacks. Research honeypots are different; they add value by gaining information on a threat, such as capturing an attacker's keystrokes" (278). Fair enough. Let's move on to the three functionality classifications. They are prevention, detection and response.
Prevention honeypots are designed to deter an attacker's attempts to compromise the system. For example, by flashing a warning banner at him to let him know that you are aware of his presence and are monitoring his actions on the network. Detection honeypots are designed to detect attacks that have penetrated your firewall and identify the attacker who is responsible. For example, by logging his ip addresses, keystrokes, and hop points. Response honeypots are designed to capture and reveal new techniques and exploits that are being used by the Blackhat community. This helps to increase the security community's incident response time by learning how hackers do what they do.
This is where the confusion sets in. If the main goal of a production honeypot is prevention and detection, then what is the main goal of a production response honeypot? On the other hand, what would be the main goal of a research honeypot with the prevention and detection functions built into it? These three classifications seem absolutely redundant. In fact, they only exist to describe functions that are already present in the first two classifications. Let's look to the last two classifications for clarification.
These have to do with the level of interaction that the attacker has with the honeypot itself. In a low level of interaction honeypot, the attacker will be shown a simple logon prompt or an http error page upon successfully connecting with a service. Neither will let him go any farther, and both log his attempts to do so. A high level of interaction honeypot will do the same with the exception of actually allowing the attacker to use the logon prompt. This will give him physical access to the system. Or if he connects through http, he will be presented with a real website designed just for him to vandalize. Again, these are functions that can be found in the first two classifications.
This leads me to believe that there are only two classifications to choose from, production and research. A production honeypot is geared toward detecting and preventing attackers by limiting their level of interaction with the honeypot. A research honeypot is geared more toward understanding how attackers compromise computer systems by increasing their level of interaction with the honeypot. The other five classifications are simply functionalities that are contained within these two classifications. They are not separate entities that can be mixed and matched.
In concluding, I found the book to be very educational. It is easy to read and offers a pleasant change from the jargon riddled prose found in most technical writing. Subjects such as networking fundamentals and hacking methods are all covered in detail using language that even the layman can understand. However, I simply do not agree with Lance's implementation and placement of these systems. The assertion that a honeypot can add an extra layer of security to complex network environments defies common security logic. In fact, they may actually hinder the ability of other security implementations and compromise the integrity of the entire network.
Published by Matthew Austin
(read this article on the yahoo voices page, and thought it would be great sharing with our honorable readers in here.)
0 comments → A Review of Honeypots.
Post a Comment