MIT-Kurs "Computer Systems Security". Vorlesung 8: Netzwerksicherheitsmodell, Teil 3

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

Zielgruppe: Warum ist ein zufälliges Token immer in der URL und nicht im Anforderungshauptteil enthalten?

Professor: HTTPS wird auf diese Weise verwendet, aber es gibt keinen guten Grund, Zufallsvariablen nicht in den Anforderungshauptteil aufzunehmen. Es gibt nur einige Formen der Vererbung, die über die URL so funktionieren. In der Praxis können Sie diese Informationen jedoch an einer anderen Stelle in der HTTPS-Anforderung ablegen, mit Ausnahme des Headers.

Beachten Sie jedoch, dass das einfache Verschieben dieser Informationen in den Anforderungshauptteil möglicherweise unsicher ist, wenn der Angreifer etwas erraten kann. Dann kann der Angreifer immer noch irgendwie die URLs aufrufen, die er benötigt. Zum Beispiel, wenn ich eine HTTP-XML-Anfrage stelle und dann explizit Inhalte in den Text einfüge, die der Angreifer erraten kann.



Wenn Sie den Frame einfach in der URL festlegen, kann der Angreifer ihn steuern. Wenn Sie jedoch eine XML-HTTP-Anforderung verwenden und ein Angreifer eine davon generieren kann, können Sie über die HTTP-XML-Schnittstelle den Hauptteil der Anforderung festlegen. Eine HTTP-XML-Anforderung ist auf denselben Ursprung beschränkt. Wenn ein Angreifer jedoch Folgendes tun kann:

<script> var x = “ntrusted”; </script> 

Anschließend kann er die HTTP-XML-Anforderung implementieren, die mit der Berechtigung der eingebetteten Seite ausgeführt wird.

Es hängt alles davon ab, auf was der Angreifer Zugriff hat. Wenn die Seite gezwungen werden kann, ein ungeprüftes Skript auszuführen, wie oben gezeigt, kann sie die JavaScript-Eigenschaft namens internes HTML verwenden und den gesamten HTML-Inhalt der Seite abrufen. Wenn ein Angreifer eine AJAX-Anforderung generieren kann oder nicht, ist dies eine Sache. Wenn er den richtigen HTML-Code sehen kann oder nicht, ist dies eine andere und so weiter. Kurz gesagt, dieses zufällig generierte Token kann CSRF-Angriffe verhindern.

Es gibt noch eine Sache, auf die Sie achten müssen, sind Netzwerkadressen. Sie beziehen sich auf den Teil unserer Konversation, in dem angegeben wurde, wer der Angreifer nicht über eine XML-HTTP-Anforderung kommunizieren konnte.

In Bezug auf Netzwerkadressen kann der Frame HTTP- und HTTPS-Anforderungen an (Host + Port) senden, die seinem Ursprung entsprechen. Beachten Sie, dass die Sicherheit derselben Richtlinie derselben Quelle sehr eng mit der Sicherheit der DNS-Infrastruktur zusammenhängt, da alle Richtlinien dieser Art auf Ihrer Bezeichnung basieren.

Wenn Sie also steuern können, wie sie mich nennen, können Sie einige eher böswillige Angriffe ausführen, z. B. einen DNS-Neubindungsangriff. Der Zweck dieses Angriffs besteht darin, ein von Angreifern kontrolliertes JavaScript mit der Autorität (oder im Namen der Website) des Opfers zu starten. Nennen wir ihn Opfer.com. In diesem Fall verwendet der Angreifer die Regeln derselben Quellrichtlinie und startet den von ihm geschriebenen Code mit der Erlaubnis einer anderen Site.

Dies geschieht wie folgt. Zunächst registriert ein Angreifer einen Domainnamen, z. B. attacker.com. Es ist sehr einfach, zahlen Sie nur ein paar Dollar - und unterwegs haben Sie Ihren eigenen Domainnamen. Der Angreifer muss den DNS-Server auch so konfigurieren, dass er auf Anforderungen reagiert, die im Namen von Objekten auf attacker.com eingehen.



Das zweite, was passieren sollte, ist, dass der Benutzer attacker.com besuchen muss. Insbesondere muss er eine Site besuchen, die von diesem Domainnamen abhängt. Auch in diesem Teil des Angriffs ist nichts schwierig.

Prüfen Sie, ob Sie eine Werbekampagne erstellen können, und bieten Sie beispielsweise ein kostenloses iPad an. Jeder möchte ein kostenloses iPad, obwohl ich niemanden kenne, der jemals ein kostenloses iPad gewonnen hat. Wenn Sie also in einer Phishing-E-Mail auf eine solche Nachricht klicken, befinden Sie sich bereits auf der Website des Angreifers. Nichts Besonderes, dieser Teil ist nicht kompliziert.

Was wird danach passieren? Der Browser generiert DNS-Abfragen für attacker.com, da die von Ihnen besuchte Seite Objekte enthält, die auf Objekte auf attacker.com verweisen. Aber der Browser wird sagen: "Ich habe diese Domain noch nie gesehen. Lassen Sie mich also eine DNS-Anfrage senden, um die Erlaubnis zu erhalten, attacker.com zu kontaktieren."



Der DNS-Server des Angreifers beantwortet diese Anfrage, aber seine Antwort enthält eine sehr kurze TTL-Lebensdauer, wodurch verhindert wird, dass die Antwort zwischengespeichert wird. Daher wird der Browser denken, dass er nur für einen sehr kurzen Zeitraum gültig ist, bevor er beendet und bestätigt werden muss, was tatsächlich bedeutet, das Caching zu verbieten.

Es stellt sich heraus, dass der DNS-Server des Angreifers, sobald der Benutzer zur Hacker-Domäne wechselt, zuerst die tatsächliche IP-Adresse des Webservers zurückgibt, der dem Benutzer bösartigen Code bereitgestellt hat. Dieser clientseitige Code greift auf attacker.com zu, da die Ursprungsrichtlinie solche Anforderungen zulässt. Der Benutzer erhält eine Antwort, und jetzt wird die schädliche Website auf der Clientseite ausgeführt.

In der Zwischenzeit konfiguriert der Angreifer den von ihm kontrollierten DNS-Server so, dass er den Namen attacker.com und die IP-Adresse von opfer.com bindet. Dies bedeutet, dass der Browser des Benutzers, wenn er eine Domainnamenauflösung für etwas in attacker.com anfordert, tatsächlich eine interne Adresse von opfer.com erhält.



Warum kann ein Angreifer DNS dies tun? Da der Hacker dies einrichtet und der DNS-Server des Eindringlings keine Konsultation durchführen muss, um erneut eine Verbindung mit opfer.com herzustellen.

Wenn unsere Site beispielsweise über AJAX ein neues Objekt erhalten möchte, wird davon ausgegangen, dass diese AJAX-Anfrage an attacker.com irgendwo außerhalb geht, aber tatsächlich geht diese AJAX-Anfrage an Opfer.com. Das ist schlecht, denn jetzt haben wir diesen Code auf der Seite, auf der sich die Webseite attacker.com befindet, die tatsächlich Zugriff auf Daten von opfer.com mit einer anderen Herkunftsquelle erhält.



Einfach ausgedrückt, wenn ein Skript im Browser des Opfers ausgeführt wird, weil die vorherige DNS-Antwort veraltet ist, wird eine neue DNS-Abfrage für diese Domain durchgeführt, die aufgrund des Verbots des Caching an den DNS-Server des Angreifers gesendet wird. Er antwortet, dass attacker.com nun eine neue IP-Adresse einer anderen Website zu haben scheint und die Anfrage an einen anderen Server geht. Um die vom Code gesammelten Informationen zurückzugeben, gibt der Angreifer in einer der folgenden DNS-Abfragen seine korrekte IP-Adresse an.

Teilnehmerin: Wäre es nicht klüger, einen gegenteiligen Angriff von opfer.com aus durchzuführen, um alle Cookies des Angreifers und dergleichen zu erhalten?

Professor: Ja, diese Option wird auch funktionieren. Auf diese Weise können Sie so gute Dinge wie das Scannen von Ports ausführen. Ich meine, Ihr Ansatz wird richtig funktionieren. Weil Sie attacker.com Schritt für Schritt ständig verschiedenen Computernamen und verschiedenen Ports im Opfer.com-Netzwerk zuweisen können. Mit anderen Worten, die attacker.com-Webseite wird immer denken, dass sie an attacker.com geht und von dort eine AJAX-Anfrage erhält.

Tatsächlich sendet der DNS-Server jedes Mal, wenn er sich erneut mit attacker.com verbindet, Anforderungen an eine andere IP-Adresse im Opfer.com-Netzwerk. Auf diese Weise kann er einfach nacheinander durch die IP-Adressen gehen und sehen, ob jemand auf diese Anfragen reagiert.

Zielgruppe: Der Benutzer, den Sie angreifen, hat jedoch nicht unbedingt internen Zugriff auf das Opfer.com-Netzwerk.

Professor: In der Regel besteht dieser Angriff darin, dass es bestimmte Firewall-Regeln gibt, die verhindern können, dass die externe Site attacker.com IP-Adressen im Opfer.com-Netzwerk anzeigt. Wenn Sie sich jedoch in einem Unternehmensnetzwerk wie corp.net hinter einer Unternehmensfirewall befinden, können Computer häufig eine Verbindung zu Computern außerhalb ihres Netzwerks herstellen.

Zielgruppe: Funktioniert diese Angriffsmethode über HTTPS?

Professor: Das ist eine interessante Frage! Tatsache ist, dass HTTPS Schlüssel verwendet. Wenn Sie HTTPS verwenden, verfügt der Computer des Opfers beim Senden einer AJAX-Anfrage nicht über die HTTPS-Schlüssel des Angreifers, und die Verschlüsselungsüberprüfung auf Opfer.com zeigt die Nichtübereinstimmung der Schlüssel an. Daher denke ich, dass HTTPS die Möglichkeit eines solchen Angriffs ausschließt.

Teilnehmerin: Was ist, wenn das Opfer nur HTTPS verwendet?

Professor: Ich denke, das wird den Angreifer aufhalten.

Zielgruppe: Warum antwortet ein Angreifer in erster Linie mit seiner IP-Adresse auf den Computer des Opfers?

Professor: Weil der Angreifer irgendwie seinen eigenen Code auf dem Computer des Opfers ausführen muss, bevor er weitere Maßnahmen ergreifen kann, um etwas im Netzwerk des Opfers zu finden. Aber lassen Sie uns keine Zeit verschwenden. Wenn Sie Fragen zur Neuzuweisung von DNS haben, kommen Sie nach dem Vortrag zu mir.

Wie können Sie das beheben? Eine Möglichkeit, diese Sicherheitsanfälligkeit zu beheben, besteht darin, den DNS-Client-Resolver so zu ändern, dass externe Hostnamen niemals auf interne IP-Adressen zugreifen dürfen.

Es ist irgendwie dumm, dass jemand außerhalb Ihres Netzwerks in der Lage sein sollte, ein DNS zu erstellen, das an etwas in Ihrem Netzwerk gebunden ist. Dies ist die einfachste Lösung.



Sie können sich vorstellen, dass der Browser so etwas wie "DNS-Pinning" oder DNS-Pinning ausführen kann. Wenn der Browser einen Datensatz mit aufgelöstem DNS empfängt, wird dieser Datensatz daher immer als gültig angesehen, z. B. für die Interaktion innerhalb von 30 Minuten, unabhängig davon, welche TTL der Angreifer zuweist, und kann auf diese Weise dem Angriff widerstehen.
Diese Lösung ist etwas kompliziert, da es Websites gibt, die absichtlich dynamisches DNS verwenden, um beispielsweise die Serverlast auszugleichen und dergleichen. Daher ist die erste Lösung mit DNS-Pinning die beste Option.

