Greenbone Networks GmbH Neuer Graben Osnabrück Germany

Transkript

1

2

3 Greenbone Networks GmbH Neuer Graben Osnabrück Germany

4 Stand: GOS , 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 an den Support: 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.

5 Inhaltsverzeichnis 1 Einführung 1 2 GSM Übersicht Enterprise-Klasse (GSM 5300 / 6400) Midrange-Klasse (GSM 400/600/650) SME-Klasse (GSM 100) Sensoren GSM 25 / 25V GSM ONE Ich möchte Inbetriebnahme Die Anmeldung als Admin Grundkonfiguration Tastaturlayout Netzwerk Management Netzwerkschnittstelle DNS Konfiguration Kennwortänderung Einstellung der Web-Oberfläche Web-Administrator Zertifikat Selbstsigniertes Zertifikat Aktivierungsschlüssel Bereitschaft Die Kommandozeilenschnittstelle (CLI) Kommandozeile Einstellungen bearbeiten Benutzer und Kennworte Kennwortänderung des Admin Erzeugen eines Web-Administrators (Scan-Administrator) Superuser Zertifikate Selbstsignierte Zertifikate Zertifikat einer externen Zertifizierungsstelle Geräteverwaltung Reboot und Herunterfahren der Appliance Netzwerkkonfiguration Experten Netzwerkkonfiguration Fernzugri HTTPS Timeout SSH-Zugang i

6 5.6.3 OpenVAS Management Protocol (OMP) Upgrade und Feeds Upgrade des Systems Feed Synchronisation Proxy Konfiguration Verwaltung der Datenbank und der Scanner Datenbankverwaltung Weitere Schwachstellenscanner Überwachung und Fehlersuche Fehlersuche und Überwachung der Netzwerkfunktionen Betrieb Benutzerverwaltung Anlegen und Verwaltung der Benutzer Upgrade Prüfen der aktuellen Version Durchführung des Patch-Level Upgrades Release Upgrade Verwendung eines Proxies Sicherung und Wiederherstellung Backup des gesamten Systems Snapshot des Systems Backup der Userdata mit USB-Stick Backup der Userdata via SSH Airgap Update Airgap via USB Stick Airgap via FTP Scanning Einfacher Scan Wizard Advanced Wizard Manuelle Konfiguration Reports Lesen des Reports Ergebnisse Authentifizierter Scan Voraussetzungen auf Zielsystemen mit Windows Konfigurieren eines Linux/UNIX-Kontos für authentifizierte Scans Voraussetzungen auf Zielsystemen mit ESXi Autogenerate Credentials Geplanter Scan Notizen Notizen anlegen Verallgemeinerung der Notizen Notizen verwalten Overrides und False Positives Was ist ein False Positive? Erzeugen eines Override Ein- und Ausschalten von Übersteuerungen Automatische False-Positives (AutoFP) Scan von Webanwendungen Berichte Delta-Report Report Plugins Import weiterer Report Plugins Compliance und spezielle Scans 97 ii

7 9.1 Allgemeine Policy Scans File Content Registry Content File Checksums CPE-basiert Richtlinien prüfen Standardrichtlinien IT-Grundschutz PCI DSS Spezielle Richtlinien Onlineprüfung Mailserver TLS-Karte Vorbereitung Prüfung TLS-Nutzung Export der Scan-Ergebnisse Conficker-Suche Suchmethoden für Schwachstellen und Befall Suche nach Schwachstelle und Conficker ausführen OVAL System Characteristics OVAL Adoption Program Scan-Daten als OVAL-SCs einsammeln OVAL-SC exportieren Beispiel: OVAL-SC für ovaldi verwenden Benachrichtigungen GUI-Konzepte Icons Charts Powerfilter Komponenten Speichern und Verwalten Tags Scan-Konfiguration Erzeugen einer neuen Scan-Konfiguration Scanner Preferences Allgemeine Preferences Ping Preferences Nmap NASL Preferences Scanner w3af Scanner w3af Scankonfiguration w3af Scan-Aufgabe PaloAlto Scanner PaloAlto Scanner Konfiguration PaloAlto Bericht Alternative Oberflächen IT-Schwachstellenampel Benutzer- und Rechteverwaltung Benutzerverwaltung Anlegen und Verwaltung der Benutzer Gleichzeitige Anmeldung Benutzerrollen Gastanmeldung Super Admin Gruppen iii

8 Permissions Zentrale Benutzerverwaltung OpenVAS Management Protokoll (OMP) Aktivieren des OMP Protokolls Zugri mit omp Konfiguration des Clients Start eines Scans Aktualisieren Sie das Ziel einer änderbaren Aufgabe mit OMP Status Codes MySettings SecInfo Management Secinfo Portal Network Vulnerability Tests Security Content Automation Protocol (SCAP) CVE CPE OVAL CVSS DFN-CERT CERT-Bund Asset Management Prognose Performanz Scan Performanz Wahl der Port-Liste für einen Scan Scan-Konfiguration Tasks Backend Performanz Appliance Performanz Master und Slave Setups Anbindung eines Slaves Sensor Manuelle Synchronisation Aktualisieren der Sensoren Kommunikation der Sensoren Integration mit anderen Systemen Integration von Drittherstellern OSP Scanner Verinice IT Security Management IT-Grundschutz Nagios Konfiguration des GSM-Nutzers Installation des Plugins Konfiguration des Plugins Sourcefire Defence Center Installation des Report Export Plugins Konfiguration des Host-Input-API-Clients Konfiguration des Alerts auf dem GSM OpenVAS Scanner Protokoll Aktivierung zusätzlicher OSP-Scanner iv

9 23.2 Wie man einen OSP Wrapper baut Die Aufgabe: debsecan als OSP-Scanner Die Basis: ospd Das Grundgerüst für den neuen OSP Scanner Verbindung scha en zwischen debsecan und OSP Fazit Erste Fehlerbehandlung einbauen Setup-Handbücher GSM ONE Voraussetzungen Import der virtuellen Appliance Anmeldung an der Weboberfläche GSM ONE Fehlersuche GSM 25V Voraussetzungen Import der virtuellen Appliance GSM Installation Serielle Schnittstelle Einschalten GSM Installation Serielle Schnittstelle Einschalten Anmeldung an der Weboberfläche GSM 500/510/ Installation Serielle Schnittstelle Einschalten Anmeldung an der Weboberfläche GSM 400/600/ Installation Serielle Schnittstelle Einschalten Anmeldung an der Weboberfläche GSM 5300/ Installation Serielle Schnittstelle Einschalten Anmeldung an der Weboberfläche CLI Kommandoreferenz CLI Einstellungsreferenz Häufig gestellte Fragen Was ist der Unterschied zwischen Scan-Sensor und Scan-Slave? Scan-Vorgang sehr langsam Scan löst Alarm bei anderen Sicherheits-Tools aus Auf gescannten Zielsystemen erscheint VNC Dialog Nach Factory Reset funktioniert weder Feed-Update noch System-Upgrade Glossar Host Quality of Detection (QoD) Schweregrad Solution Type v

10 Stichwortverzeichnis 273 vi

11 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, O ce-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

12 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-Security- Prozess einfach visualisiert werden. 2 Kapitel 1. Einführung

13 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

14 Greenbone Security Manager with Greenbone OS 3.1, Release 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 überwachten IP-Adressen empfohlen. Die GSM 5300 kann Sensoren in bis zu 30 Sicherheitszonen steuern und wird für bis zu ü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 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 IP-Adressen überwachen. Der GSM 600 unterstützt ebenfalls Sensoren in bis zu 12 Sicherheitszonen und wird empfohlen für bis zu überwachten IP-Adressen. Der GSM 400 kann 2 Sensoren steuern und ist ausgelegt für bis zu ü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

15 Greenbone Security Manager with Greenbone OS 3.1, Release Abb. 2.2: Die GSM 650 unterstützt für bis zu 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 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ü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 SME-Klasse (GSM 100) 5

16 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 Enterprise- Klasse (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 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ü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 Kapitel 2. GSM Übersicht

17 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 GSM ONE 7

18 8 Kapitel 2. GSM Übersicht

19 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

20 10 Kapitel 3. Ich möchte...

21 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 erläutert: 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

22 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 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 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 Alternativ können Sie das Keyboard-Layout auch über die Variable keyboard_layout festlegen. 12 Kapitel 4. Inbetriebnahme

23 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. Konfiguration eines externen Server für den Versand von GSM s 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

24 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 IP- Adresse 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 ( ) 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: google-public-dns-b.google.com: 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-Admin- Menü) 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 Kapitel 4. Inbetriebnahme

