Názory k článku Smyčka na ethernetu je špatná, bez přídavných ochran shodí síť

Co se přesně děje, když zblbne USB síťovka? Nepřímo jsem se s tím setkal 2x a vždy to jevilo známky smyčky, tak jsem dotyčného po telefonu nevedl, co má kde rozpojit a docela rychle došel k portu, který to dělal.

V jednom případě značková HP dokovačka, ve druhém no name USB síťovka za 3 stovky. Někdo vyškubl USB z PC a dock/síťovka zůstala na ethernetovém kabelu. Ta HP dokovačka měla pravděpodobně napájení, ale nevím. Neviděl jsem ji. Ta USB síťovka ovšem bere napájení z USB, o které přišla.

Co jsem o tom ze zvědavosti zkoušel něco najít, tak snad údajně síťové zařízení kvůli detekci protistrany přivádí na kabel co 15 ms nějaké napětí a ta osiřelá síťovka to dokáže využít, funguje v nějakém mezistavu a do sítě něco vypouští, což má podobný důsledek jako ta smyčka.

Co se tam přesně děje, co proti tomu funguje?

Tohle nejspíš bude způsobeno řízením toku na ethernetu. Některé USB síťovky, když nejsou připojeny k hostiteli (ale mají napájení), začnou vysílat rámce PAUSE, aby daly přepínači vědět, že nemohou nic přijímat. Bohužel některé přepínače tenhle rámec neznají a místo aby ho interpretovaly, přepošlou ho na všechny ostatní porty. Tím dostanou všechna ostatní zařízení zákaz vysílat a provoz na síti se zastaví.

Trochu mi v tom nesedí ta poznámka o USB síťovce bez napájení, to se mi úplně nezdá. Nebylo to tak, že ta USB síťovka zůstala zapojená v počítači, a počítač se uspal?

Ne. Dotyčný vyškubl síťovku z USB, která byla na kabelu a šel s notebookem pryč. Taky mě ta absence napájení zarazila.

To je ta věc, co to měla na svědomí:
https://www.tp-link.com/cz/home-networking/computer-accessory/ue330/

Asi něco takového, jako toto vlákno:
https://www.reddit.com/r/HomeNetworking/comments/qp6k57/unplugged_usbc_network_adapter_crashes_whole/

Myslim, ze jedina moznosti zjisti, co se vlastne deje je SPAN portu, kde je takove zarizeni pripojene + Wireshark. Co jsem mel moznost pozorovat, tak na portu, kde byala pripojena docking station hrde nesouci jmeno jednoho naseho internetoveho prodejce, byla k videni hromada vygenerovanych MAC adres. Jako by byla zapnuta funkce MAC spoofing. Co se ochrany tyce, tak doporucuji Port Security a Storm Controll

Ahoj, když jsem ještě dělal síťaře, tak se problém s dokovačkou řešil a nějak se vyřešil. Tuším, že to mělo něco dočinění s Wake-on-Lan … nebo něčím podobným. Už si nepamatuji, jestli se to řešilo na straně stanic - což pravděpodobně ne, spíš jsme pak provedli nějakou konfiguraci portů na access switchích. Totiž na straně access switchů se to chovalo tak, že uspaný nebo nějak neaktivní notebook v dokyně způsoboval UP/DOWNy na portech, což nám následně generovalo incidenty - už si na to vzpomínám. Na na starém Cisco switchy to byl pak tuším tento příkaz: spanning-tree portfast, na Nexusech to už bylo: spanning-tree port type edge.

To urce ne. Prikaz Spanning-tree portfast zpusobi, ze port na prepinace se hned prepne z blockiong do forwarding state. Pouziva se jen na portech ktere vedou k hostum. Jedinou vydohodu je, ze port na switchi nemusi projit rezimem listening a learning, takze neodazazi k situacim, kdy napr. dojde ke startu operacniho systemu, ale port na switchi jeste neni ve stavu forwarding (tzn sit stale nedostupna)...

