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

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

Misalkan klien mengeluarkan permintaan untuk menerima pesan tertentu, misalnya, "beri aku pesan No. 7," dan mengenkripsi hal ini dengan kunci Kc, mail. Segalanya tampak indah.
Server email memiliki kunci bersama yang akan mendekripsi pesan ini, setelah itu server akan mengirim kembali ke tubuh klien pesan email ini, juga dienkripsi dengan Kc, mail. Adakah yang melihat ini sebagai masalah? Mengapa ini bisa buruk?



Siswa: ada kemungkinan ketika peretas dapat mengganti pesan atau memalsukannya.

Profesor: ya, ini meresahkan karena saya dapat mengirimi Anda email apa pun yang saya inginkan. Misalkan saya bermaksud menghapus beberapa pesan yang ada di kotak masuk Anda karena saya tidak ingin Anda membacanya. Misalkan surat ini ada di nomor 23.

Karena itu, saya akan mengirimi Anda surat yang mengatakan: "hapus No. 23", dan Anda akan membacanya. Anda akan menerimanya, dan balasan yang datang dari server mail dengan perintah "delete No. 23" akan dienkripsi dengan kunci ini Kc, mail. Dan sejauh ini belum dikirim ke server surat.

Tetapi jika saya memindai jaringan pada waktu yang tepat dan melakukan paket ini, saya dapat mengirimkannya kembali ke server surat. Ini akan terlihat seperti pesan "hapus No. 23", dienkripsi menggunakan kunci. Dalam hal ini, server surat akan berkata: "Oh ya, tentu saja, Anda ingin menghapus pesan ini, dan saya akan melakukannya!"

Jadi ada masalah di sini karena kami membolehkan musuh membingungkan server mail, apakah pesan kami dibuat olehnya atau dikirim kepadanya sejak awal.

Inilah yang biasa disebut dalam deskripsi kriptografi dan protokol sebagai "serangan refleksi". Apakah Anda punya saran tentang cara menghindari masalah ini?

Siswa: apakah mungkin untuk hanya memasukkan judul pesan yang berbicara tentang asalnya?

Profesor: ya, sebagai aturan, Anda ingin memiliki semacam cara yang jelas untuk menyatakan apa yang terjadi. Salah satu caranya adalah dengan memiliki header di setiap pesan yang mengatakan: "dari klien ke server" atau "dari server ke klien". Cara yang lebih baik dalam praktek adalah dengan menggunakan dua kunci terpisah.

Karena Anda mungkin ingin memiliki aliran data yang panjang yang mungkin tidak memiliki ruang untuk bit header. Jadi, setiap kali Anda membuat koneksi dengan layanan, Kerberos 5 menegosiasikan penggunaan dua kunci, bukan satu. Kunci pertama akan digunakan untuk mengenkripsi data dari klien ke server, dan yang kedua untuk mengenkripsi data dari server kembali ke klien. Ini adalah metode perlindungan paling optimal untuk penggunaan praktis.

Mari kita bicara tentang apa yang terjadi dengan KDC. Server Kerberos sangat penting bagi sistem, tetapi apa yang terjadi jika KDC ini mogok? Seberapa buruk ini untuk sistem kita? Bagaimana "kejatuhan" KDC akan memengaruhi hidup Anda jika Anda menggunakan Athena?

Siswa: Anda mungkin tidak bisa masuk?

Profesor: ya, benar. Kedua, Anda juga tidak akan bisa mendapatkan tiket untuk permintaan baru. Tetapi yang paling keren adalah bahwa KDC cukup banyak keluar dari jalur kritis untuk koneksi yang ada. Karena itu, tidak ada data yang melewati KDC. Dan jika Anda sudah memiliki tiket untuk sesuatu, Anda dapat terus menggunakannya dan tetap masuk ke beberapa layanan jaringan. Ini sebenarnya cukup bagus di-cache. Saya pikir hal baik kedua yang para pengembang bayangkan adalah potensi untuk meniru KDC. Oleh karena itu, sistem ini memiliki satu server Kerberos utama, yang menyimpan salinan awal seluruh database. Ini memungkinkan Anda untuk membaca hanya replika yang berisi salinan basis data awal. Itu tidak memungkinkan pembaruan apa pun, seperti pendaftaran pengguna atau pembaruan kunci, tetapi memungkinkan Anda untuk merespons permintaan masuk dan TGS.

