Lesson Learned Dari Insiden Email Spamming

 

Salah satu stakeholder kami mengalami insiden berupa email spamming dan meminta bantuan Gov-CSIRT Indonesia, kami pun langsung merespon insiden tersebut dan memberikan asistensi untuk tindakan korektif dengan men-setting mail filtering dan otentikasi email, melakukan test konfigurasi, test kirim terima email biasa dan email mengandung virus, serta memberikan rekomendasi teknis lainnya. Selengkapnya disampaikan pada artikel ini.


Terjadi Insiden Siber berupa Email Spamming

Suatu ketika masuk laporan insiden siber berupa spamming pada email server di stakeholder kami,. Untuk mendeteksi bahwa terjadi insiden berikut adalah ciri-ciri dari insiden email spamming :

  1. kirim terima email terganggu. Ada kalanya tidak bisa mengirimkan email atau menerima email, bahkan keduanya sekaligus;
  2. dari log diketahui bahwa terdapat alamat email tertentu yang melakukan spamming yaitu mengirimkan email dalam jumlah yang besar dalam waktu yg singkat. Hal ini berarti kemungkinan besar pengiriman email dilakukan menggunakan engine.

Kami selaku Tim Gov-CSIRT Indonesia pun bergegas melakukan penanganan secara onsite. Setibanya di lokasi, kami diterima dengan baik oleh tuan rumah selaku pelapor dan langsung diantar ke data center dan diperkenalkan dengan staf teknis TIK yang menangani infrastruktur dan server. Kami pun langsung melakukan observasi.

Observasi Awal

Adapun email server yang dimaksud memiliki spesifikasi berikut :

Sistem OperasiAplikasi Email Server
Ubuntu versi 18Kolab Community versi 1.8

Setelah melakukan observasi awal kami mendapatkan fakta-fakta sebagai berikut :

  1. Insiden email spamming terjadi pada beberapa alamat email saja dan pemilik alamat email sudah dihubungi oleh administrator untuk berkoordinasi namun bersikap kurang kooperatif. Hal ini menyebabkan administrator bingung menentukan penyebab insiden : apakah email spamming terjadi karena komputer pemilik alamat email di-hack atau penyebab lainnya;
  2. Staf teknis TIK sudah berusaha menangani insiden ini dengan cara me-reset password, namun email spamming tetap terjadi;
  3. Kirim terima email tidak berjalan dengan baik, yaitu seringkali email yang dikirimkan tidak sampai tujuan;
  4. Kirim terima email merupakan bagian dari proses bisnis aplikasi yang digunakan instansi tersebut. Sehingga proses bisnis aplikasi menjadi terganggu;
  5. Administrator sering melakukan akses secara remote ke server menggunakan SSH, namun ketika ditanya mengenai konfigurasi SSH rupanya sudah menerapkan konsep hardening namun belum memadai. Hardening ini penting dilakukan guna mencegah serangan brute force/dictionary attack ke port SSH. Namun apakah SSH ini yang menyebabkan terjadinya insiden? Belum diketahui juga.

Sebenarnya selain melakukan observasi di atas, bisa juga dilakukan analisis melalui test secara online atas konfigurasi email server. Berikut adalah beberapa website gratis yang bisa melakukan test atas konfigurasi email server :

  1. Email Server Test – Online SMTP Diagnostic Tools pada tautan https://mxtoolbox.com/diagnostic.aspx;
  2. Test Your SMTP Mail Server (MX) pada tautan https://www.wormly.com/test-smtp-server.

Akhirnya setelah melakukan observasi lebih lanjut ternyata email server tersebut memiliki topologi yang kurang ideal, yaitu email server tersebut terkoneksi begitu saja ke internet tanpa perangkat pengamanan apapun. Berikut adalah gambaran dari topologi yang dimaksud.

Gambar 1. Topologi jaringan di email server.

Tindakan Korektif untuk Insiden Email Spamming

1. Mail Filtering

Setelah Tim Gov-CSIRT Indonesia melakukan analisis terhadap file log di server, didapatkan kesimpulan bahwa email server ini tidak memiliki konfigurasi email filtering. Rupanya inilah penyebab utama terjadinya insiden email spamming. Maka staf teknis TIK kemudian melakukan konfigurasi email server dengan panduan tutorial pada tautan : https://help.ubuntu.com/lts/serverguide/mail-filtering.html.en. Kemudian dilakukan restart atas email service.

2. Menambah Trust Dengan Otentikasi Email

Otentikasi email membantu meningkatkan pengiriman dan kredibilitas email dengan menerapkan protokol yang memverifikasi domain yang mengirimkan pesan. 
a. SPF (Sender Policy Framework) 
SPF adalah cara bagi penerima untuk mengkonfirmasi identitas pengirim email yang masuk. SPF berupa entri teks DNS yang menunjukkan daftar server yang dizinkan untuk mengirimkan email ke domain tertentu. Berikut adalah alur otentikasi email menggunakan SPF :

  1. Setelah menerima pesan HELO dan alamat pengirim diambil oleh server surat penerima;
  2. Email server penerima menjalankan kueri TXT DNS terhadap entri domain SPF yang diklaim;
  3. Data entri SPF kemudian digunakan untuk memverifikasi server pengirim;
  4. Seandainya cek gagal, pesan penolakan diberikan ke server pengirim.
Gambar 2. Otentikasi email menggunakan SPF.

b. DKIM (Domain Key Identified Mail) 
DKIM adalah metode untuk identifikasi email “palsu” tetapi menggunakan 2 (dua) kunci pada kriptografi asimetrik: kunci publik dan kunci privat. Kunci privat ditempatkan di lokasi yang aman yang hanya dapat diakses oleh pemilik domain. Kunci privat ini digunakan untuk membuat tanda tangan terenkripsi yang ditambahkan ke setiap pesan yang dikirim dari domain itu. Menggunakan tanda tangan, penerima pesan dapat memeriksa terhadap kunci publik DKIM, yang disimpan dalam catatan DNS yang menghadap publik. Jika record-nya “cocok”, maka email hanya bisa dikirim oleh orang yang memiliki akses ke kunci privat, alias pemilik domain. Adapun panduan untuk melakukan konfigurasi pada DKIM dan SPF dapat dilihat pada tautan : https://www.linuxbabe.com/mail-server/setting-up-dkim-and-spf.

  1. Saat mengirim pesan keluar, server terakhir dalam infrastruktur domain memeriksa terhadap pengaturan internal jika domain yang digunakan dalam header “From:” termasuk dalam “Signing table“. Jika tidak prosesnya berhenti di sini;
  2. Header baru, yang disebut “DKIM-Signature“, ditambahkan ke pesan email dengan menggunakan bagian pribadi dari kunci pada konten pesan;
  3. Konten utama email tidak dapat diubah, jika tidak maka header DKIM tidak akan cocok lagi;
  4. Pada penerimaan, server penerima akan membuat DNS TXT query untuk mengambil kunci yang digunakan di DKIM-Signature field;
  5. Hasil pemeriksaan header DKIM kemudian dapat digunakan ketika memutuskan apakah suatu email dapat dipercaya atau curang.
Gambar 3. Otentikasi email menggunakan DKIM.

c. DMARC (Domain-based Message Authentication, Reporting, and Conformance) 
Sementara SPF dan DKIM dapat digunakan sebagai metode yang berdiri sendiri, DMARC harus mengandalkan SPF atau DKIM untuk memberikan otentikasi. Berikut adalah skema otentikasi email menggunakan DMARC :

  1. Pada saat penerimaan, server surat penerima memeriksa apakah ada kebijakan DMARC yang ada yang diterbitkan dalam domain yang digunakan pada pemeriksaan SPF/DKIM;
  2. Jika pemeriksaan pada salah satu atau keduanya (SPF dan DKIM) berhasil, kemudian hasil pemeriksaan akan disejajarkan dengan kebijakan yang ditetapkan oleh DMARC. Hasil pemeriksaan apabila sesuai maka dianggap berhasil, namun jika tidak sesuai maka ditetapkan sebagai gagal;
  3. Jika hasil pemeriksaan gagal, maka berdasarkan tindakan yang dilakukan berdasarkan kebijakan DMARC.
Gambar 4. Otentikasi email menggunakan DMARC.

Adapun panduan konfigurasi DMARC berdasarkan pada tautan : https://www.esecurityplanet.com/applications/how-to-set-up-implement-dmarc-email-security.html.

3. Test Konfigurasi

Setelah staf teknis TIK melakukan konfigurasi email filtering, dilakukan test secara online dan didapatkan hasil sebagai berikut :

Gambar 5. Hasil test konfigurasi SMTP pada email server.
Gambar 6. Alamat IP email server yang masuk dalam beberapa blacklist.

Dengan demikian, dapat disimpulkan bahwa :

  1. Tindakan korektif sudah tepat sehingga email server tersebut bukan merupakan open relay yang sangat rentan terjadi email spamming. Open Relay maksudnya mail tersebut memperbolehkan pihak luar (di luar network yang telah didefenisikan) untuk mengirim email via email server tanpa otentikasi. Akibatnya, ketika email server menjadi Open Relay adalah :
    • Email server tersebut akan digunakan untuk mengirim email-email spam. Dampaknya kemudian alamat IP dari email server akan di-block karena terindikasi melakukan spamming;
    • Email server diambil datanya dan digunakan untuk tujuan yang tidak seharusnya. Saat ini alamat IP dari email server masih di-block oleh beberapa blacklist. Oleh karena itu perlu menyampaikan permohonan ke blacklist terkait agar alamat IP tersebut dapat di-release.
  2. Saat ini alamat IP dari email server masih di-block oleh beberapa blacklist. Oleh karena itu perlu menyampaikan permohonan ke blacklist terkait agar alamat IP tersebut dapat di-release.

4. Test Kirim Terima Email Biasa

Pada pengujian ini, email server bisa menerima email yang dikirimkan dari domain lainnya. Namun email server belum bisa mengirimkan email ke domain lainnya karena alamat IP dari email servermasih di-block, butuh waktu untuk me-release block tersebut.

5. Test Kirim Email Mengandung Virus

Ketika melakukan konfigurasi mail filtering, terdapat engine ClamAV yang berfungsi untuk mem-filter apabila terdapat virus yang dikirimkan melalui email. Untuk menguji hal ini dilakukan pengiriman email yang mengandung virus berdasarkan tutorial pada tautan : https://easyengine.io/tutorials/mail/server/testing/antivirus, kemudian dilakukan pengecekan terhadap log dan didapatkan bahwa engine sudah bisa mem-block email tersebut :

Gambar 7. Log pada email server.

Rekomendasi Keamanan Lainnya

Selain melakukan tindakan korektif, kami juga memberikan beberapa rekomendasi teknis untuk meningkatkan keamanan siber yaitu :

  • Diperlukan topologi jaringan yang lebih baik sehingga dapat mencegah serangan siber dan menjaga kontinuitas bisnis. Berikut adalah topologi jaringan yang disarankan :
Gambar 8. Topologi jaringan yang disarankan.
  • Apabila email server tidak dilindungi oleh firewall perangkat keras, maka diperlukan firewall perangkat lunak pada dengan network policy yang ketat namun sesuai kebutuhan. Network policy yang dimaksud diantaranya membuat whitelist terhadap koneksi inbound dan outbound, selain itu di-deny.
  • Selama ini staf TIK sering mengakses server secara remote menggunakan SSHTerkait hal tersebut diperlukan hardening pada SSH untuk meminimalisir risiko terhadap dictionary/brute force attack yaitu dengan menambahkan konfigurasi :
PermitRootLogin noTidak mengizinkan login dengan akun root
MaxSessions 2Session maksimal 2 user
PubkeyAuthentication yesMengaktifkan otentikasi dengan public key
PasswordAuthentication noMenonaktifkan otentikasi dengan password
  • Perlu personil yang menguasai IT Security, sehingga bisa melakukan identifikasi terhadap celah-celah keamanan(vulnerability)dan melakukan hardening terhadap vulnerability yang ditemukan. Personil dapat mengikuti pelatihan yang berelasi dengan IT Security, seperti Certified Ethical Hacker (CEH) untuk memahami teknik hacking yang dilakukan oleh hackerCertified Hacking Forensic Infestigator (CHFI) untuk dapat mengetahui teknik investigasi forensik apabila terjadi hacking, serta pelatihan IT Security lainnya   
  • Diperlukan edukasi dan sosialisasi kepada pengguna TIK mengenai penggunaan layanan TIK (seperti internet dan e-mail) secara aman.

 sumber: https://csirt.bppt.go.id/2019/05/28/lesson-learned-dari-insiden-email-spamming/

Gunakan PowerDMARC untuk mencegah semua hal ini terjadi , kontak tim kami segera. 





Posting Komentar

0 Komentar