garethedmondson (24th September 2013)
We have just been asked to setup a way of students running .exe files as part of their programming course in visual basic.
Any suggestions on how we might do this, so as to not to pose a security risk to the network?
We currently run Ranger on our network, server 2012 and windows 7 clients.
Help, much appreciated.
Virtual machines is how Ive managed this one. For us, we have built a Linux VM based on SLAX, which has loads of great programming utilities in it. In our case it was Python and Scratch among others. I read you need VB, but Im sure there must be some utils for it - or use an XP VM. Weve used VirtualBox, which has no network connection, but uses and allows access to the mapped U:\ (Home Drive) of the logged on user. Hey presto - file access and storage. They can write and run the code in the VM, save to their area, but not run the code from the normal network. I hope this makes sense.
I had this issue before the summer holiday. Personally, I don't want pupils running their .exe's on the domain in any shape or form. I considered running virtual machine images on the local PC with the vm images coming from the network, allowing the user to roam, but this was a dead end for a number of reasons.
Really pleased with the solution - a Windows 2008 R2 box running terminal services and Visual Studio, with 12 cores and 24GB of RAM, all data held locally on the server, and the server is a standalone. Only Comp Sci pupils can access the box as they can only run the RDP client by group membership. FSRM on the domain prevents them from copying executables to their home dirs, but using RDP they have access to local drive letters and printers, and can even use a memory stick to take home their work. NOTE I believe that a 2012 terminal server needs to sit in a domain, so I think you need 2008 R2, at least in the way we have configured it.
With this spec, we've had 20 or 30 concurrent users, no issues, no speed problems, everyone happy.
Last edited by digone52; 24th September 2013 at 08:47 PM.
We had this issue but in the end I set then allow .exe from their MyDocuments\Visual Studio 2010\Projects directory - it's only available in my room.
I"m not a fan of lock and block. Don't agree with it. I understand why - but don't like it.
If virtualisation is the answer the school will use, it could be a good idea to look at automating snapshots and reversion every day/week, sort of like a poor-man's VDI. Over here we're very keen to support an exceptional group of pupils in learning about Python programming and, going forward, console access to a Ubuntu Server instance. I'm going to make it happen but I'm also going to be very conscious of all the security implications and I'll definitely be making sure that I can script/automate periodic snapshot restores from time to time.
Gareth, depending on the system setup we have to consider certain realities and at the end of the day we don't have to like it. The system exists to ensure that the school does; at the end of the day T&L is only one process among many from an org. man. standpoint. We know that schools exist to educate children but we can't afford to get ahead of ourselves in that respect when we consider the potential consequences of security breaches. I'm always quite explicit about that because in principle a security breach means nothing in itself (barring a lot of work for IT staff); what's important is the consequences of it. I do support the principle of a learning-focused organisation but I'm not going to pretend that it's okay to risk disclosures of sensitive personal data on staff, pupils or their families just so a few children can learn a few things that they could easily learn at a later stage in college anyway.
I forgot to add, that the VMs are "read only" - they are essentially Live images, which exist on all machines - so once closed - any "fiddling" is lost. It means a completely flexible environment...they key was explaining the importance of saving to their home area!!!
I likewise understand the concerns...but we have to work a solution that keeps everyone happy. Part of the solution should include educating the students why it is set up in this way.
A good point - if pupils question why it works that way we would be in a good position to tell them, and from experience too.
That solution almost makes me wonder if a customised version of XP Mode on Windows 7 could be an option, deployed only on the relevant workstations.
I've also been looking for ways to manage this. We have some students running Small Basic which seems to compile an exe in to the users home directory and then attempts to run it. I considered going down a VM route but have also been looking at Sandbox applications like Sandboxie. Has anyone taken this approach?
Maybe it will shoot me in the arse but as it's only in my room which I monitor then it's not an issue for me.
I understand how bad a security breach can be. If pupils can access sensitive, personal data on staff just by opening .exe from a Virtual Studio project directory then is that stuff really safe?
Educate me. I'm not too arrogant that I will not listen to how we could be exposed. I am just a teacher after all ;-)
I imagine this will become another of my hallmark screen-filler posts and most will TL;DR.
Before I joined the big wide world of the grown-ups and began to use my skills for good, I had a "background" in this. I freely admit that because it was a long time ago and now provides me with insights I can use in a professional capacity, and I was only ever white hat. I'm going to give a number of relevant examples from intrusions I made, obviously without referencing exactly where.
In one environment (educational), a VNC server was installed on all workstations as part of a bigger package from a major vendor. Naturally this was inherently a problem as VNC stores server passwords and the manner in which they are obfuscated is insecure. It was only because I was able to issue commands like RegRead() that this mattered, however. Otherwise, and assuming no physical access to the box as ought to be the case, the password could have been stored in plain text for all the difference it would have made. It wasn't a problem until an attacker was provided with a way to read the data, which otherwise could not have occurred. The consequence was that I was able to view the screen of almost any workstation on campus, with all the obvious confidentiality implications that brings.
In another (Citrix sales demo environment), a domain admin account had what we might call a very guessable password. This was not the problem, however. The problem was that, owing to lax Group Policy restrictions, I was able to begin building up information on the target environment (server names, AD policies, virtual or not, etc) and eventually gained a list of usernames. Both the username and the password are ciphers to an outside attacker, which is why Windows doesn't tell you which you got wrong if you make a typo. Without knowing the username, it wouldn't have mattered at all that the choice of password was poor. The one problem wasn't relevant until the other existed. Because I was able to gain access to information that I shouldn't, lax security further down the line became relevant, and only then. The top and bottom of it is to never assume that you or a colleague have not slipped up somewhere else - the key is to make sure no potential attacker can find out about it! The amount of times I have been able to exploit the tiniest, most seemingly irrelevant detail to discover a more major problem down the line is unreal. This is no insult to anyone's skill or experience; it's the guideline I maintain for myself professionally as well, precisely because a significant proportion of intrusions I have carried out were possible SOLELY because someone in the equivalent of what is now my job made a silly mistake, was lax or lazy with security, didn't anticipate how information could be (mis)used or was generally a bit cr*p at their job. The implication here was that a critical sales tool could have been taken away from staff during presentations, causing no end of embarrassment and damage to the company if it happened regularly.
In another (Local Authority), the practice used to provide Internet access to many local schools through their broadband network was to give them all a username and password (which they had to type in EVERY time they opened a new browser session - unimaginable nowadays!), or in fact one set for admin, one for staff and one for pupils. These credentials were actually AD accounts in a central domain maintained by the LA, and were authenticated by a Windows-based proxy server which naturally had to have a domain computer account. On a lot of systems, an account will be created that has access to create, delete, disable or otherwise amend computer accounts, and solely to do specifically that. It will be created as a Domain User or Domain Guest, and the AD Delegation of Control Wizard will be used to give it the access rights required to the OU containing workstation accounts. It's typically used as the credentials for adding/removing workstations from the domain. That was the case on this system, except the security was misconfigured; those access rights had been granted at the root OU for all computer accounts, not just workstations but servers as well (Problem 1). Unfortunately, whether it was down to inappropriate routing or firewall port rules, it was possible to access shares on member servers of this central domain from individual schools (ports like 53 would have been needed, but why 139 as well?) - Problem 2. Anonymous enumeration of information such as user account names was also enabled on the domain controllers (Problem 3). One user account had the name "Public" - used for libraries and suchlike - and its password was easily guessable (Problem 4). This allowed me to connect to shares permitting read-only access to all Domain Users (not uncommon on larger systems). Lying around on one of those shares was what looked like an old, template SysPrep.inf file, containing the credentials of the domain-joining account (Problem 5), which were still valid (Problem 6). As a result, it was possible to disable the computer account used by the proxy server, such that no school Internet usernames/passwords could be authenticated, effectively taking down Internet access for the bulk of local schools. Despite being white hat I must admit I PoC'd this for two minutes, then reported the problem anonymously. But I've skipped ahead a little here because between Problem 2 and Problem 3 lies the Real Problem: I was able to run GFI LANGuard against the domain controllers. If that Real Problem of being able to run unapproved software (or, if you know what to look for, writing a simple programme that checks for these specific things) had not existed, then none of the rest would've mattered because I wouldn't have been able to glean the information in the first place. The problem with allowing both programming environments (that can read Registry keys, check for open ports, open a WMI connection to access data etc) and the execution of unapproved (compiled) software is that you enable problems that previously didn't matter, to now matter. You take all the Group Policy restrictions and etc that were specifically created to prevent this and effectively throw them out the window.
Consider one potential impact of illicit access to data here. Little Freddy dislikes Little Johnny and wants to beat him up but is wary of trying it in school. It's a big city and Freddy doesn't know Johnny's address. If he or a friend compromises the system and accesses this information, Johnny might find himself in hospital. If that event is ever causally linked back to the school, the people responsible will lose their careers and either way we are talking about an assault on a child. The reason I mention this is that during my own little phase, I had contact with others doing similar things. Not all were as white hat as I was; one of them was in the habit of actively selling the information they acquired (they had a few "personal issues") to whomever would pay enough for it; sometimes they wanted it for trivial reasons (egging staff's houses for example), other times for more sinister ones.
To come to the point, you're right to question whether that sensitive, personal data on minors and their families is really safe. Never assume it is. I can well imagine that the administrators of the systems I was able to compromise thought much the same thing. Having personally been that one factor that was missed, or not thought sufficiently important, a good few times, and knowing that children can be trained "groomed" by older hacker communities (as I was), the argument that school security breaches are either pretty much a myth or that their importance is overstated will never, ever wash either with me or with anyone else who has seen it, been it and done it.
That is a brilliant answer and thank you for putting it out there for me to read. A lot to take in - I appreciate the time you have taken.
Ephelyon (26th September 2013)
Block exe's using FRSM and let students use read only virtual machines
We use VMWare pro which has password protection to stop access to the network config area. Everything they do can be copied and pasted to their user area.
Search for virtualbox on these forums and you can see you can restrict everything and anything you like, from menus to configurations. Set up right, they wont even see VirtualBox other than the window with the OS on it.
There are currently 1 users browsing this thread. (0 members and 1 guests)