Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
symmetric active while configurion uses server mode, RFC compliant or not?
138 views
Skip to first unread message
Joe the Shmoe
May 18, 2013, 3:14:27 AM5/18/13
to
Hello,
After having read the RFC 5905 and having partially understood it (much
too technical about time aspects for me), I still cannot figure out
whether the fact I observe are:
- RFC compliant or not
- a configuration error on my side
- a bug in the software I use (ntpd)
- the symptoms of a attack or attempts of attack.
Here is what I observe:
The host has been configured to obtain clock as client from several NTP
parent of stratum 2. It is member of the ntp.pool.org thus provides time
to many hundred clients per hours.
By curiosity I have intercepted the NTP exchanges using wireshark, and
beside the expected NTP client and NTP server exchanges, I see NTP
symmetric active and symmetric passive ones.
Zooming on these I see two types of requests:
- received symmetric active from unconfigured hosts, which get answered
by symmetric passive from my host. Here the point I do not understand is
that the NTP server is configured in a way to "Deny packets that might
mobilize an association unless authenticated." Shouldn't the server
ignore the request rather than answering them by a symmetric passive
message?
- Other symmetric active requests come from the server itself toward one
of the 5 configured hosts. But the server only makes use of "server" in
the configuration (no "peer" statement). This occurs after a first NTP
client request to that configured host which get answered by two NTP
server from the configured host.
Looking at ntpd bug database, I could not find anything that matches
what I observed.
Thanks for any idea,
Joe.
After having read the RFC 5905 and having partially understood it (much
too technical about time aspects for me), I still cannot figure out
whether the fact I observe are:
- RFC compliant or not
- a configuration error on my side
- a bug in the software I use (ntpd)
- the symptoms of a attack or attempts of attack.
Here is what I observe:
The host has been configured to obtain clock as client from several NTP
parent of stratum 2. It is member of the ntp.pool.org thus provides time
to many hundred clients per hours.
By curiosity I have intercepted the NTP exchanges using wireshark, and
beside the expected NTP client and NTP server exchanges, I see NTP
symmetric active and symmetric passive ones.
Zooming on these I see two types of requests:
- received symmetric active from unconfigured hosts, which get answered
by symmetric passive from my host. Here the point I do not understand is
that the NTP server is configured in a way to "Deny packets that might
mobilize an association unless authenticated." Shouldn't the server
ignore the request rather than answering them by a symmetric passive
message?
- Other symmetric active requests come from the server itself toward one
of the 5 configured hosts. But the server only makes use of "server" in
the configuration (no "peer" statement). This occurs after a first NTP
client request to that configured host which get answered by two NTP
server from the configured host.
Looking at ntpd bug database, I could not find anything that matches
what I observed.
Thanks for any idea,
Joe.
Brian Utterback
May 18, 2013, 2:10:45 PM5/18/13
to
On 5/18/2013 3:14 AM, Joe the Shmoe wrote:
> Zooming on these I see two types of requests:
> - received symmetric active from unconfigured hosts, which get answered
> by symmetric passive from my host. Here the point I do not understand is
> that the NTP server is configured in a way to "Deny packets that might
> mobilize an association unless authenticated." Shouldn't the server
> ignore the request rather than answering them by a symmetric passive
> message?
This is non-intuitive and arguably incorrect according to the RFC, but
> Zooming on these I see two types of requests:
> - received symmetric active from unconfigured hosts, which get answered
> by symmetric passive from my host. Here the point I do not understand is
> that the NTP server is configured in a way to "Deny packets that might
> mobilize an association unless authenticated." Shouldn't the server
> ignore the request rather than answering them by a symmetric passive
> message?
it is the programmed behavior. There was a time when all Windows
clients used symmetric active mode, so to work around that ntpd with
nopeer configured responded with symmetric active mode packets but did
not mobilize the association. I don't know if they still use symmetric
active by default. Perhaps this should be revisited.
>
> - Other symmetric active requests come from the server itself toward one
> of the 5 configured hosts. But the server only makes use of "server" in
> the configuration (no "peer" statement). This occurs after a first NTP
> client request to that configured host which get answered by two NTP
> server from the configured host.
Brian.
Joe the Shmoe
May 19, 2013, 5:28:47 AM5/19/13
to
On 18/05/2013 20:10, Brian Utterback wrote:
> On 5/18/2013 3:14 AM, Joe the Shmoe wrote:
[...]
> On 5/18/2013 3:14 AM, Joe the Shmoe wrote:
>
> This is non-intuitive and arguably incorrect according to the RFC, but
> it is the programmed behavior. There was a time when all Windows
> clients used symmetric active mode, so to work around that ntpd with
> nopeer configured responded with symmetric active mode packets but did
> not mobilize the association. I don't know if they still use symmetric
> active by default. Perhaps this should be revisited.
Thank you for your explanations. I now understand the reason. Having
> This is non-intuitive and arguably incorrect according to the RFC, but
> it is the programmed behavior. There was a time when all Windows
> clients used symmetric active mode, so to work around that ntpd with
> nopeer configured responded with symmetric active mode packets but did
> not mobilize the association. I don't know if they still use symmetric
> active by default. Perhaps this should be revisited.
made some tests after my question here, there is effectively a
difference with a real symmetric passive which is shown by the 'peer'
command of ntpdc or ntpq (= an association is mobilized?), while here
hopefully that sort of "faked symmetric" exchanges on network side, do
not show with that same command. I guess, one cannot introduce false
time information to my server that way, if for example, the "symmetric
client" spoofs a stratum 1 server.
>
>>
>> - Other symmetric active requests come from the server itself toward one
>> of the 5 configured hosts. But the server only makes use of "server" in
>> the configuration (no "peer" statement). This occurs after a first NTP
>> client request to that configured host which get answered by two NTP
>> server from the configured host.
>
> Can you post the traces? I am not sure I follow.
ftp host: edrusb.is-a-geek.org
login: nobody
password: ntp
>
> Brian.
Regards,
Joe.
Brian Utterback
May 20, 2013, 8:42:27 AM5/20/13
to
Okay, that looks really weird. Just the rate of the packets seems very
off, only 10s of milliseconds between packets.
The system whose IP address ends in b900::1:1 doesn't like it. The
second packet it sends is a KOD packet that is complaining about the
high rate of packets, and then it shuts down and refuses to respond
anymore.
Packets 2 and 3 of the trace are the same packet, but with the hop count
decremented from 56 to 51.
Actually, on closer inspection, of the 24 packets in the trace
transmitted by 823d:1b13, they are all duplicates of only two packets.
The same two packets are looping around your network, with the hop count
going down by 5 each time, until they hit zero and are dropped.
Now, I grant that which ones are sending client, server, and symmetric
active and symmetric passive is odd, but until you fix the looping,
there is no telling what is causing that. It might be an artifact of the
looping.
> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
off, only 10s of milliseconds between packets.
The system whose IP address ends in b900::1:1 doesn't like it. The
second packet it sends is a KOD packet that is complaining about the
high rate of packets, and then it shuts down and refuses to respond
anymore.
Packets 2 and 3 of the trace are the same packet, but with the hop count
decremented from 56 to 51.
Actually, on closer inspection, of the 24 packets in the trace
transmitted by 823d:1b13, they are all duplicates of only two packets.
The same two packets are looping around your network, with the hop count
going down by 5 each time, until they hit zero and are dropped.
Now, I grant that which ones are sending client, server, and symmetric
active and symmetric passive is odd, but until you fix the looping,
there is no telling what is causing that. It might be an artifact of the
looping.
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
Joe the Shmoe
May 20, 2013, 3:24:50 PM5/20/13
to
On 20/05/2013 14:42, Brian Utterback wrote:
> Okay, that looks really weird. Just the rate of the packets seems very
> off, only 10s of milliseconds between packets.
>
> The system whose IP address ends in b900::1:1 doesn't like it.
the host ...:1:1 is my server. He is configured to ask time from
> Okay, that looks really weird. Just the rate of the packets seems very
> off, only 10s of milliseconds between packets.
>
> The system whose IP address ends in b900::1:1 doesn't like it.
...:1b13 as a client (using ntpd 4.2.6p2). So the first packet is OK.
> The
> second packet it sends is a KOD packet that is complaining about the
> high rate of packets, and then it shuts down and refuses to respond
> anymore.
>
initiating a symmetric active exchange toward that host, it is only a
KOD. I still remains that the mode used for that KOD is not identical to
the initial client request (mode 1 instead of mode 3)...
And also I see that subsequent symmetric active packets sent by my host
are no more KOD but rather what seems to be plain normal symmetric
active packet, while the ntpd configuration makes uses of the "server"
directive not of the "peer" one (!)
> Packets 2 and 3 of the trace are the same packet, but with the hop count
> decremented from 56 to 51.
>
> Actually, on closer inspection, of the 24 packets in the trace
> transmitted by 823d:1b13, they are all duplicates of only two packets.
> The same two packets are looping around your network, with the hop count
> going down by 5 each time, until they hit zero and are dropped.
network somewhere probably near the ...:1b13 host, because I have normal
exchanges from ...:1:1 host toward other destinations in IPv6 too.
>
> Now, I grant that which ones are sending client, server, and symmetric
> active and symmetric passive is odd, but until you fix the looping,
> there is no telling what is causing that. It might be an artifact of the
> looping.
>
Internet in IPv4/IPv6, I can't see how I can make a loop here as
moreover my host is configured not forwarding IPv6 packets, after this
is my ISP domain...
What I retain, is that I'd better change my configuration not asking
time to ...:1b13 server due to the network loop involved somewhere out
of my perimeter.
So remains two weird points, but don't waste your time with that:
- the KOD is not using the same mode as the request (mode 3), maybe a
detail?
- subsequent packet sent are no more KOD packets ...
I just hope that this might not be exploitable to have an ntpd server
synchronizing to a arbitrary faking stratum 1 server, for example... I
have configure the "floor" to the stratum value of servers I get time
from to reduce this risk, but I should also better update the software
to a more recent version.
Thank you very much for your pertinent explanations ! :)
Regards,
Joe.
0 new messages