Besuchen Sie jetzt unseren Online Shop www.tos.mynetcologne.de ..::..::..::..::..Schauen Sie mal unsere Service Produkte und unsere Service Angebote an es LOHNT sich.... ..::..::..::..::..

Unix/ Linux - eine große Herausforderung

Ein Unix/ Linux- Netzwerk zu sichern, ist sogar für erfahrene Anwender eine sehr große Herausforderung. Seit es Windows 2000 gibt, sind immer weniger Anwender bereit, dies zu versuchen.

Sicherheit vom Start weg

Sicherheit beginnt bei der Installation, also werden wir auch mit dieser beginnen und uns dann weiter vorarbeiten. Dieser erste Abschnitt behandelt folgende Themen:

• Physikalische Sicherheit 
• Sicherheit an der Konsole 
• Installationsmedien 
• Passwortsicherheit 
• Patches

Physikalische Sicherheit

Ihr Unix-Rechner ist immer nur so sicher wie sein Standort. Deshalb sollten Sie ihn vor böswilligen Anwendern abschirmen. In RFC 1244 steht folgendes:

Eine grundlegende Tatsache bei der Computersicherheit ist, dass, wenn der Rechner selbst nicht physikalisch sicher ist, das ganze System nicht mehr als sicher angesehen werden kann. Ein Nutzer mit physikalischem Zugang zum Rechner kann ihn anhalten, ihn im privilegierten Modus wieder hochfahren, die Festplatte austauschen oder verändern, Trojanische Pferde einschleusen oder eine Vielzahl anderer unerwünschter (und schwer zu verhindernder) Aktionen durchführen. Kritische Datenübertragungsverbindungen, wichtige Server und andere wichtige Rechner müssen an physikalisch sicheren Standorten stehen.

Wenn Sie noch keine Richtlinien für physikalische Sicherheit haben, sollten Sie welche aufstellen. Lesen Sie außerdem einige der folgenden Veröffentlichungen:

• Site Security Handbook. Internet Draft, Juli 1997, und Nachfolger des RFC 1244. Dieses Dokument beinhaltet einige ausgezeichnete Hinweise zur physikalischen Sicherheit. http://www.cert.dfn.de/eng/resource/ietf/ssh/draft-05.txt
• Computer Room Physical Security Guide. Vom Department of Defense Health Affairs. http://www.ha.osd.mil/dmim/security/comprm.html
• Report on the Follow-Up Audit of Physical Security of the Local Area Network. Kommentar zu einem Bericht des Office of Inspector General über physikalische Computersicherheit. Enthält einige unentbehrliche Informationen. http://www.fcc.gov/Bureaus/Inspector_General/Reports/rep96-1.txt

Sicherheit an der Konsole

Die Konsolensicherheit ist ein weiteres wichtiges Thema. Zwei Dinge sind besonders bedenklich:

• Konsolen- und Einzelplatz-Passwörter 
• Das Root- Passwort

Wir wollen beide kurz besprechen.

Konsolenpasswörter

Konsolenpasswörter sind an Unix-Workstations üblich. Je nach Ihrer Architektur kann ein Eindringling diese Passwörter verwenden, um unterschiedliche Ziele zu erreichen.

Bei der X86-Architektur sollten Sie das BIOS- Passwort aktivieren. Wenn Sie dies nicht tun, können lokale Eindringlinge Denial-of-Service- Attacken ausüben oder sogar Daten zerstören. Viele BIOS-Systeme beinhalten heute Programme zur Formatierung oder Oberflächenanalyse von Festplatten, die alle Daten auf der Festplatte vernichten können. Außerdem bieten die meisten modernen BIOS-Systeme Zugriff auf serielle und parallele Schnittstellen oder andere Hardware, die zum Export oder Import von Informationen verwendet werden kann. Und wenn Sie SCSI-Geräte benutzen, werden Sie Eindringlinge daran hindern wollen, auf die SCSI- Utilities zuzugreifen. Viele dieser Utilities werden beim Booten oder beim Ansprechen des SCSI-Adapters geladen. Ein gutes Beispiel dafür sind die Adaptec- Produkte: Die SCSI-Adapter-Software ermöglicht es Eindringlingen, neue Festplatten hinzuzufügen, vorhandene zu formatieren und so weiter.

Unix-Workstations haben ähnliche Probleme. Sie sollten das PROM- Passwort (und Konsolenpasswort) sofort bei der Installation aktivieren. Dieses Passwort kann Eindringlingen je nach Architektur unterschiedliche Dinge ermöglichen. Viele Systeme unterstützen Einzelplatzmodi. Bestimmte DEC-Stationen (besonders 3100) ermöglichen Ihnen, Ihre Boot- Optionen zu bestimmen:

Wenn eine DEC-Workstation ausgeliefert wird, läuft das Konsolensystem zuerst im privilegierten Befehlsmodus. Wenn Sie keine Änderungen vornehmen, gibt es keine Einschränkungen für Konsolenbefehle. Jeder, der physikalisch auf die Konsole zugreifen kann, kann beliebige Konsolenbefehle ausführen, wobei das interaktive Booten am gefährlichsten ist.

Tipp:

Eindringlinge können das interaktive Booten nutzen, um privilegierten Zugang zu erhalten und Daten zu zerstören oder Ihr System herunterzufahren.

Tipp:

Root- Passwort

Direkt nach Abschluss der Installation sollten Sie das Root- Passwort setzen. Viele Distributionen, wie SunOS oder Solaris, fordern Sie dazu auf. Dies ist die letzte Option vor dem Reboot (SunOS) oder Hochfahren (Solaris). Einige Distributionen (z.B. Linux Slackware oder AIX) erzwingen jedoch keine Passwortangabe vor dem ersten Booten. Wenn Sie eines dieser Systeme verwenden, müssen Sie das Root- Passwort sofort beim ersten Einloggen setzen.

Die Installationsmedien

Gleich danach sollten Sie Ihre Installationsmedien sichern, da diese sonst dazu missbraucht werden könnten, in Ihr System einzudringen. Ein gutes Beispiel ist AT&T Unix, besonders SVR3 und V/386. Böswillige Anwender können in das System eindringen, indem sie mit einer Diskette booten und die »Magic Mode«- Option wählen, durch die sie an eine Shell gelangen.

Auch CD-ROM-Installationsmedien ermöglichen Eindringlingen den Zugang. Wenn Ihre Sun-Workstation zugänglich und das Installationsmedium verfügbar ist, kann jeder den Rechner anhalten, mit der Installations- CD booten und Ihre Festplatte überschreiben. (Dieser Angriff ist nicht auf SunOS oder Solaris beschränkt. Durch Ändern der SCSI-ID oder einfaches Abtrennen der Festplatte können Eindringlinge ein AIX- System zu einem Neustart von CD-ROM zwingen.) Sogar in Linux- Systeme kann auf diese Art eingebrochen werden; bewahren Sie Ihre Installationsmedien also unbedingt an einem sicheren Ort auf.

Default-Einstellungen

Als nächstes müssen Sie sich den betriebssystemspezifischen Voreinstellungen zuwenden. Die meisten Unix-Versionen haben ein oder mehrere voreingestellte Accounts oder Passwörter. (Einige haben sogar passwortfreie Accounts.) Bevor Sie mit dem nächsten Schritt fortfahren (Systemintegrität) müssen Sie diese Sicherheitslücken schließen.

IRIX ist ein gutes Beispiel dafür. Bestimmte IRIX-Versionen haben riesige Sicherheitslöcher in ihrer Default-Konfiguration. Für die folgenden Accounts ist kein Passwort zum Einloggen erforderlich:

• lp (line printer) 
• guest 
• 4Dgifts 
• demos 
• jack 
• jill 
• backdoor 
• tutor 
• tour

Andere Systeme haben ähnliche Probleme, wie z.B. Default- Accounts, deren Passwörter allgemein bekannt sind.

Tipp:

Sicherheit für die Passwörter

Sie werden an Ihrem Rechner wahrscheinlich mehr als einen Benutzer arbeiten lassen (wahrscheinlich Dutzende). Bevor Sie den Rechner für das Netzwerk freigeben, sollten Sie sich der Passwortrichtlinie zuwenden.

Jedes Passwortsystem hat irgendeine angeborene Schwäche. Das ist bedenklich, weil Passwörter das Herzstück des Sicherheitsschemas von Unix darstellen. Jede Gefährdung der Passwortsicherheit kann fatale Auswirkungen haben. Deshalb sollten Sie proaktive Passwort- Utilities, wirksame Verschlüsselungsmethoden (wann immer dies möglich ist) und Passwort- Shadowing installieren.

Hinweis:

Wenn Sie kein Shadowing verwenden, können lokale Benutzer sich den Inhalt von /etc/ passwd ansehen. Die Passwörter sind zwar verschlüsselt, aber einfach zu knacken, wenn Ihre Benutzer keine sicheren Passwörter verwenden.

Passwort- Shadowing

Wenn Ihre Distribution Shadowing nicht von Haus aus unterstützt, empfehle ich Ihnen das John-F.-Haugh-II-Shadow- Paket. Es ermöglicht nicht nur grundlegendes Passwort- Shadowing, sondern auch Passwörter mit 16 Zeichen Länge (gegenüber den herkömmlichen 8 Zeichen Länge). Außerdem bietet es noch die folgenden Möglichkeiten:

• Passwortalterung 
• Tools zur Beschränkung der Ports, von denen ein Root- Login möglich ist 
• Aufzeichnung fehlgeschlagener Login- Versuche 
• Eine Funktion zur Prüfung von Benutzer- Passwörtern und Einschätzung ihrer Sicherheit 
• Erzwingen von Passwort-Prompts, sogar bei Logins, die eigentlich kein Passwort erfordern

Tipp:

Es gibt mehrere speziell für Linux geschriebene Tools für das Passwort- Shadowing. Zwei davon sind:

• Shadow in a Box von Michael Quan. Shadow in a Box ist eine Sammlung von Utilities zur Verwaltung Ihrer Shadow-Passwörter. Das Paket enthält Tools für FTP, POP, sudo und xlock sowie eine kompakte und eine umfangreiche Crack-Bibliothek. Sie finden es hier: http://sunsite.unc.edu/pub/Linux/system/admin/shadow-ina-box-1.2.tgz
• The Linux Shadow Password Suite von Julianne F. Haugh. Dieses Paket enthält viele gute Tools zur Verwaltung Ihrer Shadow- und Nicht-Shadow-Passwörter. (Auch SunOS wird unterstützt). Das Paket erhalten Sie unter: http://sunsite.unc.edu/pub/Linux/system/admin/shadow-971215.tar.gz.

Wenn Sie mehr über Shadow- Passwörter erfahren wollen (und Unix- Passwortsicherheit im allgemeinen) empfehle ich Ihnen folgende Informationsquellen:

• The Linux Shadow Password HOWTO. Aktuelle Version April 1998. http://www.tscnet.com/sysop/mhjack/SHADOW-HOWTO/SHADOW-HOWTO.html.
• Foiling the Cracker: A Survey of, and Improvements to, Password Security. Daniel V. Klein. http://www.um.es/~humberto/art/password.ps. 
• OPUS: Preventing Weak Password Choices. Eugene Spafford. http://www.alw.nih.gov/Security/FIRST/papers/password/opus.ps 
• Unix Password Security - Ten Years Later. David C. Feldmeier und Philip R. Karn. http://www.alw.nih.gov/Security/FIRST/papers/password/pwtenyrs.ps 
• Unix Password Security. http://www.iaehv.nl/users/gigawalt/TXT/pwseceng.txt 
• Password Security: A Case History. R. Morris, K. Thompson http://www.alw.nih.gov/Security/FIRST/papers/password/pwstudy.ps

