Educause Security Discussion mailing list archives
Re: Securing common access computers
From: Zach Jansen <zjanse20 () CALVIN EDU>
Date: Thu, 25 Mar 2010 09:52:28 -0400
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
Current thread:
- Re: Securing common access computers, (continued)
- Re: Securing common access computers Patrick Goggins (Mar 24)
- Re: Securing common access computers Todd Britton (Mar 24)
- Re: Securing common access computers David Gillett (Mar 24)
- Re: Securing common access computers Terence Ma (Mar 24)
- Re: Securing common access computers Michael Sana (Mar 24)
- Re: Securing common access computers SCHALIP, MICHAEL (Mar 24)
- Re: Securing common access computers Michael Sana (Mar 24)
- Re: Securing common access computers Brewer, Alex D (Mar 25)
- Re: Securing common access computers Witmer, Robert (Mar 25)
- Re: Securing common access computers James R. Pardonek (Mar 25)
- Re: Securing common access computers Zach Jansen (Mar 25)