Und jetzt schauen wir uns an, was dieselbe Quellrichtlinie schützt. Was ist mit Pixeln? Wie schützt die Ursprungsrichtlinie Pixel?

Wie sich herausstellte, haben die Pixel tatsächlich keinen Ursprung. Somit erhält jeder Rahmen seinen eigenen kleinen Begrenzungsrahmen, im Grunde nur ein Quadrat, und der Rahmen kann überall in diesem Bereich zeichnen.

Dies ist tatsächlich ein Problem, da dies bedeutet, dass der übergeordnete Frame über den untergeordneten Frame zeichnen kann. Und dies kann wiederum zu sehr heimtückischen Angriffen führen.

Angenommen, ein Angreifer erstellt eine Seite mit der Aufschrift "Klicken Sie hier, um ein iPad zu gewinnen". Der gleiche Standardtrick. Dies ist der übergeordnete Frame.



Und dieser übergeordnete Frame kann einen untergeordneten Frame erstellen, der eigentlich der Frame der Schaltfläche "Gefällt mir" auf einer Facebook-Site ist. Auf Facebook können Sie also diesen kleinen Facebook-Code ausführen, den Sie auf Ihre Seite setzen können.

Sie wissen, wenn ein Benutzer auf "Gefällt mir" klickt, bedeutet dies, dass er zu Facebook geht und sagt: "Hey, ich mag diese bestimmte Seite"! Wir haben jetzt diesen untergeordneten Rahmen der Schaltfläche "Gefällt mir".



Jetzt kann ein Angreifer diesen Frame auf dem Bildschirmbereich überlagern, auf den der Benutzer klicken muss, um ein kostenloses iPad zu erhalten, und diesen Frame unsichtbar machen. CSS ermöglicht dies.

Was wird also passieren? Wie wir bereits installiert haben, möchte jeder ein kostenloses iPad bekommen. Der Benutzer wird diese Website aufrufen, indem er auf diesen Bereich des Bildschirms klickt und sicherstellt, dass er genau auf das klickt, was ihm das kostenlose iPad bietet. Tatsächlich klickt er jedoch auf den unsichtbaren Like-Button. Es ist, als würde man auf Index C legen.

Dies bedeutet, dass der Benutzer jetzt möglicherweise auf einem Facebook-Profil landet, in dem er feststellt, dass er attacker.com mochte. Weißt du, er wird sich nicht einmal daran erinnern, wie es passiert ist. Dies ist also ein sogenannter Click-Jacking-Angriff - Unterstützung für einen Click-Angriff. Auf die gleiche Weise können Sie viele schlechte Dinge tun - Passwörter stehlen, persönliche Daten abrufen, kurz gesagt, das ist verrückt. Ich betone - dies ist möglich, weil der übergeordnete Rahmen in der Lage ist, alles innerhalb dieses Begrenzungsrahmens zu zeichnen.

Der übergeordnete Frame ist also das, was Sie auf der Seite sehen, der Aufruf, ein kostenloses Tablet zu erhalten, und der untergeordnete Frame ist die Schaltfläche "Gefällt mir", die dem übergeordneten Frame transparent überlagert wird.

Für dieses Problem gibt es verschiedene Lösungen. Der erste besteht darin, den Frame-Busting-Code zu verwenden. Auf diese Weise können Sie mithilfe von JavaScript-Ausdrücken herausfinden, ob jemand seinen eigenen Frame in Ihren Frame eingebettet hat. Einer dieser Tests ist beispielsweise ein Vergleich der folgenden Form: if (self! = Top).

Hier bezieht sich die Selbstanweisung auf den oberen Rand des oberen Rahmens, der mit der Hierarchie des gesamten Rahmens verglichen wird. Wenn Sie diesen Test durchführen und feststellen, dass self nicht gleich dem oberen Rand des übergeordneten Frames ist, werden Sie verstehen, dass Sie einen untergeordneten Frame haben. In diesem Fall können Sie den Download ablehnen.

