Недавно в Москве прошла вторая конференция по эксплуатации и администрированию информационных систем Uptime.commuinty, на которой мы тоже поделились своим опытом. У нас, как обычно, о наболевшем — про DDoS.

DDoS-атаки на Хабр начались лет десять назад и до сих пор представляют для нас неприятную проблему. Сначала были робкие попытки чуть-чуть подзалить, а сейчас для нас обычный DDoS — это порядка 30 Гбит/с. Это и не удивительно, потому что сейчас у каждой бабушки в Москве есть 50Мб. Всё по классике: одна старушка — 50, 10 старушек — 500…

Вадим Рыбалко, Хабр.

Речь пойдёт не о каких-либо ноу-хау и особых джедайских техниках. Всё просто и достаточно прозаично и больше похоже на комплекс банальных гигиенических процедур. Большинству «бывалых» администраторов всё нижесказанное и так известно, но обобщить и повторить ещё раз не лишне. До многих решений мы доходили самостоятельно на основе своего опыта, так что если получится кому-то сэкономить немного времени — это уже удача. Вы всё ещё не делаете бэкапы? Тогда мы идём к вам!

Немного про нашу архитектуру

На основной площадке железо у нас всё свое, стойка своя, все сервера у нас достаточно мощные, берем по максимуму. Все затянуто в серую сеть, потому что мы стараемся не иметь собственных IP-шников. В стойку подведено три оператора связи, у которых мы арендуем небольшие блоки IP-адресов. Мы думали взять AS c Provider independent адресами, но в таком случае нам пришлось бы покупать оборудование, которое стоит как крыло от «Боинга», и оплачивать каналы, которые стоят как второе крыло. И в итоге для защиты мы выбрали Qrator.

Мы знакомы с коллегами еще с тех пор, когда они только начали работать на технической площадке МГУ под брендом HLL, с тех пор наши отношения в некоторых сферах давно переросли корпоративные. Они были одними из первых в России, кто занимался защитой от DDoS, и до сих пор остаются одними из самых адекватных. Инсайдерской информацией, конечно, делиться я не буду, скажу так: они — одни из лучших на этом рынке.

Главная проблема

Мы прекрасно представляем, как работает Qrator, и претензий к работе у нас нет. Речь не о них, а в принципе о таком типе защиты от DDoS. У любой защиты есть архитектурные ограничения, и, соответственно, способы этими ограничениями воспользоваться злоумышленнику.

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

Откуда злоумышленник может узнать настоящие сетевые адреса?

Публичный whois и другие базы типа Ripe DB

Первое — это базы данных, например RIPE, где указано много публичной информации. Там нет прямого аналога «Privacy WHOIS», как в доменах. Там все данные указаны прямым текстом: админские контакты, название компании и иные технические данные. Очень полезная информация для злоумышленников. Допустим, мы называемся «Habrahabr». Он может поискать там слово «Habr» или что-то похожее, и может найти нас. Сейчас это не так просто, как раньше. Но есть такой вариант.

Нужно помнить, что кроме RIPE DB есть еще некоторые хостеры (типа «Hetzner»), которые всегда требуют заполнять специальный формуляр для RIPE, даже если арендуешь у них один сервер. Они также где-то могут пометить арендованные адреса в whois, например хостер все равно может указать название организации в ремарках к адресу. И всё это тоже будет видно при обычном парсинге базы. Чуть более толковый злоумышленник может отсортировать по nic-handle персоны-администратора или по майнтэйнеру.

Потенциальная защита: надо максимально обезличить свои блоки IP-адресов.

Обратный resolve

Правильные PTR — это удобно и правильно, но это ещё одно оружие злоумышленника. Как правило используется комбинировано с иными методами исследования периметра.
Все знают, что для нормальной работы почты нужно прописывать PTR. Кроме этого, например, без PTR может быть долгий резолв. Но их надо обезличивать, потому что если в PTR прописать технический домен, то злоумышленник может начать сканировать по этому домену и найти интересные записи в поддоменах. Все публичные PTR желательно либо закрывать доменом провайдера, node-0-0-0-0.yatvoidomtrubashatalisp.net, например. Либо написать какую-нибудь белиберду, которая ничего толкового не сообщит злоумышленникам.

