A következő címkéjű bejegyzések mutatása: management. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: management. Összes bejegyzés megjelenítése

2013-05-13

Tikpásztor

A Tikpásztor egy nem túl szofisztikált shell és expect szkript, a MikroTik ketyerékből álló tyúkudvarok rendben tartásának lehetséges eszköze. Azonnal használatba lehet venni, szereti az öreg, az SSH kulcsokról mit sem tudó (RouterOS 2.9.13 előtti) tikokat, mivel nem igényel előzetes SSH kulcs terítést, három dolgot azonban tudnia minden egyes eszközről: a management IP címet, az admin user nevét, illetve jelszavát. Ezen kívül természetesen az SSH szolgáltatásnak futnia kell a Tikpásztor által kezelt eszközökön. A szkript nem csodaszer, csak annyira hasznos, amennyire értünk a RouterOS CLI-jéhez, összesen két dologra képes ugyanis: RouterOS parancsot futtatni sok eszközön, illetve komplett beállításmentést készíteni (licenc, export, backup) sok eszközről.

 

Függőségek

Néhány elterjedt szoftvernek telepítve kell lennie, hogy a Tikpásztor működőképes legyen, a legfontosabb ezek közül az "expect" nevű, Tcl alapú, interaktív szkriptelést támogató csomag, ami nem része az alapértelmezett telepítésnek a legtöbb Linuxon. Szükség van továbbá olyan standard eszközökre mint a "bash", az "ssh" és az "sftp".

 

Csoportok

Az első, amit tudnunk kell a Tikpásztorról, hogy csoportokban kezeli az eszközeinket. Azt, hogy mi szerint szervezzük a csoportokat, a szkript szempontjából nem fontos. Ha nincsenek különböző jellegű feladatokat ellátó eszközeink, akkor elegendő egyetlen csoportot létrehoznunk, de készíthetünk csoportot az eszközök fizikai elhelyezkedése alapján (pl. egy csoportba kerülnek az azonos telephelyen lévő Mikrotikek) vagy az eszközök funkciója alapján (pl. egy csoportba kerülnek az AP-ként funkcionáló eszközök, egy másikba pedig a routeolást végző eszközök). A csoport egy szöveges, pontosvesszővel tagolt fájl, ami nem tartalmazhat üres sorokat és kommentárokat, csupán IP-t, usernevet és jelszót minden egyes sorban:

192.168.0.1;admin;bejohetsz
192.168.0.2;
admin;password
192.168.0.3;admin;admin


A csoport neve az lesz, amilyen néven elmentjük a fájlt, azzal az apró megkötéssel, hogy tartalmaznia kell a "csoport" prefixet, tehát "csoport.AP", "csoport.szamvitel", stb.

 

Felhasználónevek

Előre különösnek tűnik, de a felhasználónevekhez lehet hozzácsapni a RouterOS SSH login alkalmával, hogy miképp kezelje a konzolt a RouterOS, legyenek-e színek, hány sor, hány oszlop, detektáljon-e és társaik. Ha tudjuk a tikokról, hogy nem túl régiek, 4-es, 5-ös RouterOS-t futtatnak, akkor bátran véssük be a felhasználónév mögé, a "+ct" karaktersort a csoportfájlban, pl:

192.168.0.1;admin+ct;bejohetsz

A felhasználónév ettől még ugyanaz marad, csupán a login során átpasszolunk két olyan paramétert a RouterOS-nek, amelyek segítik az expect szkriptek és a RouterOS közötti együttműködést. Ez a funkció a 3-as RouterOS szériában mutatkozott be, 2-es verziókon viszont semmiképp ne használjuk, mert ott a felhasználónév részeként fogja kezelni a RouterOS a plusz karaktereket.

 

Használat

A csoportfájlok feltöltése után a Tikpásztor azonnal használható. A "tikpasztor.sh" legyen ugyanabban a könyvtárban, ahol a csoportfájlok, a /tmp könyvtáron pedig legyen írási jogunk, és már mehet is. A szkriptnek két  működési módja van, az egyikben az első paraméterként megadott csoport minden egyes eszközén a második paraméterben megadott RouterOS parancsot fogja lefuttatni:

root@tesztgep:~/mikrotik# ./tikpasztor.sh teszt "/system license print"

 * "teszt" csoport (3 eszköz)
 * "/system license print" RouterOS parancs

Folytatod (i/n)? i

