netsec-sig - [Security-WG] I2 - Strange xntpd behavior
Subject: Internet2 Network Security SIG
List archive
- From: gcbrowni <>
- To:
- Subject: [Security-WG] I2 - Strange xntpd behavior
- Date: Fri, 22 Sep 2017 10:53:24 -0400
- Ironport-phdr: 9a23:RUMa4hD3zY6RLFDeWAsTUyQJP3N1i/DPJgcQr6AfoPdwSPvyp8bcNUDSrc9gkEXOFd2CrakV26yO6+jJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fdbghMhzexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfOpWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnMVhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Xymp4aV2Rx/ykCoJNyI2/27KhMJzgqxVvgmspxNjz47ReoyZKOZyc6HbcNgHRWRBRMFRVylZD4Ozc4QAFPABPeFWron7plsFsByzBQawC+z00D9IgXH33as70+k6HgHG2AsgEMkUv3TQqtX1M7sdXfq0zKnV1znMce5Z2Srk5YXObxsvr/aMXbdqfsrQz0kiDwLFjlOMqYP7JTOV0PoCs3SF4+Z6S+2glnMnpxl3ojipwMcsjJPFhoQLxVDY8yhy3YU7JcWgRUJmbtOpFIFcuzybOoZ2WM8uXm9ltSkgxrAEtpO2ejUBxo49yB7FcfOHdpCF4hL9W+aVJjd1nHdld6i+hxa260Sv1vH8WdWu3FZFtCpFlN7MuWwX2xzS98iLUOVy8Vq82TqX1gDT7P9LIVwsmKbGJJMsxqQ8mocSvEnDBCP6hUv7gaCMekgm9eWk8+Hnba/npp+YOY90kAb+MqE2l8ywHes3KRIOX2+V+OS61b3u5kL5QLFNjvItiKbZtJbaJcMHqaKjAg9Vz5wv5AiiADe7yNgYh2UILEpZeBKbiIjkI0rOL+7kAveimVSskStrxvDfMrzvDZXANXzDkLb6fbZh8E5Q1hA/zdFZ55JIFL4BOvTzVVHttNDGFBM2LRG7w/u0QOl6g5gTUn+VA7OIdbzdmV6O+u81JeSQPskYtCuuBeIi4qvhhnUjnkAbfOH90pAdcnenGPVOLEGea3PohNAKV2YX+AcyUbq52xW5TTdPaiPqDOoH7TYhBdf+AA==
A little help? The message looks like: 2017-09-21T16:02:51+00:00 nnnn.net.internet2.edu xntpd[70981]: sendto(A.B.C.D): No route to host Node nnnn is telling me that that the NTP process (xntpd) can’t send a packet to IP A.B.C.D. This is because A.B.C.D is in the CPS table and not in the R&E table. That checks out. But … there are loopback filters in place that should prevent the router ever accepting the NTP packet from A.B.C.D in the first place. I can’t figure out why/the-triggerring-event that is causing the router is trying to send NTP to that host. 1) The first first term in the filter is a syslog that matches on "port 123". If it matches any tcp/udp on port 123 it syslogs and then next terms. I see our normal and expected NTP traffic being syslogged. Our final "deny" term is showing the non-authorized attempts to connect to us. But I DONT see anything from A.B.C.D on port 123. 2) I don’t think you can send NTP data to the router on any port other than 123. Correct? 3) I don’t think there’s a way to get a 3rd party response. A sends NTP to B who responds to C. I don’t think that’s possible.That means it can’t look like a spoofed source IP from a valid IP. 4) Related to #3, I don’t think you can compose a v6 packet in such a way that it will respond to a v4 address … so it can’t be the v6 filter that’s the issue. 5) All RE bound packets inbound MUST pass through the RE/loop filter, correct? 6) Is there any reason for XNTPD to generate this message from an event OTHER than receiving an NTP packet through the filter. In response to something other than NTP? Trace, ping, a shell command/login? I don’t thin this can happen. Anyone have any other ideas? -G |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
- [Security-WG] I2 - Strange xntpd behavior, gcbrowni, 09/22/2017
- Re: [Security-WG] I2 - Strange xntpd behavior, Andrew Gallo, 09/22/2017
- Re: [Security-WG] I2 - Strange xntpd behavior, gcbrowni, 09/22/2017
- Message not available
- Re: [Security-WG] I2 - Strange xntpd behavior, John Kristoff, 09/22/2017
- Re: [Security-WG] I2 - Strange xntpd behavior, Richard Angeletti, 09/22/2017
- Re: [Security-WG] I2 - Strange xntpd behavior, gcbrowni, 09/25/2017
- Re: [Security-WG] I2 - Strange xntpd behavior, Andrew Gallo, 09/22/2017
- <Possible follow-up(s)>
- Re: [Security-WG] I2 - Strange xntpd behavior, John Kristoff, 09/22/2017
Archive powered by MHonArc 2.6.19.