MIT-Kurs "Sicherheit von Computersystemen". Vorlesung 12: "Netzwerksicherheit", Teil 3

Ursprünglicher Autor: Nikolai Zeldovich, James Mykens
  • Übersetzung
  • Tutorial

Massachusetts Institute of Technology. Vorlesung # 6.858. "Sicherheit von Computersystemen." Nikolai Zeldovich, James Mykens. 2014


Computer Systems Security ist ein Kurs zur Entwicklung und Implementierung sicherer Computersysteme. Die Vorträge behandeln Bedrohungsmodelle, Angriffe, die die Sicherheit gefährden, und Sicherheitsmethoden, die auf der neuesten wissenschaftlichen Arbeit basieren. Zu den Themen gehören Sicherheit des Betriebssystems (Betriebssystem), Funktionen, Informationsflusssteuerung, Sprachsicherheit, Netzwerkprotokolle, Hardwareschutz und Sicherheit in Webanwendungen.

Vorlesung 1: "Einführung: Bedrohungsmodelle" Teil 1 / Teil 2 / Teil 3
Vorlesung 2: "Kontrolle von Hackerangriffen" Teil 1 / Teil 2 / Teil 3
Vorlesung 3: "Pufferüberlauf: Exploits und Schutz" Teil 1 /Teil 2 / Teil 3
Vorlesung 4: "Privilegienseparation" Teil 1 / Teil 2 / Teil 3
Vorlesung 5: "Woher kommen die Fehler des Sicherheitssystems" Teil 1 / Teil 2
Vorlesung 6: "Fähigkeiten" Teil 1 / Teil 2 / Teil 3
Vorlesung 7: "Native Client Sandbox" Teil 1 / Teil 2 / Teil 3
Vorlesung 8: "Netzwerksicherheitsmodell" Teil 1 / Teil 2 / Teil 3
Vorlesung 9: "Web Application Security" Teil 1 / Teil 2/ Teil 3
Vorlesung 10: "Symbolische Ausführung" Teil 1 / Teil 2 / Teil 3
Vorlesung 11: "Ur / Web-Programmiersprache" Teil 1 / Teil 2 / Teil 3
Vorlesung 12: "Netzwerksicherheit" Teil 1 / Teil 2 / Teil 3

Student: Gibt es eine Art Signatur für nicht vorhandene Top-Level-Domains?

Professor: Ich denke, das gibt es. Eine Punktdomäne ist nur eine andere Domäne und implementiert denselben Mechanismus. So verwenden die dot- und dot-com-Domänen heutzutage das SEC-DNS, und es gibt all diese Datensätze, die zum Beispiel besagen, dass .in ein Domänenname ist und der Punktname auch existiert. und es gibt nichts anderes zwischen ihnen. In den Top-Level-Domains gibt es all diese Dinge.



Student: Warum kümmern wir uns neben der Gefahr von DoS-Angriffen auch um die Wiederholung von Domainnamen in mit.edu?

Professor:Ich weiß es nicht genau. In jedem Fall verfügt AFS über eine Textdatei, in der alle diese MIT-Domänennamen aufgeführt sind. Ich denke jedoch, dass sich einige Unternehmen im Allgemeinen in dieser Hinsicht etwas peinlich fühlen, da sie oft interne Namen haben, die im DNS enthalten sind und die nicht an Außenstehende vergeben werden können. Ich denke, dass dies tatsächlich ein unscharfer Bereich ist, der nie formalisiert wurde und der nicht genau klarstellt, was die DNS den Benutzern garantiert. Normalerweise gehen die Leute davon aus, dass ein vertraulicher Name im Falle von DNS nicht bekannt gegeben wird.

Ich denke, dass dies ein weiterer Ort ist, an dem dieses System keine klare Spezifikation dafür hat, was es bieten sollte oder nicht.

Student:Ist es möglich, das Ablaufdatum einer Unterschrift festzulegen und sie irgendwie hervorzuheben?

Professor: Diese Dinge haben ein Ablaufdatum. Sie können beispielsweise die Gültigkeit der angegebenen Namen für eine Woche unterzeichnen, und Kunden, die über eine synchronisierte Uhr verfügen, können die alten signierten Nachrichten ablehnen.

Wir können also davon ausgehen, dass wir Angriffe besprochen haben, indem wir die Sequenznummern von TCP SYN erraten. Ein weiteres interessantes Problem, das TCP betrifft, ist der DDoS-Angriff, der die Tatsache ausnutzt, dass der Server einen gewissen Status beibehält. Wenn Sie sich diesen Handshake ansehen, der zuvor auf der Platine gezeichnet wurde, werden Sie feststellen, dass sich der Server beim Herstellen einer Verbindung zum Server an die Sequenznummer des Client-SNc erinnern muss. Daher muss der Server eine Datenstruktur in einem separaten Block unterstützen, was darauf hinweist, dass diese Sequenznummer für diese Verbindung verwendet wird.



Dies ist eine Art Tabelle, in der die Seriennummer des SN gespeichert wird und die Tatsache, dass die Client-Server-Verbindung die Seriennummer des SNc hat. Der Grund, warum der Server diese Tabelle speichern soll, besteht darin, dass der Server herausfinden muss, welchen korrekten Wert die SNc-Sequenznummer später akzeptieren soll, z. B. SNc + 1. Darüber hinaus muss der Server auch SNs-Nummern speichern, die viel wichtiger sind, da sie dem Server anzeigen, dass die Verbindung mit dem „richtigen Mann“ hergestellt wird.

Das Problem ist, dass diese Tabelle keine echte Grenze hat. Auf diese Weise können Sie Pakete von einem Computer erhalten, ohne zu wissen, wer sie sendet. Sie erhalten einfach ein Paket, das wie C-> S aussieht, mit der Quelladresse, die besagt, dass es sich um C handelt. Um diese Verbindung möglicherweise von dieser IP-Adresse zu akzeptieren, müssen Sie einen Eintrag in der Tabelle erstellen. Darüber hinaus gibt es diese Aufzeichnungen für eine lange Zeit, da möglicherweise jemand eine Verbindung mit Ihnen von einem weit entfernten Ort her aufbaut und gleichzeitig viele Pakete verloren gehen. Im schlimmsten Fall kann es beispielsweise eine Minute dauern, bis dieser TCP-Handshake beendet ist. Sie müssen diesen Status also relativ lange auf dem TCP-Stack speichern, und Sie können nicht erraten, ob er gültig ist oder nicht.

Daher ist der häufigste DoS-Angriff auf die meisten TCP-Stapel, die von den Menschen erfunden wurden, die einfache Übertragung einer großen Anzahl von Paketen. Wenn ich ein Angreifer bin, sende ich einfach eine große Anzahl von SYN-Paketen an einen bestimmten Server und erzwinge einen Überlauf dieser Tabelle.

Das Problem ist, dass der Angreifer bestenfalls dieselbe Quell-IP-Adresse verwendet. In diesem Fall können Sie einfach sagen, dass für jeden Client nur zwei Einträge zulässig sind. Der Angreifer kann dann maximal zwei Einträge in der Tabelle verwenden.

Das Problem ist natürlich, dass ein Angreifer die IP-Adressen der Clients fälschen kann, sodass sie zufällig aussehen. Dann wird es für den Server sehr schwer zu unterscheiden, wer versucht, eine Verbindung herzustellen - ein Angreifer oder eine Art Client, von dem der Server noch nie etwas gehört hat.

Wenn Sie sich also eine Site ansehen, die Verbindungen von überall auf der Welt akzeptieren soll, wird dies ein großes Problem sein. Entweder verweigern Sie allen den Zugriff, oder Sie müssen den Status für die meisten falschen Verbindungsversuche speichern können.

Dies ist also sowohl für TCP als auch für die meisten Protokolle ein Problem, die eine Art Verbindungsinitiierung ermöglichen, bei der der Server den Status speichern muss. Es gibt jedoch einige in TCP implementierte Korrekturen, über die wir gleich sprechen werden, und sie werden versuchen, dieses Problem zu lösen, das in TCP als SYN Flooding bezeichnet wird.



Im Allgemeinen ist dies ein Problem, das es wert ist, in jedem Protokoll, das Sie entwickeln, zu vermeiden und zu vermeiden. Sie müssen angeben, dass der Server den Status nicht beibehalten muss, bis er den Client authentifizieren und identifizieren kann. Denn erst nach Überprüfung der Authentizität des Clients kann entschieden werden, ob er beispielsweise nur einmal eine Verbindung herstellen darf. In diesem Fall muss der Server den Status für diese Verbindung nicht speichern.

