Was es tatsächlich tut

• Sammelt Telemetrie von Windows- und Linux-Agenten über einen einzigen TCP- Kanal. SIEM-Events, Alerts, FIM, Pakete, Netzwerkverbindungen, offene Ports, Docker-Aktivität, Bildschirm-Frames.

• Erkennt mit Sigma-Regeln, auf dem Endpunkt. 23 Regeln, die 23 MITRE- ATT&CK-Techniken abdecken, sind in conf/sigma/builtin/ enthalten; lege Community-Regelsets daneben ab. Sigma gleicht benannte Felder statt Text ab, sodass Image|endswith: '\vssadmin.exe' nicht durch das Wort „vssadmin“ in einer unzusammenhängenden Nachricht umgangen werden kann – und CommandLine|utf16le|base64offset|contains liest in ein base64- -EncodedCommand-Payload hinein, wo die Klartext-Befehlszeile nur den Wrapper zeigt. Gemessen am Evaluationskorpus: 9 von 10 Angriffen werden allein von Sigma erkannt, 0 von 9 harten Negativfällen falsch positiv gemeldet. Diese Schicht ist deterministisch und funktioniert weiter, wenn das Modell nicht verfügbar ist.

• Korreliert über Events hinweg, was keine Pro-Event-Regel kann. Ein einzelner fehlgeschlagener Logon ist Routine; fünf Konten, die in vierzig Sekunden von einer Quelle fehlschlagen, sind ein Password-Spray, und wenn du dir eines dieser fünf Events ansiehst, wirst du das nie erfahren. Abgedeckt sind Spray, Brute Force, ein Erfolg nach wiederholten Fehlschlägen sowie Ausbrüche von Kontenerstellung oder Dienstinstallationen – auf beiden Plattformen, über Windows-Event-IDs oder geparste auth.log-Zeilen.

  Läuft an zwei Beobachtungspunkten, weil sie unterschiedliche Angriffe sehen. Pro Host auf dem Agenten, wo ein Angriff gegen eine Maschine vollständig sichtbar ist. Und hostübergreifend im Ingest-Pfad, wo ein Spray, das einen Fehlschlag nach dem anderen über fünfzig Maschinen verteilt hat, sichtbar wird – kein einzelner Agent sieht mehr als ein Event, und das ist der kompetentere Angriff, da ein breites und flaches Spray sowohl unter den Pro-Konto-Sperren als auch unter den Pro-Host-Schwellen bleibt.

  Gesamtabdeckung mit Sigma: 27 Techniken. Jedes Fenster feuert einmal statt einmal pro Event, und jeder Zähler ist begrenzt – ein Zähler, der auf einen angreifer-gelieferten Benutzernamen schlüsselt, ist eine Speichererschöpfungs-Primitive, keine Erkennung.

• Ordnet Erkennungen MITRE ATT&CK zu, aus den Regeln selbst. Regeln tragen tags: attack.t1490, sodass es keine manuell gepflegte Mapping-Tabelle gibt, die veralten kann. Die Abdeckungsseite trennt drei Zustände, die eine einzelne „Abdeckungs-%“ verbergen würde: abgedeckt und gesehen, abgedeckt und ruhig, und überhaupt nicht abgedeckt – der letzte ist der einzige, bei dem das Schweigen der Konsole nichts bedeutet.

• Triagiert jedes Event mit einem lokalen LLM. Drei Worker laufen parallel: einer beobachtet jedes eingehende Event in Echtzeit, einer führt operatorgesteuerte Tiefenscans durch, und einer entscheidet, ob eine defensive Aktion ergriffen werden soll (BLOCK_IP, ISOLATE_HOST, KILL_PROCESS usw.).

• Schattenmodus für den defensiven Worker. Setze AI_SHADOW_MODE=1 und jedes autonome Urteil wird im SOAR-Hub zur menschlichen Genehmigung vorgemerkt statt ausgeführt. Nützlich, um das Modell an echtem Datenverkehr zu tunen, bevor man es eigenständig handeln lässt.

