Одна из технологий, которая применяется в Китае для блокировки неугодных правительству ресурсов, — это 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 Кбит/с. В нашем случае этот объем был превышен стократно.

Если допустить, что каждый запрос содержал 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 (в обычном состоянии их было меньше сотни). Так откуда же шел этот адов трафик?!

 

Выбраковка

Я узнал, что общий источник трафика — это 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-адресам.

 

Проблема BitTorrent

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

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

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

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

 

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

Я большой фанат свободного и доступного интернета: мне нелегко далось решение о блокировке трафика от ни в чем не повинных людей. Однако в данном случае это было единственным рабочим решением. При столкновении с 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-й порт.

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

 

Ложное чувство безопасности

Я по-прежнему остаюсь уязвимым — даже с учетом того, что файрвол настроен. Почему?

Я не уверен, что он устоит против еще одного флуда 52 Мбит/с. Напомню, что код ядра FreeBSD может обработать до 65 535 правил. Скорость выполнения этого кода, естественно, зависит от быстродействия процессора. Когда я узнал, что распределенный аппаратный файрвол Cisco не выдерживает и падает, я перестал доверять своей конфигурации (около 6500 правил и 13 тысяч пакетов в секунду) — не было уверенности, что железо это выдержит.

Предварительные расчеты показывают, что в моем случае брандмауэр выполняет 84,5 миллиона сравнений в секунду — или одно сравнение в 11 наносекунд. По этой же самой причине не стоит надеяться, что какие-либо роутеры или схемы балансировки нагрузки помогут защитить ваш сервер от Китая. Нет никакой гарантии, что ваш хостинг сможет защитить ваш сервер или виртуалку от такого интенсивного трафика, какой был у нас на прошлой неделе.

Все еще не верите? Взгляните на первый коммент поста Internet Storm Center: «Я столкнулся с аналогичной проблемой в прошлую пятницу, второго января 2015 года. Вывело из строя наш кластер с полной балансировкой нагрузки».

 

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

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

 

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

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


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

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

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

 

Мы не одиноки

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

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

 

Другие случаи

DDoS был не только на мой сервер — за последние несколько дней я увидел немало сообщений от разработчиков и администраторов о похожей проблеме с их серверами.

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

Иногда вопрос поднимался и людьми, которые знают в разы больше о запущенных серверах, чем я. Особенно убедительно он выглядел в исполнении Джона Адамса (John Adams): «Это постоянно происходит с большим числом сайтов, которыми я управляю. Что за фигня, Китай?»

Если такие люди, как Джон (напомню, что он разработал инфраструктуру «Твиттера»), вопрошают подобное, любителям вроде меня остается только нервно смеяться.

Еще одна понравившаяся мне запись была написана Джейми Завински (Jamie Zawinski), одним из первых разработчиков веб-браузера. Хочется надеяться, что его ответ на китайский торрент-трафик в конечном счете решит проблему.

 

Заключение

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

 

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

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

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

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

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

 

Пара слов о китайском правительстве

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

Это действие, вкупе с DDoS-флудом, полезно для правительства, намеревающегося изолировать своих граждан от открытого и свободного интернета. В результате послать пакет куда-нибудь за границу Китая очень сложно. Но даже если попытка будет удачной, скорее всего, его перенаправят на сервер, который и будет жертвой DDoS.
Извне это выглядит попыткой создания собственного закрытого интернета: сети, где ни один пакет не может прийти извне или покинуть ее.

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

Но важнее, чем технологии, люди, использующие интернет. Например, сайт GreatFire.org отслеживает Великий Брандмауэр и предоставляет информацию как на английском, так и на китайском. Знание — сила.

Кроме того, можно перенаправлять трафик подобного рода на зеркала. Для спецов никогда не составляло особых трудностей держаться на шаг впереди тех, кто пытается контролировать.

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

И судя по откликам, я не единственный, кто придерживается подобной точки зрения. Люди принимают ответные меры. Хотелось бы надеяться, что в течение нескольких лет, вместо того чтобы блокировать IP и создавать туннели, мы найдем способ справиться с идиотским поведением китайской правящей партии.

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    3 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии