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

Siswa: apakah ada tanda tangan untuk domain tingkat atas yang tidak ada?

Profesor: Saya kira ada. Domain titik hanyalah domain lain, dan mengimplementasikan mekanisme yang sama. Jadi domain "dot" dan "dot.kom" saat ini menggunakan DNS SEC, dan ada semua catatan yang mengatakan, misalnya, bahwa .in adalah nama domain yang ada, dan nama "dot" juga ada, dan tidak ada lagi di antara mereka. Jadi di domain tingkat atas semua hal ini ada.



Siswa: selain bahaya serangan DoS, mengapa kita begitu peduli dengan pengulangan nama domain dalam mit.edu?

Profesor: Saya tidak tahu pasti. Pokoknya, AFS memiliki file teks yang mencantumkan semua nama domain MIT ini. Tetapi saya berpikir bahwa secara umum, beberapa perusahaan merasa sedikit canggung dalam hal ini, karena mereka sering memiliki nama internal yang ada dalam DNS dan yang tidak dapat diberikan kepada orang luar. Saya pikir pada kenyataannya, ini adalah area fuzzy yang belum pernah diformalkan dan yang tidak menjelaskan dengan pasti apa yang diberikan pengguna DNS. Biasanya orang berasumsi bahwa jika ada nama rahasia, maka dalam kasus DNS tidak akan diungkapkan.

Saya pikir ini adalah tempat lain di mana sistem ini tidak memiliki spesifikasi yang jelas dalam hal apa yang seharusnya atau tidak seharusnya disediakan.

Siswa: apakah mungkin untuk menetapkan masa berlaku tanda tangan dengan menyorotnya dengan cara tertentu?

Profesor: hal-hal ini memiliki tanggal kedaluwarsa, misalnya, Anda dapat menandatangani bahwa rangkaian nama ini berlaku selama seminggu, dan kemudian klien, jika mereka memiliki jam yang disinkronkan, dapat menolak pesan bertanda tangan lama.

Jadi, kita dapat mengasumsikan bahwa kita membahas serangan dengan menebak nomor urut TCP SYN. Masalah lain yang menarik tentang TCP adalah serangan DDoS, yang mengeksploitasi fakta bahwa server dalam keadaan tertentu. Jika Anda melihat jabat tangan ini, yang digambar di papan sebelumnya, Anda akan melihat bahwa ketika klien membuat koneksi ke server, server harus mengingat nomor seri klien SNc. Dengan demikian, server harus mendukung beberapa struktur data dalam blok terpisah, yang menunjukkan bahwa nomor urut ini digunakan untuk koneksi ini.



Ini adalah semacam tabel di mana nomor urutan SN disimpan dan bahwa koneksi klien-server memiliki nomor urutan SNc. Alasan server harus menyimpan tabel ini adalah karena server perlu mencari tahu apa yang harus diambil nomor urut SNc nanti, misalnya, SNc + 1. Selain itu, server juga perlu menyimpan SN, yang jauh lebih penting, karena mereka menunjukkan server bahwa koneksi dibuat dengan "orang yang tepat".

Masalahnya adalah bahwa tabel ini tidak memiliki batas nyata. Dengan begitu, Anda bisa mendapatkan paket dari beberapa mesin tanpa mengetahui siapa yang mengirimnya. Anda hanya mendapatkan paket yang terlihat seperti C-> S dengan alamat sumber yang mengklaim sebagai C. Untuk berpotensi menerima koneksi ini dari alamat IP ini, Anda harus membuat entri dalam tabel. Selain itu, catatan ini ada untuk waktu yang lama, karena, mungkin, seseorang membuat koneksi dengan Anda dari tempat yang sangat jauh dan pada saat yang sama banyak paket hilang. Dalam kasus terburuk, mungkin diperlukan, misalnya, satu menit hingga seseorang menyelesaikan jabat tangan TCP ini. Jadi, Anda harus mempertahankan status ini pada tumpukan TCP untuk waktu yang relatif lama, dan tidak ada cara untuk menebak apakah ini akan valid atau tidak.

Dengan demikian, serangan DoS yang paling umum terhadap sebagian besar tumpukan TCP yang dibuat orang adalah transmisi sederhana sejumlah besar paket. Jika saya seorang penyerang, saya hanya mengirim sejumlah besar paket SYN ke server tertentu dan menyebabkannya meluap tabel ini.

Masalahnya adalah, yang terbaik, seorang penyerang hanya menggunakan alamat IP sumber yang sama. Dalam hal ini, Anda bisa mengatakan bahwa setiap klien hanya diperbolehkan dua entri, atau sesuatu seperti itu. Dan kemudian penyerang dapat menggunakan maksimal 2 dua entri dalam tabel.

Masalahnya, tentu saja, penyerang dapat memalsukan alamat IP klien dan membuatnya terlihat acak. Maka akan sangat sulit bagi server untuk membedakan siapa yang mencoba membuat koneksi dengannya - penyerang atau klien yang server belum pernah dengar sebelumnya.

Jadi jika Anda melihat beberapa situs yang seharusnya menerima koneksi dari mana saja di dunia, ini akan menjadi masalah besar. Karena Anda menolak akses ke semua orang, atau Anda seharusnya dapat menyimpan status untuk sebagian besar upaya koneksi palsu.

Jadi ini adalah masalah untuk TCP dan sebagian besar protokol yang memungkinkan semacam inisiasi koneksi, di mana server harus menyimpan keadaan. Tetapi ada beberapa perbaikan yang diterapkan dalam TCP yang akan kita bicarakan dalam beberapa detik, dan mereka akan mencoba untuk mengatasi masalah ini, yang disebut SYN Flooding in TCP.



Secara umum, ini adalah masalah yang harus Anda waspadai dan coba hindari dalam protokol apa pun yang Anda kembangkan. Anda harus menentukan bahwa server tidak boleh menyimpan keadaan sampai server dapat mengotentikasi dan mengidentifikasi klien. Karena hanya setelah otentikasi klien dapat diambil keputusan apakah diizinkan untuk terhubung, misalnya, hanya sekali, dalam hal ini server tidak perlu menyimpan status untuk koneksi ini.

Masalahnya adalah bahwa Anda menjamin pelestarian negara bahkan sebelum Anda tahu siapa yang terhubung dengan Anda. Mari kita lihat bagaimana kita dapat melawan serangan banjir SYN Flooding, yang berarti server mengakumulasi terlalu banyak status.

Anda dapat mengubah TCP lagi, misalnya, memperbaikinya dengan mudah dengan kriptografi atau sesuatu yang lain, atau mengubah apa yang bertanggung jawab untuk menyimpan suatu keadaan. Tetapi kenyataannya adalah bahwa kita perlu menggunakan TCP apa adanya. Bisakah kita memecahkan masalah ini tanpa memodifikasi protokol TCP yang ada?

Ini, sekali lagi, adalah latihan dalam mencoba mencari tahu trik mana yang bisa kita lakukan, atau lebih tepatnya, asumsi apa yang bisa kita tinggalkan sendiri dan masih mematuhi format tajuk TCP yang ada saat bekerja dengannya.

Dan triknya adalah menemukan cara cerdas untuk membuat server stateless, sehingga tidak perlu menyimpan tabel ini dalam memori. Ini dapat dilakukan dengan memilih SN dengan hati-hati, yaitu, alih-alih rumus yang kami pertimbangkan sebelumnya dan di mana kami harus menambahkan fungsi ini, kami akan memilih nomor seri dengan cara yang sama sekali berbeda. Saya akan memberi Anda formula yang tepat, dan kemudian kita akan berbicara tentang mengapa itu benar-benar menarik dan properti bagus apa yang dimilikinya.

Jika server mendeteksi bahwa ia sedang mengalami serangan seperti ini, ia masuk ke mode di mana ia memilih SN menggunakan rumus dengan fungsi F yang sama seperti yang kita bahas sebelumnya.



Fungsi ini memiliki alamat IP sumber, alamat IP tujuan, hal-hal yang sama seperti port sumber sebelumnya, port tujuan, cap waktu dan kunci. Dan kita akan menggabungkan fungsi ini dengan cap waktu, lebih tepatnya "butiran kasar," berukuran beberapa menit. Ada pemisahan antara dua bagian header ini - fungsi dan cap waktu, yang tidak membutuhkan banyak bit. Saya lupa bagaimana tepatnya protokol ini bekerja pada komputer nyata, tetapi Anda dapat membayangkan bahwa timestamp mengambil 8 bit, dan sisa rumus nomor urut adalah 24 bit.

