[megoldva] windows 10 smb1 enable anomália

Microsoft Windows

Sziasztok!

Tegnap óta 2 gépnél is jelentkezett, hogy az eddig működő SMB1 client nem működik. (volt egy rakat frissítés) Pipa a helyén, pipa kivesz, pipa visszatesz, újraindít és jó. Ma megint hívtak, hogy nem működik, pipa kivesz, visszatesz, újraindít és jó. Gondolom holnap reggel megint nem lesz jó.
Valaki találkozott már ilyennel? PowerShell-es tákolás tartósabb megoldás lesz?
A ne legyen SMB1 nem megoldás.

Köszi!

  • 1474 megtekintés

( uid_3194 | 2020. 09. 10., cs – 10:11 )

Szerkesztve: 2020. 09. 10., cs – 10:44

...közben volt módom tesztelni az egyiken és ezen módok egyike sem hozott tartós megoldás, csak az első kikapcsolásig működött, aztán megint nem:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb10 start= auto

Jelenleg tovább nem tudtam feltartani a dolgozókat, amint lesz módom megint a gépekhez kerülni nézem tovább mi a helyzet.

A registry modositas elvileg nem fugg reboot-tol, valamelyik service-t meg kezzel el kellene inditani, hogy mukodjon rebbot nelkul, de elso korben nem jottem ra, melyiket. Az smb, halozati tallozas dolgok futnak.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( zitev v | 2020. 09. 10., cs – 11:33 )

Szerkesztve: 2020. 09. 10., cs – 11:40

https://superuser.com/questions/1558936/what-is-the-method-to-permanent…

"A work around is to write a script that will determine if the feature is enable or disabled, if it's disabled then it will be installed and a reboot will be performed, if it's enabled it will do nothing. You can run this script when the user logs into their account. However, this is a huge security risk, you really should configure your Linux servers to use SMBv3 –"

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Amikor már azt hiszed hogy megszabadulsz az irodai készülékek legótvarabbikától, az fs1135?-től, kiderül hogy a gyártó újra elkezdi értékesíteni egy tök más modelszámmal, egy modernebb müanyag burkolatban. És igen, 2019-ben kiladtak egy olyan készüléket, amin csak smb1 támogatás volt.

( zeller | 2020. 09. 10., cs – 11:41 )

Nomostan a tüneti kezelés meg a homeopátiás placebo ideig-óráig 6, de a probléma okát kéne megszüntetni, vagyis kidobni az SMBv1-et.

Akkor az üf. a fostaligaótvarócska szambaegyest tudó eszköz gyártóját/szállítóját legyen oly kedves kettes túlméretes AI-val (An...lIntr...r) megkínálni, mert értelmes környezetben nem fogadható el egy ilyen, mindenki más által kivezetett/letiltott/beszántott és sóval behintett protokoll.

Sajnos van, amit nem lehet értelmesen és jól megoldani, mert lukas lesz, mint a jófajta ementáli, bónuszként permanensen ilyen problémákba fog vele ütközni.

De ha már belekotty, akkor egy workaround talán összehozható: a ratyi eszközről egy raspi-re felhúzni smbv1-gyel, és továbbosztani smbv3-mal. Nemlesz gyors, ellenben qrva lassú lesz, de legalább működni fog. Amíg a Linuxos/raspbian-os oldalról ki nem vágják végre  a gányláda SMBv1-et.

de legalább működni fog

Talán :) A hivatalos ajánlás, hogy ilyet ne, mert lehet vele szívás (az SMB -> VFS -> POSIX FS -> SMB -> VFS -> POSIX FS lánc bármely pontjánál lehet gond), mert a Samba feltételezi, hogy alatta értelmes FS van, amit csak részben tud emulálni SMB felett.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Az a baj,  hogy a problema onmagaban mar nem az, hogy egy zsarolovirus egyszeru halozat scannelessel tudja terjeszteni magat egy halozati tallozassal engedelyezett megosztasban, mert ezen mar tullepett a viruzsok terjedesi mechanizmusa, igy ennek tiltasa csak a problemat odazza el, nem pedig a megoldas a problemara. Akar maradhatna is az SMB1, ha jol konfiguralt a halozat, a kliensek, es kello tudatossaggal ugykodnek a felhasznalok, akkor tobbet javit a biztonsagon, mintha kiveszik az SMB1-et es mindenki tovabbra is belefosik a kozepebe.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ha az SMB1 jól van konfigurálva, akkor nem működik :) Az a baj vele, hogy az még az az időszak volt, amíg az MS magának azt csinált, amit akart, így egy verziózatlan szemétdomb lett szép lassan az egész, tele az összes legacy szeméttel - valahol egy SambaXP előadásban volt egy állapotátmenet-gráf, hogy hogyan lehet felismerni a használt dialektust, a bal oldalán mindenféle random heurisztika és fallback mechanizmussal összetűzdelt állapottal, a jobb oldalán kb. egy csíkban lefelé az SMBv2/SMBv3/SMBv31, egyértelműen meghatározhatóan.

