Istorija
Upotrebom novih tehnoloških rešenja, korisinici Interenta sada mogu na više načina sprečiti praćenje saobraćaja ISP na Interentu.
Kroz kratak istorijat upoznaćemo se sa DNS protokolima i ostalim fukncionlanostima, kako bismo bolje razumeli definicije i način rada DNS i ISP.
Početak istraživanja i rad na Internet mrežama karakteriše veliki broj hostova sa numeričkim adresama (npr. 2.2.2.2) gde je bilo potrebno da se svaki host u mreži memoriše i zapiše. Jedno od prvih rešenja bilo je grupisanje numeričkih adresa sa imenima hostova u HOSTS.TXT.
To je rađeno u početku ručno da bi se kasnije proces centralizovao.
Takvo rešenje nije bilo baš najbolje, pa je 1980 god. došlo do sporosti takvog procesa.
Evidetno je da je trebalo automatizovati sistem imenovanja i prebacivanja iz hostname (ime hosta, suprotno od numeričke adrese) u numeričku adresu.
Rešenje ovakvog problema doveli su do DNS (domain name server) od autora Paula Mockapetris i Džona Postela.
Godine 1983 Internet Engineering Task Force je publikovala orginalne specifikacije RFC 882 i RFC 883 koje služe kao tehnički dokument za razvoj softwera.
Na Univerzitetu Berkli 1984 god se razvija software BIND koji se koristi masovno na Internetu (masovno, većina DNS servera je BIND) i još uvek je ultra popularan kod ISP, hostera, cloud kompanija i mnogih drugih.
Ako znamo da je DNS tehnički osmišljen 1983 pitamo se zašto bi došlo do promena u pogledu ovog dela Interneta i softvera?
Gde koristimo svakodnevno DNS
Svaki put kada kucate neku adrese npr. – www.nesto.com – ova web adresa prolazi kroz transformaciju iz imena hosta u numeričku adresu.
To se dešava svaki put kada korisnik Interneta kuca web adresu.
U pozadini se dešavaju pretvaranja web adresa u numericke adrese (npr. 216.58.210.229 za gmail.com ) i pri tome svaki vaš zahtev ide ka ISP (Internet Servis Provajder) kod kojeg su postavljeni DNS serveri za upit.
Kako sprečiti ISP da vas prate na Internetu
Svaki takav zahtev ili svaki zahtev koji ide preko vašeg ISP može se “prisluškivati” i pratiti.
Ovo ne bi bilo strašno da ne živimo u turbulentnim vremenima gde su vlasti na Balkanu samo tek nekoliko koraka od represivnih režima.
Mnoge telekom kompanije poseduju ISO 27001 (pisaćemo na ovu temu uskoro) gde je moguće pratiti korisnika svake sekunde.
Možete reći da vas takve stvari ne brinu, ali imajte u vidu da se takve informacije mogu koristiti protiv vas.
Špijuniranje, lažiranje ili man-in-the-middle sajber napadi sa DNS iz 1983 god su mogući.
Za ovih 35 godina kako je definisan DNS protokol nije bilo značajnih izmena niti poboljšanja sigurnosti.
DNSCrypt
Treba napomenuti da je 2008 godine ekipa iz OpenBSD predložila SSL tuneliranje do DNS servera.
Iz tog poteza je nastao DNSCrypt. 2011 dolazi do prve implementacije a 2013 godine pojavljuje se DNScrypt v2 protokol koji je jako rasprostranjen.
Protokol koristi TCP ili UDP , u oba slučaja port 443.
Svaki paket između klijenta i servera je potpisan kao i enkriptovan.
Za razliku od DNS-Over-HTTPS gde klijenti paze na verifikaciju SSL sertifikata, kod DNSCrypt-a koristi se javni potpisani ključ (može se dobiti preko web stranice ili uz pomoć dig komande) koji nije verifikovan od strane sertifikovanog tela.
Umesto toga pinuje se javni ključ koji verifikuje da je dati DNSCrypt.
Verzije protokola 1 i 2 koriste X25519 algoritam za razmenu ključeva, EdDSA za potpis i XSalsa20-Poly1305 ili XChaCha20-Poly1305 za šifrovanje podataka.
Od marta 2018 godine, testira se DoH od strane kompanija koje učestvuju u razvijanju protokola su Google, Cloudflare, CleanBrowsing i Mozilla Foundation.
Svako ko prati vaš DNS saobraćaj neće moći da vidi kakve upite šaljete.
Može da vidi vaš saobraćaj ali ne i da utvrdi koji su domeni u pitanju.
Treba napomenuti da postoje obični HTTPS i HTTPS/2.
Draft standard za IETF https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/?include_text=1 predvidja HTTPS/2 koji je napredniji i brži u odnosu na standardni HTTPS.
Upit za DoH je odgovor u JSON format.
Pogledajte web interfejs prilagođen https://dns.google.com/query?name=www.digitalnasrbija.org&type=A&dnssec=true
kao i orginalni interfejs za ovakvu namenu https://dns.google.com/resolve?name=www.digitalnasrbija.org.
Treba napomenuti da Firefox (marta 2018) testira DoH podršku.
Sa ovim bi bilo moguće automatski zatvoriti problem korišćenja nezaštićenog DNS upita. Koristi sertifikat iz HTTPS da bi identifikovao i šifrovao komunikaciju.
DNS over TLS – DoT
Drugi standard koji je prošao kroz IETF i postoji u vidu “proposed protocol” jeste DNS over TLS ili samo DoT.
Protokol koristi port 853 sa svim dosadašnjim sigurnosnim implementacijama za DNS (DNSSEC – brine o integritetu DNS zapisa).
Takođe je prihvaćen kao standard, dosta DNS orijentisanih softvera ga podržava.
Po RFC 7858, DoT predlaže korišćenje dosta stvari koje već postoje unutar Linux operativnog sistema, a koji bi mogli da poboljšaju komunikaciju DNS klijenta sa DNS serverom.
Jedna od njih je TCP Fast Open (nećemo opisivati ovdje), druga je da prilikom slanja upita umesto klasičnog upita – komunikacija ostane otvorena za N period milisekundi gde bi se slao paralelni upit preko istog komunikacionog kanala.
To znači da se port na klijentu ustvari otvara i tom prilikom se vrši slanje više zahteva nego što bi bio slučaj kod obicnog DNS upita.
Ovo poboljšava performanse.
Ali, je vrlo važno napomenuti da pričamo TCP sloju i da još postoji posle uspostavljene komunikacije (3 way handshake) – ostvarivanje TLS komunikacije.
TLS (Transport Layer Security) omogućava da komunikacija ne bude praćena ili menjana i da je ista verifikovana tako da server strana važi za onu koju se predstavlja. Ovakivim pristupom se postiže da saobraćaj ne može biti lažiran od treće strane.
RFC https://tools.ietf.org/html/rfc7858 .
Trenutno na CloudFlare DNS 1.1.1.1 oko 0.3% do 0.4% saobraćaja DoT ili DoH.
Treba napomenuti da za DoT se koristi potpisani sertifikat i autorizovan od strane sertifikovanog tela.
Softverska podrška za DoT – DoH i DNSCrypt
Dnscrypt-proxy je podržan na više platformi (Mac, Linux, Android, Windows, drugi). Trenutna verzija je 2.0.9.
Pisan je u jeziku Go.
Podržava DNSCrypt protokol kao i DNS-Over-HTTPS.
Stubby je takođe podržan na više platformi. Pisan je u jeziku C.
Trenutna verzija je 0.2.2. Podržava DNS-Over-TLS.
DNS servis će biti pokrenut lokalno na portu 53. Servis će preko šifrovane komunikacije da radi upite na dns servere koji su podešeni u konfiguracionom fajlu.
Instalacija stubby
Ovde ćemo izvršiti instalaciju na Arch Linuxu. Instalacija je slična na Debian-u, Ubuntu. (otvorite terminal, shell, mračni ekran)
$ pacman -S stubby
Nakon instalacije potrebno je editovati fajl /etc/stubby/stubby.yaml i to ukloniti # ispred “dnssec_return_status: GETDNS_EXTENSION_TRUE” .
Ova linija služi za omogućavanje DNSSEC koji služi za integritet DNS informacija.
Čak i ako imamo zapise koji su poslati preko DNS-Over-TLS moramo se uveriti da je zapis nepromenjen i da stvarno pripadaju sajtu za koji smo uradili upit.
Nakon instalacije moramo proveriti status servisa.
U delu gde stoji:
$ upstream_recursive_servers:
Dodajemo 1.1.1.1 kao i javni ključ radi verifikacije upita.
Ako nemate instaliran kdig (iz paketa knot):
$ pacman -S knot
Zatim:
$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com nesto.com
Gde je izlaz:
DEBUG: Querying for owner(nesto.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP) DEBUG: TLS, imported 153 system certificates DEBUG: TLS, received certificate hierarchy: DEBUG: #1, C=US,ST=CA,L=San Francisco,O=Cloudflare\, Inc.,CN=*.cloudflare-dns.com DEBUG: SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc= DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA DEBUG: SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= DEBUG: TLS, skipping certificate PIN check DEBUG: TLS, The certificate is trusted. TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM) ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 59642 Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 EDNS PSEUDOSECTION: Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR PADDING: 410 B QUESTION SECTION: nesto.com. IN A ANSWER SECTION: nesto.com. 600 IN A 217.151.200.59 Received 468 B Time 2018-04-12 15:44:45 CEST From 1.1.1.1@853(TCP) in 102.3 ms”
Odavde uzimamo pinset tj. ključ za verifikaciju DNS servera 1.1.1.1:
SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
Ispod (kao što smo naveli) upstream_recursive_servers u fajlu /etc/stubby.yaml dodajemo:
$ - address_data: 1.1.1.1 tls_auth_name: "cloudflare-dns.com" tls_pubkey_pinset: - digest: "sha256" value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
Posle toga je potrebno da omogućimo servis i da ga restartujemo (za slučaj da je pokrenut).
systemctl enable stubby.service systemctl restart stubby.service systemctl status stubby.service
Trebalo bi da pokaže:
Sada sa komandom lsof vidimo da li je pokrenut:
$ lsof -i :53
Gde je izlaz:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMstubby 10108 stubby 3u IPv4 202713 0t0 UDP localhost:domain stubby 10108 stubby 4u IPv4 202714 0t0 TCP localhost:domain (LISTEN)
Kada smo podesili, takođe moramo proveriti da li radi sa komandom:
dig @127.0.0.1 gmail.com
Gde bi izlaz ove komande trebao da bude.
<<>> DiG 9.12.1 <<>> @127.0.0.1 gmail.com (1 server found) global options: +cmd Got answer: ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23478 flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION: EDNS: version: 0, flags: do; udp: 4096 COOKIE: dd245514df2364df5e1b67575acf5b8621359fd2edb49663 (good) CLIENT-SUBNET: 0.0.0.0/0/0 PAD (326 bytes) QUESTION SECTION: gmail.com. IN A ANSWER SECTION: gmail.com. 97 IN A 108.177.127.17 gmail.com. 97 IN A 108.177.127.18 gmail.com. 97 IN A 108.177.127.19 gmail.com. 97 IN A 108.177.127.83 Query time: 473 msec SERVER: 127.0.0.1#53(127.0.0.1) WHEN: Thu Apr 12 15:13:03 CEST 2018 MSG SIZE rcvd: 504
U slučaju da ovo ne radi, predlažemo komandu systemctl status stubby.service koja bi morala da pruži odgovor šta se dešava sa servisom.
Sledeći korak je podesiti da se taj servis koristi.
Najbolje je preko Network Manager podesiti DNS sa 127.0.0.1 međutim na linuxu je moguće podesiti i preko fajla /etc/resolv.conf gde je linija:
nameserver x.x.x.x gde je x.x.x.x neka IP , zameni sa 127.0.0.1
A to izgleda ovako:
nameserver 127.0.0.1
Nakon ove instalacije i provere svaki vaš upit je šifrovan kao i odgovor, tako da Internet Servis Provajder, kao druge kompanije ili pojedine osobe nisu u stanju da prate vaš saobraćaj.
Poslednja verifikacija rada DNS-Over-TLS vršimo sa komandom tcpdump (otvorite terminal) :
tcpdump dst port 853
U slučaju da nema saobraćaja potrebno je kreirati – komanda dig nesto.com ili nslookup nesto.com će završiti posao.
Uklanjanje stubby
Recimo da hoćete da probate kako radi dnscrypt-proxy i stubby vam u tom slučaju može predstavljati problem. Krenimo redom.
systemctl stop stubby.service
systemctl disable stubby.service
pacman -R stubby
Editujte liniju u resolv.conf iz nameserver 127.0.0.1 i stavite nameserver 1.1.1.1 ili bilo koji drugi DNS da vam odgovara.
Ovo je privremeno dok ne instaliramo dnscrypt-proxy.
Instalacija dnscrypt-proxy
Instaliraćemo isto kao i ranije:
pacman -S dnscrypt-proxy
Onda ćemo i pokrenuti sa:
systemctl enable dnscrypt-proxy.service systemctl start dnscrypt-proxy.service
Proveriti sa komandom:
lsof -i :53
Gde bi izlaz morao da bude:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root 90u IPv4 378562 0t0 TCP localhost:domain (LISTEN)
systemd 1 root 91u IPv4 380359 0t0 UDP localhost:domain
dnscrypt- 18422 dnscrypt-proxy 7u IPv4 378562 0t0 TCP localhost:domain (LISTEN)
dnscrypt- 18422 dnscrypt-proxy 8u IPv4 380359 0t0 UDP localhost:domain
U slučaju problema i sa:
journalctl -xe -t dnscrypt-proxy
Podešavanja isto kao i ranije za Network Manager i fajl /etc/resolver.conf gde stavljamo nameserver x.x.x.x da bude nameserver 127.0.0.1
Jedan od problema na koji smo naišli bio je ipv6 adresiranje u fajlu /etc/systemd/system/multi-user.target.wants/dnscrypt-proxy.service gde se, ili ukloni ili doda ispred linija za ipv6 #
Zaključak
Dnscrypt ima mogućnost keširanja DNS zapisa, podržava dva protokola dnscrypt i DNS-Over-HTTPS/2.
Zajednica koja je stvarana od 2011 godine do danas sa kompanijama koje podržavaju je velika.
Budućnost sigurno leži u sva tri protokola (dnscrypt, DNS-Over-TLS, DNS-Over-HTTPS).
Da bi zaštitili svoju privatnost podesite svoje DNS servere (lokalne, u vašem lanu) ili na svom laptop.
Ukoliko vam se članak dopao podelite ga sa prijateljima, jer ipak privatnost nam je na prvom mestu.
V. C.
Napišite komentar