Kursus MIT "Keamanan Sistem Komputer". Kuliah 14: "SSL dan HTTPS", 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
Kuliah 14: "SSL dan HTTPS" Bagian 1 / Bagian 2 / Bagian 3

Saya pikir penegakan HTTPS adalah karena kekhawatiran bagi pengguna yang memiliki terlalu banyak keleluasaan dalam memutuskan apakah akan menggunakan sertifikat.

Masalah lain yang memanifestasikan dirinya dalam praktik dan yang juga memaksa penggunaan HTTPS adalah lampiran tidak aman atau konten campuran pada halaman web. Inti dari masalah ini adalah bahwa situs yang aman atau situs web apa pun, dalam hal ini, dapat menyematkan konten lain di halaman web.

Jadi jika Anda memiliki beberapa jenis situs web, misalnya foo.com/index.html, maka itu dapat disajikan menggunakan protokol HTTPS, tetapi di dalam halaman HTML Anda dapat memiliki banyak tag yang memaksa browser untuk pergi ke suatu tempat dan menjadikannya bagian Halaman ini memiliki beberapa jenis konten asing.



Tag untuk skenario ini terlihat seperti ini:

<script scr = «http://jquery.com/…”> 

Dan menunjuk ke sumber jquery.com. Dengan demikian, perpustakaan JavaScript yang populer memfasilitasi interaksi banyak hal di browser Anda. Tetapi banyak pengembang web hanya menautkan ke URL situs lain. Ini membuat segalanya lebih mudah, tetapi apa yang bisa menjadi tangkapannya? Misalkan Anda memiliki situs yang aman dan Anda hanya mengunduh jQuery dari sana.

Mahasiswa: bisa jQuery palsu.

Profesor: ya, benar. Sebenarnya ada dua cara untuk mendapatkan hal yang salah yang tidak Anda harapkan diterima. Satu kemungkinan adalah bahwa jQuery itu sendiri dapat dikompromikan. Anda mendapatkan sesuatu yang mirip dengan apa yang Anda minta. Jika jQuery dikompromikan, maka ini sangat buruk. Kemungkinan lain adalah bahwa permintaan ini akan dikirim melalui jaringan tanpa enkripsi atau otentikasi. Oleh karena itu, jika musuh mengontrol koneksi jaringan Anda, ia dapat mencegat permintaan ini dan mengirimi Anda kode JavaScript lain sebagai tanggapan, dan sekarang kode JavaScript ini akan berfungsi sebagai bagian dari halaman Anda. Dan karena ia bekerja di domain HTTPS foo.com, ia memiliki akses ke cookie foo.com yang dilindungi dan hal lainnya di halaman ini. Ini sepertinya hal yang sangat buruk, jadi berhati-hatilah. Dan pengembang web juga harus berhati-hati untuk tidak membuat kesalahan semacam ini.

Dengan demikian, salah satu solusinya adalah memastikan keamanan semua konten yang tertanam di halaman yang aman. Ini adalah panduan yang baik untuk diikuti oleh banyak pengembang web. Jadi mungkin Anda sebaiknya menggunakan jquery.com di baris ini alih-alih jquery.com . Atau jika URL mendukung kebijakan asal, ini berarti Anda dapat menghilangkan bagian dari HTTPS dan hanya mengatakan bahwa asal skrip ini adalah //jquery.com/, yaitu, scr = "//jquery.com / ..."



Dan ini berarti bahwa tag ini akan mengirim Anda ke jquery.com jika ada di halaman HTTPS, dan ke jquery.com jika bukan di HTTPS, tetapi di URL HTTP biasa. Ini adalah salah satu cara untuk menghindari masalah seperti itu.

Namun, orang-orang terus berusaha untuk memperbaiki segalanya, jadi salah satu cara alternatif untuk menyelesaikan masalah ini adalah dengan memasukkan hash atau sesuatu seperti indikator di sini di tag:

 <script scr = «http://jquery.com/…”> 

