After over 10 years of active participation in the honeypot community, I was surprised not to have heard of MicroSolved's HoneyPoint Security Server before I started planning this roundup. HoneyPoint runs on Windows, Linux, and Mac OS X, and offers some useful features -- such as "defensive fuzzing" and the ability to track alert status -- that KFSensor and Honeyd don't. But HoneyPoint is neither as easy and complete as KFSensor, nor as flexible and scalable as Honeyd.
HoneyPoint's sensors, called HPoints, consist of HoneyPoints and HornetPoints. HoneyPoints are traditional honeypots with fake listening services and banners. HornetPoints are HoneyPoints that actively try to slow down malware and malicious hacking tools using defensive fuzzing, which is otherwise known as "tarpitting" in the computer security world. HoneyPoints and HornetPoints connect back to a centralized HoneyPoint Security Console; the data sent from the HPoints is encrypted to the console using 128-bit Blowfish.
Additionally, MicroSolved offers HoneyPoint Trojans and HoneyBees. HoneyPoint Trojans are red herring binary programs (custom created by MicroSolved when requested by the customer) that an attacker might be tricked into executing; the Trojan then connects back to the console, alerting the admin to the presence and location of the attacker. HoneyBees are programs that simulate unencrypted POP3 and HTTP connections, in order to create bogus authentication traffic that an attacker might sniff.
These are slightly interesting features, but they are useful only in certain scenarios: when the attacker has installed sniffers; when the sniffer is operating on the right network connections or the attacker has disabled the switched segments; or when the attacker is looking for POP3 or HTTP traffic. In short, they rely on a number of contingencies.
The TCP3lvl listener collects connection information and sends a banner, as well as a reply to what an attacker might type in response to the banner or header. Multiple connections from a single attacker, as determined by the connect count value, are collected into a single event for easier analysis. In the example below, an attacker connecting to port 23 will be sent a basic Cisco router banner. In addition, if the attacker responds with a username and password, he will be told that his password attempt was invalid.
The Web listener allows a basic Web page and HTTP options to be sent back in reply to a connection attempt. The default Web page displayed looks like a very basic payroll system logon page. It's not very sophisticated, but probably enough to lure prying eyes. I'd recommend mimicking one of your company's real Web pages, and the Web listener is simple enough to update.
HoneyPoint administration and alerts
Another drawback: It isn't possible to assign different banners and responses to different ports that are using the same type of sensor, unless you run additional agent binaries. You can specify multiple ports per HPoint sensor type, but the same banner or response will be sent each time regardless of the port. This makes it difficult to create legitimate-looking responses across a larger number of well-known ports once you have filled up all nine HPoint sensor types.
All new connections to listening sensors are sent to the console and appear in the Alerts tab with basic information displayed. All alerts can be reviewed, acknowledged, and assigned to specific users. External alerts can be sent via email, syslog, or Windows Event messages. For email alerts, HoneyPoint has a throttling feature that allows you to limit the flow.
If alerts are extremely long or the data field contains binary data, the console will not display the (potentially dangerous) data for safety reasons. Instead, the HoneyPoint console provides a link to an MD5-hashed, read-only file named AlertX.txt , which can then be used to open the file for analysis. HoneyPoint does not keep or display network packet detail, although a network sniffer could probably be easily incorporated on a sensor.
Acknowledged alerts get sent to the Open Issues tab. The console allows each event to be given a tracking status: New, Open, Under Investigation, Resolved Attack, Resolved False Positive, Closed, or Ignore. Tracking the status of each alert is unique among the products reviewed and a nice touch.
Administrators and users can be assigned in the console. Administrators have full control over the console, while users can only manage alerts assigned to them and generate reports. HoneyPoint is extensible through plug-ins, but the options are limited. MicroSolved cites Whois and Nmap as examples.
Most alert and configuration information is saved to a local, single-file database, although you have to remember to include any AlertX.txt files in your backups. Storing configuration information and alert data in the same database can present challenges if the administrator wants only to clear out the latter. MicroSolved suggests that administrators make a copy of the database immediately after configuration, before storing any alerts, so a configuration-only database can be restored in the future as a nearly blank template when old alerts are no longer needed.
HoneyPoint 3.00 comes with 10 built-in, HTML-formatted reports. These reports are very basic, and no other formats are available, but they're still better than most of the competition. Custom reporting can only be done using third-party SQL-based reporting tools.
HoneyPoint Security Server is an interesting product with some good features, but I don't see any scenarios in which I would choose it over KFSensor or free Honeyd. Unless the host absolutely must be Linux or Mac OS X, KFSensor is a better choice in any environment.