Установка Unbound в качестве DNSSEC-клиента в ОС Debian-based с переадресацией ДНС-запросов через DNSCrypt для защиты от подмены ДНС адреса сводится к выполнению всего нескольких простых шагов: собственно сама установка и последующая правка resolv.conf.
Сей пост посвященный криптографической защите DNS-трафика по сути является продолжением темы "паранойи много не бывает". Кругом враги и глобальные заговоры злых соседей, государства и транснациональных корпораций. Кто-то скажет пора лечится и я полностью соглашусь, но некогда имхо врагов который год всё не убывает, а значит нужно усиливать меры безопасности, ведь они идут, они заполоняют...
Итак... DNSSEC (ака Domain Name System Security Extensions) — это набор расширений безопасности системы доменных имён (протокола DNS), которые позволяют обеспечить целостность DNS-запросов между клиентом и сервером с использованием криптографии с открытым ключом.
Зачем нужен DNSSEC?
Служба доменных имен (DNS) нужна для того, чтобы облегчить пользователям запоминание адресов веб-ресурсов, ведь проще запомнить имя сайта чем его цифровой ИП-адрес. Далеко не каждому пользователю Интернетоф известно, что одному доменному имени может быть присвоено несколько ИП-адресов, что обеспечивает отказоустойчивость веб-ресурсам, для которых 100% аптайм является критически важным критерием, примером может быть ПС yandex.ru:
$ nslookup yandex.ru
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: yandex.ru
Address: 5.255.255.55
Name: yandex.ru
Address: 77.88.55.66
Name: yandex.ru
Address: 5.255.255.5
Name: yandex.ru
Address: 77.88.55.55Выше приведён список валидных ИП-адресов для ПС yandex.ru. Теперь предположим, что на нашем канале связи висит туева хуча спец. служб, которая хочет закинуть нашей машине различного "пакращення", и мы значит вбиваем в строку своего браузера доменное имя yandex.ru, а злые люди подменяют приведённый выше список ИП на ИП своего бацыльного сервера на котором висит фейковая поисковая система с элементами социальной инженерии, клюнув на которую мы широко развесив ухи "сдаем" все свои явки и пароли дополнительно получая при этом кучу всяких доселе ещё никому неизвестных вирусов и троянов, - поздравляю вам пи.дец :)
Вот именно для защиты от подмены этих самых ИП-адресов, подмена которых чревата упомянутыми выше лулзами, и призван DNSSEC.
Установка Unbound в Debian-based ОС
Мы не доверяем нашему ISP и потому просто выполняем:
apt-get install unbound unbound-anchorПроверяем состояние сервиса unbound:
# systemctl status unbound -l ● unbound.service - (null) Loaded: loaded (/etc/init.d/unbound) Drop-In: /run/systemd/generator/unbound.service.d └─50-insserv.conf-$named.conf, 50-unbound-$named.conf Active: active (running) since Чт 2015-10-29 08:45:16 EET; 57s ago CGroup: /system.slice/unbound.service └─28210 /usr/sbin/unbound окт 29 08:45:15 falian unbound-anchor[28207]: /var/lib/unbound/root.key has content окт 29 08:45:15 falian unbound-anchor[28207]: success: the anchor is ok окт 29 08:45:16 falian unbound[28210]: [28210:0] notice: init module 0: validator окт 29 08:45:16 falian unbound[28210]: [28210:0] notice: init module 1: iterator окт 29 08:45:16 falian unbound[28210]: [28210:0] info: start of service (unbound 1.4.22). окт 29 08:45:16 falian unbound[28200]: Starting recursive DNS server: unbound.
Правим resolv.conf:
vi /etc/resolv.conf or vi /etc/resolvconf/resolv.conf.d/head #nameserver 8.26.56.26 #nameserver 8.20.247.20 #nameserver 8.8.8.8 #nameserver 8.8.4.4 nameserver 127.0.0.1 resolvconf -u
Проверяем DNSSEC по наличию флага "ad" и записи "RRSIG" в результате выполнения dig com. SOA +dnssec:
$ dig com. SOA +dnssec ; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> com. SOA +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17068 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;com. IN SOA ;; ANSWER SECTION: com. 577 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1446101237 1800 900 604800 86400 com. 577 IN RRSIG SOA 8 1 900 20151105074717 20151029053717 51797 com. oo4o1US7CPYmkmSYoEqC0wPN2vFpxXJTgUn/MIBvP4PiRS64ZjCLNLtr Vd35ebK07XvqYJMVWSvSyL7pK7b3jqiOmwBKCT1K7+HVLS362H4mwvjS JFW9C6+eC4FHxPSnOpxuIfDshgc5lhGHHq7pCbeOVxHrUgrAP7a7bZyV cX4= ;; AUTHORITY SECTION: com. 161505 IN NS d.gtld-servers.net. com. 161505 IN NS b.gtld-servers.net. com. 161505 IN NS k.gtld-servers.net. com. 161505 IN NS f.gtld-servers.net. com. 161505 IN NS a.gtld-servers.net. com. 161505 IN NS h.gtld-servers.net. com. 161505 IN NS i.gtld-servers.net. com. 161505 IN NS c.gtld-servers.net. com. 161505 IN NS m.gtld-servers.net. com. 161505 IN NS e.gtld-servers.net. com. 161505 IN NS l.gtld-servers.net. com. 161505 IN NS j.gtld-servers.net. com. 161505 IN NS g.gtld-servers.net. com. 161505 IN RRSIG NS 8 1 172800 20151104055508 20151028034508 51797 com. DXj9YJiiWPCKHnY69NnAj4gzbP9FpY1gpW+JfQHU5gdT2UEXz0JcJpCE VoMs3VyzHmb+j4QNZmk+PbGwyBl8LAVZ4UQFrV899IKQjIYaOeUdPJQe 9FV805QOvZQ7uk3f6xlpTzkvHHFqf1OzbMka6Ho+ILG415Z0n9Fj5W71 N5U= ;; Query time: 194 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Oct 29 08:52:46 EET 2015 ;; MSG SIZE rcvd: 637
Конфигурационные файлы unbound:
/etc/default/unbound /etc/unbound/unbound.conf /etc/unbound/unbound.conf.d/ /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf --- less /etc/unbound/unbound.conf # Unbound configuration file for Debian. # # See the unbound.conf(5) man page. # # See /usr/share/doc/unbound/examples/unbound.conf for a commented # reference config file. # # The following line includes additional configuration files from the # /etc/unbound/unbound.conf.d directory. include: "/etc/unbound/unbound.conf.d/*.conf" --- less /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf server: # The following line will configure unbound to perform cryptographic # DNSSEC validation using the root trust anchor. auto-trust-anchor-file: "/var/lib/unbound/root.key"
Владельцем ключа "/var/lib/unbound/root.key" является пользователь "unbound", от имени которого также работает и сам сервис unbound.
Ключ "/var/lib/unbound/root.key" должен регулярно обновляться, что с успехом автоматически выполняет скрипт управления демоном "/etc/init.d/unbound" в момент старта/запуска/перезапуска и никаких дополнительных манипуляций не требует.
Настройка Unbound в Debian-based ОС
Кого устраивает конфигурация по умолчанию, умолчания смотрите в файле /usr/share/doc/unbound/examples/unbound.conf, то можно пропустить сей конфиг. Нам лично умолчания не подходят и потому конфиг /etc/unbound/unbound.conf мы допиливаем до такой кондиции:
vi /etc/unbound/unbound.conf ## Authoritative, validating, recursive caching DNS # See /usr/share/doc/unbound/examples/unbound.conf for a commented # reference config file. ## unbound.conf -- http://www.remoteshaman.com # server: # File with trusted keys, kept uptodate using RFC5011 probes, # initial file like trust-anchor-file, then it stores metadata. # Use several entries, one per domain name, to track multiple zones. # # If you want to perform DNSSEC validation, run unbound-anchor before # you start unbound (i.e. in the system boot scripts). And enable: # Please note usage of unbound-anchor root anchor is at your own risk # and under the terms of our LICENSE (see that file in the source). # # The following line will configure unbound to perform cryptographic # DNSSEC validation using the root trust anchor. auto-trust-anchor-file: "/var/lib/unbound/root.key" interface: 0.0.0.0 interface: ::0 # port to answer queries from port: 53 # Enable IPv4, "yes" or "no". do-ip4: yes # Enable IPv6, "yes" or "no". do-ip6: no # Enable UDP, "yes" or "no". do-udp: yes # Enable TCP, "yes" or "no". If TCP is not needed, Unbound is actually # quicker to resolve as the functions related to TCP checks are not done.i # NOTE: you may need tcp enabled to get the DNSSEC results from *.edu domains # due to their size. do-tcp: yes # control which clients are allowed to make (recursive) queries # to this server. Specify classless netblocks with /size and action. # By default everything is refused, except for localhost. # Choose deny (drop message), refuse (polite error reply), # allow (recursive ok), allow_snoop (recursive and nonrecursive ok) # deny_non_local (drop queries unless can be answered from local-data) # refuse_non_local (like deny_non_local but polite error reply). #access-control: 0.0.0.0/0 refuse #access-control: ::0/0 refuse #access-control: 127.0.0.0/8 allow #access-control: ::1 allow #access-control: ::ffff:127.0.0.1 allow #access-control: 10.0.0.0/16 allow #access-control: 192.168.0.0/16 allow #access-control: 192.168.0.0/16 allow # enable remote-control #remote-control: #control-enable: yes # enable to not answer id.server and hostname.bind queries. hide-identity: yes # enable to not answer version.server and version.bind queries. hide-version: yes # Will trust glue only if it is within the servers authority. # Harden against out of zone rrsets, to avoid spoofing attempts. # Hardening queries multiple name servers for the same data to make # spoofing significantly harder and does not mandate dnssec. harden-glue: yes # the time to live (TTL) value lower bound, in seconds. Default 0. # If more than an hour could easily give trouble due to stale data. cache-min-ttl: 3600 # the time to live (TTL) value cap for RRsets and messages in the # cache. Items are not cached for longer. In seconds. cache-max-ttl: 86400 # perform prefetching of close to expired message cache entries. # If a client requests the dns lookup and the TTL of the cached hostname # is going to expire in less than 10% of its TTL, unbound will (1st) # return the ip of the host to the client and (2nd) pre-fetch the dns # request from the remote dns server. This method has been shown to # increase the amount of cached hits by local clients by 10% on average. prefetch: yes # number of threads to create. 1 disables threading. # This should equal the number of CPU cores in the machine. num-threads: 1 # the amount of memory to use for the RRset cache. # plain value in bytes or you can append k, m or G. default is "4Mb". #rrset-cache-size: 4m # the amount of memory to use for the message cache. # plain value in bytes or you can append k, m or G. default is "4Mb". #msg-cache-size: 4m # Uncoment if you wish use Unbound through dnscrypt-proxy # http://dnscrypt.org/#dnscrypt-proxy #do-not-query-localhost: no # Use the following forward-zone to forward all queries to Google DNS, # OpenDNS.com or your local ISP's dns servers for example. # To test resolution speeds use "drill calomel.org @8.8.8.8" # and look for the "Query time:" in milliseconds. # forward-zone: name: "." forward-addr: 8.26.56.26 # Comodo DNS forward-addr: 8.20.247.20 # Comodo DNS forward-addr: 8.8.8.8 # Google Public DNS forward-addr: 8.8.4.4 # Google Public DNS #forward-addr: 74.82.42.42 # Hurricane Electric #forward-addr: 4.2.2.4 # Level3 Verizon # # Uncoment if you wish use Unbound through dnscrypt-proxy # http://dnscrypt.org/#dnscrypt-proxy #forward-addr: 127.0.0.1@40 # dnscrypt-proxy #forward-addr: 127.0.0.1@41 # dnscrypt-proxy # # ## Authoritative, validating, recursive caching DNS ## unbound.conf -- http://www.remoteshaman.com
Защитим файл конфигурации от изменений: chattr +i /etc/unbound/unbound.conf
Проходим тест здесь или здесь или установим плагин DNSSEC Validator для браузера Firefox. DNSSEC Validator для браузера Firefox использует DANE протокол.
Вот и всё, теперь мы как минимум на 90-98% защищены от подмены ДНС адреса, но только при условии если на ДНС сервере, на котором размещён домен имеется расширение DNSSEC и домен подписан.
Например, если мы запросим данные о домене dnssectest.sidnlabs.nl, на котором мы проверяли наш ДНС-ресолвер, то увидим запись с подписью (ака RRSIG):
$ dig dnssectest.sidnlabs.nl. SOA +dnssec ; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> dnssectest.sidnlabs.nl. SOA +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1529 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dnssectest.sidnlabs.nl. IN SOA ;; ANSWER SECTION: dnssectest.sidnlabs.nl. 3280 IN CNAME check.sidnlabs.nl. dnssectest.sidnlabs.nl. 3280 IN RRSIG CNAME 8 3 3600 20151115063544 20151016061750 20853 sidnlabs.nl. rugYHypBs7h+StBzVOmbilncuCdGWwSCVw5SuIT+X+hVeYuWqDwr01Qq bVtdXvrKVJqr1+ehgG8zoGW2Oap9YH2mVR32sgIdQ7o2vHV5j8r6nNY3 PgxRC3B9hx2IUe2iTrVuhfeE6StUZtG03MTL9jR12ePnNXCF3m6AlPeA zXs= ;; AUTHORITY SECTION: sidnlabs.nl. 3600 IN SOA proteus.sidnlabs.nl. hostmaster.sidn.nl. 1032 14400 3600 604800 300 sidnlabs.nl. 3600 IN RRSIG SOA 8 2 3600 20151129172753 20151030162753 20853 sidnlabs.nl. uPqqbk3Rrq4KLTYu4sLVMq65SAMYT8yDO+r18znoenY4aEf7ys+zcmlg ZYLpS0phtCrT4tTQPAR2fP2xTU+9xtY0lHou222lavvKjDqxPW9oI/lR 3ntvSiLupYj+mQniM3cJGwuWLgeoj5IgUEkOjBb9jWu0sI9xFUFsr4RJ QDg= check.sidnlabs.nl. 3600 IN NSEC _443._tcp.check.sidnlabs.nl. A AAAA LOC RRSIG NSEC check.sidnlabs.nl. 3600 IN RRSIG NSEC 8 3 300 20151127045551 20151028044515 20853 sidnlabs.nl. k0L4RnGaZG5Lnvi9EEtVKOXhTgmxDV+FIg1vt30F8FEdanLOxFkZocvo B00Us441fDPBJly4uN+CRM9+tkykTTjL+ZaBh7x6Kaeb/9+aByAqU/xZ yshEALGew3jPZGfOC+5F3eREP1RdOT14XLdyR8Gvvli3BPhuYu+X2PYf vb8= ;; Query time: 90 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Oct 31 03:21:47 EET 2015 ;; MSG SIZE rcvd: 693
Но запросив данные о google.com этой подписи мы не обнаружим, а следовательно надеяться на целостность ДНС-запроса мы не можем:
$ dig google.com. SOA +dnssec ; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> google.com. SOA +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23487 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;google.com. IN SOA ;; ANSWER SECTION: google.com. 3281 IN SOA ns1.google.com. dns-admin.google.com. 106735125 900 900 1800 60 ;; AUTHORITY SECTION: google.com. 345281 IN NS ns1.google.com. google.com. 345281 IN NS ns3.google.com. google.com. 345281 IN NS ns2.google.com. google.com. 345281 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 254394 IN A 216.239.32.10 ns3.google.com. 262611 IN A 216.239.36.10 ns2.google.com. 254693 IN A 216.239.34.10 ns4.google.com. 292135 IN A 216.239.38.10 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Oct 31 03:26:16 EET 2015 ;; MSG SIZE rcvd: 221
Из приведённого выше слудет, что DNSSEC является хорошим способом обеспечения безопасности и шифрования ДНС-запросов. Для запуска DNSSEC в глобальном масштабе, необходимо подписать корневые зоны (.com .org etc), что было сделано уже в 2010 году, SU была подписана в октябре 2011 года, зоны РФ и RU в конце 2012 года. Дальнейшее же продвижение DNSSEC зависит от компаний, обслуживающих авторитарные DNS сервера в своих зонах - регистраторов и хостеров. Однако, в силу того, что до сих пор ещё не на всех ДНС серверах используется DNSSEC, надеяться на шифрование всех ДНС-запросов без исключения не приходится ибо ДНС-провайдеры плевать хотели на DNSSEC. Поддержку DNSSEC на своих кеширующих DNS серверах также должны реализовать и Интернет-провайдеры.
Параноикам же экстра класса пока необойтись без полной криптографической защиты DNS-трафика с поддержкой DNSSEC включительно, которую можно заполучить с помощью DNSCrypt.
Установка DNSCrypt в Debian-based ОС
На странице "DNSCrypt - Official Project Home Page" сказано, что для большинства модерновых/современных Linux/BSD систем существуют готовые установочные пакеты, а для иных систем предлагается компиляция dnscrypt-proxy source code и единственной зависимостью для компиляции требуется библиотека libsodium.
В Debian Jessie пакет dnscrypt-proxy отсутствует, однако есть dnscrypt-proxy в SID. Библиотека libsodium есть для Debian Jessie, поэтому из репозитория установим только libsodium, а dnscrypt-proxy скомпилируем самостоятельно:
# apt-get install libsodium13 # ldconfig # cd /opt # wget http://download.dnscrypt.org/dnscrypt-proxy/dnscrypt-proxy-1.6.0.tar.gz # tar -zxf dnscrypt-proxy-*.tar.gz && rm -rf dnscrypt-proxy-*.tar.gz # cd dnscrypt-proxy-* # ./autogen.sh ... Cant exec "libtoolize": Нет такого файла или каталога at /usr/share/autoconf/Autom4te/FileUtils.pm line 345, <GEN7> line 5. autoreconf: failed to run libtoolize: Нет такого файла или каталога autoreconf: libtoolize is needed because this package uses Libtool # apt-get install build-essential libtool # ./autogen.sh # ./configure --help # ./configure --prefix=/opt/dnscrypt ... configure: error: libsodium >= 0.7.0 not found # ln -s /usr/lib/i386-linux-gnu/libsodium.so.13 /usr/lib/i386-linux-gnu/libsodium.so # ./configure --prefix=/opt/dnscrypt # make ... make[4]: вход в каталог «/opt/dnscrypt-proxy-1.6.0/src/proxy» gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../ext -I../libevent-modified/include -DPKGDATADIR='"/opt/dnscrypt/share/dnscrypt-proxy"' -D_FORTIFY_SOURCE=2 -I/usr/local/include -g -O2 -fPIC -fPIE -fno-strict-aliasing -fno-strict-overflow -fstack-protector-all -Winit-self -Wwrite-strings -Wdiv-by-zero -MT dnscrypt_proxy-app.o -MD -MP -MF .deps/dnscrypt_proxy-app.Tpo -c -o dnscrypt_proxy-app.o `test -f 'app.c' || echo './'`app.c app.c:19:20: fatal error: sodium.h: Нет такого файла или каталога #include <sodium.h> ^ compilation terminated. Makefile:530: ошибка выполнения рецепта для цели «dnscrypt_proxy-app.o» make[4]: *** [dnscrypt_proxy-app.o] Ошибка 1 make[4]: выход из каталога «/opt/dnscrypt-proxy-1.6.0/src/proxy» Makefile:392: ошибка выполнения рецепта для цели «all» make[3]: *** [all] Ошибка 2 make[3]: выход из каталога «/opt/dnscrypt-proxy-1.6.0/src/proxy» Makefile:377: ошибка выполнения рецепта для цели «all-recursive» make[2]: *** [all-recursive] Ошибка 1 make[2]: выход из каталога «/opt/dnscrypt-proxy-1.6.0/src» Makefile:507: ошибка выполнения рецепта для цели «all-recursive» make[1]: *** [all-recursive] Ошибка 1 make[1]: выход из каталога «/opt/dnscrypt-proxy-1.6.0» Makefile:413: ошибка выполнения рецепта для цели «all» make: *** [all] Ошибка 2 # apt-get install libsodium-dev # make install
Бинарные файлы будут установлены сюда
/opt/dnscrypt/bin/hostip /opt/dnscrypt/sbin/dnscrypt-proxy man /opt/dnscrypt/share/man/man8/dnscrypt-proxy.8 man /opt/dnscrypt/share/man/man8/hostip.8
Есть важное замечание! Если Unbound работает с проверкой DNSSEC в комбинации с сервером не поддерживающими DNSSEC, тогда все запросы будут неудачными. В таком случае нужно DNSCrypt resolvers которые поддерживают DNSSEC или же отключить DNSSEC в Unbound поставив символ комментария перед auto-trust-anchor-file.
Файл со списком публичных dnscrypt-резолверов поддерживающих DNSSEC можно найти в каталоге с исходным кодом less dnscrypt-resolvers.csv или же по ссылке list of public DNS resolvers, или просто выберите один из этого списка:
- cloudns-can - CloudNS Canberra, CloudNS is an Australian based security focused DNS provider.
- cloudns-syd - CloudNS Sydney, CloudNS is an Australian based security focused DNS provider.
- dnscrypt.eu-dk - DNSCrypt.eu Denmark, "Free, non-logged, uncensored. Hosted by Netgroup."
- dnscrypt.eu-dk-ipv6 - DNSCrypt.eu Denmark over IPv6, "Free, non-logged, uncensored. Hosted by Netgroup."
- dnscrypt.eu-dk-port5353 - DNSCrypt.eu Denmark (port 5353), "Free, non-logged, uncensored. Hosted by Netgroup."
- dnscrypt.eu-nl - DNSCrypt.eu Holland, "Free, non-logged, uncensored. Hosted by RamNode.", Netherlands
- dnscrypt.eu-nl-ipv6 - DNSCrypt.eu Holland over IPv6, "Free, non-logged, uncensored. Hosted by RamNode.", Netherlands
- dnscrypt.eu-nl-port5353 - DNSCrypt.eu Holland (port 5353), "Free, non-logged, uncensored. Hosted by RamNode.", Netherlands
- dnscrypt.org-fr - "DNSCrypt server in France", "DNSSEC/Namecoin/Non-logged/Uncensored - ARM server donated by Scaleway.com"
- soltysiak - Soltysiak, Public DNSCrypt server in Poland,Poland
Теперь осталось подпилить конфигурацию Unbound и запустить dnscrypt-proxy, добавить в /etc/rc.local для автозапуска и перезапустить Unbound:
# vi /etc/unbound/unbound.conf ## Authoritative, validating, recursive caching DNS # See /usr/share/doc/unbound/examples/unbound.conf for a commented # reference config file. ## unbound.conf -- http://www.remoteshaman.com # server: # ... # Uncoment if you wish use Unbound through dnscrypt-proxy # http://dnscrypt.org/#dnscrypt-proxy do-not-query-localhost: no # Use the following forward-zone to forward all queries to Google DNS, # OpenDNS.com or your local ISP's dns servers for example. # To test resolution speeds use "drill calomel.org @8.8.8.8" # and look for the "Query time:" in milliseconds. # forward-zone: name: "." #forward-addr: 8.26.56.26 # Comodo DNS #forward-addr: 8.20.247.20 # Comodo DNS #forward-addr: 8.8.8.8 # Google Public DNS #forward-addr: 8.8.4.4 # Google Public DNS #forward-addr: 74.82.42.42 # Hurricane Electric #forward-addr: 4.2.2.4 # Level3 Verizon # # Uncoment if you wish use Unbound through dnscrypt-proxy # http://dnscrypt.org/#dnscrypt-proxy forward-addr: 127.0.0.1@40 # dnscrypt-proxy forward-addr: 127.0.0.1@41 # dnscrypt-proxy # # ## Authoritative, validating, recursive caching DNS ## unbound.conf -- http://www.remoteshaman.com --- # /opt/dnscrypt/sbin/dnscrypt-proxy --ephemeral-keys --resolver-name=dnscrypt.eu-nl --local-address=127.0.0.1:40 --daemonize # /opt/dnscrypt/sbin/dnscrypt-proxy --ephemeral-keys --resolver-name=dnscrypt.eu-nl-port5353 --local-address=127.0.0.1:41 --daemonize --- # vi /etc/rc.local /opt/dnscrypt/sbin/dnscrypt-proxy --ephemeral-keys --resolver-name=dnscrypt.eu-nl --local-address=127.0.0.1:40 --daemonize /opt/dnscrypt/sbin/dnscrypt-proxy --ephemeral-keys --resolver-name=dnscrypt.eu-nl-port5353 --local-address=127.0.0.1:41 --daemonize --- # systemctl restart unbound
Запуск DNSCrypt от non-root пользователя
ДНС-ресолвер Unbound, многие часто по ошибке называют его ДНС-сервером, после установки по умолчанию запускается от имени пользователя unbound.
Любые попытки запустить DNSCrypt от имени пользователя nobody закончатся ошибкой "[ERROR] Unable to chroot to [/nonexistent]", поэтому для запуска DNSCrypt от имени ограниченного пользователя (ака non-root) нам потребуется сначала создать его и у него должна быть реальная домашняя директория.
Делаем пользователя dnscrypt (на любые вопросы жмём Enter): adduser --disabled-login --shell /bin/false dnscrypt
Запускаем DNSCrypt от имени non-root пользователя: /opt/dnscrypt/sbin/dnscrypt-proxy --ephemeral-keys --resolver-name= --local-address=127.0.0.1:53 --user=dnscrypt --daemonize
Проблемы?
unbound-control[...] error: connect: Connection refused
Если не изменялась конфигурация по умолчанию, то всё должно быть в порядке, а если же в директории /etc/unbound/unbound.conf.d/ были созданы дополнительные конфигурационные файлы, то при использовании unbound-control возможны такие вот проблемы:
# systemctl restart unbound # unbound-control reload ok # unbound-control reload [1446250350] unbound-control[25955:0] debug: address 127.0.0.1 port 8953 [1446250350] unbound-control[25955:0] error: connect: Connection refused --- или --- # systemctl restart unbound # unbound-control reload ok # unbound-control stats [1446250350] unbound-control[25955:0] debug: address 127.0.0.1 port 8953 [1446250350] unbound-control[25955:0] error: connect: Connection refused
В любом случае после первого выполнения unbound-control reload ДНС-ресолвер перестаёт отвечать и требуется перезапуск systemctl restart unbound.
Где проблема, в самом unbound (но нет же, запускается/перезапускается успешно) или в unbound-control, можно только гадать? Короче, чтобы избежать этих проблем (версия unbound 1.4.22), конфигурационный файл должен быть один с одной секцией server: ...
Unbound не пишет в unbound.log
По умолчанию Unbound пишет в syslog, однако есть возможность писать события в отдельный файл журнала - в unbound.log. Для этого директива "use-syslog:" должна быть установлена в "no" и при этом файл указанный в "logfile:" должен физически присутствовать на диске, владельцем которого должен быть unbound:
# touch /etc/unbound/unbound.log # chown unbound:unbound /etc/unbound/unbound.log # vi /etc/unbound/unbound.conf server: logfile: "/etc/unbound/unbound.log"
Проблемы с forwarding-ом DNS-запросов
Если Unbound продолжает перенаправлять запросы на сторонние сервера, а не на те что мы указали в "forward-zone:", тогда открываем /etc/default/unbound, доводим его до следующей ниже кондиции и перезапускаем Unbound:
# vi /etc/default/unbound # If set, resolvconf nameservers will be configured as forwarders # to be used by unbound. RESOLVCONF_FORWARDERS=false DAEMON_OPTS="-c /etc/unbound/unbound.conf"
DNSSEC Validator браузера Firefox пишет о неправильном IP
DNSSEC/TLSA Validator браузера Firefox иногда может выдавать ложную тревогу о том, что IP-адрес полученный браузером не совпадает с тем, который был получен расширением, как на скриншоте ниже:
На скриншоте говорится о том, что IP-адрес 150.203.164.38 полученный браузером не совпадает с IP 5.153.231.4/130.89.148.14, что даёт основания подозревать попытку атаки "DNS spoofing". Проверим:
$ nslookup debian.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: debian.org Address: 5.153.231.4 Name: debian.org Address: 128.31.0.62 Name: debian.org Address: 130.89.148.14 Name: debian.org Address: 140.211.15.34 Name: debian.org Address: 150.203.164.38 Name: debian.org Address: 200.17.202.197 $ nslookup debian.org 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: debian.org Address: 130.89.148.14 Name: debian.org Address: 140.211.15.34 Name: debian.org Address: 150.203.164.38 Name: debian.org Address: 200.17.202.197 Name: debian.org Address: 5.153.231.4 Name: debian.org Address: 128.31.0.62
Видим, что nslookup debian.org (запрос через наш локальный ДНС-ресолвер) и nslookup debian.org 8.8.8.8 (запрос через ДНС-ресолвер гугла) выдаёт одинаковый список IP-адресов, а это значит, что DNSSEC/TLSA Validator браузера Firefox выдал ложную тревогу.
По умолчанию DNSSEC/TLSA Validator браузера Firefox настроен (Инструменты - Дополнения - Расширения - DNSSEC/TLSA Validator - Настройки) как "Without resolver" и использует "DANE протокол" для проверки DNSSEC для домена. Потому как при наличии нескольких А записей для домена они выдаются динамически, то вполне вероятно что ложная тревога обусловлена несогласованностью между результатами запроса локального ресолвера и самого расширения.
Решить эту проблему можно установив в настройках расширения "Resolver settings" вариант "Custom:" и IP ресолвера "127.0.0.1", далее нажать "Test current settings" на что должны получить "Success - current settings allow DNSSEC validation.".
Итого
Установка Unbound DNSSEC с переадресацией запросов в DNSCrypt оправдана тем, что:
- DNSSEC на данный момент поддерживают очень мало ДНС-провайдеров, а своему ISP мы не доверяем;
- DNSCrypt не кэширует запросы, а Unbound как раз наоборот.
Вместо Unbound для кэширования ДНС-запросов можно установить "nscd - GNU C Library: Name Service Cache Daemon", однако он глючный и в Debian не установлен по умолчанию.
Напомним, что использование шифрования ДНС-трафика с помощью DNSCrypt не скрывает сам ИП-адрес и доменное имя сайта к которому обращается приложение, а только даёт некую уверенность в том, что результат ДНС запроса не будет подменён местной "прослушкой". При использовании не зашифрованного HTTP соединения доменное имя (заголовок Host), как собственно и строку запроса (Request-Line) можно выдрать из "Request Headers". Однако при использовании HTTPS, "прослушке" будут доступны только IP-адреса имхо перед началом передачи "Request Headers" происходит установка защищённого TCP соединения (via SSL/TLS protocol) и уже после клиент/браузер отправляет HTTP request (методом GET или POST) по зашифрованному TCP соединению.
Unbound DNSSEC совместно с DNSCrypt не является решением вопроса полной 100% анонимности, которой не может быть в принципе, а только лишь меняет доверенного поставщика с местного, как правило "подкаблучного" ISP (Internet Service Provider), на как нам кажется более надёжного и анонимного европейского поставщика ДНС-услуг от которого большей частью теперь и будет зависеть безопасность всех наших ДНС-запросов.
P.S. При возможности шифровать нужно всё что только можно!
