Arbor Networks: Security to the Core

As a result of yet another query regarding the Symantec Internet Security Threat Report XI and subsequent comment, particularly here, I finally got around to reading some of the actual report. While the report is chock-full of interesting facts and figures, and lots & lots of graphs and charts, my chief curiosity was in all the coverage surrounding Symantec’s comments regarding a decrease in DDoS attacks and an inference that the reason is that extortion is no longer profitable.

The report itself claims:

Symantec recorded an average of 5,213 denial of service (DoS) attacks per day, down from 6,110 in the first half of the year.

It is interesting that the report for the first half of the year indicated that the methodology for denial of service reporting had been changed and correlation to earlier versions of the report was not plausible. This and the previous version talked about the uptick in criminal extortion-driven denial of service attacks and then they essentially rebuke it in the current version of the report, only 12 months later[?]; arguably because of a seemingly unanalyzed 14.7% decrease in a single type of attack activity?

Later in the report, Appendix B “Denial of service attacks” provides the following explanation on how the DoS attack activity is monitored:

Although there are numerous methods for carrying out denial of service (DoS) attacks, Symantec derives this metric by measuring DoS attacks that are carried out by flooding a target with SYN requests. These are often referred to as SYN flood atacks. This type of attack works by overwhelming a target with SYN requests and not completing the initial request, which thus prevents other valid requests from being processed.

In many cases SYN requests with forged IP addresses are sent to a target, allowing a single attacking computer to initiate multiple connections, resulting in unsolicited traffic, known as backscatter, being sent to other computers on the Internet. This backscatter is used to derive the number of DoS attacks observed throughout the reporting period. Although the values Symantec derives from this metric will not identify all DoS attacks carried out, it will highlight DoS attack trends.

So basically, what Symantec observed was an average daily decrease of ~14.7% in unsolicited TCP SYN/ACK packets (presumed to be backscatter) across the six month measurement period the report covers. I couldn’t find any information further explaining the associated collection or analysis methodology for denial of service attacks, so I’m unsure if just one TCP SYN/ACK backscatter packet, or some amount one or more orders of magnitude are required to classify an event as a denial of service attack. It was also unclear to me if these backscatter packet statistics were collected from end hosts, perimeter devices, or discrete darknet monitoring systems.

With this, Yazan Gable shared the following comments on Symantec’s Security Response Weblog, apparently inciting all the fuss:

Although there are likely a number of factors at play here, I think there is one primary factor: denial of service extortion attacks are no longer profitable.

With seemingly little more to go on here than a 14.7% decrease in receipt of TCP SYN/ACK backscatter packets that’s quite a leap, methinks. In fairness, Yazan does go on to say that “DoS attacks are loud and risky”, and that by launching DoS attacks botherders “run the risk of losing some of their bots”. Furthermore, he suggests that botherders are moving towards more lucrative ventures like spam. Really?

Now, while I don’t believe anyone would disagree with the notion that bots are being employed more frequently for more economically motivated activities, Yazan glossed over a whole slew of details that would perhaps only confound his statements.

For starters, the denial of service attacks he’s reporting on apparently require that source address spoofing is employed AND that his sensors reside within ranges of address space that the attacker is inserting as spoofed source addresses, AND that the provider of those attacking sources doesn’t employ any type of source address validation on ingress (e.g., BCP 38). If this is the manner for which they’ve been collecting data all along, then a marked decrease is perhaps indicative of something, though I’m not sure just what without many, many more details. However, wider deployment of BCP 38 and anti-spoofing source address validation techniques by service providers, as well as any change in attack vectors driven by mitigation solutions, could have a considerable impact on such a single-threaded analysis model. In addition, as deployment continues the gating that Windows XP SP2 put in place to stop TCP access to raw sockets is likely now having some effect as well, as many traditional DDoS tool kits won’t work and TCP SYN-based attacks now require source host connection state, state which is rate-limited.

Next, they appear to only be counting TCP SYN/ACK backscatter packets, which would mean that not only does the source address space of their sensors need to be employed as the spoofed source for a given attack, and the ISP of the attack source(s) NOT be employing source address validation, but the attack must also employ TCP as the Transport Layer protocol and a SYN-based attack vector that elicits SYN/ACK responses from the victim. There are a whole slew of attacks that don’t employ this attack vector, not to mention that TCP SYN floods are rather straight-forward to mitigate with SYN proxy and similar techniques widely available today, and you can bet that the type of folks that seem to attract extortionists are quite keen on this. Furthermore, attackers are also quite aware of the fact that if they’re going to attack someone, with TCP SYN floods or other, spoofing packets may very will result in immediate drops on ingress, and as likely, prompt detection of the attack source per BCP 38 violation logging. E.g., some would argue spoofing is a bit out of vogue these days.

As a matter of fact, most folks that extort today seem to either aim at completely filling links and overwhelming network capacity of their targets or their target’s upstream providers, or employ Application Layer attacks that require that the source address NOT be spoofed. The interesting outcome of this is that to fill links TCP SYN packets are largely inefficient (because they’re _usually very small) and so either ICMP or UDP floods with larger packet sizes are employed. The result here is that the current analysis model employed by Symantec would see neither of these attacks types. Some of the largest attacks we’ve seen thus far, in the +20 Gbps range, actually employ DNS reflective amplification attacks, where the backscatter itself is much larger than the queries and becomes the actual attack vector.

In another statement they claim that DoS attacks are “loud and noisy” and therefore draw more attention then functions such as spam relay, resulting in the loss of their bots and potentially compromise of the command and control infrastructure. My counter here would be that DoS attack sources are rarely blacklisted in any manner akin to those offered by the zillion different spam blacklisting solutions available today, in particular because TCP SYN flood DoS sources CAN be spoofed and attacks are usually quite temporal in nature. Most mitigation is still typically destination-based and if any kind of source-based filtering is performed for DoS mitigation, it’s most always in an extremely fragmented manner across various networks, quite topological in nature, usually only at the target network and perhaps some of the adjacent upstreams, and quite temporal (i.e., when the attack ends the mitigation is usually removed from the target networks filters).

The major reason for this is that most ISPs don’t have time to chase down compromised hosts not directly on their own or their customer networks, ensure spoofing wasn’t employed, and see that the host gets sanitized. With SMTP-based spam relay hosts must disclose their actual source address, and therefore probability of false listings is much lower.

With all that said, DDoS attacks do appear to be one of the less desirable employment functions for bots, though I’m not sure if it’s in the manner which the Symantec report or subsequent comments alludes, or if there is actually any marked decrease in extortion-related activity. Today spam seemingly isn’t as painful to the network service providers as DoS attacks are, and arguably, DoS attacks will more frequently make folks seek out C&C or see that bots are quarantined and/until sanitized. Even this doesn’t mean the C&C is any more difficult to track, however.

The folks that herd the bots used for DDoS extortion often get an allowance of sorts, usually considerable, and only attack upon request. Picking the right targets at the right time is critical (e.g., online bookies before a Superbowl or World Cup, each event triggering $2B+ US in associated gambling transactions), and the miscreants are well-versed in the mechanics of this. Only attack those that are willing to pay, as far as extortion alone is concerned.

Another interesting bit along this vein is the current trend of bot herders to partition bots based on connectedness. That is, once a host is compromised perform some speed tests to n number of sites, index the hosts based on how well connected they are, and then pool the groups of bots based on that. For example, you could see the top 5% reserved for DDoS attacks, the next 80% for spam, open proxies, phishing and drop sites, and then the worst connected used for stepping stones or even C&C.

If a miscreant makes even one dollar from something that didn’t cost him a dime (our resources), isn’t that still profit? Perhaps a better spin would have been something akin to “Miscreants seek more ways to leverage bot resources for higher-margin services” :-)

This entry was posted on Friday, May 25th, 2007 at 8:30 pm and is filed under Arbor Networks, Botnets, Critical Infrastructure, Interesting Research. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.