• Indexiert alles in OpenSearch, sodass du deine Flotte mit Fuzzy-/Exakt-/Beginnt-mit-Abfragen von einer Stelle aus durchsuchen kannst.

• Führt SOAR-Playbooks aus, die in einem kleinen visuellen Editor mit mehrstufiger, Pro-Knoten-Ergebnisverfolgung erstellt werden und manuell oder per KI-Urteil ausgelöst werden können.

• Schwachstellenscans aller installierten Pakete jedes Agenten gegen OSV (online oder über einen internen Mirror).

• Zieht Threat-Intel-Feeds von abuse.ch (Feodo, ThreatFox, URLhaus) in eine lokale Indikatortabelle, mit Staleness-Bereinigung und einem Air-Gap- Schalter.

• Validiert Agentenkonfigurationen, bevor sie gepusht werden. YAML-Parse, strukturelle Form und Regex-Kompilierung – ein ungültiger Regex ist gültiges YAML und deaktiviert stillschweigend die Regel, die ihn enthält.

• Integrierter Remote-Desktop über WebSocket-JPEG-Streaming, keine separate VNC-Installation auf dem Endpunkt nötig.

So sieht es aus

Die Seitenleiste gruppiert alles in drei Abschnitte: Telemetrie (Dashboard, Agenten, Alerts, Assets, FIM, Logs, KI), Automatisierungsreaktion (defensive Aktionen, Playbooks, Automatisierungsregeln) und Administration.

Pro-Agenten-Ansicht

Jeder registrierte Agent hat seine eigene Seite mit zwölf Tabs. Die Übersicht zeigt Live-Ressourcenmeter, die neuesten SIEM-Logs, Agenten-Metadaten und eine Bedrohungszusammenfassung:

Alerts sind alles, was die eigenen Korrelationsregeln des Agenten bereits markiert haben. Nach Schweregrad eingefärbt, filterbar, durchsuchbar:

Der KI-Analyse-Tab ist die operatororientierte Seite des lokalen LLM. Manuelle und automatische Scans landen beide hier. Jede Erkenntnis trägt ein Urteils-Chip, Konfidenz, MITRE-Indikatoren (wenn das Modell sie zurückgibt), IOCs, nächste Schritte und einen View Source-Button, der die exakte Log-Zeile öffnet, die die KI betrachtet hat:

Asset-Inventar

Hardware, Software und Netzwerk-Sockets pro Agent. Der Hardware-Tab listet jedes PnP-Gerät, Software listet installierte Pakete, Netzwerk listet jeden TCP/UDP-Socket mit seinem zugehörigen Prozess:

Log-Explorer

Agentenübergreifende Suche, unterstützt von OpenSearch. Wähle einen Agenten, wähle einen Datensatz (SIEM-Events, Sicherheitsalerts, Prozess-Events, Netzwerk, FIM, Audit- Logs) und suche. Es gibt auch einen Button, um OpenSearch Dashboards (Kibana-Fork) für Power-User zu öffnen:

Audit-Logs

Jeder Login-Versuch gegen die Plattform selbst, sowohl lokal als auch LDAP, mit Ergebnis, Quell-IP und Zeitstempel. Nützlich, wenn jemand in der „Wer-hat-sich-wann-eingeloggt“-Stimmung ist:

Schnellstart

