Unsicherheit in lokalen Netzen

tausch der Programmdaten des Betriebssystems in erster Linie uber das Internet stattfand. Man kann insofern nicht von einem professionellen SoftwareEngineering wie bei einem kommerziellen Produkt sprechen. Trotzdem liegt nach einigen Jahren eine sehr stabile Betriebssystemversion vor1, die standig weiterentwickelt wird2 . In jedem Falle ist ein in dieser Weise entstandenes Produkt aus Sicht der Datensicherheit als skeptisch zu werten und es stellt sich die Frage, da bei einem Nachweis von Unsicherheit zu beachten ist, ob die Quelle im unsicheren Betriebssystem oder im netztechnischen Umfeld zu lokalisieren ist. Bewut wurde daher nicht die aktuellste, sondern eine Version genutzt, die nach langen und intensiven Tests schon langer beim Autor im Einsatz ist. Ein entscheidender Vorteil und Hauptursache der Wahl des Systems fur die Tests war der Fakt, da samtliche Quellen vorliegen. Im besonderen Mae gilt dies fur die komplette Netzwerkprotokollimplementierung im Hauptteil des Systems, dem Kernel. Weitreichende Manipulationsmoglichkeiten konnten damit ausgenutzt und analysiert werden. Die dargestellten und untersuchten Sicherheitslucken lassen sich mit dem LINUX-System gut demonstrieren, sie sind jedoch nicht LINUX-spezi sch, sondern Probleme der eingesetzten Protokolle und oder Dienste und damit Lucken, die auf allen Systemen auftreten konnen, die diese Protokolle und Dienste einsetzen. Das LINUX-System wird als Werkzeug verwendet, generelle Probleme zu demonstrieren. [...]

Tabelle 5.3: Dienste in LAN und WAN Als grundlegende Aussage bei allen Netzwerkdiensten lat sich festhalten: Jeder Dienst birgt Sicherheitsrisiken, die erheblich von Programmversion und Kon guration des Dienstes abhangen. In der Literatur nden sich Angaben aus Analysen zur Systemsicherheit, unter anderem in STOLL ATKINS . So gibt zum Beispiel STOLL an, da von etwa 450 Login-Versuchen mit Login-Namen wie "root", "guest" u.a. 22 erfolgreich waren. Von 50 Sicherheitslochern wurden 9 durch Kon gurationsfehler, 3 durch Hersteller-Softwarefehler bei Wartungsarbeiten sowie 38 durch Software-Designfehler verursacht ATKINS . Statistischen Angaben aus KYAS folgend, ergibt sich eine Hau gkeit der im Internet durchgefuhrten Angri e: 1. Angri durch Abhoren Sni ng 2. Falschung von Absenderadressen in Internet-Protokoll-Paketen 3. Angri durch Ausnutzung von Schwachen des Mailsystems [...]

Der Telnet-Dienst dient der netzweiten Terminal-Emulation, jegliche Ein- und Ausgaben des entfernten Hosts werden uber das Netz ubertragen und lokal dargestellt RFC854 . Hauptschwachpunkt ist hier die nicht verschlusselte Ubertragung von Nutz- und Protokolldaten inklusive Accountdaten, die zur anfanglichen Anmeldung am entfernten Host notwendig sind. Damit ist es moglich, Login-Namen und Passwort im Klartext abzuhoren und entsprechend zu mibrauchen. Sinnvoll ist in jedem Falle die Verwendung von einmaligen Passwortern. Da eine bestehende Verbindung durch einen Angreifer durch die Sequenznummerndesynchronisation angegri en werden kann, sollte der Dienst auch in diesem Falle nur eingeschrankt genutzt werden. Die sogenannten "R-Tools" wurden erstmals von BSD-UNIX eingefuhrt und dienen der Fernausfuhrung von Kommandos, Dateitransfer und entferntem Login auf anderen Rechnern im Netz. Mit den "R-Tools" wurde die "Trusted Host"-Relation erstmals eingefuhrt, die vermeiden sollte, da Accountdaten im Klartext uber das Netz ubertragen werden. Durch die Datei etc hosts.equiv oder die Datei $HOME .rhosts im Home-Verzeichnis des jeweiligen Systemnutzers auf den kommunizierenden Rechnern, in denen die Hostnamen der Rechner eingetragen sind, wird die "Trusted Host"-Relation zwischen diesen beiden Systemen begrundet. Da den Hostnamen ebenso wie IP-Adressen kein Vertrauen entgegen gebracht werden kann, ist die "Trusted Host"-Relation durch einen Angreifer ausnutzbar. Einen Uberblick zu unterstutzten Diensten auf einem System kann man unter anderem durch Ausdruck der Datei etc services sowie etc inetd.conf [...]