Защищаем DNS: DNSSec, шифрование и анонимность

https://t.me/w2hack

И так, сегодня в статье небольшие размышления на тему защиты DNS (корпоративного и в целом для Интернета) и сохранения собственной анонимности. И так, поехали!

DNSSec как технология защищенного DNS

Введение

DNSSEC (Domain Name System Security Extensions) — набор расширений IETF протокола DNS, позволяющих минимизировать атаки, связанные с подменой DNS-адреса при разрешении доменных имён (еще одни пример тут). Он направлен на предоставление DNS-клиентам (resolver) аутентичных ответов на DNS-запросы (или аутентичную информацию о факте отсутствия данных) и обеспечение их целостности. При этом используется криптография с открытым ключом, но при этом же не обеспечивается доступность данных и конфиденциальность самих запросов.

Как это работает (теория)

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

Особенность состоит в том, что DNSSec использует два типа ключей — одним подписывается зона (ZSK, zone signing key), другим подписывается набор ключей (KSK, key signing key). Сделано это из таких соображений: зона может быть достаточно большой чтобы удалось подобрать закрытый ключ, поэтому его надо менять почаще, да и сделать его можно покороче, чтобы зоны подписывались быстрее; KSK же используется для небольших объемов данных, поэтому его можно и подлиннее сделать и менять пореже. Тем более, что хэш от открытой части KSK требуется отправить в родительскую зону, что хотелось бы делать не слишком часто.

Механизм работы на абстрактном примере

Допустим мы хотим узнать адрес test.bar.example.com:

Мы запрашиваем доменное имя у резолвера;
Резолвер выставляет бит DO и запрашивает test.bar.example.com у корневого сервера;
Резолвер знает, что корневая доменная зона подписана — у него указан ключ или хэш ключа для нее (так называемый trust-anchor), поэтому он запрашивает у корневого сервера DNSKEY записи для корневой зоны и сверяет полученное с имеющимся;
Корневой сервер не знает такого доменного имени, да и вообще максимум что ему известно — на каких серверах располагается зона com, он и сообщает адреса этих серверов нашему резолверу вместе с подписанной DS записью для зоны com;
Резолвер валидирует DS запись полученным и проверенным ZSK ключом корневой зоны;
Теперь резолвер знает, что зона com подписана, так что он спрашивает у ее DNS сервера DNSKEY и валидирует их, после чего интересуется про bar.example.com. Естественно, что сервер зоны com про таких не знает, ему только известно, что зона example.com живет на ns.example.com и ns1.example.com, именно это он и отвечает резолверу вместе с — да-да — DS записью;
Так резолвер выстроил цепочку доверия до example.com, где он узнает серверы имен зоны bar.example.com и ее DS;
В конце концов резолвер итеративно узнает адреса DNS серверов, отвечающих за bar.example.com, идет к ним и наконец-то получает желаемое, валидирует всю информацию и отдает нам адресную запись, выставив в ответе бит AD.

Для чего вообще юзать DNSSec?

Сначала о проблемах которые порождает DNSSec:

во-первых, требуется организовать надежное хранилище для ключей;

в-вторых, необходимо постоянно следить за ротацией ключей;

в-третьих, опять же нужно следить за сроком истечения срока действия подписей;

в-четвертых, DNSSec усиливает эффект amplified ddos.

Все это является платой за то, чтобы быть уверенным в информации, получаемой от авторитетных DNS серверов. По сути это некий шит против фишинга, малварьных атак, атак с использованием DNS как протокола интернета.

Практика

Описание настройки DNSSec для серверов под управлением Windows Server и Linux не входят в рамки нашей статьи, да и вообще все эти "админские манипуляции" больше имеют отношению к администрированию чем к искусству хакерства. Поэтому я ниже приведу пример настроек DNSSec для указанных платформ в виде ссылок на отдельные пошаговые инструкции:

1) Примеры самих настроек DNSSec на базе BIND для Linux (CentOS и Ubuntu)

2) Настройка DNSSec для Windows Server 2012

Шифруем собственный трафик с помощью DNSCrypt

Все кто юзают сервсы приватности как VPN, TOR или даже Tails наверняка думают, что надежно защищены от посторонних глаз. Но к сожалению это не всегда так. Существует один очень важный канал утечки вашей приватной информации – служба DNS. Но, к счастью, на это тоже есть решение. И сегодня я расскажу вам как зашифровать свой DNS трафик с помощью утилиты DNSCrypt.

При использовании HTTPS или SSL твой HTTP трафик зашифрован, то есть защищен. Когда ты используешь VPN, шифруется уже весь твой трафик (конечно, все зависит от настроек VPN, но, как правило, так оно и есть). Но иногда, даже когда используется VPN, твои DNS-запросы не зашифрованы, они передаются как есть, что открывает огромное пространство для «творчества», включая MITM-атаки, перенаправление трафика и многое другое.

