The attack started on our new mirroring system (powered by mirrorbrain) 2.5 days ago, during the night (after 2am, so we were sleeping).
We were woken up (OP and I) in the morning by many mirrors complaining of high bandwidth use. The actual number of requests was not that high (400 req/s), but the botnet was downloading the whole vlc.exe, aka 22MB. So, we were at around 70Gbps during the night, in average.
Afterwards, North America got up, and things got worse. We had up to 1660 req/s, so around 292 Gbps...
This is very weird for a DDoS, to be honest.
Our front machine that splits the down mirrors was taking most of the load, and we were able to find the patterns to drop the botnet connexions, in order to not kill too much our mirrors. I won't discuss too much of the patterns, as you can imagine, but as usual, I'll be happy to discuss it IRL or by mail.
Tweaking the front server was also important to reduce the number of open connexions, to not kill our server.
2.5 days after, the attack is still going on, with an average of 500req/s.
The video was done using logstalgia, using scripts of OP, on my machine (<troll>he was running eclipse, he couldn't do both at the same time :)</troll>).
Maybe it was aimed at bandwidth costs?
Of course! It must be the mplayer folks!!
I've had to deploy request rate limiting solutions in the past because of well meaning federated search mash-ups that included content from servers that I run.
Filtering by useragent seems to be a temporary solution. I think that's especially true since you've disclosed publicly that's what you're doing.
No need for extra steps - this module shall be compiled and part of nginx-full package from nginx official PPA, if OP is using Ubuntu.
Also, pattern-wise - most of the traffic in the video seems to be hitting a single .asc file.
The .asc is a logstalgia visualisation bug, because in fact, it merges the few .exe.asc requests with the massive .exe requests
As someone who over the past decade regularly had to sell higher management on investing in infrastructure, I can tell you this will be extremely useful.
Seriously, even if it's just a random visualization of some normal peek traffic, it will go down easier than dozens of actual arguments, slideshows with bullet points or fat reports nobody reads. Show the video, do a bit of handwaving and there's your budget...
For any techie trying to convince their boss they need more servers, this is a very powerful tool. Use with caution.
It's easy to write off shiny visualizations as silly (which is what I did above) but they definitely offer a perpective that you can't get any other way.
It's not quiet there yet!
To make the decryption CPU intensive you may simply use any encryption algorithm you like, many are available as JS libraries, but instead of giving the entire decrypt key, skip the last 2 digits, and let the end user brut force the last 2 digits in the client via JS. That way there is a computational cost to each attack request.
Just some ideas off the top of my head. Not sure at the moment how to implement the server side part at the moment, but I am guessing that their are server side rules that allow you to easily set per ip access restrictions to folders or fils.
PS: please excuse spelling, typing this on my iPhone.
The perception being: if you can see the source of a media player program, the encryption might be implicitly compromised. This is a silly idea though, because it neglects certain realities about the very nature of electronic encryption, and media consumption. Maybe having source code lowers the bar in some respects, but the reality is that determined people will simply bootleg media anyway, by other means.
Not an accusation though, just that my tinfoil hat is tingling. Who else might be so motivated to attack an awesome software project like VLC?
Or, less likely but more timely, the GPL→LGPL relicensing to get an AppStore port, or the consultation to get the French DRM police to play its role in enforcing a conflicting law about interoperability.
Anyone who wants to show off a proof-of-concept attack to potential customers, without stepping on any huge toes. (e.g., it's relatively safe to DDoS VLC, not so much a U.S. government agency or a huge multi-national company.)
Within the last year or two I've given up trying to find reasons for DDOS attacks. I think of them now like Internet traffic weather. They just happen at random times and you better be prepared.
That's my general assumption of any attack in which the response to a request is in the many MB range and the request is in the bytes range.
That someone with limited bandwidth and many connections is attempting to acquire a large amount of bandwidth to attack someone else.
> The actual number of requests was not that high (400 req/s), but the botnet was downloading the whole vlc.exe, aka 22MB. So, we were at around 70Gbps during the night, in average.
Source spoofing would not allow downloading the whole file; the spoofed source address would get the first response packet and send an RST ("stop, no connection associated with this packet, go away") long before that point.
And more than 10 millions downloads per day?
I highly doubt 500 different people are upgrading ubuntu every second, but a bug in the software is possible I suppose.
You might be notified via downtime, alerts of load, in this instance, I suspect; download graphs, log analytic (if using a cdn which can handle the load, then you might not notice for a while i.e. eye popping bill).
Narrowing down the attack profile means looking at logs. Be that network flow data (very helpful) or in this instance web server logs. Probably something like: totals grouped by ip, destination url, etc to see if there are any spikes.
Also, managing stress. If you are some type of retailer then you likely are losing money, people are asking for updates, etc. This can be extremely stressful.
Now I can see such a tool and it looks wonderful.
(More on topic, DDOS is beautiful!)
It's not possible to inspect the user-agent via the linux firewall (iptables) is it?
I guess you can use this if your iptables supports string matching
Hang on guys!
Also follow the submitter link, currently etix seems to be most active on Twitter: https://twitter.com/etixxx
That visualization sort of looks like a cone.