xntp both serve and client - NTP

This is a discussion on xntp both serve and client - NTP ; Hello, Is it possible to turn off xntp server functionality? That is, xntpd seems to always have port 123 open. This shows up on a port scan even though the system I have really only requires client functionality. Seems like ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: xntp both serve and client

  1. xntp both serve and client

    Hello,

    Is it possible to turn off xntp server functionality?

    That is, xntpd seems to always have port 123 open. This shows up on a
    port scan even though the system I have really only requires client
    functionality. Seems like I could restrict server access via the
    ntp.conf file but port 123 would still be open... I don't want random
    port scans to show the port as open.


  2. Re: xntp both serve and client

    On 2008-11-05, fenwayfool wrote:

    > Is it possible to turn off xntp server functionality?


    No.

    The only difference between an ntpd which is a "server" and an ntpd
    which is a "client" is that the former replies to polls from other ntpds
    (or other [s]ntp clients).

    BTW: xntp is the name that was used for ntp version 3.*'; it is now
    known as "ntp".

    > That is, xntpd seems to always have port 123 open.


    ntpd binds port 123 on all interfaces. Whether or not this port is
    "open" depends on your host firewall, upstream firewalls, and the ntpd
    access restrictions.

    > This shows up on a port scan even though the system I have really only
    > requires client functionality. Seems like I could restrict server
    > access via the ntp.conf file but port 123 would still be open... I
    > don't want random port scans to show the port as open.


    Please see http://support.ntp.org/Support/AccessRestrictions to learn
    about setting ntpd access restrictions.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  3. Re: xntp both serve and client

    fenwayfool wrote:
    > Hello,
    >
    > Is it possible to turn off xntp server functionality?


    As noted, the real xntpd is obsolete, although some distributors refused
    to change to the new name. Historically, it started as ntpd, then got
    renamed to xntpd to distinguish version 3 from the older version. It
    was renamed back to ntpd for the, current, version 4.

    >
    > That is, xntpd seems to always have port 123 open. This shows up on a


    ntpd needs port 123 UDP open in order to receive the replies to its
    polls, or broadcast packets.

  4. Re: xntp both serve and client

    "fenwayfool" wrote in message
    news:9fa0247a-eb93-4ae2-a0ac-af96cc20329f@w1g2000prk.googlegroups.com...

    > Is it possible to turn off xntp server functionality?


    Effectively, yes. Strictly, no.


    > That is, xntpd seems to always have port 123 open. This shows up on a
    > port scan even though the system I have really only requires client
    > functionality. Seems like I could restrict server access via the
    > ntp.conf file but port 123 would still be open... I don't want random
    > port scans to show the port as open.


    It's _UDP_ port 123. UDP being stateless, if you want to hear replies
    to your queries, you need to listen some of the time. The easiest way
    to do that, is to listen all of the time. NTP takes that way.

    If you have a very smart firewall, you could configure it to only let
    the port show as open for a few seconds after a request came out of it.
    Don't come asking me how to do that, though, it's way over my head.

    As a benefit, NTP will provide diagnostic information when asked on
    that same port. You may not care for it, but it allows for easy
    checking that an NTP client is actually running well and where it's
    getting its time from and so on.

    Groetjes,
    Maarten Wiltink



  5. Re: xntp both serve and client

    On Nov 5, 4:30*pm, "Maarten Wiltink"
    wrote:
    > "fenwayfool" wrote in message
    >
    > news:9fa0247a-eb93-4ae2-a0ac-af96cc20329f@w1g2000prk.googlegroups.com...
    >
    > > Is it possible to turn off xntp server functionality?

    >
    > Effectively, yes. Strictly, no.
    >
    > > That is, xntpd seems to always have port 123 open. *This shows up on a
    > > port scan even though the system I have really only requires client
    > > functionality. *Seems like I could restrict server access via the
    > > ntp.conf file but port 123 would still be open... I don't want random
    > > port scans to show the port as open.

    >
    > It's _UDP_ port 123. UDP being stateless, if you want to hear replies
    > to your queries, you need to listen some of the time. The easiest way
    > to do that, is to listen all of the time. NTP takes that way.
    >
    > If you have a very smart firewall, you could configure it to only let
    > the port show as open for a few seconds after a request came out of it.
    > Don't come asking me how to do that, though, it's way over my head.
    >
    > As a benefit, NTP will provide diagnostic information when asked on
    > that same port. You may not care for it, but it allows for easy
    > checking that an NTP client is actually running well and where it's
    > getting its time from and so on.
    >
    > Groetjes,
    > Maarten Wiltink


    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.

    I have modified the ntp.config to restrict access... but the port
    still shows up on port scans. I believe this is because the UDP port
    scans simply send a packet to the port number... if no reply is seen,
    it is assumed the port is open. If the port is closed, an ICMP packet
    is returned by the network stack. Still, restricting access is a good
    thing. My problem is, customers... not me... don't like port 123
    showing up as open. 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

    Step #3 has a timeout period associated with it. True, a source port !
    = 123 violates the RFC strictly speaking... but it works.

    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??? Not
    sure about that but some comments suggest it at first glance. That
    would be another reason to keep port 123 open, I guess.

    Anyway, I very much appreciate the responses everyone. Thanks.


  6. Re: xntp both serve and client


    >ntpd needs port 123 UDP open in order to receive the replies to its
    >polls, or broadcast packets.


    That's the way the current code operates.

    If you are running in client only mode, you don't really need
    to use port 123 on the local system. It could use any port number,
    but it might take a while to modify the current source code to
    do that.

    If you are just trying to hide from bad guys, using iptables
    or whatever to only allow packets from the selected servers might work.
    That gets complicated if you are using the pool.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  7. Re: xntp both serve and client

    On 2008-11-06, fenwayfool 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
    NTP Public Services Project - http://support.ntp.org/

  8. Re: xntp both serve and client

    On 2008-11-06, Hal Murray wrote:

    > If you are running in client only mode, you don't really need
    > to use port 123 on the local system. It could use any port number,
    > but it might take a while to modify the current source code to
    > do that.


    The NTP port is set in ./include/ntp.h:

    /*
    * NTP protocol parameters. See section 3.2.6 of the specification.
    */
    #define NTP_VERSION ((u_char)4) /* current version number */
    #define NTP_OLDVERSION ((u_char)1) /* oldest credible version */
    #define NTP_PORT 123 /* included for non-unix machines */

    Changing the port that ntpd uses is trivial.

    Changing ntpq/ntpdc to work with your modified ntpd is a different
    story.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  9. Re: xntp both serve and client

    In article ,
    Steve Kostecke writes:
    >On 2008-11-06, fenwayfool wrote



    >Some time servers will not accept connections when the source port is
    >not 123.


    Which ones?

    I think that would complicate debugging. For example, I couldn't run
    ntpdate in user mode to compare my local clock with a servers.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  10. Re: xntp both serve and client

    Hal Murray wrote:

    > Steve Kostecke writes:
    >
    >>Some time servers will not accept connections when the source port is
    >>not 123.

    >
    > Which ones?
    >
    > I think that would complicate debugging. For example, I couldn't run
    > ntpdate in user mode to compare my local clock with a servers.


    I'm not aware of any specific servers which enforce the ntpport. But it
    is a restriction.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  11. Re: xntp both serve and client

    fenwayfool wrote:

    > 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??? Not
    > sure about that but some comments suggest it at first glance. That
    > would be another reason to keep port 123 open, I guess.


    broadcastclient mode has to be explicitly configured, but that is
    something that is quite commonly done by people who are operating ntpd
    in a pure client mode.

    The problem with only temporarily opening the socket during a poll is
    that it has to be treated as a special case which can only be enabled if
    none of acting as a server, broadcastclient, or management
    capabilities are in use. (A lot of pure client users also want remote
    access to management statistics.)

    Also there will still be a proportion of the time in which the port is
    open, so it could still show up on scans.

+ Reply to Thread