MIT-Kurs "Computer Systems Security". Vorlesung 14: „SSL und HTTPS“, Teil 2

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
Vorlesung 13: „Netzwerkprotokolle“ Teil 1 / Teil 2 / Teil 3
Vorlesung 14: „SSL und HTTPS“ Teil 1 / Teil 2 / Teil 3

Der erste Grund ist, dass das OCSP-Protokoll jeder von Ihnen gestellten Anforderung eine Verzögerung hinzufügt. Jedes Mal, wenn Sie eine Verbindung zu einem Server herstellen möchten, müssen Sie zuerst eine Verbindung zu OCSP herstellen, auf die Antwort warten und dann etwas anderes tun. Verbindungsverzögerungen tragen also nicht zur Popularität dieses Protokolls bei.

Der zweite Grund ist, dass OCSP Ihre Fähigkeit zum Surfen im Internet nicht beeinträchtigen soll. Angenommen, der OSCP-Server ist ausgefallen, und Sie können das Internet insgesamt verlieren, da das Protokoll berücksichtigt, dass möglicherweise alle Websites im Internet fehlerhaft sind und Sie nicht dorthin dürfen. Da dies jedoch niemand benötigt, sehen die meisten Kunden die Nichteinmischung von OCSP-Servern als positive Entwicklung an.



Dies ist aus Sicherheitsgründen wirklich schlecht. Wenn Sie ein Angreifer sind und jemanden davon überzeugen möchten, dass Sie über ein legales Zertifikat verfügen, dieses Zertifikat jedoch widerrufen wurde, müssen Sie lediglich verhindern, dass der Client mit dem OCSP-Server kommuniziert.

Der Client sagt Folgendes: "Ich versuche, eine Zertifikatsüberprüfung der von mir benötigten Site anzufordern, aber diese OCSP befindet sich anscheinend nicht in der Nähe, daher gehe ich einfach zu dieser Site." Die Verwendung von OCSP ist also kein guter Plan.

In der Praxis versuchen die Menschen, diese Alternative zu schaffen, weil Kunden einfach dazu neigen, schwerwiegende Fehler zu machen. So wird beispielsweise der Chrome-Webbrowser an den Client geliefert, der bereits eine Liste von Zertifikaten enthält, die Google wirklich widerrufen möchte. Wenn also jemand fälschlicherweise ein Zertifikat für Google Mail oder eine andere wichtige Website wie Facebook oder Amazon ausstellt, enthält die nächste Version von Chrome diese Informationen bereits in der integrierten Bestätigungsliste. Auf diese Weise müssen Sie nicht auf den CRL-Server zugreifen und mit OCSP kommunizieren. Wenn der Browser überprüft hat, dass das Zertifikat nicht mehr gültig ist, lehnt der Client es ab.

Student: Nehmen wir an, ich habe den geheimen CA-Schlüssel gestohlen, weil nicht alle öffentlichen Schlüssel verschlüsselt sind.

Professor: Ja, das wird schlimme Konsequenzen haben. Ich glaube nicht, dass es eine Lösung für dieses Problem gibt. Natürlich gab es Situationen, in denen Zertifizierungszentren kompromittiert wurden. Beispielsweise gab es 2011 zwei kompromittierte Zertifizierungsstellen, die Zertifikate für Google Mail, Facebook usw. ausgestellt haben. Es ist nicht klar, wie das passiert ist, vielleicht hat jemand wirklich seinen geheimen Schlüssel gestohlen. Unabhängig von den Gründen für den Kompromiss wurden diese Zertifizierungsstellen aus der Liste der vertrauenswürdigen Zertifizierungsstellen entfernt, die in Browsern integriert ist, sodass sie in der nächsten Version von Chrome nicht mehr enthalten waren.

Tatsächlich verursachte dies den legitimen Inhabern von Zertifikaten, die von diesen Zentren ausgestellt wurden, Probleme, da ihre vorherigen Zertifikate ungültig wurden und sie neue Zertifikate erhalten mussten. In der Praxis ist all diese Aufregung mit Zertifikaten eine ziemlich verwirrende Angelegenheit.

Wir haben also das allgemeine Prinzip der Zertifikate untersucht. Sie sind besser als Kerberos in dem Sinne, dass Sie diesen Kerl nicht mehr brauchen, um die ganze Zeit online zu sein. Darüber hinaus sind sie skalierbarer, da Sie mehrere KDCs haben können und nicht jedes Mal, wenn Sie eine Verbindung herstellen, mit ihnen kommunizieren müssen.

Ein weiteres interessantes Merkmal dieses Protokolls ist, dass Sie im Gegensatz zu Kerberos nicht beide Seiten der Verbindung authentifizieren müssen. Sie können eine Verbindung zum Webserver herstellen, ohne über ein Zertifikat zu verfügen. Dies geschieht ständig. Wenn Sie zu amazon.com gehen, werden Sie überprüfen, ob Amazon die richtige Website ist. Amazon hat jedoch keine Ahnung, wer Sie sind, und wird es erst erfahren, wenn Sie sich bei der Website authentifizieren. Auf der Ebene des Verschlüsselungsprotokolls haben Sie also kein Zertifikat, aber Amazon hat eines.

Dies ist viel besser als Kerberos, da Sie dort einen Eintrag in der Datenbank haben müssen, um eine Verbindung zu Kerberos-Diensten herzustellen. Die einzige Unannehmlichkeit bei der Verwendung dieses Protokolls besteht darin, dass der Server über ein Zertifikat verfügen muss. Sie können sich also nicht mit dem Server verbinden und sagen: "Hey, verschlüsseln wir einfach unsere Sachen. Ich habe keine Ahnung, wer du bist, aber du hast keine Ahnung, wer ich bin, aber lass es uns trotzdem verschlüsseln. “ Dies wird als opportunistische Verschlüsselung bezeichnet und ist natürlich anfällig für Man-in-the-Middle-Angriffe. Sie können gemeinsame Dinge mit jemandem verschlüsseln, ohne ihn zu kennen. Dann kann ein Angreifer, der sich auf einen Angriff vorbereitet, später auch seine Pakete verschlüsseln und sich vor Schnüffeln schützen.

Es ist daher etwas schade, dass diese Protokolle, die wir hier in Betracht ziehen - SSL, TLS - diese Art der opportunistischen Verschlüsselung nicht bieten. Aber so ist das Leben.



Student: Ich bin nur neugierig. Sagen wir einfach, dass sie einmal im Jahr Schlüsselpaare mit neuen Namen erstellen. Warum nicht versuchen, diesen speziellen Schlüssel das ganze Jahr über zu verwenden?

Professor: Ich denke, das tun sie. Aber mit dieser Schaltung scheint etwas schief zu laufen. Hier, wie bei Kerberos, verwenden die Leute zunächst eine starke Verschlüsselung, aber mit der Zeit wird es immer schlimmer. Computer werden schneller, neue Algorithmen werden entwickelt, die diese Verschlüsselung erfolgreich knacken. Und wenn es den Menschen nicht darum geht, die Zuverlässigkeit zu verbessern, wachsen die Probleme. So kommt es beispielsweise vor, wenn eine große Anzahl von Zertifikaten signiert ist.

Hier gibt es zwei Nuancen. Es gibt ein Signaturschema für öffentliche Schlüssel. Angesichts der Tatsache, dass der verschlüsselte öffentliche Schlüssel einige Einschränkungen aufweist, wird beim Signieren einer Nachricht in Wirklichkeit nur der Hash dieser Nachricht signiert, da es schwierig ist, eine gigantische Nachricht zu signieren, es jedoch einfach ist, einen kompakten Hash zu signieren.

