7
Keine neuen Geräteinstallationen zulassen
Hallo zusammen
Ich bau hier gerade neue Clients für unser Netzwerk. Jetzt habe ich eine Frage zur unterbindung von zusätzlichen Geräteinstallationen durch die Nutzer.
Nach der installation müssen keine neuen Geräte hinzugefügt werden. (Sicher mal bei USB).
Die Tastatur befindet sich auf SP/2 und die Maus auf USB. Wie kann jetzt verhindert werden, dass kein USB-Stick, oder keine externe Festplatte mehr erkannt werden?
Gruss
Matthias
Ich bau hier gerade neue Clients für unser Netzwerk. Jetzt habe ich eine Frage zur unterbindung von zusätzlichen Geräteinstallationen durch die Nutzer.
Nach der installation müssen keine neuen Geräte hinzugefügt werden. (Sicher mal bei USB).
Die Tastatur befindet sich auf SP/2 und die Maus auf USB. Wie kann jetzt verhindert werden, dass kein USB-Stick, oder keine externe Festplatte mehr erkannt werden?
Gruss
Matthias
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 57085
Url: https://administrator.de/forum/keine-neuen-geraeteinstallationen-zulassen-57085.html
Ausgedruckt am: 24.12.2024 um 02:12 Uhr
7 Kommentare
Neuester Kommentar
Das wurde hier schon heiß besprochen:
Usb Stick sperren
Usb Stick sperren
OK Danke
habe wohl unter falschen Stichwörtern gesucht.
Gruss
habe wohl unter falschen Stichwörtern gesucht.
Gruss
hab dir mal ein howto aus der ct abgekupftert.
USB-Ports für neue Geräte sperren:
? %systemroot%\system32\drivers\usbstor.sys
Zu setzende Berechtigung: "SYSTEM" Zugriff "Verweigern"
Grundsätzliches
Dieses Beispiel kann auch für andere lokale Geräte (Floppy, Serielle + Parallele Schnittstelle, PS2 etc.) hergenommen werden. Es ist nichts anderes, als die Deaktivierung des Treibers für dieses Gerät. Es funktioniert ähnlich der "Zentralen Vergabe lokaler Berechtigungen" für den Bereich "Dienste" nur mit dem Unterschied, daß es für die Gerätetreiber keine vorhandene CSE gibt, die diesen Bereich steuert und auch keine Berechtigungen über die GUI vergeben werden können. Es ist also handarbeit angesagt.
Die Problematik also solche steckt im Detail. In dem Moment, wo der USB Stick (Gerätetreiber) per Richtlinie deaktiviert wird, ist er für keinen Benutzer am Rechner mehr zugänglich. Oftmals möchten aber die Administratoren dennoch Zugriff auf die lokalen Geräte haben. Dieser Weg ist beim Einsatz dieses Templates versperrt. Eine Auswahl nach Benutzergruppe ist nicht möglich.
Das Ausblenden von Laufwerksbuchstaben (nodrives) oder die Verweigerung des Zugriffs (noviewondrives) auf diese, welches über eine Erweiterung der schon vorhandenen Richtlinie möglich wäre, ist vom Aufwand her doch zu groß. Man kennt idR den Laufwerksbuchstaben vorher nicht und muss dann entweder alle ausblenden, oder alle ausser den zugelassenen, die z.B.: per Loginscript vergeben werden. Das bedeutet einen hohen administrativen Aufwand und wäre auch nur im Falle eine Wechseldatenträgers möglich, andere lokale Schnittstellen und Geräte sind mit dieser Richtlinie nicht zu erfassen.
Ein ganz wichtiger Punkt ist in diesem HowTo völlig außer Acht gelassen und führt es fast ad absurdum.
Vor lauter Freude über die Möglichkeit und Tools, den Zugriff auf USB Geräte zu erschweren, ist nicht berücksichtigt, daß es noch andere Möglichkeiten zum Anschluss externer Speichermedien gibt: Firewire, Parallelport, PCMCIA, div. Kamera-Speicherkarten und deren Lesegeräte ...
Diese Sicherheitslücke wird nicht durch die unten erstgenannten Freeware Lösungen abgedeckt.
Bordmittel
1.) Verwendung eines eigenen ADM Templates, das die Startart des Treibers regelt.
schnipp usb.adm -----------
CLASS MACHINE
CATEGORY "Dienste und Gerätetreiber"
POLICY "USB-Massenspeichertreiber"
KEYNAME "System\CurrentControlSet\Services\usbstor"
PART "Startzeitpnkt" DROPDOWNLIST
VALUENAME "Start"
ITEMLIST
NAME "Bootzeitpunkt" VALUE NUMERIC 0
NAME "Systemstart" VALUE NUMERIC 1
NAME "Automatisch" VALUE NUMERIC 2 DEFAULT
NAME "Manuell" VALUE NUMERIC 3
NAME "Deaktiviert" VALUE NUMERIC 4
END ITEMLIST
END PART
END POLICY
END CATEGORY
schnapp usb.adm -----------
2.) Erst mit Windows XP2 verfügbar: Den USB Stick schreibschützen, Reg-Eintrag als ADM Template:
schnipp usbwriteprotect.adm -----------
CLASS MACHINE
CATEGORY "USB"
POLICY "USB schreibschützen"
KEYNAME System\CurrentControlSet\Control\StorageDevicePolicies
VALUENAME WriteProtect
VALUEON 1 VALUEOFF 0
END POLICY
END CATEGORY
schnapp usbwriteprotect.adm -----------
Ehrlich gesagt ist der Sinn hier nicht ganz gegeben, denn dieses verhindert nur den "Datenklau" im Netzwerk, denn der USB Stick ist nur schreibgeschützt, aber da er auf "Read-Only" gesetzt ist trotzallem noch lesbar. Damit wird also das Mitbringen und Ausführen von unerwünschter Software im Netzwerk nicht verhindert.
Diese Lösungen lassen sich nicht sicher für Mitglieder der lokalen Administratoren regeln, da diese über den Geräte Manager in der Lage sind, den Treiber für ihre Sitzung zu starten. Beim nächsten Start wäre der Treiber zwar wieder deaktiviert, aber er lässt sich wie gesagt "nachstarten" und das Spiel beginnt von Neuem.
Der nächste Schritt ist dann das Setzen von Berechtigungen sowohl auf Datei~ als auch auf Registry-Ebene:
=> HKLM\System\CurrentControlSet\Services\usbstor Der Pfad zum Gerätetreiber in der Registry
=> %systemroot%\inf\usbstor.inf Die Treiber-Informationsdatei
=> %systemroot%\inf\usbstor.pnf Precompiled Informationsdatei
=> %systemroot%\system32\drivers\usbstor.sys Der Treiber an sich
Zu setzende Berechtigung: "SYSTEM" Zugriff "Verweigern"
Durch diese Einstellung wird die automatische Erkennung des USB Sticks (oder anderen Gerätes) verhindert. Dem Prozess des System, der im Hintergrund die Plug&Play Hardwareerkennung inkl. Auswahl des passenden Treibers ausführt, wird hiermit der Zugriff verweigert und der Treiber kann nicht gefunden werden.
Was allerdings nur funktioniert, solange der Treiber nicht schon einmal erkannt wurde und das Gerät nicht schon einaml angeschlossen war. Es hilft also nur bei der Erst-Installation. Ist das Gerät einmal installiert worden, findet die Suche nicht mehr statt und die Einstellung hat keinerlei Auswirkung auf das Gerät. Es funktioniert weiterhin (vorrausgesetzt der Treiber ist nicht deaktiviert). Dateiberechtigungen alleine reichen nicht aus.
Wie das Ganze zu integrieren wäre findet ihr im HowTo: "Zentralen Vergabe lokaler Berechtigungen"
Aber auch das bietet keinerlei Sicherheit, da ein lokaler Administrator am System die Berechtigungen für die Dauer seiner Sitzung wieder zurücksetzen könnte und wir haben wieder eine Art Loop, wie schon mit der Treiberdeaktivierung.
Als nächste Stufe käme dann das Umbenennen der Dateien, aber sind wir mal ehrlich, was bringt das?
Das Einzige, was damit gewonnen wäre ist, daß ich diejenigen Benutzer von dem Gerät ausgeschlossen habe, die überhaupt keine Ahnung haben, wie sie mit Berechtigungen umzugehen haben, bzw. noch nie den Besitz einer Datei übernommen haben. Oder wie sie Dateien in einem System austauschen können.
Ich gebe zu: Die Prozentzahl derjenigen die durch alle 3 Stufen kommen sinkt, aber letztlich ist es nicht zufrieden stellend, da immer ein Hintertürchen bleibt. Mit Bordmitteln ist dem nicht beizukommen, denn "Admin bleibt Admin" und dieser hat immer die Chance die erforderlichen Rechte am System zu erlangen.
Solange die Benutzer allerdings "Domänen-Benutzer" und am System ebenfalls nur "Benutzer" sind, bietet es wenigstens ein Mindestmass an Sicherheit.
Fazit: Dies ist keine Lösung wenn die Benutzer über Lokalen Administratoren Rechte verfügen.
Gruß Jörg
ich hab auch noch ein freewaretool. Dieses fährt den Rechner bei Anschluss eines neuen USB Gerätes automatisch herunter. Das Tool heisst USB Wächter Beta finde aber keinen aktuellen download mehr dafür. Kann dir bei intresse das tool ja auf eine tmp Mailadresse zumailen
Richtig gute Tools für den enterprise Bereich bietet u.a. auch http://www.utimaco.de/
Gruß Jörg
USB-Ports für neue Geräte sperren:
? %systemroot%\system32\drivers\usbstor.sys
Zu setzende Berechtigung: "SYSTEM" Zugriff "Verweigern"
Grundsätzliches
Dieses Beispiel kann auch für andere lokale Geräte (Floppy, Serielle + Parallele Schnittstelle, PS2 etc.) hergenommen werden. Es ist nichts anderes, als die Deaktivierung des Treibers für dieses Gerät. Es funktioniert ähnlich der "Zentralen Vergabe lokaler Berechtigungen" für den Bereich "Dienste" nur mit dem Unterschied, daß es für die Gerätetreiber keine vorhandene CSE gibt, die diesen Bereich steuert und auch keine Berechtigungen über die GUI vergeben werden können. Es ist also handarbeit angesagt.
Die Problematik also solche steckt im Detail. In dem Moment, wo der USB Stick (Gerätetreiber) per Richtlinie deaktiviert wird, ist er für keinen Benutzer am Rechner mehr zugänglich. Oftmals möchten aber die Administratoren dennoch Zugriff auf die lokalen Geräte haben. Dieser Weg ist beim Einsatz dieses Templates versperrt. Eine Auswahl nach Benutzergruppe ist nicht möglich.
Das Ausblenden von Laufwerksbuchstaben (nodrives) oder die Verweigerung des Zugriffs (noviewondrives) auf diese, welches über eine Erweiterung der schon vorhandenen Richtlinie möglich wäre, ist vom Aufwand her doch zu groß. Man kennt idR den Laufwerksbuchstaben vorher nicht und muss dann entweder alle ausblenden, oder alle ausser den zugelassenen, die z.B.: per Loginscript vergeben werden. Das bedeutet einen hohen administrativen Aufwand und wäre auch nur im Falle eine Wechseldatenträgers möglich, andere lokale Schnittstellen und Geräte sind mit dieser Richtlinie nicht zu erfassen.
Ein ganz wichtiger Punkt ist in diesem HowTo völlig außer Acht gelassen und führt es fast ad absurdum.
Vor lauter Freude über die Möglichkeit und Tools, den Zugriff auf USB Geräte zu erschweren, ist nicht berücksichtigt, daß es noch andere Möglichkeiten zum Anschluss externer Speichermedien gibt: Firewire, Parallelport, PCMCIA, div. Kamera-Speicherkarten und deren Lesegeräte ...
Diese Sicherheitslücke wird nicht durch die unten erstgenannten Freeware Lösungen abgedeckt.
Bordmittel
1.) Verwendung eines eigenen ADM Templates, das die Startart des Treibers regelt.
schnipp usb.adm -----------
CLASS MACHINE
CATEGORY "Dienste und Gerätetreiber"
POLICY "USB-Massenspeichertreiber"
KEYNAME "System\CurrentControlSet\Services\usbstor"
PART "Startzeitpnkt" DROPDOWNLIST
VALUENAME "Start"
ITEMLIST
NAME "Bootzeitpunkt" VALUE NUMERIC 0
NAME "Systemstart" VALUE NUMERIC 1
NAME "Automatisch" VALUE NUMERIC 2 DEFAULT
NAME "Manuell" VALUE NUMERIC 3
NAME "Deaktiviert" VALUE NUMERIC 4
END ITEMLIST
END PART
END POLICY
END CATEGORY
schnapp usb.adm -----------
2.) Erst mit Windows XP2 verfügbar: Den USB Stick schreibschützen, Reg-Eintrag als ADM Template:
schnipp usbwriteprotect.adm -----------
CLASS MACHINE
CATEGORY "USB"
POLICY "USB schreibschützen"
KEYNAME System\CurrentControlSet\Control\StorageDevicePolicies
VALUENAME WriteProtect
VALUEON 1 VALUEOFF 0
END POLICY
END CATEGORY
schnapp usbwriteprotect.adm -----------
Ehrlich gesagt ist der Sinn hier nicht ganz gegeben, denn dieses verhindert nur den "Datenklau" im Netzwerk, denn der USB Stick ist nur schreibgeschützt, aber da er auf "Read-Only" gesetzt ist trotzallem noch lesbar. Damit wird also das Mitbringen und Ausführen von unerwünschter Software im Netzwerk nicht verhindert.
Diese Lösungen lassen sich nicht sicher für Mitglieder der lokalen Administratoren regeln, da diese über den Geräte Manager in der Lage sind, den Treiber für ihre Sitzung zu starten. Beim nächsten Start wäre der Treiber zwar wieder deaktiviert, aber er lässt sich wie gesagt "nachstarten" und das Spiel beginnt von Neuem.
Der nächste Schritt ist dann das Setzen von Berechtigungen sowohl auf Datei~ als auch auf Registry-Ebene:
=> HKLM\System\CurrentControlSet\Services\usbstor Der Pfad zum Gerätetreiber in der Registry
=> %systemroot%\inf\usbstor.inf Die Treiber-Informationsdatei
=> %systemroot%\inf\usbstor.pnf Precompiled Informationsdatei
=> %systemroot%\system32\drivers\usbstor.sys Der Treiber an sich
Zu setzende Berechtigung: "SYSTEM" Zugriff "Verweigern"
Durch diese Einstellung wird die automatische Erkennung des USB Sticks (oder anderen Gerätes) verhindert. Dem Prozess des System, der im Hintergrund die Plug&Play Hardwareerkennung inkl. Auswahl des passenden Treibers ausführt, wird hiermit der Zugriff verweigert und der Treiber kann nicht gefunden werden.
Was allerdings nur funktioniert, solange der Treiber nicht schon einmal erkannt wurde und das Gerät nicht schon einaml angeschlossen war. Es hilft also nur bei der Erst-Installation. Ist das Gerät einmal installiert worden, findet die Suche nicht mehr statt und die Einstellung hat keinerlei Auswirkung auf das Gerät. Es funktioniert weiterhin (vorrausgesetzt der Treiber ist nicht deaktiviert). Dateiberechtigungen alleine reichen nicht aus.
Wie das Ganze zu integrieren wäre findet ihr im HowTo: "Zentralen Vergabe lokaler Berechtigungen"
Aber auch das bietet keinerlei Sicherheit, da ein lokaler Administrator am System die Berechtigungen für die Dauer seiner Sitzung wieder zurücksetzen könnte und wir haben wieder eine Art Loop, wie schon mit der Treiberdeaktivierung.
Als nächste Stufe käme dann das Umbenennen der Dateien, aber sind wir mal ehrlich, was bringt das?
Das Einzige, was damit gewonnen wäre ist, daß ich diejenigen Benutzer von dem Gerät ausgeschlossen habe, die überhaupt keine Ahnung haben, wie sie mit Berechtigungen umzugehen haben, bzw. noch nie den Besitz einer Datei übernommen haben. Oder wie sie Dateien in einem System austauschen können.
Ich gebe zu: Die Prozentzahl derjenigen die durch alle 3 Stufen kommen sinkt, aber letztlich ist es nicht zufrieden stellend, da immer ein Hintertürchen bleibt. Mit Bordmitteln ist dem nicht beizukommen, denn "Admin bleibt Admin" und dieser hat immer die Chance die erforderlichen Rechte am System zu erlangen.
Solange die Benutzer allerdings "Domänen-Benutzer" und am System ebenfalls nur "Benutzer" sind, bietet es wenigstens ein Mindestmass an Sicherheit.
Fazit: Dies ist keine Lösung wenn die Benutzer über Lokalen Administratoren Rechte verfügen.
Gruß Jörg
ich hab auch noch ein freewaretool. Dieses fährt den Rechner bei Anschluss eines neuen USB Gerätes automatisch herunter. Das Tool heisst USB Wächter Beta finde aber keinen aktuellen download mehr dafür. Kann dir bei intresse das tool ja auf eine tmp Mailadresse zumailen
Richtig gute Tools für den enterprise Bereich bietet u.a. auch http://www.utimaco.de/
Gruß Jörg
Hallo
Das ist ja fast eine Wissenschaft. Es muss nicht 100% sicher sein. Ein ganz einfaches Tool würde reichen. Einfach USB-Massenspeicher nicht beachten. FireWire habe ich nicht.
Gut wäre auch wenn definiert werden kann, welche Geräte genau zugelassen werden und neue werden nicht mehr beachtet.
Gruss
Das ist ja fast eine Wissenschaft. Es muss nicht 100% sicher sein. Ein ganz einfaches Tool würde reichen. Einfach USB-Massenspeicher nicht beachten. FireWire habe ich nicht.
Gut wäre auch wenn definiert werden kann, welche Geräte genau zugelassen werden und neue werden nicht mehr beachtet.
Gruss
kannst ja aber auch in den lokalen Eisntellungen unter Wechseldatenträger das ganze "verweigern", sollte bei euch kein AD vorhanden sein.
Gruß
Freaky
Gruß
Freaky
hi
ihr könnt auch einfach die "newdev.dll" aus dem Ordner C:\WINDOWS\system32 löschen, dann können und werden keine neuen Geräte erkannt bzw. installiert.
Vielleicht vorher eine Kopie ziehen und sichern, man weiß ja nie.
cu
DSL_JUNKIE
ihr könnt auch einfach die "newdev.dll" aus dem Ordner C:\WINDOWS\system32 löschen, dann können und werden keine neuen Geräte erkannt bzw. installiert.
Vielleicht vorher eine Kopie ziehen und sichern, man weiß ja nie.
cu
DSL_JUNKIE
Hallo
danke für die Antowrt, werde das einmal probieren.
Gruss
danke für die Antowrt, werde das einmal probieren.
Gruss
