ONUS - Automatisierte Schwachstellenbewertung & Penetrationstests

Erstellt von maverickaayush.

Ein lokal gehostetes, netzwerkisoliertes (air-gapped) VAPT-Tool: Man richtet es auf eine autorisierte Zieldomain aus, und es führt 8 Scan-Module parallel aus, bewertet jeden Befund deterministisch (CVSS v3.1), ergänzt optional KI-generierte Beschreibungen in einfacher Sprache über ein lokales LLM und erzeugt einen PDF-Bericht plus ein Live-Web-Dashboard. Keine externen API-Aufrufe – alles läuft im eigenen Netzwerk.

Zwei Möglichkeiten, ONUS auszuführen:

• Self-hosted (dieses Repo): docker compose up → Domain eingeben → Autorisierungsfeld aktivieren → scannen. Kein Konto, keine Anmeldung, keine E-Mail-Verifizierung – es ist bewusst für einen einzelnen Bediener ausgelegt, und alles unten deckt diesen Weg ab.
• Gehostet: Eine verwaltete Instanz ist live unter tryonus.tech. Sie ergänzt produktionsspezifische Funktionen (Konten / OAuth-Anmeldung, eine Scan-Warteschlange, Verlauf pro Benutzer), die in diesem Repo standardmäßig aus sind, damit Self-Hosting einfach bleibt. Siehe Self-hosted vs. gehostet.

Funktionen

• 8 parallele Scan-Module (Celery) – Netzwerk-Reconnaissance (Ports/Dienste/Subdomains/DNS/WHOIS), Webanwendungs-Scanning (ZAP + Nikto + Katana), SSL/TLS-Konfiguration, HTTP-Sicherheitsheader, OWASP-Top-10-Checks, Technologie-Fingerprinting/WAF-Erkennung, CVE-Scanning (Nuclei), Verzeichnis-Enumeration (FFUF).
• Deterministische CVSS-v3.1-Bewertung – Schweregrad, CVSS-Score/Vektor, Priorität und OWASP-Kategorie werden aus einem Regelkatalog berechnet und niemals von einem LLM geraten. Zwei Läufe desselben Scans erzeugen byteidentische numerische Felder.
• Konfidenzprüfung – Befunde werden passiv erneut geprüft (nur nicht-destruktive Wiederbeobachtung) und als bestätigt / wahrscheinlich / unverifiziert markiert, statt stillschweigend verworfen zu werden.
• Optionale lokale KI-Analyse – Ollama + Qwen 2.5 7B verwandelt bewertete Befunde in Beschreibungen in einfacher Sprache und Schritte zur Behebung. Vollständig netzwerkisoliert; das Tool funktioniert auch ohne sie (siehe Schnellstart unten).
• Kontextbewusste, umsetzbare Behebungsempfehlungen – jeder Befund endet mit einem konkreten nächsten Schritt. Stabile Probleme verwenden deterministische Vorlagen; wirklich kontextabhängige nutzen die KI; und die Erkennung verwalteter Plattformen (Vercel / Cloudflare / Netlify / GitHub Pages / …) bedeutet, dass ein TLS-Befund auf Plattformebene sagt, wer diese Schicht kontrolliert und was als Nächstes zu tun ist – statt unmöglicher Hinweise wie „Bearbeiten Sie Ihre Serverkonfiguration“.
• PDF-Bericht + Web-Dashboard – ein mit WeasyPrint gerenderter Bericht und ein Next.js-Dashboard, beide von denselben bewerteten/beschriebenen Befunden gespeist.

Self-hosted vs. gehostet

Der Self-hosted-Standardpfad ist bewusst der einfache: keine Registrierung, keine E-Mail-Verifizierung, kein OAuth. Die nur im Hosting verfügbaren Funktionen (Authentifizierung, Scan-Warteschlange) liegen hinter Konfigurationsflags, die standardmäßig aus sind (REQUIRE_AUTH=false, HOSTED_QUEUE_ENABLED=false; siehe Konfiguration) und in docker-compose.yml nicht gesetzt werden – wer ONUS lokal betreibt, steht also nie hinter einem Login. Bevorzugen Sie null Setup? Nutzen Sie die gehostete Website unter tryonus.tech.