Dies geschieht, wenn Sie versuchen, einen Rahmen zu erstellen, z. B. für CNN.com. Wenn Sie sich den Quellcode für JavaScript ansehen, können Sie sehen, dass dieser Test durchgeführt wird, da CNN.com nicht möchte, dass andere Personen seinen Inhalt verwenden. Daher nimmt dieser Rahmen immer die höchste Position ein. Dies ist also eine der Lösungen, die hier verwendet werden können.

Die zweite Lösung besteht darin, dass Ihr Webserver als Antwort einen HTTP-Header mit dem Namen x-Frame options sendet. Wenn der Webserver eine Antwort zurückgibt, kann er daher diesen Header setzen, der besagt: "Hey, Browser, lass niemanden meinen Inhalt in den Frame einfügen!". Mit dieser Lösung kann der Browser Durchsetzungsaktionen ausführen.

Es ist also ziemlich einfach. Aber es gibt noch eine Menge anderer verrückter Angriffe, die Sie organisieren können.

Wie bereits erwähnt, führt die Tatsache, dass wir jetzt im internationalen Internet leben, zu Problemen bei der Verwendung eines Domain- oder Hostnamens.

Angenommen, wir haben den Buchstaben C. Aber in welcher Sprache? Aus welchem ​​Alphabet stammt dieser Buchstabe aus dem lateinischen ASCII oder ist es C in kyrillischer Sprache? Auf diese Weise können Sie Angriffe organisieren, die unterschiedliche Interpretationen und unterschiedliche, aber anscheinend ähnliche Buchstaben verwenden. Ein Angreifer registriert beispielsweise einen Cats.com-Domainnamen. Und Benutzer werden zu dieser Domain gehen und denken, dass sie die Site "Katzen. Com" besuchen werden, aber in Wirklichkeit werden sie zur Site des Angreifers "sats.com" gelangen, da der erste Buchstabe hier nicht lateinisch, sondern kyrillisch ist.

Ein Angreifer kann die Domain fcebook.com registrieren, aber die Leute sind unaufmerksam. Sie nehmen sie als facebook.com und gehen dorthin. Wenn Sie also Facebook.com kontrollieren, erhalten Sie eine Menge Verkehr von Personen, die glauben, bei Facebook angemeldet zu sein.



Es gibt eine Reihe verschiedener, verrückter Angriffe, die Sie über das Registrierungssystem für Domainnamen starten können und gegen die Sie sich nur schwer verteidigen können. Wie können Sie verhindern, dass Benutzer Tippfehler machen? Oder wie zeigt der Browser dem Benutzer an: "Hey, das ist kyrillisch, nicht lateinisch"!?

Wenn der Browser den Benutzer jedes Mal warnt, wenn kyrillische Schriftarten aktiviert werden, werden Personen verärgert, die tatsächlich kyrillische Schriftarten als native Schriftarten verwenden. Es ist daher nicht ganz klar, wie solche Probleme aus technischer Sicht gelöst werden können, weshalb hier sehr heikle Sicherheitsprobleme auftreten.

Eine weitere interessante Sache sind Plugins. Wie interagieren Plugins mit Ursprungsrichtlinien? Plugins sind in Bezug auf dieselbe Herkunftsquelle häufig nicht mit dem Rest des Browsers kompatibel. Wenn Sie sich beispielsweise das Java-Plug-In ansehen, wird davon ausgegangen, dass verschiedene Hostnamen mit derselben IP-Adresse auch denselben Ursprung haben.

Tatsächlich ist dies eine ziemlich große Abweichung von der Standardinterpretation von Richtlinien desselben Ursprungs. Dieser Ansatz bedeutet, dass Java davon ausgeht, dass sie dieselbe Herkunftsquelle haben, wenn Sie über xycom und zycom verfügen und diese auf dieselbe IP-Adresse projiziert werden. Dies kann ein Problem sein, da in Wirklichkeit eine Site eine vertrauenswürdige Herkunftsquelle hat und die andere nicht. Es gibt viele andere Schwierigkeiten im Zusammenhang mit Plugins, die Sie aus öffentlich zugänglichen Quellen im Internet oder aus den Vorlesungsunterlagen herausfinden können.

