The following work was done as a part of the Google Summer of Code(GSoC) 2021 Honeynet Project. The coding period started in the beginning of June 2021 and lasted for around next 10 weeks in total. During this time, I worked on the RIoTPot which is a honeypot used for IoT/OT protocols. I started working on the Riotpot by extending features of an exsiting project that supported local protocol plugins only and helped develop it into a fully functional high interaction honeypot with a new user interaction interface.
Let's get started with a general project introduction followed by insights into the RIoTPot Honeypot Goals and Challenges accomplished during the GSoC 2021 period.
Honeypots are modern-day cyber traps to defend against cyberattacks on devices/services communicating over the internet. They lead the attackers into believing that they are attacking the real target devices/services over the internet but instead they are interacting with a system designed to mimic a particular device/service behavior. The devices/services behavior is generally depicted by the communication protocol they use. For e.g. an industrial IoT device might be using Modbus protocol and attackers can search for this protocol through various means and launch an attack.
RIoTPot project is the extension of existing work for IoT/OT honeypot which can also be extended for other protocols. The project supported low interaction i.e. locally build plugins or binaries of IoT/OT and other protocols where attacker interacts with the locally run plugin believing that they are real devices. The protocol plugins work inside the RIoTPot core and listen to their specified ports. The RIoTPot core can also be deployed inside a container as well.
As depicted above, there are a few components such as a riotpot core, different running modes, different interactions it supports, etc. Let us discuss them in a little detail.
Riotpot core is the brain behind the honeypot operation. Managing the plugins and service containers for them to be able to run as a single point to entry and forwarding traffic to the respective target plugin or service container. One of the core functionalities is to either take user input or read the configuration file directly and validating if everything is correct for a successful run. Depending upon the running mode(Local build mode and containerized mode) riotpot core adapts and provides the functionality to support the intended run. There are three types of interaction Riotpot currently supports:
-
Low Interaction: Plugins run locally inside the RiotPot core and listen to the traffic from the Riotpot core hosting platform.
-
High Interaction: Services are run inside their respective container and not in riotpot core. Traffic is forwarded to them either via port attachment using docker(in Local build mode) or using glider to forward traffic(in Containerized build mode).
-
Hybrid Interaction: It is the mix of low and hybrid interaction mode, meaning, some protocols will run as plugins and some inside their respective containers. Traffic forwarding remains the same as for individual interactions mentioned above.
The above-mentioned interactions work under in two different running modes:
-
Local build mode: In this mode, the riotpot core is built locally on the host machine. If the user runs riotpot in low interaction then the plugins are generated and stored locally inside the host Linux machine and in high interaction, the services are deployed as containers with traffic forwarded using the docker port attachment feature.
-
Containerized build mode: In this mode, the riotpot core is built inside its own container. If the user runs riotpot in low interaction then the plugins are generated and stored locally inside the container and in high interaction, the services are deployed as containers in parallel to the Riotpot core container with traffic forwarded using glider tool which runs inside riotpot core.
There are supplementary components such as NoSQL MongoDB and tcpdump which run inside their respective containers capturing valuable details for analysis of what is going on traffic and packet-level in Riotpot run.
To build a fully functional high interaction honeypot from existing Riotpot code, we set attainable goals and met challenges on the way:
-
Mongodb integration: Integrating Riotpot with mongodb for traffic data collection instead of existing Postgresql. The reason could be the flexibility with storage structure and less management.
-
Supporting containerized services: To let plugins present inside the Riotpot core be deployed separately in a container i.e. sandboxed from the core and all the traffic meant for the specific protocol is now forwarded either through Riotpot core service glider or port attachment using docker.
-
Different interaction levels: To let Riotpot run in low, high and hybrid interaction levels in both local running mode as well as containerized running mode. This provides additional security and the ability to add advanced features if the need arises.
-
Interactive module for Riotpot run: To let riotpot run easier using the interaction-based system where a user no longer needs to manually change the configuration files to run Riotpot. New interactive interface to work on higher-level user input for running riotpot in any running mode and interaction level.
-
Improved code documentation: To make project code is more informed and well documented on function level to let guide future developers maintain and update the honeypot with ease.
Overall the process was both challenging and fun, the existing code made things easier somewhere but also made some tasks daunting. Especially when it came to supporting running mode where a new interface from scratch was required making sure that the functionality of other running modes remains intact. Sometimes more structured approach was required e.g. in database integration and a more trial and error approach was required in supporting containerized build running mode.
The coding phase was rolled out using github projects feature where issues and bugs were created and tracked to fulfill the project requirements. Following are the list of issues and bugs that were addressed in the coding phase:
- aau-network-security/riotpot#23
- aau-network-security/riotpot#26
- aau-network-security/riotpot#31
- aau-network-security/riotpot#33
- aau-network-security/riotpot#34
- aau-network-security/riotpot#39
- aau-network-security/riotpot#40
- aau-network-security/riotpot#41
To address issues as per the required features different branches were used to develop and test code. The following branch merge request helped into a smoother tracking of features:
In the current state of submission for GSoC 2021 is found in the branch gsoc_dev and mongo_integration Both the branches are tested, fully functional and feature complete.
To build Riotpot locally, follow the steps in gsoc_dev branch:
# Running the following command from riotpot directory will compile the necessary plugins and binaries
# and put it in the standard go path as well as in current directory.
$ make riotpot-build-local
# Command will run the Riotpot locally
$ ./riotpot
Upon running, the user needs to select the mode of interaction, in Low mode, all plugins run locally as binaries, in High mode, the selected services run in separate containers, and, in Hybrid mode, a mix of Low and High i.e. some services locally and some inside containers.
In every mode, there is an option to run the services directly from reading the configuration file located at config/samples/configuration.yml
By editing the boot_plugins tag, services to run as binaries inside can be provided, see emulators tag in the same configuration file to input allowed service plugins only
By editing the start_images tag, services to run inside a container can be provided, see images tag in the same configuration file to input allowed container images only
Not for Local build, by editing
modetag, the riotpot running mode can be provided
To exit the Riotpot in its running state at any time press Ctrl + C
In containerized build, Riotpot core is also deployed inside a container and forwards traffic to the other services.
To build inside containers, follow the steps:
# Assuming the user is at the root directory of the Riotpot GitHub repository
$ cd riotpot/deployments
# Run the command to enter the interactive mode to choose services to run
$ go run interactive_deployer.go
Upon choosing modes and services correctly, the following message will be displayed:
Perfect!, now run the command
docker-compose -f docker-compose.yml up -d --build
# This will setup the container environment and run the services along
# with database and other useful containers
$ docker-compose -f docker-compose.yml up -d --buildTo check if the containers are correctly setup, check with the following command and see,
if riotpot:development and other selected services containers are up and running.
One can also set up the Containerized Riotpot through the config file located at, config/samples/configuration.yml
By editing the boot_plugins tag, services to run as binaries inside can be provided, see emulators tag in the same configuration file to input allowed service plugins only
By editing the start_images tag, services to run inside a container can be provided, see images tag in the same configuration file to input allowed container images only
By editing mode tag, the riotpot running mode can be provided, see allowed_modes tag in the same configuration file to input allowed modes only
To stop the Riotpot in Containerized mode use the following command:
$ docker-compose down -vNOTE: Using the -v tag will remove all the mounted volumes, i.e. the database used by riotpot to store information and the volumes mounted to store logs and binaries collected by the honeypot. Remember to make copies before using the -v tag, or skip it altogether.
- Integrate an automated testing framework.
- Publish network forwarding logs in a structured way.
- Support UI Server-based runs.
- Also, a few TODOs in the codebase will help to enhance function level capabilities
It was a highly engaging and exciting project. My learning curve went up the roof and got a lot of valuable research advice from my mentors. I truly appreciate and am thankful to both of my mentors Emmanouil and Shreyas for guiding me through the project and answering/helping me with any issue I encountered during the course. I am definitely finishing my project with more zeal towards the project than with what I started and continue to actively contribute to further development.
I wish to apply for more GSoC events in the future. Thanks to the Honeynet Project and Google for providing such an amazing opportunity.