Das Problem trat auf, weil die Leute MD5 als Hash-Funktion verwendeten und das Signieren einer großen Nachricht in eine 128-Bit-Sache verwandelten, die verschlüsselt wurde. Vielleicht war MD5 vor 20 Jahren gut, aber im Laufe der Zeit entdeckten die Leute Schwächen darin, die von einem Angreifer ausgenutzt werden konnten.

Angenommen, irgendwann hat jemand wirklich nach einem Zertifikat mit einem bestimmten MD5-Hash gefragt und dann eine andere Nachricht, die mit demselben MD5-Wert gehasht wurde, sorgfältig analysiert. Infolgedessen hatte er eine gehashte CA-Signatur, und dann erschien eine andere Nachricht oder ein anderer Schlüssel oder ein anderer Name, und jetzt kann er jemanden davon überzeugen, dass sie mit dem richtigen Zertifikat signiert ist. Und das passiert wirklich. Wenn Sie beispielsweise viel Zeit damit verbringen, einen Schlüssel zu knacken, werden Sie letztendlich Erfolg haben. Wenn dieses Zertifikat verschlüsselt ist, kann es mit der Brute-Force-Methode geknackt werden.

Ein weiteres Beispiel für die erfolglose Verwendung der Verschlüsselung ist der RSA-Algorithmus. Wir haben nicht über RSA gesprochen, aber RSA ist eines dieser kryptografischen Systeme mit öffentlichem Schlüssel, mit dem Sie Nachrichten verschlüsseln und signieren können. Heutzutage können Sie viel Geld ausgeben, aber am Ende knacken Sie 1000-Bit-RSA-Schlüssel. Sie werden wahrscheinlich eine gigantische Menge an Arbeit erledigen müssen, aber dies ist das ganze Jahr über einfach zu erledigen. Sie können die Zertifizierungsstelle bitten, eine Nachricht zu signieren oder sogar den vorhandenen öffentlichen Schlüssel einer anderen Person zu übernehmen, den entsprechenden geheimen Schlüssel dafür zu finden oder ihn manuell zu hacken.
Sie müssen also mit dem Angreifer Schritt halten, größere RSA-Schlüssel verwenden oder ein anderes Verschlüsselungsschema verwenden.

Beispielsweise verwenden Benutzer derzeit keine MD5-Hashes und -Zertifikate. Sie verwenden den kryptografischen SHA-1-Hashing-Algorithmus. Für einige Zeit bot es die notwendige Sicherheit, aber heute ist es eine schwache Verteidigung. Jetzt versucht Google aktiv, Web- und Browserentwickler zu zwingen, die Verwendung von SHA-1 aufzugeben und eine andere Hash-Funktion zu verwenden, da klar ist, dass es möglicherweise nach 5 oder 10 Jahren nicht schwierig sein wird, SHA-1 erfolgreich anzugreifen. Seine Schwäche wurde bereits bewiesen.

Ich denke also, die magische Kugel als solche existiert nicht. Sie müssen nur sicherstellen, dass Sie sich parallel zu den Hackern weiterentwickeln. Natürlich besteht das Problem. Daher sollten alle Dinge, über die wir gesprochen haben, auf einer ordnungsgemäßen Verschlüsselung oder auf der Tatsache basieren, dass es sehr schwierig ist, sie zu knacken. Daher müssen Sie die entsprechenden Optionen auswählen. Zumindest gibt es ein Ablaufdatum, daher ist es besser, ein Ablaufdatum von 1 Jahr anstelle von 10 Jahren zu wählen.



Dieser CAs-Schlüssel verursacht ein schwerwiegenderes Problem, da er kein Ablaufdatum hat. Daher sollten Sie aggressivere Sicherheitseinstellungen wählen, z. B. 4000- oder 6000-Bit-RSA-Schlüssel oder etwas anderes. Oder ein anderes Verschlüsselungsschema oder alle zusammen, aber verwenden Sie SHA-1 hier nicht.

Nun wollen wir sehen, wie wir dieses Protokoll in eine bestimmte Anwendung integrieren, nämlich in einen Webbrowser. Wenn Sie Netzwerkkommunikation oder Kommunikation mit Websites mithilfe von Kryptografie bereitstellen möchten, müssen wir drei Dinge im Browser schützen.