25 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)) 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 Einstellung der Web-Oberfläche 15

26 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 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 gsf hinterlegt. Alternativ können Sie auf der Kommandozeile show customer aufrufen. 16 Kapitel 4. Inbetriebnahme

27 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-Admin- Menü 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

28 Abb. 4.9: Prüfung der Betriebsvoraussetzungen Connectivity and functionality of the DNS server (Erreichbarkeit und korrekte Funktion des DNS- Servers) 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 4. Inbetriebnahme

29 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

30 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 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)

31 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 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 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 root- Benutzer 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

32 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 CA 3. Für Linux-Systeme stehen vielfältige Lösungen zur Verfügung. Eine Variante ist im IPsec-Howto beschrieben IPSec-Howto 4. 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 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 (SSL- Self-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 ( oder mit einem DNS-Namen ( 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 Kapitel 5. Die Kommandozeilenschnittstelle (CLI)

33 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) []: Address of the GSM Administrator []: mail@firma.de Um das Zertifikat auszulesen und anzuzeigen, können Sie den Befehl sslcatself verwenden 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 Zertifikate 23

34 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) []: Address of the GSM Administrator []: mail@firma.de 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 Kapitel 5. Die Kommandozeilenschnittstelle (CLI)

35 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 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 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 Syslog- Meldungen auf einem zentralen Protokollserver. Außerdem wird die konfigurierte Domäne automatisch bei versandten s als Absender-Domäne genutzt. Zusätzlich wird der Domänenname auch bei nicht vollqualifizierten Hostname als Such-Su x angehängt Geräteverwaltung 25

36 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 dns 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_ipv /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 Kapitel 5. Die Kommandozeilenschnittstelle (CLI)

37 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_ipv 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_server 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 ptbtime2.ptb.de.ptb. 1 u LOCAL (0).LOCL. 10 l 53h 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 zu versenden, benötigt die Appliance die Angabe eines Mailservers für die Zustellung der . Die Appliance verfügt selbst nicht über einen Mailserver. Stellen Sie sicher, dass der Mail-Server die s von der Appliance immer annimmt. Die Appliance speichert im Fehlerfall die s 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 5.5. Geräteverwaltung 27

38 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:// :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] portal 5 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 Kapitel 5. Die Kommandozeilenschnittstelle (CLI)

39 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 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 iso = STRING: "Greenbone Security Manager" iso = STRING: "gsm"... Die folgenden Informationen können ausgelesen werden: Uptime (Laufzeit) Netzwerkschnittstellen Speicher Festplatten Last CPU 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 GOS- Admin-Menü oder die Variablen ändern! 5.5. Geräteverwaltung 29

40 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 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 Kapitel 5. Die Kommandozeilenschnittstelle (CLI)

41 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 lo up sleep 10s /bin/ip addr add /8 dev lo /bin/ip link set eth0 up sleep 10s /bin/ip addr add /24 dev eth0 /bin/ip -f inet6 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 set eth1 up sleep 10 /bin/ip link add link eth1 name eth1.91 type vlan id 91 /bin/ip link set eth1.91 up /bin/ip addr add /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 Geräteverwaltung 31

42 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 IP- Adresse 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 Default- Gateway 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 Default- Gateway entfallen. Um eine Route zu setzen, verwenden Sie ebenfalls den Befehl ip mit dem Argument route: /bin/ip route add default via /bin/ip -f inet6 route add default via 2607: f0d0 :2001::1 Das Schlüsselwort default wird hierbei entsprechend zu /0 oder ::/0 aufgelöst. Um weitere Routen zu setzen können Sie einfach die folgende Syntax nutzen: /bin/ip route add /24 via Hiermit setzen Sie eine Route für das Netzwerk /24 über den Router 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)) 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 Kapitel 5. Die Kommandozeilenschnittstelle (CLI)

43 gsm: get webtimeout s webtimeout 1 Der Wert für den Timeout darf zwischen 1 und 1440 Minuten (1 Tag) betragen 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 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 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) 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 Upgrade und Feeds 33

44 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 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 gsm: get proxy_feed u proxy_feed gsm: set proxy_feed gsm *: commit gsm: get proxy_feed s proxy_feed http :// :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 Kapitel 5. Die Kommandozeilenschnittstelle (CLI)

45 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 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%) 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 Verwaltung der Datenbank und der Scanner 35

46 Abb. 5.6: Konfiguration zusätzlicher OSP Scanner 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 /24 brd 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 valid_lft forever preferred_lft forever getroute Dieses CLI spezifische Kommando zeigt die aktuelle IPv4-Routing-Tabelle an: gsm: getroute /24 dev eth0 proto kernel scope link src& default via 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 *ptbtime2.ptb.de.ptb. 1 u LOCAL (0).LOCL. 10 l 11d 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 Kapitel 5. Die Kommandozeilenschnittstelle (CLI)

47 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 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 link/ether 52:54:00:98:36:5 f brd ff:ff:ff:ff:ff:ff 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 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet /8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 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 /24 brd scope global eth0 inet6 fe80 ::5054: ff:fe98 :365f/64 scope link valid_lft forever preferred_lft forever 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 dev eth0 lladdr 00:16:47:7d:11: c3 REACHABLE Überwachung des IP-Stacks Mit dem Kommando ip können auch Änderungen der Routing- Tabelle, 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

48 [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 100 baset/half 100 baset/full Advertised pause frame use: Symmetric Advertised auto - negotiation: Yes Link partner advertised link modes: 10 baset/half 10 baset/full 100 baset/half 100 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: 0x (7) drv probe link Link detected: yes 38 Kapitel 5. Die Kommandozeilenschnittstelle (CLI)

49 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

50 6.1.1 Anlegen und Verwaltung der Benutzer 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 des weissen Sterns auf blauen Grund begonnen. Die Modifikation eines existierenden Benutzers 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: (IPv4-Adresse) 40 Kapitel 6. Betrieb

51 (IPv4-Bereich Langform) (IPv4-Bereich Kurzform) /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 auf ) ca. 1 pro Monat einige empfohlen, einige kritisch (sicherheitsrelevant) 10 min pro Master-GSM Release Upgrades (z.b. von Version auf 3.1.0) ca. 1-2 pro Jahr nach Wunsch oder bei Ende der Lebensdauer 6.2. Upgrade 41

52 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 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: 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! 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 running on a Greenbone Security Manager Web Interface available at : https :// 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 Feed- Updates 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

53 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 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

54 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-Admin- Menü 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 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 Patch- Level-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 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 IP- Adressen dürfen verwendet werden Kapitel 6. Betrieb

55 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 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 Sicherung und Wiederherstellung 45

56 Alle weiteren Systeme (GSM 500 und aufwärts) verfügen über eine Backup-Partition. Diese Backup- Partition 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 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 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 Scankon- 46 Kapitel 6. Betrieb

57 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! 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 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 Sicherung und Wiederherstellung 47

58 Die Sicherung wird auch innerhalb des folgenden 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 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

59 Abb. 6.12: Wählen Sie das zu kopierende Backup aus. Long file name " 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 6.3. Sicherung und Wiederherstellung 49

60 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 Userdata- Backups 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 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

61 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 :82:81:ff:36:b3:b6:03:df:ed:4a:e9:fa:2d:6a:5d (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 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 Airgap Update 51

62 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

63 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 PRE- SEND 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 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 Airgap- Management ist in einem eigenen Untermenü verborgen. (Seite 52)). Anschließend setzen Sie Airgap 6.4. Airgap Update 53

64 Abb. 6.22: Die Airgap-Master zeigt auf seinem Display die Schritte bei der Erstellung des Update- Pakets 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

65 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 Airgap Update 55

66 56 Kapitel 6. Betrieb

67 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: 3.1/en/GSM-FirstScan-GOS-3.1-en mp 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

68 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: 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. 58 Kapitel 7. Scanning

69 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 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 Einfacher Scan 59

70 Abb. 7.6: Der fortgeschrittene Wizard bietet mehr Möglichkeiten. Abb. 7.7: Das Wizard-Kontextmenü erlaubt den Aufruf 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: 3.1/en/GSM-FirstScan-GOS-3.1-en 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

71 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 Ein Rechnernamen, z.b. mail.example.com Ein IPv4 Adressbereich, z.b oder Ein IPv4 Netz in CIDR Notation, z.b / Die maximale Netzmaske beträgt /20. Dies entspricht 4096 Adressen. Abb. 7.10: Geben Sie die Details für das Target an Einfacher Scan 61

