Titkosított DNS-elérés az új Synology SRM rendszerben
[2019. augusztus 23.]
Július végén jelent meg az SRM (Synology Router Manager) 1.2.3-as verziója, amely számtalan újdonságok hozott. Bár azóta már egy újabb frissítése (1.2.3-8017-2) is kiadásra került, most az 1.2.3-8017-ben debütáló „DNS-elérés HTTPs kapcsolaton keresztül” funkcióra szeretnénk felhívni a figyelmet.
A HTTPs talán már minden internetezőnek ismerős kifejezés, a titkosított HTTP kapcsolatot jelenti, amivel egyre több weboldal elérésénél – de akár a NAS-unk távoli elérésénél is – találkozhatunk. Az ilyen oldalakhoz biztonsági tanúsítványnak is „illene” tartoznia, amely esetleges hiányára a webböngészőnk felhívja a figyelmet, és csak jóváhagyásunk után hajlandó megjeleníteni tanúsítvány nélkül. Az átlag felhasználó számára mindebből az a fontos, hogy ha a számítógépünk és az adott weboldal között titkosított HTTP (azaz HTTPs) kapcsolat jön létre, akkor a két végpont közötti kommunikációba nincs értelme „belehallgatni”, mert az erős titkosítással kódolt, az átvitt adatokat nem lehet értelmezni, így pl. nem férhetnek hozzá a megadott bankkártyánk adataihoz illetéktelenek, csak a meglátogatott weboldal valódi üzemeltetője. Ha tehát egy weboldalhoz sima HTTP kapcsolaton keresztül csatlakozunk (ez látható a webböngésző címsorában, ami ilyenkor nem „https://” betűkkel, hanem „http://”-rel kezdődik), ne adjunk meg ilyenkor fontos adatokat, mert ahhoz nem csak a weboldal férhet hozzá esetenként. Ráadásul az is aggályos, ha egy weboldal fontos adatainkat kéri, de nem HTTPs-en keresztül érhető csak el...
A DNS mozaik szóval (Domain Name Server) is bizonyosan találkozott már szinte mindenki, aki internetezik, de erről kevesebben tudják, mi az. Pedig minden számítógépen, routeren, a hálózati kapcsolat adatai között, gépünk IP-cím mellett láthatjuk általában a DNS szerver(ek) címeit is. Ezen IP-címek általában az internet-szolgáltatónktól érkeznek (jellemzően saját szervereik), de lehetőségünk van ezt felülírni, egyedi címeket megadva, akár többet is. Persze, aki felül akarna írni egy DNS-címet, annak már tisztában kell lennie azzal, miről is van szó. Az interneten számtalan DNS-szerver üzemel. Ezek feladata, hogy megmondják, milyen domain névhez milyen IP-cím tartozik. Tehát ha pl. a Synology-forum.hu oldalt szeretnénk meglátogatni – ha ezt olvasod, Neked már sikerült :) –, akkor nem kell tudnunk az oldal IP-címét (azaz a gép IP-címét, amelyen fut az oldal), pedig az interneten minden számítógép a teljesen egyedi IP-cím alapján található meg. A Synology-forum.hu egy úgynevezett domain név, ami regisztrálva, társítva lett a szerverünk IP-címéhez egy ezzel foglalkozó szolgáltató segítségével. Az rendben, hogy mostantól ez a szolgáltató tudja, hogy a synology-forum.hu oldal milyen IP-című számítógépen található, de ettől még a Te számítógéped webböngészőjéhez nem jut el ez az információ. A DNS-szerverek feladata, hogy tárolják a domain nevek és az IP-címek társításait, tehát meg tudják mondani, hogy egy adott domain gyakorlatilag melyik IP-címhez tartozik. Mivel azonban óriási mennyiségű domain név van már regisztrálva, nem igen létezik olyan szerver, amely mindegyikről tud. Ráadásul folyamatosan regisztrálnak újabb domain neveket világszerte, vagy épp átköltöznek egyes weboldalak másik IP-című szerverekre, de persze meg is szűnnek domain nevek. Tehát egy folyamatosan változó, hatalmas információhalmazról van szó.
Amikor számítógépünk webböngészőjébe begépeljük a synology-forum.hu webcímet (domain nevet), az aktuális internetkapcsolatnál beállított DNS szerverekhez fordul a program, azaz megkérdezi, hogy milyen IP-cím van ehhez a domainhez rendelve. Ha ezek a szerverek saját adatbázisukban megtalálják a választ, akkor minden rendben, az adott IP-cím ismeretében képes a weboldalunkat futtató szerverhez csatlakozni a webböngésző. Ha a DNS szerver nem tudja a választ, bizonyos algoritmus szerint kiválaszt egy másik DNS-szervert a világban, és megpróbálja attól megtudni az információt, így nem csak azt mondja a böngészőnek, hogy „Bocs, nem tudom!”. A DNS szerverek láncában igen sokáig futhat a kérdés, mire valamelyik tud válaszolni. Bizonyosan mindenki találkozott már olyasmivel, hogy egy weboldal, a címe (pontosabban a domain neve) beírása után jelentős késéssel kezd el betöltődni. Ennek egyik jellemző oka lehet az, hogy sokára találtak a DNS-szerverek egymás között olyan „bölcset”, aki meg tudta mondani, ilyen IP-cím tartozik a beírt domain névhez. Biztosan mindannyian találkoztunk már „A keresett weboldal nem található!” üzenettel is, amely egyik oka az lehet, hogy nem sikerült az általunk megszólított DNS-szervernek megtudnia a választ, esetleg rossz választ kapott, és az adott IP-címen működő szerveren nincs is ott a keresett oldal.
Az IP-cím keresés során keletkező adatátvitel folyamatai időrend szerint sorszámozva
(ha csak egy sokadik DNS-szerver tudja feloldani a domain nevet – azaz megmondani a hozzá tartozó IP-címet)
A fentiek alapján látható, hogy a webböngészés sikeressége, sebessége nagy mértékben függ a DNS-szerverektől, amiket elér a számítógépünk, illetve ezen szervereken tárolt adatbázis frissességéből. Idő kell a DNS-szervereknek, amíg az információ egy-egy új domain név + IP-cím párosról „elterjed”, kicsit hasonlóan a hírek terjedéséhez az emberek között. Amikor pl. a Synology DDNS (dinamikus DNS) szolgáltatását használjuk (és persze, hogy használjuk, ha már ingyenes), új NAS-unkon aktiválva a szolgáltatást, először csak a Synology-val (a céggel) közvetlen kapcsolatban DNS-szerverek kapnak értesítést arról, hogy a NAS-unk milyen IP-című router mögött található éppen, tehát milyen cím tartozik az általunk kiválasztott DDNS névhez, majd idővel ez a „hír” elterjed a világ DNS-szerverein. Ha tehát a Synology-féle DDNS szolgáltatást aktiváltuk, nem biztos, hogy azonnal működni fog, és rögtön elérhető a NAS-unk a szomszédból. Pontosabban fogalmazva: a szolgáltatás azonnal működik, de a szomszéd internetkapcsolat nem talál még olyan DNS-szervert, amelyen az aktuális információ már elérhető lenne. Az otthoni routerünk a legtöbb esetben nem fix, hanem dinamikus IP-címet kap az internetszolgáltatónktól (tisztelet a kivételnek, akik felár nélkül már fix címet adnak), tehát időről időre változik a routerünk külső címe. A Synology DDNS szolgáltatásának lényege, hogy Synology NAS-unk vagy routerünk rendszeresen jelenti a Synology felé, hogy éppen milyen IP-címet kapott az otthonunk routere. Tehát a DDNS esetében még fontosabb, hogy a változásról a „hír” minél gyorsabban elterjedjen a DNS-szerverek között világszerte, hiszen időről időre erre szükség lesz, módosítani kell a DNS-szerverek adatbázisait.
Hogy a DNS szerverek mennyi adatot és hogyan tárolnak, a frissítésekről hogyan szereznek értesülést, ha nincs adatuk egy domainhez tartozó aktuális IP-címről, akkor milyen algoritmus szerint próbálják azt más DNS-szervereken keresztül megtudni, nagyon különböző lehet. Ha jó az internetszolgáltatónk saját DNS-szervere, akkor nem igen kapunk hibaüzenetet egy oldal keresése közben, mindig elérhető lesz egy DDNS címen működő NAS, és gyorsan elkezdenek betöltődni a keresett oldalak. Ha úgy érezzük, lehet, hogy jobban is működhetne az internetkapcsolatunk más DNS-szerverekkel, érdemes egy próbát tenni, a szolgáltatónktól automatikusan kapott DNS-címek helyett manuálisan megadva olyat, amiben bízunk. Számos híresen jó DNS-szerver található világszerte, ilyen pl. a Google 8.8.8.8 és 8.8.4.4 IP-címeken található két szerver. Mi egyébként javasoljuk is ezek használatát beállítani a hazai internetszolgáltatók esetén, az alábbi képen ez látható a Synology SRM felületén:
De térjünk vissza a fenti nem rövid kitérő után cikkünk tárgyához! Miért is érdemes, előnyös titkosítani a DNS-szerverekkel való kommunikációt is, hiszen itt nem továbbítódnak olyan fontos infók, mint pl. a bankkártyánk adatai? Egyrészt, számos internetszolgáltató megőrzi a felhasználók kereséseit (tehát azt, hogy milyen domain neveket írtak be a webböngészőbe, milyen oldalakat látogattak meg) akár 12 hónapig, mert vagy törvény kényszeríti erre (pl. bűnügyi nyomozások segítése érdekében), vagy éppen különböző cégek felé értékesíti a keresésekből létrehozható statisztikákat. Másrészt nem csak az internetszolgáltatók, hanem DNS-szervert üzemeltető cégek is profitálhatnak a titkosítás nélküli DNS-lekérdezésekből, hiszen ez alapján célzott reklámokat küldhetnek nekünk azok, akik megvásárolják az infót, hogy milyen IP-címről milyen weboldalakat szeretnénk elérni, mi érdekel minket, stb. A legnagyobb veszélyt azonban a rosszindulató támadások, az úgynevezett „DNS-eltérítések” megjelenése és terjedése jelenti. Ügyes hackerek saját DNS-szervereik segítségével hamis IP-címeket adtak vissza találatként bizonyos domain nevek keresésekor, így pl. a PayPal a Gmail, az Uber vagy épp a Netflix esetében is. Az általunk megadott IP-címek saját szervereikre mutattak, ahol az eredeti szolgáltatás weboldalának másolata futott, pontosabban csak annyi működött ott, hogy bekérje a login és egyéb létfontosságú adatokat. Nem igen lehet ilyen esetben a felhasználót hibáztatni, hiszen az adott címen látszólag a számára ismerős weboldal megjelenik, és a megszokott módon be is tud jelentkezni – de megadva sajnos így illetékteleneknek az értékes adatait, gyakorlatilag átadja fizetős szolgáltatásait, hozzáférést ad levelezéséhez, stb.
|
Megjegyzés: ha nagyon figyelünk, azért ezekre a DNS-eltérítésekre is fény derülhet: a weboldalak a HTTPs kapcsolathoz szükséges ún. SSL bizonyítványt (certificate) kell hogy igényeljenek, amely eléggé szigorú módon ellenőrizve adható ki az adott igénylőnek (fizetős szolgáltatás), és így a megbízható, független kibocsátó igazolja, hogy az adott oldal által használt SSL bizonyítvány ténylegesen ahhoz a domainhez illetve céghez tartozik, akinek az oldalán éppen vagyunk. Ezt a címsor elején a zöld színű zárt lakat ikon és az utána megjelenített tulajdonos neve mutatja, amelyre kattintva további részleteket tudhatunk meg, pl. hogy az adott bizonyítványt melyik kibocsátó mikor adta ki, vagy pl. meddig érvényes (ha lejárt, erre feltűnően figyelmeztet majd a böngésző). Ha komolyabb biztonságot igénylő oldallal van dolgunk (banki művelet, kártyás fizetés), akkor ne elégedjünk meg a címsorban a https:// előtaggal, mert hamis biztonságérzetet adhat, nézzük meg az SSL bizonyítvány adatait, csak 2-3 kattintás, megéri ellenőrizni, hogy a weboldal neve/domain neve stimmel-e a bizonyítvány tulajdonosának nevével! Az alábbi képek pl. az OTP Bank oldalánál látható címsort, és rá kattintva a részletes adatait mutatják Firefox esetén:
|
Léteznek már olyan DNS-szolgáltatók (pl. Google, Cloudflare), akik DoH (DNS over HTTPs), azaz titkosított DNS-lekérést garantálnak a normál, sima szövegfájlos módszer helyett. Ilyenkor ezekkel a szerverekkel bátran kommunikálhat a számítógépünk, mert hamis DNS-s szerverek nem kerülnek az adataink útjába (amelyek egyébként is titkosítva továbbítódnak a két pont között). Az ilyen DoH DNS-szerverek nem fordulnak más, általános DNS-szervehez, ha nem tudják a választ.
A legprofibb megoldás, ha a routerünkben aktiváljuk a DoH-t, így nem kell akkor a mögötte lévő telefonokon, számítógépeken egyesével beállítani (ehhez kényelmes megoldás sokszor nem is igen van még). A Synology SRM 1.2.3 már képes a DoH kapcsolatra, a Google-t és a Cloudflare-t is választhatjuk:
Nem csak a hackereknek okoz azonban bosszúságot a titkosított DNS-használat. Azon internetszolgáltatók, akik eddig pénzzé tették statisztikáikat amelyek DNS-lekéréseinkből állítottak össze, mostantól nem találkoznak velünk. A hatóságok sem kérhetik le keresési előzményeinket tőlük. Számos szolgáltató fizetős szülői felügyeletet, kártékony weboldalak kiszűrését kínáltja, melyet a DNS-keresések szűrésével valósít meg. Ha mostantól nem lát ezekbe bele, komoly bevételektől eshet el. Léteznek hardveres tűzfalak is, melyek a router előtt/mellett működnek, ezeknek sincs értelme többet, ha a router titkosítva szólít meg egy DNS-szervert.
A Synology routerekkel a DoH használata mellett sem kell lemondanunk a szülő felügyeletről, tűzfalról, hiszen ezen szolgáltatások szoftvercsomagként (Safe Access és Threat Prevention) a routeren ftutnak, és természetesen ezek hozzáférnek még a titkosítás előtt a belső hálózatunkról érkező domain-keresésekhez. (Az alábbi videóhoz kiválasztható a magyar felirat a beállításoknál.)
Felmerülhet a fentiek alapján a kérdés, hogy vajon lassabb lesz-e egy-egy domain névhez megtalálni az IP-címet, vagy gyakrabban fordul majd elő, hogy nem is lesz találat, ha csak a Google vagy a Cloudflare DNS-szervereihez csatlakozunk, amelyek bizonyosan nem úgy és nem annyi egyéb DNS-szerverrel állnak kapcsolatban, mint pl. szolgáltatónk DNS-szervere. A gyakorlat ezt majd megmutatja, várjuk a tapasztalatokat ezzel kapcsolatosan a fórumban ITT!
