MIT-Kurs "Computer Systems Security". Vorlesung 8: Netzwerksicherheitsmodell, 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

Was passiert also, wenn der Browser das Objekt nicht korrekt verarbeitet und seinen Typ nicht identifizieren kann? In diesem Fall können Sicherheitsprobleme auftreten. Einer von ihnen wird als MIME-Angriff bezeichnet.

Sie sind wahrscheinlich mit MIME vertraut - dies ist eine Art unverschlüsselter Header wie text / html, image.jpeg und so weiter. Ältere Versionen des IE-Browsers verwendeten dies, weil sie dachten, es würde dem Benutzer helfen. Manchmal kommt es jedoch vor, dass die Webserver der Objektdatei die falsche Erweiterung zuweisen.

Ein falsch konfigurierter Webserver kann das Suffix .html an die tatsächliche Erweiterung .jpeg anhängen oder umgekehrt beispielsweise foo.jpg anstelle von foo.html erstellen.



In den alten Tagen hat IE versucht, Ihnen zu helfen. Das heißt, er ging, um eine Art Ressource zu nehmen, während er dachte: "OK, diese Ressource behauptet, gemäß ihrer Dateinamenerweiterung von diesem Typ zu sein." Dann betrachtet er jedoch nur die ersten 256 Bytes, die in diesem Objekt verfügbar sind. Und wenn er dort bestimmte magische Bedeutungen fand, die darauf hinwiesen, dass es für dieses Objekt eine andere Art von Erweiterung gab, würde er einfach sagen: „Hey, ich habe hier etwas Cooles gefunden! "Ich denke, der Webserver hat dieses Objekt fälschlicherweise definiert. Lassen Sie mich dieses Objekt einfach als den Typ behandeln, den ich in diesen ersten 256 Bytes gefunden habe."
Und dann wird jeder zum Gewinner, denn ein Browser wie hat dem Entwickler des Webservers geholfen, da nun seine Seite richtig angezeigt wird. Und der Benutzer wird es mögen, weil er diesen Inhalt freischalten kann, der früher nur Müll war.

Dies ist jedoch eine eindeutige Sicherheitslücke! Angenommen, die Seite enthält passiven Inhalt, z. B. ein Bild aus einer von einem Angreifer kontrollierten Domäne. Auf der Seite des Opfers heißt es jedoch: "Auch wenn es sich um den Inhalt einer böswilligen Hacker-Website handelt, handelt es sich nur um passiven Inhalt." Er kann mir nichts antun! “ Im Extremfall wird ein nicht erfolgreiches Bild angezeigt, es kann jedoch kein Code geöffnet werden, da passiver Inhalt keine Berechtigungen hat.



Tatsache ist jedoch, dass der IE dieses Bild, seine ersten 256 Bytes, zuerst "schnüffeln" kann. Und ein Angreifer kann dort absichtlich HTML- und JavaScript-Code einfügen. Dann stellt sich heraus, dass die Website des Opfers ein Bild enthält, das es für ein Bild hält, und der IE im Kontext der eingebetteten Seite schädlichen Code ausführt.

Dies ist eine Art Beispiel dafür, wie komplex Browser sind und wie das Hinzufügen selbst sehr guter Absichten zu sehr subtilen Sicherheitsfehlern führen kann. Schauen wir uns also genauer an, wie der Browser verschiedene Ressourcen schützt.

Schauen wir uns die Frames und Fensterobjekte an (Objekte, die ein Fenster sind, das ein DOM-Dokument enthält). Frames repräsentieren diese unabhängigen JavaScript-Universen, über die wir hier gesprochen haben. Ich meine, JavaScript ist eine Instanz des DOM-Knotens, wie im Bild des DOM-Baums gezeigt.

Auf diese Weise existiert der Frame als DOM-Knotenobjekt irgendwo in dieser Hierarchie, die für JavaScript sichtbar ist.

