MIT-Kurs "Computer Systems Security". Vorlesung 12: Netzwerksicherheit, Teil 1

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

Computer Systems Security ist ein Kurs zur Entwicklung und Implementierung sicherer Computersysteme. Die Vorträge behandeln Bedrohungsmodelle, Angriffe, die die Sicherheit gefährden, und Sicherheitstechniken, die auf jüngsten wissenschaftlichen Arbeiten basieren. Zu den Themen gehören Betriebssystemsicherheit, Funktionen, Informationsflussmanagement, Sprachsicherheit, Netzwerkprotokolle, Hardwaresicherheit und Sicherheit von 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überläufe: Exploits und Schutz“ Teil 1 / Teil 2 / Teil 3
Vorlesung 4: „Trennung von Privilegien“ Teil 1 / Teil 2 / Teil 3
Vorlesung 5: „Woher kommen Sicherheitssysteme?“ Teil 1 / Teil 2
Vorlesung 6: „Chancen“ 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: „Sicherheit von Webanwendungen“ 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

Heute werden wir insbesondere über Netzwerksicherheit sprechen und einen Artikel von Stephen Bellovin mit dem Titel "Ein Rückblick auf" Sicherheitsprobleme in der TCP / IP-Protokollsuite "" diskutieren. Dieser Typ hat früher für AT & T gearbeitet und arbeitet jetzt in Kolumbien. Interessant an dieser Arbeit ist, dass sie relativ alt ist - sie ist mehr als 10 Jahre alt, und tatsächlich handelt es sich um Kommentare zu einem Artikel, der 1989 ein Jahrzehnt zuvor veröffentlicht wurde.

Viele von euch fragen, warum wir das untersuchen, wenn viele der dort beschriebenen Probleme in den heutigen Versionen des TCP-Protokolls behoben wurden.



Es ist wahr, dass einige der von Stephen beschriebenen Probleme inzwischen gelöst wurden und einige von ihnen immer noch Probleme bleiben. In diesem Sinne werden wir sie sortieren und sehen, was passiert. Sie fragen sich vielleicht, warum die Leute all diese Probleme beim Entwerfen von TCP nicht überhaupt gelöst haben? Was dachten sie nur?

Und das ist eigentlich nicht klar. Was denkst du? Warum hatte das TCP-Protokoll angesichts all dieser Überlegungen nicht die erforderliche Sicherheit? Irgendwelche Vorschläge?

Student: Zu dieser Zeit war das Internet ein viel leichtgläubigerer Ort.

Professor: Ja, es war buchstäblich ein Zitat aus dem Artikel dieses Mannes. Ja, zu dieser Zeit im Allgemeinen ... Ich glaube, vor ungefähr 40 Jahren wurde eine Reihe von Internetprotokollen entwickelt. Die Anforderungen waren völlig unterschiedlich. Es war nur notwendig, eine Reihe relativ leichtgläubiger Sites, die sich beim Namen kannten, mit einem gemeinsamen Netzwerk zu verbinden.

Ich denke, das passiert oft in jedem System, das erfolgreich wird - es braucht Änderungen. Früher war es ein Protokoll für eine kleine Anzahl von Standorten, jetzt deckt dieses Protokoll die ganze Welt ab. Und Sie kennen nicht mehr den Namen aller Personen, die mit dem Internet verbunden sind. Sie können sie nicht anrufen, wenn sie etwas Schlechtes tun, und so weiter.

Daher denke ich, dass diese Geschichte für viele der Protokolle, die wir in Betracht ziehen, dieselbe ist. Und viele von euch stellen eine Frage wie: „Was zum Teufel haben diese Leute gedacht? Das ist so fehlerhaft! " In Wirklichkeit haben sie ein völlig anderes System entworfen und es einfach an die modernen Bedürfnisse angepasst.

Das Gleiche und das Internet, wie wir es uns in den letzten Wochen angesehen haben, wurden für einen ganz anderen Zweck entwickelt. Aber es wurde erweitert, und wir hatten neue Bedenken, wie dieses Protokoll an moderne Anforderungen angepasst werden kann.

Es gibt noch eine andere Sache, die etwas plötzlich passiert ist: Die Leute mussten die Schwere des Sicherheitsproblems überschätzen. Früher haben Sie nicht alle Dinge verstanden, über die Sie sich Sorgen machen sollten, weil Sie nicht wussten, was der Angreifer mit Ihrem System tun konnte.



Ich denke, teilweise aus diesem Grund wird es interessant sein zu sehen, was mit der TCP-Sicherheit passiert ist, was schief gelaufen ist, wie wir das beheben können und so weiter. Infolgedessen müssen wir herausfinden, welche Arten von Problemen bei der Entwicklung unserer eigenen Protokolle vermieden werden sollten und was ein angemessenes Denken über Angriffe dieser Art ausmacht. Woher wissen Sie, was ein Angreifer in Ihrem eigenen Protokoll tun kann, wenn Sie es gerade entwickeln, um solche Fallstricke zu vermeiden?

Okay, lassen wir die Präambel beiseite und sprechen über diesen Artikel.

Wie sollten wir also über Netzwerksicherheit denken? Ich denke, wir könnten mit dem ersten Prinzip beginnen und versuchen, herauszufinden, was unser Bedrohungsmodell ist. Was kann ein Angreifer in unserem Netzwerk tun?

Er hat wahrscheinlich die Fähigkeit, Pakete abzufangen, und vielleicht kann er sie ändern. Wenn Sie also ein Paket über das Netzwerk senden, ist es ratsam anzunehmen, dass ein Bösewicht Ihr Paket sieht und es ändern kann, bevor es sein Ziel erreicht. Möglicherweise kann es auch gelöscht und benutzerdefinierte Pakete mit beliebigen Inhalten eingegeben werden, die Sie nie gesendet haben.



Gefährlicher ist jedoch die Möglichkeit, dass Bösewichte Ihre im Artikel beschriebenen Protokolle stören. Der Angreifer hat einen eigenen Computer, den er vollständig kontrolliert. Selbst wenn sich alle Computer, denen Sie vertrauen, ordnungsgemäß verhalten, kann der Bösewicht, der über einen eigenen Computer verfügt, Ihr Protokoll oder System stören.

Wenn Sie also ein Routing-Protokoll haben, bei dem viele Leute miteinander sprechen, und eine gewisse Skalierung wahrscheinlich unpraktisch ist, um die Bösen draußen zu halten. Wenn ein Routing-Protokoll mit 10 Teilnehmern ausgeführt wird, können Sie vielleicht einfach alle anrufen und dann sagen: "Ja, Leute, ich kenne Sie alle."

Auf der heutigen Skala des Internets ist es jedoch unmöglich, direkt herauszufinden, wer die anderen Netzwerkmitglieder dieses Protokoll verwenden. Wahrscheinlich wird ein Bösewicht an Ihren Protokollen oder verteilten Systemen teilnehmen. Daher ist es wichtig, verteilte Systeme zu entwerfen, die dennoch etwas Vernünftiges daraus machen können.

OK, was bedeutet das alles? Ich denke, wir werden die Liste durchgehen. Das Abfangen von Paketen ist im Allgemeinen leicht zu verstehen. Sie können keine wichtigen Daten über das Netzwerk senden, wenn Sie erwarten, dass der Bösewicht sie abfängt, oder zumindest nicht im Klartext. Vielleicht sollten Sie Ihre Daten verschlüsseln.



Es scheint relativ einfach zu verstehen, obwohl Sie dies bei der Entwicklung von Protokollen immer noch berücksichtigen müssen. Die Einführung oder Injektion von Paketen führt zu einem breiteren Spektrum interessanter Probleme, die in diesem Artikel behandelt werden. Insbesondere können Angreifer Pakete injizieren, die sich als Pakete eines anderen Absenders ausgeben können. Da der Datenübertragungspfad auf der Verwendung von IP basiert, hat das Paket selbst einen Header, der die Quell-IP des Pakets und die Ziel-IP angibt. Es prüft jedoch niemand, ob die Quelle unbedingt korrekt ist. Es gibt heutzutage einige Filter, aber es ist nicht perfekt und es ist schwer, sich darauf zu verlassen.

