DDoS Twitter и Facebook: что это значит для нас

На прошлой неделе атаки на Twitter и Facebook взволновали не только пользователей, но и наших клиентов. С понедельника несколько человек написали примерно одно и то же: «вы это видели? нас так могут?». Попробуем ответить без паники и без лишнего оптимизма.

Что случилось. 6 августа Twitter лёг примерно на три часа, Facebook и LiveJournal работали со сбоями. Атака была скоординирована против конкретного пользователя - грузинского блогера с аккаунтами на всех трёх платформах, - но попутно накрыла сами платформы. Масштаб ботнета, судя по всему, был значительным: с такими объёмами трафика даже большие датацентры не справляются в одночасье.

Для нас интересно другое: атака публично показала, что крупнейшие веб-сервисы не неуязвимы, и это дало клиентам повод наконец спросить про собственную защиту.

Два класса атак - два разных разговора.

DDoS принято воспринимать как «много трафика», но это упрощение. На практике атаки делятся на два принципиально разных класса, и защита от каждого строится по-своему.

Volumetric - атаки на полосу пропускания. Ботнет генерирует UDP-flood, ICMP-flood или усиленный трафик (DNS amplification, NTP reflection - последнее пока редкость, но уже встречается), забивая канал до провайдера. Если у вас канал 100 Мбит/с, а в вас льют гигабит - ваш файрвол этого даже не увидит, трафик встанет выше по стеку. Здесь помочь может только провайдер - blackhole-маршрутизация на BGP-уровне или фильтрация на стороне оператора до вашего порта.

Application-layer - атаки на конкретный сервис. Тысячи ботов делают «нормальные» HTTP-запросы - открывают тяжёлые страницы, отправляют формы, держат keep-alive соединения. Трафик внешне выглядит как пользовательский, объём может быть скромным, но веб-сервер или база данных всё равно ложатся, потому что каждый запрос реальный. Здесь фильтрация на уровне канала не помогает - нужна работа на уровне приложения и периметра.

Что можно сделать на практике.

На уровне провайдера вопрос первый - есть ли у него вообще anti-DDoS-сервис. Не декларация на сайте, а реальная фильтрация на BGP-стыках. Крупные российские операторы эту услугу предоставляют, но условия и порог реагирования сильно различаются. Стоит явно прописать в договоре, что именно провайдер делает при атаке, за какое время и без вашего дополнительного звонка в 3 ночи.

На уровне периметра:

• Rate limiting на файрволе - ограничение числа новых соединений в секунду с одного IP. Не спасёт от распределённого ботнета, но срезает простые флуды и замедляет сканирование.
• SYN cookies - защита от SYN-flood на уровне ядра, включается в Linux одной строкой в sysctl, на Cisco IOS - аналогичным параметром. Обязательный минимум для любого публичного сервиса.
• Ограничение по географии - если аудитория известна, блокировка диапазонов по GeoIP на уровне файрвола снижает attack surface. Грубо, но работает.
• Разделение публичных и внутренних сервисов - если под DDoS попадёт публичный сайт, внутренняя инфраструктура клиентов не должна ложиться вместе с ним.

Для application-layer атак добавляется работа с веб-сервером: лимиты на MaxClients в Apache, таймауты, ограничение размера тела запроса, mod_evasive или аналог на nginx. Всё это не серебряная пуля, но поднимает стоимость атаки для атакующего.

Честный разговор о пределах.

Если кто-то целенаправленно хочет положить конкретный небольшой ресурс и у него достаточно ресурсов - остановить это без внешнего scrubbing-центра практически невозможно. Twitter с его масштабом лёг - что тут говорить про небольшой корпоративный сайт.

Реалистичная цель защиты - не «нас не положат никогда», а «случайный флуд мы переживём, целевую атаку заметим быстро и минимизируем ущерб». Это достижимо.

Именно этим мы занимаемся в рамках сопровождения инфраструктуры: мониторинг полосы и аномалий трафика, готовый регламент с провайдером, настроенный периметр. Не панацея, но разница между «легли на трое суток» и «отреагировали за 20 минут» - вполне реальная.

Если хотите разобрать свою конфигурацию - пишите.