Kursus MIT "Keamanan Sistem Komputer". Kuliah 4: “Berbagi Hak Istimewa,” 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 baru-baru ini. 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

Jadi, gambar kami menggambarkan "karya seni", yang coba dilindungi oleh penciptanya dari ancaman. Dalam kasus mereka, saya pikir mereka sangat khawatir, karena dengan membuat situs kencan okcupid.com , mereka benar-benar ingin memastikan bahwa reputasi pengguna situs tidak akan terpengaruh oleh pengungkapan data pribadi. Dari percakapan dengan salah satu pengembang situs yang menulis artikel tentang ini, diketahui bahwa mereka sebenarnya tidak dikompromikan. Setidaknya, ada kehilangan data akibat penggunaan OKWS arsitektur dan sebagian karena pemantauan aktivitas berbahaya belum terjadi.

Alasan orang tidak memecah aplikasi mereka menjadi komponen yang lebih kecil adalah karena proses ini membutuhkan usaha. Penting untuk memilih semua bagian kode, mendefinisikan antarmuka yang jelas di antara mereka, dan memutuskan data yang harus diakses oleh setiap komponen. Jika Anda memutuskan untuk mengimplementasikan fungsi baru, Anda harus mengubah data yang dapat diakses oleh setiap komponen program, untuk memberikannya keistimewaan baru atau untuk memilih beberapa, dan seterusnya. Jadi ini adalah proses yang agak memakan waktu.



Mari kita coba memahami bagaimana server web dirancang, dan mungkin satu cara untuk melakukan ini adalah melacak bagaimana permintaan http diproses oleh server OKWS . Jadi, mirip dengan yang ditunjukkan pada gambar sebelumnya, kami memiliki browser web yang ingin pergi ke okcupid.com . Para pengembang proyek situs membayangkan bahwa mereka akan memiliki banyak mesin, tetapi kita hanya akan melihat antarmuka situs tempat OKWS akan bekerja, dan mesin lain di latar belakang yang akan menyimpan database. mesin kedua ini menggunakan MySQL, karena merupakan perangkat lunak yang baik untuk berbagai tugas. Mereka ingin benar-benar melindungi data ini karena sangat sulit untuk sampai ke disk mentah atau database dengan datagram mentah mentah.

Jadi, bagaimana cara kerjanya, bagaimana permintaan diproses oleh server OKWS ? Pertama, ia tiba dan diproses oleh proses yang disebut okd untuk dispatcher OKWS . Dia memeriksa apakah dia meminta permintaan ini, dan kemudian melakukan beberapa hal. Karena Anda mungkin perlu mendaftarkan permintaan ini terlebih dahulu, itu mengarahkannya ke komponen yang disebut oklogd , setelah itu Anda perlu membuat beberapa templat, dan mungkin perlu membuatnya bahkan sebelum permintaan itu tiba. Dan itu komponen lain yang disebut pubd .



Dan akhirnya, ada layanan yang pasti untuk yang permintaan dikirim, sehingga OKD ada satu set meja layanan yang mendukung. Agaknya permintaan ini datang ke salah satu layanan ini, jadi setelah meninjau okd akan mengarahkan permintaan ini ke proses layanan SVD tertentu. Layanan ini akan melakukan persis apa yang diminta oleh permintaan, misalnya, berlangganan pengguna ke buletin, atau memungkinkan untuk melihat direktori pengguna ocupid menggunakan database, dll.

Dan untuk ini, Anda mungkin perlu layanan untuk meninggalkan informasi aplikasi di log komponen oklogd . Dan pada akhirnya, ia harus "berbicara" dengan database. Pembuat situs ini telah menerapkan proses "komunikasi" ini sedikit berbeda dari yang biasanya terjadi di Apache , di mana Anda cukup berkomunikasi dengan database dan mengeluarkan pertanyaan SQL sewenang-wenang. Mereka datang dengan konsep database proxy, dbproxy, yang terletak di depan database MySQL, dan menerima permintaan dari svc layanan, untuk melakukan itu. Saya pikir ilustrasi ini pada dasarnya menunjukkan cara kerja OKWS .



