From owner-freebsd-security@FreeBSD.ORG Sat Mar 15 18:33:49 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 77B7197D; Sat, 15 Mar 2014 18:33:49 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 15E84852; Sat, 15 Mar 2014 18:33:48 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id MAA04912; Sat, 15 Mar 2014 12:33:31 -0600 (MDT) Message-Id: <201403151833.MAA04912@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 15 Mar 2014 12:32:37 -0600 To: d@delphij.net, d@delphij.net, Fabian Wenk , freebsd-security@freebsd.org From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <53248B48.5040108@delphij.net> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> <5323AF47.9080107@delphij.net> <201403150343.VAA27172@mail.lariat.net> <5323E670.5020905@delphij.net> <201403150931.DAA29130@mail.lariat.net> <53248B48.5040108@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ollivier Robert , hackers@lists.ntp.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: Sat, 15 Mar 2014 18:33:49 -0000 At 11:18 AM 3/15/2014, Xin Li wrote: >Either it wouldn't or my test was wrong. My test was 'ntpdc -c >monlist' and tcpdump. My test was to actually expose the server to the attack I was experiencing. Note that these packets might not have been exactly the same ones that are sent by ntpdc. For every packet it received, the server sent a rejection to the source IP, which was spoofed. The relaying stopped when I added the lines I mentioned in my previous message to the configuration file. It is good practice to have those lines in the file anyway, to provide effective access control. If one does not intend to be running a public NTP server, the server should not be open to the world; in fact, it should probably be behind a stateful firewall that does not accept packets destined for UDP port 123 from the Internet at large unless they are known to be responses to queries. I've implemented this in the IPFW rules of all of my servers. --Brett Glass