Dengan demikian, catatan "klon" basis data Kerberos memungkinkan Anda untuk terus masuk dan berkomunikasi dengan layanan, bahkan jika KDC gagal, sampai dihapuskan dan fungsinya sepenuhnya pulih.

Siswa: seberapa sulitkah kompromi dengan server KDC dan sistem secara keseluruhan?

Profesor: KDC adalah tulang punggung dari setiap sistem yang menjalankan Kerberos. Jika layanan ini terganggu, penyerang akan mendapatkan kontrol penuh atas sistem. Dia akan bisa mendapatkan tiket untuk layanan apa pun yang Anda inginkan, berpura-pura menjadi pelanggan yang tepat, jadi itu sangat buruk. Kami benar-benar ingin menjaga keamanan KDC, tetapi sulit. Meskipun saya tidak tahu satu kasus pun di mana KDC MIT akan benar-benar dikompromikan selama sekitar 20 tahun. Tetapi, tampaknya, yang benar-benar perlu dikhawatirkan adalah implementasi perangkat lunak keamanan dari pertukaran dua layanan ini, Kerberos dan TGS. Karena jika buffer overflow terjadi di dalamnya atau kerentanan serupa lainnya muncul, ini sangat buruk.



Sebagai contoh, jika server SSH berjalan pada KDC Kerberos dan seseorang menebak kata sandi root dari server SSH ini, maka ia hanya akan masuk dan menyalin database. Jadi saya pikir Anda benar-benar ingin meminimalkan permukaan serangan di sini, jadi berhati-hatilah saat menulis kode KDC. Jangan biarkan siapa pun secara langsung mengakses layanan ini. Tentu saja, ada beberapa tempat di mana Anda harus dianggap paranoid tentang keamanan, tetapi ini tidak begitu penting untuk server. Tentu saja, mereka menyimpan data, tetapi jika seseorang membobol server surat atau server cetak, mereka dapat dipulihkan.

Ini pertanyaan yang menarik. Misalkan seseorang meretas server surat. Apa yang harus Anda lakukan untuk pulih dari serangan ini? Misalnya, jika seseorang mencuri surat Anda, ini buruk. Tetapi apa yang harus dilakukan untuk mencegah penyerang mendapatkan akses ke email Anda di masa depan?

Kerberos tidak memiliki operasi pembatalan, tetapi Anda dapat membuat kunci baru untuk server surat dan menempelkannya ke dalam basis data KDC. Kemudian Anda memasang server surat baru, memberikannya kunci baru, dan kemudian beberapa penyerang yang memiliki kunci lama dari server surat tidak dapat mempengaruhinya dengan cara apa pun.

Di sisi lain, anggaplah Anda tidak mengubah kunci dari server surat, Kmail. Apa yang akan terjadi?



Siswa: kuncinya tidak akan sesuai dengan server baru.

Profesor: well, misalkan Anda menginstal server email baru, memperbaiki kesalahan yang digunakan peretas. Tapi dia masih memiliki kunci Kmail. Mungkin pemulihan server memakan waktu satu hari, sehingga semua tiket kedaluwarsa. Bisakah hacker ini melakukan sesuatu yang menarik dengan sistem? Jika Anda memberikan Kmail lama ke server email baru - apakah itu buruk?

Siswa: seorang penyerang dapat menyusup ke server surat karena ia dapat mendekripsi tiket pertama.

Profesor: pasti, itu sebabnya Kmail sebenarnya sangat penting. Anda mengatakan bahwa Anda dapat mendekripsi semua yang terjadi di server email. Misalkan klien terhubung ke server surat setelah memperbaikinya, tetapi penyerang masih tahu Kmail, yang tetap ada sejak peretasan terakhir sistem. Oleh karena itu, ia dapat mendekripsi tiket Kmail ini, melihat ke dalam tiket dan mendapatkan kunci sesi. Dengan itu, ia akan dapat mendekripsi semua pesan yang Anda kirim, semua balasan yang Anda terima, dan sebagainya. Karena itu, setelah memulihkan server mail, sangat penting untuk mengubah Kmail ini.

Dalam banyak hal, ini bahkan lebih buruk daripada sekadar melacak lalu lintas, karena jika seorang penyerang mengetahui kunci Kmail ini, ia dapat mensintesis tiket baru untuk server email tanpa menghubungi KDC. Misalkan saya tahu Kmail dan ingin membaca surat dari server surat. Saya hanya akan mengeluarkan tiket ini, saya akan mengumpulkan semua lima bidang ini dalam urutan yang benar, menghasilkan kunci baru dan mengenkripsi menggunakan Kmail. Ini akan terlihat seperti hal nyata yang dihasilkan oleh KDC.

