Microsoft gaat SMBv1 uit Windows 11 verwijderen

Microsoft gaat het SMBv1-protocol standaard uitschakelen in Windows 11. Daarmee komt er een definitief einde aan het dertig jaar oude protocol, dat al sinds 2017 niet meer standaard in Windows 10 en Windows Server werd geleverd.

Microsoft schrijft dat het inmiddels is begonnen met het uitschakelen van bestaande SMBv1-instanties in Windows. Het gaat dan om de laatste plek waar het protocol nog actief was, in Windows 11. Daarin zat SMBv1 nog standaard geïnstalleerd, maar het protocol verdwijnt daarbij. Systeembeheerders die de tool nog wel willen of moeten blijven gebruiken, kunnen die nog steeds wel installeren. In de toekomst worden echter ook de binaries verwijderd. Gebruikers van Windows en Windows Server kunnen daarmee niet langer de drivers en DLL's van SMB1 terugvinden in hun systemen. Microsoft blijft die wel als losse download aanbieden voor organisaties die nog bepaalde oude apparatuur hebben gekoppeld aan pc's waarvoor SMBv1 toch nodig is. Het is niet bekend op welke termijn Microsoft dat wil doen.

SMBv1 is een protocol van bijna dertig jaar oud dat inmiddels steeds vaker veiligheidsproblemen oplevert. Microsoft is al langer bezig met de uitfasering. Het protocol werd al sinds 2017 niet meer geïnstalleerd op Windows 10 en Windows Server. Dat ging geleidelijk, maar inmiddels is de tool helemaal nergens in Windows 10 meer te gebruiken. Nu volgt ook Windows 11 Home. SMBv3 wordt dan de standaard.

Reacties (106)

Nu volgt ook Windows 11 Home. SMBv3 wordt dan de standaard.

Tegen beter weten in hoop ik toch dat SMBv3 al de standaard is tenzij er nog een hele goede en antieke reden is om iets anders te doen.

Je kan trouwens in PowerShell (elevated) zien welke versie van SMB wordt gebruikt voor je networkmappings etc met:

Get-SmbConnection

[Reactie gewijzigd door PolarBear op 20 april 2022 16:23]

En een quick fix voor diegene die het nog aan hebben staan is het via powershell uit te zetten:
Set-SMBServerConfiguration -EnableSMB1Protocol $false

Dan hoef je SMBv1 protocol niet direct te deïnstalleren

Als je het nog aan hebt staan, is het probleem waarschijnlijk niet het uitzetten. Maar oude software die alleen met smbv1 kan communiceren om te functioneren.

Er is echt helemaal niks mis met een oud(er) protocol zolang je je eigen netwerk beveiliging maar op orde hebt. Tja, zijn er onbetrouwbare factoren binnen je netwerk e.d. is het natuurlijk een ander verhaal.

Ja, het kan op die manier maar het is ook gewoon een geval van weakest links in je chain, die wil je gewoon mitigeren en niet meer gebruiken.

Het kan natuurlijk wel in een hoop ergenis escaleren wat betreft die beveiliging en zo ook een hogere load meedragen!

Er van uitgaan dat binnen je eigen netwerk nooit onbetrouwbare factoren aanwezig zijn en zullen zijn is niet echt veilig denken.
Een keer iemand met een onveilige USB-stick, telefoon of verkeerde klik in een link en dat is voorbij.
Attack surface kleiner houden door dit soort dingen uit te zetten is iets waar je altijd naar moet streven en isoleren waar dat niet lukt.

Waar het over IT beveiliging gaat is het motto 'assume breach'. Dus je beveiligt je systeem met als uitgangspunt dat er al ongewenste vreemdelingen in je netwerk zitten. En dat geldt op alle lagen. Het oude idee van 'zolang niemand door je buitenste schil komt is het veilig' is echt achterhaald.

Volgens mij kan Sonos alleen SMB 1 aan.

Sonos heeft recent SMBv2 en SMBv3 support toegevoegd voor S2

Release notes for Sonos S2
13.4.1 Release date: 12/07/2021
Sonos products can now connect to local music library shares using SMBv2 and SMBv3.

Dat wist ik niet. Wat ben ik blij met jouw post. Kan ik eindelijk SMB1 op mijn NAS uitschakelen.

Dat was alleen nog voor de SONOS ingeschakeld. Mijn SONOS systeem draait echter op OS S2. Dus zou met SMB2 en 3 overweg moeten kunnen.

Ik zie nu dat SONOS idd via SMB3 connecteert met de NAS.

Me very happy now!

[Reactie gewijzigd door Panzer_V op 20 april 2022 19:24]

Hoe kan je dit controleren?

Gestreamde muziek opzetten. Inloggen op de NAS en kijken hoe de SONOS gebruiker ingelogd is.