Sie sollten jedoch wissen, daß einige Paßwort-Shadowing- Systeme auch durch andere Programme angegriffen werden können. Es gibt dafür mehrere Exploits. Bevor Sie fortfahren, sollten Sie Ihr System mit Hilfe der in Tabelle 1.2 aufgeführten Exploits überprüfen.

Hinweis:

Die folgenden Man-Pages beinhalten Informationen zu Passwortsicherheit und Shadowing:

• shadow 
• passwd 
• pwconv und pwunconv 
• nispasswd 
• yppasswd 
• getpwnam 
• putspent

Proaktive Passwortprüfung

Als nächstes müssen Sie eine proaktive Passwortprüfung installieren. Diese dient zum Eliminieren schwacher Passwörter, bevor sie der passwd- Datei übergeben werden. Das funktioniert folgendermaßen: Wenn ein Benutzer sein Passwort eingibt, wird es mit einer Wortliste und einer Reihe von Regeln verglichen. Wenn das Passwort diese Prüfung nicht besteht und sich als schwaches Passwort herausstellt, wird der Benutzer aufgefordert, sich ein neues Passwort auszudenken.

Ist diese proaktive Passwortprüfung wirklich erforderlich? Ja. Anwender sind faul. Wenn sie aufgefordert werden, ein Passwort anzugeben, nehmen sie grundsätzlich eines, das leicht zu knacken ist, z.B. Namen von Kindern, Geburtsdaten oder Abteilungsnamen. Bei Systemen ohne proaktive Passwortprüfung bleiben diese schwachen Passwörter unentdeckt, bis der Systemadministrator »dazu kommt«, sie mit einem Tool zum Knacken von Passwörtern zu überprüfen. Bis das soweit ist, ist es oft schon zu spät.

Passwd+

• Zur proaktiven Passwortprüfung empfehle ich Ihnen passwd+ von Matt Bishop. Es bietet folgende Funktionen: 
• Umfassende Protokollierungsmöglichkeiten (einschließlich der Protokollierung jeder Sitzung, wie z.B. einer erfolgreichen oder fehlgeschlagenen Passwortänderung). 
• Festlegung der Anzahl signifikanter Zeichen in dem Passwort (d.h. wie viele beim Test verwendet werden sollen). 
• Außerdem ermöglicht passwd+ Ihnen die Festlegung der Fehlermitteilungen, die ausgegeben werden, wenn ein Benutzer ein schwaches Passwort vorschlägt. Sie sollten diese Funktion nutzen, um die Benutzer darüber aufzuklären, warum ihre Passwörter nicht akzeptabel sind.

Wegweiser:

Um mehr Informationen zu passwd+ (und der Theorie, die dahinter steckt) zu bekommen, sollten Sie sich A Proactive Password Checker, Dartmouth Technical Report PCS-TR90- 152, besorgen. Er ist nicht über das Internet verfügbar, aber Sie können per E-Mail einen Ausdruck anfordern: http://www.cs.dartmouth.edu/cgi-bin/mail_tr.pl?tr=TR90-152

anlpasswd

Ein weiteres gutes Programm zur proaktiven Passwortprüfung ist anlpasswd vom Argonne National Laboratory. anlpasswd (das teilweise in Perl geschrieben ist) verwendet die Wörterbuchdatei Ihrer Wahl, und Sie können eigene Regeln aufstellen. Einige der mitgelieferten Regeln sind:

• Zahlen mit Leerzeichen und Leerzeichen mit Zahlen 
• Groß- und Kleinschreibung mit Leerzeichen 
• Alles groß oder klein geschrieben 
• Alles Zahlen 
• Großbuchstaben und Zahlen als 1. Zeichen 
• Alle Kombinationen der obigen Dinge

Tipp:

Tipp:

npasswd

npasswd (von Clyde Hoover) ist mehr als ein einfaches Programm zur proaktiven Passwortprüfung. Die Dokumentation beschreibt es so:

npasswd ist ein Ersatz für den passwd(1)-Befehl für Unix und Unix-ähnliche Betriebssysteme. Es unterzieht Benutzer- Passwörter strengen Rateprüfungen, um die Gefahr zu verringern, dass Benutzer schwache Passwörter wählen. npasswd ist dafür geeignet, die Standardprogramme zur Passwortänderung passwd, chfn und chsh zu ersetzen.

npasswd ist eine umfassende Lösung und kann viel zu Ihrer Passwortsicherheit beitragen. Wenn Sie Solaris 2.5 verwenden, werden Sie allerdings Funktionseinbußen hinnehmen müssen. (Sun änderte das NIS-passwd-API beim Übergang zu NIS+. Deshalb unterstützen auch die neuesten Versionen von npasswd NIS+ nicht.)

Tipp:

Patches

Der nächste Schritt ist, alle aktuellen Patches für Ihr Betriebssystem zu installieren. Wenn Sie brandneue Installationsmedien haben, sind die aktuellen Patches wahrscheinlich schon enthalten. Wenn Ihre Installationsdateien aber älter als 90 Tage sind, müssen Sie sich aktuellere Informationen besorgen.

In Tabelle 1.3 sind einige Adressen aufgeführt, an denen Sie Patches für populäre Unix- Plattformen finden.

Überprüfung der Dienste!

Wir nehmen jetzt einmal an, dass Sie die Workstation gesichert haben. Das Shadowing ist aktiviert und nur starke Passwörter werden akzeptiert. Nun ist es Zeit, zu überlegen, wie Ihre Workstation mit der Welt außerhalb Ihres Netzes zurechtkommen wird.

Die r-Utilities

rlogin und rsh sind für Sicherheitslöcher bekannt. Einige Linux- Distributionen beherbergen z.B. ein kritisches rlogin- Sicherheitsloch, das es sowohl lokalen auch als entfernten Benutzern erlaubt, sich privilegierten Zugang zu verschaffen:

In dem rlogin- Programm von NetKitB-0.6 existiert eine Schwachstelle. Diese Schwachstelle betrifft mehrere verbreitete Linux- Distributionen, einschließlich Red Hat Linux 2.0, 2.1 und abgeleitete Systeme wie Caldera Network Desktop, Slackware 3.0 und andere. Die Schwachstelle ist nicht auf Linux oder andere freie Unix-Systeme beschränkt. Sowohl die Informationen über diese Schwachstelle als auch die Methoden für ihre Ausnutzung sind über das Internet verfügbar gemacht worden.

- Alan Cox, Marc Ewing (Red Hat), Ron Holt (Caldera, Inc.) und Adam J. Richter, Official Update of the Linux Security FAQ; Alexander O. Yuriev, Moderator, Linux Security und Linux Alert Mailing Lists. (CIS Laboratories, Temple University, Philadelphia, PA.)

Das Problem betrifft nicht nur Linux, sondern auch viele »echte« Unix-Distributionen haben ähnliche Bugs, darunter bestimmte Distributionen von AIX. Der folgende Hinweis betraf Zehntausende von AIX-Systemen:

IBM ist gerade eine AIX- Sicherheitslücke bekannt geworden, die es ermöglicht, sich entfernt in jedes System mit AIX Version 3 als Root ohne Passwort einzuloggen. IBM hofft, dass seine Bemühungen, schnell auf dieses Problem zu reagieren, den Kunden eine schnelle Behebung dieser Sicherheitslücke ohne größere Störungen ermöglichen wird.

Bei den betroffenen Versionen konnte jeder entfernte Benutzer diesen Befehl eingeben:

rlogin AIX.target.com -l -froot
 

und erhielt umgehend Root- Berechtigung auf dem Zielrechner. AIX ist nicht das einzige Unix, das Probleme mit den r-Utilities hatte. Ich empfehle Ihnen, sie ganz zu entfernen und durch Secure Shell (SSH) zu ersetzen.

SSH bietet wirksame Authentifizierungs- und Verschlüsselungsverfahren für Remote- Sitzungen. Es ist ein ausgezeichneter Ersatz für rlogin und sogar Telnet. Darüber hinaus verhindert SSH auch IP- und DNS-Spoofing- Angriffe.

Viele Administratoren schlagen vor, die Dateien /etc/host.equiv und .rhosts zu entfernen, wenn man keine r-Utilities anbietet. Beachten Sie jedoch, daß der SSH- Client die Authentifizierung über .rhosts und /etc/host.equiv unterstützt. Achten Sie also bei der Konfiguration des sshd darauf, daß Sie genau wissen, wozu diese beiden Dateien benutzt werden, wenn Sie sie verwenden. Bevor Sie SSH auf Ihrem System installieren, sollten Sie den entsprechenden RFC zu diesem Thema studieren. Es heißt »The SSH (Secure Shell) Remote Login Protocol«.

Tipp:

Die Quellen für SSH sind für die meisten Unix-Varianten und für Linux frei verfügbar. Für Microsoft-Betriebssysteme und für MacOS gibt es kostenpflichtige Anwendungen zu kaufen. Bei http://www.cs.hut.fi/ssh/ finden Sie weitere Informationen.

Finger

Der finger- Dienst kann beträchtliche Sicherheitsrisiken beherbergen und kann verwendet werden, um die Privatsphäre Ihrer Anwender zu verletzen. Ich rate eindeutig davon ab, finger- Dienste der Außenwelt anzubieten.

Wenn Sie dennoch der Meinung sind, dass Sie finger- Dienste anbieten müssen, empfehle ich Ihnen ein verbessertes finger- Paket, wie sfingerd von Laurent Demailly. Eine Haupteigenschaft von sfingerd ist, dass es Zugang zu .plan- Dateien über ein chrooted- Verzeichnis gewährt. sfingerd (dem fast immer der Quellcode beiliegt) ist erhältlich unter:

ftp://hplyot.obspm.fr:/net/sfingerd-1.8.tar.gz

In Tabelle 1.4 sind weitere alternative finger- Daemonen aufgeführt.

Tipp:

Telnet

Telnet ist an sich kein gefährlicher Dienst. Dennoch können sogar »sichere« Versionen von Telnet externen Benutzern Zugriff auf wertvolle Informationen gewähren.

Tipp:

Telnet hat noch ein paar weitere erwähnenswerte Sicherheitslöcher. Eines wurde von Sam Hartman vom Kerberos-Entwicklungsteam am MIT entdeckt (mit Bestätigung und Hilfe bei der Programmierung von John Hawkinson, ebenfalls MIT). Dieses Sicherheitsloch war ziemlich verborgen, aber es könnte einem entfernten Benutzer Root- Zugang verschaffen. Hartman beschreibt es in »Telnet Vulnerability: Shared Libraries« so:

Am Sonntag, dem 15. Oktober, entdeckte ich auf mehreren Plattformen einen Bug in einigen Versionen von telnetd, der es einem entfernten Benutzer ermöglicht, login dazu zu bringen, eine andere C-Bibliothek von einem beliebigen Ort des Dateisystems des Rechners zu laden, auf dem telnetd läuft. Bei Rechnern, die verteilte Dateisysteme wie AFS oder NFS mounten, die von der Öffentlichkeit schreibbare, anonyme FTP-Verzeichnisse haben, oder zu denen der Benutzer bereits einen Nicht-Root- Zugang hat, ist es möglich, Root- Zugriff zu erlangen.

Das von Hartman entdeckte Sicherheitsloch betraf folgende telnetd- Versionen:

• NetBSD 
• FreeBSD 
• SGI IRIX 
• DEC Unix 
• Linux

Tipp:

Wenn Sie nach einem Ersatz für Telnet suchen, haben Sie einige Auswahl. Secure Shell ist gut, aber nicht die einzige Möglichkeit. Hier sind zwei andere, sehr gute Alternativen:

• Telnet- Authentifizierung über Kerberos. Manche Telnet-Distributionen unterstützen auf Kerberos basierende Authentifizierung und Verschlüsselung. Einige davon waren im Oktober 1995 in der Entwicklung, als das Hartman-Sicherheitsloch entdeckt wurde. Eine Distribution der »Kerberos«- Version von 4.4BSD finden Sie unter: http://andrew2.andrew.cmu.edu/dist/telnet.html.
• Telnet- Proxy durch Firewall, wie die tn-qw-Applikation, die im TIS Firewall Toolkit (FWTK) enthalten ist. Solche Applikationen können entfernte Hosts explizit zulassen oder ablehnen. (Bei vielen kann man auch Wildcards verwenden, wodurch ganze Netzwerke an der Verbindung gehindert werden können.)

Tipp:

Tipp:

FTP Dienst/ Deamon

Es gibt einige Gründe, anonymes FTP zu ermöglichen. Obwohl FTP kein kritisches Sicherheitsrisiko darstellt, sollten Sie sich einiger Probleme bewußt sein. Dabei geht es hauptsächlich um die Interaktion von FTP mit anderen Programmen oder Servern:

Bei einigen Protokollen ist es von Natur aus schwierig, sie sicher zu filtern (z.B. RPC- basierte UDP- Dienste), wodurch das interne Netzwerk weiter geöffnet wird. Dienste, die auf demselben Rechner laufen, können auf katastrophale Weise interagieren. Wenn man z.B. erlaubt, dass anonymes FTP auf demselben Rechner läuft wie der Web-Server, kann ein Eindringling eine Datei im Anonymous-FTP- Bereich plazieren und den HTTP- Server dazu bringen, sie auszuführen.

Tipp:

Anonymes FTP mit einem schreibbaren Verzeichnis macht Sie außerdem zu einem beliebten Angriffspunkt für Bösewichte, die FTP-Bounce- Attacken ausüben.

Bei FTP-Bounce- Attacken wird ein FTP-Server verwendet, um Zugang zu einem anderen zu erlangen, der dem Cracker zuvor die Verbindung verweigert hat. Meistens ist der Zielrechner dabei so konfiguriert, dass er Verbindungsanforderungen von einer bestimmten IP- Adressmaske ablehnt. Der Rechner des Crackers hat aber eine IP- Adresse innerhalb dieser Maske, so dass er nicht auf die FTP-Verzeichnisse des Zielrechners zugreifen kann. Um dies zu umgehen, benutzt der Cracker einen anderen Rechner (den »Vermittler«), um auf den Zielrechner zuzugreifen. Dazu schreibt er eine Datei in das FTP-Verzeichnis des Vermittlers, die Befehle enthält, damit dieser eine Verbindung zum Zielrechner herstellt und Dateien von diesem lädt. Wenn der Vermittler die Verbindung eingeht, geschieht dies unter seiner eigenen Adresse (und nicht der des Crackers). Der Zielrechner erlaubt also die Verbindung und liefert die gewünschte Datei.

FTP-Bounce- Attacken sind kein Problem besonders hoher Priorität, da sie selten vorkommen und meistens keine Einbruchversuche beinhalten. Die meisten dieser Angriffe kommen von außerhalb der USA. Viele Produkte, die mit einer High-Level- Kryptographie versehen sind, dürfen nicht aus den USA ausgeführt werden. Deshalb werden Bounce- Attacken verwendet, um diese Einschränkungen von FTP-Sites in den USA zu umgehen.

Tipp:

Tipp:

FTP beherbergt noch weitere, subtilere Probleme. Z.B. ist in wu-ftpd 2.4.2-beta-13 die Default-umask 002, so daß Dateien von jedem geschrieben werden können. Das kann zu ernsten Sicherheitsgefährdungen führen. Noch schlimmer ist aber, daß dieses Sicherheitsloch auch dann noch bestehen bleibt, wenn Sie die umask manuell ändern. Nur eine Änderung in der Datei inetd.conf schafft Abhilfe. Weitere Informationen finden Sie unter: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/wuftpd_umask.txt.

17.12 FTP Allgemein

Bestimmte Versionen von FTP sind fehlerhaft oder können leicht falsch konfiguriert werden. Wenn Sie eine Version von wu_ftpd verwenden, die vor April 1993 herausgekommen ist (nicht gerade wahrscheinlich, aber möglich, wenn Sie eine ältere Ausrüstung gekauft haben), müssen Sie sie sofort updaten. Denn laut CERT-Advisory 93:06 (»Sicherheitslücke wuarchive ftpd«):

Das CERT Coordination Center hat Informationen über eine Sicherheitslücke in Versionen von wuarchive ftpd erhalten, die vor dem 8. April 1993 ausgeliefert wurden. Verwundbare Versionen von wuarchive ftpd waren unter ftp://wuarchive.wustl.edu/packages/wuarchive-ftp/und vielen anderen anonymen FTP-Sites zu bekommen... Jeder Benutzer (lokal oder entfernt) konnte Zugriff auf jeden Account einschließlich Root auf einem Host erlangen, auf dem diese Version von ftpd lief.

Soviel zu den älteren Versionen von wu_ftpd. Und nun zu den neueren: Am 4. Januar 1997 wurde ein Bug in Version 2.4 entdeckt (von Aleph1 und David Greenman). Das ist bedenklich, da Version 2.4 sehr verbreitet ist. Wenn Sie 2.4 momentan verwenden (und noch nichts von diesem Bug gehört haben), sollten Sie sich den Patch so bald wie möglich besorgen. Sie finden ihn unter: http://www.landfield.com/wu-ftpd/mail-archive/1996/Feb/0029.html

Zur Auseinandersetzung mit der allgemeinen Sicherheit von FTP ist es das beste, sich das FTP-Protokoll einmal genauer anzusehen. Die FTP-Technologie hat sich seit ihrer Einführung stark verändert. Die eigentliche FTP-Spezifikation wurde ursprünglich im RFC 959 »File Transfer Protocol (FTP)« aufgestellt, und das ist über zehn Jahre her. Seitdem ist viel getan worden, um die Sicherheit dieser kritischen Anwendung zu verbessern.

Das maßgebliche Dokument ist »FTP Security Extensions« von M. Horowitz (Cygnus Solutions) und S. J. Lunt (Bellcore). Dieser Internet-Draft wurde im November 1996 verfasst, und es heißt in der Zusammenfassung:

Dieses Dokument definiert Erweiterungen der FTP-Spezifikation RFC 959, »File Transfer Protocol (FTP)« vom Oktober 1985. Diese Erweiterungen sorgen für eine starke Authentisierung, Integrität und Vertraulichkeit des Kontroll- und Datenkanals.

Tipp:

Das Dokument beginnt mit dem allgemein mit FTP verbundenen Problem - nämlich dass die Passwörter in Klartext übermittelt werden. Es beschreibt einige Fortschritte bei der Protokollsicherheit und ist ein guter Ausgangspunkt, um etwas über Sicherheit bei FTP zu lernen.

Wenn Sie die folgenden Punkte beachten, können Sie Ihren FTP-Server besser absichern:

• Überprüfen Sie Ihren Server auf den SITE_EXEC- Bug. Bei frühen FTP-Versionen konnten Angreifer eine Shell erhalten, indem sie eine Telnet-Sitzung an Port 21 einleiteten. Um dies zu überprüfen, starten Sie eine Telnet-Sitzung an Port 21 und geben den Befehl SITE_EXEC ein. Wenn Sie eine Shell bekommen, gibt es ein Problem. Mehr Informationen dazu finden Sie im CERT-Advisory CA-95:16: »Wu-ftpd Misconfiguration Vulnerability«, 30. November 1995, http://bulsai.kaist.ac.kr/~ysyun/Mail-Archives/cert-advisory/95/0006.html 
• Das HOME- Verzeichnis Ihres FTP-Servers sollte nicht schreibbar sein. Die einfachste und zuverlässigste Methode, dies zu erreichen, ist ein korrektes Setzen der Berechtigungen (chmod 555 und Root als Eigentümer).
• Unterbinden Sie für alle System- IDs die Verbindung über FTP. Root, bin, uucp und nobody sollten sich nicht per FTP auf Ihren Rechner einlassen dürfen.

TFTP Dienst

Der beste Rat, den ich Ihnen zu TFTP geben kann, ist, es zu deaktivieren. TFTP ist ein selten genutztes Protokoll und birgt erhebliche Sicherheitsrisiken, selbst wenn Sie eine als sicher angesehene Version verwenden.

Tipp:

In Kapitel 10, »Scanner«, habe ich TFTP und einen Scanner behandelt, der speziell zum Aufspüren von TFTP- Sicherheitslöchern entwickelt wurde (CONNECT). Da das Wissen um die Schwachstellen von TFTP weit verbreitet ist, verwenden die meisten Systemadministratoren es erst gar nicht.

Tipp:

TFTPD zu deaktivieren ist einfach. Sie müssen es nur in inetd.conf auskommentieren, so dass es beim Booten nicht mehr geladen wird. TFTP wird hauptsächlich beim Booten von plattenlosen (diskless) Workstations verwendet, um dem bootenden Rechner Konfigurationsdaten oder auch auszuführende Programme zu übergeben. Auf jeden Fall sollten Sie die folgenden Hinweise beachten:

• Einige TFTP- Distributionen können in einem sogenannten sicheren Modus betrieben werden. Überprüfen Sie, ob das bei Ihrer Version der Fall ist. Wenn dieser Modus existiert, können Sie ihn in inetd.conf durch Angabe der Option -s aktivieren. Dadurch können nur Dateien übertragen werden, die in dem Verzeichnis /tftpboot oder darunter liegen. Andernfalls können unter Umständen beliebige Dateien übertragen werden. 
• Lassen Sie alle wichtigen Vorgänge genau protokollieren und überprüfen Sie die log-Dateien täglich. 
• Achten Sie bei der Konfiguration vom TFTPD in /etc/inetd.conf darauf, daß der Daemon unter der Berechtigung des Benutzers »nobody« gestartet wird.

Gopher Dienst

Gopher ist ein antiquiertes, aber schnelles und effizientes Protokoll. Wenn Sie es verwenden: Hut ab vor Ihnen! Ich bin ein großer Gopher-Fan. Gopher liefert mir Informationen sofort auf den Tisch, ohne die lästige Werbung, die einen im WWW überall nervt.

