Великий китайский DDoS. Как сисадмин Iconfactory отразил удар из Китая

INFO

Это перевод статьи, впервые опубликованной в блоге Крейга Хокенберри (Крейг в числе прочего отвечает за поддержание сайта фирмы Iconfactory). Перевод предоставлен «Хакеру» компанией seed4.me, которая занимается услугами VPN. В июле 2015 года сотрудники seed4.me столкнулись с тем, что их сервис заблокировали в Китае. Разобравшись с вопросами блокировки, в seed4.me узнали об интересной обратной стороне китайского файрвола: некоторые сайты становятся жертвами перенаправления запросов и ложатся под мощным напором китайского трафика. Опыт Хокенберри — наглядная демонстрация того, как это случается. К слову, seed4.me теперь снова доступен в Китае, но уже под другим доменом.

Вступление

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

Все началось с сообщения моего коллеги, Геда, которое пришло в 8:30 утра: «Упал почтовый сервер. Посмотри, когда сможешь. Заранее спасибо».

Серверы упали как на западном побережье США, так и на восточном — в этом я удостоверился сразу же. И начал разбираться, в чем проблема.

Другие статьи в выпуске:

Xakep #216. Копаем BitLocker

• Содержание выпуска
• Подписка на «Хакер»-60%

Непосвященному этот график ничего не скажет, а вот сетевому администратору он может показать многое. На нем отображается объем трафика, поступающего на основной сервер Iconfactory. Синий график — объем входящего трафика (Мбит/с), зеленый — объем исходящего. Как правило, первый гораздо меньше — в ответ на HTTP-запросы возвращается в разы больший объем, чем они отправляют.

Пик входящего трафика составил 52 Мбит/с. Для сравнения: автор популярного блога Daring Fireball пишет, что для успешной DoS-атаки на сайт достаточно трафика объемом 500 Кбит/с. В нашем случае этот объем был превышен стократно.

Если допустить, что каждый запрос содержал 500 байт, мы получим 13 тысяч запросов в секунду, что составляет примерно треть общего поискового трафика Google. Можно также посмотреть, как журнал Paper масштабировал свои серверы из-за филейной части фотомодели Ким Кардашьян — нагрузка на них составила 8 тысяч запросов в секунду.

И весь этот трафик обрушился на один IP-адрес, обслуживаемый единственным четырехъядерным сервером.

Возврат управления

Первым делом нужно было вернуть управление сервером. Однако ни одна служба (включая SSH) не реагировала. Единственным выходом из ситуации оказалась удаленная перезагрузка, после чего нужно было дождаться, пока сервер придет в себя.

Как только был получен доступ к оболочке, я отключил веб-сервер, поскольку именно он с наибольшей вероятностью был целью для генерируемого трафика. И оказался прав: как только на 80-й и 443-й порты перестал поступать трафик, странности как отрезало. Случилось это в 9:30 (что можно увидеть на графике).

Первый же просмотренный мной лог показывал, что в 3:03 было kernel panic из-за zalloc — в это время произошел наибольший всплеск трафика. System.log отображал аналогичные проблемы, которые возникали из-за чрезмерного объема трафика и приводили к избыточному количеству процессов и критическому уменьшению объема памяти.

Рискнув на минуту запустить веб-сервер, я обнаружил, что параметр Apache MaxClients использован полностью. Наш сервер попросту не имел возможности содержать тысячи процессов-потомков Apache (в обычном состоянии их было меньше сотни). Так откуда же шел этот адов трафик?!

Выбраковка

Я узнал, что общий источник трафика — это HTTP, а значит, наверняка найдутся какие-то полезные записи в логах Apache (особенно учитывая, что они стали занимать сто мегабайт вместо обычных десяти).

В логах было огромное количество запросов, в результате которых возвращался код 403. Запрашиваемые пути были лишены всякого смысла — так, одним из самых распространенных оказался путь /announce, однако были и другие запросы, выглядевшие как обращения к различным CDN, Facebook, Twitter и прочим сайтам, к которым Iconfactory не имеет отношения.

Я решил добавить %{Host}i в CustomLog для отображения заголовков Host в запросах, после чего запустил сервер на тридцать секунд, чтобы собрать логи. Конечно же, трафик, шедший на наш сервер, был предназначен совершенно не для нас.

Какая-нибудь желтая пресса сочла бы за честь получать трафик для cdn.gayhotlove.com, но нам он был ни к чему.

Было ясно, что кто-то или что-то перенаправляет трафик заведомо неверному получателю. Самой вероятной кандидатурой были DNS-серверы. Взглянув же на IP-адреса отправителей, я выяснил нечто интересное: весь трафик шел из Китая.

Все встало на свои места. Стала понятна суть проблемы. Теперь мне оставалось лишь найти, что с этим трафиком делать.

Настройка Apache

«Нужно более эффективно обрабатывать HTTP-трафик», — это была первая мысль.

На нашем сервере хостятся несколько сайтов. Для маршрутизации запросов между ними используется директива VirtualHost. Виртуальные хосты, в свою очередь, зависят от заголовка Host: в HTTP-запросе. Эта информация была полностью ложной.

