Kursus MIT "Keamanan Sistem Komputer". Kuliah 13: Protokol Jaringan, Bagian 2

Institut Teknologi Massachusetts. Kursus Kuliah # 6.858. "Keamanan sistem komputer." Nikolai Zeldovich, James Mickens. Tahun 2014

Keamanan Sistem Komputer adalah kursus tentang pengembangan dan implementasi sistem komputer yang aman. Ceramah mencakup model ancaman, serangan yang membahayakan keamanan, dan teknik keamanan berdasarkan pada karya ilmiah terbaru. Topik meliputi keamanan sistem operasi (OS), fitur, manajemen aliran informasi, keamanan bahasa, protokol jaringan, keamanan perangkat keras, dan keamanan aplikasi web.

Kuliah 1: “Pendahuluan: model ancaman” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 2: "Kontrol serangan hacker" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 3: “Buffer Overflows: Exploits and Protection” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 4: “Pemisahan Hak Istimewa” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 5: "Dari mana sistem keamanan berasal?" Bagian 1 / Bagian 2
Kuliah 6: “Peluang” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 7: “Kotak Pasir Klien Asli” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 8: “Model Keamanan Jaringan” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 9: "Keamanan Aplikasi Web" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 10: “Eksekusi simbolik” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 11: “Bahasa Pemrograman Web / Web” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 12: Keamanan Jaringan Bagian 1 / Bagian 2 / Bagian 3
Kuliah 13: "Protokol Jaringan" Bagian 1 / Bagian 2 / Bagian 3

Mahasiswa: klien tidak dapat mendekripsi tiket ini karena dienkripsi menggunakan kunci layanan.

Profesor: ya, itu benar-benar pintar, bukan? Kami memiliki kunci Kc, yang dapat diterima klien, tetapi di sini, pada tiket Tc, ada salinan lain dari kunci ini, dienkripsi dengan Ks.



Alasan ini dilakukan adalah karena server Kerberos sebenarnya mencoba untuk mengamankan komunikasi klien dengan orang lain. Oleh karena itu, Kerberos membuat kunci acak Kc, s dan memberikan satu salinan kepada klien, dan yang lain ke server yang dengannya klien akan berbicara. Bayangkan bahwa Kerberos hanya akan memanggil layanan dengan kata-kata: "Hei, layanan, orang ini ingin berbicara dengan Anda, ini adalah kunci untuk ini!" Ini akan disayangkan karena server Kerberos akan mengakses layanan lagi dan lagi pada setiap permintaan. Jadi KDS membuat 2 salinan kunci sesi: satu untuk klien, dan yang lainnya untuk TGS.

Oleh karena itu, sebagai gantinya, para pengembang datang dengan trik yang bagus, di mana mereka memberi klien tiket ini, dan dia tidak dapat melakukan apa pun dengannya kecuali untuk menghubunginya dengan layanan yang tepat. Dan jika layanan ini memiliki kunci Ks yang benar, itu akan mendekripsi dan mengatakan: "Ya, ini adalah kunci yang sama yang harus saya gunakan untuk berbicara dengan klien ini." Dengan demikian, kedua peserta dalam koneksi, klien dan layanan, akan membuat kunci bersama untuk melindungi koneksi mereka.

Mahasiswa: jadi apa itu TGS?

Profesor: Ada dua pandangan tentang apa itu TGS. Dari sudut pandang klien, ini hanyalah layanan lain di mana Anda bisa mendapatkan tiket. Semakin banyak fitur yang disediakan layanan ini, semakin banyak tiket yang disediakannya. Ini sebenarnya adalah layanan tiket.

Siswa: maaf, maksud saya kami memiliki tiket yang disebut TGS.

Profesor: oh, ya, maaf, tulisan tgs di bawah panah di diagram ini hanyalah singkatan dari seluruh blok rekaman, kecuali indeks s pada parameter Tc, s, yang berarti nama sebenarnya dari layanan ini adalah TGS. Anda dapat membayangkan bahwa kami memiliki server Kerberos, ada layanan TGS ini dan ada layanan nyata yang ingin Anda tuju. Jadi pertama-tama Anda harus meminta Kerberos untuk memberi Anda tiket untuk mendapatkan akses ke layanan tertentu.



