since daemon might eventually change reported length and we would need to adjust anyways. So limiting
in length does not provide additional security but allows for a possible injection vector
Origin: from https://github.com/jamesstout/fail2ban
* 'OpenSolaris' of https://github.com/jamesstout/fail2ban:
ENH: Removed unused log line
BF: fail2ban.local needs section headers
ENH: Use .local config files for logtarget and jail
ENH+TST: ssh failure messages for OpenSolaris and OS X
ENH: fail message matching for OpenSolaris and OS X
ENH: extra daemon info regex
ENH: actionunban back to a sed command
Readme for config on Solaris
create socket/pid dir if needed
Extra patterns for Solaris
change sed to perl for Solaris
Conflicts:
config/filter.d/sshd.conf
- OpenSolaris keyboard message matched by new regex 3
- Removed Bye Bye regex per
https://github.com/fail2ban/fail2ban/issues/175#issuecomment-16538036
- PAM auth failure or error and first char case-insensitive, can also
have chars after the hostname. e.g.
Apr 29 16:53:38 Jamess-iMac.local sshd[47831]: error: PAM:
authentication error for james from 205.186.180.101 via 192.168.1.201
Do not trigger sshd bans on pam_unix authentication failures, this will trigger on successful logins on systems that use non-pam_unix authentication (sssd, ldap, etc.).
Noticed while looking at the source (to see the point of ssh-ddos).
POSSIBLE BREAK-IN ATTEMPT - sounds scary? But keep reading
the message. It's not a login failure. It's a warning about
reverse-DNS. The login can still succeed, and if it _does_ fail,
that will be logged as normal.
<exhibit n="1">
Jul 9 05:43:00 brick sshd[18971]: Address 200.41.233.234 maps to host234.advance.com.
ar, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Jul 9 05:43:00 brick sshd[18971]: Invalid user html from 200.41.233.234
</exhibit>
The problem (in my mind) is that some users are stuck with bad dns.
The warning won't stop them from logging in. I'm pretty sure they can't
even see it. But when they exceed a threshold number of logins -
which could be all successful logins - fail2ban will trigger.
fail2ban shouldn't adding additional checks to successful logins
- it goes against the name fail2ban :)
- the first X "POSSIBLE BREAK-IN ATTEMPT"s would be permitted anyway
- if you want to ban bad DNS, the right way is PARANOID in /etc/hosts.deny
I've checked the source of OpenSSH, and this will only affect the
reverse-DNS error. (I won't be offended if you want to check
for yourself though ;)
<exhibit n="2">
$ grep -r -h -C1 'ATTEMPT' openssh-5.5p1/
logit("reverse mapping checking getaddrinfo for %.700s "
"[%s] failed - POSSIBLE BREAK-IN ATTEMPT!", name, ntop);
return xstrdup(ntop);
--
logit("Address %.100s maps to %.600s, but this does not "
"map back to the address - POSSIBLE BREAK-IN ATTEMPT!",
ntop, name);
$
</exhibit>
Steven Hiscocks