Dante Report für 217.162.230.227 Dante Security Scanner 2.0 Thu, 20 Jun 2002 22:06:05 +0200 Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux) Zielsystem: 217.162.230.227 Scanmodus: heavy Information für 217.162.230.227: Webbrowser über $HTTP_USER_AGENT gefunden Überblick: CGI ist die Abkürzung für Common Gateway Interface, was einen Standard für die serverseitige Programmierung von Webseiten darstellt. In diesem Standard wird ein Kommando spezifiziert, anhand dessen der von den Besuchern eingesetzte Webbrowser in Erfahrung gebracht werden kann. Gefahr: Ein Angreifer kann die durch diese Funktion gegebenen Möglichkeiten zu bösartigen Zwecken missbrauchen - Zum Beispiel ist er dadurch in der Lage die eingesetzte Software seiner Besucher abzuleiten, um dann einen generischen Angriff auf diese zu starten. Test: Folgend nun die Ausgabe der Abfrage für Ihren Webbrowser: Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux) Lösung: Am effizientesten ist es, den eigenen Webbrowser dazu zu veranlassen, dass er falsche oder gar keine Informationen über sich preisgibt. In den meisten Fällen (z.B. Internet Explorer, Netscape und Opera) wird dies nicht möglich sein. Hierbei kann ein Application-Gateway genutzt werden, dass eben genau die unerwünschte Preisgabe der Informationen rechtzeitig erkennt und unterbindet. Siehe: Bitte konsultieren Sie die Vulnerability-Datenbank von SecurityFocus, um sich einen Überblick der für Ihren Browser relevanten Sicherheitslücken zu machen. [Nach oben] [Nach unten] Information für 217.162.230.227: Linux gefunden Überblick: Linux ist ein freies, unix-basierendes Betriebssystem, das vom Finnen Linus Torvald entwickelt wurde. Gefahr: Wie jedes Betriebssystem hat auch Linux mit Sicherheitslücken zu kämpfen. Da Linux und ein Grossteil der dafür geschriebenen Software der General Public License (GPL) unterliegen, kann jeder den Quelltext des Programms eingesehen werden. Sicherheitslücken werden so sehr schnell entdeckt. In Angreifer-Kreisen sind die Angriffsmöglichkeiten auf Linux bestens bekannt. Test: Dieser Punkt wurde durch das Auslesen der $HTTP_USER_AGENT-Variable (Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux)) getätigt. Solange diese nicht durch ein Application-Gateway oder direkt im System manipuliert wurde, können Falschmeldungen gänzlich ausgeschlossen werden. Lösung: Seien Sie sich stets den Sicherheitslücken Ihres Betriebssystems bewusst. Dies bedeutet, dass Sie sich durch das Lesen verschiedener Security-Newsgroups und -Newsletter auf dem Laufen halten sollten. Zudem gilt es alle Vorkehrungen zur Wahrung und Stärkung der Systemsicherheit zu treffen. Hierzu zählt das Einspielen aller zur Verfügung stehenden Patches und das Nutzen von Sicherheitslösungen (z.B. Firewalls und Intrusion Detection-Systeme). Siehe: Bitte konsultieren Sie die Vulnerability-Datenbank von SecurityFocus, um sich einen Überblick der für Ihr Betriebssystem relevanten Sicherheitslücken zu machen. Die aktuellsten Patches können Sie auf der Webseite des Linux-Distributors oder des Software-Herstellers beziehen. [Nach oben] [Nach unten] Information für 217.162.230.227: nslookup möglich Überblick: Durch das Nutzen von nslookup-Befehlen, wie zum Beispiel nslookup oder host, können die Netzwerkdaten einer IP-Adresse, eines Adressblocks oder einer Domäne identifiziert werden. Gefahr: Der erste Schritt bei der Auswertung der Netzwerkdaten ist die mit dem Ziel verbundenen Netzwerke zu identifizieren. Mit den daraus extrahierbaren Hintergrundinformationen wird das solide Fundament für Social Engineering gelegt; oder entsprechende Informationen für spezifische Angriffe auf die EDV-Infrastruktur, zum Beispiel Attacken auf die Nameserver, ausgespäht. Test: Folgend die nslookup-Ausgabe für 217.162.230.227: Unable to get information about domain -- try again later. Der Test wurde mit der simplen Eingabe von "host -l 217.162.230.227" durchgeführt. Die Chancen, dass dieser Test erfolgreich verläuft liegt bei nahezu 100 %, denn eine jede IP-Adresse sollte durch eine DNS-Datenbanken vermerkt werden. Probleme werden erst in einer solchen Situation zu Tage gefördert, bei der der entsprechende Namesserver nicht durch den Dante Scanner ansprechbar ist Für den erweiterten Umgang mit den nslookup-Tools, konsultieren Sie bitte die entsprechende Lektüre. Lösung: Die Problematik der DNS-Datenbanken ist daher präsent, weil sie für den öffentlichen Zugriff bestimmt sind. Es gilt so wenige Informationen wie möglich durch die Nameserver bekannt zu geben. Dies schliesst unter anderem mit ein, dass keine Zonetransfers erlaubt werden bzw. gänzlich der öffentliche Zugriff auf interne Nameserver mittels Firewalling unterbunden wird. Siehe: In Kapitel 1.2.2 (Die Auswertung der Netzwerkdaten, Seiten 39 bis 49) der zweiten Auflage des "Anti-Hacker-Buchs" (2001) von George Kurtz, Stuart McClure und Joel Scambray wird sehr ausführlich über die whois-Problematik berichtet. Ebenso ist im "Security-Guide" (Version 3.0) von Marc Ruef im Kapitel 1.3 (Auswertung der Netzwerkdaten) das Thema abgehandelt. In "Maximum Protection" (2001) , geschrieben von Ryan Russel und Stace Cunningham, wird in Kapitel 12.2.5 (Netzwerk/Computer ausspionieren, Seiten 455 bis 458), leider etwas unübersichtlich, die Funktionalität von whois erläutert. Im Buch "IT-Crackdown" (dritte Auflage, 2000) von Othmar Kyas und Markus a Campo wird Social Hacking mit finger und whois leider nur ganz kurz in Kapitel 7.4.6 (Seiten 218 und 219) angerissen. Das Kapitel 5.1 (Whois - Die Hintermänner aufdecken, Seiten 288 bis 291) in der zweiten Auflage des "Anti-Hacker Report" (2001) von Wolfram Gieseke befasst sich ebenso knapp mit whois-Abfragen. [Nach oben] [Nach unten] Information für ICMP: ICMP echo request-Anfragen möglich Überblick: Mit dem weitverbreiteten Netzwerk-Utility "ping" kann ein Host auf seine Erreichbarkeit hin überprüft werden. Zu diesem Zweck wird ein ICMP echo request-Paket (Typ 8) an das Ziel geschickt, welches bei entsprechender Netzwerkaktivität mit einem ICMP echo reply-Paket (Typ 0) reagiert. Einzelne Pings können mit dem gleichnamigen Tool umgesetzt werden, welches bei nahezu jedem TCP/IP-fähigen Betriebssystem beigelegt ist. Für einen weitreichenden Ping-Suchlauf, bei dem ein ganzer Adressblock nach erreichbaren Hosts abgesucht werden soll, können UNIX-Programme wie gping, fping, hping oder nmap genutzt werden. Für Windows ist Pinger von Rhino9 sehr empfehlenswert. Gefahr: Ein Angreifer wird sich vor der Einleitung eines Angriffs gerne von der Erreichbarkeit eines Hosts überzeugen lassen. Genau hier kommt die Ping-Prozedur ins Spiel. Werden diese Antworten nicht korrekt beantwortet, aber dennoch eine Kommunikation mit dem Ziel möglich, so kann irgendwo zwischen den beiden Kommunikationspartnern ein Firewall-Element vermutet werden, das den ICMP-Verkehr einschränkt. Topologische und organisatorische Hintergründe werden so entdeckt. Diese Informationen ist für den Eindringling Gold wert, denn dementsprechend vorsichtiger bzw. zielstrebiger wird er vorgehen. Zudem ebnen erlaubte ICMP-Pakete den Weg zu einer Hand voll protokollspezifischer Attacken: Von ICMP-Stürmen über Denial of Service-Attacken bis hin zu ICMP-basierende Remote-Control-Programme (z.B. loki). Test: Folgend die Ping-Ausgabe des Ping-Suchlaufs auf den Rechner 217.162.230.227: PING 217.162.230.227 (217.162.230.227): 56 data bytes 64 bytes from 217.162.230.227: icmp_seq=0 ttl=242 time=23.532 ms 64 bytes from 217.162.230.227: icmp_seq=1 ttl=242 time=87.396 ms 64 bytes from 217.162.230.227: icmp_seq=2 ttl=242 time=27.454 ms --- 217.162.230.227 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 23.532/46.127/87.396 ms Der Test wurde mit der Eingabe von "ping -c 3 217.162.230.227" durchgeführt. Die Chancen, dass dieser Test erfolgreich verläuft liegt bei etwa 85 %. Die Ausgaben können stark verfälscht werden, wenn Load-Balancing zum Einsatz kommt. Lösung: Netzwerk- und hostbasierende Intrusion Detection Systeme (IDS), wie zum Beispiel Snort oder ISS RealSecure, können Ping-Suchläufe entdecken und protokollieren. Hostbasierende Lösungen aus dem Freewarebereich für Windows zu finden ist sehr schwer. Lediglich Genius 3.1 bietet sich für solche Zwecke an. Einfacher wird das Abwehren von ICMP echo requests am Netzwerk-Perimeter. Firewall-Elemente können darauf getrimmt werden ankommende ICMP echo request-Pakete (Typ 8) und abgehende ICMP echo reply-Pakete (Typ 0) zu verwerfen. Siehe: Die Routing-Fähigkeit von IP-Adressbereichen wird in RFC 1918 abgehandelt. Kapitel 2.1 (Ping-Suchläufe im Netzwerk, Seiten 61 bis 71) der zweiten Auflage des "Anti-Hacker-Buchs" (2001) von George Kurtz, Stuart McClure und Joel Scambray widmet sich sehr ausführlich den Ping-Suchläufen. Im "Security-Guide" (Version 3.0) von Marc Ruef wird das Kapitel 2.2 (Ping-Suchläufe) der besagten Problematik gewidmet. Überblickend widmen sich Othmar Kyas und Markus a Campo in ihrem Buch "IT-Crackdown" (dritte Auflage, 2000) den ICMP-Angriffen (Kapitel 6.3.2, Seiten 164 bis 168). Die Eigenarten von ICMP werden von Ryan Russel und Stace Stunningham auf den Seiten 110, 384 und 459 ihres Buches "Maximum Protection" (2001) eingestreut. Eine kurze Einführung in Ping gib es im "Anti-Hacker Report" (2001) von Wolfram Gieseke (zweite Auflage, Ping - Wer bist Du, Seiten 284 bis 286). Für das weitere Verständnis von ICMP-Mapping-Techniken kann ich ohne zu Zögern das Buch "IDS: Intrusion Detection-Systeme" (2001) empfehlen. Stephen Northcutt und Judy Novak tragen einmal mehr in ihrem Buch auf brilliante Art und Weise Ihre Analysen vor (Kapitel 4.2, Mapping-Techniken, Seiten 105 bis 110). [Nach oben] [Nach unten] Information für 217.162.230.227: Informationen bei Google gefunden Überblick: Google gilt als einer der populärsten und mächtigsten automatisierten Index-Suchmaschinen im Internet. Gefahr: Da Google eine Vielzahl von Daten aus dem World Wide Web indexiert und teilweise auch archiviert, ist es eine ausgezeichnete Fundgrube für Informationen. Ein Angreifer kann diese für seine Vorhaben gebrauchen (z.B. Social Engineering). Test: Der Test wurde so durchgeführt, dass eine entsprechende Suchanfrage für den Host 217.162.230.227 bei Google gestartet wurde. Das resultat hierzu finden Sie auf
http://www.google.de/search?q=217.162.230.227. Lösung: Gehen Sie so restriktiv wie Möglich mit Informationen zu Ihrer Person und der von Ihnen eingesetzten Computer-Umgebung um. Das bedeutet, möglichst keine Daten auf Webseiten und im Internet allgemein bekann zu geben. Die Chancen sind einfach zu gross, dass diese für längere Zeit archiviert werden. Siehe: Das Anti-Hacker-Buch und der Anti-Hacker-Report liefern einige gute Informationen und Beispiele zu dieser Informations-Problematik. [Nach oben] [Nach unten] Information auf TCP-Port 22 (SSH): SSHD-Banner können abgegriffen werden Überblick: So manches Programm der Anwendungsschicht begrüsst den Benutzer bei der Verbindungsaufnahme mit Software-Name und -Versionsnummer. Gefahr: Für einen Angreifer ist das Wissen um die eingesetzte Software Gold wert. Neben dem Ableiten des genutzten Betriebssystems kann er sich auf die generischen Schwachstellen der entsprechenden Software einstellen (z.B. Sicherheitslücken suchen, Konfigurationsfehler kennenlernen und Exploits finden). Angriffsform: Die einfachste Möglichkeit den Banner abzufangen, ist die Terminal-Emulation Telnet oder das TCP/IP-Tool NetCat zu nutzen. Es gibt aber auch spezielle Software, wie zum Beispiel Dobin "Anthraxx" Rutishausers mban.c, das für den Zweck des Abgreifens der Banner geschrieben wurde. Test: Folgend die Ausgabe des Banners für TCP-Port 22 (SSH) des Rechners 217.162.230.227: SSH-1.99-OpenSSH_3.1p1 Protocol mismatch. Der Test wurde mit der Eingabe von "echo -e "\n" |nc -i 5 -w 10 217.162.230.227 22" durchgeführt. Dieser Test verläuft bei einem System mit einer typischen Standardinstallation der Netzwerkdienste stets erfolgreich. Heutzutage ist es selten gesehen, dass auf dem Zielsystem oder unterwegs die Banner modifiziert werden; daher sind diesem Plugin glücklicherweise false positives vorbehalten. Sorgt ein Firewall-Element oder Intrusion Detection System dafür, dass der angesprochene Rechner keine korrekten Rückantworten geben kann, so wird der Test langwierig und verfälscht. Die Wartezeiten sind dennoch sehr kurz und betragen im schlimmsten Falle höchstens 10 Sekunden. Lösung: Wie immer gilt es unnötige Dienste auf dem System am besten zu deinstallieren bzw. deaktivieren, um eine möglichst geringe Angriffsfläche zu bieten. Zusätzlich empfiehlt sich das Nutzen eines Firewall-Elements oder Intrusion Detection Systems, das unerlaubte Zugriffe erkennen, protokollieren und abwenden kann. Eine nette Lösung wäre auch die Banner der Anwendungsdienste zu modifizieren, um den Angreifer in die Irre leiten zu können. Konsultieren Sie hierfür die Dokumentation Ihrer Software. Siehe: Das Banner-Grabbing wird verhältnismässig kurz in der zweiten Auflage des "Anti-Hacker-Buchs" (2001) von George Kurtz, Stuart McClure und Joel Scambray behandelt. Auf den Seiten 135 bis 137 werden die traditionellen Techniken mittels Telnet und NetCat erläutert. In Kapitel 2.4.3 (Das Betriebssystem anhand der Ports erkennen) des "Security-Guide" (Version 3.0) von Marc Ruef wird ebenso am Rande das Thema angeschnitten. Othmar Kyas und Markus a Campo zeigen in "IT-Crackdown" (2001) auf den Seiten 144 bis 150 (Kapitel 6.1.1, Adress- und Portscanner) neuere und effizientere Methoden die Banner abzugreifen. Ryan Russel und Stace Stunningham reissen wiederum sehr oberflächlich im Kapitel 3.4.2 (Informationslecks, Seite 139/140) ihres Buches "Maximum Protection" (2001) die Problematik der freizügigen Banner an. [Nach oben] [Nach unten] Information für 217.162.230.227: ACL für TCP kann mit Packet-Trace erkannt werden Überblick: Anhand der Rückgabe von Paketen bei einem nmap-Portscan auf ein System kann versucht werden Rückschlüsse auf das Vorhandensein eines Firewall-Systems und dessen Regelwerk zu ziehen. Ein blockierter Port (firewalled) deutet bei nmap auf einer der folgenden drei Zustände hin: Es wurde kein SYN/ACK-Paket empfangen. Es wurde kein RST/ACK-Paket empfangen. Eine ICMP-Typ-3-Nachricht (Ziel nicht erreichbar) mit dem Code 13 (Communication Administratively Prohibited) nach RFC 1812 (Requirements for IP Version 4 Routers) wurde empfangen. Ansonsten lohnt sich für weitere Informationen und zusätzliche Firewall-Scanning-Techniken der Blick in die offizielle man-Page von nmap oder das Dokument "nmap - Network Mapper" von Marc Ruef. Gefahr: Ein Angreifer kann durch die akribische Auswertung des Portscans versuchen das Vorhandensein eines Firewall-Elements zu determinieren und das zum Einsatz kommende Regelwerk herauszufinden. Test: Folgend nun die Ausgabe eines zur ACL-Auswertung durchgeführten TCP-Portscans mit Packet-Traceing auf 217.162.230.227: (The 1021 ports scanned but not shown below are in state: filtered) Der Test wird sehr simpel mit dem bekannten Portscanner nmap für Linux durchgeführt. Die Kommandoeingabe hierzu lautet "nmap -sT -P0 -F zielsystem | grep filtered". Lösung: Netzwerk- und hostbasierende Intrusion Detection Systeme (IDS), wie zum Beispiel Snort oder ISS RealSecure, können Portscans entdecken und protokollieren. Für Linux gibts es den Daemon scanlogd, der Portscanns erkennen, protokollieren und zum Beispiel auf syslog ausgeben lassen kann. Auch für Windows sind vergleichbare Tools zu finden. Wollen Sie verhindern, dass ein Angreifer anhand der Admin-Prohibited-Filter-Technik die ACL eines Firewall-Elements herausfinden kann, so verhindern Sie die Herausgabe von ICMP-Typ-13-Paketen. Bei Cisco-Elementen kann dies durch "no ip unreachables" durchgesetzt werden. Siehe: In der zweiten Auflage des "Anti-Hacker-Buchs" (2001) von George Kurtz, Stuart McClure und Joel Scambray wird im Kapitel 11.2.7 (Firewall-Erkennung für Fortgeschrittene, Seiten 580 bis 583) sehr ausführlich die entsprechenden Techniken, Möglichkeiten und Gefahren abgehandelt. [Nach oben] [Nach unten] Information für 217.162.230.227: TCP-Portscan erfolgreich Überblick: Sowohl TCP als auch UDP verwenden Port-Adressen um die Daten an den betreffenden Dienst der Anwendungsschicht zu senden. Zu Beginn einer jeden TCP-Kommunikation wird der sogenannte 3-way-handshake durchgeführt: Der Client sendet ein Paket mit gesetzter SYN-Flagge, wartet eines mit SYN/ACK-Flagge ab um darauf hin ein letztes ACK-Paket zu retournieren. Ab dann steht die Verbindung und die effektiven Anwendungsdaten können ausgetauscht werden. [Client] [Server] | | |-----SYN---->| | | |<--SYN/ACK---| | | |-----ACK---->| Gefahr: Ein Angreifer kann die Prozedur des 3-way-handshakes missbrauchen um die ansprechbaren Dienste am Zielsystem ausfindig machen zu können. Weiss ein Angreifer um die offenen Ports eines Rechners bescheid, so kann er daraus versuchen das dahinterliegende Betriebssystem oder den angestrebten Nutzen abzuleiten. Test: Folgend nun die Ausgabe eines typischen TCP-Portscans auf 217.162.230.227: Starting nmap V. 2.53 by
fyodor@insecure.org (
www.insecure.org/nmap/ ) Interesting ports on dclient217-162-230-227.hispeed.ch (217.162.230.227): (The 1021 ports scanned but not shown below are in state: filtered) Port State Service 22/tcp open ssh 80/tcp closed http Nmap run completed -- 1 IP address (1 host up) scanned in 267 seconds Der Test wurde mit der Eingabe von "nmap -sT -P -I 217.162.230.227" durchgeführt. Die Chancen, dass dieser Test erfolgreich verläuft liegt bei nahezu 99 %. Sorgt ein Firewall-Element dafür, dass der Rechner keine korrekten Rückantworten geben kann, so kann der Test langwierig und verfälscht werden. Lösung: Netzwerk- und hostbasierende Intrusion Detection Systeme (IDS), wie zum Beispiel Snort oder ISS RealSecure, können Portscans entdecken und protokollieren. Natürlich gilt es unnötige Dienste auf dem System am besten zu deinstallieren bzw. deaktivieren, um eine möglichst geringe Angriffsfläche zu bieten. Zusätzlich empfiehlt sich das Nutzen eines Firewall-Elements, das unerlaubte Zugriffe - auch Portscans - frühzeitig erkennen, protokollieren und abwenden kann. Siehe: In der zweiten Auflage des "Anti-Hacker-Buchs" (2001) von George Kurtz, Stuart McClure und Joel Scambray werden im Kapitel 2.3 (Port-Scans, Seiten 73 bis 95) sehr ausführlich die entsprechenden Techniken, Möglichkeiten und Gefahren abgehandelt. Kapitel 2.3 (Portscans) des "Security-Guide" (Version 3.0) von Marc Ruef wird auf das besagte Thema eingegangen eingegangen. Eine, wie nicht anders zu erwarten, sehr saubere Analyse von verschiedenen Port-Scanning-Techniken erwartet einem im Buch "IDS: Intrusion Detection-Systeme" (2001) von Stephen Northcutt und Judy Novak. Im Kapitel 15 gehen Sie auf den Seiten 355 bis 360 auf die besagte Problematik ein. Wie immer sehr knapp, dafür leicht verständlich, widmet sich Othmar Kyas und Markus a Campo im Kapitel 6.1.1 (Adress- und Portscanner, Seiten 144 bis 148) ihres Buches "IT-Crackdown" (2001) dem entsprechenden Prozedere. Ryan Russel und Stace Stunningham widmen sich sehr zerstreut und oberflächlich in ihrem "Maximum Protection" (2001) den bliebten Portscans.
Zitieren
Lesezeichen