Kursus MIT "Keamanan Sistem Komputer". Kuliah 12: Keamanan Jaringan, Bagian 1

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

Hari ini kita akan berbicara tentang keamanan jaringan, khususnya, kita akan membahas artikel oleh Stephen Bellovin berjudul "Pandangan Kembali ke" Masalah Keamanan di TCP / IP Protocol Suite "". Orang ini dulunya bekerja untuk AT&T, dan sekarang bekerja di Kolombia. Yang menarik dalam karya ini adalah bahwa ia relatif tua - lebih dari 10 tahun, dan pada kenyataannya, ini adalah komentar pada sebuah artikel yang keluar satu dekade sebelumnya pada tahun 1989.

Banyak dari Anda bertanya mengapa kami mempelajari ini jika banyak masalah yang dijelaskan di sana telah diselesaikan dalam versi protokol TCP saat ini.



Memang benar bahwa beberapa masalah yang dijelaskan oleh Stephen sejak itu telah diselesaikan, dan beberapa dari mereka masih tetap menjadi masalah. Dengan mengingat hal ini, kita akan menyortirnya dan melihat apa yang terjadi. Anda mungkin bertanya-tanya mengapa orang tidak menyelesaikan semua masalah ini ketika merancang TCP? Apa yang mereka pikirkan?

Dan ini sebenarnya tidak jelas. Apa yang kamu pikirkan Mengapa protokol TCP tidak memiliki keamanan yang diperlukan, mengingat semua pertimbangan ini? Ada saran?

Mahasiswa: Pada waktu itu, Internet adalah tempat yang jauh lebih mudah tertipu.

Profesor: ya, itu benar-benar kutipan dari artikel orang ini. Ya, pada waktu itu secara umum ... seperangkat protokol Internet dikembangkan, saya kira, sekitar 40 tahun yang lalu. Persyaratannya sangat berbeda. Itu hanya perlu untuk menghubungkan sekelompok situs yang relatif mudah ditipu yang saling kenal dengan nama ke jaringan umum.

Saya pikir ini sering terjadi dalam sistem apa pun yang menjadi sukses - perlu perubahan. Dulu merupakan protokol untuk sejumlah kecil situs, sekarang protokol ini mencakup seluruh dunia. Dan Anda tidak lagi tahu dengan nama semua orang yang terhubung ke Internet. Anda tidak dapat memanggil mereka jika mereka melakukan sesuatu yang buruk, dan sebagainya.

Oleh karena itu, saya pikir cerita ini sama untuk banyak protokol yang kami pertimbangkan. Dan banyak dari kalian yang mengajukan pertanyaan seperti, “apa yang dipikirkan orang-orang ini? Ini sangat cacat! " Namun pada kenyataannya, mereka merancang sistem yang sama sekali berbeda, mereka hanya menyesuaikannya untuk kebutuhan modern.

Hal yang sama, dan Internet, seperti yang kita lihat selama beberapa minggu terakhir, dirancang untuk tujuan yang sama sekali berbeda. Tapi itu berkembang, dan kami memiliki kekhawatiran baru tentang bagaimana menyesuaikan protokol ini dengan persyaratan modern.

Ada hal lain yang terjadi sedikit tiba-tiba, yaitu orang harus melebih-lebihkan tingkat keparahan masalah keamanan. Dulu Anda benar-benar tidak memahami semua hal yang harus Anda khawatirkan, karena Anda tidak tahu apa yang dapat dilakukan penyerang dengan sistem Anda.



Saya pikir sebagian karena alasan ini akan menarik untuk melihat apa yang terjadi pada keamanan TCP, apa yang salah, bagaimana kita memperbaikinya, dan sebagainya. Akibatnya, kita harus mencari tahu jenis masalah apa yang harus dihindari ketika mengembangkan protokol kita sendiri, serta apa yang merupakan pemikiran yang tepat tentang serangan semacam ini. Bagaimana Anda tahu apa yang mampu dilakukan penyerang dalam protokol Anda sendiri ketika Anda baru saja mengembangkannya untuk menghindari jebakan seperti itu?

Oke, mari kita kesampingkan mukadimah dan bicarakan artikel ini.

Jadi bagaimana seharusnya kita berpikir tentang keamanan jaringan? Saya pikir kita bisa mulai dengan prinsip pertama dan mencoba mencari tahu apa model ancaman kita. Jadi apa yang bisa dilakukan penyerang di jaringan kita?

Dia mungkin memiliki kemampuan untuk mencegat paket, dan mungkin dia bisa memodifikasinya. Jadi, jika Anda mengirim paket melalui jaringan, adalah bijaksana untuk berasumsi bahwa beberapa orang jahat akan melihat paket Anda dan dapat mengubahnya sebelum mencapai tujuannya. Mungkin juga bisa menjatuhkannya dan menggunakan kemampuan untuk memasukkan paket kustom dengan konten sewenang-wenang yang tidak pernah Anda kirim.



Tetapi yang lebih berbahaya adalah kemungkinan orang jahat mengganggu protokol Anda yang dijelaskan dalam artikel. Penyerang memiliki komputer sendiri, yang dia kontrol sepenuhnya. Bahkan jika semua komputer yang Anda percayai berperilaku baik, orang jahat yang memiliki komputer sendiri dapat mengganggu protokol atau sistem Anda.

Jadi jika Anda memiliki protokol perutean yang melibatkan banyak orang berbicara satu sama lain, dan beberapa penskalaan mungkin tidak praktis untuk menjaga orang jahat di luar. Jika protokol perutean dengan 10 peserta sedang berjalan, maka mungkin Anda bisa memanggil mereka semua dan kemudian berkata, "Ya, teman, saya tahu Anda semua."

Tetapi pada skala Internet saat ini tidak mungkin untuk mengetahui secara langsung siapa anggota jaringan lain yang menggunakan protokol ini. Jadi, mungkin, beberapa orang jahat akan berpartisipasi dalam protokol atau sistem terdistribusi Anda. Oleh karena itu, penting untuk merancang sistem terdistribusi yang, bagaimanapun, dapat melakukan sesuatu yang masuk akal dengan ini.

Oke, jadi apa implikasi dari semua ini? Saya pikir kita akan melihat daftar. Paket intersepsi umumnya mudah dipahami, Anda tidak dapat mengirim data penting apa pun melalui jaringan jika Anda mengharapkan penjahat mencegatnya, atau setidaknya tidak mengirimnya dalam bentuk teks. Mungkin Anda harus mengenkripsi data Anda.



Tampaknya relatif mudah dipahami, meskipun Anda masih perlu mengingat ini saat mengembangkan protokol. Pengenalan atau injeksi paket mengarah ke berbagai masalah menarik, yang dibahas dalam artikel ini. Secara khusus, penyerang dapat menyuntikkan paket yang dapat menyamar sebagai paket dari pengirim lain. Karena jalur transmisi data didasarkan pada penggunaan IP, paket itu sendiri memiliki header yang menunjukkan IP dari sumber paket dan IP tujuan. Namun, tidak ada yang memeriksa apakah sumbernya benar. Ada beberapa pemfilteran akhir-akhir ini, tetapi tidak sempurna dan sulit untuk diandalkan.

Jadi, dalam perkiraan pertama, penyerang dapat memasukkan alamat IP apa pun di dalam sebagai sumber dan mengirimkannya ke tujuan yang benar. Sangat menarik untuk mengetahui apa yang bisa dilakukan penyerang dengan kemampuan mengirim paket yang sewenang-wenang.

Pada minggu-minggu sebelumnya, kami melihat masalah buffer overflow dalam hal keamanan web. Kami memeriksa bagaimana penyerang dapat menggunakan kesalahan implementasi seperti buffer overflows. Menariknya, penulis artikel ini tidak benar-benar tertarik pada kesalahan implementasi, ia lebih tertarik pada kesalahan protokol.

Jadi apa yang spesial dari ini? Mengapa dia tidak memperhatikan kesalahan implementasi, meskipun kami menghabiskan beberapa minggu untuk memeriksanya? Mengapa itu penting?

Siswa: karena kita harus mengesampingkan kesalahan ini ketika menulis protokol.

Profesor: ya, ini benar-benar kegagalan besar karena kesalahan dalam desain protokol karena sulit untuk diubah. Jadi jika Anda memiliki kesalahan implementasi dan Anda memiliki memcpy atau print-out yang tidak memeriksa rentang memori, Anda tidak dapat melihat kesalahan ini. Tetapi jika Anda memiliki rentang periksa dan masih berfungsi, maka buffer overflows dapat dihindari, jadi ini bagus.

Tetapi jika Anda memiliki beberapa jenis kesalahan dalam spesifikasi protokol, dalam bagaimana protokol seharusnya bekerja, maka memperbaiki kesalahan semacam itu akan memerlukan memperbaiki seluruh protokol, yang berarti dampak potensial pada semua sistem yang berbicara protokol ini. Jadi jika kita menemukan beberapa masalah dalam protokol TCP, berpotensi akan sangat merusak. Karena setiap mesin yang menggunakan TCP harus membuat perubahan, karena berpotensi sangat sulit untuk membuat protokol yang dimodifikasi kompatibel dengan mesin yang lama.

Kesalahan protokol TCP yang sangat dikhawatirkan oleh Stephen adalah mendasar, jadi dia memutuskan untuk membicarakannya. Dalam contoh pertama, dia melihat bagaimana nomor-nomor TCP SN bekerja.

Mahasiswa: ini adalah topik kecil, tapi saya hanya ingin tahu. Misalkan Anda menemukan kesalahan dalam TCP. Bagaimana Anda mengubahnya? Bagaimana Anda memberi tahu semua komputer di dunia bahwa ini perlu diubah?

Profesor : ya, saya pikir ini adalah masalah besar. Apa yang harus dilakukan jika Anda menemukan kesalahan dalam TCP? Ya, tidak jelas apa yang harus dilakukan. Saya pikir penulis di sini sedang berjuang dengan ini. Jika Anda bisa mendesain ulang TCP, maka banyak dari kesalahan ini relatif mudah diperbaiki jika Anda tahu sebelumnya apa yang harus dicari.

Tetapi karena TCP cukup sulit untuk diperbaiki atau diubah, yang berikut ini pada akhirnya terjadi: para pengembang mencoba menemukan pengaturan kompatibel yang memungkinkan Anda untuk menggunakan implementasi lama bersama dengan implementasi baru, atau menambahkan beberapa bidang tambahan yang membuat koneksi agak lebih aman.



Tapi ini masalah besar. Jika ini adalah semacam masalah keamanan yang berakar dalam pada TCP, maka itu akan menjadi masalah besar bagi semua orang, karena sangat sulit bahkan untuk hanya beralih ke versi TCP, misalkan n plus 1.

IPv6 dapat dilihat sebagai contoh bahwa ini tidak terjadi, dan kita tahu bahwa masalah ini akan muncul selama 15 tahun atau 20 tahun lagi. IPv6 telah ada selama lebih dari 10 tahun, tetapi sulit meyakinkan orang untuk menjauh dari IPv4. IPv4 sudah cukup bagi mereka, tampaknya berfungsi, dan mereka berpikir bahwa beralih ke protokol Internet baru akan terlalu mahal. Mereka berkata: "tidak ada yang berbicara IPv6 lagi, jadi mengapa saya harus mulai berbicara tentang protokol aneh ini sehingga tidak ada yang berbicara dengan saya?" Bagaimanapun, ini adalah semacam gerakan maju, tapi saya pikir itu akan memakan banyak waktu. Akan ada beberapa motivasi untuk migrasi, dan kompatibilitas ke belakang dalam hal ini sangat membantu.

IPv6 memiliki banyak opsi kompatibilitas mundur, misalnya, Anda dapat berbicara dengan host IPv4 menggunakan IPv6. Karenanya, pengembang mencoba merancang semua dukungan ini, tetapi masih sulit untuk meyakinkan orang untuk meningkatkan.

Jadi, mempertimbangkan nomor urut TCP, kita akan benar-benar mempertimbangkan dua masalah yang terkait dengan cara kerja jabat tangan TCP. Jadi mari kita meluangkan waktu untuk melihat bagaimana koneksi TCP pada awalnya dibuat.

Tiga paket dikirim untuk membuat koneksi TCP baru. Klien kami membuat paket untuk terhubung ke server, yang mengatakan bahwa ini adalah alamat IP klien saya, saya kirimkan ke server. Pada saat yang sama, ada struktur header paket yang terdiri dari area yang berbeda, tetapi kami akan tertarik pada area nomor seri. Di sini kita akan memiliki bendera SYN yang mengatakan: "Saya ingin menyinkronkan keadaan dan membuat koneksi baru", dan itu termasuk nomor seri klien SNc.



Kemudian, ketika server menerima paket ini, ia berkata: "klien ingin terhubung dengan saya, jadi saya akan mengirim paket kembali ke alamat ini, tidak peduli siapa yang mengatakan bahwa ia mencoba menghubungi saya." Dengan demikian, server akan mengirim paket ke klien, di mana ia menyertakan nomor urut sinkronisasi server SNs sendiri dan nomor konfirmasi klien ACK (SNc). Akhirnya, dalam paket ketiga, klien merespons ke server, mengonfirmasi sinkronisasi dan mengirimkan nomor konfirmasi server ACK server (SN) ke server. Sekarang klien dapat mulai mengirim data.

Dengan demikian, untuk mengirim data, pada awal koneksi, klien harus memasukkan beberapa data dalam paket dan melampirkan nomor seri klien SNc untuk menunjukkan bahwa ini sebenarnya adalah data klien yang sah. Dia menunjukkan, misalnya, bahwa ini bukan beberapa data dari pesan kemudian yang baru tiba sekarang, karena server melewatkan beberapa bagian awal data.



Jadi, sebagai suatu peraturan, semua nomor seri ini dirancang untuk menyediakan pengiriman paket. Jika klien mentransmisikan dua paket, satu yang memiliki nomor urut mulai adalah potongan data pertama, nomor urut berikutnya adalah potongan data berikutnya. Ini juga berguna untuk menyediakan beberapa persyaratan keamanan.

Sebelum itu, saya memberi contoh bahwa persyaratan ini berubah. Karena itu, awalnya tidak ada yang mengira TCP harus menyediakan fitur keamanan apa pun. Tetapi kemudian TCP mulai menggunakan aplikasi, dan mereka tampaknya mengandalkan koneksi TCP ini, percaya bahwa mereka tidak dapat dipecah oleh penyerang mana pun atau bahwa penyerang tidak dapat menyuntikkan data berbahaya ke dalam koneksi TCP yang ada. Seolah tiba-tiba mekanisme ini, yang semula dimaksudkan hanya untuk paket pemesanan, mulai menjamin kemiripan keamanan untuk koneksi ini.

Oleh karena itu, dalam hal ini, saya berasumsi bahwa masalahnya terkait dengan apa yang dapat disarankan server tentang koneksi TCP ini. Biasanya, server mengasumsikan - secara implisit, seperti yang dapat Anda bayangkan - bahwa koneksi ini dibuat dengan klien yang diinginkan pada alamat IP C ini, dan wajar baginya untuk berpikir demikian. Tetapi adakah alasan untuk asumsi seperti itu? Jika server menerima pesan dengan beberapa data tentang koneksi client-server ini, dan memiliki nomor urut C, mengapa server menyimpulkan bahwa klien sebenarnya mengirim data ini?

Siswa: karena nomor seri sulit ditebak.
Profesor: benar, jadi ini adalah semacam hal tersirat, menyiratkan bahwa harus ada nomor urut SNc yang benar. Dan agar koneksi ini dapat dibangun, klien harus memiliki nomor seri server SNs yang dikonfirmasi, dan nomor seri server dikirim oleh server hanya ke alamat IP klien.

Siswa: berapa bit yang tersedia untuk nomor urut?

Profesor: Nomor urut TCP panjangnya 32 bit, dan meskipun ini bukan angka acak, tidak mudah ditebak, akan membutuhkan banyak bandwidth.

Siswa: apakah nomor seri lebih tinggi dari nomor seri awal?

Profesor: ya, pada prinsipnya, semua ini meningkat. Karena itu, setiap kali Anda mengirim SYN, itu dianggap 1 byte lebih dari nomor urut Anda. Artinya, jika di baris pertama kita memiliki argumen (SNc), maka di baris keempat sudah ada (SNc + 1), dan kemudian penomoran berlanjut dari sini. Jadi, jika Anda mentransfer 5 byte, maka yang berikut ini adalah nilainya (SNc) +6. Ini hanya menghitung byte yang Anda kirim, dengan masing-masing SYN menghitung 1 byte. Spesifikasi TCP merekomendasikan untuk memilih nomor seri ini sehingga kenaikannya terjadi pada kecepatan yang kurang lebih tetap. Dokumen kerja awal dari protokol RFC menyarankan agar Anda meningkatkan hal-hal ini sekitar 250.000 unit ditambah 250.000 per detik.



Alasan ini tidak sepenuhnya acak adalah karena nomor urut ini sebenarnya digunakan untuk mencegah paket gagal untuk campur tangan atau untuk mencampur paket dari koneksi sebelumnya dengan koneksi baru. Setiap kali Anda membuat koneksi baru, Anda memilih nomor seri yang benar-benar acak. Pada saat yang sama, ada kemungkinan bahwa jika Anda menginstal serangkaian koneksi berulang-ulang, maka paket dari koneksi sebelumnya akan memiliki nomor urut yang sangat mirip dengan nomor urut koneksi baru Anda dan karenanya akan diterima oleh server sebagai bagian valid dari data untuk koneksi baru.

Jadi inilah yang sangat dikhawatirkan oleh para pengembang TCP - paket-paket tidak terurut ini atau paket-paket tertunda. Akibatnya, mereka benar-benar ingin nomor urut ini menjadi urutan waktu yang cukup monoton bahkan di antara senyawa.

Jika saya membuka satu koneksi, ia dapat memiliki sumber dan tujuan yang sama, nomor port, alamat IP, dan sebagainya. Tetapi karena saya membuat koneksi ini sekarang, dan bukan sebelumnya, paket-paket dari pesan yang dikirim sebelumnya, saya harap, tidak akan bertepatan dengan nomor urut yang saya miliki untuk koneksi baru saya. Jadi ini adalah mekanisme untuk mencegah kebingungan antara koneksi berulang.

Siswa: jika Anda tidak tahu persis apa langkah dari urutan paket akan, bagaimana Anda tahu bahwa paket yang Anda terima adalah paket berikutnya, dan bukan bagian dari yang sebelumnya yang Anda ...

Profesor: Sebagai aturan, Anda ingat paket terakhir yang diterima. Dan nomor urut berikutnya persis paket berikutnya dalam urutan. Jadi, misalnya, server tahu bahwa saya melihat persis bagian dari data tanggal (SNc +1), maka yang berikutnya adalah paket SYN (SNc +1), karena paket sebelumnya di awal koneksi adalah SYN (SNc).

Siswa: jadi, Anda mengatakan bahwa ketika Anda mengatur nomor seri, bahkan setelah itu Anda ...

Profesor: tentu saja, nomor seri ini, awalnya, ketika Anda menginstalnya, dipilih sesuai dengan beberapa paket. Kami akan membicarakan rencana ini. Anda mungkin berpikir bahwa mereka acak, tetapi seiring waktu mereka harus mewakili beberapa aliran perubahan berurutan dalam nomor urut awal untuk koneksi.

Tetapi dalam satu koneksi, semuanya berakhir segera setelah itu dibuat - nomor seri tetap. Dan mereka hanya menandai koneksi ini ketika data dikirimkan.

Ada rencana yang menyarankan untuk mengelola nomor seri ini. , . , , , .

, - , 250000. , , , 64k 128k, . , – , SYN .

, 64 . , .

, . , , , , IP-.
, , , , , . , , .

, ? , , , — SNc. , , - , , , .

, . ACK (SNs).

- .



SNs , , , IP- C.

, . , : , , , data (SNc +1).



(SNs). ?

: , ?

: . , , , , . , , , , .

: , , ?

: . , ?

, . , , 32 , , .

, .

: , , , . …

: , TCP .

: , .

: , .

: , , .

: , , , . , , 1000 , 2 32 .

, - , , . . , .



: - , ?

: , . , , IP-, ?

: ?

: — ? , . ?

: , , , , - .

: , , , , , . IP-, TCP , , , .

TCP , - , , , C RST (SN…), , .



- , , C , .

, C , . , S , : «, , , ».

, , , , , C .

, «» C , . , «» C , . , TCP.

: , . , SYN , .

: , , . , , , , NAT, . , NAT RST , . , , , , , Comcast , RST .

: ?

: , , TCP. , . , , , . /, .

, data (SNc +1). , IP- , : « », , S.



Dan jika SYN (SNs) ini untuk koneksi ini di baris terakhir dan (SNs) di baris ketiga terhubung, maka ini benar-benar masalah. Tapi Anda katakan - mari kita buat mereka tidak terhubung, karena ini adalah nomor dari alamat IP yang berbeda, jadi ini bukan masalah lagi. Anda tidak dapat menebak bahwa SNS ini akan didasarkan pada SNS untuk koneksi lain.

25:50 menit

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


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?