Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Sep 2008 07:39:01 +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:  <48CF4675.3090308@bindone.de>
In-Reply-To: <48CF03DD.7050100@bindone.de>
References:  <200809100940.m8A9e2xo012261@freefall.freebsd.org>	<48C84E4D.9010303@bindone.de>	<0826FC63-68BB-46B5-B228-50E3839EC548@bitchx.it> <48CF03DD.7050100@bindone.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Oh and just two make sure you understood: Blocking works okay for 
unknown logins, it's only an issue for existent logins (did you actually 
read what I wrote in one of my previous mails [ssh source excerpt])

cheers
michael

Michael wrote:
> 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"
>>>
>>
> 
> _______________________________________________
> 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?48CF4675.3090308>