Waarom is het slecht om netwerkstations in Windows te mappen?

Ik denk dat de belangrijkste reden om netwerkschijven niet in kaart te brengen is dat de beheerders geen zin hebben in de hoofdbrekens van het bijhouden van een index van een eindig aantal schijfletters naast de netwerkpaden. Er kunnen bijvoorbeeld te veel gemeenschappelijk gebruikte netwerkshares zijn om er allemaal schijfletters aan toe te kennen, en in een grote organisatie zal niet iedereen toegang hebben tot alle dezelfde shares. Share namen zijn ook beschrijvender en mogelijk minder dubbelzinnig dan schijfletters (later meer over dubbelzinnigheid).

Ten tweede kun je schijfletter-botsingen tegenkomen. Als iemands PC een geheugenkaartlezer heeft, kan die vier of meer schijfletters opslokken. A en B zijn meestal gereserveerd voor de floppydrives van de vorige eeuw, en C en D zijn meestal gereserveerd voor de harde schijf en de optische drive, dus de kaartlezer zal E, F, G, en H gebruiken. Als een van je netwerkdrives normaal gesproken is toegewezen aan H: via een logon script, zal deze arme persoon ofwel niet in staat zijn om de kaartlezer’s H: drive te gebruiken, of niet in staat zijn om de netwerkdrive te mounten.

Tenzij iemand binnen de organisatie verantwoordelijk is voor het toewijzen van schijfletters voor specifieke doeleinden, kunnen de netwerkschijven ook voor veel verwarring zorgen. Stel bijvoorbeeld dat u station S: toewijst aan de share met de setup-programma’s voor al uw software met sitelicentie, en iemand anders wijst S: toe aan de gedeelde drive waar ze allerlei gedeelde documenten neerzetten. Wanneer je probeert uit te leggen hoe je bepaalde software installeert, zeg je dat ze hun S: schijf moeten openen en het setup programma voor Microsoft Office moeten vinden, maar alles wat ze kunnen vinden is een map genaamd office, die een hoop verschillende bestanden bevat die iemand daar heeft neergezet voor een tijdelijke bestandsoverdracht. Het kost je misschien 5 of 10 minuten om de verwarring op te lossen.

Er zijn ook een aantal potentiële prestatieproblemen als een server uitvalt of als een machine van het netwerk gehaald wordt. Als je bijvoorbeeld netwerkschijven op een machine mapt, en die machine dan van het netwerk haalt (misschien is het een laptop), dan kan het lijken alsof de machine bij het inloggen blijft hangen terwijl Windows tevergeefs probeert de ontbrekende netwerkschijven te mounten.

Aan de andere kant heb ik bij oudere versies van Windows gemerkt dat bestandsoverdrachten van of naar een gemapt netwerkstation vaak veel sneller gaan dan wanneer je naar de netwerkmap bladert en dezelfde bestandsoverdracht uitvoert - in dat geval zouden de meeste mensen de voorkeur geven aan het mappen van netwerkstations.

Het eenvoudige antwoord is dat het geen slechte zaak is. Netwerkschijven zijn volkomen veilig om als schijfstations te gebruiken.

Het bijgeloof komt voort uit het feit dat je geen vreemde (d.w.z. Internet) schijven als lokale schijven zou moeten mappen, omdat bestanden die geopend worden vanaf gemapte schijven geopend worden met de “lokale” zone, wat ze over het algemeen minder bescherming biedt - en als de bestanden werkelijk van het Internet komen is dat een vermindering van de veiligheid.

Als, zoals ik vermoed, je eigenlijk int ra net netwerk drives mapt, dan is het openen van de mappen als mapped drives precies even veilig als ze benaderen via hun netwerk pad namen. Het enige verschil is dat ze in kaart brengen handiger is.

In mijn ervaring draait het meestal om slecht geschreven software.

Als persoon A werkt aan een set bestanden die zijn toegewezen aan G:, en dan probeert persoon B dezelfde set bestanden te openen met hetzelfde pad toegewezen aan H:, dan gaat het mis.

Als je UNC paden gebruikt, dan zal alles goed gaan, aangenomen dat de computers van persoon A en persoon B allebei het gedeelde punt kunnen zien.