Az, hogy többé-kevésbé nem protokoll-független (rendesen épít az IPv4-re, bár elvileg tisztán IPv6-tal is működik többé-kevésbé talán), hogy az auth mechanizmusok megrekedtek benne a Kerberosnál (ez még oké, csak általában ami csak SMBv1-et beszél, az elfogadható biztonságú Kerberost sem...) meg a rosszabbnál rosszabb LM/NTLM/NTLMv2-nél... hát na.

Persze, lehet azt jól üzemeltetni, de tisztább-szárazabb egy modern protokollt használni.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Igen, viszont a körülmények valóbannagyon fontosak abból a szempontból, hogy mennyire lesz biztonságos a dolog - volt, hogy két gép között rcp-vel ment a másolás, (üzletileg kritikus, erősenvédendő adatok), amire kissé lilára vált fejjel :) reagált egy auditnál a külsős szakértő, hogy ezt meg hogy.
Aztán megmutattuk neki azt az 1ft hosszú kábelt, amin az adatok ilyen borzasztóan védtelen és elfogadhatatlan módon utaztak két, a zárt rackszekrényben egymás fölött lévő gép között :-D

( lajos22 | 2020. 09. 10., cs – 14:09 )

A blog bejegyzéseim között van erről egy rinyálás. Nézd meg az jó-e! 

openSUSE Leap 15

( Raynes v | 2020. 11. 15., v – 22:29 )

Pedig jobb, ha az ügyfelet hozzászoktatod, hogy nem lesz SMB1. Most is már csak ilyen kínkeserves tákolással lehet megoldani, valószínű a jövőben még ezt is ellehetetleníti a MS, lehet már a következő nagy évszakos update-kor, ami a v2010 lesz valószínű. Kattanjanak le róla 2020-ban, ezt meg kell érteniük, hogy lejárt az ideje, teremtsék meg az újabb megosztási protokollok használatának feltételeit, nem érdekes hogyan csinálják, oldják meg, cseréljenek le minden gépet, minden rajta futó OS, vagy amit kell. Tudom, nincs rá pénzük, de ahhoz van, hogy minden alkalommal szakit ugrassanak, aki újra átállítja, újraindítgatja az elavult szutykukat. A MS sem hobbiból tiltogatja ennyire az SMB1-et, hanem nem akarja, hogy időzített bombaként ransomware-eknek legyen meghívó, és ugyan a kedvenc mantrám, hogy a MS-nál hülyék, de ebben teljesen igazuk van. Én olyan szinten belezném ki a helyükben a Win8.1-10-ből, hogy még csak bekapcsolni se legyen mit. Tudom, sok helyen kell még SMB1, ott harakirit elkövetve a kardjukba dőlnek, vagy lehúzzák a rolót, és a világ továbbléphet végre. Ja, kegyetlenség, meg fejlődésmániás-profitmultis, fősodratú mérnökuras szöveg, de főleg a MS-os világban a dolgok így működnek, egyre inkább. Ha nem tetszik nekik, váltsanak Linuxra, jajj, de azt se, mert azzal sem boldogulnak. Ez van, adaptálódni kell az éppen aktuális viszonyokhoz.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Neki is ugyanezt mondanám. Nem csak az SMB1-re, hanem az XP-jére, meg Win3.1-es vékonykliensére is. Ráadásul itt most nem is magánfelhasználásról van szó, hanem gyaníthatóan cégesről, ahol van keret fejleszteni, meg költségek leírására is mód van. Egy cég tanulja meg megoldani ezeket. Mert egy magánembernél azt mondom, hogy sír, mert nem tudja megoldani, vagy szakmailag vagy pénze nincs. De még hajbi is, aki meg tudná, mániából ragaszkodik ehhez-ahhoz.

Anno ment a sírás, hogy kell az XP, lejárt a támogatása hirtelen (évekre előre be volt jelentve), jajj, mi lesz Win7 nélkül (évekkel előtte be lett jelentve, hogy mikor szűnik meg a támogatás), és mégse lett vége a világnak, a szervezetek, intézmények, cégek működnek tovább. Pedig Win7-es extra 3 éves támogatást is kevesen vettek. Épp így meglesznek az SMB1 meg a többi szutyok nélkül, megoldják webes, felhős megosztással, SMB3-mal, vagy amivel akarják, van bőven alternatíva.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

csakhogy ez nem így működik. vannak rendszerek, amik felmappelt hálózati meghajtókat feltételeznek, és ezek a rendszerek esetleg egyszerű módon nem pótolhatók. persze, lehet utólag okosnak lenni, de a világ nem fordul egyik füttyről a másikra.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ezek szerint neked soha nem volt olyan eszköz, vagy szoftver a kezed között, ami az MS mindenható megoldásaira épült, és aminek cseréjére nem volt ráhatásod és meg kellett oldani a problémát valahogy.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Mondom volt rá néhány év, hogy a döntéshozók is és a végrehajtásban érintettek is megoldják az SMBv1 kihajításával járó problémát. Ha nno jelezted, hogy gond lesz vele, és a döntéshozatalra jogosult fel is fogta, hogymit írtál neki, és ennek ellenére nem történt előrelépés, akkor most szépen elő kell venni a megfelelően elrakott e-mail folyamot, odatolni elé, hogy "én szóltam"...
 