Тут на помощь приходит опенсорсная утилита DNSCrypt, разработанная хорошо известными тебе создателями OpenDNS, — программа, позволяющая шифровать DNS-запросы. После ее установки на компьютер твои соединения также будут защищены и ты сможешь более безопасно бороздить просторы интернета. Конечно, DNSCrypt — это не панацея от всех проблем, а только одно из средств обеспечения безопасности. Для шифрования всего трафика все еще нужно использовать VPN-соединение, но в паре с DNSCrypt будет безопаснее. Если тебя такое краткое объяснение устроило, можешь сразу переходить к разделу, где я буду описывать установку и использование программы.

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

Допустим, клиент (ноутбук на рисунке) пытается обратиться к google.com Первым делом он должен разрешить символьное имя узла в IP-адрес. Если же конфигурация сети такова, что используется DNS-сервер провайдера (незашифрованное соединение, красная линия на рисунке), то разрешение символьного имени в IP-адрес происходит по незашифрованному соединению.

Да, какие данные ты будешь передавать на dkws.org.ua, никто не узнает. Но есть несколько очень неприятных моментов. Во-первых, провайдер, просмотрев логи DNS, сможет узнать, какие сайты ты посещал. Тебе это нужно? Во-вторых, вероятна возможность атак: DNS спуфинг и DNS снупинг. Подробно описывать их не буду, об этом уже написано множество статей. В двух словах ситуация может быть следующей: некто между тобой и провайдером может перехватить DNS-запрос (а так как запросы не шифруются, то перехватить запрос и прочитать его содержимое не составит никакого труда) и отправить тебе «поддельный» ответ. В результате вместо того, чтобы посетить google.com, ты перейдешь на сайт злоумышленника, как две капли воды похожий на тот, который тебе нужен, введешь свой пароль от форума, ну а дальше развитие событий, думаю, ясно.

Описанная ситуация называется DNS leaking («утечка DNS»). DNS leaking происходит, когда твоя система даже после соединения с VPN сервером или Tor продолжает запрашивать DNS серверы провайдера для разрешения доменных имен. Каждый раз, когда ты посещаешь новый сайт, соединяешься с новым сервером или запускаешь какое-то сетевое приложение, твоя система обращается к DNS провайдера, чтобы разрешить имя в IP. В итоге твой провайдер или любой желающий, находящийся на «последней миле», то есть между тобой и провайдером, может получить все имена узлов, к которым ты обращаешься. Приведенный выше вариант с подменой IP-адреса совсем жестокий, но в любом случае есть возможность отслеживать посещенные тобой узлы и использовать эту информацию в собственных целях.

Если ты «боишься» своего провайдера или просто не хочешь, чтобы он видел, какие сайты ты посещаешь, можешь (разумеется, кроме использования VPN и других средств защиты) дополнительно настроить свой компьютер на использование DNS серверов проекта OpenDNS (www.opendns.com).

На данный момент это следующие серверы:

87.98.175.85 (ns10.fr): 99.74% uptime
130.255.73.90 (ns3.nw.de): 97.45% uptime

При этом тебе не нужно никакое другое дополнительное программное обеспечение. Просто настрой свою систему на использование этих DNS-серверов.

Но все равно остается проблема перехвата DNS-соединений. Да, ты уже обращаешься не к DNS провайдера, а к OpenDNS, но все еще можно перехватить пакеты и посмотреть, что в них. То есть при желании можно узнать, к каким узлам ты обращался.

Вот мы и подошли к DNSCrypt. Эта программулина позволяет зашифровать твое DNS соединение. Теперь твой провайдер (и все, кто между тобой и им) точно не узнает, какие сайты ты посещаешь! Еще раз повторюсь. Эта программа не замена Tor или VPN. По-прежнему остальные передаваемые тобой данные передаются без шифрования, если ты не используешь ни VPN, ни Tor. Программа шифрует только DNS трафик.

DNS LEAK

Сайт http://dnsleak.com/ позволяет определить «утечку» DNS. Просто зайди на этот сайт. Нажав кнопку Check for DNS leaks now, ты получишь список DNS-серверов, через которые могут проходить твои запросы. Следовательно, ты увидишь, кто именно может узнать, какие сайты ты посещаешь.

УСТАНОВКА И ИСПОЛЬЗОВАНИЕ DNSCRYPT

Самый простой способ защитить свое DNS соединение — это использовать DNSCrypt.

