EPS doesn't protect against this. EPS prevents data transfer at a software level, and doesn't disable the USB controller itself.
Since USBKiller works by drawing power and then releasing it, it won't run into any data transfer that we could block. The only way to stop that is disconnecting the controller itself.
Thanks for your answer.
I Know USBKiller works by drawing power from USB Port.
But, what about configuring BIOS Settings by Ivanti EndPoint to disable some front accessible USB ports and protect rear USB Ports with other hardware solution.
If front accessible USB ports are disabled, USBKiller couldn't draw ? Is this correct ?
USBKiller "Shouldn't" be able to draw power -- in theory, disabled USB ports shouldn't provide power.
However, this is dependant on the BIOS / motherboard manufacturer's implementation of what exactly they do, so "your mileage may vary" (YMMV)..While "not supplying power" is the sensible thing, that may not necessarily be the case (I've come across some really "special" manufacturers/models over the years).
But it's certainly one relatively easy way to achieve.do what you want - and you'd "just" need to get ahold of the relevant BIOS tool(s) from your hardware manufacturer most likely to do so (assuming that's a thing they have a tool for - most do, but again - "YMMV", depending on whose kit you have). Some "no-name" brand is less likely to have such a BIOS-setting tool than the larger OEM's.
For HP - for instance - we do even integrate with their stuff, so if you happen to have their hardware, you can change the BIOS settings straight from the LANDesk / IEM Console in its own separate tool.
Bear in mind that it's *USUALLY* a sort of "one hardware model == one tool" type of deal, so you may need to script up something that queries WMI (or whatnot) to identify what hardware model you're running on, and essentially have a massive list of conditionals that then execute the right executable with the right parameters. Shouldn't be difficult to do, just annoying, but that's the nature of the beast.
A lot of nuisance work can be removed if you have a fairly homogenous hardware environment (they do exist) .
Hope that helps.
We have that fairly homogenous DELL hardware.
There is a tool configuring their BIOS. I just need to know if disabling USB ports by BIOS will really "not supply power". I have a meet next week. I will ask them.
No problem .
Happy to help a bit.
1 of 1 people found this helpful
On that note, I did test this with both Dell and HP hardware we have lying around. A Dell Optiplex 960, an HP EliteDesk something or the other, an HP Elitebook, and some Dell laptop whose model I can't remember.
On all 4 I tried the below:
Use EPS to disable the USB interface
Disable the interface via Device Manager (What EPS should essentially do - disabling at the driver level)
Disable the interface using bios settings in EPM 2017.1 (for the HPs)
Disable the interface manually in the bios (In case there was any discrepancy I couldn't guess at, and for the Dells)
To test power draw, I plugged in my phone, since USBKiller would be a bit much.
An interesting thing I immediately noticed is that both laptops still provided power, and both desktops did not, when the interface was disabled via BIOS. However, they didn't show up in windows, which is to be expected.
The HP desktop initially also provided power with the USB interface disabled. But when I changed the power plan for the PCI interface to low, then it stopped. (weird, since I checked and it was just using a normal USB2 header and not a PCI card)
The Dell desktop never provided power with the USB interface disabled.
All 4 of them provided power with it disabled via windows or via EPS.
So as phoffmann mentioned, YMMV. Even within the same manufacturer I get different results, likely due to motherboard design and power management changes. It also means disabling the interface in the BIOS may not be enough, you might actually have to change power management settings as well.
There's nothing like consistency (and this is nothing like consistency).
The whole "a single manufacturer may differ in results" is not too surprising, since - even during a single model-line you can find entirely different NIC / BIOS / etc bits on different motherboards. So ... "fun". Unfortunately somethng we're stuck with - just worth keeping this sort of shenanigans in mind.
Big kudos for Recursion for running those test.
Thanks a lot for this return rdavidson. It's really appreciated !
I hope manufacturers will grab the issue with new bios releases.