Потенциальная защита: использовать обезличенные PTR, в обратной зоне оператора.

Подбор адресов, сканирование портов и служб

Злоумышленник может произвести сканирование блока адресов на открытые порты, в том числе всего LIR (оператора), так как их в целом относительно немного. Получив список адресов с активными web-серверами, злоумышленник может сделать запрос а-ля curl -H "host: example.com" http://INET_ADDR/ с целью получить ответы web-сервера с атакуемым virtualhost. В этом злоумышленнику может помочь HTTPS, особенно, если сертификат на сервере всего один и нет TLS SNI. И, допустим, может быть такое, что злоумышленник даже не пытается с помощью cURL дернуть с заголовком имя конкретного сайта, а просто тупо дергает IP-адрес по порту 443. И он может получить дефолтный сертификат, в котором будет указано имя сайта и его домен.

Потенциальная защита: методов защиты от таких исследований много, и лучше всего вообще ограничить входящие соединения на уровне firewall: на все, что приходит не с доверенных сетей и не с сетей точек фильтрации трафика — просто не отвечать. Если используется центр очистки данных, то нужно взять список его адресов и добавить их в white-листы и полностью закрыть вход для всех остальных. Например, Куратор недавно ввёл автоматическое тестирование доступности защищаемых хостов не с адресов точек очистки трафика, за что ему спасибо.

Следует помнить, что если вы думаете, что если вы указали в А-записи для сайта адрес центра очистки данных, то ваш nginx его не отдаст — вы ошибаетесь. Конечно отдаст. Ещё раз: проще всего просто все сокровенное скрывать фаерволом.

Почтовики

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

Второе, на что мы, подозреваю, однажды сами попались — заголовки Received: в заголовках может быть указан каждый hop, где прошло письмо. И там может быть указано, что сервер с таким-то IP получил от сервера с таким-то IP письмо, по конкретному протоколу, в конкретное время, с конкретным ID письма. Просто посмотрев исходник письма можно увидеть ваши IP-шники.

Потенциальная защита: почту лучше выводить через пограничный почтовик, который находится в изолированном от основной инфраструктуры сетевом пространстве, к примеру на арендованном сервере или виртуалке. Надо контролировать заголовки писем и маскировать/удалять компрометирующие заголовки received в автоматическом режиме. Или пользоваться внешним ресурсом, типа Mailgun, там такой проблемы нет (но есть другие).

DNS

Целая куча возможностей для атаки, все и не перечислишь. Ключевой узел — primary NS, которой является источником всех обновлений для всех secondary. Если primary положат, то при этом заблокируют еще и возможность сменить обычную А-запись. И ничего ведь не сделать, потому что сначала нужно будет переделегировать домен на другие NS сервера. В общем — куча проблем, с которыми мы тоже сталкивались, года 3 назад. В итоге primary мы просто скрываем. То есть мы их нигде не анонсируем. Они у нас есть, но они далеко. Он не один, и их IP-адреса и доменные имена вообще нигде не указывается. В записи SOA, где мы по идее должны указать primary, мы указываем адрес одного из secondary. Все очевидно. И мы не обновляем DNS с помощью axfr. Так как DNS был придуман достаточно давно, эта технология не очень подходящая для нашей схемы. Мы используем PowerDNS с MySQL бекендом, где мы храним все базы. Все наши secondary — это MySQL слейвы с PowerDNS. И даже если какой-то из наших DNS будут ддосить — у нас их все равно очень много. В том числе DNS, которые прикрыты защитой от DDoS-атак от Куратора. Мы купили кучу виртуалок, их действительно много.

Потенциальная защита: как и в случае с почтовиками, не держать DNS в одной инфраструктуре с основной инженеркой. Master вообще лучше спрятать подальше и никак не анонсировать. Делегировать домены лучше на secondary, в том числе и в SOA-записи.

Про AS

Мы думали, гадали, брать ли нам свою AS. Нам даже предлагали сделать практически на халяву со статусом LIR, но, во-первых, нам не нужно столько адресов (/23 — 512 штук). Во-вторых, это лишняя ответственность, потому что нужно общаться с RIPE, а общаться с ними надо уметь. В-третьих, нужно платить RIPE деньги за IP-шники (формально нет). И, самое главное: все данные, все IP-шники будут доступны для всех. Соответственно, нужно ставить дорогостоящие железки, нужно иметь очень хорошие каналы, иметь кучу аплинков, повысить контроль над сетью. Это совсем не для нас, но нормальная схема для кого-то покрупнее.

Спалили, льют 30 гигов в канал. Что сделать для минимизации потерь?

Независимые каналы

Иметь несколько независимых каналов независимых операторов, с независимыми роутерами. По два-три небольших блока из разных частей блоков адресов оператора. Это позволит оперативно и безопасно «слить» атакованный блок в nullroute.
Даже имея центр очистки данных, мы ему в апстримах указываем адреса нескольких наших внешних провайдеров, чтобы в случае, если у нас возникнет проблема с одним из провайдеров, например потеря сети или DDoS-атака, чтобы Куратор мог перенести всю нагрузку на другой. Это похоже на upstream от nginx, который умеет выкидывать нерабочие апстримы.

Вменяемые операторы

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

BFG

Иметь на стыке с оператором BGP, даже в случае отсутствия нормальной AS и блока адресов. BGP для многих — это три страшные буквы, которыми называется особенно темный лес с особым крепким сортом темной магии. На самом деле, ничего страшного здесь нет. Даже если у вас нет никакой AS, BGP — это хорошо. Потому что нормальные операторы могут позволить свой же маленький блок адресов анонсировать себе же с роутеров клиента под «серой» AS. Если вдруг заливают какой-то определенный префикс, то вы снимаете его у себя с анонса на пограничных роутерах, и атака затыкается на стороне оператора, и автоматом не доходит до маршрутизатора. Даже если льется какой-нибудь UDP, который тяжело контролировать, то оно уже терминируется на уровне оператора. У него хорошие каналы, и он это выдерживает. А наши роутеры, хотя и нормальные, но не лютый энтерпрайз, конечно же и 30 гигабит они не выдержат. Так что советую разобраться с сетью: как она работает, как работает маршрутизация, в том числе — в глобальной сети; что такое BGP, хотя бы основное. Без насмешек, хороший учебник по сети — Cisco CCNA, там даже расскажут про семейку Флинстоун.

Be calm

В случае атаки делать всё медленно и вдумчиво. Самое главное правило, правильно вообще его сделать первым. Если вдруг что-то случилось, нельзя терять голову. Особенно, когда начальство бесится от того, что что-то не работает, ни в коем случае не делать резких движений, потому что можно случайно потерять вообще все. К примеру, банально не в тот access-list прописать какой-нибудь не тот IP-шник, и можно потерять всю сетку целиком. Либо, когда лежит сервак, умерла база данных, нужно сначала понять, что именно умерло, прежде чем чинить, потому что можно сделать только хуже, и заодно сломать бэкап. Не зря есть пословица: «семь раз отмерь, один отрежь». Нужно все делать вдумчиво.

Заказать pentest или воспользоваться WAF

Никогда не зазорно дать контролируемо поломать защиту периметра. Скорее всего pentest будет недешёвым удовольствием для «человека с улицы», но всегда «возможны варианты». Что касается WAF — штука хорошая, но только в комплексе. Многие из присутствующих на рынке поставщиков WAF выглядят странными шарлатанами.

IDDQD mode

Если у компании действительно много денег. Всю AS целиком можно анонсировать по BGP в центр очистки данных. Это достаточно дорого, потому что необходимо здраво просчитать утилизацию каналов, так как тарификация ведётся за полосу трафика. Если кто-то начнет через эти IP-шники что-то лить не то, то налить он может на очень много денег. Дополнительно — это добавляет геморроя, так как придётся уже основательно разбираться в сетевых технологиях и уметь их готовить. Скорее всего это будет отличным вариантом для средней компании с развитой инфраструктурой и сформированным отделом эксплуатации.

Как и во всех важных делах, в случае с защитой периметра сети полагаться на авось не очень хорошо. Также верно утверждение про «волшебные пилюли» — их не существует. ДДоС — неприятная штука, но необязательно фатальная. Соблюдайте правила безопасности, не подставляйтесь, все что надо прятать — прячьте.

Всем хорошим ребятам мы желаем успешно отбивать все атаки, злоумышленникам желаем всяческих неудач. И да пребудет с вами сила!