U "modernejsich" verzi STP protokolu (802.1w, 802.1s) toho dela ponekud vic, ostatne proto to oznaceni "edge". Aneb opravdu nechcete mit topology change napric infrastrukturou s kazdym rebootem kocoveho desktopu...

Jo, kde jsou ty časy, kdy bez toho v Novell Netware sítích nenaskočil login dialog, pokud byl na switchi zapnut STP.

Pricetna zarizeni umi - mimo jine - treba take storm limity... a to mimo jine dokaze afektovane porty treba i automaticky shutdownovat (nebo minimalne dany provoz vyrazne omezit), pokud se na portu objevi vic tohoto typu provozu, nez je zdravo... a je to vec, ktera tu v tech zarizenich byla i pred dvaceti+ roky, to neni zadna "horka" novinka. Jenom na to spousta "spravcu" proste kasle a podobne veci na pristupovych portech proste jen nenastavuje - neztraci tim svuj cas...

dokaze afektovane porty treba i automaticky shutdownovat

afektované? :-)

ja v tom slovniku vidim i neprirozene se chovajici takze proc ne? :)

Protože v tomhle kontextu znamená anglické affected česky dotčený nebo zasažený, ale ne nepřirozeně se chovající.

A taky protože uměle vytvářené anglicismy, které znějí stejně jako existující česká slova s jiným významem, jsou ještě víc špatná než ostatní anglicismy :-). A původní záměr používat takové výrazy, aby text vypadal víc odborně a vzdělaně, vede jen k ukázce neschopnosti psát srozumitelně česky ;-).

Podobne reci vedou spise ti, co se snazi odvadet diskuzi od skutecne podstaty problemu. A tou je fakt, ze sitove prvky castou nejsou nastaveny tak, jak by meli byt (coz bude i pripad toho parlamentu, ktery tento clanek motivoval). A treba prave proto, ze "zodpovedne" osoby misto toho plkaji na internetu o tom, jake slovicka se maji pouzivat :D

Mě zrovna afektované v tomto kontextu přijde vhodné, i když to není technicky přesné.
Víc bije do očí slovo "shutdownovat".

Proč by to mělo být vhodné? České přídavné jméno afektovaný znamená něco úplně jiného než anglické affected a v daném kontextu nedává vůbec smysl. Je to podobné jako patetický vs. pathetic (ale to už také poslední dobou vídám).

Nebo moje oblíbené charakter (myšleno postava, například ve filmu nebo ve hře).

Afektovaný znamená něco úplně jiného, ale není port rozesílající nesmysly na všechny strany tak trochu afektovaný? :-)

Já bych si byl býval myslel, že zkratování portů je běžná chyba, a tedy novější zařízení ji na L2 úrovni již řeší automaticky. Když jsme měli v síti hloupé switche (unmanaged), k problémům docházelo. Pak jsme přešli na prvky Aruba, a...k problémům docházelo znovu, protože funkce
loopback-detection enable
standardně nastavena není. Alespoň že u prvků typu D-Link DGS-1210 už je tato vlastnost ve výchozím nastavení.

Potiz techto "loopback detection" je v tom, ze casto jde o proprietarni reseni, takze v sitich mixujicich ruzne vyrobce nemusi (a nebude) fungovat spolehlive. A samozrejme, porad jde o nejaky magicky paket, ktere zarizeni vysila - a pokud jej prijme nekde, kde nema, prijde reakce - ale co kdyz takovy paket neco po ceste zahodi? ;-)

Podobný problém jsem potkal v souvislosti s mirroringem portu na přepínači. Do jedné sítě dodavatel v rámci nějakých úprav nebo rozšíření zapojil další switch. Nevím, kde ho vzal, nikdo to nekontroloval a prostě byl tam nastavený mirroring několika portu a do monitor portu byl náhodou zapojen další switch. Byla tam tedy smycka Spanning tree byl nastaveny a mel by ji rozpojit. S tim mirroringem se to chovalo divně, broadcast storm během chvíle.

