From owner-freebsd-security@FreeBSD.ORG Mon Jan 27 15:39:07 2014 Return-Path: Delivered-To: freebsd-security@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 ABEFCB89 for ; Mon, 27 Jan 2014 15:39:07 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5C314B2 for ; Mon, 27 Jan 2014 15:39:07 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 77CA723C9; Mon, 27 Jan 2014 15:39:00 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id A01FB31605; Mon, 27 Jan 2014 16:39:04 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Fabian Wenk Subject: Re: UNS: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <21199.26019.698585.355699@hergotha.csail.mit.edu> <868uuid7y3.fsf@nine.des.no> <52D7A867.7070607@wenks.ch> Date: Mon, 27 Jan 2014 16:39:04 +0100 In-Reply-To: <52D7A867.7070607@wenks.ch> (Fabian Wenk's message of "Thu, 16 Jan 2014 10:37:43 +0100") Message-ID: <86fvo9cu3r.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 15:39:07 -0000 Fabian Wenk writes: > I think it is a bad advice, then ntpd is much nicer to NTP servers > (mainly the NTP Pool), then sntp is. [snip irrelevant details] ntpd is a particular implementation of the NTP protocol and algorithm. SNTP is a protocol. Comparing one to the other is simply meaningless. It is entirely possible to write a well-behaved SNTP client. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Jan 28 05:30:13 2014 Return-Path: Delivered-To: freebsd-security@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 082F7747 for ; Tue, 28 Jan 2014 05:30:13 +0000 (UTC) Received: from t4.revido.de (t4.revido.de [88.80.214.247]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB70186D for ; Tue, 28 Jan 2014 05:30:12 +0000 (UTC) Received: by t3.revido.de (Postfix, from userid 1000) id B840551B80CD; Tue, 28 Jan 2014 05:41:43 +0100 (CET) X-Spam-DCC: sonic.net: t3.revido.de 1156; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on t3.revido.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=none autolearn=disabled version=3.1.7-deb Received: from eight.rr1.revido.de (eight.rr1.revido.de [94.101.38.24]) by t3.revido.de (Postfix) with ESMTP id D3C4451B80CA for ; Tue, 28 Jan 2014 05:41:42 +0100 (CET) Received: from computer.home (188-22-62-129.adsl.highway.telekom.at [188.22.62.129]) by eight.rr1.revido.de (Postfix) with ESMTPA id 9E07E856A93 for ; Tue, 28 Jan 2014 05:41:42 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: online cheksum verification for FreeBSD From: Elmar Stellnberger In-Reply-To: <4BA27CDF.1040107@gmail.com> Date: Tue, 28 Jan 2014 05:41:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA27CDF.1040107@gmail.com> To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.1283) X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with clamdscan / ClamAV 0.95.3/18405/Mon Jan 27 20:37:09 2014 X-Mailman-Approved-At: Tue, 28 Jan 2014 12:26:50 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 05:30:13 -0000 A respective tool for Debian based distros has just been released = (http://www.elstel.org/debcheckroot). It takes a somewhat simpler approach than its rpm-based counterpart and = may serve as a prove of concept. The only thing that is required is a sha/md5sum list for each package = (as private keys tend to be stolen relying on them is not a good idea either way). If we already have = sha1sums somewhere in the package header it should be possible to port the tool. However locally stored = checksums are not of use as they can be manipulated arbitrarily. Elmar Am 18.03.2010 um 20:19 schrieb Elmar Stellnberger: >=20 > Unfortunately pkg_check&sign do not seem to exist any more: >=20 > from 8.0 relnotes: "The pkg_sign and pkg_check utilities for = cryptographically signing FreeBSD packages have been removed. They were = only useful for packages compressed using gzip(1); however bzip2(1) = compression has been the norm for some time now. >=20 > Besides this I would need pkg_sign to take the checksums from the = respective .tbz instead of the local file system. > " For sha1, it checksums the file and verifies that the result = matches the list of checksums recorded in /var/db/pkg/SHA1." >=20 > Moreover I would need a script that just downloads the package = headers; not the whole packages > because otherwise the check procedure would last aeons. >=20 > I thought there was a version of bzip2 that did signing/encrypting but = guess not ... in any case it is not what freebsd uses >=20 > That way it seemes to me as the easiest viable way to simply provide = external checksum lists as the package management depeers a proper = checksum handling. Such lists do already exist for Windows and OSX. That = way we would not even need a new tool; just checksum lists the user can = verify himself. For Linux on the other hand cheksums are provided by the = package headers so that we do not need separate checksum lists. >=20 > > > > You can download the packages from: > > > = ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-stable/ > > > and run pkg_check You might be able to extract the = signature > > from the package. > > > The packages themselves are signed. There is no separate > > signature file. /etc/ssl/pkg.crt is the location of the public > > key for the packages. > > =20 >=20 > P.S.: Sorry for my late reply > I must have overlloked your message as I have not been subscribed to = freebsd-security. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to = "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Tue Jan 28 12:32:20 2014 Return-Path: Delivered-To: freebsd-security@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 CDD0068F for ; Tue, 28 Jan 2014 12:32:20 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D9BE185D for ; Tue, 28 Jan 2014 12:32:20 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 32A9620EF9 for ; Tue, 28 Jan 2014 07:32:19 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 28 Jan 2014 07:32:19 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=CAYNhen4h7dN9ZG/86iRmWcW6+M=; b=sGa Pf/Xo5Ru+ng1MrWFaF//aczLsrJGkMg+TZTYpTuteNoKlFOf5fnTQFyzH7TSVK4R z9pzHLRdbNV/y8ulOixh6XZ2rFABgEnHQ1J/U7bDMRe2wAuWXDHb3BfA/ghU7tPR SpZJlsnnE2HfWEU0rFUGmkiMS4eHl4TvmHOZuSZI= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 11CB710709F; Tue, 28 Jan 2014 07:32:19 -0500 (EST) Message-Id: <1390912339.18287.76258365.0317802C@webmail.messagingengine.com> X-Sasl-Enc: ODOanWMo93kq7aBCP5NbISjjk4QyaGCeAgkcvCmR9JAV 1390912339 From: Mark Felder To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-1b692d69 In-Reply-To: References: <4BA27CDF.1040107@gmail.com> Subject: Re: online cheksum verification for FreeBSD Date: Tue, 28 Jan 2014 06:32:19 -0600 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 12:32:20 -0000 On Mon, Jan 27, 2014, at 22:41, Elmar Stellnberger wrote: > However locally stored > checksums are not of use as they can > be manipulated arbitrarily. > This shouldn't be a concern when using signed packages, correct? Or if that's still a problem couldn't we just teach `pkg check` to confirm signature of the repository matches before verifying checksums? From owner-freebsd-security@FreeBSD.ORG Wed Jan 29 14:31:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E01BE8C4 for ; Wed, 29 Jan 2014 14:31:16 +0000 (UTC) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F7801F5C for ; Wed, 29 Jan 2014 14:31:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from flashback.wenks.ch (fabian@flashback.wenks.ch [IPv6:2001:8a8:1005:1::4]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id s0TEVDbx051387 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 29 Jan 2014 15:31:13 +0100 (CET) (envelope-from fabian@wenks.ch) Message-ID: <52E910B0.4030606@wenks.ch> Date: Wed, 29 Jan 2014 15:31:12 +0100 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: portscans and blackhole References: <52DD08F7.1000306@hfbk-hamburg.de> In-Reply-To: <52DD08F7.1000306@hfbk-hamburg.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 14:31:16 -0000 Hello On 20.01.14 12:31, sa9k063 wrote: > can someone please explain: > > one of my boxes gets portscanned often by some likely infected laptops. > While having set > > net.inet.tcp.blackhole=1 > > there are still messages like > > +Limiting closed port RST response from 348 to 200 packets/sec According to the blackhole(4) manpage (from a FreeBSD 9.1 system): ---8<------------------------------------------------------------ SYNOPSIS sysctl net.inet.tcp.blackhole[=[0 | 1 | 2]] sysctl net.inet.udp.blackhole[=[0 | 1]] Part of DESCRIPTION: Normal behaviour, when a TCP SYN segment is received on a port where there is no socket accepting connections, is for the system to return a RST segment, and drop the connection. The connecting system will see this as a “Connection refused”. By setting the TCP blackhole MIB to a numeric value of one, the incoming SYN segment is merely dropped, and no RST is sent, making the system appear as a blackhole. By setting the MIB value to two, any segment arriving on a closed port is dropped without returning a RST. This provides some degree of protection against stealth port scans. ---8<------------------------------------------------------------ So it is possible, that you are hit with something else then SYN packets and should probably set net.inet.tcp.blackhole=2, or even with UDP packets, then also set net.inet.udp.blackhole=1. What output does 'sysctl -a | grep blackhole' show? bye Fabian From owner-freebsd-security@FreeBSD.ORG Wed Jan 29 17:32:23 2014 Return-Path: Delivered-To: freebsd-security@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 5962AB6F for ; Wed, 29 Jan 2014 17:32:23 +0000 (UTC) Received: from ak47.hfbk-hamburg.de (ak47.hfbk-hamburg.de [193.174.241.201]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC66124E for ; Wed, 29 Jan 2014 17:32:22 +0000 (UTC) Received: from [193.174.241.176] (ting.hfbk.net [193.174.241.176]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ak47.hfbk-hamburg.de (Postfix) with ESMTPSA id 217ED3497F for ; Wed, 29 Jan 2014 18:24:17 +0100 (CET) Message-ID: <52E93941.7080002@hfbk-hamburg.de> Date: Wed, 29 Jan 2014 18:24:17 +0100 From: sa9k063 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 CC: freebsd-security@freebsd.org Subject: Re: portscans and blackhole References: <52DD08F7.1000306@hfbk-hamburg.de> <52E910B0.4030606@wenks.ch> In-Reply-To: <52E910B0.4030606@wenks.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 17:32:23 -0000 Hello, On 01/29/2014 03:31 PM, Fabian Wenk wrote: >> net.inet.tcp.blackhole=1 >> >> +Limiting closed port RST response from 348 to 200 packets/sec > > According to the blackhole(4) manpage (from a FreeBSD 9.1 system): > > ---8<------------------------------------------------------------ > SYNOPSIS > sysctl net.inet.tcp.blackhole[=[0 | 1 | 2]] > sysctl net.inet.udp.blackhole[=[0 | 1]] > > Part of DESCRIPTION: > system will see this as a “Connection refused”. By setting the TCP > blackhole MIB to a numeric value of one, the incoming SYN segment is > merely dropped, and no RST is sent, making the system appear as a > blackhole. By setting the MIB value to two, any segment arriving on > a closed port is dropped without returning a RST. This provides > some degree of protection against stealth port scans. This added to the confusion and thus made me ask. The manpage says for both values of net.inet.tcp.blackhole={1,2} that no RSTs are sent out. Both seem to drop SYNs and suppress sending a RST. Reading it again, the only conclusion i could get to regarding the difference between 1 and 2 would be that for a value of 2, all other tcp packets with flags other than SYN are additionally ignored. Is this a better way to understand it ? > So it is possible, that you are hit with something else then SYN > packets and should probably set net.inet.tcp.blackhole=2, or even > with UDP packets, then also set net.inet.udp.blackhole=1. this remains as a likely explanation, ie FIN scans etc. > What output does 'sysctl -a | grep blackhole' show? it used to be net.inet.tcp.blackhole: 1 net.inet.udp.blackhole: 1 since setting the tcp value to 2 no more messages like these popped up supporting your line of thought. > bye > Fabian thank you, Tee From owner-freebsd-security@FreeBSD.ORG Thu Jan 30 18:31:48 2014 Return-Path: Delivered-To: freebsd-security@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 E47BC878 for ; Thu, 30 Jan 2014 18:31:48 +0000 (UTC) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 71E8C1830 for ; Thu, 30 Jan 2014 18:31:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from flashback.wenks.ch (fabian@flashback.wenks.ch [IPv6:2001:8a8:1005:1::4]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id s0UIViGM021513 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 30 Jan 2014 19:31:45 +0100 (CET) (envelope-from fabian@wenks.ch) Message-ID: <52EA9A90.4040608@wenks.ch> Date: Thu, 30 Jan 2014 19:31:44 +0100 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: portscans and blackhole References: <52DD08F7.1000306@hfbk-hamburg.de> <52E910B0.4030606@wenks.ch> <52E93941.7080002@hfbk-hamburg.de> In-Reply-To: <52E93941.7080002@hfbk-hamburg.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 18:31:49 -0000 Hello On 29.01.14 18:24, sa9k063 wrote: > On 01/29/2014 03:31 PM, Fabian Wenk wrote: >> system will see this as a “Connection refused”. By setting the TCP >> blackhole MIB to a numeric value of one, the incoming SYN segment is >> merely dropped, and no RST is sent, making the system appear as a >> blackhole. By setting the MIB value to two, any segment arriving on >> a closed port is dropped without returning a RST. This provides >> some degree of protection against stealth port scans. > > This added to the confusion and thus made me ask. The manpage says > for both values of net.inet.tcp.blackhole={1,2} that no RSTs are > sent out. > Both seem to drop SYNs and suppress sending a RST. > > Reading it again, the only conclusion i could get to regarding the > difference between 1 and 2 would be that for a value of 2, all other > tcp packets with flags other than SYN are additionally ignored. Is > this a better way to understand it ? Yes. I read it this way: If set to 1, it does drop and not send RST only for SYN packets, if set to 2, it does drop and not send RST for all packets. >> So it is possible, that you are hit with something else then SYN >> packets and should probably set net.inet.tcp.blackhole=2, or even >> with UDP packets, then also set net.inet.udp.blackhole=1. > > this remains as a likely explanation, ie FIN scans etc. > >> What output does 'sysctl -a | grep blackhole' show? > > it used to be > > net.inet.tcp.blackhole: 1 > net.inet.udp.blackhole: 1 > > since setting the tcp value to 2 no more messages like these popped > up supporting your line of thought. Then the behavior does match the man page and how I did understand it. bye Fabian