Karena jika Anda tahu konten apa yang ingin Anda unduh, Anda mungkin tidak perlu mengunduhnya sepenuhnya menggunakan protokol HTTPS. Bahkan, Anda tidak peduli siapa yang menyediakan konten ini selama ia cocok dengan hash tertentu.

Jadi, ada spesifikasi baru yang memungkinkan Anda mengonfigurasi hash untuk tag jenis ini. Jadi, alih-alih menautkan ke jquery.com dengan URL HTTPS, Anda bisa mengatakan bahwa sumber skrip adalah jquery.com atau bahkan HTTP, tetapi pada akhir skrip Anda menambahkan beberapa jenis atribut tag, misalnya hash sama dengan apa yang Anda berharap dapatkan dari server.



Mahasiswa: apa nama spesifikasi ini?

Profesor: ia memiliki nama yang kompleks, ada di catatan catatan kuliah, sesuatu seperti "integritas sumber daya", integritas sumber daya. Ini sedang dilaksanakan agak lambat, tetapi saya berharap bahwa dalam waktu dekat ini akan diterapkan di berbagai browser. Ini mirip dengan cara lain untuk mengotentikasi konten tanpa bergantung pada enkripsi data di tingkat jaringan.

Dengan demikian, kami memiliki paket yang sangat umum ini yang menggunakan SSL dan TLS untuk mengautentikasi koneksi ke server tertentu. Ini adalah cara alternatif untuk melindungi koneksi jaringan Anda. Jika Anda peduli dengan integritas, maka Anda mungkin tidak memerlukan saluran jaringan yang aman dan dienkripsi. Yang perlu Anda lakukan adalah menentukan apa yang sebenarnya ingin Anda dapatkan pada akhirnya.

Siswa: Bukankah kode SRC ini berasal dari klien?

Profesor: dia bekerja di sisi klien, tetapi klien menerima kode ini dari beberapa server.

Siswa: Tidak bisakah ada yang memasukkan kode JavaScript mereka ke halaman?

Profesor: Saya pikir itu bisa. Oleh karena itu, makna hash adalah melindungi konten halaman dari penyusup yang mencoba memasukkan kode JavaScript yang berbeda. Untuk jQuery, ini sangat penting karena jQuery terkenal, karena Anda tidak mencoba menyembunyikan kode sumber jQuery. Oleh karena itu, Anda ingin memastikan bahwa penyerang jaringan tidak dapat mencegat koneksi Anda dan memasukkan versi berbahaya dari jQuery, yang akan menyebabkan kebocoran cookie. Memang benar bahwa siapa pun dapat mengetahui hash dari hal-hal ini untuk diri mereka sendiri. Dengan demikian, ini adalah solusi untuk masalah integritas, bukan privasi.

Saya pikir pengembang harus mengawasi ini ketika mereka menulis halaman atau memasukkan konten halaman HTML mereka di URL HTTPS. Kekhawatiran lain yang kami miliki adalah dengan cookie. Di sinilah perbedaan antara cookie dengan bendera keamanan dan hanya cookie dengan asal asalnya ikut bermain. Satu-satunya hal yang dapat merusak pengembang di sini adalah hanya lupa untuk menetapkan bendera pada cookie di tempat pertama, ini terjadi. Mungkin dia hanya memikirkan pengguna yang hanya akan pergi ke URL HTTPS, dan menganggap pengaturan bendera tidak perlu. Apakah ini masalah? Jika pengguna Anda sangat berhati-hati dan selalu mengunjungi URL HTTPS, tidak ada masalah. Apakah menurut Anda masuk akal dalam hal ini untuk meninggalkan bendera keamanan di cookie Anda?

Siswa: apakah ada kemungkinan penyerang dapat terhubung ke URL Anda dan mengarahkan Anda ke situs jahat?

