From owner-freebsd-ports@FreeBSD.ORG Mon Apr 14 09:47:46 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D60CF81A; Mon, 14 Apr 2014 09:47:46 +0000 (UTC) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by mx1.freebsd.org (Postfix) with ESMTP id E31C91A11; Mon, 14 Apr 2014 09:47:45 +0000 (UTC) X-Trace: 87939530/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/pipex-temporary-group/81.170.77.156/None/crees@bayofrum.net X-SBRS: None X-RemoteIP: 81.170.77.156 X-IP-MAIL-FROM: crees@bayofrum.net X-SMTP-AUTH: bayofrum@uwclub.net X-MUA: K-9 Mail for Android X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsGABuuS1NRqk2c/2dsb2JhbABagwaEIsAMgSAXdIIlAQEBBCMPASMjEAsOCgICJgICOR4GAQ0Fh3wEqEKiRxeBKYgdLYQqAQEIRweCb4FJAQOYYYY9F4tvgzKBcQ X-IPAS-Result: AlsGABuuS1NRqk2c/2dsb2JhbABagwaEIsAMgSAXdIIlAQEBBCMPASMjEAsOCgICJgICOR4GAQ0Fh3wEqEKiRxeBKYgdLYQqAQEIRweCb4FJAQOYYYY9F4tvgzKBcQ X-IronPort-AV: E=Sophos;i="4.97,856,1389744000"; d="scan'208";a="87939530" X-IP-Direction: OUT Received: from 81-170-77-156.dynamic.dsl.as9105.com (HELO pegasus.bayofrum.net) ([81.170.77.156]) by smtp.pipex.tiscali.co.uk with ESMTP; 14 Apr 2014 10:47:44 +0100 Received: from [10.195.109.87] (unknown [149.254.181.146]) by pegasus.bayofrum.net (Postfix) with ESMTPSA id 5A7485DAF2; Mon, 14 Apr 2014 10:47:32 +0100 (BST) User-Agent: K-9 Mail for Android In-Reply-To: <534BAC12.9090704@freebsd.org> References: <53453547.2070307@uni-bielefeld.de> <534BAC12.9090704@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: FreeBSD Port: security/sshguard-pf From: Chris Rees Date: Mon, 14 Apr 2014 10:47:23 +0100 To: Stefan Esser , Benjamin Podszun , freebsd-ports@freebsd.org Message-ID: <022c964d-3478-4ad2-ac9d-a1749960c92e@email.android.com> X-bayofrum-MailScanner-Information: Please contact the ISP for more information X-bayofrum-MailScanner-ID: 5A7485DAF2.A2ADF X-bayofrum-MailScanner: Found to be clean X-bayofrum-MailScanner-From: crees@bayofrum.net X-Spam-Status: No Cc: crees@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 09:47:47 -0000 On 14 April 2014 10:36:18 BST, Stefan Esser wrote: >Am 14.04.2014 10:25, schrieb Benjamin Podszun: >> Looking at the rc script and the diff [1] the problem's easy enough: >> ${sshguard_pidfile} is passed as parameter to -i, but isn't set in >the >> script/has no default value. Either the related line from the >previous >> revision should be revived or the substitution should change to use >> ${pidfile}, which _is_ set. > >I just installed sshguard on one of my servers and noticed the same >problem. The program is not started due to several bugs: > >1) $sshguard_pidfile vs. $pidfile as noticed by you This one's my fault, sorry. >2) Pasing of log files to watch. They are correctly processed by > sshguard_prestart(), but the result is not pasted into the > command line. (You can manually add "-l " options to > the command line in the rc script as a work around ...) Don't think this one is, but I'll investigate. Chris >There are other deficiencies: > >a) The documentation lacks details about the mechanism used to block > attacks. E.g. in case of IPFW, blocking rules are injected in lines > 55000 to 55050. You have to adapt your ruleset in such a way, that > any to-be-blocked service is only enabled at a later line, or the > blocking is ineffective. This port range should be mentioned at > least in the pkg message for ipfw. Better would be a section in > the man page, which explains the mechanism used by each backend. > >b) The security/sshguard-ipfw port is marked as NO_STAGE=no, while > security/sshguard seems to work just fine with staging enabled. > This is probably an oversight: when sshguard was fixed/verified > for staging, the sub-ports where not marked as staging clean. > >c) The MAKE_ARGS variable mention ACLOCAL, AUTOCONF and AUTOMAKE, but > no dependencies are registered for any of them. > >d) The master port's Makefile lists hosts, pf, and ipfw as possible > backends, selected by SSHGUARDFW, but does not mention ipfilter > as the fourth supported backend. > >I did not have time to check the code quality of the parser. I'm a >bit suspicious, that it might be possible to attack sshguard via >parameters passed under control of an attacker. > >If you create a PR, you may want to add these points to the PR ... > >Regards, STefan -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.