Network monitoring best practice includes watching the latest trends not only in your own network, but also in other networks across the Internet. Fortunately, there are some great companies out there tracking what’s happening and issuing periodic reports to keep the rest of us up to speed.
I was very interested to read the recent report from Arbor Networks with the Q2 DDoS (distributed denial of service) attack data collated through their ATLAS Internet monitoring system. The report highlights a 43% increase in attacks from the same period in 2012.
While there’s interesting information in the blog post, there’s a lot more in the SlideShare presentation for the report. Here are some of the highlights that didn’t make it into the summary. As a trend, PPS (packets per second) is down, but BPS (bits per second) is up, implying larger packets used in the DDoS attacks. I wonder if the botmasters behind the DDoS engines are trying to increase impact with larger payloads, and/or trying to reduce the resource requirements on the bots sending out the traffic. Additionally, the duration of most DDoS attacks is getting shorter: the mean is under 3 hours, but 86% of attacks last less than an hour, implying a very long duration in the long tail. The conclusion there seems to be that, if you find yourself the target of a DDoS, it’s likely to stop in under an hour, but if it doesn’t, it’s not going to stop any time soon.
What really caught my eye was a significant increase in a particular vector of attacks. While Port 80 continues to be a very common target, there has been a significant rise in the number of attacks listed as Port 0. Last year, these equated to 10% of all attacks, but now it’s up to almost 25%.
The problem with anything listing Port 0 is that it usually doesn’t mean Port 0. For legitimate traffic, it’s a shorthand way of referring to packets without a L4 header like TCP (transmission control protocol) or UDP (user datagram protocol). The most common example of this traffic is ICMP (Internet control message protocol), and a lot of network monitoring applications will still show “port 0” for ICMP. Port 0 will also show up if there’s fragmented IP traffic, like a DNS response which exceeds the historic maximum size of 512 bytes.
This special meaning of Port 0 makes it deviously effective for DDoS bandwidth exhaustion attacks. If the victim tries to block Port 0, the network forwarding equipment may reject the ACL or policy as referencing a non-legitimate port, making it impossible to block. Even if the equipment does allow the ACL to be created, it might start blocking the aforementioned legitimate traffic – ICMP and fragmented IP – which would result in unexpected network behaviour that would only be discovered later, and be difficult to troubleshoot.
A solution we’ve found at Endace is to double-check what the forwarding and monitoring infrastructure mean when they refer to Port 0, by capturing, classifying, and visualizing the traffic. With its 100% packet capture capability, an EndaceProbe Network Recorder would be able to capture such traffic, and provide packet-level proof of what’s actually happening.
On our in-house EndaceProbe, I thought I’d configure a basic filter TCP-0 and add that to a data pipe. Given that DDoS traffic amounts are increasing, I’m not necessarily interested in wasting disk space on storing the traffic I capture, so I’m initially only interested in generating metadata. Therefore, the target for my Rotation File would have a size of 0B, but would be Vision-enabled to perform DPI traffic classification.
I won’t see packets on this data pipe unless traffic uses TCP Port 0. Remember that there is no legitimate Internet traffic which actually lists Port 0 in its TCP or UDP header, so this is a failsafe method to verify the information I’m receiving from my other network monitoring equipment. In case I do receive that traffic, I created an EndaceVision alarm to alert if attack traffic appears. Receiving any of these deliberately malformed packets is evidence of an attack, so I want to know right away if they actually arrive, since I don’t yet know if I can trust the alarms on my other systems. Once I get that traffic, I can also pivot between EndaceVision views to analyze the attack volume and source and target IP addresses. At any later point, if I want to do a deeper analysis of the packets, I can edit my Rotation File to allocate disc space to store full packets, which I can decode in Endace Packets or export to other tools like Wireshark.
What I love about my EndaceProbe is that it gives me information I can trust about my network. Packets don’t lie, and EndaceVision and Endace Packets let me learn what’s really going on when my other systems don’t give me the evidence to back up their analysis.
For more information about Port O, check out our blog at LoveMyTool.com.