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

einfacher und sinnvoller, diese auf dem Zielserver selber zu korrigieren, ein Filter ist dann
nicht mehr notwendig.
Für den Betrieb von mission critical Systemen ist es notwendig, Fehler schnell analysieren
und korrigieren zu können. Wer zum Schutz vor DoS-Angriffen seines Betriebssystems
erst auf die angepaßten Filter des Firewallherstellers warten muß, riskiert, daß
wochenlang der Server immer wieder von Angreifern stillgelegt wird. Falls der Quellcode
des Betriebssystems nicht vorliegt, ist es dann notwendig, separate Filter in den
Datenstrom zu integrieren.
Da Filter selber ebenfalls Ziele von buffer overflows sein können, sollten diese immer auf
einer dedizierten Hardware laufen, und von zwei Firewalls gesichert werden.
Leider vergessen die Hersteller von Firewalls immer wieder, zu betonen, daß ihre
Firewalls nicht Schutz gegen Fehler auf Anwendungsebene (application level) von
Serverbetriebssystemen sein können. Sie besitzen zwar Filter, um bestimmte Befehle z.B.
in FTP-Servern (remote site exec) zu sperren, weil diese in der Vergangenheit immer
wieder zu Problemen unter UNIX geführt haben, können jedoch dann mögliche buffer
overflows bei der Parameterübergabe an die übrigen Befehle nicht verhindern. Sie
behelfen sich daher mit einer pauschalen Längenbegrenzung für übergebene Parameter,
die aber meist so groß gewählt wurde, daß in der Praxis keine Probleme mit Datenbanken
u.s.w. gibt. Da buffer overflows recht kurz sein können, ist diese Filterung kein Garant.
Firewalls, insbesondere SPF´s sind vor ihrer Architektur her nicht dafür geeignet, Fehler in
Betriebssystemen vor Angreifern abzuschirmen, obwohl sie es nach entsprechender
Programmierung (mit Hilfe einer leistungsfähigen Programmiersprache) können. Für
Firewall-1 z.B. lassen sich diese Filter nachrüsten, sie müssen aber teuer bezahlt werden,
stammen aber alle aus der knowledge base für Händler von Checkpoint in Israel.
Preisverleiche lohnen sich daher.
Neuentdeckte Fehler in Betriebsystemen hinter einer Firewall (z.B. Windows NT 4.0 und
IIS WWW-Server) müssen erst auch bei dem Hersteller der Firewalls erkannt und in Filter
einprogrammiert werden. Bis dann ein Update erfolgen kann, ist mitunter mindestens eine
Woche vergangen. Für Betreiber von mission critical Systemen ist diese Zeit viel zu lange.
Mit Hilfe der Werkzeuge von Darren Reed (IPFILTER) gelingt es binnen weniger Stunden,
den Fehler mitzuprotokollieren und zu analysieren. Die Programmierung eines Filters, z.B.
mit PERL ist dann nur noch eine Aufgabe der Anpassung bestehender Filter. Wer mehr
bedarf an Lösung dieser Probleme hat, sollte sich das Modul Net::RAWIP für PERL und
FreeBSD anschauen. Genial einfach und - kostenlos!
Feindliche Übernahme von benachbarten Servern
Themen
• Stilllegung des Targets (DoS)
• MAC spoofing
• Überwachung von Netzen
Kleinere Provider haben Kundenserver auf einer "collision domain" gemeinsam
angeschlossen. Ist ein speziell ins Auge gefaßter Server bei diesem Provider nicht
verletzlich, so benutzt ein Angreifer weitere Tricks.
Häufig findet sich dort zumindest ein Server, der verletzbar ist, oder es ist möglich, nach
Absprache mit dem Provider für einige Tage "probeweise" dort einen Server aufzustellen.
Mit Hilfe dieses Servers läßt sich dann ein mit dem Zielserver identischer Server
aufbauen, der dann über ständige DoS-Angriffe den Ur-Server stilllegt, und somit seinen
Platz übernehmen kann. Es dauert nur wenige Tage oder Stunden, bis der
Systemadministrator versucht, sich einzuloggen. Über einen präparierten Login-Dämon,
Erstellt von Doc Gonzo - http://kickme.to/plugins