Screenshots

Neuer Scan	Live-Scan-Status

Berichts-Dashboard	Scan-Entdeckungen

Architektur

domain → [recon | webscan | ssl_tls | headers | owasp | tech_fingerprint | nuclei | enumeration] (parallel, Celery)
       → any module failed/timed out? → pause for operator retry/continue/cancel
       → aggregator (dedup + OWASP-map + sort)
       → confidence verification (passive re-observation)
       → deterministic CVSS scoring
       → Ollama (Qwen 2.5 7B) AI analysis
       → WeasyPrint PDF + PostgreSQL
       → dashboard / PDF download

Sechs Schichten: Next.js-Frontend → FastAPI → Celery/Redis → 8 parallele Scan-Module → Ollama (Qwen 2.5 7B) → WeasyPrint-PDF + Dashboard. Vollständige Details in ARCHITECTURE.md (Schemata, Verträge, Guardrails) und docs/QUICK_REF.md (schnelles Nachschlagen für häufige Änderungen).

Voraussetzungen

• Docker + Docker Compose v2
• ~8 GB freier Speicherplatz. Die erstellten Images umfassen insgesamt ~6,8 GB (Backend und Worker jeweils ~3,25 GB – sie bündeln Nuclei-Templates und ein Headless-Chromium über Playwright – plus ein ~270 MB großes Frontend), und der Build selbst benötigt zusätzlich Luft nach oben.
• ~6 GB freier Arbeitsspeicher. Allein der ZAP-Sidecar ist auf 4 GB begrenzt (mem_limit: 4g), und Postgres, Redis, die API, der Worker und das Frontend laufen parallel dazu.
• Der erste Build dauert bei ordentlicher Verbindung etwa 10–15 Minuten.

Schnellstart

Siehe Voraussetzungen oben: ~8 GB Speicher und ~6 GB RAM, und rechnen Sie mit einem 10–15-minütigen ersten Build.

cp .env.example .env
cp backend/subfinder-config/provider-config.yaml.example backend/subfinder-config/provider-config.yaml
docker compose up -d
docker compose ps        # wait for zap to report healthy (~2 min)

Öffnen Sie http://localhost:3000, geben Sie eine Domain ein, aktivieren Sie das Autorisierungsfeld und starten Sie den Scan.

Keine Anmeldung, keine Registrierung, keine E-Mail-Verifizierung. Self-hosted ONUS ist standardmäßig für einen einzelnen Bediener ausgelegt – zwischen dem Öffnen des Dashboards und dem Scannen gibt es keinen Kontoschritt.

Das funktioniert ohne eine Ollama-Installation. Die CVSS-/Schweregrad-/Prioritätsbewertung ist immer deterministisch (analysis/cvss_scorer.py) – ohne laufendes Ollama erhalten Befunde lediglich eine regelbasierte Beschreibungsvorlage statt KI-generiertem Text. Siehe „Optional: KI-generierte Beschreibungen aktivieren“ unten, um das einzuschalten.

Für den Betrieb dieses Tools sind null API-Schlüssel erforderlich. Jedes darin eingebundene Scan-Tool (nmap, ZAP, Nikto, testssl.sh, Nuclei, Amass, Naabu, httpx, WhatWeb, WAFW00F, FFUF) sowie Ollama selbst funktionieren ohne jeden Schlüssel. Der obige Kopierschritt für die Subfinder-Konfiguration ist die eine optionale Ausnahme – es ist in Ordnung, die leere Vorlage zu belassen; Subfinder läuft dann nur mit kostenlosen/öffentlichen Quellen. Um die Subdomain-Enumeration zu vertiefen, können Sie vor dem Start bis zu zwei Free-Tier-Schlüssel in diese Datei eintragen: ein GitHub-Personal-Access-Token und einen ProjectDiscovery-Chaos-API-Schlüssel – siehe die Kommentare in provider-config.yaml.example.

Optional: KI-generierte Beschreibungen aktivieren

Ollama läuft nativ auf dem Host (nicht in Docker), sodass es die GPU des Hosts direkt nutzen kann; Container erreichen es über host.docker.internal.

