Mail Bombing เป็นหนึ่งในการโจมตีทางไซเบอร์ที่เก่าแก่ที่สุด โดยแก่นแท้แล้ว มันมีลักษณะคล้ายกับการโจมตี DoS ทั่วไป แทนที่จะส่งคลื่นคำขอจากที่อยู่ IP ที่แตกต่างกัน คลื่นของอีเมลจะถูกส่งไปยังเซิร์ฟเวอร์ ซึ่งมาถึงที่อยู่อีเมลหนึ่งในปริมาณมหาศาล เนื่องจากมีการโหลด มันเพิ่มขึ้นอย่างมาก การโจมตีดังกล่าวอาจทำให้ไม่สามารถใช้กล่องจดหมายได้ และบางครั้งอาจทำให้เซิร์ฟเวอร์ทั้งหมดล้มเหลวได้ ประวัติศาสตร์อันยาวนานของการโจมตีทางไซเบอร์ประเภทนี้ได้นำไปสู่ผลลัพธ์ทั้งเชิงบวกและเชิงลบหลายประการสำหรับผู้ดูแลระบบ ปัจจัยเชิงบวก ได้แก่ ความรู้ที่ดีเกี่ยวกับการทิ้งระเบิดทางไปรษณีย์ และความพร้อมของวิธีง่ายๆ ในการป้องกันตนเองจากการโจมตีดังกล่าว ปัจจัยเชิงลบ ได้แก่ โซลูชันซอฟต์แวร์ที่เปิดเผยต่อสาธารณะจำนวนมากสำหรับการโจมตีประเภทนี้ และความสามารถของผู้โจมตีในการป้องกันตนเองจากการตรวจจับได้อย่างน่าเชื่อถือ
คุณลักษณะที่สำคัญของการโจมตีทางไซเบอร์นี้คือแทบจะเป็นไปไม่ได้เลยที่จะใช้มันเพื่อหากำไร ผู้โจมตีส่งอีเมลเป็นระลอกหนึ่งไปยังกล่องจดหมายกล่องหนึ่ง เขาไม่อนุญาตให้บุคคลนั้นใช้อีเมลตามปกติ ผู้โจมตีเจาะเข้าไปในอีเมลองค์กรของใครบางคน และเริ่มส่งจดหมายจำนวนมากไปทั่ว GAL ซึ่งก็คือ เหตุใดเซิร์ฟเวอร์จึงขัดข้องหรือเริ่มช้าลงจนไม่สามารถใช้งานได้ และจะเกิดอะไรขึ้นต่อไป แทบจะเป็นไปไม่ได้เลยที่จะแปลงอาชญากรรมทางไซเบอร์ให้เป็นเงินจริง ดังนั้น การโจมตีทางไปรษณีย์ในปัจจุบันจึงเกิดขึ้นไม่บ่อยนัก และเมื่อออกแบบโครงสร้างพื้นฐาน ผู้ดูแลระบบก็อาจจำไม่ได้ถึงความจำเป็นในการป้องกันการโจมตีทางไซเบอร์ดังกล่าว
อย่างไรก็ตาม แม้ว่าการทิ้งระเบิดอีเมลนั้นเป็นการกระทำที่ค่อนข้างไร้จุดหมายในมุมมองเชิงพาณิชย์ แต่ก็มักจะเป็นส่วนหนึ่งของการโจมตีทางไซเบอร์อื่นๆ ที่ซับซ้อนกว่าและหลายขั้นตอน ตัวอย่างเช่น เมื่อแฮ็กเมลและใช้เพื่อแย่งชิงบัญชีในบริการสาธารณะ ผู้โจมตีมักจะ "วางระเบิด" กล่องจดหมายของเหยื่อด้วยจดหมายที่ไม่มีความหมาย เพื่อให้จดหมายยืนยันหายไปในสตรีมและไม่มีใครสังเกตเห็น การวางระเบิดทางไปรษณีย์ยังสามารถใช้เป็นแรงกดดันทางเศรษฐกิจต่อองค์กรได้อีกด้วย ดังนั้นการทิ้งระเบิดอย่างแข็งขันในกล่องจดหมายสาธารณะขององค์กรซึ่งได้รับคำขอจากลูกค้า อาจทำให้การทำงานกับพวกเขายุ่งยากขึ้นอย่างมาก และเป็นผลให้สามารถนำไปสู่การหยุดทำงานของอุปกรณ์ คำสั่งซื้อที่ไม่บรรลุผล รวมถึงการสูญเสียชื่อเสียงและการสูญเสียผลกำไร
นั่นคือเหตุผลที่ผู้ดูแลระบบไม่ควรลืมเกี่ยวกับโอกาสที่จะเกิดอีเมลระเบิด และใช้มาตรการที่จำเป็นเพื่อป้องกันภัยคุกคามนี้เสมอ เมื่อพิจารณาว่าสิ่งนี้สามารถทำได้ในขั้นตอนของการสร้างโครงสร้างพื้นฐานของเมล และยังใช้เวลาและแรงงานน้อยมากจากผู้ดูแลระบบ จึงไม่มีเหตุผลใด ๆ เลยที่จะไม่ให้การป้องกันโครงสร้างพื้นฐานของคุณจากการทิ้งระเบิดทางไปรษณีย์ มาดูกันว่าการป้องกันการโจมตีทางไซเบอร์นี้ถูกนำไปใช้อย่างไรใน Zimbra Collaboration Suite Open-Source Edition
Zimbra ใช้ Postfix ซึ่งเป็นหนึ่งใน Mail Transfer Agent แบบโอเพ่นซอร์สที่น่าเชื่อถือและใช้งานได้ดีที่สุดในปัจจุบัน และข้อดีหลักประการหนึ่งของความเปิดกว้างคือรองรับโซลูชันของบุคคลที่สามที่หลากหลายเพื่อขยายฟังก์ชันการทำงาน โดยเฉพาะอย่างยิ่ง Postfix รองรับ cbpolicyd ซึ่งเป็นยูทิลิตี้ขั้นสูงสำหรับรับรองความปลอดภัยทางไซเบอร์ของเซิร์ฟเวอร์เมล นอกเหนือจากการป้องกันสแปมและการสร้างไวท์ลิสต์ แบล็คลิสต์ และเกรย์ลิสต์แล้ว cbpolicyd ยังอนุญาตให้ผู้ดูแลระบบ Zimbra กำหนดค่าการตรวจสอบลายเซ็น SPF รวมถึงกำหนดข้อจำกัดในการรับและส่งอีเมลหรือข้อมูล ทั้งสองสามารถให้การป้องกันสแปมและอีเมลฟิชชิ่งที่เชื่อถือได้และป้องกันเซิร์ฟเวอร์จากการทิ้งระเบิดอีเมล
สิ่งแรกที่ผู้ดูแลระบบต้องการคือการเปิดใช้งานโมดูล cbpolicyd ซึ่งได้รับการติดตั้งไว้ล่วงหน้าใน Zimbra Collaboration Suite OSE บนเซิร์ฟเวอร์ MTA โครงสร้างพื้นฐาน ทำได้โดยใช้คำสั่ง zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd หลังจากนี้ คุณจะต้องเปิดใช้งานเว็บอินเตอร์เฟสเพื่อให้สามารถจัดการ cbpolicyd ได้อย่างสะดวกสบาย ในการดำเนินการนี้ คุณต้องอนุญาตการเชื่อมต่อบนเว็บพอร์ตหมายเลข 7780 สร้างลิงก์สัญลักษณ์โดยใช้คำสั่ง ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webuiจากนั้นแก้ไขไฟล์การตั้งค่าโดยใช้คำสั่ง nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.phpโดยที่คุณต้องเขียนบรรทัดต่อไปนี้:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="รูท";
$DB_TABLE_PREFIX="";
หลังจากนี้ สิ่งที่เหลืออยู่คือการรีสตาร์ทบริการ Zimbra และ Zimbra Apache โดยใช้คำสั่ง zmcontrol restart และ zmapachectl restart หลังจากนี้คุณจะสามารถเข้าถึงเว็บอินเตอร์เฟสได้ที่ :7780/webui/index.php. ความแตกต่างหลักคือการเข้าสู่เว็บอินเตอร์เฟสนี้ยังไม่ได้รับการปกป้อง แต่อย่างใดและเพื่อป้องกันไม่ให้บุคคลที่ไม่ได้รับอนุญาตเข้ามาคุณสามารถปิดการเชื่อมต่อบนพอร์ต 7780 ได้หลังจากการเข้าสู่เว็บอินเตอร์เฟสแต่ละครั้ง
คุณสามารถป้องกันตัวเองจากอีเมลจำนวนมากที่มาจากเครือข่ายภายในได้โดยใช้โควต้าในการส่งอีเมล ซึ่งสามารถตั้งค่าได้ด้วย cbpolicyd โควต้าดังกล่าวช่วยให้คุณสามารถกำหนดขีดจำกัดจำนวนตัวอักษรสูงสุดที่สามารถส่งจากกล่องจดหมายเดียวในหนึ่งหน่วยเวลา ตัวอย่างเช่น หากผู้จัดการธุรกิจของคุณส่งอีเมลโดยเฉลี่ย 60-80 ฉบับต่อชั่วโมง คุณสามารถกำหนดโควต้าได้ 100 อีเมลต่อชั่วโมง โดยคำนึงถึงส่วนต่างเล็กน้อย เพื่อให้บรรลุโควต้านี้ ผู้จัดการจะต้องส่งอีเมลหนึ่งฉบับทุกๆ 36 วินาที ในอีกด้านหนึ่ง นี่เพียงพอที่จะทำงานได้อย่างเต็มที่ และในทางกลับกัน ด้วยโควต้าดังกล่าว ผู้โจมตีที่เข้าถึงอีเมลของผู้จัดการคนใดคนหนึ่งของคุณจะไม่ปล่อยระเบิดทางไปรษณีย์หรือการโจมตีด้วยสแปมจำนวนมากในองค์กร
ในการกำหนดโควต้าดังกล่าว คุณต้องสร้างนโยบายข้อจำกัดการส่งอีเมลใหม่ในอินเทอร์เฟซเว็บ และระบุว่าจะใช้กับทั้งจดหมายที่ส่งภายในโดเมนและกับจดหมายที่ส่งไปยังที่อยู่ภายนอก ทำได้ดังนี้:
หลังจากนี้คุณสามารถระบุรายละเอียดเพิ่มเติมเกี่ยวกับข้อ จำกัด ที่เกี่ยวข้องกับการส่งจดหมายโดยเฉพาะอย่างยิ่งกำหนดช่วงเวลาที่จะอัปเดตข้อ จำกัด รวมถึงข้อความที่ผู้ใช้ที่เกินขีด จำกัด จะได้รับ หลังจากนั้นคุณสามารถกำหนดข้อจำกัดในการส่งจดหมายได้ สามารถกำหนดได้ทั้งจำนวนตัวอักษรขาออกและจำนวนไบต์ของข้อมูลที่ส่ง ในเวลาเดียวกัน จดหมายที่ส่งเกินขีดจำกัดที่กำหนดจะต้องได้รับการจัดการที่แตกต่างกัน ตัวอย่างเช่น คุณสามารถลบออกได้ทันที หรือคุณสามารถบันทึกไว้เพื่อให้ส่งได้ทันทีหลังจากอัปเดตขีดจำกัดการส่งข้อความแล้ว ตัวเลือกที่สองสามารถใช้เมื่อกำหนดค่าที่เหมาะสมที่สุดของขีด จำกัด ในการส่งอีเมลโดยพนักงาน
นอกจากข้อจำกัดในการส่งจดหมายแล้ว cbpolicyd ยังให้คุณกำหนดขีดจำกัดในการรับจดหมายได้อีกด้วย เมื่อมองแวบแรกข้อ จำกัด ดังกล่าวเป็นวิธีแก้ปัญหาที่ยอดเยี่ยมสำหรับการป้องกันการทิ้งระเบิดทางไปรษณีย์ แต่ในความเป็นจริงการตั้งค่าขีด จำกัด ดังกล่าวแม้จะเป็นข้อ จำกัด ขนาดใหญ่ก็เต็มไปด้วยความจริงที่ว่าภายใต้เงื่อนไขบางประการจดหมายสำคัญอาจไม่ถึงคุณ ด้วยเหตุนี้จึงไม่แนะนำเป็นอย่างยิ่งให้เปิดใช้ข้อจำกัดใดๆ สำหรับเมลขาเข้า อย่างไรก็ตาม หากคุณยังคงตัดสินใจที่จะรับความเสี่ยง คุณจะต้องเข้าใกล้การตั้งค่าขีดจำกัดข้อความขาเข้าด้วยความระมัดระวังเป็นพิเศษ ตัวอย่างเช่น คุณสามารถจำกัดจำนวนอีเมลขาเข้าจากคู่ค้าที่เชื่อถือได้ เพื่อที่ว่าหากเซิร์ฟเวอร์อีเมลของพวกเขาถูกโจมตี เซิร์ฟเวอร์จะไม่โจมตีธุรกิจของคุณด้วยสแปม
เพื่อป้องกันการหลั่งไหลของข้อความขาเข้าในระหว่างการทิ้งระเบิดเมล ผู้ดูแลระบบควรดำเนินการบางอย่างที่ชาญฉลาดมากกว่าการจำกัดเมลขาเข้า วิธีแก้ปัญหานี้อาจเป็นการใช้รายการสีเทา หลักการดำเนินการคือเมื่อพยายามส่งข้อความจากผู้ส่งที่ไม่น่าเชื่อถือเป็นครั้งแรก การเชื่อมต่อกับเซิร์ฟเวอร์จะถูกขัดจังหวะอย่างกะทันหัน ซึ่งเป็นสาเหตุที่ทำให้การส่งจดหมายล้มเหลว อย่างไรก็ตาม หากในช่วงเวลาหนึ่งเซิร์ฟเวอร์ที่ไม่น่าเชื่อถือพยายามส่งจดหมายเดิมอีกครั้ง เซิร์ฟเวอร์จะไม่ปิดการเชื่อมต่อและการจัดส่งจะสำเร็จ
จุดประสงค์ของการดำเนินการทั้งหมดนี้คือโปรแกรมสำหรับการส่งอีเมลจำนวนมากโดยอัตโนมัติมักจะไม่ตรวจสอบความสำเร็จของการส่งข้อความที่ส่งและไม่พยายามส่งข้อความเป็นครั้งที่สองในขณะที่บุคคลจะแน่ใจอย่างแน่นอนว่าจดหมายของเขาถูกส่งไปยัง ที่อยู่หรือไม่
คุณยังสามารถเปิดใช้งานรายการสีเทาในเว็บอินเตอร์เฟสของ cbpolicyd ได้ เพื่อให้ทุกอย่างทำงานได้ คุณต้องสร้างนโยบายที่จะรวมจดหมายขาเข้าทั้งหมดที่จ่าหน้าถึงผู้ใช้บนเซิร์ฟเวอร์ของเรา จากนั้นจึงสร้างกฎ Greylisting ซึ่งคุณสามารถกำหนดค่าช่วงเวลาที่ cbpolicyd จะรอตามนโยบายนี้ สำหรับการตอบกลับซ้ำจากผู้ส่งที่ไม่รู้จัก โดยปกติจะใช้เวลา 4-5 นาที ในเวลาเดียวกัน สามารถกำหนดค่ารายการสีเทาเพื่อให้คำนึงถึงความพยายามที่สำเร็จและไม่สำเร็จทั้งหมดในการส่งจดหมายจากผู้ส่งหลายราย และจะมีการตัดสินใจเพื่อเพิ่มผู้ส่งลงในบัญชีขาวหรือบัญชีดำโดยอัตโนมัติตามหมายเลขของพวกเขา
เราขอแจ้งให้คุณทราบว่าการใช้รายการสีเทาควรกระทำด้วยความรับผิดชอบสูงสุด จะเป็นการดีที่สุดหากการใช้เทคโนโลยีนี้ควบคู่ไปกับการบำรุงรักษาบัญชีขาวและบัญชีดำอย่างต่อเนื่อง เพื่อลดโอกาสที่จะสูญเสียอีเมลซึ่งมีความสำคัญอย่างแท้จริงสำหรับองค์กร
นอกจากนี้ การเพิ่มการตรวจสอบ SPF, DMARC และ DKIM สามารถช่วยป้องกันการโจมตีทางอีเมลได้ บ่อยครั้งที่จดหมายที่มาถึงโดยกระบวนการระเบิดทางไปรษณีย์ไม่ผ่านการตรวจสอบดังกล่าว ได้มีการหารือเกี่ยวกับวิธีการทำเช่นนี้ .
ดังนั้นการป้องกันตัวเองจากภัยคุกคามเช่นการทิ้งระเบิดอีเมลจึงค่อนข้างง่าย และคุณสามารถทำได้แม้ในขั้นตอนของการสร้างโครงสร้างพื้นฐานของ Zimbra สำหรับองค์กรของคุณ อย่างไรก็ตาม สิ่งสำคัญคือต้องตรวจสอบให้แน่ใจอย่างต่อเนื่องว่าความเสี่ยงของการใช้การป้องกันดังกล่าวจะไม่เกินผลประโยชน์ที่คุณได้รับ
ที่มา: will.com