"Tapi itu tidak membosankan!" - ini adalah moto informal dari karyawan pusat pemantauan ancaman cyber Solar JSOC kami (dan saya harus mengatakan bahwa 2019 sepenuhnya sesuai dengan itu). Pada awal tahun baru, banyak orang suka mengambil stok dan menetapkan tujuan baru, tetapi sebaliknya kami memutuskan untuk menceritakan beberapa "kengerian kota kami" - kasus 2019, yang bahkan mengesankan analis berpengalaman. Kesimpulan dari kisah-kisah ini hanya satu: teknologi berkembang dan berkembang, dan kemalasan manusia, kelalaian dan kecerobohan adalah abadi.
Wifi tamu
Saat menghubungkan pelanggan ke pemantauan, pertama-tama kami meminta informasi paling penting: akun kritis, grup domain, segmen tidak dipercaya, alamat putih, DMZ, subnet kritis, dll. Subnet yang tidak tepercaya hanyalah Wi-Fi tamu, serta jaringan kontraktor, menguji segmen dengan izin untuk mengizinkan apa pun, dll. ... Biasanya kita melihat bahwa kemungkinan interaksi dengan segmen tersebut tidak ada atau sangat terbatas, karena mengendalikannya sangat sulit, jika bukan tidak mungkin. Di jaringan pelanggan, tidak ada kemungkinan interaksi seperti itu, kecuali untuk halaman otorisasi di jaringan tamu. Kami tenang dengan menambahkan larangan berinteraksi dari Wi-Fi dengan TOR, server C&C, dan roh jahat lainnya, sehingga kami tidak akan dibombardir dengan operasi yang tidak menarik bagi pelanggan potensial (meskipun kami mengumpulkan statistik tentang insiden ini untuk laporan ringkasan). Dan pada pagi ketiga dari proyek percontohan, kami melihat anomali: aliran peristiwa dari firewall meningkat 4 kali lipat!
Mereka mulai mencari penyebab "penyumbatan" dan, dengan terkejut, menemukannya di segmen Wi-Fi tamu. Tuan rumah tertentu menghasilkan 4 juta (!) Acara per jam. Dan kejadiannya cukup menarik - koneksi pada port 445 ke alamat putih acak ruang Internet. Empat juta, Karl!
Setelah memberi tahu pelanggan tentang hal ini, mereka mulai menunggu informasi tentang tuan rumah dan kejadian itu, karena DHCP (itu adalah server otorisasi) tidak terhubung ke SIEM. Setelah sekitar 3-4 jam, pelanggan melaporkan bahwa tuan rumah adalah ponsel. Mengatakan bahwa kami terkejut sama dengan tidak mengatakan apa-apa. Ponsel biasa tidak dapat menghasilkan aliran peristiwa seperti itu. Mereka mulai mencari tahu perinciannya, dan ternyata ponsel itu tidak ada hubungannya dengan itu - seseorang hanya menggunakan salah satu perangkat yang terdaftar sebagai penutup. Tidak mungkin menemukan sumber aktivitas yang sebenarnya, dan klien kami mengatakan bahwa dia tidak tertarik dengan kasus ini, jadi aktivitas tersebut harus diminimalkan. Namun demikian, kami memperingatkan spesialis pelanggan tentang risiko yang mungkin terjadi: karena aktivitas (jelas-jelas berbahaya) berasal dari alamat mereka, mereka dapat, misalnya, masuk ke daftar C & C-server dari vendor anti-virus dan menerima keluhan dari lembaga penegak hukum (siapa yang tahu infrastruktur apa yang host ini akan pindai) - setelah semua, mungkin ada KII, dan pemindaian untuk kerentanan mengacu pada insiden yang perlu dilaporkan ke GosSOPKA). Setelah argumen seperti itu, pelanggan masih memutuskan untuk memahami lebih detail dan memenuhi rekomendasi kami. Dan mereka adalah sebagai berikut:
- tutup semua port kecuali 80 dan 443 (ini ternyata menjadi keputusan yang tepat, karena setelah 445 pemindaian pada port 22 diikuti),
- kami memperkenalkan batasan pada kecepatan Internet yang dibagikan,
- aktifkan chip UTM, termasuk kontrol aplikasi, dan potong kategori aneh seperti torrents, browser TOR, pemindai yang terdeteksi, dan banyak lagi,
- nyalakan batas jumlah koneksi per interval waktu.
Pelanggan tidak pernah bisa mengetahui siapa pengguna Wi-Fi aktif ini, tetapi setidaknya mereka memblokirnya dengan oksigen (dan, kemungkinan besar, penyerang pergi mencari Wi-Fi berikutnya yang tersedia.
Beberapa bulan kemudian pilot ini berhasil ditutup dan dipindahkan ke kontrak, tetapi kami masih menemukan kasus serupa di perusahaan yang sama sekali berbeda, sehingga rekomendasi di atas dapat diklasifikasikan sebagai universal.
Secara default, atau sabotase vendor
Sejalan dengan koneksi percontohan ke pemantauan Solar JSOC, pelanggan menugaskan UTM baru. Migrasi ke sana bertahap: pertama-tama mentransfer ACL melalui subnet, lalu kebijakan aplikasi. Makanan penutup adalah yang paling menarik.
Semuanya terjadi sesuai dengan klasik - pada Jumat malam. Baris pertama mencatat kecelakaan dalam menghubungi infrastruktur pelanggan untuk node TOR, muncul sebagai C&C di salah satu milis FinCERT. Karena proyek ini adalah pilot dan pelanggan memindahkan semua insiden ke Low-criticality, tidak ada kartu insiden yang disediakan, selain notifikasi melalui surat, kartu insiden. Oleh karena itu, operasi pertama dari host yang berbeda ke satu alamat, meskipun menimbulkan kecurigaan di antara para insinyur pemantauan, tidak meningkat lebih lanjut. Ketika jumlah perjalanan mencapai tiga, orang-orang itu merasakan ada sesuatu yang salah dan memberi tahu analis yang membawa insiden itu untuk bekerja.
Pertama, analis menghubungi karyawan yang bertanggung jawab dari pelanggan dan menyarankan menghubungkan host di tingkat log lokal untuk mengidentifikasi sumber kegiatan. Pada saat berdiskusi dengan spesialis pelanggan, jumlah host telah bertambah menjadi 7. Situasinya sangat mirip dengan epidemi, tetapi antivirus pada host bekerja dan diam, tidak ada tindakan aktif dan interaksi host pada jaringan.
Menghubungkan tiga host di tingkat log lokal juga tidak memberikan pemahaman tentang proses yang menghasilkan aktivitas. Kegelisahan tumbuh, satu-satunya pilihan yang bekerja adalah isolasi host dengan penghapusan paralel dari dump RAM dan citra hard disk. Analis mulai menyiapkan instruksi dan pada saat yang sama memutuskan untuk mencari di Google IP yang diakses oleh tuan rumah untuk ketersediaan dalam pengiriman dan insiden lain (karena jenis kegiatan yang kami amati berbeda dari yang dijelaskan dalam buletin FinCERT). Sebagian besar, idenya cukup menyedihkan, tetapi kali ini tidak.
Perhatian tertuju pada artikel dengan judul alamat IP dan nama vendor UTM terdaftar. Untuk meringkas inti dari publikasi, vendor membeli alamat IP yang sebelumnya milik TOR-node, yang ditampilkan pada buletin FinCERT. Dan ini bukan hanya semuanya! Selanjutnya, vendor memutuskan untuk menjadikan alamat ini sebagai default untuk mengalihkan semua panggilan yang mencurigakan dari infrastruktur kliennya ke alamat yang berpotensi berbahaya. Artinya, setiap koneksi dengan alamat IP aneh ditafsirkan oleh UTM sebagai tidak sah dan dialihkan ke alamat ajaib ini.
Setelah menentukan apakah modul perlindungan anti-malware sudah aktif, dan setelah menerima konfirmasi, analis dan spesialis pelanggan mengembuskan napas.
Analisis PS dari kegagalan yang terdeteksi UTM mengkonfirmasi bahwa semua 7 kegiatan adalah False Positive.
Kami menjanjikan rekomendasi untuk setiap kasus, tetapi di sini, mungkin, kami hanya akan memberikan satu: jangan digunakan pada hari Jumat. Dan peringatkan semua yang tertarik dan simpatisan.
Secara historis
Leitmotif ini menyatukan berbagai macam kasus. Ambil penonaktifan misalnya. Seringkali proses yang kehilangan relevansi dalam perusahaan dilupakan begitu saja: tidak ada yang "mem-parsing" infrastruktur lama, meninggalkan mesin virtual lama, server dan akses jaringan. Pada saat yang sama, tidak ada yang memantau pembaruan, antivirus, dan peristiwa pada host ini, dan bahkan admin sering tidak mengetahui pemilik sistem. Oleh karena itu, setelah beberapa saat elemen-elemen infrastruktur semacam itu tidak menghadirkan kejutan yang paling menyenangkan. Berapa biayanya hanya untuk mengirim telemetri yang signifikan dari organisasi lingkungan pada proyek yang diselesaikan pada 2005 ke server FTP negara yang tidak ramah!
Seringkali tidak ada yang berurusan dengan pemeliharaan sistem berusia 10 tahun, meskipun mereka terus digunakan. Sebagai contoh, portal pengaturan ulang kata sandi yang menggunakan mesin kuno dan untuk kenyamanan pengguna melihat Internet, atau RDP, yang harus dikonfigurasikan oleh kontraktor untuk aplikasi bisnis dan bertahan selama 5-6 tahun.
Adanya masalah seperti itu biasanya diketahui ketika:
- tuan rumahnya diretas, dan enkripsi terjadi dengan pemerasan lebih lanjut (ada banyak insiden seperti belakangan ini),
- ada migrasi dari satu solusi pada perimeter ke yang lain,
- kami datang ke pilot dan mengumpulkan profil port terbuka di perimeter.
Tetapi ada juga situasi yang sepenuhnya mistis: pada 2013, perusahaan membangun terowongan dengan kontraktor yang melayani sistem keuangannya. Kontrak berakhir, tetapi terowongan tetap, karena dibuat oleh perusahaan dari mana kontraktor menyewa tempat bersama dengan infrastruktur TI. Perusahaan baru mengambil tempat yang sama dan terkejut menemukan alamat infrastruktur orang lain yang tersedia. Keingintahuan mengambil alih, dan kemudian godaan dan haus akan keuntungan. Mereka membuang database rekanan dan kontrak ke kebisingan - manfaat dari kompetisi itu menarik, tetapi tidak ada yang membuat kebisingan di perusahaan korban. Kisah ini berlangsung lebih dari setahun (tidak mungkin untuk menelusuri lebih jauh sepanjang log), tetapi pada akhirnya, penyelidikan, pemecatan dan ceri pada kue adalah kasus kriminal.
AWOL, atau Karena lebih nyaman
Kasus ini secara keseluruhan agak sepele, yang tidak bisa dikatakan tentang "metodologi implementasi".
Diberikan:
- proyek percontohan pemantauan pelanggan;
- sumber terhubung pada perimeter, serta antara segmen perusahaan dan teknologi;
- admin bertugas di tempat kerja dan melayani segmen jaringan tertutup;
- keinginan akut administrator adalah untuk bekerja lebih sedikit, tidur lebih banyak dan melakukan segalanya dengan nyaman.
Seperti yang sudah saya katakan, ketika menghubungkan, kami meminta pelanggan untuk berbagai informasi, termasuk alamat putih, untuk mengumpulkan statistik tentang koneksi ke mereka dari Internet dan dengan demikian membentuk profil perimeter eksternal. Setelah membuat aturan yang mengisi daftar di SIEM, dalam sekitar satu atau dua minggu kami mengumpulkan statistik tentang semua port terbuka pada perimeter, menurunkannya ke pelanggan, menonton dan memperbaiki bersama (sambil menutup apa yang tidak sah). Mengumpulkan informasi untuk profil, kami secara berkala menelusuri daftar, memverifikasi bahwa port terbuka untuk semua atau hanya beberapa alamat pada daftar putih. Perhatian tertuju pada port 43388, yang tampaknya biasa-biasa saja, tetapi disiarkan pada 3389 dan alamat abu-abu, yang pemiliknya tidak diketahui oleh kami saat itu.
Ketika memeriksa ternyata ditutup untuk alamat kami. Kami mengira ia terbuka dalam daftar putih, tetapi pada siang hari kami tidak melihat ada koneksi yang berhasil dengannya. Sesampainya di pagi berikutnya, mereka kembali memperhatikan bahwa satu paket acara telah tiba dalam semalam. Kali ini kami melihat lebih dekat pada alamat sumber dan melihat beberapa sesi dari Moskow dengan total durasi lebih dari 5 jam dan sejumlah besar sesi pendek dari seluruh dunia. Kemudian menjadi jelas bahwa intinya bukan bahwa port hanya dapat diakses ke alamat dari daftar putih, tetapi bahwa port hanya dibuka pada malam hari - dari sekitar pukul 00.00 hingga 06.00 pagi. Setelah menggali log dari domain dan antivirus (mereka baru saja terhubung pada saat itu), kami terkejut menemukan bahwa alamat tersebut adalah milik administrator yang bertugas, yang seharusnya berada di tempat kerja selama interval waktu ini! Setelah menganalisis koneksi dari mobilnya, kami menemukan situasi menarik lainnya: setiap malam, port juga dibuka (saya pikir tidak sulit menebak yang mana) di segmen khusus yang tertutup. Hampir tidak mungkin untuk melihat aktivitas seperti itu pada hari keempat pilot, pada saat itu jumlah koneksi yang diperbolehkan antar segmen masih lebih dari port terbuka pada perimeter. Setelah memberi tahu penjaga keamanan tentang situasi tersebut, mereka menghubungkan host di tingkat log lokal dan memastikan bahwa administrator diam-diam melarikan diri dari pekerjaan. Ternyata, dia tinggal hampir di rumah tetangga, dan koneksi yang jauh, tentu saja, menjadi terlalu banyak godaan.
Mungkin jika administrator menjelaskan situasinya, ia akan diizinkan untuk bekerja jarak jauh melalui SKDPU, asalkan pada saat kecelakaan ia akan dapat datang untuk bekerja dalam waktu 15 menit, dan tidak akan ada masalah sama sekali.
Total
Pada kenyataannya, salah satu ancaman utama terhadap keamanan informasi adalah mencungkil di tanah. Oleh karena itu, meminimalkan risiko:
- Melacak konfigurasi perimeter dan firewall.
- Cobalah untuk membuat remote di perusahaan yang dikelola (VPN melalui server terminal). Dan jika sudah ada, kontrol siapa yang menggunakannya (dengan menghapus berbagai RAT pada host yang sekarang dengan mudah mendeteksi hampir semua mesin anti-virus).
- Ikuti tindakan pengguna istimewa: sangat sering mereka kehilangan kewaspadaan mereka, percaya bahwa mereka memiliki segalanya di bawah kendali, dan membuatnya lebih mudah bagi penyerang untuk mengakses data penting.