USB STICKS per Richtlinie deaktivieren


a) Grundsätzliches
 b) mit Bordmitteln
 c) 3rd Party Alternativen



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.



3rd Party Alternativen


1. USB-Wächter.
Der USB Wächter ist eine "Fummel und Bastellösung" von der cīt http://www.heise.de/ct/ftp/03/08/190/
Die Leute von der cīt haben ein VB Script geschrieben, daß die Geräte der USB Schnittstelle überwacht. Das Script läuft im Hintergrund und entscheidet anhand einer .cfg Datei über die zugelassenen Geräte. Zum Thema Sicherheit sei nur soviel gesagt: Einen Prozess zu killen ist wohl eine der leichtesten Übungen ...

2. USB Wächter
Ähnlicher Name wie unter 1. aber anderer Entwickler. http://forum.trinit-soft.de/viewforum.php?f=10
Ist auf jeden Fall die bessere Alternative, verglichen mit dem Script der cīt, da der USB Wächter von Martin Eckes als Dienst konfiguriert ist und eine bequeme GUI bietet, welche der aktuell an USB angeschlossenen Geräte erlaubt sind. Natürlich obliegt auch in diesem Fall dem Administrator die Konfiguration.

3. Drive Lock
Kostenpflichtige Lösung von Centertools http://www.centertools.de/

4. DeviceLock
Kostenpflichtige Lösung von SmartLine http://www.protect-me.com/de/dl/

5. Sanctuary Device Control (ehemals SecureNT)
Kostenpflichtige Lösung von SecureWave  http://www.securewave.com/


Zu den drei letztgenannten möchte ich keine Wertung abgeben. Es sei nur soviel angemerkt, dass sie sich in dieser Reihenfolge im Funktionsumfang, Sicherheit, Verwaltbarkeit und auch im Preis steigern.


(c) 2003 - heute, Mark Heitbrink, weitere Informationen unter WebSite-Info\Copyright