Blocking website access to overly curious users in an open environment poses policy and technical challenges. With some simple tools, you can meet that challenge and target the result to a selected audience.
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 problem was, the kids secretly access a popular interactive youth culture site during class. Even though the site provides a wealth of positive interaction, the agency wanted to block it because it is inappropriate for vulnerable adolescents.
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 them and restore it when the teachers walk away.
Some browsers support website 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; the rationale is that someday the antediluvian machines will be replaced.
Push the changes by remote administration to specific targeted workstations? The resident pushmaster was unavailable, so the solution had to be simple to please the teachers.
Then the teachers modified their needs. Instead of just blocking the site, they wanted it to be redirected. 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 website with the IP address of a desired website. For example:
Suppose the taboo site is www.xxx.com, and the IP address of CNN is 188.8.131.52. Then append
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 we renamed the existing hosts file for backup, then copied over a revised hosts. This method avoids cumbersome programming labour that creates a handle, opens a file, appends a file and closes a file.
A simple batch file (block.bat) does the job. Suppose the revised hosts file resides on the Y drive. Then rename and copy:
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: Staffers 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 organisations 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"
Revised = "Y:\hosts"
FileCopy(Hostsfile, Backup, @FALSE)
Undoing the log-in
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 log-in 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: 1) log off as Administrator, 2) log on as yourself in the standard domain, and then 3) log off. The net effect is similar.
Sometimes enterprise policy mandates website blocking with redirection. Do it by Group Policy, push technology, vendor scripting or private scripting. Use the one that is right for you.
Lee Ratzan works at a health care agency in New Jersey and teaches at Rutgers University.