DataSoft/Honeyd — Issue #9: Standardize honeyd script string architecture
Author: PherricOxide
Created: 2012-02-03 05:48:21+00:00
State: open
Labels: Component:Scripts, Type:Extension

Background
Before commit f8fd589be429fade918d9a76d0e229d6f2947d22, the scripts were duplicated multiple times with nothing changed but the version strings that the script reported itself as being. In an early attempt to remedy this problem and give the scripts more flexibility, I combined all of the Suse7 and Suse8 scripts by removing the string differences and placing them in "strings" files located in honeyd/scripts/strings.

The idea is that these strings files contain all of the recommended strings that can be chosen from in the format of a KEY followed by a space and the string. For example, in httpd.strings,

HTTPD_SERVER_VERSION Apache/1.3.23 (Unix) (SuSE/Linux) ...
HTTPD_SERVER_VERSION Apache/1.3.12 (Unix) (SuSE/Linux) ...
HTTPD_SERVER_VERSION Apache/2.2.20 (Ubuntu)
HTTPD_SERVER_VERSION SonicWALL
...

One entry for each KEY is chosen (manually right now) and placed into a configuration file for a script. See https://github.com/DataSoft/Honeyd/blob/master/honeyd/scripts/strings/example.conf. A user could also manually write desired strings into the config file. The strings files just provide an easy mechanism for an untrained user to pick realistic version (and other parameter strings).

Things that are worth looking into

1. First off, is merging strings text files into a single config file a good way to do this? Android uses a similar system where you don't generally hard code strings, but provide them via a strings resource XML file. We already have a scripts.xml file for NOVA, we should expand this to not only store the script paths but also all of the configuration options for each string instead of using the .strings files. I'm not sure about the exact schema yet, but we would want GLOBAL KEYs like a log folder location that all scripts can share as well as LOCAL KEYs that only one script uses, like a specific http response string. KEYs should also have a human readable description so a user doesn't have to dig through the script code to find what they're used for. One KEY should be marked with a DEFAULT tag we can use if the user doesn't specify a string or a randomize option.

2. Write a GUI for creating the configuration files. Right now generating a config file by manually choosing the strings is a rather tedious process. It would be better if we can run the GUI without NOVA, but I imagine some amount of integration with it will be a necessity. A user should be able to specify a Honeyd node with scripts running on certain ports. They should be able to further customize the script configuration file for each node if they desire to not use the defaults or a randomized string value. NOVA would then generate all of the configuration files and the Honeyd configuration file, which will specify different paths to the script configuration files.

3. Make a standard library the scripts can use to figure out their configuration parameters rather than having different people write different file parsing implementations needlessly. This would also be good if we change the file format. The scripts are written in different languages (perl, python, shell, tcl), but we could create an executable or script that they could all call with something like,

STRING = system(getScriptString FILE KEY)

With system being replaced with the language's external execution function of choice.