Prüfsoftware zum Selbsttest von Internetanschlüssen

Transkript

1 Prüfsoftware zum Selbsttest von Internetanschlüssen sen Abschlußbericht Version 1.0 / Lehrgebiet Rechnernetze und Verteilte Systeme Universität Hannover Alexander von Berg berg@rvs.uni-hannover.de Christian Grimm grimm@rvs.uni-hannover.de

2 Prüfsoftware zum Selbsttest von Internetanschlüssen 2 Inhaltsverzeichnis 1. Vorwort Motivation und Anforderungen Der Selbsttest im Überblick Beschreibung der entwickelten Prüfsoftware Erkennung von Proxies Phase 1: Browser-Informationen und Sicherheitseinstellungen Phase 2: Windows-Freigaben Phase 3: Portscanner Grundlagen Programmbeschreibung Anforderungen an Hard- und Software Auswertung Öffentlich zugängliche Auswertung Intern zugängliche Auswertung Ausgabe der Auswertung Format der Datenbanken Erfahrungen im Betrieb Ausstattung und Konfiguration des WWW-Servers Maßnahmen gegen Überlastung Betriebsstatistik... 19

3 Prüfsoftware zum Selbsttest von Internetanschlüssen 3 1. Vorwort Das Projekt Prüfsoftware zum Selbsttest von Internetanschlüssen wurde im Auftrag des Landesbeauftragten für den Datenschutz Niedersachsen erstellt. Ziel des Projektes war es, mit Hilfe einer zu entwickelnden Software sowie einem geeigneten Interface auf dem WWW-Server des LfD über das Internet Nutzern einen Test ihres eigenen Rechners auf Sicherheitsmängel anzubieten. Das Ergebnis des Projektes ist mittlerweile fest in den WWW-Server des LfD integriert und wurde am im Rahmen einer Landespressekonferenz der Öffentlichkeit vorgestellt. Hannover, den 5. September 2000

4 Prüfsoftware zum Selbsttest von Internetanschlüssen 4 2. Motivation und Anforderungen Die fortschreitende Vernetzung von PCs am Arbeitsplatz bringt, für die Betreiber in vielen Fällen unbemerkt, eine steigende Gefährdung durch Zugriffe von außen mit sich. Dabei ist weniger die Vernetzung der PCs untereinander als vielmehr der Anschluss an das Internet als wesentlicher Gefahrenpunkt anzusehen. Aufgrund der in vielen Bereichen mittlerweile notwendigen Verfügbarkeit elektronischer Dienste wie und World Wide Web ist ein Zugang zum Internet häufig jedoch unumgänglich. Folglich gehört neben einer sicherheitsbewussten Planung der Vernetzung auch die ständige Kontrolle auf mögliche Sicherheitslücken im eigenen Netz bzw. den lokalen Systemen zu den Aufgaben einer verantwortungsbewussten Systemadministration. Gerade kleinere Einrichtungen sind jedoch häufig mit einer sicherheitsbewussten Planung und Administration ihrer Vernetzung fachlich überfordert. Hier soll ein Angebot des Landesbeauftragten für den Datenschutz Niedersachsen (LfD) helfen, Schwachstellen im eigenen Netz zu erkennen und ggf. Hinweise zur Behebung vermitteln. Die Konzeption und Umsetzung eines solchen Service erfolgt im Rahmen eines Projektes mit dem RVS/RRZN an der Universität Hannover. Ziel dieses Projektes ist es, ein geeignetes Verfahren zur Prüfung von Rechnern über einen zentralen Server des LfD der Allgemeinheit zur Verfügung zu stellen. Geeignet heißt in diesem Fall, dass bestimmte Randbedingungen zu erfüllen sind, die auch dem ungeübten Benutzer die Durchführung des Selbsttests und die Abstellung von Sicherheitsmängeln ermöglichen: 1. Die Bedienung des Selbsttest erfolgt über eine allgemein bekannte Schnittstelle, nämlich einen aktuellen Standard WWW-Browser, z.b. Netscape oder Internet Explorer. 2. Zur Durchführung des Selbsttests soll keine Software-Installation notwendig sein. 3. Der Test soll in wenigen Minuten durchgeführt werden können und die Ergebnisse sollen sofort vorliegen. 4. Werden Schwachstellen erkannt, sollen Erläuterungen und Hinweise zur Abstellung gegeben werden. 5. Es soll eine statistische Auswertung der durchgeführten Selbsttests möglich sein. Die Ergebnisse werden dazu anonym, d.h. ohne Angabe von IP-Adresse oder Nutzername, gespeichert.

