MIT-Kurs "Computer Systems Security". Vorlesung 13: Netzwerkprotokolle, 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
Vorlesung 13: „Netzwerkprotokolle“ Teil 1 / Teil 2 / Teil 3

Daher werden wir heute über Kerberos sprechen, ein kryptografisch sicheres Protokoll, das für die gegenseitige Authentifizierung von Computern und Anwendungen im Netzwerk entwickelt wurde. Dies ist ein Protokoll zur Authentifizierung von Client und Server, bevor eine Verbindung zwischen ihnen hergestellt wird.

Jetzt werden wir endlich Kryptographie verwenden, anders als in der letzten Vorlesung, in der wir uns mit der Sicherung nur mit TCP-SYN-Sequenznummern befasst haben.



Reden wir also über Kerberos. Was versucht dieses Protokoll zu unterstützen? Es wurde vor 25 oder 30 Jahren an unserem Institut im Rahmen des Athena-Projekts erstellt, um die Interaktion mehrerer Servercomputer und mehrerer Clientcomputer sicherzustellen.

Stellen Sie sich vor, Sie haben irgendwo einen Dateiserver. Möglicherweise handelt es sich um einen Mailserver, der mit dem Netzwerk verbunden ist, oder um andere Netzwerkdienste, z. B. Drucker. Und all dies ist einfach mit einem Netzwerk verbunden und nicht mit Prozessen auf einem Computer.



Die Voraussetzung für die Erstellung von Athena und Kerberos war, dass Sie eine Maschine für die gleichzeitige Freigabe hatten, bei der alles ein separater Prozess war und jeder sich einfach bei demselben System anmelden und seine Dateien dort speichern konnte. Daher wollten die Entwickler ein bequemeres verteiltes System schaffen.



Dies bedeutete also, dass Sie diese Server auf der einen Seite und eine Reihe von Workstations auf der anderen Seite haben würden, die Benutzer selbst verwenden würden und auf denen die Anwendungen ausgeführt würden. Diese Workstations stellen eine Verbindung zu diesen Servern her und speichern Benutzerdateien, empfangen ihre E-Mails usw.

Das Problem, das sie lösen wollten, war die Authentifizierung von Benutzern, die diese Workstations für all diese verschiedenen Computer auf der Serverseite verwenden, ohne dem Netzwerk vertrauen und dessen Richtigkeit überprüfen zu müssen. Dies war in jeder Hinsicht eine vernünftige Designanforderung. Ich sollte erwähnen, dass zu dieser Zeit die Alternative zu Kerberos das R-Login-Team war, das in der letzten Vorlesung besprochen wurde. Dies schien ein schlechter Plan zu sein, da sie einfach ihre IP-Adressen zur Authentifizierung von Benutzern verwenden.

Kerberos war recht erfolgreich, wird derzeit noch im MIT-Netzwerk verwendet und ist das Rückgrat des Active Directory-Servers von Microsoft. Nahezu jedes Microsoft Windows Server-basierte Produkt verwendet Kerberos in der einen oder anderen Form.

Dieses Protokoll wurde jedoch vor 25 oder 30 Jahren entwickelt, und seitdem sind Änderungen erforderlich, da die Menschen heute viel mehr über Sicherheit verstehen. Daher unterscheidet sich die aktuelle Version von Kerberos in vielerlei Hinsicht deutlich von der in den Materialien für diese Vorlesung beschriebenen Version. Wir werden überlegen, welche besonderen Annahmen heute nicht gut genug sind und was in der ersten Version falsch war. Dies ist unvermeidlich für das erste Protokoll, bei dem Kryptografie tatsächlich zur Authentifizierung von Netzwerkteilnehmern in einem vollständigen System verwendet wurde.

In jedem Fall ist das auf der Platine dargestellte Diagramm eine Art Installation zum Erstellen von Kerberos. Es ist interessant herauszufinden, was das Modell des Vertrauens ist. Daher wird eine zusätzliche Struktur in unser Schema eingeführt - der Kerberos-Server, der sich hier an der Seite befindet.



Daher basiert unser drittes Modell in gewisser Weise auf der Tatsache, dass das Netzwerk unzuverlässig ist, wie wir in der letzten Vorlesung erwähnt haben. Wem sollten wir dieses Kerberos-Programm anvertrauen? Natürlich müssen alle Netzwerkteilnehmer dem Kerberos-Server vertrauen. Daher haben die Entwickler des Systems einmal vorgeschlagen, dass der Kerberos-Server für alle Überprüfungen der Netzwerkauthentifizierung in der einen oder anderen Form verantwortlich ist. Was haben wir noch in diesem Netzwerk, dem Sie vertrauen können?

Student: Benutzer können ihren eigenen Maschinen vertrauen.

Professor: Ja, das ist ein gutes Argument. Es gibt hier Benutzer, die ich nicht gezeichnet habe. Aber diese Leute benutzen eine Art Workstation, und tatsächlich ist es in Kerberos sehr wichtig, dass der Benutzer seiner Workstation vertraut. Was passiert, wenn Sie Ihrer Workstation nicht vertrauen? Denn wenn der Benutzer der Workstation nicht vertraut, können Sie dort einfach Ihr Passwort „herausschnüffeln“ und in Ihrem Namen handeln.



Student: Ein Angreifer kann viel mehr tun, indem er beispielsweise Ihr Ticket für den Kerberos-Server lernt.

Professor: Ja genau. Wenn Sie sich anmelden, geben Sie Ihr Passwort ein, das noch schlimmer ist als ein Ticket. Es gibt also ein kleines Problem mit Kerberos, wenn Sie der Workstation nicht vertrauen. Wenn Sie Ihren eigenen Laptop verwenden, ist dies nicht so beängstigend, aber die Sicherheit eines öffentlichen Computers ist zweifelhaft. Wir werden überlegen, was genau in diesem Fall schief gehen kann.

Student: Sie müssen den Serveradministratoren vertrauen und sicherstellen, dass sie privilegierten Zugriff auf die Server des jeweils anderen haben können.

Professor: Ich denke, dass die Maschinen selbst einander nicht vertrauen müssen, zum Beispiel muss der Mailserver dem Druckserver oder Dateiserver nicht vertrauen.

Schüler: Vertrauen Sie nicht, haben Sie jedoch die Möglichkeit, auf einen Server zuzugreifen, auf den der Zugriff über einen anderen Server nicht unterstützt wird.

Professor: Ja, das stimmt. Wenn Sie eine Vertrauensbeziehung zwischen dem Mailserver und dem Druckserver herstellen, dem Mailserver jedoch aus Bequemlichkeitsgründen nur Zugriff auf Ihre Dateien auf dem Dateiserver gewähren, kann dies missbraucht werden. Sie sollten daher vorsichtig sein, wenn Sie hier zusätzliche Vertrauensstufen oder redundante Vertrauensstellungen einführen.

Was ist hier noch wichtig? Sollten Server Benutzern oder Workstations irgendwie vertrauen? Ich denke nicht. Das globale Ziel von Kerberos war, dass der Server a priori nicht alle diese Benutzer oder Workstations kennt oder weiß, wie sie authentifiziert werden, bis diese Benutzer kryptografisch nachweisen können, dass sie legitime Benutzer sind und Zugriff auf ihre Daten oder etwas anderes haben müssen mehr als der Server verwaltet.

Mal sehen, wie Kerberos funktioniert und wie seine allgemeine Architektur aussieht. Zeichnen wir einen Kerberos-Server in größerem Maßstab. Heutzutage heißt es KDC - Key Distribution Center oder Key Providing Center. Irgendwo gibt es Benutzer und Dienste, mit denen Sie eine Verbindung herstellen können. Es ist geplant, dass der Kerberos-Server für die Speicherung des gemeinsam genutzten Schlüssels für die Kommunikation zwischen dem Kerberos-Server und jeder Computerentität in der Welt um ihn herum verantwortlich ist. Wenn der Benutzer also eine Art Client-Schlüssel Kc hat, merkt sich der Kerberos-Server diesen Schlüssel und speichert ihn irgendwo in sich. Auf die gleiche Weise ist der Ks-Schlüssel für einen Dienst nur diesem Dienst selbst, dem Kerberos-Server und niemand anderem bekannt. Daher können Sie es sich als eine häufige Verwendung von Passwörtern vorstellen, wenn Sie das Passwort kennen und Kerberos es kennt, aber niemand anderes weiß es.



Auf diese Weise werden Sie sich gegenseitig beweisen, dass "ich der gleiche Typ bin". Natürlich muss der Kerberos-Server nachverfolgen, wem dieser Schlüssel gehört. Daher sollte er eine Tabelle enthalten, in der Benutzernamen und Dienstnamen, z. B. serv afs (dies ist ein Dateiserver), und die ihnen entsprechenden Schlüssel gespeichert werden.

Gleichzeitig ist KDC für die Speicherung einer riesigen Tabelle verantwortlich, die nicht sehr groß in Bezug auf die Anzahl der Bytes, aber sehr umfangreich in Bezug auf die Anzahl der Datensätze ist, da alle Computereinheiten im MIT-Netzwerk berücksichtigt werden, die dem Kerberos-Server bekannt sein sollten. Wir haben also zwei Arten von Schnittstellen.



Die Vorlesungsunterlagen sprechen nicht klar genug darüber, das heißt, die Existenz dieser beiden Schnittstellen wird einfach impliziert. Tatsächlich gibt es zwei Schnittstellen für eine Maschine. Einer von ihnen heißt Kerberos und der zweite ist TGS, Ticket Granting Service oder Ticket Service.

Letztendlich sind dies nur zwei Möglichkeiten, um über dasselbe zu sprechen, und das Protokoll unterscheidet sich für diese beiden Dinge nur geringfügig. Wenn sich ein Benutzer anmeldet, „spricht“ er zunächst mit der oberen Benutzeroberfläche Kerberos und sendet ihm seinen Kundennamen C. Dies kann Ihr Benutzername im Athena-Universitätsnetzwerk sein.

Der Server antwortet auf diese Anfrage mit einem tgs-Ticket oder Ticketinformationen. Wir werden die Details dieser Informationen etwas später besprechen. Wenn Sie dann mit einem Dienst chatten möchten, müssen Sie zuerst zur TGS-Schnittstelle gehen und ihr mitteilen: „Ich habe mich bereits über die Kerberos-Schnittstelle angemeldet und möchte jetzt mit dem S-Server sprechen, der mir einen bestimmten Dienst bietet.“

Sie teilen TGS also den Server mit, mit dem Sie sprechen möchten. Danach wird Ihnen so etwas wie ein Ticket für das Gespräch mit Server S zurückgegeben. Anschließend können Sie mit dem empfangenen Ticket für Server S endlich mit dem Server sprechen, den Sie benötigen.

Dies ist eine Art hochrangiger Plan. Warum werden hier 2 Schnittstellen verwendet? Hierzu können viele Fragen gestellt werden. Im Fall des Ks-Servers wird dieser Dienst wahrscheinlich auf der Festplatte gespeichert. Und was passiert mit diesem Kc auf der Benutzerseite? Woher kommt dieser Kc in Kerberos?



Student: Dieser Kc sollte sich in der Datenbank in der KDC-Servertabelle befinden.

Professor: Ja, der C-Schlüssel befindet sich hier in der Tabelle in dieser gigantischen Datenbank. Es muss aber auch dem Benutzer bekannt sein, da der Benutzer nachweisen muss, dass er ein Benutzer ist.

Student: Ist es eine Einwegfunktion, für die dann ein Passwort erforderlich ist?

Professor: Ja, sie haben tatsächlich einen so intelligenten Plan, bei dem Kc durch Hashing des Benutzerpassworts oder einer Art Schlüsselgenerierungsfunktion erhalten wird. Dafür gibt es verschiedene Methoden. Aber im Grunde nehmen wir das Passwort, konvertieren es irgendwie und bekommen diesen Schlüssel Kc. Das scheint also ein guter Weg zu sein.

Aber warum brauchen wir zwei Protokolle? Schließlich können Sie sich vorstellen, dass Sie einfach ein Ticket direkt von der ersten Kerberos-Oberfläche anfordern und ihm sagen: „Hey, ich möchte ein Ticket für diesen bestimmten Namen!“. Er sendet Ihnen das Ticket zurück und Sie können es mit Kc entschlüsseln.

Student: Vielleicht möchten sie nicht, dass der Benutzer sein Passwort jedes Mal neu eingibt, wenn er auf einen anderen Dienst zugreifen möchte?

Professor: Richtig, der Grund für den Unterschied zwischen den beiden Schnittstellen ist, dass ab der ersten Schnittstelle alle Antworten verschlüsselt mit Ihrem Kc-Schlüssel zurückgegeben werden und die Entwickler von Kerberos sich Sorgen über die Möglichkeit machten, diesen Kc für eine lange Zeit zu behalten. Denn entweder müssen Sie den Benutzer jedes Mal auffordern, das Passwort einzugeben, was nur ärgerlich ist, oder er „sitzt“ ständig im Speicher. Grundsätzlich ist dies so gut wie nur ein Benutzerkennwort, da jemand mit Zugriff auf Kc den Zugriff auf die Benutzerdateien behalten kann, bis der Benutzer möglicherweise sein Kennwort ändert oder sogar länger. Später werden wir dieses Problem genauer betrachten.

Das Auslaufen dieses Kc-Schlüssels ist also eine sehr gefährliche Sache. Daher besteht der springende Punkt bei der Verwendung der ersten und dann der zweiten Schnittstelle für alle nachfolgenden Anforderungen darin, dass Sie Kc tatsächlich vergessen können, sobald Sie die Antwort von der Kerberos-Server-TGS-Schnittstelle entschlüsseln. Von nun an hängt die Funktionalität auch im Falle eines Schlüssellecks vom erhaltenen Ticket ab. Im schlimmsten Fall erhält jemand für ein paar Stunden und nicht für unbegrenzte Zeit Zugriff auf Ihr Konto. Dies ist der Grund für ein solches Schema mit zwei Zugriffspfaden zu denselben Ressourcen.

Bevor wir uns also mit der Funktionsweise dieser Protokolle im Netzwerk befassen, wollen wir uns kurz mit dem Aspekt der Kerberos-Namen befassen. In gewissem Sinne kann Kerberos als Namensregistrierung betrachtet werden. Er ist dafür verantwortlich, diese kryptografischen Schlüssel als Kleinbuchstaben anzuzeigen. Dies ist die grundlegende Operation, die Kerberos ausführt. Sie werden in der nächsten Vorlesung sehen, warum wir eine ähnliche Funktion benötigen. Es kann anders als in Kerberos implementiert werden, aber es ist grundsätzlich sehr wichtig, in fast jedem verteilten Sicherheitssystem eine ähnliche Funktion zu haben. Mal sehen, wie Kerberos mit Namen umgeht.

Kerberos hat so etwas wie Systemaufrufe für jede Computerentität in der Datenbank der Netzwerkmitglieder, und die Hauptform dieser Daten ist nur eine Zeichenfolge. So können Sie einige grundlegende Namen in einer Form wie beispielsweise Nickolai haben. Dies ist die Namenszeichenfolge.



