🔄 Topic

Exploring how systems automatically block attackers after repeated failures.

🎯 Goal

Understand how Fail2Ban detects and blocks brute-force attacks.

🛠 What I Did

Observed how repeated failed SSH attempts trigger:

  • IP ban rules
  • firewall updates

Fail2Ban monitors logs and reacts automatically.

I treated it as a small model of detection engineering: define a pattern, watch the evidence, set a threshold, trigger a response, and then review the result.

🔗 Key Cybersecurity Connections

Fail2Ban represents:

  • automated detection + response
  • basic intrusion prevention

🔍 Investigation Questions

  • Which IP was banned?
  • How many attempts triggered the ban?
  • How long is the ban active?

🚨 Detection Opportunities

  • repeated failed logins before ban
  • sudden drop in attempts after block

🧭 MITRE ATT&CK Techniques

  • T1110 — Brute Force

⚠ Challenges

Understanding that:

  • blocking happens AFTER detection
  • logs still contain the attack evidence

📚 What I Learned

  • automation reduces manual effort
  • detection must come before response
  • logs remain critical for analysis
  • response rules need tuning or they can create false positives
  • blocking an IP is useful, but understanding the activity is still necessary

➡ Next Steps

  • tune thresholds
  • analyze false positives

🧠 Reflection

This is defensive security in action:

detect → react → block

🧩 Lessons Learned

What worked

Observing automated blocking behaviour.

What broke

Thinking blocking prevents all activity.

Why it broke

Detection happens after attempts.

Fix / takeaway

Prevention ≠ elimination.

Automated defense is valuable, but it does not replace investigation. It gives analysts time and reduces noise, while the logs still explain what happened and whether the rule behaved correctly.

📈 Skill Progression Context

This introduces automated defense mechanisms used in real environments.

😄 TL;DR

Fail2Ban is basically:
“try that again and you’re out”