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 - это, по большому счёту, побочный шум. Но шум, который поднял правильные вопросы.