Das Client/Server-Prinzip

Die Dienste der Anwendungsschcht werden oft auch als Träger von Client-Server-Verbindungen bezeichnet. Damit wird das Prinzip nahegelegt, dass sich die Dienste der Anwendungsschcht aus zwei ergänzenden Teilen zusammensetzen. Der Ausgangspunkt einer Verbindung wird Client und der Empfänger Server genannt.

,------. Anforderung  ,------. 
|Client|------------->|Server| 
`------'              `------' 

,------.  Antworten   ,------. 
|Client|<-------------|Server| 
`------'              `------' 

Ein Server-Dienst der Anwendungsschcht wartet in der ersten Phase seines Daseins auf Verbindungsanforderungen von einem Client. Der Dienst eines solchen stellt eine Verbindung zum Server her oder übergibt ihm eine Anforderung. Sobald die Verbindung eröffnet ist und die eigentliche Kommunikation beginnt, senden Clients Anforderungen, auf welche der Server entsprechend reagiert. Server können Transaktionen nicht selber initiieren. Ebensowenig kann eine Server-Software mit einer anderen Server-Software und Client-Software mit einer anderen Client-Software direkt kommunizieren.

Da es sich bei einem Anwendungsserver um herkömmliche netzwerkfähige Software handelt, können viele verschiedene Typen von Server- und Client-Software gleichzeitig auf einem multitaskingfähigen Betriebssystem laufen. Die Kommunikation mit Diensten von anderen Servern erscheint als Dialog zwischen gleichgestellten, also peer-to-peer, obwohl die Grundlage jeder TCP/IP-Kommunikation auf der Client/Server-Architektur beruht. In der UNIX-Welt wird die Server-Software normalerweise als "daemon" bezeichnet. Der Telnet-Server wird für gewöhnlich telnetd (ausgesprochen "telnet-die") genannt, eine Kurzform für "Telnet-Daemon". Der FTP-Server heisst ftpd und so weiter.

BOOTP (Bootstrap Protocol)

Das Bootstrap-Protokoll wird in den RFCs 951 (Bootstrap Protocol) und 1532 (Clarifications and Extensions for the Bootstrap Protocol) definiert. Die entsprechenden RFCs beschreiben BOOTP als Alternative zu RARP, denn wird das fortschrittlichere BOOTP verwendet, so ist RARP automatisch überflüssig. BOOTP ist umfangreicher und bietet einige Funktionen mehr als RARP. Die ursprüngliche Spezifikation erlaubte sogar Herstellererweiterungen als Mittel der Protokollevolution. RFC 1048 (BOOTP Vendor Information Extensions) brachte diese Zusatzfeatures auf einen Nenner, welche stets aktualisiert wurden und momentan als letztes in RFC 2132 (DHCP Options and BOOTP Vendor Extensions) in ihrer aktuellsten Form dokumentiert sind. BOOTP und seine Erweiterungen wurden zur Grundlage des Dynamic Host Configuration Protocol (DHCP).

Der BOOTP-Client verschickt in einer ersten Phase per Broadcast über die Adresse 255.255.255.255 ein einzelnes sogenanntes BOOTREQUEST-Paket, das mindestens seine physikalische Netzwerkadresse enthält. Diese spezielle Adresse wird als eingeschränkte Broadcast-Adresse (limited broadcast address) bezeichnet. Diese Adresse ist insofern von Nutzen, weil sie im Gegensatz zur normalen Broadcast-Adresse vom System nicht das Wissen um die Adresse des aktuellen Netzwerks voraussetzt. Wird die Antwort nicht innerhalb eines vordefinierten Zeitfensters empfangen, sendet der Client den Request erneut. BOOTP verwendet dabei UDP als Transportprotokoll und benötigt im Gegensatz zu RARP keine speziellen Protokolle der Netzzugangsschicht.

Der Server Antwortet im Gutfall dem Client mit einem BOOTREPLY-Paket. BOOTP werden zwei bekannte Port-Nummern zugesprochen: UDP-Port 67 wird für den Server, UDP-Port 68 für den Client verwendet. Dies ist ziemlich ungewöhnlich, da sich die meisten bekannten Client/Server-Anwendungen mit einem definierten Port für den Server und einem zufällig gewählten indefiniten Port für den Client begnügen. Diese Eigenheit kann sich BOOTP erlauben, da es nur in der Boot-Phase genutzt wird: Sockets verlieren somit bei diesem Einzelbetrieb den Sinn. Normalerweise stellt die zufällige clientseitige Wahl der Portnummern sicher, dass jedes Paar von Quell-/Zielports einen eindeutigen Pfad für den Austausch der Informationen ergibt. Der Client-Rechner kennt jedoch seine IP-Adresse vielleicht noch nicht. Selbst wenn er einen Quellport für das BOOTREQUEST-Paket generiert, würde eine Antwort des Servers an diesen Port/IP-Adresse-Kombination (Socket) nicht vom Client erkannt werden. Daher schickt BOOTP die Antwort an einen bestimmten Port auf allen Hosts. Ein an UDP-Port 68 adressierter Broadcast wird von allen Hosts gelesen, selbst von einem System, das seine eigene Adresse nicht kennt. Das System bestimmt, ob es als Empfänger des Pakets vorgesehen ist, indem es die in der Antwort enthaltenen Netzwerk-Adresse überprüft. Der Server füllt alle Felder des Pakets aus, für die er Daten besitzt. BOOTP kann alle wesentlichen TCP/IP-Konfigurationswerte bereitstellen.

DHCP (Dynamic Host Configuration Protocol)

DHCP ist ein TCP/IP-Protokoll, dank welchem ein mit einem DHCP-Server - auf Linux-Systemen wird der DHCP-Daemon (/usr/sbin/dhcpd) verwendet - verbundener Client-Rechner in einem Netzwerk die grundlegenden Netzwerkinformationen wie IP-Adresse, Hostname, Gateway, usw. automatisch abgreifen kann.

DHCP kommt vorzugsweise bei großen Netzwerken zum Tragen, bei jenen weniger mit IP-Adressen gearbeitet werden muss, da durch den DHCP-Dienst viel administrativer Aufwand verhindert werden kann. Unter anderem setzen auch viele ISPs (Internet Service Provider) auf DHCP: Bei jedem Einwählen eines Kunden erhält er eine dynamische IP-Adresse. ISPs müssen oft relativ sparsam mit ihren IP-Adressen umgehen, da ihnen nur ein gewisses Range - zum Beispiel 196.0.0.1 bis 196.0.5.255 - zur Verfügung steht. Wählt sich ein neuer Benutzer ein, so erhält er normalerweise die tiefste zur Verfügung stehende IP-Adresse.

In kleineren Netzwerken und bei auf IP-Adressen aufbauenden Authentifizierungen empfehle ich stets das Nutzen von statischen IP-Adressen. Die Einstellungen sind deutlich einfacher vorzunehmen und die Kommunikations-Partner müssen nicht zuerst mühsam über Umwege ihre aktuelle IP-Adresse publizieren.

Eine ausgezeichnete Informationsquelle zu DHCP ist die DHCP-FAQ von John Wobus. Es sind zudem neue und erweiterte Spezifikationen für DHCP im Gespräch. Einen Einstieg in die Diskussion findet sich in RFC 1531 (Dynamic Host Configuration Protocol).

Der DHCP-Client und der DHCP-Daemon sollten nach Möglichkeit auf allen Systemen deaktiviert werden, die keinen Nutzen daraus ziehen können oder wollen. Der Grund besteht darin, dass die ersten Freigaben der DHCP-Server in den Versionen 1.0 und 2.0 für Linux (/usr/sbin/dhcpd) anfällig auf Denial-of-Service-Attacken sind. Am besten sollte auf ein Update zurückgegriffen werden, sofern dieser Dienst wirklich benötigt wird.

Ich stelle nun die theoretische Behauptung auf, dass auch Routing-Attacken mit Hilfe von DHCP gefahren werden können. Stellen Sie sich vor, ein Angreifer schafft es in ihrem Netzwerk den Client-Rechnern falsche Routing-Informationen mit dem DHCP-Protokoll aufzuschwatzen: Zum Beispiel der zwangsweise Zugriff auf gefälschte DNS-Einträge oder korrupte Gateway-Spezifikationen. Durch dieses Manöver könnte der Angreifer alle Pakete über einen von ihm komplett kompromittierten Rechner laufen lassen, der die interessantesten Pakete anhand eines Packet-Sniffers ausliest und protokolliert. Dadurch käme er relativ schnell in den Besitz geheimer Informationen wie Passwörter oder vertrauliche Daten. Misstrauen Sie daher stets auf sicherheitsrelevanten Stationen den DHCP-Einstellungen und führen Sie Kontrollen jener und des daraus resultierenden Routings durch. Dies können Sie zum Beispiel mit dem Nutzen von Traceroute - /usr/sbin/traceroute bei Unix und seinen Derivaten oder c:\windows\tracert.exe bei Windows-Systemen - machen.

Bei der Linux-Distribution von Debian wurde in den Versionen 2.1 und 2.2 eine erfolgreiche Remote-Attacke erzielt, die Root-Zugriff zur Folge hatte. Das OpenBSD-Team berichtete in ihrem Artikel (Debian Security Advisory, 27. Juni 2000), dass ein kompromittierter DHCP-Server exekutive Kommandos an den Client schicken kann, der sie dann ohne zu zögern mit Root-Rechten ausführt.

Deaktivieren Sie grundsätzlich den Dienst server- und clientseitig und verwenden Sie statische Einstellungen falls dies Ihre Umgebung zulässt. In kleineren Netzwerken empfehle ich stets das Nutzen von festen IP-Adressen, da die Authentifizierung anhand der IP-Adressen einfacher zu regulieren ist und die Kommunikations-Partner nicht zuerst mühsam über Umwege ihre aktuelle IP-Adresse publizieren müssen.

FTP (File Transfer Protocol)

Beim Verbindungsaufbau nutzt der Client zwei Portnummern oberhalb 1024 (z.B. 4210 und 4211). Über den ersten TCP-Port baut er die Verbindung für die Kommandos auf. Der Server empfängt die Kommandos über den definierten Port 21. Bei der aktiven Methode teilt der Client mit dem Kommando "PORT 4211" dem Server mit, über welche Portnummern der Client den Datenaustausch abwickeln will. Der Server sendet ab dann die Daten von seinem definierten Port 20 auf die Portnummer 4211 des Clients. Für jede zu übertragende Datei wird eine neue Datenverbindung benötigt, die wegen TCP (Transmission Control Protocol) Bestimmungen eine andere Portnummer haben muss. Die Ports beim Datentransfer sind nicht vorhersehbar, was die Implementation von FTP (File Transfer Protocol) über Firewall-Systeme kompliziert. Sollte ein Paket-Filter zum Einsatz kommen, so empfiehlt sich das Nutzen des passiven FTP, bei dem der Client den Verbindungsaufbau durchführt.

