LEU Stuttgart, Online News 15, FTP - Zugriffe unter Linux

1.2 Zugriffe unter Linux

Abbildung 1: Eine Auswahl verfügbarer Serverdienste unter Linux

Linux-Server sind als Multitasking- und Multiuser-Betriebssystem von Haus aus mit einer Vielzahl von Serverdiensten ausgestattet. Damit stellt sich hier meist nicht die Frage, ob der eine oder andere Dienst verfügbar ist. Es geht vielmehr häufig um die Frage, welche Dienste für die Nutzer unverzichtbar sind und somit nicht abgeschaltet werden können.

Die Angriffe auf im Internet bzw. im lokalen Netzwerk (LAN) „sichtbare" Rechner nehmen täglich zu. Als Angriffsfläche dient unter anderem das Ausspähen von Benutzerkonten und deren unberechtigte Nutzung.

Nachfolgend wird deshalb meist nur kurz auf die verfügbaren Dienste eingegangen. Im Zuge der Secure Shell (SSH) soll danach ein Weg aufgezeigt werden, um zumindest „telnet" und „ftp" abzuschalten, ohne dem Benutzer Funktionalität zu nehmen.

Damit überhaupt von Außen auf den Schulserver zugegriffen werden kann, benötigt dieser auf jeden Fall einen festen Rechnernamen im Domain-Name-Service (DNS). Für Rechner, die über BelWü an das Internet angeschlossen sind, ist dies kein Thema. Der Server erhält dabei eine feste IP-Nummer und wird in den DNS von BelWü eingetragen. Bei einer Standleitung (diese Ausstattung wäre aus didaktischer Sicht flächendeckend wünschenswert) ist er damit ständig erreichbar. Bei Wahlleitungen ist er zumindest dann verfügbar, wenn er aus irgendeinem Grund online geht.

Problematischer wird die Erreichbarkeit, wenn z.B. der kostenlose T-DSL-Zugang des T@School-Programms von T-Online genutzt wird. Dies ist zumindest als Backup-Lösung bzw. zur Entlastung der BelWü-Leitung eine gute Option. Erstens gibt es hier keinen festen Rechnernamen und zusätzlich wirft T-Online den Rechner mind. einmal pro Tag ab, um eine neue IP-Nummer zu geben. Unter Verwendung von „Dynamic DNS" ist es jedoch auch in diesem Fall möglich, den Rechner mit einem Namen zu versehen. Ein kostenfreier Anbieter für diesen Service ist hier zu finden.

ACHTUNG: Der ftp-Serverdienst ist eines der sehr beliebten Angriffsziele für Server im Internet. Achten Sie bei der Installation auf eine möglichst sichere ftp-Server-Variante und beachten Sie im Betrieb des Serverdienstes ständig die verfügbaren Sicherheitshinweise und -updates!

Noch besser: Gewähren Sie keinen ftp-Zugang zu Ihrem Netz!!! Als Alternative bietet sich scp oder sftp an (siehe SSH-Artikel)!

Die Server-Seite

In der Standard-Installation der aktuellen SuSE-Distribution (Version 8.0) wird kein ftp-Serverdienst installiert. Möchte man dies tun, hat man die Wahl zwischen drei Produkten:

• Berkeley Software Distribution (BSD) FTP-Daemon

• Pure FTPd

• Very Secure FTP Daemon vsfpd

Client-Software

Windows-Clients

Kommandozeile

ftp auf der Kommandozeile ist zwar nicht sonderlich beliebt, aber wenigstens immer verfügbar. Einfach eine DOS-Shell (MS-DOS-Fenster) öffnen und mittels des Kommandos „ftp servername" eine Verbindung aufbauen. Für die weitere Benutzung benötigt man Kenntnisse über verfügbare Kommandos. Hier hilft gegebenenfalls das „help" bzw. „help <kommando>" Kommando weiter.

WS_FTP

Die Client-Software WS_FTP  erfreut sich schon seit einigen Jahre in Schulen und bei Privatpersonen großer Beliebtheit. Die älteren Versionen waren für Bildungseinrichtungen, deren Personal und für Schüler/Studenten kostenfrei. Allerdings sind diese Versionen teilweise für modernere Clients (z.B. Windows 2000) nicht mehr sauber einsetzbar, da das Hinzufügen von Verbindungsprofilen erweiterte Rechte erfordert.

Es gibt zwar neue Versionen der Software, die dieses Problem umgehen. Diese Versionen sind allerdings auch für Schulen nicht mehr kostenlos. Eine Lizenz schlägt je nach Kaufvariante mit ca. 40 US-$ zu Buche. SmartFTP Mit SmartFTP steht eine kostenfreie Alternative zu WS_FTP zur Verfügung.

SmartFTP läuft unter allen Windows-Varianten (Win9x/NT/2000/XP).

Linux-Clients

Auch hier gibt es natürlich analog zu obiger DOS-Shell ein ftp-Client-Utility auf Shell-Ebene. Daneben stehen auch hier etliche grafischen ftp-Clients zur Verfügung. Einer der komfortabelsten dürfte hier IglooFtp sein.

Mail-Services

Shell-Zugriff via Telnet

Hierzu gibt es eigentlich nur eines zu sagen _ ABSCHALTEN! Der telnet-Daemon ist eines der häufigsten Angriffsziele, und da es mit der Secure Shell eine mehr als vollwertige Alternative gibt, kann es nur diesen einen Rat geben.

Angriffe werden hier meist direkt gegen Sicherheitslücken im Telnet-Daemon ausgeübt. Aber auch das Mithören eines Verbindungsaufbaus und/oder eine „Sitzungs-Entführung" (Session-Hijacking) sind ein ernstes Problem.

Wie bereits beim ftp-Protokoll werden hier nämlich sämtliche Daten im Klartext über das Netz übertragen. Dabei wird zwar jedes Zeichen der Benutzerkennung und des Passworts in einem einzelnen TCP-Paket übertragen, was einer entsprechenden Sniffer-Software aber keine Probleme bereitet _ die sind nämlich meist in der Lage, die Nutzlast einer TCP-Sitzung wieder zusammenzusetzen.

Der angreifende Rechner meldet sich nun unaufgefordert bei „Router" und „PC1" und teilt Ihnen jeweils mit, dass sich die MAC-Adresse geändert hat (z.B. im Fall einer neuen Netzwerkkarte wirklich relevant). Dabei erklärt der „Router", dass die MAC-Adresse von „PC2" angeblich „PC1" gehört. Dem Rechner „PC1" erklärt er, dass die MAC-Adresse von „PC2" angeblich „Router" gehört. Soll es noch weniger auffallen, verwendet er zwei unterschiedliche MAC-Adressen, die aber beide zu „PC2" gehören. Diesen Angriff kann man sich so vorstellen:

Sowohl „Router" als auch „PC1" führen nun einen Update Ihrer MAC-Tabellen durch und gehen damit einer Fehlinformation auf den Leim. „PC2" sendet seine gefälschten Updates zyklisch weiter, damit dieser Zustand auch so bleibt. In der Folge sendet „PC1" alle Pakete für „Router" an die Netzwerkkarte von „PC2". Dieser reicht, damit das Ganze nicht auffällt, das Paket an „Router2" weiter, wobei er es natürlich vorher aufzeichnet. Auch „Router" sendet alle Pakete an den vermeintlichen „PC1" (der aber in Wirklichkeit „PC2" ist). Auch diese Pakete werden nach Aufzeichnung an den eigentlich gewollten Empfänger weitergeleitet.

Damit hört „PC2" alles ab und „Router" und „PC1" bekommen es im Idealfall nicht mit.

Bei einem „Session-Hijacking" übernimmt die Person an der Konsole von „PC2" nach erfolgreicher Anmeldung des „Client" einfach die ganze Sitzung. Der „Client" bekommt nur mit, dass die Verbindung abgebrochen ist, macht sich meist keine allzu großen Sorgen, re-bootet seinen Rechner und baut erneut eine Sitzung auf.

Web-Services

Sind unter Linux üblicherweise für jeden Benutzer sofort verfügbar. In SuSE 8.0 wird allerdings der Apache-Server nicht mehr standardmäßig installiert. Der Apache-Webserver ist somit nachzuinstallieren, in die Runlevel 3 und 5 zu integrieren und zu starten.

Beim Anlegen von Benutzern wird zumindest bei der SuSE-Distribution sofort das Verzeichnis „public_html" im Homeverzeichnis der Benutzer angelegt. Dieses Verzeichnis kann dann unter Verwendung des Benutzer-Login-Namens als persönliche Homepage sofort angesprochen werden.

Beispiel:

• Benutzername ist „andreas"

• Homeverzeichnis ist „/home/andreas" oder allgemeiner „~/andreas"

• Das „public_html"-Verzeichnis liegt damit unter „/home/andreas/public_html".

• Die Startseite wird direkt in diesem Verzeichnis abgelegt /home/andreas/public_html/index.html

• Diese Startseite kann dann aus dem Web heraus über folgenden URL angesprochen werden: http://server/~andreas/ bzw. http://server/~andreas/index.html (der Dateiname „index.html" ist in der Apache-Software voreingestellt).

Weitere Literatur bzw. Software

• An introduction to ARP-Spoofing - 

• Ethereal 

• Windows Packet Capture Library

• The Apache Software Foundation

• PostgreSQL

• MySQL

1.2.2 Serverabsicherung durch den Einsatz des SSH-Protokolls