Dies ist der Hauptparameter in einigen Bereichen von Kerberos. Tatsächlich befindet sich dies in der linken Spalte der KDC-Tabelle. Außerdem unterstützt das Protokoll einige zusätzliche Parameter. Ich könnte zum Beispiel einen anderen Namen wie nickolai.extra sec eingeben, der zusätzlich zum Namen nickolai verwendet wird, um auf Ressourcen zuzugreifen, die zusätzliche Sicherheit benötigen. Vielleicht habe ich ein Passwort für wirklich sichere Dinge und ein anderes Passwort für mein reguläres Konto.

Kerberos hat diesen Aspekt erwähnt. Man könnte sich daher fragen, woher die Auswirkungen kommen. Der Kerberos-Dienst ordnet Namen für Sie bestimmten Schlüsseln zu. Woher wissen Sie jedoch, welchen Namen Sie fragen müssen oder welchen Namen Sie als Antwort erwarten müssen, wenn Sie mit einem Computer sprechen? Das heißt, ich frage, welche Namen außerhalb des Kerberos-Servers angezeigt werden oder wo genau diese Benutzernamen angezeigt werden. Hast du irgendwelche Ideen?

Student: Vermutlich können Sie vom MIT-Server nach Benutzernamen fragen.

Professor: Ja natürlich. So können Sie diese Dinge auflisten. Außerdem geben Benutzer sie einfach ein, wenn sie sich anmelden. Von dort kommen sie. Werden Benutzernamen an anderer Stelle angezeigt? Sollten sie woanders erscheinen?

Student: Es ist möglich, dass der Benutzerzugriff in den Listen verschiedener Dienste angegeben ist.

Professor: Ja, das ist ein wirklich wichtiger Punkt, oder? Das Ziel von Kerberos ist es, Schlüssel einfach Namen zuzuordnen. Dies sagt Ihnen jedoch nicht, worauf dieser Name Zugriff haben soll.

Tatsächlich verwenden Anwendungen Kerberos normalerweise so, dass einer dieser Server Kerberos verwendet, um herauszufinden, mit welchem ​​Kleinbuchstaben er spricht. Wenn der Mailserver eine Verbindung von einer Arbeitsstation empfängt, erhält er ein Kerberos-Ticket, das beweist, dass dieser Benutzer Nikolai ist. Danach findet der Mailserver intern heraus, auf was dieser Benutzer Zugriff hat. Der Dateiserver macht dasselbe.

Daher gibt es in all diesen Servern Zugriffssteuerungslisten, möglicherweise Gruppenlisten oder andere Dinge, die eine Autorisierung durchführen. Kerberos bietet also eine Authentifizierung, die Ihnen zeigt, mit welcher Person Sie sprechen. Der Dienst selbst ist für die Implementierung des Teils der Autorisierung verantwortlich, der anhand Ihres Benutzernamens entscheidet, welche Zugriffsebene Sie haben sollen. Also haben wir herausgefunden, wo die Benutzernamen erscheinen. Es gibt andere grundlegende Namen, die Kerberos für die Interaktion mit Diensten unterstützt.

Laut den Vorlesungsmaterialien sehen die Dienste ungefähr so ​​aus: rcmd.hostname. Der Grund, warum Sie einen Namen für einen dieser Dienste benötigen, besteht darin, dass Sie beispielsweise beim Herstellen einer Verbindung zu einem Dateiserver eine gegenseitige Authentifizierung durchführen möchten. Dies bedeutet, dass bei diesem Verfahren nicht nur der Zielserver herausfindet, wer ich bin, sondern auch ich, der Benutzer oder die Workstation, sicherstellen, dass ich mit dem richtigen Dateiserver spreche und nicht mit einem gefälschten Dateiserver, der meinen gefälscht hat Dateien. Vielleicht möchte ich mir die Datei mit meinen Bewertungen ansehen und sie an den Registrar senden. Daher wäre es zu schade, wenn ein anderer Dateiserver als der richtige Server fungieren und mir die falsche Bewertungsdatei zur Verfügung stellen könnte.