Gopher hatte traditionell keine großen Sicherheitsprobleme, aber einige Punkte sind dennoch erwähnenswert. Der Gopher-Server der University of Minnesota ist wahrscheinlich der populärste Gopher-Server, der je geschrieben wurde (erhältlich unter boombox.micro.umn.edu ). Ich schätze, dass er heute noch auf über der Hälfte aller Gopher-Server läuft. Von diesen sind ca. 10 Prozent für einen alten Bug anfällig.

Dieser Bug betrifft sowohl Gopher als auch Gopher+ in allen Versionen, die vor August 1993 erhältlich waren. Im CERT- Advisory CA-93:11, »UMN Unix Gopher und Gopher+ Sicherheitslücken«, heißt es:

Es ist bekannt, dass Eindringlinge diese Sicherheitslücken ausgenutzt haben, um an Passwortdateien zu gelangen... Jeder (entfernt oder lokal) kann uneingeschränkten Zugang zu dem Account erhalten, auf dem der öffentlich zugängliche Client läuft. Dadurch kann er alle Dateien lesen, die diesem Account zugänglich sind (darunter möglicherweise /etc/passwd oder andere sensible Dateien)... Bei bestimmten Konfigurationen kann jeder (entfernt oder lokal) Zugriff auf jeden Account erhalten, einschließlich Root, auf einem Host, der als Server konfiguriert ist, auf dem gopherd läuft.

Über dieses Sicherheitsloch wurde auch in einem Defense Data Network Bulletin (DDN Security Bulletin 9315, 9. August 1993) berichtet, das unter http://nic.mil/ftp/scc/sec- 9315.txt eingesehen werden kann.

Gopher kann auch als Proxy für eine FTP-Sitzung dienen, so dass Sie eine Bounce- Attacke mit Gopher als Startrampe durchführen können. Dies ist ein Problem, das die Firewall- Sicherheit betrifft. Wenn z.B. Ihr FTP-Server hinter der Firewall liegt, aber Ihr Gopher-Server nicht, hat das Sperren des Zugangs zu dem FTP-Server in diesem Fall keinen Zweck.

Schließlich ist noch anzumerken, dass Gopher in seinem Default-Zustand verglichen mit anderen Netzwerkdiensten sehr schwache Protokollierungsmöglichkeiten bietet.

NFS (Network File System)

NFS sorgt für einige Sicherheitsprobleme. Exportierte Dateisysteme können ein Risiko darstellen oder nicht, je nachdem, wie sie exportiert werden. Dabei spielen Berechtigungen eine große Rolle. Wenn Sie befürchten müssen, dass Ihre Anwender ihre eigenen .rhosts- Dateien erzeugen (was Sie ausdrücklich untersagen sollten), ist das Exportieren von HOME- Verzeichnissen keine gute Idee, da diese Verzeichnisse natürlich Lese-/Schreibberechtigungen enthalten.

Einige Tools können Ihnen helfen, den Prozess der Überprüfung (und Schließung) von NFS- Sicherheitslücken zu automatisieren. Eines davon ist NFSbug, geschrieben von Leendert van Doorn. NFSbug ist ein Scanner für allgemein bekannte NFS- Sicherheitslöcher. Bevor Sie mit Ihrem Sicherheits- Audit abschließen und Ihren Rechner für die Öffentlichkeit freigeben, empfehle ich Ihnen, Ihr System mit diesem Utility zu prüfen (bevor Cracker es tun). NFSbug finden Sie unter: ftp://ftp.cs.vu.nl/pub/leendert/nfsbug.shar

Tipp:

Tipp:

NFS ist eine vielgenutzte Eingangstür für Cracker. In einem Defense Data Network Advisory von 1995 heißt es:

ZUSAMMENFASSUNG: Anstieg der Berichte über Root- Verletzungen durch Eindringlinge, die Tools zur Ausnutzung verschiedener NFS- Sicherheitslücken verwendet haben... Mit Hilfe solcher Tools verschaffen Eindringlinge sich unautorisierten Zugang zu Netzwerkressourcen. Diese Tools und Informationen darüber sind in zahlreichen Internetforen verbreitet worden.

Tipp:

Ein weiteres Problem ist, dass Sie, selbst wenn Sie »verbesserte« oder »sichere« NFS verwenden (im wesentlichen NFS plus DES), immer noch nicht sicher sind. Der DES- Schlüssel wird von dem Benutzerpasswort abgeleitet, und dies ist ein offensichtliches Problem. Die Installation von Shadowing ist vielleicht ein Weg, einen Cracker daran zu hindern, an die passwd- Listen zu gelangen. Der einzige wirkliche Vorteil der um DES erweiterten Versionen besteht darin, dass die Routine die Uhrzeit aufzeichnet. Timestamp-Verfahren schließen die Möglichkeit aus, dass ein Cracker den Austausch abhören und später wiedergeben kann.

Tipp:

Ich empfehle Ihnen, die folgenden Links zur NFS- Sicherheit aufzusuchen. Jede Site bietet eine andere Sicht des Problems und mögliche Lösungen oder wichtige Informationen über NFS- und RPC- Aufrufe:

• The COAST Archive at Purdue, mit Tutorials zu Schwachstellen von NFS (und NIS), http://www.cs.purdue.edu/coast/satan-html/tutorials/vulnerability_tutorials.html 
• NFS Version 3 Protocol Specification, B. Callaghan, B. Pawlowski und P. Staubach, (Sun Microsystems), Juni 1995, http://sunsite.auc.dk/RFC/rfc/rfc1813.html. 
• NFS Security Administration and Information Clearinghouse, Vicki Brown und Dan Egnor, http://www.cco.caltech.edu/~refguide/sheets/nfs-security.html.

HTTP

HTTP hat vielfältige Sicherheitsprobleme.  Einige wichtige Punkte sollen jedoch auch hier angesprochen werden.

Zuerst einmal dürfen Sie httpd nie als Root laufen lassen. Wenn Sie es doch tun, werden Sie ein sehr unglücklicher Systemadministrator sein. Schwachstellen in CGI- Programmen ermöglichen entfernten Angreifern die Ausführung beliebigen Codes mit der UID des httpd- Servers. Wenn dieser Server als Root läuft, ist Ihr gesamtes System gefährdet.

Sie könnten in Erwägung ziehen, httpd als einen chrooted- Prozess laufen zu lassen. Viele Ratgeber sind der Meinung, dass dies eine größere Sicherheit bietet.

Tipp:

Es hängt viel davon ab, ob Sie Ihren Anwendern Zugriff auf den Web-Server und dessen Dienste (einschließlich CGI) gewähren oder nicht. Viele ISPs verweigern einen solchen Zugriff. Das typische Angebot ist 10 M Byte Speicherplatz mit FTP, aber ohne CGI. Die meisten ISPs stellen noch nicht einmal einen Shell-Zugang zur Verfügung. Ich persönlich würde damit nicht zurechtkommen.

Wenn Sie solche Dienste anbieten, sollten Sie Richtlinien aufstellen. Ich kenne z.B. einen ISP, der CGI nur erlaubt, wenn seine Entwickler den Code prüfen können, bevor er ans Netz geht. Diese Methode hat Vor- und Nachteile. Der Vorteil ist, dass Sie jede Zeile Code zu sehen bekommen, die auf Ihren Server kommt. Der Nachteil ist, dass Sie jede Zeile Code zu sehen bekommen, die auf Ihren Server kommt. Wer möchte schon all den Code nach Sicherheitslöchern überprüfen?

Die Lösung könnte sein, ein Programm wie CGIWRAP zu verwenden. CGIWRAP automatisiert den Prozess, indem es folgende Funktionen ausführt:

• Überprüfen von CGI auf potentielle Sicherheitslöcher 
• Wrapping und Protokollierung aller Script-Zugriffe

CGIWRAP wurde von Nathan Neulinger geschrieben und 1995 herausgegeben. Es ist an verschiedenen Stellen im Netz erhältlich. Ich habe gute Erfahrungen mit ftp://ftp.cc.umr.edu/pub/cgi/cgiwrap/ gemacht.

CGIWRAP funktioniert nachgewiesenermaßen auf den folgenden Plattformen:

• A/UX 
• HPUX 
• Solaris 
• Linux 
• OSF/1

Leider kann CGIWRAP nicht alle Sicherheitsprobleme von HTTP beheben. Sie werden im einzelnen in Kapitel 26 näher erläutert, aber ein paar Punkte möchte ich hier schon ansprechen. Sie sollten wenigstens diese grundlegenden Vorkehrungen treffen:

• Deaktivieren Sie die EXEC- Option. Damit hindern Sie Anwender daran, Befehle als Server auszuführen. 
• Deaktivieren Sie Server Side Includes (Dokumentelemente, die auf der <include>- Angabe beruhen, wie Zeit, Datum und letztes Änderungsdatum). 
• Setzen Sie die Option AllowOverride auf NONE. So verhindern Sie, dass Ihre lokalen Benutzer innerhalb ihrer eigenen Verzeichnisse eigene Optionen einstellen.

Beachten Sie auch NCSAs Warnung in bezug auf DNS-basierte Authentifizierung:

Die Zugriffskontrolle durch Hostnamen und die grundlegenden Einrichtungen zur Benutzer- Authentifizierung von HTTPd sind relativ sicher, aber nicht wirklich kugelsicher. Die Benutzer- Authentifizierung sendet Passwörter in Klartext über das Netz, so dass sie leicht gelesen werden können. Die DNS-basierte Zugriffskontrolle ist nur so sicher wie DNS selbst; das sollten Sie nicht vergessen, wenn Sie sie benutzen. Fazit: Wenn er absolut sicher nicht von externen Benutzern gesehen werden kann, sollten Sie HTTPd besser nicht zu seinem Schutz verwenden.

»NCSA Tutorial Pages: Making Your Setup More Secure«, http://hoohoo.ncsa.uiuc.edu/docs/tutorials/security.html

 

HTTP-Sicherheit im allgemeinen

Bei der Sicherheit von HTTP hat sich besonders in den letzten zwei Jahren viel getan. Die größte Verbesserung war die Entwicklung von sicheren Protokollen. Von diesen Protokollen ist das Secure Sockets Layer Protocol das vielversprechendste.

Das Secure Sockets Layer Protocol

Secure Sockets Layer (SSL) wurde von Netscape Communications entwickelt. Das System verwendet RSA- und DES- Authentifizierung und zusätzlich dazu noch eine Überprüfung der MD5-Integrität. Um mehr über SSL zu erfahren, sollten Sie sich die Homepage von SSL ansehen. Das Dokument mit Namen »The SSL Protocol« (Internet-Draft) wurde von Alan O. Freier und Philip Karlton (Netscape Communications) zusammen mit Paul C. Kocher verfasst. Sie finden es unter: http://home.netscape.com/eng/ssl3/ssl-toc.html

Wie sicheren Sie das Dateisystem?

Als nächstes sollten Sie, bevor Sie mit Ihrem Rechner ans Netz gehen (lokal oder weltweit), Ihr Dateisystem sichern. Sie werden diese Sicherheitskopie später verwenden, um die Datenintegrität zu prüfen, womit wir wieder bei TripWire wären.

TripWire

