Forskellige aspekter af DNS-drift er allerede blevet berørt af forfatteren i flere offentliggjort på bloggen. Her har hovedvægten altid været lagt på at øge sikkerheden i denne essentielle internetservice.
Indtil for nylig, på trods af åbenlyse sårbarheder i DNS-trafik, som stadig hovedsageligt sendes åbent, var processen , på trods af tilstedeværelsen af forskellige teknologier som DNSSEC/DANE, DNScrypt, DNS-over-TLS og DNS-over-HTTPS, gået i stå. Og mens serverløsninger, nogle af dem har eksisteret i lang tid, er meget kendte og tilgængelige, efterlader understøttelsen af dem fra klientsoftware meget tilbage at ønske.
Heldigvis ændrer situationen sig. Især har udviklerne af den populære browser Firefox deres planer om at inkludere understøttelse af i standardindstillingen snart. Dette bør hjælpe med at beskytte brugerens DNS-trafik på WWW mod de nævnte trusler, men kan potentielt også medføre nye.
1. Problemer med DNS-over-HTTPS
Ved første øjekast ser den begyndende masseimplementering af DNS-over-HTTPS i Internet-softwarer kun ud til at fremkalde en positiv reaktion. Men, som man siger, ligger djævlen i detaljerne.
Det første problem, der begrænser den brede anvendelse af DoH, er dets fokus kun på webtrafik. Faktisk er protokollen HTTP og dens nuværende version HTTP/2, som DoH er baseret på, grundlaget for WWW. Men internettet er ikke kun web. Der er mange populære tjenester, såsom e-mail, forskellige messaging-tjenester, filoverførselssystemer, streaming af medier og mere, som ikke bruger HTTP. Dermed er DoH, på trods af at mange ser det som en mirakelkur, uanvendelig uden yderligere (og ligefrem unødvendige) anstrengelser til noget som helst andet end browserteknologier. For at sige det med det samme, virker DNS-over-TLS som en langt mere værdig kandidat til denne rolle, da det inkapsler standard DNS-trafik i den sikrede standardprotokol TLS.
Det andet problem, som potentielt er langt mere betydningsfuldt end det første, er den faktiske opgivelse af den decentrale struktur, der er indbygget i DNS by design, til fordel for brugen af en enkelt DoH-server angivet i browserindstillingerne. Specifikt tilbyder Mozilla at bruge en tjeneste fra Cloudflare. En lignende tjeneste er også blevet lanceret af andre bemærkelsesværdige aktører i internettet, herunder Google. Det viser sig, at implementeringen af DNS-over-HTTPS i den form, den bliver tilbudt nu, blot øger den endelige brugers afhængighed af de største tjenester. Det er ingen hemmelighed, at oplysningerne fra analyse af DNS-forespørgsler kan give endnu flere data om brugeren samt øge deres nøjagtighed og relevans.
I denne forbindelse har forfatteren været og forbliver fortaler for den brede implementering af ikke DNS-over-HTTPS, men DNS-over-TLS sammen med DNSSEC/DANE som et universelt, sikkert og ikke-centraliserende middel til at sikre DNS-trafik. Desværre kan man ikke forvente en hurtig implementering af bred støtte til alternativer til DoH i klientsoftware af forståelige årsager, og dens skæbne må indtil videre være i hænderne på entusiaster for sikre teknologier.
Men nu hvor vi alligevel får DoH, hvorfor så ikke bruge det, efter først at have undgået potentiel overvågning fra virksomheder gennem deres servere ved at opsætte sin egen DNS-over-HTTPS-server?
2. Protokol for DNS-over-HTTPS
Hvis man ser på standarden Hvis man beskriver protokollen DNS-over-HTTPS, kan man se, at den grundlæggende set fungerer som et web-API, der muliggør indkapsling af standard DNS-pakker i HTTP/2-protokollen. Dette realiseres gennem særlige HTTP-overskrifter samt konvertering af det binære format af de overførte DNS-data (se og efterfølgende dokumenter) til en form, der muliggør overførsel og modtagelse af dem samt arbejde med de nødvendige metadata.
Standarden understøtter kun HTTP/2 og en sikker TLS-forbindelse.
DNS-forespørgsler kan sendes ved hjælp af de standard metoder GET og POST. I det første tilfælde transformeres forespørgslen til en base64URL-kodet streng, mens den i det andet tilfælde sendes gennem POST-forespørgselens krop i binært format. Ved forespørgslen og svaret på DNS bruges en særlig MIME-type for dataene application/dns-message.
root@eprove:~ # curl -H 'accept: application/dns-message' 'https://my.domaint/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE' -v
* Forsøger 2001:100:200:300::400:443...
* TCP_NODELAY indstillet
* Forbundet til eprove.net (2001:100:200:300::400) port 443 (#0)
* ALPN, tilbyder h2
* ALPN, tilbyder http/1.1
* vellykket indstillet certifikatverifikationsplaceringer:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: ingen
* TLSv1.3 (UDEN), TLS håndtryk, Klienthej (1):
* TLSv1.3 (IND), TLS håndtryk, Serverhej (2):
* TLSv1.3 (IND), TLS håndtryk, Krypterede udvidelser (8):
* TLSv1.3 (IND), TLS håndtryk, Certifikat (11):
* TLSv1.3 (IND), TLS håndtryk, CERT verifikation (15):
* TLSv1.3 (IND), TLS håndtryk, Afsluttet (20):
* TLSv1.3 (UDEN), TLS ændrer kryptering, Ændre krypteringsspecifikation (1):
* TLSv1.3 (UDEN), TLS håndtryk, Afsluttet (20):
* SSL-forbindelse ved brug af TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepterede brug af h2
* Servercertifikat:
* emne: CN=my.domain
* startdato: Jul 22 00:07:13 2019 GMT
* udløbsdato: Oct 20 00:07:13 2019 GMT
* subjectAltName: vært "my.domain" matcher certifikatets "my.domain"
* udsteder: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certifikatverifikation ok.
* Bruger HTTP2, serveren understøtter multi-brug
* Forbindelsestilstand ændret (HTTP/2 bekræftet)
* Kopierer HTTP/2-data i stream buffer til forbindelsesbuffer efter opgradering: len=0
* Bruger Stream ID: 1 (let håndtere 0x801441000)
> GET /dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE HTTP/2
> Vært: eprove.net
> User-Agent: curl/7.65.3
> accept: application/dns-message
>
* TLSv1.3 (IND), TLS håndtryk, Ny session Ticket (4):
* Forbindelsestilstand ændret (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
<
Advarsel: Binært output kan ødelægge din terminal. Brug "--output -" for at fortælle
Advarsel: curl at vise det i din terminal alligevel, eller overvej "--output
Advarsel: <FILE>" for at gemme det til en fil.
* Mislykkedes at skrive krop (0 != 45)
* stoppede pause stream!
* Forbindelse #0 til vært eprove.net forlod intaktBemærk også overskriften cache-control: i svaret fra webserveren. Parameteren max-age indeholder TTL-værdien for den returnerede DNS-post (eller den minimale værdi, hvis en serie returneres).
Baseret på ovenstående består funktionen af en DoH-server af flere trin.
- Modtag HTTP-anmodningen. Hvis det er en GET-anmodning, skal du afkode pakken fra base64URL-kodning.
- Send denne pakke til DNS-serveren.
- Modtag svaret fra DNS-serveren.
- Find den mindste TTL-værdi i de modtagne poster.
- Returner svaret til klienten over HTTP.
3. Din egen DNS-over-HTTPS-server
Den mest enkle, hurtige og effektive måde at starte din egen DNS-over-HTTPS-server på er at bruge en HTTP/2 webserver. , som forfatteren allerede kort har skrevet om (se "«).
Det taler for dette valg, at al koden til din egen DoH-server kan implementeres fuldstændigt ved hjælp af den integrerede interpreter, der er indbygget i H2O. . Udover standardbibliotekerne kræves der et bibliotek (mrbgem) Socket for at kommunikere med DNS-serveren, som heldigvis allerede er inkluderet i den nuværende udviklingsversion af H2O 2.3.0-beta2. i FreeBSD-porte. Dog er det ikke svært at tilføje det til enhver tidligere version ved at klone bibliotekets 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
Kloning til "mruby-socket"…
remote: Enumerating objects: 385, done.
remote: Total 385 (delta 0), reused 0 (delta 0), pack-reused 385
Henter objekter: 100% (385/385), 98.02 KiB | 647.00 KiB/s, ferdig.
Bestemmer endringer: 100% (208/208), ferdig.
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # ll
total 181
drwxr-xr-x 9 root wheel 18 12 aug. 16:09 brotli/
drwxr-xr-x 2 root wheel 4 12 aug. 16:09 cloexec/
drwxr-xr-x 2 root wheel 5 12 aug. 16:09 golombset/
drwxr-xr-x 4 root wheel 35 12 aug. 16:09 klib/
drwxr-xr-x 2 root wheel 5 12 aug. 16:09 libgkc/
drwxr-xr-x 4 root wheel 26 12 aug. 16:09 libyrmcds/
drwxr-xr-x 13 root wheel 32 12 aug. 16:09 mruby/
drwxr-xr-x 5 root wheel 11 12 aug. 16:09 mruby-digest/
drwxr-xr-x 5 root wheel 10 12 aug. 16:09 mruby-dir/
drwxr-xr-x 5 root wheel 10 12 aug. 16:09 mruby-env/
drwxr-xr-x 4 root wheel 9 12 aug. 16:09 mruby-errno/
drwxr-xr-x 5 root wheel 14 12 aug. 16:09 mruby-file-stat/
drwxr-xr-x 5 root wheel 10 12 aug. 16:09 mruby-iijson/
drwxr-xr-x 5 root wheel 11 12 aug. 16:09 mruby-input-stream/
drwxr-xr-x 6 root wheel 11 12 aug. 16:09 mruby-io/
drwxr-xr-x 5 root wheel 10 12 aug. 16:09 mruby-onig-regexp/
drwxr-xr-x 4 root wheel 10 12 aug. 16:09 mruby-pack/
drwxr-xr-x 5 root wheel 10 12 aug. 16:09 mruby-require/
drwxr-xr-x 6 root wheel 10 12 sep. 16:10 mruby-socket/
drwxr-xr-x 2 root wheel 9 12 aug. 16:09 neverbleed/
drwxr-xr-x 2 root wheel 13 12 aug. 16:09 picohttpparser/
drwxr-xr-x 2 root wheel 4 12 aug. 16:09 picotest/
drwxr-xr-x 9 root wheel 16 12 aug. 16:09 picotls/
drwxr-xr-x 4 root wheel 8 12 aug. 16:09 ssl-conservatory/
drwxr-xr-x 8 root wheel 18 12 aug. 16:09 yaml/
drwxr-xr-x 2 root wheel 8 12 aug. 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
# denne eksempelkonfiguration giver dig en fornemmelse for, hvordan h2o kan bruges
# og en høj-sikkerhedskonfiguration for TLS og HTTP headers
# se https://h2o.examp1e.net/ for detaljeret dokumentation
# og h2o --help for kommandolinjeindstillinger
# v.20180207 (c)2018 af 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.rbDen eneste undtagelse er URL-behandleren /dns-query som er ansvarlig for vores DNS-over-HTTPS-server, skrevet i mruby og kaldt via behandlingsindstillingen mruby.handler-file.
root@beta:/usr/local/etc/h2o # cat h2odoh.rb
# H2O HTTP/2 web server som DNS-over-HTTP service
# 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=,'')
# 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
# --- spørg 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') # antal svar
if nans > 0 # ingen DNS-fejl
shift = 12
ttl = 0
while nans > 0
# behandle domænenavns-komprimering
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' }, [ "Unsupported Media Type" ]]
end
}Bemærk, at behandling af DNS-pakker håndteres af den lokale cache-server, i dette tilfælde fra standardleverancen af FreeBSD. Set fra et sikkerhedsmæssigt synspunkt er dette den optimale løsning. Dog kan man uden problemer erstatte localhost med adressen på en anden DNS, som du forventer at bruge.
root@beta:/usr/local/etc/h2o # local-unbound version
usage: local-unbound [options]
start unbound daemon DNS resolver.
-h denne hjælp
-c fil konfigurationsfil at læse i stedet for /var/unbound/unbound.conf
filformatet er beskrevet i unbound.conf(5).
-d fork ikke til baggrund.
-p opret ikke en pidfil.
-v detaljeret (flere gange for at øge detaljeringsgraden)
Version 1.8.1
linkede biblioteker: mini-event internal (det bruger select), OpenSSL 1.1.1a-freebsd 20 Nov 2018
linkede moduler: dns64 respip validator iterator
BSD licenseret, se LICENSE i kildepakkens detaljer.
Rapporter fejl til 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 *:*Det tilbageværende skridt er at genstarte H2O og se, hvad der er kommet 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. Testning
Lad os derfor tjekke resultaterne ved at sende en ny testforespørgsel og se netværkstrafikken med 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: " 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 kernelI outputet kan man se, hvordan anmodningen om opløsning af adressen example.com blev modtaget og behandlet succesfuldt af DNS-serveren.
Nu er det tid til at aktivere vores server i Firefox. For at gøre dette skal flere indstillinger ændres på konfigurationssiden. about:config.
For det første er dette adressen til vores API, som browseren vil anmode om DNS-oplysninger fra network.trr.uri. Det anbefales også at angive IP-adressen fra denne URL for sikkert at opløse til IP via browserens egne midler uden at henvise til DNS i network.trr.bootstrapAddress. Og endelig den faktiske parameter network.trr.mode der aktiverer brugen af DoH. At sætte værdien til «3» vil tvinge browseren til kun at bruge DNS-over-HTTPS til at opløse navne, mens en mere pålidelig og sikker «2» vil prioritere DoH og lade standard DNS-opkald være det sekundære alternativ.
5. PROFIT!
Var artiklen nyttig? Så vil jeg sætte pris på, hvis du ikke tøver med at støtte mig økonomisk gennem donationsformularen (nedenfor).
Kilde: habr.com
