From owner-freebsd-ports-bugs@FreeBSD.ORG Wed Sep 10 22:46:48 2008 Return-Path: Delivered-To: freebsd-ports-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C05D8106568B for ; Wed, 10 Sep 2008 22:46:48 +0000 (UTC) (envelope-from freebsdports@bindone.de) Received: from mail.bindone.de (mail.bindone.de [80.190.134.51]) by mx1.freebsd.org (Postfix) with SMTP id 38FF58FC15 for ; Wed, 10 Sep 2008 22:46:48 +0000 (UTC) (envelope-from freebsdports@bindone.de) Received: (qmail 61508 invoked by uid 89); 10 Sep 2008 22:46:46 -0000 Received: from unknown (HELO bombat.bindone.de) (mg@bindone.de@84.151.194.190) by mail.bindone.de with ESMTPA; 10 Sep 2008 22:46:46 -0000 Message-ID: <48C84E4D.9010303@bindone.de> Date: Thu, 11 Sep 2008 00:46:37 +0200 From: Michael User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.16) Gecko/20080818 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Mij References: <200809100940.m8A9e2xo012261@freefall.freebsd.org> In-Reply-To: <200809100940.m8A9e2xo012261@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/126867: security/sshguard-pf 1.1 fails to detect attempted logins X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2008 22:46:48 -0000 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 > To: Michael > 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"