Druhé setkání CSNOG zahájil Ondřej Filip, který připomněl, že zakladateli jsou sdružení NIX.CZ, CZ.NIC a CESNET. Komunita je ale z principu otevřená a kdokoliv se může zapojit a aktivně pomáhat. Cílem těchto setkání je vytvořit prostředí pro komunikaci lidí zabývajících se především sítěmi a vším, co s nimi souvisí.
Eugene Bogomazov: Running BGP in 2019
V ideálním světě by k provozu BGP stačily tři věci: přečíst si dokumentaci, získat prefixy a ASN a všechno správně nastavit. Ve skutečném světě ovšem existuje spousta překážek, která z celé věci dělá netriviální úkol: implementace nerespektující standardy, zastaralý hardware, chybné konfigurace, nešikovní správci a útočníci. Ti se snaží poškodit váš byznys, odklonit provoz a získat z toho peníze pro sebe.
Pokud už problém vznikne, je potřeba co nejdříve zareagovat, najít podstatu a odstranit ji. Aby všechny procesy běžely co nejjednodušší cestou, je důležité mít standardy, kterými se mohou operátoři řídit. Máme BCP194, které se věnuje provozu a zabezpečené BGP.
Pro bezpečnost jsou zásadní filtry prefixů, které nám dovolují zamezit přijetí některých prefixů například z vybraných směrů – například z peeringových uzlů. Další možností je například AS_PATH filtr a podobně. Filtry by neměly být udržovány ručně, ale je potřeba použít nějakou automatizovanou metodu.
Diskutuje se o některých aspektech, jako například maximální délka AS_PATH. RFC ji neurčuje, ale pokud bude příliš dlouhá, mohou s tím mít některé routery problémy.
Příliš dlouhé AS_PATH by tedy měly být filtrovány, ale jak určit správnou hranici? Komunita by o tomhle problému měla diskutovat a vytvořit nějaký dokument, který by tuto oblast pokrýval.
Pokud se objeví nějaký síťový problém, je nejprve potřeba určit, zda souvisí s BGP. K tomu může pomoci celá řada nástrojů jako RIPE Atlas, RIPE Widgets, veřejná API, databáze Whois a podobně. Pro analýzu BGP pak je možné použít přímo data z BGP nebo různé nástroje jako bgpdump či různé nástroje typu looking glass. Ty jsou skvělé, ale mají různé možnosti a neexistuje pro ně žádný standard.
Pokud zjistíme, že jde o útok, snažme se najít útočníka. Jde o manipulaci s AS_PATH? Snažte se zjistit co nejvíce informací a odhalit konkrétní zdroj.
Co ale udělat potom? Můžeme oslovit abuse kontakt nebo napsat do specializovaného mailing listu. Tyhle kroky ale nejsou příliš proaktivní a bude trvat, než se něco stane. Můžeme také reagovat aktivně, vytvořit nový filtr či oznamovat specifičtější cestu a převzít opět kontrolu nad svým rozsahem.
Velkým posunem v bezpečnosti BGP je podpis prefixů pomocí ROA. V současné době je v našem regionu podepsáno 21 % prefixů, což je velmi dobrý výsledek.
Tomáš Hlaváček: Secure routing in the Internet
RPKI je už poměrně starý standard, jehož cílem je svázat origin a oznamované prefixy. Výsledkem je možnost validace těchto prefixů a ověření, že pocházejí od správného zdroje. Validace se provádí pomocí validace (ROV) podepsaných a publikovaných zpráv (ROA). V našem regionu se o vše stará RIPE a celý proces je velmi přímočarý a jednoduchý. To celé přináší částečné zabezpečení BGP routingu.
Počty ROA, tedy kryptografických artefaktů svazujících, rostou velmi rychle a v současné době se pohybují okolo 20 %. Horší je to s validací pomocí ROV, což má několik různých důvodů. Co má router udělat s tím, když zjistí, že je ROA nevalidní? Jednou z možností je snížit preferenci, což je částečná ochrana, ale ne úplná.
Různé experimenty ukazují, že jen asi 0,1 % AS v internetu skutečně zahazuje nevalidní routy. Nejnovější testy ukazují, že jen 5 ze 4000 sondovaných ASN určitě provádí ROV. Výsledky dlouhodobých a pravidelně opakovaných měření je možné najít na rov.rpki.net.
Kdyby ROV začaly vynucovat a reálně aplikovat největší tranzitní AS, znemožnilo by to drtivou většinu globálních únosů prefixů. Měření ukazují, že kdyby ROV nasadila stovka největších autonomních systémů, měli bychom polovinu cest na internetu zabezpečenou.
ROV v peeringových centrech by zabránilo šíření globálních a překazilo lokalizované únosy.
Proč tak málo autonomních systému vynucuje ROV? Nejčastěji zaznívají obavy s automatického odpojování sítí, protože existují chybné či zapomenuté ROA.
Tyto problémy jsou prozkoumané a zveřejněné na webu NIST. Z naměřených čísel vyplývá, že existuje asi šest tisíc nevalidních ROA. Otázka je, jestli to reálně ohrozí cesty, kterými posíláte data.
Reálná data dopadů byla na prvním setkání CSNOG publikována vloni.
Zdeněk Brůna: Jak šlape CZ DNS Anycast
Anycast staví na běhu více serverů se stejnou IP adresou, přičemž se opírá o BGP routery směrující provoz na nejbližší lokalitu. To zajišťuje load balancing, který případně umí vyřadit nefunkční lokalitu v případě výpadku.
Doména .CZ je v 17 fyzicky oddělených lokalitách v 10 různých zemích. V předchozích letech jsme se zaměřili na hardwarový upgrade anycastu, abychom ustáli větší provoz.
V Česku je v současné době 68 samostatných serverů, v zahraničí je dalších 36 serverů. Navýšena byla také konektivita, dnes je v Česku do serverů celkem připojeno 340 gigabitů a v zahraničí 85. Rozhodli jsme se dát do provozu velké stacky, které jsou schopné samy odbavit 100 Gbps provozu.
Výsledkem celého upgrade je, že servery dokáží obnovit desetkrát více dotazů, teoreticky až 200 milionů dotazů za sekundu (QPS). Běžný provoz je přitom 20 000 QPS. To je ale běžný provoz. Dnešní útoky by mohly nabývat skutečně obrovských rozměrů a víme, že k nim dochází.
Aby CZ.NIC předcházel různým chybám, snaží se udržovat velkou diverzitu hardware i software. Servery pocházejí od různých výrobců, jako operační systémy se používají Ubuntu, Debian, OpenBSD, routovací démony BIRD, BGPD, Quagga a DNS servery Knot, Bind a NSD. Samozřejmě to našim adminům komplikuje správu.
Důležité je také správné geografické rozmístění DNS serverů, pro který je potřeba znát profil provozu a dobu odpovědi na jednotlivé dotazy. Dříve se používala aktivní měření pomocí pingu, dnes se přechází na pasivní analýzy. Za měsíc je takto naměřeno 1,5 miliardy dotazů, přičemž drtivá většina jich přichází po UDP. Jen 0,21 % jich používá TCP, což je málo, ale vlastně je to hodně.
Téměř 30 % provozu generují IP adresy z českých rozsahů, dalších 25 % pak vzniká ve Spojených státech. Tohle nám ale neodpovídá na to, jak ladit svou infrastrukturu, protože všechny tyhle dotazy někam dojdou a odbaví se.
Zajímavější je doba vyřízení dotazu, kde je na tom samozřejmě nejlépe Evropa, hůře je na tom zbytek světa. Na tahle čísla se ale musíte dívat také z pohledu provozu. V Africe máme delší odezvu, ale vzniká tam velmi málo provozu.
Pokud se vezme v potaz množství provozu a zpoždění, je zřejmé, že by bylo vhodné přidat další servery do jihovýchodní Asie, Austrálie a na Nový Zéland. Tyhle statistiky děláme velmi podrobně a pomáhají nám zjistit, kam máme zaměřit svou další snahu.
Největší provoz v současné době míří do Prahy do CE Colo. Tam máme nejlepší tranzitní konektivitu, takže je to pro nás preferovaná lokalita, kam míří spousta provozu z celého světa.
Petr Špaček: DNS flag day-nějak bylo, nějak bude?
V roce 2018 skupina tvůrců DNS resolverů vyhlásila, že je potřeba očistit protokol problémů s EDNS. Při poslání dotazu v některých případech nedorazí žádná odpověď, ale resolver nemá jak poznat, kde vznikla chyba. Ve výsledku to znamenalo timeouty, kdy z pohledu uživatele narůstalo zpoždění.
Za problémy mohly nesprávné implementace Extended DNS, kdy hacky z roku 1999 způsobovaly problémy i v roce 2018. Částečně jsme si to způsobili sami, protože tenkrát vypadalo jako dobrý nápad udržet kompatibilitu se starými implementacemi.
Vznikla tím řada nestandardních implementací, které z hlediska uživatele fungovaly, protože resolver nakonec našel typ dotazu, na který dostal odpověď. Ono to nějak fungovalo nefungovalo dvacet let a nebyla motivace to příliš řešit.
Proto přišel plán odstranit tyhle složité heuristiky a odstranit všechny nestandardní obezličky. Standard jasně definuje, jak má server reagovat na dotaz, kterému nerozumí.
Díky spolupráci velkých hráčů na DNS trhu se podařilo vyvinout dostatečný tlak na provozovatele nestandardních implementací DNS serverů odporujících standardů.
Protože šlo o první podobný pokus, byla na místě opatrnost. Bylo zjištěno, že ohroženo je asi pět procent domén. Ukázalo se, že za 85 % problémů můžou čtyři velcí provozovatelé DNS serverů, kteří to mají rozbité.
Všechny problémy byly nakonec opraveny zavčasu nebo se týkají nepoužívaných domén, které uživatele vlastně nezajímají. Navzdory všem předpovědím byly telefony technické podpory v klidu a z celosvětového měřítka se nestalo nic.
Podařilo se tak vyřešit nepříjemný problém, který v DNS hnil
dvacet let. Je vidět, že společnými silami se dá pohnout i s tak velkou věcí, jakou je DNS.
V českých doménách se ještě před zavedením změny podařilo snížit počet ovlivněných domén na 0,03 %.
Komunita se na setkání DNS OARC bavila o tom, jaký další vážný problém má smysl takto masivně řešit. Komunita se dohodla na tom, že velké problémy způsobuje IP fragmentace.
Z hlediska uživatele jde o podobný problém, protože způsobuje ztrátu odpovědí. Ukazuje se, že ve třetině případů velká odpověď sítí neprojde. IP fragmentace je rozbitá a IETF říká, že fragmentace je mrtvá.
DNS se na tuto situaci musí adaptovat, právě na tuto oblast se zaměřuje další DNS Flag Day. I kdyby fragmentace fungovala, je nebezpečná. Stejně bychom se s ní museli nějak vypořádat.
Výsledkem je, že pro velké DNS odpovědi se povinně přepne na TCP. DNS over TCP je s námi velmi dlouho, jde o standardizovanou věc.
V současné době se ve většině serverů používá hodnota 4 kB, kdy se větší odpovědi posílají pomocí TCP. Dochází ale k tomu, že například tříkilobajtové UDP pakety se po cestě musí fragmentovat a nikdy pak nedorazí. To zase způsobuje timeout, opakování dotazu a zvýšení latence.
DNS Flag Day 2020 tedy přichází vlastně s jedinou změnou: maximální velikost odpovědi posílané po UDP (EDNS buffer size) bude nastavena přibližně na 1220 bytů.
Autoritativní servery prakticky nebudou potřebovat žádné výrazné změny, novější verze budou jen jinak nastavovat zmíněnou hraniční hodnotu. Problémy mohou způsobit jen firewally, které by mohly zahazovat komunikaci po TCP na port 53.
Podle současných globálních měření je změnou ohroženo asi 7 % domén, přičemž za téměř 70 % z nich může jediný čínský operátor. Situace je podobná jako v prvním DNS Flag Day. Opět stačí opravit situaci u několika málo firem.
U resolverů je ohroženo asi 2,5 % uživatelů, ale tato měření je poměrně obtížné provádět. Pokud budete mít aktuální software, opět byste neměli mít problém.
V doméně .CZ je nepřipraveno jen 1125 domén, opět jen u několika málo provozovatelů. Dva největší jsou doménoví spekulanti, takže jim nebude vadit, že jim to rozbijeme.
Webový testovací nástroj se zatím připravuje, ale už teď je možné použít běžné nástroje jako je dig. Všechny dotazy poslané přes TCP musí fungovat, stačí tak vyzkoušet dotazování pomocí parametru +TCP.
Zatím chybí přesné datum, protože teprve probíhají měření. Není zatím známá ani přesná hodnota největší odpovědi posílané po UDP. Bez ohledu na ni ale stále jde o to, aby fungovalo dotazování po TCP. Pokud vám funguje, nebudete mít problém.
Ondřej Surý: Co se děje v protokolu DNS?
DNS vypadá poměrně jednoduše, ale je tvořeno 200 dokumenty RFC, tedy asi 3000 stranami textu o milionu slov. Co s tím? Jedním z návrhů bylo přestat psát RFC nebo začít konsolidovat stará RFC.
Zatím se ale nenašel nikdo, kdo by se tohoto heroického úkolu zhostil.
Rozumným návrhem naopak je, aby se vyžadovala skutečná implementace v software před plnou standardizací. Na základě zkušeností by se pak návrh standardu dal upravit.
Pořád to ovšem neřeší současný stav, kdy je standard popsán v mnoha různých dokumentech.
Z nejnovějších RFC je možné zmínit například Query Name Minimization, který zkracuje dotazy na nutné minimum, takže se ve všech dotazech neobjevuje kompletní doménové jméno. To vypadá velmi jednoduše, ale naráží to na praxi v různých load balancerech a CDN, které často neimplementují celý standard a neodpovídají na NS záznamy, ale jen na A. Velmi často také místo NODATA odpovídají stavem NXDOMAIN, který říká, že v celém stromu už neexistuje žádný další záznam.
Většina implementací dnes už minimizaci umožňuje použít, ale obvykle je zapnuté jen v omezeném režimu. Neodpovídá to standardu, ale je to tak proto, aby to rozbíjelo co nejméně věcí. Opět je to rovnák na ohejbák kvůli špatným implementacím DNS serverů..
Další novinkou jsou DNS cookies, které jsou ochranou před podvrženými DNS zprávami. Hodnoty cookies se počítají pomocí různých algoritmů, což způsobuje problémy v anycastu. Pokud chcete používat různé implementace DNS, narazíte na to, že různé servery používají různé algoritmy a při přepnutí klienta na jiný server v anycastu se to celé rozbije.
ISC a NlNetLabs pracují s přispěním dalších členů komunity se standardizací odpovědí mezi různými servery.
Zajímavý je standard DNS over TLS definované v RFC 7858, který přidává šifrování na transportní vrstvě. Používá vlastní TCP port 853, zatím jen pro komunikaci mezi stub resolverem a nadřazeným resolverem. Velmi rychle se ukázalo, že DNS dotazy jsou velmi krátké a i při zašifrování může útočník podle délky zprávy odhadovat, na co se klient ptá. Proto vzniklo RFC 7830, které přidává do zprávy další data a zarovnává velikost na standardní hodnotu. Tu definuje RFC 8467, které doporučuje zarovnávat na násobky 128 oktetů (bajtů). Zprávy jsou pak sice různé velké, ale jsou hodně unifikované.
Konkurenčním standardem je DNS over HTTPS, které definuje RFC 8484. Většina komunity si myslí, že to celé není dobrý nápad. Ale já se chci věnovat technické stránce.
Data jsou posílána ve formátu DNS wire a protokol umožňuje míchání různých dat v jednom streamu. Umožňuje to kešování na HTTP vrstvě, ale vzniká tam složitější interakce HTTP Max-Age a DNS TTL, což zase rozbíjí TSIG.
Připravuje se také standard ANAME, který řeší možnost přesměrování z apexu zóny, kde nemůže existovat klasický CNAME záznam. Jde o poměrně starý problém, který se snažily řešit některé staré návrhy standardů: CNAME+DNAME, BNAME a HTTP RR.
Nejnovějším pokusem je právě ANAME, který je vlastně něčím jako CNAME záznamem, ale jen pro A a AAAA záznamy. Podporuje transfer mezi různými nameservery a poskytovateli DNS hostingů. Největší problém je plynulý přechod a podpora starých DNS klientů. Vždycky musíte ještě nějakou dobu podporovat i ty staré způsoby, což v DNS obvykle znamená navždy.
Petr Špaček: DNS-přes-???
Klasické DNS běží po UDP a TCP na portu 53. Ten lze snadno blokovat, filtrovat, modifikovat a server není nijak autentizován. O třicet let mladší je DNS over TLS (DoT), které přidává další vrstvu známou z jiných protokolů. Má samostatný TCP port 853, takže jej lze opět snadno blokovat, ale díky šifrování nelze obsah číst či modifikovat a při správném použití autentizuje server a chrání před MitM útoky.
DNS over HTTPS (DoH) přidává ještě další vrstvu v podobě obecného HTTP včetně všech běžných vlastností. Používá standardní port 443 pro HTTPS, takže jej nelze snadno blokovat a součástí je automaticky autentizace serveru. Do HTTP je možné přidat spoustu dalších informací, což otevírá další možnosti. Je to ale pandořina skříňka, protože to umožňuje vracet různé odpovědi a hrozí to rozdrobeným jmenného prostoru.
Poslední přírůstek mezi transportními protokoly je zatím jen na papíře a jde o DNS over QUIC. QUIC je obecný protokol, který nemusí být použit jen s HTTPS/3, takže dává smysl ho použít i pro DNS.
Zatím jde ale opravdu jen o návrhy, ale můžeme se s ním v budoucnu setkat.
Šifrované DNS ovšem v žádném případě není náhradou za DNSSEC, který zajišťuje podepisování end-to-end. DNSSEC je stále relevantní a nové transportní protokoly mu neubírají na důležitosti.
Nové protokoly ovšem přináší šifrování dat a autentizaci DNS resolveru. Síťové prvky pak nemohou sledovat a upravovat provoz, což je výhoda v kavárně, ale už méně ve firemní síti.
Zatím chybí standard o auto konfiguraci, takže se klient v nové síti nemá jak dozvědět, jaké protokoly jsou dostupné, kde se nachází resolver a podobně. Také je potřeba si uvědomit, že i přes šifrovaný DNS pak doménová jména mohou unikat dalšími kanály. Například pomocí SNI nebo je možné je identifikovat pomocí IP adres, ke kterým se klient připojuje. Pokud chcete opravdu soukromí, raději použijte VPN, do které schováte všechno.
Trendem jsou dnes DNS v cloudu, přibývá služeb jako 8.8.8.8, 1.1.1.1 nebo 9.9.9.9. Ty ignorují místní DNS, obcházejí různé lokální filtry a kvůli absenci místní cache pak generují více provozů do internetu. Obvykle datový tok naroste 10 až 30krát, stoupne také počet TCP spojení. Pak je tu otázka politická, protože vzniká konflikt českých a zahraničních zákonů. Jak například dodržet zákon o blokaci hazardních her, když posíláme dotazy někam do Ameriky?
DNS se dnes také přesouvají do aplikaci, minimálně některé aplikace si chtějí vše implementovat po svém: například prohlížeče Firefox a Chrome. Tím se ale některé aplikace budou chovat jinak než ostatní, může dojít k rozdílnému pohledu do DNS a přinese to problémy s laděním. Přestane také fungovat například přesměrování klientů v lokální síti do naší místní keše pro některé služby. S DNS v cloudu ale ztrácíme kontrolu nad odpověďmi a budeme muset předávat do cloudového resolveru také informace o tom, kam má směrovat naše uživatele.
Přesun DNS do aplikací a cloudu může mít také právní dopady. Pro zákon o hazardních hrách zatím stačí upravovat odpovědi v místním DNS, ale v budoucnosti to nebude fungovat. Ustoupí ale ministerstvo financí Mozille a spokojí se s tím, že ve Firefoxu zakázané hazardní hry fungují?
Pravděpodobně ne a bude potřeba sáhnout k drastičtějším opatřením jako je inspekce provozu nebo povinné nasazení proxy serverů v sítích.
Zastánci těchto opatření se zaklínají lepší ochranou soukromí, ale nový přístup má také své problémy. Centralizací do několika DNS resolverů vzniká velmi lákavý cíl pro šmíráky, kteří mají o podobná data velký zájem. Zároveň jsou pak dotazy každého uživatele zřetězeny do jednotného proudu, takže je možné jej lépe identifikovat. Kde je pak to soukromí?
Jan Včelák: War games: Live security DDoS drills
NS1 provozuje anycastovou síť DNS serverů, která je rozprostřena po třech desítkách lokalit. Většina útoků je lokalizovaná do jednoho místa, takže neovlivní uživatele ve zbytku lokalit.
Zároveň se proti nim poměrně snadno brání, protože je zasažen jen jeden server. Podstatně horší dopady mají DDoS útoky, které zasahují více míst. Obvykle se snaží vyčerpat zdroje, například konektivitu nebo procesorový čas či paměť.
Velmi často jsou dnes k útokům zneužívány odrazy přes různé služby jako DNS nebo NTP. Tam lze podvrhnout zdrojovou adresu a odpověď je pak výrazně větší než dotaz, takže lze zahltit linky oběti.
Populární jsou také DNS dotazy zneužívající otevřené resolvery, kdy pak oběť vidí jen provoz z legitimních resolverů a ne z původního zdroje.
Nejprve je potřeba útok vůbec odhalit, což vyžaduje často podrobnou inspekci paketů, sledování metrik a hlavně dobrý systém varování. Pro řešení problémů je potřeba nasadit filtrování a omezování provozu. My využíváme možností, které nám dává BGP. Můžeme tak celý provoz poměrně podrobně ovlivňovat.
Aby se společnost naučila bránit se útokům, rozhodla se pořádat vlastní interní cvičení nazvané War Games, podle známého filmu. Cvičení pomáhá správcům pochopit konkrétní situace, naučit se reagovat na neustálý vývoj útočníků a jde také o dobrý způsob, jak systém představit novým lidem v týmu.
Každé dva týdny probíhá cvičení na produkčních systémech, které trvá jednu až dvě hodiny. Většinou používáme video hovory a sdílený kanál na Slacku. Ke všemu si píšeme poznámky, které později procházíme a případně podle nich upravujeme dokumentaci.
Během cvičení má jeden člověk roli útočníka a snaží se své kolegy překvapit. Obránci testují, zda všechny jejich nástroje fungují.
Po každém cvičení se přijde na věci, které je potřeba zlepšit: dokumentace je chybná, operátoři si nepamatují syntaxi k ovládání nástrojů, objeví se nové vektory útoků a podobně.
Pokud byste si chtěli něco podobného vyzkoušet, měli byste používat co možná nejrealističtější prostředí. Určitě si také vše zaznamenávejte a zpětně procházejte záznamy ze svých cvičení.
Útočník by také neměl podcenit přípravu a hlavně by vše mělo být zábavné a zajímavé.
Ivo Fišer: VoIP podvody
Velcí telefonní operátoři mají obvykle specializovaný tým lidí, kteří mají v této oblasti velmi dobré know-how a postupně si ho předává. Malý operátor má obvykle nějakého IT správce, který se občas s nějakým problémem setká a musí se s ním poprat.
Podvodů existuje celá řada, s časem se mění a některé už dávno odvál čas. Nejčastěji se setkávám se zahraničními hovory, ty jsou jednoznačně nejrozšířenější.
Velmi často podvody přicházejí z přímé blízkosti obětí. Nezapomeňte se dívat kolem sebe, velmi často v podvodu hraje roli nějaký kolega nebo dodavatel. Byť jen v roli spolupachatele.
U podobných podvodů jde o poměrně vysoké částky, během jednoho dne může jít o desítky až vysoké stovky tisíc korun. Obvykle je částka zhruba na polovině až dvou třetinách maxima, protože útočník nevede trvale několik podvodných hovorů, ale snaží se simulovat běžný provoz a vytvářet provoz podobný normálnímu.
Hovory pak běžně mění délku, jsou mezi nimi hovory, mění se cílové země a podobně. Na první pohled to nevypadá jako podvod, kromě toho, že hovory jdou do exotických destinací. Podvod trvá tak dlouho, jak mu to dovolíte. Podle toho se také odvíjí výše škody.
Pro útočníka pak nastává další problém, jak peníze skutečně vybrat. Obvykle se to podaří, protože si operátoři provolané částky vyfakturují a obětí pak přijde faktura navýšená o několikerou marži.
Jelikož jde o mezinárodní podvod, policie ne z něj nešťastná a obvykle si neví příliš rady.
V první fázi musí útočník najít nějaké zranitelné zařízení nabízející SIP žádostí OPTION. Když spustíte na internetu zařízení na portu 5060, přijde vám první dotaz během několika minut.
Nepomůže ani přesun na vyšší porty, útočníci zkouší i jiné porty, dřív nebo později dotaz přijde.
Poté útočník začne zkoušet různá čísla nebo uživatelské účty, snaží se hádat různá běžná hesla. Poté ještě musí zjistit, jakou volbu musí použít pro přechod do mezinárodní sítě. Dříve jsme doporučovali ochranu mezinárodních hovorů pomocí PINů, ale je to zbytečné. Útočník začne zkoušet různé kombinaci čísel a prapodivných znaků a stejně ho dřív nebo později uhádne.
Poté už může začít samotný útok, kdy se volá na speciální čísla v nejrůznějších exotických zemích.
Ochranných opatření existuje celá řada, žádné z nich ale není dokonalé. Je možné kontrolovat počet neúspěšné pokusy, přidání zpoždění do autentizace, používání kreditního způsobu úhrady hovorného a blokování SIP registrace ze zahraničních adres a podobně. Osvědčily se nám dvě metody: omezit hovory pouze do skutečně potřebných zemí a limitace souběžných zahraničních hovorů.
Je také možné úspěšně redukovat škody tím, že se omezí volané destinace v různých dnech včetně víkendů.
Telefonní podvody byly, jsou a budou, jen se mění jejich podoba. Neexistuje zázračná metoda ochrany, je vždy potřebné kombinovat více způsobů vhodných pro danou operátorskou či pobočkovou ústřednu.
Všichni velcí operátoři používají SIP firewally a měli by je určitě mít také operátoři všech velikostí.
Karel Tomala: Vliv kvalitativních datových parametrů a maximální rychlosti na TCP propustnost
Mezi kvalitativní datové parametry služby přístupu k internetu patří: maximální rychlost, inzerovaná rychlost, běžně dostupná rychlost, minimální rychlost, latence, kolísání kvality přenosu rámců nebo paketů a ztrátovost rámců nebo paketů. ČTÚ v roli regulátora musí stanovit minimální závazné kvalitativní datové tarify. V současné době tyto parametry nemají závaznou povahu, ale jsou jen doporučeními.
ČTÚ vypracoval metodiku měření parametrů, která využívá měření pomocí UDP a odpovídá tak druhé vrstvě v modelu ISO/OSI. Pokud operátor dodržuje stanovené parametry, je zařazena do jedné ze tří kvalitativních skupin. Nejvyšší třída má stanovenou latenci do 25 ms, jitter pod 8 ms a ztrátovost nižší než 0,01 %. Kvalitativní parametry je možné emulovat v našem testovaném polygonu. Tam jsme zjistili, že nejvyšší stanovené parametry nedostačují pro poskytování rychlostí nad 400 Mbps.
Proto by měla být přidána ještě vyšší třída sítí, která bude schopna s ještě přísnějšími parametry poskytovat rychlost až gigabit za sekundu.
Původně byl důraz kladen především na zpoždění a ztrátovost, ale ukázalo se, že s rostoucími rychlostmi začíná mít čím dál větší vliv i jitter. Při 40ms jitteru už je možné na 200Mbit lince dosáhnout jen 100 Mbit na TCP. Jitter hraje významnou roli, nejen ztrátovost a zpoždění.
Ondřej Caletka: Introduction to NOGs, especially CSNOG
NOG znamená Network Operator's Group a mělo by jít o skupinu propojující lidi z odvětví provozovatelů internetových sítí. Nejde o český výmysl, ale jde o aktivitu rozšířenou po celém světě. CSNOG je specifický v tom, že není určen pro jedni zemi, ale je společný pro Česko a Slovensko.
Existuje spousta dalších sdružení jako NLONG, ENOG, NLNOG a další.
Důležité je, že by mělo jít o otevřenou neutrální komunitu, která je otevřená každému. Nemusí se v ní řešit jen problémy se sítěmi, ale všechna související témata. Dnes jste viděli přednášky o open source, DNS a dalších tématech.
Většina podobných skupin vznikla tak, že vyrostla z malých do velkých. Nemá jít o konferenci, ale o otevřené fórum. Nejsou tu žádní oni a my, jsme tu jen my.
Vyřazovány jsou příspěvky reklamního a marketingového charakteru, upřednostňují se obecná technická témata. K tomu je tu nezávislá programová komise, která příspěvky vybírá.
CSNOG je pokus o zavedení NOG v Česku a na Slovensku. Vzniklo to neformálně během RIPE 75 a oproti ostatním jsme zvolili opačný postup odshora dolů.
Začalo se už ve velkém stylu a bylo uspořádané první velké setkání, které organizoval CZ.NIC, NIX.CZ a CESNET. Pořád to ale není konference a neorganizuje to CZ.NIC. Stále je to otevřené pro partnery a organizátory.
Kromě samotných setkání je možné s ostatními členy komunity komunikovat pomocí mailing listu, Telegramové skupiny, workspace na Slacku či organizace na GitHubu. Kanály jsou bohužel zatím používány velmi málo a je na komunitě, aby je zaplnila užitečnou konverzací a informacemi.
O obsah na setkáních se stará zmíněný programový výbor, který má v případě CSNOG celkem 12 členů a po každém setkání se třetina vymění. Jednou za tři roky se může výbor vyměnit, nikdo nemá garantované místo.
Na počátku byli první členové nominováni pořádajícími organizacemi, v budoucnu by měli být voleni. Zatím ale není jasné, jak bude probíhat volba, kdo bude volit a podobně. Také nemáme vyřešené okrajové případy jako nedostatek dobrovolníků nebo doplnění rezignujících členů a podobně.
ČLÁNKY DO MAILU