Anda bisa meminta Kerberos untuk memberi Anda tiket langsung ke server file, dan itu mungkin berhasil. Tetapi untuk ini Anda akan membutuhkan Kc Anda untuk dekripsi dan untuk sisa waktu menggunakan server. Sebagai gantinya, Anda mendapatkan tiket untuk layanan TGS khusus. Itu terlihat sama dengan layanan lain, kecuali bahwa itu ditempatkan di kotak yang terpisah. Dan dia akan dengan senang hati memberi Anda lebih banyak tiket nanti tanpa memberikan kembali kunci pelanggan Kc asli Anda.

Mahasiswa: yaitu, idenya adalah bahwa begitu Anda menerima tiket TGS, Anda bisa menyingkirkan kunci Kc Anda?

Profesor: ya, hal keren tentang ini adalah begitu Anda menerima Tc tiket ini, dari layanan TGS, Anda menyingkirkan kata sandi dan kunci Kc. Dengan demikian, segera setelah Anda masuk ke Athena workstation dan setelah beberapa detik Anda menerima tiket T, s, kata sandi Anda dihapus dari memori. Jadi, bahkan jika seseorang menangkap Anda, memilih komputer dan melarikan diri bersamanya, yang ia miliki hanyalah tiket Anda. Baik jika ia dapat mengakses informasi Anda selama 10 jam, atau selama durasi tiket, tetapi tidak lebih lama, karena kata sandi belum disimpan dan saat berikutnya Anda memasuki Athena, Anda harus memasukkannya lagi.

Satu-satunya saat Anda memerlukan kata sandi adalah ketika Anda mengirim permintaan ke server Kerberos, Anda menerima respons ini dengan tiket dan mendekripsi. Setelah itu, Anda bisa melupakan kata sandinya. Tetapi tentu saja, Anda tidak dapat menjatuhkan kata sandi sebelum menggunakannya untuk mendekripsi.
Dengan demikian, antarmuka atas pertama C dalam skema kami digunakan untuk mendapatkan tiket dengan kunci awal Kc, dan antarmuka rendah kedua S digunakan untuk mengakses layanan, tetapi tanpa perlu mendapatkan kunci awal Kc.



Jadi, kita telah berbicara tentang dua masalah spesifik dari protokol Kerberos, yang, seolah-olah, dibangun ke dalamnya, yang menyebabkan beberapa ketidaknyamanan. Pertama, pembuatnya berasumsi bahwa enkripsi juga akan memberikan otentikasi atau integritas pesan, tetapi ini tidak terjadi. Kelemahan ini telah diperbaiki di Kerberos versi 5, di mana otentikasi pesan eksplisit dilakukan. Kedua, untuk klien yang sewenang-wenang, mereka memiliki kesempatan untuk menebak kata sandi orang lain.

Bagaimana ini bisa diperbaiki? Bagaimana mencegah serangan dengan menebak kata sandi dalam protokol semacam ini? Apa yang bisa kita coba?

Siswa: Saya tidak yakin, tetapi Anda dapat mencoba untuk “memberi garam” kata sandi.

Profesor: "salting" hanya berarti bahwa klien mungkin harus hash kata sandi dengan cara yang berbeda. Tapi ini tidak ada salahnya untuk mencoba mengambilnya. Jadi mungkin lebih mahal untuk membangun kamus.

Siswa: Anda dapat mencoba menyulitkan fungsi penghitungan kata sandi.

Profesor: ya, ide bagus lainnya adalah membuat proses hash menjadi sangat mahal. Mungkin ini masuk akal. Karena itu, jika fungsi hash ini membutuhkan waktu komputasi kedua, seperti yang Anda lakukan di lab kedua, maka dalam hal ini, memilih kata sandi akan menjadi tugas yang sangat mahal. Jadi ini sepertinya rencana yang masuk akal - untuk menggunakan kombinasi "pengasinan" dan mempersulit proses menebak.