Du benötigst Docker 24+ mit Compose v2 und Python 3.10+ auf dem Host (nur für den einmaligen Agenten-Build-Schritt). Der vollständige Stack benötigt ~16 GB RAM, siehe Systemanforderungen unten.```bash git clone https://github.com/d3vhex/Sentora.git cd Sentora

.env holds your local secrets. Never commit it.

cp .env.example .env

Generate the machine-generated secrets (FERNET_KEY, RABBITMQ_PASSWORD,

AGENT_SHARED_SECRET, OPENSEARCH_PASSWORD). Safe to re-run — it never

overwrites a value that is already set.

python scripts/init_secrets.py

Then set DB_PASSWORD by hand. Compose refuses to start without it.

On an existing deployment, rotate it with scripts/rotate_db_password.py

instead — MySQL fixes the root password at first init, so editing .env

alone locks the app out rather than changing the account.

Build the agent binary once. The server serves it via

/api/agent/download/{linux,windows}; skipping this means agents can't be

deployed because the download endpoint returns 404.

cd Sentora ./build_agent.sh # on Linux/macOS/WSL

.\build_agent.ps1 # on Windows

cd ..

docker compose up --build -d

Bereitstellen eines Agents: Kopieren Sie auf der Seite Agent bereitstellen den Einzeiler für das gewünschte Betriebssystem. Fügen Sie ihn auf dem Zielsystem (Admin-Shell) ein. Der Installer lädt die Binärdatei herunter, legt eine Konfiguration ab, registriert den Agent beim Server und richtet ihn als geplanten Task / systemd-Unit ein.

Dienste im Compose

Nur app und ingest lauschen auf allen Schnittstellen. Der Rest bindet an BIND_ADDR (Standard 127.0.0.1), da keiner von ihnen in der Standardkonfiguration authentifiziert – OpenSearch läuft mit deaktiviertem Sicherheits-Plugin und Dashboards ist eine unauthentifizierte Ansicht aller gesammelten Logs. Setzen Sie einen davon hinter denselben Reverse-Proxy mit Authentifizierung wie app, statt BIND_ADDR zu erweitern.

Die Schaltfläche „Open Dashboards“ im Log-Explorer verlinkt auf Port 5601 auf dem Hostnamen des Servers, funktioniert also vom Host selbst; entfernte Bediener benötigen diesen Reverse-Proxy.

Systemanforderungen

Leerlauf-Fußabdruck:

• Ollama (llama3.2:3b): ~3 GB, mehr unter Inferenz
• OpenSearch: ~2 GB Standard-Heap, Speicher wächst mit der Aufbewahrungsdauer
• MySQL: 500 MB – 1 GB
• RabbitMQ: ~300 MB
• Sanic + ingest + 3 AI-Worker: ~1 GB zusammen

Wenn der RAM knapp ist, wechseln Sie zu qwen2.5:1.5b oder einem anderen kleinen Ollama- Modell und verkleinern Sie den OpenSearch-Heap. Eine GPU ist nicht erforderlich, aber Ollama nutzt sie automatisch, falls vorhanden.

Defensive KI-Autoaktionen

Wenn das Urteil des defensiven Workers ACT mit einer Konfidenz ≥ AI_AUTO_ACT_CONF (Standard 0.75) ist und die empfohlene Aktion auf der folgenden Whitelist steht, stellt der Worker die Aktion direkt in die automations-Tabelle des Agents:``` BLOCK_IP KILL_PROCESS RESTART_SERVICE ISOLATE_HOST DISABLE_USER QUARANTINE_FILE SUSPEND_PROCESS LOGOFF_USER CONTAINER_ISOLATE CONTAINER_STOP CONTAINER_KILL

Wenn diese Zeile 0 permission-gated meldet, wird RBAC nicht durchgesetzt – behandeln Sie das als Ausfall.

Jede Route muss genau eines von drei Dingen sein: permission-gated, in _PUBLIC_HANDLERS aufgeführt oder in SESSION_ONLY_HANDLERS in tests/test_auth_wiring.py benannt, mit einem Kommentar, warum eine Session allein ausreicht. Ein Test erzwingt dies, sodass eine neue Route nicht stillschweigend unreguliert ankommen kann – genau so waren run_playbook, delete_soar_action und test_ldap_connection für jedes Konto erreichbar geworden, das sich anmelden konnte.

Login-Drosselung

