Re: Securing common access computers

[Zach Jansen <zjanse20 () CALVIN EDU>]

I haven't seen Unfreeze used in our environment, but admittedly our user population is fairly well behaved. Although I 
do occasionally see students experimenting with script kiddie tools, this is fairly rare here, and I deal with it via 
normal judicial channels. You might address the issue of malware in general on public lab machines by requiring 
individual logins, using deepfreeze, and disabling the logoff option. It won't stop a hardware based keylogger, but it 
will help prevent spreading malware between uses.  Due to very slow boot times, we haven't disabled the logoff button 
here, but it's a thought. I would use the firewall to prevent remote logons to these types of machines if you're 
concerned about people using them remotely. Once a machine has deepfreeze on it, I don't believe we do many changes via 
remote tools. 

For our kiosk machines that don't need a login, we use another product from Faronics to lock them down. I believe it's 
called WinSelect. It does a good job of making sure other programs can't be installed, browser settings can't be 
changed, and history is wiped on the browser pretty quickly. We provide these stations primarily for checking email, 
schedules, etc, so they are very restricted as to what they offer. 

Zach

-- 
Zach Jansen
Information Security Officer
Calvin College
Phone: 616.526.6776
Fax: 616.526.8550

> > > On 3/25/2010 at 9:34 AM, in message
<EB4A14AA71CE71448233A27D6E0953B101DF98C86CFB () SNHU-CCR-A snhu edu>, "Witmer,
Robert" <r.witmer () SNHU EDU> wrote:
> Thanks!  A lot of helpful replies here.  Deep Freeze seems to be quite 
> popular.  Have any of you had any problems with Unfreeze being used in your 
> environments?  A primary concern I have with common access PCs (even if 
> running Deep Freeze) is script kiddies loading keystroke loggers and or 
> covert tunnels and picking off unames/pwds of unsuspecting users checking 
> email, bank accts, etc. OR using a common access PC to pivot off of 
> anonymously...even if it is only for a couple hours at a time (or however the 
> reboot period is configured).
>
> I suggested requiring users to log onto the common access PCs for 
> auditing/logging capabilities (A/D would log user info) but the person who 
> updates/patches the software on these machines would have to visit each 
> machine to log in before pushing the change via Deep Freeze.  I've read on 
> their website he could use RDC or VNC from the Deep Freeze console to 
> remotely log into each machine, but he didn't like that either (way too time 
> consuming). Any thoughts on dealing with forced login to common access PCs?
>
> I appreciate all the feedback!  If someone wants to go off-line, email 
> r.witmer () snhu edu.
> Bob
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv 
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Michael Sana
> Sent: Wednesday, March 24, 2010 5:47 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU 
> Subject: Re: [SECURITY] Securing common access computers
>
> Deep Freeze too for about 10 years now!  But let's not forget to implement 
> "defense in depth" strategies...
>
> Enable 802.1x if your switch supports it - this helps to prevent users from 
> unplugging and plugging in their own machines...
> Physically lock the computer down so it's more difficult to be stolen
> Put a lock on the computer so it's more difficult to steal the hard drive
> Set the system to boot from hard disk only (or network if you jumped onto 
> the whole VDI bandwagon) so users cant reboot into their favorite linux 
> hacking distro!
> Set a BIOS password so that they cant go in and change the boot sequence to 
> CD, etc.  
> When creating the deepfreeze seed file, make sure you have the system set to 
> reboot after hours (based on the location) so that no lingering scripts or 
> software continues to "phone home" after hours.  This creates a desktop 
> refresh period.
> If your seed file contains "thaw space", create a windows scheduled task to 
> purge this space hourly, daily/nightly so that no malicious scripts continue 
> to live in there while we are out saving the rest of the world :)
> Don't think of deep freeze as an anti-virus program
>
> Just my quick two cents off the top of my head...
>
> mike.sana.
>
> Michael C. Sana MSIA, CISSP, CISM, CISA
> Information Security Officer
> Information Technology Services Division
>  
> Hawai`i Pacific University
> 1132 Bishop St. Suite 307
> Honolulu, Hawai`i 96813
> Telephone: (808) 687-7034
> Fax: (808) 544-1404
> Email: msana () hpu edu 
>
> "Quis custodiet ipsos custodes?"
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv 
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of SCHALIP, MICHAEL
> Sent: Wednesday, March 24, 2010 11:06 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU 
> Subject: Re: [SECURITY] Securing common access computers
>
> We use DeepFreeze, too.....Are there any other options to this 
> software?.....or is this "the state of the art"?
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv 
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Zach Jansen
> Sent: Wednesday, March 24, 2010 2:39 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU 
> Subject: Re: [SECURITY] Securing common access computers
>
> We use a program called Deepfreeze from Faronics to secure the public lab 
> machines from configuration changes. Basically it removes any changes from a 
> machine upon reboot, returning it to the state it was deployed in. The nice 
> thing here is that students can do whatever they want on the machines, such 
> as install software, change settings, and it's removed on reboot. Faronics 
> has a similar program for kiosk type machines, though it has some additional 
> browser lockdown features. 
>
> We do have individual logins for accountability, except on kiosk machines, 
> and have few problems with misuse. Kiosk machines are more likely to be 
> abused since anyone can use them without a login. Deepfreeze does tend to 
> make investigation harder, though not impossible.
>
> Hardware keyloggers are certainly a threat, though I've yet to run into one 
> in my environment.
>
> Zach Jansen