Hai, habrozhiteli! Aplikasi yang berjalan di cloud memiliki banyak keuntungan, tetapi pada saat yang sama tunduk pada ancaman khusus. Tugas tim DevOps adalah untuk mengevaluasi risiko-risiko ini dan memperkuat perlindungan sistem terhadapnya. Buku ini didasarkan pada pengalaman unik penulis dan menawarkan solusi strategis paling penting untuk melindungi aplikasi web dari serangan, untuk mencegah upaya invasi. Anda akan melihat bagaimana memastikan keandalan dengan pengujian otomatis, pengiriman berkelanjutan dan proses DevOps utama. Belajarlah untuk mengidentifikasi, mengevaluasi, dan memperbaiki kerentanan yang ada di aplikasi Anda. Penulis akan membantu Anda menavigasi dalam konfigurasi cloud, serta menerapkan alat otomatisasi populer. Membutuhkan pengetahuan dan pengetahuan Linux tentang praktik standar DevOps seperti CI, CD, dan pengujian unit.
Kutipan. Bab 8. Analisis Log untuk Intrusion dan Deteksi Serangan
Dalam bab ini:
- Menjelajahi komponen tingkat analisis dalam pipa logging.
- Mendeteksi intrusi dan serangan menggunakan tanda tangan string, statistik, dan data historis.
- Mengelola cara untuk memberi tahu pengguna secara optimal.
Di Bab 7, Anda belajar cara membuat pipa logging yang mengumpulkan, mentransfer, menganalisis, dan menyimpan log dari seluruh infrastruktur, dan juga menyediakan akses ke sana. Pipa multi-level menciptakan infrastruktur yang fleksibel di mana log dari berbagai sumber digunakan untuk memantau aktivitas layanan organisasi. Bab 7 memberikan gambaran umum tentang fungsionalitas yang disediakan oleh semua tingkatan pipa. Dalam bab ini, kita akan fokus pada tingkat ketiga - tingkat analisis - dan menyelami teknik dan contoh kode yang terkait dengan mendeteksi intrusi dan serangan terhadap layanan.
Pipeline logging yang digunakan oleh Mozilla saat menulis buku ini mirip dengan yang ditunjukkan pada bab 7. Pipeline digunakan untuk memantau keadaan klien Firefox (disebut
telemetri ) di lingkungan alami, proses aplikasi dan log layanan, dan mendeteksi aktivitas yang tidak biasa. Pusat logis dari pipa adalah pada tingkat analisis, terdiri dari banyak program kecil yang terus-menerus mencari sesuatu yang tidak biasa. Program kecil ini tidak terlalu canggih untuk menangani input dan output peristiwa log, sehingga mereka mentransfer tugas ini ke pusat data khusus - program Hindsight (http://mng.bz/m4gg), yang dirancang untuk melakukan pekerjaan menganalisis plug-in pada aliran data .
Dalam bab ini, kita akan menggunakan Hindsight untuk membaca berbagai jenis majalah dan menulis plugin asli untuk menganalisisnya.
CATATAN
Log sampel dan plugin untuk bab ini terdapat di mengamankan-devops.com/ch08/logging-pipeline . Anda perlu menyalin repositori ini ke mesin lokal Anda dan mendapatkan wadah Hindsight Docker untuk menjalankan contoh.
Mari kita mulai dengan menjelaskan bagaimana berbagai bagian tingkat analisis diatur: Hindsight terletak di tengah, dan tingkat pengumpulan dan penyimpanan berada di kedua sisi. Kemudian kita akan berbicara tentang tiga pendekatan berbeda untuk mendeteksi intrusi dan serangan. Untuk yang paling sederhana, tanda tangan string digunakan yang berisi informasi tentang serangan yang diketahui untuk mengirim pemberitahuan. Selanjutnya, kami membandingkan model statistik dan pendekatan dengan tanda tangan, dan juga belajar bagaimana kedua pendekatan ini saling melengkapi. Akhirnya, mari kita lihat cara-cara untuk menerapkan data aktivitas pengguna historis untuk mengidentifikasi area yang mencurigakan di antara koneksi.
Bagian terakhir bab ini adalah tentang mengirim pemberitahuan. Tidak mungkin Anda ingin menerima ribuan pemberitahuan dari tingkat analisis setiap hari, yang akan menimbulkan banyak kebisingan, alih-alih berguna. Jika ini tidak diubah, penerima akan menganggap pemberitahuan sebagai spam dan akan mengabaikannya. Di bagian akhir bab ini, kami akan mempertimbangkan praktik terbaik untuk mengatur pengiriman pemberitahuan, serta mendiskusikan cara mengirim pemberitahuan secara akurat dan efisien kepada administrator dan pengguna akhir.
8.2. Mendeteksi serangan menggunakan tanda tangan string
Saat Anda bekerja dengan log, Anda bekerja dengan string. Dan ini berarti bahwa cara termudah untuk mengidentifikasi tanda-tanda penipuan adalah membandingkan log dengan daftar garis berbahaya yang diketahui. Ini mungkin tampak sederhana, tetapi justru pada tahun-tahun inilah industri keamanan terlibat. Firewall aplikasi web (WAF), yang begitu populer pada pertengahan 2000-an, pada dasarnya adalah gudang ekspresi reguler, yang diperiksa terhadap setiap permintaan yang dikirim ke aplikasi web.
Jangan mengandalkan ekspresi reguler
Saya pernah bekerja di bank tempat jenis perlindungan ini banyak digunakan. Tim keamanan bertanggung jawab untuk mendukung WAF, yang melindungi berbagai layanan online, termasuk layanan perdagangan untuk pelanggan. Setiap permintaan web yang dikirim ke layanan ini melewati ratusan ekspresi reguler sebelum sampai ke server aplikasi. Suatu ketika seorang pengembang dari tim layanan perdagangan online memutuskan untuk melihat ekspresi reguler ini. Saya tidak tahu apa yang mendorong insinyur untuk mulai membaca konten file, yang terutama diisi dengan garis miring, simbol dolar, tanda bintang, plus, kotak dan tanda kurung, tetapi ia mengambilnya. Dan di suatu tempat di baris ke-418 dalam ekspresi reguler yang kompleks, ia menemukan kombinasi yang mencurigakan dari ". +". Dua karakter yang tidak bersalah yang benar-benar membiarkan semuanya berjalan tanpa rasa sakit: ekspresi reguler ini mirip dengan nilai "biarkan semuanya".
Kebanggaan kami adalah firewall aplikasi web untuk beberapa ribu euro, didukung oleh seluruh tim, melakukan ratusan pemeriksaan ekspresi reguler, yang memengaruhi kinerja dan menyulitkan desain sistem yang sudah rumit, dan semuanya untuk melewati segala sesuatu tanpa halangan. Tentu saja, kami segera memperbaiki masalahnya, tetapi keyakinan saya pada penggunaan ekspresi reguler untuk memastikan keamanan tidak meningkat sejak saat itu. Jika Anda ingin menerapkan sistem perlindungan jenis ini di organisasi Anda, perhitungkan kerumitannya sehingga hal ini tidak terjadi pada Anda.
Ketika digunakan dengan benar, ekspresi reguler dapat menjadi alat yang ampuh, tetapi mereka sangat sulit untuk ditulis, dipelihara dari waktu ke waktu - bahkan lebih sulit, dan implementasi skala besar mereka mahal. Lihatlah ekspresi reguler ((\% 3C) | <) ((\% 2F) | \ /) * [a-z0-9 \%] + ((\% 3E) |>). Anda tidak akan menebak untuk apa digunakan, jadi saya akan memberi tahu Anda: itu dapat digunakan untuk mencari suntikan dalam string permintaan HTTP, mengungkapkan keberadaan membuka dan menutup <> karakter ketidaksetaraan dan isinya. Anda akan menerima jenis garis permintaan HTTP ini dari penyerang yang mencoba menyuntikkan kode JavaScript berbahaya ke aplikasi Anda untuk berakhir dengan serangan skrip lintas situs, yang kami bahas pada Bab 3.
Ekspresi reguler ini dapat digunakan untuk mengidentifikasi permintaan mencurigakan yang berisi upaya injeksi. Listing 8.7 memperlihatkan contoh parser yang mengimplementasikan ini dengan memeriksa kecocokan ekspresi reguler di setiap log akses NGINX yang ditransmisikan. Ekspresi reguler disimpan dalam variabel xss lokal, nilainya dibandingkan dengan setiap nilai Bidang [permintaan] menggunakan fungsi rex.match ().
Jika ada kecocokan, maka fungsi add_to_payload () mengirimkan pemberitahuan bahwa plug-in keluaran dapat menerima dan mengirimkan ke tujuan.
Listing 8.7. Plugin yang mendeteksi pesan log yang berisi tanda-tanda serangan di string kueri
Contoh output dari plugin ini ditunjukkan pada Listing 8.8. Ada beberapa pemberitahuan yang dihasilkan oleh majalah sampel, beberapa di antaranya ternyata salah positif. Ini terjadi sebagian karena log sampel dibuat secara buatan menggunakan ZAP Vulnerability Scanner, dan juga karena string kueri cenderung tidak berisi tag HTML. Secara khusus, ungkapan reguler ini tidak akan memiliki tingkat yang terlalu tinggi untuk menemukan kecocokan positif palsu.
Listing 8.8. Contoh pemberitahuan yang dihasilkan oleh plugin analisis XSS
Ini hanya satu ekspresi reguler untuk satu jenis serangan spesifik. Agar pendekatan ini bermanfaat, Anda perlu menemukan sesuatu yang lebih dari ekspresi reguler. Sebagai permulaan, Anda bisa mengumpulkan tanda tangan dari berbagai sumber dan, karena semakin banyak tanda mencurigakan ditemukan dalam log, secara bertahap menambah ukuran database Anda.
Listing 8.9 menunjukkan versi modifikasi dari analisa XSS yang mencari berbagai tanda serangan (http://mng.bz/62h8). Script ini menunjukkan bagaimana Anda dapat menggunakan tabel Lua untuk menyimpan daftar atribut dan menggunakannya secara siklis untuk menganalisis peristiwa yang masuk. Dalam contoh kode ini, tabel suspicious_terms adalah deretan sederhana baris yang menggunakan substring untuk mencari ekspresi reguler, yang jauh lebih cepat. Tabel suspicious_terms menggunakan format nilai kunci untuk menyimpan label bersama dengan ekspresi agar dapat mengingatkan Anda bahwa ekspresi itu harus ditemukan.
Listing 8.9. Cari tanda-tanda serangan menggunakan string dan ekspresi
Anda dapat menjalankan analisis ini menggunakan pengaturan tes yang dijelaskan di awal bab ini. Luncurkan wadah Docker dengan direktori yang dipasang dan output analyzer akan ditulis ke output / payload / analysis.suspicious_signatures.alerts.txt. Plugin akan mengirim ribuan pemberitahuan, yang diharapkan, karena log ini dihasilkan oleh pemindai kerentanan ZAP. Pendekatan ini dapat dianggap berhasil, tetapi memiliki kelemahan yang harus Anda pertimbangkan.
- Ekspresi reguler sulit untuk ditulis, dan bahkan lebih sulit untuk dibaca . Anda akan membuat kesalahan yang tidak mudah diselidiki dan membutuhkan berjam-jam debug yang menyakitkan. Hanya ada empat ekspresi reguler dalam analisis ini, tetapi membaca bagian kode ini sudah sulit. Tidak peduli seberapa kuat dan menariknya alat ini bisa menjadi ekspresi reguler, saya tidak akan merekomendasikan bekerja dengannya secara konstan.
- Dengan pendekatan ini, terlalu banyak pemberitahuan yang dihasilkan . Aplikasi web yang terbuka ke Internet menerima banyak lalu lintas yang tidak biasa, berbahaya dan tidak banyak. Membuat pemberitahuan untuk setiap tanda yang tidak biasa akan membuat tim keamanan gila selama beberapa minggu, bahkan jika tingkat positif palsu rendah. Lalu lintas abnormal adalah kejadian alami untuk layanan yang berjalan di Internet.
Anda bisa memperbaiki kedua masalah ini dengan menerapkan pendekatan matematika dan membuat sistem yang sempurna ini untuk mendeteksi anomali sedikit kurang sempurna. Pada bagian selanjutnya, kita akan melihat bagaimana menggunakan metode statistik untuk mengirim pemberitahuan ketika ambang batas diatasi sebagai cara untuk mengurangi noise dari logika deteksi anomali.
Tentang penulis
Pada saat penulisan,
Julien Vehen mengelola tim keamanan operasi di Firefox, Mozilla. Dia bertanggung jawab untuk membuat, menerapkan, dan mengoperasikan strategi keamanan layanan web yang berinteraksi dengan jutaan pengguna Firefox setiap hari. Julien fokus melindungi layanan jaringan di awal 2000-an. Dia mulai bekerja sebagai administrator sistem di Linux, dan pada 2007 menerima gelar master dalam keamanan informasi.
»Informasi lebih lanjut tentang buku ini dapat ditemukan di
situs web penerbit»
Isi»
KutipanKupon diskon 25% untuk
penjaja -
DevOpsSetelah pembayaran versi kertas buku, sebuah buku elektronik dikirim melalui email.