Synology geeft per ingelogde gebruiker weer via welk protocol dit is.

Dank!

S1 kan het niet en zal het nooit kunnen. Heb nog prima werkende Sonos boxen die niet hoger kunnen dan S1.

Dank je. Dan ga ik dat ook eens controleren.

Samba kan nog V1 praten, dacht dat het zelfs de standaard was? Je kan dit gelukkig wel aanpassen.
Daarmee bedoel ik dus als Windows-client verbinden naar Samba/CIFS.

Ik was pas bij een klant die grote zaagmachines heeft staan. Zo’n zaagmachine kost nieuw 75.000 euro. De aansturing van de machine ging via een ingebouwde XP machine. Vanaf een werkplek werden de tekeningen met zaaginstructies naar de XP machine gestuurd (SMB share). Die zitten dus vast aan Windows 10. Op zich begrijpelijk, maar toch wel jammer dat er geen escape meer is.

Ik zit in die sector ook wel de OT genoemd ofwel operationial technlogy ipv IT.
Er is geen enkele industriele speler die OT software aflevert die niet up te daten is naar nieuwere versie die perfect draaien op de allerlaatste Windows, Siemens, Yokogawa, Schneider, geen enkele.

Het probleem is dat een productiemanager gewoon is van een machine te kopen zonder zich de vraag te stellen wat onderhoud betreft of al van het concept end-of-life heeft gehoord. Begrippen als TCO of lifecycle zijn hun onbekend, de vraag is wat kost die zaagmachine om aan te kopen en hoeveel gaat die productie van die zaagmachine mij opbrengen.

De tussen leverancier profiteert daarvan want die levert in dit geval een zaagmachine met een sturing maar zonder enige support waarbij het bijna industry standard is dat de logica (zeg maar source code) password protected is. Zelfs perfect mogelijk dat de klant niet eens het admin wachtwoord heeft van de Windows machine. Als de klant dan ooit komt vragen om die Windows een update te geven of gelijk wat voor support dan krijgt de klant uiteraard een belachelijk hoge offerte.

Gezien je niet aan de logica kan is het onmogelijk voor een 3de partij om die te exporteren en te importen in een nieuwere versie. Vaak is er ook totaal geen functionele beschrijving van hoe die sturing werkt waardoor je maar 1 optie hebt, héél die machine (of installatie) volledig reverse engineeren wat gigantisch resource intensief is en dus veel geld kost, meer dan de belachelijk hoge offerte van de orginele leverancier.

Dan ga ik er nog vanuit dat de originele leverancier nog bestaat en zelf nog de wachtwoorden heeft, dat durft ook nogal tegen te vallen. En dan probeert men maar de WinXP of zelfs Windows 98 aan de praat te houden terwijl je stukken zoekt op Ebay want waar anders ga je nog een DDR1 ramlat scoren?

[Reactie gewijzigd door sprankel op 20 april 2022 21:21]

Binnen OT zijn de legacy systemen inderdaad vaak een probleem. Op ebay etc is er inderdaad nog een levendige handel in zaken als Siemens S5 PLC's.
Wat ook geldt is dat de protocollen die de door jou genoemde leveranciers gebruiken ook geen beveiliging kennen en sowieso geisoleerd moeten worden.

De protocollen is inderdaad nog een heel ander verhaal, OT heeft altijd zuiver naar safety gekeken (risico's als er iets per ongeluk fout gaat) maar nooit naar security (risico's waar er een kwaad opzet is).

Vanuit safety is de vraag dus gesteld wat als ik per ongeluk met een hamer op jou vingers klop? Wat op te lossen is door mij geen hamer te geven. Maar vanuit security waar ik op jou vingers wil kloppen breng ik dan gewoon een hamer van thuis mee, of ik gebruik een baksteen om op jou vingers te kloppen.

Dat maakt dat safety een vrij statisch risico beheer is, eenmaal je een risico geborgd hebt ben je klaar tenzij je oorspronkelijk iets over het hoofd hebt gezien. Security is een ander verhaal omdat men daar continu naar nieuwe manieren zoekt om het toch te omzeilen en je moet reageren elke keer iemand een nieuwe manier heeft gevonden => security is dynamisch met updates en changes die continu gebeuren.

Hoewel security & safety hand in hand gaan conflicteren ze ook want als jij gaat updaten voor security dan kan dat ook een impact hebben op je safety verhaal. Dat wilt zeggen dat als je pakweg een zuiver safety sturing gaat updaten voor security dat je heel het achterliggend safety systeem opnieuw moet gaan testen en goedkeuren, dan kan een installatie meerdere dagen plat gaan liggen. Als je dan elke maand afkomt met hier is een update voor security dan is dat simpelweg onwerkbaar.

