Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Query NTP server in container (docker/NAT)
947 views
Skip to first unread message
Huygens
Nov 2, 2016, 7:02:30 AM11/2/16
to
For my home LAN, I'm running a ntpd server which uses the NTP pool service (thanks for it by the way!!), and I'm using this local NTP server for my other devices on the LAN.
I want to improve the containment of my ntpd server. Instead of chrooting it, I decided to use Docker. Everything works fine but I cannot monitor the server anymore (timeout). I suspect NAT/masquerading to be the problem.
So is my monitoring time-outing just because the client is on a different subnet than the server (due to NAT)? If yes, how can I solve that?
**Some background/context**:
For monitoring I used collectd (https://collectd.org/) and the ntpd plugin. Basically it calls something equivalent to 'ntpdc -c kerninfo <host>' and a few other queries. When ntpd was running on the host directly, this used to work fine. However when running inside the container the same ntpd version using the same ntpd configuration (with just updated IPs for restrict statements) fails due to timeout. Strangely everything else works as expected (ntpdate or ntpq from the LAN works when using the containerised ntpd server), but not when using the above ntpdc command.
I've tested it inside the container with some reasonable restrict statements and also without any. But in both cases I timeout. Running tcpdump in the container shows that the UDP packet arrives, but nothing is answered. Of course, using tcpdump I see both request and response when using ntpq which is working.
If I run the ntpd server on the host directly, using the same ntp.conf file, the 'ntpdc -c kerninfo <host>' succeed from the host and other computers on the LAN I authorised!
So the only difference is the Docker networking (NAT/masquerading as far as I understood). I've set it up that the UDP port 123 is forwarded. But the ntp.org documentation does not mention anything really about NAT/masquerading in combination with querying.
Note: my container image is based on ubuntu:16.04 which runs ntpd 4.2...@1.3265-o (from the Ubuntu official repositories). The host runs Ubuntu 16.04 as well. Amd I also did run the ntpd inside the container with the -ddd option to get a more verbose output. The only relevant data that were logged are:
read_network_packet: fd=19 length 192 from 192.168.1.3
receive: at 26 172.17.0.2<-192.168.1.3 flags 19 restrict 000
(the address 172.17.0.2 is the one inside the container where the ntpd server is running; the address 192.168.1.3 is on my LAN)
I want to improve the containment of my ntpd server. Instead of chrooting it, I decided to use Docker. Everything works fine but I cannot monitor the server anymore (timeout). I suspect NAT/masquerading to be the problem.
So is my monitoring time-outing just because the client is on a different subnet than the server (due to NAT)? If yes, how can I solve that?
**Some background/context**:
For monitoring I used collectd (https://collectd.org/) and the ntpd plugin. Basically it calls something equivalent to 'ntpdc -c kerninfo <host>' and a few other queries. When ntpd was running on the host directly, this used to work fine. However when running inside the container the same ntpd version using the same ntpd configuration (with just updated IPs for restrict statements) fails due to timeout. Strangely everything else works as expected (ntpdate or ntpq from the LAN works when using the containerised ntpd server), but not when using the above ntpdc command.
I've tested it inside the container with some reasonable restrict statements and also without any. But in both cases I timeout. Running tcpdump in the container shows that the UDP packet arrives, but nothing is answered. Of course, using tcpdump I see both request and response when using ntpq which is working.
If I run the ntpd server on the host directly, using the same ntp.conf file, the 'ntpdc -c kerninfo <host>' succeed from the host and other computers on the LAN I authorised!
So the only difference is the Docker networking (NAT/masquerading as far as I understood). I've set it up that the UDP port 123 is forwarded. But the ntp.org documentation does not mention anything really about NAT/masquerading in combination with querying.
Note: my container image is based on ubuntu:16.04 which runs ntpd 4.2...@1.3265-o (from the Ubuntu official repositories). The host runs Ubuntu 16.04 as well. Amd I also did run the ntpd inside the container with the -ddd option to get a more verbose output. The only relevant data that were logged are:
read_network_packet: fd=19 length 192 from 192.168.1.3
receive: at 26 172.17.0.2<-192.168.1.3 flags 19 restrict 000
(the address 172.17.0.2 is the one inside the container where the ntpd server is running; the address 192.168.1.3 is on my LAN)
Huygens
Nov 2, 2016, 5:52:35 PM11/2/16
to
On Wednesday, November 2, 2016 at 12:02:30 PM UTC+1, Huygens wrote:
>
> Note: my container image is based on ubuntu:16.04 which runs ntpd 4.2...@1.3265-o (from the Ubuntu official repositories). The host runs Ubuntu 16.04 as well. Amd I also did run the ntpd inside the container with the -ddd option to get a more verbose output. The only relevant data that were logged are:
There is an error in my statement, actually the host is still running Ubuntu 14.04, I forgot to upgrade it. So there is another difference which is the ntp version. On the host this is ntp 4.2.6p5 whereas on the container it is 4.2.8p4.
>
> Note: my container image is based on ubuntu:16.04 which runs ntpd 4.2...@1.3265-o (from the Ubuntu official repositories). The host runs Ubuntu 16.04 as well. Amd I also did run the ntpd inside the container with the -ddd option to get a more verbose output. The only relevant data that were logged are:
I've quickly modified my Dockerfile to be based on Ubuntu 14.04 instead of 16.04, and now both collectd and my ntpdc commands work. I did a test using Debian Jessie for the container and it is working too (also version 4.2.6p5). But when I selected Ubuntu 16.10 and Debian Stretch, both based on 4.2.8p8, I ended up with the same error (timeout) as described originally.
So it seems that NAT is not the culprit. But that between ntpd 4.2.6 and 4.2.8 something has changed. Is it a bug or feature?
Miroslav Lichvar
Nov 3, 2016, 3:50:34 AM11/3/16
to
On 2016-11-02, Huygens <jcbe...@gmail.com> wrote:
> I've quickly modified my Dockerfile to be based on Ubuntu 14.04
> instead of 16.04, and now both collectd and my ntpdc commands work. I
> did a test using Debian Jessie for the container and it is working too
> (also version 4.2.6p5). But when I selected Ubuntu 16.10 and Debian
> Stretch, both based on 4.2.8p8, I ended up with the same error
> (timeout) as described originally.
>
> So it seems that NAT is not the culprit. But that between ntpd 4.2.6
> and 4.2.8 something has changed. Is it a bug or feature?
The ntpdc protocol is disabled in 4.2.8 by default. You can enable it
> I've quickly modified my Dockerfile to be based on Ubuntu 14.04
> instead of 16.04, and now both collectd and my ntpdc commands work. I
> did a test using Debian Jessie for the container and it is working too
> (also version 4.2.6p5). But when I selected Ubuntu 16.10 and Debian
> Stretch, both based on 4.2.8p8, I ended up with the same error
> (timeout) as described originally.
>
> So it seems that NAT is not the culprit. But that between ntpd 4.2.6
> and 4.2.8 something has changed. Is it a bug or feature?
with "enable mode7" in ntp.conf, but be careful to restrict it to your
private network, as it can be exploited for DDoS attacks.
--
Miroslav Lichvar
Huygens
Nov 3, 2016, 4:32:09 AM11/3/16
to
On Thursday, November 3, 2016 at 8:50:34 AM UTC+1, Miroslav Lichvar wrote:
> The ntpdc protocol is disabled in 4.2.8 by default. You can enable it
> with "enable mode7" in ntp.conf, but be careful to restrict it to your
> private network, as it can be exploited for DDoS attacks.
Hi Miroslav and thank you for your feedback.
> The ntpdc protocol is disabled in 4.2.8 by default. You can enable it
> with "enable mode7" in ntp.conf, but be careful to restrict it to your
> private network, as it can be exploited for DDoS attacks.
Indeed, setting mode7 in the config file solved my problem. I've found an issue now in collectd to update their plugin (https://github.com/collectd/collectd/issues/932). So I hope they will fix it soon.
One last question. How can I be sure that mode7 is restricted? Which of the "no*" terms restrict the access to mode7?
I have this default restrict for both IPv4 and IPv6:
"default kod notrap nomodify nopeer noquery limited"
Miroslav Lichvar
Nov 3, 2016, 5:10:27 AM11/3/16
to
On 2016-11-03, Huygens <jcbe...@gmail.com> wrote:
> One last question. How can I be sure that mode7 is restricted? Which
> of the "no*" terms restrict the access to mode7?
It's the same as with the mode6 (ntpq) packets - noquery.
> One last question. How can I be sure that mode7 is restricted? Which
> of the "no*" terms restrict the access to mode7?
> I have this default restrict for both IPv4 and IPv6:
> "default kod notrap nomodify nopeer noquery limited"
--
Miroslav Lichvar
Huygens
Nov 3, 2016, 5:36:46 AM11/3/16
to
On Thursday, November 3, 2016 at 10:10:27 AM UTC+1, Miroslav Lichvar wrote:
> On 2016-11-03, Huygens wrote:
> > One last question. How can I be sure that mode7 is restricted? Which
> > of the "no*" terms restrict the access to mode7?
>
> It's the same as with the mode6 (ntpq) packets - noquery.
>
> > I have this default restrict for both IPv4 and IPv6:
> > "default kod notrap nomodify nopeer noquery limited"
>
> That looks good.
Thank you very much Miroslav for your support :-) problem solved.
> > One last question. How can I be sure that mode7 is restricted? Which
> > of the "no*" terms restrict the access to mode7?
>
> It's the same as with the mode6 (ntpq) packets - noquery.
>
> > I have this default restrict for both IPv4 and IPv6:
> > "default kod notrap nomodify nopeer noquery limited"
>
> That looks good.
0 new messages