Kursus MIT "Keamanan Sistem Komputer". Kuliah 13: Protokol 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
Kuliah 13: "Protokol Jaringan" Bagian 1 / Bagian 2 / Bagian 3

Jadi, hari ini kita akan berbicara tentang Kerberos, protokol yang aman secara kriptografis yang dirancang untuk otentikasi bersama komputer dan aplikasi pada jaringan. Ini adalah protokol untuk mengautentikasi klien dan server sebelum membuat koneksi di antara mereka.

Jadi sekarang, akhirnya, kita akan menggunakan kriptografi, tidak seperti kuliah terakhir, di mana kita melihat mengamankan menggunakan nomor urut TCP SYN saja.



Jadi mari kita bicara tentang Kerberos. Apa yang mencoba mendukung protokol ini? Itu dibuat di lembaga kami 25 atau 30 tahun yang lalu sebagai bagian dari proyek Athena untuk memastikan interaksi beberapa komputer server dan beberapa komputer klien.

Bayangkan Anda memiliki server file di suatu tempat. Mungkin ini adalah server surat yang terhubung ke jaringan, atau layanan jaringan lainnya, seperti printer. Dan semua ini hanya terhubung ke beberapa jaringan, dan tidak memproses pada satu komputer.



Prasyarat untuk penciptaan Athena dan Kerberos adalah bahwa Anda memiliki mesin untuk berbagi secara simultan, di mana semuanya merupakan proses yang terpisah, dan semua orang bisa masuk ke sistem yang sama dan menyimpan file mereka di sana. Oleh karena itu, para pengembang ingin membuat sistem terdistribusi yang lebih nyaman.



Dengan demikian, ini berarti bahwa Anda akan memiliki server ini di satu sisi dan banyak workstation di sisi lain yang akan digunakan pengguna sendiri dan di mana aplikasi akan berjalan. Workstation ini akan terhubung ke server ini dan menyimpan file pengguna, menerima email mereka, dan sebagainya.

Masalah yang ingin mereka pecahkan adalah bagaimana mengautentikasi pengguna yang menggunakan workstation ini untuk semua komputer yang berbeda di sisi server, tanpa harus mempercayai jaringan dan memverifikasi kebenarannya. Ini merupakan persyaratan desain yang wajar. Saya harus menyebutkan bahwa pada saat itu alternatif untuk Kerberos adalah tim login R, yang dibahas dalam kuliah terakhir, yang tampaknya seperti rencana yang buruk, karena mereka hanya menggunakan alamat IP mereka untuk mengotentikasi pengguna.

Kerberos telah cukup sukses, sebenarnya masih digunakan pada jaringan MIT dan merupakan tulang punggung server Active Directory Microsoft. Hampir setiap produk berbasis Microsoft Windows Server menggunakan Kerberos dalam satu bentuk atau lainnya.

Tetapi protokol ini dikembangkan 25 atau 30 tahun yang lalu, dan sejak itu diperlukan perubahan, karena saat ini orang lebih memahami tentang keamanan. Dengan demikian, versi Kerberos saat ini terasa berbeda dalam banyak hal dari versi yang dijelaskan dalam bahan untuk kuliah ini. Kami akan mempertimbangkan asumsi tertentu yang tidak cukup baik hari ini dan apa yang salah di versi pertama. Ini tidak dapat dihindari untuk protokol pertama yang benar-benar menggunakan kriptografi untuk mengotentikasi peserta jaringan dalam sistem full-blown.

Bagaimanapun, diagram yang digambarkan di papan adalah semacam instalasi untuk membuat Kerberos. Sangat menarik untuk mengetahui apa model kepercayaan itu. Oleh karena itu, struktur tambahan dimasukkan ke dalam skema kami - server Kerberos, yang terletak di sebelah sini.



Dengan demikian, model ketiga kami dalam beberapa hal didasarkan pada kenyataan bahwa jaringan tidak dapat diandalkan, seperti yang kami sebutkan dalam kuliah terakhir. Siapa yang harus kita percayai dalam skema Kerberos ini? Tentu saja, semua peserta jaringan harus mempercayai server Kerberos. Dengan demikian, pencipta sistem pada suatu waktu menyarankan bahwa server Kerberos akan bertanggung jawab untuk semua pemeriksaan otentikasi jaringan dalam satu bentuk atau lainnya. Apa lagi yang kami miliki di jaringan ini yang dapat Anda percayai?