Fünf fehlgeschlagene Versuche für ein Konto oder zwanzig von einer Adresse innerhalb von fünfzehn Minuten – weitere Versuche werden mit 429 verweigert, bis das Fenster verstrichen ist. Gezählt wird aus login_logs, das bereits jeden Fehlversuch aufzeichnete und das niemand las – bcrypt war die einzige Bremse gegen Online-Raten.

Die Prüfung läuft vor dem Passwortvergleich und beseitigt damit auch den Timing- Unterschied zwischen einem bekannten und einem unbekannten Benutzernamen. Sie schlägt offen fehl, wenn login_logs nicht erreichbar ist: Eine Anmeldeseite, die nicht erreichbar ist, weil die Audit-Tabelle ausgefallen ist, ist selbst ein Ausfall.

Client-Adressen hinter einem Proxy

X-Forwarded-For wird nur von einem Peer berücksichtigt, der in TRUSTED_PROXIES (kommagetrennte Adressen oder CIDRs, standardmäßig leer) aufgeführt ist. Wenn nichts vor der App steht, ist der Header angreiferkontrolliert – ihn also bedingungslos zu glauben – was dies ersetzt hat – erlaubte es einem Aufrufer, jede beliebige Adresse in den Audit- Trail zu schreiben und im selben Request das eigene Rate-Limit zurückzusetzen.``` TRUSTED_PROXIES=10.0.0.0/8,192.168.1.5

Die alten Schlüssel sind weiterhin in der Git-Historie vorhanden. Behandeln Sie das Schlüsselpaar, das vor dieser Änderung ausgeliefert wurde, als kompromittiert; neue Installationen verwenden es nicht mehr.

Lokale Fernet-Schlüssel

Der Server verwendet zwei Fernet-Schlüssel, die beide beim ersten Start automatisch generiert werden:

Setzen Sie für beide chmod 600. Sichern Sie sie. Wenn einer verloren geht, werden die entsprechenden verschlüsselten Daten unlesbar. Eine Rotation vor Ort gibt es noch nicht.

Threat Intelligence

Zwei unabhängige Mechanismen, beide optional:

Anreicherung pro Urteil (ai/intel.py). Der KI-Worker gleicht in einem Log gefundene Indikatoren mit AlienVault OTX und VirusTotal ab. Erfordert OTX_API_KEY / VT_API_KEY; wenn nicht gesetzt, erfolgt überhaupt kein externer Aufruf.

Indikator-Feeds (core/threat_feeds.py). Befüllt die Tabelle threat_intel stündlich von abuse.ch — Feodo Tracker (Botnet-C2-Adressen), ThreatFox (gemischte IoCs mit einem Konfidenzwert) und URLhaus (URLs, die Malware verbreiten).

Indikatoren tragen last_seen und werden nach THREAT_INTEL_STALE_DAYS (Standard: 30) entfernt: Eine Adresse, die im letzten Quartal ein C2 gehostet hat, gehört in der Regel inzwischen jemand anderem, und sie zu behalten erzeugt auf Dauer Fehlalarme. Jeder Feed ist auf THREAT_INTEL_MAX_PER_FEED Zeilen begrenzt, da die Tabelle auf dem Alarmpfad gelesen wird.

abuse.ch hat Downloads hinter einen kostenlosen Kontoschlüssel verlagert. Ein Feed, der 401/403 zurückgibt, meldet dies im Server-Log; setzen Sie THREAT_INTEL_AUTH_KEY.

Prüfen Sie, was tatsächlich angekommen ist:```bash docker logs sentora-server | grep ThreatIntel

Mit diesen Einstellungen, plus OTX_API_KEY / VT_API_KEY nicht gesetzt, verlässt nichts das Netzwerk. Schriftarten sind gebündelt, Ollama ist lokal, kein CDN wird kontaktiert.

Fleet-Exposition

