/build/static/layout/Breadcrumb_cap_w.png

USB Enable/Disable scripting

We have just setup our K1000 and are trying to see if it is something we can utilize. We currently use GPO and ESET to block the use of USB drives but I have been told that the K1000 might be a better option that allows more of a fine tuned control over that.


Is there a way to block USB based on the type of device rather than just as say a storage drive? It would be nice to be able to block thumb drives but allow cameras as we need to use them and it feels a bit unsecure to enable USB devices just for that, it tends to lead to someone loading a virus ridden thumb drive.


0 Comments   [ + ] Show comments

Answers (2)

Posted by: ewoywood 3 years ago
White Belt
0

Hi Everybody.

I am in the same problem, and maybe i'm on the way to resolve it.


First: Changing registry key



When we apply the modification on the registry key, it works, but:

- if the device is connected, the changes applies on reconecting the device again.
- if the machine is restarted and the device is reconnected, it will be possible to access it (access on first logon plugin), until the device is reconected again.

Microsoft says we must remove permissions directly on
%windir%\inf\usbstor.inf   and
%windir%\inf\usbstor.PNF
to especified users.

In PowerShell exist "Get-ACL" and "Set-ACL" commands,

the first one, list the existent permissions of the file

PS C:\Windows\system32> get-acl $env:windir\inf\usbstor.inf | fl
Path   : Microsoft.PowerShell.Core\FileSystem::C:\Windows\inf\usbstor.inf
Owner  : NT SERVICE\TrustedInstaller
Group  : NT SERVICE\TrustedInstaller
Access : NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administradores Allow  ReadAndExecute, Synchronize
         BUILTIN\Usuarios Allow  ReadAndExecute, Synchronize
         NT SERVICE\TrustedInstaller Allow  FullControl


the second one, applies the permissions.

i am stucked in this point, because i want to apply to "all users" but "NT Authority\System" is wich KACE uses to run scripts,
so if i apply a blocking permission, then will be not possible to restore permissions again... isnt?



by the way, the app "SUBINACL" doesnt work on Windows 10, sadly.

i paste the help of Powershell Set-ACL command to share with you.


Thanks A Lot, Community, in advance.

- - - - - - - - - - - - - - - - - - - - - - 

PS C:\Windows\system32> get-help Set-Acl -Examples
NOMBRE
    Set-Acl
    
SINOPSIS
    Changes the security descriptor of a specified item, such as a file or a registry key.
 

  
    Example 1: Copy a security descriptor from one file to another
    
    $DogACL = Get-Acl -Path "C:\Dog.txt"
    Set-Acl -Path "C:\Cat.txt" -AclObject $DogACL
    
    These commands copy the values from the security descriptor of the Dog.txt file to the security descriptor of the Cat.txt file. When the commands complete, the security descriptors of the Dog.txt and Cat.txt files are identical.
    
    The first command uses the `Get-Acl` cmdlet to get the security descriptor of the Dog.txt file. The assignment operator (`=`) stores the security descriptor in the value of the $DogACL variable.
    
    The second command uses `Set-Acl` to change the values in the ACL of Cat.txt to the values in `$DogACL`.
    The value of the Path parameter is the path to the Cat.txt file. The value of the AclObject parameter is the model ACL, in this case, the ACL of Dog.txt  as saved in the `$DogACL` variable. 



Example 2: Use the pipeline operator to pass a descriptor --
    
    Get-Acl -Path "C:\Dog.txt" | Set-Acl -Path "C:\Cat.txt"
    
    This command is almost the same as the command in the previous example, except that it uses a pipeline operator (`|`) to send the security descriptor from a `Get-Acl` command to a `Set-Acl` command.
    
    The first command uses the `Get-Acl` cmdlet to get the security descriptor of the Dog.txt file. The pipeline operator (`|`) passes an object that represents the Dog.txt security descriptor to the `Set-Acl` cmdlet.
    
    The second command uses `Set-Acl` to apply the security descriptor of Dog.txt to Cat.txt. When the command completes, the ACLs of the Dog.txt and Cat.txt files are identical.



 Example 3: Apply a security descriptor to multiple files ---
    
    $NewAcl = Get-Acl File0.txt
    Get-ChildItem -Path "C:\temp" -Recurse -Include "*.txt" -Force | Set-Acl -AclObject $NewAcl
    
    These commands apply the security descriptors in the File0.txt file to all text files in the `C:\Temp` directory and all of its subdirectories.
    
    The first command gets the security descriptor of the File0.txt file in the current directory and uses the assignment operator (`=`) to store it in the `$NewACL` variable.
    
    The first command in the pipeline uses the Get-ChildItem cmdlet to get all of the text files in the `C:\Temp` directory. The Recurse parameter extends the command to all subdirectories of `C:\temp`. The Include parameter limits the files retrieved to those with the `.txt` file name extension. The Force parameter gets hidden files, which would otherwise be excluded. (You cannot use `c:\temp\ .txt`, because the Recurse * parameter works on directories, not on files.)
    
    The pipeline operator (`|`) sends the objects representing the retrieved files to the `Set-Acl` cmdlet, which applies the security descriptor in the AclObject parameter to all of the files in the pipeline.
    
    In practice, it is best to use the WhatIf parameter with all `Set-Acl` commands that can affect more than one item. In this case, the second command in the pipeline would be `Set-Acl -AclObject $NewAcl -WhatIf`. This command lists the files that would be affected by the command. After reviewing the result, you can run the command again without the WhatIf parameter.   



Example 4: Disable inheritance and preserve inherited access rules
    
    $NewAcl = Get-Acl -Path "C:\Pets\Dog.txt"
    $isProtected = $true
    $preserveInheritance = $true
    $NewAcl.SetAccessRuleProtection($isProtected, $preserveInheritance)
    Set-Acl -Path "C:\Pets\Dog.txt" -AclObject $NewAcl
    
    These commands is will disable access inheritance from parent folders, while still preserving the existing inherited access rules.
    
    The first command uses the `Get-Acl` cmdlet to get the security descriptor of the Dog.txt file.
    
    Next, variables are created to convert the inherited access rules to explicit access rules. To protect the access rules associated with this from inheritance, set the `$isProtected` variable to `$true`.to allow inheritance, set `$isProtected` to `$false`. For more information, see set access rule protection (/dotnet/api/system.security.accesscontrol.objectsecurity.setaccessruleprotection). The `$preserveInheritance` variable set to `$true` to preserve inherited access rules; false to remove inherited access rules. Then the access rule protection is updated using the SetAccessRuleProtection() method.
    
    The last command uses `Set-Acl` to apply the security descriptor of to Dog.txt. When the command completes, the ACLs of the Dog.txt that were inherited from the Pets folder will be applied directly to Dog.txt, and new access policies added to Pets will not change the access to Dog.txt.


Example 5: Grant Administrators Full Control of the file ---
    
    $NewAcl = Get-Acl -Path "C:\Pets\Dog.txt"
    # Set properties
    $identity = "BUILTIN\Administrators"
    $fileSystemRights = "FullControl"
    $type = "Allow"
    # Create new rule
    $fileSystemAccessRuleArgumentList = $identity, $fileSystemRights, $type
    $fileSystemAccessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $fileSystemAccessRuleArgumentList
    # Apply new rule
    $NewAcl.SetAccessRule($fileSystemAccessRule)
    Set-Acl -Path "C:\Pets\Dog.txt" -AclObject $NewAcl
    
    This command will grant the BUILTIN\Administrators group Full control of the Dog.txt file.
    
    The first command uses the `Get-Acl` cmdlet to get the security descriptor of the Dog.txt file.
    
    Next variables are created to grant the BUILTIN\Administrators group full control of the Dog.txt file. The `$identity` variable set to the name of a user account (/dotnet/api/system.security.accesscontrol.filesystemaccessrule.-ctor). The `$fileSystemRights` variable set to FullControl, and can be any one of  the FileSystemRights (/dotnet/api/system.security.accesscontrol.filesystemrights)values that specifies the type of operation associated with the access rule. The `$type` variable set to "Allow" to specifies whether to allow or deny the operation. The `$fileSystemAccessRuleArgumentList` variable is an  argument list is to be passed when making the new FileSystemAccessRule object. Then a new FileSystemAccessRule object is created, and the  FileSystemAccessRule object is passed to the SetAccessRule() method, adds the new access rule.
        The last command uses `Set-Acl` to apply the security descriptor of to Dog.txt. When the command completes, the BUILTIN\Administrators group will have full control of the Dog.txt.


Posted by: jimmysmitty 8 years ago
White Belt
0

Well after a bit of digging, and confirmation from our KACE trainer that we can't do it, I did find this:

https://technet.microsoft.com/en-us/library/cc731387(v=ws.10).aspx

If anyone happens to need the ability to block USB but allow specific devices this will work the best as it allows more precise control where as the USB Enable/Disable in the K1000 is just a blank block of the USBSTOR in the registry so it blocks anything that uses that to load such as flash drives, cameras or external HDDs.

Hope this helps others.


Comments:
  • good work on finding an answer to your question. I have in the past used Devmgr to disable devices, but you need to know its details to block it. The KACE approach seems a little basic. - Badger 8 years ago
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