aau-network-security/riotpotIoT and Operational Technology Honeypot
| 📢 ATTENTION!!! |
|---|
| This repository has been moved to the Honeynet Project :) |
RIoTPot is a hybrid interaction honeypot, primarily focused on the emulation IoT and OT protocols, although, it is also capable of emulating other services. In essence, RIoTPot acts as a proxy service for other honeypots included in the system. Therefore, you can run any honeypot and other services alongside RIoTPot. In addition, there is an UI web-application that you can use to manage your routing.
The honeypot comes with multiple low-interaction services ready to use. Since these services are written as plugins, they are only supported on Linux; however, you can start RIoTPot without them. The following table contains the list of services included in RIoTPot by defaul, their internal port, and proxy port.
| Service | Internal Port | Proxy Port |
|---|---|---|
| Echo | 20007 | 7 |
| SSH | 20022 | 22 |
| Telnet | 20023 | 23 |
| HTTP | 28080 | 80 |
| Modbus | 20502 | 502 |
| MQTT | 21883 | 1883 |
| CoAP | 25683 | 5683 |
Table of Contents
The RIoTPot architecture is based on proxy connections to internal and surrounding (or external) services (e.g., honeypots, full-services, containers, remote hosts, etc.).
For this, the honeypot manages a number of user-defined proxies that relays connections between services and RIoTPot 1.
This way, RIoTPot can decide how and where to route incomming attacks.
The logic used to determine how to handle the incomming attack is implemented in the form of middlewares 2.
To manage services, middlewares and proxies, RIoTPot ships with a REST API 3 and a webapp UI 4 out-of-the-box.
The UI can be accessed through your browser at localhost:2022 and you can fiddle with API endpoints at localhost:2022/api/swagger showing a Swagger interface.
Figure 1 shows the RIoTPot architecture, including the two main applications that constitute RIoTPot (RIoTPot itself, and RIoTPot UI) and their components, and a section to enclose external (or adjacent) services.
RIoTPot is written in Golang5. Each RIoTPot instance exposes registered proxies (based on their port) on demand. To serve a proxy, it must have a binded service and the proxy port must be available (currently, RIoTPot does not accept multiple services running in the same port). When a proxy has been binded and served, attackers will be able to send messages to RIoTPot on that port, relying the messages to the binded service and back to the attacker6.
For ease of access, multiple instances of RIoTPot can be managed from the RIoTPot UI webapp.
In addition to managing the proxies registered in each instance, the UI allows you to create, use and edit profiles.
Each profile contains a number of proxies named after protocols or other services making a RIoTPot instance resemble a real-life devices (e.g. a home assistant).
In few words, profiles speed up the process of setting up and provision a RIoTPot instance with specific configurations.
The UI is written using the React fonrt-end JavaScript library (we use Typescript for this project) and Recoil state management library.
Since RIoTPot is rather small, for the moment, it does not use a database.
Running RIoTPot is relatively simple. Overall, you have three options. The first is to download a RIoTPot release; you can either choose to download the latest release, or previous one. The second option is to build the project yourself. The last option is to use the source code to create a Docker container with RIoTPot and some additional applications to enhance the honeypot.
Info: This guide is meant for users with no special needs, who want a simple out-of-the-box experience.
Each release comes in a folder named riotpot with an executable binary (also) named riotpot and a plugins folder filled with multiple services (or low-interaction honeypots).
It is important to keep the internal folder structure for RIoTPot to work as intended.
📁 riotpot
┕ riotpot
┕ 📁 plugins
riotpot folder.riotpot binary. This will start RIoTPot with the API enabled, all the plugins ready to use, and the UI server.
localhost:2022Internal and surrounding services are not accessible through the Internet. Internal services are integrated and only accessible to RIoTPot. These services are loaded on-start and can not be deleted, but they can be stopped. Surrounding services must be in the same network as RIoTPot. External services must whitelist RIoTPot only. ↩
Middlewares are currently under development. ↩
The RIoTPot API must not be exposed to the Internet. Regardless, the API currently only accepts connections from the localhost. This may be changed in the future, providing a whitelist of hosts and standard authentication. ↩
Although the Web interface can be used as a separate component, it is embeded with the RIoTPot binary. ↩
While the base application is interoperable, internal services (plugins) can only be used in Linux, FreeBSD and macOS environments. We plan to overcome this limitation by replacing plugins with micro-services communicating through gRPC. ↩
For ethical and security reasons, RIoTPot does not allow unsolicited requests to the outside, i.e., reversed shells and the like are not allowed. ↩