1. Installieren Sie Ollama auf dem Host: https://ollama.com/install.sh
2. Laden Sie das Modell: ollama pull qwen2.5:7b
3. Machen Sie Ollama für Docker-Container erreichbar (Ollama lauscht standardmäßig nur auf 127.0.0.1, was das Docker-Bridge-Netzwerk nicht erreichen kann):
   root@kitploit:~

   sudo systemctl edit ollama
   

   Fügen Sie unter [Service] hinzu:
   root@kitploit:~

   [Service]
   Environment="OLLAMA_HOST=0.0.0.0:11434"
   

   Speichern, dann:
   root@kitploit:~

   sudo systemctl daemon-reload && sudo systemctl restart ollama
   

   Hinweis: Dadurch ist Ollama nicht nur für Docker, sondern aus Ihrem lokalen Netzwerk erreichbar – auf einem persönlichen Rechner unproblematisch, auf einem gemeinsam genutzten lohnt sich eine Firewall-Regel.
4. Überprüfen: curl http://localhost:11434/api/tags
5. Starten Sie Backend/Worker neu, damit sie es übernehmen: docker compose restart backend worker

Optional: Übungsziele

Die Compose-Datei definiert außerdem 12 absichtlich verwundbare Übungs-Apps (Juice Shop, DVWA, bWAPP, Mutillidae, NodeGoat, DVWP/WordPress hinter einer ModSecurity-WAF, Metasploitable2, WebGoat), um den Scanner an etwas auszuprobieren, ohne ein eigenes autorisiertes Ziel zu benötigen. Sie sind hinter einem Compose-Profil verborgen, sodass sie standardmäßig nie gebaut/gestartet werden:

docker compose --profile targets up -d

Warnung: Diese Dienste sind absichtlich verwundbar, einige tatsächlich mit Hintertüren versehen (Metasploitable2 enthält eine lebende vsftpd-Hintertür). Führen Sie das Profil targets nur auf einem Rechner aus, der nicht aus dem Internet oder einem gemeinsamen Netzwerk erreichbar ist – niemals auf einer öffentlichen Cloud-Instanz oder einem exponierten Host.

Die meisten davon laufen aus vorgefertigten Images und benötigen nichts Zusätzliches. Zwei – nodegoat und dvwp-wordpress – werden aus Quellcode gebaut, der nicht in dieses Repo eingebunden ist, und müssen zuerst geklont werden:

git clone https://github.com/OWASP/NodeGoat nodegoat-src
git clone https://github.com/vavkamil/dvwp dvwp-src

Veröffentlichte Ports nach dem Start: Juice Shop :3001, DVWA :8081, bWAPP :8083, Mutillidae :8084, NodeGoat :8085, DVWP (über WAF, TLS) :8444, WebGoat :8082. Metasploitable2 veröffentlicht keinen Host-Port (nur über das interne Docker-Netzwerk von backend/worker erreichbar), da es echte Netzwerkdienste mit Hintertüren/ohne Authentifizierung exponiert.

Konfiguration

Umgebungsvariablen, gesetzt über .env (kopiert aus .env.example):

Die obigen Standardwerte für POSTGRES_PASSWORD/SECRET_KEY sind nur für Demozwecke – für eine lokale/persönliche Instanz sind sie in Ordnung, aber ändern Sie beide, bevor Sie irgendwo bereitstellen, das für andere erreichbar ist. Dies wird jetzt erzwungen, nicht nur empfohlen: Setzen Sie ONUS_ENV=production (oder aktivieren Sie die gehostete Authentifizierung), und das Backend weigert sich zu starten, solange einer der beiden Werte noch ein Standard-/Platzhalterwert ist. Erzeugen Sie einen starken Schlüssel mit python -c "import secrets; print(secrets.token_urlsafe(48))".

Nur im Hosting verfügbare Funktionen sind standardmäßig aus. REQUIRE_AUTH (Konten / OAuth-Anmeldung) und HOSTED_QUEUE_ENABLED (Scan-Warteschlange) sind standardmäßig beide false und in docker-compose.yml nicht gesetzt, sodass Self-hosted ONUS Sie nie mit einem Login oder einer Warteschlange blockiert. Lassen Sie sie aus, es sei denn, Sie bauen bewusst eine Multi-User-Hosting-Bereitstellung – die verwaltete tryonus.tech-Instanz ist diejenige, die sie aktiviert.

Analytics (optional)

ONUS hat standardmäßig keine Analytics – es wird nichts geladen und keine Daten verlassen den Browser. Um anonyme Nutzungsmetriken für Ihre eigene Bereitstellung zu erfassen, setzen Sie eine einzelne Google-Analytics-4-Measurement-ID:

NEXT_PUBLIC_GA_ID=G-XXXXXXXXXX

Es ist eine Build-Zeit-Variable des Frontends, also setzen Sie sie in der Frontend-Build-Umgebung (eine Vercel-/Host-Umgebungsvariable oder frontend/.env.local für einen lokalen npm run build). Wenn gesetzt, lädt GA nur in Produktions-Builds und erfasst Seitenaufrufe sowie einige Produkt-Events (z. B. scan_started, scan_completed, report_downloaded). Benutzerdefinierte Events laufen über den typisierten Helfer in frontend/lib/analytics.ts – trackEvent('scan_started').

Datenschutz: Es werden nur anonyme Ereignisse mit geringer Kardinalität gesendet – niemals gescannte Domains, Scan-Ergebnisse, Befunde, Berichtsinhalte, der Autorisierungsstatus oder personenbezogene Daten. Lassen Sie NEXT_PUBLIC_GA_ID ungesetzt, und ONUS verhält sich genau wie zuvor; Analytics ist vollständig opt-in.

API-Dokumentation

FastAPI erzeugt automatisch interaktive Swagger-Dokumentation – sobald das Backend läuft, öffnen Sie http://localhost:8000/docs.

Beenden

docker compose down

Protokolle

docker compose logs -f backend worker

Tests & Validierung

pip install -r backend/requirements-dev.txt
pytest backend/tests

655 automatisierte Backend-Tests zum Zeitpunkt dieses Schreibens. Über die Unit-/Integrationssuite hinaus wurde das Tool während der Entwicklung End-to-End getestet: 79 echte Scans durchgeführt und 124 PDF-Berichte gegen neun absichtlich verwundbare Übungsanwendungen (DVWA, Juice Shop, Mutillidae, NodeGoat, bWAPP, WebGoat, Metasploitable2, DVWP/WordPress hinter einer WAF) plus ein autorisiertes öffentliches Ziel (testphp.vulnweb.com) erzeugt – keine hypothetischen Zahlen. Scannen Sie ausschließlich Ziele, für die Sie ausdrücklich zum Testen autorisiert sind – siehe docs/test_findings.md für die während der Entwicklung verwendeten Übungsziele.

Dokumentation

• ARCHITECTURE.md – vollständige Architektur, Schemata und die Verträge, die eine Änderung niemals brechen sollte. Lesen Sie dies, bevor Sie eine nicht-triviale Änderung vornehmen.
• docs/QUICK_REF.md – Befehle, Verantwortlichkeiten der Ordner, „Wo nehme ich diese Änderung vor?“
• docs/scanners.md – Begründung hinter dem Timing-/Flag-Design jedes Scan-Moduls.
• docs/ai.md – Ollama-Timeout-/Kontext-Tuning, warum die Bewertung vollständig vom LLM gelöst wurde.
• docs/docker.md – Hinweise zu Docker-Abweichungen und Build-Stolperfallen.
• docs/troubleshooting.md – wie man jedes Modul/jede Stufe isoliert manuell testet.
• docs/roadmap.md – historische Build-Sequenz (Build ist abgeschlossen).
• – Entwicklungs-Setup, Tests, PR-Erwartungen.

Lizenz

MIT – siehe LICENSE.

Nur autorisierte Nutzung

Das Scannen von Zielen ohne ausdrückliche schriftliche Autorisierung ist nach dem IT Act 2000 (Indien) und gleichwertigen internationalen Gesetzen illegal. Dieses Tool verlangt bei jedem Scan eine Autorisierungsbestätigung und protokolliert zu Nachweiszwecken den Bediener + Zeitstempel.