Jadi mengapa ini rencana yang bagus? Apa yang sedang terjadi di sini? Mengapa formula aneh ini dibutuhkan? Anda harus ingat apa yang kami coba dapatkan dari nomor seri. Dua hal terjadi di sini.

Yang pertama adalah perlindungan terhadap paket duplikat. Tetap ada di papan sirkuit dengan nomor seri gaya lama ini, yang kami tambahkan fungsi untuk mencegah duplikasi paket dari koneksi sebelumnya.



Ternyata orang tidak bisa menemukan cara yang lebih baik untuk melindungi diri dari serangan seperti SYN Flooding, kecuali menggunakan rencana aksi ini, yang berfungsi dengan baik dalam beberapa situasi. Itu adalah satu rencana, tetapi rencana lain adalah fungsi yang bertanda waktu di mana kami meninggalkan komponen gaya lama ini. Sebagai gantinya, kami akan fokus untuk memastikan bahwa jika seseorang memberi kami nomor urut ACK (SN) ini sebagai tanggapan terhadap paket, orang itu akan menjadi klien yang “benar”.

Anda ingat bahwa untuk mencegah serangan spoofing IP, kami agak mengandalkan nilai ini (SN). Memang, jika server mengirimkan nilai SNs ini ke klien di langkah kedua, kami berharap bahwa hanya klien ini yang dapat mengirimi kami nilai SN yang diperbaiki di langkah ketiga, menyelesaikan koneksi.

Inilah sebabnya mengapa Anda harus menyimpan nomor seri ini dalam sebuah tabel, karena jika tidak, bagaimana Anda tahu jika ini adalah jawaban nyata atau palsu? Alasan untuk menggunakan fungsi F ini adalah karena sekarang kita tidak dapat menyimpan tabel ini dalam memori.

Sebagai gantinya, ketika upaya koneksi ditampilkan, yang ditunjukkan pada langkah pertama, pada langkah kedua kami menghitung SN menggunakan rumus ini dan cukup mengirimkannya kembali ke klien yang ingin menghubungi kami, dan kemudian lupakan koneksi ini.



Kemudian, ketika paket ketiga tiba dan nilainya (SN) sesuai dengan apa yang kami harapkan, itu berarti seseorang menerima jawaban kami di langkah kedua dan akhirnya mengirimkannya kepada kami. Akhirnya, setelah langkah ketiga ini, kita dapat menempatkan catatan aktual untuk koneksi TCP ini ke dalam memori. Ini adalah cara untuk menunda kegigihan server sampai klien mengirimkan nilai persis nomor seri. Konstruksi konstruksi semacam itu memungkinkan untuk memverifikasi bahwa klien mengirim server dengan tepat jawaban yang diharapkan darinya, dan bukan nilai yang sewenang-wenang.

Siswa: apakah SNc hanya bertahan dalam waktu terbatas?

Profesor: ya, server tidak menyimpan nilai SNc secara permanen, dan ini tidak terlalu baik. Saya tidak menunjukkan ini dalam diagram, tetapi di sini pada akhir baris ketiga ada bidang yang menunjukkan bahwa paket ini tidak memiliki data, tetapi itu termasuk nomor urut SNc hanya karena memiliki bidang ini.



Dengan demikian, server dapat mengembalikan nilai SNc, karena klien akan memasukkannya ke dalam paket ini. Sebelumnya, itu tidak masalah, tetapi sekarang seolah relevan. Kami tidak akan memeriksa apa pun di sini, tetapi keberadaan bidang seperti itu sendiri merupakan hal yang baik. Namun, itu memiliki beberapa konsekuensi yang menyedihkan. Misalnya, jika Anda menggunakan beberapa hal rumit yang dapat disalahgunakan di sini. Tapi ini tidak seburuk memori server yang meluap dengan permintaan klien.

Karena satu-satunya hal yang membuat kami khawatir adalah melepaskan penyimpanan tabel ini dan keyakinan bahwa koneksi dibuat dengan klien asli. Dan jika klien ini membangun sejuta koneksi dengan saya, saya akan berhenti menerima permintaan darinya, itu cukup sederhana. Masalahnya adalah bahwa alamat palsu sulit dibedakan dari alamat pelanggan asli.

Siswa: apakah saya perlu mencatat waktu?

Profesor: ya, ada hal yang cerdas! Ketika kita mendapatkan nilai SN di langkah ketiga, kita perlu mencari cara menghitung data input untuk fungsi F ini untuk memverifikasi bahwa nilai ini benar. Oleh karena itu, kami mengambil stempel waktu yang terletak di akhir paket dan menggunakannya untuk menghitung di dalam fungsi. Segala hal lain yang dapat kami pulihkan. Kami tahu siapa yang mengirimi kami langkah ketiga dan paket, kami memiliki semua bidang ini dan kunci kami, yang, sekali lagi, masih rahasia, dan cap waktu dari 8 bit terakhir dari urutan. Dalam hal ini, dapat terjadi bahwa kami mengecualikan cap waktu terlalu lama dengan hanya melarang koneksi lama.

Siswa: Saya percaya Anda menggunakan ini ketika Anda diserang, hanya karena Anda kehilangan 8 bit keamanan, atau karena alasan lain?

Profesor: ya, ini tidak terlalu baik, ia memiliki banyak sifat buruk. Di satu sisi, kita benar-benar kehilangan 8 bit keamanan. Karena sekarang bagian yang tak terbantahkan hanya 24 bit, bukan 32.

Masalah lain adalah apa yang terjadi jika Anda kehilangan paket tertentu? Dalam TCP, secara umum diterima bahwa jika paket ketiga hilang, maka klien mungkin tidak menunggu apa pun. Atau, permisi, mungkin protokol yang kami jalankan di atas koneksi TCP ini adalah protokol yang mengasumsikan bahwa server awalnya bermaksud mengatakan sesuatu, jadi saya menyambungkannya dan hanya mendengarkan jawabannya. Dan di SMTP, misalnya, server harus mengirim saya sesuatu seperti salam melalui protokol. Misalkan saya terhubung ke server SMTP, mengirim paket ketiga, saya pikir saya melakukan segalanya dan hanya menunggu server untuk menjawab saya, misalnya:

"Hai, ini server SMTP, tolong kirimi saya email Anda!"

Jadi, paket ketiga ini mungkin hilang. Dalam TCP nyata, server mengingat bahwa pada langkah kedua ia merespons ke klien, tetapi tidak pernah menerima paket respons ketiga darinya. Oleh karena itu, server akan mengirim klien lagi paket kedua untuk memulai kembali paket ketiga. Tentu saja, jika server tidak menyimpan keadaan apa pun, ia tidak tahu harus mengirim apa. Ini membuat koneksi agak bermasalah, karena kedua belah pihak akan mengharapkan langkah timbal balik dari satu sama lain. Server bahkan tidak tahu bahwa klien sedang menunggu tanggapan darinya, dan klien sedang menunggu tanggapan server, meskipun tidak akan menjawab karena tidak menyimpan keadaan. Oleh karena itu, ini adalah alasan lain mengapa Anda tidak menggunakan mode produktif server secara konstan.

Siswa: Anda juga dapat kehilangan data jika Anda membuat dua koneksi yang sangat singkat dari satu host segera setelah satu sama lain.

Profesor: ya, tentu saja. Hal lain adalah bahwa kami menolak untuk menggunakan gaya lama nomor urut ISN ini, yang meningkatkan independensi beberapa koneksi ini dalam waktu singkat dari satu sama lain. Saya pikir ada sejumlah kompromi di sini, kami baru saja membicarakan tiga di antaranya, jadi ada beberapa alasan lagi yang perlu dikhawatirkan.

Jika kita dapat mengembangkan protokol dari awal, berjuang untuk yang terbaik, kita bisa memiliki volume 64-bit yang bagus untuk fungsi F dan volume 64-bit untuk cap waktu, dan kemudian kita dapat menggunakannya terus-menerus, tanpa menyerah semua hal baik ini.

Siswa: haruskah SN pada langkah kedua dan ketiga sama?

