This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Configuration Protection USB 3.0 Root HUB blocked

Hi again

On our new laptops USB 3.0 Root HUB is blocked by "configuration protection". How can i unblock it ?

schgu

:17993


This thread was automatically locked due to age.
  • Hello everyone,

    We are experiencing an identical problem on some new model laptops we are testing with port configuration.

    Our USB 3 port ID's are IUSB3\ROOT_HUB30 and as previously mentioned, port auditor does not see them listed whatsoever, and they cant be added as "IUSB" is not a valid port according to the management center. We are using Sageguard 6.00.1.31.

    Did anyone ever come up with a solution to this to get the ports functioning?

    Thanks

    Daniel

    :35121
  • Hi Daniel,

    I did manage to get this working but we had to change our whole Configuration Protection policy settings. - We were advised incorrectly on how CP should have been configured.

    Can I ask what you're trying to achieve? Are you simply trying to block unauthorised "devices" etc., or are you trying to block "ports" too?

    Regards,

    John

    :35131
  • Hi John,

    The CP is set to lock down quite a few aspects of laptops around our company.

    Under "Port Control", "Physical Ports", the USB field is set to restrict (I am guessing this is where the USB3 hub exists).

    We then have a white list which we can explicitly define what devices and hubs are allowed.

    So to answer your question we are blocking ports and only allowing certain devices.

    What parts of your CP did you have to modify to get it working?

    Regards

    Daniel

    :35137
  • Hi Daniel, RL,

    this is a known issue (Configuration Protection blocked the USB HUB although no policy might be applied yet, because the hardware ID of the USB ROOT HUB does not start with "USB\..." but with "IUSB\..." or "NUSB\...") and we're currently working on a public Knowledge Base Article where we provide a solution to the issue.

    If you need an immediate solution, please contact Sophos support, and refer to KBA 118467 (currently work in process). Support will provide you with a new System Policy for your Configuration Protection client that should resolve the problem immediately.

    The baseline policy unblocks USB ROOT HUBS starting with the following device IDs:

    - "IUSB3\ROOT_HUB30"

    - "NUSB3\ROOT_HUB30"
    - "ENUSB3\ROOT_HUB30"

    KBA is planned to go live in the next days.

    Hope that helps,

    Chris

    :35143
  • Hi Daniel,

    We only really needed to block devices, not ports, so we changed our CP policies to:

    • Port Control > Physical ports: Allow
    • Storage Control > : Restrict

    This then opened up the ports but still blocked the devices, unless they were whitelisted.

    Seeing as this isn't what you need then this won't help you.

    The only other suggestion I have is that you talk to Sophos technical support...

    We've got a different Configuration Protection case open with Sophos support at the moment (issue with Hybrid Control conflicting with our SSL VPN NIC, and VMWARE NIC's) and Sophos tech sent us a custom XML policy for CP.

    Using the SafeGuard Management Center we had to sign the XML file, then drop the signed file into a folder on the target end-point, run "SGMCmdIntn.exe -i" from the command line on the end-point and then reboot it.

    Unfortunately this custom policy file didn't fix our problem, but they may be able to do something similar for this defect?

    Just remember that CP isn't truly a Sophos module; it's a Safend product. So often you'll need to work your way up the support chain to get the case up to GES (Global Engineering Support) and then onto Development, who in turn may pass onto Safend.

    A tip here is to provide Sophos tech support with every single inch of detail from the outset. Otherwise GES will downgrade the call back to normal Sophos tech support, who then have to re-escalate the case back to GES. This then goes on and on.

    So get:

    1. An SGN trace of the issue: (http://www.sophos.com/en-us/support/knowledgebase/108081.aspx)

    2. Details of the port

    3.Windows System Configuration file

    4. Output from Sophos SDU: (http://www.sophos.com/en-us/support/knowledgebase/33533.aspx)

    5. A video helps if you can. (They never seem to believe or understand what the problem is, so a picture paints a thousand words) ;)

    Lastly, I'm not sure if I posted the defect number in this thread but you can always call into Sophos support and ask them if DEFECT #59405 is still outstanding.

    Regards,

    John

    :35145
  • Hi Daniel,

    Looks like ChrisD and I were replying at the same time. Also looks like the custom XML policy I mentioned may be a workaround.

    Thanks for replying to this thread ChrisD :)

    Good luck.

    John

    :35147
  • Hello ChrisD and John,

    Yes I have already gone through with technical support the process with the local XML file which is signed in the management center then imported as detailed in John's post but to no avail (this was the process technical support advised).

    It looks like the only workaround would be to allow physical reports for the time being?

    Regards

    Daniel

    :35149
  • Daniel,


    Unless the article referenced by ChrisD is something different which works, then I can't see any other way around it, other than allowing the ports, but blocking the devices (like we have).

    At this point you're in the same boat as us.

    Over the years I have learned to keep my own record of the various Sophos defects and re-skin our environment in order to come up with my own workarounds. Helps to be creative.

    Now and then I just chase up to see if the defects are fixed but quite often they are not - either because other defects have taken priority because more customers have been affected by it, or defects were more lets say "privledged" customers have been affected.

    I feel your pain! Sorry I couldn't be of more help.

    John

    P.S. With CP there's one sure way to workaround unauthorised devices no matter how you lock down your ports... (E-SATA).

    Currently CP doesn't control E-SATA, so you'll have to lock this down at the BIOS level. At best you'll have a local device encryption policy, and anyone who plugs in an E-SATA device will have their data encrypted and think twice about it next time.

    :35151
  • Hello John,

    So would it be right to assume any device which utilised USB3 with the CP we have would experience the same issue?

    Many thanks for your help.


    Regards

    Daniel

    :35155
  • Hi Daniel,

    I don't think it's all USB3 ports.

    I can't be 100% sure as we have a fleet of laptops of the same model, so not had anything else to check against.

    As far as I know it's ports with non standard labelling:

    Example 1: "NUSB3\ROOT_HUB30" (The N at the beginning could be 'NEC' (for manufacturer for example) would be blocked
    Example 2: "USB3\ROOT_HUB30" would be allowed.

    Does this make sense?

    Regards,

    John

    :35157