Firewall Handbuch für LINUX 2.0 und 2.2: Aufbau der LINUX Firewall mit ipfwadm: Die Dienste auf einer Firewall

9.16 Die Dienste auf einer Firewall

Die Firewall soll auch von innen jedem Angreifer möglichst wenig Angriffsfläche bieten. in der Datei /etc/inetd.conf sollten möglichst keine Dienste mehr laufen. Im Grunde sollte man auch den inetd selber abschalten, da auch er Ziel von DoS Angriffen werden kann. Einzelne Dämomen kann man immer auch ohne den inetd starten, nebenher gesagt. Es werden dann keine Dämonen mehr gestartet, wenn Pakete an einem bestimmten Port eintreffen. Dies ist die sicherste Einstellung. Da aber immer irgend jemand irgendeinen Dienst nutzen möchte, evtl. zur Fernwartung, so ist es notwendig, trotzdem einige Probleme bei der Aktivierung der Dienste zu erläutern.

Nach außen hin ist es immer kritisch, irgendeinen Dienst freizugeben. Das hat der Betreiber der Site http://www.kernelnotes.org schmerzlich erfahren müssen. Es ist nämlich jemandem gelungen, in den einzigen "sicheren" Dienst des Servers einzubrechen, nämlich SSH. Das Problem lag in einem möglichen buffer overflow schon bei der Übergabe der Schlüssel und Paßworte der Authentifizierung (Siehe http://www.geek-girl.com). Ein weiterer Fall, der im Januar 1999 bekannt geworden ist, betrifft den TCP Wrapper von Wietse Venema (TCPD). Dieser wurde von einem unbekannten mit einer Hintertüre versehen, die schwierig zu entdecken war. Man mußte sich von einem spezielle Quellport aus mit dem Wrapper auf einem Server verbinden lassen. Damit hatte der unbekannte Zugang zu dem gesamten System. Es ist bei der Installation einer Firewall und der Auswahl der Dienste sehr wichtig, die Quellcodes stets von einem sicheren Server zu beziehen, die Prüfsummen zu verifizieren (MD5) und diese dann eigenhändig zu kompilieren und zu installieren.

Für die Fernwartung aus dem Intranet heraus ist es zu vertreten, daß die Dienste FTP und TELNET auf der Firewall aktiviert werden. Das erspart, je nach Größe es Hauses, einige Laufarbeit. Wie oben schon erwähnt, binden sich viele Dienste an alle zur Verfügung stehenden Netzwerkkarten. Soweit dieses möglich ist, sollten alle Dienste an die interne Netzwerkkarte gebunden werden. Wie wichtig dies ist, zeigt sich u.a. auch mit dem Proxy 2.0 unter Microsoft Windows NT 4.0. Wie man sieht, sind die Probleme allgegenwärtig. Sie sind alle zu beheben, vorausgesetzt, daß man die Zusammenhänge versteht. Um alle Dämonen, also den tcpd, inetd, in.ftpd, und telnetd nach außen hin abzuschirmen, ist es notwendig, die Firewallregeln entsprechend anzupassen.

Die Standardkonfiguration bei RedHat Linux ist so, daß alle Dienste stets über den TCP Wrapper gestartet werden. Der mitgelieferte TCPD ist jedoch nicht die "überarbeitete" Version, sondern stammt vom Original ab.

Nun wenden wir uns weiteren Diensten zu, den RPC´s. Die Remote Procedure Calls werden von vielen Betriebssystemen für Dinge genutzt, von denen es niemand vermutet hätte. Beispielsweise nutzt Windows NT die RPC für den PDC, OSF-DCE verwendet es, viele Backup-Programme verwenden es, NFS, NIS+, YP basieren ebenfalls darauf. Inzwischen benötigt sogar SAMBA diesen Dienst.

