Die Secure Shell nutzt ihr Protokoll nicht nur für eigene Dienste, sie leitet auch beliebige andere TCP-Verbindungen durch einen sicheren Tunnel. Damit SSH tatsächlich sicher ist, müssen die Schlüssellänge und die Softwareversion stimmen – im Zusammenspiel mit Firewalls ist auch einiges zu beachten.

Die Secure Shell SSH trägt das Attribut sicher schon im Namen, und zwar durchaus zu Recht. Viele ihrer Security-Dienste hat bereits der erste Teil dieses Beitrags [1] vorgestellt. Zu den interessanten Features zählt das Tunneln beliebiger TCP-Protokolle, das im Folgenden näher beschrieben wird.

Vorher sei aber die Warnung aus dem ersten Teil bekräftigt: Das SSH-Paket ist nur sicher, wenn eine aktuelle Softwareversion zum Einsatz kommt, in OpenSSH wurden wiederholt Sicherheitslücken entdeckt. Die Entwickler haben jede zwar sehr rasch behoben [http://www.openssh.com/security.html], veraltete SSH-Server sind aber weiterhin ein Sicherheitsrisiko.

Bei der Suche nach alten SSH-Servern hilft das Tool »scanssh« [2]. Es untersucht einzelne Hosts oder ganze Subnetze, ob dort SSH-Server laufen, und gibt jeweils an, um welche Version es sich handelt. Beim Aufruf ist einfach die IP-Adresse mit der Subnetzmaske als Argument zu übergeben, für einen einzelnen Host sieht das wie folgt aus:

scanssh 192.168.10.3/32

Ein Beispiel für ein ganzes Subnetz zeigt Abbildung 1, in der Ausgabe ist die Versionsnummer der installierten Server zu sehen. In Abbildung 2 untersucht Scanssh einzelne Rechner und zeigt, dass OpenSSH und Ssh.com die eigene Software auf ihren Webservern einsetzen. Scanssh setzt keine Root-Rechte voraus; negativ fällt lediglich auf, dass es nicht mit Host- oder Domain-Namen arbeiten kann und dass es bislang nur SSH-Server findet, die auf Port 22 lauschen.

Abbildung 1: Das Hilfsprogramm Scanssh durchsucht das Subnetz 129.168.10.0/24 nach SSH-Servern und gibt jeweils die exakte Version aus.

Abbildung 2: Scanssh untersucht in diesem Beispiel, welche SSH-Versionen das OpenSSH-Projekt und die Firma SSH Communications Security auf ihren eigenen Webservern einsetzen.

Wie lang soll ein RSA-Schlüssel sein?

Beim Thema Sicherheit von SSH- und anderen Kryptographie-Programmen gab es Mitte März dieses Jahres einige Aufregung, die zur Abwechslung mal nicht von Software-Sicherheitslücken herrührt. Angeblich ist es inzwischen möglich, mit einem überschaubaren Zeit- und Geld-Bedarf RSA-Keys von 1024 Bit Länge zu entschlüsseln. Konkret ging es hier um PGP-Schlüssel, das Problem trifft aber auch auf SSH zu.

Dan Bernstein, Autor des Qmail-Mailservers, hatte im Herbst 2001 seine Forschungen über einen spezialisierten Parallelrechner veröffentlicht, der zum Faktorisieren von Ganzzahlen dient [3]. Daraufhin wurde auf der Bugtraq-Mailliste diskutiert, ob man nun alle 1024-Bit-PGP-Schlüssel zurückrufen müsse.

Krypto-Experte Bruce Schneier hat zu dieser Unruhe einige klärende Worte beigetragen ( [4], [5]). Bis zum Jahr 2005 sind seiner Meinung nach folgende Schlüssellängen ausreichend sicher:

• Privatpersonen: 1280 Bit
• Firmen: 1536 Bit
• Regierung: 2048 Bit

Längere RSA-Keys sind laut Schneier nur Zeitverschwendung. Wer diesem Rat folgen möchte, bislang für SSH jedoch nur einen per Voreinstellung generierten RSA-Schlüssel mit 1024 Bit verwendet, sollte lieber auf einen neuen umsteigen. Folgendes Kommando erzeugt einen neuen RSA-Schlüssel für die Protokollversion 2:

ssh-keygen -b 1280 -t rsa -f ~/keyneu/id_rsa -C "1280-Bit-Key fuer Webmaster"

Das RSA-Schlüsselpaar (»id_rsa« und »id_rsa.pub«) mit der Schlüssellänge 1280 Bit landet dann im Verzeichnis »~/keyneu/«. Die explizite Angabe des Zielverzeichnisses mit der Option »-f« verhindert, dass das Kommando vorhandene Schlüssel in »~/.ssh/« überschreibt. Die Option »-C« ergänzt den Public Key noch mit einem Kommentar, Er dient nur der besseren Unterscheidbarkeit und hat keine Auswirkung auf die Funktion.

Tunnelbau: Umgeleitete TCP-Ports

Neben ihrer ursprünglichen Aufgabe, einen sicheren Remote Login zu ermöglichen, kann die SSH auch fast beliebige andere Protokolle absichern: Durch Port Forwarding kann sie TCP-Ports durch die sichere SSH-Verbindung umleiten. Dabei tritt SSH ähnlich wie ein Proxy auf, der auf der einen Seite des SSH-Kanals die Verbindung entgegennimmt und sie auf der anderen Seite mit dem jeweiligen Server verbindet.

Dabei kennt SSH zwei unterschiedliche Varianten: Local Port Forwarding und Remote Port Forwarding. In den meisten Fällen ist Local Port Forwarding die passende Lösung. Es leitet eine Verbindung, die auf einem lokalen (Client-seitigen) Port eintrifft, durch den sicheren SSH-Kanal auf einen Port auf einem entfernten Server weiter. Man kann dieses Verfahren daher auch als ausgehenden Tunnel bezeichnen. Die Syntax dieses Kommandos ist recht einfach:

ssh login@remote_host -L local_port:remote_host:remote_port

Das Forwarding lässt sich beispielsweise dafür nutzen, eine POP3-Verbindung zur eigenen Mailbox abzusichern – der erste Teil zu OpenSSH [1] hatte POP3 ja bereits als potenzielle Gefahr ausgemacht. Der POP-Client überträgt das POP-Passwort schließlich im Klartext an den Server, auf dem Weg dahin ist es einfach abzuhören. Wer das verhindern will, auch wenn der Provider kein POP-SSL anbietet, kann die POP3-Verbindung durch SSH tunneln:

ssh kh@pop.remote.com -C -L 25025:pop.remote.com:110

Ein verwegenes »telnet localhost 25025« zeigt nun die Bannermeldung des entfernten POP3-Servers. Es funktioniert, ohne Root zu bemühen. Nun muss nur noch der POP-Client auf Localhost und Port 25025 eingestellt werden, um regulär seine Mail zu empfangen.

Den genauen Ablauf veranschaulicht Abbildung 4: Das SSH-Kommando baut eine normale SSH-Verbindung zum Server »pop.remote.com« auf und legt dabei zusätzlich den Tunnel an. So lange ein Login besteht, ist auch diese Weiterleitung aktiv. Verbindet sich nun ein POP3-Client (oder ein Telnet-Kommando) mit Port 25025 auf dem Client (Localhost), nimmt der SSH-Client diese Verbindung entgegen. Auf Server-Seite baut SSH die Verbindung zu Port 110 auf und leitet alle Daten weiter.

Mit einer ähnlichen Weiterleitung lässt sich die Verbindung zu Webmin absichern (siehe Kasten “Webmin konfiguriert SSH-Server”):

ssh kh@admin.remote.com -C 
   -L 33337:admin.remote.com:10000

Daraufhin kann ein Browser den Webmin-Server durch den Tunnel kontaktieren: »https://localhost:33337/«.

Nach diesem Prinzip lassen sich viele TCP-basierte Dienste – zum Beispiel SMTP, IMAP, LDAP oder NNTP, nicht aber FTP – umleiten und tunneln. Das Problem bei FTP wird in [7] näher erläutert: Dieses Pro- tokoll nutzt neben der Kontrollverbin- dung noch zusätzlich eine Datenverbindung, deren Ports es innerhalb der Kontrollverbindung aushandelt. Damit ist es zwar leicht, den Kontrollkanal abzusichern, die Datenverbindung bleibt aber unverschlüsselt. SSH bietet dafür mit »scp« und »sftp« geeigneten Ersatz.

Abbildung 3: Das Web-basierte Administrationsprogramm Webmin bietet ein eigenes Modul an, um SSH-Server bequem zu konfigurieren. Es gibt aber einiges zu bedenken (siehe Kasten).

Abbildung 4: Beim lokalen Forwarding leitet SSH eine Verbindung, die beispielsweise auf Port 25025 des Client-Rechners ankommt, durch den Tunnel weiter zum Server. Dort endet sie auf Port 110.

Abbildung 5: SSH kann TCP-Verbindungen auch zu einem Server weiterleiten, der auf einem anderen Rechner als der SSH-Daemon läuft. Die Verbindung zwischen »ssh.remote.com« und »pop.remote.com« ist dabei nicht geschützt.

Forwarding für beliebige Hosts

Beim bis hierher geschilderten Forwarding waren auf beiden beteiligten Hosts Anwendungs-Client und -Server zu finden und sie waren gleichzeitig die Endpunkte der SSH-Verbindung. Jedes der beteiligten Programme kann aber auch auf einem eigenen Rechner laufen: Applikations-Client, SSH-Client, SSH-Server und Applikations-Server. Es können also bis zu vier Hosts bei einem einzigen Forwarding im Spiel sein.

Durch dieses Off Host Forwarding lassen sich ungewöhnliche Netzverbindungen und SSH-Tunnel herstellen, jedoch ist der praktische Einsatz aus Sicherheitsgründen gut zu überlegen. Zum einen ist immer nur die Verbindung zwischen SSH-Client und SSH-Server geschützt. Außerdem kann ein Angreifer, der Zugang zu dem lokalen Port hat, aber nicht zum Zielport auf dem Server, durch den Tunnel auf einen für ihn gesperrten Dienst zugreifen. Um diese Gefahr zu entschärfen, sind bei OpenSSH per Default nur Verbindungen vom lokalen Rechner aus zum weitergeleiteten Port möglich. Mit dem Schalter »-g« lässt sich dies aber ändern.

Ein in der Praxis sinnvoller Fall für das Off-Host-Forwarding ist die Verbindung zu einem Server, auf dem der User selbst keinen SSH-Login besitzt. Er benötigt dann in der Nähe dieses Servers einen SSH-Server, dessen Verbindung zum POP3-Server als sicher gilt. Das könnte etwa der Fall sein, wenn beide Server in einem geschützten Netz hinter einer Firewall stehen, der User aber eine Verbindung von außen aufbaut:

ssh kh@ssh.remote.com -C -L 25025:pop.remote.com:110

Die Weiterleitung ist in Abbildung 5 dargestellt: Der SSH-Tunnel befindet sich zwischen dem Client und »ssh.remote.com«. Der Mail-Client nimmt Kontakt zum lokalen Port 25025 auf. Diese Verbindung nimmt der SSH-Client entgegen, der SSH-Server baut darauf das Gegenstück zwischen »ssh.remote.com« und »pop.remote.com« auf Port 110 auf. Nur die Verbindung zwischen Client und SSH-Server ist verschlüsselt, zwischen SSH-Server und POP3-Server ist eine gewöhnliche TCP-Verbindung aktiv. Aus Sicht des POP3-Servers stammt die Verbindung von »ssh.remote.com«.

Umgekehrtes Forwarding

Remote Port Forwarding funktioniert genau anders herum als Local Port Forwarding: Die Verbindung kommt an einem Port auf dem Host an, auf dem der SSH-Server läuft. Das Forwarding leitet die Daten dann durch den SSH-Kanal weiter zur Client-Seite und dort an einen beliebigen Port. Es könnte damit auch eingehender Tunnel heißen. Die Syntax ist:

ssh login@remote -R remote_port:local_host:local_port

Um festzustellen, wann welche Art des Port Forwarding sinnvoll ist, muss man das Szenario nur aus Sicht der TCP-Client-Anwendung betrachten. Läuft die TCP-Client-Anwendung lokal auf der SSH-Client-Maschine, dann ist lokales Forwarding die richtige Wahl. Läuft sie stattdessen auf einer entfernten SSH-Server-Maschine, dann ist Remote Port Forwarding richtig.

Nicht immer alle Ports

Die Default-Konfiguration von OpenSSH erlaubt das TCP-Forwarding. Dabei stehen alle freien Ports lokal und remote ab Port 1024 zur Verfügung, Root darf lokal auch darunter liegende, privilegierte Ports weiterleiten.

Auch ohne Unterstützung durch SSH könnte ein User mit einem vollwertigen (SSH-)Login dasselbe Ziel erreichen, etwa mit Hilfe von Netcat (»nc«). Dazu müsste er einen Netcat-Server und einen Netcat-Client über eine SSH-Shell-Pipe verbindet. Die Direktive »AllowTcpForwarding no« in der Serverkonfiguration »sshd_config« ist aus diesem Grund nur bedingt wirksam.

Durch die Firewall

Ein interessante Aufgabe für TCP-Forwarding ist es, Protokolle transparent durch eine Firewall hindurch zu tunneln, falls sie SSH erlaubt. Beispielsweise könnte ein Heimarbeiter Daten benötigen, die sich auf einem Intranet-Webserver befinden, der aber nur innerhalb des Firmen-LAN erreichbar ist. Eine Firewall verhindert den Zugriff von außen, lässt aber SSH-Logins auf das Gateway zu. Beteiligt sind folgende Rechner:

• Heimarbeitsplatz »ha«
• Firmenarbeitsplatz »fa«
• Gateway »gw«
• Interner Webserver »ws«

Auf dem Heim-Rechner ruft der Mitarbeiter folgendes Kommando auf:

ssh gw_login@gw -L 2001:ws:80

Dabei öffnet er eine SSH-Session zu »gw«, gleichzeitig leitet er den lokalen Port 2001 auf den TCP-Port 80 (HTTP) des firmeninternen Webservers »ws« durch den SSH-Kanal um. Vorausgesetzt ist, dass auf dem lokalen Port 2001 nicht bereits ein anderer Dienst aktiv ist. Nun ist der LAN-Webserver unter der URL »http://localhost:2001« vom Heimarbeitsplatz aus erreichbar.

Ungefährlich ist diese Variante nicht: Jeder User, der auf »ha« eingeloggt ist, kann den offenen Port nutzen, solange die Tunnel-Session mit »gw« besteht. Hat der Benutzer zusätzlich die Option »-g« angegeben, dann ist der Port 2001 auf »ha« sogar von anderen Rechnern aus erreichbar. Wer als Admin seinen Benutzern nicht vertrauen will (oder kann), sollte hier also vorsichtig sein, sonst ist seine Firewall schnell durchlöchert. SSH die Schuld daran zu geben, wäre aber falsch: Jede Verbindung durch die Firewall kann dazu missbraucht werden, andere Protokolle zu tunneln.

SSH-in-SSH-Verbindung

Der Beispiel-Heimarbeiter könnte nun den Wunsch haben, sich von seinem Arbeitsplatz zu Hause direkt auf seinem Arbeitsrechner in der Firma einzuloggen. Eine elegante und sichere Lösung dafür ist eine SSH-Verbindung durch einen SSH-Tunnel:

ssh gw_login@gw -L 2002:fa:22
ssh fa_login@localhost -p 2002

Das erste Kommando baut einen Tunnel vom lokalen Port 2002 zum Gateway »gw« auf, der mit dem SSH-Port 22 auf »fa« verbunden ist. Das zweite Kommando nutzt diesen Tunnel, in dem es sich mit Localhost auf Port 2002 (Option »-p«) verbindet – es entsteht also eine SSH-in-SSH-Verbindung.

Alternativ dazu könnte sich der Heimarbeiter auch auf »gw« einloggen und von dort aus weiter auf »fa«. Bei dieser Lösung müsste er auf dem Gateway seinen SSH-Key ablegen, Agenten-Forwarding aktivieren oder ein herkömmliches Passwort nutzen. Beim SSH-in-SSH-Verfahren ist dies nicht nötig, das Gateway hat auch keinen Zugriff auf die übertragenen Daten: »ha« ist durch den Tunnel direkt mit »fa« verbunden. Dabei ist der Account auf »fa« anzugeben.

Für die Tunnelverbindung ist es übrigens egal, ob auf dem Weg in die Firma und zurück NAT (Network Address Translation) stattfindet, auch mehrfaches NAT stört nicht.

Hintertür ins interne Netz

Ein weiteres Beispiel scheint schwieriger zu sein: Der Angestellte hat kein Login auf dem Gateway, die Firewall verhindert eine Verbindung ins interne Netz. In diesem Fall kann er sich aber durch Remote Port Forwarding eine Hintertür ins Firmennetz schaffen. Der Heimrechner muss dazu ins Internet eingewählt sein und von außen SSH-Logins akzeptieren. Die externe IP des Heimrechners muss der Angestellte kennen, mit Hilfe von Diensten wie DynDNS ist das auch bei dynamischen IP-Adressen kein Problem. Auf dem Arbeitsplatzrechner in der Firma gibt der User dann folgendes Kommando ein:

ssh ha_login@ha -R 2003:fa:22

Diesen Login beendet er nicht wieder, er lässt den Tunnel (siehe Abbildung 6) damit offen. Zu Hause kann er sich durch diesen Tunnel auf seinen Arbeitsplatz in der Firma einloggen:

ssh fa_login@localhost -p 2003

Wenn das Firmengateway, aus welchem Grund auch immer, keine SSH-Verbindungen nach außen erlaubt, lässt der Heimarbeiter seinen SSH-Server einfach auf einem erlaubten Port lauschen; Port 80 ist hier sehr viel versprechend.

Damit zeigt sich wieder, wie einfach ein Benutzer die eigene Firewall durchlöchern kann, wenn er es darauf anlegt: Sobald ein beliebiger Port offen ist, kann er einen Tunnel durch ihn hindurch öffnen. Freilich verstößt er damit in aller Regel gegen die Arbeitsbestimmungen; wer seinen Job nicht riskieren will, sollte mit diesen Weiterleitungen also sehr vorsichtig sein und im Zweifel Rat beim Admin einholen.

Zusammen mit Port Forwarding können die beiden Option »-N« und »-f« hilfreich sein: »-N« sorgt dafür, dass SSH auf Server-Seite keine Kommandos ausführt, sondern nur die gewünschten Ports weiterleitet. »-f« legt den SSH-Client in den Hintergrund, sobald die Authentifizierung beendet ist. Der Benutzer kann vorher noch sein Passwort oder seine Passphrase eingeben.

Sonderfall X11

SSH kennt noch eine Sonderform der Port-Umleitung: X11-Forwarding. X11 benutzt ein Netzwerkprotokoll; selbst wenn der Monitor die grafischen Ausgaben von Programmen anzeigt, die auf dem zugehörigen Rechner laufen, findet eine Datenübertragung zwischen Client und Server statt. Der X11-Server ist dabei für die Anzeige auf dem Bildschirm zuständig, er liest auch die Eingaben von Tastatur und Maus. X11-Clients sind Programme, die ihre Ein- und Ausgabe über X11 erledigen.

Ein X11-Server lauscht meist auf Port 6000; hat ein Rechner mehrere Bildschirme, Tastaturen und Mäuse, dann nutzen die weiteren X11-Server die nächsthöheren Ports ab 6001. Auf welchem Server ein Client-Programm seine Oberfläche darstellen soll, teilt ihm die Umgebungs-Variable »$DISPLAY« mit. Wer Zugriff auf einen X11-Server hat, kann die Fenster eines X11-Clients dort anzeigen lassen, er kann aber auch unerkannt einen Screenshot machen oder die Tastatur-Events abhören. Ohne weitere Schutzmaßnahmen wäre X11 also ein sicherheitstechnischer Alptraum.

Ganz so schlimm ist es aber nicht, X11 benutzt ein eigenes Authentifizierungsverfahren. Am häufigsten kommen die MIT Magic Cookies zum Einsatz. Wegen dieser Authentifizierung ist Port-Forwarding allein für X11 nicht ausreichend. Um die grafische Ausgabe eines Programms dennoch von einem entfernten Rechner auf das lokale Display umzuleiten, bietet SSH einen eigenen Mechanismus an. Der sorgt für die X11-Authentifizierung, setzt beim Login die Variable »$DISPLAY« passend und leitet die Verbindung durch den Tunnel.

Dazu müssen mehrere Voraussetzungen erfüllt sein. Die Konfiguration des entfernten SSH-Servers »sshd_config« muss »X11Forwarding yes« und eine Direktive der Art »X11DisplayOffset 10« enthalten. Auf der Seite des SSH-Clients müssen ein X11-Server laufen und das X11-Forwarding ebenfalls aktiviert sein, etwa durch die SSH-Option »-X« oder durch »ForwardX11 yes« in »/etc/ssh/ssh_config« oder in »~/.ssh/config«.

Eine Falle droht noch von den Profil-Dateien (beispielsweise »~/.profile« oder »~/.bashrc«) auf dem entfernten Rechner: Manche dieser Skripte versuchen, »$DISPLAY« selbst zu setzen, und kümmern sich dabei nicht um SSH. Sie überschreiben unter Umständen die korrekte Einstellung – das hat durchaus schon zu Überraschungen geführt, wenn trotz SSH und X11-Forwarding der X11-Client direkt mit dem X11-Server spricht und den Tunnel einfach umgeht.

Sind die Voraussetzungen für X11-Forwarding erfüllt, kann jedes beliebige X11-Programm auf dem entfernten Rechner gestartet werden, der SSH-Tunnel lenkt die Anzeige auf das lokale Display um. Die Datenübertragung erfolgt dabei verschlüsselt. Auf diese Weise sind etwa SuSE-Server auch mit dem grafischen Yast 2 oder Mandrake-Rechner mit DrakConf durch einen SSH-Tunnel sicher von der Ferne aus administrierbar.

Firewall für SSH konfigurieren

Abbildung 6: Durch einen SSH-Tunnel lässt sich auch eine weitere SSH-Verbindung tunneln: Zunächst verbindet sich »fa« mit »ha« und öffnet per Reverse Port Forwarding einen Tunnel, durch den »ha« in der anderen Richtung eine weitere SSH-Verbindung zu »fa« herstellt.

Firewalls wurden bereits mehrfach erwähnt, wie ein Benutzer sie mit einem Tunnel untergraben kann ebenfalls. Trotzdem wird ein sicherheitsbewusster Admin seine Rechner nicht ohne Firewall ans Internet binden. Oft ist der Firewall-Rechner das Internet-Gateway für ein dahinter arbeitendes LAN auf Basis privater IP-Nummern (RFC 1918).

Die Aufgabe besteht nun darin, die Firewall so zu konfigurieren, dass ein Login per SSH auf den Firewall-Host möglich ist und dass von dort aus die Server in einer DMZ oder im LAN erreichbar sind. Listing 1 zeigt, wie sich dies mit dem Firewall-Subsystem der 2.4er-Linux-Kernel-Serie konfigurieren lässt; abgedruckt ist nur der relevante Ausschnitt aus einem Regelsatz von »iptables«-Aufrufen, das vollständige Beispiel ist auf unserem FTP-Server verfügbar [8].

Listing 1: SSH zur Firewall erlauben

01 # SSH-Port
02 export SSH="22"
03 [...]
04 # Drop-Policy
05 $IPTABLES -P INPUT DROP
06 $IPTABLES -P OUTPUT DROP
07 $IPTABLES -P FORWARD DROP
08 [...]
09 # Regelsatz für SSH-Zugang auf das Gateway
10 $IPTABLES -N ssh_gate
11 $IPTABLES -A INPUT -p tcp -m state --state NEW -d $EXT_IP --dport $SSH -j ssh_gate
12 # Gate soll SSH nach außen und ins LAN erlauben
13 $IPTABLES -A OUTPUT -p tcp -m state --state NEW --dport $SSH -j ssh_gate
14 $IPTABLES -A ssh_gate -j ACCEPT
15 [...]
16 $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Dieser Regelsatz arbeitet mit einer »DROP«-Policy für »INPUT«, »OUTPUT« und »FORWARD«. Per Default lässt der Kernel kein IP-Paket in den Rechner hinein oder heraus, auch leitet er nichts durch. Interfaces, IPs und Ports muss der Regelsatz ohne Ausnahme explizit benennen, getreu der Grundregel: Was nicht erlaubt ist, ist verboten. Bei dieser Policy-Einstellung erreicht man nicht einmal das Loopback-Device des Rechners, ohne es explizit zu erlauben.

Eine »INPUT«-Regel erlaubt SSH-Verbindungen über das externe Interface zum Gateway. Eine »OUTPUT«-Regel sorgt dafür, dass SSH-Logins über das Gateway als Zwischenstation hinweg auf einen Rechner im LAN oder in der DMZ möglich sind. Ein direkter Login von außen auf einen internen Rechner erlauben diese Regeln nicht.

Die letzte Zeile in Listing 1 sorgt dafür, dass der Kernel alle Pakete, die zu einer erlaubten Verbindung gehören, erkennt und ebenfalls zulässt. Über diese Statefullness (zu Deutsch etwa Zustandsabhängigkeit) im Netzwerk-Stack verfügt Linux erst seit der Generation 2.4.

Für eingehendere Informationen sei auf die verständlich kommentierten Iptables-Skripte von Alexander Stielau verwiesen [9] sowie auf »man iptables« und die Iptables-HOWTOs [10].