Daher benötigen Dienste auch einen eigenen Namen, und Workstations sollten herausfinden, welchen Namen ich beim Herstellen einer Verbindung zum Dienst erwarten kann.



In der Regel kommt dies auf einer bestimmten Ebene vom Benutzer. Wenn ich beispielsweise ssh.foo eingebe, bedeutet dies, dass ich erwarten sollte, dass ein Kerberos-Hauptname wie rcmd.foo am anderen Ende dieser Verbindung angezeigt wird. Und wenn jemand anderes da ist, sollte der SSH-Client die Verbindung trennen und mich nicht verbinden lassen, da ich dann irregeführt werde und mit einem anderen Computer spreche.

Dies wirft eine interessante Frage auf. Wann können wir Namen in Kerberos wiederverwenden? Zum Beispiel haben Sie alle Konten im Athena-Institutssystem. Kann das MIT nach Abschluss Ihres Studiums Ihren Datenbankeintrag zerstören und jemand anderem erlauben, denselben Benutzernamen zu registrieren? Wäre das eine gute Idee?

Student: Aber nicht nur die Kerberos-Datenbank, sondern auch die Dienste haben eine Liste von Benutzernamen?

Professor: Ja, weil diese Namen eigentlich nur durch Zeichenfolgeneinträge irgendwo in der ACL auf einem Datei- oder Mailserver dargestellt werden. Wenn wir Ihren Eintrag in der Kerberos-Serverdatenbank löschen, bedeutet dies nicht, dass Ihr Eintrag vollständig verschwunden ist. Diese Einträge sind versionunabhängig.

Zum Beispiel besagt eine Aufzeichnung, dass Alice Zugang zu einem Athena-Schließfach hat. Dann macht Alice ihren Abschluss und ihr Datensatz wird gelöscht, aber eine neue Alice betritt das Institut, das den Registrierungsprozess in der Kerberos-Datenbank durchläuft. Gleichzeitig erhält sie den Hauptnamen, der vollständig mit dem Namen der alten Alice identisch ist, sodass der Dateiserver der neuen Alice Zugriff auf die Dateien der alten Alice gewähren kann.

, Kerberos , Kerberos . , , , .

. , , , , , . , , , - . , . , , .

, . , , , TGS.



, , Kerberos, «». : s , IP – addr, time stump, life, , , Kc,s, . .



.

, Kerberos «». Ac , IP- , , . , . K,s, , Kerberos Ks. , .



, , Kerberos TGS. , , Kerberos, , . : C, , S, TGS. .

Tc,s, Ks, , Ks, , Kc. .



. , Kerberos ? , ?

: , , , Kc.

: , , Kerberos , . : «, , . , , , Kc». , .

, , , Kerberos, Kerberos , . , , - Kerberos, , .
: …

: , , Kerberos, ? , ? , , , , , , , , , .



«», , , , , . , , . . Kerberos, , . , , .

: ? , …

: , . , Kerberos , . , , - , , , . 30 , .

Kerberos 5 : , — . , , , , .

Kerberos 4 , , , . , . , , .

Dies ist also der Plan, um dem Kunden mitzuteilen, ob sein Ticket gültig ist. Sie versuchen nur, es zu entschlüsseln und zu sehen, wie es funktioniert. Eine weitere interessante Frage: Warum ist dieser Schlüssel Kc in irgendeiner Form zweimal im Ticket enthalten? Es ist auf dem Ticket separat als Schlüssel Kc, s vorhanden und ist implizit im Ticket selbst Tc, s vorhanden. Warum haben wir zwei Kopien des Schlüssels Kc, s?

27:10 Min.

MIT-Kurs "Computer Systems Security". Vorlesung 13: Netzwerkprotokolle, Teil 2


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?