Auch FTP nutzt NVT (Network Virtual Terminal) mit Klartext Login- und Passwortübermittlung. Manipulierte Routing-Informationen und gut eingerichtete Sniffer vermögen die Login-Prozeduren unerlaubt und im Geheimen aufzuzeichnen. Aus diesem Grund empfiehlt sich das Wählen von differenten Passwörtern, damit ein Angreifer nicht auch noch andere Dienste (z.B. SSH, Telnet, POP3, SMB-Freigaben, ...) missbrauchen kann, sobald er Besitz von einem Passwort einer FTP-Sitzung erlangt hat.

Viele FTP-Clients erlauben auch das bequeme Abspeichern von immerwiederkehrenden Login-Daten. Diese Informationen werden bei einigen Clients im Klartext ohne Verschlüsselung abgespeichert. Würde ein Angreifer Zugriff auf das komplette System bekommen (z.B. mit Remote-Control-Software), könnte er unter Umständen die Passwörter aus der Client-Software auslesen. Dazu wäre nicht mal besonders viel technisches Wissen erforderlich. Vermeiden Sie deshalb grundsätzlich das Speichern von sicherheitsrelevanten Informationen auf der lokalen Festplatte, falls Sie nicht um die Stärke der zum Einsatz kommenden Sicherheit und Verschlüsselung wissen.

Grössere Sicherheitsprobleme haben jedoch eher die Anbieter eines FTP-Service. Der FTP-Server muss stets als Root-Prozess laufen, da er standardmäßig einen priveligierten Port zu nutzen pflegt (TCP-Ports 20 und 21). Oft finden sich arge Software- bzw. Programmierfehler in den FTP-Dämonen, die eingeloggten Benutzern das Ausführen von Kommandos mit Server- oder gar Root-Rechten erlauben. Versuchen Sie wenn möglich auf das Anbieten des FTP-Dienstes zu verzichten und deaktivieren Sie den Daemon-Prozess (bei Linux in /etc/inetd.conf). Falls Sie trotzdem diesen zugegebenermaßen komfortablen Service anbieten wollen, so verwenden Sie grundsätzlich die aktuellste Server-Software. Achten Sie auf das Erscheinen neuer Sicherheitslücken bei ihrer Software und reagieren sie gegebenenfalls.

Ein weiteres Problem in Punkto Sicherheit kommt auf die Systemadministratoren zu, die unter anderem auch für die Konfiguration der Firewall-Elemente zuständig sind. Da die allermeisten Geräte den Usern generell FTP zugänglich machen, ist der FTP-Port zusammen mit TCP-Port 80 (HTTP) sehr beliebt um unerwünschte oder unerlaubte Informationen und Daten (z.B. Scans, Kommandos für Remote-Control-Software, ...) um die Firewall-Systeme herum zu dirigieren. Aus diesem Grund sollte für die Dienste FTP und HTTP ein Proxy verwendet und eine spezifische Schließung dieser sonst relevanten Ports bei den Firewall-Elementen vorgenommen werden.

nach oben

HTTP (Hypertext Transfer Protocol)

HTTP stellt das im World Wide Web eingesetzte Protokoll zum Anfordern von Daten, vor allem HTML-Dokumenten, dar. Ein Verbindungsaufbau mit HTTP findet mit dem üblichen Dreiwege-Handschlag auf den TCP-Port 80 statt. Die Nachrichten werden in beiden Richtungen ausgetauscht, wobei man sich dies als Dialog vorstellen muss. Dieser Dialog findet zwischen einem Webserver und dem Webbrowser statt.

Auf Unix-Systemen wird /usr/sbin/httpd für das Starten des Webservers ausgeführt. Bei Unix-Derivaten kann der Webserver bei /etc/inetd.conf auskommentiert werden, um einen automatischen Start zu verhindern. Explizit bei der Distribution von SuSE muss unter Umständen eine Manipulation von /etc/rc.config getätigt werden, um das Starten des Webservers beim Booten zu steuern.

Bei HTTP werden die Daten vorzugsweise im Klartext übermittelt, was natürlich die allgemeinhin bekannten Sicherheitsrisiken nach sich zieht. Ein Angreifer könnte mit korrupten Routing-Informationen und einem gut platzierten Sniffer Ausschau nach relevanten und vertraulichen Informationen halten, um andere Dienste auf Kosten seines Opfers zu missbrauchen. Als einzige Alternative bietet sich die sicherere Form von HTTP mit der Abkürzung SHTTP (Secure Hypertext Transfer Protocol) an. Bei SHTTP werden die Daten vor dem Versand verschlüsselt, um eine passive Attacke zu erschweren.

Grundsätzlich sollte ein Proxy-Server für das Weiterreichen von HTTP-Anfragen genutzt werden. Dadurch kann die Filterung für das IP-Masquerading am Firewall-Element verschärft werden. Im gleichen Atemzug könnten Angreifer nicht mehr ungehemmt korrupte Aktionen, Daten und Informationen über die sonst zur Verfügung stehenden Ports weiterleiten lassen.

nach oben

IRC (Internet Relay Chat)

