# Administratorhandbuch — barox SecPen Zielgruppe: Personen, die die Anwendung betreiben, konfigurieren und die Sicherheitsgrenzen verantworten. --- ## 1 Rollen und Berechtigungen | Rolle | Darf | |---|---| | **Administrator** | alles: Systemeinstellungen, Nessus, Scanprofile, Benutzer, Netzbereiche, alle Scans abbrechen, Audit-Log | | **Security Operator** | Geräte verwalten, Scans vorbereiten und starten, Ergebnisse bearbeiten, Reports erstellen, eigene Scans abbrechen | | **Approver** | aggressive/produktive Scans freigeben, Wartungsfenster bestätigen, Scanprofile genehmigen, jeden Scan abbrechen | | **Viewer** | nur lesen | **Vier-Augen-Prinzip:** Wer einen Scan anlegt, kann ihn nicht selbst freigeben — auch nicht als Administrator (`ScanJobPolicy::approve()`). ### Anmeldung über Microsoft Entra ID 1. In Entra ID eine App-Registrierung anlegen. 2. Redirect-URI: `https://secpen.barox.io/auth/oidc/callback` (Web). 3. Client Secret erzeugen. 4. Optional Gruppen-Claim aktivieren (Token-Konfiguration → Gruppen). 5. In der `.env`: ``` AUTH_OIDC_ENABLED=true AUTH_OIDC_TENANT_ID= AUTH_OIDC_CLIENT_ID= AUTH_OIDC_CLIENT_SECRET= AUTH_OIDC_ALLOWED_DOMAINS="barox.ch" AUTH_OIDC_ROLE_MAP='{"":"security_operator","":"approver"}' AUTH_OIDC_DEFAULT_ROLE=viewer ``` Das `id_token` wird gegen die JWKS des Tenants geprüft (Signatur, Aussteller, Zielgruppe, Ablauf, `nonce`); der Ablauf nutzt PKCE. **Break-Glass:** `AUTH_LOCAL_ENABLED=true` lässt eine lokale Anmeldung zu. Solche Konten sind mit `is_breakglass` markiert; jede Anmeldung darüber wird im Audit-Log als Warnung geführt. Das Passwort verlangt mindestens 14 Zeichen mit Gross-/Kleinschreibung, Ziffern und Sonderzeichen und wird gegen bekannte Leaklisten geprüft. --- ## 2 Netzbereiche verwalten **Ohne Allowlist-Eintrag startet kein Scan.** Verwaltung unter *Verwaltung → Netzbereiche*. Beim Anlegen wird geprüft: - gültiges CIDR - nicht grösser als `/22` (IPv4, konfigurierbar über `TARGETS_MAX_PREFIX_V4`) - keine Überschneidung mit der harten Systemsperre - keine öffentlichen Adressen (solange `TARGETS_ALLOW_PUBLIC=false`) Jeder Eintrag braucht eine **Referenz der Freigabe** und eine **Begründung** — beides landet im Audit-Log und später im Bericht. Die **Blocklist gewinnt immer.** Systemeinträge (Loopback, Link-Local, Multicast, Broadcast, CGNAT, reservierte Bereiche) lassen sich weder löschen noch deaktivieren. Mit der **Zielprüfung** auf derselben Seite lässt sich vorab prüfen, ob eine Adresse zulässig wäre — dieselbe Logik wie beim echten Scanstart. --- ## 3 Scanprofile Profile sind die einzige Quelle für Scanparameter. Es gibt kein Feld für freie Nmap-Optionen — weder für Benutzer noch für Administratoren. Administrativ änderbar: Name, Beschreibung, Risikohinweis, Portlisten, Grenzwerte, Laufzeit, Freigabe- und Fensterpflicht. Nicht änderbar: Scantechnik, Timing-Template, NSE-Whitelist. Vor dem Speichern übersetzt die Anwendung das Profil testweise in eine Argumentliste. Die tatsächliche Argumentliste ist auf der Profilseite sichtbar — so lässt sich jederzeit belegen, was ausgeführt wird. ### Grenzwerte Wirksam ist die Kombination **global → Profil → Gerät** (später gewinnt): | Wert | Standard | |---|---| | CPU | > 90 % über 60 s | | Paketverlust | > 20 % | | Latenz | > 2000 ms über 30 s | | HTTPS | 3 Ausfälle in Folge | | SNMP | 3 Ausfälle in Folge | | Uptime-Rücksprung | sofortiger Abbruch | | Link-Flaps | 3 je Intervall | | STP-Topologieänderungen | 5 je Intervall | --- ## 4 Geräteprofile (SNMP-OIDs) Unter *Stammdaten → Geräteprofile*. Ohne passendes Profil misst SecPen nur ICMP und HTTPS — CPU, Speicher und Temperatur bleiben leer. Mitgeliefert: Generic (RFC1213), Generic (UCD/NET-SNMP), Hirschmann HiOS, Moxa EDS, Cisco IOS, barox. Neues Profil anlegen: 1. OIDs aus der Hersteller-MIB ermitteln — entweder manuell (`snmpwalk -v2c -c 1.3.6.1.4.1`) **oder** komfortabel über die MIB-Bibliothek (siehe 4.1). 2. Profil mit Hersteller, Modellfamilie und OIDs anlegen. 3. Bei Bedarf `value_transforms` setzen — Beispiel für `ssCpuIdle` (Leerlauf statt Last): `{"cpu":{"factor":-1,"offset":100}}`. 4. Profil einem Testgerät zuweisen und einen Erreichbarkeitsscan starten; die Messwerte erscheinen auf der Scan-Detailseite. ### 4.1 MIB-Bibliothek und OID-Extraktion Unter *Stammdaten → MIB-Bibliothek* (Recht `device_profile.manage`) lassen sich Hersteller-MIBs (`.mib`, `.my`, `.txt`) hochladen. Der Upload wird im Hintergrund vom Worker geparst (eigenständiger SMIv2-Parser, keine externen Werkzeuge); die symbolischen Namen werden zu numerischen OIDs aufgelöst und im Katalog abgelegt. Im Geräteprofil-Formular: 1. Unter *OID-Mapping* eine **Referenz-MIB** wählen. 2. **„Vorschläge aus MIB übernehmen"** füllt CPU, Speicher, Temperatur, Firmware und Seriennummer anhand einer Namens-Heuristik vor. Die Vorschläge werden **nie** automatisch gespeichert — sie erscheinen in den Feldern und müssen vor dem Speichern geprüft werden. 3. Für alles Weitere: in ein OID-Feld klicken und über die **Katalogsuche** (Name oder OID) den passenden Eintrag wählen — die OID wird in das zuletzt fokussierte Feld übernommen. Skalare Werte werden mit der Instanz `.0` abgefragt. Hinweise: - Auskommentierte MIB-Objekte (`-- …`) werden bewusst ignoriert; sie sind am Gerät nicht abfragbar. - MIBs gelten gemeinsam für alle Profile. Ein erneuter Upload derselben Modulversion aktualisiert den bestehenden Eintrag. - Optionale `.env`-Schlüssel: `MIB_STORAGE_PATH` (Standard `/mibs`), `MIB_MAX_KB`, `MIB_MAX_OBJECTS`. --- ## 5 Nessus einrichten *Verwaltung → Nessus*. 1. Verbindung anlegen: Produkt, Basis-URL, Access Key, Secret Key. Die Schlüssel werden verschlüsselt gespeichert und nie wieder angezeigt. Ein leeres Feld beim Bearbeiten bedeutet „unverändert lassen“. 2. **Verbindung testen.** 3. **Policies abgleichen.** Jede Policy wird vom `PolicyGuard` geprüft: `safe_checks` muss aktiv sein; die Familien *Denial of Service* und *Brute force attacks* dürfen nicht aktiviert sein. 4. Nur eine geprüfte Policy kann **freigegeben** werden. Nur eine freigegebene Policy ist verwendbar — die Prüfung erfolgt erneut bei jedem Scanstart. Bei Änderungen an der Policy auf dem Nessus-Server erneut abgleichen: Besteht sie den Guard nicht mehr, verliert sie automatisch ihre Freigabe. Wechsel auf Tenable Security Center: `NESSUS_PRODUCT=tenable_sc`. Die Endpunkte stehen in `config/nessus.php` und lassen sich ohne Codeänderung anpassen. --- ## 6 Not-Aus Zwei unabhängige Quellen: - **Oberfläche** (*Systemeinstellungen*, Berechtigung `scan.emergency_stop`): stoppt sofort alle laufenden Scans und sperrt die Annahme neuer Aufträge. - **`.env`** (`SCAN_EMERGENCY_STOP=true`): wirkt zusätzlich und lässt sich über die Oberfläche **nicht** aufheben — gedacht für den Fall, dass der Anwendung selbst nicht mehr vertraut wird. Auf der Kommandozeile: ```bash sudo -u barox php artisan barox:emergency-stop on --reason="Vorfall #4711" sudo -u barox php artisan barox:emergency-stop off ``` Auch beim Not-Aus werden **keine** Massnahmen an den Zielgeräten ausgeführt. --- ## 7 Audit-Log Protokolliert werden Anmeldungen (auch fehlgeschlagene), Geräte- und Profiländerungen, Allowlist-Änderungen, Freigaben, Scanstart und -abbruch, automatische Abbrüche, Reportexporte, Finding-Änderungen, Nessus-Konfiguration und jeder Zugriff auf hinterlegte Zugangsdaten. Jeder Eintrag ist über `prev_hash`/`hash` mit dem vorherigen verkettet. Das Model verweigert `update()` und `delete()`. Prüfung: ```bash sudo -u barox php artisan barox:audit-verify ``` oder in der Oberfläche über *Audit-Log → Hash-Kette prüfen*. **Empfehlung für den Datenbankbenutzer.** Zusätzlich zur Anwendungssperre: ```sql REVOKE UPDATE, DELETE ON barox_secpen.audit_logs FROM 'barox_secpen'@'localhost'; GRANT SELECT, INSERT ON barox_secpen.audit_logs TO 'barox_secpen'@'localhost'; FLUSH PRIVILEGES; ``` Migrationen laufen dann mit einem separaten Wartungskonto. --- ## 8 Wartung | Aufgabe | Befehl / Ort | |---|---| | Installationsprüfung | `php artisan barox:preflight` | | Verwaiste Prozesse | `php artisan barox:reap-scans` (läuft alle 5 min automatisch) | | Messreihen aufräumen | automatisch, `HEALTH_RETENTION_DAYS` (Standard 180) | | Logs | `/var/log/barox-secpen/`, `storage/logs/`, Rotation über logrotate | | Rohdaten | `/var/lib/barox-secpen/scans`, Aufbewahrung `SCAN_KEEP_RAW_DAYS` | | Schlüsselrotation | siehe unten | ### Schlüsselrotation (APP_KEY) 1. Alten Schlüssel sichern. 2. Neuen erzeugen: `php artisan key:generate --show`. 3. In der `.env`: alten Schlüssel nach `APP_PREVIOUS_KEYS` verschieben, neuen als `APP_KEY` setzen. 4. `php artisan config:cache`, Dienste neu starten. 5. Verschlüsselte Werte (SNMP-Zugangsdaten, Nessus-Schlüssel) einmal speichern, damit sie mit dem neuen Schlüssel abgelegt werden. --- ## 9 Sicherheitsprüfliste - [ ] `APP_DEBUG=false`, `APP_ENV=production` - [ ] `QUEUE_CONNECTION` ist nicht `sync` (sonst liefe der Scan im Webprozess) - [ ] `SESSION_SECURE_COOKIE=true`, HTTPS erzwungen - [ ] `TARGETS_ALLOW_PUBLIC=false` - [ ] Datenverzeichnisse ausserhalb des DocumentRoot, Rechte 0750 - [ ] Worker läuft als `barox`, nicht als `root` und nicht als `www-data` - [ ] `www-data` hat keine sudo-Regel und keine Capabilities - [ ] `disable_functions` im PHP-FPM-Pool aktiv - [ ] Allowlist ist eng gefasst und mit Referenzen belegt - [ ] Nessus-Policies geprüft und freigegeben - [ ] Audit-Kette prüft sauber - [ ] Sicherung eingerichtet und Rücksicherung getestet