Samba szervercsere majd fénymásoló scan hiba

Debian GNU/Linux

Hi!

Debian squeeze alatt lévő samba költözött új vasra, azon stretch samba 4.5.12.
Úgy tűnt sikeres volt az átállás, mindenki elér mindent, viszont a fénymásolón beállított scan mappa nem akar működni.
Azt mondja az azonosítás sikertelen, holott gépről működik ugyanazon felhasználóval a megosztás elérése.

Protokoll egyezőség körül keresgélek egyenlőre, esetleg van valakinek ezzel kapcsolatban ötlete?
A fénymásoló típusa Ricoh Aficio MP C3500.

Természetesen egyéb ötleteket is szívesen fogadok.

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

  • 1713 megtekintés

( wildy | 2018. 03. 01., cs – 10:59 )

Ezek a kutyuk szeretnek antik, manapsag alapbol tiltott authentikacios metodust (pl. NTLM1) hasznalni.

Egyrészt igazatok van, de:
1. A fénymásoló SMB beállításainál a munkacsoport, megosztási név, gépnév-en túl max azt lehet beállítani, hogy az SMB engedélyezett avagy sem. Sakk-matt. Persze, azt el tudom képzelni, hogy szervizkóddal mégis lehet állítani, de ekkor jön a következő pont.

2. Nem ez az egyetlen fénymásoló a cégnél, a többi között van a fentinél sokkal régebbi, aminél kétlem, hogy lehetne állítgatni a protokollt.

LDAP-ot is tud a masina, de most azzal nem volt már idő szórakozni, mert persze ilyenkor - amikor nem megy valami -, akkor dolgozhatnék mindenki. :)

Szóval köszönöm az ötletet!

( herka v | 2018. 03. 02., p – 06:55 )

Az smb/ftp kikapcsolása erősen ajánlott az ilyen gépeknél, ha nem akarod,h mondjuk botnet tároljon rajtuk adatot.
Twain szkennelés nem megoldható?
Nálunk így voltak beállítva a régi Ricoh-k.
Igaz kicsit kényelmetlenebb, de használható volt.

Nem csak az M$ számol furán... A Zinternet lenne ilyen gyors?
65% [62 Sources 1528 kB/6239 kB 24%] 3062 PB/s 0s

aficio 2020d
sulinetes router privat szegmensén van 192.168.64.49 fix címen
A router védett szegmenségől 172.17.122.x szeretnénk nyomtatni és scannelni. Nyomtatás megy, a scannelés nem a fenti hibával. Ha beviszem a védett 172.17.122.x szegmensbe, akkor a scannelés is megy. De több szegmensből kell tudnink nyomtatni és scannelni egyaránt.

Pedig semmilyen szűrés nincs
https://sulinet.niif.hu/tuzfal
A védett zónára igazak azok, amik a Privát + Wifi zónára is igazak voltak azzal a kivétellel, hogy a Védett zónában lévő eszközök elérhetik a Privát szegmens eszközeit IPv4-en és IPv6-on egyaránt.

Szerk.: ránéztem huzalcápával, az az érdekes, hogy nem látok semmit a pc-től a scanner-ig kivéve a pinget.
ez volna a RICOH
ez meg a pc

Sikerült megoldanom, azért leírom, hátha más is belefut.

A twain drivernek van egy saját scnhosts fájlja, ami úgy működik, mint a /etc/hosts de ez a nyűveteg twain _csak_ezt_ hajlandó olvasni, ezért nem tudott a gép és a scanner név alapján kapcsolatba lépni egymással és ezért volt üres a wireshark.

Miután helyesen kitöltöttem a scnhosts file-t, a scannertől különböző szegmensen lévő gép forgalmát összvetettem egy vele azonos szegmensen lévő gép forgalmával és ott kibukott, hogy a 514, 1022 és 1023 tcp portokat valamint az icmp-t kell a gép irányába nyitni (privát szegmens felöl a védett felé), mert ahogy a fenti sulinet tűzfal idézetből látszik, védettből a privátba csak egy irányban engedélyezett a forgalom.

Amennyiben botnet van a belső hálón, akkor már megette a fene.... - imho.

A fénymásolót nem gondolnám, hogy az SMB-n keresztül fertőzi meg, mert az az SMB-t csak küldésre használja és nem a fénymásolóra küldenek SMB-vel. Jobban el tudom képzelni, hogy egy preparált nyomtatással, esetleg fax-al, amit a fénymásolónak fel kell dolgozni azzal fertőzhetik meg a készüléket. Bár tény, nem olvastam utána.

Aztán, ha már megfertőzték, akkor az SMB/FTP be-ki kapcsolgatása nem gondolom, hogy akkora történet belülről.

Egy biztonsági protokoll száműzése, tulajdonképpen ördögüzés. Ha "ransomware" támadást tervez valaki Windows hálózati rendszerek ellen, akkor talál megoldást arra, - akkor is, - ha smb2 v. smb3 protokoll kezeli a kapcsolatokat. Legfeljebb azok 0-napi sérülékenységeit a Defender még nem kezelheti, mert nem lehet felkészítve rá. (Legalább jó esetben, ha a fejlesztők is akarják, - az smb1-es támadási mód ismert, - a Win és a böngészők védelmi rendszerei már figyelembe vehetik ezt a támadási módot is.)

Meggyőződésem, a kompatibilitás őrzése az oprendszerfejlesztők részéről nagyobb biztonsági kockázatoktól óvja a hálózatokat, mint a sokak által használt oprendszer-funkció eltávolítása, mert a felhasználók általános, borítékolható viselkedése, az akadályok elhárítása, a védelmi eszközök kikapcsolásával inkább valószínűsíthető mint a "kimetszés" elfogadása és eszközcsere. (Jelen esteben pl. még évekig fognak öreg, smb1-es hálózati nyomtatókat használni, mert működnek, mert olcsóbb az üzembetartásuk, mintha nagy pénzekért újabbakat vennének.)

És már itt is van, amit fenntebb előlegeztem..:
https://hup.hu/cikkek/20180302/smbv3_null_pointer_dereference_vulnerabi…