Ada komponen lain yang memulai semua ini, disebut okld , dan bertanggung jawab untuk memulai semua proses dalam antarmuka server web ini. Saya berharap beberapa dari hal-hal ini terlihat akrab bagi Anda, karena ini persis arsitektur yang dipertimbangkan di laboratorium. Sepertinya ini desain yang bagus. Anda tidak memiliki pubd , logd dan dbproxy di LR , tetapi Anda memiliki okd dan svc . Ada pertanyaan tentang OKWS ?

Pemirsa: Kami mengerti benar bahwa dbproxy tidak mengambil SQL-query, dan jenis lain dari permintaan?

Profesor: ya benar! Seperti apa tampilan antarmuka ini? Mereka tidak menggambarkan ini dengan sangat rinci, tetapi satu hal yang dapat Anda lakukan dengan dbproxy ini adalah untuk menyimpan banyak argumen untuk templat kueri SQL . Misalnya, itu bisa menjadi templat permintaan pencarian untuk teman Anda, memilih mereka berdasarkan ID .



Misalkan ada template seperti "pilih ^ ID dari daftar teman Anda, di mana ^ ID ="% S " . Misalkan Anda ingin menemukan Alice di antara teman-teman Anda dan mengirim permintaan S , di mana argumennya adalah "alice" . Biarkan aplikasi kami, tersedia dalam antarmuka, tahu bahwa dbproxy siap untuk melakukan tiga jenis permintaan atas namanya. Jika Anda ingin menjalankan kueri No. 1, dan argumennya adalah "Alice" , maka ia memberi Anda akses ke database.

Pemirsa: dapatkah pengguna eksternal di tingkat peramban web mengirim permintaan seperti itu ke basis data atau apakah semua itu hanya berlaku untuk pengguna internal jaringan?

Profesor: ya, mungkin. Jadi bagaimana cara kerjanya? Bahkan, itu adalah aneh bahwa database terletak pada mesin yang terpisah, karena itu mungkin untuk menghubungkan ke database OKWS atau ke server MySQL? Jadi apa yang menghentikan ini?

Pemirsa: firewall?

Profesor: ya, mungkin pada tingkat tertentu. Pengembang tidak menjelaskan hal ini dengan terlalu rinci, tetapi mungkin ada beberapa jaringan internal pada mesin kedua, dan ada pergantian antara antarmuka dan basis data yang tidak dapat dijangkau dari dunia luar. Faktanya, kedua mesin berada di jaringan yang sama, tetapi ada firewall Fw yang memiliki aturan tertentu. Mungkin mereka adalah Anda hanya dapat terhubung ke komputer antarmuka ini melalui port 80, tetapi tidak secara langsung ke server internal. Ini adalah salah satu opsi perlindungan.



Lain, mungkin, adalah bahwa ketika Anda terhubung ke proxy database dbproxy ini, Anda perlu memberikan token kriptografi 20-byte, atau kunci, dan jika Anda tidak menyediakannya, dbproxy akan menolak koneksi Anda. Jadi aturannya adalah Anda membuka koneksi TCP, mengirim 20 byte, dan jika salah, koneksi ditutup. Ini, saya pikir, adalah arti dari desain sistem semacam itu.

Jadi, mari kita coba mencari tahu bagaimana proses yang berbeda ini diisolasi di sini. Bagaimana Anda bisa memastikan bahwa semua komponen ini tidak saling membanjiri?

Hadirin: hak root dan ID pengguna berbeda?

Profesor: ya, hampir setiap komponen ini bekerja sebagai uid yang berbeda, jadi di sini, dalam deskripsi sistem, ada seluruh tabel yang menjelaskan untuk setiap komponen di mana ia bekerja dan dengan apa uid . Jadi kita dapat menulis bahwa okd memiliki uid sendiri, pubd memiliki uid sendiri dan oklogd juga memiliki uid sendiri.

Okld berfungsi sebagai root , yang agak tidak berhasil, tapi mungkin ini bukan masalah besar. Lalu ada sejumlah pengidentifikasi pengguna yang ditugaskan secara dinamis untuk setiap layanan, misalnya ID 51001, dll.



Dengan demikian, ini memastikan bahwa setiap layanan tidak dapat mengganggu proses layanan lainnya. Chroot juga banyak digunakan di sini, sehingga beberapa komponen ini memiliki hak chroot di direktori terpisah. Sebagai contoh, okd dan svc diberkahi dengan hak chroot yang umum di beberapa direktori. Menurut Anda mengapa kedua komponen ini memiliki komponen chroot yang terpisah dan tidak umum?