Egyébként volt, ott az SSLv2 kihajítása jelentett problémát - meg lett oldva: kapott egy TLS1.2-t is tudó proxy-t maga elé, és nem ő, hanem a proxy végződtette az ssl-t, illetve a proxy-n lett csekkolva a klines certje - mert az is feltétel volt. Meg lehetett oldani? Igen. Kellett vele dolgozni? Igen. Miközben az eredeti szállítót ég alól -- föld alól nem lehetett elővakarni.

Egyébként volt, ott az SSLv2 kihajítása jelentett problémát - meg lett oldva: kapott egy TLS1.2-t is tudó proxy-t maga elé, és nem ő, hanem a proxy végződtette az ssl-t, illetve a proxy-n lett csekkolva a klines certje - mert az is feltétel volt. Meg lehetett oldani? Igen. Kellett vele dolgozni? Igen. Miközben az eredeti szállítót ég alól -- föld alól nem lehetett elővakarni.

Azzal együtt, hogy egyetértek veled, itt azért el kell mondani, hogy az SSLv2 - TLS1.2 proxyzás pár nagyságrenddel egyszerűbb feladat, mint SMB-nél verziót váltva proxyzni (AFAIK SMBv1 kliens SMBv3 szerver elérés irányban talán még összetákolható lenne sok-sok megkötéssel, a fordított irány még a core SMBv3 [az ugye már modulárisabb specifikáció] esetén is elvi problémákba ütközik, annyi változás volt a protokollban és, ami nagyobb gond, a mögöttes "adatmodellben"), egyszerűen mert túl nagy és bonyolult a protokoll az MS-féle csesszünk össze mindent IS hozzáállás okán (de még egy SMBv1 - SMBv1 proxynál is lehetnek olyan edge case-k, amik miatt elvi lehetetlenség a teljes implementáció, pl. egy DFS link felvet néhány kérdést).

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Már engedhessek meg, hpgy a user eldonthesse, hogyan akarja uzemeltetni (ertsd szetbaszni) a sajat rendszeret - ha valakinek anonimus useres open ftp a maniaja, akkor erre most is lehetosege van. Egy oprendszertol nem azt varjuk el, hogy atyaskodva okoskodjon, plane miutan pontosan az o szemete miatt omlik a szarlavina. Ha nekem van egy sajat uzemeltetesu, zart rendszerem amin smb 1.0-t hasznalok, hogy Mancika megkapja a napi tallozhato halozatat, akkor nekem ne frissitgesse szet a nagysagos magassagos oprendszer ur lepten nyomon, plane hogy megoldast nem nyujt arra amit elvesz. Majd azt mindenki eldonti, hogy kell-e neki, avagy sem az a szar, amit beleganyoltak a rendszerbe, akarja-e azt abban a formaban, annak minden problemajaval, velt es valos hibajaval egyutt hasznalni, akar-e helyette egy masik megoldast (annak minden problemajaval, hibajaval, es jarulekos szarjaval) a nyakaba es a felhasznaloinak a nyakaba zuditani. Ha nem akar, akkor pedig az is  hamar kiderul, hogy MS is'nt the way...

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Direkt azzal kezdtem, hogy ebben egyetértek veled. :) Ha viszont bármi miatt az van, hogy meg kell tartani a régi SW-t/HW-t, akkor egy SSLv2-t tiltó proxy nagyságrenddel egyszerűbb kérdés, mint az SMB fő verziók között proxyzni.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Ezzel a hozzáállással jópár üffél elköszönne tőlünk. Mai napig kiválóan mennek XP alapú POS terminálok éttermekben, nincs rajtuk internet, zárt hálózaton, és semmi bajuk. Ügyfél részéről teljesen jogosan elvárható, h addig használja, míg csak lehet. A vasra nem megy fel újabb rendszer, mert kicsi az ssd, és kevés a memória, meg a proci sem combos, mivel célgép.

Elborzasztalak, ilyen esetben a megoldás valószinű az lenne nálunk, h a w10 alapú szervert kukázzuk, és kapnak helyette win7-et.

ha a fentebb emlegetett fs1135 a Kyocera-nak vmi nyomtató-szkennelő szarját jelenti, akkor a Kyocera mint gyártó természetesen maga szerepel a szégyenlistán. Külön bónuszpontot ér, hogy ezzel a roppant szimpatikus hozzáállással érdemelte ki az örökös szégyenlista tagságot: a Kyocera enbloc titkolja a selejtes szarjainak az SMBv kompatibilitását a vásárlók elől publikusan elérhető módokon.