Das erste, A ist der Datenschutz im Netzwerk. Dies ist relativ einfach, da wir nur ein Protokoll ausführen werden, das dem bisher beschriebenen sehr ähnlich ist. Wir werden alle Nachrichten verschlüsseln, unterschreiben und sicherstellen, dass sie nicht manipuliert wurden. Im Allgemeinen werden wir all diese wunderbaren Dinge tun. So schützen wir die Daten.

Aber es gibt noch zwei weitere Dinge im Webbrowser, über die wir uns wirklich Sorgen machen müssen. Das erste, B, ist der Code, der im Browser verwendet wird, z. B. JavaScript oder wichtige Daten, die im Browser gespeichert sind, Ihre Cookies oder der lokale Speicher. All dies muss irgendwie vor Hackern geschützt werden. In einer Sekunde werde ich Ihnen sagen, wie Sie sie schützen können.

Das letzte, C, an das Sie oft nicht denken, das sich jedoch in der Praxis als echtes Problem herausstellen kann, ist der Schutz der Benutzeroberfläche. Der Grund dafür ist, dass letztendlich die meisten vertraulichen Daten, die uns am Schutz liegen, vom Benutzer stammen. Der Benutzer druckt also Daten auf einer Site und hat wahrscheinlich mehrere Registerkarten verschiedener Sites gleichzeitig geöffnet. Daher muss er zu einem bestimmten Zeitpunkt unterscheiden können, mit welcher Site er tatsächlich interagiert.



Wenn er versehentlich in einem Webforum das Amazon-Passwort eingibt, führt dies nicht zu katastrophalen Folgen, je nachdem, wie sehr er sich um sein Amazon-Passwort kümmert, aber es ist trotzdem unangenehm. Daher möchten Sie wirklich eine gute Benutzeroberfläche haben, die dem Benutzer hilft, zu verstehen, was er tut, ob er vertrauliche Daten auf der richtigen Site druckt und ob mit diesen Daten etwas passiert, nachdem er sie gesendet hat. Dies stellt sich als ziemlich wichtiges Thema für den Schutz von Webanwendungen heraus.

Sprechen wir also darüber, was moderne Browser mit diesen Dingen A, B und C machen. Wie bereits erwähnt, verwenden wir zum Schutz der Daten im Netzwerk einfach dieses Protokoll, das als SSL oder TLS bezeichnet wird, wenn Verschlüsselung und Datenauthentifizierung verwendet werden.



Dies ist sehr ähnlich zu dem, was wir besprochen haben, und schließt Zertifizierungsstellen usw. ein. Und dann gibt es natürlich noch viele weitere Details. Zum Beispiel ist TLS äußerst komplex, aber wir werden es unter diesem Gesichtspunkt nicht betrachten. Wir werden uns auf den Browserschutz konzentrieren, der viel interessanter ist. Wir müssen sicherstellen, dass Code oder Daten, die über unverschlüsselte Verbindungen übermittelt werden, den von einer verschlüsselten Verbindung empfangenen Code und die von einer verschlüsselten Verbindung empfangenen Daten nicht ändern können, da unser Bedrohungsmodell so ist, dass alle unverschlüsselten Daten von einem Angreifer über das Netzwerk manipuliert werden können.

Wenn wir also einen unverschlüsselten JavaScript-Code haben, der in unserem Browser ausgeführt wird, sollten wir davon ausgehen, dass er von einem Angreifer manipuliert wurde, weil er nicht verschlüsselt war. Es wurde nicht über das Netzwerk authentifiziert. Daher müssen wir verhindern, dass Seiten gestört werden, die über eine unverschlüsselte Verbindung bereitgestellt wurden.