Profesor: ya. Bahkan jika pengguna tidak secara eksplisit pergi ke beberapa URL dalam bentuk teks biasa, penyerang masih dapat memberinya tautan ke situs yang tidak aman atau memintanya untuk mengunduh gambar dengan URL selain HTTPS. Dan kemudian cookie yang tidak aman akan dikirim bersama dengan permintaan jaringan. Jadi ini adalah masalah, dan Anda benar-benar membutuhkan bendera, bahkan jika pengguna dan aplikasi Anda sangat berhati-hati.

Mahasiswa: Saya berasumsi bahwa ada URL HTTP aman.
Profesor: ya, itu benar. Misalkan saya memiliki situs web yang bahkan tidak mendengarkan pada port 80 dan tidak ada cara untuk terhubung ke saya melalui port 80, jadi mengapa mungkin ada masalah jika saya menggunakan cookie tidak aman?

Siswa: karena browser tidak akan dapat mengirim cookie Anda ke domain lain.

Profesor: Benar, browser tidak akan mengirim cookie ke domain lain, tetapi masih ada bahaya bahwa penyerang bisa mengunduh URL-nya. Jadi, anggap saja amazon.com hanya menggunakan SSL, bahkan tidak mendengarkan pada port 80. Akibatnya, mereka tidak menetapkan bendera aman mereka pada cookie. Jadi bagaimana seorang hacker dapat mencuri cookie mereka jika Amazon bahkan tidak mendengarkan pada port 80?

Siswa: dapatkah browser masih berpikir bahwa ini adalah koneksi HTTP?

Profesor: baik, jika Anda terhubung ke port 443 dan menggunakan SSL atau TLS, maka koneksi akan selalu dienkripsi, jadi ini bukan masalah.

Mahasiswa: Seorang penyerang dapat mencegat koneksi.

Profesor: ya, penyerang dapat mencegat paket Anda yang mencoba terhubung ke Amazon melalui port 80, dan berpura-pura bahwa Anda berhasil terhubung ke situs. Jadi, jika penyerang memiliki kendali atas jaringan Anda, ia dapat mengarahkan paket Anda yang diarahkan ke Amazon ke port 80 dari mesinnya sendiri, dan klien tidak akan dapat melihat perbedaannya. Tampaknya Amazon mendengarkan pada port 80, tetapi pada kenyataannya cookie Anda akan dikirim ke server web peretas ini.

Mahasiswa: karena klien tidak dikenal.

Profesor: Benar, karena HTTP tidak memiliki cara untuk memverifikasi keaslian host yang terhubung dengan Anda. Inilah yang sedang terjadi. HTTP tidak memiliki otentikasi. Karena itu, jika Anda berasumsi bahwa ada musuh jaringan, Anda harus terlebih dahulu mencegah cookie Anda dikirim melalui HTTP, karena Anda tidak tahu kepada siapa koneksi HTTP ini akan pergi.

Siswa: untuk ini, Anda perlu mengontrol jaringan.

Profesor: ya, tentu saja. Jika Anda memiliki kontrol penuh atas jaringan Anda, maka Anda tahu bahwa lawan tidak akan dapat mencegat paket Anda. Namun, bahkan dengan kontrol penuh atas jaringan, Anda mungkin memiliki masalah, lihat materi untuk ceramah tentang TCP, berbagai jenis serangan jaringan dianggap ada.

Hadirin: Tetapi apakah tidak mungkin dalam kasus ini untuk mencegah serangan pengalihan?

Profesor: Peretas kemungkinan akan mencegat permintaan http klien di amazon.com , dan permintaan ini akan mencakup semua cookie Anda untuk amazon.com, atau cookie untuk domain lain tempat Anda mengirim permintaan. Karenanya, jika Anda tidak menandai cookie ini sebagai aman, cookie dapat dikirim baik melalui koneksi terenkripsi dan tidak terenkripsi.

Siswa: bagaimana permintaan ini dimulai?