Mahasiswa: Pengguna dapat mempercayai mesin mereka sendiri.

Profesor: ya, ini argumen yang bagus. Ada pengguna di sini yang belum saya gambar. Tetapi orang-orang ini menggunakan semacam workstation, dan pada kenyataannya, di Kerberos sangat penting bagi pengguna untuk mempercayai workstationnya. Apa yang terjadi jika Anda tidak mempercayai stasiun kerja Anda? Karena jika pengguna tidak mempercayai workstation, maka di sana Anda cukup "mengendus" kata sandi Anda dan bertindak atas nama Anda.



Siswa: penyerang dapat melakukan lebih banyak lagi, misalnya, dengan mempelajari tiket Anda ke server Kerberos.

Profesor: ya, tepatnya. Ketika Anda masuk, Anda memasukkan kata sandi Anda, yang bahkan lebih buruk daripada tiket. Jadi sebenarnya, ada masalah kecil dengan Kerberos jika Anda tidak mempercayai workstation. Jika Anda menggunakan laptop Anda sendiri, itu tidak begitu menakutkan, tetapi keamanan komputer publik diragukan. Kami akan mempertimbangkan apa yang sebenarnya salah dalam kasus ini.

Siswa: Anda harus mempercayai administrator server dan memastikan bahwa mereka dapat memiliki akses istimewa ke server masing-masing.

Profesor: Saya pikir mesin itu sendiri tidak harus saling percaya, misalnya, server surat tidak harus mempercayai server cetak atau server file.

Siswa: tidak percaya, tetapi memiliki kemampuan untuk mengakses server yang aksesnya melalui server lain tidak didukung.

Profesor: ya, itu benar. Jika Anda menjalin hubungan saling percaya antara server surat dan server cetak, tetapi hanya memberikan akses server mail ke file Anda di server file untuk kenyamanan, maka ini dapat disalahgunakan. Jadi, Anda harus berhati-hati memperkenalkan tingkat kepercayaan tambahan atau kepercayaan berlebihan di sini.

Apa lagi yang penting di sini? Haruskah server memercayai pengguna atau workstation? Saya kira tidak. Tujuan global Kerberos adalah bahwa server a priori tidak boleh mengetahui semua pengguna atau workstation ini, atau tahu bagaimana mengotentikasi mereka, sampai pengguna ini dapat membuktikan secara kriptografis bahwa mereka adalah pengguna yang sah dan harus memiliki akses ke data mereka atau sesuatu lebih dari yang dikelola server.

Mari kita lihat bagaimana Kerberos bekerja dan apa arsitektur umumnya. Mari menggambar server Kerberos dalam skala yang lebih besar. Saat ini, itu disebut KDC - Key Distribution Center, atau Key Providing Center. Di suatu tempat ada pengguna dan layanan yang dapat Anda hubungi. Rencananya adalah server Kerberos akan bertanggung jawab untuk menyimpan kunci bersama untuk komunikasi antara server Kerberos dan setiap entitas komputer di dunia di sekitarnya. Jadi, jika pengguna memiliki semacam kunci klien Kc, maka server Kerberos mengingat kunci ini dan menyimpannya di suatu tempat di dalamnya. Dengan cara yang sama, kunci Ks untuk layanan hanya akan diketahui oleh layanan ini sendiri, server Kerberos, dan tidak ada orang lain. Dengan demikian, Anda dapat menganggapnya sebagai penggunaan kata sandi yang umum ketika Anda mengetahui kata sandi dan Kerberos mengetahuinya, tetapi tidak ada orang lain yang mengetahuinya.



Begitulah cara Anda akan membuktikan satu sama lain bahwa "Saya orang yang sama." Tentu saja, server Kerberos harus melacak siapa yang memiliki kunci ini, sehingga harus memiliki tabel yang akan menyimpan nama pengguna dan nama layanan, misalnya, serv afs (ini adalah file server), dan kunci yang sesuai dengan mereka.

Pada saat yang sama, KDC bertanggung jawab untuk menyimpan tabel raksasa, tidak terlalu besar dalam hal jumlah byte, tetapi sangat banyak dalam jumlah catatan, karena memperhitungkan setiap entitas komputer yang hidup dalam jaringan MIT yang harus diperhatikan oleh server Kerberos. Jadi, kami memiliki dua jenis antarmuka.



Materi perkuliahan tidak membicarakan hal ini dengan cukup jelas, yaitu, keberadaan 2 antarmuka ini hanya tersirat. Bahkan, sebenarnya ada dua antarmuka untuk satu mesin. Salah satunya disebut Kerberos, dan yang kedua adalah TGS, Layanan Pemberian Tiket, atau Layanan Tiket.

Bahkan, pada akhirnya, ini hanya dua cara untuk membicarakan hal yang sama, dan protokol hanya sedikit berbeda untuk kedua hal ini. Karena itu, pada awalnya, ketika seorang pengguna login, ia “berbicara” dengan antarmuka atas, Kerberos, dan mengirimkannya nama kliennya C, ini mungkin nama pengguna Anda di jaringan universitas Athena.

Server menanggapi permintaan ini dengan informasi tiket atau tiket, kami akan membahas detail informasi ini sedikit kemudian. Kemudian, ketika Anda ingin mengobrol dengan beberapa layanan, pertama-tama Anda harus pergi ke antarmuka TGS dan mengatakannya: "Saya sudah masuk melalui antarmuka Kerberos dan sekarang saya ingin berbicara dengan server S, yang akan memberi saya layanan tertentu."

Jadi Anda akan memberi tahu TGS tentang server yang ingin Anda ajak bicara, setelah itu ia akan mengembalikan Anda sesuatu seperti tiket untuk berbicara dengan server S. Kemudian Anda akhirnya dapat berbicara dengan server yang Anda perlukan menggunakan tiket yang diterima untuk server S.

Ini adalah semacam rencana tingkat tinggi. Jadi mengapa 2 antarmuka digunakan di sini? Banyak pertanyaan yang bisa ditanyakan tentang ini. Dalam kasus server Ks, layanan ini mungkin akan disimpan pada disk. Dan apa yang terjadi dengan Kc ini di sisi pengguna? Dari mana asal Kc ini di Kerberos?



Mahasiswa: Kc ini harus ada di database, di tabel server KDC.

Profesor: ya, kunci C ada di sini di tabel, dalam basis data raksasa ini. Tetapi itu juga harus diketahui pengguna, karena pengguna harus membuktikan bahwa dia adalah pengguna.

Siswa: apakah ini fungsi satu arah yang kemudian membutuhkan kata sandi?

Profesor: ya, mereka sebenarnya memiliki rencana yang sangat cerdas, di mana Kc diperoleh dengan mem-hashing kata sandi pengguna atau semacam fungsi pembuatan kunci, untuk ini ada beberapa metode berbeda. Tapi pada dasarnya kami mengambil kata sandi, mengonversinya, dan mendapatkan kunci ini Kc. Jadi ini sepertinya cara yang baik.

Tetapi mengapa kita membutuhkan dua protokol? Lagi pula, Anda dapat membayangkan bahwa Anda hanya meminta tiket langsung dari antarmuka Kerberos pertama, mengatakan kepadanya: "Hei, saya ingin tiket untuk nama khusus ini!", Dia akan mengirimkan Anda tiket kembali, dan Anda dapat mendekripsi menggunakan Kc.

Siswa: mungkin mereka tidak ingin pengguna memasukkan kembali kata sandi mereka setiap kali mereka ingin mengakses layanan lain?

Profesor: benar, alasan perbedaan antara kedua antarmuka adalah bahwa dari antarmuka pertama semua respons dikembalikan dienkripsi dengan kunci Kc Anda, dan pembuat Kerberos khawatir tentang kemungkinan menyimpan Kc ini untuk waktu yang lama. Karena Anda harus meminta pengguna untuk memasukkan kata sandi setiap waktu, yang hanya mengganggu, atau dia terus-menerus "duduk" di memori. Pada dasarnya, ini sama baiknya dengan hanya kata sandi pengguna, karena seseorang dengan akses Kc dapat menjaga akses ke file pengguna hingga pengguna mungkin mengubah kata sandinya, atau bahkan lebih lama. Nanti kita akan membahas masalah ini secara lebih rinci.