In JavaScript ist das Fensterobjekt tatsächlich ein Alias ​​für den globalen Namespace. Es klingt nach einer dummen Idee. Das heißt, wenn Sie den Namen der globalen Variablen x finden würden, könnten Sie auch über den Namen window.x darauf zugreifen.

Daher sind Frames und Fensterobjekte sehr leistungsfähige Referenzen, um Ihnen den Zugriff zu erleichtern. Und sie enthalten Zeiger aufeinander. Ein Frame kann einen Zeiger auf ein verknüpftes Fensterobjekt enthalten und umgekehrt. In der Tat sind diese beiden Dinge gleichwertig.
Sowohl Frames als auch Fensterobjekte erhalten den Ursprungsursprungsursprung vom URL-Frame. Da sie sich immer in einem sicheren Teil des Netzwerks befinden, können sie das Suffix des ursprünglichen Domainnamens, dh seines ursprünglichen Ursprungs, erhalten.

Ein Frame kann beispielsweise folgendermaßen beginnen: .xyzcom. Hier können Sie das Schema und das Protokoll für eine Sekunde ignorieren.

In diesem Fall können wir davon ausgehen, dass die Ursprungsquelle für (document.domain) das Suffix yzcom ist. Ebenso ist die Ursprungsquelle für dieses Dokument der Ausdruck z.com. Dies ist möglich, da z.com ein Suffix von yzcom ist.



Das einzige, was nicht als solche Quelle dienen kann, ist der Ausdruck .ayzcom, da er das falsche Suffix für die Herkunftsquelle ist. Außerdem kann das korrekte Quellensuffix der Ursprungsquelle nicht einfach als .com betrachtet werden, da die Website in diesem Fall Cookies oder ähnliches auf Websites wie .com irgendwie beeinflussen kann, was ziemlich verheerende Folgen haben kann.

Die Motivation dafür, warum diese Art von Dingen akzeptabel ist, besteht darin, dass sie mit einer bestehenden Vertrauensbeziehung zusammenhängen. Es scheint also, dass mit den drei wichtigsten Parametern alles in Ordnung ist und die Störung nur in .com vorliegt.

Teilnehmerin: Es stellt sich heraus, dass es möglich ist, solche Aufteilungen an jedem Punkt oder am Endpunkt vorzunehmen. Kann Ihr xyzcom beispielsweise in Ihr z.com geändert werden?

Professor: Nein, das gilt nur für jeden Punkt.



Zielgruppe: Gibt es einen Grund, warum dies nicht getan wurde, um eine Super- oder Subdomain anzugeben, aber gleichzeitig sollten sie sich irgendwie darauf einigen, woher die Informationen kommen? Nehmen wir an, ich möchte nur das akzeptieren, was denselben Ursprung hat wie ich, damit mich jede dieser Ressourcen angreifen kann. Außerdem würden wir diese Interaktion symmetrisch machen, damit ich sie auch beeinflussen kann. Schließlich bedeutet das Quellensuffix .com, dass alles, was dasselbe .com-Suffix hat, mich beeinflussen kann.

Professor: Ja, das ist schwierig, daher gibt es mehrere Antworten auf diese Frage. Erstens waren die Leute sehr besorgt über die Möglichkeit eines Angriffs mit .com. Daher wollten sie die Sprache der Domänenmanipulation leicht verständlich machen. Daher erlaubten sie nicht, die Einstellungen zu verderben.

In einer Sekunde werde ich über eine Sache sprechen, mit der Sie das tun können, worüber Sie sprechen, aber nur über Domain-Suffixe. Im Moment möchte ich darauf hinweisen, dass die Post-Message-Oberfläche es Domänen ermöglicht, miteinander zu kommunizieren, wenn sie dem zustimmen. In der Praxis verwenden Benutzer Post Message, um eine domänenübergreifende Kommunikation zu implementieren, wenn sie mit den oben beschriebenen Tricks nicht dieselbe Herkunftsquelle ermitteln können. Auf diese Weise können Browser Domänen gemäß diesen Suffixen der Quelldomäne einschränken. Und hier gibt es auch eine kleine interessante Nuance - Browser verstehen, wann (document.domain) geschrieben werden kann und wann nicht.