• *

Natuurlijk, de ideale oplossing is om software te gebruiken die bestandsrelaties niet opslaat met behulp van absolute paden, maar dat is niet iets wat je altijd in de hand hebt.

Veel software in de CAD/CAM-markt is slecht geschreven, en werkt nauwelijks. Omdat de markt vrij klein is, is er weinig concurrentiedruk. Ik ken tenminste één softwarepakket dat al de laatste 5 grote releases problemen heeft met absolute paden, en die zijn nog steeds niet opgelost, ondanks dat de problemen aan het bedrijf zijn gemeld.

Waar ik werk hebben we ernstige problemen gehad met netwerkschijven omdat Windows er soms geen verbinding mee maakt, en het lijkt een netwerkschijf niet automatisch te verbinden wanneer een programma er toegang toe probeert te krijgen.

Minstens een half dozijn keer heeft een gebruiker van de boekhouding gebeld omdat ze dezelfde foutmelding kreeg. Dat komt omdat ze programma X heeft geopend, dat een bestand gebruikt op netwerkstation Y:, en dat om een of andere ondoorgrondelijke reden niet is aangesloten.

Ik betwijfel of de IT jongens zich zorgen maken over één gebruiker die een netwerk schijf in kaart brengt, ze maken zich eerder zorgen over honderd of duizend gebruikers. Bijvoorbeeld, als een aantal hosts op hetzelfde moment de zoekindexering van een netwerkschijf of schijven starten, wat voor effect heeft dat op alle anderen die het netwerk proberen te gebruiken? Wanneer een netwerkschijf onvermijdelijk offline wordt gehaald, zullen dan honderden machines vastlopen totdat het besturingssysteem het opgeeft en de schijfmapping laat vallen? Zullen PC’s langzamer opstarten of helemaal niet meer opstarten als de verbindingen met de gemapte schijven niet meer hersteld kunnen worden?

Een probleem met de syntaxis \server is dat commando vensters er niet naar kunnen cd'en. Als u admin-rechten hebt en geen stationsletter wilt gebruiken, kunt u het commando mklink gebruiken om stations te mounten naar een directory in plaats van een stationsletter. De directory Home mag niet bestaan.

mklink /d “c:\Drives\Home” “\server\HomeFolder\user1”

Deze map is door alles te gebruiken.

Monteren naar een drive leter kan slecht zijn omdat het mogelijk is dat het verandert naar een ander koppelpunt. Dan ben je aan het lezen en schrijven naar iets wat je niet verwacht. Als uitvoerbare bestanden van een mount punt veranderen, kunnen ze virussen bevatten.

Mijn oplossing vereist admin rechten, dus als je niet met admin rechten draait, is het veiliger omdat een ander programma het niet op jou kan veranderen zonder admin rechten.

Een aantal software pakketten, waaronder verschillende versies van Microsoft Visual Studio en CMS Bounceback, werken alleen met schijfletters en niet met absolute paden. Gegeven deze beperking, vereist het gebruik van dergelijke software dat u schijfletters definieert - u hebt geen keuze. Maar Windows maakt dit niet erg gemakkelijk omdat het lijkt te vragen om een gebruikers ID en wachtwoord, maar slechts één gebruikers ID en wachtwoord is toegestaan in Windows voor alle verbindingen met een netwerk apparaat (b.v. meerdere schijven en printers).

Hier is een goede reden:

Windows (tenminste XP) ondersteunt geen bestandspaden met meer dan 256 tekens. Mapping stelt iemand in staat een bestand toe te voegen waar dat anders niet mogelijk zou zijn, door het pad in te korten. Dan heb je een programma dat door alle bestanden en mappen navigeert, en niet op de hoogte is van de mapping. Zonder de mapping, heeft het bestaande bestand een padlengte van meer dan 256. Het programma crasht.

Praat maar eens met de honderden IT-consultants die nu te maken hebben met de recente Zero-day uitbraak van “CryptoLocker” en je zult je snel realiseren dat gemapte schijven op een lokale computer die geïnfecteerd raakt, enorme schade kunnen aanrichten aan gegevens op de server, via de gemapte schijf.

