Switching

We just had an internal security scan run and the Nessus software found this vulnerability on our Juniper EX4200 switches running Junos 15.1R7.9. We do point all of our Juniper switches to our internal ntp server via this command.

ntp {
    server 10.121.125.101 prefer;

}

Can I somehow fix this so these switches do not respond to this NTP query? We do sit behind a firewall that should mitigate that ability for someone to run an attack but I still thing it is important to rectify this issue.

For this situation you do need to open a TAC case, and get them to work the SIRT change into the 15.1 code stream for EX4200.  You should also ask them to include in next 12.3 SR.

We had the same internal security audit run last year and the same vulnerability was identified. I did not pursue it at that point since the Nessus software identified quite a few other problems we did work on. So what you are saying is this issue has existed for awhile and Juniper has just not addressed it in Junos to date?

Do you know what the SIRT vulernability (CVE) for this situation is?  I believe it might be CVE-2016-9310.  A quick search brings up this link:

https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10796&actp=METADATA

From looking at this, it appears EX4200 not affected?  I would still think this type of situation should be work (at least in parallel) with TAC.

I opened a ticket with JTAC about this same vulnerability on our EX4600 core. They pointed me to this

This vulnerability has been described on security bulletin JSA10613: https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10613&actp=METADATA and PR 1234119 https://prsearch.juniper.net/PR1234119

They said the best way to mitigate this is a firewall rule, here is what they wrote

If a possible attack has been identified, or if the NTP process is occupying a large amount of CPU or memory resources, the most effective mitigation is to apply a firewall filter to allow only trusted addresses and networks, plus the router's loopback address, access to the NTP service on the device, rejecting all other requests.  For example:
 

term allow-ntp {

    from {

        source-address {

            <trusted-addresses>;

            <router-loopback-address>;

        }

        protocol udp;

        port ntp;

    }

    then accept;

}

term block-ntp {

    from {

        protocol udp;

        port ntp;

    }

    then {

        discard;

    }

}

This term may be added to the existing loopback interface filter as part of an overall control plane protection strategy.  In general, security best practices recommend having such a filter term, even during normal operation.

I have been doing a lot of reading about how to protect against an NTP deflection attack. Nearly all of it talks about protecting the routing engine and applying some type of firewall filter to the loopback port. I do have a stack of EX4600s at the core of our network that provides layer 2/3. All of my edge switches are EX4200 that are strictly layer 2. All of the routing happens at the core. What I am not sure of is how to setup a firewall filter for ntp traffic for these edge switches.

The firewall filters are applied to the layer 3 interface where you have the mgmt address for the switch configured.  This is the address where traffic for the routing engine is processed.  Once the filter is in place only the authorized ntp traffic is accepted on the mgmt address for the switch itself.