Pemirsa: karena okd tidak memiliki hak akses root.

Profesor: ya, tapi mengapa mereka tidak memasukkan pubd , oklogd , dan semua orang di chroot yang sama?

Audiens: apakah mungkin jika layanan perlu berbagi banyak data, haruskah mereka diisolasi satu sama lain?

Profesor: bisa. Saya pikir mereka harus berbagi beberapa data, tetapi data ini tidak ada dalam file, mereka ditransfer melalui soket dari okd ke layanan. Tetapi pada kenyataannya, tidak satu pun dari komponen ini menyimpan sesuatu yang menarik dalam sistem file.

Oleh karena itu, tidak ada yang menarik di direktori chroot , dan saya pikir orang-orang dari OKWS hanya memutuskan untuk mengurangi biaya tidak produktif untuk chroot , seperti kebutuhan untuk membuat salinan direktori. Mungkin mereka juga ingin menyingkirkan beberapa overhead manajemen untuk setiap perintah chroot . Tetapi karena tidak ada file nyata di sini, maka semuanya beres.

Alasan orang-orang ini memberikan chroot yang berbeda untuk komponen lingkungan adalah karena beberapa hal menarik. Mungkin ada template, tetapi di sini, mungkin, ada file log, jadi mereka tidak ingin file log dibaca secara tidak sengaja, dan sejenisnya.

Pemirsa bukan apakah file layanan ini, misalnya, ketik aspx?

Profesor: seperti yang mereka jelaskan di artikel, layanan ini adalah biner C ++ tunggal yang dikompilasi, jadi sebenarnya tidak ada file tambahan.

Ada template, tetapi mereka benar-benar ditransmisikan melalui mekanisme aneh ini: pubd memiliki template dalam direktori-nya, menampilkannya di beberapa pra-komputer, form rumah di okd , dan okd sudah menyediakan template untuk semua layanan melalui panggilan RPC . Dengan demikian, mereka duduk di memori, tetapi sebenarnya tidak dapat diakses langsung melalui sistem file. Ini adalah desain yang agak paranoid ketika saya bahkan tidak bisa membaca template.
Jadi, apa gunanya memisahkan semua komponen ini? Mengapa kita perlu oklogd terpisah?

Audiens: untuk menghilangkan kemungkinan menimpa atau memangkas jurnal?

Profesor: ya, jadi kami benar-benar ingin memastikan bahwa jika terjadi kesalahan, jurnal, setidaknya, tidak akan rusak. Dengan demikian, ada file log terpisah yang dapat ditulis oleh uid ini, dan semua pesan log dikirim sebagai RPC untuk layanan log ini. Dan bahkan jika semuanya hancur, yah, dengan pengecualian okld , majalah itu akan tetap tidak terluka.

Hadirin: bagaimana jika Anda secara tidak sengaja menemukan cara untuk membaca majalah dan tidak melihat apa yang telah dilakukan orang lain dengan majalah itu?

Profesor: tidak, saya pikir jika Anda "meretas" suatu layanan, pubd atau sesuatu yang lain, Anda dapat menulis apa pun di jurnal. Oleh karena itu, membuat entri oklogd terpisah masuk akal. Sebenarnya, oklogd adalah proses yang terpisah, dan tidak hanya diperbarui dengan melampirkan file sebagai file append-only . Dengan demikian, oklogd tidak dapat menambahkan beberapa informasi tambahan untuk setiap entri log, karena jika OS mendukung file append-only , Anda tidak akan tahu bahwa seseorang telah menulis ke file ketika ini terjadi. Sementara oklogd menempatkan stempel waktu untuk setiap pesan dan memungkinkan Anda untuk mengetahui layanan mana yang membuat rekaman atau berasal dari okd . Karena itu, Anda benar-benar mendapatkan informasi tambahan dalam file log ini karena ini adalah layanan terpisah.

Dan apa arti pemisahan okld dan mengapa harus bekerja dengan hak root? Saya pikir ada beberapa alasan untuk ini.

Audiens: jika Anda tidak ingin orang lain bertindak dengan hak akses root, Anda perlu mendelegasikan fungsi otentikasi pengguna okld .