OT heeft echter in het verleden de fout gemaakt van te zeggen, wij zijn toch air gapped dus die security is voor ons niet van toepassing, men heeft security volledig buiten gezet zonder te beseffen dat je sowiezo safety mee impacteerd. Nu OT meer en meer moet koppelen met IT, smart grids, slimmere sturing, automatische stock opvolging, ga maar door, is dat air gapped verhaal eigenlijk al lang verdwenen waardoor OT nu met een accuut security probleem zit.

En dan is het gigantische probleem natuurlijk dat al die OT systemen nooit ontworpen zijn met concepten uit de IT wereld waar je modulair gaat updaten. Of gewoon al het feit om een update uit te voeren, die procedure is vaak extreem omslachtig omdat men ervan uit ging dat eenmaal het werkt, eenmaal de safety geborgd is, dan blijf je eraf.
Iets wat je ook in de IT ziet als je naar firmwares en bios/uefi kijkt, daar blijf je vanaf tenzij je echt een probleem hebt was de redenering vroeger. Vandaag bevatten die firmwares en Uefi's security updates, nu moeten die plots wel altijd de laatste versie krijgen en dan zie je IT ook worstelen om die via het gewone update proces mee te nemen. Dat gaat dan over Uefi/firmware via Windows update maar ook over Uefi settings die gewist worden met een update of bitlocker die problemen geeft omdat het update proces bitlocker niet automatisch on hold zet tijdens de update.

Dat IT probleem rond firmware & Uefi, dat heb je in de OT maar dan bijna met alles.

Een ander issue issue waar je tegen aan loopt met updates op OT gebied is een andere prioriteit.
Binnen de security geldt voor IT systemen binnen de CIA (Confidentiality, Integrity en Availability) dat de C en/of I leidend zijn en dat de A minder belangrijk is. Een uur niet kunnen webwinkelen, printen of emails lezen na een update die liefst buiten reguliere uren wordt gedaan is vervelend maar niet onoverkomelijk.

Binnen de OT is de A heilig en dat maakt het lastig samen met het ontwerp dat op "air-gapped" is ontworpen.

Klopt maar dat is dan ook het grote verschil tussen OT & IT, wat ze gebruiken en wat ze doen verschilt niet aan de basis, ze gebruiken beide chips, software en programmeurs om een doel te bereiken. Echter IT zijn doel is informatie, OT zijn doel is operationieel (fysiek)

IT zijn grootse bezorgdheid is informatie, dat het systeem tijdelijk onbereikbaar is, liever niet maar het horror scenario is dat je al u informatie zelf kwijt bent.

OT zijn grootste bezorgheid is operationieel, dat je informatie kwijt bent, liever niet maar het horror scenario is dat u systeem tijdelijk onbereikbaar is.

Praktisch voorbeeld:
Mail server => als de mailserver offline is, liever niet maar ok. Maar als alle mails weg zijn heb je pas echt een probleem

PLC sturing van een nucleaire reactor => als je niet kan zien hoe de reactor presteert wat feitelijk informatie is, liever niet maar ok. Maar als de PLC/systeem down is dan is er geen sturing meer, dan heb je pas echt een probleem omdat je met een fysiek proces zit dat niet stopt met bestaan, die reactor blijft werken maar je bent niet meer de reactor aan het sturen.

Uiteraard is de A dan heilig maar dat is dan de fout die OT in het verleden gemaakt heeft, omdat die A zo heilig was vloog security volledig buiten. Dat wilt echter niet zeggen dat die OT systemen niet in maintenance kunnen gaan maar een nucleaire reactor leg je niet even stil op 5 minuten en start je ook niet op in 5 minuten. Daar zit je met een blijvend conflict want men gaat ook niet accepteren dat een reactor elke maand in maintenance gaat voor security updates tenzij je die updates kan doen zonder enig risico zonder te herstarten maar dat is iets wat zelfs IT nog niet kan laat staan OT.

*ik gebruik gewoon even een nucleaire reactor als voorbeeld maar hetzelfde probleem heb je met heel veel fysieke sturingen. Een vliegtuig stopt niet met vliegen als het systeem down gaat, een auto stopt niet met rijden, een turbine stopt niet met draaien, een chemische reactie stopt niet,....

Je legt in feite nog een keer uit wat ik al schreef, we zijn het dus wel met elkaar eens.

Een dingetje wat niet helemaal klopt:

Klopt maar dat is dan ook het grote verschil tussen OT & IT, wat ze gebruiken en wat ze doen verschilt niet aan de basis, ze gebruiken beide chips, software en programmeurs om een doel te bereiken.

Buiten OT zijn de netwerkstacks robuuster, in PLC's etc zijn ze vaak naiever geprogrammeerd. Zie bv deze tekst uit "Hacking Exposed Industrial Control Systems" van Clint Bodungen e.a. (sorry lange quote):