Jadi membocorkan kunci Kc ini adalah hal yang sangat berbahaya. Dengan demikian, seluruh titik menggunakan antarmuka pertama dan kemudian kedua untuk semua permintaan berikutnya adalah bahwa Anda benar-benar dapat melupakan Kc segera setelah Anda mendekripsi respons dari antarmuka TGS server Kerberos. Mulai sekarang, bahkan jika terjadi kebocoran kunci, fungsionalitas akan tergantung pada tiket yang diterima. Jadi dalam kasus terburuk, seseorang akan mendapatkan akses ke akun Anda selama beberapa jam, dan bukan untuk waktu yang tidak terbatas. Inilah alasan skema semacam itu dengan dua jalur akses ke sumber daya yang sama.

Jadi, sebelum kita mempelajari mekanisme tentang bagaimana protokol ini benar-benar terlihat di jaringan, mari kita bicara sedikit tentang aspek nama Kerberos. Dalam arti tertentu, Kerberos dapat dianggap sebagai daftar nama. Dia bertanggung jawab untuk menampilkan kunci kriptografi ini sebagai nama kecil. Ini adalah jenis operasi mendasar yang dilakukan Kerberos. Anda akan melihat di kuliah berikutnya mengapa kita membutuhkan fungsi yang serupa. Ini dapat diimplementasikan secara berbeda daripada di Kerberos, tetapi pada dasarnya sangat penting untuk memiliki hal serupa di hampir semua sistem keamanan terdistribusi. Jadi, mari kita lihat bagaimana Kerberos berurusan dengan nama.

Kerberos memiliki sesuatu seperti pemanggilan sistem untuk setiap entitas komputer dalam database anggota jaringan, dan bentuk utama dari data ini hanyalah sebuah string. Jadi, Anda dapat memiliki beberapa nama dasar dalam bentuk seperti nickolai, misalnya. Ini adalah string nama.



Ini adalah parameter utama di beberapa area Kerberos, sebenarnya ini adalah hal yang ada di kolom kiri tabel KDC. Dan ada juga beberapa parameter tambahan yang didukung protokol. Saya bisa, misalnya, memasukkan nama lain seperti nickolai.extra dtk, yang akan digunakan di samping nama nickolai untuk mengakses sumber daya yang memerlukan keamanan tambahan. Jadi mungkin saya akan memiliki satu kata sandi untuk hal-hal yang benar-benar aman dan kata sandi lain untuk akun reguler saya.

Kerberos telah menyebutkan aspek ini. Karena itu, orang mungkin bertanya-tanya - dari mana dampaknya berasal? Layanan Kerberos memetakan nama untuk Anda ke kunci tertentu, tetapi bagaimana Anda tahu nama yang akan ditanyakan atau nama apa yang diharapkan sebagai respons ketika Anda berbicara dengan komputer? Yaitu, saya bertanya nama apa yang muncul di luar server Kerberos, atau di mana tepatnya nama pengguna ini muncul? Apakah Anda punya ide?

Mahasiswa: mungkin Anda dapat meminta nama pengguna dari server MIT.

Profesor: ya, tentu saja. Ini adalah bagaimana Anda dapat mendaftar hal-hal ini. Selain itu, pengguna cukup memasukkan mereka ketika mereka masuk, dari mana mereka berasal. Apakah nama pengguna muncul di tempat lain? Haruskah mereka muncul di tempat lain?

Mahasiswa: ada kemungkinan bahwa akses pengguna ditunjukkan dalam daftar di berbagai layanan.

Profesor: ya, ini adalah poin yang sangat penting, bukan? Tujuan Kerberos adalah hanya memetakan kunci ke nama. Tapi ini tidak memberi tahu Anda apa nama ini harus memiliki akses.

Bahkan, cara aplikasi biasanya menggunakan Kerberos adalah bahwa salah satu server ini menggunakan Kerberos untuk mencari tahu nama huruf kecil mana yang diajak bicara. Ketika server email menerima koneksi dari beberapa workstation, ia menerima tiket Kerberos, yang membuktikan bahwa pengguna ini adalah Nikolai. Setelah itu, server surat secara internal mencari tahu apa yang dapat diakses oleh pengguna ini. Server file melakukan hal yang sama.

Jadi, di dalam semua server ini ada daftar kontrol akses, mungkin daftar grup atau hal-hal lain yang melakukan otorisasi. Jadi Kerberos menyediakan otentikasi yang menunjukkan kepada Anda orang yang Anda ajak bicara. Layanan itu sendiri bertanggung jawab atas implementasi bagian otorisasi tersebut, yang menentukan tingkat akses yang seharusnya Anda miliki berdasarkan nama pengguna Anda. Jadi kami menemukan di mana nama pengguna muncul. Ada nama dasar lain yang didukung Kerberos untuk berinteraksi dengan layanan.