Der allgemeine Plan ist daher, dass wir hierfür ein neues URL-Schema einführen, das wir HTTPS nennen werden. Sie sehen dies oft in den URLs. Das neue URL-Schema sieht vor, dass sich diese URLs jetzt einfach von HTTP-Adressen unterscheiden. Wenn Sie also eine URL mit diesem HTTPS: // haben, hat diese eine andere Ursprungsquelle als normale HTTP-URLs, da letztere unverschlüsselte Patches und SSL / TLS durchlaufen. Auf diese Weise werden Sie diese Adresstypen niemals verwechseln, wenn dieselbe Ursprungsrichtlinie ordnungsgemäß funktioniert.

Das ist also ein Teil des Puzzles. Dann müssen Sie aber auch sicherstellen, dass Sie verschlüsselte Sites korrekt voneinander unterscheiden, da sie aus historischen Gründen unterschiedliche Cookie-Richtlinien verwenden. Lassen Sie uns zunächst darüber sprechen, wie wir verschiedene verschlüsselte Sites voneinander unterscheiden.

Der Plan ist, dass der Hostname über die URL der Name im Zertifikat sein sollte. Tatsächlich stellt sich heraus, dass die Zertifizierungsstellen den Hostnamen signieren werden, der in der URL als Name des öffentlichen Schlüssels des Webservers angezeigt wird. Als solches besitzt Amazon angeblich ein Zertifikat für www.amazon.com . Dies ist der Name in unserer Tabelle, dessen öffentlicher Schlüssel dem privaten Schlüssel entspricht.



Dies ist, wonach der Browser suchen wird. Wenn er also ein Zertifikat erhält und versucht, eine Verbindung herzustellen oder die foo.com-URL abzurufen , bedeutet dies, dass der Server das authentische foo.com-Zertifikat korrekt darstellt. Ansonsten haben wir beispielsweise versucht, einen Mann zu kontaktieren, und einen anderen kontaktiert, weil er in dem Zertifikat, mit dem wir verbunden sind, einen völlig anderen Namen hat. Dies ist eine Zertifikatsinkongruenz.

So unterscheiden wir verschiedene Sites voneinander: Wir werden CA dazu bringen, diese Sites voneinander zu unterscheiden, da CAs versprechen, Zertifikate nur an die richtigen Netzwerkmitglieder auszustellen. Dies ist also Teil derselben Ursprungsrichtlinie, nach der wir den Code in Teile aufteilen. Wie Sie sich erinnern, gelten für Cookies etwas andere Richtlinien. Sie sind fast gleicher Herkunft, aber nicht ganz, Cookies haben einen etwas anderen Plan. Cookies haben eine sogenannte Sicherheitsflagge, die sichere Flagge. Die Regel lautet: Wenn Cookies dieses Flag haben, werden sie nur als Antwort auf HTTPS-Anforderungen oder zusammen mit HTTPS-Anforderungen gesendet. Cookies mit und ohne Sicherheitsflag beziehen sich als https- und http-Anforderungen aufeinander.



Das ist etwas kompliziert. Es wäre einfacher, wenn ein Cookie lediglich anzeigt, dass es sich um ein Cookie für den HTTPS-Host handelt, und es sich um ein Cookie für den HTTP-Host handelt, und sie sind völlig unterschiedlich. Dies wäre sehr klar im Hinblick auf die Isolierung sicherer Websites von unsicheren. Leider verwenden Cookies aus historischen Gründen diese seltsame Art der Interaktion.

Wenn ein Cookie als sicher markiert ist, gilt es daher nur für HTTPS-Sites, dh es hat den richtigen Host. Sichere Cookies gelten nur für HTTPS-Host-URLs, während unsichere Cookies für beide Arten von URLs gelten, sowohl für https als auch für http. In nur einer Sekunde wird dies für uns zu einer Problemquelle.

Und die letzte Berührung, die Webbrowser unternommen haben, um uns in dieser Hinsicht zu helfen, ist der Aspekt der Benutzeroberfläche, in dem sie eine Art Schlosssymbol eingeben, damit Benutzer es sehen können. Achten Sie daher auf das Schlosssymbol in der Adressleiste des Browsers und die URL, um herauszufinden, auf welcher Site Sie sich tatsächlich befinden.