Pertahanan lain dapat mempersulit respons. Anda telah mendengar bahwa di versi pertama protokol, server Kerberos tidak tahu apakah klien yang benar mengaksesnya atau tidak. Yang dapat Anda lakukan adalah memberikan bukti bahwa Anda adalah klien yang tepat, yaitu, mengenkripsi cap waktu saat ini dengan hash kata sandi, atau sesuatu seperti itu. Kemudian server Kerberos hanya dapat memeriksa apakah hal-hal ini benar, dan jika mereka cocok, memberi Anda tiket.

Anda mungkin tidak ingin menambahkan langkah uji lagi, tetapi itu mungkin berhasil. Untuk saat ini, misalkan Anda dapat mengambil cap waktu dan hash bersama dengan kunci Kc, dan juga hanya menambahkan cap waktu.



Dalam hal ini, server dapat melihat bahwa ia memiliki kunci Kc Anda dan juga dapat meng-hash cap waktu saat ini. Jika menerima nilai yang sama, maka permintaan tersebut mungkin dibuat oleh pengguna yang tepat kepada siapa tiket dapat dikirim. Jika tidak, itu adalah kata sandi yang salah.

Mahasiswa: Anda dapat membatasi penerbitan tiket jika server mencatat terlalu banyak permintaan untuk ketentuan mereka.

Profesor: benar sekali, kita bisa membuat batasan. Namun, tidak ada alasan bagi peretas untuk meminta tiket di server lebih dari sekali. Dia hanya meminta pengguna tertentu, menerima blok terenkripsi ini darinya dan dapat mencoba mendekripsi secara offline sebanyak yang dia inginkan, dengan kata sandi yang berbeda tanpa permintaan kedua. Oleh karena itu, saya berpikir bahwa seluruh titik perlindungannya adalah server entah bagaimana bereaksi terhadap jumlah panggilan jika penyerang berulang kali meminta server, mencoba memasuki sistem di bawah kata sandi yang berbeda. Dalam hal ini, batas kueri dapat tercapai, yang akan memberikan perlindungan yang lebih baik terhadap peretasan.

Siswa: bagaimana seorang penyerang dapat mengirim permintaan ke server Kerberos?

Profesor: Saya pikir dia dapat mereproduksi pesan dari pengguna yang benar, yaitu, melihatnya, menyalinnya, mengirimnya dan juga menerima tanggapan dari server Kerberos. Jika seorang hacker memindai jaringan, ia dapat mencegat pesan selama transmisi. Jadi membatasi jumlah permintaan adalah tindakan sementara yang hanya sedikit meningkatkan keamanan. Tetapi, tentu saja, jika Anda melihat jaringan orang lain, Anda akan melihat bagaimana paket ini dikembalikan dari server terlepas dari apa yang terjadi pada tahap pembentukan Tc, s. Jadi peretas dapat melihat respons server terhadap klien dan mencoba menyerangnya.

Mungkin ada skema yang lebih rumit yang bisa Anda kembangkan, tetapi saya tidak berpikir Kerberos 5 mengimplementasikan sesuatu yang lebih rumit daripada rencana yang kami ulas, yang tampaknya cukup baik untuk mencegah orang secara acak mencoba memecahkan sesuatu atau menggunakan hewan kasar. dipaksa untuk memecahkan kata sandi.

Siswa: misalkan Anda dapat memberikan otentikasi atau yang lainnya untuk membuat kunci bersama. Dan kemudian Anda dapat mengenkripsi hal ini dan kunci bersama dengan Kc.

Profesor: ya, benar. Jika Anda benar-benar melakukannya dengan benar, maka untuk ini ada protokol yang disebut Password Authenticated Key Exchange, PAKE, yang melakukan otentikasi kata sandi. Inilah yang terjadi di Kerberos.



Anda dapat melihat Google untuk apa protokol SRP atau PAKE. Protokol-protokol ini dan elemen-elemen terkaitnya bekerja lebih baik dengan tugas Anda, di mana Anda harus membuktikan kepada kedua pihak bahwa Anda telah menginstal kunci baru. Dalam hal ini, kedua belah pihak harus diyakinkan tentang kebenaran satu sama lain dan itu, dan bahwa tidak ada cara untuk menebak kata sandi ini secara offline dan untuk menyerang set paket jaringan yang Anda amati, dan seterusnya.

Ini adalah protokol yang sangat bergantung pada kriptografi, sehingga sulit untuk menjelaskan mengapa mereka bekerja.

