Firewall Handbuch für LINUX 2.0 und 2.2 - zurück

einen geeigneten Filter schreiben. PERL eignet sich hervorragend zur Erstellung von
Filtern, sofern es im »tainted mode« gestartet wird. In diesem Modus werden alle
Variablen, die Daten von »außen« übergeben bekommen, als »verdorben« markiert.
Übergibt man Parameter von »verdorbenen« Variablen an Programme oder
Betriebssystemroutinen, so werden diese nicht ausgeführt. Ein sinnvoller Schutz. Daüber
hinaus ist PERL eine interpretierte Sprache, die selber keine »buffer overflows« kennt, da
es keine Längenbegrenzung bei Variablen gibt. Alle Speicheranforderungen für Variablen
erfolgen dynamisch. JAVA ist ebenfalls eine Interpreter-Programmiersprache, die so
designt wurde, daß alle Operationen völlig vom Betriebssystem abgeschirmt werden
können.(SANDBOX) Versuche mit C, C++ oder Visual Basic sind mit Vorsicht zu
betrachten, schließlich kann der Filter auch Angriffsziel sein, wenn auch nicht für einen
funktionierenden »exploit«, aber in den meisten Fällen reicht es dann für einen DoS
Angriff aus. Es ist also erhöhte Vorsicht beim Programmieren eines solchen Filters
geboten. Überlegenswert ist es, ob man dedizierte Hardware hierfür einsetzt und diese mit
Firewalls noch einmal sichert. Alternativ kann man auch einen Dämon/Dienst einsetzen,
dessen Fehler stets veröffentlicht werden, sodaß man präventiv stets die neuesten
Patches einspielen kann. Eine Garantie kann prinzipiell nur bei Software gegeben werden,
die auch im Quellcode verfügbar und somit überprüfbar ist. Einige Hersteller haben die
Neigung, nur dann Fehler zu korrigieren oder zuzugeben, wenn sie massiv damit
konfrontiert werden. Hierzu gehört insbesondere Microsoft. Auch dann ist es noch eine
Frage, wann die Fehler korrigiert werden. Eine Konsequenz daraus hat IBM gezogen. IBM
supportet nun offiziell z.B. den Apache WWW-Server, der u.a. auch in LINUX und BSD-
UNIX eingesetzt wird. Die Netfinity-Serie wird im Prinzip mit vielen LINUX
Softwarekomponenten ausgeliefert (GNU Software). Hersteller, wie HP, DEC u.s.w.
setzen diese Software auch ein. Software, die Datenströme filtern kann, gibt es in großer
Zahl. Sie unterscheiden sich erheblich in Qualität und Funktionalität. Sie sind zumeist in
PERL oder in JAVA geschrieben. Fast alle sind im Quellcode verfügbar, aus
nachvollziehbaren Gründen. Einige Firewalls haben Filtersprachen eingebaut, es muß
aber vorher abgeklärt werden, ob diese für alle Dienste anwendbar sind. Application level
Gateways (PROXY´s) besitzen manchmal nur minimale Filtermöglichkeiten, die nur
einzelne Befehle einiger Dienste (www,ftp..) filtern können. Es sollte unbedingt darauf
geachtet werden, daß diese Filter sowohl die Befehlssyntax, als auch die Länge der
übergebenen Parameter filtern können. Nur beide Eigenschaften zusammen können
ausreichend Schutz gegen »buffer overflows« bieten. SUN geht andere Wege und ersetzt
successive alle Dämonen unter UNIX durch deren JAVA Pendants. Diese Konzeption ist
so vielversprechend, daß es auch eine größere Zahl von freien JAVA Dämonen gibt, die
teilweise Filtermöglichkeiten direkt eingebaut haben, und so in der Lage sind, auch SQL-
Server zu sichern. (Jigsaw)
Die CPU und »buffer overflows«
Völlig neu mag der Hinweis erscheinen, bei Servern, die sensible Daten hosten, eine nicht
übliche CPU einzusetzen. Viele Angriffe könne sogar von Laien mittels fertiger
Angriffswerkzeuge aus dem Internet ausgeführt werden. Diese finden sich zumeist in
Form von "buffer/heap overflows" schon fertig kompiliert für INTEL/ ALPHA/ SPARC-
Prozessoren auf einschlägig bekannten Servern. Nur wenige Personen jedoch verfügen
über die nötigen Kenntnisse, einen "buffer overflow" derjenigen Art, wie sie monatlich zu
dutzenden verbreitet werden, auf andere Prozessoren, z.B. ARM, MIPS o.ä. zu portieren.
Hierzu sind weitreichende Assemblerkenntnisse und Praxis im Umgang mit Debuggern
notwendig. Kommt z.B. NetBSD oder LINUX auf ARM-Prozessoren zum Einsatz, so ist
das Risiko, daß ein Angriff direkt beim ersten Versuch zum Erfolg führt, äußerst gering.
Der Angreifer benötigt dann mehrere Versuche, um erfolgreich zu sein, was das Risiko der
Entdeckung stark erhöht. Auch sollten in einer Kaskade von Firewalls niemals dieselben
Prozessoren zum Einsatz kommen. Dasselbe trifft auch auf die (fast noch wichtigeren)
Log-Server zu, da ohne diese "Dokumente" ein Einbruch nicht bemerkt werden kann.
Helfen »wrapper« und »chroot()«?
Wrapper, wie sie unter UNIX häufig eingesetzt werden, installieren sich zwischen Kernel
und Dämonen. Hauptgrund ist, daß unter BSD-UNIX Ports unterhalb von 1024 als
Erstellt von Doc Gonzo - http://kickme.to/plugins