Das Problem ist, dass Sie die Erhaltung des Staates garantieren, bevor Sie herausfinden, wer sich mit Ihnen verbindet. Lassen Sie uns einen Blick darauf werfen, wie der SYN Flooding-Flood-Attacke entgegengewirkt werden kann, dh der Server sammelt zu viele Zustände an.

Sie können TCP erneut ändern, es beispielsweise mit Kryptographie oder etwas anderem leicht beheben oder die Zuständigkeit für die Aufrechterhaltung eines Status ändern. Tatsache ist jedoch, dass wir TCP so verwenden müssen, wie es ist. Könnten wir dieses Problem lösen, ohne das vorhandene TCP-Protokoll zu ändern?

Dies ist wiederum eine Übung, bei der wir versuchen herauszufinden, welche Tricks wir ausführen könnten, oder genauer, welche Annahmen wir in Ruhe lassen könnten und trotzdem bei der Arbeit mit dem vorhandenen TCP-Header-Format bleiben.

Der Trick besteht darin, einen intelligenten Weg zu finden, einen Server statusfrei zu machen, damit er diese Tabelle nicht im Speicher speichern muss. Dies kann durch sorgfältige Auswahl der SNs erfolgen, d. H., Anstelle der Formel, die wir zuvor betrachtet haben, und wo wir diese Funktion hinzugefügt haben sollten, werden wir die Sequenznummern auf eine völlig andere Weise auswählen. Ich werde Ihnen die genaue Formel geben, und dann werden wir darüber sprechen, warum es wirklich interessant ist und welche guten Eigenschaften es hat.

Wenn der Server erkennt, dass es sich um einen Angriff handelt, wechselt er in einen Modus, in dem er SNs mithilfe einer Formel mit der gleichen Funktion F auswählt, die wir zuvor betrachtet haben.



Diese Funktion hat die Quell-IP-Adresse, die Ziel-IP-Adresse und dieselben Funktionen wie zuvor: Quellport, Zielport, Zeitstempel und Schlüssel. Und wir werden diese Funktion mit einem eher grobkörnigen Zeitstempel von nur wenigen Minuten kombinieren. Es gibt eine Trennung zwischen diesen beiden Teilen des Headers - eine Funktion und ein Zeitstempel, der nicht viele Bits benötigt. Ich habe genau vergessen, wie dieses Protokoll auf einem realen Computer funktioniert, aber Sie können sich vorstellen, dass der Zeitstempel 8 Bit beansprucht und der Rest der Sequenznummernformel 24 Bit beträgt.

Warum ist das ein guter Plan? Was ist hier überhaupt los? Warum brauchen wir diese seltsame Formel? Sie müssen sich daran erinnern, dass wir versucht haben, die Sequenznummern zu ermitteln. Hier passieren zwei Dinge.

Der erste ist der Schutz gegen doppelte Pakete. Auf der Platine befindet sich ein Diagramm mit einer Ordinalzahl im alten Stil, zu der eine Funktion hinzugefügt wird, um das Duplizieren von Paketen aus vorherigen Verbindungen zu verhindern.



Es stellt sich heraus, dass die Leute keinen besseren Weg finden könnten, um sich vor Angriffen wie SYN Flooding zu schützen, außer diesen Aktionsplan zu verwenden, der in einigen Situationen gut funktioniert. Es war ein Plan, aber ein anderer Plan - eine Funktion mit einem Zeitstempel, bei der wir diese Komponente des alten Stils aufgegeben haben. Stattdessen konzentrieren wir uns darauf, sicherzustellen, dass jemand, der diese ACK-Sequenznummer (SNs) als Antwort auf ein Paket angibt, der „richtige“ Kunde ist.

Sie erinnern sich, dass wir uns auf diesen Wert (SNs) verlassen, um IP-Spoofing-Angriffe zu verhindern. Wenn der Server im zweiten Schritt den SNs-Wert an den Client sendet, gehen wir davon aus, dass nur dieser Client uns im dritten Schritt den korrigierten SNs-Wert zurücksenden kann, um den Verbindungsaufbau abzuschließen.

Deshalb mussten Sie diese Sequenznummer in der Tabelle aufbewahren, denn woher würden Sie sonst wissen, ob es sich um eine echte oder eine falsche handelt? Der Grund für die Verwendung dieser Funktion F ist, dass wir diese Tabelle jetzt nicht mehr speichern können.

