Konzeption und Aufbau eines Nessus Servers zur Sicherheitsüberprüfung von Enterpriseumgebungen
Aus Winfwiki
| Name des Autors / der Autoren: | Kevin Stagat |
| Titel der Arbeit: | "Konzeption und Aufbau eines Nessus Servers zur Sicherheitsüberprüfung von Enterpriseumgebungen" |
| Hochschule und Studienort: | FOM Essen |
Inhaltsverzeichnis |
1 Einleitung
„Im ersten Jahrzehnt des 21. Jahrhunderts haben sich die Methoden der Cyberkriminalität dramatisch gewandelt. Was einst das Metier von Aufmerksamkeit heischenden Teenagern war, ist heute ein organisiertes Verbrechen zur finanziellen Bereicherung geworden. Früher machten sich Virenschreiber einen Spaß daraus, Schädlinge an anstößige Bilder zu koppeln und über ihre Malware-Errungenschaften zu prahlen. Heutzutage greifen Hacker gezielt Unternehmen an, um personenbezogene Daten zu stehlen, komplexe Netzwerke missbrauchter Computer aufzubauen oder aber Einzelpersonen ihrer Identität zu berauben.“[1]
So beschreibt die Firma Sophos in ihrem aktuellen Security Thread Report 2010 die momentane Sicherheitssituation.
Die folgende Gegenüberstellung früherer und heutiger IT-Systeme bildet die Grundlage zur Erklärung dieses Wandels
| IT-Systeme früher | IT-Systeme heute |
| Computer waren sehr teuer, so dass sie sich nur wenige leisten konnten | Computer sind für fast jeden erschwinglich und somit weit verbreitet |
| Die Rechenleistung war gering und Speicher sehr klein und teuer | Moderne Computersysteme besitzen trotz niedriger Preise eine hohe Rechenleistung und Speicher sind (im Vergleich zu damals) extrem gewachsen und dazu günstiger geworden |
| Folgerung:
| Folgerung:
|
Einen Beleg für diese Aussage bietet die folgende Grafik, die eine Analyse der entdeckten Schwachstellen über die Jahre 1988 bis 2008 aufzeigt. Schwachstellen sind die Grundlage für Cyberkriminelle, um in Computersysteme einzudringen und so an die begehrten Daten zu kommen. Man erkennt, dass mit dem zunehmenden Einzug von Computersystemen in die Unternehmensinfrastruktur und der zunehmenden Speicherung von Daten auf Computersystemen auch die Anzahl an gefundenen Schwachstellen jährlich wächst.
Sicherheitsspezialisten (White Hats), Cyberkriminelle (Black Hats) und solche die dazwischen liegen (Grey Hats), liefern sich einen regelrechten Kampf um die Entdeckung und Schließung von Sicherheitslücken.
2 IT-Sicherheit im Unternehmen
Dieser Gefahrenlage ist sich heutzutage jedes Unternehmen mehr oder weniger bewusst.
Die Märkte haben auf die neuen Umstände reagiert. Es entstanden neue Berufsfelder im Bereich IT-Sicherheit und ein stetig wachsender Markt an innovativen Sicherheitsprodukten und Dienstleistungen, welche die Unternehmensdaten sichern sollen.
Die Installation von Sicherheitssystemen reicht jedoch bei weitem nicht aus. Ein Unternehmen muss ein Sicherheitskonzept erarbeiten, das sowohl organisatorische, wie auch betriebliche und technische Aspekte einbezieht. Die folgende Tabelle stellt eine grobe Übersicht über die Bereiche dar, mit denen sich ein Sicherheitskonzept befassen muss.
| Organigramm |
|
| Datensicherheit |
|
| Systemsicherheit |
|
| Sicherheit der Infrastruktur |
|
Diese Auflistung stellt nur einige der grundlegenden Fragestellungen dar, die im Rahmen der Erstellung eines Sicherheitskonzeptes gestellt werden müssen und erhebt keinen Anspruch auf Vollständigkeit.
2.1 Sicherheitsrisiken aus Unternehmenssicht
Die Firma Symantec hat im Jahr 2010 die Studie State of Enterprise Security 2010 [2]verfasst, in der sie sicherheitsverantwortliche Führungskräfte von Unternehmen (CSO, CISO, IT Manager) befragte, welches für sie die größte Bedrohung der Unternehmenssicherheit ist.
| Häufigkeit der Antworten | Art der Bedrohung |
| 42 % | Cyberattacken |
| 17 % | Traditionelle Kriminalität |
| 17 % | Brände |
| 14 % | Naturkatastrophen |
| 10 % | Terrorismus |
Im gleichen Report wurden die Probanden zur Häufigkeit der Angriffe befragt, denen ihr Unternehmen jährlich ausgesetzt ist. Das Ergebnis ist gleichzeitig die Begründung dafür, wieso in obiger Tabelle die Cyberattacken mit einem Vorsprung von 25 % vor allen anderen Bedrohungen liegt.[3]
| Häufigkeit der Antworten | Ausmaß der Angriffe (letzte 12 Monate) |
| 2 % | Opfer einer extremen Anzahl von Angriffen |
| 9 % | Opfer einer großen Anzahl von Angriffen |
| 18 % | Opfer regelmäßiger Angriffe |
| 46 % | Opfer einer geringen Anzahl von Angriffen |
| 25 % | Kein Opfer von Angriffen |
Die wirtschaftlichen Folgen solcher Angriffe sind für Unternehmen enorm. Neben einem drohenden Imageverlust bei seinen Kunden bis hin zum Verlust von Geschäftsgeheimnissen, die ein Unternehmen Millionen kosten kann, wenn nicht sogar den wirtschaftlichen Ruin, ist die gesamte Bandbreite vorhanden.[4]
2.2 Risikomanagement im Unternehmen
Ein Unternehmen muss diesen Bedrohungen entgegenwirken. Sicherheitssysteme sind jedoch teuer und professionelles Personal rar. Das fehlende interne Know-How stellt eines der größten Probleme dar, mit denen sich ein Unternehmen in diesem Zusammenhang konfrontiert sieht. Somit kommt es nicht selten vor, das ein technischer Sicherheitsbeauftragter (RSO) ein normaler IT-Mitarbeiter ist, dem die Aufgabe der IT-Sicherheit zusätzlich zu seinem Alltagsgeschäft anvertraut wird. Ein Mangel an Zeit und weitreichendem technischen Know-How sind nur zwei Gründe, wieso die IT-Sicherheit oft zu kurz kommt. Bedingt durch diesen Umstand werden zunehmend externe Sicherheitsfirmen beauftragt, die sich auf die Durchführung von Penetration Tests spezialisiert haben.
Aufgrund der hohen Kosten für solche Tests werden diese nur in unregelmäßigen Abständen in Unternehmen durchgeführt. Abstände von 2 Jahren oder mehr sind hier die Regel. Das Ergebnis eines solchen Tests ist aber lediglich eine Momentaufnahme des eigenen Sicherheitsstatus. Die Sicherheitsprüfung der eigenen Infrastruktur ist jedoch kein einmaliges Ereignis, sondern ein „Prozess und kein Produkt“.[5]
Themen wie Applikation Security, Mobile Security, Data Security, Vulnerybility Management, Information Security und Risk Management sowie Sicherheitsüberprüfungen sollten daher heutzutage im Fokus technischer Unternehmenssicherheit stehen und regelmäßig durchgeführt werden.
Sicherheitsanwendungen wie Virenscanner und Firewall gehören zwar schon lange zur Standardausstattung moderner Computersysteme, doch dieser Schutz reicht alleine nicht aus um die darauf befindlichen Daten dauerhaft zu schützen. Exploits nutzen Schwachstellen aus, gegen die eine solche Ausstattung meistens machtlos ist. Viel wichtiger geworden sind eine nach Sicherheitsaspekten erstellte Infrastruktur, gehärtete Systemkonfigurationen, eine sichere Programmierung von Webapplikationen und die zeitnahe Installation von Softwareaktualisierungen. Das Problem liegt hierbei in der Kontrolle der Umsetzungen. Wie soll ein Sicherheitsverantwortlicher mit fehlendem Fachwissen diese Anforderungen überprüfen?
Für diese Aufgabe gibt es eine ganze Reihe an kommerziellen Programmen, von denen nur eines auch in einer kostenfreien Version verfügbar ist.
3 Nessus – der Schwachstellenscanner
Nessus, ein Produkt der Firma Tenable Network Security, ist das einzige frei verfügbare Programm, das dieser Aufgabe gerecht wird. Seine Aufgabe besteht darin computergestützte Systeme nach bekannten Schwachstellen zu untersuchen, Konfigurationsfehler aufzudecken und Complianceanforderungen zu prüfen und zu überwachen. Der Aufbau und die Benutzung eines solchen Systems ist Thema dieser Seminararbeit.
3.1 Produktbeschreibung
Das Produkt Nessus ist der Weltmarktführer der aktiven Schwachstellenscanner und sowohl in einer kostenfreien (HomeFeed), als auch einer kommerziellen (ProfessionalFeed) Variante erhältlich.[6]
Nessus bietet dem Anwender eine ganze Reihe an Funktionen und Sicherheitstests, die im Folgenden aufgelistet sind:
- High-Speed Erkennung,
- Prüfung von Konfigurationseinstellungen,
- Prüfung von Compliance Anforderungen (z.B. PCI DSS),
- Bereitstellung von Auditvorlagen für lokale Systemkonfigurationen nach vorgegebenen Standards (z.B. Microsoft Standard für Sicherheitskonfiguration von Enterprise Rechnern),
- Entdeckung von sensiblen Informationen,
- Schwachstellen Analyse.
Der Unterschied zwischen der kostenfreien und der kommerziellen Variante liegt in der Anzahl der verfügbaren Funktionen und Tests, sowie der Supportunterstützung und der Schnelligkeit, mit der neue Scan-Plugins verfügbar sind.[7]
Der große Vorteil von Nessus liegt in der dahinter stehenden Community.[8]
Während andere Anbieter von Konkurrenzprodukten ihre Plugins selbst erstellen und verteilen, werden Plugins und Auditvorlagen bei Nessus durch eine breite Community bereitgestellt, an der sich Sicherheitsexperten weltweit beteiligen. So kommt es nicht selten vor, dass es bereits Plugins für CVEs gibt, die gerade erst bekannt gemacht wurden oder noch auf ihre Veröffentlichung warten.
Ein weiterer nennenswerter Punkt ist die programmeigene Skriptsprache, der NASL (Nessus Attack Scripting Language), mit der Plugins auf einfache Art und Weise geschrieben werden können und durch die Nessus unter anderem so erfolgreich ist.[9]
3.2 Planung einer Nessus Umgebung
Die Planung der Serverinstallation ist ein wichtiger Schritt beim Aufbau eines Nessus Servers. Fehler die an dieser Stelle gemacht werden, wirken sich später nicht nur auf die Systemsicherheit von Nessus selbst aus, sondern auf das gesamte Netzwerk. Zu bedenken ist hier die Tatsache, dass die Funktionalität von Nessus gleichermaßen nützlich und gefährlich für die interne Infrastruktur ist. Ein schlecht abgesicherter Server kann wie alle Systeme unter fremde Kontrolle fallen und im Falle von Nessus wäre dies fatal. Einem Angreifer würde durch dieses System ein mächtiges Werkzeug an die Hand gegeben werden, das alle Schwachstellen im Netzwerk aufdeckt. Ein Traum für jeden Hacker.
Im Folgenden werde ich daher die einzelnen Schritte erläutern, die nötig sind um den Server optimal zu installieren, platzieren und zu nutzen.
3.2.1 Installation des Servers
Als erstes muss das richtige Betriebssystem gewählt werden. Nessus unterstützt eine breite Palette an Betriebssystemen, darunter Windows, Linux, Mac OS, FreeBSD und Sun Solaris. Aus Kompatibilitätsgründen werden für ein Unternehmensnetzwerk die Systeme von Microsoft und Linux die größte Rolle spielen. Von diesen beiden Möglichkeiten sollte die Wahl auf ein Linux System als Basis fallen, aus folgenden Gründen:
- Linux bietet die Möglichkeit ein minimales Basissystem zu installieren (Es werden nur die nötigsten Pakete und Dienste installiert, damit Linux lauffähig ist. Somit wird die Fläche für Fehler und Angriffe auf ein Minimum reduziert.)
- Linux bietet die Möglichkeit das System vollständig zu konfigurieren, was bei Windows nur eingeschränkt möglich ist.
- Für Linux Systeme kursieren weniger Schadprogramme im Netz und sie stehen nicht so im Fokus von Hackern wie Windows Systeme. Somit ist die Gefahr einer Infizierung oder Fremdübernahme geringer als bei Windows Systemen.
- Linux bietet ein effizienteres Systemhandling (z.B. die Behandlung von Diensten).
- Linux bietet trotzdem die Möglichkeit an ein Directory System angeschlossen zu werden.
Die Wahl fällt somit auf SUSE Linux Enterprise Server 10 (64bit). Das Produkt Red Hat Enterprise Server wäre eine weitere Möglichkeit in diesem Umfeld gewesen.
3.2.2 Platzierung des Servers im internen Netzwerk
Als nächstes muss der richtige Ort gefunden werden, an dem der Server aufgestellt und mit dem Netzwerk verbunden wird. An diesem Punkt müssen einige Voraussetzungen beachtet werden, die sich aus der Aufgabe des Systems ergeben.
- Nessus muss alle Systeme uneingeschränkt erreichen können. Diese Aufgabe wird die schwerste sein, da viele Gegebenheiten wie Subnetze, das interne Routing, ACLs (Access Control List), etc. beachtet werden müssen.
- Nessus muss eine Vertrauensbasis im internen Netzwerk genießen. IDS Systeme und Firewalls dürfen die Tests nicht blocken, außer man will ihre Funktionsfähigkeit testen.
- Ein ProfessionalFeed Updateservers muss erreichbar sein, um die Plugin Datenbank auf dem aktuellsten Stand halten zu können.
- Der Nessus Server darf nicht über das Internet erreichbar sein.
- Es dürfen nur die Clients den Server erreichen, deren Benutzer mit dem Server arbeiten sollen.
3.2.3 Bestimmung berechtigter Benutzergruppen
Neben den vorangegangenen Aspekten muss weiterhin die Benutzergruppe bestimmt werden, die Zugriff auf den Nessus Scanner erhalten sollen. Da Nessus eine eigene Benutzerverwaltung besitzt, die an kein Directory angeschlossen werden kann, sollte die Zusammenstellung der Gruppe gut durchdacht werden. Nessus biete die Möglichkeit Benutzerkonten als normalen Benutzer oder als Administrator einzustufen. Normale Benutzer können weiterhin auf das Scannen bestimmter IP Adressen oder IP Adressbereiche beschränkt werden. Besitzt das Unternehmen ein eigenständiges IT-Security Team, sollte nur Mitarbeitern aus diesem Personenkreis Zugriff auf das Programm gegeben werden. Gibt es ein solches Team nicht und nimmt auch kein Mitarbeiter diese Aufgaben zentral wahr, so sollte jeder Systemadministrator einen normalen Account bekommen und die Beschränkung der IP Adressen sollte auf die von ihm verwalteten Geräte eingerichtet werden.
3.3 Das Einsatzkonzept
Nessus besitzt tausende von Plugins, die in „Families“ gruppiert sind. Man könnte nun regelmäßig eine einzige Policy, die alle Families enthält, auf das gesamte Netzwerk loslassen. Dieses Vorgehen wäre jedoch ineffektiv, da somit das Netzwerk durch nutzlose Tests unnötig belastet werden würde. Es ist daher ratsam für die verschiedenen Einsatzzwecke spezielle Policies zu erschaffen.
Die folgende Tabelle stellt eine Übersicht dar welche Policy Konfiguration für welche Systemart genutzt werden sollte und wann die Scans durchzuführen sind:
| Policy Familie | Zu scannende Systeme | Häufigkeit / Zeitpunkt |
|
Local Security Checks:
| Alle Systeme mit entsprechendem Betriebssystem |
|
| Alle Systeme |
|
| Webseiten |
|
| Alle CISCO Geräte |
|
| Alle Systeme mit entsprechender Funktion |
|
| All Unix basierten Systeme |
|
| Alle Systeme mit installiertem Finger Deamon |
|
| Alle Firewall Systeme |
|
| Alle Novell Netware Systeme |
|
| Alle SCADA Systeme |
|
| Alle Windows Systeme |
|
3.3.1 Erstellung von Scanvorlagen
Um die Scan Einstelungen nicht für jeden Scan neu erstellen zu müssen, bietet Nessus die Möglichkeit Scan Templates zu erstellen. So sollte man nach der eigentlichen Installation und Grundkonfiguration des Servers ein Angebot an Scan Vorlagen erstellt werden, das die internen Mitarbeiter nutzen können. Die Menge und Art der Policies richtet sich nach der vorliegenden IT Landschaft. Das nachfolgende Beispiel soll einen Einstieg in die Erstellung eines Templates geben.
Erstellung eines Templates am Beispiel einer Webserver Policy
Zuerstmuss man sich mit dem WebGUI von Nessus verbinden. Dazu ruft man in einem Browser über das https Protokoll die IP Adresse des Servers auf Port 8834 auf und meldet sich mit seinen Benutzerdaten an.
Nun wählt man innerhalb der GUI den Menüpunkt „Policies“ aus und wählt dort die Option „Add“ zum Hinzufügen einer neuen Policy.
Die Konfiguration beginnt mit dem Reiter „General“, auf dem die grundlegenden Einstellungen vorgenommen werden.
An dieser Stelle konfigurieren wir folgende Einstellungen:[10]
| Bereich „Baisc“ | |
| Name
| Wir nennen die Policy TMP_Webserver. TMP steht dabei für Template und über den Namen „Webserver“ geben wir den Einsatzbereich der Policy an. |
| Visibility
| Da ein Template außer vom Ersteller auch von allen anderen Nessus Benutzern genutzt werden soll, muss hier der Wert „Shared“ eingestellt werden |
| Description
| Eine kurze Beschreibung der Policy kann in dieses Feld eingefügt werden. |
| Bereich „Scan“ | |
| Save Knowledge Base
| Diese Option aktivieren, damit die Scanergebnisse hinterher auch dauerhaft auf dem Nessus Server gespeichert werden. Das vereinfacht spätere Vergleiche der Systemzustände über mehrere Scans hinweg. |
| Safe Checks
| Diese Option sollte standardmäßig aktiviert sein. Durch sie werden keine Systeme mit gefährlichen Plugins gescannt, die sie zum Abstürzen bringen können. Zum scannen einzelner Systeme sollte man sie jedoch ausschalten. Besonders für neuinstallierte Systeme ist ein Scan ohne diese Option bereits ein guter Härtetest. |
| Silent Dependencies
| Durch die Aktivierung dieser Option werden Ausgaben von Plugins, die aus Gründen der gegenseitigen Abhängigkeit automatisch mitgestartet wurden, nicht angezeigt. Ob man diese zusätzlichen Informationen sehen möchte oder nicht, ist Geschmackssache. Zur besseren Übersicht lassen wir sie in unserem Template aktiviert. |
| Log Scan Details to Server
| Möchte man sehr detaillierte Informationen im Server Log haben, sollte diese Option nachträglich aktiviert werden. Für normale Scans kann sie deaktiviert bleiben. |
| Stop Host Scan on Disconnect
| Mit dieser Option bringt man Nessus dazu den Scan eines Hosts abzubrechen, wenn dieser nicht mehr erreichbar zu sein scheint. Um keinen unnötigen Traffic zu erzeugen und den Scan nicht unnötig in die Länge zu ziehen, sollte man diese Option aktivieren. |
| Avoid Sequential Scans
| Diese Option ist hilfreich, wenn man größere IP Bereiche scannt. Mit Hilfe von „Avoid Sequential Scans“ kann man IP Bereiche nach dem Random Prinzip scannen und somit die Last des Scans verteilen. Beim scannen kleinerer Gruppen wie in unserem Beispiel macht diese Option jedoch nicht viel Sinn und bleibt daher deaktiviert. |
| Consider Unscanned Ports as Closed
| Mit dieser Option stellt man ein, ob ungescannte Ports als geschlossen berichtet werden sollen. Wir aktivieren diese Option, da wir nur einen bestimmten Portbereich scannen sollen und uns der Rest der Ports nicht interessiert. |
| Designate Hosts by their DNS Name
| Durch Aktivierung dieser Option werden in den Report anstelle der IP Adressen die DNS Namen der gescannten Hosts aufgeführt. Sie ist gerade beim Scannen von Clients in Netzwerken mit dynamischen DHCP sehr nützlich, um die Reportergebnisse auch nach einiger Zeit noch eindeutig zuordnen zu können. Da die IP Adressen von Webservern fest vergeben sind, brauchen wir diese Option nicht und lassen sie deaktiviert. |
| Bereich “Network Congestion” | |
| Reduce Parallel Connections on Congestion
| Bei größeren Scans sollte diese Option aktiviert werden, um das Netzwerk mit Anfragen nicht zu überlasten. Bei einem kleineren Scan wie unserem wird diese Option jedoch nicht benötigt. |
| Use Kernel Congestion Detection (Linux only)
| Nessus kann auf die System Leistungsdaten von Linux Systemen zugreifen um eine Überlastung des Netzwerkes zu entdecken. Sie sollte auf Nessus Servern, die auf Linux installiert wurden, aktiviert werden, wenn die Option „Reduce Parallel Connections on Congestion“ genutzt wird. |
| Bereich “Port Scanners” | |
| TCP Scan
| Durch aktivieren dieser Option schalten wir den TCP Portscanner von Nessus ein, um nach offenen Ports zu suchen, die nicht erwünscht sind. |
| SYN Scan
| Durch aktivieren dieser Option schalten wir den SYN Portscanner von Nessus ein, um nach offenen Ports zu suchen, die nicht erwünscht sind. |
| SNMP Scan
| Durch aktivieren dieser Option schalten wir den SNMP Portscanner von Nessus ein, um nach offenen Ports zu suchen, die nicht erwünscht sind. |
| Netstat SSH Scan
| Durch aktivieren dieser Option schalten wir den Netstat Portscanner von Nessus ein, um über eine SSH Verbindung lokal nach offenen Ports zu suchen, die nicht erwünscht sind. Für diese Option müssen wir später Anmeldeinformationen für das zu scannende System bereitstellen. Diese Option ist nur für Zielsysteme auf Linux Basis verfügbar. |
| Netstat WMI Scan
| Durch aktivieren dieser Option schalten wir den Netstat Portscanner von Nessus ein, um über eine WMI Verbindung lokal nach offenen Ports zu suchen, die nicht erwünscht sind. Für diese Option müssen wir später Anmeldeinformationen für das zu scannende System bereitstellen. Diese Option ist nur für Zielsysteme auf Windows Basis verfügbar. |
| Ping Host
| Durch aktivieren dieser Option schalten wir den Ping Portscanner von Nessus ein, um nach offenen Ports zu suchen, die nicht erwünscht sind. |
| Bereich “Port Scan Options” | |
| Port Scan Range
| Hier geben wir den Portbereich ein, mit dem der Server gescannt werden soll. Da auf Webservern verschiedene Webpages und Applikationen auf unterschiedlichen Ports laufen können, sollte die Port Range mit dem Wert „default“ eingestellt bleiben. Hinter dem Wert „default“ verbergen sich 4.790 so genannte Common Ports, die uns für unseren Test genügen. Man kann hier jedoch auch normale Adress-Notationen anwenden (Portranges, Gruppen, Aufzählungen, etc). Diese Einstellung wirkt sich sowohl auf TCP, als auch auf UDP Portscanner aus. |
| Bereich “Performance” | In diesem Bereich können Performance Optimierungen vorgenommen werden. Da sie für unseren Scan unwichtig sin, werden sie auf Platzgründen nicht näher beschrieben. |
Nach Abschluss der Konfiguration auf der Seite „General“ gehen wir nun zum Reiter „Credentials“. Einige Plugins müssen lokal auf den Systemen ausgeführt werden (Bsp. Netstat SSH Scan). Um sich mit den Systemen verbinden zu können, benötigen die Plugins gültige Benutzerrechte, die man ihnen an dieser Stelle mitgeben kann.
Je nach Systemumgebung der eigenen Webserver (Windows IIS oder Linux Apache) müssen hier die root, bzw. die Administrator Anmeldedaten angegeben werden.
Für Windows Server müssen unter „Windows Credentials“ die folgenden Felder ausgefüllt werden:
- SMB Account
- SMB Password
- SMB Domain (optional) – nur notwendig falls der Benutzeraccount von einem Domänenbenutzer ist
- SMB Password Type
Analog dazu müssen für Linux Systeme die folgenden Angaben unter „SSH settings“ getätigt werden:
- SSH Username
- SSH password, alternativ Angabe der Daten für eine Anmeldung per PKI
- Elevate privileges with (wie wird auf dem Linux System der Wechsel zum root User vollzogen?)
Dieses Beispiel zeigt die SSH Settings für ein Linux System auf dem man sich remote nicht mit root anmelden darf. Wir melden uns somit mit dem Benutzer „audit“ an und wechseln später über den Befehl „sudo“ zu User root.
Nachdm die Zugangsdaten konfiguriert wurden, wählen wir im Bereich „Plugins“ die Tests aus, die wir nutzen wollen. Da wir nur Webserver scannen möchten, reicht hier die Auswahl der Plugin Family „Web Servers“. Alle anderen Plugin Families bleiben ungenutzt (grauer Kreis, anstelle eines gelben neben dem Family Namen).
Der Bereich „Preferences“ stellt verschiedene Funktionen zur Verfügung, mit denen man seine Policies noch verfeinern kann. Für unsere Policy benötigen wir hier jedoch keine weiteren Einstellungsmöglichkeiten, belassen diese somit auf den Standardwerten und beenden die Erstellung unserer Policy über den Button „Submit“.
Nun müssen wir unser Scan Template erstellen, das als Konfiguration unsere eben erstellte Policy enthält und die IP Adressen der zu scannenden Webserver.
Wir gehen dazu auf den Menüpunkt „Scans“ und wählen dort die Funktion „Add“ aus.
Zuerst müssen wir dem Scan Template einen Namen geben. Wir wählen hier den Namen TMP_Webserver. Weiterhin müssen wir unter „Type“ angeben, das es sich um ein Template handelt, da der Scan sonst sofort ausgeführt wird und unsere Einstellungen des Scan Templates am Ende verschwinden würden (die Policy Konfiguration bleibt davon unberührt).
Über den Button „Save Template“ speichern wir unser Template nun in der Scanliste ab.
3.3.2 Durchführung eines Scans
Um den Scan nun zu starten, wählen wir das gewünschte Template aus der Liste und wählen die Funktion „Launch“ aus der Navigationsleiste.
Nach Abschluss des Scans erscheint der Scan Report im Bereich „Reports“.
An dieser Stelle kann man sich durch markieren des Scan Reports und der Nutzung der Funktion „Browse“ die Ergebnisse des Scans anzeigen lassen.
Weiterhin bekommt man an dieser Stelle die Möglichkeit einzelne Scanreports mittels der Funktion „Compare“ zu vergleichen (z.B. um Unterschiede zwischen dem aktuellen und vorherigen Scans deutlich machen zu können) oder die Reports über die Funktion „Download“ lokal im Format .html oder im Nessus eigenen Format .nessus abzuspeichern.
3.3.3 Nessus Plugin Aktualisierungen
Um über die regelmäßigen Aktualisierungen informiert zu bleiben und Systeme mit aktualisierten Policies erneut scannen zu können, bietet die Firma Tenable RSS Feeds für neue Plugins an. Diese sind zu erreichen unter den Adresse:
| NewNessus Plugins | http://www.nessus.org/rss-plugins.xml |
| Nessus Configuration Auditing Plugins | http://www.nessus.org/rss-audit.xml |
| New PVS Plugins | http://www.nessus.org/pvs.xml |
| Nessus and PVS Sensitive Data Auditing Updates | http://www.nessus.org/rss-content.xml |
| LCE Correlation and Normalization Updates | http://www.nessus.org/rss-lce-updates.xml |
| Product Releases and Updates | http://www.nessus.org/rss-releases.xml |
4 Fazit
Nessus ist ein sehr nützliches Werkzeug, das nach einer kurzen Einarbeitungsphase und bei richtiger Anwendung einfach und effektiv zu nutzen ist. Mit seiner Vielfältigkeit und der dahinter stehenden Community, die zeitnah neue Plugins entwirft und veröffentlicht, steht einem Unternehmen somit ein mächtiges Werkzeug zur Verfügung, mit dem die IT Sicherheit der unternehmenseigenen Infrastruktur dauerhaft überprüft und gesichert werden kann.
5 Abkürzungsverzeichnis
| Abkürzung | Bedeutung |
|---|---|
| CGI | Common Gateway Interface |
| CISO | Chief Information Security Officer |
| CSO | Chief Security Officer |
| CVE | Common Vulnerabilities and Exposures |
| DNS | Domain Name System |
| FTP | File Transfer Protocol |
| RPC | Remote Procedure Call |
| RSO | Regional Security Officer |
| SCADA | Supervisory Control and Data Acquisition |
| SMTP | Simple Mail Transfer Protocol |
| SNMP | Simple Network Management Protocol |
6 Abbildungsverzeichnis
| Abb.-Nr. | Abbildung |
|---|---|
| 1 | http://www.scip.ch/labs/images/statistik_veroeffentlichung_vulnerabilities.png |
| 2 | Nessus 4.2 User Guide, S. 6 |
| 3 | Nessus 4.2 User Guide, S. 6 |
| 4 | Nessus 4.2 User Guide, S. 7 |
| 5 | Nessus 4.2 User Guide, S. 11 |
| 6 | Nessus 4.2 User Guide, S. 13 |
| 7 | Nessus 4.2 User Guide, S. 16 |
| 8 | Nessus 4.2 User Guide, S. 30 |
| 9 | Nessus 4.2 User Guide, S. 31 |
| 10 | Nessus 4.2 User Guide, S. 32 |
| 11 | Nessus 4.2 User Guide, S. 33 |
7 Literaturverzeichnis
| Sophos & Utimaco (2010) | Security Threat Report 2010 (Report) |
| Symantec (2010) | State of Enterprise Security 2010 (Report) |
| Tenable Network Security (2010) | Nessus 4.2 - User Guide |
8 Fußnoten
- ↑ Vgl. Sophos & Utimaco – Security Threat Report 2010 S.3
- ↑ Vgl. Symantec – State of Enterprise Security 2010 (Report) S. 6
- ↑ Vgl. Symantec – State of Enterprise Security 2010 (Report) S. 8
- ↑ Vgl. Symantec – State of Enterprise Security 2010 (Report) S. 3
- ↑ Vgl. Bruce Schneier [2000] http://www.schneier.com/crypto-gram-0005.html
- ↑ Vgl. http://nessus.org/nessus/
- ↑ Vgl. http://nessus.org/nessus/
- ↑ Vgl. http://www.searchsecurity.de/themenbereiche/plattformsicherheit/schwachstellen-management/articles/193337/
- ↑ Vgl. http://www.searchsecurity.de/themenbereiche/plattformsicherheit/schwachstellen-management/articles/193337
- ↑ Vgl. Nessus 4.2 User Guide, S. 7-11
