Hacker News new | ask | show | jobs
by gmuslera 4666 days ago
If you think someone could get in thru the ssh port (exploiting an undisclosed vulnerability or with brute force password cracking) moving it elsewhere is not a long term solution. fail2ban is good to avoid brute force attacks, but portknocking with i.e. fwknop will be safer in more situations. If a service is not meant for the public then they shouldn't be able to even notice that is there.
1 comments

fail2ban and other programs that just grep a log file are a horrible idea as most of them can't properly parse a log entry and it's possible to inject an arbitrary ip address into the log file one way or another. I'm not sure if there are any outstanding exploits for the latest version of fail2ban right now but the whole concept of searching through log files that are in a format that can change at any time, aren't delimited properly, and subject to the sysadmin customizing is a precarious one at best.

Even if fail2ban and others were perfect, all it would take is the sysadmin customizing the log format to include some random field and all the sudden it's possible for an attacker to block every IP address with one request.

Source: http://seclists.org/fulldisclosure/2007/Jun/138

A better alternative is something like pam_abl which only protects logins to a user on the system but with it ssh is essentially unbruteforceable.

Does pam_abl work when you're not using PAM for authentication--only for authorization ("account") and session management? e.g., when UsePAM is enabled, but ChallengeResponseAuthentication and PasswordAuthentication are disabled.

I believe this is the problem with using pam_tally2. Then again, if you're only allowing PubkeyAuthentication then maybe you don't care about brute force login attempts so much.