/api/exposure/report zählt ungepatchte Pakete und Datei-Integritätsereignisse über die gesamte Fleet, pro Agent, schlimmste zuerst. Es meldet seine eigene Abdeckung: complete: false, wenn ein Agent nicht gelesen werden konnte, denn eine Summe über die Hälfte der Fleet ist keine Fleet-Gesamtsumme.

Es gibt bewusst keinen Score. Der Endpunkt gab zuvor 100 - vulns*2 - fim*5 als „Compliance-Score“ zurück — das entspricht keinem Framework, skaliert nicht mit der Fleet-Größe und fällt bei jeder echten Fleet auf null. Die Schweregrad-Einstufung fehlt aus demselben Grund: vulnerabilities_report hat keine Schweregrad-Spalte und seine Felder sind im Ruhezustand verschlüsselt, sodass jede Einstufung erfunden werden müsste.

Agent-Konfigurationsvalidierung

POST /<agent>/config/<type> validiert, bevor etwas einen Sensor erreicht: YAML-Parsing, strukturelle Form und — die entscheidende Ebene — Regex-Kompilierung. Ein ungültiger Regex ist perfekt gültiges YAML und deaktiviert stillschweigend die Kategorie, die ihn enthält, sodass eine reine Syntaxprüfung ihn direkt zum Endpunkt durchreichen würde. Der Editor prüft gegen denselben Endpunkt, während du tippst, und meldet Probleme mit klickbaren Zeilennummern.

Architekturübersicht```

Agent (Win / Linux) │ TCP frames + REST polling ▼ ingest (:5001) ──► RabbitMQ ──► AI worker fleet (3 modes) │ │ ▼ ▼ MySQL (per-agent _db) ai_analysis_results │ ▼ app (Sanic :8000) ──► React UI + REST + WebSocket screen proxy

KI-Arbeiter manuell

Dasselbe Skript, drei Rollen:```bash WORKER_TYPE=automation python ai_worker.py WORKER_TYPE=manual python ai_worker.py WORKER_TYPE=defensive python ai_worker.py

3. Neue Endpunkte müssen in @require_permission(...) eingebettet werden. Das Boot-Log gibt die Zählung aus; wenn es 0 permission-gated meldet, stimmt etwas mit der Verdrahtung nicht, nicht mit deiner Route.
4. Alles, was einen Agenten oder einen externen Host erreicht, benötigt eine Validierung auf der Serverseite, nicht nur im Browser. Zwei Implementierungen driften auseinander, und die Kopie im Browser ist die, der die Betreiber am Ende vertrauen.

Für alles, was größer als ein Fix ist, öffne zuerst ein Issue, damit wir uns auf den Ansatz abstimmen können.

Projektstruktur```

. ├── app.py # Sanic API + React SPA host ├── server.py # TCP ingest ├── ai_worker.py # AI worker fleet (3 modes) ├── ai/ │ ├── utils.py # LLM helpers, AI cache, SOAR queueing │ └── intel.py # OTX / VT per-verdict enrichment (opt-in) ├── core/ │ ├── mq.py # RabbitMQ publisher │ ├── opensearch.py # OpenSearch index/search │ ├── config_validation.py # Agent YAML validation (parse, shape, regex) │ └── threat_feeds.py # abuse.ch indicator feeds ├── security/ │ ├── session.py # Server-side session store │ └── ssrf.py # Proxy destination rules ├── scanners/ │ └── vuln.py # Server-side OSV scanner ├── scripts/ │ ├── init_secrets.py # Generate the secrets .env needs │ ├── rotate_db_password.py # Rotate the MySQL root password safely │ └── api_smoke_test.py # Exercise every route against a live server ├── tests/ # pytest; no MySQL or RabbitMQ required ├── frontend/ # React 18 + TS SPA │ └── src/lib/ # Shared logic (playbook action catalogue) ├── Sentora/ # Cross-platform agent ├── certs/ # Self-signed dev certs ├── docs/ # Architecture + screenshots └── docker-compose.yaml