Project

General

Profile

Bug #4463

Fix the NTPD Access Restrictions / and other NTPD related issues, including GPS

Added by Andrew Stuart over 4 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
NTPD
Target version:
Start date:
02/23/2015
Due date:
% Done:

100%

Estimated time:
Affected Version:
All
Affected Architecture:

Description

Access Restrictions once open says "these options control access to NTP from the WAN."
This is incorrect.

It sets the default for all interfaces.
Thus enabling " Enable Kiss-o'-death packets" | "Deny packets that attempt a peer association" result in clients not being able to get a valid time, instead getting "no server suitable for synchronization found" and with debugging "Server dropped: strata too high"
"stratum 16, precision -6, leap 11, trust 000"

Since these options are enabled by default, it would appear all fresh pfSense installs are broken by default.

This should be either fixed to do what it says, or changed to specify it is the defaults for all interfaces, and the options relaxed to allow clients to connect. Better yet, change it to be the default for all interfaces, and explicitly set rules for the lan interface / allow custom rules to be added.

Specifically, unsetting the above two options results in a working configuration on 4 different boxes that were working prior to 2.2. (one being a fresh reinstall)
after changes ntpd.conf looks like:
restrict default nomodify notrap
restrict -6 default nomodify notrap

default options checked:
restrict default kod limited nomodify nopeer notrap
restrict -6 default kod limited nomodify nopeer notrap

btw it would seem there is a lot of issues with the gui on 2.2 with firefox/chrome at least with NTPD, not restoring selected items after save, such as the serial port speed on gps / NMEA sentences, etc. I'm wondering if it has to do with the doctype and using selected="selected" instead of just selected. I haven't had a chance to test it. I also saw this in other places on 2.2 but didn't make notes.

Lastly, I wonder where the garmin Initialization sentences came from. $PGRMC,,,,,,,,,,3,,2,8*5E appears to be off. my reference shows there are 14 options to that, only 13 are specified. Nothing notes whether or not this is acceptable, and I haven't tried to see if it causes an error. also options 12 and 13 are not used, yet specified. see: https://www8.garmin.com/support/pdf/NMEA_0183.pdf

The default $PGRMO sentence turns on ALL sentences, but then you specifically set $PGRMO,GPRMC,1*3D
and a few others, which seems redundant. I wonder if $PGRMO was meant to be set to $PGRMO,,2*75 which turns off all sentences. and then explicitly turn on the few sentences that you have there by default.

(don't forget, the cake is a lie)

Associated revisions

Revision e138f828 (diff)
Added by Renato Botelho over 3 years ago

Clarify text, ticket #4463

Revision 31b15180 (diff)
Added by Jim Pingle about 3 years ago

Move NTP access restrictions to their own tab and add the ability to craft custom restrictions for arbitrary networks. Fixes #4463

History

#1 Updated by Chris Buechler about 4 years ago

  • Target version changed from 2.2.1 to 2.2.2

#2 Updated by Chris Buechler about 4 years ago

  • Target version changed from 2.2.2 to 2.2.3

#3 Updated by Chris Buechler almost 4 years ago

  • Target version changed from 2.2.3 to 2.3

#4 Updated by Andrew Stuart almost 4 years ago

Anything I can do to help move this along? Do I need to clarify anything?

#5 Updated by Jim Thompson over 3 years ago

  • Assignee set to Jeremy Porter

#6 Updated by Jeremy Porter over 3 years ago

  • Status changed from New to Confirmed

services_ntpd needs be updated to allow the selection of access controls on a per interface basis.

#7 Updated by Jeremy Porter over 3 years ago

  • Subject changed from Fix the NTPD lies (Access Restrictions) / and other NTPD related issues, including GPS to Fix the NTPD Access Restrictions / and other NTPD related issues, including GPS

#8 Updated by Kill Bill over 3 years ago

ntpd[6281]: restrict: 'monitor' cannot be disabled while 'limited' is enabled

This is by default broken configuration everywhere incl. 2.3. This fsck up is now visible thanks to http://bugs.ntp.org/show_bug.cgi?id=2612

monitor
Enables the monitoring facility. See the ntpq program and the monstats and mrulist commands, as well as the Access Control Options for details. The monitoring facility is also enabled by the presence of limited in any restrict commands. The default for this flag is enable.

Guys - could someone actually read the NTP docs and come up with working defaults as minimum. Considering the

//prevent NTP reflection attack, see https://forum.pfsense.org/index.php/topic,67189.msg389132.html#msg389132

comment in system.inc's system_ntp_configure() - as you can see aboe, this is no-op, has always been no-op and will remain no-op until you figure out what you actually want.

#9 Updated by Jim Thompson over 3 years ago

  • Assignee changed from Jeremy Porter to Renato Botelho

reassigned due to non-action.

#10 Updated by Jim Pingle about 3 years ago

  • Assignee changed from Renato Botelho to Jim Pingle

Renato is busy at the moment, I'll see what I can do for this one.

#11 Updated by Jim Pingle about 3 years ago

  • Status changed from Confirmed to Feedback

I moved the default Access Restrictions to their own tab and then added a mechanism to define custom access restrictions. The defaults are still the same (Aside from removing the now-unnecessary 'disable monitor'), but it's possible to craft custom restrictions to allow whatever networks you want to query the NTP server on the firewall.

We could maybe consider adding some default ACL entries to allow LAN but I'd rather err on the side of security when the previous default was to have NTP act as a client only for the firewall, which was/is the default behavior. If someone wants to enable it as a server for LAN, they can easily define an ACL to allow LAN now.

#12 Updated by Jim Pingle about 3 years ago

  • % Done changed from 0 to 100

#13 Updated by Jim Pingle about 3 years ago

  • Status changed from Feedback to Resolved

Looks good on another system as well, can't seem to break the new code.

Also of note, likely due to changes in ntpd the original problem as stated is not currently an issue. I tried several systems that did not have the new changes and even with the default settings for access a client can obtain the time from the NTP daemon, but various other combinations do result in preventing the client from obtaining the current time. Even so, having a flexible ACL system is much nicer so that access can be more tightly controlled in a granular way.

#14 Updated by Chris Buechler about 3 years ago

  • Affected Version changed from 2.2 to All

Also available in: Atom PDF