HTTPS - уже везде. Но как убрать от посторонних парсеров свои запросы к серверам DNS, которые идут без шифрования? Используем DNS over TLS.
В статье рассмотрен вариант настройки кеширующего DNS-сервера для локальной сети. Если требуется DNS через TLS только на самом компьютере (поддержка запросов от других устройств не нужна), то данное решение избыточно. Можно посмотреть эту или вот эту статьи.
За основу взял статью здесь. Ровно по статье сделать не удалось. Общая идея такая. Используем связку из stubby и unbound. Демон Stubby умеет принимать запросы от локальной машины, зашифровывать их и отправлять на DNS-сервер с поддержкой шифрования. Unbound - это DNS-сервер, он будет кеширующим DNS-сервером для нашей локальной сети. Запросы на еще не закешированные адреса он будет отдавать Stubby. Вместо Unbound может быть другой DNS-сервер. В Интернете есть примеры настройки. Используемая связка Stubby и Unbound - достаточно популярна.
Начинаем.
1. Устанавливаем сами приложения
microserver:~$ sudo apt install stubby unbound
Ставим инструменты тестирования:
microserver:~$ sudo apt install bind9-dnsutils net-tools
2. Отключаем системный DNS-клиент
microserver:~$ sudo systemctl disable systemd-resolved.service
Removed /etc/systemd/system/dbus-org.freedesktop.resolve1.service.
Removed /etc/systemd/system/multi-user.target.wants/systemd-resolved.service.
microserver:~$ sudo service systemd-resolved stop
Теперь надо отредактировать файлы настроек
3. Настройки Unbound (файл "/etc/unbound.conf"). По умолчанию он содержит только 1 строку с include. Добавляем в файл следующие настройки
server:
interface: 192.168.1.254
interface: 127.0.0.1
access-control: 192.168.1.0/24 allow
use-syslog: yes
username: "unbound"
directory: "/etc/unbound"
minimal-responses: yes
qname-minimisation: yes
rrset-roundrobin: yes
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@8053
forward-addr: ::1@8053
Красным выделил значения, которые нужно исправить под свою сеть. "interface" - адрес вашей машины, на которой настраивается DNS-сервер. "access-control" - ваша подсеть маской (/24 эквивалентно маске 255.255.255.0, /16 эквивалентно маске 255.255.0.0). У автора оригинальной стать interface равен 0.0.0.0. У меня такая настройка вызывала ошибку запуска демона.
4. Теперь настройки для Stubby. Весь файл настроек длинный, целиком приводить не буду. Но правки нужны незначительные. В секцию "LISTEN ADDRES" надо добавить прослушиваемые адреса (выделил синим):
################################ LISTEN ADDRESS ################################
# Set the listen addresses for the stubby DAEMON. This specifies localhost IPv4
# and IPv6. It will listen on port 53 by default. Use <IP_address>@<port> to
# specify a different port
listen_addresses:
- 127.0.0.1@8053
- 0::1@8053
Выбираем, какие серверы DNS будут использоваться. Это секции:
############################ DEFAULT UPSTREAMS ################################
############################ OPTIONAL UPSTREAMS ###############################
По умолчанию открыты "Surfnet/Sinodun", "getdnsapi.net". Я еще открыл "Quad 9 'secure' service", "Cloudflare 1.1.1.1 and 1.0.0.1". Не большой специалист в различиях этих серверов. Знаю, что есть сравнения. Если руки дойдут прочитать, то сделаю обновление в статье.
Секция IPv6 у меня закомментирована.
####### IPv6 addresses #######
5. Перестартовываем демоны, настраиваем автозапуск
microserver:~$ sudo systemctl restart unbound
microserver:~$ sudo systemctl enable unbound
microserver:~$ sudo systemctl restart stubby
microserver:~$ sudo systemctl enable stubby
6. На этом этапе должно было бы заработать. Но оказывается, надо еще проверить файл "/etc/resolv.conf". В нем должен быть адрес сервера имен 127.0.0.1 (выделил синим).
microserver:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.1
7. Как проверить, что работает. В статье предлагается использовать wireshark. Но у меня сервер без монитора и клавиатуры, настройка идет по SSH. Поэтому используем средства командной строки. Проверка делится на несколько этапов.
7.1. Проверяем, что работает кеширующий DNS-сервер. На настраиваемой машине запускаем команду "ss":
microserver:~$ sudo ss -tuna | grep '\(State\|:53 \)'
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:*
udp UNCONN 0 0 192.168.1.254:53 0.0.0.0:*
tcp LISTEN 0 256 127.0.0.1:53 0.0.0.0:*
tcp LISTEN 0 256 192.168.1.254:53 0.0.0.0:*
Видим, что порты прослушиваются.
Теперь на другой машине (Linux, Mac OS) в локальной сети запускаем программу nslookup, меняем сервер на наш настроенный и вводим любимое имя домена для проверки:
desktop$ nslookup
> server 192.168.1.254
Default server: 192.168.1.254
Address: 192.168.1.254#53
> mail.ru
Server: 192.168.1.254
Address: 192.168.1.254#53
Non-authoritative answer:
Name: mail.ru
Address: 217.69.139.202
Name: mail.ru
Address: 94.100.180.200
Name: mail.ru
Address: 94.100.180.201
Name: mail.ru
Address: 217.69.139.200
> exit
Должны вернуться IP-адреса выбранного доменного имени.
7.2. Теперь проверяем, что запросы от нашего сервера идут через порт 853 на выбранные серверы DNS.
Проверяем, что Stubby на месте:
microserver:~$ sudo netstat -lnptu |grep stubby
tcp 0 0 127.0.0.1:8053 0.0.0.0:* LISTEN 921/stubby
udp 0 0 127.0.0.1:8053 0.0.0.0:* 921/stubby
теперь шлем запросы DNS и смотрим активность на портах. Нашел 2 способа.
На настраиваемой машине или на машине в локальной сети делаем запрос к нашему серверу средствами nslookup (см. выше) или dig:
microserver:~$ dig github.com
; <<>> DiG 9.16.1-Ubuntu <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12207
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;github.com. IN A
;; ANSWER SECTION:
github.com. 52 IN A 140.82.121.3
;; Query time: 395 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Пн янв 04 02:19:08 MSK 2021
;; MSG SIZE rcvd: 55
Сразу после этого на настраиваемом сервере запускаем команду
microserver:~$ sudo ss -tuna | grep '\(State\|:853 \)'
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp TIME-WAIT 0 0 192.168.1.254:41080 145.100.185.16:853
Должен быть виден запрос на порт 853 одного из выбранных нами внешних DNS-серверов.
Тут есть нюанс. Наш DNS-сервер - кеширующий. Поэтому, если вы запросите разрешение одного имени несколько раз, то запрос на внешний DNS-сервер будет отправлен только первый раз, а остальные разы ответ будет взят из кеша, и команда "ss" активность на внешнем интерфейсе не покажет.
Второй вариант - длинная и страшная команда: "sudo tcpdump -tttt -nn -XX -vv -i <сетевой интерфейс> dst <адрес внешнего DNS-сервера> and port 853". <сетевой интерфейс> надо заменить на имя сетевого интерфейса настраиваемого сервера (в моем случае это em1). Узнать его можно командой ifconfig:
microserver:~$ ifconfig
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.254 netmask 255.255.255.0 broadcast 192.168.1.255
ether d8:d3:85:b3:a7:7b txqueuelen 1000 (Ethernet)
RX packets 275855 bytes 29605256 (29.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 602983 bytes 866307263 (866.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Локальная петля (Loopback))
RX packets 11410 bytes 3637832 (3.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11410 bytes 3637832 (3.6 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
С <адрес внешнего DNS-сервера> тоже всё непросто. Если вы, как и я, выбрали для Stubby в "UPSTREAMS" несколько внешних DNS-серверов, то запросы будут отсылаться по всему списку внешних DNS-серверов по кругу. Поэтому в качестве <адрес внешнего DNS-сервера> надо выбрать один из IP-адресов в списке внешних DNS-серверов. А дальше отправлять несколько запросов на разрешение имен с разными именами домена (помним, что наш DNS-сервер кеширующий). Следить, к какому DNS-серверу был отправлен запрос на этот раз можно с помощью команды "ss" (см. выше)
Последовательность действий в тесте другая. Вначале запускаем команду tcpdump, она начинает слушать "разговоры", а потом в другом терминале или с другой машины выполняем запрос на разрешение имени в dig или nslookup. Если нас DNS-сервер работает верно, то tcpdump выдаст что-то вроде:
evgeniy@microserver:~$ sudo tcpdump -tttt -nn -XX -vv -i em1 dst 145.100.185.16 and port 853
tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-01-04 01:08:58.402475 IP (tos 0x0, ttl 64, id 9505, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.254.41040 > 145.100.185.16.853: Flags [S], cksum 0x0d46 (incorrect -> 0xbaae), seq 998080101, win 64240, options [mss 1460,sackOK,TS val 2231476927 ecr 0,nop,wscale 7], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 003c 2521 4000 4006 0884 c0a8 01fa 9164 .<%!@.@........d
0x0020: b910 a050 0355 3b7d 7e65 0000 0000 a002 ...P.U;}~e......
0x0030: faf0 0d46 0000 0204 05b4 0402 080a 8501 ...F............
0x0040: a2bf 0000 0000 0103 0307 ..........
2021-01-04 01:08:58.450555 IP (tos 0x0, ttl 64, id 9506, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.254.41040 > 145.100.185.16.853: Flags [.], cksum 0x0d3e (incorrect -> 0x8035), seq 998080102, ack 3565166824, win 502, options [nop,nop,TS val 2231476975 ecr 528108829], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0034 2522 4000 4006 088b c0a8 01fa 9164 .4%"@.@........d
0x0020: b910 a050 0355 3b7d 7e66 d480 20e8 8010 ...P.U;}~f......
0x0030: 01f6 0d3e 0000 0101 080a 8501 a2ef 1f7a ...>...........z
0x0040: 4d1d M.
2021-01-04 01:08:58.451246 IP (tos 0x0, ttl 64, id 9507, offset 0, flags [DF], proto TCP (6), length 533)
192.168.1.254.41040 > 145.100.185.16.853: Flags [P.], cksum 0x0f1f (incorrect -> 0x99e2), seq 0:481, ack 1, win 502, options [nop,nop,TS val 2231476976 ecr 528108829], length 481
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0215 2523 4000 4006 06a9 c0a8 01fa 9164 ..%#@.@........d
0x0020: b910 a050 0355 3b7d 7e66 d480 20e8 8018 ...P.U;}~f......
0x0030: 01f6 0f1f 0000 0101 080a 8501 a2f0 1f7a ...............z
0x0040: 4d1d 1603 0101 dc01 0001 d803 03c8 f1ea M...............
0x0050: fcbe c3c9 dbd8 01ee c0f6 263b a4d1 4581 ..........&;..E.
0x0060: b851 838c 2e85 0fb3 bbab f789 0a20 4d9c .Q............M.
0x0070: e7ab 2589 c245 3a70 7535 9fbb c1b2 d6be ..%..E:pu5......
0x0080: 7266 85cf 092a c764 d92b 2a7f a91f 0014 rf...*.d.+*.....
0x0090: 1302 1303 1301 c02c c030 c02b c02f cca9 .......,.0.+./..
0x00a0: cca8 00ff 0100 017b 0000 001c 001a 0000 .......{........
0x00b0: 1764 6e73 6f76 6572 746c 7331 2e73 696e .dnsovertls1.sin
0x00c0: 6f64 756e 2e63 6f6d 000b 0004 0300 0102 odun.com........
0x00d0: 000a 000c 000a 001d 0017 001e 0019 0018 ................
0x00e0: 0023 00d0 5d82 2269 e2e6 8080 3ff2 1439 .#..]."i....?..9
0x00f0: e45e d872 662f befe f39c a5d4 3115 38d0 .^.rf/......1.8.
0x0100: c0d0 b8ea 38f1 4c07 40b0 1b7b 7515 9627 ....8.L.@..{u..'
0x0110: 71c8 8055 a51e f022 ad3c a73c 8ec7 11e5 q..U...".<.<....
0x0120: a5a3 586f 2867 e222 343f 7e0b 0158 245e ..Xo(g."4?~..X$^
0x0130: 2867 d209 66e4 09ff d652 edc0 7c90 ec53 (g..f....R..|..S
0x0140: 13ec b497 903b dc9c 03a0 382b 165e 8db0 .....;....8+.^..
0x0150: 4ce2 5e5c f965 2061 2d83 8030 f220 61b3 L.^\.e.a-..0..a.
0x0160: 2d33 d368 a3ef c8fc 5fd2 910d c76b 545b -3.h...._....kT[
0x0170: bac8 24e7 1825 fab2 40ab a331 fd79 3b74 ..$..%..@..1.y;t
0x0180: ee65 4fa6 c0af d853 c96c f12c 78e8 382f .eO....S.l.,x.8/
0x0190: 2eb3 12d2 4a9d 9574 aa12 8bcd 6837 7829 ....J..t....h7x)
0x01a0: 5cd7 c385 1fd5 da41 81e0 a70a 4e95 5640 \......A....N.V@
0x01b0: 5876 8f9e 0016 0000 0017 0000 000d 002a Xv.............*
0x01c0: 0028 0403 0503 0603 0807 0808 0809 080a .(..............
0x01d0: 080b 0804 0805 0806 0401 0501 0601 0303 ................
0x01e0: 0301 0302 0402 0502 0602 002b 0005 0403 ...........+....
0x01f0: 0403 0300 2d00 0201 0100 3300 2600 2400 ....-.....3.&.$.
0x0200: 1d00 209d db9a a404 bd4b 2675 03eb 8164 .........K&u...d
0x0210: 645e db98 d331 8d5b 17e0 3e92 7c98 2c85 d^...1.[..>.|.,.
0x0220: 9d8b 0d ...
2021-01-04 01:08:58.499724 IP (tos 0x0, ttl 64, id 9508, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.254.41040 > 145.100.185.16.853: Flags [.], cksum 0x0d3e (incorrect -> 0x7d8f), seq 481, ack 138, win 501, options [nop,nop,TS val 2231477024 ecr 528108841], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0034 2524 4000 4006 0889 c0a8 01fa 9164 .4%$@.@........d
0x0020: b910 a050 0355 3b7d 8047 d480 2171 8010 ...P.U;}.G..!q..
0x0030: 01f5 0d3e 0000 0101 080a 8501 a320 1f7a ...>...........z
0x0040: 4d29 M)
2021-01-04 01:08:58.500478 IP (tos 0x0, ttl 64, id 9509, offset 0, flags [DF], proto TCP (6), length 103)
192.168.1.254.41040 > 145.100.185.16.853: Flags [P.], cksum 0x0d71 (incorrect -> 0xaf2d), seq 481:532, ack 138, win 501, options [nop,nop,TS val 2231477025 ecr 528108841], length 51
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0067 2525 4000 4006 0855 c0a8 01fa 9164 .g%%@.@..U.....d
0x0020: b910 a050 0355 3b7d 8047 d480 2171 8018 ...P.U;}.G..!q..
0x0030: 01f5 0d71 0000 0101 080a 8501 a321 1f7a ...q.........!.z
0x0040: 4d29 1403 0300 0101 1603 0300 28e5 3ed0 M)..........(.>.
0x0050: 830d ad39 07f9 5171 417e 0a4b 0f19 e7fa ...9..QqA~.K....
0x0060: 7bfb 659b 9e07 0b26 8f8c 5fee e9e7 3dd9 {.e....&.._...=.
0x0070: a686 5f52 c1 .._R.
2021-01-04 01:08:58.585012 IP (tos 0x0, ttl 64, id 9510, offset 0, flags [DF], proto TCP (6), length 211)
192.168.1.254.41040 > 145.100.185.16.853: Flags [P.], cksum 0x0ddd (incorrect -> 0x6f00), seq 532:691, ack 138, win 501, options [nop,nop,TS val 2231477109 ecr 528108863], length 159
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 00d3 2526 4000 4006 07e8 c0a8 01fa 9164 ..%&@.@........d
0x0020: b910 a050 0355 3b7d 807a d480 2171 8018 ...P.U;}.z..!q..
0x0030: 01f5 0ddd 0000 0101 080a 8501 a375 1f7a .............u.z
0x0040: 4d3f 1703 0300 9ae5 3ed0 830d ad39 0804 M?......>....9..
0x0050: 835b ed3f d4a0 e0e4 cd33 7baa 3807 1992 .[.?.....3{.8...
0x0060: 4b2c 6c5e a1fd 7bde 7c35 e71d e173 99ff K,l^..{.|5...s..
0x0070: e135 5f60 1d53 e878 c935 f1ec f630 a99b .5_`.S.x.5...0..
0x0080: b5a2 f97f 13b3 7a5c ce2f c8f4 9465 5d0d ......z\./...e].
0x0090: fe8f e051 cd3d 012f 0f24 9bda f6dd eef6 ...Q.=./.$......
0x00a0: 8d18 24c6 2ad0 0823 2325 19ff 3d9d 38ef ..$.*..##%..=.8.
0x00b0: 34b0 f26c c78f e94b 4d8f 0265 2429 aaad 4..l...KM..e$)..
0x00c0: eeae 9dbf 77aa 9cfd 352d 6c9b 373f 9e1e ....w...5-l.7?..
0x00d0: 4b13 0c90 e7b3 5eca 8470 1e34 1f54 c4a2 K.....^..p.4.T..
0x00e0: fb .
2021-01-04 01:08:58.633697 IP (tos 0x0, ttl 64, id 9511, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.254.41040 > 145.100.185.16.853: Flags [.], cksum 0x0d3e (incorrect -> 0x7a22), seq 691, ack 637, win 501, options [nop,nop,TS val 2231477158 ecr 528108875], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0034 2527 4000 4006 0886 c0a8 01fa 9164 .4%'@.@........d
0x0020: b910 a050 0355 3b7d 8119 d480 2364 8010 ...P.U;}....#d..
0x0030: 01f5 0d3e 0000 0101 080a 8501 a3a6 1f7a ...>...........z
0x0040: 4d4b MK
2021-01-04 01:09:08.634244 IP (tos 0x0, ttl 64, id 9512, offset 0, flags [DF], proto TCP (6), length 83)
192.168.1.254.41040 > 145.100.185.16.853: Flags [P.], cksum 0x0d5d (incorrect -> 0x8b01), seq 691:722, ack 637, win 501, options [nop,nop,TS val 2231487159 ecr 528108875], length 31
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0053 2528 4000 4006 0866 c0a8 01fa 9164 .S%(@.@..f.....d
0x0020: b910 a050 0355 3b7d 8119 d480 2364 8018 ...P.U;}....#d..
0x0030: 01f5 0d5d 0000 0101 080a 8501 cab7 1f7a ...]...........z
0x0040: 4d4b 1503 0300 1ae5 3ed0 830d ad39 0992 MK......>....9..
0x0050: 5625 b6e6 9c5e 6832 16b2 1009 0c54 6eaa V%...^h2.....Tn.
0x0060: 69 i
2021-01-04 01:09:08.634394 IP (tos 0x0, ttl 64, id 9513, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.254.41040 > 145.100.185.16.853: Flags [F.], cksum 0x0d3e (incorrect -> 0x52f1), seq 722, ack 637, win 501, options [nop,nop,TS val 2231487159 ecr 528108875], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0034 2529 4000 4006 0884 c0a8 01fa 9164 .4%)@.@........d
0x0020: b910 a050 0355 3b7d 8138 d480 2364 8011 ...P.U;}.8..#d..
0x0030: 01f5 0d3e 0000 0101 080a 8501 cab7 1f7a ...>...........z
0x0040: 4d4b MK
2021-01-04 01:09:08.681873 IP (tos 0x0, ttl 64, id 9514, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.254.41040 > 145.100.185.16.853: Flags [.], cksum 0x0d3e (incorrect -> 0x48f1), seq 723, ack 638, win 501, options [nop,nop,TS val 2231487206 ecr 528111387], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0034 252a 4000 4006 0883 c0a8 01fa 9164 .4%*@.@........d
0x0020: b910 a050 0355 3b7d 8139 d480 2365 8010 ...P.U;}.9..#e..
0x0030: 01f5 0d3e 0000 0101 080a 8501 cae6 1f7a ...>...........z
0x0040: 571b W.
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
Как бы всё.
И ссылки по теме:
1. Оригинальная статья "DNS over TLS: Protect your network with Ubuntu"
2. Альтернативный вариант - настройка прокси-сервера в облаке "How to Easily Set Up a DNS over TLS Resolver with Nginx on Ubuntu"
3. Настройка DNS over TLS на локальной машине (без кеширующего сервера) "DNS over TLS with systemd-resolved"
4. Еще один пример для локальной машины "Use DNS over TLS"
5. То же, что 3 и 4, "How to use DNS over TLS on Ubuntu Linux"
6. На одном сайте обзор решений по безопасности DNS "DNS Privacy Clients" и отдельно по Stubby "DNS Privacy Daemon - Stubby".
Комментариев нет:
Отправить комментарий