Re: recvfrom(0.0.0.0) fd=51: Connection refused - NTP

This is a discussion on Re: recvfrom(0.0.0.0) fd=51: Connection refused - NTP ; A PRIVATE packet is a mode-7 request (ntpdc), and you have seen the reason why the 'restrict' processing is done early. I also assume you have seen http://ntp.isc.org/Support/AccessRestrictions . More to the point, I would be thrilled to have: - ...

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

Thread: Re: recvfrom(0.0.0.0) fd=51: Connection refused

  1. Re: "Listen on" semantics

    A PRIVATE packet is a mode-7 request (ntpdc), and you have seen the reason
    why the 'restrict' processing is done early.

    I also assume you have seen http://ntp.isc.org/Support/AccessRestrictions.

    More to the point, I would be thrilled to have:

    - more eyes going over the code
    - more volunteers helping to clean things up

    Would you like to be one of those folks?

    H

  2. Re: "Listen on" semantics

    >>> In article <45124ad1$0$4516$e4fe514c@news.xs4all.nl>, "Maarten Wiltink" writes:


    Maarten> [...]
    >> OpenBSD's OpenNTP was, as I recall (and IMO), originally a malignantly
    >> broken SNTP implementation.


    Maarten> Malignantly, no less? Come off it. Sure, they made mistakes, but
    Maarten> that wasn't the intent.

    I'm not suggesting their intent was malignant, I'm saying that IMO they
    released a malignantly broken SNTP implementation.

    It advertised itself as an S2 server. The time on the machine was not
    disciplined. This behavior is, IMO, malignant.

    Do we need to go further here?

    H

  3. Re: "Listen on" semantics

    >>> In article <45124ad1$0$4516$e4fe514c@news.xs4all.nl>, "Maarten Wiltink" writes:

    Maarten> (Wouldn't a client-mode real NTP, combined with an OpenSNTP server,
    Maarten> be the ideal configuration?)

    Read the RFC on when an SNTP instance can serve time, and tell me if
    OpenBSD's OpenNTP has ever been able to meet those requirements.

    H



  4. Re: "Listen on" semantics

    Luc Pardon wrote:
    > Danny Mayer wrote:
    >> Luc Pardon wrote:
    >>> Danny Mayer wrote:
    >>>> By binding to all interfaces and addresses we
    >>>> prevent other applications using them. The worst thing you can have is
    >>>> two different applications modifying the clock.
    >>> This is, I think, where we have fundamentally different perspectives.
    >>>
    >>> To you, the worst thing may well be a screwed-up clock (and
    >>> incidentally that's a perfect mindset for a clock-daemon developer ).
    >>> To me as an administrator, however, the Worst Thing is having the box
    >>> hacked and rooted.
    >>>

    >>
    >> At which point your log timestamps better be accurate so you can trace
    >> things back. This is *NOT* from a developer's viewpoint.
    >>

    > Yes, when I get rooted it is important to find out how, and having
    > accurate time does help, although we could argue about the need for
    > absolute versus relative time. But that would get off topic.


    You're talking to someone who did his thesis in General Relativity.
    There's no such thing as absolute time. All time is relative. Not that
    this is relevant!

    >
    > My point was that I'd prefer a hacker-proof fortified castle (I
    > know: "pull the plug!") with less accurate time to a open house where I
    > can determine with millisecond precision when exactly I got rooted.
    >
    > Of course I want both the super-castle _and_ the super-clock .
    >
    >>> Your reasoning makes sense, but you are reasoning from the assumption
    >>> that there are no bugs in the code. Nobody can guarantee that, and
    >>> certainly not an application with +73k lines of code (wc -l
    >>> ntp-dev-4.2.3p39/ntpd/*.c). That's simply impossible.
    >>>

    >>
    >> No, there *ARE* bugs in the code, that's not even speculation, but
    >> that's not in any way related to the question at hand.

    >
    > Quite to the contrary, it is. If there are bugs, it's dangerous to
    > take candy from strangers, as (x)ntpd does.
    >


    It's dangerous to cross the street but we do it every day. If you're
    driving you should be wearing a seatbelt and have airbags in your vehicle.

    >>> Your reasoning also assumes that every incoming packet is playing by
    >>> the rules, or at least that the code can handle all kinds of malformed
    >>> packets, that it will never cut its virtual fingers on the sharp edges
    >>> of packets that were crafted on purpose by malicious minds. That is a
    >>> dangerous assumption in today's world.

    >>
    >> No, the code actual spends a lot of time checking the packet that comes
    >> in before it uses the contents. malformed packets will be immediately
    >> rejected. The only other thing you can do to an NTP packet is put in bad
    >> timestamps, which if it is incoming to a client will be dismissed as way
    >> out of range. The only other parts in an NTP packet deals with security
    >> but you won't get far with that.
    >>
    >> Are there other ways of doing something nasty to a packet? Undoubtedly
    >> there are things we haven't thought of but there's not a lot in the
    >> packet that you can change in the first place. None of this has anything
    >> to do with binding to all interface addresses.
    >>

    >
    > Again, your reasoning is valid only if there are no bugs. There have
    > been boatloads of exploits, precisely because of bugs in UDP packet
    > processing code, many of them precisely in the code that was intended to
    > check that the packet is valid. Because all code can be assumed to
    > contain bugs, all code must be assumed to be potentially vulnerable.
    >
    > Case in point #1: back in 2001, there was a bug in - yes - (x)ntpd
    > that allowed remote root access. See, for example:
    >
    > http://archive.cert.uni-stuttgart.de.../msg00064.html
    >
    > If (x)ntpd had not listened and accepted and processed all junk that
    > comes in, it would not have happened.
    >


    Yes, and not only was it as is it still the only known ntp exploit, it's
    how I got involved in the first place. The bug was fixed by someone I
    happened to be working with at the time but I didn't know that until
    several years later when I was looking at the code.

    > Case in point #2: only last week, my logs were being flooded because
    > somebody sent icmp port unreachable packets to udp/123. Each packet is
    > good for about 80 bytes of wasted disk space.


    icmp doesn't use port numbers, it doesn't know what they are.

    > A determined attacker,
    > starting on Friday evening, could use a high-speed line to fill up a
    > multi-gigabyte disk and have free game by Sunday afternoon. By that time
    > none of his actions will be logged anymore because of disk full.


    That's a DDOS type of attack and is best prevented or at least managed
    by a firewall router. So far this is not an ntp issue whether or not
    it's listening on any particular address.

    By
    > Monday morning, the sysadmin will scratch his head over the "connection
    > refused"'s and may not even know he's been hacked.


    Connection refused by what?

    >
    > If (x)ntpd had not listened and accepted and processed all junk that
    > comes in, this would not be possible.
    >


    On the contrary, the attacker can use any service running on the system
    for this. There's nothing special about ntp here.
    >
    >>> Yes, the code path may be much shorter if you drop the packets right
    >>> away. But it takes only one typo to create an exploitable vulnerability.
    >>> If not today, then maybe tomorrow, after the next maintenance cycle.

    >>
    >> Very true, but what has this to do with binding to all interface
    >> addresses?

    >
    > If you accept packets, there is a potential vulnerability. (x)ntp
    > unnecessarily accepts anything, junk and malicious packets included.
    >


    It will drop malformed and invalid packets almost immediately.

    > If you'll allow me I'll give you an analogy (crippled like all of
    > them). I am building a fortified castle and I'm letting you live in it.
    > What you do is hanging a rope out of your window (of room 123 ) for
    > the postman to climb in and bring you the packets that you order from a
    > mail order company.
    >
    > When I object that my enemies can come in as easily as the mailman,
    > you say: "no worry, I'll fend them off, and besides, I need to hang out
    > that rope to protect you from other problems, and besides, there is no
    > other way to get at my packets".
    >
    > Now:
    >
    > * we both know that you can't guarantee me that you'll fend them off
    > (bugs, new tricks, ...).
    > * I ask you to let me decide if I want to be protected from other
    > problems or not.
    > * Finally, there _is_ another way to get at your packets, see below.
    >


    Well no, you have to have them come in the same way and examine them to
    see if you want them.

    > Because I'm the landlord, you're going to pull your rope back in or
    > convince me it's needed. If you fail to do either, I'll kick you out .
    >
    >>> Besides, the -I switch won't help me with the most vulnerable
    >>> interface on a two-NIC box acting as a stratum 3 time server for an
    >>> internal network. I tried to disable the public interface (by specifying
    >>> -I ) but then it can't seem to reach the stratum 2
    >>> servers outside. The net result is that I have no choice but to let any
    >>> "packet from hell" make its way through the "restrict" processing.
    >>>

    >>
    >> This does you no good, either way.

    >
    > That sounds a little bit like we're talking different things ??
    >


    I don't think so. The packet only gets to the restrict processing if it
    is a valid well-formed packet, it gets dropped otherwise.

    >> The *ONLY* solution here is to use
    >> the restrict processing

    >
    > No, restrict rules, while helpful, are not a solution. First, they
    > may have bugs themselves, and second, they are based on IP addresses,
    > which are easily spoofed with UDP. If I know where your IP is located,
    > it's a fair guess what time servers you'll be using. I can send you a
    > few dozen packets with various faked sender IP's until one sails right
    > through your restrict rules and into the processing code, where
    > potentially more bugs are waiting to be exploited.


    But at this point not only must the packet be well-formed but if the
    timestamps are off the server the it purports to come from will get
    ignored. The clock routines that lie at the heart of ntp will drop any
    server which is way out of synch with other servers.It's much harder for
    you to know what servers to spoof and send packets allegedly coming from
    them in a way that would cause ntp to accept them as valid and be close
    enough to the correct value to be acceptable. If you are concerned
    enough about the issue then you can add authentication to your
    configuration file and it will drop packets that are not authenticated.

    >
    >> since you *MUST* accept packets on both NIC's.

    >
    > Yes but no . Obviously, I must accept responses from time servers
    > that answer a request of mine, else no sync. But there is no reason to
    > accept anything else.


    Then you should install a stateful firewall and restrict packets as
    appropriate.

    >
    >> This is even if we had the ability to allow you to select which
    >> interface addressess to bind to you'd still have the same problem.
    >>
    >> If you are suggesting that you want to run two copies of ntpd on your
    >> server then you have a bigger problem since ntpd is not designed to work
    >> that way and it would be hard to support such a situation.

    >
    > What I want is not so much two copies of ntpd as a separation between
    > client and server functionality.
    >
    > The client should keep my clock on track. The server should tell all
    > my other systems what time it is.


    And you can do that via the restrict statements.

    >
    > The server should listen for incoming requests all right, but only on
    > the interfaces that I specify. That interface would be the one connected
    > to the internal network only. After all, that's the only one where valid
    > queries may come in. Yes, that would leave me vulnerable to attacks from
    > within, but I can deal with that - if need be with a wooden pole .
    >
    > The client, on the other hand, should not be listening all the time,
    > otherwise it's not a client but a server.



    You misunderstand how this works. The client only listens to reponses to
    queries that it makes, it doesn't need to respond to any queries. Again
    that's what the restrict statement is for.

    When it's time to ask public
    > server ntp1.example.com what time it is, the client should create a
    > socket, fill in the sockaddr with the IP of ntp1.example.com, send the
    > packet down the socket, receive the reply from the socket, then close
    > the socket again. Yes, until the reply comes in, the client _will_ be
    > listening, but with three important distinctions: a) it will see only
    > packets that (pretend to) come from ntp1.example.com,


    Use authentication to validate this.

    b) it will not be
    > listening on port 123 but on a random port assigned by the OS


    There you want something like sntp.

    and c) the
    > socket will be gone as soon as the reply is in.


    Yes you could do that.

    An attacker would 1)
    > have to guess the IP of the server I queried and fake it, 2) he would
    > have to guess the random port number that I'm listening on, and 3) he
    > would have to make the fake packet arrive after the request but ahead of
    > the real response. Still vulnerable, but much harder to exploit.
    >


    If you use authentication it doesn't matter. sntp doesn't support it, I
    believe, you need the full ntpd daemon.

    > The problem is that ntpd currently does not seem to use client mode,
    > or at least does it in asynchroneous mode. If it did things in the above
    > way:
    >
    > * it would not have to do the "rebind" trick to detect changes of
    > dynamic IP's
    >


    If the server address is static it's not needed.

    > * it would have no problems dealing with multi-IP servers
    >


    It doesn't now.

    > * it would not have to listen on - and handle every single packet
    > from - the public interface
    >


    True but so what? It's not as if it takes a lot of CPU time.

    >>> In any case, the simple fact is: as soon as you accept packets, you
    >>> are posing a security risk.
    >>>

    >> Well the alternative to that is not to connect to anything.
    >>

    >
    > There is an alternative in between, and that is to connect to the
    > outside servers in the regular client/server way, as described above.
    >


    People do it today with ntpdate.

    >>> Of course you are right that, if I run two different applications
    >>> that modify the clock, I may have a problem, but at least it's a problem
    >>> of my own making. If you really want to protect me from shooting myself
    >>> in the foot by locking all unused interfaces, make it optional. Make it
    >>> the default if you want, but at least give me the option to disable it.

    >>
    >> You have that option today by modifying the code to your liking. Not the
    >> answer you want but it's even more fraught with potential security
    >> issues that I wouldn't want to support such a configuration.

    >
    > You're probably going to kill me for this but there is another
    > option: I can switch to OpenNTPD. That does - or seems to do - precisely
    > what I want. With that setup, things like the exploit that bit (x)ntpd
    > in 2001, or the "connection refused" issue that cost me so much time to
    > diagnose, are simply impossible.
    >


    You are of course welcome to use if it you want sntp and you don't care
    about clock accuracy, lack of support for things like ntpq, etc. for
    check the state of your ntpd.

    > My only requirement is that all the clocks of my internal machines
    > are in reasonable sync. I'm not running a Space Station, so as long as
    > all the machines are off in the same way, I don't mind if their time is
    > a little off the absolute time of the Universe.
    >


    As I said before there is no absolute time.

    > What I'm testing out right now is OpenNTPD on the internal stratum 3
    > server with the internal clients running (x)ntpd. It's been running for
    > a week or so. Up to now it seems to do what I want.
    >
    > That means I have to trade off a millisecond-accurate clock against
    > more security. I'm afraid that is pretty much a no-brainer.
    >


    You mean less. You can easily fake out packets going to an OpenNTP
    server and you would have no way of knowing that. At least with ntpd you
    can authenticate the server packets and know that they are valid and use
    them.


    > Well, that's why I gave it another try. But please keep in mind that
    > I have no stake in this discussion, I have an alternative (see above).
    >
    > Unless I am mistaken, what is at stake for you is no less than a
    > redesign of ntpd, or at least of the socket handling code.


    I need a reason to do so. I did it once and now it's maintainable. It
    wasn't back then. None of what we are discussing (like not listening at
    all to certain IP addresses or interfaces is a big challenge any more. I
    made sure of that.

    > I don't
    > expect that to happen and I'm not willing to "fight" to make it happen.
    > That is why I proposed to leave it at that.
    >


    It's easy enough to change the code if you want to do so, but I won't do
    it without good well thought out reasons that will not make it less secure.

    Danny
    > Luc
    >


    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  5. Re: "Listen on" semantics

    Maarten Wiltink wrote:
    > "Luc Pardon" wrote in message
    > news:45110BAE.8040106@skopos.be...
    > [...]
    >> What I want is not so much two copies of ntpd as a separation
    >> between client and server functionality.
    >>
    >> The client should keep my clock on track. The server should
    >> tell all my other systems what time it is.

    >
    > Forget mentioning OpenNTP, folks here will crucify you for that alone.
    > Which is exactly why I want to express my moral support (from a safe
    > distance). This would be a TREMENDOUSLY good idea.
    >
    > It's also not going to happen. NTP is never finished, it seems. Never
    > any time for redesigns like this.
    >


    I would like to understand what we'd be redesigning? You set up your
    servers, you set up your restrictions and you are done. It works, you
    can authenticate the servers, you can provide authentication to YOUR
    clients and there's nothing else to do. Dropping packets can be done at
    a firewall.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  6. Re: "Listen on" semantics



    Danny Mayer wrote:

    > It's easy enough to change the code if you want to do so, but I won't do
    > it without good well thought out reasons that will not make it less secure.
    >

    That's fine with me. Thanks nonetheless for taking the time to
    respond in detail.

    Bye,

    Luc

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  7. Re: "Listen on" semantics

    "David Woolley" wrote in message
    news:T1158870334@djwhome.demon.co.uk...
    > In article <45124ad1$0$4516$e4fe514c@news.xs4all.nl>,
    > Maarten Wiltink wrote:


    >> At this point, people will shriek 'that's an SNTP server! Not NTP!'
    >> But is it? What's the difference? ...

    >
    > The difference is that an NTP server reports more information obtained
    > by the client part to its clients. Even an SNTP server is supposed
    > to report the stratum, even if Microsoft, and the original OpenNTPD
    > forgot to do this. NTP has to report root delay and root dispersion,
    > and leap warnings.


    Okay, fair deal.

    So given separate NTP client and server modules, some measure of
    cooperation between them might make the server part qualify as genuine
    NTP?

    Groetjes,
    Maarten Wiltink



  8. Re: "Listen on" semantics

    "Danny Mayer" wrote in message
    news:4513531A.1080902@ntp.isc.org...
    > Maarten Wiltink wrote:
    >> "Luc Pardon" wrote in message
    >> news:45110BAE.8040106@skopos.be...


    >>> What I want is not so much two copies of ntpd as a separation
    >>> between client and server functionality.
    >>>
    >>> The client should keep my clock on track. The server should
    >>> tell all my other systems what time it is.


    >> [...] Never any time for redesigns like this.

    >
    > I would like to understand what we'd be redesigning? You set up your
    > servers, you set up your restrictions and you are done. It works, you
    > can authenticate the servers, you can provide authentication to YOUR
    > clients and there's nothing else to do. Dropping packets can be done at
    > a firewall.


    Separation of client and server functionality, with corresponding
    separation of use of client and server sockets. The ability to _never_
    open a server socket on the red interface.

    Restrictions may actually be a better mechanism, but I can't stop
    thinking of a review of some Linux distribution I read years ago.
    Every network application had been split into two packages: a client
    part and a server part. No configuration necessary, you could install
    the client and never worry about inadvertently running the server, too.

    Between client, server, _and ntpq_, however, I'm not sure anymore life
    is that easy. The server module probably has to be told whether to serve
    time and/or status; before long you'll have strongly coupled modules and
    the full functionality of restrictions and you've won nothing.

    Groetjes,
    Maarten Wiltink



  9. Re: "Listen on" semantics

    Luc Pardon wrote:
    >
    >
    > Harlan Stenn wrote:
    >>>>> In article <45110BAE.8040106@skopos.be>, xntp@skopos.be (Luc
    >>>>> Pardon) writes:

    >>
    >> Lots of good stuff.
    >>
    >> Luc> Case in point #1: back in 2001, there was a bug in - yes -
    >> (x)ntpd
    >> Luc> that allowed remote root access. See, for example:
    >> Luc>
    >> http://archive.cert.uni-stuttgart.de.../msg00064.html
    >>
    >>
    >> First, please compare this history to other root-running processes and
    >> tell
    >> me how (x)ntpd compares. Especially given the length of time (x)ntpd has
    >> been in the field.
    >>

    >
    > We wouldn't be having this discussion if I was of the opinion that
    > (x)ntpd had a lousy track record. I wouldn't bother.
    >
    > I mentioned this only to show that there can be buffer overflow bugs
    > in otherwise correct code.
    >

    Right now you can only get buffer overflow bugs by sending an NTP packet
    but the code already checks for that, so you don't have any way of doing it.

    > > Luc> Case in point #2: only last week, my logs were being flooded
    >> Luc> because somebody sent icmp port unreachable packets to udp/123.
    >> Fair point, and Real Soon Now we're going to have better configuration
    >> control over logfiles.

    >
    > The problem is that you can't distinguish between real and fake
    > packets. If you suppress the fake "connection refused", you may be
    > wiping real problems under the carpet as well.


    Do you know what "connection refused" really means? It means that
    nothing is listening on that port of that server. It does not mean that
    the server is refusing to accept it.


    >
    >> And I thought syslog() was pretty good about "Last
    >> message repeated N times".

    >
    > Point taken, I did forget that. It issues a "repeated" every second,
    > so our attacker would not be ready by Sunday. Unless he can find another
    > way - preferably with (x)ntpd - to generate a syslog entry and alternate
    > that with the port unreachable packets. A "grep syslog *.c | grep
    > LOG_ERR" yields some promising candidates.
    >


    We silently drop any packets at the network level and I believe at the
    restrict level. They don't get logged except if you are debugging. We
    can change our code for the logging so that we can just count identical
    messages and put it out when the message changes along with the count.
    It would cut down dramatically on logging an attack.

    > Out of curiosity, I had a quick look at the ntp-dev-4.2.3p39 code.
    >
    >
    >
    > At first sight, it seems possible to craft a packet that will end up in
    > process_private() in ntp_request.c and trigger the sanity check in there.
    >
    > In ntp_proto.c(388), it says:
    >
    > hismode = (int)PKT_MODE(pkt->li_vn_mode);
    > hisstratum = PKT_TO_STRATUM(pkt->stratum);
    > if (hismode == MODE_PRIVATE) {
    > if (restrict_mask & RES_NOQUERY) {
    > sys_restricted++;
    > return; /* no query private */
    > }
    > process_private(rbufp, ((restrict_mask &
    > RES_NOMODIFY) == 0));
    > return;
    > }
    >
    > So I'd set the li_vn_mode to PRIVATE (whatever that means ) and I'd
    > fake the source address to 127.0.0.1 to steer it past the restrict rules
    > in most setups. If and when I make it into process_private(), I have a
    > choice of 4 fields in the packet that I can load with invalid values, or
    > I could make it too long or too short.


    MODE_PRIVATE is are mode 7 packets and the only thing that uses it is
    ntpdc. Notice that if restrictions don't allow it it just drops the
    request without logging. Yes, 127.0.0.1 is likely to be allowed but what
    happens to the response? It goes back to the local machine. If the
    source port is also 123 then it returns to the server and this time the
    packet will get dropped since it will no longer be a valid packet (see
    the mapping, I think in ntp_proto.c).

    In ntp_request.c(433) my
    > malicious eyes see the following code that makes me drool:
    >
    > /*
    > * Do some sanity checks on the packet. Return a format
    > * error if it fails.
    > */
    > ec = 0;
    > if ( (++ec, ISRESPONSE(inpkt->rm_vn_mode))
    > || (++ec, ISMORE(inpkt->rm_vn_mode))
    > || (++ec, INFO_VERSION(inpkt->rm_vn_mode) > NTP_VERSION)
    > || (++ec, INFO_VERSION(inpkt->rm_vn_mode) < NTP_OLDVERSION)
    > || (++ec, INFO_SEQ(inpkt->auth_seq) != 0)
    > || (++ec, INFO_ERR(inpkt->err_nitems) != 0)
    > || (++ec, INFO_MBZ(inpkt->mbz_itemsize) != 0)
    > || (++ec, rbufp->recv_length < REQ_LEN_HDR)
    > ) {
    > msyslog(LOG_ERR, "process_private: INFO_ERR_FMT: test %d
    > failed, pkt from %s", ec, stoa(srcadr));
    > req_ack(srcadr, inter, inpkt, INFO_ERR_FMT);
    > return;
    > }
    >
    > Too bad the restrict rules are in front of it, otherwise I could use
    > my own IP (or that of one of my zombies) and I'd get an ack if I
    > succeeded, then start faking source IP's.
    >
    >
    >
    > Again: this is just the result of a quick look at unfamiliar code.
    > More likely than not, I'm missing something obvious so that this won't
    > fly. But it sure looks promising and if it should work, I have my siege
    > engine complete. By alternating one of these with an icmp packet, I can
    > flood the log just fine.
    >


    We can apply counting mechanisms here.

    > Again, this would not be an issue at all if (x)ntpd didn't take candy
    > from strangers.
    >


    Whether it does or does not is up to the operator.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  10. Re: "Listen on" semantics

    Maarten Wiltink wrote:
    > At this point, people will shriek 'that's an SNTP server! Not NTP!' But
    > is it? What's the difference? The current definition seems to be that
    > to be an NTP server, you have to implement the client functionality (the
    > math) yourself. I think it's more important _that_ the math is being
    > done. _Where_ is not that important.
    >


    No, that's not true. The receiving end MUST be the one doing the math.
    There is no way for the server to know what the delays are in getting a
    packet to the client. Only the client has a chance to know that.

    >
    > [...]
    >> OpenBSD's OpenNTP was, as I recall (and IMO), originally a malignantly
    >> broken SNTP implementation.

    >
    > Malignantly, no less? Come off it. Sure, they made mistakes, but that
    > wasn't the intent. The intent was to build something with no exploits.
    > If the question is what comes first, working right or not getting rooted,
    > well, they _are_ OpenBSD.


    Which means absolutely nothing. People don't set up to create buggy or
    exploitable code. I don't assume that just because they've given
    themselves a label that they have an automatic level of trust in their
    software. On top of that even if the code is not exploitable it doesn't
    mean that it's correct.

    >
    > (Wouldn't a client-mode real NTP, combined with an OpenSNTP server, be
    > the ideal configuration?)
    >


    No.

    Danny

    > Groetjes,
    > Maarten Wiltink

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  11. Re: "Listen on" semantics

    Luc Pardon wrote:
    >
    >
    > Harlan Stenn wrote:
    >> And I thought syslog() was pretty good about "Last
    >> message repeated N times".
    >>

    >
    > In addition to my last post (which I forgot to sign, sorry), it may
    > be worth recalling that ntp 4.2.0 (and maybe later) had a bug that make
    > it log bogus IP's:
    >
    >> Sep 3 04:07:36 gida ntpd[4796]: recvfrom(193.190.230.65) fd=9:

    > Connection refused
    >> Sep 3 04:08:40 gida ntpd[4796]: recvfrom(192.168.1.3) fd=9:

    > Connection refused
    >


    There is something fundamentally wrong with these messages since
    recvfrom is receiving messages and "connection refused" means it's not
    listening on the address/port. I'd like to know how these errors got
    generated since it makes no sense to me.

    Are you using static IP addresses or are you using DHCP to assign your
    server's address?

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  12. Re: "Listen on" semantics

    Luc Pardon wrote:
    > To make it [clearer|more confusing] : currently, the (x)ntpd "time
    > client" uses a "socket server" (listening) to receive its time info,
    > i.e. it operates in async mode. I would like to see it use a regular
    > "socket client" in synchroneous mode instead.
    >


    That won't happen with ntpd. That means you are blocking sitting there
    waiting for something to happen. Nothing else can be done. ntpd doesn't
    just listen, it also sends out packets.

    >
    > Exactly. I don't care too much how the client and server are
    > implemented, in separate processes or in one single process, although
    > personally I'd go for separate if possible (KISS and security). But if
    > they are in a single process, I'd do want to be able to switch the
    > logical components (client, server, peer) on or off in the config file
    > to suit my needs.
    >


    We call those restrict statements. It's already in the code and does
    exactly what you want.

    >> The introduction of a 'client only' mode for NTP (not SNTP) would make
    >> many people happy already. That could use ports in such a manner that
    >> time service does not automatically become available from the machine,
    >> and could try not to get in the way of a separate simple NTP time server.
    >>


    You can do that today.

    >
    > It certainly would make _me_ happy. What I miss in OpenNTPD is not
    > so much the reduced precision as the lack of ntpq.
    >
    > In any case, I believe that "my" setup, i.e an stratum 3 server for
    > an internal network, is a typical setup. It's Not Good to force all
    > these admins to choose between better time and better security if they
    > can have both.


    You get that today with ntpd. Nothing else out there provides both.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  13. Re: "Listen on" semantics

    Heiko Gerstung wrote:
    > Luc Pardon schrieb:
    >> [... very interesting but long security discussion ...]
    >>
    >>
    >> It certainly would make _me_ happy. What I miss in OpenNTPD is not
    >> so much the reduced precision as the lack of ntpq.

    >
    > Sorry for eating all the quoted text, but I only wanted to ask you why
    > there is no such thing as ntpq for OpenNTPD?
    >
    > Where do you think would the "server" part get all the information that
    > ntpq shows to you?
    >


    ntpq use mode 6 packets and not mode 3 packets to get its information.
    OpenNTPD would have to support mode 6 packets AND what it needs to
    return in order to return any information.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  14. Re: "Listen on" semantics

    Maarten Wiltink wrote:
    > "Danny Mayer" wrote in message
    > news:4513531A.1080902@ntp.isc.org...
    >> Maarten Wiltink wrote:
    >>> "Luc Pardon" wrote in message
    >>> news:45110BAE.8040106@skopos.be...

    >
    >>>> What I want is not so much two copies of ntpd as a separation
    >>>> between client and server functionality.
    >>>>
    >>>> The client should keep my clock on track. The server should
    >>>> tell all my other systems what time it is.

    >
    >>> [...] Never any time for redesigns like this.

    >> I would like to understand what we'd be redesigning? You set up your
    >> servers, you set up your restrictions and you are done. It works, you
    >> can authenticate the servers, you can provide authentication to YOUR
    >> clients and there's nothing else to do. Dropping packets can be done at
    >> a firewall.

    >
    > Separation of client and server functionality, with corresponding
    > separation of use of client and server sockets. The ability to _never_
    > open a server socket on the red interface.


    There's no practical meaning to this statement. There is no such think
    as a server socket or a client socket. There is only a socket.

    >
    > Restrictions may actually be a better mechanism, but I can't stop
    > thinking of a review of some Linux distribution I read years ago.
    > Every network application had been split into two packages: a client
    > part and a server part. No configuration necessary, you could install
    > the client and never worry about inadvertently running the server, too.
    >


    Some things are easy to split, such as brower from HTTP server, for
    example, and some it makes no sense. ntpd falls into the latter case.

    > Between client, server, _and ntpq_, however, I'm not sure anymore life
    > is that easy. The server module probably has to be told whether to serve
    > time and/or status; before long you'll have strongly coupled modules and
    > the full functionality of restrictions and you've won nothing.
    >


    Exactly.

    Danny
    > Groetjes,
    > Maarten Wiltink
    >
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  15. Re: "Listen on" semantics

    Danny Mayer schrieb:
    > Heiko Gerstung wrote:
    >> Luc Pardon schrieb:
    >>> [... very interesting but long security discussion ...]
    >>>
    >>>
    >>> It certainly would make _me_ happy. What I miss in OpenNTPD is not
    >>> so much the reduced precision as the lack of ntpq.

    >> Sorry for eating all the quoted text, but I only wanted to ask you why
    >> there is no such thing as ntpq for OpenNTPD?
    >>
    >> Where do you think would the "server" part get all the information that
    >> ntpq shows to you?
    >>

    >
    > ntpq use mode 6 packets and not mode 3 packets to get its information.
    > OpenNTPD would have to support mode 6 packets AND what it needs to
    > return in order to return any information.


    I know :-) That was a rhetoric question with which I wanted to point out
    that there is a good point in combining client and server functionality
    in ntpd and that you would simply loose all the nice debugging and
    status information that ntpq offers you when you use an OpenNTP server
    and a client part "only" used for synchronizing the local clock.

    Heiko


    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >



    --
    Meinberg radio clocks: 25 years of accurate time worldwide

    MEINBERG Radio Clocks
    www.meinberg.de

    Stand alone ntp time servers and radio clocks based on GPS, DCF77 and
    IRIG. Rackmount and desktop versions and PCI slot cards.

  16. Re: "Listen on" semantics

    "Danny Mayer" wrote in message
    news:4515FCC3.109@ntp.isc.org...
    > Maarten Wiltink wrote:


    >> At this point, people will shriek 'that's an SNTP server! Not NTP!'
    >> But is it? What's the difference? The current definition seems to
    >> be that to be an NTP server, you have to implement the client
    >> functionality (the math) yourself. I think it's more important _that_
    >> the math is being done. _Where_ is not that important.

    >
    > No, that's not true. The receiving end MUST be the one doing the math.


    I meant which process at the receiving end. It might be the client part
    even though the server part would be the one claiming 'it _is_ being
    done'.


    >>> OpenBSD's OpenNTP was, as I recall (and IMO), originally a
    >>> malignantly broken SNTP implementation.

    >>
    >> Malignantly, no less? Come off it. Sure, they made mistakes, but that
    >> wasn't the intent. The intent was to build something with no exploits.
    >> If the question is what comes first, working right or not getting
    >> rooted, well, they _are_ OpenBSD.

    >
    > Which means absolutely nothing. People don't set up to create buggy
    > or exploitable code.


    No. But some people actively set up to create code with no exploits.


    > [...] On top of that even if the code is not exploitable it doesn't
    > mean that it's correct.


    People don't set up to create incorrect code, either. NTP is not
    without bugs. OpenBSD is not without holes. (For humility, guess which
    one is closer.)


    >> (Wouldn't a client-mode real NTP, combined with an OpenSNTP server,
    >> be the ideal configuration?)

    >
    > No.


    For answering a tongue-in-cheek rhetorical question... no points.

    Groetjes,
    Maarten Wiltink



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2