2022. szeptember 27., kedd

Gyorskeresés

Út a titkosított internet felé: kalandok a DNS-sel

Írta: | Kulcsszavak: cloudflare . dns . dns over tls . tomatousb . freshtomato . rt-n18u . asus . 1.1.1.1

[ ÚJ BEJEGYZÉS ]

DNS. Egyidős protokoll a ma létező internettel, ami annak idején azért jött létre, hogy ne hosszú számsorokból álló IP címeket kelljen megjegyezni a kedvenc fórumunk meglátogatásához, hanem elég legyen csak megjegyezni a prohardver.hu címet és már ott is vagyunk a kívánt oldalon. Azóta természetesen rengeteg új feladata lett, rengeteg új rekordtípus született, de maga a protokoll nem igen változott az évtizedek során. Azóta is teljes rálátással van mindenki a DNS forgalomra, mivel az nincsen megfelelően titkosítva. Így a netszolgáltató, sőt esetlegesen a hálózat többi szereplője (pl. wifin) beleláthat a feloldási előzményeinkbe. Bár ez önmagában csak annyit jelent, hogy a szolgáltatónak például lesz egy képe arról, hogy mely fő domaineket látogatjuk napi szinten, (pl google.com), a teljes címet nem fogja egy DNS lekérés tartalmazni (tehát pl google.com/search). Illetve a titkosítás és annak validálásának hiánya miatt sokkal könnyebb eltéríteni a DNS válaszokat. Ez egy probléma, amelyet a Cloudflare ismert fel először és alkották meg a DNS over TLS specifikációját és alkalmazták azt elsőként az 1.1.1.1-es DNS szerverükön. Tovább is olvastam részletek után kutatva és meg is találtam a specifikációt: [link] Kiderült, hogy ugyan friss még a dolog, az Android 9+ már támogatja a funkciót, illetve néhány böngésző bétája is. Elhatároztam tehát, hogy teszek vele egy próbát mindenképp.

Ugyanakkor itt fontos leszögezni, hogy bár a szolgáltató még a titkosított DNS mellett is képes lesz követni, hogy mely IP címekkel van forgalmunk (ami teljesen rendben van, nem is várható el, hogy ne így legyen), azt viszont, hogy pontosan mely címeket látogatjuk, nem tudják majd. Illetve így a Cloudflare, mivel én az ő DNS-ük használata mellett döntöttem tudni fogja természetesen minden netezési szokásom, tehát ez sem 100%-os megoldás az elbújásra, viszont a Cloudflare ajánlja jelenleg a leggyorsabb DNS szervert, így korábbról is az ő megoldásukat használtam (csak titkosítatlanul, tehát még a szolgáltatóm is beleláthatott), illetve ha hihetünk a szavuknak, egy nap után mindenfajta logot törölnek. Természetesen teljesen transzparens megoldás nem igen létezik, hiszen az internet használatával már fel kell áldoznunk egy bizonyos mennyiséget a személyes privacy ellen, viszont így, hogy magam válogatom meg kinek adom ki az adataim, már nyugodtabban alszom.

Érdekesség még, hogy Cloudflare DNS használata előtt, a szolgáltatóm DNS-ét használva ez a teszt oldal is rengeteg hibát írt: [link] A DNSSEC teszten sem sikerült átmenni: [link] És minden oldalbetöltés érezhetően időbe telt, ha a cím éppen nem volt gyorsítótárazva. A Cloudflarrel minden problémám megszűnt és szupergyors a betöltés!

Tehát adva volt a lehetőség, már csak az alkalmazásnak kellett utánajárni! Szerencsére otthoni kis hálózatom magját egy nagyon kedvező árfekvésű RT-N18U jelenti, a FreshTomato nevű svájci bicska rendszerrel. Ami most is meglepett, hiszen a még alig elterjedt technológiát GUI-n keresztül is sikerült benne megtalálnom (Basic -> Network fül):

Bár a Cloudflare DNS-e sajnos nincs támogatva még a beépített dnscrypt-proxy által, nekem sajnos nem sikerült működésre bírni, így a Stubby megoldás felé kezdtem el kacsintgatni és igen, határozottan ez lett az, amire végül szükségem volt. GUI-n mindössze ennyit kellett kattintgatnom:

Itt nagyon fontos volt, hogy a DNSSEC ne legyen engedélyezve, különben az egész Stubby konfig ignorálva lesz és minden forgalmunk továbbra is a hagyományos módon fog elmenni a DNS szerverhez. Erre némi fejfájással jöttem csupán rá a saját bőrömön, de szerencsére erre is van megoldás. Mégpedig az Advanced -> DHCP/DNS oldalt kiválasztva a dnsmasq Custom configuration dobozába illesszük be ezt a sort:

proxy-dnssec

Majd ne felejtsünk el a lap alján menteni.

Most pedig következhet a Stubby konfig módosítása, ugyanis erre is szükség van, ha szeretnénk DNSSEC támogatást, illetve kizárólag a Cloudflare DNS-ére hagyatkozni. Ehhez nyitni kell a routeren SSH-t (Administration -> Admin Access -> SSH Daemon), majd be is kell lépni egy tetszőlegesen választott SSH klienssel és a root felhasználónév, illetve az adminhoz tartozó jelszó párossal. A sikeres bejelentkezést követően szükségünk lesz a szintén Administration fül alatt található JFFS menü engedélyezésére, ez fogja ugyanis tárolni a módosított konfigunkat, amelyet minden indításkor bemásol majd a router az eredeti helyére. Nézzen ki így a végeredmény:

Eddig remekül állunk! JFFS partíciónk csatolásának állapotát gyorsan le is ellenőrizhetjük:

root@unknown:/tmp/home/root# mount | grep jffs
/dev/mtdblock5 on /jffs type jffs2 (rw,noatime)

Amint látható, fel lett csatolva, tehát sikerrel jártunk! Most hozzunk létre egy mappát a módosított konfigoknak:

mkdir /jffs/config/

Másoljuk át az eredeti Tomato Stubby konfigot ide:

cp /etc/stubby.yml /jffs/config/

És nyissuk meg szerkesztésre:

nano /jffs/config/stubby.yml

Belenézve az eredeti konfigba, ez tárult elém:

tls_ca_file: "/rom/cacert.pem"

resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
- GETDNS_TRANSPORT_TLS

tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

tls_query_padding_blocksize: 256

edns_client_subnet_private : 1

idle_timeout: 10000

listen_addresses:
- 127.0.0.1@5453
- 0::1@5453

round_robin_upstreams: 1

upstream_recursive_servers:
# IPv4 addresses
# Cloudflare
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
# Google
- address_data: 8.8.8.8
tls_auth_name: "dns.google"
- address_data: 8.8.4.4
tls_auth_name: "dns.google"
# Quad 9 'secure' service - Filters, does DNSSEC, doesn't send ECS
- address_data: 9.9.9.9
tls_auth_name: "dns.quad9.net"
# The Surfnet/Sinodun servers
- address_data: 145.100.185.15
tls_auth_name: "dnsovertls.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
- address_data: 145.100.185.16
tls_auth_name: "dnsovertls1.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
# The getdnsapi.net server
- address_data: 185.49.141.37
tls_auth_name: "getdnsapi.net"
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
# IPv6 addresses
# Cloudflare
- address_data: 2606:4700:4700::1111
tls_auth_name: "cloudflare-dns.com"
- address_data: 2606:4700:4700::1001
tls_auth_name: "cloudflare-dns.com"
# Google
- address_data: 2001:4860:4860::8888
tls_auth_name: "dns.google"
- address_data: 2001:4860:4860::8844
tls_auth_name: "dns.google"
# Quad 9 'secure' service - Filters, does DNSSEC, doesn't send ECS
- address_data: 2620:fe::fe
tls_auth_name: "dns.quad9.net"
# The Surfnet/Sinodun servers
- address_data: 2001:610:1:40ba:145:100:185:15
tls_auth_name: "dnsovertls.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
- address_data: 2001:610:1:40ba:145:100:185:16
tls_auth_name: "dnsovertls1.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
# The getdnsapi.net server
- address_data: 2a04:b900:0:100::38
tls_auth_name: "getdnsapi.net"
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=

Én ezt a következőkre módosítottam:

tls_ca_file: "/rom/cacert.pem"
appdata_dir: "/tmp/stubby"

dnssec: GETDNS_EXTENSION_TRUE
dnssec_return_status: GETDNS_EXTENSION_TRUE
return_both_v4_and_v6: GETDNS_EXTENSION_TRUE

resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
- GETDNS_TRANSPORT_TLS

tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

tls_query_padding_blocksize: 256

edns_client_subnet_private : 1

idle_timeout: 10000

listen_addresses:
- 127.0.0.1@5453
- 0::1@5453

round_robin_upstreams: 0

upstream_recursive_servers:
# IPv4 addresses
# Cloudflare
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
# IPv6 addresses
# Cloudflare
- address_data: 2606:4700:4700::1111
tls_auth_name: "cloudflare-dns.com"
- address_data: 2606:4700:4700::1001
tls_auth_name: "cloudflare-dns.com"

A változás az, hogy megadtam egy stubby átmeneti fájlokhoz tartozó mappát a ramdiszken:

appdata_dir: "/tmp/stubby"

Ezek a sorok felelnek a DNSSEC-ért:

dnssec: GETDNS_EXTENSION_TRUE
dnssec_return_status: GETDNS_EXTENSION_TRUE
return_both_v4_and_v6: GETDNS_EXTENSION_TRUE

Illetve a legfontosabb, hogy ezt letiltottam:

round_robin_upstreams: 0

Bár nagy jelentősége nincs, hiszen kizárólag a CloudFlare DNS címeit hagytam meg a konfigban.

Ezt követően lehet menteni a fájlt, majd az Administration -> Scripts -> WAN Up fül alá illesszük be a következő sorokat:

cp /jffs/config/stubby.yml /etc/stubby.yml
sleep 1
service dnsmasq restart

Adjunk egy rebootot a routernek, vagy szakítsuk meg manuálisan a WAN kapcsolatot és hagyjuk, hogy a router újra csatlakozzon. S amennyiben sikerrel jártunk, az új konfig lesz érvényben. Az eredeti pedig a /rom/etc/stubby.yml útvonalon megtalálható marad, és bármikor visszaállítható a WAN Up rész kitörlésével, majd egy reboottal. Azonnali visszaállításhoz pedig egy:

ln -sf /rom/etc/stubby.yml /etc/stubby.yml; service dnsmasq restart

parancsra lesz szükségünk.

Ellenőrizni munkánk sikerességét pedig tcpdumppal érdemes, amelyet sajnos a Tomato alapból nem tartalmaz, viszont az Entware igen. Telepítés és a következő parancsok kiadása után:

opkg update; opkg install tcpdump

ki kell derítenünk, hogy mely interfacen bonyolítja le routerünk a WAN forgalmat. Erre két módot tudok javasolni, az egyik az Advanced -> Routing fülön az interface oszlop. A sok-sok elem közt kell keresni egy interfacenév (WAN) párost, ami nekem ppp0 (WAN), hiszen PPPoE a kapcsolatom típusa. A másik megoldáshoz pedig SSH-n add ki az ifconfig parancsot, és amelyik interface inet addr címe megegyezik a külső WAN-os IP címeddel, nagy valószínűséggel az lesz a WAN interface.

Tehát esetemben ppp0-n kell hallgatózni, először a titkosítatlan, régi feloldás után kutatva:

tcpdump -i ppp0 udp port 53

Amennyiben itt nem, vagy csak nagyon jelentéktelen forgalom zajlik (néhány eszköz ignorálja a router DNS-ét és a sajátját preferálja, ami természetesen nem lesz titkosítva, de érdemes minden otthoni eszközön belőni a router DNS-t) és a forgalom nagyja a titkosított 853-as TCP porton zajlik:

tcpdump -i ppp0 tcp port 853

Ha van rajta forgalom, már biztosak lehetünk benne, hogy sikerrel jártunk! :)

És a tonnányi felesleges beszéd után végre büszkélkedhetünk egy szupergyors, teljes mértékben titkosított A Cloudflare és a router közti DNS feloldóval, amelyet minden hálózatra kötött eszköz képes lesz használni! Még azok is, amelyek nem támogatják a DNS over TLS-t, hiszen a belső hálózaton a router egy normál DNS kiszolgálóként fog továbbra is működni.

Jó hekkelést kívánok!

Hozzászólások

(#1) bambano


bambano
titán

felfoghatatlan számomra, hogy valaki az isp-jétől jobban fél, mint amcsi adathörcsög cégektől...
rotfl.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

(#2) Mr Dini válasza bambano (#1) üzenetére


Mr Dini
addikt

Az ISP-m DNS-e eleve megbízhatatlan, gyakran meghal és lassú. Eleve Cloudflare-t használtam, hát minek tudjon róla még az ISP-m is.

Egyébként meg nehezen tudom elképzelni, hogy szembe mennének a saját feltételeikkel: [link]

Te mit tennél a helyemben?

[ Szerkesztve ]

Sose köss bele az antikvitásba!

(#3) kraftxld


kraftxld
nagyúr

Én némi zavart érzek itt az erőben, szerintem a DNS over TLS nem egyenlő a DNSSEC-el.

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

(#4) kraftxld válasza Mr Dini (#2) üzenetére


kraftxld
nagyúr

Mi bajod van a vidéki netszolgáltató irodájának sarkában zúgó IBM x206-al, amin ezer éves nem patch-elt linux fut és a hozzá tartozó root / toor jelszót csak 1 emberke ismeri? :DDD

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

(#5) Mr Dini válasza kraftxld (#3) üzenetére


Mr Dini
addikt

Mivel semmi köze a két dolognak egymáshoz. Valahol félrefogalmaztam volna?

Sose köss bele az antikvitásba!

(#6) aprokaroka87


aprokaroka87
nagyúr

Én droidon adguard dns-t használok, bár vannak kétségeim hogy minden körülmények közt valóban azon megy át a forgalom:)

(#7) kraftxld válasza Mr Dini (#5) üzenetére


kraftxld
nagyúr

Párszor átolvastam a cikket, de csak a konfig file átbogarászása után világos, hogy mit is állítottál be :)

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

(#8) bambano válasza Mr Dini (#2) üzenetére


bambano
titán

én meg azt tudom nehezen elképzelni, hogy szembe mennek a rájuk vonatkozó törvényekkel.

hogy én mit tennék a te helyedben, nem tudom, nem vagyok a te helyedben. a saját helyemben azt tettem, hogy saját dns szervert üzemeltetek. ha ez nem oldható meg, használd az isp-d szervereit. ha azok hibáznak, tegyél hibabejelentést.

az amcsi szolgáltatói szerverek törvény szerint amcsi titkosszolgálati fennhatóság alatt állnak. a te hozzáférés-szolgáltató isp-d szervere meg valószínűleg magyar törvények alatt. ez utóbbiban nagyságrendekkel jobban bíznék, mint az usákokban.

azt gondolni teljes komolysággal, hogy egy cloudflare-s dns biztonságosabb, mint egy magyar/eu-s isp szervere, annyira nevetséges, hogy nem is érdemes rajta felröhögni.

egyébként van a sztakinak is publikus dns szervere, azt eredetileg dns regisztráció technikai ellenőrzésére csinálták. hogyha ráborulna nagyobb forgalom, bírná-e, nem tudom, de még az is jobb, mint ezek.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

(#9) samujózsi válasza bambano (#1) üzenetére


samujózsi
tag

Miután 100%-os biztonság nincs és az ISP itt van, a google meg távol...
Az ISP-k egyik-másik alkalmazottja könnyebben árthat bizonyos esetekben, mint mondjuk egy amcsi google mérnök vagy rabszolga.
Előbbinek lehet rá oka és lehetősége, hogy ártson neked adott esetben, utóbbinál max olyantól kell tartani, hogy ok nélkül mizárnak a szolgáltatásukból, mert monopol helyzetük révén megtehetik és a profilozás miatt bármikor azonosítanak.

Igaz, nem mostanában, de volt rá példa, hogy ISP alkalmazott visszaélt a szolgáltató ügyfeleire vonatkozó infókkal, köztük forgalmi adatokkal. És az esetenként kínosabb lehet, mint az, hogy a google nem publikus adstbázisaiban mi van rólad.

Nem akarok hosszabban belemenni ebbe a témába, szóval leírtam, de itt be is fejeztem. (Nem vitaindítónak szántam, inkább gondolatébresztőnek)

Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM

(#10) bambano válasza samujózsi (#9) üzenetére


bambano
titán

az, hogy az isp alkalmazottja szándékosan kitoljon veled, kivételnek számít. az, hogy a cloudfare meg a google kitoljon veled, alapértelmezett. az isp alkalmazottja ráadásul számonkérhető, a google alkalmazottja nem.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

További hozzászólások megtekintése...
Copyright © 2000-2022 PROHARDVER Informatikai Kft.