From owner-freebsd-ports-bugs@FreeBSD.ORG Mon Sep 15 23:12:12 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 0976D106566C for ; Mon, 15 Sep 2008 23:12:12 +0000 (UTC) (envelope-from mij@bitchx.it) Received: from aa012msr.fastwebnet.it (aa012msr.fastwebnet.it [85.18.95.72]) by mx1.freebsd.org (Postfix) with ESMTP id 55A258FC12 for ; Mon, 15 Sep 2008 23:12:11 +0000 (UTC) (envelope-from mij@bitchx.it) Received: from mbp-michele.lan (84.75.159.112) by aa012msr.fastwebnet.it (8.0.013.8) (authenticated as michele.mazzucchi) id 48CE63900011965F; Tue, 16 Sep 2008 01:00:18 +0200 Message-Id: <0826FC63-68BB-46B5-B228-50E3839EC548@bitchx.it> From: Mij To: Michael In-Reply-To: <48C84E4D.9010303@bindone.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 16 Sep 2008 01:00:17 +0200 References: <200809100940.m8A9e2xo012261@freefall.freebsd.org> <48C84E4D.9010303@bindone.de> X-Mailer: Apple Mail (2.926) 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: Mon, 15 Sep 2008 23:12:12 -0000 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 >> 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 >> " >