Profesor: mungkin Anda bisa membuat pengguna mengunjungi newyorktimes.com, tempat Anda membayar iklan yang mengunggah gambar dari amazon.com . Dan tidak ada yang akan melindungi pengguna dari bertanya: "silakan unduh gambar dari URL ini." Tetapi ketika browser mencoba terhubung ke situs, itu akan mengirim cookie jika koneksi berhasil.

Ada ekstensi HTTPS Everywhere, yang sangat mirip dengan Force HTTPS, atau HTTPS paksa, dan yang berupaya untuk mencegah kesalahan semacam ini. Ketika Anda memilih situs dalam mode HTTPS yang dipaksakan, browser terutama akan mencegah koneksi HTTP ke host ini.



Dengan demikian, tidak ada cara untuk tidak menandai cookie Anda sebagai aman atau membuat kesalahan serupa. Jika pengembang lupa menetapkan bendera keamanan pada cookie, dalam hal ini solusinya jelas - ia hanya perlu memperbaiki kesalahannya. Tetapi ada masalah yang lebih rumit: ketika server web yang aman menerima cookie klien kembali, ia tidak tahu apakah cookie ini dikirim melalui koneksi teks terenkripsi atau biasa. Karena pada kenyataannya, server hanya menerima beberapa nilai kunci untuk cookie.

Dari rencana tindakan yang dibahas di atas, dapat disimpulkan bahwa ketika mengirim permintaan ke server yang aman, browser akan menyertakan cookie yang aman dan tidak aman, karena untuk bagiannya, ini menyangkut kerahasiaan mereka. Tetapi di sisi server tidak ada jaminan kerahasiaan, dan ketika server menerima cookie pengguna, mereka dapat dikirim baik melalui koneksi terenkripsi maupun teks. Ini mengarah pada kemungkinan serangan seperti fiksasi sesi.

Ini berarti bahwa seorang penyerang, misalnya, ingin melihat email mana yang Anda kirim. Untuk melakukan ini, dia akan membuatkan Anda cookie sendiri, yang merupakan salinan cookie dari akun Gmail-nya. Dan ketika Anda mengirim surat Anda, itu akan muncul di folder Item Terkirimnya, dan tidak di folder Anda. Ini akan seolah-olah Anda menggunakan akun penyerang, sehingga ia dapat mengekstrak korespondensi Anda dari kotak suratnya. Jadi jika seorang hacker secara paksa memasukkan cookie sesi ke browser Anda, maka dia akan memaksa Anda untuk menggunakan akunnya. Jadi ini adalah masalah lain yang muncul karena kesalahpahaman dengan pemisahan cookie HTTP dan HTTPS yang tidak lengkap.

Siswa: tetapi untuk memasukkan cookie Anda ke browser orang lain, Anda perlu memiliki kerentanan di sana.

Profesor: tidak, untuk mengatur cookie Anda, kerentanan tidak diperlukan. Anda hanya menipu peramban agar terhubung ke URL host HTTP normal. Dan jika peramban tidak memiliki ekstensi, seperti Force HTTPS atau HTTPS Everywhere, Anda, sebagai penyerang, dapat mengatur kunci di peramban pengguna. Ini adalah cookie yang tidak aman, tetapi akan dikirim kembali, bahkan untuk permintaan yang aman.

Siswa: bagaimana Anda dapat membuat browser berpikir bahwa domain ini adalah domain yang sama?
Profesor: untuk ini, Anda harus mencegat koneksi jaringan dan melakukan salah satu jenis serangan yang telah kita bicarakan beberapa menit yang lalu.

Jadi apa yang sebenarnya dilakukan HTTPS? Dia berusaha mencegah beberapa dari banyak masalah. Studi tentang protokol Force HTTPS diterbitkan 5 atau 6 tahun yang lalu. Sejak itu, telah distandarisasi dan benar-benar diadopsi. Itu terlihat seperti plugin samar yang menyimpan beberapa hal dan beberapa cookie. Saat ini, sebagian besar pengembang browser percaya bahwa membuatnya adalah ide yang baik. Cara terbaik untuk mengintegrasikannya langsung ke browser. Ada sesuatu yang disebut HTTP Strict Transport Security, atau HSTS, suatu mekanisme untuk memaksa koneksi yang aman melalui protokol HTTPS. Ini adalah contoh yang baik tentang bagaimana penelitian ilmiah mempengaruhi keamanan aplikasi web dan browser.

Mari kita lihat apa yang dilakukan Force HTTPS untuk situs web. HTTPS Paksa memungkinkan situs web untuk mengatur bit ini untuk nama host tertentu, dan ada tiga hal yang memaksa HTTPS untuk mempengaruhi perilaku browser.

Yang pertama adalah bahwa kesalahan sertifikat selalu berakibat fatal. Dengan demikian, pengguna tidak memiliki kesempatan untuk menerima sertifikat yang salah dengan nama host yang salah atau kedaluwarsa, dan sebagainya. Ini adalah satu hal yang mengubah browser.

Yang kedua adalah bahwa Force HTTPS mengalihkan semua permintaan HTTP ke HTTPS. Ini ide yang bagus. Jika Anda tahu bahwa situs selalu menggunakan HTTPS secara sah, maka Anda mungkin harus melarang permintaan HTTP reguler, karena ini mungkin merupakan tanda kesalahan atau bukti bahwa penyerang berusaha menipu Anda agar menawarkan untuk terhubung ke situs tanpa enkripsi. . Anda ingin memastikan bahwa ini benar-benar terjadi sebelum permintaan HTTP dijalankan, jika tidak, permintaan HTTP apa pun akan masuk ke jaringan.

Dan hal terakhir yang memaksa Angkatan HTTPS lakukan adalah browser itu melarang rencana penyematan tidak aman yang kita lihat sebelumnya - ketika Anda menanamkan URL HTTP di situs HTTPS.



Jadi inilah yang dilakukan ekstensi Force HTTPS. Berdasarkan terminologi yang digunakan saat ini, protokol HSTS melakukan hal yang sama. Sekarang sebagian besar peramban secara default melarang penyematan tidak aman. Ini kontroversial, karena banyak pengembang memiliki masalah karena Force HTTPS, tapi saya pikir Firefox, Chrome dan IE secara default akan menolak untuk memuat komponen tidak aman, atau setidaknya JavaScript dan CSS tidak aman ke halaman Anda jika Anda maka lakukanlah yang salah.

Mahasiswa: mereka tidak bertanya kepada pengguna tentang kinerja tindakan apa pun?

Profesor: mereka terbiasa dengan fakta bahwa biasanya pengguna setuju. Misalnya, IE menggunakan dialog sembulan yang menanyakan apakah Anda ingin mengunduh konten tambahan, atau sesuatu seperti itu. Saya pikir jika Anda mencoba, Anda dapat menghindari semua langkah-langkah keamanan ini, tetapi saya tidak menyarankan Anda untuk melakukan ini. Dengan demikian, browser modern mencoba memecahkan beberapa masalah menggunakan Force HTTPS dan HSTS.

Siswa: apa yang terjadi ketika sebuah situs tidak mendukung HTTPS?

Profesor: apa maksudmu

Siswa: bahwa browser tidak akan terhubung ke situs melalui HTTPS.

Profesor: apa yang terjadi jika Anda memiliki situs web yang tidak mendukung HTTPS tetapi mengatur cookie ini? Faktanya adalah bahwa jika Anda menggunakan opsi ini di browser Anda, Anda tidak akan dapat berbicara dengan sebagian besar Internet, karena mereka tidak menggunakan HTTPS. Karena itu, browser harus dapat berkomunikasi melalui HTTPS dengan situs-situs yang benar-benar menginginkan perlindungan tersebut.

Siswa: jika saya ingat dengan benar, Anda tidak dapat mengatur cookie sampai situs mengizinkannya.

