PDF-Version, 277 Seiten, 17 MByte, Stand 26.1

Transcription

Greenbone Networks GmbH
Neuer Graben 17
49074 Osnabrück
Germany
http://www.greenbone.de
Stand: GOS 3.1.22, 26. Januar 2016
Dies ist das Anwenderhandbuch zum Greenbone Security Manager mit Greenbone OS
(GOS) Version 3.1. Aufgrund der zahlreichen funktionalen und auch sonstigen Unterschiede
zwischen GOS 3.1 und den vorherigen Versionen ist dieses Handbuch nicht für die Verwendung mit älteren Versionen vorgesehen.
Der Greenbone Security Manager wird fortlaufend weiterentwickelt. Dieses Anwenderhandbuch bemüht sich, immer den aktuellen Softwarestand zu dokumentieren. Dennoch
kann es sein, dass neueste Funktionen noch nicht in dem Handbuch berücksichtigt sind.
Haben Sie Anmerkungen zu Ergänzungen oder Fehlerkorrekturen in diesem Handbuch,
dann senden Sie bitte eine E-Mail an den Support:
(mailto:[email protected]).
Mitwirkende dieses Handbuchs sind:
• Greenbone Networks GmbH
• OpenSource Training Ralf Spenneberg
• Alexander Rau, arX IT Services
Die Urheberrechte für dieses Handbuch liegen bei dem Unternehmen Greenbone Networks GmbH.
Greenbone und das Greenbone-Logo sind eingetragene Warenzeichen von Greenbone Networks
GmbH. Weitere in diesem Handbuch verwendete Warenzeichen und eingetragene Warenzeichen sind
Eigentum der jeweiligen Besitzer und dienen lediglich erläuternden Zwecken.
Inhaltsverzeichnis
1
Einführung
1
2 GSM Übersicht
2.1 Enterprise-Klasse (GSM 5300 / 6400) .
2.2 Midrange-Klasse (GSM 400/600/650)
2.3 SME-Klasse (GSM 100) . . . . . . . . . .
2.4 Sensoren GSM 25 / 25V . . . . . . . . .
2.5 GSM ONE . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Ich möchte ...
4 Inbetriebnahme
4.1 Die Anmeldung als Admin . . . . . . .
4.2 Grundkonfiguration . . . . . . . . . . .
4.2.1
Tastaturlayout . . . . . . . . .
4.2.2 Netzwerk . . . . . . . . . . . .
4.3 Management Netzwerkschnittstelle
4.4 DNS Konfiguration . . . . . . . . . . .
4.5 Kennwortänderung . . . . . . . . . . .
4.6 Einstellung der Web-Oberfläche . . .
4.6.1
Web-Administrator . . . . . .
4.6.2 Zertifikat . . . . . . . . . . . .
4.6.3 Selbstsigniertes Zertifikat . .
4.7 Aktivierungsschlüssel . . . . . . . . .
4.8 Bereitschaft . . . . . . . . . . . . . . .
3
4
4
5
6
6
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
12
12
14
14
14
15
15
16
16
16
17
5 Die Kommandozeilenschnittstelle (CLI)
5.1 Kommandozeile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Einstellungen bearbeiten . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Benutzer und Kennworte . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1
Kennwortänderung des Admin . . . . . . . . . . . . . . . . .
5.3.2 Erzeugen eines Web-Administrators (Scan-Administrator)
5.3.3 Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1
Selbstsignierte Zertifikate . . . . . . . . . . . . . . . . . . . .
5.4.2 Zertifikat einer externen Zertifizierungsstelle . . . . . . . .
5.5 Geräteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.1
Reboot und Herunterfahren der Appliance . . . . . . . . . .
5.5.2 Netzwerkkonfiguration . . . . . . . . . . . . . . . . . . . . . .
5.5.3 Experten Netzwerkkonfiguration . . . . . . . . . . . . . . . .
5.6 Fernzugri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.1
HTTPS Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.2 SSH-Zugang . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
20
20
21
21
21
22
23
25
25
25
29
32
32
33
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
33
33
34
35
35
35
35
36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
41
42
43
44
44
45
45
47
47
50
51
51
53
7 Scanning
7.1
Einfacher Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1
Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.2
Advanced Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.3
Manuelle Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1
Lesen des Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Authentifizierter Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1
Voraussetzungen auf Zielsystemen mit Windows . . . . . . . . . . .
7.4.2 Konfigurieren eines Linux/UNIX-Kontos für authentifizierte Scans .
7.4.3 Voraussetzungen auf Zielsystemen mit ESXi . . . . . . . . . . . . . .
7.4.4 Autogenerate Credentials . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 Geplanter Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 Notizen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.1
Notizen anlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.2 Verallgemeinerung der Notizen . . . . . . . . . . . . . . . . . . . . . .
7.6.3 Notizen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.7 Overrides und False Positives . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.7.1
Was ist ein False Positive? . . . . . . . . . . . . . . . . . . . . . . . . .
7.7.2
Erzeugen eines Override . . . . . . . . . . . . . . . . . . . . . . . . . .
7.7.3
Ein- und Ausschalten von Übersteuerungen . . . . . . . . . . . . . .
7.7.4
Automatische False-Positives (AutoFP) . . . . . . . . . . . . . . . . .
7.8 Scan von Webanwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
57
57
59
60
68
71
71
71
73
80
81
82
83
85
85
86
87
87
88
88
88
89
90
8 Berichte
8.1 Delta-Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Report Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1
Import weiterer Report Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
92
92
95
9 Compliance und spezielle Scans
97
5.7
5.8
5.9
5.6.3 OpenVAS Management Protocol (OMP) . . . . . . . . . . .
Upgrade und Feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.1
Upgrade des Systems . . . . . . . . . . . . . . . . . . . . . .
5.7.2
Feed Synchronisation . . . . . . . . . . . . . . . . . . . . . .
5.7.3
Proxy Konfiguration . . . . . . . . . . . . . . . . . . . . . . .
Verwaltung der Datenbank und der Scanner . . . . . . . . . . . . .
5.8.1
Datenbankverwaltung . . . . . . . . . . . . . . . . . . . . .
5.8.2 Weitere Schwachstellenscanner . . . . . . . . . . . . . . .
Überwachung und Fehlersuche . . . . . . . . . . . . . . . . . . . . .
5.9.1
Fehlersuche und Überwachung der Netzwerkfunktionen
6 Betrieb
6.1 Benutzerverwaltung . . . . . . . . . . . . . . . . .
6.1.1
Anlegen und Verwaltung der Benutzer .
6.2 Upgrade . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1
Prüfen der aktuellen Version . . . . . . .
6.2.2 Durchführung des Patch-Level Upgrades
6.2.3 Release Upgrade . . . . . . . . . . . . . . .
6.2.4 Verwendung eines Proxies . . . . . . . . .
6.3 Sicherung und Wiederherstellung . . . . . . . . .
6.3.1
Backup des gesamten Systems . . . . . .
6.3.2 Snapshot des Systems . . . . . . . . . . .
6.3.3 Backup der Userdata mit USB-Stick . . .
6.3.4 Backup der Userdata via SSH . . . . . . .
6.4 Airgap Update . . . . . . . . . . . . . . . . . . . . .
6.4.1
Airgap via USB Stick . . . . . . . . . . . . .
6.4.2 Airgap via FTP . . . . . . . . . . . . . . . .
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9.1
9.2
9.3
9.4
9.5
9.6
Allgemeine Policy Scans . . . . . . . . . . . . . . . . . . . . . .
9.1.1
File Content . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.2
Registry Content . . . . . . . . . . . . . . . . . . . . . .
9.1.3
File Checksums . . . . . . . . . . . . . . . . . . . . . .
9.1.4
CPE-basiert Richtlinien prüfen . . . . . . . . . . . . .
Standardrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1
IT-Grundschutz . . . . . . . . . . . . . . . . . . . . . .
9.2.2 PCI DSS . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spezielle Richtlinien . . . . . . . . . . . . . . . . . . . . . . . .
9.3.1
Onlineprüfung Mailserver . . . . . . . . . . . . . . . .
TLS-Karte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4.1
Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . .
9.4.2 Prüfung TLS-Nutzung . . . . . . . . . . . . . . . . . . .
9.4.3 Export der Scan-Ergebnisse . . . . . . . . . . . . . . .
Conficker-Suche . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.5.1
Suchmethoden für Schwachstellen und Befall . . . .
9.5.2 Suche nach Schwachstelle und Conficker ausführen
OVAL System Characteristics . . . . . . . . . . . . . . . . . . .
9.6.1
OVAL Adoption Program . . . . . . . . . . . . . . . . .
9.6.2 Scan-Daten als OVAL-SCs einsammeln . . . . . . . .
9.6.3 OVAL-SC exportieren . . . . . . . . . . . . . . . . . . .
9.6.4 Beispiel: OVAL-SC für ovaldi verwenden . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 97
. 98
. 100
. 102
. 106
. 113
. 113
. 124
. 126
. 126
. 127
. 127
. 127
. 128
. 129
. 129
. 129
. 130
. 131
. 132
. 132
. 133
10 Benachrichtigungen
11 GUI-Konzepte
11.1 Icons . . . . . . . . . . . . . . . . . .
11.2 Charts . . . . . . . . . . . . . . . . .
11.3 Powerfilter . . . . . . . . . . . . . .
11.3.1 Komponenten . . . . . . .
11.3.2 Speichern und Verwalten
11.4 Tags . . . . . . . . . . . . . . . . . .
139
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
143
. 143
. 144
. 145
. 145
. 149
. 150
12 Scan-Konfiguration
12.1 Erzeugen einer neuen Scan-Konfiguration
12.2 Scanner Preferences . . . . . . . . . . . . .
12.2.1 Allgemeine Preferences . . . . . .
12.2.2 Ping Preferences . . . . . . . . . . .
12.2.3 Nmap NASL Preferences . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13 Scanner
13.1 w3af Scanner . . . . . . . . . . . . . . .
13.1.1 w3af Scankonfiguration . . . .
13.1.2 w3af Scan-Aufgabe . . . . . . .
13.2 PaloAlto Scanner . . . . . . . . . . . . .
13.2.1 PaloAlto Scanner Konfiguration
13.2.2 PaloAlto Bericht . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
159
. 159
. 160
. 161
. 161
. 162
. 163
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
151
153
155
155
157
157
14 Alternative Oberflächen
167
14.1 IT-Schwachstellenampel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
15 Benutzer- und Rechteverwaltung
15.1 Benutzerverwaltung . . . . . . . . . . . . . . . .
15.1.1 Anlegen und Verwaltung der Benutzer
15.1.2 Gleichzeitige Anmeldung . . . . . . . . .
15.1.3 Benutzerrollen . . . . . . . . . . . . . . .
15.1.4 Gastanmeldung . . . . . . . . . . . . . .
15.1.5 Super Admin . . . . . . . . . . . . . . . .
15.1.6 Gruppen . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
171
171
171
173
173
175
176
179
iii
15.1.7
15.1.8
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Zentrale Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
16 OpenVAS Management Protokoll (OMP)
16.1 Aktivieren des OMP Protokolls . . . . . . . . . . . . . . . . . . . . . . .
16.2 Zugri mit omp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2.1 Konfiguration des Clients . . . . . . . . . . . . . . . . . . . . .
16.2.2 Start eines Scans . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2.3 Aktualisieren Sie das Ziel einer änderbaren Aufgabe mit OMP
16.2.4 Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17 MySettings
185
. 185
. 185
. 186
. 186
. 188
. 189
191
18 SecInfo Management
18.1 Secinfo Portal . . . . . . . . . . . . . . . . . . .
18.2 Network Vulnerability Tests . . . . . . . . . . .
18.3 Security Content Automation Protocol (SCAP)
18.3.1 CVE . . . . . . . . . . . . . . . . . . . . .
18.3.2 CPE . . . . . . . . . . . . . . . . . . . . .
18.3.3 OVAL . . . . . . . . . . . . . . . . . . . .
18.3.4 CVSS . . . . . . . . . . . . . . . . . . . .
18.4 DFN-CERT . . . . . . . . . . . . . . . . . . . . .
18.5 CERT-Bund . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
193
. 193
. 195
. 195
. 196
. 196
. 198
. 200
. 202
. 202
19 Asset Management
203
19.1 Prognose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
20 Performanz
20.1 Scan Performanz . . . . . . . . . . . . . . .
20.1.1 Wahl der Port-Liste für einen Scan
20.1.2 Scan-Konfiguration . . . . . . . . .
20.1.3 Tasks . . . . . . . . . . . . . . . . . .
20.2 Backend Performanz . . . . . . . . . . . . .
20.3 Appliance Performanz . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
205
. 205
. 205
. 207
. 207
. 208
. 208
21 Master und Slave Setups
21.1 Anbindung eines Slaves . . . . . . . .
21.2 Sensor . . . . . . . . . . . . . . . . . . .
21.2.1 Manuelle Synchronisation . .
21.2.2 Aktualisieren der Sensoren .
21.2.3 Kommunikation der Sensoren
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
211
. 212
. 212
. 213
. 214
. 214
22 Integration mit anderen Systemen
22.1 Integration von Drittherstellern . . . . . . . . . . .
22.1.1 OSP Scanner . . . . . . . . . . . . . . . . . .
22.2 Verinice . . . . . . . . . . . . . . . . . . . . . . . . . .
22.2.1 IT Security Management . . . . . . . . . . .
22.2.2 IT-Grundschutz . . . . . . . . . . . . . . . .
22.3 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.3.1 Konfiguration des GSM-Nutzers . . . . . .
22.3.2 Installation des Plugins . . . . . . . . . . . .
22.3.3 Konfiguration des Plugins . . . . . . . . . .
22.4 Sourcefire Defence Center . . . . . . . . . . . . . . .
22.4.1 Installation des Report Export Plugins . . .
22.4.2 Konfiguration des Host-Input-API-Clients
22.4.3 Konfiguration des Alerts auf dem GSM . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
215
. 215
. 215
. 216
. 217
. 220
. 223
. 223
. 223
. 224
. 226
. 227
. 228
. 228
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23 OpenVAS Scanner Protokoll
231
23.1 Aktivierung zusätzlicher OSP-Scanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
iv
23.2 Wie man einen OSP Wrapper baut . . . . . . . . . . . . . . .
23.2.1 Die Aufgabe: debsecan als OSP-Scanner . . . . . .
23.2.2 Die Basis: ospd . . . . . . . . . . . . . . . . . . . . . .
23.2.3 Das Grundgerüst für den neuen OSP Scanner . . . .
23.2.4 Verbindung scha en zwischen debsecan und OSP
23.2.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.2.6 Erste Fehlerbehandlung einbauen . . . . . . . . . .
24 Setup-Handbücher
24.1 GSM ONE . . . . . . . . . . . . . . . . . . . .
24.1.1 Voraussetzungen . . . . . . . . . .
24.1.2 Import der virtuellen Appliance . .
24.1.3 Anmeldung an der Weboberfläche
24.1.4 GSM ONE Fehlersuche . . . . . . .
24.2 GSM 25V . . . . . . . . . . . . . . . . . . . .
24.2.1 Voraussetzungen . . . . . . . . . .
24.2.2 Import der virtuellen Appliance . .
24.3 GSM 25 . . . . . . . . . . . . . . . . . . . . .
24.3.1 Installation . . . . . . . . . . . . . .
24.3.2 Serielle Schnittstelle . . . . . . . .
24.3.3 Einschalten . . . . . . . . . . . . . .
24.4 GSM 100 . . . . . . . . . . . . . . . . . . . . .
24.4.1 Installation . . . . . . . . . . . . . .
24.4.3 Einschalten . . . . . . . . . . . . . .
24.5 GSM 500/510/550 . . . . . . . . . . . . . . .
24.5.1 Installation . . . . . . . . . . . . . .
24.5.3 Einschalten . . . . . . . . . . . . . .
24.6 GSM 400/600/650 . . . . . . . . . . . . . .
24.6.1 Installation . . . . . . . . . . . . . .
24.6.3 Einschalten . . . . . . . . . . . . . .
24.7 GSM 5300/6400 . . . . . . . . . . . . . . . .
24.7.1 Installation . . . . . . . . . . . . . .
24.7.3 Einschalten . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 231
. 232
. 233
. 234
. 237
. 238
. 239
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
241
. 241
. 241
. 242
. 244
. 244
. 244
. 245
. 246
. 247
. 248
. 248
. 249
. 250
. 250
. 250
. 251
. 251
. 251
. 252
. 252
. 253
. 253
. 254
. 254
. 254
. 255
. 255
. 255
. 256
. 256
. 257
. 257
25 CLI Kommandoreferenz
259
26 CLI Einstellungsreferenz
263
27 Häufig gestellte Fragen
27.1 Was ist der Unterschied zwischen Scan-Sensor und Scan-Slave? . . . . . . .
27.2 Scan-Vorgang sehr langsam . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27.3 Scan löst Alarm bei anderen Sicherheits-Tools aus . . . . . . . . . . . . . . . .
27.4 Auf gescannten Zielsystemen erscheint VNC Dialog . . . . . . . . . . . . . . .
27.5 Nach Factory Reset funktioniert weder Feed-Update noch System-Upgrade
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
267
. 267
. 267
. 267
. 268
. 268
28 Glossar
28.1 Host . . . . . . . . . . . . .
28.2 Quality of Detection (QoD)
28.3 Schweregrad . . . . . . . .
28.4 Solution Type . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
269
. 269
. 269
. 271
. 271
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
v
Stichwortverzeichnis
vi
273
KAPITEL 1
Einführung
Vulnerability Management ist ein Kernelement der modernen IT-Compliance. Als IT-Compliance wird
die Einhaltung der gesetzlichen, unternehmensinternen und vertraglichen Regelungen bezüglich der
IT-Infrastruktur bezeichnet. Hierbei betrachtet sie hauptsächlich die Informationssicherheit, die Verfügbarkeit, die Speicherung und den Datenschutz. Unternehmen wie Behörden müssen in diesen Bereichen vielfältige rechtliche Verpflichtungen erfüllen.
Die Überwachung und Verbesserung der IT-Sicherheit ist ein ständiger Prozess, der mindestens aus
den drei folgenden Schritten besteht:
• Feststellung des aktuellen Zustands
• Ergreifen von Maßnahmen zur Verbesserung
• Überprüfung der Maßnahme
Der Greenbone Security Manager unterstützt Unternehmen und Behörden durch ein automatisiertes
und integriertes Vulnerability Assessment und Vulnerability Management. Seine Aufgabe ist die Erkennung der Schwachstellen und Sicherheitslücken, bevor dies einem potentiellen Angreifer gelingt.
Der Greenbone Security Manager ermöglicht dies aus unterschiedlichen Perspektiven des Angreifers:
Extern Hierbei greift der GSM von Außen auf das Netz zu. Der GSM kann so schlecht konfigurierte
Firewall-Systeme identifizieren.
DMZ Hier kann der GSM die tatsächlich vorhandenen Schwächen ermitteln. Diese können von einem
Angreifer ausgenutzt werden, wenn er die Firewall überwindet.
Intern Viele Angri e werden von Innen durch einen Innentäter, mithilfe von Social Engineering oder
mittels eines Wurms durchgeführt. Diese Sicht ist daher für die Beurteilung der Sicherheit der
IT-Infrastruktur besonders wichtig.
Für DMZ und Intern wird zwischen authentifizierten und nicht-authentifizierten Prüfungen unterschieden. Bei authentifizierten Prüfungen wird dem Scanner eine Zugangsberechtigung mitgegeben
und kann so auch Schwachstellen in Anwendungen finden die nicht als Dienst arbeiten aber ein hohes
Gefährdungspotenzial besitzen. Darunter fallen zum Beispiel Web-Browser, Oce-Anwendungen
oder PDF-Betrachter.
Da täglich neue Bedrohungen hinzukommen, ist die regelmäßige Aktualisierung und Prüfung der Systeme erforderlich. Der Greenbone Security Feed stellt sicher, dass der GSM regelmäßig mit neuen
Test-Routinen versorgt wird und auch die neuen Bedrohungen zuverlässig erkennt. Greenbone wertet hierzu die CVE-Meldungen 1 und die Mitteilungen der Hersteller aus und entwickelt täglich neue
zertifizierte und geprüfte Testroutinen. Der GSM erhält diese Testroutinen automatisch über den verschlüsselten Greenbone Security Feed.
So erhalten die IT-Verantwortlichen durch einen Scan mit einem Greenbone Security Manager eine Liste von Schwachstellen, die in dem Netzwerk gefunden wurden. Speziell wenn bisher kein Schwachstellen Management etabliert wurde, ist diese Liste häufig sehr umfangreich. Für die Auswahl der
1
Das Common Vulnerability and Exposures (CVE) Projekt ist ein herstellerunabhängiges Forum für die Identifikation und
Verö entlichung von neuen Schwachstellen.
1
Greenbone Security Manager with Greenbone OS 3.1, Release 3.1.22
Maßnahmen ist eine Bewertung der Schwachstellen unumgänglich. Am wichtigsten sind die Maßnahmen, welche die kritischsten Risiken abwehren und die entsprechenden Sicherheitslücken schließen.
Hier nutzt der GSM das Common Vulnerability Scoring System (CVSS). CVSS ist ein Industriestandard
für die Klassifizierung und Bewertung von Schwachstellen. Es hilft die Maßnahmen zu priorisieren.
Um einer Schwachstelle zu begegnen existieren grundsätzlich zwei Möglichkeiten:
1. Entfernen der Schwachstelle durch eine Aktualisierung der Software, Entfernen der Komponente oder eine veränderte Konfiguration.
2. Einfügen einer Regel in der Firewall oder dem Intrusion Prevention System (Virtual Patching).
Als Virtual Patching wird die scheinbare Behebung des Fehlers durch eine zusätzliche Komponente
bezeichnet. Die tatsächliche Sicherheitslücke bleibt bestehen. Daher kann ein Angreifer bei Ausfall
der zusätzlichen Komponente oder durch Nutzung eines alternativen Wegs möglicherweise weiterhin
die Sicherheitslücke ausnutzen. Ein tatsächlicher Patch/Update der betro enen Software ist daher
einem virtuellen Patch immer vorzuziehen.
Auch bei der Überprüfung der umgesetzten Maßnahmen unterstützt der Greenbone Security Manager. Mit seiner Hilfe können die IT-Verantwortlichen den aktuellen Zustand der IT-Security dokumentieren, Änderungen erkennen und diese in Berichten zusammenfassen. Für die Kommunikation mit
dem Management bietet der GSM die Abstraktion der technischen Details in einfachen Grafiken oder
in Form einer Verkehrsampel, die den Zustand in Rot, Gelb und Grün einteilt. So kann der IT-SecurityProzess einfach visualisiert werden.
2
Kapitel 1. Einführung
KAPITEL 2
GSM Übersicht
Der Greenbone Security Manager ist eine dedizierte Appliance für das Schwachstellen Scanning
und -Management. Hierbei handelt es sich um eine speziell entwickelte Plattform optimiert für das
Schwachstellen Management. Sie wird in unterschiedlichen Leistungsstufen angeboten.
3
2.1 Enterprise-Klasse (GSM 5300 / 6400)
Die GSM 5300 und GSM 6400 Appliances sind für den Einsatz in großen Unternehmen und Behörden konzipiert. Die GSM 6400 kann Sensoren in bis zu 50 Sicherheitszonen steuern und wird für bis
zu 50.000 überwachten IP-Adressen empfohlen. Die GSM 5300 kann Sensoren in bis zu 30 Sicherheitszonen steuern und wird für bis zu 30.000 überwachten IP-Adressen empfohlen. Die Appliances
können jedoch auch selbst als Slave-Sensor durch einen weiteren Master gesteuert werden.
Abb. 2.1: Die GSM 6400 unterstützt für bis zu 50.000 IP-Adressen.
Die Appliances der Enterprise-Klasse werden im 19-Zoll-Gehäuse mit 2 Bauhöhen für die einfache Integration in das Rechenzentrum ausgeliefert. Sie verfügen für die einfache Installation und Überwachung über ein zweizeiliges LCD-Display mit 16 Zeichen je Zeile. Für den dauerhaften Betrieb besitzen
sie redundante Netzteile, Festplatten und Lüfter, die im laufenden Betrieb ausgetauscht werden können.
Für die Verwaltung der Systeme steht neben einem Out-of-Band-Management-Ethernet-Port auch
eine serielle Schnittstelle zur Verfügung. Die serielle Schnittstelle ist als Cisco-kompatibler ConsolePort ausgeführt.
Für die Anbindung der zu überwachenden Systeme können beide Appliances mit bis zu drei Modulen
ausgestattet werden. Die folgenden Module können hierbei in einer beliebigen Kombination genutzt
werden:
• 8 Port Gigabit Ethernet 10/100/1000 Base-TX (Kupfer)
• 8 Port Gigabit Ethernet SFP (Small-Formfactor-Pluggable)
• 2 Port 10-Gigabit Ethernet XFP
Je Port können bis zu 256 VLANs konfiguriert und verwaltet werden.
2.2 Midrange-Klasse (GSM 400/600/650)
Der GSM 400, GSM 600 und GSM 650 sind für Unternehmen und Behörden mittlerer Größe als auch
große Aussenstellen konzipiert worden. Der GSM 650 kann Sensoren in bis zu 12 verschiedenen
Sicherheitszonen verwalten und bis zu 10.000 IP-Adressen überwachen. Der GSM 600 unterstützt
ebenfalls Sensoren in bis zu 12 Sicherheitszonen und wird empfohlen für bis zu 6.000 überwachten
IP-Adressen. Der GSM 400 kann 2 Sensoren steuern und ist ausgelegt für bis zu 2.000 überwachte IP-Adressen. Die Appliances können alle auch als Slave Sensor eines anderen Masters eingesetzt
werden.
Neben den aktuellen GSM 400, GSM 600 und GSM 650 Appliances unterstützt Greenbone auch noch
ältere Appliances dieser Klasse vollständig. Die GSM 500, GSM 510 und GSM 550 Appliances wurden
jedoch 2014 durch die aktuellen Modelle ersetzt.
Die Appliances der Midrange-Klasse werden im 19-Zoll-Gehäuse mit 1 Bauhöhe für die einfache Integration in das Rechenzentrum ausgeliefert. Sie verfügen über ein zweizeiliges LCD-Display mit 16
4
Kapitel 2. GSM Übersicht
Abb. 2.2: Die GSM 650 unterstützt für bis zu 10.000 IP-Adressen.
Zeichen je Zeile. Für den dauerhaften Betrieb besitzen sie redundante Lüfter. Ein Austausch im Betrieb
ist jedoch nicht möglich.
Für die Verwaltung der Systeme steht neben einem Management-Ethernet-Port auch eine serielle
Schnittstelle zur Verfügung. Die serielle Schnittstelle ist als Cisco-kompatibler Console-Port ausgeführt.
Für die Anbindung der zu überwachenden Systeme verfügen beide Appliances über insgesamt 8 Ports,
die fest konfiguriert und folgendermaßen ausgeführt sind:
• 6 Port Gigabit Ethernet 10/100/1000 Base-TX (Kupfer)
• 2 Port Gigabit Ethernet SFP (Small-Formfactor-Pluggable)
Eine modulare Anpassung der Ports ist nicht möglich. Je Port können bis zu 128 VLANs konfiguriert
und verwaltet werden. Einer dieser Ports wird auch als Management Port genutzt.
2.3 SME-Klasse (GSM 100)
Der GSM 100 ist für kleinere Unternehmen und Behörden als auch Aussenstellen konzipiert worden.
Der GSM 100 wird für die Überwachung von bis zu 100 IP-Adressen empfohlen. Die Steuerung weiterer
Sensoren in anderen Sicherheitszonen wird nicht unterstützt. Jedoch kann der GSM 100 selbst als
Slave Sensor durch einen anderen Master gesteuert werden.
Die Appliance wird in einem Stahlblechgehäuse mit 1 Bauhöhe ausgeliefert. Für die einfache Integration in das Rechenzentrum kann ein optionales Rackkit genutzt werden. Ein Display ist nicht vorhanden.
Abb. 2.3: Die GSM 100 ist für kleinere Unternehmen gedacht
Für die Anbindung der zu überwachenden Systeme verfügt die Appliance über insgesamt 4 Ports, die
als 10/100/1000 Gigabit Ethernet Ports (RJ45) ausgeführt sind. Diese unterstützen jeweils bis zu 64
VLANs. Einer dieser Ports wird auch als Management Port genutzt.
2.3. SME-Klasse (GSM 100)
5
2.4 Sensoren GSM 25 / 25V
Die GSM 25 ist als Sensor für kleinere Unternehmen und Behörden sowie Zweigstellen konzipiert. Die
GSM 25 wird für bis zu 300 überwachten IP-Adressen empfohlen und verlangt zwingend die Steuerung
durch eine weitere Appliance im Master Mode. Hierzu können die GSM der Midrange- und EnterpriseKlasse (ab GSM 500 aufwärts) eingesetzt werden.
Die GSM 25 Appliance wird in einem Stahlblechgehäuse mit 1 Bauhöhe ausgeliefert. Für die einfache
Integration in das Rechenzentrum kann ein optionales Rackkit genutzt werden. Ein Display ist nicht
vorhanden.
Abb. 2.4: Die GSM 25 ist ein Sensor und kann nur mit einem GSM betrieben werden.
Für die Anbindung der zu überwachenden Systeme verfügt die Appliance über insgesamt 4 Ports, die
als 10/100/1000 Gigabit Ethernet Ports (RJ45) ausgeführt sind. Diese unterstützen jeweils bis zu 64
VLANs. Einer dieser Ports wird auch als Management Port genutzt.
Der GSM 25V ist eine virtuelle Appliance. Er bietet eine einfache und kostengünstige Option für die
Überwachung virtueller Infrastrukturen. Im Gegensatz zum GSM 25 bietet der GSM 25V nur einen virtuellen Port für das Management, das Scanning und den Bezug seiner Updates. Diese virtuelle Netzwerkschnittstelle unterstützt jedoch bis zu 64 VLANs.
2.5 GSM ONE
Die GSM ONE ist als virtuelle Appliance für spezielle Anforderungen, wie den Audit mit Hilfe eines Laptops und Schulungen konzipiert. Die GSM ONE wird für bis zu 300 überwachte IP-Adressen empfohlen
und kann weder weitere Sensoren steuern noch selbst durch eine größere Appliance als Sensor gesteuert werden.
Die GSM ONE verfügt lediglich über einen einzigen virtuellen Port, der für die Verwaltung, den Scan
und das Update genutzt wird. Dieser unterstützt nicht die Nutzung von VLANs.
Abb. 2.5: Die GSM ONE ist eine virtuelle Instanz.
Die GSM ONE verfügt über alle Funktionen der größeren Systeme mit den folgenden Ausnahmen:
6
• Master Mode: die GSM ONE kann nicht weitere Appliances als Sensoren steuern.
• Slave Mode: die GSM ONE kann nicht als Slave Sensor durch weitere Appliances als Master gesteuert werden.
• Alarmierungen: die GSM ONE kann keine Alarmierungen via SMTP, SNMP, Syslog oder HTTP versenden.
• VLANs: die GSM ONE unterstützt keine VLANs auf dem virtuellen Port.
2.5. GSM ONE
7
8
KAPITEL 3
Ich möchte ...
Dieses Kapitel dient Ihnen als Wegweiser durch dieses Handbuch bei der Umsetzung einfacher Aufgaben.
Ich möchte ...
• meinen ersten Scan durchführen Einfacher Scan (Seite 57).
• einen authentifzierten Scan durchführen. Bitte lesen Sie den Abschnitt Authentifizierter Scan
(Seite 71).
• den GSM aktualisieren. Bitte lesen Sie den Abschnitt : Upgrade (Seite 41).
• neue Sensoren konfigurieren und hinzufügen. Bitte lesen Sie den Abschnitt: Master und Slave
Setups (Seite 211).
• eine zentrale Authentifizierung via LDAP nutzen. Bitte lesen Sie den Abschnitt: Zentrale Benutzerverwaltung (Seite 181).
• verinice an den GSM anbinden. Bitte lesen Sie den Abschnitt Verinice (Seite 216).
• die Ergebnisse in OMD/Check_MK/Nagios anzeigen. Bitte lesen Sie den Abschnitt Nagios (Seite 223).
• mit Notizen meine Ergebnisse kommentieren und ergänzen. Bitte lesen Sie den Abschnitt Notizen (Seite 85).
• falsch-positive Meldungen mit Übersteuerungen verwalten. Bitte lesen Sie den Abschnitt Overrides und False Positives (Seite 87).
• die Berichtsformate nutzen und verwalten. Bitte lesen Sie den Abschnitt Report Plugins (Seite 92).
9
10
Kapitel 3. Ich möchte ...
KAPITEL 4
Inbetriebnahme
Dieses Kapitel betrachtet die ersten Schritte bei der Inbetriebnahme der Appliance. Die Schritte in
diesem Kapitel sind für die verschiedenen GSM Appliance Modelle identisch. Die modellspezifischen
Schritte und Hinweise zur Fehlersuche finden Sie in dem Kapitel Setup-Handbücher (Seite 241):
• GSM ONE (Seite 241)
• GSM 25V (Seite 244)
• GSM 25 (Seite 247)
• GSM 100 (Seite 250)
• GSM 500/510/550 (Seite 251)
• GSM 400/600/650 (Seite 254)
• GSM 5300/6400 (Seite 255)
Die
Inbetriebnahme
wird
auch
in
dem
folgenden
Video
http://docs.greenbone.net/Videos/gos-3.1/en/GSM-Setup-GOS-3.1-en-20150629.mp4.
erläutert:
4.1 Die Anmeldung als Admin
Sobald die Appliance eingeschaltet wird, beginnt der Boot-Prozess. Dieser Vorgang kann über die serielle Konsole verfolgt werden. Bei einer virtuellen Appliance kann der Bootvorgang in der Konsole
des Hypervisors (VirtualBox oder VMware) betrachtet werden.
Abb. 4.1: Boot-Bildschirm der Appliance
11
Nachdem der Boot-Vorgang abgeschlossen ist, können Sie sich lokal an dem System anmelden. Hierzu steht der Benutzer admin zur Verfügung. In der Werkseinstellung lautet das Kennwort ebenfalls
admin. Bei der Anmeldung erinnert Sie der GSM, einen Web-Benutzer zu erzeugen, falls Sie dies noch
nicht erledigt haben (siehe Abschnitt Web-Administrator (Seite 15)).
4.2 Grundkonfiguration
Die folgenden Abschnitte betrachten die Grundkonfiguration der Appliance. Diese Konfigurationschritte sollten nicht über eine Netzwerkverbindung sonder über die serielle Konsole oder bei einer
virtuellen Appliance über die Hypervisor-Konsole durchgeführt werden.
4.2.1 Tastaturlayout
Als erstes sollten Sie das eingestellte Tastaturlayout der Appliance prüfen und bei Bedarf an ihre Umgebung anpassen. Um das Tastaturlayout einzustellen, starten Sie das administrative Menü nach der
Anmeldung als Admin auf der Kommandozeile (siehe Abschnit Die Anmeldung als Admin (Seite 11)).
Geben Sie hierzu das Kommando gos-admin-menu ein. Dies startet das administrative Menü (siehe
Abbildung Greenbone OS Adminstrationsmenü (Seite 12)).
Abb. 4.2: Greenbone OS Adminstrationsmenü
In diesem Menü wählen Sie die erste Option Keyboard‘mit den Pfeiltasten aus und bestätigen sie
mit :kbd:‘Enter 2 . Wählen Sie im folgenden Dialog das gewünschte Layout. Nach der Bestätigung
der Auswahl müssen Sie mit Commit und Enter die Auswahl aktivieren. Sie erhalten die folgende
Meldung: The keyboard changes are submitted and become active within the next
5 minutes. Alternativ können Sie mit Rollback auch die ursprüngliche Konfiguration wiederherstellen.
4.2.2 Netzwerk
Die Konfiguration der ersten Netzwerkschnittstelle eth0 ist erforderlich um die Appliance in ein Netzwerk zu integrieren. Starten Sie hierzu das Admin-Menü auf der Kommandozeile nachdem Sie sich
angemeldet haben (siehe Abschnitt Die Anmeldung als Admin (Seite 11)). Rufen Sie das Kommando
gos-admin-menu auf der Kommandozeile auf. In dem textbasierten Menü können Sie Sie mit den
Pfeil- und der Enter-taste navigieren (siehe Bild Greenbone OS Adminstrationsmenü (Seite 12)).
2
12
Alternativ können Sie das Keyboard-Layout auch über die Variable keyboard_layout festlegen.
Kapitel 4. Inbetriebnahme
Der Menüpunkt Network bietet die Konfiguration der Netzwerkeinstellungen. Ein neues Menü (siehe
Abbildung Greenbone OS Admin: Netzwerk Konfiguration (Seite 13)) mit den folgenden Auswahlmöglichkeiten wird angezeigt:
• DNS: Konfiguration der DNS Server. Diese müssen auch bei Nutzung von DHCP gesetzt werden
und werden nicht automatisch via DHCP gefüllt. Die DHCP-Einstellungen betre en lediglich die
IP-Adresse und das Default-Gateway!
• NTP: Konfiguration der NTP Server. Diese werden ebenfalls nicht automatisch via DHCP gesetzt.
Die DHCP Einstellungen betre en lediglich die IP-Adresse und das Default-Gateway!
• ETH: Konfiguration der Ethernet-Schnittstellen.
• SNMP: Konfiguration der SNMP-Trap-Settings. Hier können Sie die Community Zeichenkette für
einen externen SNMP-Trap-Empfänger einstellen.
• Email: Konfiguration eines externen E-Mail Server für den Versand von GSM E-Mails z.B. mit Scan
Berichten.
Abb. 4.3: Greenbone OS Admin: Netzwerk Konfiguration
Um die IP-Adresse des Management Ports zu konfigurieren, wählen Sie ETH. eth0 hat hier eine besondere Bedeutung. Dieser Adapter wird als Management-Port verwendet. Die anderen möglicherweise verfügbaren Schnittstellen können während der Grundkonfiguration vernachlässigt werden.
Die Schnittstelle eth0 entspricht auf der physischen Appliance LAN1.
Abb. 4.4: Greenbone OS Admin: Ethernet Konfiguration
4.2. Grundkonfiguration
13
Durch die Auswahl von eth0 kann die Schnittstelle konfiguriert werden. Hier werden drei Optionen
geboten:
dhcp: Die IP-Adresse der Netzwerkschnittstelle wird via DHCP konfiguriert. Dies betri t nur die IPAdresse und das Default-Gateway. DNS-Server werden nicht von dem DHCP-Protokoll aktualisiert.
IP address: Die IP-Adresse wird mit ihrer CIDR-Netzmaske angegeben. Die Netzmaske muss in der
CIDR-Notation (/24, /25, etc.) und nicht als Bitmaske (255.255.255.0) angegeben werden.
Leer: Die Netzwerkschnittstelle ist deaktiviert.
Beim Setzen einer statischen IP-Adresse müssen Sie auch das Default Gateway setzen, damit der GSM
Feeds und Updates über das Netzwerk beziehen kann. Dieses kann via Network-ETH-Default Route
gesetzt werden. Die IP-Adresse des Default Gateways genügt hier. Alle Änderungen müssen Sie mit
Commit aktivieren.
4.3 Management Netzwerkschnittstelle
Wenn die Appliance über mehr als eine Netzwerkschnittstelle verfügt, können Sie auswählen welche
Schnittstelle für den administrativen Zugang zum GSM genutzt wird. Diese Schnittstelle definieren
Sie in der Variable ifadm.
4.4 DNS Konfiguration
Damit der GSM Feeds und Updates beziehen kann, benötigt er einen erreichbaren DNS Server für die
Namensauflösung. In der Werkseinstellung nutzt der GSM zwei Google Nameserver:
• google-public-dns-a.google.com: 8.8.8.8
• google-public-dns-b.google.com: 8.8.4.4
Diese Nameserver sollten Sie durch Ihre eigenen DNS Nameserver ersetzen. Dies ist insbesondere
erforderlich, falls der GSM die ö entlichen Google DNS Server zum Beispiel auf Grund von Firewallregeln nicht erreichen kann. Sie können hierzu bis zu drei DNS Server konfigurieren. Alle Änderungen
müssen Sie anschließend mit Commit aktivieren.
Ob der GSM die konfigurierten DNS-Server erreichen kann, zeigt er in dem Readiness-Check an (siehe
Abschnitt Bereitschaft (Seite 17)).
4.5 Kennwortänderung
Während der Grundkonfiguration sollten Sie auch das Kennwort des GSM Administrators neu setzen.
Die Werkseinstellung admin/admin ist für eine Produktionsumgebung nicht geeignet.
Die entsprechende Funktion finden Sie im Greenbone OS Administrationswerkzeug (GOS-AdminMenü) unter User. Die folgenden Benutzerrollen können sie hier konfigurieren:
1. GSM-Admin: Dies ist der Administrator, der sich auf der Kommandozeile z.B. via serieller Schnittstelle anmelden darf.
2. Web-Admin: Dies ist der Administrator, der die grafische Weboberfläche benutzen kann.
Um das Kennwort des Administrators zu ändern, wählen Sie GSM Admin. Sie werden zunächst nach
dem aktuellen (UNIX) Kennwort des Administrators gefragt. Anschließend müssen Sie zweimal das
neue Kennwort eingeben.
Die Änderung tritt sofort in Kraft. Ein Aktivieren der Änderung ist nicht erforderlich. Ein Rollback ist
ebenfalls nicht möglich.
14
Abb. 4.5: Ändern des Kennworts des GSM Administrators
Bemerkung: Einfache Kennwörter werden abgelehnt. Hierzu gehört auch das Default Kennwort admin.
4.6 Einstellung der Web-Oberfläche
Der Zugri auf den Greenbone Security Manager erfolgt primär über die Weboberfläche. Um diese zu
benutzen, sind zwei Schritte erforderlich:
1. Erzeugung eines Web-Administrators
Dies ist der Anwender, der sich mit administrativen Rechten auf der Weboberfläche anmelden
kann. Dieser Anwender kann alle Funktionen der Weboberfläche nutzen.
2. Erzeugung eines SSL-Zertifikats
Das SSL-Zertifikat wird für die verschlüsselte Verbindung zum GSM via HTTPS und OMP benötigt. Hierzu kann ein selbstsigniertes Zertifikat erzeugt oder ein Zertifikat einer externen Zertifikatsautorität verwendet werden (siehe Abschnitt Zertifikat einer externen Zertifizierungsstelle
(Seite 23)).
4.6.1 Web-Administrator
Um die GSM Appliance zu verwenden muss ein Web Administrator angelegt werden. Dieser Benutzer
wird teilweise auch als Scan Administrator bezeichnet.
Die Erzeugung des ersten Web-Administrators ist nur über das GOS-Admin-Menü oder auf der Kommandozeile möglich. Innerhalb des GOS-Admin-Menüs rufen Sie die Option User und anschließend
Add Web Admin auf. Nun geben Sie den Namen und das Kennwort des Web Administrators ein.
Es können mehrere Benutzer mit administrativen Rechten erzeugt werden. Die Erzeugung normaler
Benutzer ist mit dem GOS-Admin-Menü nicht möglich. Diese können lediglich angezeigt und gelöscht
werden.
Um vorhandene Benutzer zu ändern oder Benutzer mit geringeren Berechtigungen hinzuzufügen verwenden Sie die Weboberfläche.
4.6. Einstellung der Web-Oberfläche
15
4.6.2 Zertifikat
Die GSM Appliance kann zwei Arten von Zertifikaten nutzen:
• Selbstsignierte Zertifikate
• Zertifikate, die von einer externen Zertifikatsautorität ausgestellt wurden.
Die Nutzung selbstsignierter Zertifikate ist der einfachste Weg. Er bietet jedoch auch die geringste
Sicherheit und erfordert mehr Aufwand auf der Seite des Anwenders:
• Das Vertrauen in ein selbstsigniertes Zertifikat kann nur durch eine manuelle Überprüfung des
Fingerabdrucks des Zertifikats durch den Anwender hergestellt werden.
• Selbstsignierte Zertifikate können nicht widerrufen werden. Sobald sie durch den Anwender in
dem Browser akzeptiert wurden, sind sie dauerhaft im Browser gespeichert.
Üblicherweise verfügt der GSM bereits über ein individuelles selbstsigniertes Zertifikat. Die Installation eines Zertifikats ausgestellt durch eine externe Zertifikatsautorität wird im Abschnitt Zertifikat
einer externen Zertifizierungsstelle (Seite 23) besprochen.
4.6.3 Selbstsigniertes Zertifikat
Um ein neues selbstsigniertes Zertifikat zu erzeugen, wählen Sie die Option SSL im GOS-Admin-Menü
und anschließend Self-Signed. Sie werden aufgefordert einige Fragen zu beantworten auf deren Basis
das neue Zertifikat erzeugt wird. Die Angabe des commonName ist nicht kritisch, da es nicht Teil des
Zertifikats ist.
Abb. 4.6: Die Erzeugung eines selbstsignierten Zertifikats erfolgt mithilfe eines Dialogs.
4.7 Aktivierungsschlüssel
Jede Greenbone Security Manager Appliance benötigt einen Aktivierungsschlüssel. Die GSM ONE besitzt bereits einen vorinstallierten Aktivierungsschlüssel. Falls Sie eine GSM DEMO evaluieren, ist hier
auch bereits ein Aktivierungsschlüssel vorinstalliert.
Sie können erkennen, ob ein Aktivierungschlüssel hinterlegt ist, indem Sie das GOS-Admin-Menü aufrufen. Die Titelzeile zeigt Ihnen, ob ein Aktivierungsschlüssel existiert. Im Beispiel in Bild Prüfung des
Aktivierungsschlüssels (Seite 17) ist die Subskription gsf201309161 hinterlegt.
Alternativ können Sie auf der Kommandozeile show customer aufrufen.
16
Abb. 4.7: Prüfung des Aktivierungsschlüssels
Abb. 4.8: Prüfung des Aktivierungsschlüssels auf der Kommandozeile
Ist noch keine Subskription/Aktivierungsschlüssel hinterlegt, so haben Sie den üblicherweise separat erhalten. Nach dem Aufruf von subscriptiondownload müssen Sie diesen nun per Copy/Paste
einfügen. Hierzu verbinden Sie sich idealerweise per SSH mit dem System. Dazu müssen Sie möglicherweise den SSH-Zugang einschalten (siehe Abschnitt SSH-Zugang (Seite 33)).
4.8 Bereitschaft
Um die Verfügbarkeit und die richtige Konfiguration der Appliance zu prüfen, bietet das GOS-AdminMenü die Möglichkeit eines Selbsttests. Starten Sie das GOS-Admin-Menü und wählen Sie SelfCheck.
Der GSM prüft nun alle Voraussetzungen für seinen Betrieb.
Die einzelnen Voraussetzungen sind:
• Subscription key (Lizenzschlüssel)
• Web-Administrator (Scan-Administrator)
• Up-to date feeds (Aktuelle Feeds)
• Connectivity to the Greenbone feed server (Erreichbarkeit der Greenbone Server)
• Configuration of the DNS server (Konfiguration eines DNS-Servers)
4.8. Bereitschaft
17
Abb. 4.9: Prüfung der Betriebsvoraussetzungen
• Connectivity and functionality of the DNS server (Erreichbarkeit und korrekte Funktion des DNSServers)
• Available disk space of the hard disk (Verfügbarer Speicherplatz auf der Festplatte)
• Version of the operating system (Version des GOS Betriebssystems)
• Validity of the SSL certificate (Gültigkeit des SSL-Zertifikates)
• Availability of the configured sensors (only Midrange and Enterprise models) (Verfügbarkeit der
Sensoren)
• Operational state of the internal services (Funktion der internen Dienste)
Bitte führen Sie einen Neustart der Appliance durch, falls Sie grundlegende Einstellungen verändert
haben oder es sich um die erste Inbetriebnahme handelte.
18
KAPITEL 5
Die Kommandozeilenschnittstelle (CLI)
Neben dem GOS-Admin-Menu gibt es auch die Möglichkeit das Command-Line-Interface der GSM zu
nutzen. Einzelne Einstellungen, wie ein Syslog-Server, sind aktuell auch nur über diese Schnittstelle
erreichbar. Dieses Kapitel zeigt Ihnen, wie sie diese Änderungen durchführen.
5.1 Kommandozeile
Die CLI ist erreichbar über die serielle Konsole oder via SSH. Der SSH-Zugang ist möglicherweise jedoch deaktiviert und muss zunächst über die CLI oder das GOS-Admin-Menü auf der seriellen Konsole
aktiviert werden (siehe Abschnitt SSH-Zugang (Seite 33)).
Ein Zugri via SSH erfolgt von UNIX/Linux direkt auf der Kommandozeile:
$ ssh admin@<gsm>
Hierbei ersetzen Sie gsm durch die IP-Adresse oder den DNS-Namen der GSM-Appliance. Um den
Host-Key zu verifizieren, können Sie sich zuvor auf der seriellen Konsole dessen Prüfsumme anzeigen lassen. Hierzu wechseln Sie im GOS-Admin-Menü in den Unterpunkt Remote und wählen dort
SSH Fingerprint.
Während das GOS-Admin-Menü einen einfachen Menü-gesteuerten Zugang zur Konfiguration der
GSM-Appliance bietet, ist über die Kommandozeile ein umfangreicherer Zugang zum System möglich. Auf dem Command-Line-Interface (CLI) müssen Sie jedoch die Befehle auf der Kommandozeile
eingeben.
Der Zugri auf die Kommandozeile über die serielle Konsole ist in entsprechenden Abschnitt in diesem
Handbuch beschrieben. Sie können sich dort als Benutzer admin anmelden (siehe Abschnitt Die Anmeldung als Admin (Seite 11)). Das Kennwort in der Werkseinstellung lautet admin. Alternativ können
Sie auch den SSH-Zugang nutzen (siehe Abschnitt SSH-Zugang (Seite 33)).
Um Tippfehler zu vermeiden können Sie die Tabulator-Taste verwenden. Diese ergänzt automatisch
die eingegebenen Befehle.
Probieren Sie es aus: Geben Sie auf der GSM-Kommandozeile gos ein oder betätigen Sie die Tabulatortaste. Die Zeichenfolge wird automatisch zu gos-admin-menu.
gsm: gos<tab>
5.2 Einstellungen bearbeiten
Sämtliche Änderungen in den Einstellungen, die Sie auf der CLI durchführen, werden nicht sofort aktiv.
Sobald Sie eine Einstellung auf der CLI modifizieren, ändert sich der Prompt und zeigt hiermit an, dass
ungesicherte Änderungen vorliegen. Ein Stern im Prompt zeigt die noch nicht aktivierten Änderungen
an.
19
Abb. 5.1: Commit in der CLI
Sie können nun mit commit oder rollback entscheiden, ob Sie die Änderungen aktivieren oder zurücknehmen wollen.
Zusätzlich zeigt bei einem get die Ausgabe an, ob die Variable aktuell gesetzt ist. Dies wird durch ein
s zu Beginn der Zeile angezeigt. Ein u zeigt an, dass die Variable aktuell nicht gesetzt ist. Das Löschen
von Variablen ist mit dem Befehl unset möglich. Setzen können Sie die Variablen mit set.
Abb. 5.2: Set und unset in der CLI
5.3 Benutzer und Kennworte
Die CLI bietet wie das GOS-Admin-Menü die Möglichkeit, das Kennwort des Administrators der CLI zu
ändern und einen Web-Administrator (bzw. Scan-Administrator) zu erzeugen. Sie besitzt aber noch
einige darüber hinausgehende mächtigere Befehle.
5.3.1 Kennwortänderung des Admin
Das Kommando passwd ändert das Kennwort des CLI-Administrators. Dies ist das Kennwort, welches
Sie bei einer Anmeldung über die serielle Konsole oder via SSH eingeben müssen. Um das Kennwort
zu ändern, verwenden Sie den Befehl passwd.
20
Kapitel 5. Die Kommandozeilenschnittstelle (CLI)
gsm: passwd
Changing password for admin.
(current) UNIX password: old-password
Enter new UNIX password: new-password
Retype new UNIX password: new-password
passwd: password updated successfully
5.3.2 Erzeugen eines Web-Administrators (Scan-Administrator)
Um auf der CLI einen Web-Administrator zu erzeugen, verwenden Sie den Befehl addadmin. Dieser
Befehl erwartet den Login und das Kennwort des zu erzeugenden Administrators.
gsm: addadmin webadmin:kennwort
Creating user with temporary password.
User created with password ‛b759489e-c0ba-40eb-90c1-c165b641700c‛.
Setting password to desired value.
User was successfully created.
5.3.3 Superuser
Auf der GSM-Kommandozeile können Sie mit dem Befehl shell eine UNIX-Kommandozeile als unprivilegierter Benutzer admin erhalten. So können Sie jeden beliebigen UNIX-Befehl aufrufen.
Dieser Superuser ist nicht identisch und daher unabhängig von dem Super Admin, den Sie für die Weboberfläche anlegen können (siehe Abschnitt Super Admin (Seite 176)).
Um Root-Rechte (SuperUser) auf der GSM-Appliance zu erlangen, müssen Sie den Befehl su eingeben.
Dies ist in der Werkseinstellung jedoch nur möglich, wenn Sie lokal über die serielle Konsole angemeldet sind. Wenn Sie via SSH an der GSM Appliance angemeldet sind, ist der Zugri auf Root gesperrt.
Für die täglichen Aufgaben genügt der User admin. Daher sollte eine Freischaltung nur in Ausnahmen
und in Absprache mit dem Greenbone Support erfolgen.
Um sich als root anzumelden, muss die Variable superuser gesetzt werden.
gsm: get superuser
s superuser disabled
gsm: set superuser enabled
gsm *: commit
gsm: get superuser
s superuser enabled
Nach dieser Änderung ist ein Reboot des GSM erforderlich!
Wenn Sie den Superuser-Zugang aktivieren sollten Sie aber auch ein sicheres Kennwort für den rootBenutzer setzen. Hierzu verwenden Sie die Variable superuserpassword. Im Default ist das Kennwort disabled.
gsm: get superuserpassword
s superuserpassword disabled
gsm: set superuserpassword kennwort
gsm *: commit
gsm:
5.4 Zertifikate
Die GSM Appliance kann grundsätzlich zwei verschiedene Zertifikatstypen nutzen:
• Selbstsignierte Zertifikate
5.4. Zertifikate
21
• Zertifikate ausgestellt durch eine externe Zertifikatsautorität
Die Nutzung von selbstsignierten Zertifikaten ist die einfachste Variante. Sie bietet aber auch die geringste Sicherheit und mehr Aufwand für den Anwender:
• Die Vertrauenswürdigkeit eines selbstsignierten Zertifikats kann von dem Anwender nur manuell durch Prüfung des Fingerabdrucks des Zertifikats festgestellt werden.
• Selbstsignierte Zertifikate können nicht widerrufen werden. Wurden Sie einmal von dem Anwender im Browser akzeptiert, sind sie dauerhaft dort gespeichert. Erhält ein Angreifer Zugri auf
den zugehörigen privaten Schlüssel, so kann er einen Mann-in-der-Mitte Angri auf die durch
das Zertifikat geschützte Verbindung durchführen.
Die Nutzung eines Zertifikats, welches durch eine Zertifikatsautorität ausgestellt wurde hat mehrere
Vorteile:
• Alle Clients, die der Autorität vertrauen, können das Zertifikat direkt verifizieren und eine sichere
Verbindung aufbauen. Es erfolgt keine Warnung durch den Browser.
• Das Zertifikat kann durch die Zertifikatsautorität einfach widerrufen werden. Wenn die Clients
über eine Möglichkeit zur Überprüfung des Zertifikatsstatus verfügen, können sie ein vom Zeitraum noch gültiges aber widerrufenden Zertifikat ablehnen. Als Mechanismen können hier Certificate Revocation Lists (CRLs) oder das Online Certificate Status Protocol (OCSP) eingesetzt werden.
• Insbesondere wenn mehrere Systeme in einem Unternehmen SSL-geschützte Informationen
anbieten, vereinfacht die Verwendung einer eigenen Unternehmens-CA die Verwaltung enorm.
Sämtliche Clients müssen dann lediglich der Unternehmens-CA vertrauen, um sämtliche von der
CA ausgestellte Zertifikate zu akzeptieren.
Alle modernen Betriebssysteme unterstützen die Erzeugung und Verwaltung einer eigenen Zertifikatsautorität. Unter Microsoft Windows Server unterstützen die Active Directory Certificate Services
den Admin bei der Erzeugung einer root CA3 . Für Linux-Systeme stehen vielfältige Lösungen zur Verfügung. Eine Variante ist im IPsec-Howto beschrieben IPSec-Howto4 .
Bei der Erzeugung und dem Tausch der Zertifikate ist zu beachten, dass der Admin vor Erzeugung des
Zertifikats prüft, wie der spätere Zugri auf das System erfolgt. Die IP-Adresse bzw. der DNS-Name
müssen bei der Erzeugung im Zertifikat hinterlegt werden. Des Weiteren ist nach der Erzeugung eines
Zertifikats immer ein Reboot erforderlich, damit alle Dienste das neue Zertifikat nutzen. Dies ist bei
der Planung des Zertifikatswechsels zu berücksichtigen.
5.4.1 Selbstsignierte Zertifikate
Um eine schnelle Inbetriebnahme zu unterstützen, erlaubt dir GSM die Verwendung von selbstsignierten Zertifikaten. Jedoch ist bei Auslieferung bei vielen Varianten ein derartiges Zertifikat nicht vorinstalliert und muss von dem Administrator erst erzeugt werden. Die GSM One kommt jedoch bereits
mit einem vorinstallierten Zertifikat. Sehen Sie hierzu auch in Abschnitt Selbstsigniertes Zertifikat
(Seite 16).
Diese selbstsignierten Zertifikate können einfach auf der Kommandozeile erzeugt werden. Alternativ kann der Admin ein selbstsigniertes Zertifikat auch über das GOS-Admin-Menü erzeugen (SSLSelf-Signed). Bevor der Admin das Zertifikat erzeugt, muss er prüfen, wie später der Zugri auf den
GSM erfolgt. Erfolgt der Zugri über eine IP-Adresse (https://192.168.15.5) oder mit einem DNS-Namen
(https://gsm.example.com)?
Die IP-Adresse bzw. der DNS-Name muss bei der Erzeugung des Zertifikats angegeben werden. Er
kann später nur durch eine erneute Erzeugung eines Zertifikats verändert werden.
Nach der Erzeugung des Zertifikats ist ein Reboot erforderlich, damit alle Dienste das neue Zertifikat
nutzen.
3
4
22
https://technet.microsoft.com/en-us/library/cc731183.aspx
http://www.ipsec-howto.org/x600.html
gsm: sslselfsign
Generating a 2048 bit RSA private key
.+++
................................................................................+++
unable to write 'random
state '
writing new private key to 'selfcert.pem '
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value ,
If you enter '.', the field will be left blank.
----Country Name (2 letter code) [DE]: DE
State or Province Name (full name) [ Niedersachsen ]: Bundesland
Locality Name (eg , city) [Hildesheim ]: Stadt
Organization Name (eg , company) [Greenbone Networks Customer ]: Firma
Organizational Unit Name (eg , section) [ Vulnerability Management Team ]: Abteilung
IP -address of the GSM , or it 's FQDN (HOSTNAME.DOMAINNAME) []: 192.168.155.180
Email Address of the GSM Administrator []: [email protected]
Um das Zertifikat auszulesen und anzuzeigen, können Sie den Befehl sslcatself verwenden.
5.4.2 Zertifikat einer externen Zertifizierungsstelle
Um das Zertifikat einer externen Zertifizierungsstelle zu importieren, müssen Sie auf die Kommandozeile wechseln. Hierzu verlassen Sie das GOS-Admin-Menü, so dass Sie den Prompt der GSM erhalten:
gsm:.
Bemerkung: Da Sie die Zertifikatsdaten mit Copy/Paste übertragen, ist es sinnvoll diesen Vorgang
mit Hilfe einer SSH-Verbindung durchzuführen. Hierzu müssen Sie möglicherweise den SSH-Zugang
zuvor aktivieren (siehe Abschnitt SSH-Zugang (Seite 33)).
Nun deaktivieren Sie die Unterstützung für selbstsignierte Zertifikate durch den Aufruf von set
selfsigssl disabled. Hiermit deaktivieren Sie die Variable selfsigssl. Bestätigen Sie den Aufruf durch commit.
Der nächste Schritt hängt davon ab, ob Sie einen Certificate Signing Request (CSR; Zertifikatsregistrierungsanforderung) benötigen, der dann von einer Zertifizierungsstelle signiert wird, oder ob Sie bereits einen Schlüssel und ein signiertes Zertifikat haben welche Sie für diesen GSM verwenden wollen.
Sie können mit sslreq eine neuen Certificate Signing Request (Zertifikatsregistrierungsanforderung)
erzeugen. Hierbei geben Sie bitte Ihre Daten korrekt an. Besonders wichtig ist die Angabe des commonName (CN). Dieser muss später mit dem Aufruf im Browser übereinstimmen. Wenn Sie für den
Zugri auf die GSM die IP-Adresse verwenden, so geben Sie auch hier die IP-Adresse an. Bei Nutzung
eines Rechnernamens geben Sie den Namen an.
gsm: set selfsigssl disabled
gsm *: commit
gsm: sslreq
Generating a 2048 bit RSA private key
.....................................................................+++
..+++
unable to write 'random state '
writing new private key to 'tckey.pem '
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
5.4. Zertifikate
23
There are quite a few fields but you can leave some blank
For some fields there will be a default value ,
If you enter '.', the field will be left blank.
----Country Name (2 letter code) [DE]: DE
State or Province Name (full name) [ Niedersachsen ]: Bundesland
Locality Name (eg , city) [Hildesheim ]: Stadt
Organization Name (eg , company) [Greenbone Networks Customer ]: Firma
Organizational Unit Name (eg , section) [ Vulnerability Management Team ]: Abteilung
IP -address of the GSM , or it 's FQDN (HOSTNAME.DOMAINNAME) []: 192.168.155.180
Email Address of the GSM Administrator []: [email protected]
Die Zertifikatsregistrierungsanforderung wird direkt im Anschluss auf dem Terminal angezeigt. Falls
Sie die Ausgabe wiederholen möchten, können Sie dies mit dem Befehl sslcatkey erreichen.
Abb. 5.3: Die Zertifikatsregistrierungsanforderung befindet sich in dem Block zwischen BEGIN
CERTIFICATE REQUEST und END CERTIFICATE REQUEST
Die angezeigte Zertifikatsregistrierungsanforderung muss nun mit Copy/Paste an eine Zertifikatsautorität mit der Bitte um Signatur übertragen werden.
Nachdem das Sie das signierte Zertifikat von der Zertifikatsautorität erhalten haben, muss es im
PEM-Format (Base64) wieder an die GSM übertragen werden. Hierzu müssen Sie das Kommando
ssldownload aufrufen, das Zertifikat mit Copy/Paste übertragen und die Eingabe mit Strg-D auf
einer leeren Zeile abschliessen.
Falls Sie bereits über einen Schlüssel und ein signiertes Zertifikat verfügen und es für dieses GSM benutzen wollen, müssen Sie stattdessen den Befehl certdownload aufrufen um Schlüssel und Zertifikat im PEM-Format (Base64) mit Copy/Paste übertragen und die Eingabe mit Strg-D auf einer leeren
Zeile abschliessen.
Bemerkung: Bei dem Import des Zertifikats kann es zu Warnungen kommen. Das Greenbone OS prüft
selbst auch die Validität des Zertifikats. Hierzu nutzt es eine Liste von Zertifikatsautoritäten, die in
dem Greenbone OS hinterlegt sind. Wenn die ausstellende Autorität nicht dem GSM bekannt ist, zeigt
es bei dem Import des Zertifikats Warnungen an. Diese können jedoch vernachlässigt werden, da der
GSM anschließend nicht mehr die Validität des Zertifikats prüfen muss. Wichtig ist, dass alle eingesetzten Clients (z.B. Webbrowser) der Zertifikatsautorität vertrauen.
24
5.5 Geräteverwaltung
Dieser Abschnitt beschreibt die Kommandos der CLI für die Verwaltung der Appliance. Hierzu gehört
der Reboot und das Herunterfahren, das Setzen der Netzwerkkonfiguration und die Konfiguration von
Mailservern und zentralen Protokollservern.
5.5.1 Reboot und Herunterfahren der Appliance
Um die Appliance herunterzufahren, können Sie auf der CLI das Kommando shutdown eingeben. In
Abhängigkeit des eingesetzten Modells kann es sein, dass die Appliance sich nicht automatisch ausschaltet. Sobald jedoch der Shutdown durchgeführt wurde, kann die Appliance ausgeschaltet werden.
gsm: shutdown
Are you sure you want to shutdown the system?
y/n?
y
Möglicherweise laufende Scan-Prozesse können nach einem Neustart wieder aufgenommen werden.
Um einen Neustart der Appliance anzustossen können Sie in der CLI den Befehl reboot eingeben:
gsm: reboot
Are you sure you want to reboot the system?
y/n? y
Ein reboot oder shutdown wird verweigert wenn wesentliche administrative Änderungen am System
laufen wie zum Beispiel ein Upgrade.
5.5.2 Netzwerkkonfiguration
Die Netzwerkkonfiguration in der CLI erfolgt über das Setzen von Variablen. Dabei ist anschließend
immer ein Commit erforderlich. Die folgenden Parameter können gesetzt werden.
hostname
Der Name der Appliance erscheint in den Scan-Berichten und in den Syslog-Meldungen auf einem zentralen Protokollserver. Daher ist es sinnvoll, der Appliance einen aussagekräftigen Namen zu geben.
Hierbei dürfen Sie die folgenden Zeichen verwenden:
• Klein- und Großbuchstaben a-zA-Z
• Zi ern 0-9
• Bindestrich gsm: get hostname
s hostname gsm
gsm: set hostname gsm-frankfurt
gsm *: commit
gsm: get hostname
s hostname gsm -frankfurt
domainname
Der Domänenname erscheint ebenfalls wie der Hostname in den Scan-Berichten und in den SyslogMeldungen auf einem zentralen Protokollserver. Außerdem wird die konfigurierte Domäne automatisch bei versandten E-Mails als Absender-Domäne genutzt. Zusätzlich wird der Domänenname auch
bei nicht vollqualifizierten Hostname als Such-Sux angehängt.
5.5. Geräteverwaltung
25
Der Domänenname darf die gleichen Zeichen nutzen, wie der Hostname.
gsm: get domainname
s domainname greenbone.net
gsm: set domainname musterfirma.de
gsm *: commit
gsm: get domainname
s domainname musterfirma.de
DNS-Server
Die GSM-Appliance unterstützt bis zu drei DNS-Server. Sie benötigt die Angabe von mindestens einem
DNS-Server. Weitere eingetragene Server werden nur bei Ausfall des ersten Servers genutzt.
Hierzu stehen drei Variablen zur Verfügung:
• dns1
• dns2
• dns3
Um einen DNS-Server zu löschen, verwenden Sie den Befehl unset.
gsm: get dns2
s dns2 8.8.4.4
gsm: unset dns2
gsm *: commit
gsm: get dns2
u dns2
IP-Adressen
Die GSM-Appliances verfügen über bis zu 24 Netzwerkkarten. Für jede dieser Netzwerkkarten können
Sie je eine IPv4 und eine IPv6 Adresse konfigurieren. Bei IPv4-Adressen können Sie auch das Schlüsselwort dhcp angeben. Hiermit wird die IP-Adresse per DHCP bezogen. Die Variablen lauten:
• address_ethX_ipv4
• address_ethX_ipv6
Für X können die Zahlen 0 bis 23 eingesetzt werden. Dies ist abhängig von der verbauten Hardware.
gsm: get address_eth0_ipv4
s address_eth0_ipv4 dhcp
gsm: set address_eth0_ipv4 192.168.155.108/24
gsm *: commit
gsm: get address_eth0_ipv6
u address_eth0_ipv6
gsm: set address_eth0_ipv6 2001:db8:0:1::1/64
gsm *: commit
gsm:
Nach dem Setzen der IP-Adressen ist ein Reboot erforderlich, damit die Adressen tatsächlich genutzt
werden.
Um eine IP-Adresse zu löschen verwenden Sie den Befehl unset. Wenn Sie die IPv4-Adresse löschen,
wird nur diese Adresse deaktiviert. Die IPv6-Adresse ist weiterhin erreichbar.
Tipp: Grundsätzlich ist immer auch auf jeder Netzwerkkarte die IPv6-Link-Local-Adresse aktiv. Wenn
Sie IPv6 abschalten möchten, so können Sie die Variable ipv6support nutzen. Diese deaktiviert für
die gesamte Appliance die IPv6-Unterstützung. Damit sind dann auch die Link-Local-Adressen nicht
mehr aktiv.
26
Default Gateway
Um das Default-Gateway zu setzen, verwenden Sie die Variable default_route_ipv4. Wenn Sie
DHCP für die Vergabe der IP-Adressen nutzen wird auch die Default-Route über DHCP gesetzt, sofern
nicht mittels der Variable default_route_ipv4 explizit ein Router bestimmt wird.
gsm: get default_route_ipv4
u default_route_ipv4
gsm: set default_route_ipv4 192.168.155.1
gsm *: commit
gsm:
Via CLI kann nur das IPv4-Default-Gateway gesetzt werden. Komplexe Routing-Einstellungen müssen
über die Experten Netzwerkkonfigugration (siehe Abschnitt Experten Netzwerkkonfiguration (Seite 29)) erfolgen.
Network Time Protokoll
Um eine Zeitsynchronisation der Appliance mit zentralen Servern zu ermöglichen, unterstützt die
GSM-Appliance das NTP-Protokoll. Sie können zwei NTP-Server einrichten, die von der Appliance für
die Synchronisation genutzt werden. Die Appliance wählt selbst den geeigneten Server aus. Bei Ausfall eines Servers wird automatisch der andere Server genutzt.
Hierzu stehen die Variablen ntp_server1 und ntp_server2 zur Verfügung. Beide Variablen erwarten eine IP-Adresse als Angabe. Die Angabe eines DNS-Namens ist nicht erlaubt.
gsm: set ntp_server1 192.53.103.104
gsm *: commit
Um die Nutzung und die Funktion des Protokolls zu testen, steht der Befehl ntpq zur Verfügung:
gsm: ntpq
remote refid st t when poll reach delay offset jitter
==============================================================================
*ptbtime1.ptb.de .PTB. 1 u 245 1024 377 14.131 -0.432 0.495
+ptbtime2.ptb.de .PTB. 1 u 1012 1024 377 13.544 0.015 0.354
LOCAL (0) .LOCL. 10 l 53h 64 0 0.000 0.000 0.000
Hier können Sie die konfigurierten NTP-Server, ihr Stratum, die Erreichbarkeit, Zeitabweichungen und
Verzögerungen und den Jitter erkennen. Der Stern (*) in der ersten Spalte zeigt an, mit welchem Server
sich aktuell die Appliance synchronisiert.
Mail-Server
Um nach dem Abschluss eines Scans automatisch den Bericht per E-Mail zu versenden, benötigt die
Appliance die Angabe eines Mailservers für die Zustellung der E-Mail. Die Appliance verfügt selbst
nicht über einen Mailserver.
Stellen Sie sicher, dass der Mail-Server die E-Mails von der Appliance immer annimmt. Die Appliance
speichert im Fehlerfall die E-Mails nicht. Es wird kein zweiter Zustellversuch zu einem späteren Zeitpunkt unternommen. Daher müssen Sie auf dem Mailserver mögliche Anti-Spam-Maßnahmen, wie
ein Greylisting, für die Appliance deaktivieren. Auch eine Authentifizierung mit Hilfe eines Benutzers
und Kennworts wird von der Appliance nicht unterstützt. Die Authentifizierung muss daher IP-basiert
erfolgen!
Für die Konfiguration des Mail-Servers verwenden Sie die Variable mailhub:
gsm: get mailhub
s mailhub mail.greenbone.net
gsm: set mailhub mx.musterfirma.de
gsm *: commit
27
Zentraler Protokollserver
Die GSM-Appliance erlaubt die Konfiguration zentraler Protokollserver für die Speicherung der Protokolle. Hierbei nutzt die GSM-Appliance das Syslog-Protokoll. Die zentrale Speicherung der Protokolle
erlaubt eine zentrale Analyse, Verarbeitung und Überwachung der Protokolle. Zusätzlich werden die
Protokolle aber auch immer lokal gespeichert.
Sie können zwei Protokollserver konfigurieren. Beide werden genutzt. Als Transportprotokoll können
sowohl UDP (Default) als auch TCP genutzt werden. Das TCP-Protokoll garantiert die Übertragung der
Nachrichten auch bei Paketverlust. Kommt es bei einer UDP-basierten Übertragung zu Paketverlusten, so sind die Protokollmeldungen verloren.
Hierzu können Sie die folgenden zwei Variablen nutzen:
• syslog_server1
• syslog_server2
Das Format lautet:
[udp|tcp://]ip[:port]
Bespiel:
gsm: set syslog_server1 tcp://192.168.0.5:2000
gsm *: commit
Wird der Port nicht angegeben, so wird der Default-Port 514 genutzt. Wird das Protokoll nicht angegeben, so wird UDP verwendet.
SNMP
Die GSM Appliance bietet auch SNMP Unterstützung. Via SNMP können sowohl Traps mit Hilfe der Benachrichtigungen (siehe auch Abschnitt Benachrichtigungen (Seite 139)) versendet werden als auch
die Vitalparameter der Appliance überwacht werden.
Die von der Appliance unterstützten SNMP-Objekte sind in einer Management Information Base (MIB)
Datei dokumentiert. Die jeweils aktuelle MIB kann von dem Greenbone tech [doc] portal5 bezogen
werden.
Die GSM-Appliance unterstützt das SNMP-Protokoll Version 3 für lesende Zugri e und SNMPv1 für
Traps.
Die SNMPv3-Konfiguration wird am einfachsten über das GOS-Admin-Menü unter dem Punkt Remote
und SNMP Configuration vorgenommen. Hier wird dann auch deutlich, dass der GSM das Kennwort
des SNMPv3-Benutzers mit SHA-1 überträgt und die Verschlüsselung mit AES durchführt.
Das Versenden von Traps wird im GOS-Admin-Menü unter Network und SNMP konfiguriert.
Alternativ erlauben die folgenden Variablen die Konfiguration des SNMP-Zugangs:
• snmp
• snmp_key
• snmp_password
• snmp_user
• snmp_location
• snmp_contact
• snmp_trap
• snmp_trapcommunity
5
28
http://docs.greenbone.net/API/SNMP/snmp-gos-3.1.de.html
Abb. 5.4: SNMPv3 Konfiguration
• snmp_trapreceiver
Um SNMP Traps zu versenden müssen Sie die folgenden Parameter konfigurieren.
gsm: set snmp_trap enabled
gsm *: set snmp_trapcommunity public
gsm *: commit
gsm: get snmp_trapreceiver
s snmp_trapreceiver 192.168.0.1
Um einen lesenden SNMP-Zugri mit Hilfe der Variablen zu konfigurieren, nutzen Sie die entsprechenden Variablen snmp_key, snmp_password und snmp_user
Anschließend können Sie den lesenden Zugri auf den SNMP-Dienst von Linux/Unix mit snmpwalk
testen:
$ snmpwalk -v 3 -l authPriv -u user -a sha -A password -x aes -X key 192.168.155.180
iso .3.6.1.2.1.1.1.0 = STRING: "Greenbone Security Manager"
iso .3.6.1.2.1.1.5.0 = STRING: "gsm"
...
Die folgenden Informationen können ausgelesen werden:
• Uptime (Laufzeit)
• Netzwerkschnittstellen
• Speicher
• Festplatten
• Last
• CPU
5.5.3 Experten Netzwerkkonfiguration
Das GOS-Admin-Menü und die Variablen erlauben im Moment nur eine einfache Netzwerkkonfiguration. Hierbei können Sie weder VLANs nutzen noch mehrere statische Routen setzen.
Um entsprechende Änderungen der Einstellungen vorzunehmen existiert nun ein Expertenmodus.
Dieser erwartet die Eingabe sämtlicher Einstellungen in Form eines Skriptes. Die Erzeugung, Anpassung und Aktivierung dieses Skripts wird in diesem Abschnitt beschrieben.
Sobald Sie den Expertenmodus verwenden, können Sie nicht mehr die IP-Adressen über das GOSAdmin-Menü oder die Variablen ändern!
29
Um den Expertmodus zu verwenden, muss er erst aktiviert werden. Führen Sie das folgende Kommando auf der Kommandozeile (siehe Abschnitt Kommandozeile (Seite 19)). aus. Anschließend ist ein
Neustart erforderlich.
gsm: set netmode expert
gsm *: commit
gsm: reboot
Are you sure you want to reboot the system?
y/n? y
Um zu einem späteren Zeitpunkt wieder in den normalen Modus zurückzukehren verwenden Sie den
Befehl set netmode default.
Bitte beachten Sie, dass Sie noch ein commit ausführen müssen, damit der set netmod Befehl wirksam ist. Nachdem Sie die Datei expertnet.sh angepasst haben ist dann noch ein reboot notwendig,
damit die Einstellungen übernommen werden.
Derzeit versetzt der Befehl set netmode expert das System in einen Zustand, in dem der Benutzer
die gesamte Konfiguration von Hand eingeben muss. Um sie dauerhaft zu speichern, müssen Sie die
Befehle in der Datei expertnet.sh speichern und diese ausführbar machen (siehe unten).
Um die Datei zu editieren, wechseln Sie in den Shell-Modus. Geben Sie hierzu den Befehl shell ein:
gsm: shell
ATTENTION:
The shell command should only be used by expert users.
To leave the expert mode , type 'exit '.
admin@gsm :~$ ls -l expertnet.sh
-rwxr --r-- 1 admin admin 131 May 4 2012 expertnet.sh
admin@gsm :~$ _
Nachdem Sie sich auf der Greenbone OS Shell befinden, können Sie mit ls die Dateien in Ihrem Heimatverzeichnis anzeigen. Hier befindet sich auch eine Datei expertnet.sh. Diese Datei kann von Ihnen
mit einem Editor angepasst werden. Hierzu können Sie entweder den Editor vi, vim oder nano verwenden. Wenn Sie den Editor vi bzw. vim nicht kennen, verwenden Sie bitte den Editor nano. Dieser
zeigt unten am Fenster eine Hilfe an. Die dort aufgeführten Tastenkombinationen werden alle mit der
Steuerungstaste aufgerufen: Strg-O schreibt die Datei.
Wenn Sie diese Datei noch nicht editiert haben, hat sie den folgenden Inhalt:
# This script can be used to set custom network parameters like
# VLANS , source based routing and firewall restrictions on the GSM
Ein Editieren auf einem anderen System und das anschließende Übertragen der Datei mit Secure-Copy
ist nicht möglich. Der GSM unterstützt kein Secure-Copy via SSH.
Ihre erste Änderung in dieser Datei ist das Einfügen einer ersten Zeile, so dass die Datei anschließend
den folgenden Inhalt hat:
#!/bin/sh
# This script can be used to set custom network parameters like
# VLANS , source based routing and firewall restrictions on the GSM
Die erste Zeile weist das Greenbone OS an, diese Datei mit Hilfe der Shell /bin/sh zu interpretieren. Ohne diese Zeile wird die Datei später nicht ausgeführt. Damit die Datei ausgeführt werden kann,
sollten Sie die Datei auch direkt mit entsprechenden Rechten versehen. Geben Sie hierfür auf der Kommandozeile den folgenden Befehl ein:
admin@gsm :~$ chmod 755 expertnet.sh
Sämtliche Netzwerkkonfigurationen sollten mit dem Kommando ip erfolgen. Die alternativen Kommandos ifconfig, route und vconfig sollten nicht genutzt werden. Ihre Unterstützung kann in
Zukunft eingeschränkt werden.
30
Um Probleme mit den Pfaden auf dem System zu vermeiden, sollte der Befehl ip immer mit seinem
kompletten Pfad aufgerufen werden: /bin/ip.
Setzen von IP-Adressen
Das Setzen von IP-Adressen kann ganz einfach mit dem ip Befehl durchgeführt werden. Hierzu sollten
das Setzen in drei Schritten erfolgen:
1. Aktivieren der Netzwerkkarte
2. Setzen der ersten IP-Adresse
3. Setzen von optional weiteren IP-Adressen auf derselben Netzwerkkarte
Nach dem Aktivieren der Netzwerkkarte sollte eine Verzögerung von 10 Sekunden eingebaut werden,
damit die Netzwerkkarte ausreichend Zeit für die Autonegotiation erhält. Der Einheitlichkeit erfolgt
das im Beispiel auch für die Loopback-Karte.
/bin/ip link set
sleep 10s
/bin/ip addr add
/bin/ip link set
sleep 10s
/bin/ip addr add
/bin/ip -f inet6
lo up
127.0.0.1/8 dev lo
eth0 up
192.168.81.10/24 dev eth0
addr add 2607: f0d0 :2001::10/114 dev eth0
Die ersten drei Zeilen aktivieren und konfigurieren das Loopback Interface. Diese Netzwerkschnittstelle dürfen Sie nicht vergessen in dem Skript. Ohne das Loopback Interface ist der GSM nicht funktionstüchtig.
Sie können mit dem Kommando ip auch mehrere IP-Adressen auf derselben Netzwerkkarte aktivieren. Mit ip addr add werden weitere IP-Adressen hinzugefügt. Sie ersetzen nicht die vorhandene
IP-Adresse. Um eine IP-Adresse zu löschen ist explizit ein ip addr del erforderlich!
VLAN Unterstützung
Wenn Sie Ihre Switche so konfigurieren, dass diese mehrere VLANs mit Tags (VLAN IDs 6 versehen in einem IEEE 802.1q 7 -Trunk 8 ) an den GSM weiterleiten, so müssen Sie diese auf dem GSM entsprechend
zerlegen. Hierzu müssen Sie Subinterfaces auf der physikalischen Netzwerkkarte konfigurieren. Auch
diese Subinterfaces erzeugen Sie mit dem Kommando ip.
/bin/ip link
sleep 10
/bin/ip link
/bin/ip link
/bin/ip addr
set eth1 up
add link eth1 name eth1 .91 type vlan id 91
set eth1 .91 up
add 192.168.81.26/24 dev eth1 .91
Das dritte Kommando erzeugt auf der Netzwerkkarte eth1 ein Subinterface mit dem Namen eth1.91.
Der Name kann hierbei von Ihnen frei gewählt werden. Sie können also als Namen auch zum Beispiel
ServerNet oder MailDMZ oder ähnliches verwenden. Mit der Angabe type vlan weisen Sie den
Befehl an, dass ein getaggtes VLAN entsprechend ausgepackt werden soll. Mit der id 91 wählen Sie
die tatsächliche VLAN ID aus.
Die weiteren Zeilen aktivieren das Subinterface und setzen die IP-Adresse. Auch hier können mehrere
IPv4 und auch IPv6 Adressen gesetzt werden.
6
Das 802.1q Protokoll unterstützt mit einem 12Bit VID Feld bis zu 4096 VLANs. Einzelne VLAN IDs sind jedoch reserviert.
7 Das IEEE 802.1q ist heute das am meisten verbreitete VLAN Protokoll. Es hat die proprietären Protokolle einzelner Hersteller
(wie ISL von Cisco) abgelöst.
8 Mehrere VLANS werden durch Tags markiert durch eine einzige Verbindung (single interconnect) übertragen.
31
Falls es sich um einen VLAN Trunk mit einem Native VLAN handelt, so können Sie auch für die physikalische Netzwerkkarte eine IP-Adresse setzen. Wurde kein native VLAN konfiguriert, so ist eine IPAdresse für die physikalische Netzwerkkarte nicht erforderlich. Jedoch müssen Sie in dem Fall daran
denken, die physikalische Netzwerkkarte zu aktivieren!
Statisches Routing
Die meisten Netze verfügen nur über ein Gateway. Dieses Gateway wird häufig auch als DefaultGateway bezeichnet. Teilweise nutzen jedoch historisch gewachsene Netze für unterschiedliche Ziele
verschiedene Router. Wenn diese Router untereinander nicht ihre Daten über dynamische Routingprotokolle austauschen, sind häufig auf den Clientsystemen statische Routen für diese Ziele erforderlich.
Die Expertenkonfiguration erlaubt Ihnen das Setzen von beliebig vielen statischen Routen.
Wenn Sie die Expertenkonfiguration nutzen, müssen Sie auch das Default-Gateway in der Datei
expertnet.sh setzen. Wenn Sie IPv4 und IPv6 nutzen, müssen Sie für jedes Protokoll ein getrenntes Default-Gateway setzen. Wenn Sie bei IPv6 die Autokonfiguration nutzen, kann hier das DefaultGateway entfallen.
Um eine Route zu setzen, verwenden Sie ebenfalls den Befehl ip mit dem Argument route:
/bin/ip route add default via 192.168.81.1
/bin/ip -f inet6 route add default via 2607: f0d0 :2001::1
Das Schlüsselwort default wird hierbei entsprechend zu 0.0.0.0/0 oder ::/0 aufgelöst.
Um weitere Routen zu setzen können Sie einfach die folgende Syntax nutzen:
/bin/ip route add 192.168.0.0/24 via 192.168.81.5
Hiermit setzen Sie eine Route für das Netzwerk 192.168.0.0/24 über den Router 192.168.81.5.
5.6 Fernzugriff
Für den Zugri von außen auf die GSM-Appliance stehen grundsätzlich vier Wege zur Verfügung:
HTTPS Dies ist der übliche Weg für die Anlage, Durchführung und Analyse der Vulnerability-Scans.
Dieser Weg ist daher per Default freigeschaltet und kann auch nicht deaktiviert werden. Sie können lediglich den Timeout für eine automatische Abmeldung bei Inaktivität der HTTPS-Sitzung
konfigurieren.
SSH Dieser Weg bietet Ihnen die Möglichkeit per Kommandozeile auf die GSM-Appliance zuzugreifen
und die CLI und das GOS-Admin-Menü zu verwenden. Dieser Zugang ist per Default deaktiviert
und muss zunächst freigeschaltet werden. Dies kann z.B. über die serielle Konsole erfolgen.
OMP (OpenVAS Management Protocol) Das OpenVAS Management Protocol (OMP) erlaubt die Kommunikation mit weiteren Greenbone Produkten (z.B. einer weiteren GSM). Es kann auch für die
Kommunikation eigener Software mit der Appliance genutzt werden (siehe Abschnitt OpenVAS
Management Protokoll (OMP) (Seite 185)).
SNMP Der lesende Zugri auf den GSM ist via SNMPv3 möglich (siehe Abschnitt SNMP (Seite 28)).
5.6.1 HTTPS Timeout
Dieser Wert kann sowohl mit dem GOS-Admin-Menü (Remote/HTTPS Timeout) eingestellt werden als
auch auf der Kommandozeile. Auf der CLI nutzen Sie die Variable gos:var:webtimeout:
gsm: get webtimeout
s webtimeout 15
gsm: set webtimeout 1
gsm *: commit
32
gsm: get webtimeout
s webtimeout 1
Der Wert für den Timeout darf zwischen 1 und 1440 Minuten (1 Tag) betragen.
5.6.2 SSH-Zugang
Der SSH-Zugang kann ebenfalls über das GOS-Admin-Menü (Remote/SSH) als auch über die CLI eingestellt werden. Auf der CLI nutzen Sie die Variable ssh. Diese kann den Wert enabled oder disabled
einnehmen. Zusätzlich kann die Variable gelöscht werden:
gsm: get ssh
s ssh enabled
gsm: set ssh disabled
gsm *: commit
gsm: get ssh
s ssh disabled
Das GOS-Admin-Menü bietet zusätzlich die Möglichkeit, den Fingerprint des ö entlichen Schlüssels
der Appliance (Host-Key) anzuzeigen.
5.6.3 OpenVAS Management Protocol (OMP)
Das OpenVAS Management Protocol kann sowohl über das GOS-Admin-Menü (Remote/OMP) aktiviert
werden als auch über die CLI. Auf der CLI nutzen Sie hierzu die Variable public_omp:
gsm: get public_omp
s public_omp disabled
gsm: set public_omp enabled
gsm *: commit
gsm: get public_omp
s public_omp enabled
5.7 Upgrade und Feeds
Auf der Kommandozeile können Sie Systemupgrades durchführen und die Feed-Synchronisation konfigurieren. Hierzu stehen mehrere Kommandos und Variablen zur Verfügung.
5.7.1 Upgrade des Systems
Das Kommando systemupgrade führt ein Upgrade durch. Den Status können Sie mit
systemupgradestatus oder show schedule anzeigen.
Beachten Sie hierzu auch den Abschnitt Upgrade (Seite 41).
5.7.2 Feed Synchronisation
Um die Synchronisation des Feeds zu konfigurieren, stehen mehrere Variablen zur Verfügung:
feedsync, syncport und synctime. Alternativ ist die Konfiguration über das GOS-Admin-Menü unter Feed möglich.
feedsync Hiermit können Sie die automatische Synchronisation an- und abschalten.
syncport Hiermit definieren Sie den Port für den Synchronisation des Feeds. Dieser Port ist per
Default 24/tcp. Alternativ können Sie den Port 443/tcp nutzen. Andere Ports können nicht verwendet werden.
5.7. Upgrade und Feeds
33
Abb. 5.5: Konfiguration des Feeds
synctime Hiermit konfigurieren Sie die tägliche Uhrzeit für die Synchronisation des Feeds. Diese
sollte ausserhalb der normalen Nutzungszeit liegen. Außerdem ist der Zeitraum von 10:00 12:59 als Wartungsfenster des Feeds nicht nutzbar. Zeiten innerhalb dieses Fensters werden
daher abgelehnt. Die Zeiten verstehen sich immer als UTC.
gsm: get synctime
s synctime 06:25
gsm: set synctime 11:30
syntax error in value
gsm: set synctime 13:30
gsm *: commit
gsm: get synctime
s synctime 13:30
Alternativ kann der Feed auch auf der Kommandozeile gestartet werden. Hierzu verwenden Sie das
Kommando feedstartsync. Mit dem Kommando feedsyncstatus und feedversion können Sie
den aktuellen Zustand kontrollieren.
5.7.3 Proxy Konfiguration
In Abhängigkeit von der Netzwerkumgebung ist der Bezug der Feeds und Softwareupdates nur über
einen Proxy möglich. Für beide Informationen wird der Proxy über die folgende Variable konfiguriert:
• proxy_feed
Die Syntax für die Angabe des Proxies lautet http://proxy_ip[:port].
gsm: get proxy_feed
u proxy_feed
gsm: set proxy_feed http://1.2.3.4:3128
gsm *: commit
gsm: get proxy_feed
s proxy_feed http ://1.2.3.4:3128
Falls der Proxy eine Authentifizierung verlangt, kann diese über die Variable proxy_credentials
konfiguriert werden. Diese Variable erwartet den Benutzernamen und das Kennwort durch Doppelpunkt getrennt:
gsm: get proxy_credentials
u proxy_credentials
gsm: set proxy_credentials user:password
gsm *: commit
34
gsm: get proxy_credentials
s proxy_credentials user:password
Bemerkung: In Windows Umgebungen werden Benutzername und Kennwort wie folgt angegeben:
domain\user:password.
5.8 Verwaltung der Datenbank und der Scanner
Die Option Advanced im GOS-Admin-Menu bietet den Zugri auf die Verwaltung der internen Datenbank zu die Konfiguration zusätzlicher Schwachstellenscanner.
5.8.1 Datenbankverwaltung
Der GSM nutzt eine SQlite-Datenbank für die Speicherung der NVTs, Scan-Ergebnisse, Konfiguration,
etc. Mithilfe der Option Advanced/Database statistics kann der Admin Statistiken der Datenbank anzeigen. Diese Werte werden auch protokolliert und können über Advanced/Database statistics log
betrachtet werden.
Des Weiteren kann mit Hilfe der beiden Befehle VACUUM und ANALYZE die Datenbank optimiert werden. Beide Kommandos können mehrere Stunden für ihre Abarbeitung benötigen. Das ANALYZE Kommando sammelt statistische Informationen über die Tabellen und Indices. Diese werden in internen
Tabellen gespeichert und vom Query Optimizer genutzt, um die Anfragen besser planen und organisieren zu können. Das VACUUM Kommando erstellt die gesamte Datenbank neu. Hiermit lassen sich
speziell fragmentierte Datenbanken beschleunigen.
Das VACCUM Kommando zeigt die Ergebnisse der Optimierung nach seinem erfolgreichen Ende an.
Sep 28 14:56:22 gsm md main[18958]: Optimized: vacuum. Database file size reduced
by 85 MiB (55.9%)
5.8.2 Weitere Schwachstellenscanner
Die Option Advanced/Scanner Management erlaubt aktuell (3.1.19) lediglich die Anzeige der aktuell
unterstützten Schwachstellenscanner. Zukünftige GOS Versionen werden auch die Konfiguration der
folgenden Schwachstellenscanner erlauben:
• ANCOR
• Ovaldi
• Palo Alto
• w3af
• Fortinet
5.9 Überwachung und Fehlersuche
Es stehen verschiedene Werkzeuge für die Überwachung und Fehlersuche auf der GSM-Appliance zur
Verfügung. Die GSM-CLI bietet den Zugri auf einige UNIX-Befehle und -Dateien, die bei der Fehlersuche unterstützen können.
5.8. Verwaltung der Datenbank und der Scanner
35
Abb. 5.6: Konfiguration zusätzlicher OSP Scanner
5.9.1 Fehlersuche und Überwachung der Netzwerkfunktionen
Wenn der GSM nicht erreichbar ist oder nicht von allen Client-Systemen erreicht werden kann, müssen Sie die Netzwerkkonfiguration prüfen. Dies ist auch der Fall, wenn der GSM nicht alle Systeme
im Rahmen eines Scans erreichen kann. Hierzu können neben den Funktionen des GOS-Admin-Menüs
auch einige Kommandozeilenwerkzeuge genutzt werden.
Die folgenden Kommandos zeigen die aktuelle Netzwerkkonfiguration an:
getip Dieses CLI spezifische Kommando zeigt die aktuelle Netzwerkkonfiguration an. Intern nutzt es
das UNIX-Kommando ip addr show. Durch die Angabe einer bestimmten Netzwerkkarte kann
die Ausgabe auf diese beschränkt werden:
gsm: getip dev eth0
2: eth0: <BROADCAST ,MULTICAST ,UP ,LOWER_UP > mtu 1500 qdisc pfifo_fast state
UP qlen 1000
link/ether 52:54:00:98:36:5 f brd ff:ff:ff:ff:ff:ff
inet 192.168.155.108/24 brd 192.168.155.255 scope global eth0
inet6 fe80 :: dead:beef /64 scope link
valid_lft forever preferred_lft forever
inet6 fe80 ::5054: ff:fe98 :365f/64 scope link
getroute Dieses CLI spezifische Kommando zeigt die aktuelle IPv4-Routing-Tabelle an:
gsm: getroute
192.168.155.0/24 dev eth0 proto kernel scope link src&
192.168.155.108
default via 192.168.155.1 dev eth0
ntpq Dieses Kommando zeigt die konfigurierten NTP-Server und deren Kommunikationszustand an:
gsm: ntpq
remote refid st t when poll reach delay offset jitter
===========================================================================
+ptbtime1.ptb.de .PTB. 1 u 602 1024 377 14.477 -0.319 9.907
*ptbtime2.ptb.de .PTB. 1 u 44 1024 177 13.580 0.143 0.150
LOCAL (0) .LOCL. 10 l 11d 64 0 0.000 0.000 0.000
Die Zeile mit einem Stern (*) ist der aktuell präferierte NTP-Server. Die Zeile mit einem Plus (+)
kennzeichnet den Backup-NTP-Server.
ip Das UNIX-Kommando ip steht auch in der CLI für den lesenden Zugri der Netzwerkeigenschaften
zur Verfügung. Hiermit können Sie verschiedene Informationen anzeigen.
36
Anzeige der Netzwerkkarten Um eine Liste der Netzwerkkarten anzuzeigen, können Sie den
Befehl ip link show verwenden. Dieser Befehl zeigt Ihnen die verfügbaren Netzwerkkarten und ihre MAC-Adressen an:
gsm: ip link show
1: lo: <LOOPBACK ,UP ,LOWER_UP > mtu 16436 qdisc noqueue state UNKNOWN
mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST ,MULTICAST ,UP ,LOWER_UP > mtu 1500 qdisc pfifo_fast
state UP mode DEFAULT qlen 1000
Anzeige der IP-Adressen Um die Liste der IP-Adressen anzuzeigen, können Sie den Befehl ip
address show. Die Ausgabe entspricht dem Befehl getip.
gsm: ip link show
1: lo: <LOOPBACK ,UP ,LOWER_UP > mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
2: eth0: <BROADCAST ,MULTICAST ,UP ,LOWER_UP > mtu 1500 qdisc pfifo_fast
state UP qlen 1000
inet 192.168.155.180/24 brd 192.168.155.255 scope global eth0
inet6 fe80 ::5054: ff:fe98 :365f/64 scope link
Anzeige der Routen Um die Routing-Tabelle anzuzeigen, verwenden Sie den Befehl ip route
show. Die Ausgabe entspricht dem Befehl getroute. Die Anzeige der IPv6-Routen erfolgt
mit ip -6 route show.
gsm: ip -6 route show
2001:4 dd0:ff00:d58 ::1 dev eth0 metric 0 cache
2001:4 dd0:ff00:d58 ::/64 dev eth0 proto kernel metric 256
fe80 ::/64 dev eth0 proto kernel metric 256
default via 2001:4 dd0:ff00:d58 ::1 dev eth0 metric 1024
ARP- und Neighbor-Cache Der ARP-Cache enthält die MAC-Adressen der Systeme, mit denen
der GSM kürzlich direkt im LAN kommuniziert hat. Die Anzeige kann daher bei der Fehlersuche helfen, wenn der GSM ein System, welches sich im selben LAN befindet, nicht erreichen kann. Der Neighbor-Cache erfüllt dieselbe Aufgabe für IPv6-Adressen, wie sie der
ARP-Cache für IPv4-Adressen wahrnimmt. Auf dem GSM werden diese nicht mehr unterschieden und mit demselben Kommando angezeigt. Durch Angabe von -4 oder -6 kann die
Anzeige auf IPv4 oder IPv6 beschränkt werden:
gsm: ip neigh show
fe80 ::216:47 ff:fe7d :11c3 dev eth0 lladdr 00:16:47:7d:11: c3 router STALE
192.168.222.1 dev eth0 lladdr 00:16:47:7d:11: c3 REACHABLE
Überwachung des IP-Stacks Mit dem Kommando ip können auch Änderungen der RoutingTabelle, des ARP- und Neighbor-Caches und der Netzwerkkarten überwacht werden. Hierzu rufen Sie den Befehl ip monitor all auf. Alternativ können nur einzelne Subsysteme
(link, address, route, mroute, neigh, netconf) überwacht werden. Um die Überwachung abzubrechen, geben Sie Strg-C ein.
gsm: ip monitor all
[ROUTE]ff02 ::1 dev eth0 metric 0
cache
[ROUTE ]2 a01 :198:5 a1 :201: d6ae :52ff:fe96:fe9b via 2001:4
dd0:ff00:d58 ::1 dev eth0 metric 0
cache
[ROUTE ]2001:4 dd0:ff00:d58 ::1 dev eth0 metric 0
cache
5.9. Überwachung und Fehlersuche
37
[ROUTE]Deleted 2a01 :198:5 a1 :201: d6ae :52ff:fe96:fe9b via 2001:4
dd0:ff00:d58::1 dev eth0 metric 0
cache
[ROUTE ]2 a01 :198:5 a1 :255:5054: ff:fec3 :7266 via 2001:4
dd0:ff00:d58 ::1 dev eth0 metric 0
cache
[LINK ]4: eth1: <NO -CARRIER ,BROADCAST ,MULTICAST ,UP >
link/ether
Link-Status einer Netzwerkkarte Um den Link-Status einer Netzwerkkarte zu prüfen, bietet
der GSM das Kommando ethtool. Dieses Kommando erwartet zusätzlich den Namen der
Netzwerkkarte und kann anschließend die Konfiguration und den aktuellen Zustand anzeigen. Für die Fehlersuche interessant sind der ausgehandelte Modus und Geschwindigkeit
und der aktuelle Link-Status.
gsm: ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10 baseT/Half 10 baseT/Full
100 baseT/Half 100 baseT/Full
Supported pause frame use: No
Supports auto - negotiation: Yes
Advertised link modes: 10 baseT/Half 10 baseT/Full
Advertised pause frame use: Symmetric
Advertised auto - negotiation: Yes
Link partner advertised link modes: 10 baseT/Half 10 baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto - negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver : internal
Auto - negotiation: on
Supports Wake -on: pumbg
Wake -on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
38
KAPITEL 6
Betrieb
Dieses Kapitel beschäftigt sich mit dem Betrieb der Greenbone Security Manager Appliance und betrachtet die wichtigsten Aspekte, die im Betrieb auftreten. Dieses Kapitel beleuchtet erste Schritte
der Benutzerverwaltung. Außerdem wird der Upgrade der Appliance direkt aus dem Internet als auch
über den Airgap Modus besprochen. Schließlich gehört auch die Sicherung und Wiederherstellung der
Daten zu den Themen dieses Kapitels.
6.1 Benutzerverwaltung
Die Greenbone Security Manager Benutzerverwaltung erlaubt die Erzeugung und Verwaltung der Benutzer mit unterschiedlichen Rollen und Berechtigungen. Der erste Benutzer wird immer bereits während der Initialisierung der GSM Appliance auf der Kommandozeile mit dem GOS-Admin-Menü erzeugt. Nach der Anmeldung mit diesem Benutzer können weitere Benutzer angelegt und verwaltet
werden.
Dabei unterstützt die GSM Benutzerverwaltung ein rollenbasiertes Rechtekonzept bei dem Zugri
auf die Weboberfläche. Einige Rollen sind bereits von Werk angelegt. Weitere Rollen können jedoch
von einem Administrator erzeugt und verwendet werden. Die Rolle definiert, welche Funktionen der
Weboberfläche von dem Benutzer eingesehen und modifiziert werden dürfen. Dabei sind die Rollen
nicht in der Weboberfläche, sondern in dem darunterliegenden OMP-Protokoll realisiert und wirken
sich daher auf alle OMP-Clients aus. Lesender und modifizierender Zugri kann getrennt den Rollen
zugewiesen werden.
Neben den Rollen unterstützt die GSM Benutzerverwaltung auch Gruppen. Gruppen erlauben die Zusammenfassung von Benutzern. Dies dient in erster Linie der logischen Gruppierung. Neben einer Verwaltung der Rechte über die Rollen können auch Gruppen entsprechende Privilegien zugewiesen werden.
Zusätzlich kann über die Benutzerverwaltung jedem Benutzer ein Bereich von IP-Adressen zugewiesen werden, dessen Scan erlaubt oder verboten ist. Die GSM Appliance weigert sich dann andere als
die angegebenen IP-Adressen durch den entsprechenden Benutzer zu scannen. Auch der Zugri auf
bestimmte Schnittstellen der GSM-Appliance kann erlaubt bzw. verboten werden.
Der Greenbone Security Manager bietet für die Verwaltung der Rollen und spezifischen Privilegien
der Benutzer eine eigene Benutzerverwaltung. Um jedoch Kennwörter nicht mehrfach vorhalten zu
müssen und eine Kennwortsynchronisation zu erlauben, bietet der Greenbone Security Manager die
Anbindung des Systems an einen zentralen LDAP-Server. Dieser wird dann aber nur für die Überprüfung des Kennworts bei der Anmeldung des Benutzer genutzt. Alle weiteren Einstellungen erfolgen
in der Benutzerverwaltung der GSM Appliance.
Die folgenden Seiten betrachten nur die Erzeugung einzelne Benutzer. Die Verwaltung der Rechte,
Gruppen und Rollen wird in Kapitel Benutzer- und Rechteverwaltung (Seite 171) betrachtet.
39
Der Dialog für die Erzeugung und Verwaltung der Benutzer ist über das Menü Administration erreichbar. Dieser Menüpunkt ist nur für Administratoren sichtbar, da nur diese Benutzer zunächst weitere
Benutzer anlegen und verwalten dürfen. Die Erzeugung eines neuen Benutzers wird durch Anklicken
begonnen. Die Modifikation eines existierenden Benutzers
des weissen Sterns auf blauen Grund
wird durch das Schraubenschlüssel-Icon angestossen.
Bei der Anlage eines neuen Benutzers sind die folgenden Angaben möglich:
Abb. 6.1: Anlegen eines neuen Benutzers
• Login Name: Dies ist der Name, mit dem sich der Benutzer anmeldet. Wenn ein LDAP-Server als
zentraler Kennwortspeicher genutzt wird, muss der Benutzer mit dem identischen Namen (rDN)
im LDAP-Server angelegt sein. Der Name darf maximal 80 Zeichen lang sein und aus Buchstaben
und Zi ern bestehen.
• Password: Dies ist das Kennwort des Benutzers. Das Kennwort darf maximal 40 Zeichen aufweisen und aus beliebigen Buchstaben bestehen. Achten Sie darauf, dass, wenn Sie Sonderzeichen
verwenden, diese auf allen Tastaturen und Betriebssystemen, die Sie einsetzen, auch erreichbar
sind.
• Roles (optional): Jeder Benutzer darf mehrere Rollen besitzen. Die Rollen definieren die Rechte
des Benutzers bei der Verwendung des OMP Protokolls. Da der Greenbone Security Assistant das
OMP-Protokoll nutzt, definieren die Rollen auch direkt die Möglichkeiten in der Weboberfläche.
Während Sie weitere Rollen hinzufügen und konfigurieren können, stehen zu Beginn einige eingebaute Rollen zur Verfügung. Diese Rollen werden in dem Abschnitt Benutzerrollen (Seite 173)
genauer betrachtet.
• Groups (optional): Jeder Benutzer kann Mitglied mehrerer Gruppen sein. Auch über die Gruppen
kann eine Rechteverwaltung erfolgen (siehe Abschnitt Permissions (Seite 179))
• Host Access: Hier können Sie definieren, welche Rechner ein bestimmter Benutzer in einem
Scan analysieren darf und welche Rechner nicht in einem Scan berücksichtigt werden. Diese
Einschränkungen können auch für Administratoren eingerichtet werden. Diese können jedoch
auch selbst die Einschränkungen wieder aufheben. Daher ist diese Funktion bei Administratoren lediglich zum Selbstschutz. Normale Benutzer (User) bzw. andere Rollen ohne Zugri auf die
Benutzerverwaltung können diese Einschränkungen jedoch nicht umgehen. Hierbei können Sie
grundsätzlich zwischen einer Whitelist (Deny all and allow) und einer Blacklist (Allow all and
deny) wählen. Im ersten Fall ist der Scan sämtlicher Rechner grundsätzlich verboten und nur
explizit aufgeführte Systeme dürfen gescannt werden. Im zweiten Fall ist der Scan sämtlicher
Systeme mit Ausnahme der aufgeführten Systeme erlaubt. Es können sowohl Rechnernamen als
auch IPv4- und IPv6-Adressen angegeben werden. Ferner können sowohl einzelne IP-Adressen
als auch Adressbereiche und Netzwerksegmente spezifiziert werden. Die folgende Auflistung
gibt hierfür einige Beispiele:
– 192.168.15.5 (IPv4-Adresse)
40
Kapitel 6. Betrieb
– 192.168.15.5-192.168.15.27 (IPv4-Bereich Langform)
– 192.168.15.5-27 (IPv4-Bereich Kurzform)
– 192.168.15.128/25 (CIDR-Notation)
– 2001:db8::1 (IPv6-Adresse)
– 2001:db8::1-2001:db8::15 (IPv6-Bereich Langform)
– 2001:db8::1-15 (IPv6 Bereich Kurzform)
– 2001:db8::/120 (CIDR-Notation)
Sämtliche Optionen können beliebig gemischt und als kommaseparierte Liste angegeben werden. Die Netzmaske in der CIDR-Notation ist jedoch auf maximal 20 bei IPv4 und 116 bei IPv6
beschränkt. In beiden Fällen resultieren hieraus maximal 4096 IP-Adressen.
Abb. 6.2: Anzeigen des Benutzers
• Interface Access: Hier können Sie definieren, über welche Netzwerkkarten ein Anwender einen
Scan ausführen darf. Hier können Sie eine kommaseparierte Liste von Netzwerkkarten angeben
und ähnlich wie bei dem Host Access zwischen einem Whitelist und einem Blacklist-Verfahren
wählen.
Tipp: Generell sollte die Whitelist-Methode genutzt werden um den Scan sämtlicher nicht spezifisch
erlaubter Systeme zu verbieten. Damit ist sichergestellt, dass die Benutzer nicht Systeme außerhalb
ihrer Zuständigkeit, im Internet oder durch den Scan negative beinflussbare Systeme scannen.
Nach der Anlage des Benutzers werden dessen Eigenschaften angezeigt. Sie sollten diese Anzeige
kontrollieren um sicherzustellen, dass Sie dem Benutzer nicht zu viele Privilegien zugewiesen haben.
6.2 Upgrade
Innerhalb der Subskription stellt Greenbone auch Updates der GSM Appliance bereit. Diese Updates
werden regelmäßig bereitgestellt. Die Anwender können selbst entscheiden ob und wann die Updates
eingespielt werden. Die folgenden Zahlen basieren auf den verö entlichten Updates der letzten 5
Jahre und der Erfahrung des Support-Teams bei der Unterstützung von Kunden während des Updates.
Es gibt drei verschiedene Updatetypen:
• Patch-Level Upgrades (z.B. von Version 3.0.16 auf 3.0.17)
– ca. 1 pro Monat
– einige empfohlen, einige kritisch (sicherheitsrelevant)
– 10 min pro Master-GSM
• Release Upgrades (z.B. von Version 3.0.16 auf 3.1.0)
– ca. 1-2 pro Jahr
– nach Wunsch oder bei Ende der Lebensdauer
6.2. Upgrade
41
– 2-6 Stunden (abhängig davon, ob weitere Konfigurationsänderungen erforderlich sind oder
die Anwender über die Änderungen informiert werden müssen)
• LTS Release Upgrade
– ca. 1 alle 2 Jahre
– erforderlich da das Ende der Lebensdauer erreicht wurde
– ca. 1-2 Tage (abhängig davon, ob Konfigurationsänderungen erforderlich sind oder die Anwender über die Änderungen informiert werden müssen.)
• Generation Upgrades (z.B. von Version 2.2.9 auf 3.1.0)
– ca. 1 alle 2 Jahre
– nach Wunsch oder bei Ende der Lebensdauer
– ca. 1-2 Tage (abhängig davon, ob Konfigurationsänderungen erforderlich sind oder die Anwender über die Änderungen informiert werden müssen.)
Diese Upgrades werden nicht automatisch durchgeführt. Der Benutzer muss die Upgrades manuell
anstoßen.
Die erforderlichen Schritte in einem Upgrade sind auch in einem Video erläutert:
http://docs.greenbone.net/Videos/gos/en/GSM-Upgrade-en-20150703.mp4.
Wenn Sie sowohl über Master-GSM als auch Slave-GSM verfügen sind die folgenden Hinweise wichtig:
• Sensoren werden durch den Master automatisch aktualisiert.
• Slaves müssen manuell aktualisiert werden. Dabei sollten immer zuerst die Master und dann
die Slaves aktualisiert werden. So funktioniert das dann auch im Airgap-Betrieb.
• Zwei GSM mit unterschiedlichen Patchlevel können zusammenarbeiten. Dies ist aber nicht unterstützt.
• Unterschiedliche Release-Versionen auf Master und Slave sind nicht möglich!
6.2.1 Prüfen der aktuellen Version
Um die aktuelle Version zu prüfen, genügt es, sich mit der Konsole Ihrer GSM-Appliance zu verbinden.
Sie müssen sich hierzu nicht einmal anmelden. Die Willkommensmeldung Ihrer GSM führt die aktuelle
Version direkt im Namen. Alternativ können Sie den Befehl softwareversion aufrufen, der dieselbe
Ausgabe erzeugt.
Welcome to the Greenbone OS 3.1.6 running on a Greenbone Security Manager
Web Interface available at : https ://192.168.155.100
gsm login :
Ebenso können Sie die Anmeldemaske des Webinterfaces prüfen. Hier wird ebenfalls unten rechts die
aktuelle Version angezeigt.
Alternativ können Sie sich auch auf der Kommandozeile, z.B. via SSH, anmelden und die Version in
dem GOS-Admin-Menü prüfen. Unter Upgrade wird direkt eine neue Version angezeigt. Die aktuell
installierte Version wird als Current angezeigt. Available zeigt die letzte während des letzten FeedUpdates bereits heruntergeladene Version an. Mit der Option Sync kann auch in diesem Moment die
auf den Greenbone Servern verfügbare Version geprüft und heruntergeladen werden.
42
Kapitel 6. Betrieb
6.2.2 Durchführung des Patch-Level Upgrades
Bevor Sie ein Upgrade durchführen, ist es ratsam, sich über die Änderungen, die mit dem Upgrade
einhergehen, zu informieren. Hierzu dokumentiert Greenbone sämtliche durch das Upgrade durchgeführten Änderungen auf http://www.greenbone.net/technology/gos_release_history.html.
Außerdem sollten Sie vor einem Upgrade ein Backup Ihrer GSM durchführen. Die Vorgehensweise für
das Backup ist in Abschnitt Sicherung und Wiederherstellung (Seite 45) beschrieben. Sinnvoll ist ein
Backup der gesamten Appliance auf der internen Backup-Partition falls die Appliance dies unterstützt.
Weiterhin sollten Sie für das Upgrade einen Zeitpunkt auswählen, zu dem keine Scans aktiv ausgeführt
oder gestartet werden. Möglicherweise werden durch das Upgrade einzelne Systemdienste neugestartet. Hierdurch können die Scanergebnisse verloren gehen und die Geschwindigkeit des Upgrades
eingeschränkt werden.
Ein Patch-Level-Upgrade sollte üblicherweise nach wenigen Minuten abgeschlossen sein. Im Anschluss ist ein Reboot nicht zwingend aber empfehlenswert.
Das Upgrade wird über das GOS-Admin-Menü gestartet. Hierzu rufen Sie das GOS-Admin-Menü und
dann den Menüpunkt Upgrade auf.
Abb. 6.3: Das GOS-Admin-Menü zeigt die Verfügbarkeit neuer Versionen an.
Abb. 6.4: Die Suche nach Updates kann jederzeit angestossen werden.
Über den Menüpunkt Sync kann jederzeit die Verfügbarkeit neuer Versionen geprüft werden. Dadurch
wird eine neue Software-Synchronisation im Hintergrund gestartet. Die Upgrade-Funktionen sind
6.2. Upgrade
43
dann vorübergehend nicht verfügbar. Über die Auswahl des Menüpunkts Refresh können Sie die Anzeige aktualisieren. Die Synchronisation der verfügbaren Upgrades kann einige Minuten dauern, da in
diesem Rahmen die erforderlichen Daten für ein mögliches Upgrade heruntergeladen wird.
Anschließend kann über den Menüpunkt Upgrade das Upgrade ausgeführt werden. Dieser Vorgang
dauert in der Regel nur wenige Minuten, sollten ein Sprung über zahlreiche Patch-Level Versionen erfolgen ggf. einige Minuten mehr. Das Upgrade wird ebenfalls im Hintergrund angefordert. Bis zum eigentlichen Start des Upgrades können noch einige Minuten vergehen. Solange zeigt das GOS-AdminMenü den Text System upgrade is scheduled an. Sobald das Upgrade durchgeführt wird, ändert sich die Ausgabe des GOS-Admin-Menü in System Upgrade is in progress. Einige Minuten
später ändert sich die Angabe der Current Version. Jedoch ist das Upgrade noch nicht abgeschlossen
solange die Anzeige noch den System Upgrade anzeigt.
Abb. 6.5: System Upgrade in Progress
Nach dem Abschluss sollte ein Reboot erfolgen.
6.2.3 Release Upgrade
Ein Release-Wechsel wird nicht im GOS-Admin-Menü angezeigt. Über einen Release-Wechsel informiert Greenbone via Newsletter und auf der Website. Rufen Sie dann im GOS-Admin-Menü den Unterpunkt Switch Release auf. Dieser wird dann nach einer Warnmeldung das verfügbare Release anzeigen und für Sie von den Greenbone Feed Servern herunterladen. Dieser Vorgang benötigt in Abhängigkeit Ihrer Internetverbindung bis zu einer Stunde. Anschließend wird Ihnen die neue Version im
GOS-Admin-Menu zum Upgrade angeboten und Sie führen den Release-Wechsel analog zum PatchLevel-Upgrade durch.
Hierbei ist im Anschluss ein Reboot verpflichtend. Das Upgrade kann auch einige Stunden in Anspruch
nehmen. Während des Upgrades sollten Sie keine Scans durchführen oder starten.
6.2.4 Verwendung eines Proxies
Falls die GSM Appliance nicht direkt auf das Internet zugreifen kann und einen Proxy benutzen muss,
muss dieser auf der GSM Appliance eingerichtet werden. Starten Sie das GOS-Admin-Menü und wählen Sie die Feed‘Option aus. Wählen Sie dann die Option :gos:menu:‘Proxy Feed. Hier können Sie den
Proxy eintragen. Stellen Sie sicher, dass Sie eine gültige HTTP-URL verwenden. Namen als auch IPAdressen dürfen verwendet werden.
http://proxy.mycompany.com:3128
http://192.168.15.5:3128
44
Kapitel 6. Betrieb
Abb. 6.6: Release Upgrade
Um die Daten für eine Anmeldung am Proxy einzugeben, wählen Sie im gleichen Menü Credentials.
Diese Proxy-Konfiguration wird sowohl für die Feeds als auch für die GOS Updates genutzt.
6.3 Sicherung und Wiederherstellung
Eine regelmäßige Sicherung der GSM-Appliance und der von Ihnen erzeugten Daten stellt sicher, dass
Sie bei Ausfall der Appliance nach Tausch durch Greenbone die neue Appliance schnell wieder in Betrieb nehmen können. Darüberhinaus sollten Sie zur Sicherheit vor jedem Update eine Sicherung des
Systems durchführen. Hierzu stehen Ihnen grundsätzlich drei verschiedene Varianten des Backups
zur Verfügung:
• Backup des gesamten Systems (SystemBackup)
• Snapshot des gesamten Systems (SystemSnapshot)
• Backup der von Ihnen erzeugten und angepassten Daten (Userdata). Dies enthält alle von Ihnen
erzeugten Scankonfigurationen, Benutzer, Overrides, etc.
Ein Backup des gesamten Systems ist vor jedem Update der GSM-Appliance ratsam. Damit stellen
Sie sicher, dass Sie bei einem Fehler des Updates die GSM-Appliance wieder in den Ausgangszustand
zurückversetzen können.
Ein Backup der Userdata sollte durch Sie regelmäßig durchgeführt werden. Mit diesem Backup sind Sie
in der Lage, bei einem Ausfall der Appliance nach ihrem Austausch durch Greenbone Ihre Konfiguration
wiederherzustellen. Zusätzlich ist dieses Backup ebenfalls vor jedem Update ratsam.
Die folgenden Abschnitte erläutern die einzelnen Schritte.
6.3.1 Backup des gesamten Systems
Wie das Backup des gesamten Systems durchgeführt wird, hängt von der eingesetzten Appliance
ab. Die GSM ONE und der GSM 25V sind virtuelle Appliances. Hier können daher recht einfach die
Backup-Möglichkeiten des Hypervisors genutzt werden. Der Hypervisor unterstützt hierzu zum Beispiel Snapshot-Funktionalitäten, mit denen der aktuelle Zustand sogar im laufenden System gesichert werden kann und bei Bedarf wiederhergestellt wird. Für den GSM 25 und GSM 100 wird ein
Backup des gesamten Systems nicht unterstützt.
6.3. Sicherung und Wiederherstellung
45
Alle weiteren Systeme (GSM 500 und aufwärts) verfügen über eine Backup-Partition. Diese BackupPartition kann genau ein Komplett-Backup der Appliance speichern. Ein inkrementelles Backup oder
das Vorhalten von mehreren Varianten wird nicht unterstützt.
Um ein Komplett-Backup durchzuführen, rufen Sie auf der Konsole das GOS-Admin-Menü auf. Hier
wählen Sie den Menüpunkt Backup. In dem nun erscheinenden Menü gibt es die Option Create System
Backup und Restore System Backup.
Abb. 6.7: Das Komplett-Backup wird aus dem GOS-Admin-Menü gestartet.
Mit Create System Backup starten Sie den Backup-Vorgang. Die GSM Appliance wird anschließend
innerhalb der nächsten 10 Minuten rebooten (meist sofort) und ihr System in der Backup-Partition sichern. Dieser Vorgang dauert etwa 30-60 Minuten. Daher müssen Sie ein entsprechendes Wartungsfenster vorsehen und werden vor dem Start aufgefordert, diesen Vorgang zu bestätigen.
Abb. 6.8: Das Backup benötigt einige Zeit.
Während die Appliance auf den Reboot wartet, sind weitere Aktionen im Backup-Menü nicht mehr
verfügbar.
Die Wiederherstellung der GSM-Appliance aus einem Komplett-Backup erfolgt ebenfalls mit Hilfe des
GOS-Admin-Menüs. Hierzu rufen Sie den Menüpunkt Restore from Partition auf. Sie benötigen ebenfalls ein Wartungsfenster von 30-60 Minuten und die Appliance führt wieder einen Reboot durch. Sie
werden ebenfalls aufgefordert den Vorgang zu bestätigen, da es hierbei auch zu Datenverlust kommen kann.
Bemerkung: Falls Sie seit dem letzten Backup Ihre Anwenderdaten angepasst haben, neue Scankon46
Kapitel 6. Betrieb
Abb. 6.9: Nachdem das Backup gescheduled wurde, sind andere Optionen bis zum Neustart nicht mehr
verfügbar.
figurationen, Tasks oder Overrides erzeugt haben, werden diese überschrieben. Daher sollten Sie vor
der Wiederherstellung im Zweifelsfall auch noch Ihre Nutzerdaten sichern!
6.3.2 Snapshot des Systems
Das Snapshot Backup ist eine weitere Alternative um ein Backup des gesamten Systems zu erstellen.
Der Systemsnapshot ist jedoch nur bei einzelnen Appliances möglich (z.B. 5xx aber nicht 6xx). Sowohl das Systembackup als auch der Systemsnapshot erstellen ein komplettes Backup der Partition.
Jedoch überschreiben sich die beiden Backups nicht. Das heißt Sie können praktisch zwei (Backup)Zustände speichern (bei einer GSM 5xx). Bei der GSM 600 ist z.b. nur das Systembackup möglich.
Um das Erzeugen des Systemsnapshots zu starten, wechseln Sie auf die Kommandozeile und geben
das Kommando systemsnapshot ein. Anschließend wird die GSM Appliance booten und den Snapshot erzeugen.
Bei den GSM 5xx können Sie sowohl das Snapshotbackup als auch das Systembackup anlegen.
Die Wiederherstellung eines System Snapshot Backups erfolgt über das Grub-Boot-Menü. Verbinden
Sie sich mithilfe einer seriellen Schnittstelle oder eines VGA-Monitors.
Führen Sie einen Reboot durch. Im Grub Menü (vor dem GOS Boot) sollte nun der Menüpunkt angezeigt
werden. Wählen Sie diese Option aus. Das System bootet nun in den Snapshot.
6.3.3 Backup der Userdata mit USB-Stick
Die Sicherung der Anwenderdaten erfolgt auf allen GSM Appliances identisch. Die GSM Appliance unterstützt die direkte Sicherung der Anwenderdaten auf der GSM Appliance. Die Datei kann anschließend auf einem USB-Stick oder einem entfernten SSH-Server kopiert werden. Auf diese Weise sind die
Daten auch bei Ausfall der Appliance verfügbar. Um die Daten auf einem USB-Stick zu speichern, sind
zwei Schritte erforderlich:
1. Sicherung der Userdaten
2. Kopieren der Sicherung auf den USB-Stick
Der gleiche Prozess wird in umgekehrter Reihenfolge bei der Wiederherstellung der Anwenderdaten
durchlaufen. Zunächst werden die Daten von dem USB-Stick oder dem entfernten SSH-Server auf die
Appliance kopiert. Anschließend können die Daten wiederhergestellt werden.
Die folgenden Abschnitte erläutern die einzelnen Schritte.
47
Die
Sicherung
wird
auch
innerhalb
des
folgenden
http://docs.greenbone.net/Videos/gos/en/GSM-Upgrade-en-20150703.mp4.
Videos
erläutert:
Als erstes melden Sie sich auf der Appliance z.B. via SSH an. Starten Sie das GOS-Admin-Menü und
wählen Sie Backup. Nach der Auswahl von Userdata Backup sehen Sie das entsprechende Menü. Während der eigentlichen Sicherung werden die anderen Optionen bis zum Abschluss deaktiviert. Ansonsten kann das System wie gewohnt genutzt werden. Ein Wartungsfenster ist nicht erforderlich. Ein
Reboot ist ebenfalls nicht erforderlich.
Abb. 6.10: Das Backup der Userdaten kann im laufenden Betrieb erfolgen.
Im Gegensatz zum Komplett-Backup können mehrere Versionen der Userdata-Backups auf der Appliance vorgehalten werden. Diese werden immer unter einem Namen mit dem folgenden Aufbau gespeichert:
<gsf-number>-<date><time>.gsmb
201309161-201406180807.gsmb
Auf der Appliance werden die Backups in dem Verzeichnis /var/gsm/backups/userdata/ gespeichert.
Die gesicherten Daten können nun auf einen USB-Stick oder einen SSH-Server kopiert werden. Der
USB-Stick muss hierzu genau eine primäre Partition mit dem VFAT-Dateisystem aufweisen. Dies ist
bei den meisten USB-Sticks die Werkseinstellung. Nachdem der USB-Stick eingesteckt wurde, müssen Sie einige Sekunden warten, bis der USB-Stick erkannt wurde. Dann können Sie seinen Inhalt mit
der Menü-Option Show USB contents anzeigen. Die Ausführung dieses Kommandos dauert einige Sekunden.
Abb. 6.11: Ein leerer USB-Stick enthält noch keine Dateien.
Nun können Sie die Userdaten auf den Stick kopieren. Hierzu wählen Sie den Menüpunkt Copy Userdata to USB. Anschließend können Sie das zu übertragene Backup wählen.
Falls die Datei bereits auf dem USB-Stick existiert, werden Sie gefragt, ob die Datei umbenannt, überschrieben oder übersprungen werden soll:
48
Kapitel 6. Betrieb
Abb. 6.12: Wählen Sie das zu kopierende Backup aus.
Long file name "201309161 -201406180807. gsmb " already exists .
a) utorenmae A) utorename - all r) rename R) ename - all o) verwrite O) verwrite - all
s) kip S) kip q) uit ( aArRoOsSq ):
Nachdem die Daten auf den Stick kopiert wurden, kann erneut der Inhalt des Stick angezeigt werden
(siehe Abbildung Nach dem Kopiervorgang wurden die Daten übertragen. (Seite 49)). Sie können auch
den USB-Stick anschließend direkt entfernen.
Um Daten von dem Stick zurückzuspielen, rufen Sie im GOS-Admin-Menü den Unterpunkt Backup gefolgt von Copy Userdata from USB auf. Nach wenigen Sekunden wird Ihnen die Auswahl der auf dem
USB-Stick verfügbaren Backups angeboten. Nachdem Sie eine der Versionen mit OK bestätigt haben,
wird diese wieder auf die GSM-Appliance kopiert.
Abb. 6.13: Nach dem Kopiervorgang wurden die Daten übertragen.
Abb. 6.14: Userdata-Backups können von dem USB-Stick auf die Appliance kopiert werden
49
Anschließend können sie mit Restore Userdata die Daten wiederherstellen. Hierbei werden Sie gewarnt, dass bei der Wiederherstellung der alten Daten alle aktuellen Daten gelöscht werden. Falls Sie
diese vorher sichern möchten, können Sie dies tun. Eine Zusammenführung von mehreren UserdataBackups ist jedoch nicht möglich.
Abb. 6.15: Userdata-Backups können nach der Übertragung vom USB-Stick wieder hergestellt werden.
Abb. 6.16: Userdata-Backups können nach der Übertragung vom USB-Stick wieder hergestellt werden.
Tipp: Falls Sie nur einzelne Informationen wie zum Beispiel eine Scan-Konfiguration sichern möchten,
können Sie diese auch über das Web-Interface exportieren und in einer anderen Appliance wieder
importieren.
6.3.4 Backup der Userdata via SSH
Die Sicherung der Anwenderdaten kann auch via SSH erfolgen. Hierzu ist der SSH-Zugri auf ein entferntes System erforderlich. Um die Sicherung via SSH zu konfigurieren, starten Sie das gos-adminmenu und rufen Backup und anschließend Configure Server auf. Dort nehmen Sie die folgenden Einstellungen vor:
Backup server user Dies ist der Benutzer, mit dem Sie sich auf dem entfernen System anmelden können, um die Backups zu übertragen.
Backup server password Dies ist das Kennwort des oben angegebenen Benutzers.
50
Kapitel 6. Betrieb
Backup server address Dies ist die IP-Adresse des Backup-Servers.
Backup server fingerprint Hier müssen Sie die MD5-Prüfsumme des Host-Keys des Backup-Servers
eingeben. Diesen MD5-Prüfsumme können Sie auf dem Backup-Server mit folgenden Befehl
auslesen: Dieser Fingerprint muss ohne Doppelpunkte eingetragen werden (siehe Abbildung Via
Fingerprint des Host-Keys wird die Identität des Backup-Servers geprüft. (Seite 51)).
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
2048 03:82:81:ff:36:b3:b6:03:df:ed:4a:e9:fa:2d:6a:5d
root@station100 (RSA)
Remote backup directory Hier geben Sie das Verzeichnis ein, in dem die Sicherung auf dem Zielsystem gespeichert wird.
Abb. 6.17: Via Fingerprint des Host-Keys wird die Identität des Backup-Servers geprüft.
Nun müssen Sie eine Sicherung erzeugen und auf das Zielsystem mit Userdata Backup kopieren.
Eine automatische Übertragung ist noch nicht vorgesehen.
6.4 Airgap Update
Die Airgap-Funktion bietet einer GSM-Appliance, die keine direkte Verbindung zum Internet besitzt,
dennoch eine Aktualisierung mit Feeds und Updates. Hierzu benötigen Sie zwei GSM-Appliances. Eine
dieser Appliances befindet sich in einem gesicherten Bereich und verfügt über keine Verbindung zum
Internet. Die zweite Appliance muss über eine Verbindung zum Internet verfügen.
Für die Airgap Funktion stehen zwei Wege zur Verfügung:
• Greenbone Airgap USB Stick
• Airgap FTP-Server
Beide Varianten werden in den folgenden Abschnitten vorgestellt.
Bemerkung: Bitte prüfen Sie in der Übersicht der GSM Modelle (GSM Übersicht (Seite 3)), welche Modelle die Airgap Funktionalität unterstützen.
6.4.1 Airgap via USB Stick
Die Feeds und Updates werden hierbei von der mit dem Internet verbundenen GSM geladen und auf
einen USB-Stick kopiert. Dieser kann dann genutzt werden, um die zweite Appliance zu aktualisieren.
Der USB-Stick kann zuvor mit einem Security Gateway auf möglichen Schadcode analysiert werden.
6.4. Airgap Update
51
Abb. 6.18: Mit der Airgap-Funktion können die Aktualisierungen für GSM, die nicht mit dem Internet
verbunden sind, bereitgestellt werden.
Nach der Einrichtung der Airgap-Funktionalität ist keinerlei Anmeldung an den Appliances erforderlich. Die Kommunikation erfolgt komplett über das LCD-Display und kann von beliebigem Personal
durchgeführt werden. Dieses muss lediglich einmal täglich den USB-Stick vom Airgap-Master abziehen und in den Airgap-Slave einstecken. Nach wenigen Minuten wird er dann über das Display aufgefordert den Stick vom Airgap-Slave wieder abzuziehen und wieder in den Airgap-Master einzustecken.
Die Airgap-Funktion kann nur mit speziellen von Greenbone bereitgestellten USB-Sticks genutzt werden. Wenden Sie sich unter Angabe Ihrer Kundennummer an Greenbone um einen entsprechenden
Stick anzufordern.
Um die Airgap-Funktion mit dem entsprechenden Stick zu nutzen, müssen Sie Ihre GSM-Appliances
entsprechend konfigurieren und die Rollen als Airgap Master und Airgap Slave zuweisen. Hierzu rufen
Sie das GOS-Admin-Menü auf und wechseln in das Menü Feed. Hier scrollen Sie bis zum Punkt Airgap
management und rufen diesen auf.
Abb. 6.19: Das Airgap-Management ist in einem eigenen Untermenü verborgen.
52
Kapitel 6. Betrieb
Abb. 6.20: Die Airgap-Role kennzeichnet die Funktion der GSM-Appliance in dem Airgap- Vorgang.
Abb. 6.21: Mögliche Werte sind master und slave.
Tragen Sie bei der Rolle entsprechend der Rolle in dem Verfahren entweder master oder slave ein.
Der Master wird nun bei jedem kommenden täglichen Update ein spezielles Update-Paket bauen und
auf dem Stick hinterlegen. Dieser Vorgang kann über das Display verfolgt werden.
Während der Master den USB-Stick beschreibt, zeigt er die Nachricht Airgap Master U1 updating
USB... und anschließend Airgap Master U2 USB stick ready an. Sobald der Master USB MEM PRESEND ok to remove!. anzeigt, kann der USB-Stick entfernt und zum Slave getragen werden.
Der Slave erkennt den Stick automatisch und lädt das Update von dem Stick. Hierbei protokolliert er
dies im Display mit Airgap Slave DL1 updating from USB. und Airgap Slave S0 ........ Sobald auch hier
die Meldung USB MEM PRESENT ok to remove!. angezeigt wird, kann der Stick abgezogen und zurück
in den Master eingesteckt werden.
6.4.2 Airgap via FTP
Alternativ können Sie die Feed-Updates durch einen eigenen FTP-Server zur Verfügung stellen. Dabei
übernimmt der FTP-Server die Funktion des USB-Sticks. Sie benötigen also auch zwei GSM:
• Der Master holt den Feed aus dem Internet und schreibt ihn auf den FTP-Server.
• Der Slave bezieht den Feed von dem FTP-Server.
Auf dem Master müssen Sie das Menü Airgap management wechseln (siehe Abbildung Das AirgapManagement ist in einem eigenen Untermenü verborgen. (Seite 52)). Anschließend setzen Sie Airgap
6.4. Airgap Update
53
Abb. 6.22: Die Airgap-Master zeigt auf seinem Display die Schritte bei der Erstellung des UpdatePakets an.
Abb. 6.23: Die Airgap-Slave protokolliert ebenfalls die Schritte.
type zunächst den auf den Wert ftp und die Airgap role auf master. Anschließend erhalten Sie neue
Parameter in dem Menü.
Hier tragen Sie nun die entsprechenden Werte ein:
• FTP location: Dies ist der FTP-Server mit Ordner als kompletter Pfad.
• FTP user: Dies ist der Benutzer mit dem die Anmeldung erfolgt.
• FTP password: Dies ist das Kennwort mit dem die Anmeldung erfolgt.
• Test FTP: Hiermit können Sie die eingegebenen Daten prüfen. Der Test prüft, ob mit den Daten
eine Anmeldung möglich ist.
Auf dem Slave nehmen sie dieselben Einstellungen vor. Hier stellen sie lediglich die auf slave.
Damit die Synchronisation fehlerfrei abläuft müssen die Synchronisationzeiten auf dem Master und
dem Slave angepasst werden. Stellen Sie sicher, dass der Master über genügend Zeit für den Upload
der Feed verfügt, so dass der Slave nicht den Feed lädt, bevor der Master den Upload fertiggestellt
hat. Dies kann unter Synctime eingestellt werden.
Damit der FTP-Server auch wirklich die Funktion einer Diode aufweist, sollten Sie sicherstellen, dass
hochgeladene Dateien nach dem Upload geprüft werden. Dies können Sie zum Beispiel mit dem pureftpd erreichen. Dieser FTP-Server bietet die Möglichkeit nach dem Upload einer Datei ein Skript aufzurufen. Dieses startet erst einen Virenscanner. Nach der erfolgreichen Prüfung verschiebt das Skript
54
Kapitel 6. Betrieb
Abb. 6.24: Nach Aktivieren von FTP erhalten Sie neue Parameter für die Konfiguration.
die Feeddateien in ein weiteres Verzeichnis auf das der Slave Zugri hat und den Feed lädt.
6.4. Airgap Update
55
56
Kapitel 6. Betrieb
KAPITEL 7
Scanning
Dieses Kapitel beschäftigt sich mit der Einrichtung und Durchführung der eigentlichen Scans Ihrer
Systeme für das Schwachstellenmanagement. Hierbei beschreibt dieses Kapitel grundlegende erste
Schritte. Spätere Abschnitte zeigen Ihnen dann detaillierter die Nutzung und Anpassung Ihrer Scankonfigurationen und die Auswertung der Ergebnisse.
7.1 Einfacher Scan
Dieser erste Abschnitt beschreibt die ersten Schritte zur Konfiguration Ihres ersten Scans. Grundsätzlich stehen Ihnen zwei Möglichkeiten o en. Die Weboberfläche Ihrer GSM-Appliance, der Greenbone Security Assistant, stellt Ihnen einen Wizard zur Verfügung, der Ihnen mit nur wenigen Eingaben
alle erforderlichen Konfigurationen für einen ersten Scan erzeugt. Alternativ können Sie diese aber
auch selbst schrittweise anlegen. Die folgenden beiden Abschnitte betrachten beide Vorgehensweisen. Idealerweise vollziehen Sie die einzelnen Schritte direkt auf einer GSM-Appliance nach.
Diese Schritte werden auch in einem Video erläutert: http://docs.greenbone.net/Videos/gos3.1/en/GSM-FirstScan-GOS-3.1-en-20150716.mp4.
7.1.1 Wizard
Wenn Sie sich das erste Mal auf der Weboberfläche der GSM Appliance anmelden, wird der Schnellstart (Wizard) angezeigt. Der Schnellstart ist nach der Anmeldung sichtbar, bis Sie 4 Scan-Aufgaben
erzeugt haben. Anschließend können Sie den Schnellstart immer noch über das Icon starten.
Um mit dem Wizard ein System direkt zu scannen, genügt die Angabe der IP-Adresse oder des Rechnernamens. Dazu ist es aber erforderlich, dass die GSM-Appliance den Rechnernamen auflösen kann.
Der Task Wizard führt anschließend die folgenden Schritte automatisch durch:
1. Er erzeugt ein neues Scanziel (Target) in dem GSM.
2. Er erzeugt einen neue Scanauftrag (Task) in dem GSM.
3. Er startet diesen Scanauftrag sofort.
4. Er wechselt die Ansicht und lädt diese alle 30 Sekunden neu, so dass Sie den Fortschritt des
Tasks beobachten können.
Nachdem der Task gestartet wurde, können Sie den Fortschritt beobachten. Hierzu zeigt der Greenbone Security Assistant die Übersichtsseite mit allen Tasks an. Dort ist auch der neue Task zu sehen.
Die Farben und der Füllgrad des Statusbalken geben Auskunft über den Zustand des Scans (Siehe auch
Abschnitt Start des Task (Seite 66)).
57
Abb. 7.1: Der Task Wizard erleichtert die ersten Schritte.
Abb. 7.2: Nach dem Start wird der Fortschritt angezeigt.
Sobald der Scan abgeschlossen ist gibt die Spalte Severity Auskunft über die Kritikalität der gefundenen Schwachstellen. Die sich davor befindende Spalte Solution Type zeigt die Art der verfügbaren
Lösung an. Der Häufigste Typ ist hier der VendorFix .
Abb. 7.3: Die Ergebnisse sind auch vor Abschluß des Scans bereits erreichbar.
Der Task kann über die Aktionen in der rechten Spalte weiter verwaltet werden:
•
•
58
Starting of a currently not running task.
Hiermit stoppen Sie einen aktuell laufenden Task. Alle gewonnenen Ergebnisse werden in die
Datenbank geschrieben.
•
Hiermit können Sie einen gestoppten Task wieder aufnehmen.
•
Hiermit wird ein Task in den Mülleimer verschoben.
•
Hiermit können Sie den Task editieren.
Kapitel 7. Scanning
•
•
Hiermit kopieren Sie einen Task.
Hiermit exportieren Sie einen Task als XML Objekt. Dieses Objekt können Sie auf einem anderen GSM wieder importieren.
Abb. 7.4: Der Report kann in unterschiedlichen Varianten dargestellt werden.
Bevor Ihr Scan abgeschlossen ist, können Sie bereits die Ergebnisse des Scans (siehe Abbildung Die
Ergebnisse sind auch vor Abschluß des Scans bereits erreichbar. (Seite 58)) betrachten. Hierzu wählen
Sie mit der Maus einfach den Fortschrittsbalken aus. Die hier angezeigten Ergebnisse sind natürlich
noch nicht vollständig. Sie können aber den Fortschritt weiter oben rechts über den Fortschrittsbalken
verfolgen. Diese Seite lädt sich jedoch nicht mehr automatisch neu.
Um unterschiedliche Darstellungen der Ergebnisse zu erhalten, können Sie mit der Maus über die Titelzeile fahren. Es ö net sich ein Pulldown-Menü in dem Sie verschiedene Darstellungsformen wählen können.
Abb. 7.5: Außerdem kann der Bericht in verschiedenen Formaten heruntergeladen werden
Außerdem können Sie den Bericht auch in verschiedenen Formaten exportieren. Die Export-Formate
wählen Sie ebenfalls in der Titelzeile aus. Anschließend können Sie den Bericht durch Wahl des
Buttons herunterladen. Die Berichte und Berichtsformate werden im Abschnitt Reports (Seite 68) genauer betrachtet.
7.1.2 Advanced Wizard
Neben dem einfachen Wizard bietet der GSM auch einen fortgeschrittenen Wizard, in dem Sie mehr
Konfigurationsmöglichkeiten haben. Dieser Wizard erlaubt Ihnen die Abkürzung der manuellen Konfiguration der einzelnen Parameter, bietet aber dennoch eine sehr feingranuläre Konfiguration.
Diesen Wizard können Sie über das Kontextmenü des Wizard-Icons aufrufen. Hier können Sie auch
einen Wizard aufrufen, der Ihnen die Änderung eines Tasks (Modify Task Wizard) erlaubt.
7.1. Einfacher Scan
59
Abb. 7.6: Der fortgeschrittene Wizard bietet mehr Möglichkeiten.
Abb. 7.7: Das Wizard-Kontextmenü erlaubt den Aufruf.
7.1.3 Manuelle Konfiguration
Der nun folgende Abschnitt erläutert die Erzeugung eines einfachen Scans in den einzelnen Schritten, die auch der Wizard durchführt. Hierbei können Sie aber selbst sinnvolle Namen für die Scanziele
(Targets) und den Scanauftrag (Task) vergeben.
Diese Schritte werden auch in einem Video erläutert: http://docs.greenbone.net/Videos/gos3.1/en/GSM-FirstScan-GOS-3.1-en-20150716.mp4.
Anlegen des Targets
Der erste Schritt ist die Definition des Scanziels. Dieses wird von dem Greenbone Security Assistant
als Target bezeichnet.
Wählen Sie zunächst einen oder mehrere Rechner aus Ihrem Netz, den bzw. die Sie scannen möchten.
Sie benötigen hierzu entweder dessen IP-Adresse oder dessen DNS-Namen. In beiden Fällen ist es
erforderlich, dass der Greenbone Security Manager diesen Rechner erreichen kann. Bei Nutzung des
DNS-Namens muss die GSM Appliance den Namen auflösen können.
Wählen Sie aus dem Menü Configuration den Punkt Configuration. Wählen Sie hier das New Target
Icon für (den weißen Stern auf blauem Grund: ). Dieses Icon finden Sie an vielen Stellen. Es steht
immer für das Anlegen eines neuen Objektes im jeweiligen Kontext.
Sie erhalten nun ein neues Fenster, in dem Sie das Target genauer spezifizieren können.
60
Kapitel 7. Scanning
Abb. 7.8: Aufrufen der Targets.
Abb. 7.9: Anlegen eines neuen Targets.
Hier geben Sie die folgenden Informationen an:
• Name: Der Name kann frei gewählt werden. Sie sollten einen möglichst beschreibenden Namen
wählen. Möglichkeiten sind Mailserver, ClientNetzwerk, Webserverfarm, DMZ oder ähnlich, die
die Systeme genauer beschreiben.
• Comment Der optionale Kommentar erlaubt Ihnen die Angabe von Hintergrundinformationen.
Diese erleichtern später das Verständnis des konfigurierten Targets.
• Hosts Hier können Sie den Rechner manuell eintragen oder eine Liste von Rechnern importieren.
Bei der manuellen Eingabe haben Sie die folgenden Möglichkeiten:
– Eine IP-Adresse, z.B. 192.168.15.5
– Ein Rechnernamen, z.B. mail.example.com
– Ein IPv4 Adressbereich, z.B. 192.168.15.5-192.168.15.27 oder 192.168.15.5-27
– Ein IPv4 Netz in CIDR Notation, z.B. 192.168.15.0/24 9
9
Die maximale Netzmaske beträgt /20. Dies entspricht 4096 Adressen.
Abb. 7.10: Geben Sie die Details für das Target an.
7.1. Einfacher Scan
61
– Einzelne IPv6-Adressen
– Ein IPv6 Adressbereich im langen Format, z.B. ::12:fe5:fb50-::12:fe6:100
– Ein IPv6 Adressbereich im kurzen Format, z.B. ::12:fe5:fb50-fb80
– Ein IPv6 Adressbereich in CIDR Notation, z.B. fe80::222:64 :fe76:4cea/120
– Mehrere Angaben können durch Kommas getrennt angegeben werden.
Bei einem Import aus einer Datei können Sie die gleichen Schreibweisen nutzen. Hier dürfen
die Angaben auf mehreren Zeilen in der Datei gespeichert werden. Bei besonders langen
Listen von zu scannenden Systemen ist diese Variante häufig die einfachere.
• Exclude Hosts Hier können Sie Rechner angeben, die in der oben angegebenen Gruppe immer
ausgenommen sein sollen.
• Reverse Lookup Only Hier können Sie einstellen, ob nur die IP-Adresse gescannt werden sollen,
zu denen ein DNS-Name aufgelöst werden kann.
• Reverse Lookup Unify Hier bestimmen Sie, ob die Ausgabe des Reverse-Lookup vereinheitlicht
werden soll. Lösen mehrere IPs für den gleichen DNS-Namen auf, so wird dieser DNS-Name
nur ein einziges mal gescannt.
• Port list Das TCP und das UDP-Protokoll unterstützen jeweils 65536 Ports. Alle Ports zu scannen dauert in vielen Fällen zu lange. Viele Ports werden normalerweise nicht genutzt. Ein
Hersteller, der eine neue Applikation entwickelt, reserviert meist beim IANA (Internet Assigned Numbers Association) den entsprechenden Port. Daher genügt es für die meisten
Scans nur diese beim IANA registrierten Ports zu scannen. Dabei unterscheiden sich die
registrierten Ports von den privilegierten Ports. Als privilegierter Port werden die Ports
kleiner als 1024 bezeichnet 10 . Beim IANA sind aber auch zum Beispiel die Ports 1433/tcp
(MS-SQL) und 3306/tcp (MySQL) in der Liste enthalten. Nmap verwendet wieder eine abweichende Liste und testet auch nicht alle Ports. Auch OpenVAS verwendet einen abweichenden Default.
Ein Scan von TCP-Ports kann sehr einfach und schnell durchgeführt werden. Betriebssysteme müssen immer auf eine TCP-Anfrage reagieren und einen Port entweder als o en (TCPACK) oder geschlossen (TCP-RST) melden. Bei UDP ist dies nicht der Fall. Betriebssysteme
antworten nur dann verläßlich, wenn der Port geschlossen ist (ICMP-Port-Unreachable).
Ein o ener Port wird von dem Scanner durch die fehlende Antwort erkannt. Daher muss
der Scanner in diesem Fall einen internen Timeout abwarten. Dieses Verhalten tri t natürlich nur auf Systeme ohne einen Schutz durch eine Firewall zu. Bei Existenz einer Firewall
ist die Erkennung o ener und geschlossener Ports schwieriger.
Wenn Sie Applikationen auf ungewöhnlichen Ports betreiben und auch diese mit dem GSM
überwachen und testen möchten, sollten Sie im Untermenü die mitgelieferten Portlisten
kontrollieren und gegebenenfalls eine eigene Liste anlegen, in der Ihr Port aufgeführt ist.
Die ausgelieferten Listen können nicht angepasst werden.
• Alive Test Hier stellen Sie ein, wie die Erreichbarkeit eines Ziels (Targets) vor dem Scan geprüft
werden soll. Zur Verfügung stehen:
– ICMP Ping
– TCP Service Ping
– ARP Ping
– ICMP & TCP Service Ping
– ICMP & ARP Ping
– TCP Service & ARP Ping
– ICMP, TCP Service & ARP Ping
10 Unter UNIX wird ein Zugri auf diese Ports nur privilegierten Benutzern (z.B. root) erlaubt. Die Ports ab 1024 stehen auch
unprivilegierten Benutzern zur Verfügung.
62
Kapitel 7. Scanning
In der Praxis gibt es immer wieder Probleme mit diesem Test. So existieren in einigen Umgebungen
Router und Firewallsysteme, die einen TCP Service Ping mit einem TCP-RST beantworten, obwohl der
eigentlich Host nicht aktiv ist.
Auch existieren Netzwerkkomponenten, die ein Proxy-ARP unterstützen und einen ARP-Ping beantworten. Daher kann dieser Test in Ihrer Umgebung eine lokale Anpassung erfordern.
• SSH Credential Hier können Sie einen Benutzer auswählen, der sich auf dem Zielsystem des
Scans anmelden kann, wenn es sich um ein UNIX oder Linux System handelt. Dann ist ein
authentifizierter Scan möglich (siehe Abschnitt Authentifizierter Scan (Seite 71)).
• SMB Credential Hier können Sie einen Benutzer auswählen, der sich auf dem Zielsystem des
Scans anmelden kann, wenn es sich um ein Microsoft Windows System handelt. Dann ist
ein authentifizierter Scan möglich (siehe Abschnitt Authentifizierter Scan (Seite 71)).
• ESXi Credential Hier können Sie einen Benutzer auswählen, der sich auf dem Zielsystem des
Scans anmelden kann, wenn es sich um ein VMWare ESXi System handelt. Dann ist ein authentifizierter Scan möglich (siehe Abschnitt Authentifizierter Scan (Seite 71)).
Anlegen des Tasks
Der GSM steuert die Durchführung von Scans als Tasks. Diese Tasks können auch regelmäßig wiederholt oder zu bestimmten Uhrzeiten ausgeführt werden. Diese Steuerung wird in Abschnitt Geplanter
Scan (Seite 83) näher betrachtet. Zunächst soll es in diesem Abschnitt um die grundsätzliche Erzeugung neuer Tasks gehen.
Abb. 7.11: Erstellen von Tasks
Um auf die Tasks zuzugreifen, benötigen Sie aus der Menüleiste den Punkt Scan Management. Dort
wählen Sie die Option Tasks. Auf der folgenden Seite wählen Sie den weißen Stern auf blauen Grund,
um einen neuen Task zu erzeugen. Nun ö net sich eine Webseite, auf der Sie die weiteren Optionen
für den Task definieren können.
Abb. 7.12: Erstellen eines neuen Tasks
Hier geben Sie die folgenden Informationen an:
7.1. Einfacher Scan
63
• Name Dies ist ein frei wählbarer Name. Sie sollten hier einen möglichst beschreibenden Namen
wählen. Denkbar ist Scanne Mailserver, Teste ClientNetzwerk, Prüfe DMZ auf neue Ports
und Rechner oder ähnliche Namen, die die angegebene Aufgabe beschreiben.
• Comment Der optionale Kommentar erlaubt Ihnen die Angabe von Hintergrundinformationen.
Diese erleichtern später das Verständnis des konfigurierten Targets.
• Scan Targets Hier wählen Sie ein zuvor konfiguriertes Target aus der Drop-Down-List aus.
• Alerts Hier können Sie einen vorher konfigurierten Alert auswählen. So können Sie Zustandsänderungen des Tasks mittels E-Mail, Syslog, HTTP oder eines Konnektors der Außenwelt
mitteilen.
• Schedule Hier können Sie einen vorher konfigurierten Schedule auswählen. Damit können Sie
den Task einmalig oder wiederholend zu bestimmten Uhrzeiten ausführen. So ist es möglich, z.B. immer Montag morgens um 6:00 Uhr das Netz zu scannen.
• Add results to Asset Management Bei Auswahl dieser Option werde die gescannten Systeme
automatisch dem Asset Management (siehe Kapitel Asset Management (Seite 203)) des
GSM zur Verfügung gestellt. Dies kann auch später jederzeit umgeschaltet werden.
• Alterable Task Alterable TaskDies erlaubt die Modifikation des Tasks, selbst wenn bereits Berichte erzeugt wurden. Damit ist die Konsistenz der Berichte untereinander jedoch nicht
mehr gewährleistet.
• Scanner
– OpenVAS Scanner In der Werkseinstellung wird nur der OpenVAS Scanner unterstützt. Zusätzliche Scanner sind der PaloAlto und w3af Scanner.
– Scan Config Der GSM besitzt in der Werkseinstellung sieben vorkonfigurierte ScanKonfigurationen.
* Discovery Nur die NVTs, die möglichst viele Informationen über das Ziel ermitteln,
sind ausgewählt. Es werden keine Schwachstellen ermittelt.
* Host Discovery Nur die NVTs, die Zielsysteme erkennen, sind ausgewählt. Der Bericht enthält nur eine Liste der erkannten Systeme.
* System Discovery Nur die NVTs, die das Ziel, sein Betriebssystem und Hardware
ermitteln, sind ausgewählt.
* Full and Fast Dies ist der Default und in vielen Umgebungen die beste Wahl zu Beginn. Diese Konfiguration basiert auf der in dem Port-Scan gewonnenen Informationen und verwendet alle NVTs. Es werden nur für das Ziel unschädliche NVTs
genutzt. Die Plugins wurden so optimiert, dass die Rate der falsch-positiven Meldungen möglichst gering ist. Die weiteren Scan-Konfigurationen mögen in seltenen Fällen mehr Informationen liefern, benötigen jedoch einen wesentlichen
größeren Aufwand.
* Full and fast ultimate Diese Konfiguration erweitert die erste Konfiguration mit
NVTs, die Dienste oder Systeme stören oder sogar zum Absturz bringen können.
* Full and very deep Diese Konfiguration unterscheidet sich von der Full and Fast
Konfiguration darin, dass die Ergebnisse des Port-Scans keinen Einfluss auf die
Auswahl der NVTs haben. Daher werden auch NVTs aktiv, die anschließend möglicherweise auf einen Timeout warten müssen. Dieser Scan ist daher sehr langsam.
* Full and very deep ultimate Diese Konfiguration fügt zur Full and very deep Konfiguration gefährliche NVTs hinzu, die möglicherweise einen Dienst oder ein System stören können.
– Slave Hier können Sie einen vorher konfigurierten Slave auswählen, durch den der Scan
durchgeführt wird. Damit kann der Scan an ein anderes System delegiert werden, welches einen besseren Zugang zu dem Zielsystem hat.
64
Kapitel 7. Scanning
– Netzwerk-Quell-Interface Hier wählen Sie die Netzwerkschnittstelle für den Scan.
– Order for target hosts Hier können Sie wählen, wie der angegebene Netzbereich durchsucht werden soll. Zur Auswahl stehen:
* Sequential
* Random
* Reverse
Dies ist interessant, wenn Sie ein Netz, z.B. 192.168.0.0/24 scannen, in dem sich gehäuft
zu Beginn oder am Ende des IP-Adressbereichs Systeme befinden. Stellen Sie dann den
Modus auf Random, zeigt die Fortschrittsanzeige sinnvollere Werte an.
– Scan Intensity Wählen Sie die Geschwindigkeit für den Scan. Die Werkseinstellung ist bereits sinnvoll gewählt. Wenn mehr NVTs gleichzeitig auf einem Zielsystem oder mehrere Zielsysteme gleichzeitig gescannt werden, kann der Scan negative Seitene ekte
auf die Geschwindigkeit der Systeme oder des Netzwerkes haben.
Berechtigungen
Haben Sie den Task gespeichert, so wird er zunächst angezeigt (siehe Abbildung Ein neue erstellter
Task. (Seite 67)).
Abb. 7.13: Ein neuer Task nach seiner Erzeugung.
Wenn Sie das Fenster herunterscrollen, können die Berechtigungen der Aufgabe verwaltet werden.
Abb. 7.14: Die Leserechte können direkt beim Task verwaltet werden.
Bemerkung: In der Werkseinstellung können normale Benutzer keine Berechtigungen an andere Benutzer vergeben, da sie die Benutzerdatenbank nicht lesen dürfen. Um dies zu tun, muss der Benutzer
7.1. Einfacher Scan
65
explizit die Berechtigung get_users erhalten. Hierzu ist es sinnvoll eine zusätzliche Rolle zu erzeugen
(siehe Abschnitt GetUsers-Rolle für Observer (Seite 178)).
Hierzu wählen Sie entsprechend User, Group oder Role und tragen den entsprechenden Namen ein.
Nach dem Anklicken von wird die Berechtigung eingetragen.
Dies wird nun auch in der Task-Übersicht angezeigt.
Abb. 7.15: Die Leserechte an einem Task werden in der Übersicht angezeigt.
Nach der Anmeldung des Benutzers kann er diese Tasks sehen und auch auf die entsprechenden Berichte zugreifen.
Dies wird nun auch in der Task-Übersicht angezeigt.
Abb. 7.16: Nach Anmeldung kann der Beobachter die Tasks nun auch sehen aber nicht verändern.
Start des Task
Haben Sie den Task gespeichert, so wird er zunächst angezeigt (siehe Abbildung Ein neue erstellter
Task. (Seite 67)).
Der Task kann über die Aktionen in der Titelzeile weiter verwaltet werden:
•
•
Starting of a currently not running task.
•
•
Hiermit wird ein Task in den Mülleimer verschoben.
•
Hiermit können Sie den Task editieren.
•
Hiermit kopieren Sie einen Task.
•
Hiermit exportieren Sie einen Task als XML Objekt. Dieses Objekt können Sie auf einem anderen GSM wieder importieren.
Alternativ kann der Start des Tasks auch über die Übersichtsseite erfolgen, die Sie über Scan Management und anschließend Tasks erhalten (siehe Abbildung In der Übersicht erfolgt die Steuerung des
Tasks über die rechte Spalte. (Seite 67)).
66
Kapitel 7. Scanning
Abb. 7.17: Ein neue erstellter Task.
Abb. 7.18: In der Übersicht erfolgt die Steuerung des Tasks über die rechte Spalte.
Der Statusbalken gibt Auskunft über den Zustand des Tasks. Hier sind die folgenden Farben und Zustände möglich:
•
Dieser Task ist seit seiner Erzeugung noch nicht gestartet worden.
•
Dieser Task läuft gerade und ist zu 42% abgeschlossen. Diese Angabe basiert auf
der Anzahl der ausgeführten NVTs auf den ausgewählten Hosts. Daher korreliert die Angabe
nicht zwingend mit der aufgewendeten Zeit.
•
Dieser Task wurde gerade gestartet. Der GSM bereitet den Scan vor.
•
Dieser Task wurde gelöscht. Der tatsächliche Löschvorgang kann jedoch einige
Zeit in Anspruch nehmen, da auch die Berichte gelöscht werden.
•
Dieser Task wurde kürzlich gestoppt. Die Scan-Engine hat jedoch noch nicht entsprechend reagiert.
•
Der letzte Scan wurde bei 15% durch den Anwender gestoppt. Der letzte Bericht
ist daher wahrscheinlich nicht vollständig. Weitere Gründe für diesen Zustand sind ein Reboot
der GSM Appliance oder ein Stromausfall. Nach dem Neustart des Scanners wird der Task nicht
automatisch wieder aufgenommen.
•
Es ist ein Fehler aufgetreten. Der letzte Bericht ist möglicherweise nicht vollständig oder fehlt gänzlich.
•
Der Scan ist erfolgreich abgeschlossen worden.
•
Es handelt sich um einen Container-Task.
7.1. Einfacher Scan
67
Container Task
Ein Container Task kann genutzt werden, um Berichte, die von anderen GSMs erzeugt wurden zu importieren und vorzuhalten. Dabei müssen Sie bei dem Anlegen des Container Task bereits einen ersten
Bericht importieren. Anschließend können Sie weitere Berichte (Reports) importieren und diese dann
zum Beispiel auch mit einem Delta-Report vergleichen.
Abb. 7.19: Der Container Task dient zum Import fremder Berichte.
Die Berichte müssen im GSM-XML-Berichtsformat vorliegen.
7.2 Reports
Die Ergebnisse eines Scans werden in einem Report zusammengefasst. Dieser Report kann in dem
Browser betrachtet werden und in unterschiedlichen Formaten von dem GSM geladen werden. Hat
der Scan einmal begonnen, kann zu jedem Zeitpunkt der Report zu den bisher ermittelten Ergebnissen
eingesehen werden. Ist der Scan abgeschlossen, ändert sich dessen Status auf Done. Ab jetzt kommen
keine weiteren Resultate mehr dazu. Beachten Sie bezüglich der Reports auch das Kapitel Berichte
(Seite 91).
Abb. 7.20: Die Reportsummary gibt einen Überblick über die gefundenen Schwachstellen.
Die Zusammenfassung des Berichts gibt einen schnellen Überblick über den aktuellen Zustand. Sie
zeigt an, ob der Scan bereits abgeschlossen ist und wieviele Schwachstellen bisher gefunden wurden. Von dieser Ansicht kann der Bericht direkt in unterschiedlichen Formaten exportiert werden. Die
folgenden Formate werden unterstützt (siehe auch Abschnitt Report Plugins (Seite 92)).
ARF: Asset Reporting Format v1.0.0 Dieses Format erzeugt einen Bericht, der dem NIST Asset Reporting Format entspricht.
CPE - Common Enumeration CSV Table Dieser Report wählte alle CPE-Tabellen und erzeugt eine einzige komma-separierte Datei.
CSV hosts Dieser Bericht erzeugt eine komma-separierte Datei mit den gefundenen Systemen.
CSV Results Dieser Bericht erzeugt eine komma-separierte Datei mit den Ergebnissen des Scans.
68
Kapitel 7. Scanning
GSR PDF - Greenbone Security Report (recommended) Dies ist der vollständige Greenbone Security
Bericht mit allen Schwachstellen.
GXR PDF - Greenbone Executive Report (recommended) Dies ist ein gekürzter Bericht für das Management.
HTML Dieser Bericht ist in HTML Format.
ITG - IT-Grundschutz-Kataloge Dieser Bericht orientiert sich am BSI IT-Grundschutz Katalog
LaTeX Dieser Bericht wird als LaTeX Quelltext zur Verfügung gestellt.
NBE Dies ist das alte OpenVAS/Nessus Report Format.
Sie können aber auch in der Weboberfläche unterschiedliche Details des Reports anzeigen.
Abb. 7.21: Verschiedene Sichten auf denselben Report.
Weil ein Report häufig sehr viele Meldungen enthält, können Sie sich sowohl den kompletten Bericht
als auch nur gefilterte Ergebnisse anzeigen lassen und herunterladen. In der Voreinstellung werden
nur die Meldungen mit den Bedrohungen High und Medium angezeigt. Sie können dies aber einfach
ändern.
Abb. 7.22: Report Filtering
In dem Abschnitt Filtered Results sehen Sie die gefilterten Ergebnisse. Solange der Scan noch läuft
kann es hier zu Umsortierungen kommen.
Um die Ergebnisse zu deuten, beachten Sie bitte die folgenden Hinweise:
7.2. Reports
69
• False Positives
Als False Positive wird eine Meldung bezeichnet, die ein Problem beschreibt, welches in Wirklichkeit nicht vorhanden ist. So finden Schwachstellen-Scanner oft Indizien, die auf ein Sicherheitsproblem hinweisen. Eine endgültige Aussage ist jedoch nicht möglich. Hier stehen nun zwei
Möglichkeiten zur Auswahl:
– Meldung einer potentiell nicht existenten Schwachstelle (False Positive).
– Unterlassung der Meldung einer potentiell existenten Schwachstelle (False Negative.)
Da Anwender falsch-positive Meldungen erkennen und verwalten können, dies aber mit falschnegativen Meldungen nicht möglich ist, meldet der GSM Schwachstellenscanner alle potentiell existierenden Schwachstellen. Der GSM unterstützt dann bei der automatischen oder auch
semi-automatischen Kategorisierung.
Besonders typisch ist dieses Problem bei Enterprise Linux Distributionen. Ist zum Beispiel der
SSH-Service in der Version 4.4 installiert und meldet diese Software diese Version bei einer Verbindungsaufnahme, so schlägt ein Schwachstellenscanner, der eine Sicherheitslücke in dieser
Version kennt, an. Der Distributor hat die Schwachstelle aber vielleicht bereits behoben und eine Version 4.4-p1 verö entlicht, die auch installiert wurde. Diese Version meldet nach außen
aber weiterhin die Version 4.4, so dass der Schwachstellenscanner nicht unterscheiden kann.
Wenn der Anwender diesen Umstand kennt, kann er Override (siehe Abschnitt Overrides und
False Positives (Seite 87)) konfigurieren. Auch die AutoFP-Funnktionalitität (siehe Abschnitt Automatische False-Positives (AutoFP) (Seite 89)) kann hier helfen.
Bemerkung: Beachten Sie hierzu auch das neue Konzept der Quality of Detection (siehe Abschnitt
Lesen des Reports (Seite 71) and Network Vulnerability Tests (Seite 195)).
• Häufig haben mehrere Erkenntnisse eine gemeinsame Ursache. Dies ist besonders bei veralteten Softwarepaketen der Fall, die gleichzeitig mehrere Schwachstellen aufweisen. Jede dieser
Schwachstellen wird von einem eigenen NVT geprüft und erzeugt einen Alarm. Die Installation
eines aktuellen Softwarepaketes wird dann viele Schwachstellen in einem Schritt beheben.
• Wichtig sind die Resultate der Bereiche High
und Medium
. Bearbeiten Sie die
Meldungen in der Reihenfolge ihrer Einstufungen. Bevor Sie sich mit der Stufe Medium beschäftigen, sollten Sie die Stufe High betrachten. Nur in Ausnahmefällen, wenn Sie wissen, dass die
Meldungen der Stufe High für Sie weniger in Betracht kommen (weil die Dienste durch eine Firewall nicht erreichbar sind), sollten Sie von dieser Taktik abweichen.
• Low
und Log
dienen im wesentichen dazu, in die Details zu gehen. Daher sind
diese Meldungen in der Voreinstellung auch ausgefiltert. Diese Meldungen können aber dennoch
sehr interessante Informationen enthalten und ihre Berücksichtigung verbessert die Sicherheit
Ihres Netzes und Ihrer Systeme. Meist ist für ihr Verständnis aber auch ein tieferes Wissen um
die Applikationen erforderlich. Typisch für eine Meldung auf Log-Ebene ist die Meldung, dass
ein Dienst einen Banner mit seinem Namen und Versionnummer verwendet. Dies kann einem
Angreifer, wenn diese Version eine bekannte Sicherheitslücke aufweist, in seinem Angri nützlich sein.
• Um die Behebung der Schwachstelle zu vereinfachen, gibt jede Meldung auch direkt eine Lösung
des Problems an. In den meisten Fällen wird auf entsprechende aktuelle Softwarepakete des
Herstellers verwiesen. In einigen Fällen wird direkt eine Konfigurationseinstellung angegeben.
• Obwohl die Meldungen bereits sehr viele Informationen mitliefern, sind immer auch externe
Referenzen aufgeführt. Diese verweisen auf Webseiten im Internet, auf denen diese Sicherheitslücke bereits diskutiert wurde. Hier erhalten Sie weitere Hintergrundinformationen, wer die
Schwachstelle entdeckt hat, welche Auswirkungen sie haben kann und wie diese Schwachstelle
behoben werden kann.
70
Kapitel 7. Scanning
7.2.1 Lesen des Reports
Der Report enthält eine Liste sämtlicher durch den GSM aufgedeckter Schwachstellen (siehe Abbildung Liste der gefundenen Schwachstellen (Seite 71)).
Abb. 7.23: Liste der gefundenen Schwachstellen
Um den Administrator bei der Analyse der Ergebnisse zu unterstützen, wird der Schweregrad der
Schwachstelle (CVSS, siehe auch Abschnitt CVSS (Seite 200)) direkt als Balken dargestellt.
Um den Admin auf eine einfache Lösung hinzuweisen, zeigt die Spalte Solution-Type das Vorhandensein einer Lösung an. Existiert ein Patch des Hersteller
oder ist ein Workaround
verfügbar,
zeigt das die Spalte an. Existiert keine Lösung für die Schwachstelle, so wird auch dies angezeigt .
Falls aktuell die Spalte für eine einzelne Schwachstelle noch leer ist, so wurde der NVT noch nicht
entsprechend aktualisiert.
Die Spalte Qualität der Erkennung (QdE) zeigt die Verläßlichkeit der erfolgreichen Erkennung der
Schwachstelle an. Diese Information wird in allen existierenden NVTs Schritt für Schritt implementiert (siehe Abschnitt Network Vulnerability Tests (Seite 195)). Diese Spalte erlaubt ebenfalls die Filterung. Sie können den min_qod Parameter im Powerfilter nutzen. In der Werkseinstellung werden
nur die NVTs mit einem QdE von 70% angezeigt. Schwachstellen mit einer geringeren Verläßlichkeit
der Erkennung werden nicht in dem Bericht aufgeführt. Die Wahrscheinlichkeit von falsch-positiven
Meldungen ist daher gering.
Auf der Anzeige der eigentlichen Schwachstelle erhalten Sie weitergehende detaillierte Informationen.
7.3 Ergebnisse
Während die Berichte nur die Ergebnisse eines einzelnen Scan-Laufs enthalen, werden die Ergebnisse
aller Scans in einer internen Datenbank gespeichert und können über Scan Management/Ergebnisse
betrachtet werden.
In der Werkseinstellung wird die Ansicht nach dem Datum der Erzeugung der Ergebnisse sortiert. Sie
können die Ergebnisse aber auch nach Schweregrade, QdE, Art der Lösung oder dem Rechner sortieren. Zusätzlich können Sie mit Powerfiltern (siehe Abschnitt Powerfilter (Seite 145)) nur die interessanten Ergebnisse anzeigen.
7.4 Authentifizierter Scan
Ein authentifizierter Scan meldet sich auf dem Zielsystem an, um dieses zu testen. Hierzu verwendet
er Zugangsdaten, die der Scan Anwender vorher auf dem GSM hinterlegen muss. Diese Zugangsdaten
7.3. Ergebnisse
71
Abb. 7.24: Detaillierte Informationen über die Schwachstelle und Lösungsmöglichkeiten.
(Credentials) werden genutzt, um sich für verschiedene Dienste auf dem Zielsystem anzumelden.
Dabei können die Ergebnisse durch die Rechte der verwendeten Benutzer unter Umständen eingeschränkt sein.
Dabei ist der Scan Minimal-Invasiv. Das bedeutet, dass der GSM ausschließlich den Gefährdungszustand ermittelt und keine Änderung am Ziel-System durchführt. Jedoch ist die Anmeldung durch den
GSM in den Protokollen des Zielsystems feststellbar.
Die Zugangsdaten können für verschiedenste Dienste von dem GSM benutzt werden. Besonders wichtig sind jedoch
• SMB Hiermit kann der GSM auf Windows-Systemen den Patch-Level prüfen und lokal installierte Software wie den Adobe Acrobat Reader oder die Java Suite prüfen.
• SSH Dieser Zugang wird für Prüfungen des Patch-Level bei UNIX und Linux-Systemen verwendet.
• ESXi Dieser Zugang wird für lokale Prüfungen auf VMWare ESXi Servern verwendet.
Der Umfang und Erfolg der Prüfroutinen für authentifizierte Scans ist stark von den Berechtigungen
des verwendeten Zugangskontos abhängig. Dabei bestehen besonders bei Windows-Systemen mit
unprivilegierten Benutzern große Einschränkungen.
Um die Zugangsdaten anzulegen, rufen Sie im Menü den Unterpunkt Credentials auf. Hier geben Sie
dann die folgenden Informationen ein:
• Name Dies ist ein beliebiger Name für die Credentials.
• Login Dies ist der Anmeldename, mittels dessen sich die GSM an dem zu scannenden System
72
Kapitel 7. Scanning
Abb. 7.25: Bei den Credentials können auch SSH-Schlüssel genutzt werden.
anmeldet.
• Comment Die ist ein frei wählbarer Kommentar.
• Autogenerate Credentials Hiermit erzeugt die GSM Appliance selbst ein zufälliges Kennwort.
• Password Hier können Sie ein Kennwort eingeben.
• Key Pair Wenn die Anmeldung per SSH erfolgt, können Sie hier einen privaten Schlüssel hochladen. Zusätzlich kann die optionale Passphrase des privaten Schlüssels angegeben werden.
7.4.1 Voraussetzungen auf Zielsystemen mit Windows
Allgemeine Konfigurationshinweise
• Der Remote Registry Dienst muss gestartet sein, damit auf die Registry zugegri en werden
kann.
Dies können Sie erreichen, indem der Dienst automatisch gestartet wird. Falls Sie den automatischen Start nicht bevorzugen, können Sie auch den manuellen Start konfigurieren. In diesem
Fall wird der Dienst gestartet, wenn das System von dem GSM gestartet wird und anschließend
wieder deaktiviert. Um dieses Verhalten zu erzwingen sollten Sie den folgenden Punkt über die
LocalAccountTokenFilterPolicy berücksichtigen.
• Es ist erforderlich, dass auf allen gescannten Systemen die Datei- und Druckerfreigabe aktiviert
ist. Wenn Sie Windows XP verwenden, stellen Sie sicher, dass die Einstellung “Use Simple File
7.4. Authentifizierter Scan
73
Sharing” abgeschaltet ist.
• Bei allein stehenden Systemen muß der folgender Registry Wert gesetzt werden:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\DWORD:
LocalAccountTokenFilterPolicy = 1
• Auf Systemen mit Domänencontroller muss das verwendete Benutzerkonto ein Mitglied der
Gruppe Domain Administrators sein um bestmögliche Ergebnisse zu erzielen. Aufgrund des
Rechtekonzepts ist es mit Lokalen Admistratoren oder auch über die Domäne zugewiesenen
Administratoren nicht möglich, alle Schwachstellen zu erkennen. Alternativ können Sie den weiter unten stehenden Weg Konfigurieren eines Domänenkontos für authentifizierte Scans (Seite 74) gehen.
• Sollten Sie dennoch einen reinen Lokalen Administrator nehmen - was wir ausdrücklich nicht
empfehlen - ist es zwingend notwendig, dass auch hier der folgender Registry Wert gesetzt wird:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\DWORD:
LocalAccountTokenFilterPolicy = 1
• Generiertes Installationspaket für Credentials: Der Installer stellt den Remote Registry
Dienst auf Autostart. Wird der Installer auf einem Domänencontroller ausgeführt, so wird das
Nutzerkonto der Gruppe Domänen-Administratoren (SID S-1-5-32-544) zugeordnet.
• Es muss eine Ausnahmeregel für die IP des GSM in der Windows-Firewall eingerichtet werden.
Bei XP-Systemen muss zusätzlich File and Printer Sharing auf “enabled” gesetzt werden.
• Installationspaket mit Anmeldedaten: Während der Installation bietet die Installationsroutine
einen Dialog um die IP-Adresse des GSM einzugeben. Wenn der Eintrag bestätigt wird, wird automatisch eine entsprechende Firewall-Regel erzeugt. Der Datei- und Druckerfreigabe Dienst
wird in den Firewall-Regeln aktiviert.
Konfigurieren eines Domänenkontos für authentifizierte Scans
Um ein Domänenkonto für hostbasierte Remote-Audits auf einem Windows Ziel zu nutzen, muss dieses unter dem Betriebssystem Windows XP Professional, Windows Vista, Windows 2003, Windows
2008, Windows 2012 Windows 7, Windows 8 oder Windows 8.1 ausgeführt werden und außerdem Teil
einer Domäne sein.
Unter Berücksichtigung der Sicherheit sollten acht Schritte zur Einrichtung dieses Scans umgesetzt
werden.
Schritt 1: Einrichten einer Sicherheitsgruppe
Richten Sie als erstes eine Sicherheitsgruppe mit dem Namen Greenbone Local Scan ein:
• Melden Sie sich dazu an einem Domänencontroller an und ö nen Sie Active
DirectoryBenutzer und Computer.
• Nun erstellen Sie die Sicherheitsgruppe im Menü. Dazu wählen Sie Aktion > Neu > Gruppe aus.
• Nennen Sie die Greenbone Local Scan. Wichtig dabei ist, dass als Bereich Global und als Typ
Sicherheit festgelegt ist.
• Fügen Sie der Gruppe Greenbone Local Scan jenes Konto hinzu, das Sie zur Ausführung von
lokalen, authentifizierten Scans mit der Greenbone Appliance unter Windows verwenden wollen.
Schritt 2: Einrichten der Gruppenrichtlinie
Nun müssen Sie eine Gruppenrichtlinie mit dem Name Greenbone Local SecRights einrichten.
74
Kapitel 7. Scanning
• Ö nen Sie dazu die GruppenrichtlinienVerwaltungskonsole.
• Klicken Sie mit der rechten Maustaste auf Gruppenrichtlinienobjekte und wählen Sie Neu aus.
• Geben Sie als Namen der Richtlinie Greenbone Local SecRights ein.
Abb. 7.26: Neues Windows Gruppenrichtlinienobjekt für Greenbone Scans.
Schritt 3: Konfiguration der Richtlinie
Hier fügen Sie der Richtlinie Greenbone Local SecRights die Gruppe Greenbone Local Scan
hinzu und legen sie in den Gruppen Lokale Administratoren ab.
Beachten Sie bitte, dass diese Einstellung nach entfernen der GPO weiterhin besteht (Tattooing GPO).
• Klicken Sie auf die Richtlinie Greenbone Local SecRights und wählen Sie anschließend Edit
aus.
• Ö nen Sie:
Computer Configuration\Policies\Windows Settings\
Security Settings\Restricted Groups
• Klicken Sie im linken Bereich mit der rechten Maustaste auf Eingeschränkte Gruppen und wählen
Sie Add Group aus.
• Wählen Sie nun Browse``im Dialogfeld ``Gruppe hinzufügen aus, geben Sie
Greenbone Local Scan ein, klicken Sie anschließend auf Namen überprüfen.
• Klicken Sie nun 2 mal auf OK, um das geö nete Dialogfeld wieder zu schließen.
• Klicken Sie unter Diese Gruppe ist Mitglied von: auf Add.
• Fügen Sie die Gruppe Administratoren hinzu. Sollten Sie auch englisch-sprachige Systeme
haben, fügen Sie bitte auch noch Administrators hinzu. Bei anders-sprachigen Systemen, gehen Sie bitte den entsprechenden Namen für die Lokale Administratorgruppe ein.
• Klicken Sie zwei mal auf OK.
Schritt 4: Konfiguration der Richtlinie, um der Gruppe Greenbone Local Scan das lokale Anmelden am System zu verweigern
75
Abb. 7.27: Windows Gruppen-Namen überprüfen.
hinzu und verweigern Sie das lokale Anmelden der Gruppenmitglieder.
• Klicken Sie auf die Richtlinie Greenbone Local SecRights und wählen Sie anschließend
Bearbeiten aus.
• Ö nen Sie:
Computer Configuration\Policies\Windows Settings\Security Settings\
Local Policies\User Rights Assignment
• Doppelklicken Sie im rechten Bereich auf Lokal anmelden verweigern.
• Setzen Sie den Haken bei Diese Richtlinieneinstellung definieren:
• Klicken Sie auf Benutzer oder Gruppe hinzufügen
• Wählen Sie nun Durchsuchen im Dialogfeld aus, geben Sie Greenbone Local Scan ein, klicken Sie anschließend auf Namen überprüfen.
• Klicken Sie auf OK.
Schritt 5: Konfiguration der Richtlinie, um der Gruppe Greenbone Local Scan das Anmelden per
Remotedesktopdienst am System zu verweigern
hinzu und verweigern Sie der Gruppenmitgliedern das Anmelden via RDP.
Bearbeiten aus.
• Ö nen Sie:
Computer Configuration\Polices\Windows Settings\Security Settings\
Local Policies\User Rights Assignment
• Doppelklicken Sie im rechten Bereich auf Anmelden über Remotedesktopdienst
verweigern.
• Setzen Sie den Haken bei Diese Richtlinieneinstellung definieren:
• Klicken Sie auf Benutzer oder Gruppe hinzufügen
76
Kapitel 7. Scanning
Abb. 7.28: Gruppen-Mitgliedschaft hinzufügen.
• Wählen Sie nun “Durchsuchen” im Dialogfeld aus, geben Sie Greenbone Local Scan ein, klicken Sie anschließend auf Namen überprüfen.
• Klicken Sie auf OK.
Step 6 (optional): Konfigurieren Sie die Richtlinie so, dass nur Lesezugri auf das lokale Laufwerk
durch die Gruppe Greenbone Local Scan erfolgen kann.
Schränken Sie in der Richtlinie Greenbone Local SecRights für die Gruppe Greenbone Local
Scan die Rechte für das Systemlaufwerk ein. Beachten Sie bitte, dass diese Einstellung nach entfernen der GPO weiterhin besteht (Tattooing GPO)
Bearbeiten aus.
• Ö nen Sie:
Computer Configuration\Polices\Windows Settings\Security Settings\File Systems
• Klicken Sie im linken Bereich mit der rechten Maustaste auf Dateisystem und wählen Sie Datei
Hinzufügen... aus.
• Tragen Sie im Feld Ordner: %SystemDrive% ein und klicken Sie OK.
• Klicken Sie auf Hinzufügen unter dem Feld Gruppen oder Benutzernamen.
• Geben Sie Greenbone Local Scan im sich ö nenden Dialog ein und klicken Sie auf OK.
• Wählen Sie nun den Benutzer Greenbone Local Scan aus.
• Deaktivieren Sie alle Haken unter Zulassen und aktivieren Sie den Haken unter Verweigern >
Schreiben.
• Klicken Sie anschließend auf OK und bestätigen Sie die Warnmeldung mit Ja.
• Wählen Sie nun Datei oder Ordner konfigurieren und anschließend vererbbare
Berechtigungen an alle Unterordner und Dateien verteilen aus und klicken Sie
anschließend auf OK.
Schritt 7 (Optional): Konfiguration der Richtlinie, um der Gruppe Greenbone Local Scan nur Leserechte in der Registry zu geben.
77
Abb. 7.29: Eine weitere Gruppen-Mitgliedschaft hinzufügen.
Hier schränken Sie in der Richtlinie Greenbone Local SecRights für die Gruppe Greenbone
Local Scan die Rechte teilweise in der Registry ein. Eine komplette Einschränkung ist auf diesem
Wege nur schwer und mit sehr viel Aufwand möglich. Sie können ggf. für Sie kritische Zweige zusätzlich absichern, indem Sie die Zweige manuell hinzufügen.
Beachten Sie bitte, dass diese Einstellung nach entfernen der GPO weiterhin besteht (Tattooing GPO).
• Klicken Sie im linken Bereich mit der rechten Maustaste auf Registrierung und wählen Sie
Schlüssel Hinzufügen... aus.
• Wählen Sie Users aus und klicken Sie OK.
• Klicken Sie auf Erweitert und anschließend auf Hinzufügen.
• Geben Sie Greenbone Local Scan im sich ö nenden Dialog ein und klicken Sie auf OK.
• Im nun folgenden Dialog wählen Sie für Übernehmen für Dieses Objekt und
untergeordnete Objekte aus.
• Unter Berechtigungen wählen Sie Verweigern für Wert festlegen, Unterschlüssel
erstellen, Link erstellen, Löschen, Berechtigung ändern und Besitz übernehmen
aus.
• Bitte nichts unter Zulassen auswählen!
• Klicken Sie anschließend zwei mal auf OK und bestätigen Sie die Warnmeldung mit Ja.
• Klicken Sie nochmals auf OK.
• Wählen Sie nun Diesen Schlüssel konfigurieren und Vererbbare Berechtigungen
an alle Unterschlüssel verteilen aus und klicken Sie anschließend auf OK.
• Führen Sie oben genannte Punkte bitte auch noch einmal für MACHINE und CLASS-ES_ROOT aus
indem Sie im linken Bereich mit der rechten Maustaste auf Registrierung klicken und Schlüssel
Hinzufügen... auswählen.
78
Kapitel 7. Scanning
Abb. 7.30: Richtlinie für lokales Anmelden bearbeiten.
Schritt 8 (Optional): Verknüpfen des Gruppenrichtlinienobjektes
• Klicken Sie in der Gruppenrichtlinien Verwaltungskonsole mit der rechten Maustaste auf Ihre Domäne oder eine Organisationseinheit und wählen Sie Vorhandenes
Gruppenrichtlinienobjekt verknüpfen aus.
• Wählen Sie nun das Gruppenrichtlinienobjekt Greenbone Local SecRights aus.
Einschränkungen
Da die Schreibberechtigungen auf die Registrierung und die System-Festplatte entfernt wurden, werden die folgenden zwei Tests nicht mehr funktionieren:
• Leave information on scanned Windows hosts OID 1.3.6.1.4.1.25623.1.0.96171 Dieser
Test legt - wenn gewünscht - unter HKLMSoftwareVulScanInfo Informationen zum Start
und Ende des Scans an. Dies ist durch das verwehren des Schreibzugri s auf HKLM
nun nicht mehr möglich. Wenn Sie dies weiterhin wünschen, müssten Sie hier die GPO
entsprechend anpassen.
• Windows file Checksums OID 1.3.6.1.4.1.25623.1.0.96180 Der Test legt beim Aufruf - wenn
gewünscht - das Tool ReHash unter C:\Windows\system32 (für 32-Bit Systeme) oder
C:\Windows\SysWOW64 (für 64-Bit Systeme) an. Dies ist durch das Verwehren des
Schreibzugri s nun nicht mehr möglich. Sie müssten das Tool also entweder selber dort
anlegen oder aber die GPO entsprechend anpassen.
Mehr Information finden Sie in dem Abschnitt File Checksums (Seite 102).
Scannen ohne Domainadmin und lokale Adminrechte
Es ist theoretisch auch möglich eine GPO zu bauen, bei der ein User auch keine lokalen Adminrechte
hat. Aber der Aufwand um jeden einzelne Registry Zweig und auch Verzeichnis mit den entsprechen7.4. Authentifizierter Scan
79
Abb. 7.31: Richtlinie für lokales Anmelden bearbeiten.
Abb. 7.32: Eingabe des Ordners %SystemDrive%.
den Leserechten zu versehen, ist enorm. Denn leider ist die Vererbung von Rechten bei sehr vielen Verzeichnissen oder Zweigen deaktiviert. Des weiteren können diese Änderungen zwar per GPO gesetzt,
aber nicht mehr zurück genommen werden (Tattooing GPO). Außerdem würden dabei evtl. spezielle
Berechtigungen überschrieben werden, so das es zu weiteren Problemen kommen könnte.
Es macht also vom technischen und administrativen Aufwand her wenig Sinn, diesen Weg zu gehen.
7.4.2 Konfigurieren eines Linux/UNIX-Kontos für authentifizierte Scans
• Für einen authentifizierten Scan auf Linux oder Unix Systemen ist in der Regel ein einfacher Benutzerzugang ausreichend. Der Login erfolgt dabei über SSH. Die Authentifizierung erfolgt entweder über im GSM hinterlegte Passwörter oder über einen SSH-Schlüssel.
• Generiertes Installationspaket für Credentials: Das Installationspaket für Linux Debian oder Linux RedHat ist ein .deb beziehungsweise ein .rpm, mit dem ein neuer Benutzer ohne spezielle Rechte angelegt wird. Im Verzeichnis dieses Benutzers wird ein auf dem GSM erzeugter
SSH-Schlüssel abgelegt. Für Benutzer anderer Linux Distributionen und UNIX Derivate wird der
Schlüssel zum Download angeboten. Das Anlegen des Nutzers und das Ablegen des Schlüssels
mit den richtigen Dateirechten ist dann Aufgabe des Anwenders.
• In beiden Fällen ist darauf zu achten, dass Public Key Authentifizierung in der Konfiguration des
80
Kapitel 7. Scanning
Abb. 7.33: Wählen Sie nun die Gruppe Greenbone Local Scan aus.
Abb. 7.34: Schreibzugri auf die Gruppe verweigern.
SSH Daemons nicht verboten ist. Die Zeile PubkeyAuthentication no darf nicht vorhanden
sein.
• Es können auch bereits bestehende SSH-Schlüssel verwendet werden, die optional durch eine
Passphrase geschützt sein können. Es wird empfohlen, die Formate RSA und DSA zu verwenden,
wie sie von dem Befehl ssh-keygen erstellt werden.
• Für Scans, die auch Policyprüfung beinhalten, kann auch eine Rootberechtigung oder die Mitgliedschaft in bestimmten Gruppen (oftmals wheel) nötig sein. Viele Konfigurationsdateien sind
aus Sicherheitsgründen nur für Superuser oder Mitglieder einer bestimmten Gruppe lesbar.
7.4.3 Voraussetzungen auf Zielsystemen mit ESXi
In der Werkseinstellung sind lokale ESXi Anwender auf readonly-Rollen beschränkt. Entweder muss
daher ein administratives Konto oder eine readonly-Rolle mit Berechtigungen an den globalen Einstellungen verwendet werden.
Um die Nutzung eines administrativen Kontos zu vermeiden, klonen Sie die Rolle Read-Only` und
wählen dann ``Global > Settings. Schließlich muss dem Scan Anwenderkonto diese Rolle zugewiesen werden.
81
Abb. 7.35: Die Zugri sberechtigungen rekursiv einstellen.
Abb. 7.36: Richtlinie für Leserecht auf Systemlaufwerk.
7.4.4 Autogenerate Credentials
Um die Installation und Bereitstellung eines Kontos für den authentifizierten Scan zu erleichtern, bietet die Funktion Autogenerate Credential des GSM ein Installationspaket für das jeweilige Zielsystem.
Dieses Paket erzeugt den Benutzer mit den wichtigsten Berechtigungen für den authentifizierten Scan
und setzt sie bei De-Installation wieder zurück.
Das Installationspaket wird zur Verfügung gestellt für :
• Debian-basierte Systeme
• RPM-basierte Systeme
• Windows
• Public Key
Abb. 7.37: Auswählen des Registry Schlüssels USERS.
82
Kapitel 7. Scanning
Abb. 7.38: Wählen Sie nun die Gruppe Greenbone Local Scan aus.
Abb. 7.39: Bearbeitung der Registry verbieten.
7.5 Geplanter Scan
Haben Sie Ihre Tasks eingerichtet, so ist der manuelle Aufruf nur noch lästig. Daher bietet der GSM die
Möglichkeit verschiedenste Aufgaben zu automatisieren. Dies erledigen Sie mit den Schedules. Diese
finden Sie in dem Menü Configuration.
Direkt nach dem Start ist noch kein Schedule voreingestellt. Sie müssen den ersten Schedule selbst
erzeugen. Hierzu verwenden Sie den Button .
Als Schedule bezeichnet der Greenbone Security Manager automatische Scans zu einer bestimmten
Zeit. Diese können einmalig oder wiederholend ausgeführt werden. Die Wiederholungen sind dabei
sehr fein einstellbar:
• stündlich
• täglich
• wöchentlich
• monatlich
7.5. Geplanter Scan
83
Abb. 7.40: Rekursives Propagieren der neuen Einstellungen.
Abb. 7.41: Richtlinie verknüpfen.
Besonders wichtig bei einem Schedule ist die Zeitzone. Diese kann über ein Drop-Down-Menü ausgewählt werden. Für Deutschland wählen Sie wahrscheinlich Europe/Berlin. Schließlich können
Sie auch die maximale Dauer des Scans beschränken. Dauert der Scan länger, so wird er abgebrochen. Damit können Sie sicherstellen, dass der Scan immer innerhalb eines bestimmten Zeitfensters
durchgeführt wird.
Nun können Sie den Schedule definieren und die folgenden Daten eingeben:
Name NameDies ist ein beschreibender Name. Sinnvoll ist hier eine Angabe wie taeglich 17:15
oder Jeder 2. monatlich 4:15.
Comment Hier geben Sie wieder einen Kommentar ein.
First Time Hier geben Sie den Zeitpunkt der ersten Ausführung ein.
Period Dies ist der Abstand zwischen zwei Ausführungen. Hier können Sie wählen zwischen stünd-
Abb. 7.42: Schedules erlauben zeitgesteuerte Scans.
84
Kapitel 7. Scanning
Abb. 7.43: Bei dem Anlegen eines Schedules müssen Sie mehrere Informationen angeben.
lich, täglich, wöchentlich und monatlich. Wenn Sie die Period freilassen, handelt es sich um eine
einmalige Ausführung.
Timezone Hier können Sie die Zeitzone anpassen. Standard ist UTC.
Duration Dies ist die maximale Dauer, die der Task für seine Ausführung benötigen darf. Bei Ablauf
dieser Zeit wird der Task abgebrochen.
7.6 Notizen
Notizen (Notes) erlauben Ihnen Kommentare an einen Network Vulnerability Test (NVT) zu knüpfen.
Diese werden dann auch in den Berichten angezeigt. Dabei kann eine Note an ein bestimmtes Ergebnis,
einen bestimmten Task, eine Bedrohungsstufe, Port oder Host gebunden sein, so dass diese Note nur
in bestimmten Berichten auftritt. Die Note kann aber genausogut generalisiert werden, so dass sie in
allen Berichten angezeigt wird.
7.6.1 Notizen anlegen
aus, für die
Um eine neue Note zu erzeugen, wählen Sie in dem Bericht die Meldung New Note
Sie eine Notiz hinzufügen wollen und klicken . Alternativ können Sie auch ohne den Bezug zu einer
Meldung eine neue Notiz erzeugen. Dann kann der GSM Ihnen jedoch keine sinnvollen Werte für die
verschiedenen Felder in dem folgenden Dialog vorschlagen.
Nun ö net sich eine neue Seite, in der genau die Kriterien der von Ihnen gewählten Schwachstelle
bereits voreingestellt sind.
Abb. 7.44: Eine neue Notiz
7.6. Notizen
85
Hier können Sie einzelne Werte nun an- und abwählen, um die Note zusätzlich zu generalisieren oder
spezifischer einzustellen. Außerdem können Sie die Note nur für eine bestimmte Zeit aktiv schalten.
Damit ist es möglich in den Berichten einen Hinweis zu hinterlegen, dass ein Sicherheitsupdate in
den kommenden sieben Tagen eingespielt wird. In den nächsten sieben Tagen wird die Note in den
Berichten angezeigt und so dokumentiert, dass die Schwachstelle bereits in Bearbeitung ist.
Abb. 7.45: Die Notiz im Bericht
7.6.2 Verallgemeinerung der Notizen
Jede Notiz kann verallgemeinert werden. In diesem Beispiel stellen wir eine sehr weitreichende Verallgemeinerung vor, die für jeden Ziel-Rechner, jeden Port und jede Aufgabe gilt.
Abb. 7.46: Eine verallgemeinerte Notiz
Von diesem Moment an, wird die Notiz im bei den Ergebnissen angezeigt, wenn dieser NVT zutri t.
Dies betri t alle bereits erzeugten und zukünftigen Berichte bis die Notiz wieder gelöscht wird.
86
Kapitel 7. Scanning
7.6.3 Notizen verwalten
Die erzeugten Notes können Sie sich dann unter Scan Management und Notes anzeigen lassen. Hier
können Sie auch komplett neue Notes hinzufügen.
Abb. 7.47: Die Notizen können einzeln verwaltet werden.
Unter anderem sehen Sie hier, ob die von Ihnen angelegten Notizen aktuell aktiv sind. Außerdem können Sie die Notizen von hieraus editieren . Um nach einer bestimmten Notiz zu suchen, können Sie
den Suchfilter entsprechend nutzen. Dies erleichtert besonders bei vielen Notizen das Aunden einer
bestimmten Note. Dazu können Sie den Suchfilter entsprechend aufklappen und den Text entsprechend eingeben oder diesen auch direkt oben in dem Filter-Fenster eingeben. Natürlich können Sie
diese Filter auch wie in allen anderen Dialogen speichern und später wieder aufrufen.
Abb. 7.48: Die Notizen können mit einer Suche eingeschränkt werden.
7.7 Overrides und False Positives
Sie können die Ergebnisse in den Berichten nicht nur mit Hilfe von Notizen um sinnvolle oder hilfreiche
Daten ergänzen, sondern auch diese Ergebnisse in ihrem Schweregrad modifizieren. Dies wird von
dem GSM als Override (Übersteuerung) bezeichnet.
Diese Overrides eignen sich insbesondere dazu, Meldungen, die als False Positive erkannt wurden
und mit einer kritischen Severity protokolliert wurden, aber in Zukunft eine andere Severity (z.B. False
Positive) erhalten sollen, zu bearbeiten. Das gleiche gilt für Meldungen, die bisher nur die Severity Log
erhalten, lokal aber einen erhöhten Schweregrad erhalten sollen. Auch diese können dann mit einem
Override bearbeitet werden.
7.7. Overrides und False Positives
87
Die Verwendung der Overrides ist auch sinnvoll bei der Verwaltung von akzeptablen Risiken. Hier können Sie das Risiko einer Schwachstelle selbst neu einordnen und so die Risiken, die aus Ihrer Sicht nicht
kritisch sind, in dem Ergebnis neu bewerten.
7.7.1 Was ist ein False Positive?
Als False Positive wird eine Meldung bezeichnet, die ein Problem beschreibt, welches in Wirklichkeit
nicht vorhanden ist. So finden Schwachstellen-Scanner oft Indizien, die auf ein Sicherheitsproblem
hinweisen. Eine endgültige Aussage ist jedoch nicht möglich. Hier stehen nun zwei Möglichkeiten zur
Auswahl:
• Meldung einer potentiell nicht existenten Schwachstelle (False Positive).
• Unterlassung der Meldung einer potentiell existenten Schwachstelle (False Negative).
Da ein Anwender nur protokollierte Meldungen verwalten und bearbeiten kann, meldet der GSM alle
potentiell existierenden Schwachstellen um falsch-negative Meldungen zu vermeiden. Jedoch unterstützt der GSM mit verschiedenen automatischen und semi-automatischen Verfahren in deren Kategorisierung.
Bemerkung: Beachten Sie hierzu auch das neue Konzept der Quality of Detection (siehe Abschnitt
Lesen des Reports (Seite 71) and Network Vulnerability Tests (Seite 195)).
Besonders typisch ist dieses Problem bei Enterprise Linux Distributionen. Ist zum Beispiel der SSHService in der Version 4.4 installiert und meldet diese Software diese Version bei einer Verbindungsaufnahme, so schlägt ein Schwachstellenscanner, der eine Sicherheitslücke in dieser Version kennt,
an. Der Distributor hat die Schwachstelle aber vielleicht bereits behoben und eine Version 4.4-p1 verö entlicht, die auch installiert wurde. Diese Version meldet nach außen aber weiterhin die Version 4.4,
so dass der Schwachstellenscanner nicht unterscheiden kann. Wenn der Scan-Administrator diesen
Umstand kennt, kann er mit sicherstellen, dass diese Meldungen nicht mehr angezeigt werden.
7.7.2 Erzeugen eines Override
Overrides lassen sich wie die Notes unterschiedlich erzeugen. Am einfachsten erreichen Sie diese
Funktion über das jeweilige Scan-Ergebnis in dem Bericht. Rechts oben bei jeder Meldung befindet
sich das Icon .
Die Overrides haben die gleichen Funktionen wie die Notes, ergänzen diese aber um die Möglichkeit
die Bedrohungsstufe anzupassen:
• High
• Medium
• Low
• Log
• False Positive
Bedrohungen mit der Stufe False Positive werden in den Berichten nicht angezeigt. Sie können aber
auch speziell Berichte für Meldungen mit dieser Stufe erzeugen. Auch bei den Overrides können Sie
diese zeitlich beschränken.
7.7.3 Ein- und Ausschalten von Übersteuerungen
Immer wenn Übersteuerungen die Ausgabe der Ergebnisse beinflussen können, können diese einoder ausgeschaltet werden. Dies kann mit dem Icon in der Titelzeile erfolgen.
88
Kapitel 7. Scanning
Abb. 7.49: Overrides erlauben die Anpassung der Bedrohungsstufe
Abb. 7.50: Übersteuerungen können ein- und ausgeschaltet werden.
7.7.4 Automatische False-Positives (AutoFP)
Der GSM kann auch automatisch False-Positives erkennen und diese mit einem automatischen Override versehen. Hierzu muss jedoch das Zielsystem sowohl von außen als auch von innen in einem
authentifizierten Scan analysiert werden.
Ein authentifizierter Scan kann Sicherheitslücken in lokal installierter Software erkennen. So können
Schwachstellen identifiziert werden, die von lokalen Benutzern ausgenutzt werden können, oder die
einem Angreifer zur Verfügung stehen, falls er sich bereits lokalen Zugri als zum Beispiel unprivilegierter Benutzer verscha t hat. In vielen Fällen erfolgt ein Angri in mehreren Stufen und der Angreifer nutzt mehrere Sicherheitslücken aus, um seine Privilegien zu erweitern.
Der authentifizierte Scan bietet aber auch noch eine zweite mächtige Funktion, die seine Durchführung
rechtfertigt. In vielen Fällen kann durch den Scan des Systems von außen nicht einwandfrei erkannt
werden, ob eine Schwachstelle tatsächlich existent ist. Der Greenbone Security Manager meldet im
Zweifelsfall aber jede potentielle Schwachstelle. Durch den authentifizierten Scan können viele dieser
potentiellen Schwachstellen als falsch-positive Meldungen erkannt und gefiltert werden.
Besonders typisch ist dieses Problem bei Enterprise Linux Distributionen. Ist zum Beispiel der SSHService in der Version 4.4 installiert und meldet diese Software diese Version bei einer Verbindungsaufnahme, so schlägt ein Schwachstellenscanner, der eine Sicherheitslücke in dieser Version kennt,
an. Der Distributor hat die Schwachstelle aber vielleicht bereits behoben und eine Version 4.4-p1 verö entlicht, die auch installiert wurde. Diese Version meldet nach außen aber weiterhin die Version
7.7. Overrides und False Positives
89
Abb. 7.51: Automatische False-Positives (AutoFP)
4.4, so dass der Schwachstellenscanner nicht unterscheiden kann. Wurde ein authentifizierter Scan
durchgeführt, so kann der GSM erkennen, dass die Version 4.4-p1 installiert ist, die diese Schwachstelle nicht mehr besitzt.
Die automatischen False Positives werden in der Report-Filter-Funktionalität (siehe Abschnitt Powerfilter (Seite 145)) aktiviert. Die besten Ergebnisse liefert die Funktionalität bei Nutzung des Partial
CVE match.
7.8 Scan von Webanwendungen
Der Greenbone Security Manager unterstützt den Scan von Webanwendungen auf zwei Wegen:
• Mit den eigenen Network Vulnerability Tests (NVTs, mehr als 1500 mit Bedeutung für Webanwendungen).
• Mit verbundenen Scannern für Webanwendungen wie den eingebauten Scanner w3af.
Wenn die NVTs genutzt werden, werden alle für Webanwendungen relevanten NVTs bereits in den
Default Scan-Konfigurationen genutzt.
Alternativ können Sie auch eine Scan-Konfiguration nur für Webanwendungen erzeugen und nutzen.
Ein Beispiel für eine derartige Konfiguration steht zum Download zur Verfügung und kann als neue
Konfiguration importiert werden: http://greenbone.net/download/web-app-scan.xml.
Bemerkung: Wenn Sie sich nur für den Webdienst interessieren, könne Sie die Portliste des Ziels so
ändern, dass nur die Ports 80 und/oder 443 geprüft werden.
Die Scan-Konfiguration erlaubt die Feineinstellung einiger Parameter.
90
Kapitel 7. Scanning
KAPITEL 8
Berichte
Der GSM speichert sämtliche Berichte aller Scans in einer lokalen Datenbank ab. Dabei wird nicht nur
der letzte Bericht eines Scans, sondern die Berichte sämtlicher jemals durchgeführten Scans gespeichert. Dies erlaubt auch den Zugri auf Informationen aus der Vergangenheit. Die Reports enthalten
die in dem Scan gefundenen Schwachstellen und Informationen (siehe auch Abschnitt Reports (Seite 68)).
Wurde ein Scan bereits mehrfach durchgeführt, so wird auch die Entwicklung der gefundenen
Schwachstellen angezeigt. Diesen Trend finden Sie jedoch nicht auf der Seite der Reports sondern
unter Scan Management/Tasks.
Abb. 8.1: Auf der Übersicht der Tasks finden Sie in der entsprechenden Spalte auch den Trend der
gefundenen Schwachstellen bei mehrfachen Scans.
Über diese Ansicht können Sie auch nur auf die Reports eines bestimmten Scans zugreifen. Hierzu
nutzen Sie in der Ansicht die Spalte Reports/Total (siehe Abbildung Die Spalte Reports enthält die
Anzahl der insgesamt gespeicherten Reports und das Datum des letzten Reports. (Seite 91)).
Abb. 8.2: Die Spalte Reports enthält die Anzahl der insgesamt gespeicherten Reports und das Datum
des letzten Reports.
91
Hier finden Sie das Datum des letzten gespeicherten Berichtes als auch die ingesamt verfügbare Anzahl Berichte. Der erste Wert zeigt die Zahl der vollständigen Scans während die zweite Zahl die Anzahl der Berichte einschließlich der noch nicht vollendeten darstellt. Durch Anklicken der Werte erhalten Sie eine Liste der entsprechenden Berichte. Durch Anklicken des Datums wird der letzte Bericht
geladen.
8.1 Delta-Report
Wenn Sie sich mehrere Reports eines Tasks anzeigen lassen (siehe Abbildung Nun müssen Sie den
zweiten Report für den Vergleich wählen. (Seite 92)), dann können Sie auch einen Delta-Report erstellen lassen. Hierzu nutzen Sie die Funktion Compare in der Spalte Actions. Dies wählt den ersten
Report für den Vergleich aus.
Abb. 8.3: Zwei Reports des gleichen Tasks können in einem Delta-Report verglichen werden.
Das entsprechende Icon ist anschließend für den gewählten Report ausgegraut. Die Compare-Icons
der anderen Reports haben sich nun in ihrem Aussehen geändert. Sie verwenden nun das Icon , um
den zweiten Report für den Vergleich zu wählen.
Abb. 8.4: Nun müssen Sie den zweiten Report für den Vergleich wählen.
Anschließend erhalten Sie den Delta-Report. Dieser kann, wie gewohnt, in unterschiedlichen Varianten angezeigt werden und auch als PDF exportiert werden.
Der Report enhält auch die Informationen welche Zeitpunkte miteinander verglichen werden und wieviele Ergebnisse hinzugekommen oder weggefallen sind.
8.2 Report Plugins
Report Plugins definieren die Formate, mit denen aus den Scan-Resultaten ein Bericht erstellt wird.
Dies reicht vom PDF-Dokument gemäß Corporate Identity bis hin zu interaktiven Berichten wie dem
92
Kapitel 8. Berichte
Abb. 8.5: Der Delta-Report kann auch als PDF exportiert werden.
Greenbone Security Explorer. Diese Plugins können auch zur Überführung der Berichtsinformationen in weitere Datenformate genutzt werden, so dass Fremdanwendungen diese verarbeiten können
(Konnektoren).
Der Name des exportierten Berichts kann in den Benutzereinstellungen (siehe Abschnitt MySettings
(Seite 191)) angepasst werden. Greenbone unterstützt auch die Erzeugung zusätzlicher Ausgabeformate (Plugins). Anfragen, Anregungen und konkrete Vorschläge sind willkommen.
Das Report Format Plugin Framework besitzt dabei die folgenden Eigenschaften:
Einfacher Import/Export: Ein Report Plugin ist immer eine einzelne XML-Datei. Der Import kann einfach durchgeführt werden (siehe Abschnitt Import weiterer Report Plugins (Seite 95)).
Parametrisierbar: Plugins können mit Parametern ausgestattet sein, die dann in der grafischen
Oberfläche an konkrete Bedürfnisse angepasst werden können.
Content Type: Für jedes Plugin wird festgelegt welcher Art das Ergebnis ist. Verwendet werden die
aus HTTP bekannten Bezeichnungen, zum Beispiel application/pdf, graphics/png oder
text/plain. Je nach Content Type erscheinen die Plugins kontextbezogen in der Auswahl. So
z.B. die Typen text/* für den Inline Versand als E-Mail.
Signatur-Unterstützung: Über den Greenbone Security Feed werden Signaturen zu vertrauenswürdigen Plugins zur Verfügung gestellt. So kann man sich überzeugen, dass ein importiertes Plugin
von Greenbone überprüft wurde.
Die Reports können in unterschiedlichen Formaten exportiert werden.
ARF: Asset Reporting Format v1.0.0 Dieses Format erzeugt einen Bericht, der dem NIST Asset Reporting Format entspricht.
CPE - Common Platform Enumeration CSV Table Dieser Report wählte alle CPE-Tabellen und erzeugt eine einzige komma-separierte Datei.
CSV hosts Dieser Bericht erzeugt eine komma-separierte Datei mit den gefundenen Systemen.
CSV Results Dieser Bericht erzeugt eine komma-separierte Datei mit den Ergebnissen des Scans.
GSR PDF - Greenbone Security Report (recommended) Dies ist der vollständige Greenbone Sicherheitsbericht mit allen Schwachstellen in einem grafischen Ausgabeformat als PDF-Datei. Der
Topologiegrafik wird bei mehr als 100 Rechnern nicht mehr in den Bericht aufgenommen. Die
Sprache des Berichts ist Englisch.
GXR PDF - Greenbone Executive Report (recommended) Dies ist ein gekürzter Bericht mit allen
Schwachstellen in einem grafischen Format als PDF-Datei für das Management. Die Topologiegrafik wird bei mehr als 100 Rechnern nicht mehr in den Bericht aufgenommen. Die Sprache des
Berichtes ist Englisch.
8.2. Report Plugins
93
HTML Dieser Bericht im HTML-Format kann in einem Web-Browser geö net werden. Es ist eine detaillierte Liste mit einer vollständigen Beschreibung der Schwachstellen einschließlich der Notizen und Übersteuerungen mit allen Referenzen und Kreuzreferenzen. Es handelt sich um ein
neutrales Dokument ohne Bezug zu Greenbone oder dem Greenbone Security Manager. Das Dokument kann auch o ine genutzt werden und ist in Englisch verfasst.
ITG - IT-Grundschutz-Kataloge Dieser Bericht orientiert sich am BSI IT-Grundschutz Katalog. Es
stellt eine tabellarische Übersicht der gefundenen Ergebnisse in CSV-Format und deutscher
Sprache zur Verfügung.
LaTeX Dieser Bericht wird als LaTeX-Quelltext zur Verfügung gestellt. Die Sprache ist Englisch.
NBE Dies ist das alte OpenVAS/Nessus Report Format. Daher bietet es keine Unterstützung für Notizen, Overrides und einige weitere Informationen.
PDF Dies ist ein kompletter Bericht in PDF. Wie das HTML-Format ist es neutral gehalten. Die Sprache
ist Englisch.
Topology SVG Dies stellt die Ergebnisse in einem SVG-Bild dar.
TXT Dies erzeugt eine Text-Datei. Dieses Format eignet sich besonders für den Versand in einer EMail. Die Sprache ist Englisch.
Verinice ISM Erzeugt eine Import-Datei für das ISMS-Tool “verinice”.
Verinice ITG Erzeugt eine Import-Datei für das ISMS-Tool “verinice”.
XML Hiermit wird der Bericht in dem nativen GSM XML-Format exportiert. Im Gegensatz zu den anderen Formaten enthält dieses Format sämtliche Ergebnisse und bereitet diese nicht besonders
auf.
Abb. 8.6: Greenbone liefert eine Reihe Report-Plugins direkt mit.
Die Report-Plugins definieren das Format der exportierten Berichte. Dabei reduzieren viele ReportPlugins die verfügbaren Daten, um diese sinnvoll darzustellen. Das native GSM-XML-Format enthält
jedoch sämtliche Daten und kann genutzt werden, um exportierte Berichte auf einem anderen GSM zu
importieren. Hierzu nutzen Sie einen Container Task (siehe auch Abschnitt Container Task (Seite 68)).
94
Kapitel 8. Berichte
Die Übersicht (siehe Abbildung Greenbone liefert eine Reihe Report-Plugins direkt mit. (Seite 94)) zeigt
Ihnen die weiteren Details der Report Plugins an. Dabei werden zu jedem Plugin in einzelnen Spalten
die folgenden Informationen angezeigt:
Extension: Der Dateiname für den heruntergeladenen Bericht über das jeweilige Plugin besteht aus
der UUID (eindeutige interne ID des Berichts) und dieser Extension. Die Extension hilft unter anderem dem Browser eine passende Anwendung zu starten, falls der Content Type dafür nicht
ausreicht.
Content Type: Der Content-Type gibt das verwendete Format an und wird beim Download mitgesendet. So kann direkt die passende Anwendung durch den Browser gestartet werden. Darüber
hinaus ist der Content Type aber auch intern von Bedeutung: Er wird benutzt um das im Kontext passende Plugin zur Auswahl anzubieten. Beispielsweise werden für die Übermittlung des
Berichts via Email alle Plugins des Typs text/\* angeboten, da diese menschenlesbar in der
E-Mail eingebettet werden können.
Trust: Einige Plugins bestehen lediglich aus einer Datentransformation während andere einige komplexere Operationen ausführen und dabei auch Hilfsprogramme verwenden. Um einen Mißbrauch zu vermeiden, sind die Plugins digital signiert. Ist die Signatur authentisch und vertrauen
Sie dem Aussteller, so ist sichergestellt, dass Sie das Plugin in genau der vom Aussteller zertifizierten Form vorliegen haben. Die Prüfung erfolgt nicht automatisch, sondern manuell über das
Verify-Icon . Das Datum dieser Prüfung wird automatisch gespeichert. Diese Funktion sollte
unbedingt für neu importierte Plugins angewendet werden, bevor sie aktiviert werden. Für die
mitgelieferten Werks-Plugins ist dies nicht erforderlich .
Active: Die Plugins stehen nur dann in den jeweiligen Auswahllisten zur Verfügung, wenn sie aktiviert
wurden. Neu importierte Plugins sind zunächst immer deaktiviert.
Abb. 8.7: Neue Report Format Plugins können einfach importiert werden.
8.2.1 Import weiterer Report Plugins
Weitere Report Plugins lassen sich einfach importieren. Greenbone stellt auf der Seite
http://greenbone.net/technology/report_formats.de.html die folgenden zusätzlichen ReportFormat-Plugins zur Verfügung:
• Sourcefire Host Input Import (siehe auch Abschnitt Sourcefire Defence Center (Seite 226))
• OVAL System Characteristics
• OVAL System Characteristics Archive
Bemerkung: Das Berichtsformat für die verinice Anbindung ist bereits in dem Greenbone Betriebssystem enthalten. Es muss nicht mehr manuell importiert werden.
Um ein neues Report-Plugin zu importieren, müssen Sie zunächst die entsprechende XML-Datei von
Greenbone herunterladen. Anschließend wechseln Sie auf Configuration/Report Formats. Dort wählen Sie das Icon um ein neues Format hinzuzufügen.
Wählen Sie die entsprechende Datei und importieren Sie dann das Format. Nach dem Import ist das
neue Plugin zunächst nicht aktiv. Report-Plugins können durch den Herausgeber signiert werden. Diese Signatur sollte vor der Aktivierung verifiziert werden. Diese Prüfung wird bei dem Import bereits
8.2. Report Plugins
95
Abb. 8.8: Importierte Formate sollten vor der Aktivierung überprüft werden.
Abb. 8.9: Neue Formate können einfach aktiviert werden.
automatisch durchgeführt. Das Ergebnis mit dem Datum der Prüfung wird in der Spalte Trust angezeigt. Ist das Report-Plugin vertrauenswürdig, so kann es anschließend aktiviert werden. Hierzu editieren Sie das Report Plugin über das Edit-Icon in der Actions-Spalte.
96
Kapitel 8. Berichte
KAPITEL 9
Compliance und spezielle Scans
In der IT-Security-Welt ist Compliance der primäre Ansatz für die Unternehmen, ihre Informationen
und Assets zu sichern und zu schützen.
Mit Cyberkriminalität auf dem Vormarsch, sehen Regierungen die Notwendigkeit, ihre Bürger zu
schützen und beschliessen Regelwerke und Gesetze über den Datenschutz und IT-Sicherheit in der
Ho nung, unsere Identitäten und Vermögenswerte zu schützen. Information Security Verbände wie
der Information Systems Audit and Control Association (ISACA) oder der Internationalen Organisation für Normung (ISO) verö entlicht IT-Sicherheitsstandards, Rahmenbedingungen und Richtlinien
wie die Control Objectives for Information and Related Technology (COBIT) oder der Reihe ISO 27000
die Informationssicherheit Standards abdecken. Das Bundesamt für Sicherheit in der Informationstechnik (BSI), zum Beispiel, verö entlicht die IT-Grundschutz-Kataloge. Dabei handelt es sich um eine
Sammlung von Dokumenten, die nützliche Informationen zur Detektion von Schwächen und die Bekämpfung von Angri en auf IT-Umgebungen bereitzustellen. Zum besseren Schutz gegen Kreditkartendatendiebstahl verö entlicht der Payment Card Industry Security Standards Council den Payment
Card Industry Data Security Standard (PCI DSS).
Alle diese Datenschutzgesetze, Standards, Frameworks, Regeln und Vorschriften sollen Organisationen dazu bringen und unterstützen, die geeigneten Sicherheitsmaßnahmen zu implementieren,
um sich und ihre Informationsressourcen vor Angri en zu schützen. Um diese Gesetze, Normen, Frameworks, Vorschriften und Bestimmungen innerhalb einer Organisation zu implementieren muss die
Organisation ein IT-Sicherheitsrregelwerk scha en, bestehend aus Richtlinien, Standards, Baselines,
Richtlinien und detaillierte Policies.
Sicherheitsscanner wie der Greenbone Security Manager (GSM) können IT-Sicherheitsexperten dabei
unterstützen, ihre IT-Sicherheitsmaßnahmen gegen die oben genannten Vorschriften, Normen und
Rahmenbedingungen bei der Einhaltung zu überprüfen.
In den folgenden Abschnitten wird beschrieben, wie der GSM dazu verwendet werden kann, bestimmte Compliance-Prüfungen durchzuführen.
9.1 Allgemeine Policy Scans
Bei der Durchführung von Policy Scans kann normalerweise aus vier NVTs ausgewählt werden. In der
Policy Familie der NVT Database sind mindestens zwei dieser vier Policy NVTs notwending um einen
Policy Scan zu starten. Die vier NVT Typen sind:
• Base Das eigentliche NVT, das den eigentlichen Policy Scan oder Funktion ausführt.
• Matches Dieses NVT fasst alles zusammen was mit den Checks, die vom Grund-NVT durchgeführt werden, übereinstimmt.
• Violations Dieses NVT fasst alles zusammen was nicht mit den Checks, die vom Grund-NVT
durchgeführt werden, übereinstimmt.
• Errors Diese NVT fasst alles zusammen wobei Fehler bei der Durchführung des Policyscans aufgetreten sind.
97
Das Base-NVT muss ausgewählt werden, da es die eigentlichen Tests durchführt. Die anderen drei
Plugins können je nach Bedarf ausgewählt werden. Zum Beispiel, wenn passende Muster belanglos
sind, dann sollte nur das Violations Plugin zusätzlich ausgewählt werden.
9.1.1 File Content
File Content Checks sind eine Richtlinien-Prüfung, bei der nicht ausdrücklich Schwachstellen getestet werden. Es geht hierbei vielmehr um die Überprüfung von Dateiinhalten und deren Konformität
bezüglich vorgegebener Richtlinien.
Für die Überprüfung der Richtlinien stellt der GSM ein NVT zur Verifikation von Dateiinhalten zur Verfügung. Dieses prüft bestimmte Inhalte von Dateien gemäss den vorgegebenen Richtlinien.
Generell fällt der Tests in die Kategorie der authentifizierten Tests, das heißt er erfordert eine Anmeldung auf dem zu prüfenden System.
Der Dateiinhaltstest kann nur auf Systemen ausgeführt werden die das Kommando “grep” unterstützen. In der Regel sind das Linux und Linux-ähnliche Systeme.
Abb. 9.1: Das Plugin befindet sich in der „Policy“ Familie
Es gibt nun vier verschiedene NVT’s für die Überprüfung von Dateiinhalten:
• File Content: Hier werden die eigentlichen Inhalte der Dateien überprüft.
• File Content: Matches: Dieses Plugin zeigt die Muster und Dateien an, welche die Inhaltsüberprüfung bestanden haben (vorgegebene Muster sind in den Dateien korrekt)
• File Content: Violations: Dieses Plugin zeigt die Muster und Dateien an, welche die Inhaltsüberprüfung nicht bestanden haben (vorgegebene Muster sind falsch oder fehlen)
• File Content: Errors: Diese Plugin zeigt die Dateien an, bei denen ein Fehler aufgetaucht ist (z.B.
Datei ist nicht vorhanden)
Das Plugin File Content muss bei einem Dateiinhaltstest immer aktiviert sein, da in diesem die eigentlichen Tests durchgeführt werden. Die anderen drei Plugins können je nach Präferenz aktiviert werden.
Interessieren z.B. nur die Muster, welche nicht korrekt sind, wird nur das Plugin File Content: Violations
zusätzlich aktiviert.
Muster
Für den Dateiinhaltstest muss zunächst eine Datei mit den zu überprüfenden Muster und weiteren
Angaben erstellt werden:
filename|pattern|presence/absence
/tmp/filecontent_test|̂ paramter1=true.*$|presence
/tmp/filecontent_test|̂ paramter2=true.*$|presence
/tmp/filecontent_test|̂ paramter3=true.*$|absence
/tmp/filecontent_test_notthere|̂ paramter3=true.*$|absence
Diese Datei enthält zunächst verpflichtend die Zeile filename|pattern|presence/absence. Die nachfolgenden Zeilen enthalten jeweils einen Testeintrag pro Zeile. Jede Zeile enthält dabei drei Elemente,
die durch | getrennt werden. Das erste Feld enthält den Pfad und Namen der zu prüfenden Datei, das
zweite Feld das zu prüfende Muster, und das dritte, ob das Muster präsent oder absent sein muss.
98
Kapitel 9. Compliance und spezielle Scans
Abb. 9.2: Diese Datei muss anschließend in die Details des Plugins importiert werden
Das zu prüfende Muster, das zweite Element der Zeile, wird als regulärer Ausdruck (regular expression) definiert und wird entsprechend in der angegebenen Datei überprüft.
Hierzu muss die Datei mit Browse ausgewählt und Upload file selektiert werden. Ein Klick auf Save
Config startet dann den Upload der Datei.
Abb. 9.3: Wenn bereits eine Datei hinterlegt ist ändert sich die Maske
Ein Klick auf das Icon erlaubt den Download der hinterlegten Datei. Die Selektion von Replace existing file with: erlaubt es, ein neues File zu hinterlegen. Die Optionen zum Ändern stehen nur zur Verfügung, wenn die Scan Konfiguration nicht in Benutzung ist, um eine Revisionssicherheit der Scanergebnisse zu erreichen.
Schweregrad
Die Dateiinhaltstests rapportieren die Resultate per default als Log-Meldung. Durch die Aufteilung in
drei NVT’s ist es nun möglich, individuell den Schweregrad (Severity) mittels Overrides anzupassen.
Im Bild sind die Schweregrade von File Content: Violations und File Content: Errors via Overrides angepasst worden, um in den Reports entsprechend gekennzeichnet zu werden.
Beispiel
Hier (policy_file_content_example.xml11 ) kann eine Beispiel Scan Config mit allen NVT’s für den Dateiinhaltstest heruntergeladen werden. Die dazugehörige Testdatei (filecontent_test12 ) muss ebenfalls
11
12
http://www.greenbone.net/download/scanconfigs/policy_file_content_example.xml
http://www.greenbone.net/download/misc/filecontent_test
9.1. Allgemeine Policy Scans
99
heruntergeladen und in das /tmp/ Verzeichnis des Zielsystems gespeichert werden.
Erstellen Sie nun eine neue Aufgabe und starten Sie diese für das Zielsystem auf dem Sie die Testdateien abgelegt haben. Denken Sie daran, dass es ein authentifizierter Scan mit den passenden Zugangsdaten sein muss.
Die Overrides können entweder vor oder nach einem Scan erstellt werden. Letzteres ist einfacher, da
kann der entsprechende Verweis durch einen einfachen Klick in der Ergebnis-Seite erstellt werden.
9.1.2 Registry Content
Die Registry ist eine Datenbank in Windows, die wichtige Informationen über die Hardware, installierte Programme und Einstellungen und Profile der einzelnen Benutzer-Accounts auf dem Computer
enthält. Windows greift kontinuierlich auf die Informationen in der Registry zu 105 .
Aufgrund des Aufbaus der Windows-Registry registriert sich jedes Programm bzw. Anwendung, die
unter Windows installiert wird in der Windows-Registry, und hat als solche einen Registrierungseintrag. Selbst Malware und andere bösartigen Programme hinterlassen in der Regel Spuren in der
Windows-Registry. Die Registry kann nun genutzt werden, um nach bestimmten Anwendungen oder
Malwarebezogenen Informationen wie Versionslevels und -nummern zu suchen. Auch fehlende oder
geänderte Registry-Einstellungen könnten zu einer potentiellen Sicherheitsrichtlinienverletzung auf
einem Endsystem hinweisen. GSM bietet ein Richtlinienprüfung Modul, um Registry-Einträge auf
Zielsystemen zu überprüfen. Dieses Modul überprüft das Vorhandensein oder Fehlen von RegistryEinstellungen sowie Registry-Verstöße. Da die Registry einzigartig für Windows-Systeme ist, kann
diese Überprüfung nur auf Windows-Systemen ausgeführt werden. Um auf dem Zielsystem auf die
Registry zugreifen zu können, muß sich der Test auf dem Zielsystem authentifizieren.
Abb. 9.4: Die NVT’s befindet sich in der „Policy“ Familie.
Es gibt nun vier verschiedene NVT’s für die Überprüfung von Registry-Inhalten.
• Windows Registry Check: Hier werden die eigentlichen Inhalte der Registry überprüft.
• Windows Registry Check: OK: Dieses NVT zeigt die Registry-Einstellungen an, welche den Registrytest bestanden haben (Registry-Inhalt korrekt)
• Windows Registry Check: Violations: Dieses NVT zeigt die Registry-Einstellungen an, welche den
Registrytest nicht bestanden haben (Registry-Inhalt falsch).
105
http://windows.microsoft.com/en-ca/windows-vista/what-is-the-registry
100
• Windows Registry Check: Errors: Dieses NVT zeigt die Registry-Einstellungen an, bei denen ein
Fehler aufgetaucht ist (z.B. Registry-Inhalt wurde auf dem Zielsystem nicht gefunden).
Das Plugin Windows Registry Check muss bei einem Registrytest immer aktiviert sein, da in diesem die
eigentlichen Tests durchgeführt werden. Die anderen drei Plugins können je nach Präferenz aktiviert
werden. Interessieren z.B. nur die falschen Registry-Inhalte, wird nur das Plugin Windows Registry
Check: Violations zusätzlich aktiviert.
Muster für Registry-Inhalt
Eine Datei mit den Referenz-RegistryInhalten muss erstellt werden: Hier ein Beispiel:
Present|Hive|Key|Value|ValueType|ValueContent
TRUE|HKLM|SOFTWARE\Macromedia\FlashPlayer\SafeVersions|8.0|REG_DWORD|33
TRUE|HKLM|SOFTWARE\Microsoft\Internet Explorer
TRUE|HKLM|SOFTWARE\Microsoft\Internet Explorer|Version|REG_SZ|9.11.10240.16384
TRUE|HKLM|SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system|DWORD:
LocalAccountTokenFilterPolicyREG_DWORD|1
FALSE|HKLM|SOFTWARE\Virus
TRUE|HKLM|SOFTWARE\ShouldNotBeHere
Diese Datei enthält zunächst verpflichtend die Zeile Present|Hive|Key|Value|ValueType|ValueContent.
Die nachfolgenden Zeilen enthalten jeweils einen Testeintrag pro Zeile. Jede Zeile enthält dabei sechs
Elemente, die durch | getrennt werden. Das erste Feld enthält ob ein Registry-Eintrag existiert oder
nicht, das zweite Feld den Hive in dem sich ein Registry-Eintrag befindet, das dritte den Schlüssel oder
Key, das vierte den Wert, das fünfte den Wert-Typ under das sechste den Wert-Inhalt.
Schweregrad
Die Registry-Inhaltstests rapportieren die Resultate per default als Log-Meldung. Durch die Aufteilung in drei NVT’s ist es nun möglich, individuell den Schweregrad (Severity) mittels Overrides anzupassen.
Im Bild Schweregrad (Severity) Overrides angewandt für die Windows Registry Tests. (Seite 103) sind
die Schweregrade von Registry Content: Violations und Registry Content: Errors via Overrides angepasst worden um in den Reports ensprechend gekennzeichet zu werden:
Beispiel
Hier (policy_registry_ScanConfig.xml13 ) steht eine Beispiel-Konfiguration zum Download zur Verfügung die alle relevanten NVT’s für den Registry-Test ausgewählt hat. Die zugehörige Test-Datei (Registry_test.txt14 ) sollte in das Verzeichnis /tmp/ auf dem Zielsystem heruntergeladen werden.
Erstellen Sie nun eine neue Aufgabe und starten Sie diese für das Zielsystem auf dem die Testdateien
gespeichert wurden.
13
14
http://www.greenbone.net/download/misc/policy_registry_ScanConfig.xml
http://www.greenbone.net/download/misc/Registry_test.txt
101
Abb. 9.5: Diese Datei muss anschließend in die Details des Plugins importiert werden:
9.1.3 File Checksums
File Checksum Checks sind eine Richtlinien-Prüfung, bei der nicht ausdrücklich Schwachstellen getestet werden. Vielmehr geht es hierbei um die Überprüfung der Unversehrtheit von Dateien. Für die
Überprüfung der Richtlinien stellt der GSM ein Modul zur Verifikation von Dateien zur Verfügung. Dieses prüft den Inhalt von Dateien mittels MD5 oder SHA1 Prüfsummen (Checksums). Generell fällt der
Test in die Kategorie der authentifizierten Tests, das heißt er erfordert eine Anmeldung auf dem zu
prüfenden System. Ein Prüfsummentest kann nur auf Systemen ausgeführt werden die die Berechnung von Prüfsummen unterstützen. In der Regel sind das Linux und Linux-ähnliche Systeme. GSM
stellt jedoch auch eine Prüfsummentest-Variante für Windows Systeme zur Verfügung (siehe Windows (Seite 105)).
Es sind vier verschiedene NVT’s für die Überprüfung von Datei-Prüfsummen zuständig:
• File Checksums: Hier werden die eigentlichen Checksummen der Dateien überprüft.
• File Checksums: Matches: Dieses NVT zeigt die Dateien an, welche den Prüfsummentest bestanden haben (Prüfsumme korrekt).
• File Checksums: Violations: Dieses Plugin zeigt die Dateien an, welche den Prüfsummentest nicht
bestanden haben (Prüfsumme falsch).
• File Checksums: Errors: Diese Plugin zeigt die Dateien an, bei denen ein Fehler aufgetaucht ist
(z.B. Datei ist nicht vorhanden).
102
Abb. 9.6: Wenn bereits eine Datei hinterlegt ist ändert sich die Maske.
Abb. 9.7: Schweregrad (Severity) Overrides angewandt für die Windows Registry Tests.
Das Plugin File Checksums muss bei einem Prüfsummentest immer aktiviert sein, da in diesem die
eigentlichen Tests durchgeführt werden. Die anderen drei Plugins können je nach Präferenz aktiviert
werden. Interessieren z.B. nur die Dateien mit falscher Prüfsumme, wird nur das Plugin File Checksums: Violations zusätzlich aktiviert.
Prüfsummen-Muster
Für den Prüfsummentest muss zunächst eine Datei mit den Referenzprüfsummen erstellt werden,
hier ein Beispiel:
Checksum|File|Checksumtype
6597ecf8208cf64b2b0eaa52d8169c07|/bin/login|md5
ed3ed98cb2efa9256817948cd27e5a4d9be2bdb8|/bin/bash|sha1
7c59061203b2b67f2b5c51e0d0d01c0d|/bin/pwd|md5
Diese Datei enthält zunächst verpflichtend die Zeile Checksum|File|Checksumtype. Die nachfolgenden
Zeilen enthalten jeweils einen Testeintrag pro Zeile. Jede Zeile enthält dabei drei Elemente, die durch
| getrennt werden. Das erste Feld enthält die Prüfsumme als Hexadezimalzahl, das zweite Feld den
Pfad und Namen der zu prüfenden Datei, und das dritte die Art der Prüfsumme. Derzeit werden MD5
Abb. 9.8: Die NVT’s befindet sich in der „Policy“ Familie.
103
und SHA1 Prüfsummen unterstützt.
Bemerkung: Die Prüfsummen sowie der Typ müssen mit Kleinbuchstaben geschrieben werden.
Abb. 9.9: Diese Datei muss anschließend in die Details des Plugins importiert werden:
Abb. 9.10: Wenn bereits eine Datei hinterlegt ist ändert sich die Maske.
Schweregrad
Die Prüfsummentests rapportieren die Resultate per default als Log-Meldung. Durch die Aufteilung
in drei NVT’s ist es nun möglich, individuell den Schweregrad (Severity) mittels Overrides anpassen.
Im Bild Schweregrad (Severity) Overrides angewandt für die File Checksums Tests. (Seite 105) sind
die Schweregrade von File Checksum: Violations und File Checksum: Errors via Overrides angepasst
worden um in den Reports ensprechend gekennzeichet zu werden:
104
Abb. 9.11: Schweregrad (Severity) Overrides angewandt für die File Checksums Tests.
Beispiel
Hier (policy_file_checksums_example.xml15 ) kann eine Beispiel Scan Config mit allen NVT’s
für den Prüfsummentest heruntergeladen werden. Die dazugehörigen Testdateien (policy_file_checksums_testfiles16 ) können hier heruntergeladen und danach in das /tmp/
Verzeichnis des Zielsystems extrahiert werden. Dies geschieht z.B. mit tar xvC /tmp/
testfiles_checksum_check.tar.gz.
Erstellen Sie nun eine neue Aufgabe für das Zielsystem auf dem Sie die Testdateien gespeichert haben.
Denken Sie daran, dass es ein authentifizierter Scan mit den passenden SSH Zugangsdaten sein muss.
Windows
GSM stellt ein gleiches Modul für Prüfsummentest auch für Windows Systeme zur Verfügung. Da Windows kein mitgeliefertes Programm hat, um Prüfsummen zu erstellen muss ein solches entweder zuerst manuell oder durch das NVT installiert werden. GSM verwendet für die Prüfsummengeneration
das Programm Rehash (http://rehash.sourceforge.net/).
Wie beim Prüfsummentest unter Linux befinden sich die NVTs in der Policy Familie.
Abb. 9.12: Analog zu den Linux NVTs sind vier NVTs für die Prüfsummentests unter Windows zuständig.
Bitte beachten Sie die zwei technischen Betriebsmodi für diese Prüfung: Entweder wird eine vorab
auf den Zielsystemen installiertes Tool verwendet oder das Tool ReHash wird vollautomatisch durch
die Prüfroutine auf dem Zielsystem installiert und ggf. nach Ausführung wieder deinstalliert.
15
16
http://www.greenbone.net/download/scanconfigs/policy_file_checksums_example.xml
http://www.greenbone.net/download/misc/policy_file_checksums_testfiles.tar.gz
105
Abb. 9.13: Im NVT “Windows file Checksums” müssen nun die Preferences gesetzt werden.
Es kann über die Preferences bestimmt werden, ob das Prüfsummenprogramm ReHash nach dem
Test wieder gelöscht werden soll oder nicht. Um z.B. wiederkehrende Tests zu beschleunigen kann
man das Programm auf dem System belassen. Des Weiteren kann bestimmt werden, ob das Prüfsummenprogramm durch das NVT auf dem Zielsystem überhaupt installiert werden soll. Falls dies
nicht gewünscht wird, muss das Programm manuell auf dem Zielsystem (in C:\Windows\system32
(für 32-Bit Systeme) oder C:\Windows\SysWOW64 (für 64-Bit Systeme) installiert werden und für den
authentifizierten Benutzer ausführbar sein. Die Referenzdatei mit den Prüfsummen muss ebenfalls
analog zum Linuxprüfsummentest hochgeladen werden. Die Datei ist dabei genau gleich aufgebaut
wie oben beim Linux Test.
Beispiel Windows
Hier (sample_config-Windows_file_Policy.xml17 ) kann eine Beispiel Scan Config mit allen NVT’s für
den Prüfsummentest für Windows heruntergeladen werden. Die dazugehörigen Testdateien (windows_checksums_testfiles.zip18 ) können hier heruntergeladen und danach auf das Zielsystems gespeichert werden.
Gehen Sie bzgl. Task und Overrides wie oben beschrieben vor.
9.1.4 CPE-basiert Richtlinien prüfen
CPE steht für Common Product Enumeration19 . Es handelt sich um ein strukturiertes Benennungsschema für IT-Systeme, IT-Platformen und Softwarepakete.
Mit anderen Worten: CPE bietet eine eindeutige Identifikationsnummer für praktisch jedes Softwareprodukt für das eine Schwachstelle bekannt ist.
Das CPE-Verzeichnis wird von U.S. National Institute for Standards and Technology (NIST)20 gepflegt
und wurde von MITRE Corporation (MITRE)21 und NIST entwickelt. Zum Ende 2014 hat MITRE bekannt
gegeben, dass das gesamte geistige Eigentum im Bezug auf CPE and NIST übertragen wurde. MITRE
hält noch immer die CVE (Common Vulnerability Enumeration) und andere relevante Sicherheitsstandards.
17
http://www.greenbone.net/download/scanconfigs/sample_config-Windows_file_Policy.xml
http://www.greenbone.net/download/misc/windows_checksums_testfiles.zip
19 http://scap.nist.gov/specifications/cpe/
20 http://www.nist.org
21 http://www.mitre.org/
18
106
CPE-basiert einfache Sicherheitsrichtlinien prüfen
Bei jedem Scan-Vorgang werden die CPEs zu den vorgefundenen Produkten erfasst. Dies passiert unabhängig von der Frage ob die Produkte ein Sicherheitsproblem aufweisen oder nicht. Auf dieser Basis
ist es möglich einfache Sicherheitsrichtlinien zu formulieren und deren Einhaltung zu prüfen. Mit dem
Greenbone Security Manager lassen sich sowohl Richtlinien auf das Vorhandensein von Produkten als
auch auf das Fehlen von Produkten formulieren. Diesen Fällen kann jeweils manuell via Overrides ein
Schweregrad zugeordnet werden, der dann entsprechend im Bericht auftauchen wird.
Richtlinienkonformität prüfen
Dieses Beispiel zeigt, wie überprüft werden kann, ob bestimmte Produkte bezüglich einer Richtlinie
konform in einer IT-Umgebung installiert sind und die Konformität bzw. Abweichungen mit entsprechendem Schweregrad angezeigt werden kann.
1. Die Information ob ein bestimmtes Produkt auf den Zielsystemen vorliegt wird durch ein spezielles oder auch unabhängig voneinander von verschiedenen Network Vulnerability Tests (NVTs)
eingeholt. D.h., dass man für ein bestimmtes Produkt eine spezifische Scan Configuration erstellen kann die sich ausschließlich auf diese Produkt konzentriert und keine anderen Scans ausführt. Der Vorteil einer solchen speziellen Scan Configuration ist, dass sie wesentlich schneller
ausgeführt werden kann als eine umfangreiche Scan Configuration wie z.B. Full and Fast. Der
Nachteil einer speziellen Scan Configuration ist, dass man eine gewisse Erfahrung mitbringen
sollte um genau die richtigen NVTs auszuwählen und dabei auch eine maximale Tre erwahrscheinlichkeit zu erreichen. Für den Anfang ist es einfacher, eine umfangreiche Scan Configuration als Basis zu verwenden. Dann braucht man sich nicht um das zu suchende Produkt im
besonderen zu kümmern sondern trägt nur dessen CPE entsprechend ein. Dieses Beispiel geht
den einfachen Weg. Als erstes wird eine Kopie der Scan Configuration Full and Fast erstellt, denn
Full and Fast ist als voreingestellte Scan Configuration nicht änderbar.
2. Bearbeiten Sie die eben erstellte Scan Configuration indem sie auf
klicken.
3. Auf der Übersichtsseite zu dieser Scan Configuration werden im Abschnitt Network Vulnerability Test Preferences alle NVTs, die man parametrisieren kann aufgelistet. Über kann direkt zur
Bearbeitung eines bestimmten NVTs gesprungen werden, anstatt sich durch die Familienstruktur (die hier benötigten NVT’s befinden sich in der Familie Policy) durchzuklicken.
107
4. Es läßt sich entweder eine einzelne CPE direkt angeben oder eine Liste von CPEs in einer Datei, die
danach importiert werden muss (über Browse die Datei auswählen und Upload file auswählen).
Hier ist ein Beispiel bei dem Internet Explorer 9 und ClamAV 0.98 überprüft wird:
cpe:/a:microsoft:ie:9
cpe:/a:clamav:clamav:0.98
In diesem Beispiel besteht die Richtlinie, dass die angegebenen CPE’s vorhanden sein müssen (“present”). D.h. es interessieren hier vor allem Verstösse gegen diese Richtlinie (fehlende oder nicht korrekte Produkte/Versionen).
Bestätigen Sie Ihre eingaben mit Save Config.
5. Generell rapportieren Policy Tests die Resultate als “Log”-Meldung. Soll dies geändert werden
muss dies über Overrides erfolgen. In diesem Beispiel sollen Verstösse gegen die Richtlinie mit
einem erhöhten Schweregrad rapportiert werden.
Dazu muss über das Scan Management ein neuer Override erstellt werden. Als OID wird in diesem Fall “1.3.6.1.4.1.25623.1.0.103964” (für das NVT “CPE-based Policy Check Violations”) und ein
neuer Schweregrad von 5.0 (Medium) angegeben.
6. Falls die Erkennungsleistung über lokale Sicherheitstests erhöht werden soll, dann sollte zunächst ein entsprechender Zugang konfiguriert werden. Falls noch nicht geschehen, erstellen Sie dafür einen entsprechenden Anwender auf den Zielsystemen (ein niedrig privilegiertes
Benutzer-Konto reicht aus).
7. Nun werden die Zielsysteme (Targets) festgelegt und ggf. mit den entsprechenden Credentials
verknüpft.
8. Als nächstes wird die Aufgabe (Task) erstellt. Dafür kombinieren Sie die oben erstellte Scan Configuration mit den erstellten Zielsystemen.
9. Der Scan wird gestartet in dem für den eben erstellten Task auf geklickt wird. Es kann einige
Zeit dauern, bis der Scan abgeschlossen ist. Den aktuellen Stand des Scans erhalten Sie indem
Sie auf klicken.
108
10. Sobald der Status auf Done wechselt, ist der vollständige Bericht verfügbar. Sie können aber
auch schon während des Scans die bereits gefundenen Ergebnisse einsehen. Um sich nur die
Ergebnisse der Prüfung der CPE-basierten Sicherheitsrichtlinie anzeigen zu lassen, lässt sich
ein entsprechender Filter formulieren (Suchtext “cpe”).
11. In diesem Beispiel wurde ClamAV 0.98 auf einem der Zielsysteme gefunden und als Log angezeigt.
Internet Explorer 9 wurde jedoch auf dem Zielsystem nicht gefunden und wie mit dem Override definiert als “Medium-Risk” Problem angezeigt.
Problematische Produkte auffinden
Dieses Beispiel zeigt, wie das Vorhandensein eines problematischen Produktes in einer IT-Umgebung
geprüft und entsprechend angezeigt wird.
1. Führen Sie die Schritte 1 bis 3 wie bei der oben Beschriebenen Methode zum Überprüfen von
Richtlinien durch.
Bedenken Sie bei der Wahl eines allgemeinen Scans wie “Full and Fast”, dass dann sowohl die
reine Anwesenheit eines Produktes auf der Festplatte als auch dessen Ausführung (besonders
109
z.B. als Dienst) gleich behandelt wird.
D.h., falls Sie ganz sicher sein wollen, dass das gewünschte Produkt auch tatsächlich als Dienst
aktiv läuft sollten die Prüfungen die lediglich das Vorhandensein prüfen ausgeschaltet werden.
Wenn Sie sich die Arbeit noch nicht machen wollen, können Sie bei ausgelösten Alarm aber auch
anhand der einzelnen Testergebnisse nachlesen ob ein Dienst oder nur eine Installation gefunden wurde.
2. Diesmal wird nach einem einzelnen CPE (Internet Explorer 6) gesucht.
In diesem Beispiel wird eingestellt, dass das eingegebene CPE vorhanden ist (“present”).
Bestätigen Sie Ihre eingaben mit Save Config.
Dazu muss über das Scan Management ein neuer Override erstellt werden. Als OID wird in diesem Fall “1.3.6.1.4.1.25623.1.0.103963” (für das NVT “CPE-based Policy Check OK”, also) und ein
neuer Schweregrad von 10.0 (High) angegeben.
4. Falls die Erkennungsleistung über lokale Sicherheitstests erhöht werden soll, dann sollte zunächst ein entsprechender Zugang über die Credentials Funktion konfiguriert werden. Führen
Sie dazu die Schritte 6 bis 9 im obigen Beispiel aus, um lokale Sicherheitstest zu ermöglichen
und einen neuen Task mit den Zielsystemen zu erstellen und zu starten.
auch schon während des Scans die bereits gefundenen Ergebnisse einsehen.
Um sich nur die Ergebnisse der Prüfung der CPE-basierten Sicherheitsrichtlinie anzeigen zu lassen, läßt sich ein entprechender Filter formulieren (Suchtext “cpe”).
110
6. In diesem Beispiel wurde der Internet Explorer 6 auf einem der Zielsysteme gefunden und via
Override als schwerwiegendes Problem rapportiert.
Abwesenheit wichtiger Produkte feststellen
Dieses Beispiel zeigt wie das Fehlen eines bestimmten Produktes in einer IT-Umgebung als schwerwiegendes Problem eingestuft und entsprechend rapportiert wird.
1. Führen Sie die Schritte 1 bis 3 wie bei der oben Beschriebenen Methode zum Überprüfen von
Richtlinien durch.
Bedenken Sie bei der Wahl eines allgemeinen Scans wie “Full and Fast”, dass dann sowohl die
reine Anwesenheit eines Produktes auf der Festplatte als auch dessen Ausführung (besonders
z.B. als Dienst) gleich behandelt wird.
D.h., falls Sie ganz sicher sein wollen, dass das gewünschte Produkt auch tatsächlich als Dienst
aktiv läuft sollten die Prüfungen die lediglich das Vorhandensein prüfen ausgeschaltet werden.
Wenn Sie sich die Arbeit noch nicht machen wollen, können Sie bei ausgelösten Alarm aber auch
anhand der einzelnen Testergebnisse nachlesen ob ein Dienst oder nur eine Installation gefunden wurde.
2. Diesmal wird die Konfiguration von CPE-based Policy Check so vorgenommen, dass überprüft
wird, ob sich Norton Antivirus auf den Zielsystemen befindet. In diesem Fall wird dies über das
Fehlen (“missing”) rapportiert.
111
Dazu muss über das Scan Management ein neuer Override erstellt werden. Als OID wird in diesem Fall “1.3.6.1.4.1.25623.1.0.103963” (für das NVT “CPE-based Policy Check OK”, also) und ein
neuer Schweregrad von 10.0 (High) angegeben.
4. Soll auch das reine Vorhandensein einer Installation des Produktes berücksichtigt werden, dann
kann die die Erkennungsleistung über lokale Sicherheitstests erhöht werden. In Fällen in denen
Sie einen laufenden Netzwerk-Dienst suchen, macht dies in der Regel keinen Sinn sondern erhöht die Anzahl der Fehlalarme (“False Positives”’).
Um lokale Sicherheitstests zu ermöglichen und einen Task mit den Zielsystemen zu erstellen
und zu starten führen Sie die Schritte 6 bis 9 aus dem Beispiel Richtlinienkonformität prüfen
(Seite 107) aus.
auch schon während des Scans die bereits gefundenen Ergebnisse einsehen.
Um sich nur die Ergebnisse der Prüfung der CPE-basierten Sicherheitsrichtlinie anzeigen zu lassen, läßt sich ein entprechender Filter formulieren (Suchtext “cpe”).
112
6. In diesem Beispiel wurde Norton Antivirus auf einem der Zielsysteme nicht gefunden.
9.2 Standardrichtlinien
9.2.1 IT-Grundschutz
Über den Greenbone Security Manager können automatische Prüfungen zu den IT-GrundschutzKatalogen des Bundesamt für Sicherheit in der Informationstechnik22 (BSI) ausgeführt werden.
Unterstützt wird die jeweils aktuelle Ergänzungslieferung mit Prüfungen für über 80 Maßnahmen.
Das ist die maximale Zahl von Maßnahmen die sich überhaupt mit automatischen Test unterstützen
lassen.
Einige Maßahmen sind recht umfangreich und bestehen aus vielen Einzelprüfungen. Diverse Maßnahmen adressieren spezielle Betriebssysteme und werden dann auch nur für diejenigen ausgeführt.
22
http://www.bsi.de
9.2. Standardrichtlinien
113
Die Anzahl und Art der geprüften Systeme spielt für den Greenbone Security Manager keine Rolle.
Damit wird der Greenbone Security Manager zum schnellen Mitarbeiter bei der Durchführung eines
IT-Grundschutz Audits und erlaubt überhaupt erst eine automatische Prüfung auf Verstöße als regelmäßigen Vorgang im Hintergrund.
Prüfung IT-Grundschutz
Dieses Beispiel führt eine einfache Prüfung gemäß der IT-Grundschutz-Kataloge durch.
1. Importieren Sie die Scan Konfiguration IT-Grundschutz Scan23 . Für verinice Kopplung:
<http://www.greenbone.net/download/scanconfigs/it-grundschutz-discovery-v2.xml>‘_.
Sie beinhaltet die Einstellungen um sämtliche Prüfungen auszuführen. Die eigentlichen Prüfungen
sind nicht direkt einzeln ausgewählt sondern es wird ein Gesamtresultat erstellt.
2. Der größte Teil der Maßnahmenprüfungen basiert auf lokalen Sicherheitstests. Dafür muss ein
entsprechender Zugang konfiguriert werden. Falls noch nicht geschehen, erstellen Sie dafür
einen entsprechenden Anwender auf den Zielsystemen (je höher das Benutzer-Konto privilegiert ist, desto mehr Maßnahmen können geprüft werden).
3. Nun werden die Zielsysteme (Targets) festgelegt und ggf. mit den entsprechenden Credentials
verknüpft.
23
http://www.greenbone.net/download/scanconfigs/it-grundschutz-v2.xml
114
4. Nun können Sie die Aufgabe (Task) erstellen. Dafür kombinieren Sie die oben importierte Scan
Konfiguration mit den entsprechend erstellten Zielsystemen.
5. Die Prüfung wird gestartet, in dem Sie für den eben erstellten Task auf klicken. Es kann einige
Sie auf klicken.
auch schon während des Scans die bereits gefundenen Ergebnisse einsehen. Beachten Sie, dass
für die Textform des Berichtes im Filter die Kategorie “Low” eingeschaltet werden muss.
Mit der importierten Scan Konfiguration werden 2 Varianten des Ergebnisses erstellt: eine Übersicht in Textform (unter “general/IT-Grundschutz”) und eine Tabelle für weitere Verarbeitung
(unter “general/IT-Grundschutz-T”). Für letztere muss im Filter die Kategorie “Log” eingeschaltet werden.
Übernahme der Ergebnisse in eine Tabellenkalkulation
1. Wählen Sie entweder im Report-Filter oder in der Task-Übersicht das Download-Format “ITG”.
Hinweis: Bei Verwendung über den Report-Filter muss unbedingt die Kategorie “Log” aktiviert
sein.
Bei diesem Download werden die tabellarischen Ergebnisse für sämtliche Zielsysteme automatisch
herausgesucht und zusammengeführt.
2. Importieren Sie nun die ITG-Datei als sogenannte CSV-Tabelle in Ihre Tabellenkalkulation.
Obiges Beispiel zeigt den Import in OpenOce 3.2. Beachten Sie insbesondere, dass Sie folgende Einstellungen vornehmen, sofern diese nicht bereits vorausgewählt sind:
• Zeichensatz: UTF-8
• Trenner: Das “Pipe”-Symbol (senkrechter Strich)
• Texttrenner: Das doppelte Anführungszeichen
• Letzte Spalte vom Typ “Text”
115
3. Nun stehen die Ergebnisse in der Tabellenkalkulation zur Verfügung:
4. Daraus lassen sich je nach belieben einfache (wie im folgenden Screenshot) oder natürlich auch
recht umfangreiche, individuelle Analysen oder Berichte gestalten.
Übernahme der Ergebnisse in IT-Grundschutz Tools
Es gibt eine Reihe von Anwendungen die dabei Helfen das Vorgehen gemäß IT Grundschutz zu strukturieren, zu erfassen und zu steuern.
Das Bundesamt für Sicherheit in der Informationstechnik bietet auf dessen Website eine Übersicht
über IT-Grundschutz Tools24 an.
Für einen Import der Resultate des IT-Grundschutz-Scans in das jeweilige Tool kontaktieren Sie bitte
den Hersteller des Tools und bei weitergehenden Fragen auch gerne den Support von Greenbone.
Ergebnis-Klassen der IT-Grundschutz Prüfung
Die folgenden Ergebnis-Klassen können bei der Prüfung entstehen:
• Not fulfilled (FAIL): Für das Zielsystem wurde festgestellt, dass die Maßnahme nicht erfüllt ist.
• Fulfilled (OK): Für das Zielsystem wurde festgestellt, dass die Maßnahme erfüllt ist.
24
https://www.bsi.bund.de/cln_174/DE/Themen/weitereThemen/GSTOOL/AndereTools/anderetools_node.html
116
• Error (ERR): Die Prüfroutine konnte nicht ordnungsgemäß ausgeführt werden. Z.B. benötigen
die Prüfungen einiger Maßnahmen Credentials. Fehlen diese, kann die Prüfung aus technischen Gründen nicht ausgeführt werden. Falls keine Credentials mitgegeben werden, werden recht viele Prüfungen diesen Status haben.
• Check of this measure is not available (NI): Grundsätzlich wird davon ausgegangen, dass diese Maßnahme automatisiert prüfbar ist. Es ist jedoch noch keine Implementierung erfolgt.
Bei neu erschienenen Ergänzungslieferungen gilt dies zunächst für eine Reihe von Maßnahmen. Der Greenbone Security Feed wird jedoch zügig aktualisiert bis diese ErgebnisKlasse nicht mehr vorkommt.
• Check of the measure is not implemented (NA): Eine Reihe von Maßnahmen der ITGrundschutzkataloge sind zu allgemein gehalten um eine konkrete automatische Prüfung
durchzuführen. Andere Maßnahmen beschreiben ein rein manuell machbare Prüfungen
und fallen damit ebenfalls in die Klasse der nicht implementierbaren Tests.
• Check not suited for the target system (NS): Einige Maßnahmen beziehen sich ausschließlich
auf einen konkreten Betriebssystem-Typ. Ist das Zielsystem ein anderes, so wird die Kennzeichnung NS gesetzt.
• This measure is deprecated (DEP): Im Rahmen neuer Ergänzungslieferungen kommt es vor,
dass einige Maßnahmen ersatzlos entfallen. Maßnahmen-Nummern werden dabei prinzipiell nicht neu vergeben. Mit DEP gekennzeichnete Einträge sind also nur der Vollständigkeit halber vorhanden und können ansonsten ignoriert werden.
117
Unterstützte Maßnahmen
Die Übersicht bezieht sich auf die aktuelle Ergänzungslieferung. Die Maßnahmen-Kennungen verweisen auf die, auf den Webseiten des BSI angebotenen, Detailinformationen.
Folgende Test-Typen werden unterschieden:
• Remote: Für Prüfung ist lediglich eine Netzwerkverbindung zum Zielsystem notwendig.
• Credentials: Für Prüfung ist ein Zugangskonto auf dem Zielsystem notwendig.
BSI Referenz
M4.225
Titel
Bildschirmsperre
Test-Typ
Credentials
M4.326
Einsatz
von
VirenSchutzprogrammen
Geeigneter Umgang mit Laufwerken für Wechselmedien und
externen Datenspeichern
Protokollierung bei TK-Anlagen
Änderung
voreingestellter
Passwörter
Einsatz der Sicherheitsmechanismen von XWindow
Obligatorischer
Passwortschutz unter Unix
Gesichertes Login
Zugangsbeschränkungen für
Benutzer-Kennungen und /
oder Terminals
Sperren und Löschen nicht benötigter Accounts und Terminals
Credentials
M4.427
M4.528
M4.729
M4.930
M4.1431
M4.1532
M4.1633
M4.1734
Hinweis
Windows: Kann nur für Lokale
Konten getestet werden. Linux:
Nur voreingestellte Bildschirmschoner bei Gnome und KDE.
Credentials
Credentials
Remote
Test nur über SSH und Telnet.
Credentials
Credentials
Credentials
Credentials
Credentials
Fortsetzung auf der nächsten Seite
118
BSI Referenz
M4.1835
M4.1936
M4.2037
M4.2138
M4.2239
M4.2340
M4.3341
M4.3642
M4.3743
M4.4044
M4.4845
M4.4946
M4.5247
M4.5748
M4.8049
M4.9450
M4.9651
M4.9752
M4.9853
Tab. 9.1 – Fortsetzung der vorherigen Seite
Titel
Test-Typ
Hinweis
Administrative und technische Credentials
Absicherung des Zugangs zum
Monitor- und Single-UserModus
Restriktive
Attributvergabe Credentials
bei Unix-Systemdateien und
-verzeichnissen
Restriktive
Attributvergabe Credentials
bei Unix-Benutzerdateien und
-verzeichnissen
Verhinderung des unautorisier- Credentials
ten Erlangens von Administratorrechten
Verhinderung des Vertraulich- Credentials
keitsverlusts schutzbedürftiger
Daten im Unix-System
Sicherer Aufruf ausführbarer Credentials
Dateien
Einsatz
eines
Viren- Credentials
Suchprogramms bei Datenträgeraustausch und Datenübertragung
Sperren
bestimmter Credentials Cisco Geräte können nur über
Faxempfänger- Rufnummern
telnet getestet werden, da sie
SSH blowfish-cbc encryption
nicht unterstützen.
Sperren bestimmter Absender- Credentials Cisco Geräte können nur über
Faxnummern
telnet getestet werden, da sie
SSH blowfish-cbc encryption
nicht unterstützen.
Verhinderung der unautorisier- Credentials Nur für Linux Umgesetzt. Es ist
ten Nutzung des Rechnermikrounter Windows nicht möglich
fons
den Status des Microfons über
Registry/WMI auszulesen.
Passwortschutz
unter Credentials
Windows-Systemen
Absicherung
des
Boot- Credentials
Vorgangs für ein Windows
System
Geräteschutz
unter
NT- Credentials
basierten Windows-Systemen
Deaktivieren der automati- Credentials
schen CD-ROM Erkennung
Sichere Zugri smechanismen Remote
bei Fernadministration
Schutz der Webserver-Dateien
Remote
Abschaltung von DNS
Credentials
Ein Dienst pro Server
Remote
Kommunikation durch Paketfil- Credentials Getestet wird auf die Microter auf Minimum beschränken
soft Windows Firewall. Für Vista und neuer auf jegliche Firewall die sich systemkonform installiert.
119
BSI Referenz
M4.10654
M4.13555
M4.14756
M4.20057
M4.22758
M4.23859
M4.24460
M4.27761
M4.28462
M4.28563
M4.28764
M4.30065
M4.30566
M4.31067
M4.31368
M4.32569
M4.32670
M4.32871
M4.33172
M4.33273
M4.33374
120
Titel
Test-Typ
Hinweis
Aktivieren der Systemprotokol- Credentials
lierung
Restriktive Vergabe von Zu- Credentials
gri srechten auf Systemdateien
Sichere Nutzung von EFS unter Credentials
Windows
Umgang
mit
USB- Credentials
Speichermedien
Einsatz eines lokalen NTP- Credentials
Servers zur Zeitsynchronisation
Einsatz eines lokalen Paketfil- Credentials Getestet wird auf die Microters
soft Windows Firewall. Für Vista und neuer auf jegliche Firewall die sich systemkonform installiert.
Sichere
Systemkonfigura- Credentials
tion von Windows ClientBetriebssystemen
Absicherung der SMB-, LDAP- Credentials
und RPCKommunikation unter
Windows Servern
Umgang mit Diensten unter Credentials
Windows Server 2003
Deinstallation nicht benö- Credentials
tigter Client-Funktionen von
Windows Server 2003
Sichere Administration der Remote
VoIP-Middleware
Informationsschutz bei Dru- Remote
ckern, Kopierern und Multifunktionsgeräten
Einsatz von Speicherbeschrän- Credentials
kungen (Quotas)
Einrichtung des LDAP-Zugri s Remote
auf Verzeichnisdienste
Bereitstellung von sicheren Credentials
Domänen-Controllern
Löschen von Auslagerungsda- Credentials
teien
Sicherstellung
der
NTFS- Credentials
Eigenschaften
auf
einem
Samba-Dateiserver
Sichere Grundkonfiguration ei- Credentials
nes Samba-Servers
Sichere
Konfiguration
des Credentials
Betriebssystems für einen
Samba-Server
Sichere
Konfiguration
der Credentials
Zugri ssteuerung bei einem
Samba-Server
Sichere Konfiguration von Win- Credentials
bind unter Samba
BSI Referenz
M4.33475
M4.33876
M4.33977
M4.34078
M4.34179
M4.34280
M4.34481
M4.36882
M5.883
M5.1784
M5.1885
M5.1986
M5.1987
M5.2088
M5.2189
M5.3490
M5.5991
M5.6392
M5.6493
M5.6694
M5.7295
M5.9096
Titel
Test-Typ
Hinweis
SMB Message Signing und Sam- Credentials
ba
Einsatz von Windows Vista und Credentials Nur ein genereller Test, ob File
neuer File und Registry Virtualiund Registry Virtualization aktization
viert ist.
Verhindern
unautorisierter Credentials
Nutzung von Wechselmedien
unter Windows Vista und neuer
Einsatz
der
Windows- Credentials
Benutzerkontensteuerung
UAC ab Windows Vista
Integritätsschutz ab Windows Credentials Soweit technisch möglich umVista
gesetzt (aktiviertes UAC und
geschützter Modus in verschiedenen Zonen).
Aktivierung des Last Access Credentials
Zeitstempels ab Windows Vista
Überwachung von Windows Credentials
Vista-, Windows 7 und Windows Server 2008-Systemen
Regelmäßige
Audits
der Credentials
Terminalserver-Umgebung
Regelmäßiger Sicherheitscheck Remote
Es wird lediglich ein Meldung
des Netzes
ausgegeben, dass mit aktuelleten Plugins getestet werden
soll.
Einsatz der Sicherheitsmecha- Credentials
nismen von NFS
nismen von NIS
Einsatz der Sicherheitsmecha- Remote
nismen von sendmail
nismen von sendmail
nismen von rlogin, rsh und rcp
Sicherer Einsatz von telnet, ftp, Credentials
tftp und rexec
Einsatz von Einmalpasswör- Credentials
tern
Schutz vor DNS-Spoofing bei Credentials
Authentisierungsmechanismen
Einsatz von GnuPG oder PGP
Credentials
Secure Shell
Remote
Verwendung von TLS/SSL
Remote
Deaktivieren nicht benötigter Credentials Lediglich Anzeige der in Frage
Netzdienste
kommenden Dienste.
Einsatz von IPSec unter Win- Credentials
dows
121
BSI Referenz
M5.9197
M5.10998
M5.12399
M5.131100
M5.145101
M5.147102
122
Titel
Test-Typ
Hinweis
Einsatz von Personal Firewalls Credentials Getestet wird auf die Microfür Clients
soft Windows Firewall. Für Vista und neuer auf jegliche Firewall die sich systemkonform installiert. Auf Linux, soweit möglich, anzeige der iptables Regeln.
Einsatz eines E-Mail-Scanners Remote
auf dem Mailserver
Absicherung der Netzkommu- Credentials
nikation unter Windows
Absicherung von IP-Protokollen Credentials
unter Windows Server 2003
Sicherer Einsatz von CUPS
Credentials
Absicherung der Kommunikati- Remote
on mit Verzeichnisdiensten
25 http://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m04/m04002.html
123
9.2.2 PCI DSS
Dieser Abschnitt gibt eine Einführung in die Schwachstellen-Prüfung und Policy-Überwachung entsprechend dem Payment Card Industry Data Security Standard (PCI DSS) mit dem Greenbone Security
Manager.
124
Payment Card Industry Data Security Standard
Der PCI DSS ist ein Regelwerk im bargeldlosen Zahlungsverkehr, das sich auf die Abwicklung von Kartentransaktionen bezieht und von den internationalen Zahlungssystemen MasterCard, Visa, AMEX,
Discover und JCB unterstützt wird.
Handelsunternehmen und Dienstleister, die Kartentransaktionen speichern, verarbeiten oder übermitteln, werden verpflichtet, die Regelungen einzuhalten. Halten sie sich nicht daran, können Strafgebühren verhängt, Einschränkungen ausgesprochen oder ihnen letztlich die Akzeptanz von Kreditkarten untersagt werden.
Die Einhaltung der Regeln wird üblicherweise in Abhängigkeit vom Transaktionsvolumen des Unternehmens überprüft. Dabei werden Dienstleister in der Regel als Level 1 Service Provider klassifiziert
und müssen ihre Kartendaten verarbeitende Umgebung durch einen unabhängigen, vom PCI Security
Standards Council (PCI SSC) zugelassenen, Schwachstellen-Scan Anbieter (ASV) vierteljährlich über
externe Sicherheitsscans prüfen lassen. Zusätzlich müssen sie einmal im Jahr eine Begehung vor Ort
(PCI Security Audit) durch ein unabhängiges, ebenfalls vom PCI SSC zugelassenes, Unternehmen (QSA)
durchführen lassen.
Der “Approved Scanning Vendor” (ASV) ist ein Dienstleister der einen Schwachstellen-Scan der Kartendaten verarbeitenden Umgebung durchführt, welche aus dem Internet erreichbar ist. Schwachstellenscanner selber können daher nicht als ASV eingestuft oder zertifiziert werden, sondern stellen
Werkzeuge für den ASV dar, mit dem er die Schwachstellen-Scans in dem akkreditierten Arbeits- und
Sicherheitsprozess durchführt.
Greenbone Security Manager und PCI DSS
Laut PCI DSS (Version 3.1, Anforderung 11.2) müssen zwei Formen von Schwachstellen-Scans (Vulnerability Scans) im vierteljährigen Zyklus bzw. nach signifikanten Änderungen in der Kartendaten
verarbeitenden Umgebung durchgeführt werden. Zum einen der erläuterte Schwachstellen-Scan des
ASV und zum anderen ein interner Scan der Kartendaten-verarbeitenden Umgebung. Dieser Scan kann
auch durch eigene Mitarbeiter durchgeführt werden und erfordert keine Zulassung beim PCI SSC.
Mit dem Greenbone Security Manager können beide Schwachstellen-Scans durchgeführt werden. Die
Möglichkeit des False-Positive Managements vermeidet zudem den nicht unerheblichen Arbeitsaufwand für die händische Aussortierung von Fehlalarmen.
Ein Händler kann mit dem GSM seine Sicherheitsanforderungen vor dem ASV Schwachstellen-Scan
schon überprüfen um Zeit und kostenintensive Re-Scans zu vermeiden.
125
Darüber kann ein Händler mit dem GSM kontinuierlich seinen PCI Compliance Status auch zwischen
den ASV-Scans gegenprüfen.
Da der Security Change revisionssicher im GSM angelegt wird, kann der ordnungsgemäße Zustand
nicht nur während der Scans einmal pro Quartal, sondern kontinuierlich in einem beliebigen Zeitabstand nachgewiesen werden.
Mit den Eskalationsmethoden können externe Anbieter wie auch interne Experten laufend über den
Sicherheitstatus informiert, sowie Zusammenfassungen an die verantwortlichen Personen weitergeleitet werden.
Policy Monitoring
Genau wie ein GSM die technischen Aspekte der IT-Grundschutzkataloge in regelmäßigen Abständen
prüfen kann, so kann auch eine PCI DSS Policy in regelmäßigen Abständen auf technische Systemparameter geprüft werden.
Über einen permanenten Policy-Scan im Hintergrund wird sichergestellt, dass Viren-Scanner nicht
unbemerkt veralten oder Firewalls unbemerkt deaktiviert werden. Solche Parameter lassen sich über
die Zeit beobachten und genauso wie Software-Schwachstellen eskalieren.
Vorteile für den Händler:
• Permanente Policy Überwachung
• Flexible Eskalation
• “False Positive” Management
• Internes und externes Schwachstellen-Scanning
• Vollständige Vulnerability Analysis nach PCI DSS für Interne Scans
Vorteile für den ASV
• “False Positive” Management
• Statische Scan-Konfiguration für Re-Scans
• Vollständige Vulnerability Analysis nach PCI DSS für Externe Scans über das Internet
• Flexibles Reporting Framework für eigene Scan-Reports
Auch wenn die Greenbone Networks GmbH als Produzent von dem GSM nicht als ASV auftritt, hat
sie Partner, welche sowohl den Greenbone Security Manager vertreiben als auch Dienste als ASV und
Sicherheitsberater bei End-Kunden ausführen.
9.3 Spezielle Richtlinien
9.3.1 Onlineprüfung Mailserver
Das Bayerische Landesamt für Datenschutzaufsicht hat im September 2014 eine Online-Prüfung
“Mailserver hinsichtlich STARTTLS, Perfect Forward Secrecy und Heartbleed103 ” durchgeführt und diejenigen Unternehmen zu einer Beseitigung der Sicherheitsprobleme aufgefordert bei denen entsprechende Probleme durch die Prüfung entdeckt wurden.
Mit dem Greenbone Security Manager bzw. OpenVAS kann ein Unternehmen auch selbst prüfen ob die
eigenen Mailserver den Sicherheitskriterien entsprechen. Gehen Sie dafür wie folgt vor.
1. Importieren Sie folgende Scan Config: onlinepruefung-mailserver-scanconfig.xml104 .
2. Konfigurieren Sie eine neue Port List mit der Port Range T:25.
103
104
http://www.lda.bayern.de/onlinepruefung/emailserver.html
http://www.greenbone.net/download/scanconfigs/onlinepruefung-mailserver-scanconfig.xml
126
3. Konfigurieren Sie ein Target mit den Mailservern, die sie prüfen wollen und wählen Sie dort als
Port List die eben erstellte. Je nach Netzwerkeinstellungen bei Ihnen kann es Sinn machen “Consider Alive” als Alive Test einzusetzen.
4. Erstellen Sie einen Task mit obigem Target sowie der importieren Scan Config.
5. Starten Sie den Scan. Es dauert ca. 30-40 Minuten, da der Scanner in der Regel auf einige Daten
der Mailserver länger warten muss.
6. Sie erhalten schliesslich einen Scan Report mit verschiedenen Log-Einträgen pro Mailserver.
Das Fehlen von StartTLS wird zunächst auch nur als Log-Meldung erscheinen, da es eine PolicyFrage ist, wie dies bewertet werden soll. So können Sie beispielsweise ein Override für dieses NVT anlegen und einen hohen Schweregrad definieren, sowie dieses Override dann auf alle
Hosts, möglicherweise auch alle Tasks ausweiten.
7. Soll ein Monitoring etabliert werden, so kann nun für diesen Task ein Schedule (z.B. jede Woche Sonntags) und ein Alert (z.B. eine Email) eingerichtet werden. In Verbindung mit passenden
Overrides entsteht damit ein automatisiertes Warnsystem im Hintergrund.
9.4 TLS-Karte
Das TLS-Protokoll (Transport Layer Security) dient der Sicherstellung von Vertraulichkeit, Authentizität und Integrität bei der Kommunikation in unsicheren Netzen. Es stellt die vertrauliche Kommunikation zwischen Sender und Empfänger, etwa zwischen Webbrowser und Webserver, her. In den
vergangenen Jahren sind mehrere Sicherheitslücken in dem zurzeit häufig genutzten Protokoll TLS
1.0 bekannt geworden, die von Angreifern zum Abgreifen von Informationen in der Kommunikation
genutzt werden können.
Über den GSM können Sie in einem Netzwerk Systeme identifizieren, die Dienste über das SSL-/TLSProtokoll anbieten. Zusätzlich liefert der GSM Informationen über die verwendeten Protokollversionen und angebotenen Verschlüsselungsalgorithmen und kann auf Wunsch weitere Daten über den
Dienst ausgeben, sofern sich dieser eindeutig identifizieren lässt.
9.4.1 Vorbereitung
Für den einfachen Export Ihrer Scan-Ergebnisse stellen wir Ihnen ein speziell angepasstes Report
Format Plugin zur Verfügung. So können Sie die Ergebnisse in einem Format herunterladen, das Sie
leicht weiterverarbeiten können.
Bitte laden Sie hierzu das TLS-Map Report Format Plugin106 herunter und importieren Sie es.
Bitte beachten Sie, dass Sie das Plugin nach dem Import aktivieren müssen, damit es Ihnen später zur
Verfügung steht. Klicken Sie hierzu auf die Schaltfläche mit dem Schraubenschlüssel-Symbol (“Edit
Report Format”) und wählen Sie im folgenden Dialog in der Zeile “Active” die Option “yes”. Klicken Sie
anschließend auf “Save Report Format”, um das Plugin zu aktivieren.
9.4.2 Prüfung TLS-Nutzung
Für einen Überblick über die TLS-Nutzung in einem Netzwerk oder auf einzelnen Systemen empfehlen
wir die Verwendung einer der folgenden Scan-Konfiguration (“Scan Configs”):
• TLS-Map Scan Config107
Diese Scan-Konfiguration identifiziert die verwendeten Protokollversionen und die angebotenen
Verschlüsselungsalgorithmen, versucht aber nicht, den Dienst genauer zu identifizieren.
• TLS-Map with service detection108
106
http://www.greenbone.net/download/rfps/tls-map-1.0.0.xml
http://www.greenbone.net/download/scanconfigs/tls-map-scan-config.xml
108 http://www.greenbone.net/download/scanconfigs/tls-map-app-detection-scan-config.xml
107
9.4. TLS-Karte
127
Diese Scan-Konfiguration identifiziert die verwendeten Protokollversionen und die angebotenen Verschlüsselungsalgorithmen und versucht zusätzlich den Dienst genauer zu identifizieren. Diese Identifikation benötigt mehr Zeit und verursacht mehr Netzwerkverkehr als bei der
Scan-Konfiguration ohne Dienst-Identifikation.
Importieren Sie je nach Bedarf eine oder beide der oben beschriebenen Scan-Konfigurationen.
Wählen Sie nun eine für Ihre Anforderungen passende Liste der zu scannenden Ports (“Port List”).
Achten Sie darauf, dass Sie die Port-Liste so auswählen, dass alle für Sie relevanten Ports abgedeckt
werden. Eine umfangreichere Port-Liste erhöht den für den Scan benötigten Zeitraum, findet aber
unter Umständen auch Dienste, die auf ungewöhnlichen Ports hören.
In dem Menü “Port Lists” können Sie die vorkonfigurierten Port-Listen einsehen und bei Bedarf eine
neue Liste erstellen.
Bedenken Sie bei der Wahl der Port-Liste ebenfalls, dass das TLS-Protokoll ausschließlich auf dem
TCP-Protokoll aufbaut. Eine Port-Liste mit UDP-Ports verlangsamt den Scan also nur unnötig. Für
einen vollständigen Scan aller TCP-Ports bietet sich die Port-Liste “All TCP” an.
Erstellen Sie nun einen “Target”, der als Ziele die Systeme und/oder Netzwerke enthält, die Sie überprüfen möchten. Achten Sie darauf, die von Ihnen gewählte Port-Liste mit den Zielen zu verknüpfen,
indem Sie diese in der Maske “New Target” in der Zeile “Port List” auswählen.
Erstellen Sie einen neuen Task und verwenden Sie die gewünschte Scan-Konfiguration in Zusammenhang mit den zu überprüfenden Zielen. Starten Sie den neu erstellten Task.
9.4.3 Export der Scan-Ergebnisse
Sobald der von Ihnen gestartete Task in den Status “Done” wechselt, ist der Scan vollständig und die
Ergebnisse können exportiert werden.
Für den Export der Ergebnisse ö nen Sie bitte den Report für den von Ihnen durchgeführten Task,
beispielsweise durch einen Klick auf das Datum in der Spalte “Last” in der Task-Übersicht.
Wechseln Sie auf die Seite “Report: Summary and Download” in der Report-Ansicht und wählen Sie
dann das Report Format Plugin “TLS Map” für “Full report” als Download.
Der Report wird nun im CSV-Format bereitgestellt. Die Datei können Sie beispielsweise in gängigen
Anwendungen zur Tabellenkalkulation importieren und weiter verarbeiten.
Die Datei enthält jeweils eine Zeile pro Port und System, auf dem ein Dienst unter Verwendung eines
SSL-/TLS-Protokolls angeboten wird:
IP,Host,Port,TLS-Version,Ciphers,Application-CPE
192.168.12.34,www.local,443,TLSv1.0;SSLv3,SSL3_RSA_RC4_128_SHA;TLS1_RSA_RC4_128_SHA,
cpe:/a:apache:http_server:2.2.22;cpe:/a:php:php:5.4.4
192.168.56.78,www2.local,443,TLSv1.0;SSLv3,SSL3_RSA_RC4_128_SHA;TLS1_RSA_RC4_128_SHA,
cpe:/a:apache:http_server:2.2.22
Separiert durch Kommas enthält jede Zeile die folgenden Informationen:
• IP: Die IP-Adresse des Systems, auf dem der Dienst gefunden wurde.
• Host: Der DNS-Name des Systems, falls verfügbar.
• Port: Der Port, auf dem der Dienst gefunden wurde.
• TLS-Version: Die vom Dienst angebotenen Protokollversionen. Wurde mehr als eine Protokollversion angeboten, werden die Versionen durch Semikolons getrennt angegeben.
• Ciphers: Die vom Dienst angebotenen Verschlüsselungsalgorithmen. Wurde mehr als ein Verschlüsselungsalgorithmus unterstützt, werden die Algorithmen durch Semikolons getrennt angegeben.
• Application-CPE: Die vermutlich verwendete Anwendung im CPE-Format. Wurde mehr als eine
Anwendung identifiziert, werden die Anwendungen durch Semikolons getrennt angegeben.
128
9.5 Conficker-Suche
Conficker109 ist ein im Herbst 2008 aufgetauchter Wurm der Windows Betriebssysteme gefährdet und
zu zahlreichen Ausfällen sowie umfangreichen finanziellen Schaden geführt hat. Er nutzt eine Sicherheitslücke des Betriebssystems aus und aktualisiert sich selbst.
Das Microsoft Bulletin MS08-067110 beschreibt die wichtigste Sicherheitslücke, die Conficker ausnutzt, um das betre ende System zu befallen.
9.5.1 Suchmethoden für Schwachstellen und Befall
Mit dem Greenbone Security Manager empfehlen sich zwei unterschiedliche Methoden zur Suche:
• Suche nach Systemen, die mit der Conficker infiziert sind, kombiniert mit einer nicht-invasiven
Suche der von Microsoft im Bulletin MS08-067 beschriebenen Sicherheitslücke.
• Invasive Suche nach der von Microsoft im Bulletin MS08-067 beschriebenen Sicherheitslücke,
ebenfalls inklusive der Conficker-Suche.
Die erste Methode kann nicht in allen Fällen das Vorhandensein der Schwachstelle aufdecken. Die
zweite Methode geht für das Aufdecken soweit, dass versucht wird, die Schwachstelle selbst auszunutzen, um Gewissheit zu bekommen, ob sie vorliegt. Dabei kann es allerdings zum Ausfall des betre enden Systems kommen und sollte nur mit entsprechender Umsicht ausgeführt werden.
9.5.2 Suche nach Schwachstelle und Conficker ausführen
• Importieren Sie die Scan Configuration Conficker Search111 oder für die invasive Suche die Scan
Configuration Invasive Conficker Search112 .
• Falls die Zielsysteme keine anonyme Anmeldung erlaubt, erstellen Sie Credentials um der ScanEngine Zugang zu den Zielsystemen zu geben. Falls noch nicht geschehen, erstellen Sie dafür einen entsprechenden Anwender auf Ihren Windows-Systemen (ein niedrig privilegiertes
Benutzer-Konto reicht aus).
• Nun werden die Zielsysteme (Targets) festgelegt und ggf. mit den entsprechenden Credentials
verknüpft.
109
http://en.wikipedia.org/wiki/Conficker
http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx
111 http://www.greenbone.net/download/scanconfigs/conficker-search-scanconfig-v4.xml
112 http://www.greenbone.net/download/scanconfigs/conficker-search-scanconfig-invasive-v4.xml
110
9.5. Conficker-Suche
129
• Nun können Sie die Aufgabe (Task) erstellen. Dafür kombinieren Sie die oben importierte Scan
Konfiguration mit den entsprechend erstellten Zielsystemen.
• Die Prüfung wird gestartet, in dem Sie für den eben erstellten Task auf klicken. Es kann einige
Sie auf klicken.
• Sobald der Status auf “Done” wechselt, ist der vollständige Bericht verfügbar. Sie können aber
auch schon während des Scans die bereits gefundenen Ergebnisse einsehen. Hier ein Beispiel
für ein System, bei dem das Hersteller-Update für MS08-67 nicht eingespielt wurde.
9.6 OVAL System Characteristics
OVAL steht für Open Vulnerability and Assessment Language (OVAL)113 . Es ist ein Ansatz für die standardisierte Beschreibung des (Sicherheits-)Status eines IT-Systems. OVAL-Dateien beschreiben ein
Sicherheitsproblem und definieren Tests, um den verletzbaren Zustand eines Systems zu identifizieren. Sie wissen, in welchem Zustand das Problem behoben ist. Oft bezieht sich das auf die Versionsnummern bestimmter Softwareprodukte.
Um gemäß einer OVAL-Beschreibung zu prüfen, benötigen Sie also Informationen über den Systemzustand. Dieser wird in einer, ebenfalls als XML standardisierten, Form erhoben, der System Characteristics (SC).
Es gibt verschiedene Lösungen, die auf Basis von OVAL-Dateien und SC-Dateien Prüfungen durchführen. OVAL-Dateien werden von verschiedenen Herstellern zur Verfügung gestellt114 . MITRE pflegt das
OVAL Repository115 mit über 13.000 Einträgen.
113
http://oval.mitre.org/
http://oval.mitre.org/repository/about/other_repositories.html
115 http://oval.mitre.org/repository/
114
130
9.6.1 OVAL Adoption Program
Greenbone ist ozieller OVAL Adopter und der Greenbone Security Manager ist registriert als “Systems Characteristics Producer”.
Siehe dazu: OVAL Adoption Program116 .
Unterstützt werden die OVAL Versionen 5.3 bis 5.10. Sollten bei der Verwendung fehlerhafte, fehlende
oder unvollständige OVAL-Elemente gefunden werden, so bitten wir um Rückmeldung über unseren
Support. Die OVAL-SC Realisierung bei Greenbone erlaubt es, innerhalb eines Tages Updates für OVALSC zu aktivieren und damit zeitnah jegliche Verbesserungen für den Anwender bereitzustellen.
116
http://oval.mitre.org/adoption/
9.6. OVAL System Characteristics
131
9.6.2 Scan-Daten als OVAL-SCs einsammeln
Während eines Scans sichtet der Greenbone Security Manager zahlreiche Informationen
über die angegebenen Zielsysteme. Diese Informationen werden in einem eigenen, optimierten Daten-Pool verwaltet. Teile davon eignen sich aber auch direkt als Bestandteil von
OVAL System Chracteristics.
Die Erstellung von OVAL-SC Dateien ist nicht voreingestellt sondern muss in der Scan Configuration
eingeschaltet werden. Die folgende Scan Configuration konzentriert sich genau auf diese Aufgabe:
collect-oval-sc-v2.xml117 .
Importieren Sie diese in den GSM:
Die neue Scan Configuration wird anschließend in der Liste angezeigt:
Die umfassendsten Ergebnisse zu den Zielsystemen werden über authentifizierte Scans ermittelt. Dafür muss zunächst ein Zugangskonto für das Zielsystem eingerichtet werden. Sorgen Sie dafür, dass
das Konto auf dem Zielsystem entsprechend eingerichtet ist. Für unixoide Systeme reicht in der Regel
ein niedrig privilegierter Zugang, bei Windows-Systemen sind zumeist Administrator-Rechte notwendig.
Das folgende Beispiel zeigt die Einrichtung eines Ziels mit Linux. Für ein Windows-System muss das
Credential bei SMB anstatt bei SSH gesetzt werden.
Nun wird der Task eingerichtet. Starten Sie ihn unmittelbar danach.
Der Scan-Vorgang ist schnell, da mit der speziellen Scan Configuration zielgerichtet nur die notwendigen Informationen eingesammelt werden.
Die Ergebnisse werden als Log-Information abgelegt. Stellen Sie den Filter entsprechend ein, sehen
Sie die OVAL System Characteristics in für Lesbarkeit formatiertem XML:
Bitte beachten: Haben Sie die Daten von vielen Zielsystemen gesammelt, so kann das den technischen
Rahmen für die Ansicht sprengen.
9.6.3 OVAL-SC exportieren
OVAL-SC’s sind so definiert, dass sich eine Beschreibungs-Datei auch nur genau auf ein
System bezieht. Mit Greenbone können aber beliebig viele System Characteristics zu verschiedenen Systemen in einem einzelnen Schritt gesammelt werden.
117
http://www.greenbone.net/download/scanconfigs/collect-oval-sc-v2.xml
132
Wir stellen daher zwei Report Format Plugins zur Verfügung:
• OVAL System Characteristics: Für eine einzelne System Characteristics-Datei, die dann als XML
geliefert wird.
• OVAL System Characteristics Archive: Für eine beliebige Anzahl von Systeme Characteristics Dateien die in einer Zip-Datei zusammengefasst sind. Jede einzelne SC-Datei wird nach der IPAdresse des jeweiligen Systems benannt.
Beide Plugins stehen auf der Report Formats-Seite118 zum Download bereit.
Importieren Sie diese Report Format Plugins, prüfen Sie die Signaturen und aktivieren Sie die Plugins
schließlich. Wie das im Detail geht, können Sie hier nachlesen: Report Plugins (Seite 92).
Nun können Sie die Ergebnisse in geeigneter Form für die weitere Verwendung direkt herunterladen.
Wählen Sie dafür das Report Format “OVAL-SC” oder “OVAL-SC Archive” bei “Full report” aus:
Die Zip-Archive sehen wir folgt aus:
9.6.4 Beispiel: OVAL-SC für ovaldi verwenden
Die Organisation MITRE stellt nicht nur OVAL zur Verfügung sondern auch eine Referenzimplementierung für die lokale Ausführung von OVAL-Tests. Der OVAL Interpreter ovaldi119
ist unter einer Open Source Lizenz verfügbar.
Greenbone macht es über die Bereitstellung von OVAL System Characteristics möglich, dass ein
ovaldi-Aufruf beispielsweise auf einem Linux-System läuft, aber ein Windows-System prüft. Umgekehrt ist das natürlich genauso möglich.
War das im obigen Beispiel gescannte Zielsystem ein Debian Linux System, können Sie nun die oziellen Debian OVAL definitions 2010120 herunterladen und den Test ausführen (“false” bedeutet, dass
ein Test keinen Befund hatte).
Ovaldi erstellt automatisch zur folgenden Ausgabe auch eine HTML- und eine XML-Version: ovalsc-debian-squeeze-sample-ovaldi-results.html121 (102 KByte) und oval-sc-debian-squeeze-sample118
http://www.greenbone.net/technology/report_formats.de.html
http://oval.mitre.org/language/interpreter.html
120 http://www.debian.org/security/oval/oval-definitions-2010.xml
121 http://www.greenbone.net/download/misc/oval-sc-debian-squeeze-sample-ovaldi-results.html
119
133
ovaldi-results.xml122 (4,2 MByte). Um den Test auszuführen laden Sie zusätzlich noch die Dateien
oval-definitions-2010.xml123 und oval-sc-debian-squeeze-sample.xml124 herunter.
$ cd /tmp
$ ovaldi -m -o /tmp/oval-definitions-2010.xml \
-i /tmp/oval-sc-debian-squeeze-sample.xml \
-a /usr/share/ovaldi/xml/
---------------------------------------------------OVAL Definition Interpreter
122
http://www.greenbone.net/download/misc/oval-sc-debian-squeeze-sample-ovaldi-results.xml
http://www.debian.org/security/oval/oval-definitions-2010.xml
124 http://www.greenbone.net/download/misc/oval-sc-debian-squeeze-sample.xml
123
134
Version: 5.10.1 Build: 2
Build date: Sep 11 2012 07:49:59
Copyright (c) 2002-2012 - The MITRE Corporation
---------------------------------------------------Start Time: Tue Sep 11 12:12:52 2012
** parsing /tmp/oval-definitions-2010.xml file.
- validating xml schema.
** checking schema version
- Schema version - 5.3
** skipping Schematron validation
** parsing /tmp/oval-sc-debian-lenny-sample.xml for analysis.
** running the OVAL Definition analysis.
Analyzing definition: FINISHED
** applying directives to OVAL results.
** OVAL definition results.
OVAL Id
Result
135
------------------------------------------------------oval:org.debian:def:1965
false
oval:org.debian:def:1966
false
false
false
false
false
false
false
false
false
...
false
false
false
false
false
false
false
false
false
false
-------------------------------------------------------
** finished evaluating OVAL definitions.
** saving OVAL results to results.xml.
** running OVAL Results xsl: /usr/share/ovaldi/xml//results_to_html.xsl.
----------------------------------------------------
War das im obigen Beispiel gescannte Zielsystem ein Microsoft Windows System, können Sie nun die
von MITRE zur Verfügung gestellten Definitionen125 herunterladen und den Test ausführen (“false”
bedeutet, dass ein Test keinen Befund hatte).
Ovaldi erstellt automatisch zur folgenden Ausgabe auch eine HTML- und eine XML-Version: ovalsc-windows-xp-sample-ovaldi-results.html126 (23 KByte) und oval-sc-windows-xp-sample-ovaldiresults.xml127 (159 KByte).
Um die Tests laufen zu lassen laden Sie zusätzlich die Dateien windows.xml128 und oval-sc-windowsxp-sample.xml129 herunter.
$ cd /tmp
$ ovaldi -m -o /tmp/windows.xml \
-i /tmp/oval-sc-windows-xp-sample.xml \
-a /usr/share/ovaldi/xml/
---------------------------------------------------OVAL Definition Interpreter
Version: 5.10.1 Build: 2
Build date: Sep 11 2012 07:49:59
Copyright (c) 2002-2012 - The MITRE Corporation
---------------------------------------------------Start Time: Tue Sep 11 15:57:55 2012
** parsing /tmp/windows.xml file.
125
http://oval.mitre.org/rep-data/5.10/org.mitre.oval/p/family/windows.xml
http://www.greenbone.net/download/misc/oval-sc-windows-xp-sample-ovaldi-results.html
127 http://www.greenbone.net/download/misc/oval-sc-windows-xp-sample-ovaldi-results.xml
128 http://oval.mitre.org/rep-data/5.10/org.mitre.oval/p/family/windows.xml
129 http://www.greenbone.net/download/misc/oval-sc-windows-xp-sample.xml
126
136
** checking schema version
- Schema version - 5.10
** skipping Schematron validation
** parsing /tmp/oval-sc-windows-xp-sample.xml for analysis.
** running the OVAL Definition analysis.
Analyzing definition: FINISHED
** applying directives to OVAL results.
** OVAL definition results.
OVAL Id
Result
------------------------------------------------------oval:org.mitre.oval:def:754
true
oval:org.mitre.oval:def:15339
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
-------------------------------------------------------
** finished evaluating OVAL definitions.
** saving OVAL results to results.xml.
** running OVAL Results xsl: /usr/share/ovaldi/xml/results_to_html.xsl.
----------------------------------------------------
137
138
KAPITEL 10
Benachrichtigungen
Mit Hilfe der Benachrichtigungen können Sie die Zustände und Ergebnisse eines Scans automatisch
an weitere Systeme übermitteln lassen. Die Benachrichtigungen verankern sich so in dem System,
dass bei jedem konfigurieren Ereignis, z.B. dem Start oder dem Ende einer Aufgabe, eine bestimmte
Aktion ausgelöst wird. Dies kann zusätzlich noch an eine Bedingung geknüpft werden. Dabei kann es
sich zum Beispiel um das Aunden einer Schwachstelle mit der Bedrohungsstufe größer 9 handeln.
Ist dies erfüllt, kann eine E-Mail oder auch ein SNMP-Trap ausgelöst werden.
Um eine neuen Benachrichtigung zu erzeugen, wechseln Sie auf Konfiguration/Benachrichtigungen.
Fügen Sie nun eine neue Benachrichtigung hinzu.
Abb. 10.1: Benachrichtigungen bietet vielfältige Optionen.
Nun können Sie die folgenden Parameter definieren:
Name: Dies ist ein frei wählbarer Name, der die Benachrichtigung beschreibt.
Kommentar: Der optionale Kommentar kann weitere Informationen enthalten.
Event: Hier definieren Sie das Ereignis, zu dem eine Benachrichtigung versandt wird. Dies kann zum
Beispiel bei einer Statusänderung eines Aufgabe erfolgen.
139
Condition: Hier können Sie eine zusätzliche Bedingung definieren, die für den Versand erfüllt sein
muss. Die Benachrichtigung kann erfolgen:
• Immer,
• Nur wenn mindestens eine bestimmte Bedrohungstufe erreicht wird oder
• wenn die Bedrohungsstufe sich ändert, größer oder kleiner wird.
Abb. 10.2: Alerts müssen bei dem entsprechenden Task aktiviert werden.
Method: Hier wählen Sie die Methode für die Benachrichtigung aus. Nur eine Methode kann je Alert
verwendet werden. Wenn Sie unterschiedliche Benachrichtigungen für dasselbe Ereignis auslösen möchten, müssen Sie mehrere Alerts erzeugen und diese mit dem gleichen Task verknüpfen.
E-Mail Dies ist die mächtigste und am häufigsten eingesetzte Methode. Um diese Methode zu verwenden, müssen Sie zuvor den zu verwendenden Mailserver auf der GSMKommandozeile definiert haben (siehe Abschnitt Mail-Server (Seite 27)). Dann können Sie
hier zwischen den folgenden Optionen wählen:
To Address: Dies ist die E-Mail-Adresse, an die die E-Mail gesandt wird.
From Address: Dies ist die Absenderadresse der generierten E-Mail.
Subject: Dies ist die Betre -Zeile der E-Mail. Sie können hier Variablen verwenden: $n ist
der Name der Aufgabe und $e die Beschreibung des Ereignisses.
Content: Hier können Sie den Inhalt der E-Mail bestimmen:
Simple Notice: Dies ist lediglich eine einfache Beschreibung des Ereignisses.
Include Report: Falls Sie die E-Mail bei der Beendigung der Aufgabe (Default: Abgeschlossen) versenden, kann der Bericht ebenfalls mit der E-Mail versendet werden. Dabei kann jedoch nur ein Berichtsformat verwendet werden, welches den
Content-Type text/* verwendet, da E-Mails nicht direkt binäre Inhalte enthalten
dürfen. Des Weiteren können Sie hier den Inhalt der E-Mail anpassen. Dabei stehen
Ihnen wieder mehrere Variablen zur Verfügung:
• $c Bedingung
• $e Ereignis
• $F Der Name des verwendeten Filters
• $f Der tatsächliche Filter
• $H Zusammenfassung des Rechners
• $i Der Inhalt des Berichts
• $n Der Name der Aufgabe
• $r Der Name des Berichtsformates
• $t Ein Hinweis, falls der Bericht gekürzt wurde.
• $z Die Zeitzone
140
Kapitel 10. Benachrichtigungen
Attach Report: Falls Sie die E-Mail bei der Beendigung der Aufgabe (Default: Abgeschlossen) versenden, kann der Bericht ebenfalls mit der E-Mail versendet werden. Dabei kann hier ein beliebiges Berichtsformat einschließlich PDF verwendet
werden. Der Bericht wird mit dem korrekten Mime-Type an die E-Mail angehängt.
Des Weiteren können Sie hier den Inhalt der E-Mail anpassen. Dabei stehen Ihnen
dieselben Variablen zur Verfügung.
System Logger Diese Methode erlaubt die Übermittlung des Ereignisses automatisch an einen
Syslog-Daemon oder via einer SNMP-Trap. Der Syslog-Server und auch der SNMP-Trap
Dienst werden hierzu auf der Kommandozeile definiert (siehe Abschnitt Zentraler Protokollserver (Seite 28) und SNMP (Seite 28)).
HTTP Get Mithilfe der HTTP GET Methode kann zum Beispiel eine SMS Textnachricht versendet
oder eine Anbindung an ein Trouble-Ticket-System realisiert werden. Die folgenden Variablen können bei der Angabe der URL verwendet werden:
• $n: Name des Tasks
• $e: Beschreibung des Ereignisses (Start, Stop, Done)
• $c: Beschreibung der Bedingung, die eingetreten ist.
• $$: Das Zeichen $
Abb. 10.3: Bei den Alerts kann die Verwendung in den verschiedenen Tasks nachvollzogen werden.
Sourcefire Connector Hiermit können Sie automatisch die Daten an ein Sourcefire Defense
Center übertragen. Weitere Informationen finden Sie in Sourcefire Defence Center (Seite 226).:ref:sourcefire.
verinice.PRO Connector Mit dieser Option senden Sie die Daten automatisch an eine verinice.PRO Installation. Für weitere Informationen lesen Sie bitte den Abschnitt Verinice (Seite 216).
Report Result Filter Schließlich können Sie die Ergebnisse auch noch durch einen zusätzlichen Filter
einschränken. Hierzu müssen Sie den Filter vorher erzeugt und gespeichert haben (siehe Kapitel
Powerfilter (Seite 145)).
Damit dieser Alert anschließend genutzt wird, muss er bei den entsprechenden Task-Definitionen hinterlegt (siehe Abbildung Alerts müssen bei dem entsprechenden Task aktiviert werden. (Seite 140))
werden. Hierzu editieren Sie den entsprechenden Task. Diese Änderung des Tasks ist auch für bereits
definierte und verwendete Tasks erlaubt, da diese keine Auswirkung auf die bereits erzeugten Berichte hat.
Anschließend wird bei den entsprechenden Alerts auch ihre Verwendung (siehe Abbildung Bei den
Alerts kann die Verwendung in den verschiedenen Tasks nachvollzogen werden. (Seite 141)) angezeigt.
141
142
Kapitel 10. Benachrichtigungen
KAPITEL 11
GUI-Konzepte
Dieses Kapitel beschreibt immer wiederkehrende Konzepte in der Benutzung der Weboberfläche des
Greenbone Security Managers. Hierzu gehören einheitliche Icons, die Powerfilter, Tags und die Grafiken im Secinfo Dashboard.
11.1 Icons
Die Weboberfläche verwendet immer wiederkehrende Icons für die Auslösung identischer Aktionen.
Der Bezug dieser Icons ergibt sich dann jeweils aus dem Kontext der aktuellen Ansicht.
•
Hiermit zeigen Sie eine kontextsensitive Hilfe an.
•
Hiermit zeigen Sie eine Liste der aktuellen Objekte an.
•
Hiermit erzeugen Sie ein neues Objekt. Dies kann ein Benutzer, ein Ziel, eine Aufgabe, eine
Berechtigung oder ein Filter sein.
•
Hiermit wird ein Objekt in den Mülleimer verschoben.
•
Hiermit können Sie ein Objekt editieren.
•
Hiermit kopieren Sie ein Objekt.
•
•
•
Hiermit exportieren Sie ein Objekt in Form einer Datei. Diese Datei können Sie in einem anderen
GSM importieren.
Hiermit aktualisieren Sie die Seite.
Hiermit klappen Sie zusätzliche Informationen, z.B. den Powerfilter, in der Darstellung aus
und ein.
•
Hiermit löschen Sie ein Objekt unwiderruflich.
•
Hiermit springen Sie zum nächsten Objekt (Seite) in einer Darstellung.
•
Hiermit springen Sie zum letzten Objekt (Seite) in einer Darstellung.
•
Dieses Icon weist darauf hin, dass weitere Benutzer auf das Objekt zugreifen dürfen.
Einzelne Icons können nur in einem bestimmten Kontext aufgerufen werden. Dies tri t auf die folgenden Icons zu:
•
•
Hiermit starten Sie einen aktuell nicht laufenden Task.
•
•
Dieses Icon erlaubt das An- und Abschalten der Overrides.
•
Dieses Icon zeigt Ihnen, ob eine Lösung für die Schwachstelle bekannt ist.
143
•
Dieses Icon zeigt einen Herstellerpatch an.
•
Dieses Icon zeigt einen Workaround an.
•
zeigt das Fehlen einer Lösung an.
•
Dieses Icon zeigt an, dass eine Scan-Konfiguration automatisch um weitere NVTs ergänzt
wird.
•
Dieses Icon zeigt an, dass eine Scan-Konfiguration neue NVTs nicht automatisch aktiviert.
11.2 Charts
Die Charts in dem SecInfo Dashboard können angepasst werden. Somit können die SecInfo-Daten
auf unterschiedlichste Weise grafisch analysiert und aufbereitet werden. Dabei können die erzeugten
Grafiken heruntergeladen und in weiteren Dokumenten eingebunden werden.
Es stehen vier verschiedene Chart-Typen zu Auswahl:
• Liniendiagramm (Line)
• Balkendiagramm (Bar)
• Donutdiagramm (Donut)
• Blasendiagramm (Bubble)
144
Kapitel 11. GUI-Konzepte
Die Inhalte der Charts können über das Drop-Down-Menü am unteren Rand jedes Charts ausgewählt
werden. Hierdurch ändert sich im Moment auch automatisch der Chart-Typ. Ein Download des Bildes
oder eine Kopie kann durch das Kontextmenü in der linken oberen Ecke des Charts ausgewählt werden.
Abb. 11.1: Das Chart-Kontextmenü erlaubt den Download eines Charts.
11.3 Powerfilter
Fast jede Ansicht in der Weboberfläche bietet die Möglichkeit zur Filterung der angezeigten Informationen. Die hierzu notwendigen Eingaben können in der Filterleiste an dem oberen Rand der Weboberfläche durchgeführt werden.
Abb. 11.2: Der Powerfilter bietet überall die Filterung der angezeigten Ergebnisse.
Diese Filterleiste kann durch aufgeklappt werden. Dann werden kontextsensitiv mehrere Parameter angezeigt, die zu dem Powerfilter zusammengebaut werden. Diese können von Ihnen aber auch
direkt in der Filterleiste editiert werden.
Der Powerfilter ist wieder Kontext-abhängig. Werden NVTs oder Ziele gefiltert, so zeigt der Powerfilter
mehr oder weniger Optionen nach dem Ausklappen an.
Bemerkung:
Der Powerfilter unterscheidet grundsätzlich keine Groß- und Kleinschreibung.
Ein typischer Powerfilter kann nach allen CVE-2009-2906 Schwachstellen innerhalb des Netzes
192.168.155.0/24 suchen.
11.3.1 Komponenten
Die in dem Powerfilter möglichen Komponenten hängen von seinem Kontext ab. Grundsätzlich ist die
Angabe der folgenden Parameter immer möglich:
11.3. Powerfilter
145
Abb. 11.3: Der Powerfilter kann aufgeklappt werden.
Abb. 11.4: Die Möglichkeiten des Powerfilter sind kontextsensitiv.
rows: Hiermit geben Sie die Anzahl der anzuzeigenden Ergebnisse an. Meist ist dieser Wert rows=10.
Mit der Angabe -1 werden alle Ergebnisse angezeigt. Mit der Angabe -2 wird der von Ihnen unter
My Settings eingestellte Wert Rows Per Page verwendet.
first: Hiermit geben Sie an, ab welcher Position Sie die Ergebnisse anzeigen möchten. Wenn eine Suche 50 Ergebnisse zurückliefert und Sie nur 10 gleichzeitig anzeigen lassen, zeigt Ihnen rows=10
first=11 die zweiten 10 Ergebnisse an.
sort: Hiermit definieren Sie die Spalte, die für die Sortierung der Ergebnisse genutzt wird (sort=name).
Die Ergebnisse werden aufsteigend sortiert. Der Name der Spalte kann meist von dem Namen
der Tabellenspalte abgeleitet werden. Sie können testweise auch die Spalte anklicken und so
prüfen, wie der Spaltenname lautet. Typische Spaltennamen sind:
• name
• severity
• host
• location
Dabei werden die Spaltennamen der Anzeige in Kleinbuchstaben und Leerzeichen im Namen in
Unterstriche umgewandelt. Zusätzlich stehen noch ein paar weitere Felder zur Verfügung:
• uuid: Die UUID des Ergebnisses
• comment: Ein möglicher Kommentar
• modified: Datum und Uhrzeit der letzten Änderung
146
Abb. 11.5: Powerfilter können nach bestimmten CVEs suchen.
• created: Datum und Uhrzeit der Erzeugung
sort-reverse: Hiermit definieren Sie die Spalte, die für die Sortierung der Ergebnisse genutzt wird
(sort-reverse=name). Die Ergebnisse werden absteigend sortiert.
tag: Hiermit werden nur Ergebnisse mit einem bestimmten Tag ausgewählt (siehe auch Abschnitt Tags (Seite 150)). Dabei können Sie fest auf einen bestimmten Tag mit Wert filtern
(tag=”server:mail”) oder auch nur nach dem Tag suchen (tag=”server”). Reguläre Ausdrücke sind
ebenfalls möglich.
Bemerkung: Durch die Filterung mit Hilfe der Tags können Sie Ihre ganz eigenen Kategorien erzeugen
und in den Filtern verwenden. Dies erlaubt vielfältige und sehr feingranuläre Filterfunktionen!
Bei der Angabe dieser Komponenten können Sie mehrere Operatoren nutzen:
• = gleich z.B. rows=10
• ~ enthält z.B. name~admin
• < kleiner als z.B. created<-1w Älter als eine Woche
• > größer als z.B. created>-1w Jünger als eine Woche
• :RegEx z.B. name:admin$
Hier gibt es dann noch ein paar Besonderheiten. Wenn sie nach dem Gleichheitszeichen den Wert weglassen, werden alle Ergebnisse angezeigt bei denen dieser Wert nicht gesetzt ist:
comment=
liefert alle Ergebnisse ohne einen Kommentar.
Wenn Sie die Spalte, die Sie prüfen möchten weglassen, werden alle Spalten geprüft:
=192.168.15.5
Dies prüft, ob in mindestens einer der Spalten diese Zeichenfolge enthalten ist.
Dabei werden die Angaben üblicherweise or-verknüpft. Dies können Sie mit dem Schlüsselwort or
auch spezifisch angeben. Um eine Und-Verknüpfung zu erreichen, müssen Sie aber das Schlüsselwort
and angeben. Mit not können Sie den Filter negieren.
Datumsangaben
Datumsangaben im Powerfilter können sowohl absolut als auch relativ angegeben werden. Eine absolute Datumsangabe hat das folgende Format:
2014-05-26T13h50
Dabei kann die Uhrzeit weggelassen werden:
11.3. Powerfilter
147
2014-05-26
Dann wird als Uhrzeit automatisch 0:00 Uhr angenommen. Diese Datumsangabe kann dann im Suchfilter genutzt werden, z.B. created>2014-05-26.
Relative Zeitangaben werden immer relativ zur aktuellen Uhrzeit berechnet. Dabei werden positive
Zeitangaben als Angaben in der Zukunft interpretiert. Zeitangaben in der Vergangenheit werden durch
ein vorangestelltes Minus (-) definiert. Dabei können die Zeiträume durch die folgenden Buchstaben
angegeben werden:
• s Sekunde
• m Minute
• h Stunde
• d Tag
• w Woche
• m Monat (30 Tage)
• y Jahr (365 Tage)
Um Ergebnisse der letzten 5 Tage zu sehen, können Sie -5d angeben. Eine Kombination 5d1h ist nicht
möglich. Diese ist entsprechend zu ersetzen durch 121h.
Um den Zeitraum, z.B. den Monat, für den Informationen angezeigt werden sollen, einzugrenzen, können Sie den folgenden Ausdruck verwenden:
modified>2014-06-01 and modified<2014-07-01
Textphrasen
Grundsätzlich können Sie zusätzlich auch Textphrasen angeben, nach denen gesucht wird. Es werden
dann nur Ergebnisse angezeigt, in denen die Textphrasen gefunden werden. Werden diese Textphrasen nicht auf eine Spalte beschränkt (name=text) werden alle Spalten durchsucht. Damit werden auch
Spalten durchsucht, die in der aktuellen Anzeige verborgen sind.
Dabei helfen die folgenden Beispiele:
overflow Dies findet alle Ergebnisse, in denen das Wort overflow vorkommt. Das tri t auf
Overflow und Bufferoverflow gleichermaßen zu. Ebenso findet 192.168.0.1 sowohl
192.168.0.1 als auch 192.168.0.100.
remote exploit Dies findet alle Ergebnisse in denen remote oder exploit vorkommt. Natürlich
werden auch Ergebnisse angezeigt, in denen beide Wörter vorkommen.
remote and exploit Hier müssen beide Begri e in dem Ergebnis in einer beliebigen Spalte vorkommen. Dazu müssen diese Begri e nicht in derselben Spalte gefunden werden.
"remote exploit" Hier wird exakt nach dieser Zeichenkette und nicht nach den einzelnen Begriffen gesucht.
regexp 192\.168\.[0-9]+.1 Hiermit wird nach diesem regulären Ausdruck gesucht.
Abb. 11.6: Häufig benötigte Powerfilter lassen sich speichern und wieder aufrufen.
148
11.3.2 Speichern und Verwalten
Interessante und häufig verwendete Filter können auch gespeichert werden. Damit können sie einfach
wiederverwendet werden. Um zum Beispiel die NVTs anzuzeigen, die in der letzten Woche modifiziert
oder zum Feed hinzugefügt wurden, rufen Sie in der GUI SecInfo Management gefolgt NVTs von auf.
Dann editieren Sie den Powerfilter so, dass er den folgenden Inhalt hat (siehe Abbildung Häufig benötigte Powerfilter lassen sich speichern und wieder aufrufen. (Seite 148)):
Created>-1w or modified>-1w sort-reverse=created rows=1 first=1
Abb. 11.7: Die Filter sind über die Drop-Down-Box abrufbar.
Damit werden Ihnen alle NVTs angezeigt, die in der letzten Woche erzeugt oder modifiziert wurden.
Diesen Filter können Sie nun mit einem Namen versehen. Hierzu dient das Feld rechts neben dem
Powerfilter. Geben Sie hier den Namen ein und bestätigen Sie mit . Der Filter wird nun gespeichert
und ist über die Drop-Down-Box daneben auswählbar.
Um einen vorher gespeicherten Filter zu nutzen, verwenden Sie die Drop-Down-Box und betätigen
anschließend Switch Filter (siehe Abbildung Die Filter sind über die Drop-Down-Box abrufbar. (Seite 149)). Ist JavaScript aktiviert, wird der Filter sofort nach Auswahl in der Drop-Down-Box ausgelöst.
Wenn Sie bestimmte Filter grundsätzlich in bestimmten Ansichten aktivieren möchten, so geht dies
über Ihre Benutzereinstellungen (siehe auch Kapitel MySettings (Seite 191)). In diesem Beispiel (Abbildung Häufig benötigte Powerfilter können auch als Default-Filter in den Benutzereinstellungen eingerichtet werden. (Seite 149)) ist es der NVT Filter.
Abb. 11.8: Häufig benötigte Powerfilter können auch als Default-Filter in den Benutzereinstellungen
eingerichtet werden.
Alle gespeicherten Filter können über Configuration/Filters verwaltet werden. Hier können die Filter
gelöscht, editiert, geklont und für den Import auf anderen Appliances als GSM-Objekt exportiert werden.
Abb. 11.9: Alle Filter können einfach verwaltet werden.
Diese Filter können dann auch für die Filterung von Ereignisse bei den Alerts verwendet werden.
Filter können auch für andere Benutzer freigegeben werden.
11.3. Powerfilter
149
11.4 Tags
Die Tags sind willkürliche Informationen, die von den Benutzern an jede beliebige Ressource gebunden werden können. Dabei werden die Tags am einfachsten direkt bei den Ressourcen angelegt. Sie
können dann die Tags nutzen, um mit Hilfe des Powerfilters (siehe Abschnitt Powerfilter (Seite 145))
die Objekte entsprechend zu filtern. Hiermit sind sehr mächtige und feingranuläre Filtermöglichkeiten
vorhanden.
Abb. 11.10: Tags sind beliebige Zeichenketten, denen Sie einen Wert zuweisen können.
Diese Tags können anschließend in Filter-Ausdrücken genutzt werden. Mit dem Filter
tag=target:server muss das entsprechende Tag gesetzt sein, um erfasst zu werden. Der zugewiesene Wert des Tags ist unerheblich und darf auch leer sein. Mit tag="target:server=mail"
muss exakt dieser Tag mit dem entsprechenden Wert gesetzt sein.
150
KAPITEL 12
Scan-Konfiguration
Die GSM Appliance bringt bereits zahlreiche vorbereitete Scan-Konfigurationen mit. Diese können jedoch von Ihnen angepasst und durch eigene Konfigurationen erweitert werden. Die folgenden Konfigurationen sind bereits durch Greenbone hinterlegt:
Empty Dies ist ein leeres Template.
Discovery Es werden nur NVTs verwendet, die Informationen zum Zielsystem sammeln. Es werden
keine Schwachstellen abgeprüft.
Host Discovery Hier werden nur NVTs verwendet, um die verfügbaren Zielsysteme zu ermitteln. Dieser Scan gibt lediglich eine Liste der gefundenen Systeme aus.
System Discovery Hier werden nur NVTs verwendet, um die verfügbaren Zielsysteme einschließlich
der installierten Betriebssysteme und verwendeten Hardware zu prüfen.
Full and Fast Dies ist in vielen Umgebungen zu Beginn die richtige Wahl. Diese Konfiguration stützt
sich auf die zuvor im Portscan gewonnenen Informationen und verwendet fast alle Prüfroutinen. Hierbei werden aber nur diejenigen Prüfroutinen berücksichtigt, die keinen Schaden auf dem
Zielsystem anrichten können. Die Prüfroutinen sind best möglich optimiert, so dass die potentielle False-Negative Rate besonders gering ist. Die anderen Varianten bieten nur in sehr seltenen
Fällen einen Mehrwert bei wesentlich größerem Aufwand.
Full and fast ultimate Diese Konfiguration erweitert die Full and fast Konfiguration um Prüfroutinen,
die auch Dienste oder Rechner stören können oder einen Absturz herbeiführen.
Full and very deep Diese Konfiguration unterscheidet sich von der Full and fast Konfiguration, so
dass die Ergebnisse des Portscans keine Auswirkung auf die Auswahl der Prüfroutinen haben.
Daher kommen auch Prüfroutinen zum Einsatz, die dann auf ein Timeout warten müssen. Daher
ist dieser Scan sehr langsam.
Full and very deep ultimate Diese Konfiguration ergänzt die Full and very deep Konfiguration um die
gefährlichen Prüfroutinen, die möglicherweise Dienste oder Rechner stören können. Auch diese
Konfiguration ist entsprechend langsam.
Sie können die verfügbaren Scan-Konfigurationen über Configuration/Scan Configs anzeigen. Beachten Sie bitte, dass in der Default-Einstellung nur die ersten 10 Konfigurationen immer angezeigt werden.
In Abbildung Der GSM bringt bereits eine Vielzahl Scan-Konfigurationen mit. (Seite 152) können Sie erkennen, wie viele NVT-Familien und wie viele NVTs in den Konfigurationen aktiviert wurden. Zusätzlich
zeigt der Trend an, ob die Scan-Konfiguration dynamisch oder statisch konfiguriert wurde.
Greenbone verö entlicht regelmäßig neue Prüfungen (NVTs). Auch neue NVT families können durch
den Greenbone Security Feed eingeführt werden.
•
dynamisch
Scan-Konfigurationen, die dynamisch konfiguriert wurden, nehmen neue NVTFamilien oder neue NVTs aus den entsprechend aktivierten Familien automatisch bei
einem Greenbone NVT Feed Update auf und aktivieren diese. Damit ist sichergestellt,
151
Abb. 12.1: Der GSM bringt bereits eine Vielzahl Scan-Konfigurationen mit.
dass die neuen NVTs auch tatsächlich sofort ohne Interaktion des Administrators aktiv
sind.
•
statisch
Scan-Konfigurationen, die statisch konfiguriert wurden, ändern sich bei einem NVTFeed-Update nicht.
Das Icon
zeigt an, ob andere Benutzer die Scan-Konfiguration sehen und benutzen dürfen.
Abb. 12.2: Die Scan-Konfigurationen der Benutzer sind nur für diese sichtbar.
Um eine Konfiguration freizugeben, müssen Sie dem entsprechenden Benutzer, der Rolle oder der
Gruppe das Privileg get_configs zuweisen. Dann wird diese Konfiguration auch den entsprechenden
Benutzern angezeigt.
Abb. 12.3: Mit den entsprechenden Berechtigungen können andere Benutzer auf die Konfigurationen
zugreifen.
152
Kapitel 12. Scan-Konfiguration
12.1 Erzeugen einer neuen Scan-Konfiguration
Um eine neue Scan-Konfiguration anzulegen, rufen Sie zunächst Configuration/Scan Configs auf. Anschließend kann durch Anklicken von eine neue Scan-Konfiguration erzeugt werden.
Auf dem folgenden Bildschirm haben Sie die Möglichkeit eine Scan-Konfiguration zu importieren oder eine eigene Scan-Konfiguration zu erzeugen. Greenbone stellt selbst verschiedene ScanKonfigurationen auf seiner Webseite zur Verfügung. Außerdem können Sie Scan-Konfigurationen auf
anderen GSM-Appliances exportieren, um diese dann hier zu importieren.
Abb. 12.4: Eine neue Scan-Konfiguration kann selbst erzeugt oder importiert werden.
Wenn Sie eine eigene Scan-Konfiguration erzeugen möchten, geben Sie ihr einen Namen und einen optionalen Kommentar und entscheiden Sie, welche Scan-Konfiguration als Template verwendet werden soll. Hier haben Sie die Auswahl zwischen:
• Empty, static and fast
• Full and fast
Wenn Sie eine andere Scan-Konfiguration als Template verwenden möchten, so können Sie diese auf
der Übersichtsseite klonen . Dann können Sie die Konfiguration editieren und mit einem eigenen
Namen und Kommentar versehen und weiter anpassen.
Auf dem nächsten Bildschirm wird Ihnen zunächst die Konfiguration angezeigt. Um diese zu editieren,
verwenden Sie das entsprechende Icon mit dem Schraubenschlüssel.
Abb. 12.5: Die Konfiguration bietet viele Anpassungsmöglichkeiten
Nun können Sie die Konfiguration anpassen. Wichtig sind hier die folgenden Einstellungen:
12.1. Erzeugen einer neuen Scan-Konfiguration
153
Family Trend Hier können Sie entscheiden, ob neue Familien automatisch in dieser ScanKonfiguration aktiviert werden sollen.
NVT Trend Bei jeder Familie können Sie entscheiden, ob neue NVTs dieser Familie automatisch aktiviert werden sollen.
Select All In dieser Spalte können Sie einstellen, ob alle NVTs einer Familie ausgewählt werden sollen.
Über dieses Icon können Sie direkt in die Familie springen, und die einzelnen NVTs auswähAction
len, wenn Sie nicht alle verwenden möchten.
Wenn Sie weiter nach unten scrollen, erscheinen die Scanner Preferences (siehe Abschnitt Scanner
Preferences (Seite 155)). Hier können Sie weitergehende Einstellungen für den Scan vornehmen. Außerdem gibt es die NVT-Preferences, die von den NVTs genutzt werden. Diese können hier angepasst
werden. Es gibt ferner die Möglichkeit, die Einstellungen auch direkt bei den entsprechenden NVTs zu
definieren.
Abb. 12.6: Die Konfiguration erlaubt auch spezifische Anpassungen der NVTs.
Um die Einstellungen der NVTs vorzunehmen, müssen Sie in die entsprechende Familie wechseln.
Nach dem Aufruf einer Familie haben Sie Zugri auf die einzelnen NVTs. Sie sehen die NVTs, die Bestandteil der Familie sind, und ihre Bedrohungsstufen.
Außerdem können Sie den Zustand (aktiv/inaktiv) und den Timeout der NVT-Prüfung einsehen und
prüfen, ob der NVT über eine Einstellung (Spalte Pref) weiter konfiguriert werden kann. Ist dies der
Fall, kann über den entsprechenden Schraubenschlüssel die Konfiguration aufgerufen werden. Die
Einstellungen sind auf der folgenden Seite ganz unten aufzufinden.
Die bei den NVTs angepassten Einstellungen werden dann auf der Übersichtsseite der ScanKonfiguration (siehe Abbildung Die Konfiguration bietet viele Anpassungsmöglichkeiten (Seite 153)
und Die Konfiguration erlaubt auch spezifische Anpassungen der NVTs. (Seite 154)) angezeigt.
Für den praktischen Einsatz sind insbesondere die Einstellungen der verwendeten Port Scanner interessant. Die GSM Appliance nutzt als Port-Scanner Nmap und Ping . Nmap wird über den NASL wrapper
genutzt. Dies ermöglicht die größte Flexibilität.
154
Abb. 12.7: Bei dem Zugri auf eine Familie sehen Sie die einzelnen NVTs.
Abb. 12.8: Die Preferences können auch bei jedem NVT einzeln eingestellt werden.
12.2 Scanner Preferences
Sämtliche Scanner und NVT Preferences hier zu dokumentieren, würde den Rahmen sprengen. Daher
sollen hier nur die wichtigen allgemeinen Einstellungen und die spezifischen Einstellungen des Ping
und Nmap-Scanners beschrieben werden.
12.2.1 Allgemeine Preferences
• auto_enable_dependencies: Hiermit werden automatisch NVTs aktiviert, die von anderen NVTs
benötigt werden.
• cgi_path: Dies ist der Pfad, der von NVTs für den Zugri auf CGI-Skripte genutzt wird.
• checks_read_timeout: Dies ist der Timeout für die Netzwerksockets während des Scans.
• drop_privileges: Mit diesem Parameter gibt der OpenVAS-Scanner vor dem Start der NVTs die
root-Privilegien ab. Dies erhöht die Sicherheit, führt aber auch bei einigen NVTs zu weniger Ergebnissen.
• host_expansion: Hier sind drei verschiedene Werte erlaubt:
– dns: Führt einen AXFR-Zonentransfer auf dem Zielsystem durch und prüft die dabei gefundenen Systeme
– nfs: Prüft die Systeme, die auf dem Zielsystem auf eine NFS-Freigabe zugreifen dürfen.
12.2. Scanner Preferences
155
Abb. 12.9: Diese Einstellungen werden allgemein von der Konfiguration genutzt.
– ip: Scanned das angegebene Subnetz.
• log_whole_attack: Ist diese Option aktiv, protokolliert das System die Laufzeit jedes einzelnen
NVTs. Ansonsten wird nur Start und Ende des Scans protokolliert. Dies reduziert den benötigten
Speicherplatz auf der Festplatte.
• network_scan: Experimentelle Option, bei der das gesamte Netzwerk auf einmal gescannt wird,
anstatt für jeden Host einzeln zu starten. Dies kann in bestimmten Umgebungen Zeit sparen.
• non_simult_ports: Diese Ports werden nicht gleichzeitig durch NVTs getestet.
• optimize_test: NVTs werden nur gestartet, wenn die entsprechenden Voraussetzungen (z.B. offener Port) gegeben sind.
• plugins_timeout: Maximale Laufzeit eines NVTs.
• report_host_details: Detaillierte Angaben zum Host werden im Report hinterlegt.
• safe_checks: Einige NVTs können auf dem Zielsystem Schaden anrichten. Diese Einstellung deaktiviert die entsprechenden NVTs.
• unscanned_closed: Dieser Parameter definiert, ob TCP-Ports, die nicht gescannt wurden, wie
geschlossene Ports behandelt werden.
• unscanned_closed_udp: Dieser Parameter definiert, ob UDP-Ports, die nicht gescannt wurden,
wie geschlossene Ports behandelt werden.
• use_mac_addr: Hiermit werden die Systeme an Hand ihrer MAC-Adresse und nicht der IPAdresse identifiziert. Dies kann in DHCP-Umgebungen sinnvoll sein.
• vhosts: Wenn der GSM einen Webserver mit namensbasierten virtuellen Hosts scannen soll,
dann können die Einstellungen vhosts und vhosts_ip nutzt werden. In der Einstellung vhosts
werden kommasepariert die Namen der virtuellen Webhosts hinterlegt.
• vhosts_ip: Wenn der GSM einen Webserver mit namensbasierten virtuellen Hosts scannen
soll, dann können die Einstellungen vhosts und vhosts_ip genutzt werden. In der Einstellung
vhosts_ip wird die IP-Adresse des Webservers hinterlegt. In dem Bericht kann jedoch noch nicht
156
nachvollzogen werden, auf welcher virtuellen Webinstanz ein NVT eine Schwachstelle gefunden hat.
12.2.2 Ping Preferences
Der Ping-Scanner-NVT hat die folgenden Konfigurationsparameter.
Beachten Sie, dass die Alive Test Einstellung eines Target-Objektes einige Einstellungen für den
Ping-Scanner überschreiben kann.
• Do a TCP ping: Hiermit können Sie entscheiden, ob Sie per TCP die Erreichbarkeit
eines Hosts prüfen möchten. In diesem Fall werden die folgenden Ports geprüft:
21,22,23,25,53,80,135,137,139,143,443,445. Standard: Nein.
• Do an ICMP ping: Hiermit können Sie entscheiden, ob Sie per ICMP die Erreichbarkeit eines Hosts
prüfen möchten. Standard: Ja.
• Mark unreachable Hosts as dead: Hiermit entscheiden Sie, ob Rechner, die von diesem NVT nicht
erkannt wurden, später noch von anderen NVTs geprüft werden. Standard: Nein.
• Report about reachable Hosts: Hiermit entscheiden Sie, ob die von diesem NVT gefundenen Systeme aufgelistet werden. Standard: Nein.
• Report about unreachable Hosts: Hiermit entscheiden Sie, ob die von diesem NVT nicht gefundenen Systeme aufgelistet werden. Standard: Nein.
• TCP ping tries also TCP-SYN ping: Der TCP-Ping nutzt per Standard ein TCP-ACK Paket. Hiermit
können Sie zusätzlich auch ein TCP-SYN Paket nutzen. Standard: Nein.
• Use ARP: Hiermit entscheiden Sie, ob Hosts mit dem ARP-Protokoll im lokalen Netz gesucht werden sollen. Standard: Nein.
• Use Nmap: Hiermit entscheiden Sie, ob für den Ping-NVT Nmap eingesetzt wird: Standard: Ja.
• nmap: try also with only –sP: Falls Nmap eingesetzt wird, wird auch der Ping-Scan mit der Option
-sP durchgeführt.
• nmap additional ports for –PA: Hier können zusätzliche Ports für den TCP-Ping-Test angegeben
werden. Dies ist aber nur der Fall, wenn gesetzt ist. Standard: 8080,3128.
12.2.3 Nmap NASL Preferences
Die folgenden Optionen werden direkt in Optionen für den Aufruf des Nmap-Kommandos umgesetzt.
Weiterführende Informationen sind daher auch in der Dokumentation zu Nmap documentation for
nmap130 zu finden.
• Do not randomize the order in which ports are scanned: Nmap scanned dann die Ports in aufsteigender Reihenfolge.
• Do not scan targets not in the file: Nur sinnvoll gemeinsam mit File containing grepable results.
• Fragment IP packets: Nmap fragmentiert die Pakete für den Angri . Damit konnten früher einfache Paketfilter überwunden werden.
• Get Identd info: Nmap fragt den UNIX-Ident-Daemon ab. Dieser wird heute nicht mehr genutzt.
• Identify the remote OS: Nmap versucht das Betriebssystem zu ermitteln.
• RPC port scan: Nmap prüft das System auf Sun RPC Ports.
• Run dangerous ports even if safe checks are set: UDP und RPC Scans können Probleme verursachen und werden bei der Einstellung üblicherweise abgeschaltet.
• Service scan: Hiermit versucht Nmap die Dienste zu erkennen.
130
http://nmap.org/docs.html
12.2. Scanner Preferences
157
• Use hidden option to identify the remote OS: Nmap versucht das Betriebssystem aggressiver zu
erkennen.
• Host Timeout: Hiermit wird der Host-Timeout definiert.
• Initial RTT timeout: Dies ist der initiale Round-Trip-Timout. Nmap kann diesen Timeout in Abhängigkeit der Ergebnisse anpassen.
• Max RTT timeout: Dies ist der maximale RTT.
• Min RTT timeout: Dies ist der minimale RTT.
• Minimum wait between probes: Hiermit können Sie die Geschwindigkeit des Scans steuern.
• Ports scanned in parallel (max): Hiermit definieren Sie, wieviele Ports gleichzeitig gescannt werden.
• Ports scanned in parallel (min): siehe oben
• Source port: Hiermit können Sie den Source-Port definieren. Dies kann interessant sein, um durch
eine Firewall zu scannen, wenn diese Firewall Verbindungen von einem bestimmten Port grundsätzlich erlaubt.
• File containing grepable results: Hermit können Sie eine Datei angeben, in der sich zeilenweise
Einträge der Form Host: ip-addresse befinden. Wenn gleichzeitig die Option Do not scan
targets not in the file gesetzt ist, werden nur die Rechner gescannt, die in der Datei aufgeführt
sind.
• TCP scanning technique: Hiermit definieren Sie die eigentliche Scan-Methode
• Timing policy: Anstatt die Timeout-Werte einzeln anzupassen, können Sie auch die Timing policy
modifizieren.
Die Timing Policy verwendet die folgenden Werte:
Paranoid
Sneaky
Polite
Normal
Aggressive
Insane
158
initial_rtt_timeout
5 min
min_rtt_timeoutmax_rtt_timeoutmax_parallelismscan_delay max_scan_delay
100 ms
10 sec
Serial
5 min
1 sec
15 sec
1 sec
1 sec
500 ms
100 ms
100 ms
100 ms
100 ms
10 sec
10 sec
10 sec
1250 ms
Serial
Serial
Parallel
Parallel
15 sec
400 ms
0 sec
0 sec
1 sec
1 sec
1 sec
10 ms
250 ms
50 ms
300 ms
Parallel
0 sec
5 ms
KAPITEL 13
Scanner
Zusätzliche Scanner können über das GOS-Admin-Menü aktiviert werden. Der GSM bringt in seiner
Werkeinstellung den OpenVAS Scanner mit. Kein weiterer Scanner ist aktiviert.
Bemerkung: Beginnend mit GOS 3.1.17 können einzelne ausgewählte Anwender zusätzliche Scanner
aktivieren. Diese Funktionalität wird mit einem späteren Update allen Benutzern zur Verfügung gestellt. Um diese Funktion jetzt bereits zu testen, kontaktieren Sie den Greenbone Support.
Um weitere Scanner zu aktivieren, lesen Sie bitte den Abschnitt Aktivierung zusätzlicher OSP-Scanner
(Seite 231).
Dieses Kapitel zeigt die Nutzung der zusätzlichen Scanner.
13.1 w3af Scanner
w3af ist das “Web Application Attack and Audit Framework”. Sein Ziel ist die Bereitstellung eines
Baukasten für die Suche und den Test sämtlicher bekannter Web-Schwachstellen in Ihrer WebApplikation.
Nachdem der Scanner über das GOS-Admin-Menü aktiviert wurde (siehe Abschnitt Aktivierung zusätzlicher OSP-Scanner (Seite 231)), müssen Sie den w3af-Scanner konfigurieren. Hierzu nutzen Sie
die Weboberfläche. Wählen Sie Configuration gefolgt von Scanners. Hier werden alle aktivierten OSPScanner aufgeführt:
Abb. 13.1: Alle konfigurierten OSP-Scanner
Wählen Sie den w3af-Scanner. Sie sehen dann die aktuelle Konfiguration:
Die Werkseinstellungen können in diesem Dialog nicht verändert werden. Um diese Parameter zu modifizieren müssen Sie eine entsprechende Scan-Konfiguration erzeugen.
159
Abb. 13.2: w3af Konfiguraton
13.1.1 w3af Scankonfiguration
Wechseln Sie zu Konfiguration/Scan-Konfigurationen. Erzeugen Sie eine neue Scan-Konfiguration
und wählen Sie w3af als Basis.
Abb. 13.3: Erzeugen Sie eine w3af Scan-Konfiguration
Diese Konfiguration kann nun angepasst werden. Die folgenden Parameter sind verfügbar:
• Profil Sie können zwischen verschiedenen w3af Profilen wählen. Diese Profile werden auf der
Webseite http://w3af.org ausführlicher beschrieben. Diese Profile enthalten unterschiedlich
konfigurierte w3af Plugins.
– fast_scan
– audit_high_risk
– full_audit
– OWASP_TOP10
– bruteforce
160
Kapitel 13. Scanner
– empty_profile
– web_infrastructure
– full_audit_spider_man
– sitemap
• http_request_status Hiermit können Sie die entsprechende Funktion einstellen.
• http_request_headers Hiermit können Sie die entsprechende Funktion einstellen.
• http_response_status Hiermit können Sie die entsprechende Funktion einstellen.
• debug_mode Hiermit können Sie die entsprechende Funktion einstellen.
• dry_run Hiermit können Sie die entsprechende Funktion einstellen.
• use_https Hiermit können Sie die entsprechende Funktion einstellen.
• seed_path Hiermit geben Sie die Start-URL für den w3af Scanner an.
• target_port Hiermit können Sie einen alternativen Port für den Webserver angeben, z.B. 8080
oder 443.
13.1.2 w3af Scan-Aufgabe
Um ein System zu scannen müssen Sie eine entsprechende Aufgabe erzeugen. Wechseln Sie zu ScanManagement und erzeugen Sie eine neue Aufgabe. Geben Sie die üblichen Informationen oben auf der
Seite ein: Name, Ziel, Benachrichtigung, Zeitplan, etc. Scrollen Sie auf der Seite nach unten und wählen
Sie den OSP-Scanner statt dem OpenVAS Scanner:
Abb. 13.4: Erzeugen Sie eine w3af Scan-Aufgabe
Erzeugen Sie die Scan-Aufgabe und starten Sie den Scan wie üblich.
13.2 PaloAlto Scanner
Dieser OSP Scanner bezieht seine Informationen von einer PaloAlto Next Generation Firewall Appliance. Der Scanner kann drei verschiedene Informationsquellen nutzen:
• Mithilfe des protokollierten Verkehrs der Firewall können die Ports mit aktiven Diensten auf dem
Ziel ermittelt werden.
• Mithilfe des protokollierten Verkehrs der Firewall können die von dem Ziel genutzten Protokolle
erkannt werden.
13.2. PaloAlto Scanner
161
• Die Bedrohungen, die durch die Firewall erkannt und protokolliert wurden, werden nach CVEReferenzen durchsucht.
Die PaloAlto Firewall unterscheidet 5 verschiedene Schweregradklassen. Diese Klassen werden wie
folgt auf CVSS Werte übertragen:
• Informational: 0.0
• Niedrig: 3.0
• Mittel: 5.0
• Hoch: 8.0
• Kritisch: 10.0
Sie können die Funktion des PaloAlto-Scanners prüfen, indem sie den Scanner auf der Seite
Konfiguration/Scanner auswählen:
Abb. 13.5: Prüfung des PaloAlto-Scanner
Wenn der Scanner erreichbar ist, können Sie die Antwort des Scanners verifizieren. Falls der Scanner
nicht online ist, sehen Sie “O ine”.
13.2.1 PaloAlto Scanner Konfiguration
Die folgenden Schritte sind für die Nutzung des PaloAlto-Scanners erforderlich.
Scan-Konfiguration
Umden Scanner zu verwenden, müssen Sie eine Scan-Konfiguration erzeugen. Wechseln Sie zu
Konfiguration/Scan Konfigurationen.
Erzeugen Sie eine neue Scan-Konfiguration und wählen Sie als Basis PaloAlto.
Hier können Sie die folgenden Angaben machen:
• dry_run Dies führt einen Trockenlauf durch.
• period Hiermit geben Sie den Zeitraum an für den der GSM die Protokolle von der PaloAltoAppliance bezieht. Dieser Zeitraum sollte zum genutzten Zeitplan der Aufgabe passen. Wenn
Sie die Scan-Aufgabe täglich aufrufen sollte Sie hier mindestens 24 Stunden wählen.
• debug_mode Hiermit erhalten Sie weitere Informationen zur Fehlersuche.
162
Kapitel 13. Scanner
Abb. 13.6: Erzeugen Sie eine PaloAlto Scan-Konfiguration
• ca-certificate Dies ist das CA-Zertifikat der PaloAlto um diese zu verifizieren.
• address Dies ist die IP-Adresse der PaloAlto Appliance.
Ziel
Nun müssen Sie ein spezielles Ziel für den PaloAlto-Scan erzeugen. Die Ziele anderer Scans können
hier nicht genutzt werden, da die für die Anmeldung an der PaloAlto Firewall genutzten Anmeldedaten
wie die Anmeldedaten für einen authentifizierten Scan konfiguriert werden.
Zunächst erzeugen Sie die Anmeldedaten für den Zugri auf die PaloAlto Appliance (siehe Abbildung
PaloAlto Anmeldedaten (Seite 163)).
Abb. 13.7: PaloAlto Anmeldedaten
Nun erzeugen Sie ein Ziel, welches diese Anmeldedaten nutzt (siehe Abbildung PaloAlto Ziel (Seite 164)).
Aufgabe
Sobald die Scan-Konfiguration erzeugt wurde können Sie eine Aufgabe generieren. Wechseln Sie nach
Scan-Management/Aufgaben. Erzeugen Sie eine neue Aufgabe und wählen Sie als OSP-Scanner PaloAlto und ihre Scan-Konfiguration.
Starten Sie die Aufgabe. Sobald der Scan abgeschlossen wurde, können Sie den Bericht analysieren.
13.2.2 PaloAlto Bericht
Der von dem PaloAlto OSP-Scanner erzeugte Bericht ähnelt dem OpenVAS Bericht obwohl es einige
Unterschiede gibt. Die PaloAlto Next Generation Firewall besitzt ein Intrusion Detection System und
163
Abb. 13.8: PaloAlto Ziel
Abb. 13.9: Erzeugen einer PaloAlto Aufgabe
nicht einen Schwachstellenscanner. Daher werden die in dem Bericht aufgeführten Schwachstellen
nicht im Rahmen einer Prüfung erkannt. Es handelt sich um erkannte Angri e dritter Personen. Die
Qualität des Berichts hängt daher sehr stark von den Einstellungen der PaloAlto Appliance ab.
Das folgende Bild zeigt einen Beispielbericht:
Die PaloAlto Next Generation Firewall protokolliert die möglichen falsch-positiven Meldungen mit
dem Ausdruck “Attempt” (Versuch). Wie in dem Beispielbericht ersichtlich werden mehrere “Generic
HTTP Cross Site Scripting Attempt” und “HTTP SQL Injection Attempt” protokolliert.
Die PaloAlto Firewall erkennt den Angri und verhindert in vielen Fällen, dass der Angri sein Ziel erreicht. In den meisten Fällen kann daher nicht auf diesem Weg ermittelt werden, ob das Ziel tatsächlich
die Schwachstelle besitzt. Daher ist es immer sinnvoll die IDS-Ereignisse mit einem Schwachstellenscan in einer Lösung zur Verwaltung der Schwachstellen zu kombinieren.
164
Kapitel 13. Scanner
Abb. 13.10: PaloAlto Beispielbericht
165
166
Kapitel 13. Scanner
KAPITEL 14
Alternative Oberflächen
Die Weboberfläche des GSM ist austauschbar. Alle Weboberflächen nutzen einen eingebauten
Webserver, der alle Aktionen in das OpenVAS Management Protokoll umsetzt und die Ergebnisse entsprechend anzeigt. Die Weboberflächen verfügen daher über keinerlei eigene Intelligenz. Die Intelligenz ist komplett in dem OpenVAS Manager verborgen. Daher können die Weboberflächen ausgetauscht werden.
In der Version GOS 3.1 bietet der GSM zwei verschiedene Weboberflächen:
• Klassisch: Dies ist die klassische Ansicht des Greenbone Security Assistant.
• ITS: Dies ist die vereinfachte Darstellung in Form einer IT-Schwachstellenampel.
Um zwischen den verschiedenen Darstellungen umzuschalten, ist ein Zugang zur Kommandozeile erforderlich. Die ausgewählte Oberfläche ist immer für alle Anwender einer GSM-Appliance aktiv. Die
Auswahl kann nicht benutzerabhängig gesteuert werden.
14.1 IT-Schwachstellenampel
Bemerkung: Diese Benutzeroberfläche (UI) ist nur in deutscher Sprache verfügbar.
Bevor Sie auf die IT-Schwachstellenampel (ITS) umschalten, sollten Sie in der klassischen Ansicht
noch einige Schritte umsetzen. Ansonsten erhalten Sie Warnungen in der Schwachstellenampel wie
in Abbildung Scan mit der ITS Schwachstellenampel. (Seite 168) dargestellt:
• Importieren Sie das ITS-Report-Format.
Laden Sie von http://www.greenbone.net/download/rfps/its-openvas.xml das ITS-Report Format und importieren Sie diese unter Configuration/Report Formats. Editieren Sie das ReportFormat und aktivieren Sie es. Nun sollten Sie es noch durch einen Klick verifizieren.
• Importieren Sie die ITS-Scankonfiguration
Laden Sie von http://www.greenbone.net/download/scanconfigs/its-scanconfig.xml die ITSScankonfiguration und importieren Sie diese unter Configuration/Scan Configs.
Sind diese Vorarbeiten abgeschlossen, können Sie umschalten. Möglicherweise waren auf Ihrem System einzelne Vorarbeiten auch schon durchgeführt worden. Um die Darstellung zu verändern, rufen
Sie das GOS-Admin-Menü auf. Dort können Sie im Menüpunkt Remote das HTTPS web interface konfigurieren. Der Default-Wert ist classic. Um auf die IT-Schwachstellenampel umzuschalten, setzen
Sie den Wert auf its. Nach einem Commit wird die Änderung innerhalb weniger Minuten aktiv. Ein
Reboot ist nicht erforderlich.
Alternativ können Sie den Wert auch auf der Kommandozeile direkt setzen:
gsm: set web_interface its
gsm *: commit
167
Nach wenigen Minuten ist die ITS-Schwachstellenampel aktiv. Das Login zeigt nun das Vorhandensein
der neuen Oberfläche an (siehe Abbildung Der Login an der ITS Schwachstellenampel. (Seite 168)).
Abb. 14.1: Der Login an der ITS Schwachstellenampel.
Nach der Anmeldung erscheint ein Wizard, mit dem Sie einen einfachen Scan starten können.
Für den Scan können Sie einen administrativen Benutzer angeben. Der Scanner wird sich dann auf
dem System anmelden und das System auch von innen scannen (siehe Abbildung Scan mit der ITS
Schwachstellenampel. (Seite 168)). Wenn Sie das Berichtsformat und die Scankonfiguration importiert und den ITS-Scanner geklont haben, werden die Warnungen nicht mehr angezeigt.
Abb. 14.2: Scan mit der ITS Schwachstellenampel.
Werden Schwachstellen gefunden, so beginnt die abgebildete Ampel während des Scans in der entsprechenden Farbe zu blinken. Sobald die Prüfung abgeschlossen ist, stellt die Ampel das Blinken ein
und zeigt den Zustand dauerhaft an (Siehe Abbildung Nach Abschluss wird der Status von der Ampel
dauerhaft angezeigt. (Seite 169)).
168
Kapitel 14. Alternative Oberflächen
Über das Drucker-Icon (Abbildung Das Drucker-Icon stellt den Bericht bereit. (Seite 169)) kann der PDFBericht geladen werden.
Abb. 14.3: Nach Abschluss wird der Status von der Ampel dauerhaft angezeigt.
Abb. 14.4: Das Drucker-Icon stellt den Bericht bereit.
14.1. IT-Schwachstellenampel
169
170
Kapitel 14. Alternative Oberflächen
KAPITEL 15
Benutzer- und Rechteverwaltung
Dieses Kapitel betrachtet die Benutzer-, Gruppen-, Rollen- und Rechteverwaltung im Detail.
15.1 Benutzerverwaltung
Der Greenbone Security Manager erlaubt die Erzeugung und Verwaltung der Benutzer mit unterschiedlichen Rollen und Berechtigungen. Bei der Inbetriebnahme des GSM wird der erst Benutzer, der
Web/Scan-Administrator, über das GOS-Admin-Menü angelegt. Dieser Benutzer kann sich dann anmelden und weitere Benutzer verwalten.
Dabei unterstützt die GSM Benutzerverwaltung ein rollenbasiertes Rechtekonzept bei dem Zugri
auf die Weboberfläche. Mehrere Rollen sind bereits von Werk angelegt. Weitere Rollen können jedoch
von einem Administrator erzeugt und verwendet werden. Die Rolle definiert, welche Funktionen der
Weboberfläche von dem Benutzer eingesehen und modifiziert werden dürfen. Dabei sind die Rollen
nicht in der Weboberfläche, sondern in dem darunterliegenden OMP-Protokoll realisiert und wirken
sich daher auf alle OMP-Clients aus. Lesender und modifizierender Zugri kann getrennt den Rollen
zugewiesen werden.
Neben den Rollen unterstützt die GSM Benutzerverwaltung auch Gruppen. Gruppen erlauben die Zusammenfassung von Benutzern. Dies dient in erster Linie der logischen Gruppierung. Neben einer Verwaltung der Rechte über die Rollen können auch Gruppen entsprechende Privilegien zugewiesen werden.
Zusätzlich kann über die Benutzerverwaltung jedem Benutzer ein Bereich von IP-Adressen zugewiesen werden, dessen Scan erlaubt oder verboten ist. Die GSM Appliance weigert sich dann andere als
die angegebenen IP-Adressen durch den entsprechenden Benutzer zu scannen. Auch der Zugri auf
bestimmte Schnittstellen der GSM-Appliance kann erlaubt bzw. verboten werden.
Der Greenbone Security Manager bietet für die Verwaltung der Rollen und spezifischen Privilegien
der Benutzer eine eigene Benutzerverwaltung. Um jedoch Kennwörter nicht mehrfach vorhalten zu
müssen und eine Kennwortsynchronisation zu erlauben, bietet der Greenbone Security Manager die
Anbindung des Systems an einen zentralen LDAP-Server. Dieser wird dann aber nur für die Überprüfung des Kennworts bei der Anmeldung des Benutzer genutzt. Alle weiteren Einstellungen erfolgen
in der Benutzerverwaltung der GSM Appliance.
Diese Funktionen werden auf den nächsten Seiten genauer betrachtet.
Den Dialog für das Anlegen und Verwalten der Benutzer erreichen Sie über das Menü Administration.
Dieses Menü wird nur für Administratoren eingeblendet, da zunächst nur diese weitere Benutzer anlegen und verwalten dürfen. Hier können Sie den Dialog für die Anlage neuer Benutzer durch den weißen
Stern auf blauen Grund aufrufen oder durch Anwählen des Schraubenschlüssels einen vorhandenen Benutzer modifizieren.
171
Abb. 15.1: Anlegen eines neuen Benutzers
Bei der Anlage eines neuen Benutzers sind die folgenden Angaben möglich:
• Login Name: Dies ist der Name, mit dem sich der Benutzer anmeldet. Wenn ein LDAP-Server als
zentraler Kennwortspeicher genutzt wird, muss der Benutzer mit dem identischen Namen (rDN)
im LDAP-Server angelegt sein. Der Name darf maximal 80 Zeichen lang sein und aus Buchstaben
und Zi ern bestehen.
• Password: Dies ist das Kennwort des Benutzers. Das Kennwort darf maximal 40 Zeichen aufweisen und aus beliebigen Buchstaben bestehen. Achten Sie darauf, dass, wenn Sie Sonderzeichen
verwenden, diese auf allen Tastaturen und Betriebssystemen, die Sie einsetzen, auch erreichbar
sind.
• Roles (optional): Jeder Benutzer darf mehrere Rollen besitzen. Die Rollen definieren die Rechte
des Benutzers bei der Verwendung des OMP Protokolls. Da der Greenbone Security Assistant das
OMP-Protokoll nutzt, definieren die Rollen auch direkt die Möglichkeiten in der Weboberfläche.
Während Sie weitere Rollen hinzufügen und konfigurieren können, stehen zu Beginn die Rollen
Administrator, User, Info, Observer, und ein paar weitere zur Verfügung. Diese Rollen werden in
dem Abschnitt Benutzerrollen (Seite 173) genauer betrachtet.
• Groups (optional): Jeder Benutzer kann Mitglied mehrerer Gruppen sein. Auch über die Gruppen
kann eine Rechteverwaltung erfolgen (siehe Abschnitt Permissions (Seite 179))
• Host Access: Hier können Sie definieren, welche Rechner ein bestimmter Benutzer in einem
Scan analysieren darf und welche Rechner nicht in einem Scan berücksichtigt werden. Diese
Einschränkungen können auch für Administratoren eingerichtet werden. Diese können jedoch
auch selbst die Einschränkungen wieder aufheben. Daher ist diese Funktion bei Administratoren lediglich zum Selbstschutz. Normale Benutzer (User) bzw. andere Rollen ohne Zugri auf die
Benutzerverwaltung können diese Einschränkungen jedoch nicht umgehen. Hierbei können Sie
grundsätzlich zwischen einer Whitelist (Deny all and allow) und einer Blacklist (Allow all and
deny) wählen. Im ersten Fall ist der Scan sämtlicher Rechner grundsätzlich verboten und nur
explizit aufgeführte Systeme dürfen gescannt werden. Im zweiten Fall ist der Scan sämtlicher
Systeme mit Ausnahme der aufgeführten Systeme erlaubt. Es können sowohl Rechnernamen als
auch IPv4- und IPv6-Adressen angegeben werden. Ferner können sowohl einzelne IP-Adressen
als auch Adressbereiche und Netzwerksegmente spezifiziert werden. Die folgende Auflistung
gibt hierfür einige Beispiele:
– 192.168.15.5 (IPv4-Adresse)
– 192.168.15.5-192.168.15.27 (IPv4-Bereich Langform)
– 192.168.15.5-27 (IPv4-Bereich Kurzform)
– 192.168.15.128/25 (CIDR-Notation)
– 2001:db8::1 (IPv6-Adresse)
– 2001:db8::1-2001:db8::15 (IPv6-Bereich Langform)
– 2001:db8::1-15 (IPv6 Bereich Kurzform)
172
Kapitel 15. Benutzer- und Rechteverwaltung
– 2001:db8::/120 (CIDR-Notation)
Sämtliche Optionen können beliebig gemischt und als kommaseparierte Liste angegeben werden. Die Netzmaske in der CIDR-Notation ist jedoch auf maximal 20 bei IPv4 und 116 bei IPv6
beschränkt. In beiden Fällen resultieren hieraus maximal 4096 IP-Adressen.
Abb. 15.2: Anzeigen des Benutzers.
• Interface Access: Hier können Sie definieren, über welche Netzwerkkarten ein Anwender einen
Scan ausführen darf. Hier können Sie eine kommaseparierte Liste von Netzwerkkarten angeben
und ähnlich wie bei dem Host Access zwischen einem Whitelist und einem Blacklist-Verfahren
wählen.
Tipp: Grundsätzlich sollten Sie sich bemühen, das Whitelist-Verfahren zu benutzen und den Scan
grundsätzlich bis auf ausgewählte Systeme zu verbieten. Damit ist sichergestellt, dass Ihre Anwender
nicht durch Zufall oder aus Unwissenheit Systeme prüfen, die außerhalb ihrer Zuständigkeit liegen,
sich irgendwo im Internet befinden oder auf einen Scan mit Fehlfunktionen reagieren.
Nach der Anlage des Benutzers werden dessen Eigenschaften angezeigt. Sie sollten diese Anzeige
kontrollieren um sicherzustellen, dass Sie dem Benutzer nicht zu viele Privilegien zugewiesen haben.
15.1.2 Gleichzeitige Anmeldung
Natürlich ist es möglich, dass zwei unterschiedliche Benutzer gleichzeitig an einem GSM angemeldet sind. Möchte sich der gleiche Benutzer mehrfach anmelden, so muss diese Anmeldung von einem
anderen PC oder zumindest mit einem anderen Browser erfolgen. Eine weitere Anmeldung durch denselben Browser invalidiert die erste Anmeldung.
15.1.3 Benutzerrollen
Ab dem Greenbone OS 3.1 können Sie mit dem Greenbone Security Assistant die Benutzerrollen selbst
neu anlegen und anpassen. Wie in allen anderen Fällen ist die Modifikation der eingebauten und ausgelieferten Rollen nicht möglich. Diese können jedoch kopiert (geklont) werden. Dieser Klon kann dann
modifiziert werden. Dies stellt ein konsistentes Verhalten bei Updates der Software sicher.
Sie erreichen die Rollenverwaltung über die Weboberfläche im Menü Administration im Unterpunkt
Roles. Die folgenden Rollen sind bereits im Auslieferungszustand verfügbar:
• Admin: Diese Rolle verfügt im Auslieferungszustand über sämtliche Privilegien. Sie darf insbesondere weitere Benutzer anlegen und verwalten.
• Guest: Diese Rolle entspricht der Info-Rolle. Sie darf lediglich ihre Einstellungen nicht modifizieren.
• Info: Diese Rolle (Information Browser) besitzt nur lesenden Zugri auf die NVTs und die SCAPInformationen. Alle weiteren Informationen sind nicht verfügbar.
• Monitor: Diese Rolle hat Zugri auf die Performance-Daten des GSM (siehe Abschnitt Überwachung und Fehlersuche (Seite 35)).
15.1. Benutzerverwaltung
173
• Observer: Diese Rolle besitzt nur lesenden Zugri auf das System. Sie darf keine eigenen Scans
erzeugen oder starten. Sie besitzt auch nur lesenden Zugri für die Scans für die die entsprechenden Benutzer als Observer eingerichtet worden sind.
• Super Admin: Diese Rolle hat Zugri auf alle Objekte von allen Benutzern. Sie hat keine Beziehung zum SuperUser auf der Kommandozeile. Diese Rolle kann nicht über die Weboberfläche
konfiguriert werden. Die Konfiguration ist nur im GOS-Admin-Menü möglich (siehe auch Abschnitt Super Admin (Seite 176)).
• User: Diese Rolle verfügt im Auslieferungszustand über sämtliche Privilegien mit der Ausnahme der Benutzer-, Rollen- und Gruppenverwaltung. Außerdem darf diese Rolle nicht die Feeds
verwalten und synchronisieren. In der Weboberfläche besteht kein Zugri auf den Menüpunkt
Administration. Alle weiteren Funktionen stehen dieser Rolle aber zur Verfügung
Weitere Rollen können einfach angelegt werden. Am einfachsten kopieren Sie eine der vorhandenen
Rollen, die Ihren Anforderungen am nächsten kommt und passen diese dann an. In seltenen Fällen
möchten Sie vielleicht eine Rolle erzeugen, die nur wenige Funktionen unterstützt. Dann ist es sinnvoller mit einer leeren Rolle zu beginnen.
Ein Benutzer kann auch mehrere Rollen besitzen. Daher können die Privilegien mit Hilfe der Rollen
auch gruppiert werden. Werden dann mehrere Rollen einem Benutzer zugewiesen, so addieren sich
die Privilegien.
Daher kann zum Beispiel eine Rolle Maintenance erzeugt werden. Diese Rolle erhält dann die folgenden Privilegien:
• authenticate
• get_settings
• write_settings
• help
• describe_cert
• describe_feed
• describe_scap
• sync_cert
• sync_feed
• sync_scap
Abb. 15.3: Die Rolle TaskAdmin gibt nur eingeschränkten Zugri
Weitere Rollen können dann den Namen TargetAdmin, ScanConfigAdmin, TaskAdmin und Scanner erhalten und mit entsprechenden Rechten ausgestattet werden. Wichtig ist die Tatsache, dass die Rol-
174
len alle mindestens die Privilegien authenticate und get_settings erhalten. Diese werden für die Anmeldung an der grafischen Weboberfläche zwingend benötigt. Sinnvoll ist dann auch noch das Privileg
write_settings. Dann kann der Benutzer sein eigenes Kennwort, die Zeitzone und weitere persönliche
Einstellungen ändern.
Den Benutzern können dann unterschiedliche Permutationen dieser Rollen zugewiesen werden. So
können bestimmte Benutzer anschließend die Zielsysteme, die Scankonfiguration oder den tatsächlichen Scan konfigurieren oder starten. In der Auswahl der Privilegien werden Ihnen nur die noch nicht
zugewiesenen Privilegien angezeigt. Dies erleichtert das Hinzufügen und den Überblick über die noch
verfügbaren Privilegien.
Meldet sich anschließend ein Benutzer mit der Rolle TaskAdmin an, so ist die Menüauswahl entsprechend eingeschränkt.
Abb. 15.4: Die Menüauswahl der Rolle TaskAdmin ist eingeschränkt.
15.1.4 Gastanmeldung
Der GSM kann für die Gastanmeldung konfiguriert werden. Als Gast verfügt der Benutzer nur die Möglichkeit auf das SecInfo-Management (siehe Abschnitt SecInfo Management (Seite 193)) zuzugreifen.
Damit kann ohne Kennwort ein einfacher Zugri auf die aktuellen Informationen geboten werden.
Um diesen Gastzugri zu erlauben, können Sie einen Benutzer erzeugen und diesem die Rolle Guest
zuweisen.
Dieser Benutzer kann sich nun bei Kenntnis des Kennworts anmelden und erhält das Dashboard.
Um die Gastanmeldung ohne Kennwort zu erlauben, muss diese Funktion zunächst auf der Kommandozeile aktiviert werden. Hierzu starten Sie das GOS-Admin-Menü und wählen die Option User. Anschließend aktivieren Sie die Option Guest login. Mögliche Werte sind disabled und enabled. Dann
geben Sie den Namen des Gastbenutzers und dessen Kennwort ein. Dies erfolgt in dem selben Menü
unter der Option Guest User. Diese Menüoption erscheint erst nach der Aktivierung des Gastzugri s.
Aktivieren Sie die Änderungen durch den Aufruf von Commit im Menü. Alternativ können Sie den Zugri
auch über die Einstellung guest_login aktivieren:
gsm: get guest_login
s guest_login disabled
gsm: set guest_login enabled
gsm: set guest_user guest
gsm: set guest_password guest
gsm *: commit
gsm: get guest_login
s guest_login enabled
Anschließend sollte ein Reboot erfolgen. Nun ist auf der Anmelde-Maske unten rechts das Login als
Gast verfügbar (siehe Abbildung Login als Gast-Benutzer ohne Kennwort. (Seite 177)).
175
Abb. 15.5: Die Rolle Gast hat Zugri auf das SecInfo Dashboard.
Abb. 15.6: Erzeugen Sie einen Gast-Benutzer.
15.1.5 Super Admin
Der Super Admin ist die höchste Zugri sstufe. Sie wurde mit dem neuen Berechtigungskonzept eingeführt. Die normale Rolle Admin ist vom Rechtemodell zunächst einem einfachen Benutzer gleichzusetzen. Dabei ist der Admin jedoch in der Lage, neue Benutzer zu erzeugen, zu modifizieren und
zu löschen. Des Weiteren kann der Admin sämtliche Rechte(Permissions) auf dem System einsehen,
modifizieren und löschen. Dennoch ist er auch diesen Rechten unterworfen. Wenn ein Benutzer eine private Scan-Konfiguration anlegt und diese nicht freigibt, kann der Admin die Scan-Konfiguration
nicht sehen. Natürlich könnte der Admin sich selbst ein entsprechendes Recht für die von dem Benutzer erzeugte Ressource geben.
Der Super Admin ist hiervon ausgenommen. Der Super Admin darf sämtliche Konfigurationseinstellungen aller Benutzer sehen und kann diese auch editieren.
Der Super Admin kann nicht in der Weboberfläche erzeugt werden. Um den Super Admin zu erzeugen
ist ein Zugri auf der Kommandozeile erforderlich. Hier können Sie im GOS-Admin-Menü im Punkt
User im Unterpunkt Add Super Admin diesen Benutzer mit Kennwort anlegen.
176
Abb. 15.7: Login als Gast-Benutzer ohne Kennwort.
Anschließend kann der Benutzer in der Weboberfläche editiert werden.
Abb. 15.8: Der Super Admin kann nicht in der Weboberfläche erzeugt werden!
Der Super Admin kann nicht durch den normalen Administrator verändert werden. Nur der Super Admin selbst kann die Einstellungen des Benutzers ändern!
Super Permissions
Sie können auch eine Rolle mit Super-Permissions ausstatten. Dann darf diese Rolle auf alle Objekte
einer Gruppe zugreifen.
Jede auf dem GSM angelegte Ressource (Scan Konfiguration, Target, etc.) ist entweder global oder
gehört einem bestimmten Benutzer. Globale Ressourcen sind an dem Icon zu erkennen. Jede nicht
globale Ressource darf zunächst nur von ihrem Besitzer gesehen und verwendet werden. Hier sind individuelle Berechtigungen erforderlich, um die Ressource anderen Anwendern zur Verfügung zu stellen. Dies ist recht aufwändig. Daher bietet das Greenbone OS 3.1 nun die Möglichkeit Super Permissions
zu verteilen. Ein Benutzer kann diese Super Permission erhalten für:
• Benutzer
• Rolle
• Gruppe
• Jeder
Diese Super Permissions erlauben dann den kompletten Zugri auf sämtliche Ressourcen des entsprechenden Benutzers, der Rolle, der Gruppe oder tatsächlich auf alle Ressourcen. Dabei kann der
177
Jeder-Zugri nicht explizit gesetzt werden. Dies ist ein Privileg des Super Admins (siehe Abschnitt
Super Admin (Seite 176)) . Diese letzte Super Permission kann daher nur durch das Erzeugen eines
Super Admins gesetzt werden.
Dabei kann ein Benutzer nur Super Berechtigungen für die Objekte setzen, die er selbst erzeugt hat.
Hierzu muss er zunächst die RessourceID des Benutzers, der Rolle oder der Gruppe ermitteln für die
er die Super Berechtigung setzen möchte.
Anschließend kann er dann die Werte im Dialog eintragen.
Abb. 15.9: Für die Super-Berechtigung benötigen Sie die Resource-ID
In der Erfolgsmeldung wird dann statt der Ressource ID der Klartextname angezeigt.
Abb. 15.10: Der Benutzer Ralf hat Super Zugri auf die Ressourcen des Benutzers Theo.
Die Super Berechtigungen vereinfachen die Rechteverwaltung auf dem GSM. So können leicht auch die
Super Berechtigungen für ganze Gruppen vergeben werden. Damit können alle Benutzer einer Gruppe
auf alle Ressourcen, die von weiteren Mitgliedern der Gruppe angelegt wurden, zugreifen.
GetUsers-Rolle für Observer
Die GSM erlaubt die Verwaltung von Observern (siehe Abschnitt Berechtigungen (Seite 65)). Dies sind
Benutzer, die Leserechte an bestimmten Tasks und deren Reports erhalten. Diese Observer können
per Default nur von Administratoren an den Tasks und Reports berechtigt werden. Normale Benutzer
können keine Observer an ihren eigenen Tasks berechtigen. Sie können ihre Tasks somit nicht für andere Benutzer freigeben. Bei ihnen ist der entsprechende Dialog zur Verwaltung der Berechtigungen
einen Tasks nicht funktionsfähig.
Abb. 15.11: Normale Benutzer können keine Observer einrichten.
Damit normale Benutzer ebenfalls ihre Tasks mit Leserechten für andere Benutzer ausstatten dürfen,
benötigen Sie das Privileg get_users für den Zugri auf die Benutzerdatenbank. Dieses Recht verwalten Sie am einfachsten über eine eigene Rolle. Erzeugen Sie hierzu eine Rolle GrantReadPriv (siehe
178
Abbildung Die Rolle GrantReadPriv erlaubt die Verwaltung der Leserechte. (Seite 179)). Dieser weisen
Sie in einem zweiten Schritt dann das Privileg zu. Damit erhält jeder Benutzer mit dieser zusätzlichen
Rolle das Recht, Leserechte an den eigenen Tasks zu vergeben.
Abb. 15.12: Die Rolle GrantReadPriv erlaubt die Verwaltung der Leserechte.
Dann müssen Sie nur noch den entsprechenden Benutzern diese Rolle zusätzlich zuweisen.
Bemerkung: Falls der Benutzer ebenfalls Leserechte an Gruppen oder Rollen vergeben darf, müssen
entsprechend die Berechtigungen get_groups und get_roles zugewiesen werden.
15.1.6 Gruppen
Neben den Rollen gibt es auch eine Gruppenverwaltung im Greenbone Security Assistant. Diese Gruppen dienen der logischen Gruppierung der Benutzer. Zusätzlich können über diese Gruppen aber auch
Berechtigungen zugewiesen werden (siehe Abschnitt Permissions (Seite 179)). Im Auslieferungszustand sind keine Gruppen eingerichtet. Sie können beliebig viele Gruppen erzeugen.
Hierbei müssen Sie die folgenden Informationen angeben:
• Name: Der Name der Gruppe darf maximal 80 Zeichen lang sein und aus Buchstaben und Zi ern
bestehen.
• Comment: Ein optionaler Kommentar beschreibt die Gruppe genauer.
• Users: Hier können Sie direkt die Mitglieder der Gruppe angeben. Dabei dürfen Sie die Mitglieder
durch Leerzeichen oder Kommas trennen. Die Länge der Angabe darf maximal 1000 Zeichen betragen. Alternativ können Sie die Gruppenmitgliedschaften direkt bei den Benutzern verwalten.
15.1.7 Permissions
Unter dem Menüpunkt Configuration/Permissions können Sie sämtliche auf dem System vergebenen Berechtigungen einsehen. Bei mehreren angelegten Rollen können das leicht mehrere Hundert
Berechtigungen sein. Jede einzelne hier angezeigte Berechtigung bezieht sich immer auf genau ein
Subject.
Ein Subject ist entweder
179
Abb. 15.13: Gruppen können für die Verwaltung von Rechten genutzt werden.
• ein Benutzer,
• eine Rolle
• oder eine Gruppe.
Üblicherweise werden die Berechtigungen durch die Weboberfläche über die Rollen (siehe Abschnitt
Benutzerrollen (Seite 173)) verwaltet. Dabei können Sie die Berechtigungen der Rollen sowohl in der
Rollenverwaltung als auch hier verwalten. Alternativ können Sie aber auch Berechtigungen direkt Benutzern oder Gruppen zuweisen.
Diese Möglichkeit bietet Ihnen die maximal mögliche Flexibilität in der Verwaltung der Berechtigungen. Jedoch empfiehlt sich das Hinzufügen und Verwalten der Berechtigungen über diesen Dialog nur
für erfahrene Benutzer, die zum Beispiel eine bestimmte Berechtigung suchen und für einen bestimmten Benutzer entfernen möchten.
Bemerkung: Auch bei den eingebauten Rollen ist eine Modifikation der Berechtigungen über diesen
Dialog möglich. Dies führt bei Updates möglicherweise zu unerwünschten E ekten, wenn die Berechtigungen wieder zurückgesetzt werden.
Freigabe einzelner Objekte für andere Benutzer
Jeder Benutzer kann beliebige Objekte, die er selbst erzeugt hat, freigeben. Dazu muss er jedoch über
das Privileg get_users verfügen. Ansonsten hat er nicht das Recht die Namen der anderen Benutzer
zu ermitteln (siehe Abschnitt GetUsers-Rolle für Observer (Seite 178)).
Um ein Objekt freizugeben, ermitteln Sie zunächst die Objekt-ID. Eine Freigabe über den Namen ist
nicht möglich. Hierzu zeigen Sie das Objekt, welches Sie freigeben möchten (z.B. einen Filter) im Browser an. Oben Rechts in der Anzeige können Sie die ID sehen und kopieren.
Abb. 15.14: Kopieren der ID des freizugebenden Objektes.
Anschließend wechseln Sie in das Menü Configuration/Permissions. Erzeugen Sie hier eine neue Berechtigung . Wählen Sie dann die richtige Berechtigung für das von Ihnen freizugebende Objekt aus:
• Filter: get_filters
• Scan-Konfiguration: get_configs
• Alert: get_alerts
• Notizen: get_notes
• Overrides: get_overrides
180
• Tags: get_tags
• Targets: get_targets
• Task mit Reports: get_tasks
• Schedules: get_schedules
Wählen Sie das passende Subjekt (User, Role oder Group) aus und fügen Sie die kopierte Ressource ID
in das entsprechende Feld.
Abb. 15.15: Kopieren der ID des freizugebenden Objektes.
15.1.8 Zentrale Benutzerverwaltung
Besonders in größeren Umgebungen mit vielen Benutzer ist die Kennwortverwaltung aufwändig. Das
Zurücksetzen oder Vergeben neuer Kennworte benötigt viel Zeit. Um dies zu vermeiden kann die GSM
Appliance einen zentralen Kennwortspeicher via LDAP nutzen. Der GSM nutzt das LDAP-Verzeichnis
jedoch nur für die Authentifzierung des einzelnen Benutzers. Das bedeutet, dass der Benutzer, der
sich via LDAP authentifizieren möchte, auch auf dem GSM angelegt werden muss. Anschließend kann
seine Authentifizierung an den Verzeichnisdienst angebunden werden.
Voraussetzung für die Nutzung der zentralen Authentifizierung ist die gleiche Benennung Ihrer Benutzer mit den Objekten im LDAP-Baum.
Im Folgenden wird die Verbindung zum LDAP-Baum betrachtet. Die GSM Appliance nutzt hier eine
sehr einfache Schnittstelle. Während die meisten Systeme mit LDAP-Anbindung zunächst den LDAPBaum nach einem passenden Objekt durchsuchen und sich anschließend als dieses Objekt anmelden
(Search & Bind) nutzt die GSM Appliance einen einfache Anmeldung (Bind) mit einem hartkodierten
Objektpfad.
Abb. 15.16: Die zentrale LDAP-Authentifizierung verlangt die Angabe des DNs
Dazu können Sie den distinguishedName der Objekte eindeutig definieren. Der Platzhalter %s ersetzt
dabei den Benutzernamen. Beispiele für den Auth. DN sind:
• uid=%s,ou=people,dc=domain,dc=de
181
• %[email protected]
• domain.de\%s
Während das erste Beispiel für beliebige LDAP Server bei Nutzung der passenden Attribute funktionieren sollte, verwenden das zweite und dritte Beispiel Formate, die nur von dem Active Directory
unterstützt werden. In den letzteren Fällen ist die exakte Position des Benutzerobjektes im Baum irrelevant.
Das erste Beispiel unterstützt nicht Benutzer in unterschiedlichen Ästen oder Tiefen eines LDAPBaums. Alle Anwender, die sich an dem GSM anmelden möchten, müssen sich in demselben Ast und
derselben Ebene des Baums befinden.
Die einzige weitere erforderliche Information ist der LDAP Host. Lediglich ein Rechner kann hier mit
seiner IP-Adresse oder DNS-Namen eingetragen werden.
Nachdem die LDAP-Authentifizierung aktiviert wurde, finden Sie eine neue Option “Nur LDAPAuthentifizierung erlauben” bei dem Anlegen neuer Benutzer. Diese ist per Default eingeschaltet und
sollte aktiviert sein, wenn ein Benutzer sich via LDAP authentifizieren soll. Die vorhandenen Benutzer
können im Nachgang entsprechend angepasst werden.
Bitte beachten Sie, dass der Benutzer mit dem Namen im LDAP-Verzeichnis existieren muss, bevor
sie ihn in dem GSM nutzen können. Der GSM wird keine Benutzer zum Verzeichnis hinzufügen, verändern oder entfernen. Außerdem werden keine Benutzer aus dem Verzeichnis automatisch in den
GSM übernommen. Sie müssen jeden Benutzer durch Anlage einzeln autorisieren und die Option “Nur
LDAP-Authentfizierung erlauben” einschalten.
Bitte beachten Sie auch, dass ein lokal angelegter Benutzer (ohne LDAP Authentifizierung) “Smith” auf
dem GSM Vorrang vor einem Benutzer “Smith” in dem Verzeichnisdienst hat.
Funktionstüchtig ist die LDAP-Authentifizierung jedoch erst nach einem Reboot. Dieser Reboot ist einmalig zwingend nach der Aktivierung der LDAP-Authentifizierung erforderlich.
Bemerkung: Die Kommunikation muss durch SSL/TLS geschützt werden. Unterstützt der LDAPServer dies nicht, so verweigert die GSM-Appliance die Zusammenarbeit. Details hierzu werden im
folgenden Abschnitt gegeben.
LDAP mit SSL/TLS
Die GSM Appliance nutzt entweder das Kommando StartTLS via LDAP auf dem Port 389 oder SSL via
LDAPS auf dem Port 636. Der LDAP-Server muss daher seine Dienste via SSL zur Verfügung stellen. Die
genaue Konfiguration aller verfügbarer LDAP-Server würde über die Möglichkeiten dieses Handbuchs
hinaus gehen. Daher werden im Folgenden nur einige allgemeine Hinweise gegeben:
• Microsoft:
http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-sslldaps-certificate.aspx
• OpenLDAP: http://www.openldap.org/doc/admin24/tls.html
Damit die GSM Appliance die Identität des LDAP-Servers überprüfen kann, muss sie seinem Zertifikat
vertrauen. Hierzu muss das Zertifikat der ausstellenden Zertifikatsautorität auf dem GSM gespeichert
werden. Hierzu exportieren Sie das Zertifikat der Zertifikatsautorität als BASE64-kodierte Datei. Dateien mit der Endung .pem weisen meist dieses Format auf. Die Datei selbst beginnt mit ------BEGIN
CERTIFICATE-------.
Der tatsächliche Speicherort des Zertifikats hängt stark von dem eingesetzten Produkt ab.
• Univention Corporate Server (UCS)
Hier können Sie das CA Zertifikat aus der Datei /etc/univention/ssl/ucsCA/CAcert.pem
extrahieren. Diese Datei enthält das Zertifikat bereits in dem richtigen Format. Es kann direkt an
das Kommando ldapcertdownload übergeben werden.
182
• Active Directory LDAP
Falls
Ihr
Active
Directory
LDAP
Dienst
noch
nicht
LDAPS
unterstützt,
finden
Sie
in
dem
folgenden
Artikel
weitere
Hinweise:
http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldapscertificate.aspx. Die Active Directory LDAP CA Zertifikate können dann mit den folgenden
Schritten aus der Zertifikatsautoritäts-Konsole exportiert werden.
– Ö nen Sie die Zertifikatsautoritätskonsole auf einem Rechner der Domäne.
– Wählen Sie mit einem Rechtsklick auf die Zertifikatsautorität deren Eigenschaften aus.
– In dem CA Zertifikate Dialog wählen Sie die Registerkarte Allgemein. Anschließend wählen
Sie das Zertifikat der Autorität, auf die sie zugreifen möchten.
– Wählen Sie “View Certificate”.
– Wählen Sie nun die Registerkarte Zertifikatsautorität. Wählen Sie den Namen der Wurzelautorität aus und wählen Sie “View Certificate”.
– In dem Zertifikate Dialog wählen Sie nun die Registerkarte Details und Kopieren diese in ein
Datei.
– Der Zertifikatsexportwizard erscheint. Wählen Sie Weiter.
– Auf der Export Dateiformat Seite wählen Sie das Base-64 enkodierte X.509 (.CER) Format
aus.
– Wählen Sie Weiter.
– Geben Sie den Pfad und Dateinamen des zu exportierenden Zertifikats an und wählen Sie
Weiter.
– Wählen Sie nun Abschliessen. Die .cer Datei wird an der angegeben Position erzeugt.
– Der folgende Dialog weist Sie auf den erfolgreichen Export hin. Wählen Sie OK um abzuschließen.
Der Inhalt der Datei kann nun direkt als Eingabe des Kommandos ldapcertdownload genutzt
werden.
Diese Datei müssen Sie nun auf Ihren GSM übertragen. Hierzu verbinden Sie sich am besten via SSH
(z.B. Putty) mit der Appliance. Ö nen Sie das Zertifikat in einem Editor und kopieren Sie es in die Zwischenablage. Rufen Sie auf der GSM-Kommandozeile den Befehl ldapcertdownload auf und fügen
Sie das Zertifikat ein. Schließen Sie den Kopiervorgang mit einem Enter und anschließend Strg-D ab.
Falls die LDAP-Authentifizierung nicht funktioniert, so prüfen Sie bitte, ob die Angabe bei dem LDAP
Host mit dem commonName des Zertifikats Ihres LDAP-Servers übereinstimmt. Kommt es hier zu Abweichungen, so verweigert die GSM-Appliance die Nutzung des LDAP-Servers.
183
184
KAPITEL 16
OpenVAS Management Protokoll (OMP)
Die gesamte Steuerung der GSM Appliance erfolgt über das OpenVAS Management Protocol (OMP).
Auch die Weboberfläche ist ein OMP-Client und greift via OMP auf die GSM-Funktionen zu.
Das
OMP
Protokoll
ist
auf
dem
http://docs.greenbone.net/API/OMP/omp.html
Greenbone
TechDoc
Portal
dokumentiert:
Dieses Kapitel beschreibt die Aktivierung und Nutzung des Protokolls durch Fremdanwendungen.
16.1 Aktivieren des OMP Protokolls
Um das OMP Protokoll zu nutzen, muss es zunächst auf der GSM Appliance aktiviert werden. Das WebInterface nutzt das OMP Protokoll lediglich lokal auf der Appliance und nicht über das Netzwerk. Die
Aktivierung des OMP Protokolls kann mithilfe einer Variable auf der Kommandozeile (siehe Abschnitt
OpenVAS Management Protocol (OMP) (Seite 33)) oder mithilfe des GOS-Admin-Menüs unter Remote
und anschließend OMP erfolgen. In beiden Fällen muss ein Reboot der Appliance erfolgen, um die
Einstellung zu aktivieren. Der Zugri auf das OMP Protokoll erfolgt grundsätzlich SSL-verschlüsselt
und -authentifiziert. Dabei werden dieselben Benutzer wie auf der Webschnittstelle genutzt. Diese
Benutzer unterliegen denselben Beschränkungen und verfügen auch über exakt dieselben Rechte.
16.2 Zugriff mit omp
Während Sie mit Hilfe der Dokumentation des OMP-Protokolls Ihre eigenen Applikationen für den Zugri entwickeln können, hat Greenbone auch für den einfachen Zugri eine Kommandozeilenapplikation entwickelt und auf der Webseite für Linux und Windows zur Verfügung gestellt.
• GNU/Linux: omp131
– SHA1 Prüfsumme: d6b554361180b4b059bb7dd4be510cf58dcad18b
– SHA256 Prüfsumme: 69d384088b8a84770e3ccfb81fe628d2cf12238e2fa9f2d320c7c4f6a615064b
• Microsoft Windows omp.exe132 (digital signiert durch Greenbone Networks GmbH)
Der Befehl ist statisch gelinkt und sollte auf den meisten Systemen direkt funktionieren. Greenbone
stellt auch alle Komponenten als Open Source Quelltext zur Verfügung, so dass Sie den Befehl für
weitere Systeme selbst übersetzen können:
• GNU/Linux: * openvas-libraries-8.0.5.tar.gz (0.6 MB)133 * openvas-cli-1.4.3.tar.gz (0.1 MB)134
• Microsoft Windows: omp-src-win.tar.gz (40 MB)135
131
http://greenbone.net/download/tools/omp
http://greenbone.net/download/tools/omp.exe
133 http://www.greenbone.net/download/sources/openvas-libraries-8.0.5.tar.gz
134 http://www.greenbone.net/download/sources/openvas-cli-1.4.3.tar.gz
135 http://www.greenbone.net/download/sources/omp-src-win.tar.gz
132
185
Das OMP-Protokoll basiert auf XML. Jedes Kommando und jede Antwort sind OMP Objekte.
Das von Greenbone Networks gelieferte Kommandozeilen-Werkzeug omp bietet zum einen das direkte Versenden und Empfangen von XML-Kommandos und XML-Antworten. Das ist vor allem für
den Batch-Betrieb (Stapelverarbeitung, Scripting) hilfreich. Zum anderen sind die wichtigsten
Kommandos als Kommandozeilenparameter einschließlich einer Option für eine menschenlesbare
Ausgabe verfügbar. Dies ist gedacht für spontane Abfragen, Tests und zur Ausarbeitung von BatchProzessen.
With this tool the OMP protocol can be used in a simple way:
omp
omp
omp
omp
--xml=<get_tasks/>
--get-tasks
--xml=<help/>
--help
Grundsätzlich bietet der Befehl omp zwei Modi. Mithilfe des --xml Schalters werden OMP Kommandos in XML Format gesendet. Die Antworten verwenden ebenfalls das XML Format. Mit dem Schalter
--pretty-print wird die Ausgabe menschenlesbar formatiert.
Einige Kommandos sind direkt auch als Schalter beim Aufruf verfügbar. Der Schalter --get-tasks
entspricht dem XML-Aufruf --xml=<get_tasks/>. Mit dem Schalter wird die Antwort nicht in XML
sondern als einfache Texttabelle formatiert.
16.2.1 Konfiguration des Clients
Um das omp Kommando zu nutzen, muss sich der Befehl an der Appliance anmelden. Die hierfür erforderlichen Informationen können mit den Schaltern --user, --password, --host und --port übergeben werden. Damit die Angabe nicht bei jedem Aufruf erforderlich ist, können die Informationen
auch in einer Datei omp.config im Heimatverzeichnis des aufrufenden Benutzers hinterlegt werden. Auf UNIXoiden Betriebssystemen handelt es sich dann um die Datei $(HOME)/omp.config. Auf
Windows Systemen speichern Sie die Datei in %USERPROFILE%omp.config. Erzeugen Sie die Datei
mit dem folgenden Inhalt (host, username und password müssen natürlich entsprechend angepasst
werden). Achten Sie auf die Groß- und Kleinschreibung. Wenn Sie das Kennwort nicht angeben, werden Sie bei dem Aufruf des Befehls danach gefragt.
[Connection]
host=gsm
port=9390
username=webadmin
password=password
16.2.2 Start eines Scans
Ein typisches Beispiel für die Nutzung des OMP-Protokolls ist ein automatischer Scan eines neuen
Systems. Im Folgenden gehen wir davon aus, dass Sie ein Intrusion Detection System betreiben, welches die Rechner in Ihrer DMZ überwacht und neue Systeme und ungewöhnliche bisher nicht genutzte TCP-Ports sofort erkennt. Falls nun ein derartiges Ereignis erkannt wird, soll das IDS automatisch
einen Scan des Systems initiieren. Dies soll mit Hilfe eines Skripts umgesetzt werden. Dazu eignet sich
der Befehl omp sehr gut.
Ausgangspunkt ist die IP-Adresse des neuen verdächtigen Systems. Für diese IP-Adresse muss zunächst ein Target im GSM erzeugt werden.
Für
diese
Funktion
existiert
kein
einfacher
Schalter
in
dem
omp
Befehl.
Daher
muss
hier
der
Aufruf
unter
Verwendung
von
XML
erfolgen.
Auf
http://docs.greenbone.net/API/OMP/omp6.0.html#command_create_target wird das Kommando create_target beschrieben.
Wenn die IP-Adresse in der Variablen $IPADDRESS gespeichert ist, kann mit dem folgenden Kommando das entsprechende Target angelegt werden:
186
Kapitel 16. OpenVAS Management Protokoll (OMP)
$ ./omp -X "<create_target><name>Suspect Host</name><hosts>$IPADDRESS</hosts>
</create_target>"
<create_target_response status="201" id="aa410e98-ff8d-45b6-be98-11fd7a895435"
status_text="OK, resource created"></create_target_response>
Nun kann die Aufgabe erzeugt werden. Mit dem Schalter -c geben Sie die Scankonfiguration an. Das
Ziel wird mit -t angegeben.
$ ./omp -C -c daba56c8-73ec-11df-a475-002264764cea --name "ScanSuspectHost" \
-t aa410e98-ff8d-45b6-be98-11fd7a895435
a4bdad7c-6135-45c1-884b-fd226a6e7a19
Der ausgegebene Rückgabewert ist die ID der erzeugten Aufgabe. Diese wird für den Start der Aufgabe
benötigt.
Die weiteren IDs, die bei dem Aufruf angegeben werden müssen, können mit den folgenden Kommandos, die die verfügbaren Ziele und Scankonfigurationen anzeigen, ausgelesen werden.
$ ./omp -T
b493b7a8-7489-11df-a3ec-002264764cea
aa410e98-ff8d-45b6-be98-11fd7a895435
Localhost
Suspect Host
$ ./omp -g
8715c877-47a0-438d-98a3-27c7a6ab2196
085569ce-73ed-11df-83c3-002264764cea
daba56c8-73ec-11df-a475-002264764cea
698f691e-7489-11df-9d8c-002264764cea
708f25c4-7489-11df-8094-002264764cea
74db13d6-7489-11df-91b9-002264764cea
2d3f051c-55ba-11e3-bf43-406186ea4fc5
bbca7412-a950-11e3-9109-406186ea4fc5
Discovery
empty
Full and fast
Full and fast ultimate
Full and very deep
Full and very deep ultimate
Host Discovery
System Discovery
Nun muss der Task nur noch gestartet werden:
$ ./omp -S a4bdad7c-6135-45c1-884b-fd226a6e7a19
58f7f696-5ec7-49f4-9968-1d35991f8f2e
Der ausgegebene Rückgabewert ist die ID des Reports. Nun muss bis zur vollständigen Abarbeitung
des Tasks gewartet werden. Der Status des Tasks kann mit dem folgenden Kommando angezeigt werden:
$ ./omp --get-tasks a4bdad7c-6135-45c1-884b-fd226a6e7a19
a4bdad7c-6135-45c1-884b-fd226a6e7a19 Running 20% ScanSuspectHost
58f7f696-5ec7-49f4-9968-1d35991f8f2e Running
0
0
1
2 2014-06-27T12:43:17Z
$ ./omp --get-tasks a4bdad7c-6135-45c1-884b-fd226a6e7a19
a4bdad7c-6135-45c1-884b-fd226a6e7a19
58f7f696-5ec7-49f4-9968-1d35991f8f2e
Done
Done
0
ScanSuspectHost
0
1
8 2014-06-27T12:43:17Z
Sobald der Scan abgeschlossen wurde, kann der Bericht geladen werden. Hierzu benötigen Sie die ID,
die ausgegeben wurde, als Sie die Aufgabe gestartet haben. Außerdem müssen Sie ein Berichtsformat
angeben. Die IDs der Berichtsformate können mit dem folgenden Befehl angezeigt werden:
$ ./omp --get-report-formats
910200ca-dc05-11e1-954f-406186ea4fc5
5ceff8ba-1f62-11e1-ab9f-406186ea4fc5
9087b18c-626c-11e3-8892-406186ea4fc5
c1645568-627a-11e3-a660-406186ea4fc5
35ba7077-dc85-42ef-87c9-b0eda7e903b6
ebbc7f34-8ae5-11e1-b07b-001f29eadec8
16.2. Zugriff mit omp
ARF
CPE
CSV
CSV
GSR
GXR
Hosts
Results
PDF
PDF
187
6c248850-1f62-11e1-b082-406186ea4fc5
77bd6c4a-1f62-11e1-abf0-406186ea4fc5
a684c02c-b531-11e1-bdc2-406186ea4fc5
9ca6fe72-1f62-11e1-9e7c-406186ea4fc5
c402cc3e-b531-11e1-9163-406186ea4fc5
9e5e5deb-879e-4ecc-8be6-a71cd0875cdd
a3810a62-1f62-11e1-9219-406186ea4fc5
a994b278-1f62-11e1-96ac-406186ea4fc5
HTML
ITG
LaTeX
NBE
PDF
Topology SVG
TXT
XML
Nun kann der Report geladen werden:
$ ./omp --get-report 58f7f696-5ec7-49f4-9968-1d35991f8f2e --format \
c1645568-627a-11e3-a660-406186ea4fc5 > report.csv
Für eine vollständig automatische Verarbeitung der Daten könnte der Task mit einem Alert verknüpft
werden, der bei einer bestimmten Bedrohungsstufe den Report automatisch versendet.
16.2.3 Aktualisieren Sie das Ziel einer änderbaren Aufgabe mit OMP
Das folgende Beispiel zeigt Ihnen, wie das Ziel einer veränderbaren Aufgabe mithilfe von OMP verändert werden kann. Dies könnte zum Beispiel eine von einem anderen Werkzeug generierte Liste sein.
Die folgenden Variablen werden in dem Beispiel verwendet:
• TASK_UUID Dies ist die UUID der Aufgabe deren Ziel Sie ändern möchten. Die Aufgabe muss als
änderbar gekennzeichnet sein.
• NEW_HOSTS Dies ist die Liste der Rechner, die als Ziel verwendet werden sollen.
• NEW_NAME Dies ist der Name des neuen Ziels.
UNIXoide Systeme
Die folgenden Beispiele verwenden das xmlstarlet Werkzeug um die XML Daten zu verarbeiten.
Dies kann natürlich durch alternative Lösungen ersetzt werden.
• Ermitteln Sie die UUID des alten Zielobjektes der Aufgabe:
$ OLD_TARGET_UUID=$(omp --xml "<get_tasks task_id=\"$TASK_UUID\"></get_tasks>" | \
xmlstarlet sel -t -v /get_tasks_response/task/target/@id)
• Erzeugen Sie ein neues Ziel indem Sie das alte Ziel klonen:
NEW_TARGET_UUID=$(omp --xml "<create_target><copy>$OLD_TARGET_UUID</copy> \
<name>$NEW_NAME</name></create_target>" | \
xmlstarlet sel -t -v /create_target_response/@id)
• Aktualisieren Sie das neue Ziel Objekt mit einer neuen Liste von Rechnern:
omp --xml "<modify_target target_id=\"$NEW_TARGET_UUID\"> \
<hosts>$NEW_HOSTS</hosts><exclude_hosts/></modify_target>"
• Ändern Sie die Aufgabe, so dass sie das neue Ziel nutzt:
omp --xml "<modify_task task_id=\"$TASK_UUID\"> \
<target id=\"$NEW_TARGET_UUID\"/></modify_task>"
• Entfernen Sie das nun ungenutzte alte Ziel:
omp --xml "<delete_target target_id=\"$OLD_TARGET_UUID\"/>"
188
Microsoft Windows Systeme
Das folgende Beispiel nutzt das “Select-XML” Kommando der Powershell um die XML Daten zu verarbeiten. Natürlich können Sie hier auch andere Lösungen nutzen.
• Ermitteln Sie die UUID des alten Zielobjektes der Aufgabe:
omp --xml "<get_tasks task_id=‛$TASK_UUID‛></get_tasks>" > get_tasks_response.xml
$OLD_TARGET_UUID = Select-Xml .\get_tasks_response.xml `
-xpath "/get_tasks_response/task/target[@id]" | ForEach-Object { $_.Node.id}
• Erzeugen Sie ein neues Ziel indem Sie das alte Ziel klonen:
omp --xml "<create_target><copy>$OLD_TARGET_UUID</copy>
<name>$NEW_NAME</name></create_target>" > create_target_response.xml
$NEW_TARGET_UUID = Select-Xml .\create_target_response.xml `
-xpath "/create_target_response[@id]" | ForEach-Object { $_.Node.id }
• Aktualisieren Sie das neue Ziel Objekt mit einer neuen Liste von Rechnern:
omp --xml "<modify_target target_id=‛$NEW_TARGET_UUID‛>
<hosts>$NEW_HOSTS</hosts><exclude_hosts/></modify_target>"
• Ändern Sie die Aufgabe, so dass sie das neue Ziel nutzt:
omp --xml "<modify_task task_id=‛$TASK_UUID‛>
<target id=‛$NEW_TARGET_UUID‛/></modify_task>"
• Entfernen Sie das nun ungenutzte alte Ziel:
omp --xml "<delete_target target_id=‛$OLD_TARGET_UUID‛/>"
16.2.4 Status Codes
Das OMP-Protokoll verwendet Status Codes für die Kommunikation. Diese Status Codes können auch
in der Weboberfläche angezeigt werden.
Abb. 16.1: Das OMP-Protokoll verwendet Status Codes und Nachrichten für die Statusübermittlung.
Die Status Codes ähneln den HTTP-Status Codes. Die folgenden Codes werden verwendet:
2xx: Das Kommando ist erfolgreich übertragen, verstanden und akzeptiert worden.
• 200: OK
• 201: Resource created
• 202: Request submitted
4xx: Es liegt ein Benutzerfehler vor.
400: Syntax-Fehler Hierbei kann es sich um verschiedene Syntaxfehler handeln. Meist fehlen
Elemente oder Attribute im OMP-Befehl. Der Statustext gibt weitere Informationen. Aktuell
wird dieser Status-Code auch noch bei fehlender oder falscher Authentifizierung genutzt.
401: Authenticate First Dies ist der Fehlercode, der bei einer fehlenden oder falschen Authentifizierung verwendet wird. Aktuell wird hier aber noch der Wert 400 verwendet.
16.2. Zugriff mit omp
189
403: Access to resource forbidden Dies ist der Fehlercode. der bei nicht ausreichenden Rechte
genutzt wird. Häufig wird stattdessen noch ”400 Permission denied” ausgegeben.
404: Resource missing Die Ressource konnte nicht gefunden werden. Die Ressource-ID war
leer oder falsch.
409: Resource busy Diese Fehlermeldung tritt zum Beispiel auf, wenn Sie eine FeedSynchronisation starten, während diese bereits läuft.
5xx: Es liegt ein Serverfehler vor.
500: Internal Error Dies können Eingaben sein, die interne Pu ergrößen überschreiten.
503: Scanner loading NVTs Der Sanner ist momentan damit beschäftigt NVTs in seinen Speicher zu laden. Probieren Sie es später wieder.
503: Service temporarily down Möglicherweise läuft der Scanner-Daemon nicht. Ein häufiges
Problem sind auch abgelaufene Zertifikate. Prüfen Sie die Readiness (siehe Abschnitt Bereitschaft (Seite 17)).
503: Service unavailable: Der OMP-Befehl ist auf dem GSM gesperrt.
190
KAPITEL 17
MySettings
Jeder Anwender der GSM Appliance kann seine eigenen Einstellungen für die Weboberfläche verwalten. Diese Einstellungen erhält er, indem er entweder Extras unter den Menüpunkt My Settings aufruft
oder seinen Login-Namen oben rechts anklickt.
Abb. 17.1: Jeder Benutzer kann seine eigenen Einstellungen verwalten.
Durch Wahl des Knopfes
sind:
kann der Benutzer diese Einstellungen verändern. Wichtige Einstellungen
Timezone: Intern speichert die GSM Appliance alle Informationen in der UTC-Zeitzone. Damit die Daten in der Zeitzone des Benutzers angezeigt werden, ist hier eine entsprechende Auswahl erforderlich.
Password: Hier kann ein Benutzer sein Kennwort ändern.
User Interface Language: Hier wird die Sprache definiert. Die Voreinstellung nutzt die Spracheinstellung des Browsers. Um immer eine englische oder deutsche Anzeige zu erhalten, nutzen Sie english oder german.
Rows Per Page: Dies ist die Zahl der angezeigten Ergebnisse in einer Liste.
Wizard Rows: Dies definiert, wie lange der Wizard angezeigt wird. Wird der Wert beispielsweise auf
3 gesetzt, so wird auf der Task-Übersicht der Wizard nicht mehr angezeigt sobald mindestens 4
Tasks vorhanden sind.
Details Export File Name: Diese Einstellung definiert den Default-Dateinamen der exportierten Objekte. Die Zeichenkette kann alphanumerische Zeichen, Binde- und Unterstriche und weitere
Platzhalter verwenden:
• %C Dies ist das Datum der Erstellung im Format YYYYMMDD. Es ist das aktuelle Datum, falls
ein Datum der Erstellung nicht verfügbar ist. Dies ist zum Beispiel bei Ressourcenlisten der
Fall.
• %c Der Zeitpunkt der Erzeugung im Format HHMMSS. Auch hier wird ähnlich %C der aktuelle Zeitpunkt verwendet.
• %D Das aktuelle Datum im Format YYYYMMDD.
191
• %F Der Name des verwendeten Berichtformats (XML für Listen und alles andere als Berichte).
• %M Das Datum der letzten Modifikation im Format YYYYMMDD. Falls ein Änderungsdatum
nicht verfügbar ist, ist dies entweder das Datum der Erstellung oder das aktuelle Datum,
wenn auch kein Datum der Erstellung verfügbar ist.
• %m Der Zeitpunkt der letzten Änderung im Format HHMMSS. Auch hier wird der Zeitpunkt
der Erstellung oder der aktuelle Zeitpunkt wie bei %M genutzt.
• %N Der Name der Ressource oder der Name der Aufgabe bei Berichten. Listen und Typen
ohne Name verwenden hier auch den Typen (siehe %T).
• %T Der Ressourcentyp, z.B. “Aufgabe”, “Port-Listen”. Mehrzahl für Listen.
• %t Die aktuelle Zeit im Format HHMMSS.
• %U die einzigartige ID der Ressource oder “Liste” für Listen mehrerer Ressourcen.
• %u Der Name des aktuell angemeldeten Benutzers.
• %% Das Prozentzeichen (%).
List Export File Name: Dies gibt den Default-Dateinamen der exportierten Listen an (siehe oben).
Port Export File Name: Dies gibt den Default-Dateinamen für exportierte Berichte an (siehe oben).
Severity Class: Hier können Sie die Einstufung der Schwachstellen entsprechend ihrem Score definieren.
• NVD Vulnerabiliy Severity Ratings
– 7.0 - 10.0: High
– 4.0 - 6.9: Medium
– 0.0 - 3.9: Low
• BSI Schwachstellenampel
– 7.0 - 10.0: Rot
– 4.0 - 6.9: Gelb
– 0.0 - 3.9: Grün
• OpenVAS klassisch
– 5.1 - 10.0: High
– 2.1 - 5.0: Medium
– 0.0 - 2.0: Low
• PCI-DSS
– 4.3 - 10.0: High
– 0.0 - 4.2: None
Filter: Hier können für jede Seite spezifische Default-Filter eingestellt werden, die bei dem Aufruf der
Seite automatisch aktiviert werden.
192
Kapitel 17. MySettings
KAPITEL 18
SecInfo Management
Das SecInfo Management bietet einen zentralen Zugri
Sicherheit. Hierzu gehören die folgenden Informationen:
auf verschiedene Informationen zur IT-
NVTs: Dies sind die Network Vulnerability Tests. Diese Tests prüfen das Zielsystem auf mögliche
Schwachstellen.
CVEs: Die Common Vulnerability and Exposures sind die von Herstellern und Sicherheitsforschern
verö entlichten Schwachstellen.
CPEs: Die Common Platform Enumeration stellt eine standardisierte Benennung der in der Informationstechnologie verwendeten Produkte dar.
OVAL Definition: Die Open Vulnerability Assessement Language stellt eine standardisierte Sprache
für die Prüfung von Schwachstellen bereit. Die OVAL Definitions nutzen diese Sprache um konkrete Schwachstellen zu erkennen.
CERT-Bund Advisories: Die CERT-Bund Advisories werden von dem Computer-Notfallteam emergency response team136 des Bundesamts für Sicherheit in der Informationstechnik (BSI) veröffentlicht. Die maßgebliche Aufgabe des CERT-Bund ist der Betrieb eines Warn- und Informationsdienstes, der Informationen zu neuen Schwachstellen und Sicherheitslücken sowie aktuellen Bedrohungen für IT-Systeme publiziert.
DFN-CERT Advisories: Das DFN-CERT DFN-CERT137 ist das Computer-Notfallteam des Deutschen
Forschungsnetzwerks (DFN).
Die CVEs, CPEs und OVAL-Definitionen werden von dem NIST im Rahmen der National Vulnerability Database (NVD) bereitgestellt (siehe auch Abschnitt Security Content Automation Protocol (SCAP) (Seite 195)).
Um einen schnellen Überblick über diese Informationen zu erhalten, existiert ein Secinfo Dashboard
(siehe Abbildung Das index:SecInfo Dashboard erlaubt die grafische Aufbereitung der SCAP-Daten.
(Seite 194)). Dieses erlaubt die grafische Darstellung der verschiedenen Informationen gruppiert nach
unterschiedlichen Aspekten.
18.1 Secinfo Portal
Die SecInfo Daten werden von Greenbone Networks auch online bereitgestellt. Auf dieses Portal138
können Sie direkt über das Internet zugreifen. Es entspricht den Daten, die Sie auch in Ihrer GSM darstellen können. Das SecInfo Portal ist ein GSM ONE der speziell für einen anonymen Gast-Zugang konfiguriert ist. Gegenüber einem vollwertigen GSM sind lediglich das SecInfo Management und der CVSS
Online-Rechner für den Gast freigeschaltet.
Das SecInfo Portal von Greenbone erfüllt eine Reihe von Aufgaben:
136
https://www.cert-bund.de/
https://www.cert.dfn.de/
138 https://secinfo.greenbone.net
137
193
Abb. 18.1: Das index:SecInfo Dashboard erlaubt die grafische Aufbereitung der SCAP-Daten.
• Anonymer Zugang zu Details der Greenbone Schwachstellenprüfungen sowie von SCAP-Daten
(CVE, CPE, OVAL) und Meldungen verschiedener CERTs. Die Daten sind in sich referenziert und
bieten dadurch die Möglichkeit, durch die Sicherheits-Information zu einem Produkt, einem Hersteller oder einer bestimmten Schwachstelle zu browsen.
• Demo für die jeweils kommende Version von Greenbone OS sobald der SecInfo Abschnitt den
Beta-Status erreicht hat.
• Service für eingebettete Digramme wie es beispielsweise von der Greenbone Website zur Feed
Statistik verwendet wird.
• Service für direkte Verweise zu Details oder speziellen Selektionen wie beispielsweise für eine
spezielle CVE (CVE-2014-0160, Heartbleed) oder eine Übersicht: Alle 2013 verö entlichten CVE
Meldungen.
• Service für Verweise zu CVSS Schwachstellenbewertung inklusive CVSS Online-Rechner:
AV:N/AC:L/Au:N/C:P/I:P/A:P
• Beispiel wie man einen eigenen GSM für ein Intranet konfigurieren kann, um direkte Verweise in
internen Berichten und Plattformen zu ermöglichen.
Sie können einen derartigen Zugang auch selbst durch die Aktivierung des Gast-Zugangs (siehe Abschnitt Gastanmeldung (Seite 175)) bereitstellen.
194
Kapitel 18. SecInfo Management
18.2 Network Vulnerability Tests
Die Abkürzung steht für Network Vulnerability Test. Dies sind die Prüfroutinen, die der GSM verwendet
und die über den Greenbone Security Feed regelmäßig aktualisiert werden. Hier finden Sie Informationen, wann die Prüfroutine entwickelt wurde, welche Systeme betro en sind, welche Auswirkungen
die Schwachstelle haben kann und wie Sie diese beheben.
Verglichen mit dem Greenbone OS 3.0 sind zwei neue Informationen enthalten: die Art der Lösung
(siehe Solution Type (Seite 271)) und die Qualität der Erkennung (QdE, siehe Quality of Detection (QoD)
(Seite 269)).
Mit der Einführung des QdE wurde der Parameter Paranoid in der Scan-Konfiguration (siehe Kapitel
Scan-Konfiguration (Seite 151)) ersatzlos gestrichen. In der Vergangheit hat eine Scan-Konfiguration
ohne diesen Parameter nur die NVTs mit einem QdE von mindestens 70% genutzt. Nur bei Angabe
des Parameters wurden tatsächlich alle NVTs eingesetzt. Nun werden immer alle NVTs in einem Scan
ausgeführt. Sie können die Ergebnisse jedoch basierend auf dem QdE filtern. Auf diese Weise sind
immer alle Ergebnisse in der Datenbank vorhanden und können dargestellt oder unterdrückt werden.
18.3 Security Content Automation Protocol (SCAP)
Das National Institute of Standards and Technology (NIST) der USA stellt die National Vulnerability
Database (NVD)139 bereit. Die NVD ist ein Datenrepository für das Schwachstellenmanagement der
US-Regierung. Ziel ist die standardisierte Bereitstellung der Daten für die automatische Verarbeitung
und Unterstützung bei Aufgaben des Schwachstellenmanagements, der Sicherheitsbewertung und
der Umsetzung von Compliance Richtlinien. Die NVD stellt verschiedenste Datenbanken bereit. Diese
enthalten
• Checklisten,
• Schwachstellen,
• Konfigurationfehler,
• Produkte und
• Bedrohungsmetriken.
Dabei nutzt die NVD das Security Content Automation Protocol (SCAP)140 . Das Security Content Automation Protcol ist eine Kombination verschiedener interoperabler Standards. Dabei wurden viele Standards durch ö entliche Diskussion gewonnen oder abgeleitet. Die ö entliche Beteiligung der
Community in der Weiterentwicklung ist ein wichtiger Aspekt für die Akzeptanz und die Verbreitung
des SCAP-Standards. Das SCAP-Protokoll ist aktuell in der Version 1.2 spezifiziert und umfasst die folgenden Komponenten:
• Sprachen
– XCCDF: The Extensible Configuration Checklist Description Format
– OVAL: Open Vulnerability and Assessment Language
– OCIL: Open Checklist Interactive Language
– Asset Identification
– ARF: Asset Reporting Format
• Sammlungen
– CCE: Common Configuration Enumeration
– CPE: Common Platform Enumeration
139
140
https://nvd.nist.gov/
http://scap.nist.gov/
18.2. Network Vulnerability Tests
195
– CVE: Common Vulnerabilities and Exposure
• Metriken
– CVSS: Common Vulnerability Scoring System
– CCSS: Common Configuration Scoring System
• Integrität
– TMSAD: Trust Model for Security Automation Data
OVAL, CCE, CPE und CVE sind Warenzeichen des NIST.
Der Greenbone Schwachstellenscanner nutzt den OVAL Standard, CVE, CPE und CVSS. Durch die Nutzung dieser Standards ist eine Interoperabilität des System mit anderen Produkten gewährleistet.
Diese Standards erlauben auch den Vergleich der Ergebnisse.
Schwachstellenscanner wie der Greenbone Security Manager können durch das NIST geprüft und validiert werden. Der Greenbone Security Manager wurde entsprechend der SCAP Version 1.0141 validiert.
Im Folgenden werden die von dem Greenbone Security Manager genutzten Standards detaillierter
besprochen.
18.3.1 CVE
Da es in der Vergangenheit häufig mehrere Organisationen gab, die gleichzeitig eine Schwachstelle
erkannt und gemeldet haben und dabei der Schwachstelle unterschiedliche Namen und Kennungen
zugewiesen haben, war eine Kommunikation und ein Vergleich der Ergebnisse nicht einfach. Unterschiedliche Scanner haben dieselbe Schwachstelle mit unterschiedlichen Namen gemeldet. Tatsächlich handelte es sich aber statt um zwei verschiedene Schwachstellen um ein und dieselbe Schwachstelle.
Das MITRE 143 hat 1999 das CVE Projekt, gesponsert durch das US-CERT, gegründet, um Abhilfe zu
scha en. Jede Schwachstelle erhält eine eindeutige Kennung bestehend aus der Jahreszahl und einer
einfachen Nummer. Diese Nummer dient dann als zentrale Referenz.
Die CVE Datenbank des Mitre ist keine Schwachstellendatenbank. CVE ist entwickelt worden, damit
Schwachstellendatenbank und andere Systeme untereinander verknüpft werden können. Dies erlaubt den Vergleich von Sicherheitswerkzeugen und Dienstleistungen. Die CVE Datenbank enthält
daher keine Angaben zur Gefährdung, Auswirkungen oder Behebung der Schwachstelle. Detaillierte technische Informationen sind ebenfalls nicht enthalten. Ein CVE enthält lediglich die Identifizierungsnummer mit Status, eine kurze Beschreibung und Referenzen auf Berichte und Advisories.
Die National Vulnerability Database (NVD) bezieht die CVE Datenbank vom Mitre und ergänzt diese um
Informationen zur Behebung der Schwachstelle, dem Schweregrad, betro ene Produkte und möglichen Auswirkungen. Der Greenbone bezieht die CVE-Datenbank von der NVD, so dass diese Informationen enthalten sind. Gleichzeitig verknüpft der GSM die Informationen mit den NVTs und den CERTBund und DFN-CERT Advisories.
Diese Informationen können komfortabel über die Weboberfläche angezeigt werden.
18.3.2 CPE
Die Abkürzung CPE steht für Common Platform Enumeration und wurde als Industriestandard für eine
einheitliche Namenskonvention informationstechnischer Systeme, Plattformen und Softwarepakete
nach dem Vorbild des CVE ebenfalls durch das Mitre ins Leben gerufen. Hiermit besteht eine einheitliche Namensgebung für Betriebssysteme und Applikationen, die eine globale Referenzierung ermöglicht.
141
https://nvd.nist.gov/scapproducts.cfm
Die MITRE (Massachusetts Institute of Technology Research & Engineering) Corporation ist eine Organisation zum Betrieb
von Forschungsinstituten im Auftrag der Vereinigten Staaten, die durch Abspaltung vom Massachusetts Institute of Technology
(MIT) entstanden ist.
143
196
Abb. 18.2: Die CVEs enthalten Informationen über Schweregrad und betro ene Produkte.
Ursprünglich wurde der Common Platform Enumeration Standard (CPE) von dem MITRE initiiert. Heute wird der CPE Standard jedoch von dem US-amerikanischen National Institute for Standards and
Technology (NIST) im Rahmen der National Vulnerability Database (NVD) gepflegt. Das NIST hatte bereits das ozielle CPE-Dictionary und die CPE Spezifikationen für mehrere Jahre gepflegt. CPE ist ein
strukturiertes Benennungsschema für Applikationen, Betriebssysteme und Hardwaregeräte. Es basiert auf der generischen Syntax der Uniform Resource Identifier (URI).
Da der CPE-Standard eng mit dem CVE-Standard verknüpft ist, erlauben diese Standards in ihrer
Kombination bei Erkennung einer Plattform oder eines Produkts den Rückschluss auf vorhandene
Schwachstellen.
CPE besteht aus den folgenden Komponenten:
Naming: Die Namensspezifikation beschreibt die logische Struktur der Well-formend Names (WFNs),
ihrer Bindung an URIs und formatierte Zeichenketten und die Konvertierung der WFNs und ihrer
Bindungen.
Name Matching: Die Name Matching Spezifikation beschreibt die Methoden für den Vergleich der
WFNs untereinander. Dies erlaubt die Prüfung, ob einige oder alle sich auf das gleiche Produkt
beziehen.
Dictionary: Das Dictionary ist ein Repositorium der CPE Namen und Metadaten. Jeder Name kennzeichnet eine einzelne Klasse eines IT-Produkts. Die Dictionary Spezifikation beschreibt die Prozesse für die Verwendung des Dictionaries, wie die Suche nach einem bestimmten Namen oder
der Suche nach Einträgen, die zu einer allgemeineren Klasse gehören.
18.3. Security Content Automation Protocol (SCAP)
197
Abb. 18.3: Common Product Enumeration: Name Structure
Applicability Language: Die Applicability Language Spezifikation beschreibt die Erzeugung komplexer logischer Ausdrücke mit Hilfe der WFNs. Diese Applicability Statements können für das Markieren (Tagging) von Checklisten, Richtlinien oder anderer Dokumente genutzt werden und so
beschreiben auf welche Produkte diese Dokumente anzuwenden sind.
18.3.3 OVAL
Die Open Vulnerability and Assessment Language ist ebenfalls ein Projekt des Mitre. Hierbei handelt
es sich um eine Sprache, um Schwachstellen (Vulnerability), Konfigurationseinstellungen (Compliance), Patches(Patch) und Programme (Inventory) zu beschreiben. Die in XML gehaltenen Definitionen
erlauben eine einfache Verarbeitung durch automatische Systeme. So beschreibt die OVAL Definition oval:org.mitre.oval:def:22127 aus der Inventory-Klasse die Installation des Adobe Flash
Player 12 während die Oval-Definition oval:org.mitre.oval:def:22272 eine Verwundbarkeit
des Google Chrome Browsers unter Windows beschreibt.
Diese OVAL Definitionen werden in XML bereitgestellt und beschreiben die Erkennung einzelner Systeme und Schwachstellen die oben erwähnte OVAL Definition 22272 hat folgende Struktur:
<definition id="oval:org.mitre.oval:def:22272" version="4" class="vulnerability">
<metadata>
<title>Vulnerability in Google Chrome before 32.0.1700.76 on Windows allows
attackers to trigger a sync with an arbitrary Google account by
leveraging improper handling of the closing of an untrusted signin
confirm dialog</title>
<affected family="windows">
<platform>Microsoft Windows 2000</platform>
<platform>Microsoft Windows XP</platform>
<platform>Microsoft Windows Server 2003</platform>
<platform>Microsoft Windows Server 2008 R2</platform>
<platform>Microsoft Windows Vista</platform>
<platform>Microsoft Windows 8.1</platform>
198
Abb. 18.4: OVAL beschreibt die Erkennung von Schwachstellen
<platform>Microsoft Windows Server 2012 R2</platform>
<product>Google Chrome</product>
</affected>
<reference source="CVE" ref_id="CVE-2013-6643"
ref_url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6643"/>
<description>The OneClickSigninBubbleView::WindowClosing function in
browser/ui/views/sync/one_click_signin_bubble_view.cc in Google
Chrome before 32.0.1700.76 on Windows and before 32.0.1700.77 on Mac
OS X and Linux allows attackers to trigger a sync with an arbitrary
Google account by leveraging improper handling of the closing of an
untrusted signin confirm dialog.</description>
<oval_repository>
<dates>
<submitted date="2014-02-03T12:56:06">
<contributor organization="ALTX-SOFT">Maria Kedovskaya</contributor>
</submitted>
<status_change date="2014-02-04T12:25:48.757-05:00">DRAFT</status_change>
<status_change date="2014-02-24T04:03:01.652-05:00">INTERIM</status_change>
<status_change date="2014-03-17T04:00:17.615-04:00">ACCEPTED</status_change>
</dates>
<status>ACCEPTED</status>
</oval_repository>
</metadata>
<criteria>
<extend_definition comment="Google Chrome is installed"
definition_ref="oval:org.mitre.oval:def:11914"/>
<criteria operator="AND" comment="Affected versions of Google Chrome">
<criterion comment="Check if the version of Google Chrome is greater than
or equals to 32.0.1651.2" test_ref="oval:org.mitre.oval:tst:100272"/>
<criterion comment="Check if the version of Google Chrome is less than
199
or equals to
</criteria>
</criteria>
</definition>
32.0.1700.75" test_ref="oval:org.mitre.oval:tst:99783"/>
Diese Informationen werden von der Weboberfläche grafisch aufbereitet und leicht lesbar dargestellt
(siehe Abbildung OVAL beschreibt die Erkennung von Schwachstellen (Seite 199)).
18.3.4 CVSS
Ein großes Problem für den normalen Administrator ist die Deutung der Schwachstellen in seiner
persönlichen Umgebung. Wie kritisch muss er eine Schwachstelle einstufen? Um hier den Personen,
die sich nicht ununterbrochen mit der Analyse und Bewertung von Schwachstellen beschäftigen, zu
unterstützen, wurde das Common Vulnerability Scoring System (CVSS) erfunden. CVSS ist ein Industriestandard zur Beschreibung des Schweregrades von Sicherheitslücken in Computer-Systemen. Im
CVSS werden Sicherheitslücken nach verschiedenen Kriterien bewertet und miteinander verglichen.
So kann eine Prioritätenliste für Gegenmaßnahmen erstellt werden kann.
Der CVSS Score wird regelmäßig weiterentwickelt. Aktuell wird üblicherweise der CVSS-Score in der
Version 2 verwendet. Die Version 3 wird jedoch von der CVSS Special Interest Group (CVSS-SIG) des
Forum of Incident Response and Security Teams (FIRST)142 entwickelt.
Abb. 18.5: Der CVSS Rechner erlaubt angenehm die Berechnung des Scores.
Der CVSS Score in der Version 2 unterstützt Base Score Metrics, Temporal Score Metrics und Environmental Score Metrics.
Die Base Score Metrics prüfen allgemein die Ausnutzbarkeit einer Schwachstelle und deren Auswirkung auf das Zielsystem. Hierbei bewerten Sie den Zugang, die Komplexität und die Erfordernis einer
Authentifizierung. Gleichzeitig bewerten sie, ob die Vertraulichkeit, die Integrität oder Verfügbarkeit
bedroht wird.
Die Temporal Score Metrics prüfen, ob bereits fertiger Beispiel-Code existiert, der Hersteller bereits
einen Patch bereitstellt und die Sicherheitslücke bestätigt wurde. Dieser Score ändert sich daher im
Laufe der Zeit sehr stark.
Die Environmental Score Metrics betrachten, ob ein Kollateralschaden zu befürchten ist und die Zielverteilung der Schwachstelle. Des weiteren prüfen diese Metriken, ob die Vertraulichkeit, Integrität
und Verfügbarkeit erforderlich ist. Diese Beurteilung ist stark von der Umgebung, in der das verwundbare Produkt eingesetzt wird, abhängig.
142
https://www.first.org/cvss
200
Da lediglich die Base Score Metriken sinnvoll allgemeingültig und dauerhaft bestimmt werden können,
stellt der GSM diese im Rahmen der SecInfo-Daten zur Verfügung.
Hierbei wird folgende Formel verwendet, die auch mit dem CVSS-Rechner des GSMs berechnet werden
kann (Extras/CVSS-Calculator, siehe Abbildung Der CVSS Rechner erlaubt angenehm die Berechnung
des Scores. (Seite 200)).
𝐵𝑎𝑠𝑒𝑆𝑐𝑜𝑟𝑒 = 𝑟𝑜𝑢𝑛𝑑𝑇 𝑜1𝐷𝑒𝑐𝑖𝑚𝑎𝑙(((0.6 * 𝐼𝑚𝑝𝑎𝑐𝑡) + (0.4 * 𝐸𝑥𝑝𝑙𝑜𝑖𝑡𝑎𝑏𝑖𝑙𝑖𝑡𝑦) − 1.5) * 𝑓 (𝐼𝑚𝑝𝑎𝑐𝑡))
Hierbei wird der Impact folgendermaßen berechnet:
𝐼𝑚𝑝𝑎𝑐𝑡 = 10.41 * (1 − (1 − 𝐶𝑜𝑛𝑓 𝐼𝑚𝑝𝑎𝑐𝑡) * (1 − 𝐼𝑛𝑡𝑒𝑔𝐼𝑚𝑝𝑎𝑐𝑡) * (1 − 𝐴𝑣𝑎𝑖𝑙𝐼𝑚𝑝𝑎𝑐𝑡))
Die Exploitability wird berechnet als:
𝐸𝑥𝑝𝑙𝑜𝑖𝑡𝑎𝑏𝑖𝑙𝑖𝑡𝑦 = 20 * 𝐴𝑐𝑐𝑒𝑠𝑠𝑉 𝑒𝑐𝑡𝑜𝑟 * 𝐴𝑐𝑐𝑒𝑠𝑠𝐶𝑜𝑚𝑝𝑙𝑒𝑥𝑖𝑡𝑦 * 𝐴𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑖𝑜𝑛
Die Funktion 𝑓 (𝐼𝑚𝑝𝑎𝑐𝑡) ist 0, wenn der Impact 0 ist. In allen anderen Fällen ist der Wert 1.176. Die
weiteren Werte sind Konstanten:
• Access Vector
– Lokaler Zugri erforderlich: 0.395
– Naher Netzwerkzugang erforderlich: 0.646
– Netzwerkzugang ausreichend: 1.0
• Access Complexity:
– Hohe Zugangkomplexität: 0.35
– Mittlere Zugangkomplexität: 0.61
– Niedrige Zugangskomplexität: 0.71
• Authentication
– Mehrfache Authentifizierung erforderlich: 0.45
– Einmalige Authentifizierung erforderlich: 0.56
– Keine Authentifizierung erforderlich: 0.704
• ConfImpact:
– Kein Bruch der Vertraulichkeit: 0.0
– Teilweiser Bruch der Vertraulichkeit: 0.275
– Kompletter Bruch der Vertraulichkeit: 0.660
• IntegImpact
• AvailImpact
201
18.4 DFN-CERT
Während die einzelnen NVTs, CVEs, CPEs und OVAL Definitionen in erster Linie zur Verarbeitung durch
Computersysteme erzeugt werden, verö entlicht das DFN-CERT, wie viele andere Computer Emergency Report Teams (CERTs) weltweit, regelmäßig neue Warnungen (Advisories). Das DFN-CERT ist
verantwortlich für mehrere Hundert Universitäten und Forschungseinrichtungen, die am deutschen
Forschungsnetz ( DFN) angeschlossen sind. Ein Advisory beschreibt besonders kritische Sicherheitslücken, die eine schnelle Reaktion verlangen. Auch diese werden von dem GSM bezogen und in der
internen Datenbank zur Referenzierung gespeichert. Sie können diese aber auch direkt anzeigen.
18.5 CERT-Bund
CERT-Bund bietet einen Warn- und Informationsdienst (WID) an. Dieser Dienst stellt aktuell zwei
verschiedene Arten von Informationen zur Verfügung (Zitat von der Webseite https://www.certbund.de):
Advisories: Dieses Informationsangebot steht derzeit nur Bundesbehörden als geschlossene Liste
zur Verfügung! In den Advisories sind aktuelle Informationen zu sicherheitskritischen Vorfällen
in Computersystemen und Maßnahmen zur Behebung von Sicherheitslücken in ausführlicher
Form beschrieben.
Kurzinformationen Kurzinformationen zeichnen sich dadurch aus, dass aktuelle Informationen zu
Sicherheitslücken und Schwachstellen in IT-Systemen kurz und knapp beschrieben werden. Beachten Sie bitte, dass die Informationen teilweise nicht verifiziert sind und daher unter Umständen unvollständig oder auch fehlerhaft sein können.
Der Greenbone Security Feed enthält die CERT-Bund Kurzinformationen. Diese können auch an dem K
in der Meldung erkannt werden (CB-K14/1296).
202
KAPITEL 19
Asset Management
Alle Ergebnisse sämtlicher Scans kann der GSM im Asset-Management speichern. Bei der Definition
eines Tasks können Sie entscheiden, ob die Ergebnisse des Scans in das Asset Management aufgenommen werden sollen (siehe Abschnitt Anlegen des Tasks (Seite 63)).
In der Übersicht sehen Sie zunächst alle in der Asset Datenbank gespeicherten Systeme.
Abb. 19.1: Die Asset-Datenbank zeigt die gespeicherten Systeme.
Hier sehen Sie, wieviele Sicherheitslücken aktuell auf dem System gefunden wurden. Außerdem zeigt
die Übersicht das Betriebssystem mit einem Logo (Spalte OS) und die erkannten Ports und Applikationen an. Außerdem wird angezeigt, wie ein Scan des Systems in diesem Moment wahrscheinlich
ausfallen würde (Spalte Prognosis, siehe auch Abschnitt Prognose (Seite 204)). Über das
können
Sie auch jetzt einen prognostischen Bericht erzeugen lassen. Über das Asset Management haben Sie
immer auch Zugri auf den letzten Report des Hosts. Sie sehen das Datum des Reports und können
diesen direkt durch Anklicken des Links aufrufen. Wenn mehrere Berichte existieren, können Sie in den
Host-Details auch auf ältere Reports zugreifen. Durch Anklicken der Host-IP-Adresse erhalten Sie die
Host Details. Hier sehen Sie die Anzahl der gefundenen Schwachstellen, das erkannte Betriebssystem,
die vorgefundenen Ports und die Anzahl der erkannten Applikationen auf dem Zielsystem.
Die Host-Details enthalten weitere Informationen über den Rechner:
Hardware: Hier speichert der GSM Informationen über die Hardware. Wenn bekannt, ist hier zum Beispiel die MAC-Adresse aufgeführt. Diese kann aber nur angezeigt werden, wenn sich das Zielsystem in demselben LAN wie der GSM befindet.
Detected Applications: Besonders interessant sind die erkannten Applikationen. Hiermit kann der
Greenbone Security Manager ohne einen erneuten Scan basierend auf den Informationen seiner
SecInfo-Datenbank eine Prognose abgeben, ob er weitere Sicherheitslücken finden würde. Dies
ist insbesondere bei Systemen interessant, die aktuell über keine Schwachstellen verfügen und
für die Sie nicht regelmäßig neue Scans durchführen wollen.
203
19.1 Prognose
Die Prognose erlaubt, ohne einen erneuten Scan, basierend auf den aktuellsten Informationen zu bekannten Sicherheitslücken aus dem SecInfo Management (SCAP, Security Content Automation Protocol) Angaben über mögliche Sicherheitslücken zu machen (siehe auch Abschnitt SecInfo Management (Seite 193)). Dies ist insbesondere interessant in einer Umgebung in der Sie mit Hilfe des GSM die
meisten Schwachstellen entfernt und behoben haben. Natürlich werden täglich neue Schwachstellen bekannt. Nicht jede Schwachstelle rechtfertigt aber einen neuen Scan des Netzes oder einzelner
Rechner. Da aber der GSM diese Informationen erhält, kann er, das Wissen um die installierten Applikationen zugrundelegend, prognostizieren, welche Sicherheitslücken vorhanden sind. Werden Sicherheitslücken bekannt, ist die tatsächliche Durchführung eines Scan gerechtfertigt, um diese Prognose
zu überprüfen. Hierzu benötigt die Asset-Datenbank natürlich aktuelle Daten. Ein Scan der Systeme
sollte daher in regelmäßigen wöchentlichen oder monatlichen Abständen erfolgen.
Sie können auch einen prognostischen Scan durchführen lassen. Dieser ermittelt dann die wahrscheinlich vorhandenen Schwachstellen.
204
Kapitel 19. Asset Management
KAPITEL 20
Performanz
Beim Einsatz des Greenbone Security Managers können zum einen erhebliche Datenmengen von den
Zielsystemen ermittelt werden. Zum anderen werden auch die vorliegende Scan-Ergebnisse auf dem
GSM analysiert, gefiltert oder aufbereitet. Auf größeren GSM Modellen findet das auch in der Regel
gleichzeitig und durch viele Anwender oder Automatismen statt.
Dieses Kapitel widmet sich diversen Fragen der Performanz und zeigt Möglichkeiten zur Optimierung
auf.
20.1 Scan Performanz
Die Geschwindigkeit eines Scans ist von vielen Parametern abhängig. Dieser Abschnitt weist auf die
wichtigsten Einstellungen hin und gibt einige Empfehlungen.
20.1.1 Wahl der Port-Liste für einen Scan
Welche Port-Liste für ein Ziel und damit für die Aufgabe und die Scans konfiguriert wird hat eine weitreichende Bedeutung, zum einen für die Erkennungsleistung und zum anderen bzgl. Scan-Dauer.
Zwischen diesen beiden Aspekten gilt es bei der Planung der Schwachstellenprüfungen abzuwägen.
Über Ports
Ports sind die Verbindungspunkte einer Netzwerkkommunikation, wobei sich jeweils der Port des
einen Rechners mit einem Port auf einem anderen Rechner verbindet.
Jeder Rechner verfügt über 65535 TCP-Ports und 65535 UDP-Ports. Streng genommen gibt es einen
mehr, nämlich den speziellen Port 0. Bei Verbindungen zwischen TCP-Ports findet eine Datenübertragung in beide Richtungen statt, bei UDP nur in eine Richtung. Da bei UDP empfangene Daten nicht
unbedingt bestätigt werden, sind die Prüfungen für UDP-Ports in der Regel langsamer.
Hervorzuheben sind die Ports 0 bis 1023, die als sogenannte privilegierte oder System-Ports gelten
und üblicherweise nicht durch Anwender-Programme geö net werden können.
Bei der IANA (Internet Assigned Numbers Authority) können für Standard-Protokolle Ports reserviert
werden, die dann mit einem Protokollnamen versehen sind wie beispielsweise Port 80 für http oder
Port 443 für https.
Bei IANA sind über 5000 Ports registriert. Es ist jedoch einer Software durchaus möglich einen dieser
Ports für beliebige andere Zwecke zu verwenden, sofern er auf dem jeweiligen System noch nicht
verwendet wird.
Aus Analysen, bei denen sämtliche Ports sämtlicher Internet-zugängiger Rechner geprüft wurden,
sind Listen für die am häufigsten verwendeten Ports entstanden. Diese spiegeln nicht unbedingt die
205
IANA-Liste wieder, denn es existiert keine Verpflichtung dort einen Dienst-Typ für einen bestimmten
Port zu registrieren.
Typischerweise sind bei Desktop-Rechnern weniger Ports o en als bei Servern. Aktive NetzwerkKomponenten wie Router, Drucker und IP-Telefone haben in der Regel nur einige wenige Ports o en,
nämlich nur die, die für ihre eigentliche Aufgabe und für deren Wartung erforderlich sind.
Welche Port-Liste für welche Scan-Aufgabe
Die Wahl der Port-Liste ist immer eine Abwägung zwischen Erkennungsleistung und Scan-Dauer.
Die Dauer des Port-Scans wird vor allem durch die Anzahl der zu prüfenden Ports und durch NetzwerkKonfigurationen bestimmt. So kann es beispielsweise ab einer bestimmten Anzahl geprüfter Ports zu
einer Ausbremsung seitens Netzwerk-Elementen oder seitens des geprüften Systems kommen.
Bei der Erkennungsleistung ist es o ensichtlich, dass Dienste, die an nicht in der Liste enthalten Ports
gebunden sind, auch nicht auf Schwachstellen geprüft werden. Ebenso werden auch Schadprogramme, die sich an solche Ports gebunden haben, natürlich nicht erkannt. Zumeist ö nen die Schadprogramme Ports, die üblicherweise nicht verwendet werden und weit jenseits der System-Ports liegen.
Ein weiteres Kriterium sind Abwehreinrichtungen, die bei bestimmten, zumeist umfangreichen, PortPrüfungen aktiviert werden und Gegenmaßnahmen oder einen Alarm einleiten. Schon bei normalen
Port-Scans könnten Firewalls vortäuschen, dass alle 65535 Ports aktiv sind und verlangsamen so den
eigentlichen Scan dieser Ports, die dann ins Leere laufen, also in sogenannte “Timeouts”.
Zu beachten ist auch, dass bei jedem Port, der angefragt wird, der Dienst dahinter häufig mit einem
Log-Eintrag reagiert. Einige Dienste sollen möglicherweise aus organisatorischen Gründen nicht oder
nur zu vereinbarten Zeiten angesprochen werden.
Die folgende Tabelle gibt Anhaltspunkte, welche Port-Listen für welche Aufgabenstellung sinnvoll
sein könnten.
Aufgabe/Fragestellung
Anfangsverdacht, Penetrationstest, Hochsicherheit, Erst-Scan unbekannter Systeme in
geringer Zahl
Hintergrundprüfung einer Umgebung mit bekannter bzw. definierter Umgebung (Server) in
großer Zahl oder in hoher Frequenz
Erst-Scan unbekannter Systeme in großer Zahl
oder in hoher Frequenz
Port-Liste
• All TCP und All UDP
• SpezifischeListe für die bekannten Dienste
• All IANA TCP
• All IANA TCP
• Nmap Top 1000 TCP und Top 100 UDP
Die letztendliche Abwägung muss durch den Verantwortlichen für die Scans erfolgen. Es sollte mindestens eine Dokumentation der Ziele bzw. Fragestellungen der Scans hierbei erfolgen, um die Wahl
der Port-Liste zu begründen.
Auf der einen Seite kann auf Nummer sicher gehen, also immer sämtliche Ports scannen, zur NichtErfüllung der eigentlichen Aufgabe führen, weil schlichtweg nicht alle Systeme in der verfügbaren Zeit
geprüft werden können oder aber weil eine Störung im Betriebsablauf erzeugt wird.
Auf der anderen Seite kann superschnell, also einfach nur alle privilegierten TCP-Ports, für unbekannte Systeme mit hohem Sicherheitsbedarf als ungeeignet erscheinen, wenn später ein Schadensfall
durch eine eigentlich leicht aundbare Schwachstelle festgestellt wird. Beispiele dafür sind Datenbankdienste.
Zu beachten ist auch, dass einige Systeme keine feste Port-Zuordnung verwenden, sondern diese sogar im laufenden Betrieb ständig ändern. Das erschwert natürlich das Port-Profiling für eine spezifische Port-Liste.
206
Kapitel 20. Performanz
Scan-Dauer
Sämtliche TCP- und UDP-Ports zu prüfen kann in Situationen mit Scan-Ausbremsung durchaus 24
Stunden und mehr für einen einzelnen Rechner bedeuten. Da die Scans parallel ausgeführt werden,
dauern zwei Rechner natürlich nur unwesentlich länger als ein einzelner Rechner. Jedoch hat die Parallelisierung auf Grund der System-Ressourcen bzw. Netzwerk-Leistung auch ihre Grenzen.
Sämtliche IANA TCP-Ports hingegen benötigen in der Regel nicht mehr als wenige Minuten.
Da einige Abwehrmechanismen die Scan-Dauer erhöhen können, besteht auch die Möglichkeit, auf
der Seite der Abwehrsysteme durch Konfigurationsanpassung eine Ausbremsung zu verhindern.
Insgesamt lernt man letztlich die zu scannenden Netzbereiche und wie diese auf die Scans reagieren
mit der Zeit kennen, und kann seine Routineaufgaben darauf hin optimieren.
Bei Verdachtsfällen einer Kompromittierung oder höchsten Sicherheitsansprüchen bleibt ein vollumfänglicher Scan natürlich unerlässlich.
Totale Sicherheit
Auch bei den Port-Scans gilt natürlich der Grundsatz, dass es keine totale Sicherheit gibt. Dies bedeutet, auch wenn All TCP und All UDP verwendet wurde, so kann der voreingestellte Timeout der
Port-Prüfung zu kurz sein um ein sich versteckendes Schad-Programme zu einer Antwort zu verleiten.
Oder es kommt gerade durch die große Anzahl Ports zur Abwehr durch die Infrastruktur. Weniger kann
also sogar gelegentlich mehr bedeuten.
Liegt ein Anfangsverdacht vor, so sollte auf einen erfahrenen Penetrationstester zurückgegri en
werden, der die eigentlichen Scan-Tools mit Erfahrung und berufsbedingtem Gespür ergänzt sowie
die Fein-Parametrisierung für die Scans beherrscht.
20.1.2 Scan-Konfiguration
Auch die Scan-Konfiguration hat eine Auswirkung auf die Dauer des Scans. Der GSM bietet für den
Schwachstellenscan vier verschiedene Scan-Konfigurationen:
• Full and fast
• Full and fast ultimate
• Full and very deep
• Full and very deep ultimate
Die beiden Scan-Konfigurationen Full and fast und Full and fast ultimate optimieren ihren Ablauf mit Hilfe der bereits gewonnenen Informationen. Dadurch können viele NVTs optimiert
werden und müssen im Zweifelsfall nicht geprüft werden. Die beiden anderen Scan-Konfigurationen
ignorieren die bereits gewonnenen Informationen und führen daher alle NVTs aus. Hierzu gehören
auch diejenigen NVTs, die auf Grund vorher gewonnener Informationen nicht sinnvoll sind.
20.1.3 Tasks
Bei dem Ablauf des Scans wird ein Fortschrittsbalken erzeugt. Dieser Fortschrittsbalken soll den prozentualen Ablauf des Scans widerspiegeln. In den meisten Fällen handelt es sich hierbei nur um eine
grobe Schätzung, denn wie sich die noch nicht gescannten Systeme oder Dienste im Vergleich zu den
bisher gescannten Systemen und Diensten verhalten, ist für dem GSM schwer vorhersagbar.
Dies kann an einem Beispiel am besten verstanden werden. Gegeben sei ein Netz 192.168.0.0/24 mit 5
Hosts: 192.168.0.250-254. Sie konfigurieren einen Scan dieses Netzes. Der Scan erfolgt sequentiell. Da
zu Beginn des Netzes die IP-Adressen nicht genutzt werden, läuft der Scan sehr schnell und erreicht
95%. Dann jedoch werden Systeme erkannt, die über viele Dienste verfügen. Der Scan ist entsprechend langsamer, da alle diese Dienste geprüft werden müssen. Der Fortschrittsbalken macht nun
20.1. Scan Performanz
207
nur noch geringe Sprünge. Um dieses Verhalten anzupassen, kann im Scanner-Dialog die Order for
target hosts angepasst werden. Sinnvoll ist hier die Einstellung Random.
20.2 Backend Performanz
Das Webinterface greift mit Hilfe des OMP-Protokolls auf den GSM zu. Einige Operationen benötigen
hier mehr Zeit als andere. Um eine Analyse und Untersuchung der Geschwindigkeit des OMP-Backends
zu ermöglichen, zeigt jede Webseite die von ihr benötigte Zeit zur Aufbereitung der Daten unten auf
der Webseite an.
Abb. 20.1: Die Verarbeitungszeiten des Backends werden angezeigt.
20.3 Appliance Performanz
Die Gesamt-Performanz des GSM kann durch die integrierte Überwachung kontrolliert werden. Unter
Extras stellt der GSM eine eigene Performance-Überwachung zur Verfügung. Hier kann die Ressourcennutzung der GSM für die letzte Stunde, Tag, Woche, Monat und Jahr angezeigt werden. Dabei kann
der Bericht auch für einen Slave angezeigt werden.
Abb. 20.2: Die Verarbeitungszeiten des Backends werden angezeigt.
Hierbei sind die folgenden Punkte wichtig:
Prozesse Eine hohe Zahl Prozesse ist nicht kritisch. Es sollten jedoch in erster Regel nur schlafende
(Sleeping) und laufende (Running) Prozesse angezeigt werden.
System Load Eine dauerhaft hohe Last ist kritisch. Dabei gilt eine Last von 4 auf einem System mit 4
Kernen als OK.
208
CPU Usage Hier ist besonders ein hoher Wait-IO kritisch.
Memory Usage Der GSM nutzt aggressives Caching. Die Nutzung des größten Teils des Arbeitsspeichers als Cache ist in Ordnung.
Swap Eine Nutzung des Swap-Speichers zeigt auf eine potentielle Überlastung des Systems hin.
20.3. Appliance Performanz
209
210
KAPITEL 21
Master und Slave Setups
Der Greenbone Security Manager erlaubt den Aufbau von verteilten Scan-Systemen. Hierbei ist es
möglich, dass ein GSM einen anderen GSM zum Zwecke eines Scans fernsteuert.
Dabei wird der steuernde GSM als Master und der gesteuerte GSM als Slave bezeichnet. Sobald zwei
GSM als Master und Slave konfiguriert wurden, kann ein Anwender einen Scan für den Scan-Slave in
der Weboberfläche des Scan-Master je nach Bedarf und Berechtigung individuell konfigurieren. Jeder
GSM ab der Midrange-Klasse aufwärts kann als Scan-Master genutzt werden und einen oder mehr
Scan-Slaves steuern. Jeder GSM kann als Scan-Slave arbeiten.
Die Scan-Slaves sind eigenständige GSM. Daher muss der Administrator die Feed-Updates und
Release-Updates auch auf den Slaves lokal konfigurieren und deren Ausführung sicherstellen. Ein
Scan-Slave verfügt weiterhin über eine eigene grafische Oberfläche und eigene Verwaltung. Er kann
daher auch lokal komplett eigenständig genutzt werden, obwohl einige Scans von einem Scan-Master
ausgeführt werden.
Zusätzlich kann der Slave als Sensor konfiguriert werden. Ein Scan-Sensor ist ein GSM der ausschließlich für die Funktion als Scan-Slave gedacht ist und außerdem vollständig durch einen zugeordneten Master verwaltet wird. Diese Verwaltung beinhaltet sowohl die automatische Aktualisierung des
Feeds als auch automatische Release-Updates. Ein Sensor benötigt keinerlei Netzwerk-Verbindungen
außer zu seinem Sensor-Master und nach der Ersteinrichtung keinerlei administrative Tätigkeiten
Scan-Sensoren wie -Slaves können in einem Scan-Master integriert werden, um auch die NetzwerkSegmente auf Schwachstellen zu prüfen, die auf anderen Wegen nicht erreichbar sind.
Grundsätzlich baut der Master die Verbindung zu den abgesetzten Scan-Slaves auf. Die Verbindung
erfolgt dabei über das OpenVAS Management Protocol (OMP), das den TCP Port 9390 benutzt. Für die
Feed- und Release-Updates auf einem Scan-Sensor ist zusätzlich der Port 22/tcp (SSH) nötig.
Abb. 21.1: Aufrufen eines Tasks auf dem Slave
211
21.1 Anbindung eines Slaves
Wie bei jedem anderen GSM auch erfolgt die Grundkonfiguration des Scan Slaves über die serielle
Schnittstelle. Neben den Netzwerkeinstellungen und dem Administrator Zugang sind zwei zusätzliche Grundparameter für die Nutzung als Slave erforderlich:
• Setzen eines Scan-Administrators auf dem Slave, mit dem der Master den Scan-Slave steuern
kann. Dieser wird auf dem Slave im GOS-Admin-Menü unter User und dann Add Web Admin gesetzt.
• Aktivieren des Remote OMP Features. Dies kann in dem GOS-Admin-Menü unter Remote
und OMP gesetzt werden. Alternativ kann es direkt auf der Kommandozeile mit der Variable
public_omp gesetzt werden:
set public_omp enabled
Beachten Sie: Das Aktivieren des Remote OMP Features erfordert einen Reboot des Scan Slaves.
Auf dem Master kann anschließend der Slave eingerichtet werden und ein Task auf den Slave übertragen werden:
21.2 Sensor
Häufig ist aus Sicherheitsgründen das Scannen eines Netzwerksegments nicht direkt möglich. Meist
ist dann auch der direkte Zugri aus diesem Segment auf das Internet unerwünscht. Damit ein Scan
Sensor auch in diesen Fällen über aktuelle NVTs verfügt, ist es möglich, den Greenbone Security Feed
vom Master auf den Scan Sensor zu übertragen und so eine Feed-Synchronisation mit dem Sensor
zu ermöglichen. Dies erfolgt nach der Einrichtung automatisch. Sobald der Master sich mit dem Feed
Server synchronisiert hat, überträgt er die Informationen auch auf den Sensor.
Hierzu nutzt der Master das SSH-Protokoll. Die folgenden Schritte erlauben dem Master die passwortlose Anmeldung auf dem Sensor via SSH für die Übertragung dieser Informationen.
Abb. 21.2: Aktivieren des SSH-Zugangs.
Zunächst muss der ö entliche SSH-Key des Masters (Masterkey) auf den Sensor übertragen werden.
Dann kann der Master automatisch die SSH-Verbindung zum Sensor aufbauen.
Hierzu zeigen Sie auf dem Master der Schlüssel an. Dafür verwenden Sie das Kommando show
masterkey. Den angezeigten Schlüssel kopieren Sie in die Zwischenablage.
gsm-master> show masterkey
ssh-dss AAAAB3 .... root@gsm
Anschließend verbinden Sie sich auf den Sensor und geben hier auf der Kommandozeile das Kommando masterkeydownload ein. Dann kopieren Sie den Schlüssel aus der Zwischenablage auf die
Kommandozeile und schließen die Eingabe mit CTRL-D ab.
212
Kapitel 21. Master und Slave Setups
gsm-sensor> masterkeydownload
Please paste the master key into the CLI , END with CTRL -D
gsm-sensor> show sensormasterkey
Anschließend ist es insbesondere bei Verwendung eines USB/Seriell-Adapter empfehlenswert den
Schlüssel zu verifizieren. Viele USB/Seriell-Adapter übertragen einzelne Zeichen fehlerhaft. Auf älteren GOS-Versionen (< 3.0.20) wird hierfür das Kommando showmasterkey genutzt.
Zusätzlich muss der Administrator auf dem Sensor den SSH-Zugangs aktivieren. Dies kann entweder
über die Variable ssh oder über das GOS-Admin-Menü erfolgen.
Abb. 21.3: Der Feed des Sensors wird vom Master übertragen
Damit der Sensor nicht mehr versucht den Feed direkt zu beziehen, muss diese Funktion deaktiviert
werden. Diese Einstellung findet der Administrator im GOS-Admin-Menü Feed unter Automatic Sync.
Zusätzlich müssen der Administrator in diesem Menü die Aktualisierung des Feeds durch den Master
aktivieren (Feed from Master). Zum Abschluss müssen diese Einstellungen durch ein Commit bestätigt werden.
Abb. 21.4: Eintragen der Sensoren auf dem Master
Da der Master die Verbindungen zu den Sensoren aufbaut, müssen die Sensoren noch in die Verwaltung des Masters aufgenommen werden. Diese Funktion finden Sie auf dem Master im GOS-AdminMenü unter Sensors. Aktivieren Sie hier die Funktion Automatic Sensor Sync. Anschließend fügen Sie
die IP-Adresse des Sensors zur Sensorliste (Sensors) hinzu. Hierbei handelt es sich um eine Liste von
IP-Adressen, die mit Leerzeichen separiert wurden.
Mit dem Sensor-Check kann die Erreichbarkeit der Sensoren geprüft werden.
21.2.1 Manuelle Synchronisation
Mithilfe des GOS-Admin-Menüs kann auch eine manuelle Synchronisation des NVT-Feeds angestossen werden. Dieser manuelle Schritt ist jedoch nur erforderlich, falls die automatische Synchronisa-
21.2. Sensor
213
Abb. 21.5: Bei dem Sensorcheck prüft der GSM die Erreichbarkeit.
tion nicht aktiviert wurde. Sowohl der Feed als auch die GOS-updates werden dann zu den Sensoren
übertragen. Die GOS-Updates werden hierbei nur übertragen aber nicht automatisch installiert.
Verwenden Sie Sensors/Synchronize sensors um die Synchronisation zu starten.
Während der Synchronisation sind die Menü-Optionen Synchronize sensors und Upgrade sensors
nicht verfügbar.
21.2.2 Aktualisieren der Sensoren
Nachdem die manuelle Synchronisation abgeschlossen ist, können die Sensoren auch aktualisiert
werden. Dies erfolgt über den Menüpunkt Sensors/Upgrade sensors.
21.2.3 Kommunikation der Sensoren
Die Slaves/Sensoren kommunizieren über zwei Protokolle: OMP (Slaves und Sensoren) und SSH (nur
Sensor). Diese Protokolle müssen durch die möglicherweise vorhandenen Firewall-Systeme zugelassen werden. Dabei baut immer der Master die Verbindung zum Slave/Sensor auf.
Das Feed Update der abgesetzten Scan Sensoren erfolgt wahlweise entweder direkt von den Greenbone Update Servern oder über den Master. Für Updates vom Master zum Scan Sensor wird SSH (TCP
Port 22) benutzt. Wenn dieses Feature nicht benutzt wird, ist darauf zu achten, dass eine gegebenenfalls zwischen Master und Scan Sensor platzierte Firewall die Verbindungen nicht ohne Rückmeldung
blockiert (Einstellung Drop oder Deny). Statt dessen sollte der Verbindungsaufbau zugelassen (Accept oder Permit) oder mit Rückmeldung verhindert (Reject) werden, da der Master immer versucht,
die Feed Updates auf den Scan Sensor zu übertragen.
214
Kapitel 21. Master und Slave Setups
KAPITEL 22
Integration mit anderen Systemen
Die Greenbone GSM Appliance kann mit anderen Systemen verknüpft werden. Dieses Kapitel betrachtet die verschiedenen Möglichkeiten. Greenbone Networks hat bereits die Kommunikation der GSM
mit einzelnen anderen Produkten dritter Hersteller ermöglicht. Hierzu zählen das verinice ITSM System, das Sourcefire IPS Defense Center und das Nagios Monitoring System. Die folgenden Abschnitte
zeigen die Möglichkeiten und die erforderlichen Schritte zur Konfiguration auf. Die Integration einiger
weiterer Produkte wie Palo Alto werden in dem Kapitel Scanner (Seite 159) beschrieben.
22.1 Integration von Drittherstellern
Die GSM verfügt über eine Vielzahl von Schnittstellen, die eine Kommunikation mit Produkten von Drittherstellern ermöglichen. Dieser Abschnitt zeigt die Möglichkeiten für eine Integration und Kopplung
mit anderen Systemen auf.
Die GSM bietet hierzu die folgenden Schnittstellen:
OpenVAS Management Protokoll (OMP) Das OpenVAS Management Protokoll erlaubt die komplette
Fernsteuerung der GSM Appliance. Das Protokoll unterstützt das Anlegen von Benutzern, Erzeugen und Starten von Scan-Tasks, Beziehen von Reports, etc.
Anbindung weiterer Scanner über OSP Das OpenVAS Scanner Protocol (OSP) ist eine standardisierte Schnittstelle für beliebige Schwachstellenscanner. Mit dieser Schnittstelle können weitere
Scanner nahtlos in das GSM Schwachstellenmanagement integriert werden. Die Steuerung der
Scanner und die Auswertung der Ergebnisse erfolgt für alle Scanner in der gleichen Art und Weise.
Report Format Die GSM kann die Scan-Ergebnisse in einem beliebigen Format präsentieren. Dazu
bringt die GSM bereits eine Reihe vorinstallierter Report Formats mit. Weitere Report-Formats
können von Greenbone bezogen oder in Zusammenarbeit mit Greenbone erstellt werden. Eine
digitale Signatur des Plugins seitens Greenbone ist notwendig um es auf dem GSM ausführen zu
können.
Alerts via Syslog, E-Mail, SNMP-Trap oder HTTP
Automatische Ergebnisweiterleitung über Konnektoren Diese Konnektoren werden von Greenbone erstellt, geprüft und auf dem GSM integriert.
Überwachung via SNMP Die Webseite http://docs.greenbone.net/API/SNMP/snmp-gos-3.1.en.html
hält die aktuelle MIB (Management Information Base) Datei vor. MIB Dateien beschreiben die
Objekte, die via SNMP ausgelesen werden können.
22.1.1 OSP Scanner
Das OpenVAS Scanner Protokoll ähnelt dem OpenVAS Management Protokoll (OMP, siehe Kapitel
OpenVAS Management Protokoll (OMP) (Seite 185)). Es ist XML-basiert, zustandslos und erfordert kei-
215
ne dauerhafte Kommunikationsverbindung. Sein Design erlaubt die nahtlose Unterstützung weiterer
Scanner durch den GSM.
Der GSM bringt bereits einige OSP Scanner in seiner Werkseinstellung mit (siehe Kapitel Scanner (Seite 159).)
Das o ene Format erlaubt die Entwicklung beliebiger eigener OSP Scanner. Greenbone stellt hierzu
sowohl die Protokolldokumentation als auch ein grundlegendes Gerüst für Programmierer bereit (siehe Kapitel OpenVAS Scanner Protokoll (Seite 231)).
22.2 Verinice
Verinice (see http://verinice.org/en/) ist ein freies OpenSource Information Security Management
System (ISMS), welches durch das Unternehmen SerNet (see http://sernet.de/en/) entwickelt wird.
Abb. 22.1: Der GSM kann mit verinice Daten austauschen.
Verinice eignet sich für:
• Vulnerability Remediation Workflow
• zur Umsetzung der BSI IT-Baseline Kataloge
• zum Durchführen einer Risko Analyse nach ISO 27005
• für den Betrieb eines ISMS nach ISO 27001
• für das Durchführen eines IS-Assessments nach VDA Vorgaben
• für den Nachweis von Compliance mit Standards wie ISO 27002, IDW PS 330
Der Greenbone Security Manager kann sowohl bei der Modellierung und Umsetzung von BSI ITGrundschutz als auch bei dem Betrieb eines ISMS unterstützen.
Hierzu stellt Greenbone für den Export der Daten aus dem GSM in verinice zwei Report-Plugins zur
Verfügung:
• Verinice-ISM mit sämtlichen Scan-Ergebnissen
• Verinice-ITG mit Scan-Ergebnissen eines BSI IT-Grundschutz Scans
216
Kapitel 22. Integration mit anderen Systemen
Es besteht die Möglichkeit der vollautomatischen Übertragung der Daten vom Greenbone Security
Manager an verinice.PRO, der Server-Erweiterung von verinice.
Im Folgenden betrachten wir den manuellen Import der Berichte aus dem GSM in die freie verinice
Version. Für Unterstützung bei der Anwendung des Connector wenden Sie sich bitte an SerNET oder
Greenbone.
22.2.1 IT Security Management
Das Report-Plugin für verinice ist vorkonfiguriert im GSM verfügbar als Verinice-ISM.
Mit diesem Berichtsformat unterstützt Greenbone den Vulnerability Remediation Workflow in verinice.
Hierbei spielen die Notizen (Notes-Objekte, siehe Kapitel Notizen (Seite 85)) der Scan-Ergebnisse
für das Verinice-ISM Plugin eine zentrale Rolle. Über die Notizen werden in verinice Objekte zu
Schwachstellen für die Bearbeitung angelegt. Gibt es zu einem Scan-Task keine Notizen, so werden
lediglich die Assets übernommen sowie der Gesamt Schwachstellen-Bericht. Ausschließlich solche
Schwachstellen die mit einer Notiz versehen sind werden in verinice auch als Schwachstelle übernommen. Damit können Sie den Import feingranular steuern.
Bemerkung: Warum werden nur dann Schwachstellen übertragen, wenn sie über eine Notiz verfügen?
Während des gesamten Prozesses zur Bearbeitung der Schwachstellen sollte es nur einen einzigen
Zeitpunkt geben, wo die Entscheidung gefällt wird, ob eine Schwachstelle behoben werden muss oder
toleriert werden kann. Diese Entscheidung muss im Rahmen des Vulnerability Managements fallen
indem die Schwachstellen entsprechend markiert werden.
Das Ziel des Remediation Workflows ist die Lösung der vorher festgelegten Probleme. Innerhalb des
Remediation Workflows darf nicht mehr die Entscheidung fallen, ob ein Problem toleriert werden darf.
Anschließend müssen Sie Ihren Bericht als Verinice ISM-Report speichern. Sie erhalten eine
.vna Datei. Hierbei handelt es sich um ein ZIP-Archiv mit den Daten des GSM-Scans.
Starten Sie verinice für den Import. In verinice ö nen Sie die ISM Ansicht. Importieren Sie den Katalog Implementation Assistance for ISO27001. Erzeugen Sie eine Organisation. Anschließend
sollte der Bildschirm ähnlich der Abbildung Verinice bietet eine ISM Perspektive. (Seite 218) aussehen.
Import des ISM-Scans
Wählen Sie in der verinice Oberfläche die Import-Funktion im Informationssicherheitsmodell aus.
Wählen Sie nun Ihren ISM-Report aus. Die restlichen Parameter können auf ihren DefaultEinstellungen verbleiben.
Die Ergebnisse des ISM-Reports wurden importiert und können in Verinice ausgeklappt werden. Dabei
wurden nur die Ergebnisse importiert, die im GSM-Bericht mit Notizen versehen wurden.
Der Prozess zur Verfolgung von Schwachstellen für die importierte Organisation gliedert sich in zwei
Unterprozesse:
• Erzeugung von Aufgaben
• Beheben von Schwachstellen
22.2. Verinice
217
Abb. 22.2: Verinice bietet eine ISM Perspektive.
Abb. 22.3: Der Import-Button befindet sich im Fenster Informationssicherheitsmodell.
Erzeugung von Aufgaben
Vor dem Erzeugen von Aufgaben müssen die Daten in der Organisation mit den folgenden Schritten
vorbereitet werden:
• Nach dem ersten Import einer Organisation, muss diese aus der Gruppe der importierten Objekte
auf die oberste Ebene verschoben werden. Schneiden Sie dazu die Organisation aus und fügen
Sie diese auf der höchsten Ebene wieder ein.
• Die Assets und Controls müssen gruppiert werden. Wählen Sie im Kontextmenü der obersten
Asset- und Control-Gruppe die Funktion Gruppiere mit Tags... aus. In der Abbildung Die
Assets wurden bereits gruppiert. (Seite 220) wurde dies bereits für die Assets durchgeführt.
• Allen Asset-Gruppen muss eine verantwortliche Person zugewiesen werden. Verknüpfen Sie dazu eine Person mit einer oder mehreren Asset-Gruppen. Hierzu legen Sie die Personen an und
verknüpfen diese mit Drag&Drop. Die erfolgreiche Verknüpfung wird im Fenster Relations angezeigt.
• Nachdem allen Asset-Gruppen eine verantwortliche Person zugeordnet wurde, kann über das
Kontextmenü der Organisation der Prozess zum Beheben von Schwachstellen gestartet werden. Wählen Sie aus dem Kontextmenü einer Organisation Aufgaben Greenbone: Start
Schwachstellenverfolgung. Zuerst wird geprüft, ob allen Asset-Gruppen eine Person zugeordnet und ob Assets und Controls gruppiert sind. Das Ergebnis der Überprüfung wird in ei218
Abb. 22.4: Wählen Sie im Dialog Ihren Report aus.
Abb. 22.5: Über das Setzen der Notizen können Sie den Import der Schwachstellen steuern.
nem Dialog angezeigt. Der Benutzer kann fortfahren und Aufgaben erzeugen oder die Erzeugung
abbrechen.
Beheben von Schwachstellen
Die erzeugten Aufgaben können mit Hilfe des Aufgaben-Views oder des Webfrontends in der Version
verinice.PRO (unter: ISO 27000 Aufgaben) bearbeitet werden. Die Aufgabe zum Beheben von Schwachstellen hat den Titel Schwachstellen beheben. Eine Aufgabe enthält Controls, Szenarios und Assets,
die mit einer Control-Gruppe verknüpft sind und zu einer verantwortlichen Person gehören.
Dieser Vorgang erfolgt nun in den folgenden Schritten:
• Die verantwortliche Person muss nun die Schwachstelle für alle Assets beheben.
• Wenn der Termin für die Aufgabe Schwachstellen beheben abläuft, wird per E-Mail eine Erinnerung an die verantwortliche Person verschickt.
• Nach Abschluss einer Aufgabe mit dem Titel Schwachstellen beheben, werden alle Verknüpfungen zwischen Assets und Szenarios, die einer Aufgabe zugeordnet waren, gelöscht.
• Ein Control wird als umgesetzt markiert, wenn dem Szenario keine Assets mehr zugeordnet sind.
22.2. Verinice
219
Abb. 22.6: Die importierte Organisation muss auf die höchsten Ebene verschoben werden.
Abb. 22.7: Die Assets wurden bereits gruppiert.
Wenn noch andere Verknüpfungen zu Assets bestehen, wird der Status eines Controls als teilweise markiert. Anschließend wird der Prozess beendet.
22.2.2 IT-Grundschutz
Greenbone stellt eine spezielle Konfiguration (IT Security Baseline Scan einschließlich Discovery für
verinice) als auch ein IT Security Baseline Reportformat (Verinice ITG) speziell für die Anbindung an
verinice zur Verfügung.
Für die optimalen Ergebnisse sollte diese Scan-Konfiguration importiert werden. Das Berichtsformat
wird mit der GSM ausgeliefert. Ein manueller Import des Berichtsformats ist daher nicht mehr erforderlich.
Für die optimalen Ergebnisse im Scan, ist es hilfreich, einen authentifizierten Scan durchzuführen (siehe Abschnitt Authentifizierter Scan (Seite 71)).
Abb. 22.8: Die Verknüpfungen einzelner Objekte lassen sich im Relations Fenster nachkontrollieren.
220
Sobald der Scan abgeschlossen ist, kann das Ergebnis mit dem verinice ITG Format exportiert werden.
Eine Datei mit der Endung .vna wird hierbei erzeugt. Dies ist ein ZIP-Archiv mit den Ergebnissen des
Scans. Diese Datei kann direkt in verinice geö net werden.
Im Folgenden verwenden wir für die Übersichtlichkeit einen Scan, in dem nur ein Host gescannt wurde.
Ö nen Sie verinice und wechseln Sie in die IT Security Baseline Ansicht (siehe Abbildung Verinice ö net den bereits modellierten IT-Verbund. (Seite 221)). Falls noch kein IT Bond erzeugt wurde, ist die
mittlere Spalte noch leer.
Abb. 22.9: Verinice ö net den bereits modellierten IT-Verbund.
Import des ITG-Scans
Wählen Sie in der verinice Oberfläche die Import-Funktion im Grundschutz-Modell aus.
Abb. 22.10: Der Import-Button befindet sich im Fenster BSI-Modell.
Wählen Sie nun Ihren ITG-Report aus. Die restlichen Parameter können auf ihren DefaultEinstellungen verbleiben.
Die Ergebnisse des ITG-Reports wurden importiert und können in den Verinice ausgeklappt werden.
Die importierten Objekte sind nach ihrem Ziel im GSM oder ihrer IP-Adresse benannt. Jedes der importierten Objekte besitzt ein Tochterobjekt GSM result mit den Maßnahmenergebnissen des Scans.
22.2. Verinice
221
Abb. 22.11: Wählen Sie im Dialog Ihren Report aus.
Abb. 22.12: Die importierten Daten können in verinice ausgeklappt werden.
Nun können Sie die IT-Grundschutz-Module hinzugefügt werden. Dazu wählen Sie den Server mit einem Rechts-Mausklick aus. Im Kontext-Menü wählen Sie Greenbone: Bausteine automatisch
zuordnen. Verinice wird nun auf Grund der von dem GSM gesetzten Tags automatisch die richtigen
Bausteine für Modellierung des Systems auswählen.
Abb. 22.13: Die IT-Grundschutzbausteine können nun automatisch gewählt werden.
Nun können Sie die Ergebnisse des Scans auf den Maßnahmenkatalog übertragen. Hierzu markieren Sie das Server-Objekt und rufen im Kontextmenü die Funktion Greenbone. Automatischer
Basis-Sicherheitscheck auf.
222
22.3 Nagios
Nagios kann die Ergebnisse eines Scans als zusätzlichen überwachten Dienst in seiner Übersicht anzeigen. In diesem Fall werden die gescannten Systeme automatisch mit den überwachten Systemen
verknüpft. Somit stehen die Scan-Ergebnisse auch für eine Alarmierung über Nagios zur Verfügung.
Wenn Nagios mit dem GSM verknüpft wird, übernimmt Nagios die Steuerung. Nagios prüft automatisch regelmäßig die neuesten Scan Ergebnisse von dem Greenbone Security Manager. Dies erfolgt
mithilfe des Nagios Plugins “check_omp”.
Im Folgenden erhalten Sie Schritt für Schritt die Anweisungen um den GSM mit Nagios als Teil der
Open Monitoring Distribution <http://omdistro.org/>‘_(:index:‘OMD) zu verbinden. Andere Produkte
wie Icinga, Centreon etc. erfordern möglicherweise kleine Anpassungen dieser Anleitung.
22.3.1 Konfiguration des GSM-Nutzers
Für den Zugri auf die Appliance benötigt das Plugin einen Benutzer zur Anmeldung. Auf
dem
GSM muss für diesen Benutzer ein oder mehrere Scan-Ziele mit allen Rechnern, deren Sicherheitsstatus überwacht werden soll, erzeugt werden. Die folgende Beispielkonfiguration geht
von nur einem relevanten Ziel aus. Grundsätzlich ist es jedoch möglich, komplexe Konfigurationen mit mehreren Zielen und mehreren GSMs umzusetzen.
Das GSM Benutzerkonto für die Zugri e des Nagios Plugins muss der Eigentümer der relevanten ScanZiele sein oder zumindest über uneingeschränkte Leserechte auf diese Scan Ziele verfügen. Die Aufgaben sollten mithilfe eines Zeitplans automatisch in regelmäßigen Abständen ausgeführt werden.
Zusätzlich ist ein Netzwerkzugri via OMP auf die GSM Appliance erforderlich. Hierzu muss der OMP
Zugri in dem GOS-Admin-Menu auf der Kommandozeile aktiviert werden (siehe Abschnitt Aktivieren
des OMP Protokolls (Seite 185) und OpenVAS Management Protocol (OMP) (Seite 33)).
22.3.2 Installation des Plugins
Greenbone stellt das check_omp Nagios Plugin unter http://greenbone.net/download/tools/check_omp
zur Verfügung. Für die Analyse des Quelltexts ist dieser unter http://greenbone.net/download/sources/check_ompsrc.r18825.tar.gz einsehbar.
22.3. Nagios
223
Abb. 22.14: Die Konfiguration erfolgt am Beispiel einer leeren Beispiel-Site.
Laden Sie das Plugin auf Ihrem Monitoring System herunter und machen Sie es ausführbar:
omd-host :~# wget -q http://greenbone.net/download/tools/check_omp
omd-host :~# chmod 755 check_omp
omd-host :~# ./check_omp --version
Check-OMP Nagios Command Plugin 1.3+ beta3
Copyright (C) 2013 Greenbone Networks GmbH
License GPLv2+: GNU GPL version 2 or later
This is free software : you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Dieses Plugin kopieren Sie nun nach /opt/omd/sites/site/local/lib/nagios/plugins/.
22.3.3 Konfiguration des Plugins
Prüfen Sie zunächst, ob das Plugin den GSM über das Netzwerk erreichen kann, OMP aktiviert wurde
und der Benutzer richtig angelegt wurde. Ersetzen Sie im folgenden Aufruf die IP-Adresse durch die
Adresse Ihres GSM und geben Sie den Benutzernamen und das Kennwort ein, welches Sie angelegt
haben.
omd-host# /opt/omd/sites/<site>/local/lib/nagios/plugins/check_omp -H 192.168.255.12 \
-u omd -w password -ping
OMP OK: Alive and kicking!
Prüfen Sie anschließend, ob Sie auch Zugri auf die Daten haben. Dies geschieht am einfachsten auf
der Kommandozeile:
omd-host# /opt/omd/sites/<site>/local/lib/nagios/plugins/check_omp -H 192.168.255.12 \
-u omd -w password --status -T KVM-Hosts --last-report -F 192.168.255.199
OMP CRITICAL: 4 vulnerabilities found - High : 1 Medium : 1 Low : 2
|High=1 Medium=1 Low=2
Sofern diese Tests erfolgreich waren, können Sie den Check in OMD über das WebAdministrationsfrontend WATO einbauen. Wechseln Sie hierzu auf die Weboberfläche Multisite
für Ihre OMD-Site (siehe Abbildung Die Konfiguration erfolgt am Beispiel einer leeren Beispiel-Site.
(Seite 224)).
224
Abb. 22.15: Der Host-Tag kennzeichnet die Rechner, die von dem GSM überwacht werden.
Legen Sie zunächst einen Host-Tag (Abbildung Der Host-Tag kennzeichnet die Rechner, die von dem
GSM überwacht werden. (Seite 225)) an. Dieser kennzeichnet die Hosts, die auch von der GSM Appliance gescannt werden. Hierzu rufen Sie im linken Menü die Host Tag auf und erzeugen hier einen
neuen Tag.
Nun erstellen Sie eine neue Regel (Abbildung Diese Regel prüft für jeden Host mit dem Tag Monitored by GSM den Status im GSM. (Seite 226)), die den Host-Tag auswertet. Hierzu wechseln Sie im linken Menü in Host & Service Parameters. Wählen Sie hier Active Checks. Im nächsten Menü
wählen Sie Classical Active and Passive Nagios Checks. Dann erzeugen Sie eine neue Regel (Abbildung Diese Regel prüft für jeden Host mit dem Tag Monitored by GSM den Status im GSM.
(Seite 226)) im aktuellen Ordner (Create Rule in Folder Main Directory). Achten Sie hierbei
darauf, den folgenden Aufruf zu verwenden:
$USER2$/check_omp -H <gsm -ip > -u <user > -w < password > -- status -T <report > \
--last -report -F $HOSTADDRESS$
Nun müssen Sie noch den Host anlegen bzw. so anpassen, dass er über das entsprechende Host-Tag
verfügt (siehe Abbildung Jeder von dem GSM gescannte Host muss nun das Tag erhalten. (Seite 227)).
Nachdem Sie die Änderungen in der Multisite aktiviert haben (Activate Changes) stehen die
Status-Informationen in der grafischen Oberfläche zur Verfügung.
Damit der Benutzername und das Kennwort nicht in der grafischen Oberfläche angezeigt werden, können diese in der Datei /opt/omd/sites/site/etc/nagios/resource.cfg als Variablen hinterlegt werden:
############################################
# OMD settings, please use them to make your config
# portable, but dont change them
$USER1$=/omd/sites/produktiv/lib/nagios/plugins
$USER2$=/omd/sites/produktiv/local/lib/nagios/plugins
$USER3$=produktiv
$USER4$=/omd/sites/produktiv
############################################
# set your own macros here:
$USER5$=omd
$USER6$=kennwort
Nun können Sie den Benutzernamen und das Kennwort in WATO durch die Variablen USER5 bzw.
USER6 ersetzen.
22.3. Nagios
225
Abb. 22.16: Diese Regel prüft für jeden Host mit dem Tag Monitored by GSM den Status im GSM.
22.4 Sourcefire Defence Center
Das Sourcefire Intrusion Prevention System (IPS) ist eine der führenden Lösungen für die Einbruchserkennung und -abwehr in Rechnernetzen. Als Network Intrusion Detection System (NIDS) hat es die
Aufgabe, Angri e gegen das Netz zu erkennen, zu melden und abzuwehren.
Das Sourcefire IPS benötigt für eine korrekte Erkennung und Zuordnung der Angri e möglichst exakte
Informationen über die im Netz vorhandenen Systeme, dort installierte Applikationen sowie deren
mögliche Schwachstellen. Hierzu hält das Sourcefire System eine eigene Asset-Datenbank vor, die
über den GSM mit Informationen ergänzt werden kann. Außerdem kann das Sourcefire System bei
Verdachtsmomenten einen automatischen Scan anstoßen.
Es existieren zwei Kopplungsmethoden:
1. Automatischer Daten-Transfer von GSM nach NIDS/IPS Sind GSM und NIDS/IPS entsprechend konfiguriert, so ist der Datentransfer von GSM nach NIDS/IPS so einfach nutzbar,
wie jede andere Alert-Funktionalität beim GSM. Nach Abschluss eines Scans wird entsprechend der gewünschten Kriterien das Scan-Ergebnis als Alert automatisch an das NIDS/IPS
übertragen. Läßt man diesen Scan-Auftrag jede Woche automatisch ausführen, erhält man
ein vollautomatisiertes Melde- und Optimierungssystem.
2. Aktive Steuerung des GSM durch NIDS/IPS Beim Betrieb des NIDS/IPS können Verdachtsmomente zu Systemen mit besonderer Gefährdung entstehen. Das NIDS/IPS kann in einem
226
Abb. 22.17: Jeder von dem GSM gescannte Host muss nun das Tag erhalten.
solchen Fall den GSM anweisen, das System zu überprüfen 144 .
Um diese Kopplung in den Varianten 1 oder 2 zu nutzen, muss sowohl das GSM als auch das Sourcefire
Defense Center vorbereitet werden. Auf dem GSM müssen Sie ein Report Plugin installieren und auf
dem Defense Center müssen Sie die Annahme der Daten erlauben.
22.4.1 Installation des Report Export Plugins
Das
Report
Plugin
erhalten
sie
auf
der
Greenbone
Webseite
unter
http://greenbone.net/technology/report_formats.de.html. Laden Sie das Plugin herunter und
installieren Sie es in dem GSM. Denken Sie daran, nach dem Import das Plugin zu verifizieren und zu
aktivieren (siehe Abschnitt Import weiterer Report Plugins (Seite 95)).
144 Diese Steuerung existiert im Moment noch nicht als fertige Remediation für das Sourcefire System, kann jedoch via OMP
realisiert werden (siehe Kapitel chapter OpenVAS Management Protokoll (OMP) (Seite 185)).
Abb. 22.18: Der GSM-Status wird nun in der Multisite angezeigt.
22.4. Sourcefire Defence Center
227
Abb. 22.19: Das Report Plugin bereitet die Daten für Sourcefire auf.
22.4.2 Konfiguration des Host-Input-API-Clients
Abb. 22.20: Der GSM muss in dem Defense Center angelegt werden.
Melden Sie sich auf Ihrem Sourcefire Defense Center an und erzeugen Sie einen Host- Input-Client. Die
Host-Input-API ist die Schnittstelle, über die das Defense Center Daten für seine Asset Datenbank von
anderen Anwendungen annimmt. Sie finden diese Funktion in der Weboberfläche des Defense Centers unter System->Local->Registration. Dort wechseln Sie zur Registerkarte Host Input Client.
Hier legen Sie die GSM-Appliance an. Wichtig ist, dass Sie hier die IP-Adresse der Appliance eintragen,
mit der sich die Appliance mit dem Defense Center verbindet. Diese Verbindung ist TLS-verschlüsselt.
Das Defense-Center erzeugt automatisch einen privaten Schlüssel und ein Zertifikat. In dem Zertifikat
wird die angegebene IP-Adresse als Common Name eingetragen und bei dem Verbindungsaufbau des
Clients geprüft. Wenn der Client eine andere IP-Adresse nutzt, schlägt die Verbindung fehl.
Die erzeugte PKCS12-Datei wird optional mit einem Kennwort gesichert.
Anschließend wird das Zertifikat und der Schlüssel erzeugt und als PKCS12-Datei zum Download angeboten. Laden Sie diese Datei herunter.
22.4.3 Konfiguration des Alerts auf dem GSM
Nun müssen Sie auf dem GSM einen entsprechenden Alert einrichten. Hierzu wechseln Sie auf
Configuration/Alerts. Geben Sie hier die Daten des Sourcefire-Systems und die PKCS12-Datei an.
Wenn Sie bei der Erzeugung des Clients ein Kennwort angegeben haben, müssen Sie die PKCS12-Datei
vor dem Laden auf dem GSM entschlüsseln. Hierzu können Sie unter Linux das folgende Kommando
nutzen:
$ openssl pkcs12 -in encrypted.pkcs12 -nodes -out decrypted.pcks12
Enter Import Password : password
MAC verified OK
$
228
Abb. 22.21: Die erzeugte PKCS12 Datei muss heruntergeladen werden.
Abb. 22.22: Die PKCS12-Datei nutzt der Connector zur Authentifizierung.
22.4. Sourcefire Defence Center
229
230
KAPITEL 23
OpenVAS Scanner Protokoll
Das OpenVAS Scanner Protocol (OSP) ist eine XML-basierte zustandslose Request-Response API die
eine einheitliche Abstraktion für Schwachstellen-Scanner bietet. Der Greenbone Security Manager ist
in der Lage OSP-Scanner bruchfrei in das Schwachstellenmanagement zu integrieren. OSP-Scanner
werden alle auf die gleiche Weise gesteuert und die Ergebnisse sind in der Datenbank in ein und derselben Struktur abgelegt. Es kann eine beliebige Zahl gleicher oder verschiedener OSP-Scanner angebunden werden.
Der Begri “Schwachstellen-Scanner” ist hierbei sehr weit gefasst zu sehen. Es kann sich auch um
Abfragen in ein Patch-Management System handeln oder eine reine Asset-Abfrage. Als Ergebnis
eines Scanners wird lediglich erwartet, dass es sich um Schwachstellen-Details oder um AssetInformationen handelt. Letzteres können installierte Software-Pakete, o ene Ports, laufende Dienste, TLS-Zertifkate und ähnliches sein.
Einige OSP Scanner sind bereits in die GSM Appliance integriert worden und können über das GOSAdmin-Menü aktiviert werden. Es ist jedoch auch möglich externe OSP Scanner hinzuzufügen.
23.1 Aktivierung zusätzlicher OSP-Scanner
Zusätzliche Scanner können über das GOS-Admin-Menü aktiviert werden. Der GSM hat in seiner Werkseinstellung nur den OpenVAS-Scanner aktiv. Kein weiterer Scanner ist eingeschaltet.
Bemerkung: Beginnend mit GOS 3.1.17 können ausgewählte Anwender zusätzliche Scanner aktivieren.
Diese Funktionalität wird in späteren Versionen allen Benutzer zur Verfügung stehen. Um bereits jetzt
diese Funktionalität zu nutzen, kontaktieren Sie den Greenbone Support.
Um die zusätzlichen Scanner einzuschalten, rufen Sie das GOS-Admin-Menü auf und wählen Sie
Advanced/Scanner Management. Das folgende Menü wird ihnen angezeigt:
Um z.B. den w3af Scanner einzuschalten, wählen Sie Add OSP w3af Scanner. In Abhängigkeit des gewählten Scanners, werden möglicherweise weitere Informationen oder Lizenzen angezeigt:
Der Scanner ist erzeugt worden. Der Scanner ist nach einem Neustart verfügbar.
Mithilfe des gleichen Menüs können Sie die Scanner auch aktualisieren und wieder abschalten.
23.2 Wie man einen OSP Wrapper baut
Die OSP Protokoll-Dokumentation ist auf der Greenbone Website verfügbar unter
http://docs.greenbone.net/API/OSP/osp.html
231
Abb. 23.1: Aktivierung zusätzlicher Scanner
Abb. 23.2: Akzeptieren Sie die Bedingungen
23.2.1 Die Aufgabe: debsecan als OSP-Scanner
Im Folgenden stellen wir uns die Aufgabe, das Werkzeug “debsecan” mit einem OSP Wrapper zu versehen. Dieses Werkzeug ist für Debian GNU/Linux Systeme verfügbar und ermittelt für das System
auf dem es ausgeführt wird, eine Liste von Schwachstellen zu den installierten Paketen. Es geht dabei über die herkömmliche Abfrage nach fehlenden Updates hinaus und holt sich über eine OnlineVerbindung Informationen zu noch in Bearbeitung befindlichen Schwachstellen.
Weitere Details zu diesem Werkzeug finden such auf der debsecan Homepage:
http://www.enyo.de/fw/software/debsecan/
Für die Ausführung von debsecan reichen einfache Anwender-Privilegien aus:
$ debsecan
CVE-2015-3333 chromium (remotely exploitable, high urgency)
CVE-2015-3334 chromium (remotely exploitable, medium urgency)
CVE-2015-3336 chromium (remotely exploitable, medium urgency)
TEMP-0000000-EA424A libbluray1
CVE-2014-9447 libelf1 (remotely exploitable, medium urgency)
CVE-2014-8354 libmagickcore5
232
Kapitel 23. OpenVAS Scanner Protokoll
Abb. 23.3: Ein Neustart ist erforderlich nachdem der Scanner eingeschaltet wurde.
TEMP-0000000-2FC21E libmagickcore5 (low urgency)
TEMP-0000000-7C079F libmagickcore5
TEMP-0000000-EEF23C libmagickcore5 (low urgency)
TEMP-0000000-FDAC72 libmagickcore5
TEMP-0773834-5EB6CF libmagickcore5
CVE-2013-4288 libpolkit-gobject-1-0 (low urgency)
CVE-2002-2439 libstdc++6-4.7-dev (low urgency)
CVE-2014-5044 libstdc++6-4.7-dev
...
Wie man sieht sind viele Schwachstellen schon direkt mit einer CVE verknüpft. Diese ScanInformationen wollen wir nun OpenVAS zugängig machen.
23.2.2 Die Basis: ospd
OSP it letztlich nur eine Spezifikation. Man könnte also selbst einen OSP Wrapper in einer beliebigen
Programmiersprache entwickeln.
Um sofort mit der eigentlichen Anbindung zu starten, kann man aber auch auf das OpenVAS-Modul
“ospd” zurückgreifen. Dies ist in Python geschrieben und stellt eine Basis-Klasse sowie Hilfsfunktionen zur Verfügung. Damit ist die gesamte Service-Funktionalität inklusive TLS-Verschlüsselung bereits fertig.
Das aktuelle ospd Paket kann hier heruntergeladen werden:
http://www.openvas.org/install-source-de.html
Wir arbeiten mit Version 1.0.0:
https://wald.intevation.org/frs/download.php/1999/ospd-1.0.0.tar.gz
Und prüfen natürlich die Signatur:
https://wald.intevation.org/frs/download.php/1999/ospd-1.0.0.tar.gz.sig
$ gpg --verify ospd-1.0.0.tar.gz.sig
$ tar xzf ospd-1.0.0.tar.gz
$ cd ospd-1.0.0/
Wir installieren das Paket an einem temporären Ort:
$ mkdir /tmp/osptest
$ export PYTHONPATH=/tmp/osptest/lib/python2.7/site-packages/
23.2. Wie man einen OSP Wrapper baut
233
Nun wird ospd dorthin installiert:
$ python setup.py install --prefix=/tmp/osptest
Natürlich führen viele Wege nach Rom. Man kann das Paket auch an andere Orte und auf andere Weise
installieren. Wer selbst häufiger mit Python zu tun hat, kann hier gerne den bevorzugten Weg gehen.
23.2.3 Das Grundgerüst für den neuen OSP Scanner
Zunächst legen wir ein passendes Verzeichnis und die zentrale Datei “wrapper.py” an.
Die beiden wichtigsten Elemente dort sind zunächst eine Ableitung des “OSPDaemon” mit einer fürs
erste sehr einfachen Selbstauskunft (“OSPDdebsecan”) sowie die Hauptroutine für den Service selbst
(“main”).
$ mkdir -p debsecan/ospd_debsecan
$ cd debsecan/ospd_debsecan
$ gvim wrapper.py
from ospd.ospd import OSPDaemon
from ospd.misc import main as daemon_main
from ospd_debsecan import __version__
class OSPDdebsecan(OSPDaemon):
""" Class for ospd-debsecan daemon. """
def __init__(self, certfile, keyfile, cafile):
""" Initializes the ospd-debsecan daemon‛s internal data. """
super(OSPDdebsecan, self).__init__(certfile=certfile, keyfile=keyfile,
cafile=cafile)
self.server_version = __version__
self.scanner_info[‛name‛] = ‛debsecan‛
def check(self):
""" Checks that debsecan command line tool is found and is executable. """
return True
def main():
""" OSP debsecan main function. """
daemon_main(‛OSPD - debsecan wrapper‛, OSPDdebsecan)
Nun komplettieren wir das Gerüst um einen lau ähigen, wenn auch noch sehr dummen Service zu
erhalten. Dafür legen wir noch “__init__.py” im selben Verzeichnis von “wrapper.py” an:
__version__ = ‛1.0b1‛
Und das Steuerungs-Modul für das Paket: debsecan/setup.py:
from setuptools import setup
from ospd_debsecan import __version__
setup(
name=‛ospd-debsecan‛,
version=__version__,
packages=[‛ospd_debsecan‛],
url=‛http://www.openvas.org‛,
author=‛OpenVAS Development Team‛,
author_email=‛[email protected]‛,
234
license=‛GPLV2+‛,
install_requires=[‛ospd==1.0.0‛],
entry_points={
‛console_scripts‛: [‛ospd-debsecan=ospd_debsecan.wrapper:main‛],
},
)
Damit läßt sich unser neuer Server installieren und starten:
$ python setup.py install --prefix=/tmp/osptest
Falls noch nicht geschehen, sollte der Pfad für den Server angepasst werden:
$ export PATH=$PATH:/tmp/osptest/bin
Dann kann der Aufruf direkt erfolgen:
$ ospd-debsecan --version
OSP Server for debsecan version 1.0b1
OSP Version: 1.0
Using: OSPd 1.0.0
Copyright (C) 2014, 2015 Greenbone Networks GmbH
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Testen wir als nächstes die Server-Funktion und schicken den Server in den Hintergrund, so dass er
auf unserem System an Port 2346 auf Anfragen wartet:
$ ospd-debsecan -b 127.0.0.1 -p 2346 \
-k /tmp/osptest/var/lib/openvas/private/CA/clientkey.pem \
-c /tmp/osptest/var/lib/openvas/CA/clientcert.pem \
--ca-file /tmp/osptest/var/lib/openvas/CA/cacert.pem &
Die verwendeten Schlüssel und Zertifikate wurden tatsächlich für den OpenVAS Scanner durch das
Werkzeug “openvas-mkcert” erzeugt. Um die Komplexität zu reduzieren, verwenden wir sie hier einfach anstelle ein eigenes Schlüsselpaar zu erzeugen. Wenn Sie den OpenVAS-Scanner mit einem anderen Prefix installiert haben, nutzen Sie den entsprechenden Pfad statt “/tmp/osptest/”.
Wie man bereits vermuten kann, erfolgt die Authentifizierung bei einem OSP-Server via KlientZertifikat. Eine Anmeldung mit einer Kombination von Benutzername und Passwort ist nicht vorgesehen.
Mit dem “omp” Kommandozeilen-Werkzeug des “openvas-cli” Paketes kontaktieren wir den Server:
$ omp -h 127.0.0.1 -p 2346 --use-certs -X "<get_version/>"
<get_version_response status_text="OK" status="200"><protocol><version>1.0</versi...
Voreingestellt verwendet “omp” mit “–use-certs” die Standardpfade für die Schlüssel und Zertifikate.
Das funktioniert natürlich nur, wenn wir in der selben Umgebung des Servers arbeiten.
Etwas hübscher und besser lesbar ist die Antwort mit der zusätzlichen Option “–pretty-print”:
$ omp -h 127.0.0.1 -p 2346 --use-certs --pretty-print -X "<get_version/>"
<get_version_response status_text="OK" status="200">
<protocol>
<version>1.0</version>
<name>OSP</name>
</protocol>
<daemon>
<version>1.0.0</version>
<name>OSPd</name>
</daemon>
<scanner>
235
<version>No version</version>
<name>debsecan</name>
</scanner>
</get_version_response>
Schauen wir uns das in der GSM Web-Oberfläche an:
Über den Menüpunkt Configuration/Scanners wird ein neuer Scanner angelegt, siehe Abbildung Anlegen eines neuen OSP Scanners. (Seite 236). Die Zertifikate sind die gleichen wir beim Start des Servers.
Abb. 23.4: Anlegen eines neuen OSP Scanners.
Es werden direkt nach Erstellung die Details zum Scanner angezeigt, siehe Abbildung Online Rückmeldungstest für den OSP Scanner. (Seite 236). Diese “Online Response” zeigt uns die schon oben
abgefragte Versionsnummer sowie auch einen Parameter: “debug_mode” ist ein Standardparameter
der durch die Basisklasse “OSPDaemon” mitgeliefert wird.
Abb. 23.5: Online Rückmeldungstest für den OSP Scanner.
So weit, so gut: Wir haben einen funktionierenden Server. Leider kann er noch nichts von seiner eigentlichen Bestimmung. Das werden wir nun ändern.
236
23.2.4 Verbindung schaffen zwischen debsecan und OSP
Dafür müssen wir eine weitere Methode für die Klasse “OSPDaemon” definieren, nämlich “exec_scan”:
def exec_scan(self, scan_id, target):
""" Starts the debsecan scanner for scan_id scan. """
# run the debsecan command
result = subprocess.check_output(["debsecan"])
# parse the output of the debsecan command and create
# respective alarms
for line in result.split("\n"):
words = line.split()
if words.__len__() > 2 and words[0].split("-")[0] == "CVE":
self.add_scan_alarm(scan_id, host=target, name=words[0],
value=line)
Wie oben installieren und starten wir die neue Version und testen danach die Funktion erstmal auf der
Kommandozeile:
$ omp -h 127.0.0.1 -p 2346 --use-certs --pretty-print \
-X "<start_scan target=‛localhost‛><scanner_params/></start_scan>"
<start_scan_response status_text="OK" status="200">
<id>8f48d691-c136-488f-8f31-d8761e1c75e1</id>
</start_scan_response>
Damit haben wir die ID unseres Scans. Schauen wir die Details dazu an:
$ omp -h 127.0.0.1 -p 2346 --use-certs --pretty-print \
-X "<get_scans scan_id=‛8f48d691-c136-488f-8f31-d8761e1c75e1‛/>"
<get_scans_response status_text="OK" status="200">
<scan id="8f48d691-c136-488f-8f31-d8761e1c75e1" target="localhost"
end_time="1428004156" progress="100" start_time="1428004156">
<results>
<result host="localhost" severity="" test_id="" name="CVE-2015-3333"
type="Alarm">CVE-2015-3333 chromium (remotely exploitable, high urgency)
</result>
type="Alarm">CVE-2015-3334 chromium (remotely exploitable, medium urgency)
</result>
type="Alarm">CVE-2015-3336 chromium (remotely exploitable, medium urgency)
</result>
type="Alarm">CVE-2014-9447 libelf1 (remotely exploitable, medium urgency)
</result>
type="Alarm">CVE-2013-4288 libpolkit-gobject-1-0 (low urgency)</result>
type="Alarm">CVE-2002-2439 libstdc++6-4.7-dev (low urgency)</result>
type="Alarm">CVE-2013-2074 kdelibs5-plugins (remotely exploitable, low urgency)
</result>
</results>
</scan>
</get_scans_response>
Das sieht soweit gut aus. Nun ein Scan über die GUI. Dafür brauchen wir zuerst noch eine Scan
Configuration für debsecan, auch wenn diese eigentlich leer beibt. Diese wird über das Menü
Configuration/Scan Configs neu erstellt, siehe Abbildung Anlegen einer neuen Scan-Konfiguration für
den debscan OSP-Scanner. (Seite 238).
237
Abb. 23.6: Anlegen einer neuen Scan-Konfiguration für den debscan OSP-Scanner.
Nun den Task erstellen wie in Abbildung Anlegen eines Tasks für den debscan OSP-Scanners. (Seite 238):
Abb. 23.7: Anlegen eines Tasks für den debscan OSP-Scanners.
Wenn wir dann auf die übliche Weise den Scan starten, erhalten wir die Ergebnisse wie in Abbildung
Ein Scan-Ergebnis eines OSP debscans. (Seite 239).
Der Schweregrad der Ergebnisse wird automatisch, basierend auf der internen CVE Datenbank, durch
den GSM bestimmt.
23.2.5 Fazit
Wir haben mit 40 Zeilen Python-Quelltext eine OSP Scanner-Anbindung gescha en die die CVESchwachstellen-Informationen des Werkzeuges debsecan an den Greenbone Security Manager liefern kann.
Durch die Verwendung als ganz regulären Task können wir die debsecan-basierten Prüfungen nun mit
einer zeitgesteuerten Ausführung versehen. Wir können Notizen und Übersteuerungen anlegen und
alle weiteren Funktionen eines vollwertigen Schwachstellen-Managements nutzen.
Aber noch ist der OSP-Wrapper für debsecan recht rudimentär. Es fehlen noch Fehlerbehandlungen
und wir können durch bessere Aufbereitung noch mehr aus den Scan-Resultaten für den Greenbone
Security Manager herausholen.
Abseits dieser Erweiterungen ist ein weiteres Ziel erstrebenswert: Der Ausbau des OSP-debsecan zu
einem Remote-Scanner. Bisher wird das Zielsystem ignoriert und einfach immer das lokale System
geprüft. Doch könnte sich der OSP-Wrapper unter Verwendung von über den GSM konfigurierten Zugangsdaten per SSH auf den genannten Zielsystemen einloggen und den dort installierten debsecan ausführen und die Resultate entsprechend aufbereiten. Damit liessen sich dann ganze Netzwer-
238
Abb. 23.8: Ein Scan-Ergebnis eines OSP debscans.
ke prüfen, ohne dass auf jedem System ein ospd-debsecan installiert wäre. Der OSP-Scanner “ospdovaldi” ist ein Beispiel für einen solchen Remote-Scanner.
Der aktuelle Stand von OSP-debsecan ist natürlich als Open Source unter der GPLv2+ lizensiert und
hier verfügbar:
https://wald.intevation.org/scm/viewvc.php/trunk/osp-servers/debsecan/?root=openvas
23.2.6 Erste Fehlerbehandlung einbauen
OSP erlaubt das Senden einer Fehlermeldung, falls irgendein Problem während des Scans auftrat.
Diese Meldungen werden in der Benutzeroberfläche im Abschnitt “Fehler” auftauchen.
Die Methode, die hierfür verwendet wird, heisst “add_scan_error” und funktioniert analog zur Methode “add_scan_alarm”. Die Ausführung des externen Werkzeuges “debsecan” könnte fehlschlagen,
weil es beispielsweise gar nicht installiert ist. Das wollen wir nun in der Methode “exec_scan” berücksichtigen:
# run the debsecan command
try:
result = subprocess.check_output(["debsecan"])
except:
self.add_scan_error(scan_id, host=target,
value="A problem occurred trying to execute ‛debsecan‛.")
return
239
240
KAPITEL 24
Setup-Handbücher
Dieses Kapitel stellt für die einzelnen Modelle spezifische Handbücher für die Inbetriebnahme und
Fehlersuche bereit.
• GSM ONE (Seite 241)
• GSM 25V (Seite 244)
• GSM 25 (Seite 247)
• GSM 100 (Seite 250)
• GSM 500/510/550 (Seite 251)
• GSM 400/600/650 (Seite 254)
• GSM 5300/6400 (Seite 255)
Die allgemeinen Schritte, die für alle GSM Modelle identisch sind, werden in dem Kapitel Inbetriebnahme (Seite 11) beschrieben.
Die Inbetriebnahme ist auch in einem Video erläutert: http://docs.greenbone.net/Videos/gos3.1/en/GSM-Setup-GOS-3.1-en-20150629.mp4.
24.1 GSM ONE
Dieser Abschnitt erläutert die Schritte bei der Inbetriebnahme einer GSM ONE Appliance. Sie können
die folgende Checkliste für die Kontrolle Ihres Fortschritts nutzen.
Schritt
Installation von Virtualbox 4.3
Verifikation der Integrität
Import des OVA
Ressourcen: 2 CPUs, 2GB Ram
Tastaturlayout
IP-Adresskonfiguration
DNS Konfiguration
Ändern des Kennworts
Web-Administrator-Konto
SSL-Zertifikat
Bereitschaft
Erledigt
24.1.1 Voraussetzungen
Dieser Abschnitt zählt die Voraussetzungen für den erfolgreichen Einsatz der GSM ONE Appliance auf.
Bitte stellen Sie sicher, dass alle Voraussetzungen erfüllt werden.
241
Ressourcen
Die virtuelle Appliance benötigt mindestens die folgenden Ressourcen:
• 2 virtuelle CPUs
• 2 GB RAM
Unterstützte Hypervisoren
Obwohl die GSM ONE auf unterschiedlichen Hypervisoren lau ähig ist, werden nur die folgenden aktuell unterstützt:
• Oracle VirtualBox 4.3 auf GNU/Linux
• Oracle VirtualBox 4.3 auf Microsoft Windows
Verifikation der Integrität
Die Integrität der virtuellen Appliance kann verifiziert werden. Der Greenbone Support kann hierzu auf Anfrage eine Integritätsprüfsumme bereitstellen. Um die Prüfsumme zu erhalten, kontaktieren Sie den Greenbone Support via E-Mail (emailto:[email protected]). Geben Sie Ihre Lizenznummer in der E-Mail an. Die Integritätsprüfsumme kann via Telefon oder Support-Portal (https://support.greenbone.net) bereitgestellt werden. Bitte geben Sie den bevorzugten Kanal in der EMail an.
Die Methode zur Überprüfung der Prüfsumme hängt von dem lokal eingesetzten Betriebssystem ab.
Unter Linux berechnen Sie die Prüfsumme mit folgendem Befehl:
sha256sum GSM-ONE-3.1.19-18-gsf201599999.ova
Unter Windows müssen Sie zunächst ein entsprechendes Programm installieren. Sie können hierzu
Rehash verwenden, welches Sie unter http://rehash.sourceforge.net finden. Um die Prüfsumme zu
berechnen nutzen Sie dann:
rehash.exe -none -sha256 C:\<path>\GSM-ONE-3.1.19-18-gsf201599999.ova
Falls die berechnete Prüfsumme nicht mit der durch den Greenbone Support bereitgestellten Prüfsumme übereinstimmt, wurde die virtuelle Appliance verändert und sollte nicht genutzt werden.
Einsatz
Jede GSM ONE wird mit einem einzigartigen Lizenzschlüssel aktiviert. Sie dürfen die GSM ONE nicht
klonen und mehrere Instanzen parallel betreiben. Dies kann Inkonsistenzen und unerwünschte Seitene ekte zur Folge haben.
24.1.2 Import der virtuellen Appliance
Die virtuellen Appliances werden von Greenbone im Open Virtualization Appliance (OVA) Format bereitgestellt. Diese Dateien können direkt in VMWare oder VirtualBox importiert werden. Die folgenden
Szenarien werden von Greenbone unterstützt:
• GSM ONE: Oracle VirtualBox 4.3 (Linux und Microsoft Windows)
• GSM 25V: ESXi 5.1
242
Kapitel 24. Setup-Handbücher
Import in der VirtualBox
Installieren Sie Oracle VirtualBox für Ihr Betriebssystem. Häufig ist VirtualBox bereits Bestandteil der
Linux-Distributionen. Falls dies nicht der Fall ist oder Sie Windows nutzen, können Sie VirtualBox direkt von Oracle beziehen (http://virtualbox.org/wiki/Downloads).
Starten Sie VirtualBox nach der Installation. Importieren Sie die OVA-Datei über File -> Import Appliance (siehe Abbildung Import der OVA-Appliance (Seite 243)).
Abb. 24.1: Import der OVA-Appliance
Bestätigen Sie die Konfiguration der virtuellen Maschine in dem folgenden Fenster (siehe Abbildung
Akzeptieren Sie die Hardware-Einstellungen. (Seite 243)). Falls möglich stellen Sie 4096 MB RAM (Arbeitsspeicher) für die optimale Konfiguration der virtuellen Appliance ein. Akzeptieren Sie die weiteren
Hardware-Einstellungen.
Der tatsächliche Import kann bis zu 10 Minuten benötigen. Nach dem Import starten Sie die virtuelle
Appliance.
Abb. 24.2: Akzeptieren Sie die Hardware-Einstellungen.
24.1. GSM ONE
243
Allgemeine Systemkonfiguration
Alle GSM Appliances nutzen dieselben Schritte in ihrer Grundkonfiguration und der Prüfung der Bereitschaft.
Bitte folgen Sie den in Kapitel Inbetriebnahme (Seite 11) beschriebenen Schritten und fahren Sie dann
mit den folgenden Abschnitten für die Protokollierung oder Fehlersuche fort.
Der Hauptzugri auf den GSM erfolgt über die Weboberfläche. Greifen Sie mit einem aktuellen WebBrowser auf https://<ip-des-gsm>/ zu.
Die IP-Adresse des GSM wird am Login-Prompt auf der Konsole angezeigt.
Melden Sie sich mit dem während der Inbetriebnahmen angelegten Web-Administrator an.
24.1.4 GSM ONE Fehlersuche
Die folgenden Warnungen und Probleme sind bekannt und können in Abhängigkeit der Umgebung auftreten:
• Auf Linux-Systemen kann die VirtualBox möglicherweise während des Imports warnen, dass der
Host-I/O-Cache aktiviert ist, wenn das Image auf einer XFS-Partition gespeichert wird. Dies ist
eine erwartete Warnung und sollte akzeptiert werden.
• Auf Linux-Systmen kann die Warnung “Failed to attach the network LUN
(VERR_INTNET_FLT_IF_NOT_FOUND)” angezeigt werden, wenn die virtuelle Maschine keine
Netzwerkkarte erkennen kann. Dann sollte die Netzwerkkarte innerhalb des VirtualBoxHypervisors konfiguriert werden. Meist können hierbei die Default-Einstellungen akzeptiert
werden.
Abb. 24.3: Wählen Sie in VirtualBox die richtige Netzwerkkarte.
• Falls die Warnung “AMD-V is disabled in the BIOS. (VERR_SVM_DISABLED).” angezeigt wird, müssen Sie im BIOS Ihres Rechners die Option “VT-X/AMD-V” aktivieren. Alternativ können Sie auch
die Beschleunigung in dder Systemkonfiguration der virtuellen Maschine abschalten.
24.2 GSM 25V
Dieser Abschnitt beschreibt die Schritte bei der Inbetriebnahme der GSM 25V virtuellen Appliance. Sie
können die folgende Checkliste für die Überwachung Ihres Fortschritts nutzen.
244
Abb. 24.4: Abschalten der Hardwarebeschleunigung in VirtualBox
Schritt
VMware ESXi 5.1
Import des OVA
Ressourcen: 2 CPUs, 4GB Ram
Tastaturlayout
DNS Konfiguration
Scan Benutzer Konto
SSL-Zertifikat
Master Key Download
Sensorkonfiguration auf dem Master
Bereitschaft
Erledigt
24.2.1 Voraussetzungen
Dieser Abschnitt führt die Voraussetzungen für den erfolgreichen Einsatz einer GSM 25 V Appliance
auf. Bitte stellen Sie sicher, dass alle Voraussetzungen erfüllt werden.
Ressourcen
Die virtuelle Appliance benötigt mindestens die folgenden Ressourcen:
• 2 virtuelle CPUs
• 4 GB RAM
Unterstützte Hypervisoren
Der GSM 25V wird nur auf dem folgenden Hypervisor unterstützt:
• VMware ESXi 5.1
Einsatz
Sie erhalten den GSM 25V als VM-Image im OVA-Format. Üblicherweise enthält das Image noch nicht
die letzten Updates und Feeds. Sie werden daher nach der Inbetriebnahme zunächst die Updates und
Feeds über den Master installieren müssen.
24.2. GSM 25V
245
Jeder GSM 25V benötigt einen einzigartigen Lizenzschlüssel. Dieser Schlüssel ist nicht vorinstalliert
und muss manuell vor der ersten Nutzung installiert werden. Sie dürfen den GSM 25V nicht klonen
und mehrere Instanzen parallel mit demselben Lizenzschlüssel betreiben. Dies kann Inkonsistenzen
und unerwünschte Seitene ekte erzeugen.
24.2.2 Import der virtuellen Appliance
Die virtuellen Appliances werden von Greenbone im Open Virtualization Appliance (OVA) Format bereitgestellt. Diese Dateien können direkt in VMWare oder VirtualBox importiert werden. Die folgenden
Szenarien werden von Greenbone unterstützt:
• GSM ONE: Oracle VirtualBox 4.3 (Linux und Microsoft Windows)
• GSM 25V: ESXi 5.1
Import im ESXi 5.1
Starten Sie den VMware ESXi 5.1 Client.
• Importieren Sie nun die OVA-Datei via File -> Deploy OVF Template (siehe Abbildung Import der
OVA-Appliance (Seite 246))
Abb. 24.5: Import der OVA-Appliance
• Wählen Sie die OVA-Datei (siehe Abbildung Geben Sie die OVA-Datei an. (Seite 246)).
Abb. 24.6: Geben Sie die OVA-Datei an.
• Bei der Anzeige der OVF-Template-Details wird der Produktname GSM25V angezeigt (siehe Abbildung Verifizieren Sie das Produkt (Seite 247)).
• Geben Sie den Namen und den Ort der VM Image-Datei an (siehe Abbildung Geben Sie den Namen
und den Ort des VM-Images an (Seite 247)).
• Wählen Sie das Festplattenformat “Thin Provision Lazy Zeroed” (siehe Abbildung Wählen Sie das
Festplattenformat. (Seite 247)).
• Prüfen Sie alle Import-Einstellungen und klicken Sie “Fertigstellen” (siehe Abbildung Prüfen Sie
alle Import-Einstellungen. (Seite 248)).
246
Abb. 24.7: Verifizieren Sie das Produkt
Abb. 24.8: Geben Sie den Namen und den Ort des VM-Images an
• Nach dem Import können Sie die virtuelle Appliance einschalten.
Als Sensor unterscheidet sich der GSM 25V von den anderen Appliances:
• Sie erzeugen keinen Web-Administrator sondern einen Scan-Benutzer-Konto.
• Sie müssen den Masterkey mit dem Sensor austauschen.
Bitte führen Sie zunächst die Schritte im Kapitel Inbetriebnahme (Seite 11) durch. Erzeugen Sie hierbei einen Scan-Benutzer anstelle eines Web-Administrator-Benutzer und fahren Sie dann mit dem
Abschnitt Sensor (Seite 212) fort um die Schlüssel mit dem Master auszutauschen.
Der GSM 25V Sensor bietet keine Weboberfläche. Sie können sich auf dem Sensor nur auf der Konsole
und via SSH vom Master anmelden. Der Sensor wird einzig vom Master verwaltet.
Falls die Kommunikation zwischen dem Master und dem Sensor fehlschlägt, müssen Sie möglicherweise den Regelsatz einer internen Firewall in Ihrem Netzwerk anpassen.
24.3 GSM 25
Dieser Abschnitt beschreibt die Schritte für die Inbetriebnahme eine GSM 25 Sensor-Appliance. Sie
können mit der folgenden Checkliste Ihren Fortschritt überwachen.
Abb. 24.9: Wählen Sie das Festplattenformat.
24.3. GSM 25
247
Abb. 24.10: Prüfen Sie alle Import-Einstellungen.
Schritt
Netzteil
Serielles Konsolenkabel / USB Adapter
Putty/Screen Konfiguration
Tastaturlayout
DNS Konfiguration
Scan Benutzer Konto
SSL-Zertifikat
Master Key Download
Sensorkonfiguration auf dem Master
Bereitschaft
Erledigt
24.3.1 Installation
Die Appliance GSM 25 kann in ein 19 Zoll Rack montiert werden und benötigt eine Höheneinheit (HE).
Das optionale RACKMOUNT25 Kit stellt die erforderlichen Winkel für die Installation in das Rack bereit. Für den Stand-Alone-Betrieb liegen 4 selbstklebende Gummifüsse bereit, die am Boden in die
Vertiefungen geklebt werden können.
Die GSM 25 Appliance verfügt über die folgenden Anschlüsse auf der Rückseite:
• Rückseite:
– Netzteil +12V DC (einmal), externes Netzteil und Kabel beigelegt
– Netzwerkschnittstelle (LAN1)
– RS-232 Konsole, passendes Kabel beigelegt
– Resetknopf
Für die Installation müssen Sie eine Terminal-Anwendung und ein serielles Kabel zur Verbindungsaufnahme nutzen.
24.3.2 Serielle Schnittstelle
Um den seriellen Anschluss zu nutzen, verwenden Sie das beigelegte Konsolenkabel. Alternativ können Sie auch ein blaues Cisco-Konsolenkabel (rollover-cable) nutzen.
Sollte Ihr System nicht einen seriellen Anschluß bieten, benötigen Sie einen USB/Seriell-Adapter. Stellen Sie sicher, dass Sie einen hochwertigen Adapter nutzen. Viele preiswerte Adapter erzeugen Fehler
im seriellen Protokoll. Außerdem sind diese Adapter möglicherweise nicht kompatibel mit den unter
Microsoft Windows verfügbaren Treibern.
Um auf den seriellen Port zuzugreifen benötigen Sie eine Terminal-Anwendung. Die Anwendung muss
auf eine Geschwindigkeit von 9600 Bits/s (Baud) eingestellt sein.
248
Unter Linux kann auf der Kommandozeile das Kommando screen genutzt werden. Hier genügt es das
Kommando unter Angabe der seriellen Schnittstelle aufzurufen.
screen /dev/ttyS0 #(for serial port)
screen /dev/ttyUSB0 #(for USB adapter)
Gelegentlich funktioniert es nicht mit der ersten seriellen Schnittstelle. Testen Sie die weiteren
Schnittstellen (0, 1 oder 2). Sie können Screen durch Eingabe von Strg-a \ beenden. Nach dem Start
des Kommandos müssen Sie möglicherweise einige Male ENTER eingeben, um einen Prompt zu erhalten.
Unter Windows können Sie Putty145 nutzen. Nach dem Start von Putty wählen Sie die Optionen wie in
Abbildung fig:putty-serial. Stellen Sie hier auch die richtige serielle Schnittstelle ein.
Abb. 24.11: Wahl der seriellen Schnittstelle in Putty
24.3.3 Einschalten
Sobald die Appliance vollständig angeschlossen wurde, Sie mit einem Konsolenkabel verbunden sind
und die Terminal-Anwendung (putty, screen o.ä.) gestartet haben, können Sie die Appliance einschalten. Die Appliance wird booten und die ersten Meldungen werden in der Terminal-Anwendung nach
einer kurzen Wartezeit erscheinen.
Da ein GSM 25 lediglich als Sensor arbeitet, unterscheidet er sich etwas von den anderen Appliances:
• Sie erzeugen keinen Web-Administrator sondern einen Scan-Benutzer-Konto.
• Sie müssen den Masterkey mit dem Sensor austauschen.
Bitte führen Sie zunächst die Schritte im Kapitel Inbetriebnahme (Seite 11) durch. Erzeugen Sie hierbei einen Scan-Benutzer anstelle eines Web-Administrator-Benutzer und fahren Sie dann mit dem
Abschnitt Sensor (Seite 212) fort um die Schlüssel mit dem Master auszutauschen.
Der GSM 25 Sensor bietet keine Weboberfläche. Sie können sich auf dem Sensor nur über die Konsole
und via SSH vom Master anmelden. Der Sensor wird nur vom Master verwaltet.
Falls die Kommunikation zwischen dem Master und dem Sensor fehlschlägt, müssen Sie möglicherweise den Regelsatz einer internen Firewall in Ihrem Netzwerk anpassen.
145
http://www.chiark.greenend.org.uk/~sgtatham/putty/
24.3. GSM 25
249
24.4 GSM 100
Dieser Abschnitt beschreibt die Schritte bei der Inbetriebnahme der GSM 100 Appliance. Die folgende
Checkliste hilft Ihnen dabei:
Schritt
Netzteil
Tastaturlayout
DNS Konfiguration
SSL-Zertifikat
Bereitschaft
Erledigt
24.4.1 Installation
Die Appliance GSM 100 kann in ein 19 Zoll Rack eingebaut werden und benötigt 1 Höheneinheit (HE).
Das optionale RACKMOUNT100-Kit stellt die benötigten Winkel für den Einbau bereit. Für den StandAlone-Betrieb können optional 4 selbstklebende Gummifüsse in die Vertiefungen des Bodens geklebt
werden.
Die GSM 100 Appliance verfügt über die folgenden Anschlüsse an der Rückseite:
• Rückseite:
– Netzteil +12V DC (einmal), externes Netzteil und Kabel beigelegt
– Netzwerkschnittstelle (LAN1)
– RS-232 Konsole, passendes Kabel beigelegt
– Resetknopf
Für die Installation müssen Sie eine Terminal-Anwendung und ein serielles Kabel zur Verbindungsaufnahme nutzen.
250
24.4.3 Einschalten
Bitte folgen Sie den Schritte in Kapitel Inbetriebnahme (Seite 11) und fahren Sie dann mit den folgenden
Abschnitten fort.
24.5 GSM 500/510/550
Dieser Abschnitt erläutert die Inbetriebnahme einer GSM 500, GSM 510 oder GSM 550 Appliance. Die
folgende Checkliste unterstützt hierbei:
146
24.5. GSM 500/510/550
251
Schritt
Netzteil
Firmware Prüfung (>= 2.0)
Tastaturlayout
DNS Konfiguration
SSL-Zertifikat
Bereitschaft
Erledigt
24.5.1 Installation
Die Appliances GSM 500, GSM 510 und GSM 550 können in ein 19 Zoll Rack eingebaut werden und benötigen 1 Höheneinheit (HE). Für die Installation in ein 19 Zoll Rack verfügen die Appliance über die
entsprechenden Winkel.
Die GSM 500, GSM 510 und GSM 550 Appliance verfügen über die folgenden Anschlüsse an der Vorderund Rückseite:
• Rückseite:
– Stromversorgung (einmal)
– VGA-Monitor
– Tastatur via USB
– Serielle Schnittstelle
• Vorderseite
– Netzwerkschnittstelle eth0
– RS-232 Konsole (|O|O|O), Cisco kompatibel, passendes Kabel ist beigefügt
Für die Installation müssen Sie eine Terminal-Anwendung und ein Konsolenkabel für den Verbindungsaufbau nutzen.
252
24.5.3 Einschalten
Firmware-Hinweis
Die Appliances GSM 500, GSM 510 und GSM 550 sind Geräte der ersten Generation. Diese Geräte wurden mit älterer Firmware ausgeliefert, die vor der Inbetriebnahme aktualisiert werden muss.
Falls die angezeigte Firmware-Version < 2.0 ist, kontaktieren Sie bitte den Greenbone Support (mailto:[email protected] ) bevor Sie fortfahren.
Abschnitten fort.
147
148
[email protected]
24.5. GSM 500/510/550
253
24.6 GSM 400/600/650
Dieser Abschnitt zeigt Ihnen die Schritte zur Inbetriebnahme einer GSM 400, GSM 600 oder GSM 650
Appliance. Die folgende Checkliste hilft Ihnen dabei:
Schritt
Netzteil
Tastaturlayout
DNS Konfiguration
SSL-Zertifikat
Bereitschaft
Erledigt
24.6.1 Installation
Die Appliances GSM 400, GSM 600 und GSM 650 können in ein 19 Zoll Rack eingebaut werden und
benötigen eine Höheneinheit (HE). Für die Installation im Rack werden die entsprechenden Winkel bereitgestellt.
Die GSM 400, GSM 600 und GSM 650 Appliances verfügen über die folgenden Anschlüsse an der
Vorder- und Rückseite:
• Rückseite:
– Stromversorgung (einmal)
– VGA-Monitor
– Serielle Schnittstelle
• Vorderseite
– Netzwerkschnittstelle eth0
254
24.6.3 Einschalten
Abschnitten fort.
24.7 GSM 5300/6400
Dieser Abschnitt beschreibt die Schritte für die Inbetriebnahme einer GSM 5300 oder GSM 6400 Appliance. Sie können die folgende Checkliste nutzen, um den Fortschritt festzuhalten.
149
24.7. GSM 5300/6400
255
Schritt
Stromversorgung (zweimal)
Tastaturlayout
DNS Konfiguration
SSL-Zertifikat
Bereitschaft
Erledigt
24.7.1 Installation
Die Appliances GSM 5300 und GSM 6400 können in ein 19 Rack eingebaut werden und benötigen 2
Höheneinheiten (HE). Die Appliance verfügen über die erforderlichen Winkel für den Einbau.
Die Appliances GSM 5300 und GSM 6400 verfügen über die folgenden Anschlüsse an der Vorder- und
Rückseite:
• Rückseite:
– Stromversorgung (zweimal)
– VGA-Monitor
• Vorderseite
– Netzwerkschnittstelle benannt “MGMT” (eth0)
256
24.7.3 Einschalten
Abschnitten fort.
150
24.7. GSM 5300/6400
257
258
KAPITEL 25
CLI Kommandoreferenz
Dieses Kapitel führt sämtliche Kommandos in alphabetischer Reihenfolge auf. Zu jedes Kommando
wird eine Kurzbeschreibung angegeben und auf die Abschnitte verwiesen, wo das Kommando genauer
betrachtet wird.
addadmin Mit diesem Befehl können Sie einen Web- bzw. Scanadministrator anlegen. Der Befehl
erwartet den Benutzernamen und das Kennwort durch einen Doppelpunkt getrennt (siehe Abschnitt Erzeugen eines Web-Administrators (Scan-Administrator) (Seite 21)).
certdownload Mit diesem Befehl können Sie einen Schlüssel und ein durch Ihre CA signiertes Zertifikat auf den GSM übertragen (siehe Abschnitt Zertifikat einer externen Zertifizierungsstelle
(Seite 23)).
commit Hiermit können Sie noch nicht aktivierte Änderungen auf der Kommandozeile bestätigen
(siehe Abschnitt Einstellungen bearbeiten (Seite 19)).
ethtool Der Befehl zeigt den aktuellen Zustand der Netzwerkkarten einschließlich Link-Status an
(siehe Abschnitt Fehlersuche und Überwachung der Netzwerkfunktionen (Seite 36)).
exit Hiermit melden Sie sich auf der Kommandozeile ab.
feedstartsync Das Kommando startet die Synchronisation des Feeds auf der Kommandozeile (siehe Abschnitt Feed Synchronisation (Seite 33)).
feedsyncstatus Hiermit kontrollieren Sie, ob in diesem Moment eine Synchronisation erfolgt (siehe Abschnitt Feed Synchronisation (Seite 33)).
feedversion Dieses Kommando zeigt die aktuelle Version. Hierbei handelt es sich um das Datum
und die Uhrzeit, z.B. 201502090646 ist 6:46 Uhr am 09.02.2015 (siehe Abschnitt Feed Synchronisation (Seite 33)).
gbfw Dies ist ein Frontend für die lokale Greenbone Firewall und nur für Experten gedacht.
getip Dieser Befehl zeigt die aktuelle IP-Konfiguration an (siehe Abschnitt Fehlersuche und Überwachung der Netzwerkfunktionen (Seite 36)).
getroute Dieses Kommando zeigt die aktuelle IP Routingkonfiguration an (siehe Abschnitt Fehlersuche und Überwachung der Netzwerkfunktionen (Seite 36)).
getusers Dieser Befehl zeigt die aktuell auf der Kommandozeile angemeldeten Benutzer an.
gos-admin-menu Dieser Befehl ruft das GOS Admin Menü auf (siehe Abschnitt Grundkonfiguration
(Seite 12)).
gsmuser Dies ist ein alternatives Kommando für die Benutzerverwaltung.
ip Mit diesem Kommando können verschiedenste Informationen der Netzwerkkonfiguration angezeigt werden (siehe Abschnitt Fehlersuche und Überwachung der Netzwerkfunktionen (Seite 36)).
ldapcacertdownload Mit diesem Kommando können Sie das Zertifikat des LDAP-Servers auf dem
GSM hinterlegen (siehe Abschnitt LDAP mit SSL/TLS (Seite 182)).
259
masterkeydownload Hiermit hinterlegen Sie auf einem Slave den Schlüssel des Masters (siehe Abschnitt Master und Slave Setups (Seite 211)).
ntpq Dieser Befehl zeigt Ihnen die Zeitsynchronisation des Systems mit externen Quellen (siehe Abschnitt Network Time Protokoll (Seite 27)).
passwd Hiermit können Sie das Kennwort des Benutzers auf der Kommandozeile ändern (siehe Abschnitt Kennwortänderung des Admin (Seite 20)).
ps Hiermit könne Sie die laufenden Prozesse anzeigen. Um alle Prozesse zu sehen, nutzen Sie ps
-ef.
reboot Hiermit lösen Sie einen Reboot der Appliance auf der Kommandozeile aus (siehe Abschnitt
Reboot und Herunterfahren der Appliance (Seite 25)).
rollback Hiermit verwerfen Sie Ihre Änderungen vor einem Commit (siehe Abschnitt Einstellungen
bearbeiten (Seite 19))
shell Nach der Anmeldung als Admin arbeiten Sie in einer Restricted-Shell. Hiermit rufen Sie von
der Kommandozeile eine vollständige UNIX-Shell auf.
show Dieser Befehl zeigt Ihnen einzelne Dateien oder den Schedule an (siehe Abschnitt Aktivierungsschlüssel (Seite 16)).
shutdown Hiermit lösen Sie das Herunterfahren der Appliance auf der Kommandozeile aus (siehe
Abschnitt Reboot und Herunterfahren der Appliance (Seite 25)).
softwarestartsync Hiermit wird die Synchronisation von System Upgrades gestartet (siehe Abschnitt Upgrade (Seite 41)).
softwaresyncstatus Hiermit prüfen Sie die Synchronisation von System Upgrades (siehe Abschnitt Upgrade (Seite 41)).
softwareversion Hiermit zeigen Sie die aktuelle Softwareversion an (siehe Abschnitt Upgrade
(Seite 41)).
sslcatkey Dieser Befehl zeigt die Zertifikatsregistrierungsanforderung für ein zu unterzeichnendes
Zertifikat an (siehe Abschnitt Zertifikat einer externen Zertifizierungsstelle (Seite 23)).
sslcatreq Wie das Kommando sslcatkey zeigt auch dieses Kommando Zertifikatsregistrierungsanforderung für ein zu unterzeichnendes Zertifikat an. (siehe Abschnitt Zertifikat einer externen
Zertifizierungsstelle (Seite 23)).
sslcatself Dieser Befehl zeigt das durch den GSM selbstsignierte Zertifikat an (siehe Abschnitt
Selbstsignierte Zertifikate (Seite 22)).
sslcheck Dieser Befehl prüft bei Zertifikaten, welche durch ein Trustcenter ausgestellt wurden, ihre
Zertifikatskette (siehe Abschnitt Zertifikat einer externen Zertifizierungsstelle (Seite 23)).
ssldownload Mit diesem Befehl können Sie ein aufgrund einer Zertifikatsregistrierungsanforderung durch Ihre CA signiertes Zertifikat auf den GSM übertragen (siehe Abschnitt Zertifikat einer
externen Zertifizierungsstelle (Seite 23) und sslreq).
sslreq Hiermit stossen Sie die Erzeugung einer Zertifikatsregistrierungsanforderung an (siehe Abschnitt Zertifikat einer externen Zertifizierungsstelle (Seite 23)).
sslselfsign Hiermit stossen Sie die Erzeugung eines durch den GSM selbst signierten Zertifikats
an (siehe Abschnitt Selbstsignierte Zertifikate (Seite 22)).
subscriptiondownload Hiermit laden Sie den Aktivierungsschlüssel auf den GSM (siehe Abschnitt
Aktivierungsschlüssel (Seite 16)).
systembackup Hiermit starten Sie das Backup des Systems (siehe Abschnitt Sicherung und Wiederherstellung (Seite 45)).
systembackupstatus Hiermit zeigen Sie den Status des Backup des Systems an (siehe Abschnitt
Sicherung und Wiederherstellung (Seite 45)).
260
Kapitel 25. CLI Kommandoreferenz
systemfeedbackup Hiermit starten Sie das Backup des Feeds (siehe Abschnitt Sicherung und Wiederherstellung (Seite 45)).
systemfeedbackupstatus Hiermit zeigen Sie den Status des Backup des Feeds an (siehe Abschnitt
Sicherung und Wiederherstellung (Seite 45)).
systemrecoverybackup Hiermit führen Sie eine Rücksicherung durch (siehe Abschnitt Sicherung
und Wiederherstellung (Seite 45)).
systemrecoverybackupstatus Hiermit zeigen Sie den Status einer Rücksicherung an (siehe Abschnitt Sicherung und Wiederherstellung (Seite 45)).
systemrecoverysnapshot Hiermit führen Sie eine Rücksicherung eines Snapshots durch (siehe
Abschnitt Snapshot des Systems (Seite 47)).
systemrecoverysnapshotstatus Hiermit zeigen Sie den Status einer Rücksicherung eines
Snapshots an (siehe Abschnitt Snapshot des Systems (Seite 47)).
systemsnapshot Hiermit erzeugen Sie einen Snapshot (siehe Abschnitt Snapshot des Systems (Seite 47)).
systemsnapshotstatus Hiermit zeigen Sie den Snapshotstatus an (siehe Abschnitt Snapshot des
Systems (Seite 47)).
systemupgrade Hiermit starten Sie ein Upgrade (siehe Abschnitt Upgrade (Seite 41)).
systemupgradestatus Hiermit zeigen Sie den Upgrade-Status an (siehe Abschnitt Upgrade (Seite 41)).
systemuserdatabackup Hiermit führen Sie ein Backup der Benutzerdaten durch (siehe Abschnitt
Backup der Userdata mit USB-Stick (Seite 47)).
systemuserdatabackupstatus Hiermit zeigen Sie den Status des Backups der Benutzerdaten an
(siehe Abschnitt Backup der Userdata mit USB-Stick (Seite 47)).
261
262
Kapitel 25. CLI Kommandoreferenz
KAPITEL 26
CLI Einstellungsreferenz
Dieses Kapitel führt sämtliche Einstellungen in alphabetischer Reihenfolge auf. Zu jeder Einstellung
wird eine Kurzbeschreibung angegeben und auf die Abschnitte verwiesen, wo die Einstellung genauer
betrachtet wird.
address_ethX_ipv4 IPv4 Adresse der Netzwerkkarte Ethernet-X mit Netzmaske. Alternativ kann
hier der Wert dhcp stehen. In Abhängigkeit der Appliance kann X einen Wert zwischen 0 und 19
annehmen. Siehe Abschnitt IP-Adressen (Seite 26). Die Angabe einer IPv4 Adresse für die Netzwerkkarte Ethernet-0 ist verpflichtend alle weiteren IP-Adressen sind optional.
address_ethX_ipv6 Dies ist die IPv6 Adresse der Ethernet-X Schnittstelle. Siehe Abschnitt IPAdressen (Seite 26). Die Angabe ist optional.
airgap Default: disabled Dies ist die Rolle in einem Airgap Synchronisationsszenario. Die möglichen Werte sind: disabled, master oder slave. Siehe Abschnitt Airgap Update (Seite 51).
airgap_ftp_location Default: nicht gesetzt Die Adresse des FTP-Servers für die Airgap Synchronisation. Hierbei kann auch ein Verzeichnis mitangegeben werden (Beispiel:
your.ftp.server/subdirectory). Siehe Abschnitt Airgap Update (Seite 51).
airgap_ftp_password Default: nicht gesetzt Dies ist dass Passwort, mit dem die Anmeldung auf
dem FTP-Server für die Airgap-Funktionalität erfolgt. Siehe Abschnitt Airgap Update (Seite 51)
airgap_ftp_user Default: nicht gesetzt Die ist der Benutzername, mit dem die Anmeldung auf dem
FTP-Server für die Airgap-Funktionalität erfolgt. Siehe Abschnitt Airgap Update (Seite 51).
airgap_type Default: usb Dies ist die Airgap-Methode. Mögliche Werte sind ftp und usb. Siehe
Abschnitt Airgap Update (Seite 51).
autoslavesync Default: disabled Diese Variable entscheidet, ob Slaves automatisch vom Master mit NVT-Feeds im Push-Verfahren versorgt werden. Mögliche Werte sind enabled und
disabled. Siehe Abschnitt Master und Slave Setups (Seite 211).
default_route_ipv4 Default: nicht gesetzt Dies ist die Default-Route für IPv4. Per Default ist das
System via DHCP konfiguriert. Dann wird die Default-Route auch via DHCP bezogen. Siehe Abschnitt Default Gateway (Seite 27). Die Angabe ist optional.
dns1 Default: 8.8.8.8 Dies ist der erste Nameserver, der von dem GSM verwendet wird. Ist dieser Nameserver ausgefallen, wird der zweite Nameserver genutzt. Als Wert ist nur eine IPv4Adresse erlaubt. IPv6 Nameserver werden noch nicht unterstützt. Der Default-Wert ist ein DNSServer von Google. Siehe Abschnitt DNS-Server (Seite 26).
dns2 Default: 8.8.4.4 Dies ist der zweite Nameserver, der von dem GSM verwendet wird. Diese Angabe ist optional. Ist dieser Nameserver ausgefallen, wird der dritte Nameserver genutzt. Als
Wert ist nur eine IPv4-Adresse erlaubt. IPv6 Nameserver werden noch nicht unterstützt. Der
Default-Wert ist ein DNS-Server von Google. Siehe Abschnitt DNS-Server (Seite 26).
dns3 Default: nicht gesetzt Dies ist der dritte Nameserver, der von dem GSM verwendet wird. Diese
Angabe ist optional. Ist dieser Nameserver ausgefallen, ist eine Namensauflösung nicht möglich.
263
Als Wert ist nur eine IPv4-Adresse erlaubt. IPv6 Nameserver werden noch nicht unterstützt.
Siehe Abschnitt DNS-Server (Seite 26).
domainname Default: greenbone.net Dies ist die Domäne der Appliance. Durch Voranstellen des
Hostnamens ergibt sich der vollqualifizierte Name der Appliance. Siehe Abschnitt domainname
(Seite 25).
fancontrol Default: enabled Hiermit steuern Sie das Lüfterverhalten. Ist die Funktionalität aktiviert, so werden die Lüfter nur bei Bedarf eingeschaltet. Mögliche Werte sind enabled und
disabled. See section domainname (Seite 25).
feedfrommaster Default: disabled Diese Variable definiert, ob der Slave Feeds vom Master erwartet und entgegennimmt. Mögliche Werte sind enabled oder disabled. Siehe Abschnitt
Master und Slave Setups (Seite 211).
feedsync Default: enabled Diese Variable definiert, ob eine Synchronisation mit Greenbone Security Feed erfolgt. Mögliche Werte sind enabled und disabled. Siehe Abschnitt Feed Synchronisation (Seite 33).
guest_login Default: disabled Diese Variable schaltet den Gast-Zugri über das Webinterface
ein bzw. aus. Mögliche Werte sind enabled und disabled. Siehe Abschnitt Gastanmeldung
(Seite 175).
guest_password Default: nicht gesetzt Diese Variable definiert das Kennwort für den Gastzugri .
Siehe Abschnitt Gastanmeldung (Seite 175).
guest_user Default: nicht gesetzt Diese Variable definiert den Benutzernamen für den Gastzugri .
Siehe Abschnitt Gastanmeldung (Seite 175).
hostname Default: gsm Dies ist der Rechnername der Appliance. Durch Anfügen der Domäne ergibt
sich der vollqualifizierte Name der Appliance. Siehe Abschnitt hostname (Seite 25).
ifadm Default: all Dies ist die Netzwerkkarte, über die auf die Weboberfläche und die SSHSchnittstelle zugegri en werden darf. Mögliche Werte sind all oder die spezifische Netzwerkkarte (z.B. eth0). Siehe Abschnitt Management Netzwerkschnittstelle (Seite 14).
ipv6support Default: enabled Mit dieser Variable kann die IPv6-Unterstützung ein- und ausgeschaltet werden. Bei eingeschalteter IPv6-Unterstützung erzeugt der GSM Link-Local IPv6
Adressen. Mögliche Werte sind enabled und disabled. Siehe Abschnitt IP-Adressen (Seite 26).
keyboard_layout Default: DE Hiermit konfigurieren Sie das Tastaturlayout für die CLI-Schnittstelle.
Mögliche Werte sind: DE, ES, FR, IT, PL, SE, UK und US. Siehe Abschnitt Tastaturlayout (Seite 12).
mailhub Default: mail.example.com Der GSM kann E-Mails z.B. mit Berichten versenden. Hierzu
wird der in dieser Einstellung angegebene Mailserver verwendet. Als Wert sollte ein vollqualifizierter DNS-Name angegeben werden. Siehe Abschnitt Mail-Server (Seite 27).
netmode Default: default Hiermit wählen Sie den Netzwerkkonfigurationsmodus aus. Mögliche
Werte sind default und expert. Siehe Abschnitt Experten Netzwerkkonfiguration (Seite 29).
ntp_server1 Dies ist der erste NTPv5 Zeitserver. Als Wert wird hier eine IPv4-Adresse erwartet.
Siehe Abschnitt Network Time Protokoll (Seite 27).
ntp_server2 Dies ist der zweite NTPv5 Timeserver. Die Angabe des zweiten NTP-Servers ist optional. Siehe Abschnitt Network Time Protokoll (Seite 27).
omp_ciphers Default:
SECURE128:-AES-128-CBC:-CAMELLIA-128-CBC:-VERS-SSL3.0:-VERS-TLS1.0
Selects the TLS cipher supported by OMP. The syntax of this cipher priority string is the one of
“GNUTLS” and documented here: http://gnutls.org/manual/html_node/Priority-Strings.html .
See section OpenVAS Management Protocol (OMP) (Seite 33).
proxy_credentials Default: nicht gesetzt Der GSM kann seine Feeds über eine HTTP-Proxy beziehen. Wenn der Proxy eine Authentifizierung erwartet, können in dieser Variable Benutzernamen und Kennwort hinterlegt werden (username:password). Siehe Abschnitt Proxy Konfiguration (Seite 34).
264
Kapitel 26. CLI Einstellungsreferenz
proxy_feed Default: nicht gesetzt Der GSM kann seine Updates und die Feeds via Proxy beziehen.
Mit dieser Einstellung kann der HTTP-Proxy konfiguriert werden. Siehe Abschnitt Proxy Konfiguration (Seite 34).
public_omp Default: disabled Hiermit schalten Sie den OMP-Zugri auf Port 9390 ein bzw. aus.
Siehe Abschnitt OpenVAS Management Protocol (OMP) (Seite 33).
selfsigssl Default: enabled Diese Einstellung erlaubt die Erzeugung und Verwendung von selbstsignierten Zertifikaten für die Authentifizierung des GSM. Siehe Abschnitt Selbstsignierte Zertifikate (Seite 22).
sensors Default: nicht gesetztDies ist eine Liste der durch den GSM verwalteten Sensoren. Diese
Liste wird durch Leerzeichen separiert. Siehe Abschnitt Sensor (Seite 212).
snmp Default: disabled Diese Einstellung erlaubt den Zugri
schnitt SNMP (Seite 28).
von außen via SNMP v3. Siehe Ab-
snmp_contact Default: Greenbone_Unspecified_contact Dies ist der in der SNMP-Ausgabe
angegebene Kontakt. Siehe Abschnitt SNMP (Seite 28).
snmp_key Default: nicht gesetzt Dies ist das Privacy Kennwort für SNMPv3 Anfragen. Das Kennwort
muss mindestens 8 Zeichen lang sein. Siehe Abschnitt SNMP (Seite 28).
snmp_location Default: Hildesheim Dies ist der in der SNMP-Ausgabe angegebene Ort. Siehe Abschnitt SNMP (Seite 28).
snmp_password Default: nicht gesetztDies ist das Authentifizierungskennwort für SNMPv3 Anfragen. Das Kennwort muss mindestens 8 Zeichen lang sein. Siehe Abschnitt SNMP (Seite 28).
snmp_trap Default: disabled Hiermit aktivieren Sie das Versenden von SNMP Traps. Siehe Abschnitt SNMP (Seite 28).
snmp_trapcommunity Default: public Hiermit definieren Sie den Community String für SNMP
Traps. Siehe Abschnitt SNMP (Seite 28).
snmp_trapreceiver Default: 192.168.0.1 Hiermit konfigurieren Sie die Empfänger der SNMP
Traps. Siehe Abschnitt SNMP (Seite 28).
snmp_user Default: nicht gesetztDies ist der Benutzername für SNMPv3 Abfragen. Siehe Abschnitt
SNMP (Seite 28).
ssh Default: disabled Dies ist der Zustand des SSH-Servers. Mögliche Werte sind enabled und
disabled. Siehe Abschnitt SSH-Zugang (Seite 33).
superuser Default: disabled Hiermit können Sie den Superuser-Zugang via SSH für Debuggingzwecke aktivieren. Mögliche Werte sind enabled und disabled. Siehe Abschnitt Superuser
(Seite 21).
superuserpassword Default: disabled Wenn der Superuser aktiviert wurde, können Sie hiermit
dessen Kennwort einstellen. Mögliche Werte sind disabled oder ein 8-Zeichen langes Kennwort. Siehe Abschnitt Superuser (Seite 21).
syncport Default: 24 Dies ist der Port für die Synchronisation mit dem Greenbone Security Feed.
Mögliche Werte sind 24 oder 443. Siehe Abschnitt Feed Synchronisation (Seite 33).
synctime Default: 06:25 Dies ist die Uhrzeit für die tägliche Synchronisation des Greenbone Security Feed. Das Format wird in HH:MM in der UTC-Zeitzone angegeben. Zwischen 10:00 und 13:00
Uhr ist eine Synchronisation nicht möglich. Siehe Abschnitt Feed Synchronisation (Seite 33).
syslog_server1 Default: nicht gesetztDies ist der erste Syslog-Server. Siehe Abschnitt Zentraler
Protokollserver (Seite 28).
syslog_server2 Default: nicht gesetztDies ist der zweite Syslog-Server. Siehe Abschnitt Zentraler
Protokollserver (Seite 28).
web_ciphers Default:
SECURE128:-AES-128-CBC:-CAMELLIA-128-CBC:-VERS-SSL3.0:-VERS-TLS1.0 Select
the supported SSL/TLS cipher. See section Zentraler Protokollserver (Seite 28).
265
web_interface Default: classic Dies ist das aktuelle Webinterface. Siehe Abschnitt Alternative
Oberflächen (Seite 167).
webtimeout Default: 15 Dies ist das Timeout der HTTPS Browser Sitzung in Minuten. Siehe Abschnitt
HTTPS Timeout (Seite 32).
266
Kapitel 26. CLI Einstellungsreferenz
KAPITEL 27
Häufig gestellte Fragen
Dieser Abschnitt sammelt häufig gestellte Fragen mit den passenden Antworten.
27.1 Was ist der Unterschied zwischen Scan-Sensor und ScanSlave?
Ein Scan-Slave wird durch einen Scan-Master gesteuert, um Schwachstellen-Scans auszuführen.
Scans für Scan-Slaves werden im Scan-Master durch Anwender je nach Bedarf und Berechtigung individuell konfiguriert. GSM’s ab Midrange-Klasse aufwärts können als Scan-Master arbeiten und einen
oder mehr Scan-Slaves steuern. Jeder GSM kann auch als Scan-Slave arbeiten. Für jeden Scan-Slave
muss separat dafür Sorge getragen werden, dass Feed-Updates und Release-Updates ausgeführt
werden.
Ein Scan-Sensor ist ein GSM der ausschließlich für die Funktion als Scan-Slave gedacht ist und außerdem vollständig durch einen zugeordneten Sensor-Master gemanaged wird. Dieses Management
beinhaltet sowohl die automatische Aktualisierung des Feeds als auch automatische Release Updates. Im Besonderen benötigt ein Sensor keinerlei Netzwerk-Verbindungen außer zu seinem SensorMaster und, einmal eingerichtet, keinerlei administrative Arbeit.
27.2 Scan-Vorgang sehr langsam
Die Geschwindigkeit eines Scans hängt von vielen Faktoren ab.
• Es wurden mehrere Port-Scanner gleichzeitig aktiviert.
Wenn Sie eine individuelle Scan-Config verwenden, achten Sie darauf, dass nur ein Port-Scanner
in der Familie “Port Scanner” eingeschaltet ist. “Ping Host” darf natürlich trotzdem aktiviert sein.
• Unbelegte IP-Adressen werden zeitintensiv gescannt.
In einer ersten Phase wird festgestellt ob hinter den IP-Adressen aktive Systeme vorliegen. Ist
das nicht der Fall, so werden sie auch nicht gescannt. Durch Firewalls und andere Systeme kann
eine eindeutige Erkennung behindert werden. Das NVT “Ping Host” (1.3.6.1.4.1.25623.1.0.100315)
bietet Möglichkeiten zum Finetuning an.
27.3 Scan löst Alarm bei anderen Sicherheits-Tools aus
Bei vielen Schwachstellenprüfungen wird das Verhalten eines echten Angreifers durchgespielt. Zwar
findet kein tatsächlicher Angri statt, aber es gibt Sicherheits-Tools die Alarm schlagen könnten.
Bekannte Beispiele sind:
267
• Symantec meldet einen Angri bzgl. CVE-2009-3103 wenn das NVT “Microsoft Windows SMB2 ‘_Smb2ValidateProviderCallback()’ Remote Code Execution Vulnerability”
(1.3.6.1.4.1.25623.1.0.100283) ausgeführt wird. Dieses NVT wird aber nur ausgeführt wenn
“sichere Prüfungen” in der Scan Configuration ausgeschaltet wird, da es das Zielsystem bei
Vorliegen der Schwachstelle beeinträchtigen könnte.
27.4 Auf gescannten Zielsystemen erscheint VNC Dialog
Beim Test von Port 5900 bzw. des konfigurierten VNC Port, erscheint ein Fenster auf dem Ziel, das den
Benutzer au ordert die Verbindung zu erlauben. Beobachtet wurde das für UltraVNC Version 1.0.2.
Lösung: Port 5900 bzw. den am Server definierten VNC Port vom Scan ausschließen. Alternativ kann
man auch auf die neuste Version des UltraVNC wechseln (UltraVNC 1.0.9.6.1 verwendet nur noch ein
Ballon).
27.5 Nach Factory Reset funktioniert weder Feed-Update noch
System-Upgrade
(Dies gilt nicht für virtuelle Appliances für die kein Factory Reset integriert ist)
Ein Factory Reset löscht das gesamte System inklusive des Subskriptions-Schlüssels. Dieser ist aber
sowohl für Feed-Update als auch System-Upgrade notwendig.
1. Subskriptions-Schlüssel reaktivieren:
Im Lieferumfang von GSM Appliances ist ein Rettungsschlüssel enthalten. Dieser befindet sich
in der Regel auf einem USB-Stick und ist gekennzeichnet mit der Schlüssel-ID. Verwenden Sie
diesen um den GSM wieder zu reaktivieren. Beschrieben wird die Aktivierung im Kapitel Inbetriebnahme.
2. System auf aktuellen Stand bringen:
Je nach Aktualität des Factory-Rettungssystems ist nun ein Upgrade-Verfahren zu durchlaufen.
268
Kapitel 27. Häufig gestellte Fragen
KAPITEL 28
Glossar
Dieser Abschnitt definiert relevante Begri e die konsistent im gesamten System verwendet werden.
28.1 Host
Ein Host (Rechner) ist ein einzelnes System, welches mit einem Computer-Netzwerk verbunden ist
und das gescannt werden kann. Ein oder viele Hosts bilden die Grundlage für ein Scan-Ziel.
Ein Host ist auch ein Asset-Typ. Jeder gescannte oder auch nur gefundene Host kann in die AssetDatenbank aufgenommen werden.
Hosts in Scan-Zielen und Scan-Berichten werden anhand ihrer Netzwerkadresse identifiziert, entweder der IP-Adresse oder dem Host-Namen.
28.2 Quality of Detection (QoD)
Die Quality of Detection (QoD) ist ein Wert zwischen 0% und 100% und beschreibt die Verlässlichkeit
der ausgeführten Schwachstellen-Detektion oder Produkt-Detektion.
Dieses Konzept lösst zudem die Herausforderung sogenannter potentieller Schwachstellen. Solche
Funde werden grundsätzlich immer in der Datenbank abgelegt aber nur auf explizite Anfrage sichtbar.
Während der QoD-Bereich eine sehr feingranulare Einstufung der Qualität erlaubt, basieren die meisten Prüf-Routinen jedoch auf einer Standard-Methode. Dafür werden die QoD Typen mit einem bestimmten QoD-Wert verbunden und dann entsprechend verwendet. Die aktuelle Typen-Liste kann
mit der Zeit erweitert werden.
269
QoD
100%
QoD-Typ
exploit
99%
remote_vul
98%
remote_app
97%
package
97%
registry
95%
remote_active
80%
remote_banner
80%
executable_version
75%
70%
remote_analysis
50%
remote_probe
30%
remote_banner_unreliable
30%
executable_version_unreliable
1%
general_note
Beschreibung
Die Detektion wurde via einer tatsächlichen Ausnutzung der Schwachstelle ausgeführt und ist damit voll verifiziert.
Aktive Prüfung aus der Ferne (Code-Ausführung,
Traversal Attack, SQL Injektion etc.) bei der die Antwort eindeutig das Vorhandensein der Schwachstelle zeigt.
Aktive Prüfung aus der Ferne (Code-Ausführung,
Traversal Attack, SQL Injektion etc.) bei der die Antwort eindeutig das Vorhandensein der verletzlichen Anwendung zeigt.
Authentifizierte paket-basierte Prüfung für Linux(oide) Systeme.
Authentifizierte registry-basierte Prüfungen für
Windows-Systeme.
Aktive Prüfungen aus der Ferne (Code-Ausführung,
Traversal Attack, SQL Injektion etc.) bei der die Antwort auf das wahrscheinliche Vorhandensein der
Schwachstelle oder des verwundbaren Produktes
hinweist. “Wahrscheinlich” bedeutet hier, dass nur
in selten Fällen ein Irrtum der Detektion vorkommt.
Prüfung aus der Ferne für eine Anwendung die den
Patch-Status als Information anbietet. Das kommt
bei vielen proprietären Produkten vor.
Authentifizierte Prüfung bei der über eine ausführbare Datei die Version abgefragt wird. Dies funktioniert für Anwendungen sowohl für Linux(oide)
als auch Windows Systeme, sofern sie den PatchStatus in der Version anbieten.
Dieser Wert wurden wurde allen Scan-Ergebnissen
während der System-Migration zugeordnet. Es
kann aber auch NVTs geben die diesen Wert aus anderen Gründen haben.
Prüfung aus der Ferne welche einigen Analysieren
durchführt die nicht in jedem Fall zuverlässig sind.
Prüfung aus der Ferne bei der Systeme zwischen
Scanner und Zielsystem wie beispielsweise eine Firewall eine Antwort vortäuschen ohne dass die eigentlich zu scannende Anwendung selbst antworten konnte. So etwas kann insbesondere bei unverschlüsselten Verbindungen (ohne TLS) vorkommen.
Banner-Prüfungen aus der Ferne für Anwendungen
die keinen Patch-Status als Versions-Information
anbieten. Dies kommt oft für Open Source Produkte vor die über sogenannte Backport-Patches gepflegt werden.
Authentifizierte Prüfungen von ausführbaren Programmen die keine Patch-Information über die
Versions-Information anbieten.
Allgemeine Notiz zu einer Verwundbarkeit ohne
konkret festgestellte Präsens der Anwendung.
Der Wert von 70% ist das voreingestellte Minimum des voreingestellten Filters für die ErgebnisAnsicht.
270
Kapitel 28. Glossar
28.3 Schweregrad
Der Schweregrad ist ein Wert zwischen 0.0 (keine Bedrohung) und 10.0 (höchste Bedrohungsstufe)
und beschreibt gleichzeitig auch die Schweregrad-Klasse (Keine, Niedrig, Mittel oder Hoch).
Dieses Konzept basiert auf CVSS, wird aber auch dort angewandt, wo kein CVSS Base Vector verfügbar
ist. Zum Beispiel können Werte aus diesem Bereich auch ohne Vektor-Definition für Übersteuerungen
oder bei OSP Scannern verwendet werden.
Vergleich, Gewichtung und Priorisierung ist für sämtliche Ergebnisse und NVTs möglich, weil das
Schweregrad-Konzept strikt über das gesamte System eingehalten wird. So wird beispielsweise in
keinem einzigen Fall der Schweregrad lediglich als “Hoch” definiert, es steht immer ein passender Wert
dahinter. Jedes neue NVT erhält einen vollständigen CVSS Vektor, selbst dann, wenn die zugehörige
CVE keinen anbietet. Ebenso werden sämtliche Ergebnisse von OSP Scannern mit einem passenden
Wert versehen, selbst dann wenn der dahinter stehende Scanner ein anderes Schema für den Schweregrad verwendet.
Die Schweregrad-Klassen Keine, Niedrig, Medium und Hoch werden durch Unterbereiche des Hauptbereichs 0,0-10,0 definiert. Anwender können für die Ansicht zwischen verschiedenen SchweregradKlassen wählen. Voreingestellt ist die NVD-Klassifikation als gebräuchlichste Klassifikation.
Scan-Resultaten wird ein zum Zeitpunkt des Scannens gültiger Schweregrad zugeordnet. Der Schweregrad von NVTs kann sich mit der Zeit allerdings ändern. Anwender können durch die Konfiguration
des Dynamischer Schweregrad dafür sorgen, dass bei der Darstellung von Ergebnissen immer der aktuellste Wert des zugehörigen NVTs verwendet wird.
28.4 Solution Type
Diese Information zeigt die möglichen Lösungswege für die Beseitigung der Schwachstelle. Derzeit
sind fünf Varianten verfügbar:
•
Workaround: Es sind Informationen verfügbar, wie mit einer Konfiguration oder einem bestimmten Einsatzszenario verhindert werden kann, die Schwachstelle zu entblößen. Im Allgemeinen kann es keinen, einen oder auch viele Workarounds geben. Es ist typischerweise die “erste Verteidigungslinie” gegen eine Schwachstelle, bevor eine Mitigation oder ein Produkt-Update
des Herstellers verö entlicht wird.
•
Mitigation: Es sind Informationen verfügbar, wie mit einer Konfiguration oder einem bestimmten Einsatzszenario das Risiko vermindert werden kann, ohne dass aber die eigentliche Verwundbarkeit des Produktes behoben wird. Mitigationen beinhalten möglicherweise Geräte oder
Zugangskontrolle außerhalb des betro enen Produktes. Mitigationen werden manchmal vom
Autor des betro enen Produktes, aber auch von Anderen verö entlicht und sie sind möglicherweise oziell durch den Verö entlichenden sanktioniert.
•
Vendor-Fix: Es sind Informationen über eine Lösung verfügbar, die direkt vom Autor des betro enen Produktes stammen. Sofern nicht anders vermerkt, beseitigt die Lösung das Problem
vollständig.
•
None-Available: Aktuell ist keine Lösung verfügbar. Weitergehende Informationen geben Hinweise warum keine Lösung existiert.
•
WillNotFix: Es ist keine Lösung für das Problem vorhanden und es wird auch keine geben.
Solche Fälle liegen oft dann vor, wenn das Produkt verwaist, abgekündigt oder auf andere Weise
ausgelaufen ist. Weitergehende Informationen sollten Details dazu geben, warum keine Lösung
mehr erwartet wird.
28.3. Schweregrad
271
272
Kapitel 28. Glossar
A
Advisory, 202
Airgap, 42
Alert, 64, 137
Alerts, 228
Art der Lösung, 195
B
Benachrichtigung, 28
BSI IT-Baseline, 216
C
CERT-Bund, 193
Common Platform Enumeration, 196
Common Vulnerability Scoring System, 200
Compliance, 216
Container Task, 68, 94
CPE, 193, 196
CVE, 193
CVSS, 200
D
Default Gateway, 14
Delta-Report, 92
DFN, 202
DFN-CERT, 193, 202
DNS Server, 14
Dynamischer Schweregrad, 271
E
eth0, 12
F
False Positive, 88
Firewallregeln, 14
G
GOS Admin Menu
Add Group, 75
Add OSP w3af Scanner, 231
Add Super Admin, 176
Add Web Admin, 15, 212
Advanced, 35, 231
Airgap management, 52, 53
Airgap role, 54
Airgap type, 53
Automatic Sensor Sync, 213
Automatic Sync, 213
Backup, 46, 48–50
Backup server address, 51
Backup server fingerprint, 51
Backup server password, 50
Backup server user, 50
Commit, 12, 14, 167, 175, 213
Configure Server, 50
Copy Userdata from USB, 49
Copy Userdata to USB, 48
Create System Backup, 46
Credentials, 45
Database statistics, 35
Database statistics log, 35
Default Route, 14
DNS, 13
Email, 13
ETH, 13, 14
eth0, 14
Feed, 33, 52, 213
Feed from Master, 213
Feed‘Option aus. Wählen Sie dann die Option
:gos:menu:‘Proxy Feed, 44
FTP location, 54
FTP password, 54
FTP user, 54
GSM Admin, 14
Guest login, 175
Guest User, 175
HTTPS Timeout, 32
HTTPS web interface, 167
Keyboard‘mit den Pfeiltasten aus und bestätigen sie mit :kbd:‘Enter, 12
Network, 13, 14, 28
NTP, 13
OMP, 33, 185, 212
Refresh, 44
Remote, 19, 28, 32, 33, 167, 185, 212
Remote backup directory, 51
Restore from Partition, 46
Restore System Backup, 46
Restore Userdata, 50
273
Rollback, 12
Scanner Management, 35, 231
Self-Signed, 16, 22
SelfCheck, 17
Sensors, 213, 214
Show USB contents, 48
SNMP, 13, 28
SNMP Configuration, 28
SSH, 33
SSH Fingerprint, 19
SSL, 16, 22
Switch Release, 44
Sync, 42, 43
Synchronize sensors, 214
Synctime, 54
Test FTP, 54
Upgrade, 42–44
Upgrade sensors, 214
User, 14, 15, 175, 176, 212
Userdata Backup, 48, 51
GOS Commands
addadmin, 21, 259
certdownload, 24, 259
check_omp, 223
Commit, 25
commit, 20, 23, 30, 259
ethtool, 38, 259
exit, 259
feedstartsync, 34, 259
feedsyncstatus, 34, 259
feedversion, 34, 259
gbfw, 259
get, 20
getip, 36, 37, 259
getroute, 36, 37, 259
getusers, 259
gos-admin-menu, 12, 259
gsmuser, 259
ip, 36, 259
ldapcacertdownload, 259
ldapcertdownload, 182, 183
masterkeydownload, 212, 260
ntpq, 27, 36, 260
omp, 186
passwd, 20, 260
ps, 260
reboot, 25, 260
rollback, 20, 260
set, 20
shell, 21, 30, 260
show, 260
show customer, 16
show masterkey, 212
show schedule, 33
shutdown, 25, 260
snmpwalk, 29
softwarestartsync, 260
softwaresyncstatus, 260
274
softwareversion, 42, 260
sslcatkey, 24, 260
sslcatreq, 260
sslcatself, 23, 260
sslcheck, 260
ssldownload, 24, 260
sslreq, 23, 260
sslselfsign, 260
subscriptiondownload, 17, 260
systembackup, 260
systembackupstatus, 260
systemfeedbackup, 261
systemfeedbackupstatus, 261
systemrecoverybackup, 261
systemrecoverybackupstatus, 261
systemrecoverysnapshot, 261
systemrecoverysnapshotstatus, 261
systemsnapshot, 47, 261
systemsnapshotstatus, 261
systemupgrade, 33, 261
systemupgradestatus, 33, 261
systemuserdatabackup, 261
systemuserdatabackupstatus, 261
tar
xvC
/tmp/
testfiles_checksum_check.tar.gz, 105
unset, 20, 26
GOS Variables
|, 98, 101, 103
address_ethX_ipv4, 26, 263
address_ethX_ipv6, 26, 263
airgap, 263
airgap_ftp_location, 263
airgap_ftp_password, 263
airgap_ftp_user, 263
airgap_type, 263
autoslavesync, 263
default_route_ipv4, 27, 263
dns1, 26, 263
dns2, 26, 263
dns3, 26, 263
domainname, 25, 264
fancontrol, 264
feedfrommaster, 264
feedsync, 33, 264
guest_login, 175, 264
guest_password, 264
guest_user, 264
hostname, 25, 264
ifadm, 14, 264
ipv6support, 26, 264
keyboard_layout, 12, 264
mailhub, 27, 264
netmode, 264
ntp_server1, 27, 264
ntp_server2, 27, 264
omp_ciphers, 264
proxy_credentials, 34, 264
proxy_feed, 34, 265
public_omp, 33, 212, 265
selfsigssl, 23, 265
sensors, 265
snmp, 28, 265
snmp_contact, 28, 265
snmp_key, 28, 29, 265
snmp_location, 28, 265
snmp_password, 28, 29, 265
snmp_trap, 28, 265
snmp_trapcommunity, 28, 265
snmp_trapreceiver, 29, 265
snmp_user, 28, 29, 265
ssh, 33, 213, 265
superuser, 21, 265
superuserpassword, 21, 265
syncport, 33, 265
synctime, 33, 34, 265
syslog_server1, 28, 265
syslog_server2, 28, 265
web_ciphers, 265
web_interface, 266
webtimeout, 266
GOS WebUI
Administration, 40, 171, 173, 174
Alerts, 228
Aufgaben, 163
Auth. DN, 181
Autogenerate Credential, 82
Benachrichtigungen, 139
Browse, 99, 101, 104, 108
Configuration, 60, 83, 95, 149, 151, 153, 159,
167, 179, 180, 228, 236, 237
Container Task, 68
CPE-based Policy Check, 111
Credentials, 72, 110
CVSS-Calculator, 201
Done, 109, 110, 112, 115
Ergebnisse, 71
Extras, 191, 201, 208
File Checksum: Errors, 104
File Checksum: Violations, 104
File Checksums, 103
File Checksums: Violations, 103
File Content, 98
Filters, 149
Full and Fast, 107
Group, 66
Groups (optional), 40, 172
Host Access, 40, 172
Interface Access, 41, 173
Konfiguration, 139, 160, 162
LDAP Host, 182, 183
Login Name, 40, 172
My Settings, 146, 191
Network Vulnerability Test Preferences, 107
New Note, 85
New Target, 60
Notes, 87
NVTs, 149
Password, 40, 172
Performance, 208
Permissions, 179, 180
Policy, 105, 107
Replace existing file with:, 99, 101, 104
Report Formats, 95, 167
Role, 66
Roles, 173
Roles (optional), 40, 172
Save Config, 99, 101, 104, 108, 110
Scan Configs, 151, 153, 167, 237
Scan Konfigurationen, 162
Scan Management, 63, 66, 71, 87, 91, 108, 110,
112
Scan-Konfigurationen, 160
Scan-Management, 161, 163
Scanner, 162
Scanner Preferences, 154
Scanners, 159, 236
Schedules, 83
SecInfo Management, 149, 193, 204
Switch Filter, 149
Tasks, 63, 66, 91
Upload file, 99, 101, 104, 108
User, 66
Windows Registry Check, 101
Windows Registry Check: Violations, 101
Greenbone Security Explorer, 93
Greenbone Security Feed, 195
GSM 100, 5
GSM 25, 5
GSM 25V, 5
GSM 400, 4
GSM 500, siehe GSM 600
GSM 5300, 3
GSM 600, 4
GSM 6400, 3
GSM 650, 4
GSM ONE, 6
Guest, 175
H
Host, 269
I
IPS, 226
ISMS, 216
ISO 27001, 216
ISO 27005, 216
L
LAN1, 13
LCD-Display
Airgap Master U1 updating USB..., 53
Airgap Master U2 USB stick ready, 53
275
Airgap Slave DL1 updating from USB., 53
Airgap Slave S0 ......., 53
USB MEM PRESEND ok to remove
., 53
USB MEM PRESENT ok to remove
., 53
Link-Status, 38
list of routes, 37
Liste der IP-Adressen, 37
Liste der Netzwerkkarten, 37
Liste der Routen, 37
M
Mitre, 198
Multisite, 224
N
Nagios, 223
NASL wrapper, 154
Network Intrusion Detection System, 226
Network Vulnerability Test, 85, 195
NIDS, 226
Nmap, 154, 155
Note, 85
NTP, 27
NVT, 85, 151, 193
NVT-Familien, 151
O
OMP, 39, 171, 185
OMP Commands
create_target, 186
Open Monitoring Distribution, 223
Open Vulnerability and Assessment Language,
198
OpenVAS Management Protocol, 185
OVAL Definition, 193
Override, 70, 87
P
Permissions
authenticate, 174, 175
describe_cert, 174
describe_feed, 174
describe_scap, 174
get_alerts, 180
get_configs, 152, 180
get_filters, 180
get_groups, 179
get_notes, 180
get_overrides, 180
get_roles, 179
get_schedules, 181
get_settings, 174, 175
get_tags, 181
get_targets, 181
get_tasks, 181
get_users, 66, 178, 180
276
help, 174
sync_cert, 174
sync_feed, 174
sync_scap, 174
write_settings, 174, 175
Ping, 154, 155
Port Scanner, 154
Powerfilter
and, 147
first, 146
min_qod, 71
not, 147
or, 147
rows, 146
sort, 146
sort-reverse, 147
tag, 147
Preferences
/tmp/, 101, 105
auto_enable_dependencies, 155
Base, 97
C:\Windows\system32, 106
C:\Windows\SysWOW64, 106
cgi_path, 155
checks_read_timeout, 155
Do a TCP ping, 157
Do an ICMP ping, 157
Do not randomize the order in which ports
are scanned, 157
Do not scan targets not in the file, 157, 158
drop_privileges, 155
Errors, 97
File Checksums, 102
File Checksums: Errors, 102
File Checksums: Matches, 102
File Checksums: Violations, 102
File containing grepable results, 157, 158
File Content, 98
File Content: Errors, 98, 99
File Content: Matches, 98
File Content: Violations, 98, 99
Fragment IP packets, 157
Get Identd info, 157
Host Timeout, 158
host_expansion, 155
Identify the remote OS, 157
Initial RTT timeout, 158
log_whole_attack, 156
Mark unreachable Hosts as dead, 157
Matches, 97
Max RTT timeout, 158
Min RTT timeout, 158
Minimum wait between probes, 158
network_scan, 156
nmap additional ports for –PA, 157
nmap: try also with only –sP, 157
non_simult_ports, 156
optimize_test, 156
plugins_timeout, 156
Ports scanned in parallel (max), 158
Ports scanned in parallel (min), 158
Registry Content: Errors, 101
Registry Content: Violations, 101
Report about reachable Hosts, 157
Report about unreachable Hosts, 157
report_host_details, 156
RPC port scan, 157
Run dangerous ports even if safe checks are
set, 157
safe_checks, 156
Service scan, 157
Source port, 158
TCP ping tries also TCP-SYN ping, 157
TCP scanning technique, 158
Timing policy, 158
unscanned_closed, 156
unscanned_closed_udp, 156
Use ARP, 157
Use hidden option to identify the remote OS,
158
Use Nmap, 157
use_mac_addr, 156
vhosts, 156, 156
vhosts_ip, 156, 156
Violations, 97
Windows Registry Check, 100
Windows Registry Check: Errors, 101
Windows Registry Check: OK, 100
Windows Registry Check: Violations, 100
Prognosis, 203
pure-ftpd, 54
S
Scan Administrator, 15
Scan Config, 64
Scan-Sensor, 267
Scan-Slave, 267
Schedule, 64
Schweregrad, 271
Schweregrad-Klasse, 271
SecInfo Dashboard, 176
Slave, 64
Solution Type, 58
Sourcefire, 226
Status Codes, 188
Super Admin, 21
Super Permissions, 177
T
Tag, 147
Target, 60, 64
Trend, 91
U
QdE, 195
QoD, 269
QoD Typen, 269
Quality of Detection, 269
User Settings
Checksum|File|Checksumtype, 103
Details Export File Name, 191
filename|pattern|presence/absence, 98
Filter, 192
List Export File Name, 192
NVT Filter, 149
Password, 191
Port Export File Name, 192
Present|Hive|Key|Value|ValueType|ValueContent,
101
Rows Per Page, 146, 191
Severity Class, 192
T:25, 126
Timezone, 191
User Interface Language, 191
Wizard Rows, 191
R
V
Q
Risko Analyse, 216
Roles
Admin, 173
Administrator, 172
Guest, 173, 175
Info, 172, 173
Maintenance, 174
Monitor, 173
Observer, 172, 174
ScanConfigAdmin, 174
Scanner, 174
Super Admin, 174
TargetAdmin, 174
TaskAdmin, 174, 175
User, 40, 172, 174
Routing, 29
VendorFix, 58
Verinice, 216
VLAN, 29
W
WATO, 224
Web Administrator, 15
277

PDF-Version, 277 Seiten, 17 MByte, Stand 26.1

Transcription

Similar documents

UTM-1 - All-About

PGP® Desktop 9.8 für Windows - Symantec SSL Certificates Support

MITARBEITERPROFIL

Dominion KX II

Installations

PDF-Version, 173 Seiten, 11 MByte, Stand 16.7.2014

Dominion KX II-101-V2 Benutzerhandbuch

Oracle Database 11g - New Features

Visioneer OneTouch Scanner Installationshandbuch

- Fachhochschule Kiel

McAfee® Internet Security - Gelsen-Net

Artikel als PDF anzeigen

Private Cloud und Hybrid Cloud

3Com® Router 5012 Leistungsmerkmale Technische Daten

Protokoll Praktikum Anwendungssicherheit

Einführung in Lucene

OpenVAS Kompendium - Wald