Wenn im ersten Schritt ein Verbindungsversuch unternommen wird, berechnen wir im zweiten Schritt die SNs anhand dieser Formel und senden sie einfach an den Client zurück, der mit uns in Kontakt treten möchte, woraufhin wir diese Verbindung vergessen.



Wenn dann das dritte Paket eintrifft und sein Wert (SNs) mit dem übereinstimmt, was wir erwarten, bedeutet das, dass jemand im zweiten Schritt unsere Antwort erhalten und sie uns schließlich gesendet hat. Schließlich können wir nach diesem dritten Schritt den echten Eintrag für diese TCP-Verbindung in den Speicher legen. Auf diese Weise wird das Speichern des Serverstatus verzögert, bis der Client den genauen Wert der Sequenznummer sendet. Durch das Erstellen einer solchen Konstruktion können Sie sicherstellen, dass der Client dem Server genau die Antwort sendet, die von ihm erwartet wird, und nicht einen beliebigen Wert.

Student: Spart die SNc nur eine begrenzte Zeit?

Professor:Ja, der Server speichert den SNc-Wert nicht immer und das ist nicht zu gut. Ich habe dies im Diagramm nicht gezeigt, aber hier am Ende der dritten Zeile gibt es ein Feld, das anzeigt, dass dieses Paket keine Daten enthält, aber es enthält nur die Sequenznummer SNc, weil es dieses Feld hat.



Daher kann der Server den SNc-Wert wiederherstellen, da der Client diesen Wert trotzdem in dieses Paket aufnehmen wird. Früher war es egal, aber jetzt scheint es relevant zu sein. Wir werden hier nichts prüfen, aber die Existenz eines solchen Feldes ist an sich eine gute Sache. Es hat jedoch einige traurige Konsequenzen. Zum Beispiel, wenn Sie komplexe Dinge verwenden, die missbraucht werden können. Dies ist jedoch nicht so schlimm wie ein Überlauf des Servers mit Clientanforderungen.

Denn das einzige, was uns beunruhigt, ist die Freigabe der Speicherung dieser Tabelle und das Vertrauen, dass die Verbindungen zu echten Kunden hergestellt werden. Und wenn dieser Client eine Million Verbindungen mit mir aufbaut, werde ich einfach keine Anfragen mehr von ihm erhalten, es ist ziemlich einfach. Das Problem ist, dass die gefälschten Adressen schwer von den Adressen echter Kunden zu unterscheiden sind.

Student: Muss ich einen Zeitstempel speichern?

Professor:Ja, hier gibt es eine clevere Sache! Wenn wir im dritten Schritt den Wert der SNs-Sequenznummer erhalten, müssen wir herausfinden, wie die Eingabedaten für diese Funktion F berechnet werden, um zu überprüfen, ob dieser Wert korrekt ist. Daher nehmen wir den Zeitstempel am Ende des Pakets und berechnen ihn innerhalb der Funktion. Alles andere können wir uns erholen. Wir wissen, wer uns gerade den dritten Schritt und das Paket geschickt hat, wir haben alle diese Felder und unseren Schlüssel, der wiederum immer noch geheim ist, und den Zeitstempel der letzten 8 Bits der Sequenz. In diesem Fall kann es vorkommen, dass zu alte Zeitstempel ausgeschlossen werden, indem alte Verbindungen einfach gesperrt werden.

Student: Ich glaube, dass Sie es verwenden, wenn Sie angegriffen werden, nur weil Sie 8 Bit Sicherheit verlieren oder aus einem anderen Grund?

Professor: Ja, es ist nicht sehr gut, es hat viele schlechte Eigenschaften. In gewissem Sinne verlieren wir wirklich 8 Bits an Sicherheit. Denn jetzt ist der unbestreitbare Teil nur noch 24 Bit statt 32.

Ein anderes Problem ist, was passiert, wenn Sie bestimmte Pakete verlieren? Bei TCP wird davon ausgegangen, dass der Client bei einem Verlust des dritten Pakets nicht auf etwas warten kann. Oder, Entschuldigung, vielleicht ist das Protokoll, das wir über dieser TCP-Verbindung ausführen, ein Protokoll, das davon ausgeht, dass der Server anfangs etwas zu sagen hat. Ich verbinde mich damit und höre mir die Antwort an. Und in SMTP sollte der Server mir beispielsweise eine Begrüßung über das Protokoll senden. Angenommen, ich verbinde mich mit dem SMTP-Server, sende das dritte Paket, ich glaube, ich habe alles getan und warte nur darauf, dass der Server mir antwortet, zum Beispiel:

"Hallo, das ist ein SMTP-Server, bitte senden Sie mir Ihren Brief"!

So kann dieses dritte Paket verloren gehen. In echtem TCP erinnert sich der Server daran, dass er im zweiten Schritt auf den Client geantwortet hat, aber niemals ein Antwortpaket von ihm erhalten hat. Daher sendet der Server das zweite Paket erneut an den Client, um das dritte Paket erneut zu starten. Wenn der Server keinen Status speichert, hat er natürlich keine Ahnung, was gesendet werden soll. Dies macht den Verbindungsaufbau etwas problematisch, da beide Seiten auf einen Antwortschritt warten. Der Server weiß nicht einmal, dass der Client auf eine Antwort von ihm wartet, und der Client wartet auf eine Serverantwort, obwohl er nicht antworten wird, da er den Status nicht speichert. Dies ist ein weiterer Grund, warum Sie den Produktivservermodus nicht ständig verwenden.

Student:Es kann auch zu Datenverlust kommen, wenn Sie sofort zwei sehr kurze Verbindungen von einem Host aus einrichten.

Professor: Ja, definitiv. Eine andere Sache ist, dass wir auf die Verwendung dieser ISN-Sequenznummer im alten Stil verzichten, was die Unabhängigkeit dieser mehrfachen Verbindungen in kurzer Zeit voneinander erhöhte. Ich denke, dass es eine Reihe von Kompromissen gibt, wir haben gerade über drei von ihnen gesprochen, also gibt es noch ein paar Gründe mehr zur Besorgnis.

Wenn wir ein Protokoll von Grund auf entwickeln könnten, um nach dem Besten zu streben, könnten wir nur ein gutes 64-Bit-Volume für die F-Funktion und ein 64-Bit-Volume für den Zeitstempel haben, und dann könnten wir es ständig nutzen, ohne aufzugeben all diese schönen Dinge.

Student:Sollten die SNs im zweiten und dritten Schritt gleich sein?

Professor: natürlich, weil der Server sonst nicht auf den Erhalt dieses Pakets schließen kann. Wenn der Server nicht verifiziert hat, dass diese SNs dieselbe Bedeutung wie zuvor haben, kann es noch schlimmer sein - schließlich konnte ich im ersten Schritt eine Verbindung von einer zufälligen IP-Adresse aus fälschen und diese Antwort dann im zweiten Schritt erhalten. Oder ich würde diese Antwort nicht einmal bekommen, weil sie an eine andere IP-Adresse gesendet wird. Dann stelle ich im dritten Schritt eine Verbindung von einer anderen IP-Adresse her her. Zur gleichen Zeit würde der Server die hergestellte Verbindung unterstützen, warten, bis ich die Daten sendete, und so weiter.



Student: Aber der Zeitstempel wird anders sein, oder? Wie kann der Server dies mit dem neuen Zeitstempel neu berechnen, wenn der Status nicht gespeichert wird?

Professor: Wie ich schon sagte, diese Zeitstempel sind ziemlich grobkörnig und innerhalb von Minuten abgestuft. Wenn Sie zur gleichen Minute eine Verbindung herstellen, ist alles in Ordnung, wenn Sie sich an der Grenze einer Minute anschließen, ist dies zu schlecht.

Ein weiteres Problem bei diesem Schema ist, dass es in vielerlei Hinsicht unvollkommen ist. Die meisten Produktionssysteme, einschließlich Linux, können jedoch zu viele Einträge in dieser Tabelle erkennen. Und wenn der Überlauf droht, wechselt das System zu einem anderen Schema.

Student: Wenn ein Angreifer eine große Anzahl von IP-Adressen kontrolliert und tut, was Sie gesagt haben, auch wenn Sie wechseln ...

Professor:ja, man kann wenig tun. Der Grund, warum wir so besorgt sind, ist, dass wir zwischen den Angreifern und den „Guten“ filtern oder irgendwie unterscheiden wollten. Wenn ein Angreifer über mehr IP-Adressen verfügt und einfach mehr Maschinen als die Guten kontrolliert, kann er eine Verbindung zu unserem Server herstellen, viele Webseiten anfordern oder in Kontakt bleiben.

