Skip to Content.
Sympa Menu

netsec-sig - Re: [Security-WG] I2 - Strange xntpd behavior

Subject: Internet2 Network Security SIG

List archive

Re: [Security-WG] I2 - Strange xntpd behavior


Chronological Thread 
  • From: gcbrowni <>
  • To:
  • Subject: Re: [Security-WG] I2 - Strange xntpd behavior
  • Date: Fri, 22 Sep 2017 11:50:01 -0400
  • Ironport-phdr: 9a23:J3la4RTgG/yCV0jMQdADPHUJtNpsv+yvbD5Q0YIujvd0So/mwa69YxKN2/xhgRfzUJnB7Loc0qyN4vCmATRIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+KPjrFY7OlcS30P2594HObwlSijewZbB/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbDVwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4qF2QxHqlSgHLSY0/mHLhcN/kaxVrhyhqQJ9zIDXe4yVO+ZyfqbHcN8GWWZMXMBcXDFBDIOmaIsPCvIMPelEoIbmvVsOqhW/BQ+tBOjyzTJIiWP50rYg0+QmHwDG2g0gEskBsHTQq9X6L70dUeSzzKnP0TrPdfJW2Srn5IfWbx8hvOiBULRtesTfzkkvEhnKjlSWqYH9PjOV0PgNvHaB7+pmS+2vl3ArpxtvrTey28chjJTCiIENyl3c6Cl0z4I4KcelREN6YdOoCoZcui+VOodsQM4vTGdlszsgxLIco560Zi0KxYwnxxHBb/yHdJCF4hf5W+aQJTd0nm5qeK6jiBqo/kig0Ov8Vs6o31pQrypFj8PAuW4Q2BzO8sSHS/198Vm92TuXygze5eVJLVopmafaK5Mt2KM8m5QcvEjZHCL7l136jKqMeUUl/uio5f7nYrLjppKEOI97lhrxMr4pms2xB+Q4MxMDX2ef+eS7z7Ls50n5QLNNjvIqiKXZsY3aKd4FqaGkHg9Zypwj5AqnDze6zNQYmmEKLElbdx2bkojpIVDOIOz4DPumjVWsnyxmx/THPr36HpXNNWbPnK3gfbZ7905T1hAzzdZB6JJIFL0NOuz8VVLstI+QMhhsKAG/3vzmFMQ4yYw2WGSTD7WfPb+I91KE+7EBOe6JMYAesiz6NP4kr6rhhnUjnkAbfIGm2ZwdYXS+Gf8gIljfbHbx1IRSWVwWtxYzGbS5wGaJViReMi6/

John:
ntp.conf is as expected with just out NTP server in it, we don’t do outbound RE filters, and I don’t think A.B.C.D is an NTP server. I THINK this is somehow scanning related. I think. 

Andrew:
Hard to address intervals. It’s not a pattern I can detect, although we do see it more often at certain time blocks. But it’s not a nice pretty pattern when time mapped. I doubt A.B.C.D is a legit attempt to request time. I THINK it’s either an attempt to amplify or a scan. I think. But that all assumes it’s a response to a packet coming in.

I see this on multiple nodes and I see it from multiple source IP’s, although there are a few nodes and source IP’s that appear more often than others. I might get 5 in a 2-3 day period.

Mirroring
I thought about this. If syslog "port 123" doesn’t work then I’m suspicious that mirroring would turn anything up. It’s still an option, but it’s not high on the list because of the resources currently required.









On Sep 22, 2017, at 11:34 AM, Andrew Gallo <> wrote:

Couple of questions-


Is this happening intermittently, or at set intervals?

Is A.B.C.D a legit IP attempting to request time, even if it should be filtered?  Any chance you could mirror the packet in the filter?

I just tried sending a Juniper router random traffic on udp 123- nothing was logged.


On 9/22/2017 10:53 AM, gcbrowni wrote:
A little help?

I’m seeing some syslog messages that indicate the router is trying to respond/do something related to NTP. I understand the error message proper but I don’t understand WHY the router is trying to engage in NTP activity.



The message looks like:
2017-09-21T16:02:51+00:00 nnnn.net.internet2.edu <http://rtsw.port.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

-- 
________________________________
Andrew Gallo
The George Washington University

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.19.

Top of Page