Содержание статьи

Одна из технологий, которая применяется в Китае для блокировки неугодных правительству ресурсов, — это DNS poisoning. Для тех сайтов, которые становятся целью перенаправления, это может превратиться в мощнейший DDoS, в несколько раз превосходящий трафик Google. Статья рассказывает, как это случается и как при этом спасать сервер.

INFO

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

 

Вступление

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

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

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

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

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

Читайте также:  Почтовый сервис Lavabit вернулся из небытия и открыл исходные коды

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

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

Почему мы?

Едва ли не самый главный вопрос, ответа на который я не нахожу, — почему это произошло с Iconfactory?

Единственное, что нас связывает с Китаем, — один из партнеров, Талос Тсуй (Talos Tsui), родившийся и выросший в Гонконге (еще в бытность последнего британской колонией). Маловероятно, что мы сделали что-то, раздражающее китайское правительство, — во всяком случае, до этого дня.

Всплески трафика ранее на неделе привели меня к мысли, что мы просто «попали под раздачу» — китайцы проверяли нашу способность обработки больших объемов трафика. У нас широкий канал без защиты от DDoS. Периодичность и количество попыток позволяют определить оба этих параметра.

 

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

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

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

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

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

Читайте также:  Броня для сайтов. Изучаем возможности нового WAF Shadow Daemon

 

Выбраковка

Я узнал, что общий источник трафика — это 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 для достижения максимального количества процессов-потомков. Кроме того, читатель моего твиттера из Китая напомнил, что у них день только-только начался, а значит, трафик будет лишь расти. К восьми вечера трафик по-прежнему шел, так что я выключил веб-сервисы и отправился успокаивать нервы рюмкой крепкого спиртного.

Читайте также:  Более миллиарда Android и iOS устройств уязвимы перед атаками через OAuth 2.0 протокол

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

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

 

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

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

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

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

Проблема BitTorrent

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

На сайте TorrentFreak есть хороший обзор, посвященный роли BitTorrent в этих атаках.

Самое время молиться всем богам, чтобы ваш IP-адрес не оказался здесь. По ссылке — всего лишь пример теста thepiratebay.org. Ваш сервер может попасть в этот список точно так же, как любой другой популярный сайт.

Короче, DNS poisoning во всей красе.

Источник

Реклама партнёра:

Добавить комментарий

Ваш e-mail не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.