Und dann wird es für den Server sehr schwer zu bestimmen, ob Anforderungen von legitimen Clients stammen oder dass der Angreifer nur Serverressourcen verknüpft. Da hast du absolut recht. Dieses Schema funktioniert nur, wenn ein Angreifer über wenige IP-Adressen verfügt und diesen Effekt erzielen möchte.

Und es ist beunruhigend, weil einige Angreifer heute eine große Anzahl gehackter Computer normaler Benutzer kontrollieren. Dies ermöglicht es ihnen, DoS mit einer Flotte von Maschinen auf der ganzen Welt zu erstellen, und es ist ziemlich schwierig, sich dagegen zu schützen.

Ich möchte noch eine andere interessante Sache erwähnen - der Misserfolg des DoS-Dienstes ist an sich schlecht, aber noch schlimmer, wenn die Protokolle selbst zum Angriff beitragen. Der Angreifer ist sich dessen bewusst und greift in erster Linie Systeme mit Protokollen wie DNS an. Beim DNS-Protokoll sendet der Client eine Anfrage an den Server, und der Server sendet die Antwort an den Client zurück. In vielen Fällen liegt das Antwortvolumen in Bytes weit über dem Anforderungsvolumen.



Sie haben nach dem Server mit.edu gefragt. Die Antwort auf Ihre Anfrage können also alle Datensätze sein, die sich auf dem Server mit.edu - E-Mail-Adresse befinden, der E-Mail-Server für mit.edu, der zugewiesene Datensatz, wenn dieser DNS SEC verwendet, usw.

Die Anforderung kann also 100 Byte umfassen und die Antwort beträgt mehr als 1000 Byte. Angenommen, Sie möchten einen Mann mit einer großen Anzahl von Paketen "überfluten" oder die gesamte Bandbreite seines Kommunikationskanals nutzen. Sie können nur wenig von Ihrer Bandbreite verwenden, aber Sie können falsche Anfragen an den DNS-Server für diesen Mann organisieren. Sie müssen nur 100 Bytes an einen DNS-Server senden, indem Sie so tun, als ob die Anfrage von diesem armen Kerl stammt, und der Server sendet ihm in Ihrem Namen 1000 Bytes.

Dies ist ein problematisches Merkmal dieses Protokolls, da Sie damit die Bandbreite des Angriffs erhöhen können. Aus dem gleichen Grund, den wir auch beim TCP-SYN-Flooding erwähnt haben, ist es für den DNS-Server sehr schwierig, zu bestimmen, ob diese Anfrage gültig ist oder nicht. Weil während des Datenaustauschs keine Authentifizierungs- oder Sequenznummer vorhanden ist, wird die Verbindung mit dem "Richtigen" hergestellt.

Heute ist es noch ein DNS-Problem. Diese Sicherheitsanfälligkeit wird häufig für Angriffe verwendet, indem die Bandbreite des Client-Kanals reduziert wird. Wenn Ihre Bandbreite auf einen bestimmten Wert begrenzt ist, müssen Sie einen ähnlichen Angriff vom DNS-Server abwehren, um effektiv arbeiten zu können. Diese Server müssen jedoch auf jede Anfrage antworten, da andernfalls die Ablehnung legitimer Anfragen droht. In der Praxis ist dies also ein großes Problem.

Student: Wenn Sie die Anforderung des Angreifers auf dem DNS-Server sehen und nicht darauf reagieren können ...

Professor: Ja, es gibt eine bestimmte Möglichkeit, den DNS-Server so zu ändern, dass er Status speichert.

Student:Warum wird diese Regelung bisher verwendet, wenn sie nicht die Erhaltung des Staates vorsieht?

Professor: Ich denke, jetzt beginnen einige Leute, den DNS-Server zu ändern, um zu versuchen, den Zustand zu speichern. Es gibt jedoch so viele DNS-Server, dass es keine Rolle spielt. Selbst wenn Sie 10 Anforderungen an jeden DNS-Server stellen, wird jedes Paket durch einige wesentliche Faktoren verstärkt, und der Server muss darauf reagieren, da diese Anforderungen möglicherweise von einem legitimen Client stammen. Das ist also ein Problem. Ja, Sie haben recht, wenn es sich um einen einzelnen DNS-Server handelt, wäre das Ändern nicht so schwierig.

