Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

DDoS: modern tricks, DNS amplification, counter-strategies

Freewheeling spot to chew the fat on anything cryptostorm-related that doesn't fit elsewhere (i.e. support, howto, &c.). Criticism & praise & brainstorming & requests for explanation... this is where it goes when it's hot & ready for action! :-)
User avatar

Topic Author
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am

DDoS: modern tricks, DNS amplification, counter-strategies

Postby Pattern_Juggled » Sat Mar 30, 2013 12:03 pm

How Spamhaus’ attackers turned DNS into a weapon of mass destruction
DNS amplification can clog the Internet's core—and there's no fix in sight.
by Sean Gallagher | Mar 28 2013, 12:30pm PDT

A little more than a year ago, details emerged about an effort by some members of the hacktivist group Anonymous to build a new weapon to replace their aging denial-of-service arsenal. The new weapon would use the Internet's Domain Name Service as a force-multiplier to bring the servers of those who offended the group to their metaphorical knees. Around the same time, an alleged plan for an Anonymous operation, "Operation Global Blackout" (later dismissed by some security experts and Anonymous members as a "massive troll"), sought to use the DNS service against the very core of the Internet itself in protest against the Stop Online Piracy Act.

This week, an attack using the technique proposed for use in that attack tool and operation—both of which failed to materialize—was at the heart of an ongoing denial-of-service assault on Spamhaus, the anti-spam clearing house organization. And while it hasn't brought the Internet itself down, it has caused major slowdowns in the Internet's core networks.

DNS Amplification (or DNS Reflection) remains possible after years of security expert warnings. Its power is a testament to how hard it is to get organizations to make simple changes that would prevent even recognized threats. Some network providers have made tweaks that prevent botnets or "volunteer" systems within their networks to stage such attacks. But thanks to public cloud services, "bulletproof" hosting services, and other services that allow attackers to spawn and then reap hundreds of attacking systems, DNS amplification attacks can still be launched at the whim of a deep-pocketed attacker—like, for example, the cyber-criminals running the spam networks that Spamhaus tries to shut down.

Hello, operator?

The Domain Name Service is the Internet's directory assistance line. It allows computers to get the numerical Internet Protocol (IP) address for a remote server or other network-attached device based on its human-readable host and domain name. DNS is organized in a hierarchy; each top-level domain name (such as .com, .edu, .gov, .net, and so on) has a "root" DNS server keeping a list of each of the "authoritative" DNS servers for each domain registered with them. If you've ever bought a domain through a domain registrar, you've created (either directly or indirectly) an authoritative DNS address for that domain by selecting the primary and secondary DNS servers that go with it.

When you type "arstechnica.com" into your browser's address bar and hit the return key, your browser checks with a DNS resolver—your personal Internet 411 service— to determine where to send the Web request. For some requests, the resolver may be on your PC. (For example, this happens if you've requested a host name that's in a local "hosts" table for servers within your network, or one that's stored in your computer's local cache of DNS addresses you've already looked up.) But if it's the first time you've tried to connect to a computer by its host and domain name, the resolver for the request is probably running on the DNS server configured for your network—within your corporate network, at an Internet provider, or through a public DNS service such as Google's Public DNS.

There are two ways for a resolver to get the authoritative IP address for a domain name that isn't in its cache: an iterative request and a recursive request. In an iterative request, the resolver pings the top-level domain's DNS servers for the authoritative DNS for the destination domain, then it sends a DNS request for the full hostname to that authoritative server. If the computer that the request is seeking is in a subdomain or "zone" within a larger domain—such as http://www.subdomain.domain.com—it may tell the resolver to go ask that zone's DNS server. The resolver "iterates" the request down through the hierarchy of DNS servers until it gets an answer.

But on some networks, the DNS resolver closest to the requesting application doesn't handle all that work. Instead, it sends a "recursive" request to the next DNS server up and lets that server handle all of the walking through the DNS hierarchy for it. Once all the data is collected from the root, domain, and subdomain DNS servers for the requested address, the resolver then pumps the answer back to its client.

How DNS queries are supposed to work—when they're not being used as weapons.

To save time, DNS requests don't use the "three-way handshake" of the Transmission Control Protocol (TCP) to make all these queries. Instead, DNS typically uses the User Datagram Protocol (UDP)—a "connectionless" protocol that lets the server fire and forget requests.
Pump up the volume

That makes the sending of requests and responses quicker—but it also opens up a door to abuse of DNS that DNS amplification uses to wreak havoc on a target. All the attacker has to do is find a DNS server open to requests from any client and send it requests forged as being from the target of the attack. And there are millions of them.

The "amplification" in DNS amplification attacks comes from the size of those responses. While a DNS lookup request itself is fairly small, the resulting response of a recursive DNS lookup can be much larger. A relatively small number of attacking systems sending a trickle of forged UDP packets to open DNS servers can result in a firehose of data being blasted at the attackers' victim.

DNS amplification attacks wouldn't be nearly as amplified if it weren't for the "open" DNS servers they use to fuel the attacks. These servers have been configured (or misconfigured) to answer queries from addresses outside of their network. The volume of traffic that can be generated by such open DNS servers is huge. Last year, Ars reported on a paper presented by Randal Vaughan of Baylor University and Israeli security consultant Gadi Evron at the 2006 DefCon security conference. The authors documented a series of DNS amplification attacks in late 2005 and early 2006 that generated massive traffic loads for the routers of their victims. In one case, the traffic was "as high as 10Gbps and used as many as 140,000 exploited name servers," Vaughan and Evron reported. "A DNS query consisting of a 60 byte request can be answered with responses of over 4000 bytes, amplifying the response packet by a factor of 60."

But even if you can't find an open DNS server to blast recursive responses from, you can still depend on the heart of the Internet for a respectable hail of packet projectiles. A "root hint" request—sending a request for name servers for the "." domain—results in a response 20 times larger than the packet the request came in. That's in part thanks to DNS-SEC, the standard adopted to make it harder to spoof DNS responses, since now the response includes certificate data from the responding server.

A comparison of a "root hint" query and the response delivered by the DNS server. Not all data shown. | Sean Gallagher

In the case of the attack on Spamhaus, the organization was able to turn to the content delivery network CloudFlare for help. CloudFlare hid Spamhaus behind its CDN, which uses the Anycast feature of the Border Gateway Protocol to cause packets destined for the antispam provider's site to be routed to the closest CloudFlare point of presence. This spread out the volume of the attack. And CloudFlare was able to then shut off amplified attacks aimed at Spamhaus with routing filters that blocked aggregated DNS responses matching the pattern of the attack.

But that traffic still had to get to Cloudflare before it could be blocked. And that resulted in a traffic jam in the core of the Internet, slowing connections for the Internet as a whole.

No fix on the horizon

The simplest way to prevent DNS amplification and reflection attacks would be to prevent forged DNS requests from being sent along in the first place. But that "simple" fix isn't exactly easy—or at least easy to get everyone who needs to participate to do.

There's been a proposal on the books to fix the problem for nearly 13 years—the Internet Engineering Task Force's BCP 38, an approach to "ingress filtering" of packets. First pitched in 2000 1998 as part of RFC 2267 , the proposal has gone nowhere. And while the problem would be greatly reduced if zone and domain DNS servers simply were configured not to return recursive or even "root hint" responses received from outside their own networks, that would require action by the owners of the network. It's an action that doesn't have a direct monetary or security benefit to them associated with it.

ISPs generally do "egress filtering"—they check outbound traffic to make sure it's coming from IP addresses within their network. This prevents them from filling up their peering connections with bad traffic. But "ingress" filtering would check to make sure that requests coming in through a router were coming from the proper direction based on their advertised IP source.

Another possible solution that would eliminate the problem entirely is to make DNS use TCP for everything—reducing the risk of forged packets. DNS already uses TCP for tasks like zone transfers. But that would require a change to DNS itself, so it's unlikely that would ever happen, considering that you can't even convince people to properly configure their DNS servers to begin with.

Maybe the attack on Spamhaus will change that, and core network providers will move to do more to filter DNS traffic that doesn't seem to match up with known DNS servers. Maybe just maybe, BCP 38 will get some traction. And maybe pigs will fly.

Source: ArsTechnica
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar

Topic Author
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am

summary: how to protect against DNS-based DDoS

Postby Pattern_Juggled » Thu Apr 25, 2013 4:02 pm

The above is a typically well-written, technically accurate summation from Ars Technica.

However, we were recently asked (ok, actually, I was asked - but "we" does sound so much more substantial :roll:) an interesting question: how does one protect against such attacks, if one is on the receiving end of them?

Well, nowadays it seems the knee-jerk answer is - not to put too fine a point on it - "sign up with Cloudflare." I have my own somewhat curmudgeonly issues with the Cloudflare model (summary: since Cloudflare controls Cloudflare's fine-grained decisions on packet blocking heuristics, an inherent loss of control comes into the picture - which can be maddening for control-oriented and/or old school sysadmins), let's for argument's sake consider an astonishing scenario: what if there were no magical Cloudflare wand to wave at DDoS attacks? (note: of course, there's a bunch more anti-DDoS companies than Cloudflare)

That's a worthwhile consideration even if one really does simply plan to pick up the phone and buy Cloudflare service. Having at least a baseline understanding of what's going on inside the black box helps those responsible for making such decisions to do so with a much more confident foundation. Plus, yeah, it's sort of cool to work through the mechanics of this stuff purely as a learning exercise.

Standard caveat: I am not an expert on DDoS, anti-DDoS, or anything related to the black magicks commonly known as the Domain Name System. There are folks out there, some of who may well read this, who have forgotten more about the subject than I'll ever learn. Proper respect to those kung-fu masters. In contrast, if I bring anything to this essay it is a broad background in network security management, design, and operations - as well as a nontrivial dose of academic economics (which it turns out is useful in this kind of analytic exercise). I know a little bit about quite a few things (and quite a bit about a couple of specific subject areas, none of which - alas - really have much to do with DDoS in any tangible sense), and that dilettante's broad scope might provide, if nothing else, a different take on this question. Also, I do my best to use technical vocabulary correctly; if I err (and likely I do), by all means please correct me - I'm shooting for narrative cohesion here, not technical perfection, but I still prefer not to mangle terms of art if possible. Thanks! 8-)

