Date: Tue, 16 Sep 2008 02:54:53 +0200 From: Michael <freebsdports@bindone.de> To: Mij <mij@bitchx.it> Cc: freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/126867: security/sshguard-pf 1.1 fails to detect attempted logins Message-ID: <48CF03DD.7050100@bindone.de> In-Reply-To: <0826FC63-68BB-46B5-B228-50E3839EC548@bitchx.it> References: <200809100940.m8A9e2xo012261@freefall.freebsd.org> <48C84E4D.9010303@bindone.de> <0826FC63-68BB-46B5-B228-50E3839EC548@bitchx.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mij,
I would be really interesting to get some input on this from a third
party, because I tried it on 5 different 7.0-RELEASE, 2 6.3-RELEASE and
one 6.2-RELEASE machine, it's all the same. Of course, sshguard is
optional to a standard system, but if it's part of your strategy it
still lowers the security level of your system, especially because this
way you can find valid logins for the machine. Can you do me a favour
and send me all the relevant configuration files of your install
(/etc/syslog.conf, /etc/ssh/sshd_config, /etc/pam.d/* and maybe also a
tarball of /usr/src/crypto/openssh - doesn't have to be to the list)?
Even if it's not that much about sshguard, I really would like to
understand this difference in behaviour between our machines, especially
because as soon as I set LogLevel to VERBOSE it works and logs as expected.
(btw. all of my /etc/syslog.conf say:
auth.info;authpriv.info |exec /usr/local/sbin/sshguard
auth.info;authpriv.info /var/log/auth.log)
All of this just doesn't add up at all :(
michael
Mij wrote:
> 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@bitchx.it>
>>> To: Michael <freebsdports@bindone.de>
>>> Cc: bug-followup@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@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports-bugs
>>> To unsubscribe, send any mail to
>>> "freebsd-ports-bugs-unsubscribe@freebsd.org"
>>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48CF03DD.7050100>