Firewall Handbuch für LINUX 2.0 und 2.2: Aufbau der LINUX Firewall mit ipfwadm: Die Clients

9.13 Die Clients

Die Clients laufen gewöhnlich unter Windows 95/98/NT. Woher weiß man eigentlich bei Microsoft, welche Dienste welche Ports benutzen ? Mit Microsoft ist das so eine Sache, glücklicherweise findet man genau diese Dateien in C:\Windows\ alle wieder: protocol, services, und die Bindungen der Dienste an die Netzwerkkarten befinden sich in protocol.ini.

Es gibt aber auch ausnahmen, wie z.B. den Port 0 und die IP-Nummer 0.0.0.0. Obwohl nirgendwo definiert, verwendet Microsoft NT diese.

NOVELL hält sich mehr an die UNIX Konventionen. Alle Einstellungen, die mit dem Programm INETCNF an der Konsole vorgenommen werden, finden sich unter NOVELL auf dem Volume SYS wieder. Die Struktur entspricht genau der von UNIX. Entsprechend einfach lassen sich alle UNIX Programme auf NOVELL portieren. NOVELL nennt sie nur anders, beispielsweise ist der Dämon, mit dem man von NOVELL Daten nach Windows NT kopieren kann (Migration Toolkit) identisch mit SAMBA unter UNIX. SAMBA läuft übrigens auch unter NT :))

Zurück zu Protokollen und Diensten. Ein Beispiel:


# allow www (80)
ipfwadm -I -a accept -P tcp -W $EXTERNES_INTERFACE -S $ANYWHERE $UNPRIVPORTS -D $INTRA1 80

Es wird gerade einem Paket erlaubt, von ANYWHERE von einem Port > 1024 über das Protokoll TCP auf den Host INTRA1, Port 80 zuzugreifen. Die könnte einen WWW-Server mit der IP-Adresse INTRA1 hinter der Firewall sein. Wir können obigen UNIX Dateien entnehmen, daß HTTP auf Port 80 ansprechbar ist, und ein TCP Dienst ist. Die Angabe $UNPRIVPORTS dient dazu, festzulegen, daß ein Client sich nur unter Verwendung von Ports > 1024 an dem Server anmelden darf. Wenn wir diese Regel einführen, dann dürfte klar sein, daß Masquerading in der Firewall nicht verwendet werden darf. Masquerading schirmt IP - Nummern hinter der Firewall ab, und ersetzt diese durch ihre eigene. Mehr hierzu jedoch später. Warum sollte man Clients nicht erlauben, sich mit einer Portnummer < 1024 an dem Server anzumelden. Das hat zum Teil historische Gründe. Bei der Programmierung von BSD UNIX wurden definiert, daß alle Ports < 1024 privilegierte Ports sind, die ausschließlich den UNIX Dämonen vorbehalten sein sollen. Alle anderen Ports können entsprechend den Vorschlägen in den RFC´s genutzt werden. Diese findet man in jeder LINUX Distribution im Verzeichnis /usr/doc/rfc. Da TCP Verbindungen sich nach dem 3-Wege Handshake auf höhere Ports > 1024 verlagern, hat man dann also eine sauberere Trennung zwischen Anwenderprogrammen und UNIX Systemprogrammen bei der Nutzung der Ports. Ein Netscape Client, der sich von Port 3120 mit seiner IP - Nummer an Port 80 des Servers anmeldet und akzeptiert wird, wird vom Serverdämon auf einen höheren Port verlagert, beispielsweise 54123. Von nun an unterhalten sich Netscape und der WWW-Server zwischen Port 3120 und Port 54123 des Servers.

Auf diese Weise kann man mit netstat -a einfach nach normalem Traffic (Verkehr) zwischen Anwendungsprogrammen und wichtigem Verkehr zwischen UNIX Servern und Routern im Internet unterscheiden. Nebenher fallen dann Verbindungsversuche von Hackern oder Fehlkonfigurationen von Clients schneller auf. Viele der einfachen Angriffswerkzeuge, die man im Internet findet, benutzen als Quellcode privilegierte Ports. Wenn ein Angreifer mehr Ahnung hat, dann wird er die Quellcodes sicher anpassen, eine Sicherheitsgarantie ist die Aufteilung der Ports in privilegierte und unprivilegierte ohnehin nicht. Bei vielen UNIX Betriebsystemen und Microsoft - Programmen ist diese Regel ziemlich aufgeweicht worden. Firma Microsoft hat aber in Windows NT über die Registry eine Möglichkeit geschaffen, die Bereiche von verwendeten Ports einzelner Dienste einzuschränken oder zu verlagern. Damit ist es nun möglich, bestimmte Dienste (PDC) in bestimmte Portnummern zu verbannen und speziell zu überwachen. Da ein Angreifer die Portnummern nicht kennen kann, kann der Systemadministrator schnell feststellen, ob ein Angriff stattgefunden hat. Eine Ausnahme ist auch SSH, Secure SHell. SSH verlagert sich nicht auf unpriviligierte Ports, sondern verbleibt im Bereich zwischen 512 und 1024. SSH ist hervorragend geeignet, sichere point to point Verbindungen zwischen Hosts über das Internet aufbauen zu können. Es kann als Ersatz von VPN´s, z.B. PPTP eingesetzt werden. Insofern ist die Verwendung der privilegierten Ports kein Verstoß gegen die BSD - Konventionen.