Profesor: ya. Seseorang harus mengkonfigurasi semua ini uro chroot , dan Anda perlu root untuk Unix ini, jadi okld menyediakan ini. Ini salah satu alasannya. Ada lagi?

Hadirin: 80 definisi port?

Profesor: Ya, tentu saja! Anda harus mengikat mendengarkan port 80, yang mana okld dan memberikan hal lain?

Pemirsa: ini melengkapi pembukaan file log oklogd karena kami tidak ingin membiarkan oklogd terbuka untuk mencegah akses ke file log.

Profesor: mungkin. Tapi saya tidak tahu apakah pengembang benar-benar melakukannya karena mereka tidak melihat kode sumber mereka. Anda berpikir, okld membuka file log dan mengirimkannya oklogd? Mungkin

Hadirin: karena jika tidak, penyerang yang berkompromi dengan oklogd dapat menghapus seluruh log.

Profesor: ya, itu benar. Mungkin Anda ingin membukanya dalam mode append dan kemudian meneruskannya oklogd , maka Anda memiliki jaminan keamanan lebih untuk log. Ini adalah sesuatu yang tidak dapat Anda lakukan tanpa hak root.

Jadi, kami memiliki pertanyaan tentang pekerjaan rumah, apa yang akan terjadi ketika token 20-byte ini “bocor” untuk mengakses database. Kerusakan apa yang dapat menyebabkan ini? Haruskah kita khawatir tentang ini?

Hadirin: dalam hal ini, penyerang dapat mengambil kendali atas layanan tertentu.

Profesor: ya, benar, karena sekarang Anda dapat terhubung dan mendapatkan semua templat kueri. Ini sebenarnya terlihat cukup sederhana. Anda mungkin perlu kompromi salah satu komponen ini agar dapat terhubung ke database server terlebih dahulu. Jadi saya pikir jika Anda memiliki token ini dan Anda dapat kompromi salah satu komponen ini yang ditunjukkan pada gambar, maka Anda dapat menggunakan semua pertanyaan ini.

Sekarang mari kita lihat bagaimana desain OKWS ini dapat ditingkatkan? Misalnya, akan dimungkinkan untuk mengalokasikan unit UID terpisah untuk setiap pengguna, selain mengalokasikan UID terpisah untuk setiap layanan. Di sini, setiap layanan, misalnya, berita, mencari teman, atau membuat akun, memiliki userid terpisah, tetapi setiap pengguna OKWS tidak direpresentasikan sebagai uix Unix . Sebenarnya tidak ada userid di sini, hanya ID layanan yang ada di sini. Apakah Anda pikir Anda harus memiliki uid yang berbeda untuk setiap klien OKWS ?

Pemirsa: dalam kasus ini, ternyata jika satu pengguna “meretas” suatu layanan, ia akan dapat mengakses semua data pengguna lain dari server ini.

Profesor: ya, benar!

Hadirin: tetapi jika Anda memiliki, pada kenyataannya, layanan terpisah dan dbproksi terpisah untuk setiap pengguna, maka tidak mungkin untuk mengakses data orang lain.

Profesor: ya, tetapi mungkinkah ini model yang lebih kuat? Saya pikir pengembang OKWS tidak mengambil langkah seperti itu karena dua alasan. Yang pertama adalah kinerja. Jika Anda memiliki beberapa juta pengguna situs okcupid , beberapa juta proses yang berjalan, dan beberapa juta dbproxie , maka overhead kinerja dimungkinkan. Dan ini tidak akan memungkinkan untuk mencapai kinerja yang sama dengan yang disediakan oleh arsitektur OKWS .

Pemirsa: deskripsi OKWS mengatakan bahwa kinerja sistem ini lebih baik daripada sistem lain. Bagaimana ini dicapai?

Profesor: Saya pikir ini sebagian karena mereka menyesuaikan desain mereka dengan beban kerja tertentu, di samping itu, mereka menulis semua ini di C ++ . Alternatifnya adalah menulis beberapa hal dalam PHP , maka kemungkinan besar Anda akan mendapatkan manfaat di bagian depan ini.

Selain itu, mereka tidak memiliki banyak fitur yang dimiliki Apache . Ini memiliki desain tujuan umum, sehingga memiliki banyak proses kerja, dan memuatnya dari waktu ke waktu. Ada banyak koneksi TTP yang memastikan durasi proses koneksi dan mempertahankan aktivitasnya. Ini juga meningkatkan jumlah proses yang berjalan pada sistem. Apache telah dibuat lebih universal dan dapat melakukan segala sesuatu yang Anda ingin dapatkan dari server Internet, dan orang-orang dari OKWS lebih fokus untuk menyelesaikan masalah tertentu.