Let us begin with the fundamentals: a DDoS attack seeks to overload a public-facing resource by presenting it with a surfeit of input sufficient to prevent it from successfully dealing with "legitimate" queries from regular users of the service in question. In theoretical terms, "DDoS" is not limited to websites, or even TCP-based resources - one could imagine just about any network-connected service being DDoS'd. However, in practical terms we pretty much use the term to refer to taking a website (http) offline.

Building from a simple case, imagine (and this is imaginary - I'm not sure if there's clever emulators and whatnot to make this happen on a poor old C64, but we'll just do a bit of hand-waving and make it so, for now) a Commodore 64 with a 300 baud analog modem connecting it to TCP-based network capability. This C64 is running some sort of basic webserver, and has a little web page it serves when packets engage in suitable protocol niceties via port 80 to convince this gutsy little server to respond back with packets representing the website. Someone visits the website, the C64 chugs away, and it loyally sends back packets that represent the website. Yay!

All one would need to do in order to functionally DDoS this little C64 is hit the refresh button on one's web browser repeatedly: click, click, click. Because the "server" is so desperately constrained - in CPU, in network bandwidth, in onboard interconnet... you name it - having even one visitor keep asking over and over for the page to be served is going to be enough to prevent another visitor from getting any reply at all. If the server can serve one visitor at a time, then having one visitor hog the connection will result in any and all other visitors being 'denied access' to the website. That's a simple DDoS "attack" based on nothing more than the refresh button.

The arms race proceeds as expected from there.

Throw capacity at the server - more CPU, more onboard RAM (which becomes crucial in managing sockets and thus handling TCP sessions, bigger pipe coming in, better/faster network interface card (NIC) or even multiple parallelized NICs - and an attacker needs to point more packets at the entire architecture in order to distract it sufficient to prevent legitimate visitors from accessing the resource.

S0 the whole point of a DDoS is to knock a site "offline" not by actually rooting the box and trashing anything on the hard drives, but by making it so damned busy dealing with crap packets that it just can't handle legitimate ones (in fact, some forms of DDoS can actually cause various flavours of kernel panic and or forkbomb-like recursive meltdowns that will crash the entire OS... but that's neither necessary nor terribly common in practice).

As the cat and mouse game proceeds apace - attackers throw more junk packets at websites, websites increase in their overall capacity for handing packets, junk and non-junk alike - things start to get more specialized. Instead of manually hitting the refresh button, write a little BASIC program to do it automatically. Then have your buddies also have that BASIC program running, so together you can sort of gang up on a website and throw more bad packets at it in one go (see also: LOIC, which was in fact backdoored by LEO from the get-go, and thus was essentially an application honeypot - a fascinating category of #snitchware, but I digress...). At this point, there's no force multipliers in the game: I generate packets, and the server has to handle them. We're sort of all on a level playing field, in a sense.

This is where economics comes in.

If it costs about as much - per packet - for me to generate bunk packets as it does for the server to deal with them, we're in a situation where the party with the most economic resources wins. If I can buy 100 Apple II+ machines with 1200 baud Hayes modems and run them all at once, but my target can only afford that one little C64, then as an attacker I win: he's going to go offline (unless he does some amazingly clever, and efficient, algorithmic implementations of packet heuristics; see below). Conversely, if the website operator can splurge for a whole basement full of Apple IIc's and 9600 baud modems, then my little ragged band of II+ attackers is never going to win the day. Deeper pockets win (mostly).

The same dynamic is more or less in play even as we get to more complex, more far-flung network topologies: the attacker is utilizing a screensaver-like voluntary application that takes unused network capacity for a bunch of folks and puts it to use in a parallelized attack stream (again: LOIC), and the website admins scale up by using a bunch of raw server capacity that's buffered by some sort of load balancing/middleware layer. Still, in the end, it's who has the most resources (read: money) that wins out over the long term.

Right. So now if I can sneak into the Computer Science department at my local Uni and commandeer their mainframe to generate bunk packets, suddenly the terrain shifts. My "cost" to generate packets drops several orders of magnitude (still taking into account the probability-driven cost of getting caught breaking in, valued in some quantitative metric), whilst my target still has to have enough horsepower to handle the packets. I might be able to crush her this way, because I'm not paying out of pocket and she's forced to keep buying more machines, more phone lines, more modems.

That's "cheating," in a sense - but of course it's also how DDoS attacks have progressed in the last 5 years or so. Botnets of commandeered PCs are "herded" into cohesive attack entities, and throw bunk packets at targeted websites - nobody's paying out of pocket to generate those packets; they're essentially "stolen" from the owners of the zombie PCs (not to argue about the semantics of theft, etc., for now). On the website manager side, there's really no concomitant version of "stealing resources" to defend against an attack: one must lease more servers, buy more network capacity, whatever. So it's asymmetric warfare.

Therefore, the attackers always win, right? I mean, if their cost-per-packet is asymptotically dropping to zero, and the website admins have to pay to scale, then get swamped by the economics. Well, not exactly...

- - -

Let's say we're lazy, as attackers, and all of our bunk packets have some sort of easily-observed identifying characteristics. Say, for example, they are all SYN/ACK packets and they are all coming from one source IP address (not likely, I know, but this is essentially a Gedankenexperiment). Our website admin notices this and she thinks "hmm, well how about I put a gateway device between myself and the public internet, and all that device will do (a specialized router, basically) is look at each packet, see if it matches the 'fingerprint' of the attack packets, and toss out the bunk packets before they ever even get to my server itself, so I don't have to buy tons of server capacity just to throw out bunk packets?" She's smart, so she codes a nice little algorithm to run on her gateway router, and it throws out (nullroutes) the bunk packets - because it's a specialized algorithm running on specialized hardware that does nothing else but look at packets and make decisions about fingerprints, it can do so very cheaply on a per-packet basis. (in fact, there's commercial "network appliances" that are able to do this kind of packet inspection on massive volumes of network traffic for relatively tiny cost-per packet.)

"Well shit," thinks our attacker, "she's sort of outsmarted me. My packets aren't even getting to her server, so I'm not bogging it down at all... and that cheapo router she's got her packet fingerprinting algorithm on is just too damned efficient for me to overload in a cost-effective manner!" He sits and ruminates, chewing his cognitive cud. "Aha," he does the Eureka thing absent the requisite overflowing bathtub, "all I need to do is ensure that the bunk packets I'm sending are sufficiently diverse and/or sufficiently indistinguishable from legitimate packets that she can't use that cheap little router to make snap judgments about packets, and she'll have to let them all through to the server or risk shutting out lots of legitimate visitors." He rubs his hands in that evil-genius way we all know so well.

Because, in addition to the economic factors that come into DDoS conflict scenarios, there's also the false positive issue. Simply put, if I'm website admin and my packet fingerprinting algorithm - the one that tries to preemptively 'filter out' bunk packets before they gum up my actual webserver - is overly aggressive, it's going to filter out legitimate packets as well. Ouch. Basically, I"m self-DDoSing at that point: blocking my own legitimate visitors from accessing my website. So my tolerance for false positives is pretty low, usually: if I'm cutting off 5% of my legitimate visitors, that likely way, way too high. It's going to want to be done in the rounding-error range... or, ideally, zero.

(If this is starting to sound to you like a scenario that could be quite effectively modeled by classican von Neumann / Nash game theoretic frameworks, good on 'ya - gold star! This is very much congruent with game theoretic analysis, and if enough bells and whistles are added there's no doubt just about any DDoS conflict could be turned into a very accurate qualitative game theory model by a doctoral candidate looking for a cool thesis subject... but I digress, as usual.)

- - -

Where are we at now? Well, we've got an attacker who wants to generate hard-to-fingerprint, cheap bunk packets that look really similar to legitimate packets and we've got a website admin who wants to find clever algorithms to filter out bunk packets cheaply, with false positive rates very close to zero. That's the conflict landscape, in a nutshell, and various flavours of DDoS come at the challenge using different technological approaches. Conversely, website admins have a suite of different kinds of fingerprinting techniques, gateway/buffering techniques, and load-balancing/parallelizing of resource techniques which together seek to nullroute those bunk packets cheaply and without taking legitimate traffic with them.

It's also worth thinking about what the actual objectives are of a DDoS attack - they can vary quite a bit, which ends up being really important in defining appropriate defense methodologies. If I want to "DDoS" my buddy's blog that he hosts on an Apache instance he's jammed into the funky *nix environment that's built into his fancy new "internet of things" refrigerator, I might just want to make the blog not respond for 10 minutes so I can text him with the message: 'OMFG YOUR REFIGERATOR HAS BIT THE DUST AND YOUR BLOG IS GONE GONE GONE!!!!! ;-) lol"" ...whereas, if your'e a serious player and you want to extort a target website with the threat that "we will take your business website offline for a month continuously, no matter how much extra capacity you buy, unless you send us 500 bitcoins by 5pm GMT tomorrow" then you need to be able to sustain a DDoS for a long period of time.

Somewhere in the middle are the DDoS scenarios that involve, essentially, a political statement. Taking {insert government website name here} offline for an hour, and powering up a big twitter frenzy of attention during that hour, might just be the bee's knees if you're seeking to draw widespread attention to {insert political grievance here}. In that case, you can likely rely on something relatively unsophisticated and brute-force-y to get the job done. By the time your target figures out what you're doing, fingerprints your packet patterns, and updates their gateway/firewall/network appliance/whatever with the info, you've already got exactly what you wanted out of the attack.

- - -

What are the specific characteristics of "DNS amplification" DDoS attacks, within this larger framework we've outlined above? There's a few:

    1. There's a leverage inherent in the technical model being deployed, which means that the per-packet (or per-bit, or whatever) cost to generate bunk traffic is amazingly low. The Ars article above goes into detail; short version is that it cleverly uses a quirk of the DNS protocol itself to get entirely independent servers to "amplify" a single, small packet into a big mass of stuff that's targeted at the website being attacked (this crucially relies in the ability to viably spoof "source IP" in the packet header of UDP packets... which is sort of a big deal in many levels). It's essentially similar to an amplifier: a little bit of signal (bunk data) goes in, and big wave of noise (mass bunk data) comes out. This is, again, rather a clever way to make the DNS protocol do something it wasn't ever intended to do, but will do because it's an unintended consequence of some design decisions made, innocently, quite a while back.

    2. As I read it, the packets being generated by DNS amplification attacks are not actually asking for any kind of response from the targeted webserver. This is different from many DDoS methodologies, which make httpd (or whatever non-Apache web service) actually process the bunk packets and do something about them: classically, this could be accomplished by asking the website to serve pages, just as it normally would (as in our C64 example, above) or (as in a SYN/ACK DDoS) make the OS at least initiate all the bells and whistles of a TCP session or ping response. Again as I understand it, DNS amplification isn't asking the targeted website to do anything at all - it's just throwing huge volumes of nonsense at it. Actually, to be more precise, it's tricking other machines on the internet into "providing answers" - verbose answers - to "questions" about DNS tables that were asked by the target website's server... even though the poor server never actually asked those questions of anyone (that's where the "source IP" spoofing that can be done in UDP - as opposed to TCP - comes into play: the spoofed "please send your answer to my query back to me here" IP address is the target website's machine). The target site is flooded in a bunch of voluminous answers to questions it never asked, the poor dear. And it crumples under the sheer volume of this nonsense flood.

Given that, let's think about the kind of packet fingerprinting heuristics we might put into place to deal, specifically, with a DNS amplification DDoS attack:

    - all the traffic coming in from a DNS amplification attack is going to be in the form of answers to unasked DNS resolution questions - thus, our fingerprinting heuristic is going to be turning a skeptical eye to just that sort of traffic; in contrast, packets coming in that are just plain-vanilla "here's my request for a file resource as defined in http and can you send it to me here at this IP address" sorts of things are absolutely not going to need to be closely filtered - they're ok, and we know they're ok just by knowing they're not responses to any kind of DNS query whatsoever.

    - the specific kinds of "answers to unasked questions" that are generated in DNS amplification attacks seem to me, as a nonspecialist and essentially n00bish dilettante, to be of a certain sort: wordy, detailed, heavy. So I might just take any responses to DNS queries and run them through some sort of hyper-specialized process before they ever get onto the local network, and ask them essentially "are you a reply to a question I even remember answering? - if they aren't, toss 'em right then and there.

    - honestly, if you do end up false-positiving some of these verbose DNS resolution query answers because you're nullrouting a big whack of bunk traffic of exactly that sort, it's unlikely anyone is going to do: your website will still work, visitors will still be able to access it. I've no doubt that card-carrying, wizard-hatted DNS black magicians could do clever stuff to offload basically all DNS-related processes to a dedicated resource on the local network - or not even on the local network (something like OpenDNS)... thus freeing the actual web servers to junk any and all packets that are of a DNS-response sort, period.

    - The first go-to way to deal with most DDoS attacks, if possible, is to do old-school source IP filtering at the iptables level: if the packet comes from xxx.xxx.xxx.xxx (where such IPv4 octet is one that's churning out bunk packets but isn't actually a source of any legitimate packets), junk it. Modern firewalls, be they inbuilt in the OS (iptables) or in some external device or process, are very good at tossing blacklisted IP packets with very little use of computational resources. Attackers know this, of course, and try to make sure their source IPs are either as variable as possible, or intermingled sufficiently with legitimate packets that the website can't just toss all packets coming from that IP as they'll lose a whack of legitimate traffic - or both. (aside: I recently blacklisted all registration emails that met the following definition, after a particularly powerful wave of forum spambots came through our neck of the woods: *@*.ru ...and, sad to say, it dropped successful spambot registrations by about 95% - hopefully not blocking too many legitimate Russian forum participants who have legitimate .ru email accounts.)

    - the further up into the guts of the network itself you can get to filter this kind of bunk packet traffic, the better. I expect that Cloudflare, in the case cited by Ars above (Spamhaus) is looking to filter out that packet traffic somewhere out in BGP-land, not even allowing it onto the local network segment, let alone onto actual webservers or even datacentre switches. That's what I'd want to do, anyway, from a topological perspective, to minimize the cost of routing all those bunk packets around inside my local network. But, again, the Cloudflare folks are undoubtedly very smart about this stuff and there may be practical considerations of which I am entirely unaware that militate against this approach. Perhaps some smart young lady on the Cloudflare tech team will come though here and set this stumbling old academic straight as to how it all really works - one can always hope.

    - finally, I've no doubt that there's Bayesian rulesets that could be self-trained to correctly categorize this kind of packet traffic with scary accuracy. Bayesian inference modeling methodologies are really, really good at that kind of challenge - and I'm nowhere near smart enough about Bayesian stuff to explain why. But they work really well, and will likely be useful here right off the bat.

At core, in summary, this is all going to boil down to a 2 by 2 variable conflict matrix: who has more financial resources to throw at the challenge of, respectively, generating bunk packets and processing bunk packets to filter them out of the flow of legitimate packets? - and, who is more clever in, respectively, generating diverse packets and writing efficient algorithms to categorize accurately bunk and legitimate packets with very low false positive rates. The antagonist who has the best mix of variables in that 2-space matrix "wins," ceteris paribus.

(in this theoretical framework, one can think of the role of Cloudflare as - in part - a shared risk entity, otherwise known as insurance: you pay Cloudflare every month so that, if you do come under withering attack one day, you get to access the whole pool of available Cloudflare capacity at no increased cost. In the non-Cloudflare world, your colo might otherwise call up and say "hey, you're website is eating 5 gigabytes of inbound network capacity right now - send us $4,000 in bitcoins, right now, or we're nullrouting all traffic trying to get your server" - which is not a call anyone really wants to get, trust me.)

- - -

So how does this translate down to an actual website operator who is actually worried about preparing for a possible DNS amplification DDoS attack against their actual server? Most of us aren't Spamhaus, and we don't have Cloudflare's CTO programmed into our phone's address book, ready to call at a moment's notice. Particularly for activists working on non-commercial projects, the budget for dealing with this crap is basically zero: one either finds clever ways to handle it, or one's project gets offlined for the time being.

Simple but obvious: one way to "deal with" a DDoS of any sort is simply to wait it out. If you're a noncommercial project, then you don't have any "lost revenue" calculations to do; your project website is an outreach tool, not a revenue generator. So some nasty troll wants to DDoS you because they hate your political message? Let it be know: "sure, DDoS ahead, we'll just take the time when your packets are jamming us up to do more Twitter work, or redesign our website, or - hell - go out and take a well-deserved hike in the woods." That'll take the wind out of the sails of most any attacker: remember, even with clever attack vectors, the cost of maintaining a DDoS is not zero! If nothing else, there's the opportunity cost to consider: they could be DDoSing some other victim, if they weren't pointing their packets at you. And if you exhibit a genuinely blase attitide - "sure, whatever dude, DDoS away, we'll just go on twitter and talk about the DDoS - which will earn us sympathy and increased visibility the longer it goes on" - you are unlikely to see many attackers that will sustain the effort for very long. They want a panicked reaction; if you don't provide that, it undercuts their reward expectations.

Also, if you think this might come down the pipeline, talk to your colo or VPS provider in advance, to make sure you understand how they'll react! This is super important and super useful, so I"ll add another few exclamation points: !!! From experience, the worst part of dealing with a DDoS is often the panicked overreaction by the colo, not the actual offlining if your site because of bunk traffic. You get a text message that says "shit, we're down"... and, when you research it, you realize that your VPS provider itself has offlined your virtual instance and cancelled your hosting account entirely for 'violating their Terms of Service' or some such bullshit! Which sucks. You're trying to get them on the phone, begging, panicking - did you even back up that VM recently, shit... - and the DDoS has totally offlined you without even needing to melt your server down. Your hosting company saw the spike in inbound traffic, saw it's all headed to your domain name, and - seeing you as merely $25/month in revenue, dumped you like a rotten fish. Shit. Now you're in a panic to find a new host, update DNS records, etc. - and you're down the whole time, with your attacker chucking and toasting their brilliance.

That sucks.

In contrast, if you've talked this out with your hosting company there's no panic. They might still say "hey look, we can't handle this traffic as it'll offline all our customers - you gotta move" - but you've planned ahead so you've got your fallback host all ready to go, and your VM instance is backed-up offsite and ready to swipe over to your new host. No muss, no fuss. Maybe the new host is way more expensive per-month, but they will ride out a DDoS with you. Whatever the circumstances, being prepared in advance - and talking with your hosting company in advance - takes all the panic out of the process.

Finally, if you've got some technical chops, you might be able to peek at those inbound packets when the attack starts, and add a simple iptables rule to nullroute them before they bring mayhem to your server itself. If it's not a massive attack, this is quite possible - and very rewarding, in my experience, on a "job well done" level. Fuck you, troll - you lose. Hoo-ra. That said, if someone points 300 gigabits/second at your poor little VPS, it's going to melt down. As is your hosting company. As is, perhaps, your entire MAE neighborhood... :o

So... there you go. It's fascinating stuff.


...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar

Topic Author
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am

DDoS attacks grow meaner & ever-more powerful (Ars)

Postby Pattern_Juggled » Fri Apr 26, 2013 10:50 pm

{I've highlighted a few particularly interesting passages using an annoying green color, below -Pt_jD}

Fueled by super botnets, DDoS attacks grow meaner and ever-more powerful
Average amount of bandwidth used in DDoS attacks spiked eight-fold last quarter.
by Dan Goodin - Apr 17 2013, 12:00am PDT

Coordinated attacks used to knock websites offline grew meaner and more powerful in the past three months, with an eight-fold increase in the average amount of junk traffic used to take sites down, according to a company that helps customers weather the so-called distributed denial-of-service campaigns.

The average amount of bandwidth used in DDoS attacks mushroomed to an astounding 48.25 gigabits per second in the first quarter, with peaks as high as 130 Gbps, according to Hollywood, Florida-based Prolexic. During the same period last year, bandwidth in the average attack was 6.1 Gbps and in the fourth quarter of last year it was 5.9 Gbps. The average duration of attacks also grew to 34.5 hours, compared with 28.5 hours last year and 32.2 hours during the fourth quarter of 2012. Earlier this month, Prolexic engineers saw an attack that exceeded 160 Gbps, and officials said they wouldn't be surprised if peaks break the 200 Gbps threshold by the end of June.

The spikes are brought on by new attack techniques that Ars first chronicled in October. Rather than using compromised PCs in homes and small offices to flood websites with torrents of traffic, attackers are relying on Web servers, which often have orders of magnitude more bandwidth at their disposal. As Ars reported last week, an ongoing attack on servers running the WordPress blogging application is actively seeking new recruits that can also be harnessed to form never-before-seen botnets to bring still more firepower.

Also fueling the large-scale assaults are well-financed attackers who are increasingly able to coordinate with fellow crime organizations, Prolexic officials wrote in quarterly global DDoS report published Wednesday.

"These types of attack campaigns appear to be here to stay as a staple on the global threatscape," they wrote. "Orchestration of such large attack campaigns can only be achieved by having access to significant resources. These resources include manpower, technical skills and an organized chain of command."

The most prominent targets of DDoS attacks over the past six months have been the nation's largest banks, which at times have become completely unreachable following above average floods of traffic. Most of the assaults were preceded by online posts that showed the writer had foreknowledge of what was about to happen. The posts were penned by self-proclaimed members of Izz ad-Din al-Qassam Brigades, the military wing of the Hamas organization in the Palestinian Territories, and said the attacks were in retaliation for videos posted to YouTube that were insulting to Muslims. The Prolexic report cast doubt on some of that narrative.

Prolexic "believes these attacks go beyond common script kiddies as indicated by the harvesting of hosts, coordination, schedules and specifics of the selected attack targets," the report stated. "These indicators point to motives beyond ideological causes, and the military precision of the attacks hints at the use of global veteran criminals that consist of for-hire digital mercenary groups."

Not the only one

Prolexic is by no means the only DDoS mitigation service that's seeing more powerful attacks. For 45 minutes on Tuesday, San Francisco-based CloudFlare's network was bombarded by data sent by more than 80,000 servers across the Internet that all appeared to be running WordPress. Over the past half-year, CloudFlare has seen a dramatic uptick in attacks that target website applications, such as those that provide encrypted HTTPS sessions. In many cases, those types of attacks are much harder to block.

"Sometimes the nastiest attacks aren't the biggest ones," CloudFlare CEO Matt Prince told Ars. "The nasty attacks that we're seeing right now are the ones that go after the underlying application by doing something like sending a ton of traffic to a log-in page."

Attackers in such cases will unleash scripts that enter a legitimate user name along with passwords that are known to be invalid. When repeated millions of times, the technique overwhelms targeted systems as servers perform database lookups, report the authentication failure, and then record it in internal logs.

In addition to increasingly well-funded and organized attackers and new techniques, the growing firepower of DDoS attacks is also getting a boost from the proliferation of do-it-yourself Web applications such as WordPress and Joomla, Prince said. In that respect these applications, which are designed to help people with only moderate levels of technical expertise deploy websites, could become to this decade what early versions of Microsoft's Windows XP were to the previous decade.

"It is clear that if the story of the 2000s was how easy it was to compromise desktop PCs and turn them into spam-sending engines or botnets to do other nefarious things, the story of the 2010s is going to be how easy it is to compromise server software, which has gotten very consumerized and doesn't necessarily have the best security in place," Prince said. "If a server is 10 times as powerful as a desktop computer then you only need one-tenth to do the same level of damage."
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar

Topic Author
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am

Prolexic Q1 2013 DDoS report

Postby Pattern_Juggled » Fri Apr 26, 2013 11:49 pm

{this information comes from the most recent Prolexic quarterly report, said being attached below in .pdf format; I went ahead and did the basic ctrl-c/ctrl-v although of course most formatting is badly mangled... at least the statistics are easier to grab with search tools, as raw text -Pt_jD}

Prolexic Quarterly Global DDoS Attack Report - Q1 2013

DDoS attackers target ISP and carrier
router infrastructures with
high packet-per-second attacks.
Analysis and Emerging Trends
At a Glance
Compared to Q4 2012
• Average attack bandwidth up 718 percent
from 5.9 Gbps to 48.25 Gbps
• Average attack duration increases 7.14
percent from 32.2 hours to 34.5 hours
• Total number of application attacks fell
3.85 percent
• Total number of infrastructure attacks rose
3.65 percent
• 1.75 percent increase in total number of
DDoS attacks
• China retains #1 position as leading origin
of DDoS attacks
Compared to Q1 2012
• Average attack bandwidth up 691 percent
from 6.1 Gbps to 48.25 Gbps
• 21 percent increase in average attack
duration from 28.5 hours to 34.5 hours
• Total number of application attacks rose 8
• Total number of infrastructure attacks rose
26.75 percent
• 21.75 percent increase in total number of
When we look back at what occurred in Q1 2013, it’s quite
possible that this will be seen as a landmark quarter for
distributed denial of service (DDoS) attacks. Never before have
attacks been this formidable. While the size of this quarter’s
recent Spamhaus.org attack was grossly inflated, Prolexic did
mitigate a 130 Gbps attack in March and more than 10 percent
of attacks directed at Prolexic’s global client base exceeded 60
Gigabits per second (Gbps).
However, volumetric bandwidth, which averaged an attention-
grabbing 48.25 Gbps this quarter, was not the real story.
What defined this quarter was an increase in the targeting of
Internet Service Provider (ISP) and carrier router infrastructures.
In Q1 2013, it was the packet-per-second (pps) rate, which
averaged 32.4 Mpps, which got our attention. Prolexic noted
that these high pps attacks caused significant issues for other
mitigation providers and carriers throughout the quarter.
Most mitigation equipment tends to be limited by pps capacity,
not Gbps. But it’s not just mitigation equipment that struggles
against these high pps attacks. Even routers that carry traffic to
the mitigation gear have trouble with packet rates at this level.
As a result, we are entering a situation where simply moving
such a large amount of attack traffic to a scrubbing center can
be problematic. This has resulted in an increase in the null routing
(black holing) of traffic by carriers and ISPs, which is obviously
not a viable or acceptable long-term strategy for clients.
Because Prolexic operates upstream in the cloud, it typically
intercepts traffic long before it concentrates within carriers and
saturates their networks, making it one of the few companies in
the world that can handle this level of traffic.
This quarter, attackers favored launching infrastructure (Layer 3 and Layer 4) attacks directed against
bandwidth capacity and routing infrastructure over application layer attacks. Infrastructure attacks accounted
for 76.54 percent of total attacks during the quarter with application layer attacks making up the remaining
23.46 percent. SYN, GET, UDP and ICMP floods were the attack types most commonly directed against
Prolexic’s clients. In Q1 2013, average attack duration increased again, rising to 34.50 hours. This continues
a recent trend of longer duration attack campaigns.
Looking at the three-month period overall, Prolexic mitigated more attacks than in any previous quarter,
although increases in the total number of attacks over the previous quarter were inconsequential. March was
the month with the most attacks mitigated, accounting for 44 percent of the quarter’s attacks, and the
period 3/19 – 3/26 was the most active week of the quarter.
Consistent with previous quarters, the list of source countries responsible for the most DDoS attacks was fluid
with the exception of China, which once again remained first. This quarter, China was joined at the top of
the list by the U.S., Germany, and Iran.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Compared to Q4 2012
Despite mitigating the highest volume of attacks to date in Q1 2013, total attacks only increased 1.75 percent
over the previous quarter, reflecting the consistently high level of attack activity in the world over the last
six months. The total number of infrastructure attacks increased 3.64 percent over Q4 2012, while the total
number of application layer attacks declined 3.87 percent. Average attack duration continued to rise, from
32.2 hours to 34.5 hours, an increase of 7.14 percent. As noted earlier, average attack bandwidth jumped
dramatically from 5.9 Gbps to 48.25 Gbps, a staggering 718 percent increase.
Compared to Q1 2012
Compared to the same quarter one year ago, the total number of attacks increased 21 percent in Q1 2013.
While the split between the total number of infrastructure attacks and application layer attacks was similar
between the two quarters, both attack types increased when the two quarters are compared – by 21.77 percent
and 26.77 percent respectively. Average attack duration increased from 28.5 hours in Q1 2012 to 34.5 hours
this quarter. Average attack bandwidth increased dramatically this quarter, rising from 6.1 Gbps to 48.25 Gbps,
an increase of 691 percent compared to Q1 2012, reflecting how the power of botnets has increased over the
last 12 months.
Q1 2013 Average Gbps
This is a new metric that PLXsert has added to the Global DDoS Quarterly Attack Report and will continue
to release in upcoming quarters. The chart shows all attacks mitigated this quarter by bandwidth (Gbps) and
assigns a percentage.
Throughout Q1 2013, the most common attack was less than 1 Gbps, which made up approximately 25 percent
of total traffic. These smaller attacks are most common because they do not require a large amount of
bandwidth and can be executed by low skilled actors using tools such as PHP booters and a handful of
VPS servers.
As observed in the chart below, 11 percent of the total attacks were over 60 Gbps. This indicates that
advanced malicious actors have become more adept at harnessing the power of large DDoS botnets.
Furthermore, it indicates that the malicious groups behind these large-scale attacks are becoming more
organized and are coordinating with different veteran crime organizations.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Q1 2013 Average Mpps
Similar to the above chart, PLXsert has also categorized all attacks mitigated this quarter by packet rate (Mpps).
The chart shows that 22 percent of attacks this quarter had a packet rate in excess of 20 Mpps.
The first bar, packet rates less than 1 Mpps, is likely a reflection of the percentage of attacks targeting the
application layer, as such attacks do not typically use high packet rates to achieve their aim.
Based on these numbers, we can see that attackers are increasing the use of high pps rates in an attempt to
overwhelm mitigation equipment processing power and some edge routers. Prolexic’s proprietary mitigation
techniques have made such attempts unsuccessful, while at the same time providing valuable intelligence as
to the evolutionary methodologies of malicious actor groups.
Total Attack Types (Q1 2013)
Throughout Q1 2013, the majority of DDoS traffic came in the form of infrastructure attacks.
Approximately 76.54 percent of the malicious traffic that was mitigated by Prolexic came in the form of
Layer 3 and 4 protocols, whereas the remaining 23.46 percent were application attacks (Layer 7).
This section will examine the technical detail behind the protocols that were used in these attacks.
Throughout the fall and winter of 2012, there was a developing underground trend where both researchers
and malicious actors would target DDoS-as-a-Service websites that utilized booter scripts. The DDoS-as-a-
Service provider’s web application source code and database structure would be obtained, and the results
were often leaked into the public realm. PLXsert researchers were able to identify over a half dozen publicly
available booter script control panel suites.
Upon further analysis, it was determined that the majority of the popular DDoS-as-a-Service websites would
utilize the same public PHP scripts, making use of slight modifications to the payment processing options.
By default, most DDoS services providers only accept PayPal, however there are custom underground coding
services that offer to design payment-processing portals for more anonymous forms of e-currency, such as
the peer-to-peer currency Bitcoin.
(continued on next page)
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Total Attack Types (Q1 2013) (continued)
Infrastructure (Layer 3 & 4)
The majority of the infrastructure attacks came in the form of SYN floods, which consisted of 25.83 percent
of all infrastructure traffic. SYN floods continue to be a popular and effective attack type due to the
simplicity of how the attack executes, the ability to spoof origin IP addresses, and the fact that many of
DDoS botnets have SYN flooding capabilities as a primary functionality.
The second most popular type of infrastructure attack type came in the form of UDP floods. The UDP packet
is a stateless packet and also remains a favorite of malicious actors due to the ease of which attacks can
be launched. An increasingly popular method of sending UDP attack traffic has been through the use of
booters, which are PHP scripts deployed on web servers. Booters were the subject of a previous PLXsert
Threat Advisory issued in April 2012.
Application (Layer 7)
The majority of application (Layer 7) attacks came in the form of HTTP GET floods, making up approximately
19.33 percent of the total. This can be partially attributed to the fact that the majority of commercial and
public DDoS kits make use of GET floods as their standard method of attack. GET floods are potent because
they overwhelm the application running the web server and the flood may initially appear to be legitimate
traffic, requiring additional mitigation controls to be implemented.
The second most popular types of Application (Layer 7) attack came in the forms of HTTP POST floods and
SSL GET floods, each making up approximately 1.43 percent of attack traffic. HTTP POST floods are also featured in
many DDoS crimeware kits, and enable attackers to POST large amounts of data to the application. SSL GET floods
add an additional strain to the victim web servers as processing power is utilized to decrypt incoming traffic.
The multiple DDoS as a Service websites will often specify the type of attack options available and Layer 7
attacks are among the more popular choices. For example, a DDoS-as-a-Service website will make use of several
web servers that have the Slowloris script installed, which acts as a Layer 7 flood tool. Traditionally, it has been
used as a standalone DoS tool, however malicious actors have bundled it as an option into their booter suites.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Comparison: Attack Types (Q1 2012, Q4 2012, Q1 2013)
Increase in DNS Attack Traffic
Trending data points to an increase of DNS attacks that can be observed in the comparison of Q1 2012
(2.50 percent), Q4 2012 (4.67 percent), and Q1 2013 (6.97 percent). This represents an increase of over 200
percent in the last year.
DNS attacks are usually directed at organizations with large infrastructures where oversight or misconfiguration
of this service can cause severe impact to selected targets.
The increasing deployment of high-speed bandwidth to remote global regions has enabled the exponential
growth of Internet usage and along with that Internet services. A proliferation of DNS servers, many poorly
configured, and other protocol based services was the natural evolutionary step and the result has been
the reuse of old attack methods that have not lost their effectiveness, but actually gained strength with the
availability of fast and inexpensive bandwidth.
Decrease in ICMP Floods
Prolexic data shows a decrease in use of ICMP floods as an attack vector in Q1 2012 (19.65 percent),
Q4 2012 (18.04 percent), and Q1 2013 (15.53 percent). These types of attacks are focused on Layer 3 and
are relatively easy to launch and mitigate.
ICMP floods are often launched with tools such as hping or custom perl scripts that have been deployed on
compromised machines. ICMP floods have also sometimes been observed being used in tandem with basic
SYN floods as well. This particular method of use seems to be losing popularity as more effective and stealthy
methods of DDoS attacks are available.
Amplification Attacks Favored
Amplification attacks present an added layer of sophistication as the attackers must spoof the source IPs of
requests within the named protocol attack vector and direct misconfigured or unprotected servers at attack
victims to amplify the responses directed to the primary target.
Based on collected data, an increasing trend can be seen by the percentages of SYN and UDP attacks
rendered in the graphic. Data shows SYN floods in Q1 2012 (24.66 percent), Q4 2012 (24 percent), Q1 2013
(25.83 percent) respectively, and UDP floods with Q1 2012 (15.41 percent), Q4 2012 (15.46 percent),
Q1 2013 (16.32 percent). If we were to add both protocols in terms of percentage in every quarter we can
see that both together represent the most used attack vectors, accounting for 40 percent of attack activity.
Layer 7 Attacks as a Significant Attack Vector
GET flood attacks consistently appear in the quarterly data including Q1 2012 (20.42 percent), Q4 2012
(20.61 percent), Q1 2013 (19.33 percent). Layer 7 attacks are more difficult to mitigate and require deep
packet inspection technologies.
(continued on next page)
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Comparison: Attack Types (Q1 2012, Q4 2012, Q1 2013) (continued)
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Total Attacks per Week (Q1 2012 vs. Q1 2013)
As seen in the graphic below, the week of March 19th represented the largest increase in attack activity with
a 306 percent increase compared to Q1 2012. In addition, the week of March 26th shows an increase of
154 percent compared to the same period last year.
These peaks of activity are skewed by ongoing DDoS campaigns against many U.S.-based financial
services organizations. These campaigns may spread to different industry sectors in the current year as the
current DDoS threatscape is evolving with new and improved attack tools and a renewed supply/demand
ecosystem that makes it very profitable for malicious actors.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Top Ten Source Countries (Q1 2013)
The first quarter shows China as the leader of botnet activity with 40.68 percent of sourced botnet activity.
This was a significant drop from last quarter, where China represented over half (55.44 percent) of all
maliciously sourced DDoS traffic. The United States was in second place with 21.88 percent, Germany at
10.59 percent, Iran with 5.51 percent, and India at 5.01 percent. The inclusion of Brazil (4.73 percent) this
quarter further validates the steady increase of botnet activity in South America. Though not included in the
top ten, four additional countries from South America are included in the top 40 within this category.
Other additions to this quarter versus Q4 2012 are Vietnam (2.61 percent) and Canada (2.19 percent)
rounding out the top 10. PLXsert logged malicious bots from a total of 237 country codes in Q1 2013.
Prolexic has seen a steady pattern of country sourced botnet traffic across many quarters. Iran though,
has not been included in the top 10 source countries before. It is expected that countries with the largest
network infrastructures would have more incidents of botnet infection, so the appearance of Iran at number
four definitely stands out.
Countries that have vast and extensive infrastructures are typically more susceptible to being selected
as targets by malicious groups. There are also other factors involved in being targeted, such as web
applications that are vulnerable and accessibility to large numbers of web servers. Another example is
hosting providers that are slow to respond to malware clean-up requests and those perceived as out of
reach for international authorities.
These factors present a fertile ground for malicious actors and organized crime to harvest bots that are being
used for multiple purposes. These can be controlled and deployed at will to paying customers, effectively
creating an ecosystem of DDoS-as-a-Service.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Comparison: Top Ten Source Countries (Q1 2012, Q4 2012, Q1 2013)
The illustration listed below represents a vertical comparison of top ten source countries of malicious activity
within three different time periods. China (40.68 percent) continues this quarter in first place, however the
United States (21.88 percent) made a dramatic rise into second place this quarter compared to Q4 2012.
This increase of comprised hosts is directly related to the botnet framework called BroDoS. The continued
strength of this botnet includes the modification of infection methods that are targeting web-hosting
providers in the United States.
Germany has remained consistent averaging 8.98 percent over a one-year time span. The Russian Federation
continues to show a significant reduction as a source country of botnet attacks according to PLXsert
intelligence. An historically active region for hosting DDoS campaigns, the Russian Federation went from third
place (13.42 percent) in Q1 2012 to not making the top ten for the last two quarters. Other noted countries
that have decreased in overall botnet activity in Q1 2013 are Egypt (3.30 percent) and India (5.01 percent),
which has dropped almost 100 percent since Q1 2012.
In Q1 2013, the following countries show an increase in botnet activity: United States (21.88 percent), Germany
(10.59 percent), Iran (5.51 percent), Brazil (4.73 percent), Vietnam (2.61 percent), and Canada (2.19 percent).
As DDoS continues to become a more popular form of malicious activity, the security community should
expect to see more botnets being constructed in regions around the world. This has been validated through
the tracking of DDoS activity over the course of 10 years. This leaves the security community with the
increasingly challenging task of sanitizing infected hosts participating in DDoS attacks.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Comparison: Attack Campaign Start Time per Day (Q1 2012,
Q4 2012, Q1 2013)
The graph below indicates the average start time for DDoS campaigns that were launched against Prolexic’s
infrastructure. Distribution of attacks per start time shows a skewed difference towards the upper part of the
GMT continuum. Prolexic observed a notable peak of activity starting at 14:00 hours GMT and remaining equal
or above average activity until 23:00 hours. This is a change from Q4 2012 where the peak activity distribution looks
more like a bell curve, with DDoS campaigns increasing at 8:00 GMT, peaking at 11:00 GMT and then declining.
Malicious actors will choose a range of hours based on inflicting the highest possible damage to business
operations of a target. The hour distribution represents distinct targets being attacked mostly after 14:00 GMT
which in United States eastern standard time (EST) translates to 10:00 AM and continuing at a high rate until
23:00, which translates to 7:00 PM eastern standard time (EST) and 4:00 PM pacific standard time (PST).
This time frame of attacks focuses on the primary hours of business for both the East and West Coast of the
United States with the highest activity at 18:00 GMT, which translate to 2:00 PM EST and 11:00 AM PST.
The highest percentage of DDoS campaigns this quarter also correlate to enterprises whose targeted
infrastructure is located in the United States.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Highlighted Campaigns of Q1 2013
Case 1: Enterprise Organization
Prolexic is retained by an enterprise organization, which was targeted with a DDoS attack of significant
proportions. Attack traffic peaked at 130 Gbps, which was routed through various global Prolexic data centers.
The architecture of the attack consisted of thousands of compromised servers hosting web vulnerable
applications. These infected hosts contained PHP booter script files that received commands via PHP eval()
statements, which in turned generated several attack signatures. The attacks targeted a distinct number of
services, including HTTP, HTTPS, and DNS.
The analysis below will go over the technical details of the incoming attack vectors.
Attack Campaign Metrics
Attack Types: SYN Flood, UDP Flood, and DNS Attacks
Peak Bits Per Second: 130.2 Gbps
Peak Packets Per Second: 94 Mpps
Destination Ports: 53, 80, 443
Malicious Source Traffic Distribution
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Syn Flood: Port 80
14:28:31.448739 IP x.x.x.x.34022 > xxx.xxx.xxx.xxx.80: S 3582268762:3582268762(0) win 5840 <mss
1460,sackOK,timestamp 450422861 0,nop,wscale 7>
14:28:31.448742 IP x.x.x.x.35985 > xxx.xxx.xxx.xxx.80: S 3100683672:3100683672(0) win 14600 <mss
1460,sackOK,timestamp 3204823938 0,nop,wscale 7>
14:28:31.448746 IP x.x.x.x.40853 > xxx.xxx.xxx.xxx.80: S 2087368191:2087368191(0) win 14600 <mss
1460,sackOK,timestamp 2268941596 0,nop,wscale 7>
DNS Recursive Query Flood: Port 53
14:38:30.217754 IP x.x.x.x.57709 > xxx.xxx.xxx.xxx.53: 23+ A? http://www.domain.com. (352)
14:38:30.217758 IP x.x.x.x.48166 > xxx.xxx.xxx.xxx.53: 23+ A? http://www.domain.com. (352)
14:38:30.217761 IP x.x.x.x.51778 > xxx.xxx.xxx.xxx.53: 23+ A? http://www.domain.com. (352)
DNS Flood Variant(s): Port 53
15:06:44.584663 IP x.x.x.x.43111 > xxx.xxx.xxx.xxx.53: 11822 update [b2&3=0x2e2e] [11822a] [11822q]
[11822n] [11822au][|domain]
18:29:28.491124 IP x.x.x.x.49233 > xxx.xxx.xxx.xxx.53: 11822 update [b2&3=0x2e2e] [11822a] [11822q]
[11822q] [11822n] [11822au][|domain]
0x0000: 4500 0594 4cb0 4000 3211 8674 7ac9 4743 [email protected]
0x0010: aba2 0286 c051 0035 0580 7dec 2e2e 2e2e .....Q.5..}.....
0x0020: 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e ................
0x0030: 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e ................
0x0040: 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e ................
0x0050: 2e2e .
UDP Flood: Various Ports
15:47:56.799662 IP x.x.x.x.59371 > xxx.xxx.xxx.xxx.427: UDP, length 637
15:47:56.799665 IP x.x.x.x.59886 > xxx.xxx.xxx.xxx.372: UDP, length 288
15:47:56.799667 IP x.x.x.x.53637 > xxx.xxx.xxx.xxx.1018: UDP, length 520
15:47:56.799678 IP x.x.x.x.51049 > xxx.xxx.xxx.xxx.517: UDP, length 1021
15:47:56.799679 IP x.x.x.x.44458 > xxx.xxx.xxx.xxx.428: UDP, length 637
15:47:56.799765 IP x.x.x.x.62952 > xxx.xxx.xxx.xxx.503: UDP, length 1125
Syn Attack: Combination Port 80 / 443
16:06:45.588464 IP x.x.x.x.43201 > xxx.xxx.xxx.xxx.80: S 4033985943:4033985943(0) win 14600 <mss
1460,sackOK,timestamp 718642077 0,nop,wscale 7>
16:06:45.588480 IP x.x.x.x.44939 > xxx.xxx.xxx.xxx.443: S 4185809158:4185809158(0) win 5840 <mss
1460,sackOK,timestamp 154382772 0,nop,wscale 7>
16:06:45.588485 IP x.x.x.x.43193 > xxx.xxx.xxx.xxx.80: S 3418724878:3418724878(0) win 14600 <mss
1460,sackOK,timestamp 718642077 0,nop,wscale 7>
16:06:45.588490 IP x.x.x.x.45053 > xxx.xxx.xxx.xxx.443: S 1411645330:1411645330(0) win 5840 <mss
1460,sackOK,timestamp 154382774 0,nop,wscale 7>
SSL Floods: Port 443
20:43:16.487664 IP x.x.x.x.54653 > xxx.xxx.xxx.xxx.443: S 2483757859:2483757859(0) win 5840 <mss
1460,nop,nop,sackOK,nop,wscale 8>
20:43:16.487670 IP x.x.x.x.50810 > xxx.xxx.xxx.xxx.443: S 1426535454:1426535454(0) win 5840 <mss
1460,sackOK,timestamp 201785384 0,nop,wscale 7>
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
20:43:16.487675 IP x.x.x.x.46748 > xxx.xxx.xxx.xxx.443: S 3440393524:3440393524(0) win 5840 <mss
1460,sackOK,timestamp 825147656 0,nop,wscale 3>
Case Study Conclusion
As observed in the signatures, the attackers utilized several different attack vectors, primarily SYN floods,
UDP floods, and DNS floods. The architecture and source of these types of attacks appears to be multiple
botnets composed of thousands of compromised hosts. The majority of the attacking machines appear to be
compromised through vulnerable web applications such as WordPress or Joomla.
The compromised hosts are being managed via remote scripts pushed to the PHP scripts through the use of
eval() scripts. Attackers are making use of eval() scripts in order to avoid basic logging mechanisms on the
compromised hosts by ensuring the attacks are executed in memory. Furthermore, this enables attackers
to push out modifications to the attack scripts that will execute on the fly. This makes it more difficult to
preempt possible attack instructions, targets, and signatures.
Malicious Actor Group Classification
• Script Kiddies – Low technical barrier to entry and may
generate denial of service attacks for fun, fame or profit.
These attacks are simple to mitigate and not very effective
against enterprise organizations.
• Criminal Enterprises – DDoS-as-a-Business. Lacking the
passion and drive to be great attackers. This is just a 9-5 job
working for people that are paying for attacks or utilizing
extortion methodologies.
• Veteran Criminals – Utilize mature techniques to create
flash mob botnets that do not stay active for extended
periods of time, and are capable of generating attacks in
excess of 50 Gbps. This group consists of experienced digital
mercenaries for hire.
DDoS Volume by Actor type
These modifications to the attack instruction
code being passed on the fly makes it more
difficult to mitigate, and in some instances, it can
bypass mitigation technology. Prolexic engineers
are engaged in an active digital battle during
these campaigns in order to implement mitigation
signatures at the same time as the attackers are
making their modifications.
The above attack methods were used during
different time frames and interchangeably
among different services. Attackers have
evolved to the point where they will probe
for the latency of protection measures in
different services as they map selected targets.
This indicates that attackers are seeking the
weakest links and pressure points within the
DDoS protected network.
These types of attack campaigns appear
to be here to stay as a staple on the global
threatscape. Orchestration of such large attack
campaigns can only be achieved by having
access to significant resources. These resources
include manpower, technical skills and an
organized chain of command.
PLXsert believes these attacks go beyond common
script kiddies as indicated by the harvesting
of hosts, coordination, schedules and specifics
of the selected attack targets. These indicators
point to motives beyond ideological causes, and
the military precision of the attacks hints at the
use of global veteran criminals that consist of
for-hire digital mercenary groups.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Case 2: DNS Reflection against Prolexic
Recently, DNS Reflection attacks have become a hot topic in mainstream media. New extension mechanisms
such as DNSSEC are now being used as attack vectors. This case study will show how attackers are leveraging
DNS reflection attacks and what kind of impact they have on targets.
The DNS reflection attack process can be simplified into three steps: enumeration, packet creation and
attack execution. There are many different ways to abuse the DNS protocol, but in this study we will examine
a specific attack against a Prolexic nameserver.
The attack to Prolexic’s name server was directed at ns1.prolexic.com and took place on Jan 23, 2013. This specific
case was chosen because it is a prime example of a very popular technique widely used on the Internet.
Attack Campaign Metrics
Attack Type: DrDoS DNS Amplification
Event Time Start: Jan 23, 2013 23:23:00 UTC
Event Time End: Jan 23, 2013 23:30:00 UTC
Bandwidth: 25 Gbps
Attack Types: UDP Flood, UDP Fragment
Destination IPs:
Hostname: ns1.prolexic.net
Destination Port: 25345
This attack event was short, but was of high volume. Attacks that reach 20+ Gbps attacks are quite easy to
accomplish through the use of DNS Amplification attack techniques.
The 64 byte request that was used in this attack was able to generate a response exceeding 3,000 bytes,
averaging around 1,200 bytes. This attack method yields about 18x of reflection and makes it possible for
1 Gb of attack traffic to yield 20 Gb of reflected traffic.
Malicious Source Traffic Distribution
In this above graph, it can be noted that Prolexic observed a 25 Gbps increase in traffic for approximately 7 minutes.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
The above chart contains the heat map of participating countries by packet distribution. The U.S. and Japan were
the main sources of malicious traffic, with Taiwan a distant third.
Network Speeds of Attacking IPs
Analysis of the network speeds for the attacking IP addresses indicated interesting results. PLXsert discovered
the majority of malicious traffic originated from cable modems and dial up connections, indicating that
malware infected home computers are still a popular source of DDoS traffic. These statistics were obtained
from an updated MaxMind NetSpeed database.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
In the enumeration phase, the malicious actor will acquire a list of open recursive name servers from an associate,
or they will port scan the Internet for open DNS servers. Open recursive name servers will take requests for
any record. The name server will respond with either a cached response, or they will retrieve a response from the
authoritative name server, or yet another recursive name server. For example:
The above image is a request for the A record of microsoft.com from Google’s open recursive name server.
The Google’s name server responds with the answer to the A request, to which it is not authoritative. This means
that this server is an open recursive server. The malicious actor is then able to write custom tools, or use already
available tools such as dnsscan, in order identify these open recursive servers.
Packet Crafting
This specific attack made use of a popular pre-crafted packet. We will recreate that packet using the Python-
based Scapy packet-crafting framework tool. The packet will be crafted to mimic the one used in the attack.
After some minor modifications, we are able to use the EDNS option. These modification details are located
in the appendix.
Packet Crafting Parameters
The parameters for this packet contains a short list of options that we are going to need to replicate:
Query Type = * (255) commonly known as ANY
Query ID = 57369
Recursion Desired = True
Query Name = isc.org
EDNS Flag = True
EDNS Buffer Size = 4096
These options translate into scapy like so:
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Then showing the packet with scapys show() function.
These options were all set on the attack received by Prolexic, even the Query ID and Source Port were static.
The simplicity of the attack made mitigation possible using simple ACLs.
Using this packet diagram, the attacker was able to create a script that has raw socket capabilities to generate
packets with spoofed sources. This application is going to require root privileges, so a simple hack to a
web application won’t suffice. In this case, an attacker would either purchase a legitimate hosting provider,
compromise credentials for root access to a server, or escalate privileges to the root level on a compromised host.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
Servers used in reflection attacks are most likely purchased or taken over with compromised root passwords.
The requests would be generated from the attack script and send traffic toward the victim name servers
acquired during the enumeration phase. The resulting amplified responses will be sent from the victim servers
to the primary target.
DNS reflection infrastructure attacks are often easily mitigated via ACLs on border routers. The attackers
are unable to manipulate the source port, so dropping source traffic from port 53 UDP is a viable mitigation
tactic, especially if the victim infrastructure contains the available bandwidth and mitigation capabilities.
However, these attacks may cause downtime, resulting in interruption of service as thousands of genuine
cable/dsl customers might be effectively blocked from using DNS service. In addition, enterprise networks
without DDoS protection capabilities and adequate bandwidth capacities can be significantly affected,
impacting day-to-day business operations.
http://trac.secdev.org/scapy/attachment ... -edns.diff
Looking Forward
One word sums up Q1 2013: remarkable. Prolexic mitigated attacks exceeding 100 Gbps without
overwhelming its network infrastructure. The veteran criminals that are organizing and coordinating these
large campaigns are highly skilled and Prolexic has spent years building an infrastructure that can keep up
with ever increasing attack bandwidth and packet per second processing requirements.
Attack rates of this size are almost impossible for a normal enterprise to plan for. It was just September when
Prolexic saw that 50 Gbps was an easily attainable attack characteristic. We are now seeing over 10 percent
of attacks exceeding the 60 Gbps threshold. Already in Q2 2013, we have mitigated an attack that exceeded
160 Gbps. PLXsert would not be surprised that if by the end of the quarter we saw an attack break the
200 Gbps mark.
Infections in the U.S. have increased dramatically, which has been due to the vulnerability of unpatched
web applications. It is also notable that this quarter Iran became one of the top 10 countries sourcing
malicious traffic. This is very interesting because Iran enforces strict browsing policies similar to Cuba and
North Korea.
One thing is certain: DDoS is going to continue to evolve. Reflection and amplification attacks have received
significant media attention. Attacks that have generated the highest bandwidth and packets-per-second
volume against our infrastructure have been targeted attacks from infected web servers with user-level
permissions. Next quarter, we can expect the largest attacks to continue to come from these infected
web servers.
Prolexic Quarterly Global DDoS Attack Report - Q1 2013
About Prolexic Security Engineering & Response Team (PLXsert)
PLXsert monitors malicious cyber threats globally and analyzes DDoS attacks using proprietary techniques
and equipment. Through digital forensics and post-attack analysis, PLXsert is able to build a global view of
DDoS attacks, which is shared with customers and the security community. By identifying the sources and
associated attributes of individual attacks, the PLXsert team helps organizations adopt best practices and
make more informed, proactive decisions about DDoS threats.

About Prolexic

Prolexic Technologies is the world’s largest, most trusted distributed denial of service (DDoS) protection
and mitigation service provider. Able to absorb the largest and most complex DDoS attacks ever launched,
Prolexic protects and restores within minutes mission-critical Internet-facing infrastructures for global
enterprises and government agencies. Ten of the world’s largest banks and the leading companies in
e-Commerce, SaaS, payment processing, travel, hospitality, gaming and other industries at risk for DDoS
attacks rely on Prolexic for DDoS protection. Founded in 2003 as the world’s first in-the-cloud DDoS
mitigation platform, Prolexic is headquartered in Hollywood, Florida, and has DDoS scrubbing centers
located in the Americas, Europe and Asia. To learn more about how Prolexic can stop DDoS attacks and
protect your business, please visit http://www.prolexic.com, call +1 (954) 620 6002 or follow @Prolexic on Twitter.
© 2013 Prolexic Technologies, Inc. All rights reserved.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

Posts: 97
Joined: Tue Jan 01, 2013 11:21 pm

Re: DNS behind the Spamhaus/CyberBunker DDoS shitstorm threa

Postby Rider » Sat May 11, 2013 2:33 am

Excellent summary of the technical underpinnings of the attacks, from a sysadmin perspective:

First, this kind of attack is not (mainly) targeting DNS itself as your title suggests. It will of course create some additional load on DNS servers but the main purpose is to DDoS someone else. Bad server configuration might make it worse but in the end this issue is inherent in the design of DNS and UDP and, in fact, any stateless communication protocol.

It basically works like this: An attacker sends ordinary (DNS) queries to a (DNS) server. Those queries are forged to appear as if they were originating from the targets system. The DNS server now answers the query, sending the answer back to its alleged origin - the victim. This is why it's called reflection attack.

This is possible because you can verify the source of stateless communication (as DNS over UDP) as good as you can trust the sender address on a postcard. The server has just no way to decide if a query is legitimate or part of such an attack. DNS is just the most popular protocol here because there are lots and lots of servers for it around and you don't need much technical insight or special equipment to (mis)use it.

To make things worse (and at all attack-efficient), look at the amplification part. It would be not much of harm if the traffic of the attacker was equal in size to the resulting traffic. The only benefit for the attacker would be that his address gets hidden behind the DNS server. He could fake the sender address directly, there would totally be no need to re-route over DNS. But DNS answers, and that's another point why DNS is so popular here, can be a lot bigger than the question. You can find varying numbers on this depending on the exact queries used, but it can go up to 1:60 if the server is friendly enough to perform recursive queries for you. So the attacker does not need many machines under his control to produce lots of malicious traffic.

As you can easily find hundreds and thousands of "open" DNS server on the public internet, you can do the quick math how little work an attacker has to do if each open DNS server he knows will reflect his queries amplified sixtyfold to the target. As I said in the beginning, there is no really good way to countermeasure this. Naturally many DNS servers are open to everyone while they should not be, due to misconfiguration. But there are as many open server that have to be open, because exactly that's their purpose.

While you can't tell if a request is part of an attack or not your only option is to not run the server anymore. You can fiddle with rate limiting and other toys but you cannot get completely rid of this. If you are providing DNS for fun you can blacklist the source IP of the requests. But if you are on a larger scale this would damage the victim even more. Remember, all you can see on the DNS server is the address of the victim. Imagine your company is under attack through the DNS of your provider and your provider decides to cut DNS service for your company. The attacker could score this as a bazillion bonus points concerning denial-of-service.

Anyhow, those attacks happen all day and night and they are considered as "background noise" of the internet. If you set up a public (recursive) DNS server it won't take long before you are participating in random attacks. Of course sometimes things get real bad when large infrastructures (like even the dns root servers) are misused to amplify but in those cases proactive countermeasures are taken by personell until the attack goes down to "normal" levels.

So far on the teaching. To answer your question, at last:

You know your server is vulnerable if it answers queries without restriction. Period. If you are serving recursive queries, your server can generate the mentioned 1:60 ratio for the attacker. If it's serving only un-recursive it's not as bad, but still...


make sure that you really need to run a public DNS server
if you have to, take a look at BIND's allow-recursion and allow-query directives
if your DNS server will be authoritative for your own zone, there is no need for recursion at all, set allow-recursion to "none;"
if you want to run a resolver for other domains, restrict the allowed users for queries and recursive queries. You can define IP addresses, networks or access lists in the mentioned directives
think about rate limiting DNS traffic not only in BIND but also on system level. As a very simple example, these iptables rules will not allow more than 10 queries per minute from each IP address:

iptables -A INPUT -p udp --dport 53 --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP

Now, with these points in mind you should be good to go. There might still be malicious traffic on your server now and then but not in amounts that take your good night's sleep.

User avatar

Topic Author
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am

Spamhaus-style DDoS attacks: All the hackers are doing it

Postby Pattern_Juggled » Mon Jun 03, 2013 4:07 pm

Spamhaus-style DDoS attacks: All the hackers are doing it
'All you need is 10 lines of code and a lot of patience'
By John Leyden | 3rd June 2013 08:04 GMT | The Register

Hackers are increasingly turning to DNS reflection to amplify the volume of distributed denial of service (DDoS) attacks.

The technique has been known about for years but seldom used in anger, until the debilitating DDoS attack in March that peaked at 300 Gbps against anti-spam organisation Spamhaus and cloud-based DDoS mitigation firm CloudFlare.

DNS reflection attacks involve sending a request for a large DNS zone file to a DNS server, with the details of the request forged so that they appear to come from the IP addresses of the intended victim.

Open public-facing DNS servers respond to the request with a large file. The attackers' requests are only a fraction of the size of the responses, meaning the attacker can effectively amplify his attack by a factor of 100 from the volume of bandwidth they control.

The same sort of technique has been used to run a series of other attacks since, according to Matthew Prince, CloudFlare's chief exec. Traffic of 50-60 Gbps in each attack is becoming typical. The Spamhaus attack illustrated the open DNS server problem; mitigation actions since that attack mean there are less open resources to exploit.

Nonetheless, exploiting open systems to run debilitating attacks remains relatively straightforward, according to Prince: "All you need is 10 lines of code and a lot of patience.”

As well as the high volume attacks, CloudFlare is seeing a growth in smaller but more sophisticated attacks, often targeting online multiplayer games and similar targets.

In one example, gamers turned haters are targeting login credential servers by blitzing them with fake usernames and passwords. The tactic is designed to stop rivals of hackers being able to log back into online games after being turfed off by so-called booters. With rivals unable to log back into the game, hackers can win by default.

Initial "caveman with a club" SYN flood attacks designed to swamp an internet connection are being followed up by more sophisticated app layer attacks against credential servers, Prince explained. He added that, in many ways, DDoS attacks are getting run for much the same reasons IRC flamewars used to take place.

Prolexic, another DDoS mitigation firm, separately announced it had successfully blacked a massive DNS reflection DDoS attack that peaked at 167 Gbps against an unnamed "real-time financial exchange platform" on 27 May.

“This was a massive attack that made up in brute force what it lacked in sophistication,” said Scott Hammack, Prolexic's CEO. “Because of the proactive DDoS defense strategies Prolexic had put in place with this client, no malicious traffic reached its website and downtime was avoided. In fact, the company wasn’t aware it was under attack.”

The DDoS mitigation for this attack was distributed across Prolexic’s four cloud-based scrubbing centres in Hong Kong, London, and the US. Prolexic’s London-based scrubbing center mitigated the majority of the malicious traffic, which peaked at 90 Gbps.

More background info on DNS reflection DDoS attacks can be found in a whitepaper by Prolexic here (registration required).
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar

Topic Author
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am

Prolexic DrDoS whitepaper (.pdf, no reg'd required)

Postby Pattern_Juggled » Mon Jun 03, 2013 4:23 pm

A Prolexic White Paper - An Analysis of DrDoS | SNMP/NTP/CHARGEN Reflection Attacks
Part II of the DrDoS White Paper Series - Technical Series

During 2012, there was a significant increase in the use of a specific Distributed Denial of Service (DDoS) attack methodology known as Distributed Reflection Denial of Service (DrDoS). DrDoS attacks have been a persistent DDoS method for more than 10 years. The technique continues to grow in effectiveness, and it remains a popular attack method for many malicious actors.

This second DrDoS whitepaper from the Prolexic Security Engineering & Response Team (PLXsert) focuses on the use of three common network protocols engaged in reflection attacks:

    • Simple Network Management Protocol (SNMP)
    • Network Time Protocol (NTP)
    • Character Generator Protocol (CHARGEN)

Unlike other DDoS and DrDoS attacks, SNMP attacks allow malicious actors to hijack unsecured network devices – such as routers, printers, cameras, sensors and other devices – and use them as bots to attack third parties.

Similarly, basic vulnerabilities in the NTP and CHARGEN protocols (used for time synchronization and response testing respectively), can be used to misdirect and amplify server responses to a third party victim. These protocols are ubiquitous across the Internet and out-of-the-box device and server configurations leave most networks vulnerable to these attacks. In this white paper, we analyze the use of these three protocols and suggest actions system administrators can take to reduce their vulnerability to these DrDoS attacks.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar

Topic Author
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am

Prolexic Q2 2013 DDoS report: WordPress botnets big

Postby Pattern_Juggled » Fri Jul 19, 2013 6:08 pm

Average Packet-Per-Second and Attack Bandwidth Rates Rise 1,655 Percent and 925 Percent Respectively , According to Prolexic’s Latest DDoS Attack Report
July 17, 2013 | Prolexic

HOLLYWOOD, FL – (July 17, 2013) – Prolexic Technologies, the global leader in Distributed Denial of Service (DDoS) protection services, today announced that the average packet-per-second (pps) rate reached 47.4 Mpps and the average bandwidth reached 49.24 Gbps based on data collected in Q2 2013 from DDoS attacks launched against its global client base. These metrics, representing increases of 1,655 percent and 925 percent respectively compared to Q2 2012, are just two of many findings contained in the company’s Quarterly Global DDoS Attack Report, which was published today.

“This quarter we logged increases for all major DDoS attack metrics, and some have been significant. DDoS attacks are getting bigger, stronger and longer,” said Stuart Scholly, president at Prolexic. “We believe this growth is being fueled by the increasing prevalence of compromised Joomla and WordPress web servers in increasingly large botnets.”

In Q1 2013, Prolexic recorded an average DDoS attack bandwidth of 48.25 Gbps, an all-time high since the company began issuing quarterly attack reports in Q3 2011. This second quarter, average bandwidth ticked even higher to 49.24 Gbps, representing a 2 percent increase over Q1 2013 and a 925 percent increase over Q2 2012. In addition, average packet-per-second volume reached 47.4 Mpps this quarter, a dramatic 46 percent increase over the 32.4 Mpps that was logged just last quarter. Compared to Q2 2012, the average packet-per-second rate has increased 1,655 percent.

After trending down in 2011 and part of 2012, average attack durations are increasing, rising from 17 hours in Q1 2012 and 34.5 hours in Q1 2013, to 38 hours this quarter.

“Attack durations are likely increasing because perpetrators are less concerned about detection and protecting their botnets,” said Scholly. “The widespread availability of compromised web servers makes it much easier for malicious actors to replenish, grow and redeploy botnets. Traditionally, botnets have been built from compromised clients. This requires malware distribution via PCs and virus infections, and takes considerable time and effort. Consequently, attackers wanted to protect their client-based botnets and were more fearful of detection, so we saw shorter attack durations.”

Summary highlights from Prolexic’s Q2 2013 Global DDoS Attack Report

Compared to Q2 2012

    33 percent increase in total number of DDoS attacks
    23 percent increase in total number of infrastructure (Layer 3 & 4) attacks
    79 percent increase in total number of application (Layer 7) attacks
    123 percent increase in attack duration: 38 hours vs. 17 hours
    925 percent increase in average bandwidth
    1,655 percent increase in average packet-per-second (pps) rate

Compared to Q1 2013

    20 percent increase in total number of DDoS attacks
    17 percent increase in total number of infrastructure (Layer 3 & 4) attacks
    28 percent increase in total number of application (Layer 7) attacks
    10 percent increase in attack duration: 38 hours vs. 34.50 hours
    2 percent increase in average bandwidth: 49.24 Gbps vs. 48.25 Gbps
    46 percent increase in average packet-per-second (pps) rate
    China maintains its position as the main source country for DDoS attacks.

Analysis and emerging trends

As in previous quarters, attackers predominantly used infrastructure-directed attacks (Layer 3 and Layer 4), which accounted for 74.7 percent of all attacks, with application layer attacks making up the remainder. SYN floods were the attack type of choice, accounting for nearly one-third of all attacks mitigated by Prolexic’s Security Operations Center (SOC). This is the highest volume for any single attack type since Prolexic began publishing its Quarterly Global DDoS Attack Report. GET, ICMP and UDP floods were also frequently directed against Prolexic clients over the three-month period.

Compared to the same quarter one year ago, the total number of DDoS attacks increased 33.8 percent. In addition, the total number of infrastructure attacks increased 23.2 percent while the total number of application attacks (Layer 7) increased by 79.4 percent compared to one year ago. While the split between the total number of infrastructure attacks and application layer attacks was similar between the two quarters, both attack types increased when the two quarters were compared. Average attack durations have increased significantly, rising from 17 hours in Q2 2012 to reach 38 hours this quarter, an increase of 124 percent.

Compared to Q1 2013, the total number of attacks increased by 20 percent. This reflects a consistently high level of denial of service attack activity around the globe over the last six months. The total numbers of both infrastructure and application attacks increased over Q1 2013 (17.4 percent and 28.9 percent respectively). Average attack duration continued to tick upwards, rising from 34.5 hours last quarter to 38 hours in Q2 2013.

April was the most active month of the quarter for DDoS attacks, accounting for 39.7 percent of all attacks, followed by May (31.6 percent) and June (28.7 percent). This quarter, two weeks tied for the most active week of the quarter: April 8-14 and April 15-21. This high level of activity can be attributed to attacks against financial services clients and the ongoing use of the itsoknoproblembro toolkit.

Data for the Q2 2013 report has been gathered and analyzed by the Prolexic Security Engineering & Response Team (PLXsert). The group monitors malicious cyber threats globally and analyzes DDoS attacks using proprietary techniques and equipment. Through digital forensics and post attack analysis, PLXsert is able to build a global view of DDoS attacks, which is shared with Prolexic customers. By identifying the sources and associated attributes of individual attacks, the PLXsert team helps organizations adopt best practices and make more informed, proactive decisions about DDoS threats.

...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

Return to “general chat, suggestions, industry news”

Who is online

Users browsing this forum: No registered users and 3 guests