Mahasiswa: Salah satu alasan pengembang melakukan ini adalah karena mereka ingin mendukung kemampuan untuk mengirim hanya kata sandi. Dan protokol hanya membiarkan Anda mengirim satu hal sebagai autentikator.

Profesor: ya, ada banyak persyaratan aneh yang harus diperhitungkan oleh orang-orang ini. Tentu saja, dalam praktiknya, server ini dapat menerima koneksi Kerberos dan non-Kerberos. Dan untuk koneksi non-Kerberos, Anda mendapatkan gambar seolah-olah seseorang terhubung ke server email tetapi tidak menggunakan workstation Athena. Dia hanya ingin mengirim kata sandinya.



Dan kemudian klien email di sini, katakanlah, akan mengambil kata sandi ini dan mendapatkan tiket atas nama Anda hanya untuk memverifikasinya, yang akan memungkinkan Anda untuk menggunakan klien email ini. Jadi, Anda mungkin masih ingin Kerberos sendiri memverifikasi kata sandi Kerberos. Saya tidak berpikir ini keluar dari pertanyaan karena tentu saja Kerberos 5 menyebarkan hash cap waktu ini dan semua itu.

Saya pikir satu hal lagi yang harus Anda perhatikan dalam materi kuliah adalah bahwa pengembang Kerberos 4 memilih satu skema enkripsi - DES, algoritma enkripsi paling populer saat itu. Ini adalah cipher blok simetris, cukup cepat. Pada saat itu, itu memberikan keamanan yang cukup, dan mereka hanya membangunnya ke dalam protokol.

Segala sesuatu di Kerberos seharusnya hanya menggunakan DES, atau setidaknya semuanya dalam Kerberos versi 4. Ini telah menjadi masalah, karena sekarang, 25-30 tahun kemudian, enkripsi DES dapat dengan mudah dipecahkan menggunakan metode brute-force, karena kunci enkripsi memiliki ukurannya sangat kecil - hanya 56 bit.

Karenanya, Anda cukup membuat beberapa jenis peralatan pengguna yang akan menghitung 2 hingga 56 derajat kombinasi dan mencari tahu kata sandi yang sebenarnya. Inilah yang ingin Anda hindari dalam protokol apa pun yang sedang dikembangkan saat ini.

Kerberos versi 5 mendukung beberapa skema enkripsi yang berbeda, termasuk AES dan algoritma kriptografi lainnya. Jadi ini sepertinya cara yang jauh lebih baik untuk memastikan keamanan. Di sisi lain, MIT terus mendukung DES 2 tahun yang lalu, tetapi sekarang telah menolaknya, jadi hari ini rektor Anda dilindungi, setidaknya dari jenis serangan ini. Sekarang mari kita lihat apa yang terjadi di layanan TGS dari mana Anda menerima tiket. Interaksi dengan layanan ini terlihat sedikit berbeda.

Di satu sisi, sebagai klien, Anda akan berbicara dengannya seolah-olah Anda sedang berbicara dengan layanan lain yang mendukung Kerberos. Pertimbangkan bagaimana Anda melakukan otentikasi Anda sendiri dengan tiket ke mesin. Tetapi jawaban yang akan Anda kembalikan hanyalah tiket ke prinsip lain, atas dasar itu Anda akan berkomunikasi, misalnya, dengan server file.

Oleh karena itu, pesan tingkat protokol akan terlihat seperti ini - di sebelah kanan saya akan menggambar TGS, dan di sebelah kiri - klien. Klien sudah memiliki tiket untuk TGS, diperoleh dengan menggunakan protokol yang ditunjukkan di atas.



Sekarang klien akan mengirim beberapa kombinasi pesan yang membuktikan bahwa ia adalah klien yang tepat, dan pesan-pesan ini terkait dengan penerbitan permintaan pada prinsip tertentu melalui TGS.

