Implementierung einer sicheren IP-Verbindung ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hubert Feyrer, 7.1.1996 Irgendwann kurz nach dem Aufstehen ist mir heute die im Folgenden beschriebene Methode durch's IRC gescrollt, wie man eine sichere (d.h. verschluesselte) IP-Verbindung herstellen kann. Ich find's genial, und wollte es mal etwas naeher dokumentieren. Das IRC-Log ist bei mir erhaeltlich. * Erstmal alles wie gehabt: der IP-Stack jetzt ********************************************** Das folgende Schema beschreibt den IP-Stack, wie er momentan eigentlich ueberall fuer "normale" Anwendungen eingesetzt wird: +-------------------------------------------------+ | Div. Anwendungsprotokolle: FTP, WWW, NFS, etc. | +-------------------------------------------------+ | TCP, UDP | +-------------------------------------------------+ | IP | +------------------------+------------------------+ | PPP, SLIP | | +------------------------+ Ethernet | | V.24 (Modem) | | +------------------------+------------------------+ Den Zugriff auf die Hardware bewerkstelligt ein Ethernet-Treiber, bei einer seriellen Verbindung ueber V.24, wie sie z. B. auch ueber Modem gemacht wird, wird als weitere Protokollschicht noch SLIP oder PPP verwendet, um die IP-Paeckchen zu kapseln und (im Fall von PPP) einige Daten wie IP-Nummern der Rechner auf beiden Seiten auszuhandeln. Darauf aufbauend IP fuer Routing und TCP bzw. UDP fuer den Datentransfer. Darauf aufsetzend endlich die ganzen Anwendungsprotokolle. Soweit nichts neues, aber eben auch nicht verschluesselt. * Ein paar Moeglichkeiten der Datenverschluesselung ************************************************** Sicherlich die einfachste Art der Datenverschluesselung im aufgelisteten Protokoll-Stack ist es, einzelne Anwendungsprotokolle zu Verschluesseln, wie dies z. B. in der Diplomarbeit von Bretz & Bolle mit FTP gemacht wurde. Eine solche Loesung verlangt jedoch eine Anpassung fuer jede einzelne Anwendung. Eine aehnliche Loesungen sind Packete wie SSL (Secure Socket Layer), die zwar auf dem selben Anwendungscode aufsetzen, jedoch auch ein neues Binden mit den veraenderten Netzwerk-Bibliotheken erfordern. Eine allgemeinere Loesung ist das Software-Packet swIPe, das eine Verschluesselung auf IP-Ebene vornimmt, und so die vorhandenen Anwendungen unveraendert laesst. Der Nachteil von swIPe ist die Installation, die durch eine Kernel-Modifikation erfolgt und dadurch relativ stark an das verwendete Betriebssystem gebunden ist. Unterstuetzt werden BSD-basierende Systeme (SunOS, NetBSD, kein Solaris). * Eine robuste Alternative ************************** Nun zu einer anderen Loesung, die vollstaendig ohne Kernel-Modifikationen auskommt. Man betrachte sich den oben gezeichneten Protokollstapel nochmals (genauer gesagt, die Loesung mit PPP & der seriellen Leitung). Alles was diese serielle Leitung bietet ist eine sequentielle Uebertragung von jeweils einem einzigen Zeichen. Genau diesen Dienst kann man auch durch "etwas" anderes ersetzen, das ebenfalls eine Reihe von Zeichen 1:1 uebertraegt - z. B. ein rsh-Protokoll (das beim rlogin verwendet wird): +------------------------+ | FTP, WWW, NFS, etc. | +------------------------+ | TCP, UDP | +------------------------+ | IP | +------------------------+ | PPP | +------------------------| | rsh | +------------------------+ Voraussetzung dafuer ist eine aktuelle PPP-Implementierung, die auf rsh aufgesetzt werden kann. Da rsh ausserdem aus der Sicht des TCP/IP-Stacks eine Anwendung (oberste Schicht!) ist, ist fuer den Betrieb desselben wiederum ein vollstaendiger IP-Stack noetig, woraus sich dann folgendes Gebilde ergibt: +------------------------+ \ | FTP, WWW, NFS, etc. | \ +------------------------+ \ | TCP, UDP | \ +------------------------+ \ | IP | > "oberer" IP-Stack +------------------------+ / | PPP | / +------------------------| \ / | rsh | X +------------------------+ / \ | TCP | \ +------------------------+ \ | IP | > "unterer" IP-Stack +------------------------+ / | PPP | / +------------------------| / | V.24 | / +------------------------+ / Dieser Stapel laeuft auf den beiden zu verbindenden Rechnern, die durch den unteren Teil des Stapels ueber eine beliebige Verbindung (Ethernet, SLIP/PPP, X.25, etc.) kommunizieren koennen. Durch PPP begruendet kann diese Verbindung auch nur zwischen zwei Rechnern stehen, es werden ausserdem fuer den "oberen" Teil des Stapels andere IP-Nummern benoetigt als fuer den "unteren" Teil. Nachdem nun so eine virtuelle Punkt-zu-Punkt-Verbindung geschaffen ist, kann diese als naechstes sicher gestaltet werden. Dazu wird einfach ihre niedrigsten Schicht (die rsh-Verbindung) verschluesselt. Dies geschieht mit Hilfe des ssh (Secure Shell) Packates, das einen vollstaendigen Ersatz fuer rsh (u.a.) darstellt. Durch den letzten Punkt hat man innerhalb eines IP-basierenden Netzes (LAN oder WAN) eine sichere Punkt-zu-Punk-Verbindung. Die Installation dieser Verbindung muss nach wie vor durch den Systemverwalter durchgefuehrt werden, da nur dieser die noetigen PPP-Devices konfigurieren und das Routing fuer die PPP-Verbindung aufsetzen kann. Jedoch besteht die eingesetzte Software besteht aus zwei Userland-Prozessen (pppd und ssh), die ohne Kernel-Modifikationen auskommen und so wesentlich portabler sind. * Sonstiges *********** Die oben beschriebene Methode sollte so funktionieren, wurde aber nicht ausprobiert. Knackpunkt dabei ist der auf rsh (ssh) aufsetzende PPP-Daemon. Ein weiterer Punkte waere der Verbindungsaufbau, bei dem die Punkt-zu-Punkt-Verbindung (und damit die beiden IP-Nummern des oberen IP-Stapels) zugewiesen werden. Es soll an dieser Stelle nicht unerwaehnt bleiben, dass diese Idee von Theo de Raadt im IRC erwaehnt wurde. Er eroerterte zusammen mit Tim Newsham die Details. * Software ********** swIPe: ftp://ftp.cert.dfn.de/pub/tools/crypt/swipe/ pppd: ftp://cs.anu.edu.au/pub/software/ppp/ ssh: http://www.cs.hut.fi/ssh/ =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/943-2905 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ==========================================================================