Profesor: tentu saja, karena jika tidak, server tidak akan dapat menyimpulkan bahwa klien ini menerima paket kami. Jika server tidak memverifikasi bahwa SNs ini memiliki arti yang sama seperti sebelumnya, maka itu bisa lebih buruk - karena saya bisa memalsukan koneksi dari alamat IP sewenang-wenang di langkah pertama, dan kemudian mendapatkan jawaban ini di langkah kedua. Atau saya bahkan tidak akan mendapatkan jawaban ini karena diarahkan ke alamat IP yang berbeda. Kemudian pada langkah ketiga saya membuat koneksi dari alamat IP lain. Dalam hal ini, server akan mendukung koneksi yang ada, menunggu saya mengirim data, dan sebagainya.



Siswa: tetapi stempel waktu akan berbeda, bukan? Bagaimana cara server menceritakan ini menggunakan cap waktu baru jika tidak menyimpan status?

Profesor: seperti yang saya katakan, cap waktu ini cukup "berbutir kasar" dan dinilai dalam beberapa menit. Jika Anda terhubung pada menit yang sama, maka semuanya beres, jika Anda terhubung pada batas menit - ini terlalu buruk.

Masalah lain dengan sirkuit ini adalah tidak sempurna dalam banyak hal. Tetapi kebanyakan sistem kerja, termasuk Linux, memiliki cara untuk mendeteksi terlalu banyak entri dalam tabel ini. Dan ketika ancaman melimpahnya terjadi, sistem beralih ke skema lain.

Siswa: jika seorang penyerang mengontrol sejumlah besar alamat IP dan melakukan apa yang Anda katakan, bahkan jika Anda ...

Profesor: ya, Anda benar-benar bisa berbuat banyak. Alasan skema ini sangat mempedulikan kami adalah karena kami ingin menyaring atau entah bagaimana membedakan antara penyerang dan "orang baik." Jika penyerang memiliki lebih banyak alamat IP dan hanya mengendalikan lebih banyak mesin daripada orang-orang baik, maka ia dapat terhubung ke server kami, meminta beberapa halaman web atau tetap berhubungan.

Dan kemudian akan sangat sulit bagi server untuk menentukan apakah permintaan diterima dari klien yang sah atau hanya penyerang yang mengikat sumber daya server. Jadi kamu benar sekali. Skema ini hanya berfungsi jika penyerang memiliki sejumlah kecil alamat IP dan ingin mencapai efek.

Dan ini memprihatinkan, karena saat ini beberapa penyerang mengendalikan sejumlah besar komputer yang diretas oleh pengguna biasa. Hal ini memungkinkan mereka untuk membuat DoS dengan armada mesin yang berlokasi di seluruh dunia, dan cukup sulit untuk mempertahankannya.

Saya ingin menyebutkan satu hal lagi yang menarik - penolakan layanan DoS itu buruk dalam dirinya sendiri, tetapi bahkan lebih buruk ketika protokol sendiri berkontribusi terhadap serangan semacam itu. Penyerang tahu tentang ini dan terutama menyerang sistem dengan protokol seperti DNS. Protokol DNS mencakup klien yang mengirim permintaan ke server, dan server mengirim respons kembali ke klien. Dan dalam banyak kasus, ukuran respons dalam byte jauh lebih besar daripada volume permintaan.



Anda bertanya tentang server mit.edu. , , mit.edu — , mit.edu, , DNS SEC, .

100 , — 1000 . , «» - . , DNS- . 100 - DNS-, , , 1000 .

, . , TCP SYN Flooding, DNS- , . , , « ».

DNS. . , DNS-. , . .

: DNS- …

: , DNS- , - .

: , ?

: , DNS-, . DNS-, . 10 DNS-, , , , , . . , , DNS-, .

, DNS , , , . , .

, , , – , , , . , , . .

DNS- , . , , .

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

, . - -, . DoS , . , , , , .



, , . , , , .

, , . .

, DHCP, . , , IP-. , , MIT DHCP, , , , IP-, , DNS-, , .

, DHCP DHCP-, , DHCP-. , , . , DHCP IP-, : «, DNS- »! DNS .

, . , BGP, IP-, . , , BGP, : «, IP-!», : „, , “.



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

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

, , , . : , , , , , DoS — . .

, , , , SYN Flooding RST , . , . – . , , «».


.

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?