Forskellige aspekter af DNS-drift er allerede gentagne gange blevet berørt af forfatteren i en række udgivet som en del af bloggen. Samtidig har hovedvægten altid været på at forbedre sikkerheden for denne vigtige internettjeneste.
Indtil for nylig, på trods af den åbenlyse sårbarhed af DNS-trafik, som stadig for det meste overføres i det klare, til ondsindede handlinger fra udbyderes side, der søger at øge deres indkomst ved at indlejre reklamer i indhold, offentlige sikkerhedsagenturer og censur, såvel som blot kriminelle, processen , på trods af tilstedeværelsen af forskellige teknologier såsom DNSSEC/DANE, DNScrypt, DNS-over-TLS og DNS-over-HTTPS, gik i stå. Og hvis serverløsninger, og nogle af dem har eksisteret i ret lang tid, er almindeligt kendte og tilgængelige, lader deres support fra klientsoftware meget tilbage at ønske.
Heldigvis er situationen ved at ændre sig. Især udviklerne af den populære Firefox-browser om planer om at aktivere supporttilstand som standard (DoH) snart. Dette skulle hjælpe med at beskytte WWW-brugerens DNS-trafik mod ovenstående trusler, men kan potentielt introducere nye.
1. DNS-over-HTTPS-problemer
Ved første øjekast forårsager den begyndende masseintroduktion af DNS-over-HTTPS i internetsoftware kun en positiv reaktion. Djævelen er dog, som de siger, i detaljerne.
Det første problem, der begrænser omfanget af DoH's udbredte brug, er dets fokus udelukkende på webtrafik. Faktisk er HTTP-protokollen og dens nuværende version HTTP/2, som DoH er baseret på, grundlaget for WWW. Men internettet er ikke kun nettet. Der er en masse populære tjenester, såsom e-mail, forskellige instant messengers, filoverførselssystemer, multimediestreaming osv., der ikke bruger HTTP. På trods af manges opfattelse af DoH som et vidundermiddel, viser det sig således at være uanvendeligt uden yderligere (og unødvendig) indsats for andet end browserteknologier. I øvrigt ligner DNS-over-TLS en meget mere værdig kandidat til denne rolle, som implementerer indkapslingen af standard DNS-trafik i den sikre standard TLS-protokol.
Det andet problem, som potentielt er meget mere væsentligt end det første, er den faktiske opgivelse af den iboende decentralisering af DNS ved design til fordel for at bruge en enkelt DoH-server angivet i browserindstillingerne. Især foreslår Mozilla at bruge en tjeneste fra Cloudflare. En lignende tjeneste blev også lanceret af andre prominente internetfigurer, især Google. Det viser sig, at implementeringen af DNS-over-HTTPS i den form, som det i øjeblikket foreslås, kun øger slutbrugernes afhængighed af de største tjenester. Det er ingen hemmelighed, at de oplysninger, som analyse af DNS-forespørgsler kan give, kan indsamle endnu flere data om det, samt øge dets nøjagtighed og relevans.
I denne henseende var og forbliver forfatteren tilhænger af masseimplementeringen, ikke af DNS-over-HTTPS, men af DNS-over-TLS sammen med DNSSEC/DANE som et universelt, sikkert og ikke befordrende for yderligere centralisering af internettet. for at sikre sikkerheden af DNS-trafik. Desværre kan man af indlysende grunde ikke forvente en hurtig introduktion af masseunderstøttelse af DoH-alternativer i klientsoftware, og det er stadig domænet for sikkerhedsteknologientusiaster.
Men da vi nu har DoH, hvorfor så ikke bruge det efter at have undsluppet potentiel overvågning fra virksomheder gennem deres servere til vores egen DNS-over-HTTPS-server?
2. DNS-over-HTTPS-protokol
Hvis man ser på standarden beskriver DNS-over-HTTPS-protokollen, kan du se, at det i virkeligheden er en web-API, der giver dig mulighed for at indkapsle en standard DNS-pakke i HTTP/2-protokollen. Dette implementeres gennem specielle HTTP-headers samt konvertering af det binære format af transmitterede DNS-data (se. og efterfølgende dokumenter) i en formular, der giver dig mulighed for at transmittere og modtage dem, samt arbejde med de nødvendige metadata.
Ifølge standarden understøttes kun HTTP/2 og en sikker TLS-forbindelse.
Afsendelse af en DNS-anmodning kan udføres ved hjælp af standardmetoderne GET og POST. I det første tilfælde transformeres anmodningen til en base64URL-kodet streng, og i det andet gennem brødteksten af POST-anmodningen i binær form. I dette tilfælde bruges en speciel MIME-datatype under DNS-anmodningen og -svaret applikation/dns-meddelelse.
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: <FILE>" to save to a file.
* Failed writing body (0 != 45)
* stopped the pause stream!
* Connection #0 to host eprove.net left intactVær også opmærksom på titlen cache-kontrol: i svaret fra webserveren. I parameteren max-alder indeholder TTL-værdien for den DNS-post, der returneres (eller minimumsværdien, hvis et sæt af dem returneres).
Baseret på ovenstående består funktionen af en DoH-server af flere trin.
- Modtag en HTTP-anmodning. Hvis dette er en GET, så afkode pakken fra base64URL-kodning.
- Send denne pakke til DNS-serveren.
- Få et svar fra DNS-serveren
- Find den mindste TTL-værdi i de modtagne poster.
- Returner et svar til klienten via HTTP.
3. Din egen DNS-over-HTTPS-server
Den enkleste, hurtigste og mest effektive måde at køre din egen DNS-over-HTTPS-server på er at bruge en HTTP/2-webserver , som forfatteren allerede har skrevet kort om (se "").
Dette valg understøttes af det faktum, at al koden på din egen DoH-server kan implementeres fuldt ud ved hjælp af tolken integreret i selve H2O . For at udveksle data med DNS-serveren skal du ud over standardbibliotekerne (mrbgem) Socket-biblioteket, som heldigvis allerede er inkluderet i den nuværende udviklingsversion af H2O 2.3.0-beta2 i FreeBSD-porte. Det er dog ikke svært at tilføje det til en tidligere version ved at klone depotet til kataloget /deps før kompilering.
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
===> License MIT BSD2CLAUSE accepted by the user
===> h2o-2.2.6 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by h2o-2.2.6 for building
===> Extracting for h2o-2.2.6.
=> SHA256 Checksum OK for h2o-h2o-v2.2.6_GH0.tar.gz.
===> h2o-2.2.6 depends on file: /usr/local/bin/ruby26 - found
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: Enumerating objects: 385, done.
remote: Total 385 (delta 0), reused 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
...Webserverkonfigurationen er generelt standard.
root@beta:/usr/ports/www/h2o # cd /usr/local/etc/h2o/
root@beta:/usr/local/etc/h2o # cat h2o.conf
# this sample config gives you a feel for how h2o can be used
# and a high-security configuration for TLS and HTTP headers
# see https://h2o.examp1e.net/ for detailed documentation
# and h2o --help for command-line options and settings
# v.20180207 (c)2018 by Max Kostikov http://kostikov.co e-mail: [email protected]
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.rbDen eneste undtagelse er URL-handleren / Dns-query som vores DNS-over-HTTPS-server, skrevet i mruby og kaldet via handleroptionen, faktisk er ansvarlig for mruby.handler-fil.
root@beta:/usr/local/etc/h2o # cat h2odoh.rb
# H2O HTTP/2 web server as DNS-over-HTTP service
# v.20190908 (c)2018-2019 Max Kostikov https://kostikov.co e-mail: [email protected]
proc {|env|
if env['HTTP_ACCEPT'] == "application/dns-message"
case env['REQUEST_METHOD']
when "GET"
req = env['QUERY_STRING'].gsub(/^dns=/,'')
# base64URL decode
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' }, [ "Bad Request" ]]
else
# --- ask DNS server
sock = UDPSocket.new
sock.connect("localhost", 53)
sock.send(req, 0)
str = sock.recv(4096)
sock.close
# --- find lowest TTL in response
nans = str[6, 2].unpack1('n') # number of answers
if nans > 0 # no DNS failure
shift = 12
ttl = 0
while nans > 0
# process domain name compression
if str[shift].unpack1("C") < 192
shift = str.index("x00", shift) + 5
if ttl == 0 # skip question section
next
end
end
shift += 6
curttl = str[shift, 4].unpack1('N')
shift += str[shift + 4, 2].unpack1('n') + 6 # responce data size
if ttl == 0 or ttl > 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' }, [ "Unsupported Media Type" ]]
end
}Bemærk venligst, at den lokale cachingserver er ansvarlig for at behandle DNS-pakker, i dette tilfælde fra standard FreeBSD distributionen. Ud fra et sikkerhedsmæssigt synspunkt er dette den optimale løsning. Intet forhindrer dig dog i at udskifte localhost til en anden DNS-adresse, som du har til hensigt at bruge.
root@beta:/usr/local/etc/h2o # local-unbound verison
usage: local-unbound [options]
start unbound daemon DNS resolver.
-h this help
-c file config file to read instead of /var/unbound/unbound.conf
file format is described in unbound.conf(5).
-d do not fork into the background.
-p do not create a pidfile.
-v verbose (more times to increase verbosity)
Version 1.8.1
linked libs: mini-event internal (it uses select), OpenSSL 1.1.1a-freebsd 20 Nov 2018
linked modules: dns64 respip validator iterator
BSD licensed, see LICENSE in source package for details.
Report bugs to [email protected]
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 *:*Det eneste, der er tilbage, er at genstarte H2O og se, hvad der kommer ud af det.
root@beta:/usr/local/etc/h2o # service h2o restart
Stopping h2o.
Waiting for PIDS: 69871.
Starting h2o.
start_server (pid:70532) starting now...4. Test
Så lad os tjekke resultaterne ved at sende en testanmodning igen og se på netværkstrafikken ved hjælp af værktøjet 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: <FILE>" 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 kernelOutputtet viser, hvordan anmodningen om at løse adressen example.com blev modtaget og behandlet af DNS-serveren.
Nu er der kun tilbage at aktivere vores server i Firefox-browseren. For at gøre dette skal du ændre flere indstillinger på konfigurationssiderne about: config.
For det første er dette adressen på vores API, hvor browseren vil anmode om DNS-oplysninger netværk.trr.uri. Det anbefales også at angive domæne-IP fra denne URL for sikker IP-opløsning ved hjælp af selve browseren uden at få adgang til DNS i network.trr.bootstrapAddress. Og endelig selve parameteren netværk.trr.tilstand herunder brugen af DoH. Indstilling af værdien til "3" vil tvinge browseren til udelukkende at bruge DNS-over-HTTPS til navneopløsning, mens den mere pålidelige og sikre "2" vil prioritere DoH, hvilket efterlader standard DNS-opslag som en reservemulighed.
5. RESULTAT!
Var artiklen nyttig? Så vær ikke genert og støt penge gennem donationsformularen (nedenfor).
Kilde: www.habr.com