Внимательно изучив документацию, я обнаружил, что у Apache в некоторых случаях бывают проблемы с определением того, какой виртуальный хост использовать. Цитата из документации: «Если не указано директивы ServerName, сервер попытается узнать имя хоста, осуществляя обратный DNS-запрос по данному IP-адресу».

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

<VirtualHost _default_:80>
    ServerName default
    DocumentRoot "/Web/Sites/default"
    <Directory "/Web/Sites/default">
        Options None
        AllowOverride None
        DAV Off
    </Directory>
    LogLevel warn
</VirtualHost>

Можете убедиться, что это реально работает, подставив неправильный заголовок:

$ curl -H "Host: facebook.com" [http://199.192.241.217](http://199.192.241.217)

Все это, конечно, помогло, но не окончательно — лишь увеличило время, требуемое Apache для достижения максимального количества процессов-потомков. Кроме того, читатель моего твиттера из Китая напомнил, что у них день только-только начался, а значит, трафик будет лишь расти. К восьми вечера трафик по-прежнему шел, так что я выключил веб-сервисы и отправился успокаивать нервы рюмкой крепкого спиртного.

В 11:30 вечера снова произошло что-то странное: трафика не стало. Видимо, в Китае кто-то дернул рубильник...

Я было собрался запустить сервер, но опыт подсказывал мне оставить все как есть — выпивка и bash плохо сочетаются. Проблема была отложена на завтра.

Здравствуй, дедушка Torrent

Утром я попытался запустить сервер. Какое-то время он работал нормально, но через десять минут Apache опять пошел в разнос.

Наибольшая часть трафика сыпалась на URL BitTorrent /announce — китайские торрент-клиенты по-прежнему считали мой сервер трекером и каждые десять минут проверяли доступность 80-го порта. И BitTorrent в Китае явно пользуется больше, чем пара-тройка человек.

Основной трафик, возникший при DNS poisoning, исчез, но наш сервер по-прежнему был погребен под трафиком от торрент-клиентов. Оставался лишь один путь — блокировка по IP-адресам.

Блокировка Китая

Я большой фанат свободного и доступного интернета: мне нелегко далось решение о блокировке трафика от ни в чем не повинных людей. Однако в данном случае это было единственным рабочим решением. При столкновении с DDoS-атакой наподобие описанной это нужно делать сразу же.

Для этого следует получить список всех блоков IP-адресов, принадлежащих данной стране, и добавить их в список правил файрвола. На момент написания статьи в Китае было 5244 заблокированных IP-адреса.

У нас используется ipfw, и я написал скрипт для создания набора правил на основе файла cn.zone:

#!/bin/sh
# cn.zone взято с http://www.ipdeny.com/ipblocks/
# Для создания правил нужно выполнить следующую команду:
# $ build_rules > /tmp/china_rules
# А для применения вот такую:
# $ sudo ipfw /tmp/china_rules

r=1100
while read line; do
    echo "add $r deny ip from " $line " to any in";
    r=$(( $r + 1 ))
done < cn.zone

Здесь может потребоваться изменить начальный номер правила, чтобы оно шло перед тем, которое разрешает 80-й порт.

После установки этих правил трафик на наш сервер сразу же вернулся в норму.

Копаем глубже

После того как я поднял сервер, у меня появилось время для более внимательного изучения логов и для того, чтобы узнать, не было ли у кого-нибудь такой же ситуации.

Первые успехи

Как оказалось, трафик на трекер появился чуть раньше — присмотревшись внимательнее к недельной статистике трафика, я обнаружил несколько всплесков (5 Мбит/с), которые произошли поздним вечером в четверг 15 января и в субботу, 17-го.

Когда я столкнулся с этим впервые, я списал их на случайный трафик наподобие пакетов из Румынии на phpMyAdmin. Однако на сей раз румыны были ни при чем.

Если посмотреть на источники первых пакетов, можно заметить, что они были разбросаны по всему Китаю — от густонаселенного Гонконга до севера Тибета. Что это был за трафик, мне неизвестно и по сей день.

У меня остались все логи, которые были сгенерированы этим трафиком, так что, если у вас есть объективные причины для их анализа, пожалуйста, дайте мне знать.

Мы не одиноки

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

На данный момент каждый компьютер в Китае может быть использован для DDoS-атак на ничего не подозревающие сайты. Как едко выразился мой коллега Син: «Они превратили в оружие весь свой народ».

Заключение

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

Полезные ресурсы

Если у вас вместо Apache используется nginx, то и для него есть решение, позволяющее заблокировать китайские торрент-запросы.

Для тех, кто пользуется iptables в Linux, опять же есть статья по блокировке IP. Интересно, что сайт Мэтта хостится на Linode, — не стоит надеяться на защиту крупных хостеров.

Есть и хорошее обсуждение с другими владельцами сайтов, которые столкнулись с торрент-трафиком.

Существует еще одно решение — переезд сервера на другой IP. Конечно, что-то нужно будет делать с распределением DNS и перенастраивать обратное преобразование имен (в частности, если у вас запущен почтовый сервер), но это может оказаться самым простым способом уйти с линии огня.