Slashdot Mirror
Worm Attack Prompts DoD To Ban Use of External Media
An anonymous reader writes "The Pentagon has suffered from a cyber attack so alarming that it has taken the unprecedented step of banning the use of external hardware devices, such as flash drives and DVDs [...] The attack came in the form of a global virus or worm that is spreading rapidly throughout a number of military networks."
Dave Richards, the administrator of the Largo, Florida computer network, came up against this problem. He made the system mount USB disks as FTP shares, and made the file browser hide any executable files on the share so they couldn't be transferred.http://davelargo.blogspot.com/2008/02/hp-thin-clients-and-usb-access-for.html
I'm not surprised the DoD just completely shut the door on these things, but I think that for most admins, a solution like Dave's would be a really good compromise.
Only it was with people bringing in docx files and expecting to use them with OpenOffice and blaming the IT department when it wouldn't work. So I followed some guides and wrote a script, threw it up in a GPO and now only Admins can use USB storage.
The procedure is a HUGE pain in the ass (you need to modify ACL's on registry keys and the whole 9 to cover all angles) but scripted it was as simple as "USBStorage.exe </enable|/disable>" in a logon script.
I think it took all of two hours.
Boot Windows, Linux, and ESX over the network for free.
Forgot to disable AutoRun, perhaps. But actually, it's quite non-intuitive how to disable AutoRun in Microsoft Windows. There are several options, and none of them (and even all of them combined) will disable AutoRun and AutoPlay features in their entirety. In fact, up until recently, Windows Vista had the logic reversed for one of the AutoRun features! i.e., if you take the effort to disable the AutoRun feature, you actually put yourself at more risk. More details here:
http://www.kb.cert.org/vuls/id/889747
But luckily, there is a single registry value that can disable AutoRun at its core. Once this change is made, Windows will not interpret the Autorun.inf file on any device, effectively disabling AutoRun for all devices, including USB drives, network shares, and more. Get the scoop here:
http://www.cert.org/blogs/vuls/2008/04/the_dangers_of_windows_autorun.html
It needs to be said:
In linux, one can remove exec permissions from a whole device via the noexec switch in /etc/fstab .
It is.
But then the network is also so locked down that often times that's the only way to transfer large files. There are shared network drives in the States but they're paltry and always 100% used by some officer's powerpoint presentation and his 2 hour home video.
When my unit was deploying to Iraq I gave all of my guys 2g thumb drives loaded with the data that the company needed. They attached it to their dog tag chain and I had them swear up and down to wear it at all times.
There was simply no other way provided.
---There is no technological defense against PEBKAC.
You are absolutely wrong. If a system is designed properly, or set up properly, the user cannot wreak havoc on a system or the network.
In windows, there are many ways to do X behavior that changes the system. Therefore, Windows is hard to secure properly. It is possible, only by globally applying over-secure regedits that disable even basic functionality. Instead, I propose Linux as a good starting point.
PEBKAC, at least in the business setting can be effectively eliminated by the use of simply being unable to even execute the programs.
Games? Not on the HD.
Web browser? If you need it, you'll be in the webbrowser group.
Some document program? does your job require documents, if it does, you'll have that.
Are you a developer for 3d stuff? If so, you get DRI rights. If not, no permission. Can Windows restrict access to the 3d device?
My question is why do you grant rights to users when they do not justify those rights? We need to provide granular access so that the user is limited in what they do and act only in prescribed ways.
As for that, the only way users can then screw things up is if they do not back up their user files, which you should already have thought of. A morning rsync of the /home (which should be mounted from the server) should take care of basic backup issues. Then it turns to your problem of access to the backups (which could be automated also). It really is a game of admin vs user, and you must outsmart stupidity. You do that by providing 1 way as the only way.
---Something about "internet license"
meh. You do that by providing a punishment via the lines of willful negligence. If one does not provide basic security to prevent infection/takeover or notices and takes no heed, one is guilty and owes a fine to the party harmed. In the course of a botnet, that would be the proportion of bandwidth they used (based upon the actions of the the takeover tool).
Simply put: use the laws we already have now, and not some new, easily to corrupt, new license.
You can with Windows as well.
Don't tailgate - the end is near!
It's actually quite a bit easier to do than that. Just disable usbstor.sys with GPO. done. Keyboards still work. Mice still work. Just mass storage devices. And whoever said you can't prevent execute on windows systems is ignorant. You've been able to deny "Read & Execute" via NTFS permissions since NT 3. Note: Read is a seperate right. Since you have to be able to read it to exectute it, it's just included in the permission description. Semantics. Here's something that may help you understand it. It's not that complicated. In reading the doc it will talk about share permissions and individual permissions, group permissions, and NTFS permissions all seperately, and what wins in what scenario, and will talk about scenarios that no administrator that is worth his salt would ever implement. When done correctly it's actually very simple. However it does have the flexibility to be as complex as one needs it to be. http://www.windowsecurity.com/articles/Understanding-Windows-NTFS-Permissions.html So there.
... what did you expect, something profound?