Screen OS

The Juniper SSG-140 has an "ICMP Flood Protection" option.  We tried enabling that with a threshold as low as 10, and it still does not seem to protect us from ICMP Flood attacks.  We currently have an IP that our upstream provider has had to blackhole because if they allow the traffic through on that IP it takes our entire network offline and we have a stream of log entries on the Juniper such as the following:

2013-11-04 11:54:48     alert     ICMP flood! From 1.7.8.43 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 2955 times.
2013-11-04 11:54:46     alert     ICMP flood! From 66.242.243.144 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 1021 times.
2013-11-04 11:54:44     alert     ICMP flood! From 221.150.195.4 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 2815 times.
2013-11-04 11:54:43     alert     ICMP flood! From 194.21.21.95 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 2047 times.
2013-11-04 11:54:42     alert     ICMP flood! From 139.89.241.149 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 7164 times.
2013-11-04 11:54:41     alert     ICMP flood! From 36.117.185.226 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 1020 times.
2013-11-04 11:54:38     alert     ICMP flood! From 218.168.87.67 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 1516 times.
2013-11-04 11:54:35     alert     ICMP flood! From 118.251.44.55 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 4244 times.
2013-11-04 11:54:33     alert     ICMP flood! From 34.231.106.8 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 3053 times.
2013-11-04 11:54:32     alert     ICMP flood! From 222.240.81.182 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 1022 times.
2013-11-04 11:54:29     alert     ICMP flood! From 223.223.38.61 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 2180 times.
2013-11-04 11:54:26     alert     ICMP flood! From 2.169.220.141 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 3459 times.
2013-11-04 11:54:24     alert     ICMP flood! From 219.97.67.4 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 3731 times.
2013-11-04 11:54:21     alert     ICMP flood! From 54.56.57.180 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 3277 times.
2013-11-04 11:54:18     alert     ICMP flood! From 142.250.5.214 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 2750 times.
2013-11-04 11:54:17     alert     ICMP flood! From 95.51.87.53 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 2812 times.
2013-11-04 11:54:16     alert     ICMP flood! From 180.13.83.57 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 1024 times.
2013-11-04 11:54:13     alert     ICMP flood! From 87.80.29.95 to xxx.xxx.xxx.xxx, proto 1 (zone Untrust, int ethernet0/2). Occurred 1496 times. 

...and our uplink connection is instantly saturated until we have them re-blackhole the ip.  Why is it showing "Occurred" counts in the thousands when ICMP was supposed to be ignored after 100 pps?  Does the "ICMP Flood Protection" feature not work?

Check your config for the following line:

set zone Untrust screen alarm-without-drop

(->  get conf | include alarm-without-drop)

---

@keithr wrote:

Check your config for the following line:

set zone Untrust screen alarm-without-drop

 

(->  get conf | include alarm-without-drop)

 

 

---

That was a good idea, but I don't have that line in my configuration.  In fact, if I set the ICMP threshold to 1 and then ping from more than one server on the outside, it definitely starts dropping packets. But, in the case of the DDoS ICMP Flood attack that is hitting one of our IPs, the ICMP Flood Protection feature seems completely in effective.  All I can think is that the ping volume is more than the Juniper can defend against.  Any other ideas on how to block this would be appreciated.

Thanks!

Take a look at this KB article, which mentions:

---

ScreenOS provides a Screening option called as ICMP Flood Protection, which protects against this attack.  When enabling the ICMP flood protection feature, you can set a threshold that once exceeded invokes the ICMP flood attack protection feature.   (The default threshold value is 1000 packets per second.)   If the threshold is exceeded, the security device ignores further ICMP echo requests for the remainder of that second plus the next second as well.

---

Repeated / ongoing attacks will only be partially quashed.  When the threshold is exceeded, it will drop packets for up to the next 2 seconds, then packets will be allowed again, and then the threshold will be exceeded, so it will drop for up to 2 seconds, then permit packets again......

Lather, rinse, repeat.

While I would argue that this is probably a naive or somewhat unsophisticated way of handling these attacks, ScreenOS *is* on the legacy side of the firewall market.  There's no real-time blacklist or dynamic blacklisting, or configurable thresholds for "when XYZ happens, block the offending host/network for ABC seconds/minutes/hours" functionality, which would be AWESOME.

What I ended up doing to solve issues like this in the past was far more work than I felt it should have been, but ya gotta do what ya gotta do -- basically what I did was monitor the screen logs, correlate that with Netflow / sFlow data we were collecting, and use some scripting to dynamically generate a blacklist ACL on my edge routers with a timer on it.  When the timer expired, the blacklisted hosts would be allowed back through.  If a host/network was blocked 3 times within 24 hours, they would remain blocked, a notification would be generated and sent to the security department for review, and then if they decided to unblock or leave the offender blocked, we'd implement the change.

Excellent idea, kr.

As the Juniper is connected directly to our upstream provider, it is the only thing we have to work with.  Our upline provider can blackhole the IP they're attacking, but they're unable to block lists of source IPs. 

If we were to create a policy on the Juniper to block the IPs involved in the attack (it logged over 80 IPs), would that work?  If so, we could create a script that parsed the logs and automatically blocked them using Juniper's CLI.   Or is the Juniper simply not able to deal with DDoS type attacks? 

---

@spockdude wrote:

 

If we were to create a policy on the Juniper to block the IPs involved in the attack (it logged over 80 IPs), would that work?  If so, we could create a script that parsed the logs and automatically blocked them using Juniper's CLI.   Or is the Juniper simply not able to deal with DDoS type attacks? 

---

You could do something like that... but it's likely not going to solve the issue entirely.

* Note -- this _could_ have changed in the years since I looked into it... *

Every icmp packet is still going to hit the firewall, and the firewall is still going to create a session for it, even if the action is DROP/DENY due to the way ScreenOS is built.  The session will be short-lived and should recycle reasonably quickly, but it's not difficult to max out the session table of an SSG with a ICMP or SYN flood if it's happening fast enough.  This will still DoS your site as your firewall will be exhausted for resources.

Also, and this is more obvious than the last point, if the packets aren't getting dropped until they reach your network, then they're going across your circuit(s) and consuming bandwidth.  If you're bandwidth-limited, a fast enough DDoS could be sending enough packets, even though they're small, to cause you a bandwidth / congestion problem.  By blocking the attacks at the ISP level, that prevents the bad packets from crossing the wire into your network and consuming your bandwidth.  If that's not an option, the best you can do then is to try and stomp the packets as they get into your network.

I was afraid of that. So, I guess the only way to deal with this is upstream.  Unfortunately, they've offered very little help with this.  😕