Tenhle článek možná bude poněkud ostřejší, za což se předem omlouvám. Rád bych, aby se informace, kterou jsem dnes náhodou zjistil, dostala k co nejvíce lidem, protože to, co budu v článku níže rozebírat, se prostě nedělá, ať už měl být úmysl jakýkoliv.
Notoričtí potížisti
Jeden malý jihomoravský poskytovatel internetu mi leží v žaludku už docela dlouho. Bohužel má jako jeden z mála pokrytí v nejrůznějších „prdelích světa“, takže několik mých klientů jeho sítě využívá, ať už k firemním či soukromým účelům. Nelíbí se mi na nich zejména to, že se ke svým zákazníkům chovají jako k laboratorním krysám. A problémem není jen laxní přístup podpory, ale i docela hrubé technické chyby. Nejednou jsem řešil problém se zázračně nedoručitelnými maily, jen abych zjistil, že milý poskytovatel prostě při velkém množství mailů odchozí SMTP na chvíli zablokuje. Přičemž „velké množství“ znamená víc jak 10. Nebo že pár hodin nepřekládá DNS. Nebo je že prostě z čista jasna, pravděpodobně kvůli nějaké interné závadě, firemní klient, který je připojen kabalem nebo optikou a který by normálně měl mít připojení pevné jako skála, na pár minut (nebo hodin) odpojen, což třeba u klientů, kteří mají ve firmě lokální server, není úplně příjemné. Nicméně to co jsem náhodou zjistil dnes, to už je fakt přes čáru.
Je to rozbitý
Jeden můj klient mi napsal, že mu už nějakou dobu nefunguje iCloud, App Store, nahrávání fotek na Facebook a tak. Zmínil se, že si myslí, že mu to nefunguje od doby, co jsem u něj jako gateway router instaloval MikroTik. Normálně do domácích routerů dávám firewall jen na vstup, takže mi bylo divné, že by se filtrovalo něco na výstupu a ještě k tomu takhle specificky. Nicméně jsem projel nastavení, updatoval RouterOS na nejnovější verzi, ale žádnou očividnou vadu jsem neshledal. Nemaje Jablka™, šel jsem se na stránky Apple podpory kouknout, jaké porty používají ony zmíněné nefunkční služby. K mému překvapení jsem zjistil, že je to obyčejné HTTP a HTTPS na standardních portech TCP/80, resp. TCP/443. Layer7 firewally, proxy ani žádné jiné podrobné filtrování obsahu nevedu, takže mi začalo být vážně divné, proč jako zrovna tohle by nemělo fungovat. Chvíli jsem podezíral nějaký malware, ale obratem mi bylo vyvráceno, že problém se týká několika Applích mobilních zařízeních a jednoho standardního domácího PC. Začal jsem tedy druhé kolo kontroly konfigurace. Vyčistil jsem DNS cache, zkusil si přes Google DNS, kterou požívám snad úplně všude, resolvnout nějaký hostname, telnetem si otevřel port TCP/53 na 8.8.8.8 a.. a ono nic. TCP/53 se nespojil. A mám vás, dobytci!
Docela Nenáročný Systém
To že DNS funguje na portu 53 je relativně rozšířená znalost. Méně rozšířené pak už může být, kterýže z té hrstky transportních protokolů vlastně používá. Inu, je to prosté, milý Watsone. První požadavek je vždy na UDP/53. První odpověď přijde vždy z UDP/53. A teď ta zajímavá část popsaná v RFC5966. Pokud by byla odpověď serveru delší než 512 bajtů, Dotazovaný DNS server tento fakt svému klientovi sdělí, a ten se pak zeptá znovu na to samé co předtím, ale tentokrát na TCP/53. Každý slušný DNS server, kterým by ten od Google rozhodně měl být, tedy musí naslouchat na UDP/53 i TCP/53. IP adresa v A záznamu nebo pár písmenek v CNAME a MX jsou relativně krátké objekty, takže se do 512 bajtů bez větších problémů vlezou, ale třeba s DNSSEC záznamem už je to horší. Nebo s odpovědí, která vrací několik A a AAAA záznamů, jako tomu bývá u webů velkých společností. Třeba tak velkých jako je Apple nebo Facebook.. hmmm..
Čmuchy čmuch
Zkusmé telnetnutí na TCP/53 na jeden z mých vlastních DNS serverů ukázalo, že port jako takový blokovaný není. OK, takže IP adresa 8.8.8.8 není tím, kým se zdá být. A totéž platí i pro 8.8.4.4. Nu dobrá, pátrám tedy dál. Pustím si traceroute na svém drahém, ale stabilním připojení od UPC, abych věděl, jak to má vypadat.
root@server:~# traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
...
2 86.49.52.129 10.457 ms 10.431 ms 10.402 ms
3 84.116.220.246 15.427 ms 15.448 ms 15.424 ms
4 84.116.221.41 16.136 ms 16.109 ms 16.301 ms
5 84.116.221.37 15.580 ms 15.868 ms 15.633 ms
6 84.116.130.54 15.932 ms 84.116.130.230 12.574 ms 213.46.172.229 13.153 ms
7 213.46.172.210 13.476 ms 14.331 ms 14.815 ms
8 209.85.251.145 14.461 ms 209.85.251.143 15.205 ms 209.85.251.141 14.161 ms
9 8.8.8.8 13.816 ms 14.148 ms 13.571 msStejný traceroute jsem pustil ještě z několika náhodných umístění na různých místech v Evropě a různých ISP a dozvěděl se, že předposlední hop je vždy z 209.85.251.x. A když úplně to samé udělám u klienta onoho ISP, dostanu
root@server:~# traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
...
2 172.16.153.254 13.548 ms 15.222 ms 16.928 ms
3 172.16.10.61 23.792 ms 23.806 ms 23.856 ms
4 8.8.8.8 39.742 ms 39.706 ms 39.788 msJak je vidět, požadavek jde interními sítěmi (172.16.0.0/12 je subnet class B) a najednou z ničeho nic přeskočí na cílovou IP 8.8.8.8 bez toho, aniž by kdy vylezl na internet. OK, co dalšího nám o sobě náš falešný Google DNS prozradí? Zkusím si trochu pohrát z nmapem.
Pravý Google DNS:
root@server:~# nmap -O 8.8.8.8
Starting Nmap 5.21 ( http://nmap.org ) at 2015-01-13 20:21 CET
...
Nmap scan report for google-public-dns-a.google.com (8.8.8.8)
Host is up (0.0058s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
53/tcp open domain
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING) : OpenBSD 4.X (92%)
Aggressive OS guesses: OpenBSD 4.0 (92%)
No exact OS matches for host (test conditions non-ideal).Falešný Google DNS:
root@server:~# nmap -O 8.8.8.8
Starting Nmap 6.40 ( http://nmap.org ) at 2015-01-13 20:30 CET
Nmap scan report for google-public-dns-a.google.com (8.8.8.8)
Host is up (0.060s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
22/tcp closed ssh
Too many fingerprints match this host to give specific OS detailsUDP porty z principu jeho fungování vidět nejsou, nicméně je zde už krásně vidět, že onen tolik potřebný TCP/53 Google opravdu vystrčený má, ale server, na který ISP požadavky krade, se místo něj akorát snaží ututlat SSH. Z tohohle už je více než očividné, že požadavky nekončí na témže zařízení. Nedělám si iluze, že mě Google obsluhuje pouze jedním serverem, ale ani při opakovaném dotazu nedostávám nic podobného těm nesmyslům, které dostávám ze serveru poskytovatele připojení.
Zahoďte to
Tak nějak nevím, co si o tom mám vlastně myslet. Přijde mi úplně normální, když ISP provozuje vlastní DNS servery. O trochu méně normální mi přijde, když blokuje přístupy k DNS serverům ostatních provozovatelů, ale ještě pořád by se to dalo svým zvráceným způsobem vysvětlit. Ale takhle sprostě unášet cizí požadavky a k tomu ještě tak amatérským způsobem, že celý to princip fungování DNS protokolu rozbijí, to už chce fakt pořádnou dávku choromyslnosti. Není tohle vlastně varianta phishingu? Tímhle způsoben se totiž celkem snadno dá podvrhnout jakýkoliv záznam. Co přijde dál? HTTP proxy, kterou se budou pohodlně dát zachytávat hesla v plaintextu? Nebo třeba lokální kopie Facebooku, ať se ještě víc sníží traffic na těch jejich odfláknutých sítích? Kolik DNS dotazů proboha musí denně projít, aby nějaké takové nucené přesměrování vůbec mělo smysl a měřitelný dopad? Nebo to je prostředek, jak jednoduše šmírovat svoje klienty? Ani jedna z možností mi nedává valný smysl. Ale jasno mám rozhodně v jednom. Tuhle firmu budu ode dneška bojkotovat s ještě větším úsilím než doposud. Co je to proboha za poskytovatele internetu, který nemá ani páru o tom, jak funguje DNS? Pokud jste náhodou klienty takovéhle nebo jiné pochybné společnosti, popřemýšlejte o tom, jestli vám takový zásah do soukromí stojí za to. Rozhodně ale frajerům zavolejte, a velmi důrazně požadujte, aby požadavky posílané do internetu byly opravdu zodpovídány servery na které mají směřovat.