From owner-freebsd-ports-bugs@FreeBSD.ORG Tue Sep 16 05:39:20 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 492901065671 for ; Tue, 16 Sep 2008 05:39:20 +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 888128FC0C for ; Tue, 16 Sep 2008 05:39:19 +0000 (UTC) (envelope-from freebsdports@bindone.de) Received: (qmail 48689 invoked by uid 89); 16 Sep 2008 05:39:17 -0000 Received: from unknown (HELO bombat.bindone.de) (mg@bindone.de@84.151.219.81) by mail.bindone.de with ESMTPA; 16 Sep 2008 05:39:17 -0000 Message-ID: <48CF4675.3090308@bindone.de> Date: Tue, 16 Sep 2008 07:39:01 +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> <48C84E4D.9010303@bindone.de> <0826FC63-68BB-46B5-B228-50E3839EC548@bitchx.it> <48CF03DD.7050100@bindone.de> In-Reply-To: <48CF03DD.7050100@bindone.de> 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: Tue, 16 Sep 2008 05:39:20 -0000 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 >>>> 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" >>> >> > > _______________________________________________ > 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"