Operational technology (OT) device control, or disruption, is the end goal of a threat determined to cause maximum impact. Unfortunately for asset owners, making these devices behave in a way that is outside of their designated function is not that difficult since security wasn’t an inherent design consideration. For example, the network stack is often unable to handle traffic that it’s not intended to receive (for example, oversized packets, malformed packets, or even just regular traffic that doesn’t conform to the specific intended functionality of the device). The device’s other hardware components also have limited thresholds that can be exploited, such as creating a load that causes a spike in processor utilization. Scenarios such as this have been known to cause devices to malfunction, reset, and fault. For example, a simple one-line command like this one using the ICMP protocol has been known to have adverse effects on the vast majority of ICS devices:
root@kali:~# ping -s 65535 192.168.50.127
That’s right, it’s the infamous (or notorious) Ping of Death from the 1990s. For those of you unfamiliar with the Ping of Death, this command simply sends a large ping request packet of 65,535 bytes to the target. It’s virtually harmless to all modern, common business IT systems and applications, but it can give ICS devices trouble.

Ongelofelijk dat die niet meegaan met de tijd. Italiaanse levererancier? In het verleden ook al eens mee gewerkt. Zelfs nog 2 machines op de plank gelegd toen met een echte COM poort voor het geval de pc er mee op hield

Present. Hier ook een Italiaanse CNC waarvan de XP controller is afgekoppeld van het netwerk, en lokaal verbonden is met een Win10 werkstation ernaast. Deze stuurt de opdrachten naar een SMB share op de controller. Probleem is dat leveranciers belachelijk veel geld vragen voor het inrichten van een Win10 machine. Zelf een upgrade doen is kansloos, daar zijn deze machines echt te complex voor. Wij kopen ze tweedehands dus dan loop je al snel tegen EOL aan, maar ook nieuw worden ze vaak uitgeleverd met een OS dat al 1 of 2 versies achterloopt. Zo worden nieuwe machines nu uitgeleverd met Win7. Dan is EOL snel in zicht. Gelukkig zit onze productieleider nu op 1 lijn v.w.b. aanschaf nieuwe. Laatste OS en anders niet.

[Reactie gewijzigd door fRiEtJeSaTe op 21 april 2022 09:20]

Zolang het nog maar wel te installeren is, aangezien er nog zat mensen zullen zijn die een oude NAS hebben staan, die alleen maar SMB 1 aan kan. Op zich helemaal geen ramp, zolang je het maar binnen je eigen LAN gebruikt.

Dat moet dan een wel héél erg antiek NAS zijn. SMBv2 is al in 2006 geintroduceerd, met de introductie van Windows Vista en Windows Server 2008. SMBv3 is er al sinds 2012, met Windows 8 en Windows Server 2012.

Dan zou je dus een 16+ jaar oud NAS moeten hebben, die ook nooit een update (met o.a SMBv2-support) gehad heeft.

En zelfs dan kan je altijd nog uitwijken naar 3rd party implementaties van SMBv1 als LikeWise, Tuxera, NQ of CIFSD.

Soms moet je eens serieus overwegen of je dat soort (in IT-termen) antieke apparatuur wel in je netwerk wil hebben. Zelfs als dat een intern LAN is. Je loopt namelijk serieuze beveiligingsrisico's, en niet alleen via SMBv1.

Een SMB server wordt in de praktijk door de software Samba geïmplementeerd. Zo is SMBv2 support pas sinds midden 2011 beschikbaar. Daarna moeten de Linux distributies die Samba versie oppikken, en dat gebeurde vaak pas bij major versies van die distributies. Veel NAS draaien een afgeleide van Debian dus dan duurt dat sowieso al langer.

Bottom line is dat je niet zomaar zeggen "Nieuwe SMB versie is direct beschikbaar".

Bovendien is Samba voor veel mensen (lees: voor mij) nogal abstract, en snappen niet helemaal waar de problemen en kwetsbaarheden precies zitten. Gevoelsmatig valt het allemaal wel mee, terwijl de CVE's toch behoorlijk ernstig zijn.

Dat komt omdat veel mensen "gewoon" simpel bestanden willen delen zonder poespas. Bijvoorbeeld hun mapje "Downloads". Maar Samba bestaat uit vele services met juist een hoop poespas om bijvoorbeeld printers te delen, automatische driver installaties te verzorgen, bestanden van ingelogde gebruikers automatisch te delen, makkelijke netwerknamen communiceren, etc.

Welk van deze services zijn nu eigenlijk steeds kwetsbaar? Kan je die ook uitschakelen als je "gewoon" bestanden wilt delen? Als je een Samba server opzet maar printers, drivers, homes etc allemaal uitschakelt, wanneer ben je dan kwetsbaar? Als de kwetsbaarheden als SambaCry steeds over buffer overflow en read code execution gaan, ben je dan veilig als je shares read-only zijn zodat een hacker (in jouw huis op jouw LAN) geen payload weg kan schrijven? Ben je sowieso veilig als je alleen authenticated shares gebruikt?

