Linux-Magazin 20 Jahre Linux (Vorschau)

Sysadmin
www.linux-magazin.de Open VAS 4 09/2011
84
Abbildung 6: Mit Severity Override lässt sich jede vom Scanner generierte Meldung in der Bedeutung zwischen »Security hole« und »False positive« neu einstufen.
die Sicherheitsrichtlinien der gegebenen
Netzinfrastruktur. Selbst den eigenen
Server im öffentlichen Bereich des Firmennetzes
über das Internet zu scannen,
kann eine Herausforderung werden.
Aus dem Innern des
Zielobjekts
Sehr viel bessere Ergebnisse liefern Open-
VAS-Scans, die die Möglichkeit zum Log in
auf dem Zielhost haben und diesen aus
dem Innern heraus analysieren. Der Log in
sollte nicht über einen Root-Account laufen,
bereits ein normaler Account liefert
genug Informationen zum System und
dessen Schwachstellen.
Auch die User-Passwort-Paare der Zielsysteme
sind ein schützenswertes Gut.
Leider gehen der Open-VAS-Manager und
damit die neuen, über OMP arbeitenden
Open-VAS-Clients damit nicht sonderlich
pfleglich um, da sie die Paare einfach
im Klartext in der SQLite-Datenbank
speichern und so zumindest für den Administrator
des Scanservers zugänglich
machen, der ja nicht zwingend zugleich
der Admin aller Zielsysteme ist. Eine einfache
SQL-Anweisung in der Form
sqlite3 tasks.db 'select * fromU
lsc_credentials;'
gibt Personen mit Zugang zur Datenbank
alle vertraulichen Informationen preis.
Die Zugangsdaten verschlüsselt abzulegen
löst das Problem auch nicht, da während
des Scans die Daten entschlüsselt
verschiebt, was einem Quasi-Einmalzugang
für diesen Scan entspricht.
Das Erzeugen der Schlüsselpaare erfolgt
ähnlich wie bei Open SSH und ist detailliert
unter [15] beschrieben. Doch funktionieren
entgegen der Open-VAS-Dokumentation
derzeit nur DSA- und keine
RSA-Schlüssel [16]. Das macht den Einsatz
des eingebauten Tools zur Paketerzeugung
(unter »Extras | LSC Credentials
Manager«) wenig empfehlenswert.
Nachdem das Schlüsselpaar (hier für
den Nutzer »sshovas«) erzeugt ist, sollwerden
und der Schlüssel innerhalb der
Anwendung hinterlegt wäre.
Auch der klassische Open-VAS-Client
zeigt hier Schwächen, er legt die Zugangsdaten
im Klartext in den lokalen Konfigurationsdateien
».openvasrc« (Tabelle 1)
ab. Davor wird zwar gewarnt, aber die
Klartextablage der Passphrase zum privaten
Schlüssel ist keine gute Alternative.
Optimal wäre, die Daten verschlüsselt
zu speichern in Verbindung mit einem
nicht hinterlegten Masterpasswort oder
gar mit Unterstützung einer Smartcard –
reichlich Entwicklungsbedarf für spätere
Open-VAS-Versionen.
Wichtig ist dabei, dass der Open-VAS-
Client eine geänderte Konfiguration in
den Zugangsdaten immer nur beim Scan
des Zielobjekts in der Datei aktualisiert.
Denn selbst wenn der Admin vor dem
Schließen des Programms die Zugangsdaten
löscht, verbleiben diese in der Konfigurationsdatei.
Sicherheit durch Schlüssel
Um Zugangsdaten möglichst einfach auf
mehrere Systeme zu verteilen und die
Problematik der zentralen Zugangsdaten
zu entschärfen, bieten sich asymmetrische
Schlüssel an. Der öffentliche
Schlüssel kommt auf die Zielsysteme.
Der zugrunde liegende Account sollte
ein deaktiviertes Passwort haben, sodass
allein der auf dem Client verbleibende
private Schlüssel den Zugang ermöglicht.
Da die Passphrase sich nur im Klartext
hinterlegen lässt, verzichtet man gleich
darauf. Zum Schutz des privaten Schlüssels
bietet sich derzeit an, ihn gesichert
aufzubewahren, etwa auf USB-Stick, oder
ihn nochmals mit Truecrypt, PGP oder
Encryptfs zu verschlüsseln.
Da der passende öffentliche Schlüssel
auch auf dem Zielsystem (in »~./.ssh/
authorized_keys2«) hinterlegt sein muss,
kann der Admin des Zielsystems den Zugriff
durch Hinzufügen oder Entfernen
des öffentlichen Schlüssels steuern. Er
könnte sogar durch ein spezielles Open-
VAS-Plugin den Zugang auf einen einmaligen
Scan beschränken, indem es nach
dem Scan die Schlüsseldatei selbst mit
pread(cmd: "/bin/mv", argv: make_listU
("mv","~/.ssh/authorized_keys2",U
"~/.ssh/authorized_keys2.bak"));
Listing 4: Meldung nach internem
Login
01 Reported by NVT "SSH Authorization"
(1.3.6.1.4.1.25623.1.0.90022):
02
03 It was possible to login using the SSH credentials
supplied.
04 Hence local security check are enabled.
Abbildung 7: Auswirkungen von Severity Override auf einen Bericht.