IRC ist ein Service, über den Internetbenutzer live an Onlinekonversationen mit anderen Benutzern teilhaben können. Ein IRC-Kanal, der von einem IRC-Server zur Verfügung gestellt wird, überträgt reinen ASCII-Text, der von den Benutzer eingegeben wird, und überträgt sie in Real-Time an die Client-Software der anderen Benutzer im gleichen Channel. In der Regel wird sich in einem Kanal einem bestimmtem Thema (Topic) gewidmet, das sich am Namen (z.B. #hack, #games, #dates, ...) erkennen lässt. Der IRC-Client zeigt automatisch die Namen der aktuell aktiven Kanäle an und ermöglicht es dem Benutzer, eine Verbindung zu einem solchen herzustellen. Anschliessend werden die Texte  der anderen Benutzer über einzelne Leitungen angezeigt, so das der Benutzer an der Kommunikation teilhaben kann. IRC wurde 1988 von Jarkko Oikarinen aus Finnland erfunden, und zählt zusammen mit ICQ von Mirabilis zum meist genutzten Chat-Dienst der Internets. Zusätzliche Informationen zu IRC finden sich in der kurzen Online-Dokumentation von MagicMartin und auf http://irc.pages.de. Um die von IRC genutzte Befehlsstruktur sollte man sich das Text-Dokument von Beowulf anschauen, welches das Nutzen von IRC mittels Telnet verdeutlicht.

Der beliebteste IRC-Client für Linux ist ohne Zweifel BitchX (/usr/bin/BitchX), da er komfortabel auf der Kommandozeile mit einer farbigen Darstellung alle Funktionen leicht zugänglich macht. Sein wohl noch erfolgreicheres Gegenstück aus der Windows-Welt ist mIRC, der mit einer ausgeklügelter Funktionalität ohne grosse Tastenkombinations-Hürden auftrumpft.

Grundsätzlich gelten für den IRC die gleichen Gefahren wie bei ICQ: Zum Einen öffnet ein Benutzer des Chats den hunderten von anderen Anwendern, die in diesem Augenblick potentielle Gegner sind, die Türen zum heimischen Rechner. Es gibt duzende von Tools, mit jenen man Chat-Sessions und -Kanäle sabotieren kann; so zum Beispiel mit ircdexp.c, welches einem erweiterte Rechte in einem Kanal beiircd 6 besorgen kann. Dies birgt weniger die Gefahr eines Eindringens, als eher einer lästigen Denial of Service-Attacke. Da dank dem IRC jedoch auch Daten binärer Natur durch die Datenleitungen des Internets gejagt werden können, schleicht sich die selbe Viren-Gefahr wie beim Mail-Verkehr durch das Netz der Netze. Zusätzlich weisen einige IRC-Clients Sicherheitslücken auf, die für Benutzer eine Bedrohung darstellen können: Der neueste Bug trifft, wie wunderschön bei PacketStorm im Artikel bitchx-dns-oddities.txt von Michael Zalewski berichtet wurde, alle BitchX-Nutzer bis zur Version 74p4 wegen einer falschen Handhabung der in RFC 1035 (Domain Names - Implementation and Specification) bei Absatz 2.3.4 spezifizierten Länge von Domain Namen im ircd bis 2.9.5 mit einer DoS-Attacke. Will man den IRC-Service nutzen, so sollte man mit einem sicheren Client und gesundem Menschenverstand bewaffnet die einzelnen Channels aufsuchen.

Zusätzlich stellt das Betreiben eines IRC-Servers eine additionelle Gefahr dar, denn die Vergangenheit vermochte zu beweisen, dass mit Programmen wie ircd_kill.c und doomzday4.c auch IRC-Daemonen korrumptiert werden können: DoS-Attacken in Form von Splits (siehe deutschsprachiger Artikel von Snowman) werden gerne genutzt um den Dienst unzugänglich, oder sich selber zum Channel-Operator zu machen. Verzichten Sie auf das Anbieten dieses Service. Im Intranet mag dieser Dienst interessant erscheinen, doch gibt es bessere Lösungen wie ICQ fürs LAN oder Talk unter Unix. Ausserdem gibt es genug externe IRC-Server, die für eine Kommunikation genutzt werden können. Zusätzliche War-Software zu IRC findet sich im IRC-Software-Archiv.

nach oben

Kerberos

Kerberos nutzt den TCP-Port 88 und ist ein Network Authentication Protocol, das vom MIT (Massachusetts Institute of Technology) entwickelt wurde und zur freien Verfügung bereit steht.. Kerberos bestätigt die Identität des Benutzers, der sich bei einem Netzwerk anmeldet, mittels eines Drittservers, und verschlüsselt die Kommunikation durch eine Secret-Key-Kryptographie. Kerberos ist bereits in vielen Produkten integriert, darunter auch in Windows 2000. Mehr Informationen zu Kerberos Version 5 und seine Spezifikationen finden Sie in RFC 1510 (The Kerberos Network Authentication Service (V5)).

Kerberos selbst weist keine erwähnenswerten Mängel in der Sicherheit auf, was den gewissenhaften Administrator nicht gegen das Nutzen dieses Protokolls auflehnen lassen sollte. Eine Gefahr besteht in schlecht vorgenommenen Implementationen des Protokolls, die unter Umständen Bufferoverflows und Denial of Service-Attacken ermöglichen. Weiterhin sind die Session-Keys auf dem Kerberos-Server 4 unter gewissen Umständen schlecht gewählt. Ein Angreifer könnte zudem die starke Authentifizierung in einer Windows 2000-Domäne mittels SYN-Flooding auf den von Kerberos genutzten TCP-Port am Domänen-Controller unterlaufen, da alle Clients auf die wackelige NT-Beglaubigungsroutine herabgesetzt werden. Das erfolgreiche Schnüffeln ist dann nur noch ein Kinderspiel und eine Frage der Zeit.

nach oben

NFS (Network File System)

Das Network File System, das immernoch unter diesem Namen bekannt ist, obwohl Sun Microsystems als ursprüngliche Hersteller-Firma die Bezeichnung ONC (Open Network Computing) gewählt hat, wurde für die hochleistungs UNIX-Workstations aus dem eigenen Hause entwickelt und später von den drei RFCs 1014 (XDR: External Data Representation Standard), 1057 (RPC: Remote Procedure Call Protocol Specification Version 2) und 1094 (NFS: Network File System Protocol Specification) spezifiziert. Als Sun den herannahenden Stellenwert der IBM-PCs erkannte, wurde auch NFS-Software für PCs entwickelt, der sogenannte PC-NFS Client. Mit ihm können PCs UNIX-Workstations als entfernte Datei- und Druckerserver verwenden. NFS ist mitlerweile für die meisten Plattformen verfügbar.

NFS fasst Dienste zusammen, die den Benutzern von herstellerspezifischen LANs zur gemeinsam en Nutzung von Ressourcen, wie zum Beispiel NetWare, LAN Manager oder Banyan VINES, vertraut sind. Dateien, Verzeichnisse und Peripheriegeräte werden in einem entfernten NFS-Server virtuell abgebildet. Ausser den Einbussen in der Performance unterscheiden sich solch gemappte Ressource nicht von anderen und kann in der altgewohnten Weise verwendet werden. In einem UNIX-System erscheint jedes entfernte Verzeichnis als zusätzliches Verzeichnis innerhalb der lokalen Hauptverzeichnishierarchie. Bei PCs mit PC-NFS erscheinen entfernte Verzeichnisse als zusätzliche Laufwerke. Dies garantiert eine einfache Einarbeitung und Handhabung von Seiten des Benutzers. Zusätzliche aufwändige Instruierungen und Schulungen fallen erfreulicherweise Weg. NFS bietet aber im Grunde mehr, als nur Ressourcen für eine gemeinsame Nutzung bereitzustellen. Es schafft die Voraussetzung für echte verteilte Datenverarbeitung, bei der mehrere vernetzte Rechner nicht nur die Daten, sondern auch die Prozessorleistung gemeinsam verwenden können. Einer der Vorteile von NFS ist der modulare Aufbau. Als Transportmechanismus wird UDP bzw. seit Version 3 TCP benutzt, auf welchem die für NFS entwickelten Module RCP (Remote Procedure Call) und XDR (Exchange Data Representative) aufsetzen. Ein Dienst wie NFS durch die Hilfe von reinem UDP zu realisieren schafft eventuell weitreichende Probleme. UDP bei NFS ist der primäre Grund, warum bei der Übermittlung von Daten entfernter Hosts der Datendurchsatz bei den ersten beiden Protokoll-Generationen merklich leidet. Es gibt daher Implementierungen von vergleichbaren Lösungen, die ein ähnliches Konzept wie das von NFS mit TCP durchsetzen; auch NFS in der Version 3 ist dank TCP unter Umständen die bessere Wahl. Eine alternative Lösung dieses Performance-Problems bestünde im Einsatz mehrerer lokaler Server.

NFS-Verwaltung

Das Administrative und die Verwaltung im Zusammenhang mit NFS können vor den Benutzern verborgen werden. Diese Aufgaben betreffen die Datensicherheit und die Abbildung der Benutzerkennungen und Zugriffsrechte zwischen den einzelnen Systemen. NFS arbeitet mit NIS (Network Information Services) zusammen. NIS ist ein verteiltes Datenbanksystem für die NFS-Sicherheitsdienste und ermöglicht das zentrale Management verteilter Systeme. Trotzdem erfordert die Verwaltung grosser NFS-Cluster eine sorgfältige Organisation und korrekte Dokumentation, wie dies auch bei vergleichbaren Lösung der Fall ist. Die Sicherheitsvorkehrungen sollten nicht zu locker gehandhabt werden, dass die Integrität der Daten gefährdet wäre. Andererseits sollen die Sicherheitsrichtlinien auch nicht mit solch eiserner Faust durchgesetzt werden, dass die Arbeit in ihrem eigentlichen Sinne gehemmt werden würde.

Sicherheit ist bei PC-Zugriffen in vernetzten Umgebungen immer und erst recht ein Problem. Solange die Hardware von Computer-Systemen nicht standartisiert ist, können die meisten Sicherheitsvorkehrungen von erfahrenen und hartnäckigen Angreifern umgangen werden. Die NFS-Anordnung überprüft die Zugriffsberechtigungen von PCs mit dem Programm PC-NFS Daemon, das von einem Server ausgeführt wird und den Zugriff der Benutzer auf die Dateisysteme überwacht. Damit ist der erste Stein einer Grundlage zur Realisierung der Sicherheit gelegt. Einige Arbeitsumgebungen benötigen jedoch zusätzliche Sicherheitsmassnahmen. So löst zum Beispiel "Secure NFS" die Probleme der unerlaubten Einsicht und Manipulation Dritter durch das DES-Verfahren (Data Encryption Standart).

Wenn NFS vor allem zur gemeinsamen Nutzung von Ressourcen eingesetzt wird, können mangelhafte Konfigurationsmöglichkeiten der Workstations das Datenaufkommen im Netz drastisch erhöhen. Durcker-Spooldateien, temporäre Backups und das Format des "path"-Statements können die Auslastung des Netzwerks in die Höhe schnellen lassen.

Um NFS vollkommen vor dem Endbenutzer zu verbergen, sollte an jeder Workstation ein Skript erstellt werden, das die NFS-Befehle zum Mounten der entfernten Ressourcen enthält. Bei Bedarf wird die Stapelverarbeitungsdatei ausgeführt, so dass beim Weg zum effektiven Datenaustausch keine Zusätzliche Arbeit für den User anfällt.

nach oben

NFS-Angriffe

NFS hat, wie jedes exportierbare Dateisystem, ein sehr hohes Missbrauchspotential. Neben den vielen Bufferoverflows auf mountd, den NFS-Server für UNIX, kann das auf RPC-Aufbauende Konzept bei falscher Konfiguration leicht durch Angreifer rein zum Zweck des Missbrauchs gemounted werden. Viele Sicherheitsfunktionen beziehen sich auf ein Datenobjekt mit dem Namen "File-Handle". Der File-Handle ist ein Token, das der Identifizierung einer jeden Datei und eines jeden Verzeichnisses am Remote-Server dient. Wenn der Angreifer ein File-Handle erkennen oder erraten kann, kann er den Zugriff auf diese Ressource am Remote-Server erzwingen.

Eine fehlerhafte Konfiguration des NFS-Dienstes ist schon für so manchen Administrator zum Verhängnis geworden. Wird das Dateisystem aus Faulheit oder Unwissenheit für everyone exportiert, so kann jeder Remote-Benutzer die Ressource ohne Authentisierung mounten. Der Angreifer braucht die Sicherheitshürden des zu komprimittierenden Systems gar nicht mehr zu überwinden, sondern mounted gelassen das Dateisystem und bringt die Daten seines Begehrens so in seinen Besitz. Typischerweise werden die Home-Verzeichnisse der Benutzer für den globalen Zugriff freigegeben. Noch schlimmer wird es, wenn die komplette Partition einer solchen Exportierung unterzogen wird.

Um ein Zielsystem daraufhin zu untersuchen, ob NFS ausgeführt wird und welche Dateisysteme dem Export nachgehen, kann man sich des Programms rpcinfo bedienen. Im Gutfall verrät Ihnen das Kommando showmount die exportierten Ressourcen auf dem Zielsystem. Über den altbekannten Mount-Befehl kann man sich nun in das Dateisystem remote einklinken. Nützlicher und flexibler ist jedoch das Toolkit nfsshell von Leendert van Doorn: Das nfsshell-Paket enthält einen robusten Client mit dem Namen nfs, welcher ähnlich wie ein FTP-Client funktioniert. NFS hat sehr viele nützliche Funktionen, die einem das Browsen im non-lokalen Dateisystem erleichtert.

NFS-Angriffe: Gegenmaßnahmen

Wenn Sie  NFS nicht benötigen, so deaktivieren sie es und alle damit verbundenen Dienste wie mountd, statd und lockd. Führen Sie zudem Zugriffssteuerungsmechanismen für den Client- und Benutzerzugriff ein, um nur authorisierten Benutzern freie Hand zu gewähren. Im Allgemeinen werden in den Dateien /etc/exports, /etc/dfc/dfstab oder ähnlichen der Zugriff auf exportierte Dateisysteme gesteuert. Dortige zusätzliche Optionen erlauben das Einschränken anhand Benutzer- oder Maschinennamen und das Deaktivieren von SUID-Bit auf exportierbaren Dateisystemen. Tragen Sie niemals die eigene Maschine in die Dateien ein, wo die authorisierten Systeme für das Mounten von lokalen NFS-Ressourcen vermerkt werden. Dadurch verleihen Sie unerweigerlich lokalen Benutzern erweiterte Rechte.

Ältere Versionen von portmapper erlauben einem Angreifer das Aufbauen von Verbindungen über Proxy-Server. Wenn das System das exportierte Dateisystem aktivieren konnte, hatte der Angreifer die Möglichkeit NFS-Pakete an den portmapper des Zielsystems zu senden, der wiederum eine Anforderung an localhost weiterleitet. Die Anforderung würde dann so aussehen, als stamme sie von einem vertrauten Host und könnte alle Zugriffsteuerzbgsregeln umgehen. Installieren Sie beim Auftreten solcher Probleme Patches oder Updates.

nach oben

POP3 (Post Office Protocol 3)

Dieses Protokoll ist im Internet für das Empfangen, Speichern und Übertragen von E-Mails zuständig. Dieses Protokoll wird auch bei Mail-Clients auf Computern eingesetzt, die eine Verbindung zu ihrem Mail-Server aufbauen, um die elektronische Post zu laden oder herunterladen. Die Spezifikationen werden in RFC 1725 (Post Office Protocol - Version 3) und RFC 2449 (POP3 Extension Mechanism) publiziert.

Das Protokoll selber gilt als sehr sicher für seine Zwecke, da unter anderem eine vertrauenswürdige Beglaubigung des Benutzers stattfindet, und viele POP3-Server in ihren Konfigurationen Einstellungen zulassen, die mögliche Brute-Force-Attacken abzuwehren vermögen. Der Vorgang der Authentizierung des Benutzers am Server wird offiziell in RFC 1734 (POP3 AUTHentication command) geregelt.

Wie bei einigen FTP-Clients weist manch cleintseitige Software, die eine Implementation von POP3 aufweist, eine schlechte Handhabung des persönlichen Passworts auf. Mit anderen Worten wird desöfteren das Login-Passwort im Klartext irgendwo auf der Festplatte gespeichert. Betroffen davon sind sehr viele Windows-Clients; verschont bleibt die Software von UNIX-Systemen jedoch keinesfalls: Das oft eingesetzte Programm "Fetchmail" (/usr/bin/fetchmail) speichert das Passwort für den POP3-Account in der Datei ~/.fetchmailrc, welche zum Glück mit den sicheren Rechten 100600 ausgestattet ist. Hat ein Angreifer erst einmal Zugriff auf die lokale Festplatte seines Opfers und das Wissen um den Standort der vermeindlichen Passwörter, so ist es in jenem Augenblick auch um den POP3-Account des betroffenen geschehen.

Die grösste Gefahr besteht für die Server-Betreiber, die diesen Dienst ihren Benutzern zukommen lassen wollen. Ab und zu tauchen Exploits für POP3-Software auf, die DoS-, Race-Condition- oder Bufferoverflow-Attacken auf betroffenen Systemen ausnutzen können, um den Betrieb (im negativen Sinne) zu stören. Aus diesem Grund sollte versucht werden den POP3-Server zu deaktivieren (bei Unix unter /etc/inetd.config die besagte Zeile einfach auskommentieren), sofern auf den Dienst eines Drittanbieters ausgewichen werden kann. Als markante Nachteile dieser externen Lösung gestalten sich löchrigere Firewall-Regeln und das Mögliche Abfangen der Nachrichten zwischen Server und Client.

nach oben

SMB (Server Message Block-Protokoll)

NetBEUI bezeichnet von IBM 1985 entwickeltes Netzwerkprotokoll. Es ist zu allen derzeit aktuellen Microsoft Windows-Versionen (angefangen von Windows 3.X bis Windows 2000) kompatibel. Im Unterschied zu TCP/IP kann es nicht über Router weitergeleitet werden. Es eignet sich daher nur zum Aufbau kleiner Netze. Um ein LAN an das Internet anzubinden, ist auf jeden Fall TCP/IP notwendig.

Doch nicht nur Windows-Systeme nutzen diesen Service: Unter anderem ist er auch von OS/2 und UNIX-Derivaten her ansteuerbar. Um mit einem UNIX-Rechner auf diese Weise einen Host ansteuern zu können, muss auf die Samba-Suite zurückgegriffen werden, welche folgende Elemente enthält:

• smbd - Der Samba-Daemon für das Zugänglichmachen von eigenen Ressourcen. Konfiguriert wird er, für Anfänger ein bisschen kompliziert, in der Datei /etc/smb.conf.
• smbclient - Der FTP-ähnliche Shell-Client für das nutzen von externen Ressourcen.
• smbmount / smbmnt - Durch dieses Tool können Shares fest von Betriebssystem gemounted werden, und erhalten danach den selben Status, wie lokaler fester Speicherplatz.
• smbumount - Mit diesem Utlility können durch Samba gemountete Ressourcen wieder abgekoppelt werden.
• smbstatus - Informiert in real-time über den aktuellen Status von Samba, bei dem unter anderem auch die eingeloggten User und deren genutzte Ressourcen ersichtlich sind. Mit Samba auf einem System eingeloggte User können auch durch die Eingabe von "ps aux" auf Linux-Systemen ersichtlich gemacht werden.
• smbpasswd - Mit diesem Programm aus der Samba-Suite können die Samba-Passwörter der einzelnen Benutzer geändert werden.
• smb_auth / smb_auth.sh - Führt die Authentifizierung von Samba-Nutzern durch.
• smbtar - Mit diesem kleinen Tool können von Samba-Shares ein Backup direkt auf ein Streamer-Tape gemacht werden, falls ein solches vorhanden und in Betrieb sein sollte.

Natürlich existiert auch (komfortablere) Software von Drittanbietern, unter anderem auch für die graphische Oberfläche X, welche schlussendlich jedoch meist auf die Elemente der Samba-Suite zurückgreift.

Da NetBEUI nicht von Routern weitergeleitet werden kann, bietet das Protokoll einen angenehmen Nebeneffekt beim Einsatz im lokalen Netzwerk. So können interne damit zur Verfügung gestellte Informationen, Daten und Shares nicht mit externem Zugriff angesteuert werden. Trotzdem machen viele User den Fehler, Rechner, die direkt mit dem Internet verbunden sind, komplett oder zu breitflächig mit Sharing-Eigenschaften zu versehen. Die Gefahr besteht darin, dass sich jeder Benutzer für freigegebene Ressourcen ohne Passwortschutz einloggen kann und darf. Nicht selten werden so private Dokumente oder geheime Informationen freigegeben (z.B. der komplette ICQ-Ordner, welcher einmal kopiert das Nutzen unter anderem Namen erlauben kann!). Das schlimmste sind jedoch komplette Schreibrechte für die ganze Festplatte für jederman. Angreifer können Produkte wie msmbs.sh, smbls98.tgz, SmbScanner v1.0, SharesFinder und eventuell noch crazy.c und STC 3.0 nutzen um nach Freigaben mit lax gesetzten Rechten zu suchen und zur Nutzung zugänglich zu machen. Geben Sie deshalb so wenig wie möglich frei, und schützen Sie es im besten Falle mit einem undurchschaubaren Passwort. Ich muss Sie nun vor den Kopf stossen, denn bei so mancher Windows-Version kann das Passwort auf schnellste Weise mittels ausgeklügelter Brute-Force-Attacke identifiziert werden: Durch das Windows-Tool PQwak werden die serverseitigen Antwort-Sequenzen durchschaut, so dass innerhalb weniger Minuten das richtige Passwort herausgefunden werden kann. Von dieser Fehlimplementierung betroffen sind Windows 95, Windows 98 und Windows NT 4.0.

Eine weitere nicht zu unterschätzende Gefahr besteht im Ausspionieren der Passwort-Sequenzen, welche durch Programme wie readsmb.c und readsmb2.c aus l0phtcrack 2.0 ermöglicht werden. Eine Niederschrift zu dieser Attacke wurde von L0pht bei Bugtraq publiziert. In diesem Falle wäre das komplette Verzichten von passwortgeschützten Freigaben wohl nicht das wirklich richtige, denn vielerorts müssen solche Realisationen für den komfortablen Datenaustausch einfach herhalten. Dafür sollten unbedingt starke Passwörter Verwendung finden, die möglichst oft - am besten etwa alle 60 bis 90 Tage - gewechselt werden, und sonst nirgends in ihrer Form zum Einsatz kommen. Dadurch will man verhindern, dass ein Angreifer, wenn er einmal im Besitz eines Passworts für eine Share ist, auch auf andere solche oder Systeme mit dem Wissen um jenes zugreifen kann.

Die Samba-Suite für UNIX-Derivate beherbergt einige Möglichkeiten, die die Sicherheit von Samba-Shares einfach konfigurieren lässt:
smb.conf - Die sich in /etc befindende Datei kann mit einem ASCII-Editor modifiziert werden, und bietet in einigen Abschnitten die Möglichkeit einer komfortablen Zugriffssteuerung. Anfänger werden jedoch Anfangs Probleme mit der Konfiguration haben, da viele DInge beachtet werden müssen.
smbpasswd - Mit diesem Programm aus der Samba-Suite können die Samba-Passwörter der einzelnen Benutzer geändert werden.
smb_auth / smb_auth.sh - Führt die Authentifizierung von Samba-Nutzern durch.
Zusätzlich kann mit dem Kommando "smbstatus" der aktuelle Status der Verbindungen abgefragt werden, wobei die genutzten Shares und die eingeloggten User ausfindig gemacht werden können. Unter anderem tauchen ähnliche Informationen auf Linux mit der Eingabe von "ps aux" auf.

Wie so oft, so geht jedoch beim Nutzen der Samba-Suite auf UNIX-Systemen eine gewisse Gefahr von demselbigen aus. So findet sich zum Beispiel eine Verwundbarkeit der bei vielen Linux Distributionen, darunter Red Hat, Caldera und TurboLinux, mitgelieferten binären Version von wsmbconf, welche mit gid root installiert wird, und für jeden ausführbar ist. Benutzer können diesen Fehler ausnutzen um die Lese-/Schreibrechte der Gruppe root zu erhalten, wie im Artikel der Bugtraq-Mailingliste am 19. November 1998 berichtet wurde. Ein separater Artikel für die Caldera-Distribution folgte einen Tag später vom Caldera-Support. Desweiteren existiert für smbd 2.0.1 ein Root-Exploit unter dem Namen smb_mount.c. Bugfixes für löchrige Samba-Suiten finden sich in Vendor Bulletin 97.10 und Information Bulletin H-110 vom CERT und Advisory vom 23.07.1999 von Red Hat.

               ,----------.                ,----------. 
   ,------.    |          |      SMTP      |          | 
   | User |<-->|          |   Kommandos-/  |          | 
   `------'    |  Sender  | Uebertragungen |Empfaenger| 
   ,------.    |          |<-------------->|          |    ,------. 
   |Datei-|<-->|          |    und Mail    |          |<-->|Datei-| 
   |System|    |          |                |          |    |System| 
   `------'    `----------'                `----------'    `------' 

                Sendender                  Empfangender 
                 Rechner                     Rechner 

 - Lokales Netz --- Das ungeschützte Internet ------- Lokales Netz -------
|                |                          |                             |
|                |                          |                             |
 ----  Absender   -----  Übertragung   -----                          ----
|User|  einer    | MTA |  per SMTP-   | MTA |<-- Abfrage neuer Mails |User|
 ----  E-Mail -->|     | Protokoll -->|     | --> Laden neuer Mails   ----
[====]            -----                -----                         [====]

Received: from relay03.cablecom.net (relay03.cablecom.net [62.2.33.103]) 
 by mail.swissonline.ch (8.9.3/8.9.3) with ESMTP id HAA08221 
 for ; Fri, 7 Jul 2000 07:01:26 +0200 (MET DST) 
Received: from iis-cf9a5410.col.impulse.net ([207.154.84.16]) 
 by relay03.cablecom.net (8.9.3/8.9.3) with ESMTP id HAA32623 
 for ; Fri, 7 Jul 2000 07:01:23 +0200 
Received: from mta1-rme.xtra.co.nz (mta1-rme.xtra.co.nz [203.96.92.1]) 
 by iis-cf9a5410.col.impulse.net (8.9.3/8.9.3) with ESMTP id VAA11134 
 for ; Thu, 6 Jul 2000 21:00:48 -0700 
Received: from [210.55.122.20] by mta1-rme.xtra.co.nz 

             -------     ,-------.      -------- 
eingehende  | SMTP- |    |  ---->|-    |  MTA   | 
E-Mail      | Proxy |    | /     | \   |  z.B.  | abgehende 
----------->|.......|-   |¦SMTP- |  \  |Sendmail| E-Mail 
Port 25     |       | \  |¦Daemon|   ->|........|----------> 
             -------   ->`-------'      -------- 

mruef@prometheus:~ > xscan zion 
Scanning hostname uion ... 
Connecting to zion (192.168.0.5) on port 6000... 
Connected. 
Host zion is running X. 
Starting keyboard logging of host zion:0.0 file KEYLOGzion:0.0... 

mruef@prometheus:~ > tail -f KEYLOGzion:0.0 
su 
[Shift_L]Password