ServerSec installieren

1. Voraussetzungen prüfen

Benötigt werden ein 64-Bit-Linux-Rechner, Administratorzugriff, Python 3 sowie Docker Engine mit dem Compose-Plugin. Das Paket muss zur Architektur des Docker-Rechners passen: amd64 für übliche Intel-/AMD-Rechner oder arm64 für entsprechende ARM-Rechner. Die Zielserver können eine andere unterstützte Architektur haben.

Als Startempfehlung für eine kleine Umgebung: zwei CPU-Kerne, 4 GB RAM und mindestens 10 GB freier Speicher, zusätzlich Platz für Berichte und Sicherungen. Dies ist eine Planungsgröße, keine gemessene Mindestanforderung für jede Umgebung.

Docker bei Bedarf nach der offiziellen Ubuntu-Anleitung installieren. Vorhandene Docker-Installationen nicht durch ein fremdes Installationsskript ersetzen.

python3 --version
sudo docker info
sudo docker compose version

Der Verwaltungsrechner benötigt HTTPS-Zugriff zum Lizenzdienst auf serversec.de und zu den Quellen für Werkzeug- und Schwachstellendaten. Zielserver benötigen SSH und Python 3; für den CVE-Scan lädt der Verwaltungsrechner die Daten. Eine dauerhaft vollständig offline betriebene Installation ist derzeit nicht vorgesehen.

2. Paket beziehen und prüfen

Den persönlichen Downloadlink des Anbieters über HTTPS öffnen und Paket sowie Prüfsummendatei auf den Linux-Rechner übertragen, beispielsweise per SFTP. Der Link und die passende Architektur werden mitgeliefert. Keine Installationsbefehle direkt aus einem Downloadstream ausführen.

Beispiel für Version 0.7.0 auf amd64; bei einer anderen Ausgabe die Dateinamen entsprechend ersetzen:

sha256sum -c serversec-0.7.0-linux-amd64.tar.gz.sha256
tar -xzf serversec-0.7.0-linux-amd64.tar.gz
cd serversec-0.7.0-linux-amd64

Die Prüfung muss „OK“ melden. Die erwartete Prüfsumme zusätzlich mit der separat vom Anbieter übermittelten Angabe vergleichen. Eine Prüfsumme aus derselben Downloadquelle allein bestätigt keine unabhängige Herausgeberidentität. Bei einer Abweichung die Installation abbrechen.

Das Paket enthält die Anwendung bereits als Containerimage. Kunden müssen nichts kompilieren und benötigen keinen Quellrepository-Zugang.

3. Starten

Für die Benutzung von anderen Rechnern im eigenen Netzwerk die feste LAN-IP des Verwaltungsrechners einsetzen. Beispiel: 192.168.1.20.

sudo ./install.sh --address 192.168.1.20

Ohne --address bleibt ServerSec ausschließlich auf dem Verwaltungsrechner unter 127.0.0.1 erreichbar. Mit --port 8121 lässt sich ein anderer freier Port ab 1024 wählen. Der Standard ist HTTPS-Port 8120.

Der Installer prüft Paket und Architektur, importiert das Image und startet ausschließlich den eigenen ServerSec-Stack. Er installiert Docker nicht, ändert keine Firewall und überschreibt keine bestehende Installation. Die beiden Container laufen als UID 10001 ohne root und ohne Docker-Socket.

Nur im vertrauenswürdigen LAN oder über VPN zugänglich machen. Keine Router-Portweiterleitung ins Internet einrichten. Docker-Portfreigaben können UFW-Regeln umgehen; die konkrete Bindung an die LAN-Adresse und vorgeschaltete Netzregeln müssen passen. Hinweise von Docker

4. Zertifikat und ersten Zugang einrichten

Im Beispiel https://192.168.1.20:8120/ öffnen. Beim ersten Start erstellt ServerSec ein lokales Zertifikat. Dessen SHA-256-Fingerabdruck auf dem Verwaltungsrechner anzeigen:

sudo docker compose exec -T web openssl x509 -in /data/tls/cert.pem -noout -fingerprint -sha256

Den Wert mit dem im Browser angezeigten Zertifikat vergleichen, bevor Sie ihm vertrauen und Zugangsdaten eingeben. Für den Dauerbetrieb kann der Administrator ein passendes vertrauenswürdiges Zertifikat als data/tls/cert.pem und Schlüssel als data/tls/key.pem mit Leserecht für UID 10001 bereitstellen und den Webdienst neu starten.

Den einmaligen Einrichtungscode lokal anzeigen:

sudo docker compose exec -T web cat /data/bootstrap.token

Diesen Code in der Einrichtungsmaske verwenden und einen eigenen Benutzernamen sowie ein Passwort mit mindestens zwölf Zeichen festlegen. Der Code wird danach gelöscht. Code, private Schlüssel und Passwörter nicht in Supportprotokolle kopieren.