Das Problem liegt auch in der Tatsache, dass Root-DNS-Server nicht eine einzige Maschine sind, sondern Racks und Server-Racks, da sie massiv verwendet werden und es daher sehr schwierig ist, den Status für eine so große Anzahl von Maschinen zu speichern. Das Anwachsen böswilliger Eingriffe führt jedoch dazu, dass die Aufrechterhaltung des Zustands immer geeigneter wird.

Ich denke, das allgemeine Prinzip, das Sie in einem beliebigen Protokoll einhalten möchten, und es kann ein gutes Prinzip sein, dass der Client mindestens so viel Arbeit leistet wie der Server. Das Problem ist jedoch, dass der Client nicht so viel tun kann wie der Server. Daher sollte der Server ihm dabei helfen.

Wenn Sie einen DNS-Server von Grund auf erstellt haben und dies wäre Ihr großes Problem, könnten Sie es ganz einfach lösen. Der Client muss eine Anforderung senden, die zusätzliche Auffüllbytes enthält, um die Bandbreite des Kanals zu erhöhen, und der Server sendet dann eine Antwort derselben Größe zurück.

Und wenn Sie eine größere Antwort erhalten möchten, sagt der Server: "Entschuldigung, Ihr Zusatz war nicht groß genug, schicken Sie mir mehr"! Sie garantieren daher, dass der DNS-Server nicht dazu verwendet werden kann, Angriffe durch Aufnahme von Bandbreite zu verstärken.

Tatsächlich tritt dieses Problem auf höheren Ebenen auf. Webanwendungen verfügen oft über Webservices, die viele Berechnungen für eine einzelne Anforderung durchführen. Auf dieser Ebene bestehen DoS-Angriffe in der Tatsache, dass Gegner über die Ressourcenintensität einer bestimmten Art von Operation Bescheid wissen und einfach eine Anfrage senden, um diese Operation immer wieder auszuführen. Wenn Sie Ihr Protokoll und Ihre Anwendung nicht sorgfältig entwickeln, damit der Client nachweisen kann, dass er nicht weniger Arbeit als der Server leistet, ist es ziemlich schwierig, sich vor solchen Dingen zu schützen.



Das letzte, was ich in diesem Artikel erwähnen möchte, ist der Routing-Angriff. Die Gründe für diese Angriffe sind interessant, da sie die Probleme der Transportschicht des Protokolls an die Oberfläche bringen und die Möglichkeit bieten, zu sehen, was in einer Anwendung falsch geschieht.

Ein besonders interessantes Beispiel ist das Routing-Protokoll, für das das Vertrauen in den Benutzer die Basis der Arbeit ist, das oft falsch interpretiert wird. Bis heute gibt es keine einwandfreien Authentifizierungsmechanismen.

Das bekannteste Beispiel ist DHCP, mit dem eine Verbindung zu einem drahtlosen oder kabelgebundenen Netzwerk hergestellt wird. Der Computer sendet einfach das Paket und sagt, es möchte eine IP-Adresse. In diesem Fall sendet der MIT-DHCP-Server beispielsweise nach Erhalt des Pakets das Paket zurück. Dies gibt die IP-Adresse an, die Sie verwenden müssen, hier ist der DNS-Server, den Sie verwenden müssen, und hier sind weitere nützliche Konfigurationsdaten für diese Verbindung.

Das Problem ist, dass das DHCP-Anforderungspaket im lokalen Netzwerk nur sendet, wenn versucht wird, einen DHCP-Server zu kontaktieren, da Sie wirklich nicht im Voraus wissen, was der DHCP-Server tun soll. Sie verbinden sich einfach zum ersten Mal mit dem Netzwerk und senden eine Anfrage. Ihr Client-Computer weiß nicht, was er tun soll und wem er vertrauen kann. Folglich kann jeder Computer im lokalen Netzwerk diese DHCP-Anforderungen abfangen und dem Client von einer beliebigen IP-Adresse aus antworten: "Hey, Sie sollten meinen DNS-Server anstelle eines echten verwenden"! Dadurch kann der Angreifer zukünftige DNS-Anforderungen vom Client abfangen und so weiter.

