|
|
Honeydctl, which stands for Honeyd control, is the secret doorway into the inner workings of Honeyd. With it, you can change Honeyd's configuration while the system is running and use it to create dynamic honeypots that adapt to almost any situation. For example, you can add new honeypots, remove existing ones, or add new services to an IP address. It can also be used to retrieve status information on any of your honeypots or to inspect the currently loaded configuration.
When you start honeydctl, it will connect to the running instance of Honeyd and present you with a console that looks similar to the following output. After some initial information about the system, the user is presented with a prompt. The prompt includes two numbers that characterize the current activity of the honeypots: the number of active connections and the number of active processes. To update the statistics, just press return.
Honeyd 1.5 Management Console Copyright (c) 2005 Niels Provos. All rights reserved. See LICENSE for licensing information. Up for 320014 seconds. 101C 5P honeydctl> |
At the moment, honeydctl supports all commands used in the regular configuration file described in Section 4.5, plus a small number of additional commands. The additional commands are as follows:
list: The list command can be used to display the name of all currently configured templates and all bound IP addresses by appending the code word template. To select a smaller number of templates, it's possible to specify a pattern — for example, list template "10.1*" shows the name of all bound IP addresses that start with 10.1. When the full name of a template is specified, it's possible to see the full configuration of a virtual honeypot that includes the support services, the simulated operating system, and other network statistics:
43C 5P honeydctl> list template "10.1.0.5"
template 10.1.0.5:
personality: Linux 2.2.19 - 2.2.20
IP id: 25969
TCP seq: e461ac26
TCP drop: in: 0 syn: 0
refcnt: 4
ports:
tcp 25 reset
tcp 42 subsystem
./scripts/mwcollect.sh log.mwcollect.$date
tcp 80 open
scripts/webserver.py
tcp 81 reset
tcp 135 subsystem
./scripts/mwcollect.sh log.mwcollect.$date
tcp 445 subsystem
./scripts/mwcollect.sh log.mwcollect.$date
tcp 2745 subsystem
./scripts/mwcollect.sh log.mwcollect.$date
tcp 8080 reset
tcp 8866 subsystem
./scripts/mwcollect.sh log.mwcollect.$date
tcp 11117 subsystem
./scripts/mwcollect.sh log.mwcollect.$date
|
Information about subsystems can be inspected by appending the code word subsystem. The syntax is very similar to listing templates, and the output can be restricted again by specifying patterns that a subsystem name needs to match. When the full name of a subsytem is specified, honeydctl provides information about the PID of the subsystem and indicates how long it has been running.
delete: This command allows you to removed ports from templates or completely delete templates themselves. For example, you can use this feature to simulate hosts that get powered off or are completely removed from the network. Remember that it is also possible to use Dynamic Templates for similar purposes. Honeydctl is a low-level tool to change the configuration of Honeyd.
!: This is really a very advanced command and is cryptic for a reason. Using the bang, it is possible to send Python commands to Honeyd. For example, you can import the honeyd Python module and interact with Honeyd like an internal Python service would. The most straightforward example is to get a list of functions exported by the internal Python module:
0C 0P honeydctl> ! import honeyd 0C 0P honeydctl> ! print dir(honeyd) ['EVENT_OFF', 'EVENT_ON', '__doc__', '__name__', 'config', 'config_ips', 'delete_connection', 'delete_template', 'interfaces', 'log', 'raw_log', 'read_selector', 'security_info', 'stats_network', 'status_connections', 'uptime', 'version', 'write_selector'] |
We can see commands that can be used to retrieve various configuration information and even to delete currently existing connections and templates. To get a terse description for these functions, you can issue the following command: ! honeyd.help().
Access to the console is easily controlled by realizing that communication between Honeydctl and Honeyd happens via a name socket at /var/run/ honeyd.sock. Honeyd creates this file on startup. You can use regular Unix filesystem permission to control which individuals can connect to it. By default, only root is allowed access to the console. Instead of interactively interacting with Honeydctl, it's also possible to script it and configure Honeyd completely dynamically without using a configuration file.
|
|