Dafür gibt es einen Grund, den wir gleich betrachten werden. Somit können zwei Frames aufeinander zugreifen, wenn mindestens eine der folgenden beiden Bedingungen erfüllt ist:

• beide Framesätze setzen (document.domain) den gleichen Wert;
• Keiner dieser Frames kann sich ändern (document.domain), obwohl der Wert dieses Dokuments in beiden Frames gleich ist.

Die Hauptidee dieser Regeln ist, dass sie die Domain vor Angriffen schützen, die durch ihre eigenen Fehler oder die Schädlichkeit einer der Subdomains verursacht werden.

Stellen Sie sich vor, Sie haben eine xyzcom-Domain, die versucht, die yzcom-Domain anzugreifen, weil die erste Domain einen Fehler enthält oder böswillig ist. Er wird versuchen, die yzcom-Domain auf ein .com-Aussehen zu verkürzen, und dann beginnen, mit dem Status von JavaScript, Cookies oder anderen Dingen zu „chemisieren“.



Diese beiden Regeln bedeuten also, dass wenn yzcom niemandem erlauben möchte, mit ihm zu interagieren, der Wert (document.domain) niemals geändert wird. Wenn der xyzcom-Frame ihn kürzen möchte, sagt der Browser: "Ja, Sie möchten ihn kürzen, aber Sie haben kein Recht dazu!" Es gibt ein Zusammentreffen von Werten, aber die yzcom-Domain hat nicht angegeben, dass sie daran teilnehmen möchte. Das ist klar? In diesem Fall ist ersichtlich, dass die meisten Frames mit derselben Ursprungsrichtlinie arbeiten.

Jetzt können wir sehen, wie unser DOM-Knoten verarbeitet wird. Es ist ziemlich einfach. In der Regel erhalten DOM-Knoten ihren Ursprung im umgebenden Frame. Bei Cookies ist dies etwas komplizierter. Cookies haben eine Domain und sie haben ihren eigenen Weg. Sie können sich beispielsweise vorstellen, dass ein Cookie mit den folgenden Informationen verknüpft ist, z. B. * .mit.edu / 6.858. In diesem Fall hat das Cookie eine * .mit.edu / domain und einen Pfad 6.858.



Bitte beachten Sie, dass diese Domain möglicherweise das vollständige Suffix der Seiten in der aktuellen Domain ist. Sie können also mit ihm dieselben Tricks ausführen wie mit denen, über die wir zuvor gesprochen haben. Beachten Sie, dass dieser Pfad 6.858 auch als Schrägstrich gefolgt von nichts dargestellt werden kann, was darauf hinweist, dass alle Domänenpfade Zugriff auf das hier befindliche Cookie haben müssen.

In diesem Fall haben wir jedoch eine bestimmte Pfadadresse. Wer diese Cookies setzt, kann sehen, wie die Domain und der Pfad aussehen. Diese Werte können sowohl auf der Serverseite als auch auf der Clientseite festgelegt werden. Auf der Clientseite haben Sie ein JavaScript-Objekt namens document.cookie. In diesem Format werden alle Pfade zu ähnlichen Objekten angegeben.

Es gibt ein Sicherheitsflag mit sicherem Flag, das Sie für ein Cookie setzen können, um anzuzeigen, dass es sich um eine HTTPS-Datei handelt. In diesem Fall sollte der HTTP-Inhalt keinen Zugriff auf dieses Cookie haben. Dies ist die Hauptidee von Cookies.

Bitte beachten Sie, dass ein Browser, wenn er eine Anfrage an einen bestimmten Webserver generiert, alle relevanten Cookies in diese Anfrage einbezieht. Es gibt eine Art Korrespondenz und Algorithmen, die es ermöglichen, herauszufinden, dass dies die richtigen Cookies sind, die als Antwort auf eine Anfrage gesendet werden sollten, da sie möglicherweise seltsame Dinge mit Domain-Suffixen usw. enthalten.

Zielgruppe: Können Frames auf die Cookies des anderen zugreifen, wenn sie diesen Regeln entsprechen?

Professor: Ja, Frames können das. Dies hängt jedoch davon ab, wie document.domain, die Cookie-Domäne und der Pfad festgelegt sind. Frames können also auf die Cookies des anderen zugreifen, daher stellt sich die Frage: Kann es ein Problem geben, wenn wir zulassen, dass beliebige Frames beliebige Cookies an Personen schreiben? Es genügt zu sagen, dass es schlecht sein wird. Der Grund, warum dies schlecht ist, liegt darin, dass diese Cookies es der Client-Seite der Anwendung ermöglichen, Benutzerdaten zu speichern.

Sie können sich also vorstellen, dass ein Angreifer, wenn er Benutzer-Cookies steuern oder überschreiben kann, beispielsweise das Cookie für Google Mail so ändern kann, dass sich der Benutzer über das Google Mail-Konto dieses Angreifers anmeldet. In diesem Fall könnte jeder Benutzerbrief von einem Angreifer gelesen werden. Sie können sich vorstellen, dass jemand Cookies von Amazon.com erhalten kann, um alle Arten von lächerlichen Einkäufen und dergleichen in Ihren Warenkorb zu legen.

Cookies sind daher eine sehr wichtige Ressource für den Schutz. Und viele Netzwerksicherheitsangriffe sind darauf ausgelegt, sie zu stehlen und ihnen Schaden zuzufügen.
Es gibt noch eine weitere interessante Frage zu Cookies. Angenommen, Sie haben eine Website foo.co.uk. Was ist, wenn eine Site mit diesem Hostnamen Cookies für co.uk setzen kann?



Es gibt hier eine Subtilität in Bezug auf die Regeln, die wir zuvor besprochen haben, da die erste Site in der Lage sein sollte, ihre Domain zu verkürzen und Cookies für die zweite zu setzen. Hier scheint alles legal zu sein. Aber aus menschlicher Sicht betrachten wir es mit Argwohn, weil wir verstehen, dass co.uk eine einzelne atomare Domäne ist. Dies entspricht jedoch .com. Wir können sagen, dass die Briten es vermasselt haben, dass sie hier einen Punkt haben sollten. Aber das ist nicht ihre Schuld. Aus moralischer Sicht ist dies eine einzelne Domäne, die nicht gebrochen werden kann. Daher müssen wir über eine spezielle Infrastruktur verfügen, damit Cookies ordnungsgemäß funktionieren.

Mozilla hat eine Website namens publicsuffix.org, die Listen mit Regeln enthält, wie Cookies, Herkunft und Domains gekürzt werden sollten, wobei zu berücksichtigen ist, dass in einigen Dingen möglicherweise Punkte vorhanden sind, während sie tatsächlich als ein einzelnes Atom betrachtet werden sollten das ganze.

Wenn Ihr Browser herausfindet, wie er verschiedene Cookies manipulieren soll, muss er diese Seite des Problems überprüfen. Oder stellen Sie irgendwie sicher, dass foo.co.uk die Domain nicht auf co.uk verkürzen kann. Hier gibt es also ein sehr heikles Thema.

Es gibt viele weitere interessante Probleme mit der Websicherheit, die wir dabei entdecken, da ein Großteil der ursprünglichen Infrastruktur speziell für die englische Sprache entwickelt wurde. Zum Beispiel ASCII-Text oder ähnliches. Es war ursprünglich nicht für die internationale Gemeinschaft gedacht.

