A project leader came to us and presented an intriguing logistical problem: His agency runs an educational unit for adolescents who have difficulty in public schools. The kids are curious and computer savvy, and they secretly access a popular interactive youth culture site during class. The agency wanted to block the site. This site provides a wealth of positive interaction but it's inappropriate for vulnerable adolescents and apprehensive staff. Dark tales of lurking online predators abound in TV crime shows.
Strategies
The "Just Say No!" method does not work. Teachers travel between classrooms and computer screens face different directions. The kids hide the taboo window when the teacher is near and restore it when the teachers are gone.
Some browsers support Web site blocking. Ours did but the process was awkward. Teachers balked at the prospect.
Group Policy would be a viable solution but the affected computers are low-end models passed down the corporate food chain. They lie below acceptable specs and are rarely upgraded -- because of the rationale that someday the ante-diluvian machines will be replaced.
Push the changes by remote administration to specific targeted workstations? The resident pushmaster was unavailable. The solution had to be simple to please the teachers.
Then the teachers modified their needs. Don't just block the site, they said, redirect it! If someone accesses the bad site by whatever devious means then direct it to CNN at www.cnn.com instead. (Is this a surreptitious way to expose and educate adolescents to current events?)
Hail to the hosts
A simple and effective solution for a contemporary Windows environment involves the hosts file. Insert two lines that mix and match the undesirable Web site with the IP address of a desired Web site. For example:
Suppose the taboo site is www.xxx.com and the IP address of CNN is 64.236.24.28 then append
64.236.24.28 xxx.com
64.236.24.28 www.xxx.com
to the file c:\windows\system32\drivers\etc\hosts. If you type www.xxx.com then you are redirected to CNN. The change takes effect immediately. (Reboot is recommended).
Our users have generic hosts files as a consequence of receiving cloned drive images when the machines were first put into service or repaired after a crash. So you go with what you have. Rename the existing hosts file for backup then copy over a revised hosts. This method avoids cumbersome programming labor that creates a handle, opens a file, appends a file and closes a file.
Script solutions
A simple batch file (block.bat) does the job. Suppose the revised hosts file resides on the Y drive. Then rename and copy thusly:
Rename c:\windows\system32\drivers\etc\hosts hostsbkp
Copy y:\hosts c:\windows\system32\drivers\etc\hosts
Purists can CD to the proper directory and then use simpler command syntax.
Note that an ECHO command can append but makes no backup.
Tip: Staff like fixing problems themselves. They feel empowered and it improves public relations. You could give them a diskette encoded with the fix and say "Click Here," but beware: The script won't work unless they have administrative rights to their own machine.
Some organizations grant such power to a designated person in the department (The Local Superhero). This scenario strikes a balance between lockdown where the user has no control and full access where the user has total control.
A scripting language that supports a RunAs feature grants the ordinary user administrative rights for a specific task. The job is initiated by the user but run as the Administrator. In this situation there are two scripts:
Script 1 (Setup.exe)
Set admin parameters
Call the Block routine
Script 2 (Block.exe)
Backup the old hosts file
Copy the new hosts file
Here is a sample code snippet example from the blocking program. The example uses the WinBatch scripting language.
Hostsfile = "c:\windows\system32\drivers\etc\hosts"
Backup= "c:\windows\system32\drivers\etc\hosts-bkp"
Revised = "Y:\hosts"
FileCopy(Hostsfile, Backup, @FALSE)
FileCopy(Revised, Hostsfile,@FALSE)
Undoing the login
Some logistical points deserve mention. If no user has administrative rights then tech support might need to touch each affected machine under the local administrator login. If so, the regular user will likely be confused because the last displayed login name and domain may not be their own. This typically prompts another call to tech support. Here are two ways to avoid the problem:
Launch the Registry Editor (regedit)
Open HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon
Step 1: Delete the value in DefaultUserName
Step 2: Change the value in DefaultDomain Name
Exit the Registry Editor
Adjust as necessary to your specific platform. The next user login displays a blank login name and the familiar domain.
The Registry method is fast and elegant. Alternatively, a crude and simple method is: a) logoff as Administrator; b) logon as yourself in the standard domain; and then c) logoff. The net effect is similar.
Sometimes enterprise policy mandates Web site blocking with redirection. Do it by Group Policy, push technology, vendor scripting or private scripting. Use the one that is right for you.
Dr. Lee Ratzan works at a health care agency in New Jersey and teaches at Rutgers University. Contact him at lratzan@scils.rutgers.edu.