Online Suche im Handbuch

LITTLE-IDIOT NETWORKING

13. Problem Fernwartung einer LINUX Firewall

Die Fernwartung eines Servers oder einer oder mehrerer Firewalls ist eine kritische Angelegenheit. Einerseits ist hierfür ein zusätzlicher Dienst oder Dämon notwendig, der auch Sicherheitsprobleme mit buffer overflows haben kann, andererseits ist Fernwartung in größeren Netzwerken unerläßlich. Oft sind größere Netzwerke mit strukturierter Verkabelung mit intelligenden Switches ausgerüstet, sodaß man für die Firewalls ein eigenes VPN (Virtual Private Network) schalten kann. Hierbei sollte man pro Firewall einfach noch eine zusätzliche Netzwerkkarte einstecken, und dafür sorgen, daß die Dämonen INETD bzw. SSH sich keinesfalls an die beiden anderen Karten anbinden, siehe Kapitel Protokolle und Dienste. Man muß also stets sehr genau darauf achten, daß die Fernwartungssoftware nur über das dritte Interface zu erreichen ist !

Der Grund hierfür ist oft nicht ganz einsichtig. Angenommen, eine Firewall besitzt ein externes und ein internes Interface. Über das interne Interface wird aller Traffic und auch die Fernwartung abgewickelt. Angenommen, daß ein Angreifer von dem Äußeren Interface nicht auf z.B. Port 22 von SSH zugreifen kann. Speziell SSH hatte aber z.B. ein Buffer overflow Problem. Dasselbe Problem könnte aber auch jedes andere Verschlüsselungsprotokoll besitzen. Ein weiteres Problem ist häufig, daß es viele Systemadministratoren mit dem Schutz vor Angriffen von innen nicht so ernst nehmen. Tatsache ist aber, daß viele installierte Firewalls unter LINUX von innen her verletzbar sind, insbesondere dann, wenn noch offene Ports von innen her zu erreichen sind, z.B. für Fernwartung, SMNP, MAIL, o.ä. Die zu mächtige Skriptsprache von Microsoft erlaubt die direkte Programmierung von TCP/IP Paketen über Visual Basic und die Winsock 2.1/3.0 von Windows. Damit lassen sich buffer overflows von innerhalb initiieren, ohne daß der Anwender von Winword überhaupt merkt, daß im Hintergrund sein Arbeitsplatz-PC gerade die Firewall außer Betrieb setzt. Die ist leider keine Hypothese, sondern bittere Erfahrung. Darum sollte man stets, sofern möglich, der Firewall ein drittes Interface spendieren, welches an ein V-LAN zur Administration von sicherheitsrelevanten Komponenten des Netzwerkes eingerichtet wurde. Von diesem Arbeitsplatz sollte dann logischerweise kein Zugang zu Mailservern oder evtl. sogar zum Internet möglich sein.

Damit nun kein Streß entsteht, ("Wir brauchen ein V-LAN), sei noch erwähnt, daß man durchaus z.B. die SINUS Firewall sicher von einem Arbeitsplatz aus administrieren kann, auch dann, wenn kein V-LAN und kein drittes Interface auf der Firewall existent sind. Die Angriffe sind schon etwas anspruchsvoller und höchst selten. Ein Profi würde sicher einfachere Sicherheitslücken auszunutzen wissen. Die weitere Vorgehensweise ist in einem Unterkapitel Fernwarung und Sicherheit der SINUS Firewall beschrieben. Die SINUS Firewall ist zentral über ein JAVA Applet sicher über kryptografische Protokolle (ENSkip, OPIE, SSH, PPTP) zu administrieren. Die dort angegebenen TIPS zur Installation gelten auch für die LINUX Kernel Firewalls mit dem ipfwadm Toolkit.

Eine Alternative ist die Fernwartung der Firewall über das ISDN Interface der Firewall. Hierzu muß man das zweite ISDN-Interface als DIAL-IN Router mit SYNC-PPP konfigurieren. Als Schutz dient die Firewall und die Paßwortkennung des PPP-Dämons. Leider sind diese Maßnahmen völlig unzureichend, da bereits bei der Paßwortkennung und der CHAP/PAP Authentifizierung ein buffer overflow möglich ist. In der Praxis hat sich gezeigt, daß viele Dämonen unter diesem Problem leiden, daher ist diese Maßnahme alleine auch unzureichend. Man kann dem ISDN-Interface glücklicherweise auch sagen, daß es nur Verbindungen von bestimmten Telefonnummern aus annehmen soll. Fremde Telefonnummern werden generell abgelehnt, es kommt erst gar nicht zur CHAP/PAP Authentifizierung. Ein kleines Problem gibt es jedoch noch. Telefonnummern sind prinzipiell spoofbar, sofern der Anrufer aus demselben Ortsbereich anruft. Spoofing kann man mit vielen Telefonanlagen durchführen, sofern man einen Anlagenanschluß bei der Telekom besitzt, und über eine vollwertige TK-Anlage verfügt. Interne ISDN-Nummern der TK-Anlage werden nach außen an andere Teilnehmer weitergeleitet. Prinzipiell kann man dann jede Telefonnummer vortäuschen, also ISDN Nummern spoofen. Es gab in vergangener Zeit einige wenige Cracker, die so auf anderer Teilnehmer Kosten telefoniert haben. Die Telekom übermittelt jedoch tatsächlich zwei ISDN-Nummern zwischen den Teilnehmern über den D-Kanal. Einmal die von der TK-Anlage angegebene Nummer und direkt hinterher die offizielle, amtliche Telefonnummer. Leider wird diese von vielen ISDN-Anlagen und von vielen ISDN Treibern nicht an das Betriebssystem übermittelt. Wer ISDN Anlagen sicher betreiben möchte, der sollte sich einmal bei Rohde und Schwarz, Köln-Porz-Wahn informieren. Zusammenfassen kann man also sagen, daß man Fernwartung über ISDN nicht absolut sicher gestalten kann. Jedoch wenn man bedenkt, daß es nur sehr wenige Cracker mit TK-Anlagenanschluß in demselben Ortsbereich gibt, die buffer overflows für den IPPPD konstruieren können, um somit in die Firewall vorzudringen, kann man behaupten, daß diese Art der Fernwartung doch recht sicher ist.

Die einfachste und beste Lösung ist die Installation des PPTP Servers, der im Kapitel PPTP unter Windows und LINUX beschrieben wird. Sowohl die Client-Software als auch die Serversoftware ist kostenlos. Damit kann der komplette IP Traffic zwischen Arbeitsstation und Firewall verschlüsselt übertragen werden. Eine preisewertere IPSec Lösung für ein Unternehmen gibt es nicht.

Online Suche im Handbuch

LITTLE-IDIOT NETWORKING