[Megoldva] "Eltűnt eszköz" megtalálása Linux segedelmével

Hálózatok egyéb

Sziasztok!

Bocs' az idézőjelért: egy, a hálózatban eltűnt eszközről van szó:

Az IP kamerát reseteltem, a gyári IP-je 192.0.0.64. A jó fene tudja, miért nem DHCP-n csücsül gyárilag, de ha már így akarta a gyártó, ezt kell megenni. Nos, tudom, hogy ott csücsül most is, de nem szeretnék csak azért egy gépet, vagy egy routert 192.0.0/24 DHCP-re felkonfigolni, hogy el tudjam érni a 192.168.1.x gépről, mert egyszerűen nem tartom elegáns megoldásnak.
Onnan tudom, hogy a 192.0.0.64-es porton van, mert a kézikönyve ezt írja (lol), meg hát a szomszéd Windows 7-es gépén tudtam futtatni egy gyári szoftvert, ami képes valahogyan megtalálni az eszközt bármi is legyen az IP-je, ha közös routeren vannak. Ja, és ezzel a szoftverrel lehet manipulálni a kamera hálózati beállításait. (Ezzel néhány hete játszadoztam.)

A gondom az, hogy egyszerűen nem találom/látom Linux alól a kamerát. Sem nmap, sem arp-scan nem látja, bárhogyan is erőlködöm a kapcsolókkal.

Van tippetek, hogy elegánsan megtaláljam a hálózatban, esetleg akkor is, ha az IP címét nem tudom, de a MAC address-ét igen? (Az arp-scannel MAC-re sem találtam meg.)

Előre is köszönöm.

Megoldva.
Köszönöm mindenki segítségét.

  • 4824 megtekintés

( zrubi v | 2016. 11. 23., sze – 14:04 )

ha az 'arping' "látja", akkor tudsze vele kommunikálni - de csak úgy ha te is felveszel egy abból a tartományból való (alias) IP-t a saját gépeden.

--
zrubi.hu

Ez jutott nekem is az eszembe! Hogy meddig tart linuxon beállítani egy ip-t, átállítani vele kamera ip-jét, és mehet is vissza?! 2perc?

Topic nyitónak: az hogy van a "routereden", mondjuk inkább a hálózatodon egy dhcp szerver annak van egy tartománya, attól még bármilyen fix ip címet felvehetsz egy gépnek...max a addig nem lesz neted.
Illetve most tudjuk a címét vagy sem?! én előszeretettel használom az arpscan-t, átpattintod géped a kamera feltételezett(?!) tartományába és leszkenneled mi van a hálón.

Igazad van, Seaweed, nem egy nagy dolog úgy alakítani a hálózatot, hogy megtaláljam, ha tudom, hol keressem. Engem inkább az aggaszt, egyrészt hogy ha nem tudom, mi az IP, akkor hogyan találhatom meg, másrészt, hogy a lótúróba találja meg a gyári kliens szoftver? (Talán nem IP alapú protokoll?)

Én is gyanítottam, hogy STUN-on keresztül kommunikálhat, de off-line is "betalált" a gyári kliens.
Nagyon nem értem, mit csinál.
Mielőtt azt tenném, hogy a szomszéd Windows7-es gépe elé tennék egy szervert - amivel mindent route-olhatnék, és ezzel megint "jobb kézzel vakarom a bal fülemet" akciót hajtanék végre - valami olyasmi közelítő válaszra várok, kollégák, ami megértethetné velem, mit csinálhat a kamera, milyen protokollal teheti meg UTP kábeles hálózaton...?

Ugyan ezt a módszert használja a Mikrotik windowsos kezelő szoftvere is. Akkor is tudod vele adminisztrálni az eszközt, amikor egyáltalán nincs IP címe.

Egyébként csak arról van szó, hogy le kell menni a mélyebb rétegekbe és ott készíteni magadnak egy saját alkalmazás protokollt. Gyakorlatilag amíg szabványos ethernet frame-ket tologatsz MAc cím alapján, addig a buta switceken és hubokon keresztül működni fog a dolog (routerek és más komolyabb eszközök persze eldobálják, mivel nincsenek meg az IP által igényelt extra mezők benne, ezáltal érvénytelen csomag számukra). Többek között ilyen célra is lehet használni azokat a könyvtárakat, amik lehetővé teszik, hogy nyers ethernet csomagot készíts és kiküldj (pl libpcap).

Zavard össze a világot: mosolyogj hétfőn.

Az arpinget nem próbáltam. 

