CrossNodes Net Tip: Dissociate Scripts, But Leave Them Enabled
Some Network managers turn off Windows Scripting Host to avoid malicious code from running, but there is a way you can have it function and still be protected.
Given the threat of viruses and Trojans that try to take advantage of the powerful capabilities of Windows scripts, many network managers have simply decided to turn Microsoft's Windows Scripting Host (WSH) function off. However, this can be akin throwing out the baby with the bathwater scripts can be a powerful ally in network administration.
There is a simple fix you can employ. Modify the end-users' environments so they associate most script extensions with Wordpad or Notepad. Usually these will be .WSH, .JS, or .VBS. Should someone double-click on a suspect e-mail attachment, all they will accomplish is reading the script itself. However, you can still run the scripts from the command prompt using cscript.exe.
The syntax is as follows:
Usage: CScript scriptname.extension [option...] [arguments...] Options: //B Batch mode: Suppresses script errors and prompts from displaying //D Enable Active Debugging //E:engine Use engine for executing script //H:CScript Changes the default script host to CScript.exe //H:WScript Changes the default script host to WScript.exe (default) //I Interactive mode (default, opposite of //B) //Job:xxxx Execute a WS job //Logo Display logo (default) //Nologo Prevent logo display: No banner will be shown at execution time //S Save current command line options for this user //T:nn Time out in seconds: Maximum time a script is permitted to run //X Execute script in debugger //U Use Unicode for redirected I/O from the console
CrossNodes Net Tips are a new feature of crossnodes.com. If you have a networking tip or trick that you'd like to share, please submit it to the Managing Editor. There can be no financial remuneration, though we will place your byline upon request.