Internet2 Network Security SIG

[gcbrowni <>]

Yeah, I checked the multiple loopback thing. No dice. And the FXP’s are not up.

Juniper let us in on some new NTP commands. We tried it on one of the nodes and it doesn’t log the message anymore ... implying that this WAS in response to a received request from a packet. I’m willing to say now that it’s not being self-generated, eliminating option #6. We’re still working on additional data gathering techniques. We’re apprehensive about "fixing" it without understanding what was causing it.

NTP
It looks like this works in the 15.1 code train, and, while not perfect, gets us a long way to shutting off the server capabilities of the NTP system on the Juniper routers:

set system ntp restrict noquery
set system ntp restrict noserve

On Sep 22, 2017, at 11:58 AM, Richard Angeletti <> wrote:

In regards to:

5) All RE bound packets inbound MUST pass through the RE/loop filter, correct?

If you have multiple loopback (sub)interfaces, do you have the RE filter to every loopback interface ?

On Fri, 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





-- 
Rich Angeletti 

Network Engineering 
3ROX/PSC

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