Email bombing adalah salah satu jenis serangan cyber tertua. Pada intinya, ini menyerupai serangan DoS biasa, tetapi alih-alih gelombang permintaan dari alamat ip yang berbeda, poros email dikirim ke server, yang dalam jumlah besar tiba di salah satu alamat email, yang karenanya bebannya meningkat secara signifikan. Serangan seperti itu dapat menyebabkan ketidakmampuan untuk menggunakan kotak surat, dan kadang-kadang bahkan dapat menyebabkan kegagalan seluruh server. Sejarah panjang jenis serangan cyber ini telah menyebabkan sejumlah konsekuensi positif dan negatif bagi administrator sistem. Faktor-faktor positif termasuk pengetahuan yang baik tentang pemboman email dan ketersediaan cara-cara sederhana untuk bertahan melawan serangan semacam itu. Faktor-faktor negatif termasuk sejumlah besar solusi perangkat lunak yang tersedia secara publik untuk melakukan jenis serangan ini dan kemampuan bagi penyerang untuk secara andal melindungi diri mereka dari deteksi.
Fitur penting dari serangan siber ini adalah bahwa hampir tidak mungkin digunakan untuk keuntungan. Nah, penyerang mengirim batang email ke salah satu kotak surat, yah, dia tidak mengizinkan orang itu untuk menggunakan email secara normal, yah, penyerang meretas surat perusahaan seseorang dan mulai secara besar-besaran mengirim ribuan email di seluruh GAL, karena servernya crash atau mulai melambat sehingga menjadi tidak mungkin untuk menggunakannya, dan apa yang selanjutnya? Hampir tidak mungkin untuk mengubah kejahatan dunia maya menjadi uang nyata, itulah sebabnya pemboman email saat ini sangat jarang dan administrator sistem mungkin tidak ingat perlunya melindungi diri dari serangan dunia maya seperti itu ketika merancang infrastruktur.
Namun demikian, terlepas dari kenyataan bahwa pemboman email itu sendiri adalah kegiatan komersial yang agak tidak masuk akal, sering kali merupakan bagian integral dari serangan cyber lainnya, yang lebih kompleks dan multi-tahap. Misalnya, ketika meretas surat dan menggunakannya untuk membajak sebuah akun di layanan publik, penyerang sering "membom" kotak surat korban dengan surat yang tidak berarti sehingga pesan konfirmasi hilang dalam aliran mereka dan tidak diketahui. Email bombing juga dapat digunakan sebagai sarana tekanan ekonomi pada perusahaan. Dengan demikian, pemboman aktif kotak surat publik perusahaan, yang menerima aplikasi dari pelanggan, dapat menyulitkan pekerjaan dengan mereka dan, akibatnya, dapat menyebabkan penghentian peralatan, pesanan yang belum diselesaikan, serta hilangnya reputasi dan hilangnya laba.
Itulah sebabnya administrator sistem tidak boleh lupa tentang kemungkinan melakukan pemboman email dan selalu mengambil tindakan yang diperlukan untuk melindungi terhadap ancaman ini. Mengingat bahwa ini dapat dilakukan bahkan pada tahap membangun infrastruktur surat, serta fakta bahwa dibutuhkan administrator sistem sangat sedikit waktu dan tenaga, alasan obyektif agar tidak memberikan infrastruktur mereka perlindungan dari pemboman email, sama sekali tidak tetap . Mari kita lihat bagaimana perlindungan terhadap serangan siber ini diimplementasikan dalam Edisi Terbuka Sumber-Sumber Zimbra Collaboration.
Inti dari Zimbra adalah Postfix - salah satu Agen Transfer Surat Sumber Terbuka yang paling andal dan fungsional saat ini. Dan salah satu keuntungan utama keterbukaannya adalah mendukung berbagai solusi pihak ketiga untuk memperluas fungsionalitas. Secara khusus, Postfix sepenuhnya mendukung cbpolicyd, utilitas keamanan siber canggih untuk server mail. Selain melindungi terhadap spam dan membuat daftar putih, daftar hitam, dan daftar abu-abu, cbpolicyd memungkinkan administrator Zimbra untuk mengatur verifikasi tanda tangan SPF, serta menetapkan batas untuk menerima dan mengirim email atau data. Mereka dapat memberikan perlindungan yang andal terhadap email spam dan phishing, serta melindungi server dari pemboman email.
Hal pertama yang diperlukan dari administrator sistem adalah aktivasi modul cbpolicyd, yang sudah diinstal sebelumnya di Zimbra Collaboration Suite OSE pada infrastruktur MTA server. Ini dilakukan dengan menggunakan perintah zmprov ms `zmhostname` + zimbraServiceEnabled cbpolicyd. Setelah itu, Anda harus mengaktifkan antarmuka web agar dapat mengelola cbpolicyd dengan nyaman. Untuk melakukan ini, Anda harus mengaktifkan koneksi pada nomor port web 7780, membuat tautan simbolik menggunakan perintah
ln -s / opt / zimbra / common / share / webui / opt / zimbra / data / httpd / htdocs / webui , lalu edit file pengaturan menggunakan perintah nano
/opt/zimbra/data/httpd/htdocs/webui/includes/config.php , di mana Anda perlu mendaftarkan baris berikut:
$ DB_DSN = "sqlite: /opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$ DB_USER = "root";
$ DB_TABLE_PREFIX = "";
Setelah itu, tetap hanya untuk me-restart layanan Zimbra dan Zimbra Apache menggunakan zmcontrol restart dan zmapachectl restart perintah. Setelah itu, Anda akan memiliki akses ke antarmuka web di
example.com : 7780 / webui / index.php . Nuansa utama adalah bahwa pintu masuk ke antarmuka web ini tidak terlindungi dengan cara apa pun dan untuk mencegah orang yang tidak berwenang memasukinya, Anda cukup menutup koneksi pada port 7780 setelah setiap pintu masuk ke antarmuka web.
Kuota untuk mengirim email, yang dapat diatur berkat cbpolicyd, memungkinkan Anda untuk melindungi diri dari aliran surat yang datang dari jaringan internal. Kuota semacam itu memungkinkan Anda menetapkan batas jumlah huruf maksimum yang dapat dikirim dari satu kotak surat ke satu unit waktu. Misalnya, jika manajer perusahaan Anda mengirim rata-rata 60-80 email per jam, maka, dengan margin kecil, Anda dapat menetapkan kuota 100 email per jam. Untuk menghabiskan kuota seperti itu, manajer harus mengirim satu huruf setiap 36 detik. Di satu sisi, ini cukup untuk sepenuhnya berfungsi, dan di sisi lain, dengan kuota seperti itu, penyerang yang mendapatkan akses ke surat salah satu manajer Anda tidak akan mengatur pemboman email atau serangan spam massal di perusahaan.
Untuk menetapkan kuota seperti itu, perlu membuat kebijakan pembatasan baru untuk mengirim surat di antarmuka web dan menentukan bahwa itu berlaku baik pada surat yang dikirim dalam domain dan pada surat yang bertindak pada alamat eksternal. Ini dilakukan sebagai berikut:
Setelah itu, dimungkinkan untuk menentukan secara lebih rinci pembatasan yang terkait dengan pengiriman surat, khususnya, mengatur interval waktu setelah mana pembatasan akan diperbarui, serta pesan yang akan diterima oleh pengguna yang melebihi batasnya. Setelah itu, Anda dapat mengatur batasan pengiriman surat. Dapat diatur baik sebagai jumlah surat keluar, dan sebagai jumlah byte informasi yang dikirimkan. Dalam hal ini, dengan surat yang dikirim melebihi batas yang ditentukan, lakukan secara berbeda. Jadi, misalnya, Anda dapat langsung menghapusnya, atau Anda dapat menyimpannya segera setelah memperbarui batas pengiriman pesan. Opsi kedua dapat digunakan saat mengidentifikasi batas optimal untuk mengirim email oleh karyawan.
Selain pembatasan pengiriman surat, cbpolicyd memungkinkan Anda untuk mengonfigurasi batas penerimaan surat. Pembatasan seperti itu, pada pandangan pertama, adalah solusi yang sangat baik untuk perlindungan terhadap pemboman email, tetapi pada kenyataannya penetapan batas seperti itu, bahkan jika besar, penuh dengan fakta bahwa dalam kondisi tertentu surat penting mungkin tidak mencapai Anda. Itu sebabnya sangat tidak dianjurkan untuk memasukkan batasan untuk surat masuk. Namun, jika Anda masih memutuskan untuk mengambil kesempatan, untuk mendekati pengaturan batas pesan masuk Anda perlu mendekati dengan perhatian khusus. Misalnya, Anda dapat membatasi jumlah surat masuk dari rekanan tepercaya, sehingga jika server email mereka disusupi, ia tidak akan melakukan serangan spam pada perusahaan Anda.
Untuk melindungi diri Anda dari gulungan pesan masuk selama pemboman email, administrator sistem harus melakukan sesuatu yang lebih pintar daripada sekadar membatasi surat masuk. Solusi semacam itu bisa berupa penggunaan daftar abu-abu. Prinsip tindakan mereka adalah bahwa upaya pertama untuk mengirimkan pesan dari pengirim yang tidak dapat diandalkan, koneksi ke server tiba-tiba terputus, itulah sebabnya pengiriman pesan gagal. Namun, jika dalam periode tertentu server tidak dapat diandalkan lagi mencoba mengirim pesan yang sama, server tidak memutuskan dan pengirimannya berhasil.
Arti dari semua tindakan ini adalah bahwa program untuk surat massal secara otomatis dari email biasanya tidak memverifikasi keberhasilan pengiriman pesan yang dikirim dan tidak berusaha mengirimkannya untuk yang kedua kalinya, sementara orang tersebut pasti akan memastikan apakah suratnya dikirim ke alamat atau tidak.
Anda juga dapat mengaktifkan daftar abu-abu di antarmuka web cbpolicyd. Agar semuanya berfungsi, Anda perlu membuat kebijakan yang akan mencakup semua pesan masuk yang ditujukan kepada pengguna di server kami, dan kemudian membuat aturan Greylisting berdasarkan kebijakan ini, di mana Anda dapat mengonfigurasi interval selama cbpolicyd akan menunggu respons berulang dari yang tidak dikenal pengirim. Biasanya 4-5 menit. Pada saat yang sama, daftar abu-abu dapat dikonfigurasi sehingga semua upaya yang berhasil dan tidak berhasil untuk mengirim surat dari pengirim yang berbeda dipertimbangkan, dan berdasarkan nomornya, keputusan dibuat untuk secara otomatis menambahkan pengirim ke daftar putih atau hitam.
Kami menarik perhatian Anda pada fakta bahwa penggunaan daftar abu-abu harus didekati dengan tanggung jawab maksimal. Akan lebih baik jika penggunaan teknologi ini berjalan seiring dengan pemeliharaan daftar putih dan hitam secara terus-menerus untuk mengecualikan kemungkinan kehilangan surat yang benar-benar penting bagi perusahaan.
Selain itu, penambahan cek SPF, DMARC dan DKIM dapat membantu melindungi terhadap pemboman surat. Seringkali, surat yang diterima selama proses pengeboman surat tidak lulus pemeriksaan semacam itu. Cara melakukan ini dijelaskan
dalam salah satu artikel kami sebelumnya .
Dengan demikian, melindungi diri Anda dari ancaman seperti pemboman email cukup sederhana, dan Anda dapat melakukan ini bahkan pada tahap membangun infrastruktur Zimbra untuk perusahaan Anda. Namun, penting untuk selalu memastikan bahwa risiko dari menggunakan perlindungan tersebut tidak pernah melebihi manfaat yang Anda terima.
Untuk semua pertanyaan yang terkait dengan Zextras Suite, Anda dapat menghubungi perwakilan Zextras Katerina Triandafilidi melalui email katerina@zextras.com