On 25.3.2014, at 15.48, Olafur Gudmundsson <o...@ogud.com> wrote: > > On Mar 25, 2014, at 8:00 AM, freebsd-security-requ...@freebsd.org wrote: > >> >> Message: 1 >> Date: Mon, 24 Mar 2014 11:02:08 -0400 >> From: Gary Palmer <gpal...@freebsd.org> >> To: Brett Glass <br...@lariat.org> >> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, >> Remko Lodder <re...@freebsd.org>, "Ronald F. Guilmette" >> <r...@tristatelogic.com> >> Subject: Re: NTP security hole CVE-2013-5211? >> Message-ID: <20140324150208.ga5...@in-addr.com> >> Content-Type: text/plain; charset=us-ascii >> >> On Fri, Mar 21, 2014 at 06:13:10PM -0600, Brett Glass wrote: >>> At 03:28 PM 3/21/2014, Remko Lodder wrote: >>> >>>> Ofcourse the software should be well protected as well, and secteam@ did >>>> his >>>> best to offer the best solution possible. Though as mentioned by Brett for >>>> example we just cannot force the update of ntpd.conf on user machines >>>> because >>>> every admin could have legitimate reasons for having a configuration in >>>> place >>>> they decided to have. It's risky to change those things and especially >>>> enforce >>>> them on running machines. Most of his ideas were in the advisory already >>>> except for the 'disable monitor' part, which might be reason to discuss >>>> whether that makes sense or not. >>> >>> I've suggested one other thing, and still think it would be a good idea to >>> thwart attacks: that we compile ntpd to source outgoing queries from >>> randomly >>> selected ephemeral UDP ports rather than UDP port 123. (This was, >>> in fact, done >>> in earlier releases of FreeBSD and I'm unsure why it was changed.) This >>> makes >>> stateful firewalling less necessary and improves its performance if it is >>> done. >> >> >> Could you please explain how randomising the source port of NTP queries >> would thwart NTP monitor amplification attacks? The attack works because >> the NTP control port on the server is always UDP/123, and I don't see how >> changing the source port would fix that. Unless I'm missing something, you'd >> need to change the port the daemon accepts queries on, not the port it >> sources >> outbound queries on. >> >> Thanks, >> >> Gary > > There are three problems > 0. NTP can be tricked to give out big answer to forged addresses. > 1. Some NTP servers listen on port 123 all address even when only expecting > to providing service on > "internal addresses", > 2. NTP servers are easily discoverable due to the listening on fixed port. > > Moving the servers of port 123 will make the search for servers harder but > intrusion detection systems > will need to be modified to expect NTP traffic on any port. > > IF and ONLY if people are willing to change how NTP servers are discovered in > DNS then servers > can listen on any port. > Instead of loping up "A/AAAA" record for a name, the service discovery should > look up SRV record as > that includes port number on each server. Even if everyone agrees to make > this change > there still has to be "temporarily" backwards hack to allow old software to > find the service. > (In the mail world MX (SRV equivalent) use is not universal after over 25 > years). > > So while it is possible to move NTP servers off port 123 I do not think it is > worth the effort. > > Olafur > > I believe Gary was talking about changing the control/status port and not the actual service port (UDP 123). That should be doable without breaking compatibility with existing NTP tools.
-Kimmo
signature.asc
Description: Message signed with OpenPGP using GPGMail
