ในข้อตกลงกับ @tilman-schmidt เพียงไม่กี่เซ็นต์จากฝ่ายของฉัน (เกี่ยวกับความล้มเหลว 2 แบน ฯลฯ )...
ผู้คน OpenSSH เปลี่ยนพฤติกรรมการบันทึกอย่างต่อเนื่อง ดังนั้นจึงอาจไม่ถูกพิจารณาโดย fail2ban ตามค่าเริ่มต้น (ขึ้นอยู่กับว่าการตัดการเชื่อมต่อเกิดขึ้นที่ใด เช่นในขั้นตอนการตรวจสอบสิทธิ์หรือหลังจากได้รับชื่อผู้ใช้ ตลอดจนวิธีการตรวจสอบสิทธิ์ที่อนุญาตใน sshd ของคุณ เช่นเดียวกับพฤติกรรม "ผู้บุกรุก")
อย่างน้อยฉันก็ตั้งค่า LogLevel VERBOSE ใน sshd_config ตามที่อธิบายไว้ใน /etc/fail2ban/filter.d/sshd.conf
บันทึกคำตอบนี้สำหรับคำถามที่คล้ายกันด้วย - https://unix.stackexchange.com/questions/662946/fail2ban-regex-help-for-banning-sshd-connection-attempts/663002#663002
ไม่เร็วกว่า 24 ชั่วโมงต่อมา ผู้โจมตีเปลี่ยนไปยังการหมุนเวียนผ่านที่อยู่ IP ที่ไม่ซ้ำกันหลายร้อยรายการ
สิ่งนี้ไม่เกี่ยวข้องกับการใช้ fail2ban - สแกนเนอร์ เนื่องจากพบ sshd listener จึง "เผยแพร่" ในบางรายการ ดังนั้นการสแกนที่ลึกขึ้น (เช่น ด้วยบอทเน็ตแบบกระจาย) สามารถเริ่มต้นได้ นี่คือชะตากรรมที่น่าเสียใจของเซิร์ฟเวอร์ใด ๆ ที่มีพอร์ตเปิดสู่ภายนอก
คุณสามารถลองเปลี่ยนพอร์ต ssh เป็นอย่างอื่นได้ แต่มันจะหลีกเลี่ยงสคริปต์ตัวเล็กเพียงครึ่งเดียว (ถ้าคุณห้ามความพยายามในการสแกนพอร์ต) และโดยพื้นฐานแล้วไม่ใช่ยาครอบจักรวาลเลย
แต่คุณสามารถลดจำนวนผู้บุกรุกได้อย่างมาก อย่างน้อยในช่วงเวลาสั้นๆ ถึงไม่กี่เดือน
สิ่งที่อาจช่วยได้อย่างแน่นอนคือการเปิดใช้งาน bantime.increment
ใน fal2ban (สำหรับคุก sshd หรือโดยค่าเริ่มต้น)
ดูเหมือนว่า Failed2ban จะไม่ยอมรับความพยายามซ้ำๆ ที่ส่งผลให้การเชื่อมต่อถูกปิดโดย
สิ่งนี้ไม่ถูกต้องเสียทีเดียว
คุณต้องตั้งค่า โหมด = ก้าวร้าว
สำหรับ sshd
ติดคุก คุก.local
เพื่ออนุญาตให้ fail2ban พิจารณา "การโจมตี" ทุกประเภท (ไม่ใช่ปัญหาการตรวจสอบเท่านั้น) ซึ่งเกิดขึ้นโดยเครื่องสแกนพอร์ตและสิ่งที่คล้ายกัน DoS
และคุณสามารถดูสิ่งที่ Fail2ban จะพบได้อย่างแน่นอนด้วยตัวกรองปัจจุบันของคุณด้วยคำสั่งนี้ (หมายเหตุ จับคู่
ในบรรทัดสุดท้ายจากผลลัพธ์):
fail2ban-regex /var/log/auth.log 'sshd[mode=aggressive]'