Všichni se shodneme, že na Internetu najdeme spoustu věcí, které jsou nepříjemné, otravné či dokonce škodlivé. Stojí nás čas, peníze a vnitřní klid. Ale ne všechny tyto věci vznikají se zlým úmyslem. Často je tomu dokonce naopak. Ale jak se říká, cesta do pekel je dlážděna dobrými úmysly.
Ukázalo se, že projekt Turris je takovým magnetem na nepříjemnosti způsobené jinými subjekty.
Například, zkoušíme pingat různé servery po Internetu. Jednak chceme vidět, jak se mění dostupnost a kvalita Internetu. Taktéž nás zajímá, které IP adresy uživatel dostane a jestli se liší klient od klienta. Jaké bylo naše překvapení, když jsme zjistili, kolik serverů na Internetu neodpovídá na pingy. Velmi rozšířené je to například u bank a jiných peněžních institucí. Přitom, RFC 792 celkem jasně říká, že na pingy je třeba odpovídat.
Pravda, toto je jen taková maličkost. A mnozí správci sítě argumentují, že je to z důvodu bezpečnosti. Což je, ovšem, nesmysl. Ty servery vesele komunikují po protokolu HTTP, takže pokud chcete vědět, jestli běží, stačí zkusit navázat spojení na portu 80. Co se dozvíte za pomoci pingu, to se takovou metodou dozvíte také, jen to na serveru způsobí vyšší zátěž.
Druhou, spíše drobnou, nepříjemností, kterou můžete celkem často potkat, je vyrovnávání zátěže pomocí DNS. Když se pokusíte zjistit IP adresu například pro doménu google.com, dostanete jednu. Když to zkusíte za chvíli, dostanete jinou. A poté zase jinou. Tento trik umožňuje posílat klienty na různé servery v závislosti na jejich aktuálním zatížení, geografické lokaci klienta a mnoha jiných faktorech.
Ale má to i stinnou stránku. Pominu fakt, že to komplikuje život nám, když se snažíme detekovat podvržené IP adresy (pokud služba vrací jednu IP adresu a jeden router vybočuje z řady, je to podezřelé, když máte 100 různých adres pro 1000 routerů, moc z toho nezjistíte). Ale aby tento trik fungoval, je potřeba snížit takzvané TTL, což je doba, po kterou si odpověď klient smí pamatovat, než se zeptá znovu. Najdete služby, které mají TTL nastavené na několik dní, ale Googlu se musíte přeptat co 5 minut, což způsobí pomalejší načítání stránky.
Přitom, kdyby vrátili těch IP adres v jedné odpovědi více, tak se klienti mezi ně rozloží sami. Je asi nevhodné vrátit stovku adres, už jen proto, že by odpověď byla poněkud veliká, ale i s třeba deseti by rozložení bylo větší a TTL by mohli dát vyšší.
Abychom ale nemluvili jen o službách na Internetu, podíváme se i na zlozvyky poskytovatelů připojení.
Pro uživatele asi nejvýraznější problém je, když poskytovatel blokuje některé vybrané porty. Nebo, ještě častěji, blokuje všechny porty kromě hrstky vybraných. Někteří to dělají plošně (například majitelé restaurací, kteří poskytují zákazníkům WiFi), jiní jen občas a výběrově (když podezřívají zákazníka, že má virus). Důvodem je prý opět bezpečnost, aby malware nemohl komunikovat se svými servery a aby znepříjemnili život zlým crackerům. Přitom tím znepříjemní život především běžným uživatelům; zatímco každý malware, co za něco stojí, komunikuje na portu 80 (a ten nechávají povolený) a kdekdo má nějakou VPN běžící na portu 80 či 443, aby se mohl připojovat kamkoliv i z takových sítí. Samozřejmě, že už jsme narazili na poskytovatele, co se snažil blokovat spojení Turrisu se serverem, a také se bránil, že je to kvůli virům.
Další problém je zasahování do komunikace DNS. U některých poskytovatelů se stává, že pokud použijete jeho DNS server a zkusíte z něho získat kromě vlastní odpovědi i podpisy pro DNSSEC, tak vám je nedá. Proto je v Turrisu DNS resolver unbound, který dokáže komunikovat přímo s autoritativními servery a DNS server poskytovatele obejít.
Ale u některých poskytovatelů selže i to. Poskytovatel vezme procházející paket s odpovědí a ty podpisy z něj odstraní, než jej pošle dál zákazníkovi, nebo paket úplně zahodí. Technici poskytovatele často vůbec netuší, že se to děje, uživatelé Turrisu řeší problém, proč jim DNS nefunguje a píší nám.
V některých případech to bylo způsobené monitorovacím zařízením CISCO, které nezvládalo DNS pakety větší než 512 bytů a zahazovalo je. Dříve opravdu větší DNS pakety existovat nesměly. Ale doba pokročila a dnes již jsou větší pakety povolené a podpisy ten paket docela nafouknou.
V jiných případech to byla pravděpodobně bezpečnostní funkce routeru. Zjednodušeně, Kaminskeho útok funguje tak, že k vyžádané odpovědi útočník přibalí i nějakou další, nesouvisející, informaci a doufá, že si ji klient zapamatuje pro případ, že by ji někdy potřeboval (ten útok ještě řeší, jak přimět oběť zeptat se na něco přímo útočníka, ale to ponecháme stranou). Tento útok už v dnešní době není tak nebezpečný, software si zvykl takové přibalené nevyžádané kousky informací zahazovat. Ale router tohoto poskytovatele zřejmě dělal takové zahazování z průchozích DNS paketů preventivně. A pravděpodobně byl starší než DNSSEC, a proto podpisy také považoval za nesouvisející.
Nedávno nasazený test objevil ještě další prohřešek poskytovatele, a to přesměrování veškeré komunikace na portu 25 na svůj server. Přes port 25 se posílají e-maily, ať již od klienta na server nebo z jednoho serveru na druhý. Většinou se na něm nešifruje, avšak klient o šifrování může požádat. A to právě zkoušel náš test. Pokusil se připojit na smtp.seznam.cz a zjistil, že druhá strana se představila SSL certifikátem úplně jiného serveru. A smtp.google.com se představil úplně stejným certifikátem. Vzdělaný uživatel samozřejmě nenaletí, protože na něj vyskočí varování o certifikátu, ale všichni známe některé lidi, kteří prostě cokoliv takového odkliknou, aniž by to četli.
Otázkou je, co tím poskytovatel sleduje. Pravděpodobně má jít o nějaké vynucení antispamu nebo antiviru. Ale je v pořádku, aby uživateli koukal do pošty a možná i na heslo k účtu na Seznamu.cz či Googlu? Takovému druhu útoku se říká MITM (Man In The Middle ‒ člověk v prostředku) a rozhodně to není něco, co bychom měli od svého poskytovatele čekat.
Podle zmíněných poskytovatelů to je v pořádku, protože o tom uživatele informují a že prý je to pro jejich dobro. Jeden doporučil použít port 587, který se používá pro odesílání e-mailů od klienta na serveru (a vznikl přesně proto, že někteří poskytovatelé s portem 25 dělali nehezké věci). Druhý nabídl vypnout podporu šifrování na takto přesměrovaném portu 25, že prý to problém vyřeší.
Pokud pomineme morální otázky ohledně nahlížení do pošty, dostaneme se k otázkám ohledně síťové neutrality. Ta říká, že by poskytovatel měl měřit veškerému provozu stejně a ke spojení se chovat stejně nehledě na port, na který jde, nebo na tom, kdo je na druhém konci. V praxi je toto samozřejmě trochu složitější, ale to už se dostáváme k jiné problematice, než na kterou chtěl upozornit tento článek.
Toto rozhodně není úplný seznam problémů, které můžete potkat. Ale jak vidíte, tyto jsou způsobené tím, že se někdo snažil něco „vylepšit“, aniž by si rozmyslel do důsledků, k čemu to může vést.
Obcas by to chtelo cist standardy pozorneji – z RFC 792: „There are still no guarantees that a datagram will be delivered or control message will be returned“. Jinymi slovy, nejde na to vubec spolehat a kdyz neprijde odpoved, odesilatel se s tim musi smirit. A napriklad moderni HW smerovace jim adresovane ICMP zahodi, pokud je prekrocena nejaka stanovena mez, tak aby nebylo utokem s vyuzitim trivialniho protokolu (a treba s podvrzenymi IP) smerovac odstavit. RFC 6192 primo obsahuje nejaka doporuceni, kterak i ICMP na smerovacich omezovat (tzn. v extremu neodpovidat).
Pokud jde o naznaceny rozklad v DNS mj. ad ten Google – tak je znamo, ze nektere implementace nemaji korektni round-robin a vezmou prvni IP z odpovedi, kterou dostanou. Dalsi nevyhodou je fakt, ze pokud se takto z baliku IP vylosuje IP, ktera je zrovna nahodou nedostupna, klient ma opet problem. A co je horsi – co pet minut se zeptat, nebo mit dve hodiny v cache nefunkcni IP? :-) RFC 1035 navic primo pripousti nulu, jako moznou hodnotu pro TTL, tak jakapak fuserina? Ten vyraz je krajne nevhodny.
Blokace na strane ISP maji casto sve opodstatneni. Historicky se zacla blokovat tcp/25 mj. kvuli spamu, ktery rozesilaji zavirovane koncove stanice uzivatelu. Resit to pres abuse@ v pripade problemu je sice fajn, jenze nez se to podchyti, spousta spamu je davno rozeslana a spousta prijemcu zablesena – jak znamo, spamujici stanice nezadouci provoz tlaci dle MX primo na cilove MTA. Port 587 je urcen pro message submission (viz RFC 6409). MUA (tzn. postovni klient) by se dle RFC mel obecne pripojovat spise na MSA (587), nikoliv na MTA (25) – byt je pouziti 25 dle RFC mozne, bavime-li se o „fuserine“, pak 587 je cistejsi reseni (akorat se na nej v praxi spise kasle). Blokace tcp/25 je prave ta snaha o predchazeni dusledkum – jak jinak se chcete branit v retail prostredi, tedy s domacnostmi plnou neznalych lidi? Bylo by dobre tedy navrhnout, jak jinak „by se“ to melo delat :-)
Problematika trivialnich protokolu z historickych RFC je z pohledu bezpecnosti pretrasana stale vice, nebot spise nez dobrym sluhou jsou dnes casto zlym panem – zneuzivaji se u ruznych amplification utoku pri zneuzivani jejich nestavovosti atd. Ta debata je hlubsi – muzeme sice kritizovat poskytovatele, ze nektere „sluzby“ blokuji, ale pokud tak neucini, najde se nekdo jiny, kdo bude kritizovat jejich necinnost :-) A pak presne podle hesla „100x nic umorilo vola“ staci stroje se zapomenutym historickym (treba) chargenem, spatne nastavenym DNS ci NTP, podvrzene zdrojove IP svoji praci udelaji (RFC2827 / BCP38 se v tom „sitove neutralnim“ internetu moc neresi) a na konci mate nestastnika pod DDoS utokem. A ted co s tim… spolehat na to, ze vsichni maji zarizeni pripojena k internetu v bezpecnem stavu, spravne nakonfigurovane a zaplatovane je neskutecne naivni. Praxe dokazuje opak…
Spise nez jen kritizovat v blogu by se to obcas chtelo zamyslet nad duvody. I pokusit se i o perspektivu ne-ajtaka :-)
To RFC 792 ale zřejmě mluví o tom, že se pakety mohou po cestě ztrácet. Což zřejmě není situace, kdy máte 100% packet loss na pingu, ale ostatní komunikace funguje zcela v pořádku. Což, mimochodem, není ani překročení meze, to je prostě neodpovídání.
U toho portu 25, kdyby šlo jen o zablokování, tak z toho sice budu smutný, ale pochopím to. Ale zde jde o přesměrování na jiný stroj a aktivní zasahování do komunikace. To lze připodobnit tomu, když někdo umístí na ulici oranžovou bedýnku a napíše na to „poštovní schránka“. Poté, čas od času, vybere vše, co tam lidi hodili, prohlédne si to a zanese do opravdové poštovní schránky, aby si nikdo ničeho nevšiml.
Také mi přijde, že těm poskytovatelům ten dobrý úmysl přiznávám. Jen se mi zdá, že je to buď tak, že netuší, proč to dělají a udávají nějaký dost zcestný důvod, který to zřejmě neřeší, nebo to dělají prostě proto, že „je potřeba s tím něco udělat, tak něco děláme“. Čímž nejen, že problém nevyřeší, ale přinesou problémy nové.
Mě ty blokace ICMP taky štvou, pokud se nedělají citlivě, po zralé úvaze, studiu RFC a na základě zkušeností z reálného provozu. Bohužel typický scénář blokace ICMP začíná u toho, že si admini přečtou o ICMP zprávách typů 5, 4, 9, 10 a o historii útoků, které s tím souvisí. V důsledku toho zakážou šmahem celé ICMP, bez ohledu na typ zprávy. Tím rozbijou i Path MTU Discovery. A krom toho všechny chyby, které u nich nastanou, se od toho okamžiku projevují timeoutem TCP či aplikačního protokolu, bez jakéhokoliv pokusu o vysvětlení. Proti tomu je zákaz Echo už jen drobnou patálií. A zvlášť pikantní jsou tyhle zákazy ICMP u IPv6, kde nefunkční PMTUD prakticky znamená, že půlka komunikace vytimeoutuje.
Za Blokaci ICMP by se někdy měli „lámat ruce“ obzvláště u mého bývalého ISP, který blokoval ICMP průchod přes jeho síť. To pak bylo divu, že si člověk nepingne ani seznam když mu tracert skončí před serverem ISP :)
add ping: zakázat, jinak DDOS
add port 25: jako klienta mne to štve, ale pořád lepší než tuna spamu. Provider by měl implicitně zakázat a povolovat na vyžádání.
ping jinak DDOS ? ehm… a jeste dalsi sluzby HTTP treba ? DNS ? priklanel bych se k prvnimu komentari, dle RFC je dobre by ICMP chodilo, nicmene vse v siti by melo pocitat s tim ze to muze byt zahozeno, nicmene NORMALNI reseni je ping limitovat, nez zakazovat.
ICMP pro DDoS? Ale jasne. Nekde si vygenerovat „par“ echo-request paketu s podvrzenou source IP, nechat korektne odpovedet ty nahodile stroje v internetu na tu vyse podvrzenou a onen cil ma tolik odpovedi, ze nevi co s nima ma delat… :-)
Jasne, neni to co do objemu takova darda, jako treba u NTP ci DNS – u ICMP alespon nedochazi k efektu zesileni (takze se to tolik nepouziva) – kdy na maly paket chybne konfigurovany server generuje vyrazne vetsi odpoved, u ICMP je „aspon“ ta odpoved stejne velka jako request.
Inu dusledek toho, ze v sitich se dodnes jen na malo mistech implementuje RFC 2827 :-) …14 let stare doporuceni. A zneuzivani starych jednoduchych protokolu z dob, kdy „nikdo nikomu neskodil“ k necemu, co nikdo puvodne nezamyslel.
Text RFC 792 rozhodne tak jednoznacny neni – je to poplatne dobe jeho vzniku, kdy se jeste prilis neresila ustalena terminologie (ktera prisla az s RFC 2119 o mnoho let pozdeji). Ostatne nac kritizovat banku, k plosne blokaci ICMP dochazi treba i ve vychozi konfiguraci firewallu novejsich Windows…
Ze ICMP muze byt dobry sluha, ale take zly pan dokazuje treba „Loki“. ICMP protokol se dnes mimo jine i zneuziva k vecem, ke kterym nebyl zamyslen. Resit hloubkovou protokolovou inspekci u nestavoveho ICMP a porovnavat cely obsah zdrojoveho a ciloveho paketu (kdy v ICMP prenasena „data“ se pouzivaji v rozporu s RFC) je… sakra narocne. Fakticky by to znamenalo na firewallu drzet v pameti po nejaky cas kazdy prichozi ICMP „request“ pro budouci porovnani, zda odchozi „reply“ obsahuje v payloadu identicka data v souladu s RFC 792. Uz samotne porovnani cele datove casti ICMP paketu bude klast nejake naroky na vykon.
Uvedomte si, ze to RFC 792 je z roku 1981 a od te doby jej nikdo neaktualizoval. Pred 33 lety si ale malokdo pripoustel bezpecnostni problemy, ktere jsou dnes bohuzel kazdodenni zalezitosti. Lpet na jednom konkretnim vykladu (ktery muze mit kazdy jiny) stareho RFC je samo o sobe zvlastni. Kritizovat druhe, ze na dane riziko zvoli nejake reseni (treba i problematicky protokol zakazat, pokud neni k necemu vylozene potreba) je v 21. stoleti zcestne. Samozrejme i zajisteni ochrany stoji nejake penize a pokud tyto nejsou k dispozici v plne vysi, tak clovek resici bezpecnost infrastruktury holt alespon zvoli takove reseni, ktere nemusi byt z pohledu RFC fanatika ciste a slunickove, ale svuj ucel splni. Protoze krome bohulibych (monitorovacich) ucelu je i ICMP zneuzitelne i jako back-door – pokud nejsou zajistene hloubkove kontroly popsane vyse (a to je casto problem). A samozrejme jen „rate-limit“ problem Loki neresi.
K tomu SMTP a „stourani se v obsahu“ – je to stejne jako s ICMP, nektere (pokrocilejsi) firewally se snazi mj. o hlubsi protokolovou inspekci. Tzn. se nezajimaji jen o to, zda je legitimni komunikace pres dany TCP/UDP port, ale soucasne nahlizi do obsahu one komunikace – zda komunikace pres dany port skutecne odpovida ucelu, pro ktery je prostup pres firewall otevreny (tzn. zda pres ten port skutecne bezi posta a ne nejaky nedefinovany stream – treba genericky tunel pres TCP). Sifrovani tuto inspekci do znacne miry znemoznuje, takze se samozrejme „hledaji“ ruzne obezlicky, kterak toto obejit. Opet je to vec tykajici se bezpecnosti. Analogicky u ISP – bud muze port 25 zakazat, nebo jej prohnat nejakou „transparentni“ aplikacni proxy (kde zajisti nejakou uroven ochrany pred zneuzitim sluzby, aniz by neznemoznoval normalni uziti)… nebo nechat koncove stanice volne spamovat do internetu. Je potreba posuzovat lokalni prostredi, kde k takovemu „zasahu“ dochazi a premyslet. Zvlast v sitich, kde se provadi 1:N NAT je zpetne slozite dohledat konkretni spamujici stanici, kdyz z vnejsiho sveta se dozvite pouze IP, za kterou mate schovanou hromadu koncovych uzivatelu – a pokud to nechcete zablokovat uplne. Kdyz uz se bavime o fuserine – zakladem pro obecne zfusovani bylo samotne RFC 1631, kdy formalne padlo paradigma o otevrene end-to-end komunikaci. Jiz pred 20 lety… :-)
Jak jiz jsem rekl, obcas se to chce zamyslet i nad motivaci, proc to ty lidi delaji :-) Ony ty duvody muzou mit v konkretnich mistnich podminkach racionalni zaklad. Vy zde odsuzujete, ze ISP „neco“ dela, Vasi kolegove z CSIRTu by asi byli znacne rozladeni, kdyby se nedelalo nic ;-) A nic nedelaji zejmena prave ti, co netusi o dnesnich rizicich.
Ohledně toho blokování emailu, a to portu 25 nebo dneska i obskurního 465 (pár červů jelo i přes SMTPS, tak řada blokuje i to), tak je mi mnhem milejší, když to ISP natvrdo blokne než přesměruje na své servery, profiltruje a případně pošle dál. Tímto totiž totálně rozbije SPF/DKIM/DMARC, pokud je používán a mail šel původně na server, co to měl zlegalizovat a forwardovat případně dál k adresátovi. Protože po profiltrování to ISPík pošle dle hlavičky To: a ne tam, kam to spojení původně šlo…
Když to blokne, tak vím hned, že to nedojde a můžu si vyslechnout osvětu o submisson. Jenže řada ISP, než se hádat s klienty to přesměruje natvrdo na sebe profiltruje a pošle někam, často blbě, kde případná kontrola na zmíněné mechanismy to zlikviduje.
Ono to vlasntě je i dost na hraně zákona. Sice zákon o elektornickýh komunikcích dovoluje dělat akce pro ochranu sítě, ale zase zákon o některých aspektech informační společnosit říká, že pokud ISPík změní obsah přenášených dat nebo cíl doručení (což často provede), tak se stává zodpovědný za to, co s tím udělal. A tretsní zákon to může chápat jako klasický MITM útok, navíc prováděný telko operátorm, takže se zvýšenou trestní sazbou. Mohl by to být zajimavý spor, pokud by na toto někdo podal trestní oznámení, zda to ISPík uhraje na možnost dle ZoEK nebo by to už bylo nad rámec jeho pravomocí. :-)
Za svůj život jsem měl možnost vystřídat 3 různé ISP a díky bohu žádný z nich tyto „zlepšováky“ nepoužíval. Troufam si rici, ze v tomto pripade hraje roli jejich velikost. V pripade ISP, který má radové stovky az tisíce zakazniku je totiž počet top odborníků (nikoliv techniku „pripojovacu/odpojovacu koncového zákazníka) v zasade stejný jako u ISP se statisici klientů. Pak musí vcelku logicky dojit bud k realizaci euznych obezlicek, polovičatých reseni, nebo jeste hure k praktikam na základě obyčejné lenosti. Pokud k tomu jeste pridate finanční či jine tlaky korporace, …
Osobnesi myslím, ze nebudu tak daleko o Vašich uvadenych vytecniku. Pokud ano, rad uznam ze se mylim – v takovém pripade by to totiž nebylo s celým inzernetem jeste tak zle, jak to dnes, již na první pohled vypadá…
P.S.: Jeden můj bývaly provider pouziva drahou ale velmi uzitecnou masinku. Na spam listu jako provider, pokud je mi známo, nikdy nebyl. Na několika mail serverech, které jsem v jeho síti opecovaval u klientů bylo prichozicho spamu také výrazně mene než jinde. Port 25 totiž smerem ven při podezření na zneužití rovnou blokoval a klientovi vzapeti volal telefonem, zda je vše v pořádku. Po naprave/vyjasneni situace port ipet uvolnil. Starat se o sit poradne je holt kus odpovedne práce. ;)
Tenhle článek je úplnej paskvil, autor očividně nikdy nedělal u žádného ISPka. Turise máme na síti jednoho (díky bohu) a mohu říci, že je s ním nejvíce problémů ze všech zařízení. Nezvládne se připojit přes Hotspot který je nastavený v mikrotiku (tudíž musí bejt ručně bajpáslej), občas se sekne a začne vytěžovat celou linku tak že zkolabují všechny spoje a naty po cestě (to je zcela nejlepší) a když už konečně třeba i funguje tak najednou si začne krátit rychlost (měření bez Turise = 90M měření s Turisem = 30M) prostě šrot největšího kalibru.