Различни аспекти на експлоатацията на DNS вече многократно са били разглеждани от автора в редица публикации в блога. В същото време, основният акцент винаги е поставен на повишаването на сигурността на тази ключова за Интернет услуга.
До последното време, въпреки очевидността на уязвимостта на DNS трафика, който все още в по-голямата си част се предава в открит вид, за злонамерени действия от страна на доставчици, стремящи се да увеличат доходите си чрез вграждане на реклама в съдържанието, държавни органи и цензура, както и просто престъпници, процесът , въпреки наличието на различни технологии, като DNSSEC/DANE, DNScrypt, DNS-over-TLS и DNS-over-HTTPS, буксуваше. И ако сървърните решения, някои от които съществуват от доста дълго време, са широко известни и достъпни, то подкрепата им от страна на клиентския софтуер дава много какво да се желае.
За щастие, ситуацията се променя. По-специално, разработчиците на популярния браузър Firefox обявиха плановете си за включване по подразбиране на режима (DoH) в близко бъдеще. Това трябва да помогне за защита на DNS трафика на потребителите от гореспоменатите заплахи, но потенциално може да предизвика нови.
1. Проблеми с DNS-over-HTTPS
На пръв поглед, започващото масово внедряване на DNS-over-HTTPS в софтуера, работещ в Интернет, предизвиква единствено позитивна реакция. Въпреки това, както се казва, дяволът е в детайлите.
Проблемът, който ограничава обхвата на масовото приложение на DoH, е неговата ориентация изключително към уеб трафика. Наистина, протоколът HTTP и актуалната му редакция HTTP/2, на която се основава DoH, е основата на WWW. Но Интернет не е само уеб. Съществуват множество популярни услуги, като електронна поща, различни мессенджъри, системи за пренос на файлове, стрийминг на мултимедия и др., които не използват HTTP. Така, въпреки че много хора възприемат DoH като панацея, той се оказва неприложим без допълнителни (и ненужни) усилия, освен за браузерни технологии. Между другото, за тази роля значително по-добър кандидат изглежда DNS-over-TLS, който реализира инкапсулацията на стандартния DNS трафик в защитен стандартен протокол TLS.
Втората проблема, която потенциално е много по-сериозна от първата, е фактическото отказване от присъщата на DNS по подразбиране децентрализация в полза на използването на един DoH сървър, зададен в настройките на браузъра. По-специално, Mozilla предлага да се използва услугата на Cloudflare. Подобни услуги също пуснаха и други забележителни фигури в Интернет, включително Google. Получава се, че внедряването на DNS-over-HTTPS в сегашния му вид, всъщност увеличава зависимостта на крайните потребители от най-големите услуги. Не е тайна, че информацията, която анализът на DNS запитванията може да предостави, е способна да събира още повече данни за тях, а също така да повиши точността и актуалността им.
В тази връзка, авторът беше и остава привърженик на масовото внедряване не на DNS-over-HTTPS, а на DNS-over-TLS в комбинация с DNSSEC/DANE като универсално, безопасно и немотивиращо допълнителната централизация в Интернет средство за осигуряване на безопасност на DNS трафика. За съжаление, не трябва да очакваме бързо внедряване на масова поддръжка на алтернативи на DoH в клиентския софтуер по разбираеми причини, и досега местата остават на ентусиастите за безопасни технологии.
Но, след като сега получаваме DoH, защо да не го използваме, преди да се откажем от потенциално наблюдение от страна на корпорации чрез техните сървъри в полза на собствен DNS-over-HTTPS сървър?
2. Протокол DNS-over-HTTPS
Ако погледнете стандарта описващ протокола DNS-over-HTTPS, ще видите, че той, по същество, представлява уеб API, позволяващо инкапсулирането на стандартния DNS пакет в протокола HTTP/2. Това се реализира чрез специални HTTP заглавия, а също и конверсия на бинарния формат на предаваните DNS данни (вж. и следващите документи) във форма, позволяваща предаване и получаване, както и работа с необходимите метаданни.
По стандарт се поддържа само HTTP/2 и защитена връзка TLS.
Изпращането на DNS запитвания може да се извършва чрез стандартните методи GET и POST. В първия случай запитването се трансформира в base64URL-кодирана стринг, а във втория — през тялото на POST запитването в бинарна форма. При това при запитването и при отговора на DNS се използва специален MIME тип данни application/dns-message.
root@eprove:~ # curl -H 'accept: application/dns-message' 'https://my.domaint/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE' -v
* Trying 2001:100:200:300::400:443...
* TCP_NODELAY set
* Connected to eprove.net (2001:100:200:300::400) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=my.domain
* start date: Jul 22 00:07:13 2019 GMT
* expire date: Oct 20 00:07:13 2019 GMT
* subjectAltName: host "my.domain" matched cert's "my.domain"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x801441000)
> GET /dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE HTTP/2
> Host: eprove.net
> User-Agent: curl/7.65.3
> accept: application/dns-message
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< server: h2o/2.3.0-beta2
< content-type: application/dns-message
< cache-control: max-age=86274
< date: Thu, 12 Sep 2019 13:07:25 GMT
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< content-length: 45
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: " to save to a file.
* Failed writing body (0 != 45)
* stopped the pause stream!
* Connection #0 to host eprove.net left intactОбърнете внимание и на заглавката cache-control: в отговора на уеб сървъра. В параметъра max-age се съдържа стойността на TTL за върнатата DNS записа (или минималната стойност, ако се връщат повече).
Следователно, функционирането на DoH сървъра се състои от няколко етапа.
- Получаване на HTTP заявка. Ако е GET, декодирайте пакета от base64URL кодиране.
- Изпратете този пакет до DNS сървъра.
- Получете отговор от DNS сървъра.
- Намерете минималното значение на TTL в получените записи.
- Върнете отговор на клиента през HTTP.
3. Вашият DNS-over-HTTPS сървър
Най-простият, бърз и ефективен начин да стартирате собствен DNS-over-HTTPS сървър е да използвате HTTP/2 уеб сървър , за който авторът вече е споменавал (вижте "«).
В полза на този избор е фактът, че целият код на собствения DoH сървър може да бъде изцяло реализиран чрез интегрирания в H2O интерпретатор . Освен стандартните библиотеки, за обмен на данни с DNS сървър е необходима библиотека (mrbgem) Socket, която, за щастие, вече е включена в текущата девелоперска версия H2O 2.3.0-beta2 в портовете на FreeBSD. Въпреки това, не е трудно да я добавите и в предишна версия, като клонирате репозитория в каталога /deps преди компилация.
root@beta:~ # uname -v
FreeBSD 12.0-RELEASE-p10 GENERIC
root@beta:~ # cd /usr/ports/www/h2o
root@beta:/usr/ports/www/h2o # make extract
===> Лиценз MIT BSD2CLAUSE приета от потребителя
===> h2o-2.2.6 зависи от файл: /usr/local/sbin/pkg - намерен
===> Изтегляне на всички нужни дистрибутивни файлове за h2o-2.2.6 за изграждане
===> Извличане за h2o-2.2.6.
=> SHA256 Контролна сума ОК за h2o-h2o-v2.2.6_GH0.tar.gz.
===> h2o-2.2.6 зависи от файл: /usr/local/bin/ruby26 - намерен
root@beta:/usr/ports/www/h2o # cd work/h2o-2.2.6/deps/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # git clone https://github.com/iij/mruby-socket.git
Клониране в «mruby-socket»…
remote: Изброяване на обектите: 385, готово.
remote: Общо 385 (delta 0), използвани 0 (delta 0), pack-reused 385
Получаване на обекти: 100% (385/385), 98.02 KiB | 647.00 KiB/s, готово.
Определяне на изменения: 100% (208/208), готово.
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # ll
total 181
drwxr-xr-x 9 root wheel 18 12 авг. 16:09 brotli/
drwxr-xr-x 2 root wheel 4 12 авг. 16:09 cloexec/
drwxr-xr-x 2 root wheel 5 12 авг. 16:09 golombset/
drwxr-xr-x 4 root wheel 35 12 авг. 16:09 klib/
drwxr-xr-x 2 root wheel 5 12 авг. 16:09 libgkc/
drwxr-xr-x 4 root wheel 26 12 авг. 16:09 libyrmcds/
drwxr-xr-x 13 root wheel 32 12 авг. 16:09 mruby/
drwxr-xr-x 5 root wheel 11 12 авг. 16:09 mruby-digest/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-dir/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-env/
drwxr-xr-x 4 root wheel 9 12 авг. 16:09 mruby-errno/
drwxr-xr-x 5 root wheel 14 12 авг. 16:09 mruby-file-stat/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-iijson/
drwxr-xr-x 5 root wheel 11 12 авг. 16:09 mruby-input-stream/
drwxr-xr-x 6 root wheel 11 12 авг. 16:09 mruby-io/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-onig-regexp/
drwxr-xr-x 4 root wheel 10 12 авг. 16:09 mruby-pack/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-require/
drwxr-xr-x 6 root wheel 10 12 септ. 16:10 mruby-socket/
drwxr-xr-x 2 root wheel 9 12 авг. 16:09 neverbleed/
drwxr-xr-x 2 root wheel 13 12 авг. 16:09 picohttpparser/
drwxr-xr-x 2 root wheel 4 12 авг. 16:09 picotest/
drwxr-xr-x 9 root wheel 16 12 авг. 16:09 picotls/
drwxr-xr-x 4 root wheel 8 12 авг. 16:09 ssl-conservatory/
drwxr-xr-x 8 root wheel 18 12 авг. 16:09 yaml/
drwxr-xr-x 2 root wheel 8 12 авг. 16:09 yoml/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # cd ../../..
root@beta:/usr/ports/www/h2o # make install clean
...Конфигурацията на уеб сървъра е, като цяло, стандартна.
root@beta:/usr/ports/www/h2o # cd /usr/local/etc/h2o/
root@beta:/usr/local/etc/h2o # cat h2o.conf
# този примерен конфигурационен файл ви дава представа за начина, по който H2O може да се използва
# и високосигурна конфигурация за TLS и HTTP заглавия
# вижте https://h2o.examp1e.net/ за подробна документация
# и h2o --help за опции и настройки на командния ред
# v.20180207 (c)2018 от Max Kostikov http://kostikov.co e-mail: max@kostikov.co
user: www
pid-file: /var/run/h2o.pid
access-log:
path: /var/log/h2o/h2o-access.log
format: "%h %v %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i""
error-log: /var/log/h2o/h2o-error.log
expires: off
compress: on
file.dirlisting: off
file.send-compressed: on
file.index: [ 'index.html', 'index.php' ]
listen:
port: 80
listen:
port: 443
ssl:
cipher-suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
cipher-preference: server
dh-file: /etc/ssl/dhparams.pem
certificate-file: /usr/local/etc/letsencrypt/live/eprove.net/fullchain.pem
key-file: /usr/local/etc/letsencrypt/live/my.domain/privkey.pem
hosts:
"*.my.domain":
paths: &go_tls
"/":
redirect:
status: 301
url: https://my.domain/
"my.domain:80":
paths: *go_tls
"my.domain:443":
header.add: "Strict-Transport-Security: max-age=15768000; includeSubDomains; preload"
paths:
"/dns-query":
mruby.handler-file: /usr/local/etc/h2o/h2odoh.rbИзключение представлява само обработката на URL /dns-query за която всъщност отговаря нашият DNS-over-HTTPS сървър, написан на mruby и извикан чрез опцията на обработчика mruby.handler-file.
root@beta:/usr/local/etc/h2o # cat h2odoh.rb
# H2O HTTP/2 уеб сървър като DNS-over-HTTP услуга
# v.20190908 (c)2018-2019 Max Kostиков https://kostikov.co e-mail: max@kostikov.co
proc {|env|
if env['HTTP_ACCEPT'] == "application/dns-message"
case env['REQUEST_METHOD']
when "GET"
req = env['QUERY_STRING'].gsub(/^dns=/,'')
# base64URL декодиране
req = req.tr("-_", "+/")
if !req.end_with?("=") && req.length % 4 != 0
req = req.ljust((req.length + 3) & ~3, "=")
end
req = req.unpack1("m")
when "POST"
req = env['rack.input'].read
else
req = ""
end
if req.empty?
[400, { 'content-type' => 'text/plain' }, [ "Невалидна заявка" ]]
else
# --- запитване към DNS сървъра
sock = UDPSocket.new
sock.connect("localhost", 53)
sock.send(req, 0)
str = sock.recv(4096)
sock.close
# --- намиране на най-ниския TTL в отговора
nans = str[6, 2].unpack1('n') # брой на отговорите
if nans > 0 # няма DNS грешка
shift = 12
ttl = 0
while nans > 0
# обработка на компресиране на домейн имена
if str[shift].unpack1("C") curttl
ttl = curttl
end
nans -= 1
end
cc = 'max-age=' + ttl.to_s
else
cc = 'no-cache'
end
[200, { 'content-type' => 'application/dns-message', 'content-length' => str.size, 'cache-control' => cc }, [ str ] ]
end
else
[415, { 'content-type' => 'text/plain' }, [ "Неподдържан медиен тип" ]]
end
}Обърнете внимание, че обработката на DNS пакети се извършва от локален кеширащ сървър, в случая от стандартната инсталация на FreeBSD. От гледна точка на сигурността, това е оптимално решение. Въпреки това, нищо не пречи да замените localhost с адреса на друг DNS, който планирате да използвате.
root@beta:/usr/local/etc/h2o # local-unbound версия
употреба: local-unbound [опции]
стартиране на unbound демон DNS резолвър.
-h тази помощ
-c файл конфигурационен файл за четене вместо /var/unbound/unbound.conf
форматът на файла е описан в unbound.conf(5).
-d не създавайте фонова задача.
-p не създавайте pid файл.
-v подробно (колкото повече пъти, толкова по-голяма подробност)
Версия 1.8.1
свързани библиотеки: mini-event internal (използва select), OpenSSL 1.1.1a-freebsd 20 ноември 2018
свързани модули: dns64 respip валидатор итератор
Лиценз BSD, вижте ЛИЦЕНЗА в източника за повече информация.
Докладвайте грешките на unbound-bugs@nlnetlabs.nl
root@eprove:/usr/local/etc/h2o # sockstat -46 | grep unbound
unbound local-unbo 69749 3 udp6 ::1:53 *:*
unbound local-unbo 69749 4 tcp6 ::1:53 *:*
unbound local-unbo 69749 5 udp4 127.0.0.1:53 *:*
unbound local-unbo 69749 6 tcp4 127.0.0.1:53 *:*Остава да рестартирате H2O и да видите какво стана.
root@beta:/usr/local/etc/h2o # service h2o restart
Stopping h2o.
Waiting for PIDS: 69871.
Starting h2o.
start_server (pid:70532) starting now...4. Тестване
Така, нека проверим резултатите, като изпратим отново пробно запитване и разгледаме мрежовия трафик с помощта на утилита tcpdump.
root@beta/usr/local/etc/h2o # curl -H 'accept: application/dns-message' 'https://my.domain/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE'
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: " to save to a file.
...
root@beta:~ # tcpdump -n -i lo0 udp port 53 -xx -XX -vv
tcpdump: listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes
16:32:40.420831 IP (tos 0x0, ttl 64, id 37575, offset 0, flags [none], proto UDP (17), length 57, bad cksum 0 (->e9ea)!)
127.0.0.1.21070 > 127.0.0.1.53: [bad udp cksum 0xfe38 -> 0x33e3!] 43981+ A? example.com. (29)
0x0000: 0200 0000 4500 0039 92c7 0000 4011 0000 ....E..9....@...
0x0010: 7f00 0001 7f00 0001 524e 0035 0025 fe38 ........RN.5.%.8
0x0020: abcd 0100 0001 0000 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01 mple.com.....
16:32:40.796507 IP (tos 0x0, ttl 64, id 37590, offset 0, flags [none], proto UDP (17), length 73, bad cksum 0 (->e9cb)!)
127.0.0.1.53 > 127.0.0.1.21070: [bad udp cksum 0xfe48 -> 0x43fa!] 43981 q: A? example.com. 1/0/0 example.com. A 93.184.216.34 (45)
0x0000: 0200 0000 4500 0049 92d6 0000 4011 0000 ....E..I....@...
0x0010: 7f00 0001 7f00 0001 0035 524e 0035 fe48 .........5RN.5.H
0x0020: abcd 8180 0001 0001 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01c0 0c00 mple.com........
0x0040: 0100 0100 0151 8000 045d b8d8 22 .....Q...].."
^C
2 packets captured
23 packets received by filter
0 packets dropped by kernelВ изхода се вижда как запитването за разрешаване на адреса example.com беше получено и успешно обработено от DNS сървъра.
Сега остава да активираме нашия сървър в браузъра Firefox. За целта в страниците на конфигурацията трябва да променим няколко настройки. about:config.
На първо място, това е адресът на нашия API, по който браузърът ще запитва информация в DNS за network.trr.uri. Препоръчително е също да зададете IP адреса на домейна от този URL за сигурно разрешаване в IP посредством самия браузър без обръщение към DNS в network.trr.bootstrapAddress. И накрая, самият параметър network.trr.mode включващ използването на DoH. Настройването на стойност «3» ще принуди браузъра да използва изключително DNS-over-HTTPS за разрешаване на имена, а по-надеждната и безопасна «2» ще даде предимство на DoH, оставяйки стандартното обръщение към DNS като резервен вариант.
5. ПЕЧАЛБА!
Статията беше полезна? Тогава не се колебайте и подкрепете ни финансово чрез формата за дарения (по-долу).
Източник: habr.com