Specifiek:

“CryptoLocker zal ook toegang krijgen tot gemapte netwerk drives waar de huidige gebruiker schrijftoegang tot heeft, en deze versleutelen. Het zal niet aanvallen eenvoudige server aandelen, alleen in kaart gebrachte stations. ”

Er zijn dus duidelijk veiligheidsproblemen met het gebruik van mapped drives in deze tijd van altijd aanwezige en nieuw ontdekte zero-day malware die gebruikers regelmatig treft.

We hebben alle gemapte drives in ons LAN geëlimineerd en gebruiken in plaats daarvan “network shares”.

Een paar redenen om geen mapped drives te gebruiken:

1) Ze nemen bronnen in beslag op zowel de lokale machine met de gemapte schijf als op de netwerkbronnen. Lokale toepassingen kunnen traag worden omdat de lokale computer de inhoud van de gemapte schijf moet lezen als de toepassing wordt gestart of als het systeem wordt opgestart. Probeer het maar eens. Koppel een aantal stations aan elkaar en start Excel. Maak de mapping ongedaan en probeer het opnieuw.

2) Het verplaatsen van uw applicatie naar een nieuwe omgeving zal vervelend zijn. In het geval van een disaster recovery, verhuizing naar een krachtiger machine, of als een andere ontwikkelaar uw applicatie overneemt. Als de nieuwe omgeving geen mapped drives toestaat of de drive letters zijn anders gemapped dan is iemand tijd kwijt met het herschrijven van code. De tijd die wordt bespaard aan de voorkant zal meer zijn dan verloren aan het repareren ervan.

Gemapte stations zijn sneller als u grote hoeveelheden bestanden manipuleert. Windows verifieert uw toegang eenmaal met een gemapt station, en laat dan de bestandsinteracties plaatsvinden. UNC paden worden door Windows geverifieerd voor elk bestand dat wordt geopend. Het authenticatieproces zou dus duizenden keren gebeuren als u duizenden bestanden onder een UNC-pad zou manipuleren. Mapped Drive - Eenmaal authenticeren UNC - Elke keer dat een bestand wordt benaderd, wordt geauthenticeerd.

Dit kan gevolgen hebben voor iets simpels als het kopiëren van bestanden. Mapped drives zullen altijd sneller zijn; merkbaar bij grote aantallen bestanden.

Bepaalde wijdverspreide virussen en malware maken gebruik van gemapte schijven. Dat is een goede reden om ze niet te gebruiken.

Een reden om drive mapping te beperken zou zijn e-mail virussen (zip of exe bestanden geopend door enigszins “dichte” gebruikers) zoals Cryptolocker die alle bestanden op lokale en gemapte drives zal alfabetiseren en versleutelen. Het maakt (met name) geen onderscheid op basis van drives. Wij werden getroffen, en konden herstellen met behulp van backups van de server(s), maar natuurlijk waren de lokale bestanden “toast”.

Ik weet dat het een oude draad is, maar ik zou niet zeggen dat ze volkomen veilig zijn. We hebben gemapte schijven verwijderd vanwege de veiligheidsrisico’s. Veel virussen proberen zich te verspreiden over drives. Ze verspreiden zich echter niet over snelkoppelingen die naar DFS shares wijzen. Iets om in gedachten te houden…

In verband met de crypto/ransomware overwegingen, Locky is een voorbeeld van ransomware die zich kan verspreiden via UNC paden, maar ook via gemapte schijfletters. Als je je zorgen maakt over netwerkstations versus UNC paden vanwege de mogelijkheid van ransomware aanvallen, begrijp dan dat het slechts tegen enkele beschermt.

Er zijn verschillende manieren om ransomware-aanvallen te detecteren/voorkomen - en het is over het algemeen aan te raden om meerdere beschermingsmethoden te gebruiken: bescherm het netwerk, bescherm het eindpunt, en zorg voor een robuust back-up regime. Persoonlijk gebruik ik Sophos InterceptX als anti-ransomware oplossing op het eindpunt, een Cisco ASA (met IPS) firewall, ShadowProtect voor back-up en gebruik ik gemapte netwerkschijven waar dat administratief zinvol is.

Disclaimer: Ik ben een Sophos Certified Architect. Hoewel ik niet voor Sophos werk, vind ik hun technologie goed. Ik werk ook voor een MSP, en dat is de technologie waar we voor gekozen hebben na onderzoek van de verschillende opties die in Australië beschikbaar zijn.

Bewerkt zoals gevraagd om meer informatie te geven voor de tweede paragraaf. Ook spreek ik Australisch, geen Engels, de grammatica is iets anders en sommige woorden worden anders gespeld (het is Colour, niet Color, en laat me niet eens beginnen over cantaloupe).

Ik hou er niet van om gemapte stations te gebruiken omdat ik verschillende netwerkbronnen niet vaak gebruik en ik nooit het volledige adres voor anderen kan vinden om te gebruiken. Het gebruik van snelkoppelingen stelt me ook in staat om gemakkelijk hogerop te komen in de directory. Als de enige reden om stations te mappen de limiet van 256 karakters is, dan is dat een spijtig excuus om al die bestandslocatie details te verliezen.

Gemapte schijven zijn gevaarlijk! In de afgelopen jaren, met de toename van ransomware, heb ik waar mogelijk ‘mapped drives’ verwijderd. Ransomware richt zich op alle DRIVE LETTERS en niet alleen op lokale data. Dus hoewel je veilig bent zolang je redundante back-ups houdt, is het nog steeds een hoofdpijn om te maken te krijgen met zo'n datalek.

Als je in een zakelijke omgeving bent (het primaire doelwit van ransomware), en als je kunt, verwijder dan de gemapte schijven!!!

Bepaalde ransomware virussen, zoals de CryptoWall familie, zoeken naar elke gemapte drive en infecteren die drives. Als de netwerkshare echter UNC gebruikt en geen stationsletter, dan infecteren deze virussen de share niet.

De nummer 1 reden waarom je dit niet zou willen doen is dat ransomware geen toegang heeft tot een UNC pad, maar schijfletters zijn eerlijk spel. Als je wilt dat je netwerk share cryptolocked is, ga dan gerust door met het toewijzen van schijfletters.

Ik zie persoonlijk het voordeel niet van driveletters en vind de UNC paden echt eenvoudiger, omdat ik me nooit zorgen hoef te maken over het toewijzen van driveletters, zeker niet na het veranderen van login wachtwoorden. U kunt snelkoppelingen maken die zich niet anders gedragen dan stationsletters en u kunt die snelkoppelingen toevoegen aan Windows Explorer.

Een netwerkschijf is een goede manier om bronnen te delen, maar ik ben het er niet mee eens dat homedirectories op een deelbare netwerkschijf worden gezet. Dat is gewoon overduidelijk dom. De meeste applicaties gebruiken je home directory als plaats om specifieke applicatie-instellingen voor gebruikers op te slaan. Als IT nog een hoofdpijn wil (alsof ze nog niet genoeg hebben om mee om te gaan), dan kan het vastleggen van applicatie afhankelijkheden voor gebruikers binnen het netwerk een pijnpunt zijn dat ze aan hun zak met problemen kunnen toevoegen. Deze problemen kunnen zich opstapelen in een omgeving waar veel van dergelijke toepassingen worden gebruikt en hun afhankelijkheden en vereisten veranderen. Ten eerste kan het werk voor gebruikers op het netwerk worden belemmerd en verliest het bedrijf geld en tijd op basis van lage productiviteitsniveaus. Dat is iets dat niet mag worden geriskeerd. Ten tweede brengen sommige organisaties de home drive van gebruikers op het netwerk in kaart om te controleren wat er op staat. De overheid doet dat veel als onderdeel van hun eis. Het draagt ook bij aan het probleem van thuis kunnen werken. Als je connectiviteit via VP problemen heeft met je applicatie die op afstand werkt via een VPN sessie, waar je je applicatie uitvoert die een afhankelijkheid vereist van je netwerk gemapte home drive en de drive mapping faalt, dan ben je de pineut.

Persoonlijk denk ik dat het alleen zou moeten worden gedaan om goede redenen, maar niet tot het punt waar het de productiviteit belemmert en de bottom line van het bedrijf beïnvloedt.