Profesor: ya, itu benar. Orang-orang ini khawatir tentang serangan DoS, di mana plugin ini dapat digunakan untuk menyebabkan masalah ke situs lain. Misalnya, jika Anda mengatur bit Force HTTPS untuk beberapa situs web yang tidak menaruh curiga, maka mereka akan tiba-tiba berhenti berfungsi, karena sekarang semua orang akan mencoba untuk menyambungkannya melalui HTTPS, yang tidak mereka dukung. Jadi ini adalah salah satu contoh yang khawatir tentang kemungkinan menggunakan serangan DoS dengan menggunakan HTTPS paksa untuk situs yang tidak mengandalkan ini.

Hal lain adalah protokol ini tidak mendukung penggunaan Force HTTPS untuk seluruh domain. Misalnya, saya adalah pengguna mit.edu yang telah menetapkan cookie Force HTTPS di semua browser, dan sekarang hanya koneksi HTTPS yang berfungsi di MIT. Ini sepertinya sedikit bencana, jadi Anda mungkin ingin menghindari situasi yang sama.

Di sisi lain, protokol HSTS kembali ke ini, mengatakan bahwa Anda dapat mengatur Force HTTPS untuk seluruh subdomain, karena ternyata berguna untuk cookie tidak aman yang dikirim bersama dengan permintaan jika Anda tidak tahu dari mana mereka awalnya dikirim. Ada banyak pengaturan untuk hal-hal ini di tingkat terendah, tetapi masih belum jelas apa arti pilihan yang tepat dalam kasus ini.

Ada pertanyaan menarik yang bisa Anda tanyakan: apakah perbaikan ini mendasar atau hanya ditujukan untuk membantu pengembang menghindari kesalahan? Misalkan Anda memiliki pengembang yang sangat bertanggung jawab yang tidak mengambil tindakan berbahaya, memperbarui sertifikat tepat waktu, membuat yang baru - apakah ia perlu menggunakan Force HTTPS?

Mahasiswa: tentu saja, karena tidak ada yang akan menghentikan peretas yang akan memaksa pengguna untuk mengunduh sesuatu melalui HTTP, dan kemudian menyadap koneksi.

Profesor: itu benar. Tetapi jika Anda merasa bahwa dia sangat rajin, dan semua cookie-nya ditandai sebagai aman, maka jika seseorang mengunjungi versi HTTP situs Anda, ini seharusnya tidak menimbulkan masalah.



Namun, Anda mungkin masih harus bertahan melawan menimpa cookie atau serangan injeksi. Ini melelahkan, tetapi Anda mungkin bisa melakukan sesuatu.

Mahasiswa: Saya pikir pengembang dalam hal apa pun tidak akan dapat memverifikasi keaslian sertifikat, bukan?

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

: , , HTTP HTTPS, , , .

: , UI, - , . URL-. amazon.com, , , . HTTPS amazon.com, HTTP URL . , URL-, , amazonn.com amazon.com. . , Force HTTPS.



– Force HTTPS ? ?

: , .

: . , , Force HTTPS HTTPS . , . , Force HTTPS, , , HTTP, HTTPS. , HTTPS. , , HTTPS.

: Force HTTPS?

: , , , . , , , , , , , Force HTTPS .

, amazon.com Force HTTPS, , , , amazon.com, .



. DNSSEC. DNSSEC, , , , HTTPS Force HTTPS, DNS-. , DNSSEC, , , .

Google , . , Chrome , Force HTTPS. Chrome, , CRL Force HTTPS, . , , , . , Google, , , .

Tentu saja, saat ini Google mengatakan bahwa situs mana pun dapat dimasukkan ke dalam browser karena daftar yang ada sangat kecil, tetapi jika berkembang menjadi jutaan entri, saya yakin Google akan berhenti memasukkan semua situs dalam daftar browser. Tetapi sekarang Anda benar-benar dapat menambahkan domain Anda di sana hanya dengan mengirim email ke pengembang Chrome dan situs Anda akan terdaftar dalam URL Force HTTPS.


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?