Первым делом качаем сам DNSCrypt с GitHub. Чтобы скачать программу с GitHub, нажми кнопку Download ZIP. Будет загружен архив с исходниками DNSCrypt. Уже откомпилированная версия находится в каталоге DNSCrypt архива. Распакуй файлы. В принципе тебе нужен только один файл — dnscrypt-proxy.exe. Он находится в том самом каталоге. Все остальное (исходники) можно удалить.

Но это еще не все. Если ты уже погуглил, то, значит, видел скриншоты DNSCrypt. Запустив dnscrypt-proxy.exe, ты понял, что что-то не то. Программа запустилась в окне командной строки. Все правильно, ты скачал сам прокси, а теперь еще нужно скачать к нему оболочку. На GitHub есть еще один проект — необходимая нам оболочка (https://github.com/Noxwizard/dnscrypt-winclient).

Аналогичным образом скачай ZIP-архив, распакуй его куда-нибудь. В каталоге binaries/Release/ будет программа dnscrypt-winclient.exe. Скопируй этот файл в каталог, в котором находится файл dnscrypt-proxy.exe.

Осталось только запустить dnscrypt-proxy.exe. В появившемся окне выбери сетевые адаптеры, которые нужно защитить, и нажми кнопку Start. Если все нормально, тогда возле кнопки Stop (в нее превратится кнопка Start) появится надпись DNSCrypt is running.

Еще один вариант защита - DNS-over-TLS

Другим более современным способом защиты DNS трафика явился протокол DNS-over-TLS описанный в стандарте RFC7858, который представляет собой инкапсуляцию данных в стандартный TLS. Для доступа рекомендуется использовать порт 853.

Также как и в случае с DNScrypt предполагается, что клиент DNS, каковым обычно выступает тот же локальный кэширующий DNS, обращается к поддерживающим DNS-over-TLS удалённым серверам (см. актуальный список).

Вышеупомянутый Unbound имеет встроенную поддержку данного протокола, поэтому никакой дополнительной программной прослойки для использования, как это было в случае с DNScrypt, не требуется.

Unbound как клиент DNS-over-TLS

Для работы в качестве клиента DNS-over-TLS Unbound требует лишь список серверов в той же секции forward-zone файла конфигурации.

root@my:~ # cat /usr/local/etc/unbound/unbound.conf
server:
...
forward-zone:
        name: "."
        # Quad9
        forward-addr: 9.9.9.9@853
        forward-addr: 2620:fe::fe@853
        ...
        forward-ssl-upstream: yes
...

Unbound как сервер DNS-over-TLS

Не составлят труда и настройка Unbound в качестве сервера обслуживающего DNS-over-TLS запросы. Для этого можно использовать уже имеющиеся сертификаты TLS, например от Let's Encrypt.

root@my:~ # cat /usr/local/etc/unbound/unbound.conf
server:
...
        interface: 127.0.0.1
        interface: ::1
        interface: 0.0.0.0@853
        interface: ::0@853
        tls-service-key: "/usr/local/etc/letsencrypt/live/my.domain/privkey.pem"
        tls-service-pem: "/usr/local/etc/letsencrypt/live/my.domain/cert.pem"
        tls-port: 853
...

В данном случае Unbound по умолчанию обслуживает стандартные нешифрованные DNS запросы на локальном интерфейсе 127.0.0.1 и ::1, однако в данном случае понадобилось это указать в конфигурации в явном виде. Теперь также он доступен и для внешних запросов доступен исключительно по протоколу DNS-over-TLS на порту 853.

root@my:~ # sockstat -46 | grep unbound
unbound  unbound    18533 3  udp4   127.0.0.1:53          *:*
unbound  unbound    18533 4  tcp4   127.0.0.1:53          *:*
unbound  unbound    18533 5  udp6   ::1:53                *:*
unbound  unbound    18533 6  tcp6   ::1:53                *:*
unbound  unbound    18533 7  udp4   *:853                 *:*
unbound  unbound    18533 8  tcp4   *:853                 *:*
unbound  unbound    18533 9  udp6   *:853                 *:*
unbound  unbound    18533 10 tcp6   *:853                 *:*

ЗАКЛЮЧЕНИЕ

VPN-провайдер предоставит тебе безопасный туннель для передачи твоих данных, а DNSCrypt обеспечит защиту DNS-соединений. Конечно, услуги VPN провайдеров платны, но ведь за безопасность нужно платить?

Можно использовать, конечно, и Tor, но Tor работает относительно медленно, и это, как ни крути, не VPN — весь трафик «торифицировать» не получится. В любом случае (какой бы вариант ты ни выбрал) теперь твои DNS-соединения защищены. Осталось только определиться со средством шифрования трафика (если ты это еще не сделал).