Bison/Flex parser

27 Jun 2009 Robin Berthier honeybrid-gsoc-parser

This week I completed an important step which is to integrate a parser in Honeybrid. There are now two new files in the source code:

  • rules.l which defines the different tokens to analyze,

  • rules.y which defines the configuration language and the different subroutines to call when a specific combination of tokens is detected.

Flex and Bison compile these two files and generate rules.c and rules.h which are then used by honeybrid to parse its configuration. The great advantages of having a parser are to have a flexible configuration file and to better handle configuration errors with a short volume of code.

The configuration of Honeybrid is now defined in a single file honeybrid.conf, which is divided in three sections:

  1. Configuration parameters: to define the general parameters of Honeybrid (logging level, log output files, network behavior, network timeouts…).

  2. Module definition: to define the parameters of each decision modules. Note that a module can be defined multiple times with different parameters. A unique name is assigned to each module definition.

  3. Target definition: to define the IP spaces covered by honeybrid and the behavior of honeybrid when receiving packets to these IP spaces.

The goal with the target section is to precisely control the behavior of the honeynet at each stage of an attack: during initialization (frontend), during the attack itself (backend), and after the attack, when the honeypot is compromised (outbound control). So the target section is made of four keywords:

  • filter: a pcap filter expression (similar to tcpdump filter syntax) to define the network traffic that this target should cover.

  • frontend: a honeypot IP address followed by a sequence of decision modules, to define which frontend honeypot should first answer to requests sent to this target, and which decision criteria to apply to accept request packets.

  • backend: a honeypot IP address followed by a sequence of decision modules, to define which backend honeypot should take over the network sessions initiated between attackers and the frontend, and which decision criteria to apply to start the redirection.

  • control: a sequence of decision modules, to define how to limit outgoing packets from network sessions initiated by honeypots.

An example of the final configuration file is attached to this blog post.