In erster Näherung kann ein Angreifer also eine beliebige IP-Adresse als Quelle einfügen und an das richtige Ziel senden. Es ist interessant herauszufinden, was ein Angreifer mit der Fähigkeit tun kann, beliebige Pakete zu senden.

In den Wochen zuvor haben wir uns mit Pufferüberlaufproblemen im Hinblick auf die Websicherheit befasst. Wir haben untersucht, wie ein Angreifer einen Implementierungsfehler wie Pufferüberläufe verwenden kann. Interessanterweise war der Autor dieses Artikels nicht wirklich an Implementierungsfehlern interessiert, er ist mehr an Protokollfehlern interessiert.

Was ist das Besondere daran? Warum hat er die Implementierungsfehler nicht beachtet, obwohl wir mehrere Wochen damit verbracht haben, sie zu untersuchen? Warum ist das wichtig?

Student: weil wir diese Fehler beim Schreiben des Protokolls ausschließen müssen.

Professor: Ja, dies ist wirklich ein großer Fehler aufgrund eines Fehlers im Protokolldesign, da es schwierig ist, Änderungen vorzunehmen. Wenn Sie also einen Implementierungsfehler haben und einen Speicher oder Ausdruck haben, der den Speicherbereich nicht überprüft hat, können Sie diesen Fehler nicht bemerken. Wenn Sie jedoch eine Bereichsprüfung haben und diese weiterhin funktioniert, können Pufferüberläufe vermieden werden. Das ist also großartig.

Wenn Sie jedoch einen Fehler in der Protokollspezifikation haben und wissen möchten, wie das Protokoll funktionieren soll, müssen Sie zur Korrektur eines solchen Fehlers das gesamte Protokoll reparieren. Dies bedeutet eine mögliche Auswirkung auf alle Systeme, die dieses Protokoll sprechen. Wenn wir also ein Problem im TCP-Protokoll finden, ist es möglicherweise ziemlich destruktiv. Weil jeder Computer, der TCP verwendet, Änderungen vornehmen muss, da es möglicherweise sehr schwierig ist, ein modifiziertes Protokoll mit dem alten Computer kompatibel zu machen.

Die TCP-Protokollfehler, über die Stephen so besorgt war, waren grundlegend, deshalb beschloss er, darüber zu sprechen. Im ersten Beispiel untersucht er, wie die TCP-SN-Nummern funktionieren.

Student: Das ist ein wenig abseits des Themas, aber ich bin nur neugierig. Angenommen, Sie finden einen Fehler in TCP. Wie nehmen Sie Änderungen daran vor? Wie können Sie allen Computern auf der Welt mitteilen, dass dies geändert werden muss?

Professor : Ja, ich denke das ist ein großes Problem. Was tun, wenn in TCP ein Fehler auftritt? Nun, es ist nicht klar, was zu tun ist. Ich denke, dass der Autor hier damit zu kämpfen hat. Wenn Sie TCP neu gestalten könnten, lassen sich viele dieser Fehler relativ einfach beheben, wenn Sie im Voraus wissen, wonach Sie suchen müssen.

Da es jedoch schwierig ist, TCP zu reparieren oder zu ändern, geschieht letztendlich Folgendes: Die Entwickler versuchen, abwärtskompatible Einstellungen zu finden, mit denen entweder die alten Implementierungen in Verbindung mit der neuen Implementierung verwendet werden können, oder fügen ein zusätzliches Feld hinzu, das die Verbindung etwas sicherer macht.



