Kursus MIT "Keamanan Sistem Komputer". Kuliah 12: Keamanan 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

Siswa: mungkin Anda masih memiliki masalah konflik kepentingan karena Anda dapat menggunakan 32 bit untuk alamat rekan dan Anda memiliki banyak port untuk masing-masing. Anda mungkin memiliki konflik nomor urut dari semua koneksi ini yang Anda dapatkan?

Profesor: ternyata nomor urut ini khusus untuk alamat IP dan nomor port dari pasangan sumber / tujuan. Jadi jika ini adalah port yang berbeda, maka mereka tidak saling mengganggu sama sekali. Secara khusus, port memiliki nomor seri yang lebih rendah.



Siswa: jika nomor seri bersifat global, dapatkah penyerang masuk ke koneksi antara klien lain?

Profesor: ya, ini adalah poin yang bagus. Bahkan, jika server menambah nomor seri, misalnya, sebesar 64k untuk setiap koneksi, Anda terhubung ke server, dan kemudian 5 orang lainnya terhubung, dan di sini Anda dapat mengatur serangan. Jadi sampai batas tertentu, Anda benar, ini sedikit merepotkan. Di sisi lain, Anda mungkin bisa membuatnya sehingga paket dari baris terakhir S-> A akan dikirimkan segera sebelum paket itu di baris pertama C-> S. Jika Anda mengirim paket Anda satu per satu, ada kemungkinan besar bahwa mereka akan tiba di server satu per satu juga.

Server akan menerima S-> A dan merespons dengan nomor urut ini (SN). Ini akan berbeda dari (SN) di baris kedua, tetapi dengan nomor seri segera mengikutinya. Dan kemudian Anda akan tahu persis apa nomor urut (SN) yang harus dimasukkan dalam paket ketiga dari urutan Anda.
Oleh karena itu, saya pikir ini bukan cara yang sangat dapat diandalkan untuk terhubung ke server, ini didasarkan pada asumsi. Tetapi jika Anda dengan hati-hati mengatur paket Anda dengan cara yang benar, Anda dapat dengan mudah menebak urutannya. Atau mungkin Anda akan mencoba beberapa kali dan Anda akan beruntung.

Siswa: bahkan jika angka dihasilkan secara kebetulan, Anda perlu menebak salah satu dari 4 miliar angka yang mungkin. Ini tidak terlalu banyak, bukan? Saya pikir dalam satu tahun Anda mungkin akan dapat masuk ke jaringan ini.

Profesor: ya, Anda benar sekali. Anda seharusnya tidak terlalu mengandalkan TCP dalam hal keamanan. Karena Anda benar, itu hanya 4 miliar tebakan. Dan Anda mungkin dapat mengirim banyak paket di siang hari jika Anda memiliki koneksi yang cukup cepat.

Jadi di sini kami memiliki semacam argumen menarik tentang TCP tidak dapat diandalkan, karena kami hanya memiliki 32 bit. Kita tidak bisa mengamankannya dengan cara apa pun. Tetapi saya berpikir bahwa banyak aplikasi yang mengandalkan protokol ini cukup tidak memikirkan keamanan sama sekali, dan ini benar-benar menjadi masalah.

Tapi kamu benar sekali. Dalam praktiknya, Anda ingin menggunakan beberapa jenis enkripsi sebagai tambahan untuk mendapatkan jaminan yang lebih serius bahwa tidak ada yang memalsukan data Anda, karena Anda menggunakan kunci enkripsi lebih dari 32 bit. Dalam kebanyakan kasus, ini masih efektif dalam mencegah gangguan dengan koneksi TCP.

Sekarang mari kita lihat mengapa itu buruk jika orang dapat memalsukan koneksi TCP dari alamat yang sewenang-wenang?

Salah satu alasan mengapa ini buruk adalah bahwa hal itu dapat mempengaruhi otorisasi berdasarkan pada alamat IP ketika server memeriksa dari mana alamat permintaan itu berasal. Jika server memutuskan apakah akan mengizinkan atau menolak koneksi berdasarkan alamat IP, ini berpotensi menjadi masalah bagi penyerang yang memalsukan koneksi dari alamat sumber yang sewenang-wenang.

