Latar Belakang: Sebagai pemimpin impor dan ekspor dunia, Vandalay Industries telah menjadi sasaran banyak musuh yang mencoba mengganggu bisnis online mereka. Baru-baru ini, Vandaly mengalami serangan DDOS terhadap server web mereka.
Tidak hanya server web yang offline karena serangan DDOS, namun kecepatan unggah dan unduh juga terkena dampak signifikan setelah pemadaman. Tim jaringan Anda memberikan hasil kecepatan jaringan sekitar waktu serangan DDOS terbaru.
File Tes Kecepatan
Tangkapan layar file 'server_speedtest.csv' yang diunggah ke Splunk:
eval
, buat kolom bernama rasio yang menunjukkan rasio antara kecepatan unggah dan unduh. Petunjuk: Format untuk membuat rasio adalah: | eval new_field_name = 'fieldA' / 'fieldB'
Kueri yang digunakan di Splunk untuk menghasilkan rasio antara kecepatan unggah dan unduh - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS
Kita bisa melihat rasio download dan upload dari query ini.
_time
IP_ADDRESS
DOWNLOAD_MEGABITS
UPLOAD_MEGABITS
ratio
Petunjuk: Gunakan format berikut ketika untuk perintah tabel: | bidang tabelA bidangB bidangC
Kueri yang digunakan di Splunk untuk menghasilkan rasio antara kecepatan unggah dan unduh - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS | table _time, IP_ADDRESS, DOWNLOAD_MEGABITS, UPLOAD_MEGABITS, ratio
Dari tangkapan layar di atas, kita dapat melihat total timeline peristiwa kapan pengunduhan dan pengunggahan dilakukan.
Dari tangkapan layar di atas, kita dapat melihat waktu terjadinya pengunduhan dan pengunggahan serta alamat IP sumber yang melakukan tindakan ini.
Dari screenshot di atas, kita dapat melihat representasi visual dari event download dan upload tersebut dalam format grafik kolom. Waktu ditampilkan di bagian bawah dan ini membuat data kita lebih mudah dibaca.
Berdasarkan temuan kami pada kueri di atas, kami dapat melihat kecepatan unduh dan unggah turun drastis sekitar pukul 14.30 pada tanggal 23 Februari. Kita dapat melihatnya pada tangkapan layar di bawah ini:
Kita dapat melihat unduhan turun menjadi 7,87 pada pukul 14:30. Ini merupakan penurunan drastis dari 109,16 megabit pada peristiwa sebelumnya. Maka wajar untuk berasumsi bahwa ini adalah saat serangan dimulai.
Kita dapat melihat dari tangkapan layar di atas bahwa megabit unduhan meningkat dari 17,56 menjadi 65,34, yang merupakan peningkatan drastis. Oleh karena itu, dapat diasumsikan bahwa hal ini terjadi ketika sistem mulai pulih dan kembali ke arus lalu lintas jaringan normal.
Kita dapat melihat dari tangkapan layar di atas bahwa megabit yang diunduh melonjak menjadi 123,91 dari 78,34 sekitar pukul 23:30 pada tanggal 23 Februari. Dapat diasumsikan bahwa ini adalah waktu di mana arus lalu lintas jaringan telah stabil dan kembali normal.
Kirimkan tangkapan layar laporan Anda dan jawaban pertanyaan di atas.
Latar Belakang: Karena frekuensi serangan, manajer Anda perlu memastikan bahwa data sensitif pelanggan di server mereka tidak rentan. Karena Vandalay menggunakan pemindai kerentanan Nessus, Anda telah melakukan pemindaian 24 jam terakhir untuk melihat apakah ada kerentanan kritis.
Untuk informasi lebih lanjut tentang Nessus, baca tautan berikut: https://www.tenable.com/products/nessus
Hasil Pemindaian Nessus
Tangkapan layar hasil scan nessus yang diunggah ke Splunk:
10.11.36.23
. Gunakan dest_ip="10.11.36.23"
dalam kueri
Perlu diperhatikan bahwa ada 5 jenis tingkat keparahan yang dicari log ini, seperti yang ditunjukkan di bawah ini:
Kami ingin memfilter kerentanan apa pun yang tingkat keparahannya merupakan nilai 'kritis'. Kita dapat menggunakan severity="crtiical"
dalam kueri kita.
Seluruh kueri adalah source="nessus_logs.csv" dest_ip="10.11.36.23" severity="critical"
Lihat tangkapan layar di bawah untuk seluruh kueri yang menampilkan jumlah kerentanan kritis dari server database pelanggan dari file log ini:
Ada total 49 kerentanan kritis yang ditemukan ketika IP tujuan adalah 10.11.36.23 (yang merupakan server database).
[email protected]
.Buat lansiran dengan mengklik 'simpan sebagai' dan kemudian 'peringatan' setelah kami menghasilkan hasil dari kueri di atas:
Masukkan detail untuk menghasilkan peringatan setiap kali Nessus mendeteksi kerentanan pada server database. Masukkan nama, deskripsi, dan informasi relatif lainnya:
Masukkan detail email untuk mengirim peringatan yang dihasilkan ke - [email protected]
dan masukkan detail pesan untuk dikirim bersama email:
Lanjutkan memasukkan detail peringatan lalu klik 'simpan':
Setelah disimpan kita akan dapat melihat peringatan dan mengeditnya jika kita mau:
Kirimkan tangkapan layar laporan Anda dan tangkapan layar bukti bahwa pemberitahuan telah dibuat.
Latar Belakang: Server Vandalay juga mengalami serangan brute force ke akun administratornya. Manajemen ingin Anda mengatur pemantauan untuk memberi tahu tim SOC jika serangan brute force terjadi lagi.
Login Admin
Tangkapan layar file 'Administrator_logs.csv' yang diunggah ke Splunk:
Petunjuk:
Cari bidang nama untuk menemukan login yang gagal.
Perhatikan bahwa serangan itu berlangsung beberapa jam.
Karena kami ingin mencari indikator serangan brute force, kami ingin menelusuri log yang menyebabkan akun gagal masuk. Jika kita menavigasi ke bidang 'nama', kita dapat melihat nilai yang ada di log. Dalam hal ini, kita dapat melihat hitungan 1004 "Akun gagal masuk". Ini adalah indikator yang baik bahwa serangan brute force telah terjadi. Lihat tangkapan layar:
Sekarang jika kita menambahkan ini ke pencarian kita, kita dapat melihat total kejadian ketika hal ini terjadi. Kita kemudian dapat melihat kapan sebagian besar peristiwa ini terjadi, yang merupakan indikator yang baik mengenai kapan peristiwa tersebut terjadi. Lihat tangkapan layar:
Seperti yang bisa kita lihat, ada lonjakan yang cukup besar dalam kejadian dimana "Akun gagal masuk" sekitar jam 9 pagi pada tanggal 21 Februari. Kita bisa melihat dari total 1004 kejadian yang terjadi, pada jam 9 pagi ada 124 kejadian dengan jumlah serupa muncul pada jam-jam berikutnya. Oleh karena itu, saya yakin serangan dimulai sekitar waktu ini - pukul 09.00 pada tanggal 21 Februari 2020.
Kita bisa melihat dari timeline kejadian tersebut, 124 merupakan lonjakan yang cukup besar. Dalam beberapa jam sebelum kejadian ini, jumlah login buruk terbanyak adalah sekitar 23. Kita dapat menganggap perilaku ini normal. Lihat tangkapan layar:
Dengan mengingat hal ini dan dengan mempertimbangkan ada sekitar 124-135 upaya login ketika serangan brute force terjadi, saya akan mempertimbangkan garis dasar sekitar 40 login buruk per jam. Saya akan memiliki rentang log masuk yang buruk per jam sebagai berikut:
[email protected]
jika dipicu.Untuk membuat peringatan untuk acara jenis ini, saya melakukan langkah-langkah berikut:
Klik 'simpan sebagai' dan kemudian 'peringatan':
Isi detail peringatan, termasuk kapan harus memicunya (di atas 25 upaya per jam):
Masukkan detail suatu tindakan. Dalam hal ini kami akan mengirimkan email ke [email protected]
:
Simpan peringatannya dan kita dapat melihatnya:
Kami sekarang telah berhasil membuat peringatan yang akan terpicu ketika ada lebih dari 25 peristiwa akun gagal masuk.
Kirimkan jawaban atas pertanyaan tentang waktu brute force, baseline, dan ambang batas. Selain itu, berikan tangkapan layar sebagai bukti bahwa peringatan telah dibuat.