Re: xntp both serve and client
- From: Steve Kostecke <kostecke@xxxxxxx>
- Date: 06 Nov 2008 05:12:19 GMT
On 2008-11-06, fenwayfool <peterson.russell@xxxxxxxxx> wrote:
Thanks for the replies everyone. The system I have is an embedded
system and the NTP software was ported (to a non-Linux OS) a while
back so I guess it was called xntp when that work was done. In this
environment, we only use NTP as a client.
The current stable version of the NTP Reference Implementation is
4.2.4p5
I have modified the ntp.config to restrict access... but the port
still shows up on port scans.
ntpd binds UDP port 123 on all interfaces.
The access restrictions don't change this binding.
My problem is, customers... not me... don't like port 123 showing up
as open.
It is up to you to convince your customers that this is not a problem.
The port scan shows that ntpd is listening on 123/UDP. But the port scan
does not show that the Access Restrictions are causing ntpd to drop all
packets except those explicitly allowed.
I suspect this is because they are thinking more along the
lines of a simple SNTP sequence that goes like:
1. open socket (using a random port > 1023 as the source port)
2. send message (port 123 is dest port)
3. wait for reply 4. close socket
ntpd is continuously disciplining the clock and, since it is
continuously running port 123/UDP is continuously bound.
Step #3 has a timeout period associated with it. True, a source port !
= 123 violates the RFC strictly speaking... but it works.
Some time servers will not accept connections when the source port is
not 123.
NTP seems a bit more involved. It even seems like if I configure a
server... and the code has trouble reaching the server... that it may
revert into a "listen to NTP broadcast messages" like mode???
If you tell ntpd to poll certain servers that is what it will do.
If you tell ntpd to listen for broadcast packets that is what it will
do.
There is no facility for the sort of reversion you are suggesting.
--
Steve Kostecke <kostecke@xxxxxxx>
NTP Public Services Project - http://support.ntp.org/
.
- Follow-Ups:
- Re: xntp both serve and client
- From: Hal Murray
- Re: xntp both serve and client
- References:
- xntp both serve and client
- From: fenwayfool
- Re: xntp both serve and client
- From: Maarten Wiltink
- Re: xntp both serve and client
- From: fenwayfool
- xntp both serve and client
- Prev by Date: Re: xntp both serve and client
- Next by Date: Re: xntp both serve and client
- Previous by thread: Re: xntp both serve and client
- Next by thread: Re: xntp both serve and client
- Index(es):
Relevant Pages
|