Daher denke ich, dass diese Protokolle ziemlich schwer zu beheben sind. Auf globaler Ebene können Protokolle wie BGP jedem Mitglied des Netzwerks ermöglichen, ein bestimmtes IP-Adressenpräfix anzukündigen, um Pakete zu sortieren und an einen Angreifer weiterzuleiten. Zur gleichen Zeit gab es Angriffe, bei denen der an BGP teilnehmende Router sagte: "Oh, ich kenne einen sehr schnellen Weg, um diese bestimmte IP-Adresse zu erreichen!", Und dann antworteten alle anderen Router: "OK, natürlich senden wir Ihnen diese Pakete “.



Wahrscheinlich wird dies am häufigsten von Spammern missbraucht, die Spam versenden möchten, aber ihre alten IP-Adressen stehen überall auf der schwarzen Liste. Daher wählen sie einfach eine zufällige IP-Adresse aus und geben an, dass ihre IP-Adresse jetzt hier liegt. Dann geben sie diese IP-Adresse im Netzwerk an, senden Spam und schalten sie aus. Jetzt werden solche Fälle weniger, aber es ist schwierig, dies vollständig zu beseitigen. Um dies zu beheben, müssen Sie wissen, wer diese IP-Adresse wirklich besitzt. Ohne dies ist es schwierig, eine globale Datenbank kryptografischer Schlüssel für jeden Anbieter auf der Welt zu erstellen, aber die Benutzer unternehmen große Anstrengungen, um diese Datenbank zu erstellen.

Gleiches gilt für die DNS SEC. Um zu wissen, nach welcher Signatur im DNS gesucht werden soll, müssen Sie einen kryptografischen Schlüssel für alle Netzwerkentitäten der Welt besitzen. Heute ist dies nicht möglich, aber wir sollten uns darum bemühen, denn dies ist natürlich das größte Problem für die weit verbreitete Verwendung der DNS-SEC.

Ich glaube also, dass Informationen aus diesem Artikel ausgewählt werden sollten, was in den Protokollen überhaupt nicht enthalten sein sollte. Ich möchte Ihre Aufmerksamkeit auf eine wichtige Sache lenken: Während Sicherheit und Integrität wichtige Merkmale und Triebkräfte für höhere Abstraktionsebenen sind, wie kryptographische Protokolle in den Anwendungen, die wir in der nächsten Vorlesung behandeln werden, sollten die Hauptanforderungen für das Netzwerk die Zugänglichkeit und das Netzwerk sein DoS Widerstand gegen Angriffe. Denn diese Eigenschaften sind im Stack auf höheren Ebenen viel schwieriger zu erreichen.

Daher sollten Sie sich bemühen, solche Angriffe wie SYN-Flooding-Angriffe und RST-Angriffe zu vermeiden, sodass Sie die Verbindung eines beliebigen Netzwerkbenutzers unterbrechen können. Dies sind Dinge, die auf niedrigem Niveau wirklich schädlich sind und auf hohem Niveau nur schwer zu beheben sind. Zur Gewährleistung der Integrität und Vertraulichkeit von Daten kann jedoch mehr oder weniger eine Verschlüsselung verwendet werden. Wir werden in der nächsten Vorlesung über Cerberus darüber sprechen.


Die vollständige Version des Kurses ist hier verfügbar .

Danke, dass Sie bei uns bleiben. Magst du unsere Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Freunden empfehlen, 30% Rabatt für Habr-Benutzer auf ein einzigartiges Analogon der Einstiegsserver, die wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbps $ 20 oder wie kann ich den Server freigeben? (Optionen sind für RAID1 und RAID10 verfügbar, bis zu 24 Kerne und bis zu 40 GB DDR4).

VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s bis Dezember kostenlos, wenn Sie für einen Zeitraum von sechs Monaten bezahlen, können Sie hier bestellen .

Dell R730xd 2 mal billiger? Nur bei uns2 x Intel Dodeca-Core Xeon E5-2650v4 128 GB DDR4 6 x 480 GB SSD 1 Gbit / s 100 TV ab 249 $ in den Niederlanden und den USA! Lesen Sie mehr darüber, wie Sie ein Infrastrukturgebäude bauen. Klasse C mit Servern Dell R730xd E5-2650 v4 im Wert von 9000 Euro für einen Cent?

Jetzt auch beliebt: