Fail2ban บนเกตเวย์ VPN: อะไรที่มันแก้และอะไรที่มันไม่แก้

ทุกบริการที่เปิดเผยได้รับคำแนะนำเดียวกัน: วาง fail2ban ไว้บนมัน สำหรับเกตเวย์ VPN คำแนะนำนั้นไม่ผิดและไม่เพียงพอ และการปฏิบัติต่อมันเป็นเพียงรายการติ๊กในการเสริมความแข็งแกร่งคือวิธีที่ผู้คนลงเอยด้วยคุก (jail) ที่ไม่ได้บล็อกอะไรที่มีประโยชน์เลย Fail2ban อ่านบันทึกความล้มเหลวที่คุณชี้ไป และขอให้ backend การบังคับใช้แบนแหล่งที่ตรงกัน คุณค่าทั้งหมดของมันขึ้นอยู่กับว่าพื้นผิวการพิสูจน์ตัวตนใดสร้างบันทึก ที่อยู่ในนั้นเป็นไคลเอนต์จริงหรือไม่ และเกิดอะไรขึ้นกับทุกคนที่อยู่หลังที่อยู่นั้น

fail2ban คืออะไรในเชิงกลไก

ตัวกรองจับคู่บรรทัดในบันทึก คุกนับการจับคู่ต่อแหล่ง และการกระทำใช้การแบนผ่าน backend ของไฟร์วอลล์ ส่วนที่เคลื่อนไหวสามส่วน และแต่ละส่วนอาจผิดได้อย่างอิสระ

ทั้งสามไม่แตะเส้นทางการพิสูจน์ตัวตน: fail2ban ตอบสนองต่อหลักฐานหลังจากเหตุการณ์และไม่เคยตรวจสอบข้อมูลรับรองด้วยตัวเอง ดังนั้นคุกจึงทำงานได้อย่างสะอาดในขณะที่พื้นผิวที่มันระบุยังคงเปิดเผยเหมือนเดิม

ตัวรับฟังของอุโมงค์ไม่ใช่แบบฟอร์มเข้าสู่ระบบ

ตัวรับฟังOpenVPNที่ได้รับการป้องกันด้วยtls-authหรือtls-cryptจะทิ้งแพ็กเก็ตที่ขาดการป้องกันช่องควบคุมก่อนที่การประมวลผล TLS ปกติจะเริ่มขึ้น สแกนเนอร์ที่ไม่เคยมีคีย์จะไม่สร้างอะไรที่ตัวกรองของคุณนับได้ การพิสูจน์ตัวตนด้วยใบรับรองเพิ่มประตูอีกบาน เพราะไม่มีรหัสผ่านให้เดาโครงการ Fail2banจัดทำเอกสารแบบจำลองทั่วไปที่ขับเคลื่อนด้วยบันทึก และตัวกรอง VPN ทั่วไปไม่ได้เปลี่ยนแพ็กเก็ตที่ไม่ผ่านการพิสูจน์ตัวตนให้เป็นเหตุการณ์ล้มเหลวที่มีความหมาย

ถ้าเกตเวย์ยอมรับเฉพาะใบรับรอง เรื่องราวการโจมตีแบบ brute-force ที่คุณป้องกันอยู่อาจไม่มีอยู่เลยบนพอร์ตนั้น

แล้วคุณกำลังปกป้องพื้นผิวใด?

โฮสต์เดียวกันมักเปิดเผยสามสิ่งต่างกัน: ตัวรับฟังของอุโมงค์ พอร์ทัลโปรไฟล์ไคลเอนต์หรือบริการตนเอง และหน้าจอผู้ดูแลระบบ พอร์ทัลและหน้าผู้ดูแลมีแบบฟอร์มรหัสผ่านและสร้างบรรทัดบันทึกที่ตัวกรองนับได้ อุโมงค์อาจสร้างเฉพาะข้อผิดพลาดการจับมือที่มีความหมายต่างกันโดยสิ้นเชิง จับคู่คุกกับพื้นผิว ไม่ใช่กับชื่อผลิตภัณฑ์

คุกหนึ่งอันที่เฝ้าดูบันทึกผิดนั้นแย่กว่าไม่มีเลย เพราะมันสร้างความมั่นใจโดยไม่มีการครอบคลุม ชี้ตัวกรองการเข้าสู่ระบบไปที่ข้อผิดพลาดการจับมือของอุโมงค์ แล้วตัวนับจะดังกับสแกนเนอร์ที่ไม่เคยมีคีย์ ในขณะที่การโจมตีด้วยรหัสผ่านต่อพอร์ทัลจะไม่ถูกนับ อ่านบรรทัดบันทึกที่ตัวกรองจับคู่ก่อนที่คุณจะเชื่อตัวเลขของคุก

การระบุแหล่งที่มาคือจุดอ่อน

การแบนดีเท่าที่อยู่ที่มันเล็งเท่านั้น เมื่อบริการอยู่หลังพร็อกซีแบบย้อนกลับในเครื่อง ที่อยู่ไคลเอนต์ในบันทึกอาจเป็นพร็อกซี และการแบนมันจะลบทุกคน การไว้วางใจส่วนหัวที่ส่งต่อจากแหล่งที่ไม่น่าเชื่อถือให้ความสามารถแก่ผู้โจมตีในการแบนที่อยู่ตามอำเภอใจ บน UDP ที่อยู่ต้นทางสามารถปลอมแปลงได้ ดังนั้นการนับจึงต้องระมัดระวังมากกว่าการนับการเข้าสู่ระบบ TCP ที่เสร็จสมบูรณ์

บันทึกวิธีการระบุแหล่งที่มาไว้ใน README ของคุก เพราะส่วนหัวที่ส่งต่อจากฮอปที่ไม่น่าเชื่อถือเปลี่ยนการแบนให้เป็นอาวุธ

ค่าใช้จ่ายข้างเคียงคือคนอื่น

พนักงานหลายคนหลัง NAT ของสำนักงานหนึ่งแห่งแชร์ที่อยู่เดียวกัน ดังนั้นรหัสผ่านที่บันทึกไว้เก่าเพียงหนึ่งรหัสอาจล็อกทั้งสำนักงานเมื่อเกินขีดจำกัด บันทึกแสดงแหล่งหนึ่งและบัญชีหนึ่งที่ล้มเหลว ไม่ใช่การหยุดชะงักทั้งสำนักงาน

การแบนสั้นและขีดจำกัดปานกลางลดสิ่งนั้น และเส้นทางการปลดแบนที่บันทึกไว้ช่วยลดภาระการสนับสนุนเมื่อมันเกิดขึ้นอยู่ดี ที่อยู่คือสัญญาณหยาบ ไม่ใช่ตัวตนและคนที่เปิดตั๋วจะอธิบายการหยุดชะงัก ไม่ใช่ขีดจำกัด

เมื่อใดควรนำไปใช้ และเมื่อใดควรแก้อย่างอื่น

นำไปใช้เมื่อมีมีความล้มเหลวในการเข้าสู่ระบบออนไลน์จริง ระบุแหล่งได้ และเกิดซ้ำบนพื้นผิวที่คุณควบคุม และเมื่อ backend การบังคับใช้ครอบคลุมพื้นผิวนั้นจริง ๆ แก้อย่างอื่นเมื่อปัญหาเป็นนโยบายข้อมูลรับรองที่อ่อนแอ หน้าจอการจัดการที่เปิดเผยต่ออินเทอร์เน็ต หรือบัญชีที่เข้าสู่ระบบสำเร็จเพราะถูกบุกรุก การแบนไม่สามารถซ่อมแซมสิ่งใดเหล่านั้นได้ และไม่สามารถดูดซับทราฟฟิกที่อิ่มตัวลิงก์ต้นทางของคุณแล้ว ปัญหาสุดท้ายนั้นเป็นของต้นน้ำ ของคนที่สามารถกรองได้ก่อนที่แพ็กเก็ตจะมาถึงคุณ

ผูกทุกคุกไว้กับพื้นผิวเดียว ตรวจสอบผลบวกปลอม และวัดงานพิสูจน์ตัวตนที่หลีกเลี่ยงได้แทนจำนวนที่อยู่ที่ถูกแบน