Bug #4463
closed
Fix the NTPD Access Restrictions / and other NTPD related issues, including GPS
100%
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)
Updated by Chris Buechler almost 10 years ago
- Target version changed from 2.2.1 to 2.2.2
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.2 to 2.2.3
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.3 to 2.3
Updated by Andrew Stuart over 9 years ago
Anything I can do to help move this along? Do I need to clarify anything?
Updated by Jeremy Porter about 9 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.
Updated by Jeremy Porter about 9 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
Updated by Kill Bill about 9 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.
Updated by Jim Thompson almost 9 years ago
- Assignee changed from Jeremy Porter to Renato Botelho
reassigned due to non-action.
Updated by Jim Pingle almost 9 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.
Updated by Jim Pingle almost 9 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.
Updated by Jim Pingle almost 9 years ago
- % Done changed from 0 to 100
Applied in changeset 31b151809d04c40fd915c129d28cc9b440a0eabe.
Updated by Jim Pingle almost 9 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.
Updated by Chris Buechler over 8 years ago
- Affected Version changed from 2.2 to All