ICMP Unreachable DoS Attacks (aka "Black Nurse")
Thanks to our reader Mikael for pointing out a new branded vulnerability with domain name, logo and catchy name: "BlackNurse". (no jingle though). [1]
The problem pointed out by this announcement is that firewalls can spend significant resources on processing these relatively common ICMP error messages. Type 3 error messages are used for various "Unreachable" messages. For example, Type 3 Code 3 is used for port unreachable. For a complete list, see the official IANA list [2] .
The announcement doesn't make any statements as to why these packets take up so much CPU time. In my opinion, this is likely due to the firewall attempting to perform stateful analysis of these packets. ICMP unreachable packets include as payload the first few bytes of the packet that caused the error. A firewall can use this payload to determine if the error is caused by a legit packet that left the network in the past. This analysis can take significant resources.
According to the description of the attack, firewalls will suffer performance issues if hit by a few 10s of MBits of ICMP traffic, even for firewalls that are supposed to be able to dell with Gigabit networks. The "fix" is to block or rate limit the traffic.
It is not recommended to block all Type 3 ICMP messages. In particular Type 3 Code 4 (Fragmentation Needed and Don't Fragment was Set) messages are requied for path MTU discovery, which many modern operating systems use. Port unreachable messages (Type 3 Code 3), which were used in most of the tests performed by the group releasing this vulnerability, can usually be blocked but you may see some performance issue if for example a DNS resolver is attempting to connect to a non-existing DNS server, and then delays trying a secondary server because it never receives the port unreachable message.
So what should you do?
- Don't panic. This is not a big deal. Test your firewall if you can, or check if is on the vulnerable list
- You are vulnerable if you use a smaller Cisco ASA firewall. Newer/Larger multi-core versions appear to be fine. SonicWall and "some" Palo Alto firewalls appear to be vulnerable too.
- iptables based firewalls are not affected
- Monitor incoming ICMP unreachables. The advisory includes some snort rules to do so, but anything monitoring ICMP should work (netflow?) as no payload inspection is necessary
- Cisco does not consider this a security issue. There is no CVE.
[1] http://www.netresec.com/?page=Blog&month=2016-11&post=BlackNurse-Denial-of-Service-Attack
[2] http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-codes-3
Packet Capture Options
As a quick follow-up to Didier's post, I wanted to quickly summarize some of the other tools (aside from tcpdump) that can be used to collect full packet captures. I limited myself to open source tools that are meant to run unattended (no GUI) on a remote system and use libpcap. By using libpcap, all these tools are able to use BPF to limit the collected data and they all produce pcap output.
To make it a bit easier to compare, I added an example command line for each tool that will listen on the eth0 interface and rotate logs once an hour. I am also excluding ssh traffic to show how BPF syntax can be used to limit capture.
daemonlogger: This comes out of the snort project. One nice option is the -M option that will allow you to log packets and automatically delete old logs if the disk fills up. For example, -M 90 makes sure the disk usage never exceeds 90%. My favorite utility just for that option alone. A typical command line:
daemonlogger -d -n packetfiles -g pcapgrp -u pcapuser -t 3600 -i eth0 not port 22
snort: Snort itself can be used to log packets to a directory. Snort automatically appends a time stamp to the log file, avoiding overwriting existing files. But snort doesn't have a "rotate" option, so you need to send a signal to snort ot reload.
snort -l /var/log -i eth0 -b -D not port 22
dumpcap: dumpcap comes as part of Wireshark. It can capture packets in monitor mode on wireless interfaces. It has a ringbuffer mode that keeps the last x files. So you have to make sure they don't exceed the available space (not as nice as -M in daemonlogger). It can log in pcapng format and if you do so, you can add a comment to the file. A timestamp is inserted into the filename.
dumpcap -i eth0 -a files:24 -a duration:3600 -P -w packets.pcap
pcapdump: Very simple/basic utility but has the unique feature to be able to sample packets (even randomly). It can also limit packet captures to link/network and transport layer header and strip off all application data (-H option)
pcapdump -i eth0 -w pcapfile.pcap -u pcapuser -g pcapgrp -r 3600
netsniff-ng: one of the less well known tools, and one I haven't played with yet. It claims to be optimized for performance by taking advantage of newer linux kernels. It does not use libpacp, so not strictly speaking "in scope" for this list. It also comes with a packet generator.
tshark: I just include it here for "completeness". I don't consider it a capture utility. Wireshark provides dumpcap for that.
Any other options I forgot about? (open source, non-GUI, libpcap compatible...)
Links to tools:
Daemonlogger: https://snort.org/downloads#additional_downloads
Snort: https://snort.org
Dumpcap: http://www.wireshark.org
pcapdump: https://launchpad.net/ubuntu/precise/+package/pcaputils
netsniff-ng: http://netsniff-ng.org
Comments