Evolution from Mataelang
RavenXcope is the rebranded successor to Mataelang, an open-source network intrusion detection platform. It keeps Mataelang's core idea — sensors on the wire feeding a central "Defense Center" for processing and visualization — but modernizes nearly every moving part. This page maps the heritage so readers familiar with Mataelang can orient quickly, and so the older terminology you may still find in code, topics, and indexes makes sense.
What stayed the same
- The shape of the system. Sensors detect on the network edge; a central Defense Center ingests, enriches, stores, and presents the alerts.
- A streaming pipeline. Detection events still flow through Kafka, get enriched in a stream processor, and land in OpenSearch for analytics.
- Some names on the wire. Several Kafka topics and OpenSearch index names retain the Mataelang lineage (e.g.
snort_alerts,mataelang-sensor-events-<tenant_id>). These are kept for compatibility; don't read them as "still using Snort."
What changed
| Concern | Mataelang | RavenXcope |
|---|---|---|
| Detection engine | Snort | Suricata (see Suricata Image) |
| Sensor software | Separate sensor-parser + sensor-api (agent + client) | Unified ravenxcope-sensor Go binary (see Sensor) |
| Sensor activation | Ansible playbooks orchestrated by an Ansible service | NATS commands over a JetStream work-queue (see NATS Provisioner) |
| Sensor trust | Install token / shared key | Claim code → CSR → mTLS client certificate (see Sensor → Enrollment & PKI) |
| Defense Center | "Defence Center" | "Defense Center" (defense_center-deployment compose stack — see Deployment) |
| Access model | Single-tenant | Multi-tenant org / role / permission model |
| Extras | — | Virtual sensor deployment, live threat map, AI-powered analytics chat |
Why it matters when reading these docs
Two transitions are still visible in the running system, and the docs call them out where relevant:
- Snort → Suricata naming. The aggregator still produces to a topic called
snort_alertsand Logstash indexes intomataelang-sensor-events-<tenant_id>. The data is Suricataeve.jsonoutput; only the names are inherited. - Ansible → NATS control. The backend no longer talks to an Ansible service; sensor activation/deactivation is published as NATS commands. Some legacy configuration keys (e.g. install-token settings) still coexist with the newer claim-code flow during the transition.
For the full picture of how trust and commands move versus how alerts move, read the Control Plane and Data Plane scenarios.