RPC ist ein Dienst, der oberhalb von IP, TCP und UDP angesiedelt ist. Der Grund für die Einführung dieses Dienstes liegt darin, daß TCP und UDP nur 65535 verschiedene Ports, also Verbindungen simultan benutzen können. Berücksichtigt man, daß z.B. X-Windows sehr viele simultane Verbindungen benötigt (Fontserver...), dann kann es passieren, daß die Ports alle schnell vergeben sind. RPC hat die 2 Byte auf 4 Byte erweitert, und kann somit ca. 4.3 Milliarden simultane Verbindungen handeln. Die einzig feste Portnummer dieses Dienstes, die niemals verändert werden darf, ist die des Portmappers auf Port 111. Dieser handelt die Kanäle mit den Clients aus. Die Firewall im Kernel von LINUX hat keinerlei speziellen Kenntnisse über die Mechanismen, die für die RPC Dienste erforderlich sind. Hier bleibt nur der Einsatz des TIS FWTK übrig. Die Installation des TIS FWTK ist ein einem der folgenden Kapitel beschrieben. Die Firewall ist nun im Prinzip von allen Arbeitsstationen im Intranet zu erreichen. Die Fernwartung könnte also von allen Arbeitsplätzen im Netz erfolgen. Es existieren nun zwei Möglichkeiten, den Zugriff zu begrenzen. Die Änderung der Firewallregeln, oder die Anpassung des der Datei /etc/hosts.allow, /etc/hosts.deny und der /etc/inetd.conf Datei. Betrachten man nun die Datei /etc/hosts.allow:


ALL: LOCAL
in.ftpd sshd : ALL

Es wird allen Arbeitsstationen im Netzwerk die Aktivierung der Dämonen in.ftpd und sshd erlaubt. (FTP und SSH) Betrachten man nun die Datei /etc/hosts.deny:y


ALL: PARANOID 
ALL EXCEPT in.ftpd sshd : ALL

Man erreicht mit diesen Einstellungen, daß die Firewall ein "double reverse lookup" bei jedem Verbindungsaufbau durchführt, d.h. den DNS - Namen in eine IP - Nummer auflöst, mit reverse lookup diese IP - Nummer zurück in den DNS - Namen auflöst, und vergleicht. Ist die zugreifende Maschine dann nicht korrekt in die DNS - Server eingetragen, also nicht offiziell, dann wird die Verbindung abgelehnt. Ein Grund hierfür kann sein, daß ein Angreifer versucht, von einem Laptop o.ä. sich Zugang zur Firewall zu verschaffen. Im Internet führt diese Einstellung zu einer erheblichen Belastung der DNS Server, weil weltweit viele Konfigurationsfehler passieren. Allerdings verbessert diese Einstellung sehr den Schutz vor Angriffen mit gespooften Adressen. Hierzu muß jedoch der TCPD mit -DPARANOID neu kompiliert werden. Dies trifft im Übrigen auf die Dämonen zu: APACHE, SAMBA, BIND, SQUID, mountd...Diese müssen alle mit der eingebundenen libwrap neu kompiliert werden, damit diese bei jedem Kontakt mit einem Client einen double reverse lookup durchführt. Der Befehl man tcpd gibt zusätzlich noch genügend Hinweise für die Konfiguration des TCP Wrappers.

Hier noch einige Tips zur Konfiguration der Firewall

Die Firewallregeln sollten immer nur von einem vollständigen Skript aus gesetzt werden.
Es sollte sichergestellt sein, daß alle vorherigen Regeln gelöscht werden. Dies kann mit: ipfwadm -F/I/O -f geschehen. Um sich davon zu überzeugen, daß alle Regeln wirklich gelöscht sind, reicht ipfwadm -I/O/F -l aus.
Man sollte nicht vergessen, vor dem Löschen der Regeln die Firewall von dem ISDN - Router zu trennen. Die default policy ist auch eine Regel. Im richtigen Moment könnte sonst ein Angreifer durch die Firewall tunneln. Dies ist abhängig davon, ob forwarding im Kernel aktiviert wurde.
Die Firewall sollte niemals ungeprüft an das Internet angeschlossen werden. Die Philosophie des Herumprobierens, bis es läuft, und dann zu testen, hat schon vielfach zu Einbrüchen geführt. Insbesondere interessieren sich Hacker für neu vergebene IP-Netze und Domainnamen (RIPE). Es dauert mitunter nur Stunden, bis ein Hacker sein Glück versucht.
Das Mitloggen von Ereignissen schon zu Beginn kann sehr aufschlußreich sein, insbesondere auch der internen Pakete. Es sollten stets auch alle Flags (SYN, ACK) überprüft werden. Mit der Option -o am Anschluß einer jeden Firewallregel wird sichergestellt, daß bei einem Verstoß gegen diese Regel ein Eintrag im Logfile der Firewall erscheint.
Schon beim Aufbau der Firewall sollte die Security Policy aufgestellt sein.

Online Suche im Handbuch

LITTLE-IDIOT NETWORKING