Nice minimal approach. One design point: the threshold counts failures over the entire file, so a slow trickle across weeks looks the same as a burst of 50 attempts in a minute. Bucketing timestamps into a sliding window (for example a deque per IP, evicting entries older than N minutes) would separate those cases. Note the syslog timestamp has no year, which can bite around January rollovers. Also, 'Invalid user' and 'Failed password' lines are separate events in sshd logs, and distributed attacks spread across many IPs would evade a per-IP counter, so grouping by username might be a useful second view. Would you consider tracking successful logins following a failure streak from the same IP?
Appreciate the deep dive and exceptional feedback! You're completely right about the limitations of a global counter—implementing a sliding time window with collections.deque and adding username-based tracking for distributed attacks are fantastic next steps for v2. The syslog year rollover edge-case is also a classic trap. Thanks for reading closely; these are exactly the kind of production-grade hardening steps LogSentry needs.
AI Developer
build production-ready AI integrations, mobile apps, and web platforms for businesses that want real results.
Nice minimal approach. One design point: the threshold counts failures over the entire file, so a slow trickle across weeks looks the same as a burst of 50 attempts in a minute. Bucketing timestamps into a sliding window (for example a deque per IP, evicting entries older than N minutes) would separate those cases. Note the syslog timestamp has no year, which can bite around January rollovers. Also, 'Invalid user' and 'Failed password' lines are separate events in sshd logs, and distributed attacks spread across many IPs would evade a per-IP counter, so grouping by username might be a useful second view. Would you consider tracking successful logins following a failure streak from the same IP?