5. Automatische Testphase prüfen

Beim ersten erfolgreichen Online-Start nach der Installation aktiviert ServerSec automatisch eine Testphase für fünf Hosts. Sie läuft ab der signierten Erstfreigabe genau sieben Tage; ein zusätzlicher Klick oder Lizenzschlüssel ist nicht nötig. Der Download allein startet keine Frist. Die Testzeit läuft unabhängig davon weiter, wann Sie den ersten Server anbinden.

Das genaue Ende steht unter „Lizenz verwalten“ und im Seitenmenü. Neustarts, erneute Anmeldungen und normale Updates verlängern die Testphase nicht. Eine vorhandene Kauflizenz wird nicht ersetzt.

Der Verwaltungsrechner muss serversec.de über HTTPS erreichen und eine korrekte Uhrzeit haben. Ist die Freigabe zunächst nicht möglich, zeigt ServerSec die ausstehende Aktivierung und versucht es automatisch erneut. Ohne gültige signierte Freigabe bleiben die Fachansichten gesperrt; eine lokale Ersatzerlaubnis wird nicht erzeugt. Nach Beheben der Verbindung können Administratoren „Aktivierung erneut versuchen“ wählen.

Nach sieben Tagen benötigen Sie eine freigeschaltete Kauflizenz. Diese tragen Administratoren unter „Lizenz verwalten“ ein. Es werden keine Zahlungsdaten verlangt und es entsteht keine automatische Verlängerung.

Die Anwendung erneuert ihre signierte Freigabe regelmäßig. Eine Freigabe gilt höchstens 72 Stunden und nie länger als die Testphase/Lizenz selbst. Nach deren Ablauf bleibt die Lizenzverwaltung erreichbar; Arbeitsoberfläche und neue Prüfungen werden gesperrt. Gespeicherte Daten bleiben erhalten. Eine Wiederherstellung darf nicht als parallele zweite Lizenzinstanz betrieben werden.

6. Ersten Server prüfen

„Server anbinden“ öffnen, Adresse und SSH-Zugang eintragen und den angezeigten Hostschlüssel mit dem Zielserver vergleichen. Ein eigenes Prüfkonto mit SSH-Schlüssel ist sinnvoll. Im Anbindungsdialog gibt es kopierbare Ubuntu-/Debian-Befehle.

Zunächst ohne sudo anbinden. Für umfassendere Konfigurations- und Logdaten kann ein Administrator gezielt weitergehende Rechte vergeben. Fehlende Rechte werden als Prüflücken ausgewiesen.

Einen Vollscan starten, anschließend Befunde und Prüfabdeckung ansehen. Der erste Scan kann wegen des Datenbankdownloads länger dauern. Ein unauffälliger Bericht beweist keine Angriffsfreiheit. Empfehlungen werden nicht automatisch ausgeführt.

Im Tool führt „Hilfe“ durch Einrichtung, Ergebnisbewertung und Betrieb. Bereichsrechte bestimmen, welche Arbeitsansichten und Aktionen sichtbar sind.

Sicherung und Betrieb

Im Installationsordner:

sudo docker compose ps
sudo docker compose exec -T web python -m app.backup
sudo docker compose logs --tail=80 web worker

Sicherungen liegen unter data/backups/. Sie enthalten sensible Daten einschließlich Entschlüsselungsschlüssel. Geschützt auf einen getrennten Datenträger kopieren; nur im gleichen Datenordner aufbewahrte Sicherungen schützen nicht gegen dessen Verlust.

Für eine Wiederherstellung werden die gesicherte Datenbank und master.key gemeinsam benötigt. Auch Lizenzidentität, Archive und TLS-Dateien müssen erhalten bleiben. Eine Rückkehr zu einer älteren Anwendung kann nach Datenbankänderungen eine vollständige passende Datensicherung erfordern. Wiederherstellungen und Anwendungsupdates deshalb anhand des konkreten Releasepakets mit dem Anbieter planen. Der Erstinstaller ist kein Updatewerkzeug.

Werkzeugupdates für Trivy und Lynis sind in „Werkzeuge“ möglich; sie aktualisieren nicht die ServerSec-Anwendung. Für Diagnosemeldungen vor Weitergabe Serveradressen und andere vertrauliche Inhalte prüfen.

Bei Startproblemen sudo docker compose ps und die letzten Protokollzeilen prüfen. Ist der Port belegt, vor einer neuen Installation einen freien Port wählen. Bei „bestehende Installation erkannt“ bleiben Dateien unangetastet; den ursprünglichen Installationsordner und dessen .env verwenden. Der normale Startbefehl einer bereits eingerichteten Installation lautet:

sudo docker compose up -d --no-build --pull never