Windows NT im besonderen erlaubt durch gezielte Manipulationen in der Registry eine Begrenzung von Ports auf einen bestimmten Bereich. Dies ist immer dann sinnvoll, wenn sich Bereiche häufig benutzter Ports einiger Dienste überschneiden. Einem Client Zugriff auf einen Server hinter einer Firewall zu geben, kann wegen möglichen buffer overflows tödlich sein. Wenn also eine solche Konstruktion erwogen wird, dann ist immer eine zweite Firewall mit einzuplanen, die eine weiteres Hindernis für einen Angreifer ist.

Betrachtet man nun den Zugriff aus dem Intranet auf Server im Internet:


# Erlaube WWW
ipfwadm -I -a accept -P tcp -k -W $EXTERNES_INTERFACE \
                -S $ANYWHERE 80 -D $INTRANET $UNPRIVPORTS

Es wird hier ein besonderes Zeichen \ verwendet, auch META Zeichen oder Fluchtsymbol genannt. Es soll dafür sorgen, daß das direkt darauffolgende ASCII Zeichen ignoriert wird. Welches ? Das ist bei Editoren meist nicht sichtbar - Es ist das RETURN oder NEWLINE Zeichen. Hiermit werden lange Zeilen umgebrochen, ohne daß die Shell bei der Abarbeitung der Regeln in Schwierigkeiten mit der Interpretation der Zeichen gerät.

Es wird hier das Senden eines TCP Paketes aus dem Internet von Port 80 den Zugriff auf einen Client innerhalb unseres Netzwerkes zugelassen, der Ports oberhalb von 1024 benutzt, z.B. Netscape.

Das "-k" hat eine sehr wichtige Bedeutung. Es bedeutet, daß alle Pakete das ACK Bit gesetzt haben müssen, andern falls werden diese abgewiesen.

Nochmals zur Erinnerung: Beim Verbindungsaufbau mit SYN-Bit, danach werden alle Pakete nur noch mit gesetztem ACK Bit ausgetauscht. Im Grunde bedeutet dies, daß zwar Pakete aus dem Internet in unser Intranet akzeptiert werden, aber keinen Verbindungsaufbau aus dem Internet zu einem der Hosts im Intranet möglich ist. Eine genaue Liste von Protokollen, Ports und Regeln findet sich im Anhang über Firewallregeln

Pakete mit ACK Bit werden also nur dann akzeptiert, wenn ein SYN Paket aus dem Intranet zu dem Host im Internet übertragen wurde. Die Firewall merkt sich diese Adresse und erlaubt dann den Partnern, weiterhin Pakete untereinander auszutauschen. Kurz gesagt, die Firewall öffnet die Ports nur dann, wenn jemand aus dem Intranet surfen möchte. Genau das war das Ziel.

Nun werden noch Regeln für Browser hinzugefügt:


# Erlaube HTTPS und PROXY 
ipfwadm -I -a accept -P tcp -k -W $EXTERNES_INTERFACE \
                   -S $ANYWHERE 443 8080 3128\
                   -D $INTRANET $UNPRIVPORTS

Hier wird die Übertragung von Ports 443 und 8080 aus dem Internet zu einem Client im Intranet zugelassen. Auch hier muß die Verbindung von innen initiiert worden sein. (-k)

Die Schreibweise ist nun so, daß mehrere Ports hintereinander angeben werden können, das IPFWADM Toolkit interpretiert dieses korrekt. Ports 443 werden für die sichere Übertragung von Daten über das Internet verwendet (Der Schlüssel links unten im Browser schließt sich), was aber nicht bedeutet, daß die Daten, z.B. Kreditkartennummern am Zielort auch sicher aufgehoben sind. Port 8080 und 3128 sind gebräuchliche Ports für HTTP-PROXY-CACHES, die viele Seiten aus dem Internet zwischen gespeichert haben, und somit für eine beschleunigte Übertragung sorgen. Wer z.B. mit ISDN surft, sollte nur über Profis surfen. Es verhindert Angriffe auf den TCP/IP Stack von Microsoft Betriebssystemen. Außerdem geht es schneller und der Provider spart Kosten ein. Bei der Angabe des Proxies im Browser sollte man es einmal mit proxy.provider.de, auf den beiden oben erwähnten Ports versuchen.

Wir haben nun einige Ports betrachtet. UNIX verfügt aber über ein unglaubliche Zahl von Diensten, sodaß man wirklich alle abschalten sollte, von denen man nicht definitiv weiß, ob sie bei falscher Konfiguration ein Sicherheitsproblem darstellen. Allgemein sollte man sich an der UNIX Computer Security Checklist von AUSCERT oder dem DFN-Verein in Hamburg orientieren. Diese ist zwar etwas veraltet, das ist aber UNIX auch im Prinzip, auch wenn einige Benutzeroberflächen sehr modern aussehen. Das Grundprinzip bei UNIX ist seit den 70er Jahren nicht mehr verändert worden. Eine große Hilfe ist das Grundschutzhandbuch des BSI (http://www.bsi.bund.de) sein.

Um jedoch eine sichere Firewall aufzubauen, sei jedermann/frau dringenst geraten, so konservativ, wie möglich mit der Freigabe von Ports auf der Firewall zu verfahren. Dasselbe gilt insbesondere für Dienste auf der Firewall selber. In der Vergangenheit haben unzählige Einbrüche über Dämonen, wie z.B. sendmail, pop3, http...gezeigt, daß ein Angreifer über trojanische Pferde auf den Arbeitsstationen auch die Firewall selber angreifen kann.

Online Suche im Handbuch

LITTLE-IDIOT NETWORKING