Kasus untuk Menggunakan Alat Analisis Anomali Jaringan: Deteksi Kebocoran

Pada salah satu acara, diskusi menarik terjadi pada kegunaan dari solusi NTA (Network Traffic Analysis), yang, dengan menggunakan infrastruktur jaringan telemetri Netflow (atau protokol aliran lainnya), memungkinkan untuk mendeteksi berbagai serangan. Lawan saya berpendapat bahwa ketika menganalisis header dan informasi terkait (dan NTA tidak menganalisis isi data paket, tidak seperti sistem deteksi serangan klasik, IDS), Anda tidak dapat melihat banyak. Dalam artikel ini saya akan mencoba untuk menyangkal pendapat ini dan membuat percakapan lebih substantif, saya akan memberikan beberapa contoh nyata ketika NTA benar-benar membantu mengidentifikasi berbagai anomali dan ancaman yang hilang pada perimeter atau bahkan melewati perimeter. Dan saya akan mulai dengan ancaman yang datang pertama di peringkat ancaman tahun lalu dan, saya pikir, akan tetap demikian tahun ini.Ini akan mengenai kebocoran informasi dan kemampuan untuk mendeteksi mereka melalui telemetri jaringan.

Saya tidak akan mempertimbangkan situasi ini dengan tangan-tangan admin yang bengkok yang meninggalkan Internet tanpa terlihat Elastis atau MongoDB. Mari kita bicara tentang tindakan penyerang yang ditargetkan, seperti halnya dengan kisah biro kredit Equifax yang terkenal. Biarkan saya mengingatkan Anda bahwa dalam kasus ini, para penyerang pertama-tama menembus celah keamanan yang tidak tertandingi ke portal Web publik, dan kemudian ke server basis data internal. Tersisa tanpa diketahui selama beberapa bulan, mereka mampu mencuri data pada 146 juta klien biro kredit. Bisakah insiden seperti itu diidentifikasi menggunakan solusi DLP? Kemungkinan besar tidak, karena DLP klasik tidak dirancang untuk tugas memonitor lalu lintas dari database menggunakan protokol tertentu, dan bahkan di bawah kondisi bahwa lalu lintas ini dienkripsi.Tetapi solusi dari kelas NTA dapat dengan mudah mendeteksi kebocoran tersebut dengan melebihi nilai ambang tertentu dari jumlah informasi yang diunduh dari database. Selanjutnya, saya akan menunjukkan bagaimana ini semua dikonfigurasi dan ditemukan menggunakan solusi Cisco Stealthwatch Enterprise.

Jadi, hal pertama yang perlu kita lakukan adalah memahami di mana server basis data kita berada di jaringan, menentukan alamatnya dan mengelompokkannya. Di Cisco Stealthwatch, tugas inventaris dapat dilakukan secara manual atau menggunakan classifier khusus yang menganalisis lalu lintas dan, sesuai dengan protokol yang digunakan dan perilaku node, memungkinkan Anda untuk menghubungkannya ke satu atau kategori lain.



Setelah kami memiliki informasi tentang semua server basis data, kami memulai penyelidikan untuk mengetahui apakah kami membocorkan data dalam jumlah besar dari kelompok node yang diinginkan. Kami melihat bahwa dalam kasus kami, basis data paling aktif berkomunikasi dengan server DHCP dan pengontrol domain.



Penyerang sering membangun kontrol atas node jaringan dan menggunakannya sebagai jembatan untuk mengembangkan serangan mereka. Pada tingkat lalu lintas jaringan, ini terlihat seperti anomali - pemindaian jaringan dari node ini menjadi lebih sering, data ditangkap dari berbagi file, atau interaksi dengan server mana pun. Oleh karena itu, tugas kita selanjutnya adalah untuk memahami dengan siapa sebenarnya basis data kita paling sering berkomunikasi.



Dalam kelompok server DHCP, ternyata ini adalah node dengan alamat 10.201.0.15, interaksi dengan yang menyumbang sekitar 50% dari semua lalu lintas dari server database.



Pertanyaan logis berikutnya yang kami tanyakan pada diri kami sebagai bagian dari penyelidikan adalah: “Dan seperti apa simpul ini pada 10.201.0.15? Dengan siapa dia berinteraksi? Seberapa sering? Protokol apa? "



Ternyata simpul yang menarik bagi kami berkomunikasi dengan berbagai segmen dan simpul jaringan kami (yang tidak mengejutkan, karena ini adalah server DHCP), tetapi pertanyaannya menyebabkan terlalu banyak interaksi dengan server terminal dengan alamat 10.201.0.23. Apakah ini normal? Jelas ada semacam anomali. Server DHCP tidak dapat berkomunikasi secara aktif dengan server terminal - 5610 stream dan 23,5 GB data.



Dan interaksi ini dilakukan melalui NFS.



Kami mengambil langkah berikutnya dan mencoba memahami dengan siapa server terminal kami berinteraksi? Ternyata ia memiliki komunikasi yang cukup aktif dengan dunia luar - dengan simpul-simpul di AS, Inggris Raya, Kanada, Denmark, UEA, Qatar, Swiss, dll.



Kecurigaan disebabkan oleh fakta interaksi P2P dengan Puerto Rico, yang merupakan 90% dari semua lalu lintas. Selain itu, server terminal kami mengirimkan lebih dari 17 GB data ke Puerto Riko melalui port 53, yang terhubung dengan protokol DNS. Dapatkah Anda bayangkan bahwa Anda memiliki volume data yang dikirimkan melalui DNS? Dan saya mengingatkan Anda bahwa menurut penelitian Cisco, 92% malware menggunakan DNS untuk menyembunyikan aktivitasnya (mengunduh pembaruan, menerima perintah, mengeluarkan data).



Dan jika protokol DNS ITU tidak hanya terbuka, tetapi tidak diperiksa, maka kami memiliki lubang besar di perimeter kami.



Segera setelah simpul 10.201.0.23 membuat kami curiga, mari kita lihat dengan siapa dia masih berbicara?



"Tersangka" kami menukar setengah dari semua lalu lintas dengan simpul 10.201.3.18, yang ditempatkan dalam sekelompok workstation karyawan dari bagian penjualan dan pemasaran. Seberapa khas ini bagi organisasi kami untuk server terminal untuk "berkomunikasi" dengan komputer penjual atau pemasar?



Jadi, kami melakukan penyelidikan dan menemukan gambar berikut. Data dari server database "dituangkan" ke server DHCP dengan transfer mereka selanjutnya melalui NFS ke server terminal di dalam jaringan kami, dan kemudian ke alamat eksternal di Puerto Rico menggunakan protokol DNS. Ini jelas merupakan pelanggaran terhadap kebijakan keamanan. Pada saat yang sama, server terminal juga berinteraksi dengan salah satu workstation dalam jaringan. Apa yang menyebabkan kejadian ini? Akun yang dicuri? Perangkat yang terinfeksi? Kami tidak tahu. Ini akan memerlukan kelanjutan dari penyelidikan, yang didasarkan pada solusi kelas NTA, yang memungkinkan menganalisis anomali lalu lintas jaringan.



Dan sekarang kami tertarik pada apa yang akan kami lakukan dengan pelanggaran kebijakan keamanan yang teridentifikasi? Anda dapat melakukan analisis rutin sesuai dengan skema di atas, atau Anda dapat mengonfigurasi kebijakan NTA sehingga segera memberi sinyal ketika pelanggaran serupa terdeteksi. Ini dilakukan baik melalui menu umum yang sesuai, atau untuk setiap koneksi yang terdeteksi selama penyelidikan.



Inilah yang akan terlihat seperti aturan deteksi interaksi, sumbernya adalah server database, dan tujuannya adalah setiap node eksternal, serta setiap internal, tidak termasuk server Web.



Jika kejadian seperti itu terdeteksi, sistem analisis lalu lintas jaringan segera menghasilkan alarm korespondensi dan, tergantung pada pengaturan, mengirimkannya ke SIEM, menggunakan alat komunikasi dengan administrator, atau bahkan dapat secara otomatis memblokir pelanggaran yang terdeteksi (Cisco Stealthwatch melakukan ini dengan berinteraksi dengan Cisco ISE )



Ingatlah bahwa ketika saya menyebutkan kasus dengan Equifax, saya menyebutkan bahwa para penyerang menggunakan saluran terenkripsi untuk membuang data. Untuk DLP, lalu lintas ini menjadi tugas yang tidak larut, tetapi untuk solusi kelas NTA, mereka tidak - mereka melacak kelebihan lalu lintas atau interaksi yang tidak sah antara node, terlepas dari penggunaan enkripsi.



Hanya satu kasus yang ditunjukkan di atas (dalam materi berikut kami akan mempertimbangkan contoh lain menggunakan NTA untuk tujuan keamanan informasi), tetapi pada kenyataannya, solusi modern dari kelas Analisis Lalu Lintas Jaringan memungkinkan Anda untuk membuat aturan yang sangat fleksibel dan mempertimbangkan tidak hanya parameter dasar header paket IP:



tetapi juga melakukan analisis yang lebih dalam, hingga mengaitkan kejadian tersebut dengan nama pengguna dari Active Directory, mencari file berbahaya dengan hash (misalnya, diperoleh sebagai indikator kompromi dari SOSOPKA, FinCERT, Cisco Threat Grid, dll.), dll.



Mudah diimplementasikan. Sebagai contoh, ini adalah bagaimana aturan yang biasa terlihat untuk mendeteksi semua jenis interaksi antara server database dan node eksternal menggunakan protokol apa pun selama 30 hari terakhir. Kami melihat bahwa basis data kami “dikomunikasikan” dengan node eksternal ke segmen DBMS menggunakan protokol DNS, SMB, dan port 8088.



Selain bentuk tabel untuk menyajikan hasil investigasi atau pencarian, kami juga dapat memvisualisasikannya. Untuk skenario kami, sebuah fragmen dari diagram alur jaringan mungkin terlihat seperti ini:



Dan langsung dari peta yang sama kita dapat mengelola kebijakan - memblokir koneksi atau mengotomatiskan proses pembuatan aturan pemantauan untuk aliran yang menarik bagi kita.



Berikut ini adalah contoh yang cukup menarik dan hidup menggunakan alat pemantauan Netflow (dan protokol aliran lainnya) untuk keamanan siber. Dalam catatan berikut, saya berencana untuk menunjukkan bagaimana Anda dapat menggunakan NTA untuk mendeteksi kode berbahaya (menggunakan contoh Shamoon), server jahat (menggunakan kampanye DNSpionage sebagai contoh), program akses jarak jauh (RAT), melewati proxy perusahaan, dll.

Source: https://habr.com/ru/post/undefined/