###### 192.168.0.1 START #########################################################
spawn ssh -l admin 192.168.0.1
admin@192.168.0.1's password:

  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 2.9.50 (c) 1999-2007       http://www.mikrotik.com/

Terminal xterm detected, using multiline input mode
[admin@MikroTik1] > /system license print
    software-id: "K8FN-PTT"
  upgradable-to: v4.x
         nlevel: 4
       features:
[admin@MikroTik1] > /quit
Connection to 192.168.0.1 closed.
########################################################## 192.168.0.1 STOP ######
Nyomj meg egy gombot a folytatáshoz...


###### 192.168.0.2 START #########################################################
spawn ssh -l admin+ct 192.168.0.2
admin@192.168.0.2's password:

  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 5.25 (c) 1999-2013       http://www.mikrotik.com/

[admin@MikroTik2] > /system license print
    software-id: H0N3-48VJ
  upgradable-to: v7.x
         nlevel: 4
       features:
[admin@MikroTik2] > /quit
interrupted
Connection to 192.168.0.2 closed.
########################################################## 192.168.0.2 STOP ######
Nyomj meg egy gombot a folytatáshoz...


###### 192.168.0.3 START #########################################################
spawn ssh -l admin+ct 192.168.0.3
admin+ct@192.168.0.3's password:

  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 5.25 (c) 1999-2013       http://www.mikrotik.com/

[admin@MikroTik3] > /system license print
    software-id: RGED-3LWV
  upgradable-to: v6.x
         nlevel: 4
       features:
[admin@MikroTik3] > /quit
interrupted
Connection to 192.168.0.3 closed.
########################################################## 192.168.0.3 STOP ######
Nyomj meg egy gombot a folytatáshoz...


root@tesztgep:~/mikrotik# 

Mielőtt egyszerre levágnánk az összes MikroTik eszközünket, javasolt átolvasni, hogy melyik csoportra, milyen parancsot futtatunk, ezt annyiban segíti a szkript, hogy futás előtt rákérdez, hogy valóban folytatni szeretnénk-e. Pozitív válasz esetén a csoportban lévő minden egyes eszközre, egymás után, for ciklusban ráereszti azt az expect szkriptet, ami bejelentkezik SSH-n, majd lefuttatja a megadott parancsot.

A másik működési mód mentést készít az eszközről. A mentés három dolog mentését jelenti, a RouterOS szoftverlicenc-klucsát, egy "/export" paranccsal készített szöveges konfigurációs fájlt, illetve egy "/system backup save" paranccsal készített bináris konfig mentést. Ez utóbbit csak azon az eszközön lehet visszaállítani ahol készült, míg az "/export" kimenete némi mókolást követően más MikroTiken is behúzható. A mentés során a MikroTikek flash memóriáján a három mentett dolognak megfelelő három fájl jön létre, egy ".key" kiterjesztésű fájl a licenckulccsal, egy ".rsc" fájl az exporttal, és egy ".backup" kiterjesztésű bináris fájl. A fájlok lementése SSH/SFTP protokollon keresztül történik, majd a másolás végeztével törlődnek is az eszközről. A mentés menete:

root@tesztgep:~/mikrotik# ./tikpasztor.sh teszt BACKUP
###### 192.168.0.1 START #########################################################
spawn ssh -l admin 192.168.0.1
admin@192.168.0.1's password: 

  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 2.9.50 (c) 1999-2007       http://www.mikrotik.com/

Terminal xterm detected, using multiline input mode
[admin@MikroTik1] > /system license output

[admin@MikroTik1] > /system backup save name=2013-05-13
Saving system configuration
Configuration backup saved
[admin@MikroTik1] > /export file=2013-05-13
[admin@MikroTik1] > /quit
Connection to 192.168.0.1 closed.

FÁJLOK MENTÉSE:
spawn sftp admin@192.168.0.1
admin@192.168.0.1's password: 
Connected to 192.168.0.1.
sftp> get ????-???*.key 2013-05-13_192.168.0.1.key
Fetching /K8FN-PTT.key to 2013-05-13_192.168.0.1.key
/K8FN-PTT.key                                                100%  203     0.2KB/s   00:00    
sftp> get 2013-05-13.backup 2013-05-13_192.168.0.1.backup
Fetching /2013-05-13.backup to 2013-05-13_192.168.0.1.backup
/2013-05-13.backup                                           100%   10KB  10.5KB/s   00:00    
sftp> get 2013-05-13.rsc    2013-05-13_192.168.0.1.rsc
Fetching /2013-05-13.rsc to 2013-05-13_192.168.0.1.rsc
/2013-05-13.rsc                                              100%   13KB  12.8KB/s   00:00    
sftp> rm ????-???*.key
Removing /K8FN-PTT.key
sftp> rm 2013-05-13.backup
Removing /2013-05-13.backup
sftp> rm 2013-05-13.rsc
Removing /2013-05-13.rsc
sftp> exit
########################################################## 192.168.0.1 STOP ###### 

A mentés során az eszközökről lementett fájlok abba a könyvtárba kerülnek, ahol a "tikpasztor.sh" található. Backup módban a szkript folyamatosan fut, amint végzett egy eszközön, azonnal kezdi a következőt a csoportból, nem igényel interakciót.

Korlátok

A szkript nem kezeli le az SSH szerverek fingerprint változását (pl. formázással egybekötött RouterOS újratelepítés után), ezt nekünk kell megtennünk. Nincs külön összesítés vagy figyelemfelhívás a szkript lefutása közben/után ha egy MikroTik eszköz elérhetetlen, csupán az SSH kliens hibaüzenetét láthatjuk ilyenkor ("No route to host"). A szkript jelen formájában Debian / Ubuntu rendszereken fut, máshol nem is próbáltam. Stb. Stb. Stb.

2011-04-13

Network discovery módszerek

Mit tehetünk akkor, ha a feladatunk a világ másik végén lévő telephely LAN-jának minél alaposabb feltérképezése, és nincs semmiféle dokumentáció, amivel neki lehetne kezdeni a feladatnak? A helyi IT-s munkaerő nem ismeri igazán a hálózati eszközöket, ha kell, néhány alapvető dolgot -- hostname, IP, default gateway, admin jelszó -- be tud állítani webes felületen, de itt nagyjából kimerül a szakértelem.

Ilyenkor az lenne a legjobb, ha az ember csak ráeresztene valami okos szoftvert a megfelelő subnetre, az meg minden kis információmorzsát felcsipegetne, benézne ide is, oda is, HTTP-n, HTTPS-en, telneten, SSH-n, SNMP-n, amelyiken éppen lehet, végül kiadna egy részletes layer 2-es topológia ábrát hostnevekkel, IP-kkel, portszámokkal, az eszközök típusával, meg minden. A valóság ezzel szemben az, hogy nem véletlenül jut el a világnak erre a felére a probléma, az adott telephelyen a LAN eszközök nincsenek egységesen konfigurálva, különböző felhasználónevek és jelszavak vannak rajtuk beállítva (ha egyáltalán be van állítva valami), több különböző gyártótól valóak, vicces hurkokat kötöttek rájuk, némelyiknek még IP-je sincs.

A tipikusan ilyesmire használt gyártóspecifikus szoftverek, mint amilyen régi kedvencem, a 3Com Network Director (3ND) vagy újabban az azt felváltó HP Intelligent Management Center - IMC (bár szerintem ez kissé nehézkesre sikeredett) vagy a Nortel Enterprise Switch Manager vagy a Cisco Network Assistant nem igazán rúgnak labdába ilyen helyzetben, és soha nem lesz pontos az, amit kiköpnek magukból egy discovery után, de azért kiindulási alapként nem feltétlenül rossz az. Jelenleg épp a 3ND és a Cisco Network Assistant volt kéznél, gondoltam kipróbálom, mire mennek.

A menedzsment szoftverek alternatívájaként pedig ott a CLI-s buherálás, első körben nmap-pel kiszűrhetők az adott subnetben lévő gyanús hostok: a már említett protokollok portjai közül legalább egy nyitva van, szerencsésebb esetben több is (TCP-80, TCP-22, TCP-23, TCP-443, UDP-161), ezekről listát készít az ember, összeszedi a helyi IT-től előzetesen begyűjtött jelszavakat, majd jöhet a favágás: megpróbálni belépkedni mindenhova. A sikeres műveletekről táblázat készül, hogy egy adott IP adott portján mivel lehetett belépni. Ha a subnet elfogyott, akkor jó eséllyel a legtöbb távolról adminisztrálható eszközt sikerült azonosítani, így már csak a köztük lévő kapcsolatokat kell feltérképezni. A kapcsolatok feltérképezésében óriási segítség a CDP, NDP vagy egyéb hasonló protokoll által begyűjtött információ, ám nem mindig elegendő. A végső megoldás annak megállapítására, hogy mely portra van kötve egy-egy eszköz, a CAM tábla nézegetése. Ha sikerült bejutni már akár csak egyetlen eszköz parancssorába, onnantól a subnet összes hostjának MAC címét meg tudjuk keresni, egy ping után ott lesz az ARP táblánkban. Az ARP táblából kikeresett MAC címet utána már megleljük a CAM táblában is, és ha kell, switchről switchre, CAM tábláról CAM táblára végig lehet követni addig a portig, ahová az adott eszköz ténylegesen be van dugva. A CAM tábla további előnye, hogy megmutatja az összes csatolt switchet, hubot: ha azt látjuk a CAM táblában, hogy mondjuk az Fa0/8-as porton 13 MAC címet tanult be az eszközünk, akkor biztosak lehetünk benne, hogy a 8-as porton lóg még valamilyen hálózati eszköz, akár mutatja a CDP neighbor-ök közt a switchünk, akár nem (leszámítva az olyan extrém eseteket, mint például a virtual hostok, ahol virtuális a switch is). Végül a CLI-ben elérhető STP, LACP információk alapján pontosíthatjuk a topológiát, bejelölve a redundáns linkeket is. Hát, ez a kézi módszer, sziszifuszi meló, az biztos.

No, de hogy valami érdekes is jusson végére, az említett telephely feltérképezését megcsináltam 3ND-vel, Cisco Network Assistant-tal és kézzel is. Amint az utólag kiderült, a telephelyen az eszközök többsége Cisco volt, szóval a 3ND-nek eleve nem voltak nagy esélyei. Gondoltam érdemes az eredményeket számszerűsíteni is, ha a layer2-es topológia gráfjának minden megtalált éle és csúcsa egy-egy pontnak számít (az élek estén szükségesek a portok információi is a ponthoz, pl. egyik eszköz Gi1/0/2-ről megy a másik Gi0/1-re), akkor a következő eredmények születtek:

A kézi módszerrel 41 pontot sikerült elérni, 21 csúcs és 20 él került fel a topológia ábrájára (semmi redundancia), ez összesen 16 Cisco eszközt jelent, egy 3Com eszközt és négy közelebbről nem azonosítható, feltehetően unmanaged switchet. Természetesen messze ez a módszer igényli a legtöbb időt, a management szoftverek néhány vagy néhány tíz perces discovery idejéhez képest itt több óráról van szó.

A Cisco Network Assistant 20 pontot gyűjtött, a 16 Cisco eszközből 11-et megtalált, köztük egy olyat is, mely csak a CDP neighbor-ök közt volt megtalálható, egyébként nem volt IP cím beállítva rajta. A többi Cisco eszközre különféle okokból nem tudott bejelentkezni, az egyik például szolgáltatói eszköz volt az ötből, amelyhez nincs jelszavunk, a maradék négy Cisco eszközökhöz pedig csak Telnet hozzáférés volt, amit nem tudott használni, míg az egyéb (nem Cisco) eszközöket pedig hivatalból ignorálta. De legyünk méltányosak a programhoz, az általa megrajzolt topológia pontos volt, nem húzott be téves éleket a gráf csúcsai közé, minden teljesen egybevágott az eszközökből kinyerhető CDP információkkal, így sokat segített a kézi módszer felgyorsításában, ellenőrzésében.

A 3Com Network Director meglepetésre 21 pontot ért el, összesen 16 eszközt talált meg (ugye emlékszünk: a maradék 5 eszköznek nincs IP címe!), ám csak 5 kapcsolatot fedezett fel az eszközök közt helyesen, a többi eszköz fura felhőkön keresztül csatlakozott vagy csak úgy lógott a levegőben. Vitathatatlanul ez volt a legzajosabb módszer, számos nyomtató és egyéb SNMP-képes eszköz bukkant fel a topológiában, igaz ezeket nem volt nehéz kiszűrni.

A végső találati arányokat még sajnos nem tudom, ugyanis nemrég küldtem el a helyi IT-snek ellenőrzésre a kézi módszerrel összeállított topológiáról a Visio ábrát, amit ki fog egészíteni/javítani a tényleges állapotoknak megfelelően. Remélhetőleg a 41 pont nem lesz messze a valós értéktől...