Różne aspekty użytkowania DNS były już wielokrotnie poruszane przez autora w szeregu opublikowanych w ramach bloga. Przy tym główny nacisk zawsze kładziony był na zwiększenie bezpieczeństwa tej kluczowej usługi dla całego Internetu.
Do niedawna, pomimo oczywistej podatności ruchu DNS, który wciąż w dużej mierze przesyłany jest w otwartym formacie, na złośliwe działania ze strony dostawców, którzy dążą do zwiększenia swoich dochodów poprzez wbudowywanie reklam w treści, organów ścigania i cenzury, a także zwykłych przestępców, proces , mimo istnienia różnych technologii takich jak DNSSEC/DANE, DNScrypt, DNS-over-TLS i DNS-over-HTTPS, utknął w martwym punkcie. I jeśli rozwiązania serwerowe, a niektóre z nich istnieją już od dość dawna, są szeroko znane i dostępne, to wsparcie ze strony oprogramowania klienckiego pozostawia wiele do życzenia.
Na szczęście sytuacja się zmienia. W szczególności, deweloperzy popularnej przeglądarki Firefox plany włączenia domyślnie trybu wsparcia (DoH) w najbliższym czasie. To powinno pomóc w ochronie ruchu DNS użytkowników WWW przed wspomnianymi zagrożeniami, jednak potencjalnie może wywołać nowe.
1. Problemy z DNS-over-HTTPS
Na pierwszy rzut oka, masowe wdrożenie DNS-over-HTTPS w oprogramowaniu działającym w sieci Internet budzi tylko pozytywne reakcje. Jednak, jak to mówią, diabeł tkwi w szczegółach.
Pierwszym problemem, który ogranicza masowe zastosowanie DoH, jest jego skupienie wyłącznie na ruchu webowym. Rzeczywiście, protokół HTTP i jego najnowsza wersja HTTP/2, na której opiera się DoH, stanowią podstawę WWW. Jednak Internet to nie tylko sieć webowa. Istnieje wiele popularnych usług, takich jak e-mail, różne komunikatory, systemy przesyłania plików, strumieniowanie multimediów i inne, które nie korzystają z HTTP. W związku z tym, mimo że wiele osób postrzega DoH jako panaceum, okazuje się on nieprzydatny bez dodatkowych (a niepotrzebnych) wysiłków do niczego innego poza technologiami przeglądarkowymi. Zresztą, do tej roli znacznie lepszym kandydatem wydaje się DNS-over-TLS, który realizuje enkapsulację standardowego ruchu DNS w zabezpieczonym standardowym protokole TLS.
Drugim problemem, który potencjalnie jest znacznie ważniejszy od pierwszego, jest de facto rezygnacja z inherentnej dla DNS decentralizacji na rzecz korzystania z jednego, wskazanego w ustawieniach przeglądarki serwera DoH. W szczególności Mozilla proponuje korzystanie z usługi od Cloudflare. Tego rodzaju usługę uruchomiły także inne znaczące podmioty w Internecie, w tym Google. W efekcie, wprowadzenie DNS-over-HTTPS w obecnej formie zwiększa zależność końcowych użytkowników od największych usługodawców. Nie jest tajemnicą, że analiza zapytań DNS, której dokonują te usługi, może zbierać jeszcze więcej danych o użytkownikach, a także zwiększać ich dokładność i aktualność.
W związku z tym, autor pozostaje zwolennikiem masowego wprowadzenia nie DNS-over-HTTPS, a DNS-over-TLS wspólnie z DNSSEC/DANE jako uniwersalnego, bezpiecznego i nie sprzyjającego dalszej decentralizacji Internetu narzędzia do zabezpieczania ruchu DNS. Niestety, nie możemy oczekiwać szybkiego wprowadzenia masowej obsługi alternatyw dla DoH w oprogramowaniu klienckim z oczywistych powodów, a jej prawdziwym odbiorcą są na razie entuzjaści technologii zabezpieczeń.
Ale jeśli już zdobywamy DoH, to czemu by go nie wykorzystać, przechodząc równocześnie od potencjalnego śledzenia ze strony korporacji poprzez ich serwery do własnego serwera DNS-over-HTTPS?
2. Protokół DNS-over-HTTPS
Jeśli spojrzymy na standard opisujący protokół DNS-over-HTTPS, który zasadniczo stanowi API webowe umożliwiające enkapsulację standardowego pakietu DNS w protokole HTTP/2. Realizowane jest to za pomocą specjalnych nagłówków HTTP oraz konwersji binarnego formatu przekazywanych danych DNS (zob. i dokumentów późniejszych) w formę pozwalającą na ich przekazywanie i odbieranie oraz na pracę z niezbędnymi metadanymi.
Zgodnie ze standardem obsługiwany jest tylko HTTP/2 i zabezpieczone połączenie TLS.
Wysyłanie zapytań DNS można realizować standardowymi metodami GET i POST. W pierwszym przypadku zapytanie jest przekształcane w ciąg zakodowany w base64URL, a w drugim — przez ciało zapytania POST w formie binarnej. Przy tym w zapytaniu i odpowiedzi DNS używany jest specjalny typ MIME danych application/dns-message.
root@eprove:~ # curl -H 'accept: application/dns-message' 'https://my.domaint/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE' -v
* Próba połączenia z 2001:100:200:300::400:443...
* TCP_NODELAY ustawione
* Połączono z eprove.net (2001:100:200:300::400) port 443 (#0)
* ALPN, proponując h2
* ALPN, proponując http/1.1
* pomyślnie ustawiono lokalizacje weryfikacji certyfikatu:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: brak
* TLSv1.3 (OUT), handshake TLS, Klient hello (1):
* TLSv1.3 (IN), handshake TLS, Serwer hello (2):
* TLSv1.3 (IN), handshake TLS, Zaszyfrowane rozszerzenia (8):
* TLSv1.3 (IN), handshake TLS, Certyfikat (11):
* TLSv1.3 (IN), handshake TLS, Weryfikacja CERT (15):
* TLSv1.3 (IN), handshake TLS, Zakończenie (20):
* TLSv1.3 (OUT), zmiana szyfru TLS, Zmiana specyfikacji szyfru (1):
* TLSv1.3 (OUT), handshake TLS, Zakończenie (20):
* Połączenie SSL używa TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, serwer zaakceptował użycie h2
* Certyfikat serwera:
* podmiot: CN=my.domain
* data rozpoczęcia: Jul 22 00:07:13 2019 GMT
* data wygaśnięcia: Oct 20 00:07:13 2019 GMT
* subjectAltName: host "my.domain" pasuje do certyfikatu "my.domain"
* wydawca: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* weryfikacja certyfikatu SSL ok.
* Używanie HTTP2, serwer obsługuje wielokrotne użycie
* Stan połączenia zmieniony (HTTP/2 potwierdzony)
* Kopiowanie danych HTTP/2 do bufora połączenia po aktualizacji: len=0
* Użycie ID Strumienia: 1 (łatwe obsługowanie 0x801441000)
> GET /dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE HTTP/2
> Host: eprove.net
> User-Agent: curl/7.65.3
> accept: application/dns-message
>
* TLSv1.3 (IN), handshake TLS, Nowy bilet sesji (4):
* Stan połączenia zmieniony (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< serwer: 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
<
Uwaga: Wyjście binarne może zrujnować twój terminal. Użyj "--output -" aby powiedzieć
Uwaga: curl aby wyprowadził go do twojego terminala, lub rozważ "--output
Uwaga: <FILE>" aby zapisać do pliku.
* Nie udało się napisać ciała (0 != 45)
* zatrzymano strumień pauzy!
* Połączenie #0 z hostem eprove.net pozostało nienaruszoneZwróć także uwagę na nagłówek cache-control: w odpowiedzi serwera. W parametrze max-age znajduje się wartość TTL dla zwróconego rekordu DNS (lub minimalna wartość, jeśli zwracany jest ich zbiór).
Na podstawie powyższych informacji, działanie serwera DoH składa się z kilku etapów.
- Otrzymać żądanie HTTP. Jeśli to GET, zdekodować pakiet z kodowania base64URL.
- Wysłać ten pakiet do serwera DNS.
- Otrzymać odpowiedź od serwera DNS.
- Znaleźć minimalną wartość TTL w otrzymanych rekordach.
- Zwrócić odpowiedź klientowi przez HTTP.
3. Własny serwer DNS-over-HTTPS.
Najprostszym, najszybszym i najskuteczniejszym sposobem uruchomienia własnego serwera DNS-over-HTTPS jest skorzystanie z serwera WWW HTTP/2. , o którym autor już wcześniej pisał (patrz „«).
Na korzyść tego wyboru przemawia fakt, że cały kod własnego serwera DoH może być w pełni zrealizowany za pomocą zintegrowanego w samym H2O interpretera. . Oprócz standardowych bibliotek, do wymiany danych z serwerem DNS potrzebna jest biblioteka (mrbgem) Socket, która, na szczęście, jest już włączona w aktualną wersję deweloperską H2O 2.3.0-beta2. w portach FreeBSD. Niemniej jednak, nie jest trudno dodać ją do każdej wcześniejszej wersji, klonując repozytorium. do katalogu /deps przed kompilacją.
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
===> Licencja MIT BSD2CLAUSE akceptowana przez użytkownika
===> h2o-2.2.6 zależy od pliku: /usr/local/sbin/pkg - znaleziono
===> Pobieranie wszystkich plików potrzebnych do budowy h2o-2.2.6
===> Rozpakowywanie dla h2o-2.2.6.
=> SHA256 Suma kontrolna OK dla h2o-h2o-v2.2.6_GH0.tar.gz.
===> h2o-2.2.6 zależy od pliku: /usr/local/bin/ruby26 - znaleziono
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
Klonowanie do «mruby-socket»…
remote: Enumerowanie obiektów: 385, gotowe.
remote: Łącznie 385 (delta 0), ponownie użyto 0 (delta 0), zapakowane ponownie 385
Pobieranie obiektów: 100% (385/385), 98.02 KiB | 647.00 KiB/s, gotowe.
Określanie zmian: 100% (208/208), gotowe.
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # ll
total 181
drwxr-xr-x 9 root wheel 18 12 sie 16:09 brotli/
drwxr-xr-x 2 root wheel 4 12 sie 16:09 cloexec/
drwxr-xr-x 2 root wheel 5 12 sie 16:09 golombset/
drwxr-xr-x 4 root wheel 35 12 sie 16:09 klib/
drwxr-xr-x 2 root wheel 5 12 sie 16:09 libgkc/
drwxr-xr-x 4 root wheel 26 12 sie 16:09 libyrmcds/
drwxr-xr-x 13 root wheel 32 12 sie 16:09 mruby/
drwxr-xr-x 5 root wheel 11 12 sie 16:09 mruby-digest/
drwxr-xr-x 5 root wheel 10 12 sie 16:09 mruby-dir/
drwxr-xr-x 5 root wheel 10 12 sie 16:09 mruby-env/
drwxr-xr-x 4 root wheel 9 12 sie 16:09 mruby-errno/
drwxr-xr-x 5 root wheel 14 12 sie 16:09 mruby-file-stat/
drwxr-xr-x 5 root wheel 10 12 sie 16:09 mruby-iijson/
drwxr-xr-x 5 root wheel 11 12 sie 16:09 mruby-input-stream/
drwxr-xr-x 6 root wheel 11 12 sie 16:09 mruby-io/
drwxr-xr-x 5 root wheel 10 12 sie 16:09 mruby-onig-regexp/
drwxr-xr-x 4 root wheel 10 12 sie 16:09 mruby-pack/
drwxr-xr-x 5 root wheel 10 12 sie 16:09 mruby-require/
drwxr-xr-x 6 root wheel 10 12 wrz 16:10 mruby-socket/
drwxr-xr-x 2 root wheel 9 12 sie 16:09 neverbleed/
drwxr-xr-x 2 root wheel 13 12 sie 16:09 picohttpparser/
drwxr-xr-x 2 root wheel 4 12 sie 16:09 picotest/
drwxr-xr-x 9 root wheel 16 12 sie 16:09 picotls/
drwxr-xr-x 4 root wheel 8 12 sie 16:09 ssl-conservatory/
drwxr-xr-x 8 root wheel 18 12 sie 16:09 yaml/
drwxr-xr-x 2 root wheel 8 12 sie 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
...Konfiguracja serwera WWW, w ogólności, jest standardowa.
root@beta: /usr/ports/www/h2o # cd /usr/local/etc/h2o/
root@beta: /usr/local/etc/h2o # cat h2o.conf
# ta próbna konfiguracja daje ci poczucie, jak h2o może być używany
# oraz wysokiej bezpieczeństwa konfigurację dla TLS i nagłówków HTTP
# zobacz https://h2o.examp1e.net/ dla szczegółowej dokumentacji
# oraz h2o --help dla opcji wiersza poleceń i ustawień
# v.20180207 (c)2018 by 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.rbJedynym wyjątkiem jest obsługa URL /dns-query za który odpowiada nasz serwer DNS-over-HTTPS, napisany w mruby i wywoływany przez opcję handlera mruby.handler-file.
root@beta: /usr/local/etc/h2o # cat h2odoh.rb
# H2O HTTP/2 serwer internetowy jako usługa DNS-over-HTTP
# v.20190908 (c)2018-2019 Max Kostikov 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=/,'')
# dekoduj 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' }, [ "Złe żądanie" ]]
else
# --- zapytaj serwer DNS
sock = UDPSocket.new
sock.connect("localhost", 53)
sock.send(req, 0)
str = sock.recv(4096)
sock.close
# --- znajdź najniższy TTL w odpowiedzi
nans = str[6, 2].unpack1('n') # liczba odpowiedzi
if nans > 0 # brak błędu DNS
shift = 12
ttl = 0
while nans > 0
# przetwarzaj kompresję nazwy domeny
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' }, [ "Nieobsługiwany typ mediów" ]]
end
}Zauważ, że za przetwarzanie pakietów DNS odpowiada lokalny serwer cache, w tym przypadku z domyślnej instalacji FreeBSD. Z punktu widzenia bezpieczeństwa to optymalne rozwiązanie. Jednak nic nie stoi na przeszkodzie, aby zamienić localhost na adres innego serwera DNS, którego zamierzasz używać.
root@beta: /usr/local/etc/h2o # local-unbound verison
usage: local-unbound [options]
uruchom demona rozwiązywania DNS unbound.
-h ta pomoc
-c plik plik konfiguracyjny do odczytania zamiast /var/unbound/unbound.conf
format pliku jest opisany w unbound.conf(5).
-d nie forkować w tle.
-p nie tworzyć pliku pid.
-v szczegółowy (więcej razy zwiększa szczegółowość)
Wersja 1.8.1
powiązane biblioteki: mini-event wewnętrzny (używa select), OpenSSL 1.1.1a-freebsd 20 Nov 2018
powiązane moduły: dns64 respip validator iterator
Licencjonowane na zasadzie BSD, zobacz LICENSE w pakiecie źródłowym dla szczegółów.
Zgłaszaj błędy na 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 *:*Pozostaje zrestartować H2O i zobaczyć, co z tego wynikło.
root@beta:/usr/local/etc/h2o # service h2o restart
Zatrzymywanie h2o.
Czekanie na PIDY: 69871.
Uruchamianie h2o.
start_server (pid:70532) zaczyna teraz...4. Testowanie
Sprawdźmy zatem wyniki, wysyłając ponownie próbne zapytanie i obserwując ruch sieciowy za pomocą narzędzia tcpdump.
root@beta/usr/local/etc/h2o # curl -H 'accept: application/dns-message' 'https://my.domain/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE'
Ostrzeżenie: Wydajność binarna może zepsuć twój terminal. Użyj "--output -", aby powiedzieć
Ostrzeżenie: curl, aby wyjście trafiło do twojego terminala, lub rozważ "--output
Ostrzeżenie: " aby zapisać do pliku.
...
root@beta:~ # tcpdump -n -i lo0 udp port 53 -xx -XX -vv
tcpdump: nasłuchuje na lo0, typ linku NULL (BSD loopback), rozmiar przechwytywania 262144 bajtów
16:32:40.420831 IP (tos 0x0, ttl 64, id 37575, offset 0, flags [none], proto UDP (17), length 57, zły cksum 0 (-e9ea)!)
127.0.0.1.21070 > 127.0.0.1.53: [zły 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, zły cksum 0 (-e9cb)!)
127.0.0.1.53 > 127.0.0.1.21070: [zły 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
Przechwycono 2 pakiety
23 pakiety otrzymane przez filtr
0 pakietów odrzuconych przez jądroW wynikach widać, jak żądanie rozwiązania adresu example.com zostało odebrane i pomyślnie przetworzone przez serwer DNS.
Teraz trzeba aktywować nasz serwer w przeglądarce Firefox. W tym celu w ustawieniach konfiguracji należy zmienić kilka ustawień about:config.
Przede wszystkim adres naszego interfejsu API, z którego przeglądarka będzie żądać informacji DNS w network.trr.uri. Zaleca się również podanie adresu IP domeny z tego URL, aby bezpiecznie rozwiązać na IP za pomocą samej przeglądarki bez odwołania do DNS w network.trr.bootstrapAddress. A na końcu sam parametr network.trr.mode włączający użycie DoH. Ustawienie wartości "3" zmusi przeglądarkę do korzystania wyłącznie z DNS-over-HTTPS do rozwiązywania nazw, podczas gdy bardziej niezawodne i bezpieczne "2" nada priorytet DoH, pozostawiając standardowe żądanie do DNS jako opcjonalne.
5. ZYSK!
Artykuł był pomocny? Nie krępuj się i wesprzyj nas pieniędzmi za pośrednictwem formularza darowizny (poniżej).
Źródło: habr.com