TripWire ist ein Tool, das Integritätsprüfungen von Dateisystemen mit Hilfe kryptographischer Prüfsummen vornimmt. Mit TripWire können Sie jede Manipulation aufspüren, die vorgenommen worden ist. Sie können TripWire auch verwenden, um Ihre Festplatten nach Dateien zu durchforsten, die dort nichts verloren haben. Am Ende dieses Kapitels finden Sie eine umfassende Liste von Exploits. Für jeden Exploit gebe ich eine URL an, unter der Sie seinen Quellcode finden. Wenn Sie die Exploits herunterladen und kompilieren - und dann MD5-Werte für jeden erzeugen - können Sie diese Werte in Ihre wöchentliche oder monatliche Festplattenanalyse miteinbeziehen.

Da ich TripWire in vorangegangenen Kapiteln bereits behandelt habe, möchte ich hier nicht näher darauf eingehen. Ich habe bereits darauf hingewiesen, wo Sie das Tool finden können. An dieser Stelle möchte ich Ihnen empfehlen, sich die folgenden Dokumente zu besorgen:

• »Writing, Supporting, and Evaluating TripWire: A Publicly Available Security Tool«, Kim und Spafford, http://www.raptor.com/lib/9419.ps 
• »The Design and Implementation of TripWire: A Filesystem Integrity Chekker«, Kim und Spafford, http://www.raptor.com/lib/9371.ps

X-Window

Das X-Window- System ist ein weiterer Punkt, der Sie eventuell betreffen könnte. Wenn Ihr Rechner ein Web-Server ist, besteht überhaupt kein Grund dafür, X-Window zu installieren. Wenn Sie X-Window jedoch einsetzen, gibt es einige wichtige Dinge zu beachten.

Die Hauptschwachstelle von X-Window - das xhost- Sicherheitsloch - lässt sich leicht beheben. Wenn ein X-Server keine Zugriffskontrolle aktiviert hat, kann jeder von überall her im Internet ein zusätzliches X-Window öffnen und beliebige Programme starten. Als generelle Lösung können Sie dieses Loch schließen, indem Sie den xhost- Eintrag von Xsession von xhost + in xhost - ändern.

Wenn Sie ein Unix-Neuling sind, denken Sie vielleicht, dass X nur eine weitere grafische Oberfläche ist, aber es steckt sehr viel mehr dahinter. G. Winfield Treese und Alec Wolman schrieben in »X Through the Firewall and Other Application Relays«:

Beim X-Window- System ermöglicht es das grundlegende Sicherheitsmodell den Benutzern, die Hosts selbst festzulegen, denen eine Verbindung zu dem X-Server gewährt wird. Das betrifft nur neue Verbindungen, nicht die bereits existierenden. Viele Benutzer deaktivieren die Zugriffskontrolle aus Bequemlichkeit ganz, sobald sie mehr als ein paar Hosts benutzen.

X-Window ist keine grafische Benutzeroberfläche, auch wenn es so aussehen mag. Verbindungen werden an den X-Server gesendet. Der X-Server kann jeden gültigen X-Client bedienen, egal, ob dieser sich auf demselben Rechner befindet oder Kilometer entfernt ist. John Fisher schreibt in seinem Artikel »Securing X Windows«:

X-Window ist auf seiner untersten Ebene eigentlich ein Kommunikationsprotokoll, das X-Protokoll. Dieses Protokoll wird innerhalb eines einzelnen Computers oder über ein Netzwerk von mehreren Computern benutzt. Es ist nicht an das Betriebssystem gebunden und daher auch für eine Vielzahl anderer Plattformen erhältlich. X- Window verwendet ein Client-Server-Modell der Netzwerkkommunikation. Dieses Modell ermöglicht es einem Benutzer, ein Programm an einem Ort laufen zu lassen, aber von einem anderen Ort aus zu steuern.

X-Window ist deshalb genau wie alle anderen Protokolle unter Unix. Es arbeitet nach dem Client-Server-Modell und stellt Zugang über das Internet und zu einer Vielzahl von Systemen und Architekturen zur Verfügung. Wenn eine gültige Verbindung gestartet wird, ist alles möglich (wie in der X11R5-Xserver-ManPage beschrieben):

Das X-Protokoll an sich weiß nichts von Berechtigungen für Fenster-Operationen oder irgendwelchen Beschränkungen dessen, was ein Client machen darf. Wenn ein Programm eine Verbindung zu einem Display herstellen kann, hat es freien Zugang zu dem Bildschirm.

Sobald eine Verbindung steht, kann der Angreifer Fenster zerstören, neue Fenster erzeugen, Tastatureingaben und Passwörter abhören und wirklich jede mögliche Aktivität in der X- Umgebung ausführen.

Die X-Authentifizierung basiert auf einem sogenannten Magic Cookie. Das ist ein 128-Bit- Wert, der durch eine Pseudo-Zufallsauswahl erzeugt wird. Er wird an die Clients verteilt und in der Datei .Xauthority gespeichert. Dieses Authentifizierungsschema kann theoretisch überwunden werden. Es wird aus folgendem Grund als schwach angesehen:

Obwohl der XDM-Authorization-1-Mechanismus ausreichenden Schutz vor Leuten bietet, die versuchen, sich Authentifizierungsdaten aus dem Netzwerk zu fischen, hat er ein großes Problem: Der ganze Sicherheitsmechanismus steht und fällt mit dem Schutz der Datei .Xauthority. Wenn Fremde sich Zugang zum Inhalt Ihrer .Xauthority -Datei verschaffen können, kennen sie den für die Verschlüsselung der Daten verwendeten Schlüssel, und mit der Sicherheit ist es vorbei.

Tipp:

Wenn Sie die Zugriffskontrolle aktivieren, besteht zwar wenig Gefahr, dass ein Eindringling an Ihre .Xauthority- Datei gelangen kann. Dennoch sollten Sie sich nicht auf die einfache Zugriffskontrolle verlassen. Man hat sich bemüht, die X-Sicherheit zu verbessern, und es gibt keinen Grund, warum Sie nicht von diesen Bemühungen profitieren sollten. Sie sollten schon deshalb zusätzliche Sicherheitsmaßnahmen ergreifen, weil sich in der Vergangenheit gezeigt hat, dass die grundlegenden X-Sicherheitsschemata fehlerhaft sind. So steht im CERT- Bulletin »X Authentication Vulnerability«:

Zwei weit verbreitete Authentifizierungsschemata für das X-Window- System haben Schwachstellen bei der Sample Implementation. Diese Schwächen könnten es unautorisierten Benutzern ermöglichen, sich mit X-Displays zu verbinden. Davon betroffen sind X11 Release 6 und ältere Releases der X11-Sample-Implementation. Es wurde berichtet, daß unter Ausnutzung zumindest einer dieser Schwächen in Systeme eingebrochen wurde, und dass in Cracker-Kreisen inzwischen Exploits verfügbar sind.

Außerdem automatisieren viele verfügbare Programme (wie xkey, xscan, xspy und watchwin) die Aufgabe entweder des Knackens des X-Servers oder des Ausnutzens des Servers, sobald er geknackt wurde.

Experten raten zur Verwendung einer Kerberos-basierten Xlib oder des in RFC 1413 definierten Authentifizierungsprotokolls. Ihre Wahl hängt natürlich von Ihrer speziellen Netzwerkkonfiguration ab. Hier sind einige grundlegende Tipps zur X-Sicherheit:

• Verwenden Sie wenigstens immer die Magic-Cookie- Authentifizierung, nicht die Host- basierte Authentifizierung mit xhost. 
• Sorgen Sie dafür, daß sich nirgendwo in Ihrem System xhost + befindet, sei es in den .xsession-Dateien oder gar in den Shell-Scripts zu X. 
• Einige Unix-Varianten, darunter Solaris, erzeugen unter /tmp Verzeichnisse für die Sokkets des X-Servers mit falschen Berechtigungen. Gegebenenfalls müssen Sie die Modes dieser Verzeichnisse nach jedem Boot des Systems anpassen mit: chmod 1777 /tmp /tmp/ .X11*.

Checklisten und Leitfäden

Bevor Sie mit der Planung Ihres Netzwerks beginnen, sollten Sie sich einige der im folgenden aufgeführten Dokumente besorgen. Sie sind eine gute Hilfe zum besseren Verständnis der Struktur eines Netzwerks, und Sie lernen, wie Sie gute Sicherheitsvorkehrungen implementieren können.

• Securing Internet Information Servers. CIAC-2308 R.2. Von den Mitgliedern des CIAC- Teams. Dezember 1994. PDF- Format. Ihr Rechner wird zum Internet Information Server. Dieses Dokument führt Sie Schritt für Schritt durch die Sicherung von anonymem FTP, Gopher und des Web. Es gewährt Ihnen Einblicke in häufige Konfigurationsprobleme und häufige Sicherheitslücken. http://ciac.llnl.gov/ciac/documents/CIAC-2308_Securing_Internet_Information_Servers.pdf 
• Securing X Windows. CIAC-2316 R.0. Von John Fisher, August 1995. Lawrence Livermore National Laboratory Computer Incident Advisory Capability CIAC Department of Energy UCRL-MA-121788. PDF-Format. Dieses Dokument wird Ihnen helfen, die grundlegenden Schwächen von X-Window zu verstehen und die Sicherheit auf Ihrem Server zu verbessern. http://ciac.llnl.gov/ciac/documents/CIAC-2316_Securing_X_Windows.pdf. 
• Electronic Resources for Security Related Information. CIAC-2307 R.1. Von Richard Feingold. Dezember 1994. Dieses Dokument versorgt Sie mit einer umfassenden Liste von Sicherheitsressourcen für Unix. Es wird Ihnen helfen, Ihr Problem einzugrenzen, und sagt Ihnen, wen Sie wo fragen sollten. http://ciac.llnl.gov/ciac/documents/CIAC-2307_Electronic_Resources_for_Security_Related_Information.pdf.
• The AUSCERT (Australian CERT) Unix Security Checklist. (Version 1.1.) Letzte Aktualisierung 19. Dezember 1995. Dieses Dokument ist wahrscheinlich die umfassendste Sammlung von Unix-Sicherheitsinformationen. Es leitet Sie Schritt für Schritt bei der Absicherung häufiger Löcher auf einer Vielzahl von Plattformen an. Eine ausgezeichnete Veröffentlichung. ftp://caliban.physics.utoronto.ca/pub/unix_security_checklist_1.1 
• Computer Security Policy: Setting the Stage for Success. National Institute of Standards and Technology. Januar 1994. CSL-Bulletin. Dieses Dokument hilft Ihnen bei der Aufstellung von Sicherheitsrichtlinien für Ihr Netzwerk. http://www.raptor.com/lib/csl94-01.txt

Exploits für Unix (allgemein)

Der nächste Abschnitt enthält eine umfangreiche Sammlung von Angriffen und Sicherheitslöchern bei Unix. Um den größten Nutzen aus dieser Liste zu ziehen, sollten Sie folgendermaßen vorgehen:

1. Laden Sie die Liste in eine Textdatei.

2. Extrahieren Sie die URLs.

3. Schreiben Sie ein Script, um die einzelnen Dateien zu bekommen.

4. Kompilieren Sie jede Datei und berechnen Sie ihren MD5-Wert.

5. Scannen Sie Ihr Netzwerk nach den resultierenden Signaturen ab.

Wenn unter Ihren Anwendern ein Cracker ist, werden Sie ihn möglicherweise finden.

abuse.txt

Zweck: Red Hat Linux hat ein Sicherheitsloch im Spiel Abuse. Diese Datei beschreibt, wie man dieses Loch ausnutzen kann.

URL: http://main.succeed.net/~kill9/hack/os/linux/linabuse.txt

aix_dtterm.c

Zweck: Öffnet eine Root-Shell durch Ausnutzung eines Puffer-Überlaufs in dtterm.

URL: http://esperosun.chungnam.ac.kr/~jmkim/hacking/1997/07&before/aix_dtterm.c

AIX_host.c

Zweck: Öffnet eine Root-Shell in AIX durch Ausnutzung eines Puffer-Überlaufs in gethostbyname.

URL: http://www.asmodeus.com/archive/Aix/AIX_HOST.C

AIX_mount.c

Zweck: Nutzt einen Puffer-Überlauf in mount bei AIX 4.x aus.

URL: http://samarac.hfactorx.org/Exploits/AIX_mount.c

aix_ping.c

Zweck: Erlaubt Root-Zugriff auf AIX durch Ausnutzung eines Puffer-Überlaufs in gethostbyname.

URL: http://www.society-of-shadows.com/security/aix_ping.c

aix_xlock.c

Zweck: Erlaubt Root-Zugriff auf AIX durch Ausnutzung eines Puffer-Überlaufs in xlock.

URL: http://www.society-of-shadows.com/security/aix_xlock.c

amod.tar.gz

Zweck: Ermöglicht Crackern, beliebigen Code in SunOS-Kernel zu laden.

URL: http://www.sabotage.org/rootshell/hacking/amod.tar.gz

arnudp.c

Zweck: UDP-Spoofing-Utility.

URL: http://www.asmodeus.com/archive/IP_toolz/ARNUDP.C

ascend.txt

Zweck: Attackiert Ascend-Router von einem Linux- Rechner aus.

URL: http://www2.fwi.com/~rook/exploits/ascend.txt

asppp.txt

Zweck: SolarisX86-Exploit, der zu für jeden schreibbaren .rhosts- Dateien führt.

URL: http://www.unitedcouncil.org/c/asppp.txt

autoreply.txt

Zweck: Modifizierte .rhosts- Dateien können zur Root- Berechtigung führen. (Die Ursache ist ein Sicherheitsloch in der elm-mail- Distribution.)

URL: http://samarac.hfactorx.org/Exploits/autoreply.txt

bdexp.c

Zweck: Nutzt einen Puffer-Überlauf in einem Spiel (bdash) unter Linux aus.

URL: http://oliver.efri.hr/~crv/security/bugs/Linux/bdash.html

bind.txt

Zweck: Anleitung für eine DoS- Attacke gegen Bind.

URL: http://www.asmodeus.com/archive/SunOS/BIND.TXT

block.c

Zweck: Denial-of-Service durch Aufhebung der Benutzer- ttys.

URL: http://www.plato-net.or.jp/usr/vladimir/ugtxt/unix/OddsEnds.txt

breaksk.txt

Zweck: Wordlist-Attacke gegen Netscape-Server.

URL: http://www.society-of-shadows.com/security/breaksk.txt

brute_web.c

Zweck: Dies ist eine Gewaltattacke auf Web-Server. Das Programm sendet in schneller Abfolge Benutzernamen und Paßwörter aus.

URL: http://www2.fwi.com/~rook/exploits/brute_web.c

cfexec.sh

Zweck: Attackiert GNU-cfingerd und führt beliebige Befehle aus.

URL: http://www2.fwi.com/~rook/exploits/cfexec.sh

cloak.c

Zweck: Cracker beseitigen ihre Spuren mit diesem Utility, indem sie ihre Aktivitäten aus den System-Logs entfernen.

URL: http://www2.fwi.com/~rook/exploits/cloak.c

color_xterm.c

Zweck: Mit diesem Programm erhält man Root- Zugang in Linux durch Ausnutzen eines Puffer-Überlaufs in dem Color-Xterm- Paket.

URL: http://ryanspc.com/exploits/color_xterm.c

convfontExploit.sh

Zweck: Erlaubt Root- Zugriff durch Ausnutzen der Prozeß- ID von convfont. (Funktioniert nur mit Linux.)

URL: http://www.space4less.com/usr/teknopia/security/convfontExploit.sh

cxterm.c

Zweck: Erlaubt Root- Zugriff durch Ausnutzen eines Puffer-Überlaufs in cxterm auf Linux- Systemen.

URL: http://ryanspc.com/exploits/cxterm.c

dec_osf1.sh

Zweck: Nutzt eine Schwachstelle in top unter DEC Unix aus. (Führt zu Root- Zugang.)

URL: http://www.asmodeus.com/archive/DEC/DEC_OSF1.SH

demonKit-1.0.tar.gz

Zweck: Trojanisches Pferd zum Eindringen in Linux-Systeme durch eine Hintertür.

URL: http://www.net-security.sk/unix/rootkit/demonKit-1.0.tar.gz

dgux_fingerd.txt

Zweck: Anleitung zum Angreifen von finger auf Digital Unix.

URL: http://www.unitedcouncil.org/c/dgux_fingerd.txt

dipExploit.c

Zweck: Dieser Code nutzt dip aus, ein Einwähl-Utility unter Linux.

URL: http://www2.fwi.com/~rook/exploits/dipExploit.c

doomsnd.txt

Zweck: Ergibt Root- Zugriff auf Linux durch Ausnutzen einer Lücke in Dooms sndserver- Paket.

URL: http://www.asmodeus.com/archive/Xnix/DOOMSND.TXT

dosemu.txt

Zweck: Auf Debian Linux kann das DOS-Emulationspaket verwendet werden, um Dateien zu lesen, die Root gehören.

URL: http://pcisys.net/~bpc/work/dosemu.txt

dumpExploit.txt

Zweck: Beschreibung eines Sicherheitslochs in Red Hat 2.1-4.1 /sbin/dump. (Es ist in suid- root installiert und ermöglicht lokalen Benutzern das Lesen aller Dateien.)

URL: http://www.unitedcouncil.org/c/dumpExploit.txt

eject.c

Zweck: Exploit für Puffer-Überlauf in dem Programm eject auf Solaris 2.4.

URL: http://www.asmodeus.com/archive/slowaris/EJECT.C

elm_exploit.c

Zweck: Nutzt einen Puffer-Überlauf in elm unter Linux aus.

URL: http://www.chaostic.com/filez/exploites/elm_exploit.c

eviltelnetd

Zweck: Trojanisches Pferd für den Telnet- Daemon, das eine Root-Shell ermöglicht.

URL: http://samarac.hfactorx.org/Exploits/telnetd-hacked.tgz

expect_bug.txt

Zweck: Erläutert eine Schwachstelle in Expect, einer beliebten Programmiersprache zur Automatisierung von Terminal-Sitzungen.

URL: http://www.society-of-shadows.com/security/expect_bug.txt

fdformat-ex.c

Zweck: Erlaubt Root- Zugriff auf Solaris 2.x durch Ausnutzen des Utilitys zur Disketten- Formatierung.

URL: http://www.asmodeus.com/archive/slowaris/FDFORMAT-EX.C

ffbconfig-ex.c

Zweck: Nutzt einen Puffer-Überlauf in dem FFB Graphics Accelerator aus und erzielt Root- Zugriff.

URL: http://www.asmodeus.com/archive/slowaris/FFBCONFIG-EX.C

finger_attack.txt

Zweck: Beschreibung einer Denial-of-Service-Attacke durch Bombardieren von fingerd.

URL: http://www.sabotage.org/rootshell/hacking/finger_attack.txt

FreeBSDmail.txt

Zweck: Exploit zum Angriff von sendmail auf Rechnern mit FreeBSD 2.1.x.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/FreeBSDmail.txt

FreeBSD-ppp.c

Zweck: Erlaubt Root- Zugriff auf FreeBSD durch Ausnutzen eines Puffer-Überlaufs in pppd.

URL: http://www.rasputin.net/~itamae/outernet/filez/FreeBSD-ppp.c

ftpBounceAttack

Zweck: Die beliebte FTP-Bounce- Attacke.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/ftpBounceAttack

ftp-scan.c

Zweck: Nutzt FTP als Startrampe zu Scan- Diensten, die hinter Firewalls liegen.

URL: http://www.society-of-shadows.com/security/ftp-scan.c

getethers1.6.tgz

Zweck: Scannt Netzwerke und erhält Hostnamen und Hardware-Adressen aller Hosts in einem LAN.

URL: http://www.rootshell.com/archive-ld8dkslxlxja/199707/getethers1.6.tar.gz

glimpse_http.txt

Zweck: Nutzt ein Sicherheitsloch im Suchtool Glimpse aus und führt auf dem Zielrechner beliebige Befehle aus.

URL: http://www.unitedcouncil.org/c/glimpse_http.txt

gpm-exploit.txt

Zweck: Nutzt ein Sicherheitsloch in Linux' Mausunterstützung aus, um Root- Rechte zu erlangen.

URL: http://www.asmodeus.com/archive/linux/GPM-EXPLOIT.TXT

h_rpcinfo.tar.gz

Zweck: Stiehlt Speicherauszüge von RPC- Diensten von einem entfernten Host.

URL: http://www.jammed.com/~jwa/Security/h_rpcinfo.tar.gz

hide.c

Zweck: Erlaubt unautorisiert Lese- und Schreibberechtigung für /etc/utmp.

URL: http://irdu.nus.sg/security/softwares/hide.c

hpjetadmin.txt

Zweck: Erläuterung eines Exploits in hpjetadmin, der zu Root- Berechtigung führt.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/hpjetadmin.txt

identd_attack.txt

Zweck: Denial-of-Service- Attacke durch Bombardieren von identd.

URL: http://www2.fwi.com/~rook/exploits/identd_attack.txt

ident-scan.c

Zweck: Erhält UID und Namen von Daemonen, die auf entfernten Hosts laufen.

URL: http://users.dhp.com/~fyodor/nmap/scanners/ident-scan.c

iebugs.tar.gz

Zweck: HTML-Distribution von sechs Internet-Explorer-Bugs.

URL: http://users.dhp.com/~fyodor/sploits/internet_explorer_bug_collection.html

imapd_exploit.c

Zweck: Nutzt ein Sicherheitsloch in Red Hat Linux aus, das es entfernten Angreifern ermöglicht, über imapd Root- Zugang zu erhalten.

URL: http://mayor.dia.fi.upm.es/~alopez/bugs/bugtraq2/0263.html

innd_exploit.c

Zweck: Erzielt eine Shell durch Ausnutzen eines Puffer-Überlaufs in innd auf bestimmten Linux- Systemen.

URL: http://www.unitedcouncil.org/c/innd_exploit.c

ipbomb.c

Zweck: Wirft einen Host aus dem Netz, indem es ihn mit einer Vielzahl von Paketen bombardiert (von denen einige sehr groß sind).

URL: http://www.truelink.net/user/mtoole/Linux/ipbomb.c

IPInvestigator.tgz

Zweck: Sniffer (neu).

URL: http://www2.fwi.com/~rook/exploits/IPInvestigator.tgz

ipspoof.c

Zweck: Spoofing- Code für Linux (wobei Linux die Kompilierungsplattform ist).

