Generating keys for ntpdc control - NTP

This is a discussion on Generating keys for ntpdc control - NTP ; Bob wrote: > > It's happened again. I disabled auth last night after my previous post, and > let it run overnight with Wireshark capturing I've now got two IP addresses > listed as peers that I did not add. ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 33 of 33

Thread: Generating keys for ntpdc control

  1. Re: Unauthorized remote server configuration

    Bob wrote:

    >
    > It's happened again. I disabled auth last night after my previous post, and
    > let it run overnight with Wireshark capturing I've now got two IP addresses
    > listed as peers that I did not add. They are listed as "sym_passive". I see


    Seems more likely that you've just got W32Time clients. Using peer mode
    by default is one of the known misfeatures. Of course, disabling
    authentication may defeat the normal countermeasures for such clients
    (treating them as though they had you configured as a server, rather
    than peer).

    The associations don't represent configuration in the normal sense; they
    are not the result of management actions, but simply the result of using
    peer type time exchanges; even then, they do represent a risk to the
    time integrity.

    Incidentally, you appear to have a local clock configured at an
    inappropriate stratum. The only time it is appropriate to configure it
    at 5 is when your clock is being disciplined, but not by NTP (it's never
    appropriate to configure one for a pure client). The fact that you have
    other servers configured is a contraindication for the presumption that
    you are being disciplined by non-NTP means.

  2. Re: Unauthorized remote server configuration

    On Sat, Jul 5, 2008 at 9:58 AM, Bob wrote:

    > It's happened again. I disabled auth last night after my previous post, and
    > let it run overnight with Wireshark capturing I've now got two IP addresses
    > listed as peers that I did not add. They are listed as "sym_passive". I see
    > requests from these sites listed as "mode 1" in monlist. Looking at the
    > Wireshark packet captures, the packet from the remote that seems to make me
    > start polling the remote contains a flag of "Symmetric Mode Active". I got
    > a number of packets from this same remote that I began polling, that when
    > looked at with Wireshark, did things like changing polling frequency. All
    > had "Symmetric Mode Active" set. My polls all have "Symmetric Mode Passive"
    > set.


    Could they be Windows machines running Windows Time Service W32time
    without proper configuration polling your server? By default, w32time
    uses symmetric active mode (it assumes it is talking to other W32time
    domain machines.)

    The reference implementation of ntpd will not reject or ignore those
    symmetric active polls, I think, but will not really peer with them
    either. It just answers with a timestamp in symmetric mode, but
    internally treats the associations as client mode in all other
    respects.

    --
    RPM

  3. Re: Unauthorized remote server configuration


    "Ryan Malayter" wrote in message
    news:5d7f07420807050823s60d01f8h89f079be01279788@m ail.gmail.com...
    > On Sat, Jul 5, 2008 at 9:58 AM, Bob wrote:
    >
    >> It's happened again. I disabled auth last night after my previous post,
    >> and
    >> let it run overnight with Wireshark capturing I've now got two IP
    >> addresses
    >> listed as peers that I did not add. They are listed as "sym_passive". I
    >> see
    >> requests from these sites listed as "mode 1" in monlist. Looking at the
    >> Wireshark packet captures, the packet from the remote that seems to make
    >> me
    >> start polling the remote contains a flag of "Symmetric Mode Active". I
    >> got
    >> a number of packets from this same remote that I began polling, that when
    >> looked at with Wireshark, did things like changing polling frequency. All
    >> had "Symmetric Mode Active" set. My polls all have "Symmetric Mode
    >> Passive"
    >> set.

    >
    > Could they be Windows machines running Windows Time Service W32time
    > without proper configuration polling your server? By default, w32time
    > uses symmetric active mode (it assumes it is talking to other W32time
    > domain machines.)
    >
    > The reference implementation of ntpd will not reject or ignore those
    > symmetric active polls, I think, but will not really peer with them
    > either. It just answers with a timestamp in symmetric mode, but
    > internally treats the associations as client mode in all other
    > respects.
    >
    > --
    > RPM


    It does more than just answer. After the first packet - Frame 1 - I answer
    within a couple of hundred milliseconds. I also begin polling the remote for
    time. Frame 72, 73, 75, 76. The remote also shows up on my peer list with
    whatever frequency was requested by the remote. If it's considered normal
    for a remote to request my machine to alter it's peer list with disable auth
    in the config file, I'll just remove that. This seems to conflict with an
    earlier post, but if that's how it's supposed to work, then that's how it
    is.




    No. Time Source Destination Protocol
    Info
    1 04:40:04.483617 206.205.105.226 10.33.90.10 NTP
    NTP symmetric active

    Frame 1 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: Cisco-Li_bb:95:dc (00:12:17:bb:95:dc), Dst:
    AsustekC_50:98:6b (00:13:d4:50:98:6b)
    Internet Protocol, Src: 206.205.105.226 (206.205.105.226), Dst: 10.33.90.10
    (10.33.90.10)
    User Datagram Protocol, Src Port: metagram (99), Dst Port: ntp (123)
    Network Time Protocol

    No. Time Source Destination Protocol
    Info
    2 04:40:04.608762 10.33.90.10 206.205.105.226 NTP
    NTP symmetric passive

    Frame 2 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: AsustekC_50:98:6b (00:13:d4:50:98:6b), Dst:
    Cisco-Li_bb:95:dc (00:12:17:bb:95:dc)
    Internet Protocol, Src: 10.33.90.10 (10.33.90.10), Dst: 206.205.105.226
    (206.205.105.226)
    User Datagram Protocol, Src Port: ntp (123), Dst Port: metagram (99)
    Network Time Protocol


    Frame 71 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: Cisco-Li_bb:95:dc (00:12:17:bb:95:dc), Dst:
    AsustekC_50:98:6b (00:13:d4:50:98:6b)
    Internet Protocol, Src: 206.205.105.226 (206.205.105.226), Dst: 10.33.90.10
    (10.33.90.10)
    User Datagram Protocol, Src Port: metagram (99), Dst Port: ntp (123)
    Network Time Protocol

    No. Time Source Destination Protocol
    Info
    72 06:02:38.301049 10.33.90.10 206.205.105.226 NTP
    NTP symmetric passive

    Frame 72 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: AsustekC_50:98:6b (00:13:d4:50:98:6b), Dst:
    Cisco-Li_bb:95:dc (00:12:17:bb:95:dc)
    Internet Protocol, Src: 10.33.90.10 (10.33.90.10), Dst: 206.205.105.226
    (206.205.105.226)
    User Datagram Protocol, Src Port: ntp (123), Dst Port: metagram (99)
    Network Time Protocol

    No. Time Source Destination Protocol
    Info
    73 06:03:43.310142 10.33.90.10 206.205.105.226 NTP
    NTP symmetric passive

    Frame 73 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: AsustekC_50:98:6b (00:13:d4:50:98:6b), Dst:
    Cisco-Li_bb:95:dc (00:12:17:bb:95:dc)
    Internet Protocol, Src: 10.33.90.10 (10.33.90.10), Dst: 206.205.105.226
    (206.205.105.226)
    User Datagram Protocol, Src Port: ntp (123), Dst Port: metagram (99)
    Network Time Protocol

    No. Time Source Destination Protocol
    Info
    74 06:03:46.997061 206.205.105.226 10.33.90.10 NTP
    NTP symmetric active

    Frame 74 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: Cisco-Li_bb:95:dc (00:12:17:bb:95:dc), Dst:
    AsustekC_50:98:6b (00:13:d4:50:98:6b)
    Internet Protocol, Src: 206.205.105.226 (206.205.105.226), Dst: 10.33.90.10
    (10.33.90.10)
    User Datagram Protocol, Src Port: metagram (99), Dst Port: ntp (123)
    Network Time Protocol

    No. Time Source Destination Protocol
    Info
    75 06:05:51.328047 10.33.90.10 206.205.105.226 NTP
    NTP symmetric passive

    Frame 75 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: AsustekC_50:98:6b (00:13:d4:50:98:6b), Dst:
    Cisco-Li_bb:95:dc (00:12:17:bb:95:dc)
    Internet Protocol, Src: 10.33.90.10 (10.33.90.10), Dst: 206.205.105.226
    (206.205.105.226)
    User Datagram Protocol, Src Port: ntp (123), Dst Port: metagram (99)
    Network Time Protocol

    No. Time Source Destination Protocol
    Info
    76 06:08:00.346095 10.33.90.10 206.205.105.226 NTP
    NTP symmetric passive

    Frame 76 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: AsustekC_50:98:6b (00:13:d4:50:98:6b), Dst:
    Cisco-Li_bb:95:dc (00:12:17:bb:95:dc)
    Internet Protocol, Src: 10.33.90.10 (10.33.90.10), Dst: 206.205.105.226
    (206.205.105.226)
    User Datagram Protocol, Src Port: ntp (123), Dst Port: metagram (99)
    Network Time Protocol




  4. Re: Unauthorized remote server configuration

    Bob wrote:

    >
    > It does more than just answer. After the first packet - Frame 1 - I answer


    I think that is because it recognizes the requests as unauthenticated,
    rather than specifically as W32Time requests. When you turn off
    authentication, they are no longer unauthenticated.

  5. Re: Unauthorized remote server configuration

    In article "Bob"
    writes:
    >
    >It's happened again. I disabled auth last night after my previous post, and
    >let it run overnight with Wireshark capturing I've now got two IP addresses
    >listed as peers that I did not add. They are listed as "sym_passive". I see
    >requests from these sites listed as "mode 1" in monlist. Looking at the
    >Wireshark packet captures, the packet from the remote that seems to make me
    >start polling the remote contains a flag of "Symmetric Mode Active". I got
    >a number of packets from this same remote that I began polling, that when
    >looked at with Wireshark, did things like changing polling frequency. All
    >had "Symmetric Mode Active" set. My polls all have "Symmetric Mode Passive"
    >set.


    OK - I'll defer to others about whether 'disable auth' is supposed to
    have this effect or it's a bug, but I think it's clear that they aren't
    actually changing your config as ntpdc commands may do (they are mode 7
    IIRC). I believe that what you see is the equivalent of other systems
    having you configured as "peer" rather than "server".

    --Per Hedeland
    per@hedeland.org

  6. Re: Unauthorized remote server configuration

    On 2008-07-05, Bob wrote:

    > It's happened again. I disabled auth last night after my previous post, and
    > let it run overnight with Wireshark capturing I've now got two IP addresses
    > listed as peers that I did not add. They are listed as "sym_passive". I see
    > requests from these sites listed as "mode 1" in monlist.


    This is the first time I've been able to understand what you're going on
    about.

    There is a very simple solution here. You need to be using the nopeer
    restriction on your default restrict line.

    I highly suggest that you review
    http://support.ntp.org/Support/AccessRestrictions to learn about setting
    a proper default restriction.

    Here's a good paranoid default restriction which allows only time
    service to everyone, but blocks symmtric_passive peers, and allow more
    access for the localhost:

    restrict default nomodify nopeer notrap noquery
    restrict 127.0.0.1

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

  7. Re: Unauthorized remote server configuration

    Bob wrote:
    > It does more than just answer. After the first packet - Frame 1 - I answer
    > within a couple of hundred milliseconds. I also begin polling the remote for
    > time. Frame 72, 73, 75, 76. The remote also shows up on my peer list with
    > whatever frequency was requested by the remote. If it's considered normal
    > for a remote to request my machine to alter it's peer list with disable auth
    > in the config file, I'll just remove that. This seems to conflict with an
    > earlier post, but if that's how it's supposed to work, then that's how it
    > is.


    Use the restrict nopeer option to prevent it peering with other servers.
    Windows W32time service try to use peer by default. It's a bug in
    Microsoft's code. They should always use client/server mode. Someone
    probably just got lazy when coding it.

    Danny

  8. Re: Unauthorized remote server configuration

    David Woolley wrote:
    > Bob wrote:
    >
    >> It does more than just answer. After the first packet - Frame 1 - I answer

    >
    > I think that is because it recognizes the requests as unauthenticated,
    > rather than specifically as W32Time requests. When you turn off
    > authentication, they are no longer unauthenticated.


    Authentication is not the same as allowing the server to accept the
    packet and peer with it. disabling authentication merely means to accept
    the packet without checking that it's valid.

    Danny

  9. Re: Unauthorized remote server configuration

    Danny Mayer wrote:
    >
    > Authentication is not the same as allowing the server to accept the
    > packet and peer with it. disabling authentication merely means to accept
    > the packet without checking that it's valid.


    I was explaining why it made a difference in this case.

    In any case, as I understand it, enabling authentication allows you to
    be used by a server by broken W32Times, but disabling peering requires
    that you configure the W32Times to send the correct association type.

  10. Re: Unauthorized remote server configuration

    On 2008-07-06, David Woolley wrote:

    > In any case, as I understand it, enabling authentication allows you to
    > be used by a server by broken W32Times,


    Setting nopeer does not "disable peering"; nopeer _blocks_ peering
    attempts from the specified host/subnet.

    > but disabling peering requires that you configure the W32Times to send
    > the correct association type.


    Even if your assertion is correct, it is not the operator's problem
    unless their organization owns both the affected server and the W32time
    clients.

    Would someone with access to both w32time and an ntpd actually check to
    see if 'nopeer' on the server blocks polls from w32time?

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

  11. Re: Generating keys for ntpdc control

    Steve Kostecke wrote:
    > On 2008-07-04, Martin Burnicki wrote:
    >
    >> ntp.key:
    >> -----------------------------------------
    >> 6 M key1
    >> 5 M key2
    >> -----------------------------------------

    >
    > [snip]
    >
    >> Maybe you can try to use a simple MD5 key like me, and see if it works?

    >
    > The key* strings in your ntp.key file are not the actual keys; they are
    > what you enter at the _password_ prompt. An MD5 hash of the password is
    > the key which is sent across the wire.


    Yes, of course. Sorry for not being specific enough.

    > FWIW: I had an association running here which used an ~ 480 character
    > password.


    I've read this on the bugs list. Just wanted to propose to start with a
    simple setup in order to find out why it didn't work for the OP.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  12. Re: Generating keys for ntpdc control

    Danny,

    Danny Mayer wrote:
    > Bob wrote:

    [...]
    >> Also, it appears from your
    >> example, which I assume is from BSD / Linux / Mac, that ntpdc is supposed
    >> to prompt for a password. The windows version says nothing after you
    >> respond to Keyid. If figured you have to enter a password (key contents?)
    >> because it does say "Invalid password" if you press enter at the flashing
    >> cursor after Keyid.
    >>

    >
    > That might be a bug in the Windows environment. You should enter a bug
    > report on this.


    As already mentioned in an earlier posting I'll have a closer look at why
    the password prompt is not displayed. I I run the debug version of the
    current ntpdc from -stable then the password prompt is displayed, using the
    release build it is not.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  13. Re: Generating keys for ntpdc control

    Martin Burnicki wrote:
    > As already mentioned in an earlier posting I'll have a closer look at why
    > the password prompt is not displayed. I I run the debug version of the
    > current ntpdc from -stable then the password prompt is displayed, using
    > the release build it is not.


    The "MD5 password:" prompt is displayed under Linux, etc., because under
    Linux the getpass() function from the OS is used.

    Windows does not provide a getpass() function so NTP provides one under
    Windows. Unfortunately that function prints the prompt only if compiled
    with DEBUG. Just opened a bug for this:
    https://support.ntp.org/bugs/show_bug.cgi?id=1038

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2