Bereits weiter oben konnten Sie sehen, dass viele Protokolle ihre Authentifizierungs- und nachfolgenden Sitzungsdaten im Klartext über das Netzwerk (LAN oder Internet) versenden. Dies ist ein erhebliches Sicherheitsrisiko. Es gibt zwischenzeitlich verschiedene Möglichkeiten, um den Datenverkehr zwischen Server und Client so zu verschlüsseln, dass ein reines „Mithören" sinnlos ist. „Session-Hijacking" bzw. „Man-in-the-Middle-Attacks" werden damit natürlich nicht verhindert.

Eine Möglichkeit für eine sicherere Kommunikation ist die „Secure Shell". Für den Endanwender unterscheidet sie sich nicht von dem bereits weiter oben erwähnten Dienst „telnet" und stellt nach erfolgreicher Anmeldung eine Shell zur Verfügung. Der Datenverkehr wird jedoch bereits vor dem Austausch sensibler Daten wie Benutzerkennung und Passwort verschlüsselt. Es kommen dabei sowohl asymmetrische wie auch symmetrische Verfahren zum Einsatz (siehe ONLINE-News Nr. 8).

Der nachfolgende Text stammt aus der Manual-Page des SSH-Serverdienstes. Er ist für die Anwendung der vorgestellten Software-Pakete nicht notwendig.

Nun beginnen Server und Client einen Authentifzierungs-Dialog. Üblicherweise wird hier die User-Password-Authentifizierung verwendet.

SSH-Protokoll 2

Version 2 arbeitet ähnlich. Auch hier hat der Server ein hostspezifisches Schlüsselpaar (RSA oder DSA), um den Server gegenüber Clients zu identifzieren. Allerdings wird im Gegensatz zur Protokoll-Version 1 kein zweites Schlüsselpaar beim Serverstart erstellt. Die weitere Sicherheit wird durch ein Diffie-Hellman-Key-Agreement geleistet.

Der Rest der Sitzung wird unter Verwendung eines symmetrischen Verfahrens verschlüsselt. Derzeit 128 bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 bit AES, oder 256 bit AES. Der Client wählt den zu verwendenden Algorithmus aus der vom Server angebotenen Auswahl aus. Die Sitzungs-Integrität wird zusätzlich durch einen kryptografischen Message-Authentifizierungs-Code zur Verfügung gestellt (hmac-sha1 oder hmac-md5).

Da PuTTY auch das normale Telnet-Protokoll beherrscht, bietet es sich generell als Ersatz für das bei Windows mitgelieferte Telnet-Programm an. Es unterstützt eine beliebige Anzahl an Zeilen und Spalten und übermittelt vor allem die Cursor-Steuerungstasten korrekt an den Server! Auch Farbdarstellungen nach ANSI werden unterstützt. Nach dem Start von PuTTY (eine Datei mit 324kB) erscheint der obige Konfigurationsdialog. Damit kann eine Vielzahl von Verbindungsparametern eingestellt werden und anschließend als „Session-Profil" abgespeichert werden. Für den Verbindungsaufbau reicht dann ein Doppelklick auf eine gespeicherte Session. Der eigentliche Anmeldevorgang und das spätere Arbeiten mit SSH unterscheidet sich nicht von der klassischen Telnet-Sitzung. Der Datenverkehr wird allerdings vollständig verschlüsselt. Der nachfolgende Mitschnitt gehört zu obiger SSH-Sitzung. Man kann nur noch den Aufbau der Verschlüsselung zwischen den beiden Kommunikationspartner sehen, alles Weitere ist unlesbar chiffriert.

Shellzugriff verwendet werden _ z.B. Secure FTP (sftp), Secure Copy (scp), Tunneling einer Sitzung mit einer grafischen Oberfläche (wie X11), ... .

Secure FTP _ SFTP

sftp nutzt einen verschlüsselten Übertragungskanal, der durch den oben beschriebenen SSH-Mechanismus zur Verfügung gestellt wird. Nach erfolgreicher Anmeldung stehen die meisten der bereits vom normalen ftp bekannten Kommandos zur Verfügung.

Eine mögliche Client-Software stammt erneut von Simon Tatham (siehe PuTTY) und läuft in einer DOS-Shell.

Komfortablere sftp-Software mit grafischer Oberfläche unter Windows konnte nicht gefunden werden. Dies ist aber angesichts des für scp verfügbaren Windows-Clients nicht weiter schlimm. Secure Copy _ SCP scp ist ein weiteres Verfahren, um auf Basis eines SSH-Kanals Dateien zwischen zwei Rechnern über das Netzwerk zu übertragen. Eine sehr komfortable Software ist hier WinSCP von Martin Prikryl .

Nach kurzer Konfiguration und erfolgreichem Verbindungsaufbau steht bei WinSCP eine komfortable Oberfläche zur Verfügung. Drag-and-drop erleichtert den Transfer von Dateien.