Jadi, klien akan mengirim pesan seperti itu ke TGS: S adalah layanan yang akan digunakan untuk berkomunikasi lebih lanjut, itu bisa berupa mail atau file server, maka ini termasuk tiket klien Tc yang ia terima untuk tgs, dienkripsi menggunakan kunci K tgs dan autentikator yang dienkripsi dengan kunci Kc, tgs umum untuk klien dan layanan TGS. Seperti inilah pesan yang akan Anda kirim ke TGS - katanya: "lihat pesan ini, lakukan sesuatu dengannya dan balas dengan tiket ke layanan S. yang baru ini." Jawabannya di sini terlihat hampir sama seperti pada gambar di atas, dan faktanya sama - ini adalah tiket antara klien dan layanan baru ini, dienkripsi menggunakan Ks. Tapi sekarang sudah sedikit berbeda.



Alih-alih enkripsi dengan kunci Kc, yang harus dilupakan klien sejak saat itu, sekarang enkripsi dilakukan dengan menggunakan kunci umum Kc, tgs antara klien dan layanan TGS.

Bagaimana cara server mengetahui apa yang diinginkan klien dan bagaimana server mengotentikasi klien? Server TGS mengetahui kunci Ktgs sendiri, jadi pertama-tama akan mendekripsi pesan ini Tc, tgs, lihat ke dalam tiket dan cari tahu apa yang terjadi. Mengapa kita membutuhkan semua bidang ini di tiket? Mengapa penting untuk memiliki nama server S di tiket? Apa yang salah jika kita tidak memiliki S?

Siswa: jika tidak ada, maka Anda berpotensi mendapatkan izin untuk menggunakan server apa pun.

Profesor: ya, benar. Secara umum, merupakan ide bagus untuk membuat protokol jaringan sehingga Anda dapat mengatakan dengan tepat apa arti pesan ini. Jika Anda menghilangkan S, Anda dapat mengandalkan fakta bahwa jika Anda menggunakan tiket untuk S yang salah, maka mungkin Anda akan memiliki kunci K yang lain dan itu tidak akan dapat melakukan dekripsi atau sesuatu seperti ini. Jadi sepertinya ide yang baik untuk memasukkan nama layanan untuk memastikan bahwa server yang menerima tiket ini mendekripsi mereka dan memeriksa apakah ini tiket untuk saya atau untuk orang lain?

Siswa: apa yang dilakukan klien dengan kunci Ktgs yang diterima?

Profesor: pertanyaan bagus! Klien tidak tahu apa itu. Karena itu kunci rahasia. Jika Anda mengetahuinya, Anda akan dapat memecahkan semua Kerberos. Jadi klien tidak tahu apa itu Ktgs.

Siswa: dari mana Ktgs ini berasal?

Profesor: server Kerberos sendiri menghasilkan untuk Anda semua pesan ini, yang sudah memiliki Tc, tgs dan Ktgs, Anda tidak membuatnya sendiri, tetapi cukup menyalinnya dari sini.

Jadi mengapa nama pelanggan begitu penting? Ini mudah diketahui. Jika Anda tidak memasukkan nama klien pada tiket, maka server menerima pesan ini, tetapi tidak tahu dengan siapa ia mencoba berbicara. Dia tidak tahu untuk siapa dia harus mengeluarkan tiket - untuk Anda atau orang lain.

Bagaimana dengan bidang lainnya? Mengapa pengembang memasukkan alamat addr pada tiket Tc? Itu hanya alamat IP klien, jadi mengapa tidak menggunakannya secara langsung?



Saya pikir arti dari solusi ini adalah keinginan pengembang untuk meningkatkan keamanan. Mereka ingin memastikan bahwa jika klien login dari beberapa alamat IP, maka semua yang lain pada tiket yang sama berasal dari alamat IP yang sama. Misalnya, jika Anda masuk dari beberapa alamat IP, misalnya 18.26.4.9, maka setiap koneksi ke file atau server mail harus dari alamat IP yang sama. Jika tidak, server harus menolak koneksi Anda, karena mungkin menyarankan seseorang mencuri tiket Anda. Dengan demikian, kami melindungi diri kami di sini dari penggunaan tiket curian. Jika Anda masih memiliki tiket yang sama - baik-baik saja, tetapi jika Anda tidak menggunakan alamat IP yang sama, Anda tidak akan berhasil.

Ini sepertinya kesalahpahaman saat ini, dan Kerberos 5 masih menggunakan pendekatan yang sama, meskipun ini tidak perlu. Memang, Anda hanya harus mengandalkan kriptografi daripada mengamankan alamat IP.

