HoneyPoint Security Server
Saturday, September 23. 2006
There is a new commercial honeypot solution available: HoneyPoint Security Server. The description sounds like it is some kind of "honeyd on steroids" with nice alerting mechanisms: it creates virtual hosts on the network and these hosts serve as sensors for a burglar alarm. Once a sensor is hit (e.g., during the reconnaissance phase prior to the attack), simply an alarm is generated since nobody should access the sensors (basic principle of honeypots). I'm looking forward to get a trial version and blog more about it later on. Because currently it seems like everyone can build something like that with some more honeyd scripting...
Excerpt from the description:
[...] The idea is an old one. The implementation is new. The idea of honeypots goes back a long way. They are essentially based upon the idea that if you create artifical systems or services on your network, an attacker will not know if what they see is real. The idea is that in order to determine what is real, they will have to probe and attack all of the visible targets. In doing so, they will, in more cases than not, probe a honeypot - thus alerting security folks to their presence. Obviously, the more honeypots, the higher the likelihood of their being probed instead of a real system.
This is the basis for HoneyPoint. We use it to make our systems offer services across the network that appear to be vanilla and homogenous. Imagine a big 10×10 grid of light sockets. If you had a light bulb and were asked to screw it into some of the sockets in the board, but some of the sockets were real and would light the bulb, while others would set off an alarm - how would you go about identifying which ones were real and which were alarms? You might carefully examine them, but if they all look similiar, the only way to know would be to try them.
That is exactly what we do with HoneyPoint. We dialate ports across our systems with similiar appearing services, and then wait for attackers to try and figure out which ones are real and which ones are HoneyPoints. Just by doing what attackers do - that is, probing the network and services they find - they fall into our trap and alert us to their presence. Once identified, they can be quickly isolated and shut down by network security staff.
[...]
Excerpt from the description:
[...] The idea is an old one. The implementation is new. The idea of honeypots goes back a long way. They are essentially based upon the idea that if you create artifical systems or services on your network, an attacker will not know if what they see is real. The idea is that in order to determine what is real, they will have to probe and attack all of the visible targets. In doing so, they will, in more cases than not, probe a honeypot - thus alerting security folks to their presence. Obviously, the more honeypots, the higher the likelihood of their being probed instead of a real system.
This is the basis for HoneyPoint. We use it to make our systems offer services across the network that appear to be vanilla and homogenous. Imagine a big 10×10 grid of light sockets. If you had a light bulb and were asked to screw it into some of the sockets in the board, but some of the sockets were real and would light the bulb, while others would set off an alarm - how would you go about identifying which ones were real and which were alarms? You might carefully examine them, but if they all look similiar, the only way to know would be to try them.
That is exactly what we do with HoneyPoint. We dialate ports across our systems with similiar appearing services, and then wait for attackers to try and figure out which ones are real and which ones are HoneyPoints. Just by doing what attackers do - that is, probing the network and services they find - they fall into our trap and alert us to their presence. Once identified, they can be quickly isolated and shut down by network security staff.
[...]
".