72 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 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 (TCP- ACK) 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

73 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

74 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 , 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 Scan- Konfigurationen. * 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

75 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 /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

76 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 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. 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

77 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 Einfacher Scan 67

78 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

79 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

80 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

81 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

82 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

83 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 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

84 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 ) 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

85 Ö 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 7.4. Authentifizierter Scan 75

86 Abb. 7.27: Windows Gruppen-Namen überprüfen. Hier fügen Sie der Richtlinie Greenbone Local SecRights die Gruppe Greenbone Local Scan 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 nun 2 mal auf OK, um das geö nete Dialogfeld wieder zu schließen. Klicken Sie auf OK. Schritt 5: Konfiguration der Richtlinie, um der Gruppe Greenbone Local Scan das Anmelden per Remotedesktopdienst am System zu verweigern Hier fügen Sie der Richtlinie Greenbone Local SecRights die Gruppe Greenbone Local Scan hinzu und verweigern Sie der Gruppenmitgliedern das Anmelden via RDP. Klicken Sie auf die Richtlinie Greenbone Local SecRights und wählen Sie anschließend 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

87 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 nun 2 mal auf OK, um das geö nete Dialogfeld wieder zu schließen. 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) Klicken Sie auf die Richtlinie Greenbone Local SecRights und wählen Sie anschließend 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 Authentifizierter Scan 77

88 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

89 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 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 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 entsprechen Authentifizierter Scan 79

90 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 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

91 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 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 Authentifizierter Scan 81

92 Abb. 7.35: Die Zugri sberechtigungen rekursiv einstellen. Abb. 7.36: Richtlinie für Leserecht auf Systemlaufwerk 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

93 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

94 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

95 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 Notizen anlegen Um eine neue Note zu erzeugen, wählen Sie in dem Bericht die Meldung New Note aus, für die 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

96 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 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

97 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 Au nden 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 Overrides und False Positives 87

98 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 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 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 Scan-Administrator diesen Umstand kennt, kann er mit sicherstellen, dass diese Meldungen nicht mehr angezeigt werden 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 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

99 Abb. 7.49: Overrides erlauben die Anpassung der Bedrohungsstufe Abb. 7.50: Übersteuerungen können ein- und ausgeschaltet werden 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 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 7.7. Overrides und False Positives 89

100 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: 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

101 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

102 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

103 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 . 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 Report Plugins 93

104 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 E- Mail. 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 Report- Plugins 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

105 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 alle Plugins des Typs text/\* angeboten, da diese menschenlesbar in der 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 Import weiterer Report Plugins Weitere Report Plugins lassen sich einfach importieren. Greenbone stellt auf der Seite die folgenden zusätzlichen Report- Format-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

106 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

107 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 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

108 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 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

109 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.xml 11 ) kann eine Beispiel Scan Config mit allen NVT s für den Dateiinhaltstest heruntergeladen werden. Die dazugehörige Testdatei (filecontent_test 12 ) muss ebenfalls Allgemeine Policy Scans 99

110 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 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 Registry- Einstellungen 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) Kapitel 9. Compliance und spezielle Scans

111 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 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. Hierzu muss die Datei mit Browse ausgewählt und Upload file selektiert werden. Ein Klick auf Save Config startet dann den Upload der Datei. 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 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.xml 13 ) 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.txt 14 ) 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. 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 Allgemeine Policy Scans 101

112 Abb. 9.5: Diese Datei muss anschließend in die Details des Plugins importiert werden: 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 Kapitel 9. Compliance und spezielle Scans

113 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 ed3ed98cb2efa cd27e5a4d9be2bdb8 /bin/bash sha1 7c b2b67f2b5c51e0d0d01c0d /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 Allgemeine Policy Scans 103

114 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: 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.10: 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 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 Kapitel 9. Compliance und spezielle Scans

115 Abb. 9.11: Schweregrad (Severity) Overrides angewandt für die File Checksums Tests. Beispiel Hier (policy_file_checksums_example.xml 15 ) kann eine Beispiel Scan Config mit allen NVT s für den Prüfsummentest heruntergeladen werden. Die dazugehörigen Testdateien (policy_file_checksums_testfiles 16 ) 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. 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. 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 ( 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 Allgemeine Policy Scans 105

116 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.xml 17 ) 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.zip 18 ) können hier heruntergeladen und danach auf das Zielsystems gespeichert werden. Gehen Sie bzgl. Task und Overrides wie oben beschrieben vor CPE-basiert Richtlinien prüfen CPE steht für Common Product Enumeration 19. 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 Kapitel 9. Compliance und spezielle Scans

117 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 Allgemeine Policy Scans 107

