|
|
A low-interaction honeypot like Honeyd does not simulate enough detail to allow an adversary to compromise a virtual honeypot, so you might wonder about the benefits provided by these honeypots. As mentioned earlier, Honeyd is a good tool to get a more detailed overview of network activity. Each virtual honeypot gives a little more insight into what is happening in your network. With a little bit of extra instrumentation for services, it is even possible to analyze what kind of attacks are being carried out. Clearly, our analysis capabilities become more powerful with more honeypots. So why stop at instrumenting a single network? Instead, we might want to instrument several C-class networks all over the Internet. Managing the different packet logs can be cumbersome. For each Honeyd installation, we would have to copy new logs to a central machine, collate them, and then run analysis algorithms over the aggregated logs. To faciliate this task, Honeyd supports a protocol for sending interesting statistics to a remote analysis station. The analysis software is called Honeydstats and it receives packet level logs quite similar to the logs described in Section 4.8.1 and continously analyzes their contents. It computes the following four tables:
OS Versions: Using passive fingerprinting, Honeydstats computes the distribution of operating systems that have talked to the connected Honeyd machines in the last minute, hour, and day.
Destination Ports: Computes a table of the most active destination ports. The destination ports are often a good indiciation of the kind of attacks that are being carried out against a honeypot. We can clearly differentiate, for example, between Windows and Unix services that are being attacked. The table shows the most active ports for the last minute, hour, and day.
Country Report: Uses reverse DNS to determine the top-level domain of each IP address that contacted a honeypot. Although DNS is not very accurate, this table gives us some idea where the network activity originated.
Spammer Report: Analyzes the data traffic on port 25, is used for SMTP traffic. It lists the most active IP addresses. Because the honeypots are unlikely to transport any real mail traffic, these IP addresses are likely to be sending spam. For this report to work correctly, your honeypots should be instrumented with a fake mail relay.
Figure 5.9 shows the flags it supports, which we discuss following. The most important parameters are the port number and the name of the configuration file.
-p port: Which UDP port the analyzer should listen on to receive reports from Honeyd machines. This port needs to correspond with the information provided when you start up your Honeyd daemons; see following for more information.
-f configfile: The name of the configuration file. It contains a list of username and password pairs. The username and password are separated by a colon — for example, niels:supersecret. Without this information, Honeydstats cannot authenticate incoming reports and is just going to ignore them.
-c checkpoint: The name of the checkpointing file. Honeydstats saves all incoming information so it can be postprocessed later but also so Honeydstats can recreate its internal information if should be killed or if the machine crashes.
–os-report filename: The filename to which Honeydstats should save its report data for the operating system distribution. Honeydstats updates this file once a minute. It can be used by a web server to update live statistics as, for example, at http://www.honeyd.org/live.php.
--os_report <filename> Report os versions to this file. --port_report <filename> Report port distribution to file. --country_report <filename> Report country codes to this file. --spammer_report <filename> Report spammer IPs to this file. -V, --version Print program version and exit. -h, --help Print this message and exit. -l <address> Address to bind listen socket to. -p <port> Port number to bind to. -f <config> Name of configuration file. -c <checkpoint> Name of checkpointing file. |
The parameters for the other reports have the same syntax as the os-report flag just explained. They are also updated once a minute. Figure 5.10 shows an output sample from the operating system table. In this particular case, the Honeyd was unable to determine the operating system for the majority of network activity. This might be because most of the traffic comes from specifically crafted attack tools that circumvent the operating system TCP/IP stack, but it could also indicate that the passive fingerprinting tables are out of date.
The output from Honeydstats becomes more powerful the more Honeyd machines report to it. To instruct Honeyd to report its statistics to a remote Honeydstats collector, you need to use the following command line flag:
honeyd -c host:port:username:password
The host corresponds to the IP address that Honeydstats runs on. The port number needs to be the same as specified by the -p flag mentioned previously. The username and password need to match the information in Honeydstat's configuration file. Honeyd uses the HMAC-SHA1 message authentication code to make sure that nobody can tamper with the transmitted information and only authorized users can contribute their information. If a password is compromised, it is easy to remove the username from the configuration file and rerun Honeydstats on the checkpoint data. Honeydstats is just going to ignore all information from the compromised account.
|
|