Das Letzte, was ich diskutieren möchte, ist ein Bildschirmfreigabeangriff oder ein Bildschirmfreigabeangriff.

HTML5 definiert tatsächlich eine neue API, mit der eine Webseite alle ihre Bits für die Freigabe mit einem anderen Browser oder Server freigeben kann. Dies scheint eine wirklich coole Idee zu sein, da mehrere Benutzer gleichzeitig an demselben Dokument arbeiten können. Das ist großartig, weil wir in der Zukunft leben.

Das Lustigste ist jedoch, dass sie bei der Entwicklung dieser neuen API überhaupt nicht an eine gemeinsame Quellrichtlinie gedacht haben!

Angenommen, Sie haben eine Seite, auf der sich mehrere Frames befinden, und jeder von ihnen hat das Recht, einen Screenshot Ihres gesamten Monitors zu erstellen. Er kann einen Screenshot aller auf dem Bildschirm befindlichen Frames und des gesamten Inhalts erstellen, unabhängig davon, aus welchen Quellen sie stammen.



Tatsächlich ist dies ein ziemlich zerstörerischer Fehler in der Politik derselben Herkunftsquelle, daher sollten Sie in Betracht ziehen, ihn zu beheben. Wenn eine Person aus dem richtigen Bild beispielsweise Screenshots machen kann, kann sie nur einen Screenshot des richtigen Rahmens und nicht des gesamten Bildschirms als Ganzes machen.

Warum haben die Browserentwickler das nicht so implementiert? Weil sie unter Wettbewerbsdruck stehen und gezwungen sind, ihre Bemühungen darauf zu konzentrieren, immer mehr neue Funktionen und Funktionen zu entwickeln, anstatt darauf zu achten, bereits entwickelte Dinge zu verbessern.

Viele Fragen, die Studenten im Internet zu dieser Vorlesung stellten, lauteten: „Warum haben die Entwickler nicht getan, was sie konnten? Ist das nicht klar? " oder: „Es scheint, dass dieses spezielle Schema tot ist. Wäre der andere nicht besser? " usw.

Ich sage es Ihnen ehrlich - ja, das ist sicher, fast alles wäre besser, wenn die Entwickler dies verantwortungsbewusst übernehmen würden. Ich schäme mich, dass ich damit verbunden bin.

Tatsache ist jedoch, dass wir dies zuvor hatten. Wenn Sie sich alle Elemente ansehen, die zuvor vorhanden waren, werden Sie feststellen, dass sich Webbrowser entwickeln und die Sicherheit der Menschen etwas größer geworden ist. Aber nicht bei der Bildschirmfreigabe, bei der die Entwickler so besorgt über die innovativen Funktionen des Browsers waren, dass sie die Möglichkeit eines kleinen Lecks völlig vergaßen.



Deshalb bitte ich Sie, immer auf die Dinge zu achten, die wir heute besprochen haben. Stellen Sie sich vor, wir würden von vorne anfangen, alles zerstören, was vor uns lag, und versuchen, eine bessere Sicherheitsrichtlinie zu entwickeln. Was denken Sie, wie viele Websites würden für uns funktionieren? Ich denke nicht mehr als 2%. Benutzer würden sich also wahrscheinlich über uns beschweren.

Es gibt eine weitere interessante Eigenschaft in Bezug auf Sicherheit.Sobald Sie Benutzern eine Funktion zugewiesen haben, ist es sehr schwierig, sie zurückzurufen, selbst wenn die Verwendung unsicher ist. Deshalb haben wir heute so viele Dinge im Zusammenhang mit der Herkunftspolitik besprochen, und wir werden in der nächsten Vorlesung weiter darüber sprechen.


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

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

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?