Das ist aber ein großes Problem. Wenn dies ein Sicherheitsproblem ist, das tief in TCP verwurzelt ist, wird es für alle zu einem großen Problem, da es sehr schwierig ist, einfach auf die TCP-Version zu wechseln, vorausgesetzt, n plus 1.

IPv6 kann als Beispiel dafür angesehen werden, dass dies nicht der Fall ist, und wir wissen, dass dieses Problem für weitere 15 oder 20 Jahre auftreten wird. IPv6 gibt es seit über 10 Jahren, aber es ist schwer, die Leute davon zu überzeugen, sich von IPv4 zu entfernen. IPv4 ist genug für sie, es scheint zu funktionieren, und sie denken, dass die Umstellung auf ein neues Internetprotokoll zu teuer sein wird. Sie sagen: "Niemand spricht mehr IPv6. Warum sollte ich dann über dieses seltsame Protokoll sprechen, mit dem niemand mehr mit mir sprechen kann?" Auf jeden Fall ist dies eine Art Vorwärtsbewegung, aber ich denke, es wird viel Zeit in Anspruch nehmen. Es wird wirklich eine gewisse Motivation für die Migration geben, und die Abwärtskompatibilität hilft in diesem Fall sehr.

IPv6 bietet viele Abwärtskompatibilitätsoptionen. Sie können beispielsweise über IPv6 mit einem IPv4-Host kommunizieren. Daher versuchen Entwickler, all diese Unterstützung zu entwickeln, aber es ist immer noch schwierig, die Leute von einem Upgrade zu überzeugen.

In Anbetracht der TCP-Sequenznummern werden wir also zwei Probleme betrachten, die mit der Funktionsweise des TCP-Handshakes zusammenhängen. Schauen wir uns also an, wie eine TCP-Verbindung anfänglich hergestellt wird.

Es werden drei Pakete gesendet, um eine neue TCP-Verbindung herzustellen. Unser Client generiert ein Paket für die Verbindung zum Server. Hier steht, dass hier meine Client-IP-Adresse angegeben ist. Ich sende sie an den Server. Gleichzeitig gibt es eine Paket-Header-Struktur, die aus verschiedenen Bereichen besteht, aber wir werden uns für den Bereich der Seriennummer interessieren. Hier wird das SYN-Flag mit der Aufschrift "Ich möchte den Status synchronisieren und eine neue Verbindung herstellen" angezeigt, das die Seriennummer des SNc-Clients enthält.



Wenn der Server dieses Paket empfängt, sagt er: "Der Client möchte eine Verbindung zu mir herstellen, daher sende ich das Paket an diese Adresse zurück, unabhängig davon, wer sagt, dass er versucht, mich zu kontaktieren." Somit sendet der Server das Paket an den Client, wo er seine eigene SNs-Server-Synchronisationssequenznummer und die ACK-Client-Bestätigungsnummer (SNc) enthält. Schließlich antwortet der Client mit dem dritten Paket auf den Server, bestätigt die Synchronisation und sendet die Server-ACK-Server-Bestätigungsnummer (SNs). Jetzt kann der Client mit dem Senden von Daten beginnen.

Um Daten zu senden, muss der Client zu Beginn der Verbindung einige Daten in das Paket aufnehmen und die Seriennummer des SNc-Clients anhängen, um anzuzeigen, dass dies tatsächlich legitime Clientdaten sind. Er weist zum Beispiel darauf hin, dass dies nicht einige Daten aus späteren Nachrichten sind, die gerade jetzt eintreffen, weil der Server einige der ersten Teile der Daten übersehen hat.



Daher sind alle diese Seriennummern in der Regel so ausgelegt, dass sie eine Paketzustellung ermöglichen. Wenn der Client zwei Pakete überträgt, ist das mit der Startsequenznummer das erste Datenelement, die nächste Sequenznummer das nächste Datenelement. Es ist auch nützlich, um einige Sicherheitsanforderungen bereitzustellen.