Tapi apa arti cap waktu dan stempel waktu dalam tiket? Untuk apa mereka dan untuk apa mereka berguna?

Siswa: Mereka diperlukan untuk mencegah serangan replay.
Profesor: serangan replay membantu kami mencegah autentikator, karena hal ini dihasilkan setiap kali Anda membuat permintaan baru. Tapi di sisi lain, tiketnya tetap sama, jadi ini, tentu saja, tidak mengganggu serangan replay.

Siswa: ini mencegah seseorang mencuri tiket Anda dan kemudian menggunakannya untuk tujuan mereka sendiri.
Profesor: ya, ini hanya membatasi waktu di mana tiket berlaku, sehingga kerusakan dari pencuriannya berkurang. Stempel waktu adalah waktu Anda menerima tiket, dan masa berlaku menunjukkan berapa jam tiket ini berlaku dari stempel waktu awal. Oleh karena itu, jika Anda mencoba menggunakannya terlalu cepat atau terlambat, maka server mana pun harus menolak tiket tersebut menggunakan protokol Kerberos. Ini berarti bahwa setiap server harus menyinkronkan jamnya.

Siswa: Anda mengatakan sebelumnya bahwa klien dapat membuang kunci awal, membuang Kc, tetapi harus menyimpan Kc, yang diterima dari TGS.

Profesor: ya, memang, klien menjatuhkan Kc setelah masuk, tetapi harus menjaga Kc, s.

Mahasiswa: jadi, jika seseorang mencuri Kc, s, maka ia memiliki akses ...

: , , ? , Kc,tgs, K?

: K,s, , K, .



: . , Kc,s — , , . , Tc,tgs, . , 56 Kc,s. . , Tc,tgs , Kc,s , - .

: , - — Tc,tgs, Kc,tgs, Kc,tgs, Kc — .

: , - , , , , 10 . Kc , .

, , , IP-, . - , , Kc,tgs, TGS. — , , , .

, , , . , , . TGS , , PO12, TGS PO12. , , Kc,s . , , . Kc,s.



, , Tc,mail, Kmail, , , , 5 – DELETE 5, Kc,mail.



, mail? Kmail, - , , Kc,s, Kerberos 5. : «, C , ».

: Kerberos Tc,tgs Kc,s. ?

: Ac . , Kc,s, , . , .



, Kerberos 4 , , , , , , , .

, , , , . , . , , . , , , , . , .
. Kerberos, , , Kerberos 4. , - .

, , , , , Kerberos 4, , , K,mail. , .



, , . , , . - : «, , DELETE 5, - ».

, Kerberos 5 -, . , , , , , .

: K,mail?

: .



, TGS , , S – mail, S Tc,s – mail, S Kc,s — mail. Kc,s K,mail. , .

: K,mail?

: , ? , , . K,mail ?

: ?

: , , ! Kmail, T,mail, , . , , .

, . . Kerberos , , 30 .
Karena itu, tidak dapat dihindari bahwa kami memiliki masalah yang harus Anda pecahkan. Jadi, satu masalah Kerberos 4 yang menarik menyangkut metode mengenkripsi dan mengotentikasi pesan untuk aplikasi. Terdiri dari fakta bahwa kunci yang sama digunakan di sini untuk mengenkripsi pesan dari klien ke server dan untuk pesan tanggapan dari server ke klien.

54:00 mnt

kursus MIT "Keamanan Sistem Komputer". Kuliah 13: Protokol Jaringan, Bagian 3


Versi lengkap dari kursus ini tersedia di sini .

Terima kasih telah tinggal bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikannya kepada teman-teman Anda, diskon 30% untuk pengguna Habr pada analog unik dari server entry-level yang kami buat untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps dari $ 20 atau bagaimana membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps hingga Desember secara gratis ketika membayar untuk jangka waktu enam bulan, Anda dapat memesan di sini .

Dell R730xd 2 kali lebih murah? Hanya kami yang memiliki 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV dari $ 249 di Belanda dan Amerika Serikat! Baca tentang Cara Membangun Infrastruktur Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?