Oleh karena itu, saya hanya terhubung ke server surat, itu akan mendekripsi pesan dengan benar dan berpikir bahwa itu adalah pengguna tertentu, sehingga Anda dapat menyediakannya dengan surat, membagikan kunci bersama dengannya, dan sebagainya. Oleh karena itu, sangat penting bahwa tidak ada yang tahu kunci rahasia layanan ini, karena jika tidak, Anda tidak hanya dapat membuat lalu lintas dapat diuraikan dan terlihat, tetapi juga meniru siapa pun dalam layanan ini.

Siswa: jika server email dipulihkan setelah kegagalan, maka mungkin Anda perlu mengubah kuncinya dalam database?

Profesor: ya, setelah Anda mengembalikan server email setelah kegagalan, Anda perlu memanggil orang yang bekerja dengan KDC ini dan berkata: "server email kami diretas, jadi hapus kunci Ks yang lama dari database dan masukkan yang baru!" Jadi Anda mungkin ingin memiliki semacam mekanisme di luar database untuk membuktikan bahwa Anda benar-benar server email.

Karena kita akan melihat sebentar lagi bagaimana Anda mengubah kunci, misalnya, menggunakan protokol perubahan kata sandi. Anda dapat membuat kata sandi dalam protokol Kerberos, karena jika Anda tahu kata sandi lama, Anda dapat mengubah kata sandi pengguna menjadi kata sandi baru di KDC. Tetapi karena peretas dapat memotong kata sandi yang dikirim melalui surat, Anda mungkin harus menghubungi kantor pendaftaran akun dan meminta mereka untuk mengubah kata sandi Anda ke server surat. Mereka akan menghasilkan kunci baru dan memberikannya kepada Anda sehingga peretas tidak bisa mengenalinya.



Jika tidak, jika penyerang mengetahui kunci Kmail ini, server mail tidak memiliki apa pun untuk membedakan penyerang dari klien yang benar. Pada kenyataannya, penyerang mungkin mengubah kunci, jadi sekarang mereka tahu parameter baru, dan Anda tidak ada di sana, seolah-olah Anda tidak lagi berada di server email. Jadi Anda perlu protokol eksternal untuk prinsip-prinsip pendaftaran awal dalam database dan untuk mengubah kunci jika Anda lupa kata sandi atau seseorang mengubah kata sandi Anda sehingga Anda kehilangan akses.

Oleh karena itu, ada sekelompok orang di MIT yang membantu pengguna mendaftar akun dan mengubah kata sandi mereka. Untuk melakukan ini, Anda memberikan mereka ID MIT Anda, dan apa pun yang terjadi, mereka akan dapat mengubah kunci untuk Anda.

Karena itu, sangat penting untuk melakukannya dengan benar. Karena jika orang yang memungkinkan Anda untuk mereset kata sandi salah ketika memeriksa ID MIT Anda, maka Anda dapat membahayakan sistem, kan? Jadi orang-orang di Kerberos ini adalah bagian dari basis komputasi yang tepercaya.

Mari kita lihat penggunaan lain yang menarik dari Kerberos. Anda dapat menggunakan Kerberos untuk masuk ke komputer jarak jauh melalui SSH. Dan cara kerjanya sangat mirip dengan bekerja dengan server mail. Anda mendapatkan tiket untuk server SSH, dan Anda mengirim tiket beserta koneksi SSH Anda. Tetapi bagaimana jika Anda terhubung ke Athena.dial-up dan Anda tidak memiliki klien Kerberos di komputer Anda? Anda hanya ingin masuk ke Athena.dial-up dengan kata sandi Anda yang biasa.

Jadi bagaimana Athena dial-up mengotentikasi Anda jika Anda hanya terhubung ke mesin ini dengan kata sandi? Anda tidak memiliki kata sandi untuk Athena.dial-up, ini adalah kata sandi untuk server Kerberos. Jadi apa yang harus dilakukan oleh komputer dial-up jika Anda login dengan kata sandi?

Dial-up dial-up akan berfungsi menggunakan protokol yang sama dengan masuk. Jadi dia akan mengirim permintaan dari klien ke server Kerberos dengan permintaan untuk memberikan tiket, misalnya, ke nama pengguna "Alice". Dan kembali, klien akan menerima respons yang dienkripsi dengan kata sandi Alice. Kemudian dia akan mencoba menerapkan kata sandi dan melihat apakah dia mendekripsi dengan benar. Jika didekripsi dengan benar, maka Anda dapat masuk ke sistem.

Siswa: Anda bahkan tidak perlu mengirim kunci Anda ke server SSH, karena dalam koneksi ini server KDS dapat mengirim pengguna Kc kembali melalui koneksi SSH.

Profesor: mungkin saja ya, tapi itu membutuhkan imajinasi klien SSH, yang mungkin tidak. Tetapi pada prinsipnya ini benar. Jika Anda ingin melakukan ini dengan benar, Anda mungkin ingin memiliki klien Kerberos di komputer Anda dan mendapatkan tiket sendiri, atau mungkin menggunakan server SSH untuk penerusan, sementara tidak mengizinkan server SSH untuk memiliki kunci Anda.

Ini mungkin rencana yang bagus. Tetapi ternyata pada kenyataannya, ini adalah hal yang agak berbahaya yang memungkinkan siapa pun untuk masuk ke server SSH. Sebelumnya kami berbicara tentang klien yang mencoba masuk. Klien ini tahu bahwa dengan memberikan kata sandi legal, ia menerima respons dari server Kerberos yang benar, dan jika ia dapat mendekripsi responsnya, maka kata sandi itu mungkin bekerja dengan benar.

Namun, tidak ada dalam protokol ini yang mengkonfirmasi fakta bahwa respons ini berasal dari server Kerberos yang benar. Karenanya, jika saya mencoba masuk ke mesin hanya dengan memasukkan kata sandi, mesin akan mengirimkan permintaan ini ke server. Kemudian, respons akan dikembalikan ke permintaan ini, yang tampaknya dienkripsi dengan kata sandi yang saya masukkan, tetapi jawaban ini mungkin juga tidak dari server Kerberos.

Misalkan saya memiliki mesin yang ingin saya masuki. Saya memasukkan kata sandi X, dan kemudian mesin mengirimkan permintaan ini dari, ke server Kerberos.



Tetapi sebelum server Kerberos mengirimkan jawaban nyata kepada klien, saya akan mengirim tanggapan saya sendiri, yang terlihat seperti jawaban nyata, dienkripsi dengan kata sandi X. Dan kemudian workstation yang saya coba masuki atau server SSH akan mencoba mendekripsi jawaban ini dengan kata sandi palsu saya. Ini akan terlihat bagus, karena respons ini dihasilkan oleh saya alih-alih server Kerberos yang asli. Karena itu, saya bisa masuk bukan Anda. Mengapa ini terjadi?

Siswa: karena tidak ada otentikasi dari server Kerberos.

Profesor: ya, tidak ada di sini yang akan menautkan ini ke server Kerberos nyata. Cara Kerberos memperbaiki ketidaknyamanan ini untuk komputer jarak jauh, seperti Athena.dial-up, adalah bahwa komputer dial-up sendiri memiliki semacam kunci rahasia yang mereka bagikan dengan KDC. Oleh karena itu, untuk masuk ke dial-up atau workstation yang benar-benar peduli untuk memeriksa apakah Anda benar-benar pengguna yang tepat, dua hal dilakukan.

Login pertama ke Kerberos terjadi seperti yang ditunjukkan pada diagram. Tetapi dia tidak akan mempercayai siapa pun hanya karena jawaban ini didekripsi dengan benar. Dia akan mencoba mendapatkan tiket layanan untuk dirinya sendiri menggunakan TGS, karena komputer dial-up ini memiliki kunci rahasia sendiri. Pada tahap pertama, dia hanya mendaftarkan Anda, dan kemudian beralih ke TGS, mengatakan: "tolong beri saya tiket layanan berdasarkan prinsip saya sendiri, berdasarkan dial-up, untuk klien ini".

Kemudian dia menerima respons dan memeriksa apakah dia dapat mendekripsi dengan benar, karena dia tahu kunci dial-up untuk Ks ini. Dan jika didekripsi, itu berarti bahwa komputer sedang berbicara dengan server Kerberos yang benar. Karena hanya server Kerberos yang benar di tahap kedua yang dapat mengirimkan saya tiket terenkripsi dengan kunci rahasia Kdial-up saya.

Jadi ini sebenarnya sangat penting. Biasanya, workstation Athena tidak mengambil langkah ekstra ini karena workstation Athena tidak memiliki kunci rahasia yang tersimpan di dalamnya dan dibagikan dengan KDC. Mengapa workstation Athena dianggap normal untuk memberi Anda kesempatan masuk pada tahap pertama, tetapi tidak memberi kesempatan seperti itu untuk dial-up?

Siswa: ini normal jika Anda tidak memiliki akses ke layanan apa pun karena penyerang tidak dapat memalsukan tiket.

Profesor: ya, ini benar, karena tidak ada yang menarik di workstation dial-up itu sendiri. Bahkan jika Anda memiliki akses root, atau Anda memasuki workstation dengan kata sandi palsu, ini tidak mengganggu siapa pun. Bukannya mereka bisa melakukan hal lain di luar stasiun kerja mereka. Pada dial-up, semuanya jauh lebih menarik. Mungkin Anda memiliki proses lain yang berjalan dari sesi lain di workstation dial-up, dan fakta bahwa Anda masuk dengan UID khusus Unix, dan mereka benar-benar ingin memastikan bahwa Anda adalah entitas yang tepat, penting di sana. . Itu sebabnya mereka melakukan proses dua langkah untuk memasuki mesin, yang secara bersamaan digunakan oleh beberapa pengguna.

Hal terakhir yang ingin saya bicarakan adalah bagaimana kami mengganti kunci. Kami mengajukan gagasan bahwa Anda dapat kompromi kunci server surat. Tetapi sebagai pengguna, Anda mungkin juga ingin mengubah kata sandi. Misalnya, Anda berpikir bahwa kata sandi Anda tidak cukup aman, Anda menulisnya di selembar kertas, dan seseorang mungkin memata-matainya, jadi sekarang Anda ingin mengubahnya.

Dalam arti tertentu, ini cukup sederhana. Selain layanan Kerberos dan TGS, antarmuka server Kerberos memiliki layanan tambahan yang disebut Kpassword, yang memungkinkan Anda mengubah kata sandi.



Anda mendapatkan tiket untuk menggunakan layanan ini seperti tiket ke server surat atau server lain. Setelah itu, Anda mengirim kata sandi baru ke layanan Kpassword ini, dienkripsi dengan kunci sesi Anda. Dan kemudian, jika semua cek lulus, kunci Anda dalam database akan diperbarui dengan kunci baru.

Jika Anda ingat, kami memiliki tujuan - jika seseorang mencuri tiket Anda, ia seharusnya tidak cukup baik untuk memberikan kesempatan untuk sepenuhnya menangkap akun Anda. Untuk alasan ini, layanan Kpassword tidak menerima tiket apa pun, tetapi hanya tiket yang awalnya Anda terima dari layanan Kerberos dengan kunci Kc Anda. : , , , , – Kerberos TGS – . : Kerberos, , TGS, .
Kpassword, , , : «, Kerberos, . TGS, , , , - , . ».

, Kpassword , , , Kerberos. , Kpassword , Kerberos Kpassword.

Kpassword, - . , , Kerberos. Kerberos, ID , Kpassword.



Kerberos , Kpassword, Kpass, Kc,kpass Kpassword, Kc.

, – Kpassword, Tc,kpass, Kpass, , new pass Kc,pass, .

, , , , . - Athena, , , , . , , Gmail, , . , Kerberos TGS , - , .

, - Athena , , , . , . , . Tc,kpass, Kpassword, TGS, . , Kerberos Kc.

: , ?

: K . Kerberos , . , K. - K, .

: , ?

: , - , , . .

, , , , , , .

: , , .

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

: K, ?

: , K – 56- DES, , , 56 , , 7 , . .

, , . , , , , . Kerberos?



: …

: , , , , , , . ?

: .

: , .

: - , , , , …

: , , Kerberos , , , . . , , , «» - , ! : „, Kc,pass, K. Kc,pass , Kpassword». , , KDC. , .
, , - , - . .

: , Kerberos ?

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

, Kerberos 5. , , , . , . , X, Kpassword - Y. , , . , g X , g Y.



gy X, gxy, gx Y gxy. gxy , . , , gxy. , , - gxy, . , .

: - G.

:ya tentu saja. G adalah beberapa parameter yang dapat Anda kirim di awal protokol atau sebelumnya ditempatkan di Kerberos, itu tidak terlalu penting. Bagaimanapun, jika Anda menggunakan protokol enkripsi pertukaran Diffie-Hellman, Kerberos 5 melakukannya dengan benar. Tetapi Anda perlu tahu tentang keberadaan protokol ini jika Anda mengembangkan beberapa protokol baru Anda sendiri. Jadi itu saja yang ingin saya bicarakan Kerberos, dan pada hari Senin mari kita bicara tentang SSL.


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?