Vorher habe ich ein Beispiel gegeben, dass sich diese Anforderungen ändern. Daher dachte anfangs niemand, dass TCP Sicherheitsfunktionen bereitstellen sollte. Aber dann begann der TCP, Anwendungen zu verwenden, und sie schienen sich auf diese TCP-Verbindungen zu verlassen, da sie glaubten, dass sie von keinem Angreifer unterbrochen werden konnten oder dass der Angreifer keine schädlichen Daten in die vorhandene TCP-Verbindung einfügen konnte. Als ob plötzlich dieser Mechanismus, der ursprünglich nur für die Bestellung von Paketen gedacht war, einen gewissen Anschein von Sicherheit für diese Verbindungen zu garantieren begann.

Daher gehe ich in diesem Fall davon aus, dass das Problem damit zusammenhängt, was der Server in Bezug auf diese TCP-Verbindung vorgeschlagen haben könnte. In der Regel geht der Server - wie Sie sich vorstellen können - implizit davon aus, dass diese Verbindung mit dem gewünschten Client unter dieser IP-Adresse C hergestellt wird, und es ist für ihn selbstverständlich, dies zu glauben. Aber gibt es einen Grund für eine solche Annahme? Wenn der Server eine Nachricht mit einigen Daten zu dieser Client-Server-Verbindung empfängt und die Sequenznummer C hat, warum kommt der Server zu dem Schluss, dass der echte Client diese Daten gesendet hat?

Student: weil die Seriennummer schwer zu erraten ist.
Professor: Richtig, das ist also eine Art implizite Sache, was bedeutet, dass es eine korrekte SNc-Sequenznummer geben muss. Damit diese Verbindung hergestellt werden kann, muss der Client über eine bestätigte Seriennummer des SN-Servers verfügen, und die Seriennummer des Servers wird vom Server nur an die IP-Adresse des Clients gesendet.

Student: Wie viele Bits stehen für die Sequenznummer zur Verfügung?

Professor: Die TCP-Sequenznummer ist 32 Bit lang, und obwohl dies keine Zufallszahl ist, ist es nicht leicht zu erraten, es würde viel Bandbreite erfordern.

Student: Ist die Seriennummer höher als die ursprüngliche Seriennummer?

Professor: Ja, im Prinzip nehmen diese Dinge zu. Daher wird jedes Mal, wenn Sie SYN senden, 1 Byte mehr als Ihre Sequenznummer betrachtet. Das heißt, wenn wir in der ersten Zeile das Argument (SNc) hatten, dann wird es in der vierten bereits (SNc + 1) geben, und dann wird die Nummerierung von hier aus fortgesetzt. Wenn Sie also 5 Bytes übertragen, ist der folgende Wert (SNc) +6. Es werden einfach die von Ihnen gesendeten Bytes gezählt, wobei jede SYN 1 Byte zählt. In der TCP-Spezifikation wird empfohlen, diese Seriennummern so zu wählen, dass ihr Inkrement mit einer ungefähr festgelegten Geschwindigkeit erfolgt. In den ersten Arbeitsdokumenten des RFC-Protokolls wurde vorgeschlagen, diese Werte um ca. 250.000 Einheiten plus 250.000 pro Sekunde zu erhöhen.



Der Grund, warum dies nicht völlig zufällig war, ist, dass diese Sequenznummern tatsächlich verwendet werden, um zu verhindern, dass Pakete nicht eingreifen, oder um Pakete von früheren Verbindungen mit neuen Verbindungen zu mischen. Jedes Mal, wenn Sie eine neue Verbindung herstellen, wählen Sie eine völlig zufällige Seriennummer. Gleichzeitig besteht die Möglichkeit, dass ein Paket der vorherigen Verbindung, wenn Sie eine Reihe von Verbindungen immer wieder installieren, eine Sequenznummer hat, die der Sequenznummer Ihrer neuen Verbindung sehr ähnlich ist und daher vom Server als gültiger Teil der Daten für die neue Verbindung akzeptiert wird.

Das war es also, worüber TCP-Entwickler sehr besorgt waren - diese ungeordneten oder verzögerten Pakete. Infolgedessen wollten sie wirklich, dass diese Sequenznummern selbst zwischen Verbindungen eine ziemlich monotone Zeitsequenz sind.

Wenn ich eine Verbindung öffne, kann sie dieselbe Quelle und dasselbe Ziel, dieselben Portnummern, dieselben IP-Adressen usw. haben. Da ich diese Verbindung jetzt und nicht früher hergestellt habe, stimmen die Pakete aus zuvor gesendeten Nachrichten hoffentlich nicht mit den Sequenznummern überein, die ich für meine neue Verbindung habe. Dies war also ein Mechanismus, um Verwechslungen zwischen sich wiederholenden Verbindungen zu verhindern.

Student: Wenn Sie nicht genau wissen, wie der Schritt der Paketsequenz aussehen wird, woher wissen Sie, dass das Paket, das Sie erhalten, das nächste Paket ist und nicht Teil des vorherigen Pakets, das Sie ...

Professor: In der Regel erinnern Sie sich an das zuletzt empfangene Paket. Und die nächste Sequenznummer ist genau das nächste Paket in der Sequenz. So weiß der Server beispielsweise, dass ich genau einen Teil der Datumsdaten (SNc + 1) gesehen habe. Das nächste ist das SYN-Paket (SNc + 1), da das vorherige Paket zu Beginn der Verbindung SYN (SNc) war.

Student: Also, Sie sagen, wenn Sie die Seriennummer einstellen, auch danach ...

Professor: Nun, natürlich werden diese Seriennummern zunächst bei der Installation nach einem bestimmten Plan ausgewählt. Wir werden über diesen Plan sprechen. Sie könnten denken, dass sie zufällig sind, aber im Laufe der Zeit sollten sie einen sequentiellen Strom von Änderungen in den anfänglichen Sequenznummern für die Verbindung darstellen.

Aber innerhalb einer Verbindung endet alles, sobald es hergestellt ist - Seriennummern sind festgelegt. Und sie kennzeichnen diese Verbindung nur, wenn Daten darüber gesendet werden.

Es gab Pläne, die die Verwaltung dieser Seriennummern vorschlugen. , . , , , .

, - , 250000. , , , 64k 128k, . , – , SYN .

, 64 . , .

, . , , , , IP-.
, , , , , . , , .

, ? , , , — SNc. , , - , , , .

, . ACK (SNs).

- .



SNs , , , IP- C.

, . , : , , , data (SNc +1).



(SNs). Das ist klar?

: , ?

: . , , , , . , , , , .

: , , ?

: . , ?

, . , , 32 , , .

, .

: , , , . …

: , TCP .

: , .

: , .

: , , .

: , , , . , , 1000 , 2 32 .

, - , , . . , .



: - , ?

: , . , , IP-, ?

: ?

: — ? , . ?

: , , , , - .

: , , , , , . IP-, TCP , , , .

TCP , - , , , C RST (SN…), , .



- , , C , .

, C , . , S , : «, , , ».

, , , , , C .

, «» C , . , «» C , . , TCP.

: , . , SYN , .

: , , . , , , , NAT, . , NAT RST , . , , , , , Comcast , RST .

: ?

: , , TCP. , . , , , . /, .

, data (SNc +1). , IP- , : « », , S.



SYN (SNs) (SNs) , . — , IP-, . , SNS SNS .

25:50

MIT-Kurs "Computer Systems Security". 12: « », 2


.

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden empfehlen, einen Rabatt von 30% für Habr-Benutzer auf ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s von $ 20 oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 mal günstiger? Nur wir haben 2 x Intel Dodeca-Core Xeon E5-2650v4 128 GB DDR4 6 x 480 GB SSD 1 Gbit / s 100 TV von 249 US-Dollar in den Niederlanden und den USA! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse mit Dell R730xd E5-2650 v4 Servern für 9.000 Euro für einen Cent?