Menurut materi kuliah, layanannya terlihat seperti ini: rcmd.hostname. Alasan Anda memerlukan nama untuk salah satu layanan ini adalah karena Anda ingin, misalnya, saat menyambung ke server file, untuk melakukan otentikasi bersama. Ini berarti bahwa dalam prosedur ini, tidak hanya server tujuan akan mengetahui siapa saya, tetapi juga saya, pengguna atau workstation, pastikan bahwa saya berbicara dengan server file yang benar, dan bukan ke beberapa server file palsu yang memalsukan milik saya. file. Karena, mungkin, saya ingin melihat file dengan peringkat saya dan mengirimkannya ke registrar. Oleh karena itu, akan sangat buruk jika beberapa file server lain dapat bertindak sebagai server yang benar dan memberi saya file peringkat yang salah.

Oleh karena itu, layanan juga memerlukan nama mereka sendiri, dan stasiun kerja harus mencari tahu nama apa yang saya harapkan ketika saya terhubung ke layanan tersebut.



Sebagai aturan, pada tingkat tertentu ini berasal dari pengguna. Jadi, misalnya, jika saya mengetik ssh.foo, ini berarti saya harus mengharapkan nama utama Kerberos seperti rcmd.foo muncul di ujung lain koneksi ini. Dan jika ada orang lain di sana, maka klien SSH harus memutuskan dan tidak membiarkan saya terhubung, karena dengan begitu saya akan disesatkan dan mulai berbicara dengan beberapa mesin lain.

Ini menimbulkan satu pertanyaan menarik. Kapan kami dapat menggunakan kembali nama dalam Kerberos? Misalnya, Anda semua memiliki akun di sistem institut Athena. Ketika Anda lulus, bisakah MIT menghancurkan entri basis data Anda dan mengizinkan orang lain untuk mendaftarkan nama pengguna yang sama? Apakah itu ide yang bagus?

Mahasiswa: tetapi tidak hanya basis data Kerberos, tetapi juga layanan memiliki daftar nama pengguna?

Profesor: ya, karena nama-nama ini sebenarnya hanya diwakili oleh entri string di suatu tempat di ACL pada file atau server mail. Jika kami menghapus entri Anda dalam database server Kerberos, ini tidak berarti bahwa entri Anda telah hilang sama sekali. Entri-entri ini adalah versi independen.

Sebagai contoh, sebuah catatan mengatakan bahwa Alice memiliki akses ke loker Athena. Kemudian Alice lulus, dan catatannya dihapus, tetapi beberapa Alice baru memasuki institut, yang melewati proses pendaftaran di database Kerberos. Pada saat yang sama, ia mendapatkan nama utama yang benar-benar identik dengan nama Alice lama, sehingga server file dapat memberikan akses Alice baru ke file-file Alice lama.

, Kerberos , Kerberos . , , , .

. , , , , , . , , , - . , . , , .

, . , , , TGS.



, , Kerberos, «». : s , IP – addr, time stump, life, , , Kc,s, . .



.

, Kerberos «». Ac , IP- , , . , . K,s, , Kerberos Ks. , .



, , Kerberos TGS. , , Kerberos, , . : C, , S, TGS. .

Tc,s, Ks, , Ks, , Kc. .



. , Kerberos ? , ?

: , , , Kc.

: , , Kerberos , . : «, , . , , , Kc». , .

, , , Kerberos, Kerberos , . , , - Kerberos, , .
: …

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



«», , , , , . , , . . Kerberos, , . , , .

: ? , …

: , . , Kerberos , . , , - , , , . 30 , .

Kerberos 5 : , — . , , , , .

Kerberos 4 , , , . , . , , .

Jadi, ini adalah rencana untuk memberi tahu klien apakah tiketnya valid. Mereka hanya mencoba mendekripsi dan melihat cara kerjanya. Pertanyaan menarik lainnya - mengapa kunci Kc ini, dalam beberapa bentuk termasuk dalam tiket dua kali? Ini hadir pada tiket secara terpisah sebagai Kc kunci, dan hadir secara implisit dalam tiket itu sendiri Tc, s. Mengapa kami memiliki dua salinan kunci Kc, s?

27:10 mnt.

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