Jadi, salah satu contoh di mana ini merupakan masalah, hari ini masalah ini pada dasarnya diselesaikan, adalah penggunaan keluarga r perintah, seperti rlogin. Dulu Anda bisa menjalankan sesuatu seperti rlogin untuk komputer di, katakanlah, athena.dialup.mit.edu. Dan jika koneksi Anda berasal dari host MIT, maka perintah rlogin ini akan berhasil jika Anda berkata: "Ya, saya adalah pengguna Alice di komputer ini, izinkan saya masuk sebagai pengguna Alice ke komputer lain." Dan operasi ini akan diizinkan, karena semua komputer di jaringan mit.edu dapat dipercaya untuk membuat pernyataan seperti itu.

Saya harus mengatakan bahwa dial-up tidak pernah memiliki masalah ini. Senyawa ini menggunakan Cerberus sejak awal. Tetapi sistem lain, tentu saja, memiliki masalah seperti itu. Dan ini adalah contoh penggunaan alamat IP dalam mekanisme otentikasi koneksi ketika sistem memeriksa untuk melihat apakah klien yang memanggil server dapat dipercaya. Jadi apa yang dulunya masalah tidak lagi menjadi masalah. Tapi mengandalkan IP sepertinya masih rencana yang buruk.



Sekarang rlogin tidak lagi digunakan, baru-baru ini telah diganti dengan SSH shell yang aman, yang merupakan protokol lapisan jaringan yang sangat baik. Di sisi lain, ada banyak contoh protokol yang bergantung pada otorisasi berbasis alamat IP. Salah satunya adalah SMTP. Saat Anda mengirim email, Anda menggunakan SMTP untuk berbicara dengan beberapa server email untuk mengirim pesan. Untuk mencegah spam, banyak server SMTP hanya menerima pesan masuk dari alamat IP sumber tertentu. Misalnya, server surat Comcast hanya menerima email dari alamat IP Comcast. Hal yang sama berlaku untuk server email MIT - mereka hanya akan menerima email dari alamat IP MIT. Tetapi kami memiliki setidaknya satu server yang tidak berfungsi sebagaimana mestinya, menggunakan otentikasi IP.

Semuanya di sini tidak terlalu buruk. Dalam skenario terburuk, Anda akan mengirim beberapa spam melalui server surat. Jadi ini mungkin mengapa mereka masih menggunakan rlogin, sementara hal-hal yang memungkinkan Anda untuk masuk ke akun sewenang-wenang telah berhenti menggunakan otentikasi berbasis IP.

Jadi mengapa mekanisme otentikasi seperti itu merupakan rencana yang buruk? Sebagai asumsi, anggaplah beberapa server menggunakan rlogin. Apa yang akan Anda lakukan untuk menyerang? Apa yang buruk bisa terjadi?

Siswa: seorang penyerang dapat dengan mudah masuk ke komputer Anda, memalsukan pengguna yang akan memasuki jaringan dengan nama pengguna Anda, dan mendapatkan akses ke jaringan.

Profesor: ya, pada dasarnya penyerang mengambil alih komputer. Ini mensintesis data yang tampak seperti seperangkat perintah rlogin yang valid yang mengatakan, "Masuk sebagai pengguna ini dan jalankan perintah ini di shell Unix saya."

Anda mensintesis data data ini (SNc +1), me-mount seluruh serangan dan mengirim data ini seolah-olah pengguna yang sah berinteraksi dengan klien rlogin, dan kemudian Anda dapat melanjutkan.



Nah, itulah salah satu alasan mengapa Anda tidak ingin nomor urutan TCP Anda dapat ditebak. Masalah lainnya adalah serangan reset reset ini serangan. Dengan cara yang sama seperti kita bisa mengirim paket SYN, jika kita tahu nomor seri seseorang, kita dapat mengirim paket reset dengan cara yang sama.

Kami menyebutkan secara singkat klien hukum yang mengirim paket reset koneksi palsu yang telah dibuat oleh penyerang. Seorang penyerang bisa juga mencoba mengirim paket buangan untuk koneksi yang ada jika dia entah bagaimana tahu bahwa nomor urut Anda ada dalam koneksi itu. Faktanya, tidak jelas seberapa besar masalah ini.

Pada tingkat tertentu, Anda harus mengasumsikan bahwa semua koneksi TCP Anda dapat diputus dalam hal apa pun dan kapan saja, artinya, itu tidak terlihat seperti jaringan Anda dapat diandalkan. Karena itu, mungkin Anda harus mengharapkan putuskan sambungan.

Dalam kasus ketika router "berbicara" satu sama lain, asumsi ini sangat penting. Jika Anda memiliki banyak router yang berkomunikasi satu sama lain menggunakan beberapa protokol routing, maka ada beberapa koneksi fisik di antara mereka. Tetapi di atas semua koneksi fisik ini, mereka berkomunikasi melalui protokol jaringan yang berfungsi melalui TCP. Bahkan, dalam setiap koneksi fisik yang digunakan router untuk bertukar informasi routing, sesi TCP dimulai. Protokol BGP digunakan di sini, yang akan kita bicarakan nanti.

Protokol BGP ini menggunakan fakta bahwa jika koneksi TCP hidup, maka koneksi fisik juga hidup. Jadi, jika koneksi TCP terputus, router percaya bahwa koneksi terputus dan mulai menghitung ulang semua tabel routingnya.



Oleh karena itu, jika musuh ingin mengatur semacam DoS denial of service attack, ia dapat mencoba menebak nomor seri router ini dan membatalkan sesi ini. Jika sesi TCP antara dua router dimatikan, kedua router menganggap koneksi ini sudah mati dan mereka harus menghitung ulang semua tabel routing, yang akan menyebabkan rute berubah. Setelah itu, penyerang dapat mengatur ulang koneksi lain, dan seterusnya.

Jadi, ini adalah serangan yang agak mengkhawatirkan, dan bukan karena itu melanggar rahasia orang lain dan sebagainya, setidaknya tidak secara langsung, tetapi karena itu benar-benar menyebabkan banyak masalah akses bagi pengguna sistem lainnya.

Siswa: jika Anda seorang penyerang dan ingin mengatur serangan yang ditargetkan terhadap pengguna tertentu, dapatkah Anda terus mengirim permintaan untuk terhubung ke server atas nama alamat IP-nya dan memaksanya untuk mengatur ulang koneksi ke server?

Profesor: misalkan saya menggunakan Gmail dan Anda ingin mencegah saya menerima informasi apa pun dari Gmail, jadi kirimkan saja paket ke mesin saya, berpura-pura berasal dari server Gmail. Dalam hal ini, Anda harus menebak nomor port sumber dan tujuan yang benar.

Nomor port tujuan mungkin 443 karena saya menggunakan HTTPS. Tetapi nomor port sumber akan berupa beberapa hal 16-bit acak. Selain itu, nomor seri akan bervariasi. Karena itu, jika Anda tidak menebak nomor urut yang ada di jendela TCP saya dan yang puluhan kilobyte, Anda tidak akan berhasil.

Jadi, Anda harus menebak banyak hal. Tidak ada akses Oracle di sini. Anda tidak bisa hanya meminta server untuk nomor seri orang ini. Ini adalah alasan mengapa ini tidak akan berhasil.

Jadi, banyak dari masalah ini telah diperbaiki, termasuk hal berbasis RST ini, terutama untuk router BGP. Sebenarnya ada dua perbaikan lucu. Satu hal benar-benar menunjukkan bagaimana Anda dapat mengeksploitasi hal-hal yang ada atau menggunakannya untuk memperbaiki masalah tertentu. Ini menggunakan properti yang hanya berkomunikasi dengan router ini satu sama lain, dan tidak dengan orang lain di jaringan. Akibatnya, jika paket tidak datang dari router yang terletak di ujung koneksi, maka paket ini dibuang.

Implementasi yang sukses dari pengembang protokol ini adalah bidang yang luar biasa dalam paket yang disebut "seumur hidup", atau TTL. Ini adalah bidang 8-bit yang dikurangi oleh setiap router untuk memastikan bahwa paket tidak berakhir dalam loop tak terbatas. Nilai TTL maksimum adalah 255 dan semakin menurun.

Jadi apa yang saya lakukan protokol pintar ini? Mereka membuang paket apa pun dengan nilai TTL yang tidak sama dengan 255. Karena jika paket tersebut memiliki nilai 255, maka itu hanya bisa datang dari router di sisi lain dari koneksi ini. Dan jika musuh mencoba untuk menyuntikkan paket lain ke dalam koneksi BGP yang ada, itu akan memiliki nilai TTL kurang dari 255, karena nilai ini akan dikurangi oleh router lain yang terletak di sepanjang jalur routing, termasuk router ini. Oleh karena itu, paket ini hanya akan ditolak oleh penerima.

Jadi ini adalah salah satu contoh kombinasi cerdas dari teknik yang kompatibel mundur yang memecahkan masalah yang sangat spesifik ini.



Siswa: Bukankah router kanan bawah mengirim sesuatu dengan TTL 255?

Profesor: Ini adalah router fisik. Dan dia tahu bahwa ini adalah koneksi yang terpisah, jadi dia melihat TTL dan dari mana paket itu berasal. Jadi jika paket tersebut berasal dari router kiri atas, itu tidak akan menerimanya untuk koneksi TCP antara itu dan router kanan atas.

Sebagian besar, router ini mempercayai tetangga terdekat mereka, dan proses ini dapat dikontrol menggunakan mekanisme multi-jalur routing Pan Otomatis.

Perbaikan lain untuk BGP adalah untuk mengimplementasikan beberapa bentuk header otentikasi, termasuk header otentikasi MD5. Namun pada kenyataannya, pengembang fokus pada aplikasi khusus ini, yang mana serangan reset sangat penting.

Masalah ini masih ada sampai sekarang. Jika ada koneksi jangka panjang dan saya ingin menghentikannya, saya hanya perlu mengirim sejumlah besar paket RST, sekitar ratusan ribu, tetapi mungkin tidak 4 miliar. Karena server sebenarnya agak rentan terhadap nomor urut apa yang mereka terima untuk reset.

Itu bisa berupa paket apa saja di jendela tertentu. Dalam hal ini, penyerang dapat memutuskan koneksi ini tanpa banyak usaha. Ini masih merupakan masalah yang tidak ada solusi yang benar-benar baik.

Dan hal buruk terakhir yang dapat terjadi karena prediktabilitas nomor urut adalah menyuntikkan data ke koneksi yang ada. Misalkan kita memiliki protokol hipotetis yang mirip dengan rlogin, yang sebenarnya tidak melakukan otentikasi berbasis IP, jadi Anda harus memasukkan kata sandi Anda untuk login.

Masalahnya adalah segera setelah Anda memasukkan kata sandi Anda, mungkin koneksi TCP Anda cukup dibuat dan dapat menerima data sewenang-wenang. Jadi penyerang hanya perlu menunggu sampai salah satu dari kalian masuk ke komputer dengan memasukkan kata sandi Anda.

Penyerang tidak tahu apa kata sandi itu, tetapi segera setelah Anda membuat koneksi TCP, ia akan segera mencoba menebak nomor seri Anda dan memasukkan beberapa data ke dalam koneksi yang ada. Jadi jika saya dapat menebak dengan benar nomor seri Anda, maka ini akan memungkinkan saya untuk berpura-pura bahwa itu bukan saya, tetapi Anda memasukkan beberapa perintah setelah Anda mengautentikasi dengan kata sandi dengan benar.



Semua ini menunjukkan mengapa Anda benar-benar tidak ingin mengandalkan nomor urut 32-bit ini dalam arti keamanan. Tapi mari kita lihat apa sebenarnya tumpukan TCP modern untuk mengurangi masalah ini. Salah satu pendekatan untuk masalah yang akan kita bahas dalam 2 kuliah berikutnya adalah menerapkan beberapa tingkat keamanan di tingkat aplikasi. Pada level ini, kami akan menggunakan kriptografi untuk mengotentikasi, mengenkripsi, menandatangani, dan memverifikasi pesan tanpa banyak keterlibatan TCP.

Beberapa aplikasi yang ada juga membantu menyelesaikan masalah keamanan, atau setidaknya membuatnya lebih sulit bagi penyerang untuk mengeksploitasi masalah ini. Orang-orang mempraktikkannya hari ini, misalnya, di Linux dan Windows, mempertahankan nomor urut awal yang berbeda untuk setiap pasangan sumber / tujuan.

Dengan demikian, sebagian besar implementasi TCP SYN masih menghitung nomor urut ISN awal ini dengan cara yang sama seperti yang kita lakukan sebelumnya. Jadi ini adalah gaya lama ISN, katakanlah begitu. Dan untuk benar-benar menghasilkan nomor seri untuk koneksi tertentu, kami menambahkan ISN gaya lama ini dengan offset 32-bit acak. Artinya, kami menambahkan fungsi ke dalamnya - sesuatu seperti fungsi hash atau SHA-1, atau sesuatu yang lebih baik.



Fitur ini termasuk alamat IP sumber, nomor port sumber, alamat IP tujuan, nomor port tujuan dan beberapa kunci rahasia yang hanya diketahui oleh server. Dengan demikian, kami menciptakan peluang yang baik untuk koneksi tertentu untuk menentukan alamat IP dan port untuk pasangan sumber / tujuan, sambil mempertahankan semua properti baik dari algoritma penetapan nomor urut gaya lama ini.

Tetapi jika Anda memiliki koneksi dari rangkaian sumber / tujuan yang berbeda, maka tidak ada yang memungkinkan Anda untuk mengetahui nilai persis nomor seri dari rangkaian koneksi lain. Bahkan, Anda harus menebak kunci ini untuk menghitung nilai ini.

Saya berharap bahwa kernel OS server menyimpan kunci ini di suatu tempat di memorinya dan tidak memberikannya kepada siapa pun. Ini adalah bagaimana kebanyakan tumpukan TCP saat ini memecahkan masalah khusus ini dalam bidang nomor urut 32-bit yang umum. Ini tidak terlalu bagus, tetapi berhasil.

Siswa: dapatkah Anda mengulanginya lagi? Tentang keunikan kunci ...

Profesor: ketika mesin saya dinyalakan, atau ketika mesin apa pun dinyalakan, itu menghasilkan kunci acak. Setiap kali Anda memuat ulang, itu menghasilkan kunci baru. Ini berarti bahwa setiap kali nomor seri pasangan sumber / tujuan tertentu berubah dengan frekuensi offset yang sama. Dengan demikian, untuk pasangan sumber / tujuan tertentu, parameter fungsi diperbaiki. Jadi Anda mengikuti urutan ketika angka berevolusi sesuai dengan nomor urutan awal Anda untuk senyawa baru, berubah sesuai dengan algoritma tertentu. Dengan demikian, perlindungan terhadap injeksi paket lama dari koneksi sebelumnya ke koneksi baru disediakan, serta perlindungan terhadap pengalihan paket.

Satu-satunya hal yang kita butuhkan nomor seri sampel lama ini adalah pilihan algoritma untuk mencegah masalah dengan paket duplikat ini. , A: A -> S: SYN (…), ACK (SNs).



, 32- , F. , , .

: ?

: , . F, , F , , , .

: , …

: , F - -, . -, , . , , , , . , F .

, TCP, . , , - .

, . , TCP , DNS, . , DNS UDP – . UDP — , , . UDP . , , , . , , . DNS-. DNS?



, DNS- C: C53 -> S53 mit.edu, 53.

S: S53 -> C53 IP-, – .

, , , , . , mit.edu, .

, DNS- . IP-, , . IP- mit.edu IP-. , , , , . , .



, , . IP-. , , DNS- . , , IP- mit.edu.

: , , ?

: , . , , . DNS-, , . 2 . — , 16 . , 16 . ID, 16 , .

, , 32 . , , , , .



, , .

, DNS DNS . , , DNS . , DNS SEC, . , , , DNS- . , , .

origin. DNS , IP-, : „, “. , , , , , , . , , ?

, – DNS- , . , , . -, DNS-, . , DNS SEC, , , DNS- . DNS- , , , – , .

DNS SEC , NSEC. , . , NSEC , foo.mit.edu, goo.mit.edu, , .



, , , , , , „, “.

. , foo.mit.edu -> goo.mit.edu — >…. : » , , gooa.mit.edu". , , .

, DNS . NSEC3, – - , - .

52:00

Kursus MIT "Keamanan Sistem Komputer". 12: « », 3


.

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?