Literatur bzw. beschriebene Software

An introduction to SSH Secure Shell

OpenSSH on Windows

Shaolin Secure ftp

Liste von Windows SSH-Server und _Client Tools

SecPanel _ Grafische SSH- und SCP-Oberfläche

PuTTY, PSCP, PSFTP von Simon Tatham

1.2.3 sshd - OpenSSH SSH daemon

Beschreibung

Der sshd (SSH Daemon) ist das Serverprogramm zum Betrieb von ssh (Secure Shell) als Client. Zusammen ersetzen der Daemon und der Client Programme wie „rlogin" oder „rsh" und erlauben eine verschlüsselte Kommunikation zwischen zwei Rechnern über ein unsicheres Netzwerk. Trotz der darunter verborgenen Komplexität ist ein möglichst einfacher und für den Benutzer transparenter Betrieb möglich.

Der sshd ist der Serverdienst, der auf eingehende Verbindugswünsche von Clients wartet. Er wird üblicherweise bereits im Verlauf des Bootvorgangs gestartet. Bei eingehenden Verbindungen regelt dieser Serverdienst (bzw. ein erzeugter Sohnprozess) den Schlüsselaustausch, die eigentliche Verschlüsselung, die Ausführung von Kommandos und den Datenaustausch. Die heute üblichen sshd's unterstützen normalerweise gleichzeitig das SSH-Protokoll der Version 1 und 2.

SSH-Protokoll 1

Jeder Server hat ein RSA-Schlüsselpaar (üblicherweise 1024 Bit Länge), das dazu dient, den Server zu identifizieren. Dieses Schlüsselpaar, der „Host-Key", wird einmal erzeugt und dient zur fortlaufenden Identifikation des Servers gegenüber einem Client. Zusätzlich wird beim Start des Serverdienstes ein weiteres RSA-Schlüsselpaar (dieses Mal üblicherweise mit einer Schlüssellänge von 768 Bits) generiert. Dieses zweite Schlüsselpaar wird im Betrieb jede Stunde neu berechnet und nie auf einem Datenträger gespeichert. Es wird für die fortlaufende Arbeit des SSH-Servers benötigt und könnte wohl am Besten mit der Bezeichnung Server-Arbeits-Schlüssel bezeichnet werden.

Sobald ein Client eine Verbindung zum Server aufbaut, antwortet der SSH-Server, indem er den Public-Key der beiden Schlüsselpaare (also des Host-Key und des Server-Key) an den Client übermittelt. Der Client kann nun, falls er schon einmal eine Verbindung mit diesem Server hatte, überprüfen, ob er tatsächlich wieder den gleichen Server vor sich hat wie beim letzten Mal. Dazu vergleicht er den erhaltenen Public-Host-Key mit einer eigenen Datenbank, in der er bekannte Server-Host-Keys speichert. Ist an dieser Stelle alles in Ordnung, erzeugt der Client eine Zufallszahl mit 256 Bit Länge. Er verschlüsselt diese Zufallszahl sowohl mit dem Server-Host-Key wie auch mit dem Arbeitsschlüssel des Servers und sendet das Ergebnis an den Server zurück. Dieser ist im Besitz der passenden Secret-Key und kann somit die 256-Bit Zahl wieder dechiffrieren. Im weiteren Verlauf der Kommunikation verwenden die beiden Kommunikationspartner diese Zufallszahl als Sitzungsschlüssel für eine konventionelle symmetrische Verschlüsselung. Derzeit kommen hier der Blowfish- oder 3DES-Algorithmus zum Einsatz, wobei 3DES die Standardeinstellung ist. Welches der vom Server angebotenen konventionellen Verfahren verwendet wird, entscheidet der Client.

Nun beginnen Server und Client einen Authentifzierungs-Dialog. Üblicherweise wird hier die User-Password-Authentifizierung verwendet.

SSH-Protokoll 2

Version 2 arbeitet ähnlich. Auch hier hat der Server ein hostspezifisches Schlüsselpaar (RSA oder DSA), um den Server gegenüber Clients zu identifzieren. Allerdings wird kein zweites Schlüsselpaar beim Serverstart erstellt. Die weitere Sicherheit wird durch ein Diffie-Hellman-Key-Agreement geleistet.

Der Rest der Sitzung wird unter Verwendung eines symmetrischen Verfahrens verschlüsselt. Derzeit 128 bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 bit AES, oder 256 bit AES. Der Client wählt den zu verwendenden Algorithmus aus der vom Server angebotenen Auswahl aus. Die Sitzungs-Integrität wird zusätzlich durch einen kryptografischen Message-Authentifizierungs-Code zur Verfügung gestellt (hmac-sha1 oder hmac-md5).