Response Policy Zones (RPZ) на страже сети


        Мой эксперимент с открытием рекурсивного DNS сервера для всех желающих получился настолько успешным, что срочно пришлось менять правила игры. Вместо полного закрытия рекурсивного DNS я решил ограничить доступ к наиболее популярным у атакующих доменам с помощью механизма RPZ (Response Policy Zone).
         RPZ – это функционал DNS-сервера Bind, грамотное использование которого позволяет решить следующие проблемы:
    • блокировать коммуникации botnet и malware с управляющими центрами (C&C);
    • снизить нагрузку на кэширующий DNS и канал связи;
    • блокировать доступ по списку «запрещенных» сайтов (как для предприятий, так и для провайдеров);
    • перенаправлять пользователей на локальные ресурсы.
        Рассмотрим подробно варианты применения RPZ и его настройку.


    Блокирование коммуникаций botnet и malware

          Многие Botnet’ы и Malware используются DNS для связи с управляющими центрами (C&C), что усложняет процесс идентификации и борьбы с ними. Примером таких технологий является FastFlux (известна с ноября 2006г.) и DGA (Domain Generation Algorithm).
        FastFlux — для связи с C&C используется домен(ы) с большим количеством А-записей, которые часто изменяются (TTL – 5 минут). В более сложном варианте реализации данные записи могут указывать на зараженные/взломанные серверы и компьютеры, выступающие в качестве прокси. Блокирование коммуникаций такого вредоносного ПО по IP невозможно в виду их большого количества и частых изменений.
        BredoLab – один из известных botnet, который использовал технологию FastFlux. BredoLab использовался: для заражения компьютеров другими malware (Zbot a.k.a. Zeus, SpyEye, TDSS, HareBot, Blakken a.k.a. Black Energy 2) для рассылки спама и проведения атак. Подробнее о BredoLab можно почитать тут.
        Используя технологию DGA вредоносное ПО генерирует по определенным правилам большое количество доменов (до 50 тысяч), часть из которых каждый день проверяется и используются для связи с C&C.
        Cryptolocker – одна из наиболее известных на сегодняшний момент программ вымогателей — использовала данный алгоритм. После заражения компьютера Cryptolocker пытался связаться с C&C и, при успешном подключении, скачать публичный ключ, который используется для шифрования. lcxgidtthdjje.org, kdavymybmdrew.biz, dhlfdoukwrhjc.co.uk, xodeaxjmnxvpv.ru – примеры доменов использовавшихся Cryptolocker.
        Для предотвращения данных угроз можно использовать RPZ, блокируя коммуникации вредоносного ПО с C&C. RPZ-зону для защиты от подобных угроз можно вести вручную (используя данные с специализированных форумов, блогов и сайтов) или воспользоваться сервисом подписки.
     
        Несколько компаний предоставляют подобный сервис для RPZ (список взят с dnsrpz.info):
    • SpamHaus – стоимость подписки зависит от типа организации и количества пользователей;
    • Surbl – стоимость подписки зависит от типа организации и количества пользователей;
    • InternetIdentity – стоимость не ясна;
    • ThreatStop – подписка продается компанией Infoblox под торговой маркой DNS Firewall. Стоимость зависит от модели устройства. 18 сентября по этой теме Infoblox проводит вебинар на русском языке, зарегистрироваться можно тут.
    Некоторые поставщики RPZ-зон предоставляют их для тестирования, поэтому очень легко проверить свою сеть на наличие известных botnet и malware.

    Снижение нагрузки на кэширующий DNS и канал связи


        Активность botnet-агентов может приводить к значительному росту нагрузки на кэширующий DNS и канал связи. Все «правильные» администраторы ограничивают доступ к своим кэширующим DNS-серверам, и данный трафик приходит от авторизованных клиентов. Паразитная нагрузка на сервер DNS может быть как постоянной, так и периодической.

        На приведенном выше рисунке на 2 часа нагрузка вырастала со стандартных 15 тысяч запросов в секунду до 43 тысяч запросов. Для атак использовалась амплификация и ответ сервера (в 4Кб) превышал запрос в 60 раз. Соответственно, дополнительная нагрузка в 28 тысяч запросов в секунду сгенерировала исходящий трафик 875 Мб/с.
         Я просканировал одну из сетей /16 московского оператора связи (к которому я подключен). В вечернее время было обнаружено 69 устройств, которые отвечают на запросы DNS и доступны из Internet. Мой (средний по параметрам) маршрутизатор Linksys EA3200 может отработать от 1000 запросов в секунду (размер пакета 4Кб) до 3500 запросов в секунду (небольшой размер пакета), то есть сгенерировать 31Мб/с исходящего трафика при 0.5Мб/с входящего. То есть, обнаруженных 69 устройств могут сгенерировать поток в 2 Гб/с и значительно нагрузить сеть оператора.
        Весь паразитный трафик на моем открытом рекурсивном DNS (см. предыдущую статью) генерировался только 3 доменами: webpanel.sk, energystar.gov и doleta.gov.

        Блокирование данных доменов с помощью RPZ (я использовал для ответа NODATA) позволило снизить нагрузку на сеть, так как размер запроса практически совпадает с размером ответа сервера. Проведение атаки стало бессмысленным.

    Блокирование доступа по списку запрещённых сайтов


        Блокировка доступа к доменам по спискам запрещенных сайтов полезна как для предприятий, так и для интернет провайдеров. С ограничениями доступа внутри предприятий всё тривиально и каких-либо проблем в реализации не возникает. Не следует забывать, что нужно заблокировать доступ пользователей к публичным DNS.
        Провайдеры же могут использовать RPZ для исполнения ФЗ, так как не у всех есть возможность пропускать трафик через DPI, а блокирование доступа по IP чревато потерей лояльности абонентов. В этом случае ограничения реализуются таким образом:
    1. Реестр запрещенных сайтов разделяется на 2 группы:
      • Ограничения накладываемые на целый домен;
      • Ограничения накладываемые на определенный раздел сайта;
    2. Сайты попадающие под блокирование целого домена прописываются в зоне PRZ;
    3. Маршрутизация к оставшимся сайтам прописывается таким образом, чтобы пакеты проходили или через DPI или через Proxy-сервер. В крайнем случае, можно осуществить блокировку через IP.

    Перенаправление пользователей на локальные ресурсы


        Помимо простого блокирования доступа к ресурсам (NXDOMAIN, NODATA, DROP) можно изменять ответ DNS-сервера. Такое изменение ответов может потребоваться, например:
    • для предупреждение пользователей, что их компьютеры заражены malware, botnet-агентами или при обращении к сайтам, которые распространяют вредоносное ПО. Дополнительно провайдеры могут показать рекламу антивируса, а администраторы на предприятиях указать телефон и email IT-службы;
    • для предупреждение пользователей, что данный ресурс заблокирован. Провайдеры могут указать причину блокировки (ФЗ), а для корпоративных пользователей можно вывести список заблокированных доменов и образец заявления по собственному желанию (для несогласных) ;
    • перенаправление пользователей на локальные ресурсы или локальные (серые) IP-адреса серверов (пример приведен в этой хабра-статье).

    Настройка RPZ на BIND 9.10


        Для эффективного использования RPZ все DNS запросы должны приходить только на ваш DNS. Это можно достичь двумя способами:
    • блокировать доступ к другим DNS;
    • автоматически перенаправлять все запросы на DNS с включенным механизмом RPZ.
        Приведенная ниже конфигурация корректна для версии BIND 9.10, в предыдущих версиях нет команд drop и tcp-only, ограничений по адресу клиента и DNS-сервера.
        1. Первоначально необходимо определить список RZP-зон и их параметры выражением response-policy.

    response-policy {zone "whitelist" policy passthru; zone "badlist" policy disabled;};

        Bind проверяет запрос по RPZ в соответствии с определенным в responce-policy порядком зон. Наиболее важным является дополнительный параметр policy, который позволяет переопределить правила отработки запросов указанных на уровне зоны. Этот параметр может принимать следующие значения:
    • given – выполняются действия определенные в зоне (значение по умолчанию);
    • disabled – зона отключена;
    • passthru – ответ DNS-сервера не модифицируется, но попадание в зону отражается в лог-файлах;
    • drop – сервер игнорирует запрос (не отвечает);
    • nxdomain – сервер отвечает NXDOMAIN (не существующий домен);
    • nodata – сервер отвечает NODATA (нет записи);
    • tcp-only – отсылается обрезанное сообщение, что вынуждает клиента выполнить запрос по TCP (защита от DrDoS);
    • cname domain-name – сервер переписывает все ответы на указанный домен.

        2. Затем определить список зон, используя стандартный формат. Для локальных зон прописываем тип master, для RPZ feed – тип slave.

    zone "badlist" {type master; file "master/badlist"; allow-query {none;}; };

        3. Определяем зону (комментарии по формату в тексте)
    $TTL 1H
    @                  SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
                       NS  LOCALHOST.
    
    ; QNAME policy records.  There are no periods (.) after the owner names.
    nxdomain.domain.com     CNAME   .               ; (.) - возврат NXDOMAIN
    *.nxdomain.domain.com   CNAME   .               ; (.) - возврат NXDOMAIN
    nodata.domain.com       CNAME   *.              ; (*.) - возврат NODATA
    *.nodata.domain.com     CNAME   *.              ; (*.) - возврат NODATA
    bad.domain.com          A       10.0.0.1        ; меняем ответ на нужный
                            AAAA    2001:2::1
    bzone.domain.com        CNAME   garden.example.com.
    
    ok.domain.com           CNAME   rpz-passthru.   ; не делаем изменений
    
    ; меняем зону x.bzone.domain.com на x.bzone.domain.com.garden.example.com
    *.bzone.domain.com      CNAME   *.garden.example.com.
    
    ; Правила блокировки по IP
    8.0.0.0.127.rpz-ip      CNAME   .
    32.1.0.0.127.rpz-ip     CNAME   rpz-passthru.
    
    ; Правила блокировки по имени и IP сервера доменов
    ns.domain.com.rpz-nsdname   CNAME   .
    48.zz.2.2001.rpz-nsip       CNAME   .
    
    ; Блокировка по IP клиента
    112.zz.2001.rpz-client-ip    CNAME   rpz-drop.
    8.0.0.0.127.rpz-client-ip    CNAME   rpz-drop.
    
    ; принуждение клиента запроса зон по TCP
    16.0.0.1.10.rpz-client-ip   CNAME   rpz-tcp-only.
    example.com                 CNAME   rpz-tcp-only.
    *.example.com               CNAME   rpz-tcp-only.
    


    RZP это удобный механизм повышения защищенности сети и ограничения доступа к ресурсам.



    Список источников


    1. dnsrpz.info
    2. www.spamhaus.org/faq/section/ISP%2520Spam%2520Issues#164
    3. www.infosecurity.ru/cgi-bin/mart/arts.pl?a=101219
    4. www.bleepingcomputer.com/virus-removal/cryptolocker-ransomware-information
    5. www.infoblox.com/products/infrastructure-security/dns-firewall
    6. ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.html
    7. www.zytrax.com/books/dns/ch7/rpz.html
    8. www.zytrax.com/books/dns/ch9/rpz.html

    Vadim Pavlov
    UPD1:
    Infoblox предлагает протестировать в пассивном режиме DNS Firewall (RPZ) + Feed.
    Зарегистрироваться и получить доступ можно по этой ссылке: www.infoblox.com/catchmalware
    Для установки требуется VmWare версии 5.0 и выше и vCenter Server.
    Share post

    Similar posts

    Comments 24

      0
      С ботнетами понятно, а что такое «запрещённые сайты»?
        0
        Для провайдеров сайты попавшие в реестр eais.rkn.gov.ru/.
        На корпоративном уровне (это каждая компания решает самостоятельно :), например, социальные сети.
          +1
          Но они же не запрещены, нет? Их всего лишь вносят в нелепый список сайтов, которые кому-то-там напоминают о суициде.
            0
            Они запрещены в РФ на законодательном уровне. Интернет-провайдеры обязаны блокировать доступ к ним.
            Для маленьких операторов (у которых нет больших и жирных DPI) лучше их блокировать не на уровне IP (когда могут пострадать невинных несколько сайтов), а на уровне доменов с помощью RPZ, Proxy, DPI — вреда будет меньше.
              +1
              Обязаны блокировать — не означает, что сайты запрещены. Всякие игры в «да-да, мы блокируем, и даже список скачиваем» касаются только обладателей лицензий. Остальным никаких ограничений или запретов в просмотре этих сайтов нет. Более того, большинство из них даже не запрещено держать. То есть называть их «запрещёнными» (пока что) не правильно. Вносимымыми в список для блокировки — да. Блокируемыми — может быть ( хотя сейчас к русской vds'ке подключился — все работает), но не более.
        0
        Не следует забывать, что нужно заблокировать доступ пользователей к публичным DNS.

        Обоснуйте.
          –3
          А что обосновывать то? Если не заблокировать доступ, то половина пользователей себе пропишут 8.8.8.8 и администратор получит «по шапке».
          Мы же обсуждаем варианты использования, а не методы их обхода :)
            +2
            Если не заблокировать доступ, то половина пользователей себе пропишут 8.8.8.8 и администратор получит «по шапке».


            Вообще-то законом от оператора это не требуется, ну так и зачем вы усложняете жизнь вашим же пользователям?
            Из-за страха «как бы чего не вышло»?

            Тьфу.
              0
              К сожалению, в нашей стране всё работает именно так.
              Поэтому большая часть мелких (а иногда и крупных) операторов не парится и блокирует всё по IP.
                +1
                Это все так работает именно из-за таких излишне инициативных товарищей.
                Никаким законом блокировать днс серверы не требуется и точка.
              +1
              В том и фишка — формально нет причин, как и полномочий блокировать внешние DNS серверы.
              И многие «запреты» и «блокировки» легко обходятся — в этом и заключается глупость подхода властей.
              Если уж надо «надежно заблокировать», то придется блокировать все открытые прокси/анонимайзеры/vpn/google translate/и т.д.
              А если вспомнить, что пользователь может взять vps за 5$ и поднять там openvpn сервер, список для бана увеличивается до размеров всея интернета.
              Вы случаем не корпоративных пользователей ограничиваете?
              Там это ещё как-то оправдано политикой компании и т.д.
                0
                Нет, я вообще не ограничиваю пользователей :) Но данная глава была как раз написана как для корпоративщиков, так и для операторов.
                Я не думаю, что после этой статьи операторы блокирующие доступ по IP массово начнут переходить на использование RPZ.
                Но если Вы настаиваете, то я могу перенести эту фразу «к корпоративной» части главы :)
              • UFO just landed and posted this here
                  –1
                  Акадо много лет блокирует и по шапке ещё не получила (сервис как был закрыт, так и остается закрыт).
              0
              Спасибо за статью!
              Рад, что Вы не бросили эксперимент. На Хабре очень мало практики по этой теме.

              Несколько вопросов/комментариев:

              1) В схеме с fast-flux первый уровень (те узлы, которые крутятся round-robin'ом в A-записях) — всегда proxy до moshership-сервера. В простейшем варианте DNS для такого домена работает на abuse-устойчивом DNS-хостинге. Это называется single-flux. Случай посложнее — double-flux, когда и DNS для домена обслуживают боты (точнее, проксируют на mothership). В этом случае round-robin'ом крутятся еще и NS-записи.

              2) FarSight Security не дают в явном виде фид для блокировки ботнетов. Их Security Information Exchange — сервис не для операторов DNS, а скорее для сервис-провайдеров услуг безопасности, которым нужны «сырые» данные DNS для анализа. Для того, чтобы подключиться к SIE, нужно поставить свою железку в дата-центр FarSight в Калифорнии или Вирджинии. А вот, например, Virus Tracker для операторов DNS гораздо удобнее. Им пользуется Яндекс.DNS для фильтрации ботнет-активности.

              3) С утверждением
              Активность botnet-агентов может приводить к значительному росту нагрузки на кэширующий DNS и канал связи
              готов согласиться только в контексте «Атаки с использованием техники DNS amplification, реализуемые через ботнет-сети, могут приводить ...» :) Просто все, чтобы было выше этой фразы, касалось управления ботами и пресечения каналов связи с C&C-серверами. Эта «активность» ботов не дает большой нагрузки. Вот, например, статистика Яндекса: «Каждый день Яндекс.DNS обрабатывает около семи миллиардов запросов, из них примерно 1,9 миллиона отправляют боты.» 0,03% — это капля в море с точки зрения нагрузки (даже с учетом того, что большая часть этих запросов не попадает в кэш).

              4) В своей предыдущей статье Вы утверждали, что скорее всего атака, которую Вы обнаружили, идет на DNS-сервера этих самых доменов (webpanel.sk, energystar.gov и doleta.gov). И хотя я с этим выводом не согласен (считаю, как минимум 2 из 3 доменов скорее всего использовались для усиления и отражения атаки на другие жертвы), не могу не отметить непоследовательность Ваших действий — если целью атакующего была недоступность ресурсов, которые обслуживают эти DNS-сервера, то включенная Вами фильтрация означает, что атакующий своих целей достиг. Хотя бы на небольшом участке фронта в лице Вашего DNS-сервера :)

              Ну и напоследок — пожелание. Понятно, что ручная правка RPZ-зон — не вариант. Было бы здорово увидеть практику работы с каким-либо из перечисленнных в статье DNSBL-сервисов — процесс подключения к услуге, настройка, статистика по результатам использования.
                0
                Спасибо. Тест мой ещё продолжается, надеюсь ещё будут интересные результаты :)
                1) Я не против, просто для такой небольшой статьи не стал усложнять. Основная цель же была не рассказ про Fastflux. Полную ссылку с описанием забыл добавить :)
                2) Спасибо. Ещё раз проверю.
                3) Да. Это именно так и есть. Но если не будет коммуникаций с C&C, то и не будет атаки. И мне кажется, что статистика Яндекса тут менее интересна, по сравнению со статистикой операторов, так как на них приходит первый «удар».
                Круглый стол от Яндекса в тему:
                tech.yandex.ru/events/yac/2013/talks/1135/
                4) По сравнению с предыдущей статьей я немного переосмыслил результаты :) Относительная нагрузка на мой сервер была небольшая до 5Мб/с (сервер имеет Гигабитный uplink), но с учетом того, что она выросла в 3 раза за несколько минут, я решил не дожидаться дальнейшего усиления атаки и рисковать отключением от Hetzner :)
                  0
                  По поводу FarSight Security я имел в виду NOD, вот описание с их сайта:
                  NOD is also published in DNSBL and RPZ formats. Many network defense products are directly capable of ingesting and acting upon policy information in the supported «rbldnsd» format (for NOD DNSBL) or in IETF «zone file format» (for NOD RPZ). Farsight updates our NOD distribution files very frequently owing to the importance of timeliness in this data feed. Customers are advised to check for updates once a minute, noting that «rsync» is extremely efficient and will use very little network bandwidth even when executed frequently. Note that Farsight expects to announce AXFR/IXFR/NOTIFY support for the NOD DNSBL and NOD RPZ distributions at a later time.
                  Я с ними не связывался, но предположил, что они дают свой RPZ.

                  По поводу Virus Tracker — не обнаружил ни слова про RPZ и описания алгоримов их работы. Может они предоставляют списки доступа для маршрутизаторов/файрволов?
                    0
                    NOD отдает новые, ранее неизвестные домены. Фильтровать их в DNS только потому, что они новые — не очень разумно.

                    У Virus Tracker нет выдачи в RPZ. У него есть API для доступа к данным (правда, только на двух верхних тарифах), с помощью которого можно получать сырые данные и на основании их формировать политики фильтрации в том виде, в котором это удобнее вашему инструменту.
                      0
                      Спасибо за разъяснения. FarSight — удалю.
                  0
                  Если я правильно понял, у вас много ручного труда — вы должны мониторить, какие домены пытаются резолвить через ваш DNS.
                  С появлением нового домена у атакующих, через ваш DNS становится возможна атака.
                  Если вы спите/на даче/в отпуске, ваш DNS может использоваться для амплификации несколько часов.
                    0
                    Любую задачу можно разумным образом автоматизировать :)
                  • UFO just landed and posted this here
                      0
                      На маршрутизаторе стоковая прошивка, поменять нет возможности.
                      А большинство пользователей вообще не знаю что это такое :)
                      • UFO just landed and posted this here

                    Only users with full accounts can post comments. Log in, please.