arping 192.0.0.64
ARPING 192.0.0.64 from 192.168.1.141 eth0
Unicast reply from 192.0.0.64 [XX:19:B7:YY:85:C1]  0.840ms
Unicast reply from 192.0.0.64 [XX:19:B7:YY:85:C1]  0.772ms
Unicast reply from 192.0.0.64 [XX:19:B7:YY:85:C1]  0.781ms
Unicast reply from 192.0.0.64 [XX:19:B7:YY:85:C1]  0.797ms
Unicast reply from 192.0.0.64 [XX:19:B7:YY:85:C1]  0.743ms
Unicast reply from 192.0.0.64 [XX:19:B7:YY:85:C1]  0.772ms
Unicast reply from 192.0.0.64 [XX:19:B7:YY:85:C1]  0.778ms
^CSent 7 probes (1 broadcast(s))
Received 7 response(s

Ok, ez eddig rendben, de tudtam az IP-t. Még mindig fáj, hogy nem tudok a 192.168.1/24-ből manipulálni a kamerát.

Attól, hogy a saját netmaszkodat variálod, a kameráé nem fog változni. A 255.0.0.0 netmaszk eredményeképp a te csomagod jó eséllyel direktben oda fog érni a kamerához - na de a kamera hova küldje a válaszát, ha nála megmaradt a 255.255.255.0 netmaszk, amibe a te címed már nem esik bele?

( Mcsiv v | 2016. 11. 23., sze – 17:58 )

tcpdump, mikor felveszi az ip-t rá fog visítani a hálózatra (nem kell azonos tartományban lennetek)

// Happy debugging, suckers
#define true (rand() > 10)

( pepo v | 2016. 11. 23., sze – 17:58 )

Egy HUP-felhasznlóval telefonon értekeztem közben: Ő erősen abban gondolkozik, hogy nem IP alapú a kamera kommunikációja a gyári szoftver felé. Sosem csalódtam a megérzéseiben, és most talán erre terelném a szót: Ha nem standard IP a kommunikáció, akkor hogyan lehetne lekövetni azt? Egyáltalán IP-alapú gépek hálózatából a nem IP alapú kommunikáció hogyan lehetséges fizikailag?

Rakj fel egy wiresharkot a szomszéd gépére és nézd meg mit csinál az eredeti kliens. Az OSI modellben egyik rétegben sincs varázslat nevű doboz, tehát valószínűleg simán broadcastol valamit, ahogy felettem is írták.

Egyébként vannak manapság ilyen csoda "cloud based" vackok ahol a kamera és a szoftver is kicsatlakozik egy harmadik helyre (kínai szerver) és azon keresztül bonyolítják a csomagcserét

( apostroph3 | 2016. 11. 23., sze – 18:40 )

nyitsz egy konzolt, belépsz rootként. 


:~# ifconfig eth0:0 192.0.0.63
:~# 
:~# 
:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         openwrt         0.0.0.0         UG    100    0        0 eth0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.0.0.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

és máris látja a 192.0.0.0/255.255.255.0 alhálózatot

aztán ha már nem kell: 


:~# ifconfig eth0:0 down
:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         openwrt         0.0.0.0         UG    100    0        0 eth0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
:~# 


$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.1.0.0        10.1.0.9        255.255.255.0   UG    0      0        0 tun0
10.1.0.9        *               255.255.255.255 UH    0      0        0 tun0
192.0.0.0       *               255.255.255.0   U     0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     1      0        0 eth0
192.168.123.0   10.1.0.9        255.255.255.0   UG    0      0        0 tun0

( renard | 2016. 11. 23., sze – 18:58 )

Pl. LLDP-t is használhat a kamera, de bármilyen más hasonlót is, akár a gyártó is írhatott valamit, ami L2-n megy.
Már írta más is, hogy Wiresharkkal megtalálhatod az eszközt, azzal akkor is megy, ha nem vagytok IP-ügyileg azonos alhálózatban.
Másik lehetőség, hogy telepítesz Linuxra VirtualBox alatt egy virtuális Windows-t, beállítod a virtuális gépet úgy, hogy a hálózati kártyája egy bridge-ben legyen a gazdagépével (bridge mód), majd azon futtatod a gyártó által adott okos szoftvert.
Ha ismered a kamera IP-jét, akkor valamilyen kis hardverigényű virtuális Linux is megteszi, ha nem akarod az alapgéped hálózati beállításait piszkálni (a bridge mód akkor is ajánlott).

Összegezve mindannyiótok hozzászólásait mégiscsak azt kell(ene) leszűrnöm, hogy:

- A gyártó LLDP - vagy - más, nem IP alapú protokollú hálózatot használ a saját autentikációjához (vagy mi a fenéhez)?
Ez esetben: Linux alól ezt hogyan tudnám felderíteni?
- Windows-t kellene telepíteni mégiscsak egy látszólag triviális probléma megoldására?
Ez esetben: lopnom kellene, hogy egy Windows-t? (Ja, van egy notim, amihez jár XP, de nem ebben gondolkodom.)

- ... Nagyon szeretném Linux alól elérni az akár tudott, akár nem ismert IP-című hálózati eszközt: szerintem ez a kardinális eset.

létezik linux alá lldp daemon, de egyáltalán nem biztos hogy a kamerád használ lldp-t

ha nem megy ne erőltesd, olvasd el a használati utasítást.

a window$os program valószínűleg azért találja meg, mert ismeri az ip címét, aliast hoz létre ahálókártyára, és megadja neki a megfelelő ip-t, vagy routot hoz létre arra az időre amíg fut. ha azt ip-t elállítod valószínűleg az sem fogja megtalálni.

pl erre van az nmap, de nyilván ahhoz előbb bele kel hogy lásson az alhálózatba, ahol a kamera van. ha nem tudod hol van akkor - a leírás alapján - reset, és az alapértelmezett ip címen kell lennie.

Meg fogja találni akkor is, ha átállítod az IP-jét. Nem egy ilyen eszközt láttam már, ami "akármikor" felderíthető a hozzá adott segédprogrammal (nem a Lantronix megoldására gondolok, amikor muszáj legalább az alhálózatot ismerned, a MAC address alapján dolgozó megoldásoknál tök mindegy, hogy milyen IP-cím van beállítva az eszközben).

Kiderült: SADP-t használ a program.
Van ingyenes alkalmazás is, amivel felderíthetők az ilyen kamerák, de csak Windows alá írták még meg.
Ha nem akarsz Windows-t venni (vagy "lopni"), két lehetőséged még maradt: WINE alatt próbáld meg, illetve ReactOS virtuális gépben. Nem vicc, a ReactOS kezd használható lenni (azért még messze nem az igazi), ha szerencséd van, valamelyik alkalmas program megy alatta (akár a gyártótól letöltött, akár az ingyenes).

VirtualBox+ReactOS kombóval az SADP gyári eszközzel sikerült megtalálni a kamerát, és konfigurálni is.

Mindenki segítségét köszönöm.

Ui.: Végül is az volt a lényeg, hogy ne kelljen emiatt kábeleket dugdosnom, hálózatot átvariálni, és a hátsómat se kelljen felemelnem azért, hogy a megszokott környezetemből akár percekre is kilépjek: ergó a kényelem dominált. Az azért egy kicsit fáj, hogy Win-alapú cucchoz is nyúlnom kellett, de azért elégedetten dőlök hátra. :)

Az új fw-ben dobták már a Hikvision-nél a tárva nyitva telnet-et, ssh van helyette. Kicsit van olyan érzése az embernek kezdenek security felé menni, ha gyenge a jelszó, léptem nyomon írja hogy az az.
(Pont most a hétvégen néztem meg jópár linuxos (zoneminder-en túl, pl.:Bluecherry) NVR megoldást...de még mindig a gyári Hikvision-ős eszik a legkevesebbet (vm, ezért fontos))

( apostroph3 | 2016. 11. 28., h – 22:32 )

$ sudo apt install netdiscover

hogy megtalál e olyan eszközöket amihez nem vezet route/bridge, vagy v-mi nemt'om, de mondjuk én elképzelni sem tudom hogy tenné. - hacsak magának létre nem hoz ilyesmit. -

egy próbát megér. 


:~$ sudo netdiscover 

 Currently scanning: 172.24.219.0/16   |   Screen View: Unique Hosts                          
                                                                                              
 1369 Captured ARP Req/Rep packets, from 15 hosts.   Total size: 82140                        
 _____________________________________________________________________________
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname      
 -----------------------------------------------------------------------------
 192.168.5.253   74:ea:3a:db:15:c4    400   24000  TP-LINK TECHNOLOGIES CO.,LTD.              
 192.168.0.1     24:76:7d:4b:52:47     17    1020  Cisco SPVTG                                
 192.168.0.50    10:c3:7b:a2:93:3d    900   54000  ASUSTek COMPUTER INC.                      
 192.168.0.151   2c:ab:a4:a5:72:74      1      60  Cisco SPVTG                                
 192.168.0.153   2c:ab:a4:a5:72:79      1      60  Cisco SPVTG                                
 192.168.0.152   f4:4b:2a:92:ba:81      2     120  Cisco SPVTG                                
 192.168.0.254   f4:ec:38:cc:8d:fe     40    2400  TP-LINK TECHNOLOGIES CO.,LTD.              
 192.168.33.1    24:76:7d:4b:52:47      1      60  Cisco SPVTG                                
 192.168.34.1    24:76:7d:4b:52:47      1      60  Cisco SPVTG                                
 192.168.35.1    24:76:7d:4b:52:47      1      60  Cisco SPVTG                                
 192.168.36.1    24:76:7d:4b:52:47      1      60  Cisco SPVTG                                
 192.168.37.1    24:76:7d:4b:52:47      1      60  Cisco SPVTG                                
 192.168.38.1    24:76:7d:4b:52:47      1      60  Cisco SPVTG                                
 192.168.39.1    24:76:7d:4b:52:47      1      60  Cisco SPVTG                                
 192.168.100.1   00:09:5b:ed:da:02      1      60  NETGEAR                                    

:~$