ports/126867: security/sshguard-pf 1.1 fails to detect attempted logins

[Michael]

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"