Ty smyčky mohou být vůbec záludnější, jeden náš zákazník třeba vyrobil smyčku tak, že na dvou počítačích ve stejném ethernetovém segmentu dal do bridge vlan interface a ethernet pod ním. A pak samozřejmě nahlásil jako bug, když se síťový stack choval přesně tak, jak měl nakonfigurováno.

Sorry... ale potencial ke vzniku tohohle pruseru bych jaksi v port mirroru predpokladal i pri nastavenem STP.
Je to o tom k cemu se asi port mirroring pouziva a kde nemusi byt STP interpretovano. A nemelo by aby se neovlivnila analyzovana data.

Já mám zkušenost se vznikem smyčky skrz wifinu: na dlouhé chodbě menší firmy byly kanceláře. Na jednom konci bylo AP pro wi-fi - no a na druhém konci to chtěli taky, takže tam dali AP-čko a nastavili podle toho prvního: stejné SSID, stejné heslo a stejný kanál.
Jakmile se ty dně wifiny našly, bylo uzavřeno. ;oD

V tomhle příběhu nějaká podstatná informace chybí. Wi-Fi AP se nechovají jako klienti, takže umístěním dvou AP vedle sebe smyčka nevznikne.

Může k tomu ale dojít, pokud je AP v režimu WDS Bridge, tedy jako bezdrátový repeater. Pak si to dokážu představit.

Ty dvě wifiny se takřka jistě rušily, ale klient se stejně může registrovat jen do jedné z nich, krátké spojení typu loopback tak nevznikne.

Soudím, že mohou - přesně, jak píše p. Caletka.
(A máte pravdu, že při jen trochu příčetném nastavení to vzniknout nemůže.)

Podle mých dávných zkušeností byl Spanning Tree Protocol proti smyčkám zcela k ničemu. Aby SPT fungoval, musí mezi přepínači proběhnout docela dost komunikace: musí si zvolit kořen stromu a pak ten strom (tj. kostru grafu). Jenže probíhající broadcast storm tomu spolehlivě brání. Co proti smyčkám pomáhalo, byl limit na počet rámců, myslím, že se to jmenovalo Storm control.

STP samozrejme proti sluckam funguje. V case ked sa vytvara topologia, porty neforwarduju packety a teda broadcast strorm nemoze prebiehat.

STP proti smyckam funguje - ale jen do chvile, nez vam neco "v ceste" zafiltruje BPDU - a i to zafiltrovani je samozrejme jedna z moznych funkci nastavitelna na portu. A samozrejme i s tim se musi pocitat...

Ehm.. root bridge election s tim nema nic spolecneho. Behem tohoto procesu se procesuji jen BPDU message a port neni ve forwarding state. Problem je spise problem je v tom, ze na spouste prepinacu je spanning-tree loopguard v defaultu vypnuty a musi se zapnout pro box globalne nebo jen per port. Spousta administratoru neresi ani bpduguard na trunky vuci virtual switchi. Jinak storm controll urcite ano. Ergo. Spanning-tree urcite neni proti loopum k nicemu. Jen ho lide neumi nastavit

STP bývá ve větších sítích často vypnutý.
Nevím proč, nikdy jsem se s problémem s STP ve mnou spravovaných sítích nesetkal, a už kdysi se říkalo, že každé trochu chytřejší zařízení STP umí, takže smyčky na ethernetu už jsou minulostí.
Ano, umí, ale často je to vypnuté.
Naposledy jsem zapnutým STP způsobil incident v nejmenovaném pražském housingu, kde ho vyžadovali vypnutý, a já to nevěděl. Zhruba hodinu trvalo, než ten switch rozhýbali. Ale co to přesně způsobilo, to nevím.
Přesně jak autor píše, je dobré kvůli tomu vést management zvlášť, nebo mít ten scénář alespoň na paměti, když síť navrhuji. Ale držel bych se zuby nehty toho, že STP by prostě mělo být zapnuté. Nikdy nevíte, kdy se poslanec rozhodne zapojit kabel.
A to je vůbec ostuda, co se tam stalo. Jedna věc je, že uživatel může způsobit takový problém; ale druhá věc je, že první, čím se to zdůvodnilo, byl ruský hackerský útok. A pak má člověk těm médiím věřit.

9. 11. 2022, 10:29 editováno autorem komentáře

Drzel bych se toho mit dobre nakonfigurovane. Tj. mit treba oddelene STP stromy.

Bohužiaľ veľa ľudí nevie (s)pracovať s informáciami a zjednodušuje na čo poukazuje váš komentár o médiach (a nie nebolo to prvé, čím sa to zdôvodnilo).
PS: Druhá vec je, ako presne to prevzali české média. To som nesledoval.

9. 11. 2022, 11:58 editováno autorem komentáře

SPT paket je technicky paket, s nahozenym I/G bitem v cilove adrese. Takze vlastne multicast. Maler nastane pokud jsou v siti switche, ktrere ho "neprectou a poslou dal" a/nebo zaroven sitche, nastavene zastavit vsechen broadcast/multicast . Dokud to nenarazi na switch, ktery se se podle pakety zaridi a reaguje pokusem znovu sestavit strom, nebo jen odpojenim linky (protoze port je nastaveny jako access, ne trunk) tak je na nestesti zadelano. Sit se rozpojuje tam kde nema.

Já to s tím ruským hackerským útokem chápu. Upřímně, prostým naivním rozumem byste asi zvládl odhadnout, že zrovna v parlamentu pravděpodobnější, než zprasená síť prostou smyčkou je, že rusáci dělají bordel. Problémem není ta informace jako spíš její víceméně neúmyslná (diletantismus) desinterpretace.

Nenaivní rozum si ovšem dovede představit IT bordel ve státních institucích takže to už tak jasné pak není.

Siti ve verejnem sektoru, kde "vrcholem" nastaveni bylo prirazeni portu do VLAN (a jinak nic) jsem ja za svuj zivot uz par potkal... Holt externi dodavatele, kterym zakaznik (statni instituce) duveruji a sami se v tom moc nevyznaji. A jako bonus pristup dodavatelu "levne koupit, draze prodat" (prece tam neutopi praci cloveka, co to udela poradne).

Na jednom nejmenovanem urade se dalo z portu tiskarny na chodbe dostat do administrativniho rozhrani pole od IBM, kde bylo trivialni heslo. Na spoustu uradu staci do tiskarny vrazit "Raspberry" se dvema porty v bridge, a mate volne pole pusobnosti.
Samozrejme ze urad plati miliony za SIEM a spoustu dalsich blackboxu, kterym nikdo nerozumi. A papirove je taky vse OK :-)

Papirove je vse vporadku, stat nezajima ze nekde po uradech jim v siti tahaj data cinani nebo rusaci. Az nastane pruser, odvola se nejaky ten namestek, pripadne se to ututla. Pred par lety jsme reportovali nejake otevrene tiskarny na vnitru, dalo se pres ne dostat do interni site. Nikoho to tehdy nezajimalo, papir od externi firmy meli.

V te dobe probihal rusky utok na polsky sejm. Takze kdyz padl slovensky parlament byla analogie na miste. Navic slovensky NBU jiz delsi dobu varuje ze to pride.

9. 11. 2022, 16:02 editováno autorem komentáře

Slovensky NBU je pripad pro dr. Chocholouska. Jednou jsme jim nahlasili megapruser a jejich reakce byla takova ze ten pruser byl dalsich 5 let nevyresen.

Nevim jak je to ted, ale drive se pouzivalo vice verzi a pod-verzi STP. A ruzne generace Cisco umely ruzne veci. Meli jsme praci kolegu ktery mel v hlave obrovskou matici toho co ktere zarizeni umi, co s cim jde propojit a na jakou verzi IOS se musi to ktere zarizeni ugradovat. Takhle to dopada v situaci kdy mate v siti ruzne stara zarizeni, ktera nechavate dozit za kazdou cenu.

Tak cely pes je zakopany v tom, jestli pouzivate standardizovane reseni (tzn. to, co popisuji IEEE normy) a nebo proprietarni reseni konkretniho vendora. Ano, treba s proprietarnim PVST od Cisca mela samozrejme spousta ostatnich zarizeni "problem" se domluvit. Ale to je holt problem vendor-locku obecne...

PVST jakožto proprietární protolol bych tak příkře neposuzoval. Šlo o klasický osud průkopníka, který předběhl ostatní, ale vývoj pak šel jinudy (Jára Cimrman by mohl vyprávět). Stejně to dopadlo v případě ISL vs. 802.1q, naopak protokol GRE se ujal (pomocí něj jsme kdysi přes IP honili IPX.
Současná verse PVST+ jednak umí spolupracovat s MST, jednak je nativně podporovaná významnými konkurenčními výrobci.

Pointa je, ze jde jde o nestandardni reseni, ktere neimplementuji zdaleka vsichni. Cilova multicastova MAC "plusovych" BPDU je jina, nez cilova multicastova MAC klasickeho STP. A pokud to plusove BPDU neni korektne zpracovano, muzou se dit skarede a necekane veci. A to, ze jini vyrobci ekvivalent PVST+ implementuji (obcas jako bonus jinak pojmenovany) jeste neznamena, ze to je by-default take zaply... no a kdyz neni, plusove BPDU tam skrz proste prolitne jako jakykoliv genericky L2 multicast. A to opravdu chcete :-)

Copak o to, takova vec se muze stat a jsou i zajimavejsi scenare, jak sit "zabit". Napriklad XON/XOFF pakety poslane do site, jejiz switche je nepodporuji. Technicky jde o SPT multicast paket (https://en.wikipedia.org/wiki/Ethernet_flow_control)
Takze pri prvnim naznaku zahlceni se siti zacnou sirit jako multicast XOFF pakety, ktere vedou na zahlceni, ktere posila dalsi XOFF pakety.

Stat se muze spousta veci. Ale na tom pribehu ze Slovenska, ktery byl nepriznanym podnetem clanku, je zarazejici neco jineho. Diagnostika takoveho problemu by mela trvat minuty, maximalne hodiny, ale ne nekolik dni.

Ale oni příčinu znali hned, Putin :-)
Předpokládám, že diagnostika byla rychlejší, ale než vypustí do světa další dezinformaci o tom, jak to bylo, chtěli to nejdříve prošetřit. A to se jim povedlo až do toho detailu, že se ví, který poslanec, a je známé i jeho vyjádření k tomu.
Což samozřejmě nevylučuje, že za tím ten Putin skutečně stojí.

Tady v tomhle případě bych se fakt koukal na nějakou politickou příčinu, i když bych neřekl, že to bude sahat až k Putinovi. Ale udělat DOS na Sněmovnu obecně není úplně k zahození, a zrovna tady to asi v nějakém kritickém okamžiku bylo.

Politickou príčinou boli komunálne voľby, v ktorých kandidovali aj niektorí poslanci parlamentu. Niekoľkodňová pauza sa im hodila.

Tak nebudeme si tady namlouvat ze putin je holubice miru. Snad az tak daleko politicka korektnost tady neni. Ze ne?

Ten článek není nepřiznaný. Vymysleli jsme ho samozřejmě jako reakci na ten slovenský incident. V textu je na něj přímý odkaz.

Ona ta analýza slovenského případu podle všeho proběhla poměrně rychle. Jenže původně to bylo chybně vyhodnoceno jako kybernetický útok a celý úřad byl ochromen. Proto se poslanci rozhodli na týden přerušit schůzi.

Dlouhý výpadek tedy nebyl technický, ale administrativní. Někdo pak někde psal, že zrušit přerušení schůze je tak komplikované, že bylo lepší nechat pauzu proběhnout podle původního plánu.

Jm to netrvalo zase tak dlouho, ale schůzi prostě odložili o týden a navíc se to politicky zrovna celkem hodilo.

Nevíte, jestli existuje nějaký tester odolnosti sítě, který by automaticky postupně procházel různé podobné scénáře, případně rovnou vyhodnocoval odolnost sítě? Představuji si to jako zařízení s několika ethernetovými porty, které se dle pokynů připojí na různá místa sítě. Takový test by probíhal před uvedením nové sítě do provozu a při různých bezpečnostních auditech. V době testu by síť nejspíš byla oddělena od Internetu, buďto úplně nebo nějakým filtrem paketů.

Omlouvám se k brebentění trochu mimo téma, ale fascinuje mě to České pojmenování přepínač (ačkoliv je zažité a normálně jej akceptuji). Nebylo tím v angličtině původně míněno "výhybka" (také switch)? To by dávalo trochu lepší představu než přepínač, posílání provozu nějakým směrem. :-) Jak si hezky čte adresy rámců a posílá je jako na seřaďovacím nádraží svou cestou.

Přidám postup jak se problém fakticky řeší:
Diagnostika: Nechodí síť, ale switche intenzivně blikají, dost možná i poměrně pravidelně.
Akce: Odpojím polovinu kabelů. Problém vyřešen ? => V té polovině je ten problém. Není vyřešen? Je to v té druhé polovině. S defektní polovinou opakuju proces - tj. zapojím ji zpět a z ní vemu zase polovinu (polovinu polovinu, už jsem teda na čtvrtině). Atd.
Chyták: pokud se problém vyskytuje pro jednu i druhou polovinu, pak je smyček/škůdců víc, a bude jistější odpojit vše a postupně zapojovat po jedno. Taky pro <=8 portů to bude rychlejší.

V tomto sebevědomém modelu řešení problému je bohužel několik "zapíchnutých vidlí".

Namátkou:

* Vada na HW switche, která se může projevit při specifikcých podmínkách.
* Problém v aktuálním stavu SW switche.
* Že těch switchů tam můžete mít desítky i stovky.
* Že to může být úplně jiný problém, něž zde popisovaná smyčka.
* ... zlí skřítkové maskující se za vysokoenergetickou částici interagujícící, jak na potvoru, zrovna v RAM switche ...

Já jsem zažil takovou zvláštní asi-smyčku. Kolega si myslel že když se krimpuje, tak se mají odizolovat konce jednotlivých vodičů. A když to nakrimpoval, tak se pár náhodných vodičů šluslo. A připojení zařízení tímto kabelem způsobilo podivné chování odpovídající smyčce. Takže předpokládám že se nějak spojily nějaké vodiče z Rx a Tx páru ale přitom nějak proběhl handshake že se to nahodilo a pak se to spustilo.

Neumím si představit, že bych nakrimpoval kabel a neotestoval jej pořádným testerem.

Pche - ja uz videl i nakrimplovanej kabel, kde se tvurce nezabyval ani spravnym zapojenim paru. Link se tam rozsvitil... a to take bylo cele "testovani" :D

Pokud si dobře vzpomínám, při odizolování vnější izolace kabelu došlo k nepatrnému proříznutí izolace drátků. Vše fungovalo až do chvíle, než se s kabelem nešikovně pohnulo a dráty s naříznutou izolací se propojily...

Ale k takové situaci může dojít max. třikrát za 100 let :-)

Pokud je síť rozdělená na podsítě (routovaná), pak je problém smyčky izolován jen do té konkrétní podsítě. Pokud router umí zahlcení na portech detekovat a nenechat se přetížit, pak se může správce o problému obratem dozvědět a reagovat. Mikrotik to takhle umí.

...ono to umi i dvacet let stara Cisca :-) Akorat to obcas nekdo "zapomene" nastavit...

Trill nebrat - jednak ustupující podpora na zařízeních předních výrobců a obecně špatná konvergence při přidávání nových zařízení se zvětšující se sítí. Když pak máte v síti s Trill storage, tak to může nadělat pěknou paseku.