Ondrej Žilinec – IT Blog

Uz dlhsie som rozmyslal ci napisat dany clanok a az teraz som sa rozhodol, ze ano. A ze dokonca bude po slovensky 🙂 aj ked bez diakritiky. Pokusim sa vam popisat tri situacie ked som bol povolany do boja proti neposlusnej sieti. A taktiez ako som ich poriesil pomocou porozumeniu ARP protokolu (Address Resolution Protocol).

1. pripad

Bol to moj prvy pripad v terajsom zamestnani. Zakaznik mal siet o rozsahu 192.168.0.0/24. Dosli mu IP adresy, tak sa rozhodol rozsirit IP rozsah zmenou sietovej masky na /23. Cize servery na serveroch a aktivnych prvkoch, o ktorych ITckari vedeli, prehodli sietovu masku na /23. Taktiez na DHCP pool-e zmenili sietovu masku na /23. A vtedy sa zacali problemy. Prejavovalo sa to nasledovne. Ked na klientskom PC dali pingat IP adresu servera, tak presli 2 pingy a 3 sa stratili, 2 pingy presli a 3 sa stratili,…atd. Bolo to zaujimave. Nastartoval som WireShark a napisal filter ARP. Vtedy som si vsimol nieco zaujimave na sietej komunikacii. Zacal som pingat server na lokalnej sieti. Predtym ako sa poslal ICM Request, tak sa poslal ARP Request. Dostal som ARP Reply, naco som nasledne poslal ICMP Request na MAC adresu ziskanu ARP Reply (MAC adresa servera). Po dvoch ICMP Requestoch dosla dalsia ARP Reply z uplne inej MAC adresy ako bola MAC adresa servera. A kedze Windows very kazdej MAC Reply (vsak ako by sme robili Man-In-the-Middle?), tak zacal moj komp posielat ICMP Request na novu MAC adresu. A ta, samozrejeme, neodpovedala. Takze preto par pingov preslo a par nepreslo.

Riesenie

Problem spocival v tom, ze lokalny ITckari nezmenili IP rozsahy na vsetkych zariadeniach. Zabudli na to, ze maju v sieti este nejake zabudnuty Cisco router a na tom nezmenili sietovu masku. A na Cisco zariadeniach je defaultne zapnute Proxy ARP. Kedze si zakaznik rozsiril IP rozsah, a klientsky DHCP pool sa presunul do noveho rozsahu, mimo 192.168.0.0/24, tak pre Cisco routery tieto IP adresy boli mimo ich rozsah, takze sa chovali presne ako sa od nich ocakava, ked je zapnute Proxy ARP. Cize podvrhuju svoju MAC adresu, pretoze sa “pokusia” dorucit paket pre IP adresy mimo ich lokalny rozsah. Viac o Proxy ARP.

2. pripad

Inokedy som bol prizvany ku dalsiemu problemu. Popis od zakaznika znel tak, ze blbne im IP telefonia a Slovak Telecom, od koho mali IP Telco ustrednu, nema ziaden problem. Ze maju vsetko zelene 🙂 Tak som vyrazil na hodinovu cestu. Pri dojdeni na miesto som sa pozeral na zaujimavy stav. Stal som v kancelarii a telefony blikali ako v zlom filme o hackeroch 🙂 Zelene telefony boli v poriadku a svietiace na cerveno boli v zlom stave. Ich stavy sa nahodne menili a blikalo to cele v kancelarii ako ked sa strasny hacker infiltruje do siete FBI 🙂 Tu som bol za guru ako nikdy predtym, pretoze som zapol notebook, nastartoval WireShark, nastavil IP adresu z rozsahu pre IP telefoniu a hned po cca 20 paketoch ARP protokolu som videl nasledovne:

Riesenie

Takze bolo potrebne len vystopovat danu MAC adresu, ktora mala nastavenu rovnaku IP adresu ako IP telco ustredna a vsetko bolo v poriadku. Na koniec sme zistili, ze dana MAC adresa patrila jednemu ITckarovi 😀 Takze sumar dna: 1 hodina cesta ku zakaznikovi, 10 sekund najdenie dovodu vypadkov, 2 minuty najdenie pachatela, 30 minut vymyslanie pribehu pre management a 1 hodina cesta domov 🙂

3. pripad

Bol to rovnaky zakaznik ako v pripade cislo 2. Mali problem s citackami ciarovych kodov v sklade. Pri telefonate som zistil, ze citacky ciarovych kodov maju v rovnakej VLANe ako PCcka a telefoniu. Problem bol, ze vypadavalo z citaciek pripojenie na SAP server v serverovej VLANe. Ked sme dali pingat dany server z klientskeho PC, tak vypadavali pingy na server a dokonca aj na vlastnu default gateway. Router nemal ziadne vytazenie (<1%). Co bolo divne. Takze sme nastartovali WireShark. A pri zadani filtra ARP som spozoroval, ze pomedzi ARP spravy, ktore tam mali byt som videl ARP spravy tykajuce sa IP rozsahu VLANy v ktorej su tlaciarne a tlacovy server. Co bolo celkom divne. Tak som si nastavil druhu IP adresu z rozsahu tlacovej VLANy a zistil som, ze ked pingnem tlacovy server, tak idem na priamo a nie cez router. Takze problem bol detekovany hned, mali domiesane VLANy.

Riesenie

Ked som si nastavil druhu IP adresu z rozsahu tlacovej VLANy, tak som mohol na switchoch dohladat kde sa dane VLANy domiesali/zoskratovali. 🙂 Takze siel som switch za switchom az som dosiel na nejaky lacny TP Link na ktorom bol vypnuty Spanning Tree Protocol. Tak som ho skonfiguroval a zrazu sa siet prebrala a zacala robit co mala. Pri dalsej analyze som zistil, ze u zakaznika mala dojst nejake navsteva a kedze upratovali nezapojene LAN kable, tak iniciativni ludia ich pozapajali kde prislo. Tym sa zmiezali VLANy a taktiez sa spravili slucky na switchoch, ktore nemali STP zapnuty a tak vznikali slucky/broadcast stormy a dalsie prejavy “zoskratovaneho prepinaca”.

Takze tolko som sa chcel podelit s mojimi skusenostami ako sa stat sietovym guru v ociach zakaznika. Dokonca niektore problemy poriesit do 5 minut 🙂 Samozrejme sa musim podakovat mojemu dobremu ucitelovi sieti, ktory mi dal velmi dobre zaklady – Peter Palúch. Dakujem Peto!