5 Prüfsoftware zum Selbsttest von Internetanschlüssen 5 3. Der Selbsttest im Überblick Der Selbsttest prüft einen Rechner auf Sicherheit in Bezug auf mögliche Angriffe über IP-Netze. Der Test erfolgt von außen, d.h. über die Internet-Verbindung des Rechners vom WWW-Server des LfD aus. Die Prüfsoftware läuft nicht auf dem zu testenden Rechner ab und kann somit auch keine Sicherheitseinstellungen verändern. Dies muss der Benutzer selbst vornehmen. Das Funktionsprinzip des Selbsttests ist in Abbildung 1 dargestellt. Der Benutzer ruft den Selbsttest über die Homepage des LfD mit seinem WWW-Browser auf. Der WWW-Server des LfD führt den Test über die Internet-Verbindung durch und liefert die Ergebnisse als HTML-Seite zurück. Internet PC LfD-Webserver Durchführung des Tests Abbildung 1: : Funktionsprinzip des Selbsttests Der Selbsttest gliedert sich in drei Phasen: 1. Ermitteln von Informationen über den benutzten WWW-Browser 2. Ermitteln von Windows-Freigaben Dialogsteuerung (WWW-Anfragen und -Seiten) 3. Ermitteln von offenen TCP-Ports (sog. Portscan) Vor dem Beginn des Tests werden dem Benutzer wichtige Hinweise zur Durchführung gegeben. Jede Phase wird durch Anklicken eines Hyperlinks gestartet und läuft dann automatisch ab. Die Ergebnisse werden auf der nächsten WWW-Seite dargestellt. In allen drei Phasen werden die Ergebnisse für eine spätere statistische Auswertung gespeichert. Die Speicherung erfolgt für jede Phase in einer eigenen Datei. Da die abgelegten Daten keine Angaben über die Herkunft des getesteten Rechners enthalten, kann ein Missbrauch dieser Informationen ausgeschlossen werden. Die Auswertung aller durchgeführten Tests ist vor Beginn und nach Abschluss des Tests zugänglich. Öffentlich werden vorgefertigte Tabellen angeboten; für die Mitarbeiter des LfD steht eine Schnittstelle zu Excel zur Verfügung, so dass individuelle Statistiken möglich sind.

6 Prüfsoftware zum Selbsttest von Internetanschlüssen 6 4. Beschreibung der entwickelten Prüfsoftware Bevor in den nächsten Abschnitten eine detaillierte Beschreibung der drei Phasen erfolgt, werden kurz die Probleme des Selbsttests bei der Nutzung von Proxies beschrieben Erkennung von Proxies In der Regel greifen die Nutzer direkt über das Internet auf den LfD-Webserver zu. Die Verbindung zwischen PC und LfD-Webserver wird dabei lediglich über Netzkomponenten wie Switches und Router hergestellt. Diese Komponenten vermitteln die Anfragen transparent über das Netz, d.h. der LfD-Webserver sieht die IP-Adresse des Klienten; ihm ist die Quelle der Anfragen bekannt. Internet PC LfD-Webserver Abbildung 2: : Direkter Zugriff auf LfD-Webserver In einigen Fällen, so z. B. bei der Einwahl von Heim-PCs über einige kommerzielle Provider, wird der direkte Zugriff jedoch durch Proxies (z. B. Cache-Server) unterbrochen. Der Proxy (engl. Stellvertreter) nimmt Anfragen des PCs entgegen und leitet sie an den LfD-Webserver weiter. Im Gegensatz zur direkten Verbindung bricht der Proxy die direkte Verbindung zwischen PC und LfD- Webserver auf. Dieses Verfahren ist nichttransparent, d.h. die Quell- und Zieladressen der Kommunikation stimmen nicht mehr mit dem direkten Zugriff überein. Der Proxy tritt dem LfD- Webserver gegenüber als Klient auf, der LfD-Webserver sieht folglich die IP-Adresse des Proxies und nicht die des PCs. Internet PC Proxy LfD-Webserver Abbildung 3: : Indirekter Zugriff über Proxy In diesem Fall kommt es während des Selbsttests zu Problemen, da die Prüfsoftware die Anfragen an die IP-Adresse des Absender und somit an den Proxy sendet. Zum einen führt dieses Verhalten offensichtlich zu falschen Ergebnissen, da nicht der eigentliche Klient geprüft wird. Zum anderen kann es sogar zu einer Überlastung eines Proxies führen, wenn in Phase 3 zeitgleich mehrere Portscans über denselben Proxy durchgeführt werden. Der Zugriff über Proxies sollte daher von der Prüfsoftware automatisch erkannt und der Selbsttest abgebrochen werden. Die Software ist so konzipiert, dass in zwei Fällen der Selbsttest automatisch unterbunden wird: 1. Erkennung von HTTP_X_FORWARDED_FOR oder HTTP_VIA im HTTP-Request. 2. Erkennung der Zeichenkette proxy oder cache im Rechnernamen. In der Praxis zeigt sich jedoch, dass eine zuverlässige automatische Erkennung von Proxies nicht möglich ist. Zwar wird in der HTTP-Spezifikation gefordert, dass ein Proxy in jedem HTTP-Request

7 Prüfsoftware zum Selbsttest von Internetanschlüssen 7 die Felder HTTP_X_FORWARDED_FOR oder HTTP_VIA einfügt. Hierdurch soll dem Webserver signalisiert werden, dass ein Proxy in die Kommunikation eingeschaltet ist. Es zeigte sich jedoch bei unseren Untersuchungen, dass diese Funktion von einigen Proxies nicht unterstützt wird oder von Administratoren sogar gezielt ausgeschaltet wird. Deshalb wird als dritte Maßnahme eine halbautomatische Prüfung vorgeschlagen, die jedoch von der Kooperation des Nutzers abhängt: Auf der Startseite des Selbsttests wird darauf hingewiesen, dass die Nutzer sich vor Beginn des Selbsttests vergewissern sollten, ob ihr Provider den Zugang zum Internet über Proxies realisiert. Um dem Nutzer diese Erkennung zu ermöglichen, wird auf der Startseite die IP-Adresse sowie der Name des Rechners ausgegeben, der die Anfrage an den LfD- Webserver gestellt hat. Hier erscheint entweder die IP-Adresse des Klienten oder die eines Proxies. Der Nutzer wird nun gebeten, die angezeigte IP-Adresse mit der seines Rechners zu vergleichen. Auf gängigen Windows-Systemen kann die IP-Adresse des Systems sehr einfach in einer MS-DOS- Eingabeaufforderung mit dem Kommando ipconfig oder winipcfg abgefragt werden. Stimmen die Angaben überein, kann der Selbsttest fortgeführt werden. Andernfalls sollte von einer weiteren Nutzung des Selbsttests abgesehen werden. Es ist jedoch nicht möglich, dem Nutzer die Fortführung zu verweigern Phase 1: Browser-Informationen und Sicherheitseinstellungen WWW-Browser übermitteln bei Anfragen an Webserver neben der geforderten URL auch Informationen über den verwendeten Rechner, das Betriebssystem und den verwendeten WWW- Browser selbst. Diese Informationen werden im ersten Teil von Phase 1 angezeigt. Im zweiten Teil von Phase 1 werden Sicherheitseinstellungen des WWW-Browsers überprüft und angezeigt. Bei allen Browsern wird getestet, ob Java, JavaScript oder die Annahme von Cookies aktiviert sind; beim Microsoft Internet-Explorer wird zusätzlich aus VBScript oder ActiveX geprüft. Die Erkennung der jeweiligen Informationen wurde wie folgt realisiert: Cookies Auf der Startseite (selbsttest.php) wird ein Cookie TestCookie mit einer Gültigkeitsdauer von 1 Stunde gesetzt, falls die Einstellungen im WWW-Browser dies gestatten. In Phase 1 (phase1.php) wird die Existenz dieses Cookies im WWW-Browser abgefragt. Bei erfolgreicher Prüfung wird die Meldung aktiviert ausgegeben, sonst deaktiviert. Java Auf der Startseite (selbsttest.php) wird das Java-Applet Testjava.class gestartet. Mit Hilfe dieses Applets wird in dem Verzeichnis tmp/ des Webservers eine Datei java-is-active-for-$ip-address angelegt. Anhand der im Dateinamen eingetragenen IP-Adresse ist die Datei für jeden Klienten eindeutig. Ist Java im WWW-Browser des Nutzers deaktiviert, wird die Datei nicht erzeugt. In Phase 1 (phase1.php) wird auf Existenz dieser Datei geprüft. Ist die Datei vorhanden, wird die Meldung aktiviert ausgegeben, sonst deaktiviert. Die Datei wird bei Eintritt in Phase 2 wieder gelöscht. JavaScript Phase 1 (phase1.php) enthält einem Abschnitt, der mit den HTML-Tags <Script language= JavaScript > und </Script> begrenzt wird. Der Abschnitt enthält lediglich eine

8 Prüfsoftware zum Selbsttest von Internetanschlüssen 8 Anweisung zur Ausgabe der Zeichenkette aktiviert. Weiterhin enthält die Seite einen Abschnitt, der mit den HTML-Tags <NoScript> und </NoScript> begrenzt wird. Dieser Abschnitt enthält die Anweisung zur Ausgabe der Zeichenkette deaktiviert. Ist JavaScript im Browser implementiert und aktiviert, wird der Abschnitt <Script>...</Script> durchlaufen, sonst <NoScript>...</NoScript>. Entsprechend erscheinen die jeweiligen Zeichenketten in der Ausgabe. VBScript Die Prüfung auf VBScript verläuft ähnlich zu JavaScript. Phase 1 (phase1.php) enthält einem Abschnitt, der mit den HTML-Tags <Script language= VBScript > und </Script> begrenzt wird. Der Abschnitt enthält lediglich eine Anweisung zur Ausgabe der Zeichenkette aktiviert. Weiterhin enthält die Seite einen Abschnitt, der mit den HTML-Tags <NoScript> und </NoScript> begrenzt wird. Dieser Abschnitt enthält die Anweisung zur Ausgabe der Zeichenkette deaktiviert. Ist VBScript im Browser implementiert und aktiviert, wird der Abschnitt <Script>...</Script> durchlaufen, sonst <NoScript>...</NoScript>. Entsprechend erscheinen die jeweiligen Zeichenketten in der Ausgabe. ActiveX Die Prüfung auf ActiveX verläuft ähnlich zu Java. Über die Startseite (selbsttest.php) wird das ActiveX Control ActiveXTest.dll gestartet. Mit Hilfe dieses Controls wird in dem Verzeichnis tmp/ des Webservers eine Datei activex-is-active-for-$ip-address angelegt. Anhand der im Dateinamen eingetragenen IP-Adresse ist die Datei für jeden Klienten eindeutig. Ist ActiveX im WWW-Browser des Nutzers deaktiviert, wird die Datei nicht erzeugt. In Phase 1 (phase1.php) wird auf Existenz dieser Datei geprüft. Ist die Datei vorhanden, wird die Meldung aktiviert ausgegeben, sonst deaktiviert. Die Datei wird bei Eintritt in Phase 2 wieder gelöscht Phase 2: Windows-Freigaben Unter Windows-Freigaben sind Verzeichnisse und Drucker auf dem eigenen Rechner zu verstehen, die für Zugriffe über das Netzwerk, von fremden Rechnern aus, freigegeben sind. Zur Ermittlung der Windows-Freigaben dienen zwei Programme aus dem Samba-Paket. Samba ( ist eine freie UNIX-Implementierung des File- und Printer-Sharing- Mechanismus von Windows. Samba ermöglicht es UNIX-Servern, als Windows-SMB-Server aufzutreten und Verzeichnisse und Drucker Windows-Rechnern transparent zur Verfügung zu stellen. Für den Selbsttest werden lediglich zwei Hilfsprogramme aus dem Samba-Paket der Version eingesetzt. Das Programm nmblookup ermittelt bei vorgegebener IP-Adresse den Windows-eigenen Namen des Rechners, die Arbeitsgruppe und eventuell den Namen des angemeldeten Benutzers, sofern der Benutzer mit Namen angemeldet ist und nicht Windows 95 installiert ist. Der Windows-eigene Name des Rechners wird im Dialog Eigenschaften der Netzwerkumgebung eingetragen und stimmt nicht zwangsläufig mit dem DNS-Namen des Rechners überein. Das Programm smbclient fragt die freigegebenen Verzeichnisse und Drucker ab. Dazu muss ein Benutzername und ein Passwort angegeben werden. Wird das Passwort weggelassen, so werden nur die Verzeichnisse und Drucker angezeigt, die für Gastnutzer freigegeben sind. Unter Windows 95 und 98 sind dies üblicherweise alle, für die kein explizites Passwort gesetzt wurde. Unter Windows NT und 2000 muss dafür zusätzlich die Gastkennung aktiviert sein.

9 Prüfsoftware zum Selbsttest von Internetanschlüssen 9 Ausgabe HTML- Kopfdaten Ermittle IP- Adressen Auswertung der Phase1 Proxy entdeckt? ja nein Ausgabe: Warnhinweis Teste Port 139 Port 139 offen? ja Ermittle Betriebssystem nein Ausgabe: keine Verbindung Ermittle Rechner- Informationen (nmblookup) BS-Info erhalten? nein ja Informationen erhalten? nein ja Ermittle Rechner- Informationen (smbclient) ja Fehler aufgetreten? nein Ausgabe: keine Freigaben Ausgabe: keine Antwort Ausgabe: Windows 9x Ausgabe: Betriebssystem Schreibe Ergebnis Suche nach Freigaben Abbildung 4: : Flussdiagramm von Phase 2 Abbildung 4 zeigt den Ablauf von Phase 2. Phase 2 ist in der Datei phase2.php implementiert. Zu Beginn werden die Ergebnisse von Phase 1 in die Log-Datei geschrieben. Vor dem eigentlichen Test wird zunächst geprüft, ob ein Proxy verwendet wird. Dies erfolgt analog zum Vorgehen in Phase 1, wobei hier keine weitere Bestätigung durch Markieren einer Checkbox erfolgen muss. Der eigentliche Test beginnt mit einem Verbindungsaufbau zu Port 139 des Zielrechners. Schlägt diese Verbindung fehl, so erübrigt sich der ganze weitere Test. Es wird eine entsprechende

10 Prüfsoftware zum Selbsttest von Internetanschlüssen 10 Meldung erzeugt und abgebrochen. Dieser Fall tritt auf, wenn entweder eine Firewall den Zielrechner schützt oder der Zielrechner kein Windows-Betriebssystem hat. Anderenfalls werden mit nmblookup die o.e. Rechnerdaten abgefragt. Liefert die Abfrage keine Ergebnisse, so sind keine Freigaben vorhanden und eine entsprechende Meldung wird ausgegeben. Lässt sich aus der Ausgabe von nmblookup das Betriebssystem nicht ablesen, so erfolgt eine weitere Prüfung mit einem Abruf von smbclient, bei dem nur entscheidend ist, ob ein Fehler auftritt oder nicht. Tritt kein Fehler auf, so handelt es sich um Windows 9x, tritt ein Fehler auf, so sind keine Freigaben vorhanden und über das Betriebssystem kann keine Aussage gemacht werden. Wurde ein Windows-Betriebssystem identifiziert, so erfolgt die Ermittlung der Freigaben mit smbclient. Dazu werden Abfragen mit dem ermittelten Benutzernamen und verschiedenen Passworten durchgeführt. Als Passwort werden der Leerstring, der Benutzername, der Rechnername und die Arbeitsgruppe verwendet. Anschließend werden Abfragen mit der Gastkennung und leerem Passwort durchgeführt. Sobald Freigaben gefunden wurden, wird der Test abgebrochen. Die gefundenen Freigaben werden nach Verzeichnissen und Druckern separat ausgegeben. Im letzten Schritt werden die Ergebnisse in die Log-Datei phase2.db geschrieben Phase 3: Portscanner Grundlagen Ports bilden auf Rechnern im Internet die Anfangs- und Endpunkte von Datenverbindungen. Internet-Adresse und Portnummer bilden zusammen eine eindeutige Kennzeichnung des Verbindungsanfangs-, bzw. -endpunkts. Es gibt auf einem Rechner pro Internet-Adresse je Ports für das TCP- und für das UDP-Protokoll. Einige dieser Ports sind fest für bestimmte Internet- Dienste (z.b. TELNET, FTP, HTTP) reserviert, andere können frei verwendet werden. Aktuelle Listen findet man bei der IANA (Internet Assigned Numbers Authority, Liste der registrierten Port-Nummern: Liste der registrierten Service-Namen: Man unterscheidet zwischen zwei Arten, einen Port zu verwenden: als Client und als Server. In der Betriebsart Client wird aktiv eine Verbindung zu einem bestimmten Port eines Rechners mit bekannter Internet-Adresse aufgebaut. Der eigene Port, der verwendet wird, wird i.d.r. vom Betriebssystem aus der Menge der freien Ports gewählt. In der Betriebsart Server wird ein Verbindungsendpunkt auf dem eigenen Rechner eingerichtet, der auf Verbindungsanfragen von Clients wartet. Der Server bietet anfragenden Clients bestimmte Dienste an, z.b. das Versenden einer . Ein solcher Server-Port wird als offen bezeichnet. Versucht ein Client eine Verbindung zu einem Port aufzubauen, an dem kein Server wartet, so erhält er eine entsprechende Meldung. Ein solcher Port, der keine Verbindung akzeptiert, wird als geschlossen bezeichnet. Bleibt eine solche Fehlermeldung an den Client aus, sei es, weil das Betriebssystem keine verschickt, sei es, weil eine dazwischen geschaltete Firewall, die Verbindungsanfrage abgefangen hat, so weiss

11 Prüfsoftware zum Selbsttest von Internetanschlüssen 11 der Client nicht, ob unter der angegebenen Internet-Adresse überhaupt ein Rechner aktiv ist. Ein solcher Port, dessen Existenz nicht festgestellt werden kann, wird als geschützt bezeichnet. Offene und geschlossene Ports verraten jedem potentiellen Angreifer das Vorhandensein des Rechners im Internet. Die beschriebenen Zustände der Ports können mit Hilfe einfacher, jedem zugänglicher Programme (Portscanner) abgefragt und ausgewertet werden. Je weniger ein Rechner dabei an Informationen preisgibt, umso besser ist er geschützt. Offene Ports bilden die primären Angriffspunkte für Angreifer. Angriffe können zum einen das Ziel haben, den Rechner durch viele Verbindungsanfragen zu überlasten und so komplett zu blockieren (Denial-Of-Service-Attacken), zum anderen, in den Rechner selbst einzubrechen, um Daten abzurufen oder zu manipulieren. Viele Serverdienste an offenen Ports haben bekannte Schwachstellen, die von Angreifern ausgenutzt werden können. Das Abfragen der Port-Zustände eines Rechners (Portscan) hilft nicht nur dem Angreifer. Es kann auch zum Schutz, d.h. zur Überprüfung der Sicherheit des Rechners eingesetzt werden. Viele Betriebssysteme starten grundsätzlich zunächst viele Dienste, um den Benutzern möglichst viel Komfort zu bieten. Oft geschieht dies aber ohne Meldung und ohne entsprechende Hinweise auf die Gefahren, die von den damit verbundenen offenen Ports ausgehen. Hier hilft ein selbst durchgeführter Portscan, die Dienste zu identifizieren, so dass nicht benötigte gezielt abgeschaltet werden können. Eine große Gefahr geht auf Mehrbenutzersystemen von Diensten aus, die von unvorsichtigen Benutzern selbst gestartet werden. Oft sind dies Spiele-Server oder CHAT-Server. Deren Schwachstellen können wiederum von Angreifern genutzt werden. Ein regelmäßiger Portscan kann helfen, solche Dienste zu erkennen. Alle nicht benötigten Dienste sollten abgeschaltet werden. Guten Schutz bieten Firewall-Systeme, die das ganze lokale Netz nach außen hin abschotten. Nur noch wirklich benötigte Verbindungen werden durchgelassen, alle anderen gesperrt. Will man einzelne Rechner ohne eine Firewall schützen, empfehlen sich TCP-Wrapper. Dies sind Programme, die zwischen den Port und den eigentlichen Dienst geschaltet werden und bei einem Verbindungsaufbau zunächst anhand von Regeln prüfen, ob die Verbindung zulässig ist. Diese Regeln sind mit denen von Firewalls vergleichbar, d.h. anhand von Ausgangsadresse und -port sowie Zielport wird entschieden, ob die Verbindung angenommen oder abgelehnt wird Programmbeschreibung Der Portscanner ermittelt, welche TCP-Ports des Zielrechners einen Verbindungsaufbau zulassen, welche ihn ablehnen und bei welchen keine Antwort erfolgt. Die Ergebnisse werden in einer Tabelle mit farbiger Markierung angezeigt, wobei für jeden Port noch ergänzende Hinweise gegeben werden können. Der Portscanner ermittelt zu Beginn die Internet-Adresse und den Namen des zu scannenden Rechners und prüft, ob ein Proxy benutzt wird. Zur Kontrolle werden diese Informationen noch einmal dargestellt, so dass Benutzer, die ihre Internet-Adresse kennen, eine zusätzliche Kontrollmöglichkeit haben.

12 Prüfsoftware zum Selbsttest von Internetanschlüssen 12 Proxy ermitteln, IP-Adresse ermitteln Hinweise ausgeben Proxy verwendet? ja Liste der zu scannenden Ports erzeugen Datei "services" Hinweis ausgeben nein alle Ports gescannt? Ende nein n Verbindungen Rechnername ermitteln Socket erzeugen und Verbindung öffnen ja Rechnerdaten ausgeben Timeout? nein Verbindung angenommen nein ja ja Ergebnisse speichern Datei "scanner.log" Ergebnis "Port geschützt" speichern Ergebnis "Port offen" speichern Ergebnis "Port geschlossen" speichern Ergebnisse ausgeben Ende Abbildung 5: : Flussdiagramm des Portscanners Der Port-Scan erfolgt anschließend in der Weise, dass eine bestimmte Anzahl der zu testenden Ports jeweils parallel gescannt wird, um Zeit zu sparen. Momentan sind dies 50 Ports; jedoch ist diese Zahl abhängig von Betriebssystem-Parametern und der durchschnittlichen Last auf dem Server, so dass hier eventuell im Produktionsbetrieb noch eine Anpassung erfolgen muss. Erfolgt auf die Verbindungsanfrage von einem Port keine Antwort, so wird nach drei Sekunden angenommen, dass dieser Port durch eine Firewall geschützt ist und der Scan dieses Ports wird abgebrochen. Dieses Zeitintervall kann ebenfalls variiert werden, wenn sich zeigt, dass größere Verzögerungen bei der Verbindung zu bestimmten Zielrechnern auftreten.

13 Prüfsoftware zum Selbsttest von Internetanschlüssen 13 Nach Abschluss der Scans werden die ermittelten Ergebnisse in einer Tabelle ausgegeben. Die Einträge sind nach der Portnummer sortiert und enthalten neben dieser den ermittelten Status des Ports (offen, geschlossen, geschützt), das Protokoll (nur TCP), den registrierten Namen des Ports (z. B. FTP, HTTP) und optional einen Text, der weitere Informationen zu dem Port sowie Hyper-Links zu anderen Informationsquellen enthalten kann. Diese Texte werden im HTML-Code in einer Datei abgelegt und können jeder Zeit ergänzt und geändert werden, da die Datei bei jedem neuen Scan gelesen wird. Unter der Ergebnistabelle werden die drei möglichen Zustände der Ports kurz erläutert. Die Ergebnisse werden außerdem zur Auswertung in eine Log-Datei geschrieben. Das Format und die weitere Nutzung dieser Log-Datei wird in Abschnitt 4.5 beschrieben. Der Portscanner ist in C++ unter Verwendung der Standard-C++-Bibliothek und einigen Hilfsklassen des RVS geschrieben und wird als CGI-Programm (scanner.cgi) aufgerufen. Folgende Dateien werden verwendet: main.cc portscan.cc portscan.h ScannerPage.cc ScannerPage.h Makefile services-comments nmap-services scanner.log Hauptprogramm Scanner-Funktionen Header-Datei für Scanner-Funktionen HTML-Funktionen für Ausgabe Header-Datei für HTML-Funktionen Steuerdatei für make (zur Erstellung von scanner.cgi) Kommentare und Hinweise Servicenamen (von nmap übernommen) Logdatei für die Ergebnisse 4.5. Anforderungen an Hard- und Software Die Entwicklung des Selbsttest erfolgte auf einem Rechner am RVS. Folgende Voraussetzungen werden an ein System gestellt, auf dem der Selbsttest angeboten werden soll. Dabei ist zu beachten, dass die Hardware-Ausstattung nach der Anzahl zu erwartender gleichzeitiger Zugriffe dimensioniert werden muss (vgl. Kapitel 6). Software: o o UNIX-basiertes Betriebssystem, z.b. Linux 2.2.x Apache-Webserver (min empfohlen) mit PHP4-Modul o PHP4-Interpreter (standalone) für Auswertung Hardware: o Samba (Version 2.0.7) o Intel Pentium II 233 MHz oder höher für Linux (für andere UNIX-Derivate entspr. Modelle)

14 Prüfsoftware zum Selbsttest von Internetanschlüssen 14 o o o 128 MByte Hauptspeicher, 256 MByte empfohlen 1 GByte freier Festplattenspeicher für die Log-Dateien Fast-Ethernet (100 Mbps)

15 Prüfsoftware zum Selbsttest von Internetanschlüssen Auswertung Die Ergebnisse der drei Phasen des Selbsttests werden in eigenen Datenbanken gespeichert und stehen für detaillierte Auswertungen zur Verfügung. Die abgelegten Daten enthalten dabei lediglich einen Zeitstempel sowie die ermittelten sicherheitsrelevanten Informationen. Angaben über die Herkunft des Klienten (z. B. IP-Adresse oder Nutzername) werden nicht abgelegt, so dass von vornherein eine Anonymisierung der Daten vorliegt. Die Auswertung wird für jede der drei Phasen getrennt durchgeführt. Die Ergebnisse werden in textbasierten Tabellen dargestellt und sind in zwei Varianten verfügbar: in einer einfachen öffentlichen Form sowie einer erweiterten Form, die lediglich internen Zwecken dienen sollte Öffentlich fentlich zugängliche Auswertung Um Interessierten einen einfachen Überblick über die Ergebnisse der durchgeführten Selbsttests zu ermöglichen, werden Auswertungen öffentlich auf dem WWW-Server des LfD zur Verfügung gestellt. Ein Link auf die entsprechenden Seiten befindet sich auf der Startseite des Selbsttests (selbsttest.php). Um evtl. Missbrauch vorzubeugen, wird die öffentliche Auswertung täglich um 4:00 Uhr nachts für einen vordefinierten Zeitbereich generiert. Der Beginn des Zeitraums ist durch den Administrator festzulegen, das Ende wird automatisch auf den vergangenen Tag festgelegt. Ein weiterer Vorteil dieses Ansatzes besteht in der geringen Belastung des WWW-Servers. Würden die öffentlich zugänglichen Auswertungen für jede Anfrage on the fly aus den Datenbanken generiert, wäre entsprechend hohes Interesse an den Auswertungen vorausgesetzt eine Überlastung des Servers zu erwarten. Zur Generierung der öffentlichen Auswertung dient das Skript make_auswertung.sh. Als Aufruf des Skriptes empfiehlt sich die tägliche Ausführung als sog. Cronjob. Hierzu wurde ein entsprechender Eintrag in die crontab des Nutzers root auf dem Server vorgenommen Intern zugängliche Auswertung Eine erweiterte Auswertung steht für interne Zwecke des LfD zur Verfügung. Zunächst kann der Zeitraum der betrachteten Auswertung über ein Menü ausgewählt werden; die Auflösung beträgt einen Tag. Weiterhin steht als Ausgabeformat neben der HTML-Tabelle auch eine sog. Comma Separated List (CSV) zur Verfügung. Diese Liste kann in herkömmliche Programme zur Tabellenkalkulation (z. B. Microsoft Excel) importiert und weiter verarbeitet werden. Auf diesem Wege lassen sich mit geringem Aufwand grafische Diagramme über einen ausgewählten Zeitraum erstellen (s. Abbildung 6).

16 Prüfsoftware zum Selbsttest von Internetanschlüssen 16 Phase 1: Browser-Sicherheitseinstellungen im Zeitraum bis (Bezug: alle 424 getesteten Browser im genannten Zeitraum) Prozent Cookies aktiviert JavaScript aktiviert Java aktiviert VBScript aktiviert Abbildung 6: : Auswertung auf Basis einer Excel-Tabelle Da im Gegensatz zur öffentlichen die interne Auswartung on the fly erfolgt, kann es bei großen Datenbanken zu erheblichen Bearbeitungszeiten und somit Verzögerungen bis zu Darstellung der Ergebnisse kommen. Es ist zu berücksichtigen, dass bei einer häufigen Nutzung der internen Auswertung der Betrieb des WWW-Servers durch Überlastung beeinträchtigt werden kann Ausgabe der Auswertung Dieser Abschnitt enthält eine kurze Übersicht über die Informationen, die bei der Auswertung der drei Phasen ausgegeben werden. Jede Ausgabe enthält zuerst die Angabe des betrachteten Zeitraumes sowie die Anzahl der darin berücksichtigten Abfragen. Weiterhin enthält die Auswertung der jeweiligen Phasen folgende Angaben: Phase 1 User Agent (z. B. Netscape, Internet Explorer) Betriebssystem (z.b. Windows 98, Windows 2000, MacOS) Sicherheitseinstellungen (Cookies, Java, JavaScript, VBScript, ActiveX) Phase 2 Betriebssystem (nur Unterscheidung auf Windows oder nicht) Windows Freigaben (Erkannte Freigaben, Freigaben unter verschiedene Kombinationen aus Username/Password)

17 Prüfsoftware zum Selbsttest von Internetanschlüssen 17 Phase 3 Portnummer Name des Service Zustand (gesamte Anzahl Offen, Geschlossen oder Geschützt) 5.4. Format der Datenbanken Die Ergebnisse der drei Phasen des Selbsttests werden in getrennten Datenbanken abgelegt. Die Datenbanken sind vollständig textbasiert; jede Zeile entspricht einem Testereignis. Im folgenden werden die drei Dateien aufgeführt und ihr Aufbau dargestellt. Dabei werden die Einträge in den einzelnen Felder nicht im Detail erklärt, sondern lediglich in der Übersicht zusammengefasst. Die Datenbanken für Phase 2 und 3 können, je nach Häufigkeit erkannter Freigaben oder offener Ports, innerhalb einer Zeile mehrere, durch Kommata getrennte Einträge, umfassen. Phase 1 Dateiname: phase1.db Timestamp, Useragent, OS, Cookie, JavaScript, Java, VBScript, ActiveX Phase 2 Dateiname: phase2.db Timestamp, OS, Liste erkannter Freigaben Anmerkung: die Liste erkannter Freigaben kann ggf. mehrere Einträge enthalten Phase 3 Dateiname: phase3.db Timestamp, gescannter Bereich, Liste von Portnummern [T U] [O F] Anmerkung: in den meisten Fällen werden mehrere Listen von Portnummern eingetragen Anmerkung: die Angabe T und U stehen für TCP bzw. UDP. Da der Portscan per Konfiguration nur über TCP-Ports durchgeführt wird, erscheint in der Ausgabe stets T. Anmerkung: die Angabe O und F stehen für Open bzw. Firewalled. Ports, die in der Datenbank nicht aufgeführt werden, gelten als geschützt.

18 Prüfsoftware zum Selbsttest von Internetanschlüssen Erfahrungen im Betrieb Das offizielle Angebot eines Selbsttests für Internet-Nutzer des LfD wurde im Rahmen einer Landespressekonferenz am der Öffentlichkeit vorgestellte. Dieser Abschnitt fasst die Ausstattung des Servers sowie Betriebserfahrungen, die in der ersten Tagen gesammelt werden konnten, zusammen Ausstattung und Konfiguration des WWW-Servers Der Selbsttest ist auf einem eigenständigen Server (check.lfd.niedersachsen.de) im iznnet installiert. Der Server ist wie folgt ausgestattet: Prozessor: Pentium III 500 MHz Hauptspeicher: 256 Mbyte Netzanbindung: 100 Mbps Fast Ethernet Betriebssystem: Linux (aus SuSE 6.2) Webserver: Apache Module: PHP/4.0b4pl1, mod_ssl/2.6.2, OpenSSL/0.9.5 Um eine verschlüsselte Übertragung der Testergebnisse zu gewährleisten, verwendet der Server ausschließlich HTTP über Secure Socket Layer (SSL). Das für die Verschlüsselung notwendige offizielle Zertifikat wurde bisher nicht installiert, so dass lediglich eine am ablaufende Version zum Einsatz kommt Maßnahmen gegen Überlastung Bereits kurze Zeit nach Veröffentlichung des Selbsttests zeigte sich, dass bei einer hohen Anzahl gleichzeitiger Nutzer ein leistungsfähiger Server notwendig ist. Als kritische Prozesse stellten sich aufgrund hohen Speicherbedarfs die dynamische Auswertung mit freier Auswahl des betrachteten Zeitraumes sowie der Portscan in Phase 3 heraus. Die dynamischen Auswertungen sind daher nur noch intern verfügbar (s. Kapitel 5.2) und sollten in Hauptverkehrszeiten nicht häufig durchgeführt werden. Der Portscan benötigt maximal, d.h. kurz vor Ablauf eines vollständigen Scans der Ports 0 bis 65535, annähernd 20 MByte Hauptspeicher. Bei einer Ausstattung von 256 MByte Hauptspeicher kommt es rechnerisch bereits bei 13 gleichzeitig durchgeführten Portscans zu einem Engpass aufgrund mangelnden Hauptspeichers. Folge sind deutlichen Einbußen der Performance aller Prozesse bis hin zum Stillstand des gesamten Servers. In der Praxis zeigt sich mittlerweile, dass bis zu 20 gleichzeitige Portscans bearbeitet werden können. Die gesamte Anzahl gleichzeitig möglicher Verbindung wurde in der Konfigurationsdatei des Webservers (Option MaxClients in /etc/httpd/httpd.conf) auf 35 begrenzt. Das bedeutet, dass bei 35 bereits etablierten Verbindungen weitere Verbindungsanforderungen in eine Warteschlange gestellt und erst dann bearbeitet werden, wenn bestehende Verbindungen beendet werden. Hierdurch kommt es bei vollständig belegtem Webserver ggf. zu längeren Wartezeiten für die Nutzer, bis er überhaupt eine Antwort des Webservers erhalt. Ist die Verbindung jedoch etabliert, erhält der Nutzer die Ergebnisse in akzeptabler Zeit. Dieses Verhalten ist aus Sicht des Betreibers

19 Prüfsoftware zum Selbsttest von Internetanschlüssen 19 eher tolerierbar als ein dauerhaft überlasteter Server. Ein weiteres Heraufsetzen der Anzahl gleichzeitig möglicher Verbindungen darf nur mit dem Ausbau des Hauptspeichers einhergehen Betriebsstatistik Zur Veranschaulichung des Nutzerverhaltens wird in regelmäßigen Abständen eine Betriebs- und Zugriffsstatistik erstellt. Es werden Zugriffe auf einzelne Dateien und auf Seiten sowie Besuche pro Tag, pro Stunde und pro Domain gezählt und grafisch dargestellt. Die Betriebsstatistik ist unter abrufbar. Abbildung 7 zeigt die Verteilung der Besucher auf die Toplevel-Domains. Die Mehrzahl der Besucher mit über 50% kam aus der.net-domain der Internet-Service-Provider, die sich nur manuell den einzelnen Ländern zuordnen ließe. An zweiten Stelle mit 34% kamen Besucher aus der.de-domain. Ein geringer Prozentsatz der Zugriffe kam von Rechnern ohne DNS-Namen. Abbildung 7: : Verteilung der Besucher auf die Toplevel-Domains In den ersten Tagen nach der Freigabe des Dienstes am besuchten etwa 3000 Nutzer pro Tag den Check-Server, wobei ca Seiten pro Tag aufgerufen wurden. Abbildung 8 zeigt die Tagesstatistik für den August 2000 mit Seiten, Dateien, Besuchen, Rechnern und Datenmenge.

20 Prüfsoftware zum Selbsttest von Internetanschlüssen 20 Abbildung 8: : Tagesstatistik für August 2000