ADG Оставить заявку
Блог Информационная безопасность 4 мин чтения

Megaupload, Anonymous и DDoS: клиенты спросили - а нас накроет?

ФБР закрыло Megaupload, Anonymous ответили DDoS-волной на правительственные сайты. Клиенты звонят: как защититься? Разбираем что реально работает на уровне оператора и приложения.

Контекст момента

ФБР закрыло Megaupload 19 января 2012, Anonymous организовали ответные DDoS-атаки на сайты Министерства юстиции США, RIAA, MPAA и Universal Music

В четверг вечером стало известно, что ФБР закрыло Megaupload и арестовало его владельцев. К пятнице Anonymous уже укладывали сайты Министерства юстиции США, RIAA, MPAA и Universal Music - DDoS-атаки шли волнами, несколько ресурсов лежали по несколько часов. У нас зазвонил телефон.

Звонили клиенты с разными формулировками одного и того же вопроса: «А нас так же могут положить?» Кто-то имел в виду Anonymous конкретно, кто-то - любую мотивированную группу с инструментами типа LOIC. Разговор полезный, потому что DDoS как тема давно висит в воздухе, а конкретный живой случай помогает объяснить, что здесь вообще реально.

Что произошло технически. DDoS от Anonymous в этот раз - классический HTTP-флуд и UDP-флуд, усиленный тем, что тысячи участников добровольно запускали LOIC (Low Orbit Ion Cannon) с домашних машин. Никакого ботнета, никакой особой изощрённости - просто координированный объём. Сайты упали не потому что у атакующих был нулевой день или особый инструмент, а потому что инфраструктура была рассчитана на нормальный трафик, а не на кратный всплеск синтетических запросов.

Что защищает на уровне оператора связи. Это первый и самый важный рубеж. Если провайдер не фильтрует паразитный трафик на своей стороне - до клиентского оборудования долетает всё, и там уже делать особо нечего: канал забит раньше, чем пакеты добрались до сервера.

Операторский уровень защиты выглядит примерно так:

  • Мониторинг аномалий трафика - автоматическое обнаружение резких всплесков по объёму и профилю пакетов.
  • Blackhole routing (RTBH) - в крайнем случае адрес жертвы объявляется «чёрной дырой» на маршрутизаторах оператора; трафик поглощается до того, как дойдёт до клиента. Минус очевиден: сервис тоже недоступен, но инфраструктура жива.
  • Scrubbing-центры - трафик перенаправляется на очистку, фильтруется паразитная часть, легитимный трафик доходит до клиента. Это дороже и сложнее в настройке, зато сервис продолжает работать.

Всё это - предмет договора с оператором. Если в договоре про DDoS-защиту ничего нет, по умолчанию её нет. В сервисе managed-поддержки мы помогаем разобраться, что реально прописано в SLA провайдера и что можно из него получить.

Что можно сделать на стороне приложения. Допустим, оператор трафик пропустил или атака прошла через CDN. Тогда помогает несколько вещей:

  • Rate limiting на nginx/haproxy - ограничение числа запросов с одного IP за единицу времени. Против распределённой атаки не панацея, но сильно поднимает цену атаки для атакующего.
  • Разделение инфраструктуры - если публичный сайт и внутренние сервисы на разных адресах и подсетях, DDoS на сайт не валит внутренние системы. Простое и часто забытое.
  • Кеширование статики - сервер, который отдаёт кешированные страницы через CDN или nginx, держит нагрузку на порядок лучше того, что генерирует каждый ответ динамически. Часть атак буквально не доходит до бэкенда.
  • Капча и проверка JS - против LOIC и простых HTTP-флудеров работает. Против ботнета с браузерными движками - нет.
  • Разделение DNS - если DNS-сервер совпадает с боевым сервером, флуд на DNS кладёт всё разом. Лучше держать их раздельно, желательно с разными AS.

Реальный разговор с клиентом. Один из звонивших - небольшой интернет-магазин, хостинг у популярного shared-провайдера. Спросил: «Что у меня есть?» Ответ честный: практически ничего. Shared-хостинг по природе своей не предполагает индивидуальной защиты - если атака идёт на один сайт, страдают все соседи по серверу, и провайдер почти наверняка просто заблокирует атакуемый аккаунт, чтобы защитить остальных. Это не злой умысел, это логика shared-среды.

То, что случилось с сайтами правительства США - организации с реальными ресурсами и бюджетами - показывает, что DDoS-атака достаточного объёма ляжет почти на любую цель, если она не готовилась к этому специально. Но «готовиться специально» и «лечь от первого чиха» - не единственные варианты.

Большинству клиентов достаточно понять свой реальный профиль риска: кто будет атаковать и зачем, какой объём атаки реалистичен, что падение сайта на несколько часов означает для бизнеса. Из этого уже складывается разумный набор мер - без паранойи и без иллюзии, что одна коробка решит всё.

История с Megaupload ещё не закончена - там идут разбирательства по экстрадиции, хостинги по всему миру нервно проверяют свои TOS. DDoS-волна от Anonymous - это, по большому счёту, побочный шум. Но шум, который поднял правильные вопросы.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.