Monitoring, das keine Angriffsfläche hinzufügt
Der Agent ist ein lesbares Shell-Skript, das per Cron läuft, Werte sammelt und sendet. Er öffnet keinen Port, lauscht nicht und nimmt keine Befehle entgegen. Das Portal kennt nur das, was der Agent schickt. Und was das Portal selbst schützt, steht hier, Punkt für Punkt.
PeakNode fügt Ihrer Infrastruktur keine Angriffsfläche hinzu: Der Agent öffnet keinen Port und nimmt keine Befehle entgegen, er sendet Messwerte über TLS mit einem Token je Gerät im Authorization-Header. Das Konto ist mit Zwei-Faktor-Authentifizierung und Sperren nach Fehlversuchen geschützt, Uptime-Checks und Webhooks erreichen nur öffentliche Ziele.
- Eingehend keine Firewall-Freigabe, ausgehend nur Port 443 zu peaknode.de.
- Ein bekannt gewordenes Token liefert nur Messwerte für genau diesen Monitor ein.
- Gesamter Quellcode im Oktober 2026 geprüft, Maßnahmen auf dieser Seite beschrieben.
| Gesendet | Quelle | Nicht gesendet |
|---|---|---|
| CPU-, RAM-, Swap-, Festplatten-, Netzwerk-Auslastung | /proc, df, cgroup | Dateiinhalte, Verzeichnisse, Konfiguration |
| GPU-Werte je Karte, ECC, PCIe, Drosselgrund | nvidia-smi | Anmeldedaten, Umgebungsvariablen |
| Xid-Zeilen des NVIDIA-Treibers (letzte 15 Minuten) | journalctl -k / dmesg | übrige Kernel- oder Anwendungslogs |
| Prozesse auf GPUs: PID, Name, Nutzer, Speicher | nvidia-smi, ps | Prozessargumente, Befehlszeilen |
| Betriebssystem, Kernel, CPU-Modell, Uptime | os-release, uname, lscpu | IP-Adressen interner Netze, Hostnamen anderer Systeme |
Schutz des Portals und Ihrer Konten
Umgesetzt nach einem Audit des gesamten Quellcodes im Oktober 2026. Die Liste ist vollständig, nicht ausgewählt.
Token je Gerät, im Header
Jeder Server-Monitor hat ein eigenes Token mit 192 Bit Zufall. Der Agent sendet es im Authorization-Header, nicht in der URL, damit es in keinem Zugriffsprotokoll landet. Ein kompromittiertes Gerät kann nur seine eigenen Messwerte fälschen.
Konto-Schutz
Zwei-Faktor-Authentifizierung per Authenticator-App. Sperre nach wenigen Fehlversuchen, je IP-Adresse und je Konto, falsche 2FA-Codes zählen mit. Passwort-Reset-Links verfallen nach 60 Minuten und heben die Zwei-Faktor-Authentifizierung nicht auf.
Sitzungen und Browser
Sitzungs- und Login-Cookies sind HttpOnly, Secure und SameSite. Das Portal lässt sich nicht in fremde Seiten einbetten (X-Frame-Options, frame-ancestors), Inhaltstypen werden nicht erraten (nosniff), HSTS erzwingt TLS inklusive Subdomains.
Keine Umwege ins Innere
Uptime-Checks, Web-Tools und Webhooks akzeptieren nur öffentliche Ziele. Private Netze, Loopback, Link-Local und Cloud-Metadaten-Adressen werden nach DNS-Auflösung abgewiesen; Abrufe sind auf http und https begrenzt.
Eingaben und Dateien
Ping-Ziele werden als einzelnes Argument übergeben, nie als Kommandozeile. Hochgeladene Dateien werden nie als Skript ausgeführt. Repository-, Migrations- und Build-Dateien sind über das Web nicht erreichbar.
Zuverlässigkeit
Jede Treiberabfrage im Agenten hat ein Timeout. Bleiben Meldungen aus, erkennt das Portal den Ausfall nach drei Intervallen und meldet die Rückkehr. Hardware-Ereignisse werden dedupliziert, damit ein Vorfall eine Nachricht erzeugt, nicht zehn.
Maßnahmen im Detail
Transparenz statt Versprechen: Was genau gilt, und wo.
| Maßnahme | Gilt für | Umsetzung |
|---|---|---|
| Push-Architektur ohne Daemon | Agent auf Linux, macOS, Windows | Cron bzw. geplanter Task ruft das Skript auf; keine Netzwerkschnittstelle wird geöffnet |
| TLS-Verifikation | Agent | curl ohne --insecure; ausgehend nur Port 443 |
| Token je Monitor | Agent, Empfangs-Endpunkt | 192 Bit Zufall, Vergleich in konstanter Zeit, Bearer-Header; Meldungen nur im eingestellten Intervall |
| Meldungs-Grenzen | Empfangs-Endpunkt | nur application/json, maximal 256 KB, strikte Zahlenprüfung; ungültige Werte werden als unbekannt gespeichert, nie als Null |
| Installationsskript | Agent | Rechte 700 bei Installation, Deinstallation entfernt Cron-Eintrag und Datei |
| Zwei-Faktor-Authentifizierung | Konto | TOTP (RFC 6238), Fehlversuche fließen in die Sperre ein |
| Sperre nach Fehlversuchen | Login | je IP-Adresse und je Konto, Zeitfenster konfigurierbar |
| Passwort-Reset | Konto | Link einmalig, 60 Minuten gültig; 2FA bleibt aktiv; Dauer-Logins werden beendet |
| Cookies | Sitzung, Dauer-Login, Statusseiten-Passwort | HttpOnly, Secure (https), SameSite=Lax; Statusseiten-Cookie trägt einen HMAC, nie den Passwort-Hash |
| Browser-Richtlinien | alle Seiten | X-Frame-Options SAMEORIGIN, frame-ancestors, X-Content-Type-Options nosniff, Permissions-Policy, HSTS mit includeSubDomains, Referrer-Policy |
| Zielprüfung (SSRF) | Uptime-Monitore, API, Web-Tools, Webhooks | nur öffentliche Hosts nach DNS-Auflösung aller A/AAAA-Einträge; nur http/https, auch bei Weiterleitungen |
| Kommandoaufrufe | Ping-Checks | Ziel als einzelnes, maskiertes Argument; TTL und Timeout als Ganzzahl |
| Uploads | Logos, Favicons, Bilder | Whitelist, Zufallsnamen, SVG-Bereinigung, keine Skriptausführung im Upload-Verzeichnis |
| CSRF | alle Formulare | Token je Sitzung, Vergleich in konstanter Zeit |
Statusseiten dürfen weiterhin per iframe eingebettet werden, wenn Sie das in den Einstellungen der Seite erlauben. Für das Portal selbst gilt das nicht.
Was Sie auf Ihrer Seite tun können
Drei Schritte, die den Schutz vervollständigen.
Zwei-Faktor-Authentifizierung einschalten
Unter Konto, Sicherheit. Dauert eine Minute mit jeder Authenticator-App.
Agent als root per Cron laufen lassen
Nur so kann er das Kernel-Log (Xid) und die Prozesse anderer Nutzer lesen. Das Skript ist kurz und lesbar, prüfen Sie es vor der Installation.
Benachrichtigungskanäle absichern
Webhook-URLs mit eigenem Geheimnis versehen, Teams- und Slack-Hooks nicht weitergeben, Kanäle bei Personalwechsel neu anlegen.
Häufige Fragen
PeakNode für Ihren Anwendungsfall
Monitoring, das Ihre Sicherheitsabteilung durchwinkt
Skript lesen, Monitor anlegen, eine Zeile ausführen.
Jetzt starten