Пиковая мощность DDoS-атак достигает 450-500 Гбит/сек

Пиковая мощность DDoS-атак достигает 450-500 Гбит/сек

Пиковая мощность DDoS-атак достигает 450-500 Гбит/сек

Компания Arbor Networks обнародовала 11 ежегодный отчет, рассказывающий о безопасности общемировой сетевой инфраструктуры. Документ составлен на основе данных, полученных от 354 респондентов, которыми выступили провайдеры, хостеры и мобильные операторы со всего мира.

Согласно отчету, за прошедший год мощность DDoS-атак вновь возросла, установив новый рекорд: 500 Гбит/сек.

Хотя пару недель назад группа хакеров, называющая себя New World Hacking, заявила об осуществлении DDoS-атаки мощностью 605 Гбит/сек, никаких доказательств их «подвига» так и не было найдено. Таким образом, самой мощной атакой в истории по-прежнему оставалась атака мощностью 334 Гбит/сек, зафиксированная в прошлом году Arbor Networks, пишет xakep.ru.

Год 2015 продолжает тренд последних лет и снова поднимает планку мощности DDoS’а. За период с ноября 2014 года по ноябрь 2015 года различными респондентами был зафиксирован ряд атак, чья мощность достигала 450 Гбит/сек, 425 Гбит/сек и 337 Гбит/сек. В дополнение к этому одна неназванная компания и вовсе подверглась атаке мощностью 500 Гбит/сек, что является новым мировым рекордом.

 

Рост мощности атак в последние 11 лет

 

Специалисты Arbor Networks приводят и еще более неутешительную статистику: в 2014 году лишь 20% опрошенных компаний сообщали об атаках мощнее 50 Гбит/сек. В 2015 году уже почти 25% респондентов наблюдали атаки, чья пиковая мощность достигала 100 Гбит/сек. К тому же сразу пять респондентов сообщили  об атаках мощностью свыше 200 Гбит/сек.

В этом году активно набирают популярность атаки, направленные против облачных сервисов. Если в 2014 году они составляли 29%, теперь их уже 33%.

Не теряют актуальности отраженные и усиленные DDoS-атаки. Именно с их помощью злоумышленникам удается наращивать мощность до 500 Гбит/сек.

 

Статистика использования протоколов для отраженных/усиленных DDoS-атак

 

Но киберпреступники не стоят на месте и активно применяют новые техники. Так, 9% опрошенных компаний наблюдали атаки с использованием инфраструктуры IPv6. Впервые число атак направленных против DNS превысило число атак на HTTP, а количество SIP/VoIP атак увеличилось с 9% до 19%.

Ознакомиться с полной версией 120-страничного отчета можно здесь. Документ содержит не только свежую статистику о DDoS-атаках, но и в целом рассказывает об угрозах, которым за прошедший год подвергались компании по всему миру.

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru