I get that it increases attack surface, though I'd feel a python-written parser is relatively safe. but performance win remains.
-
-
It's not the mem safety, it's that logs are untrusted freeform text. The classic bugs in these are like ssh "foo from 127.0.0.1"
@host.com.2 replies 1 retweet 10 likes -
Good luck parsing that correctly first try! On top of that, you're papering over the real issue - a weak pw scan shouldn't concern anyone.
1 reply 0 retweets 4 likes -
I run fail2ban and only for one reason: To keep my logs clean. Okay, secondary to report bad hosts to blocklists. It's a collab. effort.
1 reply 0 retweets 3 likes -
Replying to @thermicorp @hanno and
Yeah, but is log noise a serious enough concern to try parsing untrusted data as root? I wouldn't make that trade
2 replies 0 retweets 5 likes -
Well, considering how I use it, there is no danger from accidental command injection, because the data is not used as argument in the shell.
1 reply 0 retweets 0 likes -
Replying to @thermicorp @hanno and
I bet I could get you to add 0.0.0.0/0 (i.e. cidr range) to your blocklist ;-)
2 replies 2 retweets 9 likes -
Replying to @taviso @thermicorp and
Would it be less concerning if fail2ban ran unpriv, had only one API call to a separate daemon that only accepted IPs, and managed iptables?
1 reply 0 retweets 1 like -
You’d still have a thing automatically banning random IPs based on random log messages in order to solve zero real security problems.
2 replies 0 retweets 3 likes -
You realise that the IPs are not random or taken from user defined input but the actual IP that attempted some malicious action?
3 replies 0 retweets 0 likes
Tom knows how log monitoring works. You've misunderstood the problem.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.