company_banner

DDoS в обход Куратора: простые действия для спокойной жизни

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



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


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

    ТechMedia 326,35
    Создаем и развиваем сервисы для гиков
    Поделиться публикацией

    Вакансии компании ТechMedia

    Комментарии 17
    • 0
      Что такое BFG?
      • +1
        • +3

          Это метафорическое переосмысление инструмента BGP с точки зрения игровой классики.

        • +7

          Замечание про сканирование портов в поисках сертификатов SSL, PTR или ответов по HTTP:
          все уже просканировано до нас и лежит на scans.io и на commoncrawl.org вместе с историей изменений за много лет.

          • +1
            Максимум, что пришлось справляться в прошлой жизни — 10G, которые лили на обычную виртуалку со 100mbit. Спасибо, что не UDP — отбился малой кровью (2 часа даунтайма). TARPIT наше всё.

            А вот с UDP весело — при виртуалке 100mbit, FastVPS отрубал сеть при входящем потоке в 50mbit, и отказывались что бы то ни было делать на своей стороне. Уехал на OVH, которые срезали атаку самостоятельно без малейших телодвижений с моей стороны.
            Думал даже CloudFlare убрать с фронта, но решил не рисковать.

            Если кто хочет пентеста — могу рекомендовать esagelab.com
            • +2
              TARPIT наше всё.

              LaBrea-подобные? или чего другое?
              А то как-то видел тисипишный флуд на те же 10G, где тарпит-ом даже четверть не срезало.
              Не говоря уже про веб-серверные типа limit-req и ко.


              Про UDP флуд не совсем понял — провайдеру жеж легче его срубить, почти все современные железки то умеют, и автоматом (иногда по звонку провайдеру) меняют "UDP flood threshold" и иже с ним (и все идут лесом). "Нормальный" то трафик в основном через TCP бегает, а его так рубить уже нельзя...

              • +2
                Не, самый обычный TARPIT из xtables.
                iptables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK
                iptables -A INPUT -p tcp --dport 80 -j qTARPIT

                и в qTARPIT суём правила вида
                iptables -A qTARPIT -s botnethost -j TARPIT

                botnethost'ы собирал из access.log'а.

                этот тарпит ставит TCP окно нулевое, что означает «заткнись и помолчи». удалённые хосты это и делали — плюс такого соединения в том, что со стороны сервера затрат — один пакет, со стороны клиента — висящее соединение (занятый порт). то есть через несколько тысяч попыток соедениться, TCP коннекты полностью становились заняты, и открыть новые нельзя => ботнет хост переставал выполнять какие-либо атаки.

                через 20 минут набралось 200 записей, на которых атака похудела до 2 сотен мегабит, через еще 20 минут было около 300 записей, и траффик упал до обычных 40 мегабит.
                держал скрипт около трёх суток, суммарный улов был всего 5 тысяч хостов.
                первое время пытался удалять старые, но они через час опять появлялись живыми (похоже, они затыкались и их ребутили...)

                а вот про UDP да, это я и просил сделать — меня послали в пешее эротическое вида «мы ничего не делаем, разбирайтесь сами». а что я с UDP со своей стороны сделать могу? канал уже засран… только линять на другого провайдера, который может фильтровать на своей стороне или стороне его аплинка.
                • +2

                  Я там тоже так пытался, но видимо ботнет ширше был, ибо SYN/ACK-ми все завалено было, а результат так себе.


                  botnethost'ы собирал из access.log'а.

                  Мне даже делать ничего не нужно было, все собиралось fail2ban-ом автоматически из отдельного лога от псевдо-location с limit-req (с отдельным логом, т.е. значит одни "нарушители") плюс те что в протоколе от iptables отметились (порт сканы, режекты, залимичиные и т.д.)… и отправлялось в тарпит-action почти тем же макаром через iptables (только с ipset, на одном iptables таблицу бы сильно раздуло).
                  Но…
                  Видать шибко "широкий" бот-нет был… Т.е. 10G, но много-много маленьких пакетов (подозреваю что "бабушек" просто черезчур много было).
                  Совсем стихло только через сутки где-то.
                  Я статистику с логов собирал тогда, но сильно много было (слимши в базу sqlite под 20-гиг было) и анализировать не стал — руки не дошли (где-то валяется еще вроде).

                  • +1
                    Наверное. Тогда пытались вымогать что-то около 5k$, писали трижды… хе хе.
                    Вероятно, арендовали что-то маленькое, потому как срезалось легко.

                    Но если 10G на syn'ах — то тут так же как с UDP, только аплинком можно отбиваться.
                    На текущий момент, 1G хост кладут старым добрым SYNFLOOD'ом на ура, причем плевать что хост сам флуд переживает — канал просто забит, зараза.
                    Куратор, клаудфлёр, и прочие заградительные решения — ничего другого тут не сделаешь.
                    • +2
                      Но если 10G на syn'ах ...

                      Та не… Вроде нормальные three-way handshake, оно то моими SYN/ACK-ответами все завалено было, и их ACK-ответы как положено "игнорились" и т.д.
                      Просто видно правда сильно жирно было. Ну или действительно часть SYN/ACK-пакетов в пустую уходили (на поддельные адреса), так сказать в качестве "защиты" атакующей сети от возможного тарпит'а со стороны обороняющегося (т.е. комби-атака).
                      Ну а я попался.

            • 0
              Речь о habrahabr.ru или я что-то не понял?

              $ host -t ns habrahabr.ru
              habrahabr.ru name server ns3.habradns.net.
              habrahabr.ru name server ns2.habradns.net.
              habrahabr.ru name server ns1.habradns.net.
              $ host ns3.habradns.net.
              ns3.habradns.net has address 88.198.175.104
              $ host ns1.habradns.net.
              ns1.habradns.net has address 88.198.175.104
              ns1.habradns.net has IPv6 address 2a01:4f8:d16:4d4a::2
              $ host ns2.habradns.net.
              ns2.habradns.net has address 188.226.201.107

              Хетцнер и ДО. Куратора нет, кучи виртуалок тоже не видно.
              • +1

                Куратор есть:


                $ nslookup habrahabr.ru
                Address: 178.248.237.68


                $ whois 178.248.237.68
                netname: QRATOR-2041
                descr: OOO Habr

                • 0
                  Все наши secondary — это MySQL слейвы с PowerDNS. И даже если какой-то из наших DNS будут ддосить — у нас их все равно очень много. В том числе DNS, которые прикрыты защитой от DDoS-атак от Куратора. Мы купили кучу виртуалок, их действительно много.
              • +2
                Использовал в свое время Amazon для очистки трафика, дешевле чем через куратора. Наружу торчали только амазоновские ип, старых ддосеров отвадили за пол-года, новые даже не брали на нас заказы.
                • 0
                  В итоге primary мы просто скрываем. То есть мы их нигде не анонсируем. Они у нас есть, но они далеко. Он не один, и их IP-адреса и доменные имена вообще нигде не указывается.

                  Эм тогда зачем он? и можно поподробней как такое сделать? Просто не могу представить как без master обойтись, ведь он должен быть обязательно в каждом домене.
                  • +1

                    Для внешнего наблюдателя все NS, которые ассоциированы с доменом (прописаны у регистратора и в зоне домена) равнозначны. По идее, первичный NS прописывается в зоне в SOA-записи, но для стороннего наблюдателя он опять же, не особо важен. Поэтому стороннему наблюдателю запросто можно подсунуть в списке NS только вторичные сервера.


                    Понятие "первичный" и "вторичные" — они больше для внутренней кухни, так как вторичные NS забирают AXFR-запросом изменения с первичного, а первичный рассылает NOTIFY вторичным в случае обновления зоны. Так как мы в принципе AXFR не используем, у нас механика "первичный-вторичный NS" переехала в плоскость "MySQL Master-Slave".

                  • +1
                    «По нашему опыту крупные операторы — зло»
                    Золотые слова, Юрий Венедиктович (С)

                    Лет 5 назад, когда я это говорил начальству — все смотрели на меня, как на идиота. Сейчас это уже доходит до более широкого круга лиц…

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое