Documentation

CROWSI consists of the CROWSI platform and CROWSI decoys. The CROWSI platform is a Kubernetes based orchastrator of honeypot decoys, purpose built to protect and surveil edge devices. As default it comes with the CROWSI httpCatcherDecoy docker image deployed, which is a low-interaction HTTP API decoy. The below image shows an architectural diagram of CROWSI in its current released version. In this documentation we will try to describe the main building blocks.

Remark on Open-Source

As we believe in the power of open-source, the CROWSI orchestrator platform as well as the httpCatcherDecoy is available as open-source projects on GitHub. The code is licensed under the MPL-2.0 license. We welcome and appreciate anybody using CROWSI to protect his eco-system and even more any contributor. Also a deployment guide for the CROWSI platform is available at GitHub, in case you want to jump over the documentation.

However, please be aware that our planned managed service offering comes with additional features like high-interaction decoys, log processing, dashboarding and alerting, which are closed-source.

Of course, you can add your own containerized decoys to the CROWSI platform simply and also request to release decoys built by you under the CROWSI open-source organization.

Traefik Proxy

CROWSI exposes honeypot decoys via a reverse proxy. For this, the well known open-source proxy Traefik was chosen.

Traefik serves as a reverse proxy to distribute incoming requests to the underlying conatainer based honeypot web server decoys while enforcing specific security measures and logging requirements.

Secure Connection and Access Control

Traefik is configured to only accept HTTPS connections, ensuring all communication is encrypted.

The needed web server TLS certificates are retrieved by integrating the open-source project Cert-Manager.

Cert-Manager automates the management of TLS certificates using Let’s Encrypt.

It automatically obtains and renews SSL/TLS certificates for the specified domains, ensuring secure connections between clients and services.

In addition to this, Traefik is configured to authenticate clients using client certificates.

Therefore, the certificate of the CA used to sign the edge device certificates needs to be provisioned to Traefik as a Kubernetes secret. This serves as the trusted authority for the client certificate validation.

Only clients presenting a valid certificate, signed by the CA are allowed to access the services routed through Traefik.

Additionally, Traefik is configured to add relevant client certificate data as a header to the requests forwarded to the decoys to allow them to include this relevant data in the logs.

Access Logging:

But not only the decoys produce relevant logs, also Traefik is configured to generate access logs for all incoming requests. These are particularly relevant when securely operating CROWSI by your own.

Access logs capture detailed information about each request, including client IP addresses, requested URLs, response status codes and more.

Traefik is configured to write logs to stdout.

In summary, CROWSI leverages Traefik’s capabilities as a reverse proxy to enforce TLS encryption, client certificate authentication and access logging.

httpCatcherDecoy

The httpCatcherDecoy is the default HTTP API that is exposes by CROWSI and therefore the current heart of the CROWSI open-source framework. Whenever a client requests a path that doesn’t match with any other deployed honeypot decoy, CROWSI routes the request to the httpCatcherDecoy.

This container is a Python based Gunicorn web server that logs details like the request method, the request path, the certificate serial number of the connecting edge device and many more to stdout.

The attacker is then provided with just an empty response. As this typically doesn’t keep attackers involved for a longer time, httpCatcherDecoy is a typical low-interaction honeypot. Yet still, it allows us to attract attackers and get an early notification about their presence.

You can add whatever decoy you want within CROWSI by just following the example of the httpCatcherDecoy deployment.

Edge Device Configuration

Obviously CROWSI can only fulfill its purpose if there is an edge device asset that implements another reverse proxy and therefore exposes a port and forwards incoming attacker traffic to CROWSI. For an attacker this looks for example like an edge device that makes backend services available to other (not-connected) systems in your eco-system or like an exposed application on the edge device itself.

The actual needed edge device software is, as of now, not part of the CROWSI stack as the perfect implementation for this is very much device specific. However on GitHub we provide an example implementation using NGINX.

It exposes a TCP connection on port 80 and forwards all incoming request to CROWSI using a secure mTLS connection established with a client certificate stored on the device.

Logs

All application logs created by CROWSI are pushed to the Kubernetes default container log space. By integrating the Kubernetes cluster into your existing cyber security monitoring solution and shipping these logs to it, you can leverage the gained data to get early notifications and create threat landscape insights for your security team, while luring attackers away from your assets.