DDoS Attack - How to mitigate in an ISP?

[#1]

Hello, we are witnessing a Distributed DoS attack from ports 23, 2323, 17 and 53. We have two 500 bps providers and some ISP clients and when the attack occurs we saturate the providers. If we block the attacks in the router we are also saturated because the traffic is not connection oriented. I leave an image to explain it

I think the best way to mitigate this is with BGP communities, we have the blackhole bgp communities of our suppliers but we do not know how to detect the attack with the MX5. Someone could help me? I need to detect the DDoS attack and the attacked IP apply the blackhole community so that the providers discard that traffic.

Attacked IPs are from ISPs and are random.

Thank you!

Luciano

[#2]

Hello,

Do You really think You can announce the random IP/32 from all over the world to Your ISPs and then Your ISPs are supposed to drop the traffic with these src IP?

Either Your providers are using the bleeding edge technology or You misread their blackholing policies. 

For instance, NTT blackholing policy https://us.ntt.net/support/policy/routing.cfm#blackhole explicitly reads 

The /32 or /128 prefix must be one included in the customer's 
existing ingress BGP filter

Which means that if Your ISP is NTT, and You are attacked with spoofed src IP 8.8.4.4. (8.8.4.4 belongs to GOOG) then You won't be able to announce e.g. 8.8.4.4/32 to NTT with blackholing community. No way. If NTT would allow You to do that, they will shoot themselves into the foot: Your 8.8.4.4/32 announcement would be most specific and all DNS traffic within NTT destined to 8.8.4.4 would go to Your MX5.

Same with Hurricane Electric ISP https://www.he.net/adm/blackhole.html - You are supposed to [a] null-route Your OWN /32 under attack and [b] announce it to HE with blackhole community 6939:666 . 

I suggest You to read RFC 5635 https://tools.ietf.org/html/rfc5635 to understand how destination RTBH and source RTBH work, and then decide if You want to announce Your own /32 under attack to get it blackholed - i.e. "complete the attack on the behalf of the attacker" as described in RFC 5635 section 3.1.

And to answer Your original question - on a very high level, You would need to enable Netflow on MX5 and install a collector that can give You "top talkers" IP and ports - that's where You get the attack src IPs from. Please see https://www.forwardingplane.net/2013/09/inline-jflow-on-mx-series-juniper/ for a working example.

HTH

thx

Alex 

[#3]

Hi Alex! I expressed it incorrectly. The idea is to publish to the providers of the IP attacked with the Blackhole community.

But how do I detect an attack? by netflow using software, example fastnetmon.com, but how do I apply the policies automatically in the MX5?

Thanks!

Luciano.

[#4]

Hello,

---

@Luciano Raffaldi wrote:

how do I apply the policies automatically in the MX5?

---

With fastnetmon.com specifically,  I believe You can use iBGP to advertise dst IP/32 being attacked from fastnetmon server to Your MX5, and then announce these IP/32 to Your ISP.

With other collectors that do not support BGP, you can use Python script with Juniper PyEz library (https://github.com/Juniper/py-junos-eznc) running on that collector server  to connect to Your MX5 via SSH & configure the required IP/32 in Your MX5 as static/BGP static routes

JUNOS BGP static route

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/bgp-static-routes-config...

More PyEz info :

https://www.juniper.net/documentation/en_US/junos-pyez/information-products/pathway-pages/junos-pyez...

HTH

Thx

Alex

[#5]

Hello!

Yes, that's right. From FastNetMon's side we offer complete support for BGP unicast (for blackhole announces) and BGP Flow Spec (RFC 5575) to filter out only malicious traffic. using your router. More details you could find here: https://fastnetmon.com/advanced-quick-start/ 

As more flexible option we offer script callback and you could implement any language and use custom API to change JunOS settings: https://fastnetmon.com/fastnetmon-advanced-notify-script-in-perl/ and https://fastnetmon.com/notify-script-in-bash/ 

For number of vendors (Radware, A-10 Networks, Mikrotik) we offer out of the box integration. 

[#6]

Hi Folks,

Please find my favorite DDOS Commands to isolate/troubleshoot DDOS issues in Junos MX routers with MPC: [My favorite List]

show ddos-protection protocols statistics terse  <<< who is violating at this point; check the state

show ddos-protection protocols statistics brief  <<< Show brief output for all Protocol

show ddos-protection protocols statistics detail <<< Show detail output for all Protocol 

show ddos-protection statistics                        <<< Show overall statistics

show ddos-protection protocols parameters detail <<< show detailed configured/default ddos-protection protocols parameters

show ddos-protection protocols parameters brief

show ddos-protection protocols parameters | no-more <<< to see the default values

show ddos-protection protocols violations           <<< Show summary of all protocol violations

show ddos-protection protocols ip-options flow-detection

show ddos-protection protocols flow-detection | no-more  

show ddos-protection protocols flow-detection detail | no-more

clear ddos-protection protocols arp states

clear ddos-protection protocols statistics

show ddos-protection protocols arp violations

show ddos-protection protocols arp culprit-flows

[#7]

To add.. With SCFD you will be able to identify the culprit flow in your MX and drop the traffic in the box; [however up link will be still used; but the box will not be spared]

SCFD:

# set system ddos-protection global flow-detection

# set system ddos-protection protocols arp aggregate bandwidth 10000

# set system ddos-protection protocols arp aggregate burst 1000

# set system ddos-protection protocols arp aggregate flow-detection-mode on

CLI:

show ddos-protection protocols arp violations

show ddos-protection protocols arp culprit-flows

clear ddos-protection protocols culprit-flows

clear ddos-protection protocols arp states

clear ddos-protection protocols arp statistics

clear ddos-protection protocols ipv4-unclassified states

clear ddos-protection protocols ipv4-unclassified statistics

clear ddos-protection protocols ttl states  

clear ddos-protection protocols ttl statistics

clear ddos-protection protocols reject states

clear ddos-protection protocols reject statistics

clear ddos-protection protocols tcp-flags established states

clear ddos-protection protocols tcp-flags established statistics  

[#8]

Hello,

---

@python wrote:

Hi Folks,

Please find my favorite DDOS Commands to isolate/troubleshoot DDOS issues in Junos MX routers with MPC: [My favorite List]

---

That'cool but this is router self-protection from DDOS. 

It has nothing to do with DDOS aimed at subnets behind the router, except few cases like DDOS targeting non-existent IPs in a subnet connected to the router.

HTH

Thx
Alex

[#9]

Hi again,

---

@python wrote:

To add.. With SCFD you will be able to identify the culprit flow in your MX and drop the traffic in the box; [however up link will be still used; but the box will not be spared]

---

Again, this is useful to identify DDOS aimed at a router, or connected subnet but useless in case of volumetric DDOS aimed at subnets behind the router.

The OP asked to mitigate the uplink saturation in case of DDOS attack, and the commands You cited are for the diferent use case.

HTH

Thx
Alex