Ik vind het moeilijk in te schatten allemaal, dus zet ik het uit voorzorg op de NAS vaak op extra streng, maar het frustrerende gevolg is dat veel mensen die met een Windows-laptop langskomen vaak niet op de share kunnen komen. Linux-laptops overigens wel.

Ik heb er nog een ReadyNAS Duo liggen die ik gebruik voor het delen van content op lan parties. Die is trouwens zeker geen 14 jaar oud. Toch best wel jammer dat een goed werkend stuk hardware afgedankt moet worden vanwege verouderde software. Misschien veilig, maar niet echt sustainable.

Het gaat niet om de leeftijd van de hardware natuurlijk. Zolang de producent keurig software updates levert zou SMBv3 ook gewoon mogelijk moeten zijn.
Probleem is echter steeds vaker dat er hardware wordt uitgebracht waar daarna niet meer wordt omgekeken.

Tja, als het bedrijf minder dan veertien jaar geleden gekozen heeft om een destijds al verouderd protocol als enige optie te gebruiken, ligt de blaam in mijn ogen eerder bij de fabrikant van die NAS dan bij Microsoft als ze de wereldwijde cyberveiligheid willen verbeteren.

ReadyNAS is daar helaas ook zeker niet de enige in, maar het zijn wel dit soort bedrijven die ervoor hebben gezorgd dat Windows zo lang dit brakke protocol heeft moeten ondersteunen, met alle exploits die daarbij horen.

even snel gegoogled en de handleiding dateert van 2011 time flies

Ook hier kan je Debian op installeren.

ook op de SPARC(v8)-variant? want dat was een rare custom-SOC waar geen recenter modules voor waren dacht ik (had er ooit een)