URL: http://www.rat.pp.se/hotel/panik/archive/ipspoof.c

IP-spoof.txt

Zweck: Ausgezeichneter kleiner Leitfaden zum Spoofing (Code und Beispiele für Linux.)

URL: http://www.unitedcouncil.org/c/IP-spoof.txt

irix-buffer.txt

Zweck: Eine Sammlung von Pufferüberlauf- Exploits für IRIX.

URL: http://sunshine.sunshine.ro/FUN/New/hacking/irix-buffer.txt

irix-csetup.txt

Zweck: Kurze Beschreibung des Exploits von csetup in IRIX.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/irix-csetup.txt

irix-dataman.txt

Zweck: Exploit für dataman auf IRIX- Systemen, der es Angreifern ermöglicht, unautorisiert Shell-Befehle auf dem Zielsystem auszuführen.

URL: http://www.asmodeus.com/archive/Irix/IRIX-DATAMAN.TXT

irix-df.c

Zweck: Exploit zum Öffnen einer Root-Shell auf IRIX mit Hilfe von df.

URL: http://samarac.hfactorx.org/Exploits/irix-df.c

irix-fsdump.txt

Zweck: Ergibt Root- Zugriff auf IRIX über einen Puffer-Überlauf in fsdump.

URL: http://www.sabotage.org/rootshell/hacking/irix-fsdump.txt

irix-iwsh.c

Zweck: Nutzt einen Puffer-Überlauf in iwsh (auf IRIX) aus, um Root- Rechte zu erhalten.

URL: http://www.unitedcouncil.org/c/irix-iwsh.c

irix-login.c

Zweck: Erlaubt Root- Zugriff durch Ausnutzung eines Puffer-Überlaufs in login auf IRIX.

URL: http://www.chaostic.com/filez/exploites/irix-login.c

irix-login.txt

Zweck: IRIX-login ermöglicht Ihnen die Erzeugung beliebiger Dateien durch Angabe von Pfaden, Verzeichnisnamen und Dateinamen anstelle von Login- Namen. Dieser Text erläutert, wie man dieses Sicherheitsloch ausnutzen kann.

URL: http://www.chaostic.com/filez/exploites/irix-login.txt

irixmail.sh

Zweck: Erlaubt Root- Zugriff durch Ausnutzen eines Sicherheitslochs in mail auf IRIX.

URL: http://www.asmodeus.com/archive/Irix/IRIXMAIL.SH

irix-xhost.txt

Zweck: Bei frisch installierten IRIX- Versionen kann jeder auf den X-Server zugreifen. Dieser Text beschreibt dieses Problem.

URL: http://www.unitedcouncil.org/c/irix-xhost.txt

irix-xlock.c

Zweck: Erlaubt Root- Zugriff durch Ausnutzen eines Puffer-Überlaufs in xlock unter IRIX.

URL: http://www.unitedcouncil.org/c/irix-xlock.c

irix-xterm.c

Zweck: Erlaubt Root- Zugriff durch Ausnutzen eines Puffer-Überlaufs in xterm unter IRIX.

URL: http://www.sabotage.org/rootshell/hacking/irix-xterm.c

jakal.c

Zweck: Scannt hinter Firewalls durch Aussenden halboffener Verbindungsanforderungen.

URL: http://pages.ripco.com:8080/~flyght/old/jakal.zip

jizz.c

Zweck: DNS- Spoofing- Utility (automatisiert Cache- Spoofing).

URL: http://dewmed.ml.org/online/jizz.c

jolt.c

Zweck: Wirft Windows-95-Rechner durch Aussenden sehr großer, fragmentierter Pakete aus dem Netz. Führt manchmal auch zum Reboot oder schlichten stehenbleiben des Windows- 95-Rechners.

URL: http://www.tomco.net/~nomad/files/mine/jolt.c

kcms.txt

Zweck: Ergibt durch einen Exploit Root- Berechtigung auf Solaris.

URL: http://www.sabotage.org/rootshell/hacking/ksolaris.txt

kill_inetd.c

Zweck: Denial-of-Service- Attacke durch Bombardieren von inet.d (für Linux geschrieben).

URL: http://www2.fwi.com/~rook/exploits/kill_inetd.c

kmemthief.c

Zweck: Exploit zum Erlangen von Root- Rechten auf Systemen, wo kmem für die ganze Welt lesbar ist.

URL: http://www2.fwi.com/~rook/exploits/kmemthief.c

ld.so.c

Zweck: Durch Ausführen einer dynamisch gelinkten setuid-Binary kann ein Benutzer einen Fehler des Laufzeit-Linkers (ld.so) erzwingen und schließlich beliebige Root- Befehle ausführen. (ELF ld-linux.so ist ebenfalls verwundbar.)

URL: http://smash.gatech.edu/archives/ale/9707/0138.html

lemon25.c

Zweck: Erlaubt Root-Zugriff auf Solaris durch Ausnutzen eines Puffer-Überlaufs in passwd.

URL: http://www.geek-girl.com/bugtraq/1997_1/0211.html

lilo-exploit.txt

Zweck: Erlaubt Root- Zugriff auf Linux durch Ausnutzen eines Sicherheitslochs im Laufzeit-Linker. (Erfordert eine geknackte libc.so.5, verfügbar unter http://www.rootshell.com// .)

URL: http://www.asmodeus.com/archive/linux/LILO-EXPLOIT.TXT

lin_probe.c

Zweck: Erlaubt Root- Zugriff durch Ausnutzen eines Puffer-Überlaufs in SuperProbe unter Linux.

URL: http://www.unitedcouncil.org/c/lin_probe.c

lin-pkgtool.txt

Zweck: Das Linux-Software- Installationstool pkgtool schreibt seine Log-Dateien mit den Rechten 666, so daß lokale Benutzer Schreibzugriff haben. Das kann es Angreifern ermöglichen, eine neue .rhosts- Datei zu schreiben (und schließlich Root-Rechte zu erlangen.)

URL: http://www.society-of-shadows.com/security/lin-pkgtool.txt

linux_httpd.c

Zweck: NCSA auf Linux- Systemen hat einen Bug. Entfernte Angreifer können eine Remote-Shell erlangen, indem sie dieses Utility verwenden. (Das ist ein ziemlich schwerwiegender Fehler.)

URL: http://www2.fwi.com/~rook/exploits/linux_httpd.c

linux_lpr.c

Zweck: Erlaubt Root- Zugriff über lpr, das einen Puffer-Überlauf hat.

URL: http://www.unitedcouncil.org/c/linux_lpr.c

linux_rcp.txt

Zweck: Der Benutzer nobody kann Root- Privilegien erhalten. (Passen Sie auf Ihren HTTP- Server auf.)

URL: http://www.sabotage.org/rootshell/hacking/linux_rcp.txt

locktcp.c

Zweck: Killt entfernte Solaris-X86-2.5x-Hosts.

URL: http://www.geek-girl.com/bugtraq/1996_4/0338.html

logarp.tar.gz

Zweck: Findet Rechner anhand der Hardware-Adresse der Netzkarte, die eine falsche IP- Adresse haben.

URL: http://www.jammed.com/~jwa/Security/logarp.tar.gz

lquerylv.c

Zweck: Öffnet eine Root-Shell durch Überschreiben eines Puffers in /usr/sbin/lquerylv (nur für AIX).

URL: http://samarac.hfactorx.org/Exploits/lquerylv.c

lquerypv.txt

Zweck: Lokale Benutzer können alle Dateien (einschließlich der Passwort- Dateien) lesen, indem sie lquerypv auf AIX verwenden. Folgender Text zeigt wie:

URL: http://samarac.hfactorx.org/Exploits/lquerypv.txt

minicom.c

Zweck: Nutzt einen Puffer-Überlauf im beliebten Linux-Terminalprogramm Minicom aus.

URL: http://linuxwww.db.erau.edu/mail_archives/server-linux/Sep_97/0451.html

mod_ldt.c

Zweck: Speicher-Exploit für Linux. Diese Attacke erzielt Root-Rechte.

URL: http://www.society-of-shadows.com/security/mod_ldt.c

mount-ex.c

Zweck: Linux' mount hat einen Puffer-Überlauf: Dieser Code automatisiert den Exploit.

URL: http://www.asmodeus.com/archive/linux/MOUNT-EX.C

nfsbug.c

Zweck: Nutzt einen Bug in unfsd 2.0 und älteren Versionen. (Errät ein Datei-Handle.)

URL: http://www.klaphek.nl/files/nfsbug_hpux.patch

octopus.c

Zweck: Killt einen entfernten Host durch Aussenden Tausender Verbindungsanforderungen (für Linux).

URL: http://www.tomco.net/~nomad/files/dos/octopus.c

oracle.txt

Zweck: Denial-of-Service- Attacke gegen Oracle-Web-Server.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/oracle.txt

pepsi.c

Zweck: Tool für UDP- Flooding und Denial-of-Service- Attacken (Linux als Kompilierungsplattform).

URL: http://www.society-of-shadows.com/security/pepsi.c

perl-ex.sh

Zweck: Root-Exploit für SUIPERL.

URL: http://www.asmodeus.com/archive/Xnix/PINE_EXPLOIT.SH

phf.c

Zweck: Scannt nach Hosts, die durch das PHF- Sicherheitsloch verwundbar sind.

URL: http://www.asmodeus.com/archive/web_java/PHF.C

phobia.tgz

Zweck: Noch ein Scanner. Sucht nach einer Vielzahl von Sicherheitslöchern.

URL: http://www.sabotage.org/rootshell/hacking/phobia.tgz

pine_exploit.sh

Zweck: Nutzt eine Schwachstelle im Mail-Client pine aus. (Erzeugt falsche .rhosts- Dateien.)

URL: http://www.unitedcouncil.org/c/pine_exploit.sh

pingexploit.c

Zweck: Sendet riesige ping- Pakete von einem Unix-Rechner aus. (DoS-Tool.)

URL: http://pxpx.com/underground/dwm/windoze/pingexploit.c

pingflood.c

Zweck: Das beliebte DoS-Tool überschwemmt einen Host mit ping- Paketen. (Nur fünf Zeilen Code.)

URL: http://samarac.hfactorx.org/Exploits/pingflood.c

pmcrash.c

Zweck: Wirft einen Livingston-Portmaster- Router aus dem Netz. (Pufferüberlauf-Programm.)

URL: http://www.sec.de/sven/pmcrash.c

pop3.c

Zweck: Gewaltattacke gegen POP3-Server.

URL: http://www.asmodeus.com/archive/Xnix/POP3.C

portscan.c

Zweck: Noch ein Port-Scanner. Identifiziert auf einem entfernten Host laufende Dienste. Klein, leicht, schnell.

URL: http://www.asmodeus.com/archive/IP_toolz/PORTSCAN.C

psrace.c

Zweck: Nutzt eine Race-Condition in Solaris aus und erzielt Root- Rechte.

URL: ftp://ftp.enslaver.com/pub/exploits/solaris/sun-psrace.c.asc

puke.c

Zweck: Spoofing eines ICMP Destination/Port Unreachable, wodurch eine bestehende IP- Verbindung unterbrochen wird (Denial-of-Service).

URL: http://www.mesopust.com/jogurt/puke.c

qmail_exploit.c

Zweck: Killt ein Qmail-System durch Bombardieren.

URL: http://www2.fwi.com/~rook/exploits/qmail_exploit.c

rdist-ex.c

Zweck: Erzielt eine Root-Shell unter FreeBSD.

URL: http://www.society-of-shadows.com/security/rdist-ex.c

reflscan.c

Zweck: Scannen Sie mit diesem Utility hinter Firewalls; es öffnet nur halboffene Verbindungen und verhindert dadurch eine Protokollierung, wenn SYN-Pakete nicht explizit durch einen Daemon geloggt werden.

URL: http://lhq.com/~tont0/reflscan.c

resolv+.exp

Zweck: Liest die Shadow- Passwortdatei.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/resolv+.exp

rexecscan.txt

Zweck: Umgekehrter Scan, bei dem ein Server eine rsh des Clients benutzend gescannt wird. Interessantes Tool, das die normalen Authentifizierungsprozeduren in rsh und rshd umgeht. Gute Dokumentation.

URL: http://www2.fwi.com/~rook/exploits/rexecscan.txt

rlogin_exploit.c

Zweck: Öffnet eine Root-Shell auf Solaris 2.5.x durch Puffer-Überlauf von gethostbyname.

URL: http://www.netcraft.com/security/lists/gethostbyname.txt

rpc_chk.sh

Zweck: Scanner-Shellscript, das Listen vielversprechender Hosts durch Abfrage von Name- Servern erzeugt.

URL: http://irdu.nus.sg/security/softwares/rpc_chk.sh

rsucker.pl

Zweck: Stiehlt Benutzernamen von r-Clients.

URL: http://www.unitedcouncil.org/c/rsucker.pl

rxvtExploit.txt

Zweck: Erzielt eine Root-Shell durch Ausnutzen eines falschen popen()- Aufrufs in RXVT.

URL: http://www.unitedcouncil.org/c/rxvtExploit.txt

screen.txt

Zweck: Screen auf BSDI hat eine Sicherheitslücke, die es Benutzern ermöglicht, Passwortdateien zu lesen.

URL: http://www.sabotage.org/rootshell/hacking/screen.txt

sdtcm_convert.txt

Zweck: Tutorial zum Erlangen von Root- Rechten durch Ausnutzen von sdtcm_convert auf Solaris.

URL: http://www.asmodeus.com/archive/slowaris/SDTCM_CONVERT.TXT

secure_shell.txt

Zweck: Normale Benutzer können sich mit privilegierten Ports verbinden und diese umleiten.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/secure_shell.txt

sendmail-ex.sh

Zweck: Erlaubt Root- Zugriff auf Linux über sendmail 8.7-8.8.x.

URL: http://ryanspc.com/sendmail/sendmail-ex.sh

seq_number.c

Zweck: Errät TCP- Sequenznummern.

URL: http://irdu.nus.sg/security/softwares/seq_number.c

sgi_html.txt

Zweck: Angreifer können Remote- Code auf SGI -Zielsystemen ausführen.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/sgi_html.txt

sgi_systour.txt

Zweck: Erlaubt Root- Zugriff durch Ausnutzen eines Sicherheitslochs in der Standardinstallation des systour- Pakets auf IRIX 5.3 und 6.2.

URL: http://esperosun.chungnam.ac.kr/~jmkim/hacking/1997/07&before/sgi_systour.txt

slammer

Zweck: Verwendet yp-Daemonen, um Befehle auf entfernten Hosts auszuführen.

URL: http://www.sabotage.org/rootshell/hacking/slammer.tar.gz

sol_mailx.txt

Zweck: Exploit für ein Sicherheitsloch in mailx auf Solaris.

URL: http://www.asmodeus.com/archive/slowaris/SOL_MAILX.TXT

sol2.5_nis.txt

Zweck: /usr/lib/nis/nispopulate schreibt Dateien mit Mode 777. Damit könnte ein Benutzer auf alle Dateien schreiben.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/sol2.5_nis.txt

SolAdmtool.txt

Zweck: Exploit zur Verwendung von Admintool (nur Solaris), um unautorisiert .rhosts- Dateien zu schreiben.

URL: http://www.sabotage.org/rootshell/hacking/SolAdmtool.txt

solaris_lp.sh

Zweck: Exploit, der lp verwendet, um Root- Rechte auf Solaris zu erzielen.

URL: http://samarac.hfactorx.org/Exploits/solaris_lp.sh

solaris_ping.txt

Zweck: Killt ein Solaris-2.x-System.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/solaris_ping.txt

solaris_ps.txt

Zweck: Erlaubt Root- Zugriff durch Ausnutzen einer Sicherheitslücke in ps.

URL: http://www.sabotage.org/rootshell/hacking/solaris_ps.txt

solaris_telnet.c

Zweck: Killt ein entferntes Solaris-System.

URL: http://www.unitedcouncil.org/c/solaris_telnet.c

sol-license.txt

Zweck: Der Solaris License Manager hat einen Bug, der zu Root- Rechten führt. Der Text in dieser Datei erklärt, wie das geht.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/sol-license.txt

sperl.tgz

Zweck: Nutzt einen Puffer-Überlauf in sperl aus. (Das führt zu Root- Zugriff.)

URL: http://www2.fwi.com/~rook/exploits/sperl.tgz

splitvt.c

Zweck: Puffer-Überlauf in usr/bin/splitvt auf Linux führt zu Root- Berechtigung.

URL: ftp://ftp.enslaver.com/pub/exploits/linux/linux-splitvt.c.asc

startmidi.txt

Zweck: Startmidi auf IRIX ist suid-root installiert.

URL: http://www.sabotage.org/rootshell/hacking/startmidi.txt

sunos-ovf.tar.gz

Zweck: Testet SunOS-4.1.x-Binaries auf Puffer-Überläufe.

URL: http://users.dhp.com/~fyodor/sploits/sunos.xterm.resource_manager.overflow.html

sushiPing.c

Zweck: Erlaubt Root- Zugriff auf SunOS 4.1.x

URL: http://www.unitedcouncil.org/c/sushiPing.c

synk4.c

Zweck: SYN-Flooding- Programm mit per Zufallsgenerator erzeugten IP- Absenderadressen.

URL: http://www.rat.pp.se/hotel/panik/archive/synk4.c

SYNpacket.tgz

Zweck: Denial-of-Service-Tool.

URL: http://www2.fwi.com/~rook/exploits/SYNpacket.tgz

syslogFogger.c

Zweck: Gibt Angreifern Zugriff auf Log-Dateien.

URL: http://samarac.hfactorx.org/Exploits/syslogFogger.c

talkd.txt

Zweck: Ermöglicht Root- Zugriff durch einen Puffer-Überlauf in talkd.

URL: http://www.asmodeus.com/archive/IP_toolz/TALKD.TXT

tcpprobe.c

Zweck: Port-Scanner; findet aktivierte Ports auf dem Zielsystem.

URL: http://www.zerawarez.com/main/files/csource/tcpprobe.c

telnetd_ex.tar.gz

Zweck: Umgebungsvariablen können über eine Telnet-Sitzung übermittelt werden. Die folgende Datei enthält Exploit- Code für diese Attacke (SunOS und Linux).

URL: http://users.dhp.com/~fyodor/sploits/telnetd.LD_PRELOAD.enviropassing.html

tlnthide.c

Zweck: Verbirgt Telnet-Sitzungen, so dass der Angreifer schwerer aufzuspüren und zu verfolgen ist.

URL: http://esperosun.chungnam.ac.kr/~jmkim/hacking/1997/07&before/tlnthide.c

ttysurf.c

Zweck: Spioniert Login- Namen und Passwörter von tty- Sitzungen aus.

URL: http://www.deter.com/unix/software/ttysurf.c

udpscan.c

Zweck: Scannt Zielsysteme nach offenen UDP-Ports ab.

URL: http://kropf.raex.com/warez/proggies/Unix/udpscan.c

utclean.c

Zweck: Verwischt die Spuren eines Crackers durch Löschen seiner Anwesenheit aus den Log-Dateien.

URL: http://www.kki.net.pl/shmasta/clean/utclean.c

vixie.c

Zweck: Überschreibt einen Puffer in crontab auf Linux- Systemen (führt zu Root- Zugriff).

URL: http://www.space4less.com/usr/teknopia/security/vixie.c

web_sniff.c

Zweck: Fängt Benutzernamen und Passwörter ab, die über die Basis-HTTP- Authentifizierung gesendet werden (mit htpasswd- Passwortschutz).

URL: http://www.unitedcouncil.org/c/web_sniff.c

wipehd.asm

Zweck: Entfernt die ersten 10 Sektoren einer Festplatte.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/wipehd.asm

wuftpd_umask.txt

Zweck: Die Voreinstellung von umask für wu-ftpd 2.4.2-beta-13 ist 002, wodurch Dateien für jeden schreibbar sind.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/wuftpd_umask.txt

Xfree86 Exploit

Zweck: 3.1.2-Server werden suid root installiert. Dieses Dokument beschreibt, wie man das ausnutzen kann.

URL: http://www.madness.org/hack/hacking/xfree86-ex.txt

xkey.c

Zweck: Ausspionieren von X-Sitzungen.

URL: http://www.paranoia.com/~ice9/xkey.html

xsnoop.c

Zweck: Ausspionieren von X-Sitzungen (ähnlich wie XKEY).

URL: http://www.society-of-shadows.com/security/xsnoop.c

ypsnarf.c

Zweck: Automatisiert die Ausnutzung von Sicherheitslücken in yp und NIS (yellow pages).

URL: http://www.plato-net.or.jp/usr/vladimir/ugtxt/unix/ypsnarf.c

Infoquellen

Im folgenden sind einige Publikationen und Webseiten aufgeführt, die wertvolle Informationen zur Unix-Sicherheit enthalten.

Online-Publikationen

COAST Watch Newsletter. Veraltete, aber dennoch interessante Publikation, die sich auf das Thema Internet-Sicherheit konzentriert. http://www.cs.purdue.edu/coast/coast-news.html

Journal of Internet Security. Zweimonatlich erscheinendes Elektronik-Magazin und Mailing-Liste. Gute Quelle für Informationen von EDI-Sicherheit bis zu neuen Zertifizierungs-/ Audit-Diensten. http://www.csci.ca/

SC Magazine. Monatlich erscheinende Zeitschrift, die sich mit Produkten und Techniken zur Computersicherheit befaßt. http://www.infosecnews.com/

Seven Locks Software's SecurityDigest. Ausführlicher Ratgeber zu verschiedenen Sicherheitsproblemen von Seven Locks. http://www.sevenlocks.com/SecurityDigest.htm

SunWorld Online. Internet- und Unix-Sicherheit von den Leuten bei Sun. http://www.usec.sun.com/sunworldonline/

Zusammenfassung

Dieses Kapitel kratzt nur an der Oberfläche der Unix-Sicherheit. Wenn ich ein Buch zu diesem Thema empfehlen sollte, wäre es Practical Unix and Internet Security von Simson Garfinkel und Gene Spafford.

[ Home ] [ Nach oben ]

Senden Sie E-Mail mit Fragen oder Kommentaren zu dieser Website an: tos.computer@gmx.de 
Copyright © 2003 TOS Computer Systeme
Stand: 14. November 2004