ports/126867: security/sshguard-pf 1.1 fails to detect attempted logins
Mij
mij at bitchx.it
Mon Sep 15 23:12:12 UTC 2008
Dear Michael,
In my 7.0-PRERELEASE install I have LogLevel set to INFO (default) and
MaxTries to 6 (default), I get
the log messages reported as described; I got similar feedback when
inquiring a 6.x user on this problem.
The reason why the PAM message cannot be used in place of the ssh
message is that the former is not
portable while the latter is. Meaning, to recognize the former it
would be necessary to write one case for
each different implementation of PAM or whatever authentication system
is used, while OpenSSH is
basically standard and portable.
Concerning the "security bug" report, even in presence of this problem
the system's security is not compromised:
even if sshguard blocking doesn't work, what you get is the same level
of security of a default system.
Concerning your "running away": this is the fun of open source, you're
welcome to try alternatives. The
100% cpu has been found in 1.0 and fixed with 1.1. So far, no problems
have been reported for 1.1. Still,
you may want to move to some similar implementations based on regex
and scripts.
I believe we can close the ticket.
michele
On 11 Sep 2008, at 00:46, Michael wrote:
> Okay, I checked the ssh sources to see when the logging message
> you#re checking for is emitted
>
> /usr/src/crypto/openssh/auth.c, around line 250:
>
> void
> auth_log(Authctxt *authctxt, int authenticated, char *method, char
> *info)
> {
> void (*authlog) (const char *fmt,...) = verbose;
> char *authmsg;
>
> if (use_privsep && !mm_is_monitor() && !authctxt->postponed)
> return;
>
> /* Raise logging level */
> if (authenticated == 1 ||
> !authctxt->valid ||
> authctxt->failures >= options.max_authtries / 2 ||
> strcmp(method, "password") == 0)
> authlog = logit;
>
> if (authctxt->postponed)
> authmsg = "Postponed";
> else
> authmsg = authenticated ? "Accepted" : "Failed";
>
> authlog("%s %s for %s%.100s from %.200s port %d%s",
> authmsg,
> method,
> authctxt->valid ? "" : "invalid user ",
> authctxt->user,
> get_remote_ipaddr(),
> get_remote_port(),
> info);
>
>
> Let's check the possibilities to get that message into syslog:
>
> Possibility 1:
> authlog function ptr is set to verbose.
> Verbose is defined as:
>
> /* More detailed messages (information that does not need to go to
> the log). */
>
> void
> verbose(const char *fmt,...)
> {
> va_list args;
>
> va_start(args, fmt);
> do_log(SYSLOG_LEVEL_VERBOSE, fmt, args);
> va_end(args);
> }
>
> do_log checks for:
> if (level > log_level)
> return;
>
>
> So, to get your message in the log one would have to set the
> loglevel for sshd to VERBOSE in /etc/ssh/sshd_config by specifying:
>
> LogLevel VERBOSE
>
> This is not default and not mentioned anywhere in the documentation.
>
> Possibility 2:
> Make the following expression true:
> /* Raise logging level */
> if (authenticated == 1 ||
> !authctxt->valid ||
> authctxt->failures >= options.max_authtries / 2 ||
> strcmp(method, "password") == 0)
> authlog = logit;
>
> Authenticated is not 1 in case of a login failure. Authctxt is valid
> (because it's a valid user), method is not password (but "keyboard
> interactive/pam"). So the only way to have this kick in is to have
> the expression:
>
> authctxt->failures >= options.max_authtries / 2 == true
>
> For some reasons I'm too lazy to look for in the code, the only
> reliable way to get logging on every failed attempt is to set the
> option
> MaxAuthTries to 1 in /etc/ssh/sshd_config (default is 6):
>
> MaxAuthTries 1
>
> This is also neither default nor documented (and btw a stupid
> solution anyway).
>
> So I basically see two options:
> 1. Document that people have to set LogLevel to VERBOSE
> 2. Change the software so it reverts to the old behaviour (which is
> IMHO the better option, because it doesn't force people to change
> their sshd config and would be backwards compatible).
>
> Whatever you do, you should warn users when upgrading the port.
> portupgrade ssguard-pf effectively lowers your systems protection
> level considerably (actually to a point where I would personally
> like to see that in the vulnerability database so portaudit while
> prohibit the upgrade).
>
> Personally I will most probably change away from sshguard anyway
> (besides being really tired of discussing trivial bugs), because
> I've seen too many runaway conditions (sshguard-pf 1.0 as well as
> 1.1) when rotating the logs (last was today eating up 100% CPU,
> which is ironic considering that the sshguard design sacrifices a
> lot of flexibility for maximum efficiency :)
>
> /michael
>
> Mij wrote:
>> The following reply was made to PR ports/126867; it has been noted
>> by GNATS.
>> From: Mij <mij at bitchx.it>
>> To: Michael <freebsdports at bindone.de>
>> Cc: bug-followup at FreeBSD.org
>> Subject: Re: ports/126867: security/sshguard-pf 1.1 fails to detect
>> attempted logins
>> Date: Wed, 10 Sep 2008 11:24:14 +0200
>> The way syslog is configured in a default system wrt what
>> finishes into "auth.log"
>> should impact sshguard only if you poll its content with the so-
>> called "tail+sshguard combo"
>> http://sshguard.sourceforge.net/doc/setup/loggingrawfile.html
>> Under FreeBSD this is not the recommended way (this is the way
>> the port prepares the
>> system), as the system implementation of syslog supports pipes to
>> external tools:
>> http://sshguard.sourceforge.net/doc/setup/loggingsyslog.html
>> In this latter approach, no matter what the original configuration
>> of the system is, syslog
>> is setup to feed sshguard with both messages. Please check that
>> as follows:
>> 1) enable this line:
>> auth.info;authpriv.info |exec /usr/local/sbin/sshguard
>> high in the /etc/syslog.conf file.
>> 2) run /etc/rc.d/syslogd reload
>> if sshguard is still not blocking, you can investigate it further
>> pipe- ing from syslog to
>> an instance of tee that logs and passes through to sshguard.
>> On Sep 6, 2008, at 12:04 , Michael wrote:
>> > No, I'm talking about auth.log. Seriously.
>> > What about trying it on your own on a fresh install?
>> >
>> > Mij wrote:
>> >> The fact you say there is only a single line and "the system
>> logs" >> make me think you're considering /var/log/messages,
>> >> there authentication messages do not appear. What about /var/
>> log/ >> auth.log (or any other destination you set for auth.info)?
>> _______________________________________________
>> freebsd-ports-bugs at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports-bugs
>> To unsubscribe, send any mail to "freebsd-ports-bugs-unsubscribe at freebsd.org
>> "
>
More information about the freebsd-ports-bugs
mailing list