Webbrowser-Entwickler erwarten, dass Sie sich folgendermaßen verhalten: Sobald Sie zu einer Website gelangen, überprüfen Sie zunächst die URL und stellen sicher, dass dies der Name des Hosts ist, mit dem Sie sprechen möchten. Anschließend finden Sie das Schlosssymbol und Verstehe, dass alles in Ordnung ist. Dies ist ein Aspekt der Benutzeroberfläche des Browsers.

Dies reicht jedoch nicht aus. Es stellt sich heraus, dass viele Phishing-Sites einfach das Bild des Schlosssymbols in die Site selbst aufnehmen, aber eine andere URL verwenden. Und wenn Sie nicht wissen, wie die Adresse dieser Website lauten soll, werden Sie möglicherweise getäuscht. In diesem Sinne ist diese Seite der Benutzeroberfläche etwas verwirrend, auch weil die Benutzer selbst oft verwirrt sind. Es ist also schwer zu sagen, was hier richtig ist. Daher konzentrieren wir uns hauptsächlich auf den zweiten Aspekt, B, der sicherlich viel einfacher zu diskutieren ist. Haben Sie Fragen dazu?



Student: Ich habe festgestellt, dass sich einige Websites im Laufe der Zeit von HTTP zu HTTPS ändern.

Professor: Ja, Browser entwickeln sich im Laufe der Zeit weiter. Dies wird durch die Tatsache bestätigt, dass sie ein Schlosssymbol erhalten. Einige Browser setzen nur dann ein Schlosssymbol, wenn alle Inhalte oder Ressourcen auf Ihrer Seite auch über https übertragen werden. Eines der Probleme, die HTTPS mit Gewalt zu lösen versucht, sind gemischte Inhalte oder Probleme mit unsicheren Arten von Inhalten, die in die Seite eingebettet sind. Daher können Sie aufgrund dieser Prüfung manchmal kein Schlosssymbol erhalten. Wenn der Chrome-Browser der Ansicht ist, dass das Site-Zertifikat nicht gut genug ist und eine schwache Kryptografie verwendet, wird kein Schlosssymbol angezeigt. Unterschiedliche Browser verhalten sich jedoch unterschiedlich. Wenn Chrome kein Schlosssymbol anzeigt, kann Firefox dies. Daher gibt es wiederum keine klare Definition der Bedeutung dieses Schlosssymbols.

Mal sehen, welche Probleme bei der Umsetzung dieses Plans auftreten können. Bei normalem HTTP sind wir es gewohnt, uns auf DNS zu verlassen, das uns die richtige IP-Adresse auf dem Server geben sollte. DNS HTTPS URL-? DNS DNS?

: , , , IP-.

: , , , amazon.com.

: , - amazon.com, IP-.

: , , – - DNS . , DNS , . , DNS , IP-, . , - DNS- IP-? ?

: , HTTPS?

: , , .

: , HTTP URL.

: , HTTPS, .

: .

: , . . , CA, , , , - , .

, - https , - , , , , , , .

HTTPS , - . , . , , , . -. « , ». , , , - , . , - .

, , , . , amazon.com www.amazon.com , , , .

-, , , . , : „ , , , , ». , - , . .

, DNS, , , .

, , DNS, . , DNS-, SSL / TLS HTTPS, DNS . , DNS . DoS , , .

, — , ? , , ? , ?



: , - , . , .

: , , , , , , : « »! , , - , , , , . , .

: , .

: , . . , , , , , cookies, , URL-, , origin. , - amazon.com , , , , amazon.com. , amazon.com, , , , , , JavaScript .

, , -. , . - amazon.com «» . , amazon.com, , , , . . , , .

52:10

MIT « ». 14: «SSL HTTPS», 3


Die Vollversion des Kurses finden Sie hier .

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 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 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?