Dat microsoft in 2006 het smb2 protocol heeft geïntroduceerd houdt niet in dat iedereen dat toen ook al kon en mocht doen. Het heeft even geduurd voordat het smb2 protocol breed werd geaccepteerd en geïmplementeerd. Het heeft tot versie 3.5/3.6 (2010/2011) geduurd voordat de samba suite het bood (https://en.wikipedia.org/wiki/Samba_(software)). Vanaf dit moment boden de nas-leveranciers het ook aan in hun (nieuwe) producten en de betere leveranciers ook in hun bestaande producten.

Dus als je in 2012 een ouder nas model hebt gekocht had die origineel nog geen smbv2 aan boord.

Overigens op de zelfde pagina (https://en.wikipedia.org/wiki/Samba_(software)) zie ik ook dat samba na versie 4.11 (2019) het smbv1 protocol standaard niet aan heeft staan.

Gelukkig is 10 jaar oud helemaal niet het stenen tijdperk in de IT wereld. Dus dat kan je nog prima blijven gebruiken

En dat zou dan ook betekenen dat je NAS al 10 jaar geen software updates krijgt?

Menig ziekenhuis waar nog apparatuur staat die alleen op W98 draait.

Dat zal dan apparatuur zijn die op geen enkele manier een verbinding met de buitenwereld heeft. Anders zou dat een grof schandaal zijn.

Die PC is inderdaad air gapped, maar het apparaat erachter is gewoon duur en heeft geen nieuwe software versie, en werkt niet op nieuwere windows. Dus zo ver het backwards compatability verhaal van windows.

Mijn qnap 419 nas is uit 2011 (pricewatch: QNAP TS-419P+ Turbo NAS) en ze heeft begin maart 2022 nog updates gekregen: https://www.qnap.com/nl-n...419p%2B&category=firmware.

Dus ja, er worden nog wel eens wat oudere systemen goed onderhouden.

bij mij thuis hadden we een nas uit 2009 die niets verder dan smb1 deed.

dus er zijn best nog wel nieuwere nassen uitgekomen waar nieuwer niet in zat (was een of ander budget ding maar toch).

niet dat je nog een nas uit 2009 wilt gebruiken maar toch 3 jaar releasen na introductie van smb2 en het niet supporten is niet goed.

SMB 2.0 / SMB2.02 introduced with Windows Vista/2008 is supported with Samba 3.6

Als je NAS nog steeds geen SMB 2 ondersteund, verwacht ik dat je ook andere issues er mee hebt.

Als je NAS prima werkt (zoals bijv mijn D-Link DNS-320) en de fabrikant geen firmware uitbrengt waarin een hogere versie van het samba protocol aangeboden wordt, wat moet je dan? Een prima werkend apparaat bij de e-waste berg voegen? Voor het centraal opslaan van de foto's en documenten (welke vervolgens via ftp off-site op een externe hdd gezet worden) voldoet zo'n NAS meer dan genoeg.

Naar mijn idee moet je dan nog steeds bij de fabrikant zijn. Het feit dat Windows na zoveel jaar stopt met de support is niet het probleem. Net zoiets dat AGP ook al heel lang niet meer een standaard is, terwijl mijn 20 jaar oude videokaart het misschien nog wel prima doet.

werkelijk waar? je gaat een protocol met een connector vergelijken?

AGP is niet een connector maar een standaard voor een snelle 'bus' voor videokaarten...
Dus een standaard met een protocol/standaard vergelijken is niet heel raar, waarom zou dat zoveel anders zijn dat het je zo verbaasd?

Beide zijn verouderd en achterhaald, omdat er snellere, betere en veiligere alternatieven zijn.

het is toch Avanced Graphics Port en geen Avanced Graphics Protocol??
Het is een doorontwikkeling van een ISA-slot toch?
Net als VLB (Vesa Local Bus) een doorontwikkeling is van Local Bus?
en PCIe dat is van PCI?

Allemaal poorten en connectors, die aangestuurd worden met protocollen en drivers, ja.
Maar ik vind hardware met software vergelijken een beetje raar...
my2cts

Net zoals Universal Serial Bus wat geen Bus is, Thunderbolt niet letterlijk via bliksem werkt en FireWire niet altijd in brand staat, soms is een naam alleen maar een merknaampje en niet een juridisch waterdichte beschrijving
Zo ook met AGP, ja het is een connector, maar die connector moet ergens aan vast zitten en de AGP standaard bepaalt hoe dat gebeurt, welke pinnen wat doen, hoe data-transfers geregeld moeten worden enz.
Het is niet zo dat een AGP poort met wat Prit-stift vastgeplakt zit, daar zit nog best wel wat achter en daarom heb je een standaard zoals AGP nodig om te bepalen hoe en wat er achter die connector speelt

VESA-local bus was niet echt een doorontwikkeling van local bus, local bus was geen standaard maar de verzamelnaam/term voor whatever elke fabrikant zelf bedacht, VLB moest dat samenbrengen tot 1 standaard en faalde hier grotendeels in. ISA deed dit dan weer een stuk beter door de bus-klok los te koppelen van de CPU klok (onder andere) zodat uitbreidingskaarten een daadwerkelijke standaard konden volgen.

AGP is niet een doorontwikkeling van ISA sloten, maar van PCI sloten, omdat ISA toen al flink achterhaald was en PCI eigenlijk ook; het had niet genoeg bandbreedte voor voornamelijk videokaarten.
AGP is dan ook eigenlijk een PCI bus zonder 'bus' maar met een direct pad naar de CPU, de AGP kaart deelt niet zijn bandbreedte met de rest van de bus, verder heeft AGP nog wat extra optimalisaties vergeleken met PCI.

En hoewel PCIe kwa naam erg lijkt op PCI (of PCI-X) is het niet direct een opvolger van PCI maar vooral van juist AGP.

Hardware met software vergelijken is hetzelfde, zowel de AGP, PCI en PCIe standaarden beschrijven/bepalen hoe software er van gebruik moet maken, daar kan je de software niet loskoppelen van de hardware, ook zit er nog een laag firmware tussen die ook volgens de standaard moet functioneren. Ja wat je ziet is een fysieke connector (hardware), maar de standaard 'AGP' gaat niet alleen over die connector. Net zoals Windows niet alleen software is maar ook een deel hardware (afhankelijkheid van de x86 instructie-set en een aantal extras).

Dingen als het OSI-model beschrijven heel leuk de digitale wereld als individuele lagen die je perfect uit elkaar kan trekken maar in realiteit werkt het niet zo
De vergelijking was daarnaast over hoe spullen nog prima kunnen werken terwijl niemand het meer ondersteunt...

Een protocol kan je beter met een kabel vergelijken: er zijn 2 partijen bij betrokken, net zoals de 2 stekkers aan de beide einden van de kabel.

Beide partijen in de communicatie moeten met elkaar overweg kunnen.

Eerder deze de Twain-drivers uit Windows 98 met webcams en scanners.

Zoals je zegt de support stopt, maar er zijn altijd work arounds, in het geval van smb 1.0 Zeer zeker ook in Windows 11 en wss ook de volgende!

Wat is 'prima werkt' ? een van de belangrijkste redenen om SMBv1 niet te gebruiken is security. dus als je NAS alleen SMB1 doet werkt hij wat betreft security totaal niet prima. Als je dit dan op je PC aan gaat zetten maak je ook daar een probleem.
Kom niet aan zetten met er staat toch geen privé data op. Want je windows systeem gebruik je vast wel om je bank te benaderen, aan kopen te doen, of je om te mailen en er staan vast wachtwoorden opgeslagen.

.edit: hier stond onzin, ik ging er even vanuit dat de SMB vulnerabilities voornamelijk aan de serverkant van de Windows implementatie zaten, maar dat is niet zo.

Als alternatief zou je natuurlijk wel een 3rd party SMBv1 client kunnen gebruiken. Het probleem is niet inherent aan het protocol.

[Reactie gewijzigd door .oisyn op 20 april 2022 20:16]

Volgens mij is het juist wel inherent aan het protocol. De security uit die tijd was van een hele andere orde.

Nee, het protocol zegt niet dat je willekeurige code uit moet voeren die de tegenpartij aan je geeft. Dat is een implementatieding op basis van speciaal geformatteerde packets die niet goed worden gevalideerd.

Het kan allemaal best gepatcht worden, maar op een gegeven moment maak je de keuze om die oude versie niet meer te maintainen en dus gewoon uit te zetten, zodat je niet meer kwetsbaar bent voor nog onontdekte fouten.

[Reactie gewijzigd door .oisyn op 20 april 2022 21:18]

SMB1 is uit 1983, het protocol is oorspronkelijk ontworpen voor gesloten tokenring netwerken, voor het internet tijdperk en nooit met de gedachte van security. De patch is er in de vorm van V2 en V3.

We hebben het hier waarschijnlijk over Samba/CIFS, dat is compatibele eraan, maar wordt wel gepatched.
Het enige is dat Windows 10/11 het dus niet meer praat.

de naam CIFS kwam in 1996 uit de koker van Microsoft. met het idee om NETBIOS te laten verdwijnen. CIFS hebben ze nooit door gezet.
Je bedoeld dan waarschijnlijk Samba als reverse engineering van SMB. maar ook Samba heeft sinds 2019 SMB1 uit staan by default.
Windows 10/11 kan rustig met Samba shares connecten geen enkel probleem

SMBv1 weer inschakelen. Windows 11 zal nog wel een tijdje ondersteund worden.

Er zijn eerder Samba clients voor Windows gebouwd, kan weer gedaan worden.

Je kent de risicos. Als jij daar mee kunt leven, hoeft er niks op de schroothoop. Maar vaak is het natuurlijk zo dat wanneer er 1 veiligheidslek is, er wel meer zullen zijn. TLS 1.0 zal ook nog wel gesupport worden op die NAS. Etc, etc.

Je moet toch bij elke NAS eens in de zoveel jaar de harddisks vervangen. Dan zou ik bij mijn volgende cyclus op de NAS mee vervangen.

Helaas is het nu eenmaal zo dat eens in de x jaar (vind 30 jaar voor een protocol vrij lang) een protocol te vervallen komt.

Helaas is het alleen wel zo dat er veel NAS's in de wereld zijn die zijn uitgebracht in de tijd van SMB 2 of zelf 3. Maar nog 1 draaien want zal denk ik wel makkelijker geweest zijn om te ontwikkelen want het werkt toch? Een makkelijk manier om kosten te besparen waar de gebruiker op moment van aanschaf niets van merkt.

Ligt de fout van bij Microsoft of bij de leverancier? Ik vind de leverancier.

De HW kan het nog perfect doen, maar als de software al zo oud is. Zou ik het persoonlijk niet eens in mijn netwerk willen. Maar ik lees, dat je er Debian op kan zetten en daarmee weer up to date kan zijn.

En over de e-waste berg, beter een device kopen, wat opensource software gebruikt en ondersteund de volgende keer Ik kijk altijd, in hoevere ik custom firmware er op kan zetten. Juist, omdat ik de fabrikanten niet vertrouw in hun update beleid.

Maar dit ben ik en jij kan natuurlijk totaal andere afwegingen maken

Als je NAS prima werkt

Straks werkt hij niet prima meer, iig niet met Windows 11 clients.

Hoezo? Gebruik nog steeds Movian(voorheen Showtime) als mediaspeler en die volgensmij ook alleen nog SMBv1 en lijkt er niet op gaan komen dat die hoger gaat ondersteunen. Zeer fijne mediaplayer voor mn PS3 en FireTV stick.

Op zich helemaal geen ramp, zolang je het maar binnen je eigen LAN gebruikt.

Totdat er ongewenste (user-mode) software binnenkomt die op het lokale netwerk gaat zoeken naar exploiteerbare machines, of iemand dat (onbewust) meeneemt op zijn telefoon/tablet/laptop en verbindt met jouw wifi-netwerk.

Of totdat een smart apparaat blijkt een reverse shell open te zetten omdat de fabrikant geen zier geeft om software security. Eigen LAN veilig houden is een utopie.

Precies. Hoewel ik ook het gevoel krijg dat mensen die een NAS met SMBv1 gebruiken er sowieso geen authenticatie op hebben staan ("want het is toch alleen maar intern bereikbaar") dus behoorlijk wat doelen kunnen ook zonder exploits al bereikt worden.

Op zich helemaal geen ramp, zolang je het maar binnen je eigen LAN gebruikt.

Op zich geen ramp als geen enkel apparaat geëxploiteerd is. Zodra dat wel het geval is, geef je hiermee je hele LAN in feite weg.

Dus als je een oude NAS hebt met je gegevens op mag een hacker deze zomaar onklaar maken? Hopelijk heeft er niemand backup gegevens op staan dan.
Het is niet het eerste bedrijf dat gehacked worde en door exploits of niet gepatched systemen de backup onklaar gemaakt wordt.

Dat staat toch in het artikel?

v2 stamt uit 2006. Hoe lang moeten we oude troep blijven ondersteunen... v1 is al 9 jaar geleden gestorven.

Ze zouden ook een smb v1.x kunnen implementeren mocht die er ooit komen, die deze kwetsbaarheden niet heeft.

Wat is de logica dat ze het al in 10 hadden verwijderd maar nog niet in 11 ?

in win 10 zat het vgm nog wel maar stond het standaard uit.

Ik las smb dus als Super Mario Bros

Mocht tijd worden!

Want het zat je in de weg of je had er last van?

[Reactie gewijzigd door XfadeR op 20 april 2022 16:57]

Het is al 30 jaar oud en lek als een mandje...
Dus ja, dat soort meuk moet een keer verdwijnen

Het was al weg.

Het protocol werd al sinds 2017 niet meer geïnstalleerd op Windows 10 en Windows Server

Het enige verschil lijkt te zijn dat zeer eigenwijze mensen het toen nog handmatig konden installeren?

edit: Het artikel van tweakers is nogal slecht geschreven. De link naar Microsoft geeft een veel duidelijker overzicht wat er al verwijderd was en welke versies het nog hadden.

[Reactie gewijzigd door mjtdevries op 21 april 2022 10:09]

Geen expert in SMB (vanwege linux gebruik ik overal ssh voor) maar wordt dat over publieke netwerken gebruikt en is het dan goed te beveiligen met encryptie?

SMB is tegenhanger van NFS. Niet voor over het internet maar intern bij bedrijven gebruiken ze het op alle systemen.

Qua authenticatie/encryptie zit dat wel goed met de laatste versies (SMB3) (authenticatie via kerberos/domain).
In de praktijk zijn er al wel veel pijnlijke security vulnerabilities geweest, zeker in SMB1.
En via SMB kan je ook processen starten op andere systemen, waardoor SMB vulnerabilities vaak wormable zijn binnen het LAN.

Helder. En dan vermoedelijk via vpn tunnels over publieke netwerken stel ik me zo voor.

jep

Met windows server 2022 en windows 11 heb je SMB over QUIC
https://docs.microsoft.co...file-server/smb-over-quic

"SMB over QUIC offers an "SMB VPN" for telecommuters, mobile device users, and high security organizations. The server certificate creates a TLS 1.3-encrypted tunnel over the internet-friendly UDP port 443 instead of the legacy TCP port 445. All SMB traffic, including authentication and authorization within the tunnel is never exposed to the underlying network. SMB behaves normally within the QUIC tunnel, meaning the user experience doesn't change. SMB features like multichannel, signing, compression, continuous availability, directory leasing, and so on, work normally. "

Voor linux is samba de smb-tool: https://en.wikipedia.org/wiki/Samba_(software). Ze biedt smb2 sinds 2010.

Gezien hoe jong Windows 11 is, had het er natuurlijk nooit in mogen zitten.

Ik denk dat ze die fout nu gaan herstellen.

Edit: tweaker is nog steeds kapot. Dit is volgens mij toch echt on-topic! Zeker geen -1, maar ja.
En een comment als: "Mocht tijd worden!" krijgt '0'. Pffff.

[Reactie gewijzigd door Triblade_8472 op 20 april 2022 20:16]

dat al sinds 2017 niet meer standaard in Windows 10 en Windows Server werd geleverd.

het maakt nog altijd deel uit van windows 10 21h2. Het staat enkel niet meer standaard enabled, maar zit nog altijd mooi mee in de ISO/ESD

Voor alle duidelijkheid, het gaat om de client. De server was al een tijdje niet beschikbaar (gelukkig).

Als je verbinding probeer te maken vanuit je systeem naar een share, gaat het de hoogst mogelijke versie nemen. Home en Pro edities ondersteunen daarbij alle versie 1-3. Vanaf nu gaat enkel versie 2 en 3 werken. Heb je dus een share die enkel SMBv1, dan gaat die een fout geven. (vermoedelijk error 53)

Dat dacht ik ook.... Tot ik op mijn privé desktop zie dat de smb/cifs roles/features juist voor de server wel aan blijken te staan. Hierbij vraag ik mij af welke tool/installatie dat geflikt heeft.