Routing
Highlighted
Routing

Strange DDOS attack break all connections

‎04-10-2017 12:23 AM

Hello Friends ,

 

 

We are getting a strange attack that makes the MX80 inaccessible. Attack is coming from multiple sources (NTPv2 Reflection) to UNUSED ip addresses .

 

I have seen an exact same issue on discussion mailing list today. Is there any body know a bug about that ? or faced with sth. like that ?

 

 

 

Screen Shot 2017-04-10 at 10.04.17.pngScreen Shot 2017-04-10 at 10.03.34.pngScreen Shot 2017-04-10 at 09.43.34.pngScreen Shot 2017-04-10 at 09.43.29.png

4 REPLIES 4
Highlighted
Routing

Re: Strange DDOS attack break all connections

‎04-11-2017 04:40 PM

I'm not aware of any bugs related to this.  But I think you are saying you are under a DDoS attack of the NTP refection variety.  For this you can apply a firewall filter to you input on the interface where the traffic arrives to block the attack.

 

Create a prefix list of the NTP servers you use:

set policy-options prefix-list pool_ntp_org x.x.x.x/32

 

A blocking filter for the rest

set firewall family inet filter protect-ntp term allow-ntp from source-prefix-list pool_ntp

set firewall family inet filter protect-ntp term allow-ntp from protocol udp

set firewall family inet filter protect-ntp term allow-ntp from source-port 123

set firewall family inet filter protect-ntp term allow-ntp then count allow-ntp

set firewall family inet filter protect-ntp term block-ntp from protocol udp

set firewall family inet filter protect-ntp term block-ntp from source-port 123

set firewall family inet filter protect-ntp term block-ntp then count block-ntp

set firewall family inet filter protect-ntp term block-ntp then reject

set firewall family inet filter protect-ntp term allow then accept

 

Apply to the input of the inbound interface

set interfaces xe-0/0/0 unit 0 family inet filter output protect-ntp

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
Routing

Re: Strange DDOS attack break all connections

‎04-12-2017 01:06 PM

We have faced with a SSDP Amplification , unfortunately result was same. 

We have a Routing instance. And we connect routing instance to main router via LT interface . So we have write some rules on main router interface's filter and LT's filter and put a firewall between of them

 

Xe-0/0/0   ------------   LT 0.0  --------- LT 0.1 (Routing Instance Side) ------- Xe-0/0/3

 

Xe-0/0/1 and 2 is firewall ports so we route some ip addresses to FW from ISP zone and internal zone.

 

We realize that LT interface is having traffic 3x more then real traffic between the routing instance and main router , there would be a loop but why ? do you faced with sth. like that  

Highlighted
Routing

Re: Strange DDOS attack break all connections

‎04-16-2017 06:05 AM

I am not sure I understand fully the issue so this may be off track.

 

For DDoS mitigation, you will want the filter applied to the interface closest to the attack.  In other words the interface where the attack traffic first enters your network or this MX.  If you apply the filter on the input of this interface the reset of the interfaces are already covered because the traffic is dropped before reaching them.

 

I don't understand why the traffic would be higher in volume on a downstream interface or increased as it traverses your network.  That does seem to indicate some kind of internal routing problem.  Or perhaps equipment on your network or systems compromised and participating in the attack.

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Routing

Re: Strange DDOS attack break all connections

‎04-30-2017 07:41 PM

Hi Folks,

 

Please refer to the below Security Bulletin,

 

2014-07 Security Bulletin: Junos: NTP server amplification denial of service attack (CVE-2013-5211)

 

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

 

 

WORKAROUND:

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.

Also, note that the router loopback address must be included under the NTP allow term. If the loopback is not allowed, ‘show ntp’ commands will time out.

User@Router> show ntp status

localhost: timed out, nothing received

***Request timed out



Using the above filter allows only trusted sources to request the NTP service, but if you are interested in identifying the sources of unwanted NTP requests, add the 'log' action to the term block-ntp along with the 'discard' action.  For example:

term block-ntp {

    from {

        protocol udp;

        port ntp;

    }

    then {

        log;

        discard;

    }

}


If your trusted IPs are spoofed, then you will have to apply the 'log' action to the allow-ntp accept action as well. This will help in identifying misbehaving trusted sources as well.

term allow-ntp {

    from {

        source-address {

            <trusted-addresses>;

            <router-loopback-address>;

        }

        protocol udp;

        port ntp;

    }

    then {

        log;

        accept;

    }

}


Once you identify the source of unwanted NTP requests, take appropriate action to block them at the network perimete, and delete the 'log' action from the filter term.

 

-Python JNCIE 3X [SP|DC|ENT] JNCIP-SEC JNCDS 3X [ WAN | DC|SEC] JNCIS-Cloud JNCIS-DevOps CCIP ITIL
#Please mark my solution as accepted if it helped, Kudos are appreciated as well.
Feedback