Aber als das Internet immer beliebter wurde, sagten die Leute: „Hey, am Anfang haben wir ein ziemlich umfangreiches Lösungsdesign erstellt, und jetzt müssen wir es für Menschen geeignet machen, die gezwungen sind, unser enges Verständnis der Bedeutung von Sprache zu nutzen.“ Deshalb stehen wir jetzt vor all diesen verrückten Problemen.

Überlegen Sie, wie HTTP-XML-Antworten von derselben Ursprungsquellenrichtlinie behandelt werden. Standardmäßig kann JavaScript nur eines davon generieren, wenn es auf seinem Ursprungsserver erstellt wird. Es gibt jedoch eine neue Schnittstelle namens Cross Origin Request (CORS).

Dies ist also derselbe Ursprung, es sei denn, der Server hat dieses CORS-Gizmo aktiviert. Grundsätzlich wird ein neuer HTTP-Antwortheader mit dem Namen Access-Control-Allow-Origin hinzugefügt.



Angenommen, JavaScript von foo.com möchte eine XML-HTTP-Anfrage an bar.com senden. Wie in den Regeln beschrieben, findet hier ein Cross-Origin statt. Und wenn der bar.com-Server dies zulassen möchte, gibt er seine HTTP-Antwort mit der Überschrift zurück: "Ja, ich lasse mich von foo.com diese originenübergreifenden XML-XML-Anforderungen senden."

Tatsächlich kann der bar.com-Server mit "Nein" antworten, dh er kann die Anfrage ablehnen. In diesem Fall kann der Browser die HTTP-XML-Anforderung nicht ausführen. Das ist also eine Art neue Sache, die hauptsächlich aufgrund gemischter Anwendungen auftrat. Es wird für Anwendungen von verschiedenen Entwicklern und verschiedenen Domänen benötigt, damit sie die Möglichkeit haben, Daten miteinander auszutauschen.



Anstelle von foo.com können hier Sternchen stehen, wenn jemand Ursprungsdaten abrufen möchte, und so weiter. Ich finde das ziemlich einfach. Es gibt eine Reihe anderer Ressourcen, die wir uns ansehen könnten, z. B. Bilder. Dank Access-Control-Allow-Origin kann ein Frame Bilder von jeder gewünschten Quelle laden. Er kann jedoch die Teile dieses Bildes nicht überprüfen, da angenommen wird, dass es bei unterschiedlichen Richtlinien für Herkunftsquellen nicht gut ist, den Inhalt der Dateien des jeweils anderen zu überprüfen.

Obwohl der Rahmen die Bits nicht überprüfen kann, kann er dennoch auf die Größe der Bilder schließen, da er sieht, wie sie auf der Seite platziert werden. Dies ist also ein weiterer dieser seltsamen Fälle, in denen dieselbe Herkunftsquelle angeblich versucht, alle Informationslecks zu verhindern. Tatsächlich kann dies jedoch nicht verhindert werden, da durch das Einbetten der Vererbung tatsächlich einige Arten von Informationen angezeigt werden.

CSS ähnelt Bildern, sodass ein Frame CSS aus jeder Quelle einbetten kann. Der Text in der CSS-Datei kann jedoch nicht direkt überprüft werden, wenn er aus einer anderen Quelle stammt. Aber er kann erkennen, was dieses CSS tut, weil er einfach eine Reihe von Knoten erstellt und dann beobachtet, wie sich ihr Stil ändert. Und es sieht ein bisschen seltsam aus.

JavaScript ist mein Lieblingsbeispiel dafür, wie dieselbe Ursprungsrichtlinie versucht, jede Art von intelligenter Sequenz zu unterstützen. Die Idee hier ist, dass dies zulässig ist, wenn Sie JavaScript über Kreuz abrufen. Sie können die Ausführung von externem JavaScript im Kontext Ihrer eigenen Seite aktivieren, den Quellcode jedoch nicht anzeigen.



Wenn Sie also eine Skript-Tag-Quelle haben, die etwas außerhalb Ihrer Domäne entspricht, können Sie bei Ausführung dieser Quelle Funktionen darin initiieren. Sie können den darin enthaltenen JavaScript-Quellcode jedoch nicht anzeigen.

Das alles sieht sehr gut aus, hat aber ein paar "Löcher". Beispielsweise ist JavaScript eine dynamische Skriptsprache. Und Funktionen sind erstklassige Objekte. Somit können Sie für jede Funktion f einfach die Funktion f.tostring () verwenden, und dies gibt Ihnen den Quellcode für die Funktion f. Und die Leute machen das die ganze Zeit, sie machen dynamisches Umschreiben und dergleichen.



Obwohl Sie mit den Ursprungsrichtlinien den Inhalt des Skript-Tags nicht direkt anzeigen können, können Sie einfach den angegebenen Vorgang ausführen und den Quellcode abrufen.

Ebenso können Sie Ihren Heimserver von Ihrer Domain abrufen, um den Quellcode darauf abzurufen und ihn dann an Sie zurückzusenden. Das heißt, Sie haben gerade Ihren Heimserver gebeten, das Wget-Programm auszuführen, um den Quellcode auf diese Weise abzurufen. Es sieht also auch ein bisschen albern aus, das heißt, die Ursprungspolitik hier ist etwas seltsam.

Zielgruppe: Angenommen, der Grund dafür ist, dass der Benutzer keinen JavaScript-Empfang erhält, da dann auch Cookies gesendet werden können. Das heißt, der Benutzer kann das resultierende JavaScript an seine Bedürfnisse anpassen.

Professor: Ja, das ist es.

Zielgruppe: Wenn Sie Ihren Server dazu veranlassen, kann er Ihnen keine benutzerdefinierten Cookies bereitstellen.

Professor: Dies ist wahr, obwohl in der Praxis der "rohe" Quellcode nicht dazu gedacht ist, vom Benutzer überarbeitet zu werden. Aber Sie haben Recht, dass dies einige Angriffe verhindern wird.

, , JavaScript, . , - , -, , . , , , . , , .

, . - - , - HTML JavaScript. , , . .

, JavaScript, , . Java, .



, HTML5 , , , , Java. , .

, HTTP, cookie. , URL, ?



, URL- bank.com. , - . , URL, , , $500 . , .

— , origin, bank.com - , , cookie . : «, , , $500 attacker! , ».
. , , , , . . , , , , - . , , CSRF.

, URL. , c .

, - . – , , :

<form action = “/transfer.cdi”…> 

In diesem Formular befinden sich die Eingabedaten, die normalerweise zur Eingabe von Text, Tastenanschlägen, Mausklicks und dergleichen verwendet werden. Tatsächlich können wir diese Eingabe ausblenden, damit sie nicht auf der Benutzerseite angezeigt wird: Eingabetyp = "ausgeblendet", geben Sie den Attributnamen = "csrf" und den Zufallswert = "a72f ..." an. Dieses Formular wird auf dem Server generiert.



Wenn der Benutzer diese Seite auf der Serverseite aufruft, generiert der Server diesen Zufallswert = "a72f ..." und bettet ihn in den HTML-Code ein, den der Benutzer erhält. Wenn der Benutzer dieses Formular ausfüllt, lautet diese URL des Formulars:

bank.com/xfer?amount=500&to=attacker

Es wird mit einem zufälligen Token ergänzt:

 http://bank.com/xfer?amount=500&to=attacker/&csrf=a72f... 

Dies bedeutet, dass der Angreifer nun in der Lage sein sollte, das spezifische Token zu erraten, das der Server für den Benutzer jedes Mal generiert, wenn er zur Bankseite wechselt. Wenn wir also einen ausreichend zufälligen Wert haben, kann der Hacker nichts vortäuschen, denn wenn er das falsche Token angibt, lehnen die Serverregeln seine Anfrage ab.

58:00 min

Fortsetzung:

MIT-Kurs "Computer Systems Security". Vorlesung 8: Netzwerksicherheitsmodell, Teil 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?