privacyguides.org/dns-overview.nl.md at 2a4947bd72af4c24e84f14eed9b07202f9e4abbd

mirror of https://github.com/privacyguides/privacyguides.org.git synced 2024-07-31 15:42:52 +00:00

Privacy Guides [bot] 7b6a158e4d

Add Crowdin Translations (#2026 )

Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
Co-authored-by: Jonah Aragon <jonah@triplebit.net>

2023-02-24 16:47:54 -06:00

20 KiB

Raw Blame History

title	icon
Inleiding tot DNS	material/dns

Het Domain Name System is het "telefoonboek van het internet". DNS vertaalt domeinnamen naar IP-adressen zodat browsers en andere diensten internetbronnen kunnen laden, via een gedecentraliseerd netwerk van servers.

Wat is DNS?

Wanneer je een website bezoekt, wordt een numeriek adres teruggezonden. Wanneer je bijvoorbeeld privacyguides.orgbezoekt, wordt het adres 192.98.54.105 teruggezonden.

DNS bestaat al sinds de begindagen van het internet. DNS-verzoeken aan en van DNS-servers zijn niet over het algemeen gecodeerd. In een residentiële omgeving krijgt een klant servers van de ISP via DHCP.

Onversleutelde DNS-verzoeken kunnen onderweg gemakkelijk worden gesurveilleerd en gewijzigd. In sommige delen van de wereld worden ISP's opgedragen primitieve DNS-filters te gebruiken. Wanneer je het IP-adres opvraagt van een domein dat is geblokkeerd, antwoordt de server mogelijk niet of met een ander IP-adres. Aangezien het DNS-protocol niet versleuteld is, kan de ISP (of om het even welke netwerkexploitant) DPI gebruiken om verzoeken te controleren. ISP's kunnen ook verzoeken blokkeren op basis van gemeenschappelijke kenmerken, ongeacht welke DNS-server wordt gebruikt. Onversleutelde DNS gebruikt altijd poort 53 en gebruikt altijd UDP.

Hieronder bespreken we en geven we een tutorial om te bewijzen wat een externe waarnemer kan zien met gewone onversleutelde DNS en versleutelde DNS.

Onversleutelde DNS

Met tshark (onderdeel van het Wireshark project) kunnen we de internet packet flow monitoren en opnemen. Dit commando registreert pakketten die aan de gespecificeerde regels voldoen:
```
tshark -w /tmp/dns.pcap udp poort 53 en host 1.1.1.1 of host 8.8.8.8
```
We kunnen dan dig (Linux, MacOS etc) of nslookup (Windows) gebruiken om de DNS lookup naar beide servers te sturen. Software zoals webbrowsers doen deze lookups automatisch, tenzij zij geconfigureerd zijn om gecodeerde DNS te gebruiken.

=== "Linux, macOS"
```
 ```
 dig +noall +answer privacyguides.org @1.1.1.1
 dig +noall +answer privacyguides.org @8.8.8.8
 ```
```
=== "Windows"
```
 ```
 nslookup privacyguides.org 1.1.1.1
 nslookup privacyguides.org 8.8.8.8
 ```
```

Vervolgens willen wij analyseren de resultaten:

=== "Wireshark"

 ```
 wireshark -r /tmp/dns.pcap
 ```

=== "tshark"

 ```
 tshark -r /tmp/dns.pcap
 ```

Als je het bovenstaande Wireshark-commando uitvoert, toont het bovenste deelvenster de "frames", en het onderste deelvenster toont alle gegevens over het geselecteerde frame. Oplossingen voor bedrijfsfiltering en -monitoring (zoals die welke door overheden worden aangeschaft) kunnen dit proces automatisch uitvoeren, zonder menselijke tussenkomst, en kunnen deze frames samenvoegen tot statistische gegevens die nuttig zijn voor de netwerkwaarnemer.

Nee.	Tijd	Bron	Bestemming	Protocol	Lengte	Info
1	0.000000	192.0.2.1	1.1.1.1	DNS	104	Standaard zoekopdracht 0x58ba A privacyguides.org OPT
2	0.293395	1.1.1.1	192.0.2.1	DNS	108	Standaard vraag antwoord 0x58ba A privacyguides.org A 198.98.54.105 OPT
3	1.682109	192.0.2.1	8.8.8.8	DNS	104	Standaard zoekopdracht 0xf1a9 A privacyguides.org OPT
4	2.154698	8.8.8.8	192.0.2.1	DNS	108	Standaard query-antwoord 0xf1a9 A privacyguides.org A 198.98.54.105 OPT

Een waarnemer kan elk van deze pakketten wijzigen.

Wat is "versleutelde DNS"?

Versleutelde DNS kan verwijzen naar een van een aantal protocollen, waarvan de meest voorkomende zijn:

DNSCrypt

DNSCrypt was een van de eerste methoden om DNS-query's te versleutelen. DNSCrypt werkt op poort 443 en werkt met zowel de TCP- als de UDP-transportprotocollen. DNSCrypt is nooit ingediend bij de Internet Engineering Task Force (IETF) en is ook nooit door het Request for Comments (RFC) proces gegaan, dus is het buiten een paar implementaties nog niet op grote schaal gebruikt. Als gevolg daarvan is het grotendeels vervangen door het meer populaire DNS over HTTPS.

DNS over TLS (DoT)

DNS over TLS is een andere methode voor het versleutelen van DNS-communicatie die is gedefinieerd in RFC 7858. Ondersteuning werd voor het eerst geïmplementeerd in Android 9, iOS 14, en op Linux in systemd-resolved in versie 237. De laatste jaren is de voorkeur in de sector verschoven van DoT naar DoH, omdat DoT een complex protocol is en de naleving van de RFC in de bestaande implementaties varieert. DoT werkt ook op een speciale poort 853 die gemakkelijk kan worden geblokkeerd door restrictieve firewalls.

DNS over HTTPS (DoH)

DNS over HTTPS zoals gedefinieerd in RFC 8484 verpakt query's in het HTTP/2 protocol en biedt beveiliging met HTTPS. Ondersteuning werd voor het eerst toegevoegd in webbrowsers zoals Firefox 60 en Chrome 83.

Native implementatie van DoH dook op in iOS 14, macOS 11, Microsoft Windows, en Android 13 (het zal echter niet standaard worden ingeschakeld ). Algemene Linux desktop ondersteuning wacht op de systemd implementatie dus het installeren van third-party software is nog steeds vereist.

Wat kan een buitenstaander zien?

In dit voorbeeld zullen we vastleggen wat er gebeurt als we een DoH-verzoek doen:

Start eerst tshark:

tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"

Ten tweede, doe een aanvraag met curl:

curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org

Na het verzoek te hebben gedaan, kunnen we de packet capture stoppen met CTRL + C.
Analyseer de resultaten in Wireshark:
```
wireshark -r /tmp/dns_doh.pcap
```

We zien de verbinding tot stand brengen en TLS handshake die bij elke versleutelde verbinding optreedt. Als we kijken naar de "toepassings gegevens" pakketten die volgen, bevat geen van hen het domein dat we hebben aangevraagd of het IP adres dat wordt teruggestuurd.

Waarom zou ik geen versleutelde DNS gebruiken?

Op plaatsen waar internet wordt gefilterd (of gecensureerd), kan het bezoeken van verboden bronnen eigen gevolgen hebben waarmee je rekening moet houden in jouw bedreigingsmodel. Wij niet suggereren het gebruik van gecodeerde DNS voor dit doel. Gebruik in plaats daarvan Tor of een VPN. Als je een VPN gebruikt, moet je de DNS-servers van jouw VPN gebruiken. Wanneer je een VPN gebruikt, vertrouwt je hen al jouw netwerkactiviteiten toe.

Wanneer we een DNS lookup doen, is dat meestal omdat we toegang willen tot een bron. Hieronder bespreken we enkele van de methoden die jouw surf-activiteiten kunnen onthullen, zelfs wanneer je versleutelde DNS gebruikt:

IP-adres

De eenvoudigste manier om de surfactiviteit vast te stellen, is te kijken naar de IP-adressen waartoe jouw apparaten toegang hebben. Als de waarnemer bijvoorbeeld weet dat privacyguides.org op 198.98.54.105staat, en jouw apparaat gegevens opvraagt van 198.98.54.105, is de kans groot dat je Privacy Guides bezoekt.

Deze methode is alleen nuttig wanneer het IP-adres toebehoort aan een server die slechts enkele websites host. Het is ook niet erg nuttig als de site wordt gehost op een gedeeld platform (bijv. Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, enz). Het is ook niet erg nuttig als de server gehost wordt achter een reverse proxy, wat heel gebruikelijk is op het moderne Internet.

Server Naam Aanwijzing (SNA)

Server Name Indication wordt meestal gebruikt wanneer een IP-adres veel websites host. Dit kan een dienst als Cloudflare zijn, of een andere Denial-of-service-aanval bescherming.

Begin opnieuw te vangen met tshark. We hebben een filter toegevoegd met ons IP adres zodat je niet veel pakketten opvangt:
```
tshark -w /tmp/pg.pcap poort 443 en host 198.98.54.105
```
Dan gaan we naar https://privacyguides.org.
Na het bezoek aan de website, willen we de packet capture stoppen met CTRL + C.
Vervolgens willen we de resultaten analyseren:
```
wireshark -r /tmp/pg.pcap
```
We zullen de verbinding tot stand zien komen, gevolgd door de TLS handshake voor de Privacy Gidsen website. Rond frame 5. zie je een "Client Hello".

Vouw de driehoek ▸ uit naast elk veld:

▸ Transport Layer Security
  ▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello
    ▸ Handshake Protocol: Client Hello
      ▸ Uitbreiding: server_name (len=22)
        ▸ Uitbreiding servernaam-aanduiding

Wij kunnen de SNI-waarde zien die aangeeft welke website wij bezoeken. Het tshark commando kan je de waarde rechtstreeks geven voor alle pakketten die een SNI waarde bevatten:
```
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```

Dit betekent dat zelfs als we "Encrypted DNS" servers gebruiken, het domein waarschijnlijk zal worden onthuld via SNI. Het TLS v1.3 protocol brengt het Encrypted Client Hello met zich mee, dat dit soort lekken voorkomt.

Regeringen, met name China en Rusland, zijn al begonnen met het blokkeren van of hebben de wens geuit dit te doen. Onlangs is Rusland begonnen met het blokkeren van buitenlandse websites die gebruik maken van de HTTP/3 norm. Dit komt doordat het QUIC protocol dat deel uitmaakt van HTTP/3 vereist dat ClientHello ook gecodeerd wordt.

Protocol voor onlinecertificaatstatus (PVOC/OCSP)

Een andere manier waarop jouw browser jouw surfactiviteiten kan onthullen is met het Online Certificate Status Protocol. Wanneer je een HTTPS-website bezoekt, kan de browser controleren of het -certificaat van de website is ingetrokken. Dit gebeurt over het algemeen via het HTTP-protocol, wat betekent dat het niet versleuteld is.

Het OCSP-verzoek bevat het certificaat "serienummer", dat uniek is. Het wordt naar de "OCSP responder" gezonden om de status ervan te controleren.

We kunnen simuleren wat een browser zou doen met het openssl commando.

Haal het server certificaat op en gebruik sed om alleen het belangrijke deel te bewaren en schrijf het uit naar een bestand:

openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert

Haal het tussenliggende certificaat op. Certificaatautoriteiten (CA) ondertekenen een certificaat gewoonlijk niet rechtstreeks; zij gebruiken een zogeheten "intermediair" certificaat.
```
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
Het eerste certificaat in pg_and_intermediate.cert is eigenlijk het servercertificaat uit stap 1. We kunnen sed opnieuw gebruiken om te wissen tot de eerste instantie van END:
```
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
    /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
Haal de OCSP responder voor het server certificaat op:
```
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
Ons certificaat toont de Lets Encrypt certificaat responder. Als we alle details van het certificaat willen zien, kunnen we gebruik maken van:
```
openssl x509 -text -noout -in /tmp/pg_server.cert
```

Start de pakketopname:

tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"

Doe het OCSP-verzoek:

openssl ocsp -issuer /tmp/intermediate_chain.cert \
             -cert /tmp/pg_server.cert \
             -text \
             -url http://r3.o.lencr.org

Open de opname:

wireshark -r /tmp/pg_ocsp.pcap

Er komen twee pakketten met het "OCSP"-protocol: een "Request" en een "Response". Voor de "Aanvraag" kunnen we het "serienummer" zien door het driehoekje ▸ naast elk veld uit te vouwen:

▸ Online Certificate Status Protocol
  ▸ tbsRequest
    ▸ requestList: 1 item
      ▸ Verzoek
        ▸ reqCert
          serialNumber

Voor de "Response" kunnen we ook het "serienummer" zien:

▸ Online Certificate Status Protocol
  ▸ responseBytes
    ▸ BasicOCSPResponse
      ▸ tbsResponseData
        ▸ antwoorden: 1 item
          ▸ SingleResponse
            ▸ certID
              serialNumber

Of gebruik tshark om de pakketten te filteren op het Serienummer:

tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber

Als de netwerkwaarnemer het publieke certificaat heeft, dat publiekelijk beschikbaar is, kunnen zij het serienummer met dat certificaat vergelijken en op basis daarvan de site bepalen die je bezoekt. Het proces kan worden geautomatiseerd en IP-adressen kunnen worden gekoppeld aan serienummers. Het is ook mogelijk om Certificate Transparency logs te controleren op het serienummer.

Moet ik versleutelde DNS gebruiken?

We hebben dit stroomschema gemaakt om te beschrijven wanneer u versleutelde DNS zou moeten gebruiken:

grafiek TB
    Start[Start] --> anoniem{Probeert<br> anoniem te zijn?}
    anonymous--> | Yes | tor(Use Tor)
    anonymous --> | No | censorship{Avoiding<br> censorship?}
    censuur --> | Ja | vpnOrTor(Gebruik<br> VPN of Tor)
    censuur --> | Nee | privacy{Wil je privacy<br> van ISP?}
    privacy --> | Yes | vpnOrTor
    privacy --> | No | obnoxious{ISP makes<br> obnoxious<br> redirects?}
    onaangenaam --> | Yes | encryptedDNS(Gebruik<br> gecodeerde DNS<br> met derde partij)
    onaangenaam --> | No | ispDNS{Doet ISP ondersteunen<br> gecodeerde DNS?}
    ispDNS --> | Yes | useISP(Gebruik<br> gecodeerde DNS<br> met ISP)
    ispDNS --> | No | nothing(Doe niets)

Versleutelde DNS met een derde partij mag alleen worden gebruikt om redirects en basis-DNS-blokkering van te omzeilen als je er zeker van kunt zijn dat er geen gevolgen zijn of als je geïnteresseerd bent in een provider die een aantal rudimentaire filters uitvoert.

Lijst van aanbevolen DNS-servers{.md-button}

Wat is DNSSEC?

DNSSEC (Domain Name System Security Extensions) is een functie van DNS waarmee reacties op domeinnaamzoekopdrachten worden geverifieerd. Het biedt geen bescherming van de privacy voor die lookups, maar voorkomt dat aanvallers de antwoorden op DNS-verzoeken manipuleren of vergiftigen.

Met andere woorden, DNSSEC ondertekent gegevens digitaal om de geldigheid ervan te helpen garanderen. Om een veilige lookup te garanderen, vindt de ondertekening plaats op elk niveau in het DNS lookup-proces. Als gevolg daarvan kunnen alle antwoorden van DNS worden vertrouwd.

Het DNSSEC-ondertekeningsproces is vergelijkbaar met iemand die een juridisch document met een pen ondertekent; die persoon ondertekent met een unieke handtekening die niemand anders kan maken, en een gerechtsdeskundige kan naar die handtekening kijken en verifiëren dat het document door die persoon is ondertekend. Deze digitale handtekeningen garanderen dat er niet met de gegevens is geknoeid.

DNSSEC implementeert een hiërarchisch digitaal ondertekeningsbeleid over alle lagen van DNS. Bijvoorbeeld, in het geval van een privacyguides.org lookup, zou een root DNS-server een sleutel ondertekenen voor de .org nameserver, en de .org nameserver zou dan een sleutel ondertekenen voor privacyguides.org's gezaghebbende nameserver.

Aangepast uit DNS Security Extensions (DNSSEC) overview van Google en DNSSEC: An Introduction van Cloudflare, beide met een licentie onder CC BY 4.0.

Wat is QNAME-minimalisatie?

Een QNAME is een "gekwalificeerde naam", bijvoorbeeld privacyguides.org. QNAME-minimalisatie vermindert de hoeveelheid informatie die van de DNS-server naar de authoratieve naamserver wordt gestuurd.

In plaats van het hele domein privacyguides.org te sturen, betekent QNAME-minimalisatie dat de DNS-server alle records opvraagt die eindigen op .org. Een verdere technische beschrijving is te vinden in RFC 7816.

Wat is EDNS Client Subnet (ECS)?

Het EDNS Client Subnet is een methode voor een recursieve DNS-oplosser om een subnetwerk te specificeren voor de host of client die de DNS-query uitvoert.

Het is bedoeld om de levering van gegevens te "versnellen" door de client een antwoord te geven dat toebehoort aan een server die zich dicht bij hem bevindt, zoals een content delivery network, die vaak worden gebruikt bij videostreaming en het serveren van JavaScript-webapps.

Deze functie gaat wel ten koste van de privacy, aangezien de DNS-server informatie krijgt over de locatie van de client.

20 KiB Raw Blame History