The open-source project Clawforge combines security events from multiple services and evaluates them based on its own rules.
Fail2ban and CrowdSec are security tools that administrators frequently use on Linux servers. For example, this is done to protect SSH, WordPress, Nginx, or Apache from attacks. However, they reach their limits under certain conditions. Clawforge provides a remedy.
What is Clawforge?
This is security software written in Rust. Here you can find the repository. It collects information about potential threats from various sources and analyzes network data. Based on this, it determines how risky or trustworthy an IP address or another connection is. The results can then be used by other security programs via an interface (API).
Fail2ban and CrowdSec are well-known tools for detecting suspicious access and responding accordingly. For many servers, this approach is sufficient, as known attack patterns can be detected using existing logs and predefined actions can then be triggered.
However, with my own setup, a different problem eventually arose. My own homelab has grown larger and larger over the past few years. What once started with a few Docker containers now consists of several production services that no longer run only locally. Some of these services sit behind my own VPS. Tailscale connects the systems to each other, while the VPS serves as the entry point for various applications.
However, as the infrastructure grew, the situation also changed. While the individual components provide a lot of information, each only looks at its own area. HAProxy sees incoming requests. Containers write their logs, applications report their own errors. What was missing was a place where this information comes together.
A failed login is not yet an attack. Neither is a request for a non-existent path. However, when the same address queries various scanner paths, repeatedly attempts logins, and stands out across multiple services, a different picture emerges.
Why existing solutions aren’t always enough
The question of why a dedicated project is being set up for this naturally comes to mind. After all, Fail2ban has been a proven tool for years. It analyzes logs, detects known patterns, and can react accordingly. For many individual servers, this is completely sufficient.
However, CrowdSec now goes significantly further, as it enables a comprehensive view of attack patterns. When it came to home infrastructure, however, another issue arose.
There is not just a single service with a single log file, but multiple production applications behind a shared entry point. The information came from different sources and was distributed. Fail2ban, on the other hand, looks at a single service. CrowdSec, by contrast, looks at events through its own architecture. What was missing was a layer in between.
What was needed was not another list of blocked IP addresses, but the ability to combine events from different sources and evaluate them based on custom rules. A failed login, scanner access via HAProxy, and a suspicious address from another source are each just individual clues on their own. Together, however, they can reveal a specific pattern that enables a better assessment of the threat situation.
OpenClaw Sentinel became Clawforge
Originally, this area was part of OpenClaw Sentinel. During development, however, it became clear that it made sense to offer the features related to event analysis, rules, and controlled responses independently. That is how Clawforge was created.
Events from the various sources converge, and the software evaluates them based on the rules individually set by the user.
Not every anomaly is an attack
A single anomaly usually reveals very little. Only multiple events combined form a complete picture. Clawforge stores this information, evaluates relationships, and can thus consider multiple indicators together. Over time, these stored events build a picture of your own infrastructure.
Past events provide additional information for subsequent evaluations. As a result, an analysis does not start from scratch every time.
The AI analyzes, but does not decide
At Clawforge, an AI model can explain events, create summaries, or assist with analysis. However, decisions regarding blocks or changes to the infrastructure still depend on self-defined rules.
Your data stays local with you
Features include a dedicated dashboard, API access, role management, and audit logs. This ensures full traceability of what happened and what response Clawforge triggered. Security data stays within your own environment.
A technical problem ultimately resulted in an open-source software project. Clawforge was born out of necessity to somehow effectively secure one’s own setup against attacks from the outside. Originally, it was never planned to develop a custom security solution.
The primary goal is to maintain an overview even with multiple production services and to no longer view events in isolation. Anyone who wants to get involved with the project is invited to further develop Clawforge. The software was released under the Apache License 2.0 .