Tapi saya pikir ada server web lain hari ini yang mungkin bisa cocok dengan kinerja OKWS . Misalnya, Nginx adalah server web yang sangat optimal yang dapat Anda jalankan hari ini. Jika Anda ingin aplikasi berkinerja tinggi di sisi server, Anda mungkin ingin proses panjang sangat mirip dengan layanan OKWS . Dan itu akan memiliki mekanisme untuk antarmuka gateway CGI cepat umum untuk menghubungkan program eksternal dengan server web, atau semacam protokol yang dapat digunakan di sisi server untuk mengimplementasikan ini bahkan di Apache atau Nginx . Oleh karena itu, saya pikir banyak dari ide-ide ini tidak eksklusif untuk OKWS , mereka dapat diimplementasikan di server web lain. Mereka hanya menunjukkan bahwa meningkatkan keamanan tidak menghalangi penggunaan "trik" ini. Saya pikir mereka mulai dengan skema yang mirip dengan Apache , tetapi berpikir itu tidak akan cukup aman.

Jadi saya berpikir bahwa salah satu alasan mengapa pembuat OKWS tidak ingin memperkenalkan hak istimewa terpisah untuk pengguna adalah kemungkinan penurunan kinerja.



Alasan lain adalah bahwa model aplikasi lengkap mereka “berputar” di sekitar layanan yang mencoba mengakses data masing-masing pengguna, seperti mencari teman di okcupid atau seseorang yang dapat Anda undang saat kencan. Akibatnya, model isolasi pengguna ini tidak masuk akal, karena, pada akhirnya, harus ada layanan yang Anda kirim permintaan, dan itu akan melihat semua data lain untuk menemukan kecocokan untuk permintaan Anda. Jadi, bahkan jika Anda memiliki pengidentifikasi pengguna atau mekanisme untuk mengisolasi mereka, Anda masih harus membuka akses ke layanan untuk setiap pengguna.

Untuk layanan lain, seperti Gmail atau Dropbox , yang jauh lebih fokus pada pengguna tertentu dan tidak memberikan kemampuan terbuka untuk berbagi file, mengisolasi pengguna dapat memberikan lebih banyak keuntungan. Misalnya, di server Dropbox ada userid untuk setiap klien Dropbox . Dan jika ada proses yang berjalan untuk Anda dan proses yang berjalan untuk orang lain, maka bahkan menggunakan exploit berbahaya, Anda tidak akan bisa mendapatkan informasi orang lain.
Sekarang mari kita lihat apakah OKWS benar-benar berhasil meningkatkan keamanan dalam model server seperti itu. Untuk mengevaluasi keamanan, Anda perlu mempertimbangkan setiap komponen sistem dan menentukan jenis serangan apa yang dapat merusaknya.

Mari kita mulai dengan okd . Itu dapat diserang dengan permintaan melalui browser, misalnya, menyebabkan buffer overflow. c++, , - , okd . ?



: ?

: , , . ?

: , .

: , . , , , http , , , . , .

: ?

: , . , , , , , match.com . , , OkCupid . , - ? ?

: , , okd . , ?

: . , okd .

: , ?

: ! , , , , , . , , , , . , , . «» okd , , , .

: DOS-?

: , , , «» «» , DOS- - .

: okd , , …

: , . , , okd , okd , . okd , . , okd , , , , .

: .

: , . , okd . , oklogd ? ?

: .

: , , , ? pubd , , , - .

: , , «» oklogd .

: , . , , append-only , .

: , …

: , , . .

svc ? , , . , , okd oklogd . , , .

svc - -, , , . , , , .

okld ? , root. ? , . dbproxy . okld ? «»? ?

: , - ?

: , . , , . , , - , , , - . - . root- .

: -, , - dbproxy .

: !

: , , , RPC , , , , , ! .



: , . dbproxy ? , . , «» , dbproxy - .

: , svc …

: , svc , !

: , , !

: , , «» , …

: dbproxy .

: . , dbproxy , .

, , . , . , . , , , , .


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?