118 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 (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 Kapitel 9. Compliance und spezielle Scans

119 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 9.1. Allgemeine Policy Scans 109

120 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. 3. 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 (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. 5. 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äßt sich ein entprechender Filter formulieren (Suchtext cpe ). 110 Kapitel 9. Compliance und spezielle Scans

121 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 Allgemeine Policy Scans 111

122 3. 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 (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. 5. 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äßt sich ein entprechender Filter formulieren (Suchtext cpe ). 112 Kapitel 9. Compliance und spezielle Scans

123 6. In diesem Beispiel wurde Norton Antivirus auf einem der Zielsysteme nicht gefunden. 9.2 Standardrichtlinien IT-Grundschutz Über den Greenbone Security Manager können automatische Prüfungen zu den IT-Grundschutz- Katalogen des Bundesamt für Sicherheit in der Informationstechnik 22 (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 Standardrichtlinien 113

124 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 Scan 23. Für verinice Kopplung: < _. 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 Kapitel 9. Compliance und spezielle Scans

125 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 Zeit dauern, bis der Scan abgeschlossen ist. Den aktuellen Stand des Scans erhalten Sie indem Sie auf klicken. 6. 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. 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 OpenO ce 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 9.2. Standardrichtlinien 115

126 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 Tools 24 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 Kapitel 9. Compliance und spezielle Scans

127 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 Ergebnis- Klasse nicht mehr vorkommt. Check of the measure is not implemented (NA): Eine Reihe von Maßnahmen der IT- Grundschutzkataloge 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 Standardrichtlinien 117

128 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 Titel Test-Typ Hinweis M Bildschirmsperre Credentials Windows: Kann nur für Lokale Konten getestet werden. Linux: Nur voreingestellte Bildschirmschoner bei Gnome und KDE. M Einsatz von Viren- Credentials Schutzprogrammen M Geeigneter Umgang mit Laufwerken Credentials für Wechselmedien und externen Datenspeichern M Protokollierung bei TK-Anlagen Credentials M Änderung voreingestellter Remote Test nur über SSH und Telnet. Passwörter M Einsatz der Sicherheitsmechanismen Credentials von XWindow M Obligatorischer Passwortschutz Credentials unter Unix M Gesichertes Login Credentials M Zugangsbeschränkungen für Credentials Benutzer-Kennungen und / oder Terminals M Sperren und Löschen nicht benötigter Accounts und Terminals Credentials Fortsetzung auf der nächsten Seite 118 Kapitel 9. Compliance und spezielle Scans

129 Tab. 9.1 Fortsetzung der vorherigen Seite BSI Referenz Titel Test-Typ Hinweis M Administrative und technische Credentials Absicherung des Zugangs zum Monitor- und Single-User- Modus M Restriktive Attributvergabe Credentials bei Unix-Systemdateien und -verzeichnissen M Restriktive Attributvergabe Credentials bei Unix-Benutzerdateien und -verzeichnissen M Verhinderung des unautorisierten Credentials Erlangens von Administra- torrechten M Verhinderung des Vertraulichkeitsverlusts Credentials schutzbedürftiger Daten im Unix-System M Sicherer Aufruf ausführbarer Credentials Dateien M Einsatz eines Viren- Credentials Suchprogramms bei Datenträgeraustausch und Datenübertragung M Sperren bestimmter Credentials Cisco Geräte können nur über Faxempfänger- Rufnummern telnet getestet werden, da sie SSH blowfish-cbc encryption M Sperren bestimmter Absender- Faxnummern M Verhinderung der unautorisierten Nutzung des Rechnermikrofons Credentials Credentials M Passwortschutz unter Credentials Windows-Systemen M Absicherung des Boot- Credentials Vorgangs für ein Windows System M Geräteschutz unter NTbasierten Credentials Windows-Systemen M Deaktivieren der automatischen Credentials CD-ROM Erkennung M Sichere Zugri smechanismen Remote bei Fernadministration M Schutz der Webserver-Dateien Remote M Abschaltung von DNS Credentials M Ein Dienst pro Server Remote M Kommunikation durch Paketfilter auf Minimum beschränken Credentials nicht unterstützen. Cisco Geräte können nur über telnet getestet werden, da sie SSH blowfish-cbc encryption nicht unterstützen. Nur für Linux Umgesetzt. Es ist unter Windows nicht möglich den Status des Microfons über Registry/WMI auszulesen. Getestet wird auf die Microsoft Windows Firewall. Für Vista und neuer auf jegliche Firewall die sich systemkonform installiert. Fortsetzung auf der nächsten Seite 9.2. Standardrichtlinien 119

130 Tab. 9.1 Fortsetzung der vorherigen Seite BSI Referenz Titel Test-Typ Hinweis M Aktivieren der Systemprotokollierung Credentials M Restriktive Vergabe von Zugri srechten Credentials auf Systemdatei- en M Sichere Nutzung von EFS unter Credentials Windows M Umgang mit USB- Credentials Speichermedien M Einsatz eines lokalen NTP- Credentials Servers zur Zeitsynchronisation M Einsatz eines lokalen Paketfilters Credentials Getestet wird auf die Microsoft Windows Firewall. Für Vista und neuer auf jegliche Firewall die sich systemkonform installiert. M Sichere Systemkonfiguration Credentials von Windows Client- Betriebssystemen M Absicherung der SMB-, LDAPund Credentials RPCKommunikation unter Windows Servern M Umgang mit Diensten unter Credentials Windows Server 2003 M Deinstallation nicht benötigter Credentials Client-Funktionen von Windows Server 2003 M Sichere Administration der Remote VoIP-Middleware M Informationsschutz bei Druckern, Remote Kopierern und Multi- funktionsgeräten M Einsatz von Speicherbeschränkungen Credentials (Quotas) M Einrichtung des LDAP-Zugri s Remote auf Verzeichnisdienste M Bereitstellung von sicheren Credentials Domänen-Controllern M Löschen von Auslagerungsdateien Credentials M Sicherstellung der NTFS- Credentials Eigenschaften auf einem Samba-Dateiserver M Sichere Grundkonfiguration eines Credentials Samba-Servers M Sichere Konfiguration des Credentials Betriebssystems für einen Samba-Server M Sichere Konfiguration der Credentials Zugri ssteuerung bei einem Samba-Server M Sichere Konfiguration von Winbind unter Samba Credentials Fortsetzung auf der nächsten Seite 120 Kapitel 9. Compliance und spezielle Scans

131 Tab. 9.1 Fortsetzung der vorherigen Seite BSI Referenz Titel Test-Typ Hinweis M SMB Message Signing und Samba Credentials M Einsatz von Windows Vista und neuer File und Registry Virtualization Credentials M Verhindern unautorisierter Nutzung von Wechselmedien unter Windows Vista und neuer M Einsatz der Windows- Benutzerkontensteuerung UAC ab Windows Vista M Integritätsschutz ab Windows Vista M Aktivierung des Last Access Zeitstempels ab Windows Vista M Überwachung von Windows Vista-, Windows 7 und Windows Server 2008-Systemen M Regelmäßige Audits der Terminalserver-Umgebung M Regelmäßiger Sicherheitscheck des Netzes Credentials Credentials Credentials Credentials Credentials Credentials Remote Nur ein genereller Test, ob File und Registry Virtualization aktiviert ist. Soweit technisch möglich umgesetzt (aktiviertes UAC und geschützter Modus in verschiedenen Zonen). Es wird lediglich ein Meldung ausgegeben, dass mit aktuelleten Plugins getestet werden soll. M Einsatz der Sicherheitsmechanismen Credentials von NFS M Einsatz der Sicherheitsmechanismen Credentials von NIS M Einsatz der Sicherheitsmechanismen Remote von sendmail M Einsatz der Sicherheitsmechanismen Credentials von sendmail M Einsatz der Sicherheitsmechanismen Credentials von rlogin, rsh und rcp M Sicherer Einsatz von telnet, ftp, Credentials tftp und rexec M Einsatz von Einmalpasswörtern Credentials M Schutz vor DNS-Spoofing bei Credentials Authentisierungsmechanismen M Einsatz von GnuPG oder PGP Credentials M Secure Shell Remote M Verwendung von TLS/SSL Remote M Deaktivieren nicht benötigter Credentials Lediglich Anzeige der in Frage Netzdienste kommenden Dienste. M Einsatz von IPSec unter Windows Credentials Fortsetzung auf der nächsten Seite 9.2. Standardrichtlinien 121

132 Tab. 9.1 Fortsetzung der vorherigen Seite BSI Referenz Titel Test-Typ Hinweis M Einsatz von Personal Firewalls für Clients Credentials Getestet wird auf die Microsoft Windows Firewall. Für Vista und neuer auf jegliche Firewall die sich systemkonform installiert. Auf Linux, soweit möglich, anzeige der iptables Regeln. M Einsatz eines -Scanners Remote auf dem Mailserver M Absicherung der Netzkommunikation Credentials unter Windows M Absicherung von IP-Protokollen Credentials unter Windows Server 2003 M Sicherer Einsatz von CUPS Credentials M Absicherung der Kommunikation mit Verzeichnisdiensten Remote 122 Kapitel 9. Compliance und spezielle Scans

133 Standardrichtlinien 123

134 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 Kapitel 9. Compliance und spezielle Scans

135 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 Standardrichtlinien 125

136 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 Onlineprüfung Mailserver Das Bayerische Landesamt für Datenschutzaufsicht hat im September 2014 eine Online-Prüfung Mailserver hinsichtlich STARTTLS, Perfect Forward Secrecy und Heartbleed 103 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.xml Konfigurieren Sie eine neue Port List mit der Port Range T: Kapitel 9. Compliance und spezielle Scans

137 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 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 Policy- Frage 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 ) 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-/TLS- Protokoll 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 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 Plugin 106 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 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 Config 107 Diese Scan-Konfiguration identifiziert die verwendeten Protokollversionen und die angebotenen Verschlüsselungsalgorithmen, versucht aber nicht, den Dienst genauer zu identifizieren. TLS-Map with service detection TLS-Karte 127

138 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 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 , cpe:/a:apache:http_server:2.2.22;cpe:/a:php:php: ,www2.local,443,TLSv1.0;SSLv3,SSL3_RSA_RC4_128_SHA;TLS1_RSA_RC4_128_SHA, cpe:/a:apache:http_server: 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 Kapitel 9. Compliance und spezielle Scans

139 9.5 Conficker-Suche Conficker 109 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 MS beschreibt die wichtigste Sicherheitslücke, die Conficker ausnutzt, um das betre ende System zu befallen 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 MS beschriebenen Sicherheitslücke. Invasive Suche nach der von Microsoft im Bulletin MS 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 Suche nach Schwachstelle und Conficker ausführen Importieren Sie die Scan Configuration Conficker Search 111 oder für die invasive Suche die Scan Configuration Invasive Conficker Search 112. Falls die Zielsysteme keine anonyme Anmeldung erlaubt, erstellen Sie Credentials um der Scan- Engine 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 Conficker-Suche 129

140 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 Zeit dauern, bis der Scan abgeschlossen ist. Den aktuellen Stand des Scans erhalten Sie indem 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 gestellt 114. MITRE pflegt das OVAL Repository 115 mit über Einträgen Kapitel 9. Compliance und spezielle Scans

141 9.6.1 OVAL Adoption Program Greenbone ist o zieller OVAL Adopter und der Greenbone Security Manager ist registriert als Systems Characteristics Producer. Siehe dazu: OVAL Adoption Program 116. Unterstützt werden die OVAL Versionen 5.3 bis 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 OVAL- SC zu aktivieren und damit zeitnah jegliche Verbesserungen für den Anwender bereitzustellen OVAL System Characteristics 131

142 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.xml 117. 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 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 Kapitel 9. Compliance und spezielle Scans

143 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 IP- Adresse des jeweiligen Systems benannt. Beide Plugins stehen auf der Report Formats-Seite 118 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: 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 ovaldi 119 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 o ziellen Debian OVAL definitions 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.html 121 (102 KByte) und oval-sc-debian-squeeze-sample OVAL System Characteristics 133

144 ovaldi-results.xml 122 (4,2 MByte). Um den Test auszuführen laden Sie zusätzlich noch die Dateien oval-definitions-2010.xml 123 und oval-sc-debian-squeeze-sample.xml 124 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 Kapitel 9. Compliance und spezielle Scans

145 Version: Build: 2 Build date: Sep :49:59 Copyright (c) The MITRE Corporation Start Time: Tue Sep 11 12:12: ** parsing /tmp/oval-definitions-2010.xml file. - validating xml schema. ** checking schema version - Schema version ** skipping Schematron validation ** parsing /tmp/oval-sc-debian-lenny-sample.xml for analysis. - validating xml schema. ** running the OVAL Definition analysis. Analyzing definition: FINISHED ** applying directives to OVAL results. ** OVAL definition results. OVAL Id Result 9.6. OVAL System Characteristics 135

146 oval:org.debian:def:1965 false oval:org.debian:def:1966 false oval:org.debian:def:1967 false oval:org.debian:def:1968 false oval:org.debian:def:1969 false oval:org.debian:def:1970 false oval:org.debian:def:1971 false oval:org.debian:def:1972 false oval:org.debian:def:1973 false oval:org.debian:def:1974 false... oval:org.debian:def:2124 false oval:org.debian:def:2125 false oval:org.debian:def:2126 false oval:org.debian:def:2127 false oval:org.debian:def:2128 false oval:org.debian:def:2129 false oval:org.debian:def:2130 false oval:org.debian:def:2131 false oval:org.debian:def:2132 false oval:org.debian:def:2133 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 Definitionen 125 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.html 126 (23 KByte) und oval-sc-windows-xp-sample-ovaldiresults.xml 127 (159 KByte). Um die Tests laufen zu lassen laden Sie zusätzlich die Dateien windows.xml 128 und oval-sc-windowsxp-sample.xml 129 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: Build: 2 Build date: Sep :49:59 Copyright (c) The MITRE Corporation Start Time: Tue Sep 11 15:57: ** parsing /tmp/windows.xml file. - validating xml schema Kapitel 9. Compliance und spezielle Scans

147 ** checking schema version - Schema version ** skipping Schematron validation ** parsing /tmp/oval-sc-windows-xp-sample.xml for analysis. - validating xml schema. ** 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 oval:org.mitre.oval:def:15465 false oval:org.mitre.oval:def:15452 false oval:org.mitre.oval:def:15377 false oval:org.mitre.oval:def:15346 false oval:org.mitre.oval:def:15173 false oval:org.mitre.oval:def:15057 false oval:org.mitre.oval:def:15546 false oval:org.mitre.oval:def:14566 false oval:org.mitre.oval:def:720 false oval:org.mitre.oval:def:627 false oval:org.mitre.oval:def:286 false oval:org.mitre.oval:def:748 false oval:org.mitre.oval:def:684 false oval:org.mitre.oval:def:396 false oval:org.mitre.oval:def:1205 false oval:org.mitre.oval:def:679 false oval:org.mitre.oval:def:165 false oval:org.mitre.oval:def:565 false oval:org.mitre.oval:def:289 false oval:org.mitre.oval:def:730 false oval:org.mitre.oval:def:1162 false oval:org.mitre.oval:def:2041 false oval:org.mitre.oval:def:1946 false oval:org.mitre.oval:def:1815 false oval:org.mitre.oval:def:1282 false oval:org.mitre.oval:def:1804 false oval:org.mitre.oval:def:1469 false oval:org.mitre.oval:def:718 false oval:org.mitre.oval:def:347 false oval:org.mitre.oval:def:283 false oval:org.mitre.oval:def:282 false ** finished evaluating OVAL definitions. ** saving OVAL results to results.xml. ** running OVAL Results xsl: /usr/share/ovaldi/xml/results_to_html.xsl OVAL System Characteristics 137

148 138 Kapitel 9. Compliance und spezielle Scans

149 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 Au nden einer Schwachstelle mit der Bedrohungsstufe größer 9 handeln. Ist dies erfüllt, kann eine 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

150 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. 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 GSM- Kommandozeile definiert haben (siehe Abschnitt Mail-Server (Seite 27)). Dann können Sie hier zwischen den folgenden Optionen wählen: To Address: Dies ist die -Adresse, an die die gesandt wird. From Address: Dies ist die Absenderadresse der generierten . Subject: Dies ist die Betre -Zeile der . 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 bestimmen: Simple Notice: Dies ist lediglich eine einfache Beschreibung des Ereignisses. Include Report: Falls Sie die bei der Beendigung der Aufgabe (Default: Abgeschlossen) versenden, kann der Bericht ebenfalls mit der versendet werden. Dabei kann jedoch nur ein Berichtsformat verwendet werden, welches den Content-Type text/* verwendet, da s nicht direkt binäre Inhalte enthalten dürfen. Des Weiteren können Sie hier den Inhalt der 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

151 Attach Report: Falls Sie die bei der Beendigung der Aufgabe (Default: Abgeschlossen) versenden, kann der Bericht ebenfalls mit der versendet werden. Dabei kann hier ein beliebiges Berichtsformat einschließlich PDF verwendet werden. Der Bericht wird mit dem korrekten Mime-Type an die angehängt. Des Weiteren können Sie hier den Inhalt der 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

152 142 Kapitel 10. Benachrichtigungen

153 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 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. Hiermit stoppen Sie einen aktuell laufenden Task. Alle gewonnenen Ergebnisse werden in die Datenbank geschrieben. Hiermit können Sie einen gestoppten Task wieder aufnehmen. Dieses Icon erlaubt das An- und Abschalten der Overrides. Dieses Icon zeigt Ihnen, ob eine Lösung für die Schwachstelle bekannt ist. 143

154 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 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

155 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 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 Schwachstellen innerhalb des Netzes /24 suchen 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: Powerfilter 145

156 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 Kapitel 11. GUI-Konzepte

157 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: = 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: T13h50 Dabei kann die Uhrzeit weggelassen werden: Powerfilter 147

158 Dann wird als Uhrzeit automatisch 0:00 Uhr angenommen. Diese Datumsangabe kann dann im Suchfilter genutzt werden, z.b. created> 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> and modified< 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 sowohl als auch 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 Kapitel 11. GUI-Konzepte

159 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 Powerfilter 149

160 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 : 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 11. GUI-Konzepte

161 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 NVT- Familien oder neue NVTs aus den entsprechend aktivierten Familien automatisch bei einem Greenbone NVT Feed Update auf und aktivieren diese. Damit ist sichergestellt, 151

162 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 Das Icon Scan-Konfigurationen, die statisch konfiguriert wurden, ändern sich bei einem NVT- Feed-Update nicht. 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

163 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 Scan- Konfigurationen 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: Erzeugen einer neuen Scan-Konfiguration 153

164 Family Trend Hier können Sie entscheiden, ob neue Familien automatisch in dieser Scan- Konfiguration 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. Action Über dieses Icon können Sie direkt in die Familie springen, und die einzelnen NVTs auswählen, 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 Scan- Konfiguration (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 Kapitel 12. Scan-Konfiguration

165 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 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 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 Scanner Preferences 155

166 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 IP- Adresse 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 Kapitel 12. Scan-Konfiguration

167 nachvollzogen werden, auf welcher virtuellen Webinstanz ein NVT eine Schwachstelle gefunden hat 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, 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 nmap 130 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 Scanner Preferences 157

168 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: initial_rtt_timeout min_rtt_timeoutmax_rtt_timeoutmax_parallelismscan_delay max_scan_delay Paranoid 5 min 100 ms 10 sec Serial 5 min 1 sec Sneaky 15 sec 100 ms 10 sec Serial 15 sec 1 sec Polite 1 sec 100 ms 10 sec Serial 400 ms 1 sec Normal 1 sec 100 ms 10 sec Parallel 0 sec 1 sec Aggressive 500 ms 100 ms 1250 ms Parallel 0 sec 10 ms Insane 250 ms 50 ms 300 ms Parallel 0 sec 5 ms 158 Kapitel 12. Scan-Konfiguration

169 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 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 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 Web- Applikation. 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 OSP- Scanner 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

170 Abb. 13.2: w3af Konfiguraton 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 ausführlicher beschrieben. Diese Profile enthalten unterschiedlich konfigurierte w3af Plugins. fast_scan audit_high_risk full_audit OWASP_TOP10 bruteforce 160 Kapitel 13. Scanner

171 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 oder w3af Scan-Aufgabe Um ein System zu scannen müssen Sie eine entsprechende Aufgabe erzeugen. Wechseln Sie zu Scan- Management 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 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 PaloAlto Scanner 161

172 Die Bedrohungen, die durch die Firewall erkannt und protokolliert wurden, werden nach CVE- Referenzen 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 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 PaloAlto- Appliance 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

173 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 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 PaloAlto Scanner 163

174 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

175 Abb : PaloAlto Beispielbericht PaloAlto Scanner 165

176 166 Kapitel 13. Scanner

177 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 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 das ITS-Report Format und importieren Sie diese unter Configuration/Report Formats. Editieren Sie das Report- Format und aktivieren Sie es. Nun sollten Sie es noch durch einen Klick verifizieren. Importieren Sie die ITS-Scankonfiguration Laden Sie von die ITS- Scankonfiguration 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

178 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

179 Über das Drucker-Icon (Abbildung Das Drucker-Icon stellt den Bericht bereit. (Seite 169)) kann der PDF- Bericht 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 IT-Schwachstellenampel 169

180 170 Kapitel 14. Alternative Oberflächen

181 KAPITEL 15 Benutzer- und Rechteverwaltung Dieses Kapitel betrachtet die Benutzer-, Gruppen-, Rollen- und Rechteverwaltung im Detail 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 Anlegen und Verwaltung der Benutzer 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

182 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: (IPv4-Adresse) (IPv4-Bereich Langform) (IPv4-Bereich Kurzform) /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

183 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 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 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 SCAP- Informationen. 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)) Benutzerverwaltung 173

184 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 Kapitel 15. Benutzer- und Rechteverwaltung

185 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 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)) Benutzerverwaltung 175

186 Abb. 15.5: Die Rolle Gast hat Zugri auf das SecInfo Dashboard. Abb. 15.6: Erzeugen Sie einen Gast-Benutzer 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 Kapitel 15. Benutzer- und Rechteverwaltung

187 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 Benutzerverwaltung 177

188 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 : 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 : 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 Kapitel 15. Benutzer- und Rechteverwaltung

189 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 : 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 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 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 Benutzerverwaltung 179

190 Abb : 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 : 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 Kapitel 15. Benutzer- und Rechteverwaltung

191 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 : Kopieren der ID des freizugebenden Objektes 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 LDAP- Baum 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 : 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 Benutzerverwaltung 181

192 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 LDAP- Baums. 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 LDAP- Authentifizierung 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. 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: Bemerkung: Die Kommunikation muss durch SSL/TLS geschützt werden. Unterstützt der LDAP- Server dies nicht, so verweigert die GSM-Appliance die Zusammenarbeit. Details hierzu werden im folgenden Abschnitt gegeben. Microsoft: OpenLDAP: 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 Kapitel 15. Benutzer- und Rechteverwaltung

193 Active Directory LDAP Falls Ihr Active Directory LDAP Dienst noch nicht LDAPS unterstützt, finden Sie in dem folgenden Artikel weitere Hinweise: 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 Benutzerverwaltung 183

194 184 Kapitel 15. Benutzer- und Rechteverwaltung

195 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 Greenbone TechDoc Portal dokumentiert: Dieses Kapitel beschreibt die Aktivierung und Nutzung des Protokolls durch Fremdanwendungen Aktivieren des OMP Protokolls Um das OMP Protokoll zu nutzen, muss es zunächst auf der GSM Appliance aktiviert werden. Das Web- Interface 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 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: omp 131 SHA1 Prüfsumme: d6b b4b059bb7dd4be510cf58dcad18b SHA256 Prüfsumme: 69d384088b8a84770e3ccfb81fe628d2cf12238e2fa9f2d320c7c4f6a615064b Microsoft Windows omp.exe 132 (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 tar.gz (0.6 MB) 133 * openvas-cli tar.gz (0.1 MB) 134 Microsoft Windows: omp-src-win.tar.gz (40 MB)

196 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 Batch- Prozessen. With this tool the OMP protocol can be used in a simple way: omp --xml=<get_tasks/> omp --get-tasks omp --xml=<help/> omp --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 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 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 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)

197 $./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-a cea --name "ScanSuspectHost" \ -t aa410e98-ff8d-45b6-be98-11fd7a a4bdad7c c1-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 b493b7a df-a3ec cea aa410e98-ff8d-45b6-be98-11fd7a $./omp -g 8715c877-47a0-438d-98a3-27c7a6ab ce-73ed-11df-83c cea daba56c8-73ec-11df-a cea 698f691e df-9d8c cea 708f25c df cea 74db13d df-91b cea 2d3f051c-55ba-11e3-bf ea4fc5 bbca7412-a950-11e ea4fc5 Localhost Suspect Host 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 c1-884b-fd226a6e7a19 58f7f696-5ec7-49f d35991f8f2e 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 c1-884b-fd226a6e7a19 a4bdad7c c1-884b-fd226a6e7a19 Running 20% ScanSuspectHost 58f7f696-5ec7-49f d35991f8f2e Running T12:43:17Z $./omp --get-tasks a4bdad7c c1-884b-fd226a6e7a19 a4bdad7c c1-884b-fd226a6e7a19 Done ScanSuspectHost 58f7f696-5ec7-49f d35991f8f2e Done T12: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 ca-dc05-11e1-954f ea4fc5 5ceff8ba-1f62-11e1-ab9f ea4fc5 9087b18c-626c-11e ea4fc5 c a-11e3-a ea4fc5 35ba7077-dc85-42ef-87c9-b0eda7e903b6 ebbc7f34-8ae5-11e1-b07b-001f29eadec8 ARF CPE CSV Hosts CSV Results GSR PDF GXR PDF Zugriff mit omp 187

198 6c f62-11e1-b ea4fc5 77bd6c4a-1f62-11e1-abf ea4fc5 a684c02c-b531-11e1-bdc ea4fc5 9ca6fe72-1f62-11e1-9e7c ea4fc5 c402cc3e-b531-11e ea4fc5 9e5e5deb-879e-4ecc-8be6-a71cd0875cdd a3810a62-1f62-11e ea4fc5 a994b278-1f62-11e1-96ac ea4fc5 HTML ITG LaTeX NBE PDF Topology SVG TXT XML Nun kann der Report geladen werden: $./omp --get-report 58f7f696-5ec7-49f d35991f8f2e --format \ c a-11e3-a ea4fc5 > 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 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 Kapitel 16. OpenVAS Management Protokoll (OMP)

199 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 />" 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 Zugriff mit omp 189

200 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 Feed- Synchronisation 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 16. OpenVAS Management Protokoll (OMP)

201 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

202 %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 : High : Medium : Low BSI Schwachstellenampel : Rot : Gelb : Grün OpenVAS klassisch : High : Medium : Low PCI-DSS : High : 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

203 KAPITEL 18 SecInfo Management Das SecInfo Management bietet einen zentralen Zugri auf verschiedene Informationen zur IT- Sicherheit. Hierzu gehören die folgenden Informationen: 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 team 136 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-CERT 137 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 Secinfo Portal Die SecInfo Daten werden von Greenbone Networks auch online bereitgestellt. Auf dieses Portal 138 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:

204 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 , 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

205 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 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 Network Vulnerability Tests 195

206 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 validiert. Im Folgenden werden die von dem Greenbone Security Manager genutzten Standards detaillierter besprochen 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 CERT- Bund und DFN-CERT Advisories. Diese Informationen können komfortabel über die Weboberfläche angezeigt werden 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 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. 196 Kapitel 18. SecInfo Management

207 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 o zielle 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 Security Content Automation Protocol (SCAP) 197

208 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 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 hat folgende Struktur: <definition id="oval:org.mitre.oval:def:22272" version="4" class="vulnerability"> <metadata> <title>vulnerability in Google Chrome before 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</platform> <platform>microsoft Windows Server 2008 R2</platform> <platform>microsoft Windows Vista</platform> <platform>microsoft Windows 7</platform> <platform>microsoft Windows 8</platform> <platform>microsoft Windows 8.1</platform> <platform>microsoft Windows Server 2012</platform> 198 Kapitel 18. SecInfo Management

209 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 " ref_url=" <description>the OneClickSigninBubbleView::WindowClosing function in browser/ui/views/sync/one_click_signin_bubble_view.cc in Google Chrome before on Windows and before 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=" t12:56:06"> <contributor organization="altx-soft">maria Kedovskaya</contributor> </submitted> <status_change date=" t12:25: :00">draft</status_change> <status_change date=" t04:03: :00">interim</status_change> <status_change date=" t04:00: :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 " test_ref="oval:org.mitre.oval:tst:100272"/> <criterion comment="check if the version of Google Chrome is less than Security Content Automation Protocol (SCAP) 199

210 or equals to </criteria> </criteria> </definition> " 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)) 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 Kapitel 18. SecInfo Management

211 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)). BaseScore = roundt o1decimal(((0.6 * Impact) + (0.4 * Exploitability) 1.5) * f(impact)) Hierbei wird der Impact folgendermaßen berechnet: Impact = * (1 (1 ConfImpact) * (1 IntegImpact) * (1 AvailImpact)) Die Exploitability wird berechnet als: Exploitability = 20 * AccessV ector * AccessComplexity * Authentication Die Funktion f(impact) ist 0, wenn der Impact 0 ist. In allen anderen Fällen ist der Wert Die weiteren Werte sind Konstanten: Access Vector Lokaler Zugri erforderlich: Naher Netzwerkzugang erforderlich: 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: ConfImpact: Kein Bruch der Vertraulichkeit: 0.0 Teilweiser Bruch der Vertraulichkeit: Kompletter Bruch der Vertraulichkeit: IntegImpact Kein Bruch der Vertraulichkeit: 0.0 Teilweiser Bruch der Vertraulichkeit: Kompletter Bruch der Vertraulichkeit: AvailImpact Kein Bruch der Vertraulichkeit: 0.0 Teilweiser Bruch der Vertraulichkeit: Kompletter Bruch der Vertraulichkeit: Security Content Automation Protocol (SCAP) 201

212 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 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 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 18. SecInfo Management

213 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

214 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

215 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 Scan Performanz Die Geschwindigkeit eines Scans ist von vielen Parametern abhängig. Dieser Abschnitt weist auf die wichtigsten Einstellungen hin und gibt einige Empfehlungen 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 TCP-Ports und 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

216 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 Netzwerk- Komponenten 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 Netzwerk- Konfigurationen 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, Port- Prüfungen aktiviert werden und Gegenmaßnahmen oder einen Alarm einleiten. Schon bei normalen Port-Scans könnten Firewalls vortäuschen, dass alle 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 Port-Liste All TCP und All UDP SpezifischeListe für die bekannten Dienste All IANA TCP Erst-Scan unbekannter Systeme in großer Zahl oder in hoher Frequenz 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 Nicht- Erfü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 au ndbare 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

217 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 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 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 /24 mit 5 Hosts: 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 Scan Performanz 207

218 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 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 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 Kapitel 20. Performanz

219 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 Appliance Performanz 209

220 210 Kapitel 20. Performanz

221 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 Netzwerk- Segmente 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

222 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... 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

223 gsm-sensor> masterkeydownload Please paste the master key into the CLI, END with CTRL -D ssh-dss AAAAB3... gsm-sensor> show sensormasterkey ssh-dss AAAAB3... 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 (< ) 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-Admin- Menü 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 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 Sensor 213

224 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 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 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

225 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 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, , 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 hält die aktuelle MIB (Management Information Base) Datei vor. MIB Dateien beschreiben die Objekte, die via SNMP ausgelesen werden können 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

226 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)) Verinice Verinice (see ist ein freies OpenSource Information Security Management System (ISMS), welches durch das Unternehmen SerNet (see 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 für den Betrieb eines ISMS nach ISO 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 IT- Grundschutz 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

227 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 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 ISO 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 Default- Einstellungen 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 Verinice 217

228 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 ei- 218 Kapitel 22. Integration mit anderen Systemen

229 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 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 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 Verinice 219

230 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 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 Kapitel 22. Integration mit anderen Systemen

231 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 : Der Import-Button befindet sich im Fenster BSI-Modell. Wählen Sie nun Ihren ITG-Report aus. Die restlichen Parameter können auf ihren Default- Einstellungen 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 Verinice 221

232 Abb : Wählen Sie im Dialog Ihren Report aus. Abb : 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 : 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 Kapitel 22. Integration mit anderen Systemen

233 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 < _(:index: OMD) zu verbinden. Andere Produkte wie Icinga, Centreon etc. erfordern möglicherweise kleine Anpassungen dieser Anleitung 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 Scan- Ziele 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)) Installation des Plugins Greenbone stellt das check_omp Nagios Plugin unter zur Verfügung. Für die Analyse des Quelltexts ist dieser unter einsehbar Nagios 223

234 Abb : 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 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/ 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 \ -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 \ -u omd -w password --status -T KVM-Hosts --last-report -F 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 Web- Administrationsfrontend 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 Kapitel 22. Integration mit anderen Systemen

235 Abb : 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 Nagios 225

236 Abb : Diese Regel prüft für jeden Host mit dem Tag Monitored by GSM den Status im GSM 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 Kapitel 22. Integration mit anderen Systemen

237 Abb : 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 Installation des Report Export Plugins Das Report Plugin erhalten sie auf der Greenbone Webseite unter 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 : Der GSM-Status wird nun in der Multisite angezeigt Sourcefire Defence Center 227

238 Abb : Das Report Plugin bereitet die Daten für Sourcefire auf Konfiguration des Host-Input-API-Clients Abb : 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 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 Kapitel 22. Integration mit anderen Systemen

239 Abb : Die erzeugte PKCS12 Datei muss heruntergeladen werden. Abb : Die PKCS12-Datei nutzt der Connector zur Authentifizierung Sourcefire Defence Center 229

240 230 Kapitel 22. Integration mit anderen Systemen

241 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 Asset- Informationen 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 GOS- Admin-Menü aktiviert werden. Es ist jedoch auch möglich externe OSP Scanner hinzuzufügen 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 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 Wie man einen OSP Wrapper baut Die OSP Protokoll-Dokumentation ist auf der Greenbone Website verfügbar unter 231

242 Abb. 23.1: Aktivierung zusätzlicher Scanner Abb. 23.2: Akzeptieren Sie die Bedingungen 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 Online- Verbindung Informationen zu noch in Bearbeitung befindlichen Schwachstellen. Weitere Details zu diesem Werkzeug finden such auf der debsecan Homepage: Für die Ausführung von debsecan reichen einfache Anwender-Privilegien aus: $ debsecan CVE chromium (remotely exploitable, high urgency) CVE chromium (remotely exploitable, medium urgency) CVE chromium (remotely exploitable, medium urgency) TEMP EA424A libbluray1 CVE libelf1 (remotely exploitable, medium urgency) CVE libmagickcore5 CVE libmagickcore5 CVE libmagickcore5 CVE libmagickcore5 232 Kapitel 23. OpenVAS Scanner Protokoll

243 Abb. 23.3: Ein Neustart ist erforderlich nachdem der Scanner eingeschaltet wurde. TEMP FC21E libmagickcore5 (low urgency) TEMP C079F libmagickcore5 TEMP EEF23C libmagickcore5 (low urgency) TEMP FDAC72 libmagickcore5 TEMP EB6CF libmagickcore5 CVE libpolkit-gobject-1-0 (low urgency) CVE libstdc dev (low urgency) CVE libstdc dev... Wie man sieht sind viele Schwachstellen schon direkt mit einer CVE verknüpft. Diese Scan- Informationen wollen wir nun OpenVAS zugängig machen 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: Wir arbeiten mit Version 1.0.0: Und prüfen natürlich die Signatur: $ gpg --verify ospd tar.gz.sig $ tar xzf ospd 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/ Wie man einen OSP Wrapper baut 233

244 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 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= author= OpenVAS Development Team, author_ = info@openvas.org, 234 Kapitel 23. OpenVAS Scanner Protokoll

245 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 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 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 Klient- Zertifikat. 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 p 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 p 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> Wie man einen OSP Wrapper baut 235

246 <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 Kapitel 23. OpenVAS Scanner Protokoll

247 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 p use-certs --pretty-print \ -X "<start_scan target= localhost ><scanner_params/></start_scan>" <start_scan_response status_text="ok" status="200"> <id>8f48d691-c f-8f31-d8761e1c75e1</id> </start_scan_response> Damit haben wir die ID unseres Scans. Schauen wir die Details dazu an: $ omp -h p use-certs --pretty-print \ -X "<get_scans scan_id= 8f48d691-c f-8f31-d8761e1c75e1 />" <get_scans_response status_text="ok" status="200"> <scan id="8f48d691-c f-8f31-d8761e1c75e1" target="localhost" end_time=" " progress="100" start_time=" "> <results> <result host="localhost" severity="" test_id="" name="cve " type="alarm">cve chromium (remotely exploitable, high urgency) </result> <result host="localhost" severity="" test_id="" name="cve " type="alarm">cve chromium (remotely exploitable, medium urgency) </result> <result host="localhost" severity="" test_id="" name="cve " type="alarm">cve chromium (remotely exploitable, medium urgency) </result> <result host="localhost" severity="" test_id="" name="cve " type="alarm">cve libelf1 (remotely exploitable, medium urgency) </result> <result host="localhost" severity="" test_id="" name="cve " type="alarm">cve libpolkit-gobject-1-0 (low urgency)</result> <result host="localhost" severity="" test_id="" name="cve " type="alarm">cve libstdc dev (low urgency)</result> <result host="localhost" severity="" test_id="" name="cve " type="alarm">cve 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) Wie man einen OSP Wrapper baut 237

248 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 Fazit Wir haben mit 40 Zeilen Python-Quelltext eine OSP Scanner-Anbindung gescha en die die CVE- Schwachstellen-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 Kapitel 23. OpenVAS Scanner Protokoll

249 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: 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 Wie man einen OSP Wrapper baut 239

250 240 Kapitel 23. OpenVAS Scanner Protokoll

251 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: 3.1/en/GSM-Setup-GOS-3.1-en mp 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 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

252 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 ( to:support@greenbone.net). Geben Sie Ihre Lizenznummer in der an. Die Integritätsprüfsumme kann via Telefon oder Support-Portal ( bereitgestellt werden. Bitte geben Sie den bevorzugten Kanal in der E- Mail 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 gsf ova Unter Windows müssen Sie zunächst ein entsprechendes Programm installieren. Sie können hierzu Rehash verwenden, welches Sie unter finden. Um die Prüfsumme zu berechnen nutzen Sie dann: rehash.exe -none -sha256 C:\<path>\GSM-ONE gsf 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 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 Kapitel 24. Setup-Handbücher

253 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 ( 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 GSM ONE 243

254 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 Anmeldung an der Weboberfläche Der Hauptzugri auf den GSM erfolgt über die Weboberfläche. Greifen Sie mit einem aktuellen Web- Browser auf 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 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 VirtualBox- Hypervisors 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 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 Kapitel 24. Setup-Handbücher

255 Abb. 24.4: Abschalten der Hardwarebeschleunigung in VirtualBox Schritt VMware ESXi 5.1 Import des OVA Ressourcen: 2 CPUs, 4GB Ram Tastaturlayout IP-Adresskonfiguration DNS Konfiguration Ändern des Kennworts Scan Benutzer Konto SSL-Zertifikat Master Key Download Sensorkonfiguration auf dem Master Bereitschaft Erledigt 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 GSM 25V 245

256 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 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 Kapitel 24. Setup-Handbücher

257 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. Allgemeine Systemkonfiguration Alle GSM Appliances nutzen dieselben Schritte in ihrer Grundkonfiguration und der Prüfung der Bereitschaft. 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 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 GSM

258 Abb : Prüfen Sie alle Import-Einstellungen. Schritt Netzteil Serielles Konsolenkabel / USB Adapter Putty/Screen Konfiguration Tastaturlayout IP-Adresskonfiguration DNS Konfiguration Ändern des Kennworts Scan Benutzer Konto SSL-Zertifikat Master Key Download Sensorkonfiguration auf dem Master Bereitschaft Erledigt 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 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 Kapitel 24. Setup-Handbücher

259 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 Putty 145 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 : Wahl der seriellen Schnittstelle in Putty 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. Allgemeine Systemkonfiguration Alle GSM Appliances nutzen dieselben Schritte in ihrer Grundkonfiguration und der Prüfung der Bereitschaft. 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 GSM

260 24.4 GSM 100 Dieser Abschnitt beschreibt die Schritte bei der Inbetriebnahme der GSM 100 Appliance. Die folgende Checkliste hilft Ihnen dabei: Schritt Netzteil Serielles Konsolenkabel / USB Adapter Putty/Screen Konfiguration Tastaturlayout IP-Adresskonfiguration DNS Konfiguration Ändern des Kennworts Web-Administrator-Konto SSL-Zertifikat Bereitschaft Erledigt 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 Stand- Alone-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 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. 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. 250 Kapitel 24. Setup-Handbücher

261 Unter Windows können Sie Putty 146 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 : Wahl der seriellen Schnittstelle in Putty 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. Allgemeine Systemkonfiguration Alle GSM Appliances nutzen dieselben Schritte in ihrer Grundkonfiguration und der Prüfung der Bereitschaft. Bitte folgen Sie den Schritte in Kapitel Inbetriebnahme (Seite 11) und fahren Sie dann mit den folgenden Abschnitten fort Anmeldung an der Weboberfläche Der Hauptzugri auf den GSM erfolgt über die Weboberfläche. Greifen Sie mit einem aktuellen Web- Browser auf 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 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: GSM 500/510/

262 Schritt Netzteil Serielles Konsolenkabel / USB Adapter Putty/Screen Konfiguration Firmware Prüfung (>= 2.0) Tastaturlayout IP-Adresskonfiguration DNS Konfiguration Ändern des Kennworts Web-Administrator-Konto SSL-Zertifikat Bereitschaft Erledigt 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: Vorderseite Stromversorgung (einmal) VGA-Monitor Tastatur via USB Serielle Schnittstelle Tastatur via USB 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 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. 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) 252 Kapitel 24. Setup-Handbücher

263 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 Putty 147 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 : Wahl der seriellen Schnittstelle in Putty 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. 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:support@greenbone.net 148 ) bevor Sie fortfahren. Allgemeine Systemkonfiguration Alle GSM Appliances nutzen dieselben Schritte in ihrer Grundkonfiguration und der Prüfung der Bereitschaft. Bitte folgen Sie den Schritte in Kapitel Inbetriebnahme (Seite 11) und fahren Sie dann mit den folgenden Abschnitten fort Anmeldung an der Weboberfläche Der Hauptzugri auf den GSM erfolgt über die Weboberfläche. Greifen Sie mit einem aktuellen Web- Browser auf 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 support@greenbone.net GSM 500/510/

264 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 Serielles Konsolenkabel / USB Adapter Putty/Screen Konfiguration Tastaturlayout IP-Adresskonfiguration DNS Konfiguration Ändern des Kennworts Web-Administrator-Konto SSL-Zertifikat Bereitschaft Erledigt 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: Vorderseite Stromversorgung (einmal) VGA-Monitor Tastatur via USB Serielle Schnittstelle Tastatur via USB 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 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. Unter Linux kann auf der Kommandozeile das Kommando screen genutzt werden. Hier genügt es das Kommando unter Angabe der seriellen Schnittstelle aufzurufen. 254 Kapitel 24. Setup-Handbücher

265 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 Putty 149 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 : Wahl der seriellen Schnittstelle in Putty 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. Allgemeine Systemkonfiguration Alle GSM Appliances nutzen dieselben Schritte in ihrer Grundkonfiguration und der Prüfung der Bereitschaft. Bitte folgen Sie den Schritte in Kapitel Inbetriebnahme (Seite 11) und fahren Sie dann mit den folgenden Abschnitten fort Anmeldung an der Weboberfläche Der Hauptzugri auf den GSM erfolgt über die Weboberfläche. Greifen Sie mit einem aktuellen Web- Browser auf 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 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 GSM 5300/

266 Schritt Stromversorgung (zweimal) Serielles Konsolenkabel / USB Adapter Putty/Screen Konfiguration Tastaturlayout IP-Adresskonfiguration DNS Konfiguration Ändern des Kennworts Web-Administrator-Konto SSL-Zertifikat Bereitschaft Erledigt 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: Vorderseite Stromversorgung (zweimal) VGA-Monitor Tastatur via USB Netzwerkschnittstelle benannt MGMT (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 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. 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. 256 Kapitel 24. Setup-Handbücher

267 Unter Windows können Sie Putty 150 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 : Wahl der seriellen Schnittstelle in Putty 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. Allgemeine Systemkonfiguration Alle GSM Appliances nutzen dieselben Schritte in ihrer Grundkonfiguration und der Prüfung der Bereitschaft. Bitte folgen Sie den Schritte in Kapitel Inbetriebnahme (Seite 11) und fahren Sie dann mit den folgenden Abschnitten fort Anmeldung an der Weboberfläche Der Hauptzugri auf den GSM erfolgt über die Weboberfläche. Greifen Sie mit einem aktuellen Web- Browser auf 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 GSM 5300/