Ask Slashdot: Safe Learning Environment For VMs?

First time accepted submitter rarkian writes "I am the teacher in this story. I teach Python and C++ to high school students: grades 9-12. I use CentOS 6 with DRBL to run my computer lab. Some of my students have become Linux experts. Next year I'm planning on allowing students to create and run their own VMs in a segregated LAN. Any advice on which virtualization technology to use and security concerns with allowing students to be root in a VM?"

Comments

Set up VLANs

[Anonymous Coward]

for each of the students and don't allow any interface between them...and certainly no main network/internet access.

Re:Set up VLANs

[ttucker]

for each of the students and don't allow any interface between them...and certainly no main network/internet access.

VLANs are not for security! Any two things plugged into the same switch, whether virtual or real, can talk to each other if sufficiently motivated.

Re:Set up VLANs

[Anonymous Coward]

...and certainly no main network/internet access.

This is Linux were talking about. What could you possibly teach them without an internet connection? The only use I see is teaching shell scripting or something, since other tasks like package management, and sane server configuration kinda require an active internet connection. Assuming these are wiped on exit, (and they should be) I see no problem with giving them root and network access. Probably the worst they could do is a ping scan or attempt to screw with other hosts by changing local ip addresses, all of which can be handled by having the instructor watch what the students are doing, or kicking them off the campus network.

Re:Set up VLANs

[Anonymous Coward]

VLANs are not for security! Any two things plugged into the same switch, whether virtual or real, can talk to each other if sufficiently motivated.

I don't think you understand VLANs or switching as well as you think you do.

Re:Set up VLANs

[The MAZZTer]

Only if the switch lets them.

Re:Set up VLANs

[TheCarp]

> This is Linux were talking about. What could you possibly teach them without an internet
> connection? The only use I see is teaching shell scripting or something, since other tasks like
> package management, and sane server configuration kinda require an active internet connection.

Well Python, that is what he said he wanted to teach them :)

Beyond that, you are right, I say, the key is not security but recovery. Template boxes so that a new VM can be spun up effortlessly, then let them have at it. Segment the lab off from the rest of the network, maybe let the lab out to the internet, but not to the schools internal network.

However the key is, you can always blow away a machine and reimage it to get class moving, so there is no real danger in letting them play. Hell, I took a class that taught us administration and hacking eachother's machines was explicitly allowed, as long as it stayed in the lab. (we were also required to create a guest account as one of the exercises)

Gives the advanced kids who are bored with the class something to do that lets them learn too; I certanly had fun.

Re:Set up VLANs

[LordLimecat]

Not if they are on private VLANs (still not clear if it is a standard or not). VMWare supports this; the idea is roughly analogous to AP isolation on a wifi AP-- "isolated" nodes can all talk to the gateway (the community / public node), but cannot talk to each other.

And VLANs actually are for security, and can provide far superior security than ACLs, since unless you have a trunk port or layer 3 switches, it is impossible for two devices on different VLANs to communicate, short of a switch misconfiguration. Its probably second to air-gapping in terms of security-- its sort of a logical implementation of "air gapped switches", except that they CAN be joined together if someone gets onto the switch.

Re:Set up VLANs

[Anonymous Coward]

As long as they have the same level of access from their VMs that anyone would if they walked in with a laptop, things should be fine. They're just as much of a security risk really. A destructive person can wreak havoc with either quite easily on an unsecured network.

Re:Set up VLANs

[ttucker]

VLANs are not for security! Any two things plugged into the same switch, whether virtual or real, can talk to each other if sufficiently motivated.

This is simply not true. You're probably referring to 802.1q tag hopping attacks, which are not particularly difficult to prevent.

Do you really think tag hopping is the only attack on VLAN? Perhaps you should read what Cisco says about the matter, if your job depends on it: http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml . They point out that with an adequately secure switch, and good configuration practices, that the security is adequate. Without all of the correct practices, VLANs provide a very dangerous false sense of security.

Re:Set up VLANs

[MattW]

VLANs are not for security! Any two things plugged into the same switch, whether virtual or real, can talk to each other if sufficiently motivated.

As you pointed out below, VLANs in general are trustworthy when properly configured with a proper switch. I did nothing but netsec work in the late 90s, and everything was airgapped; we'd never have frames from two networks on the same wire. If you wanted to cross security zones, it was at L3 on a firewall and to different wires and switches.

On the other hand, it seemed like back then a new practical way to defeat VLANs was coming out every other week, so this was a wise precaution.

That said, keep in mind that VMware also affords some additional security in terms of VLANs. Physical switches have to connect to virtual switches to interact with the VMware layers (either the hypervisor for control traffic, or with the VMs for VM traffic), and the hypervisor itself will enforce a lot of things. On a VMware vSwitch properly configured:

- VMs can't enter promiscuous mode, change their MAC address, or forge transmits with the wrong L2 address
- QinQ frames are discarded
- The hypervisor itself will determine which virtual nics on a vswitch should receive copies of a frame, depending on which VLAN tag is on a portgroup
- Guests can't send tagged frames if their portgroup is set with a VLAN; you have to specifically configure a trunk on a portgroup to pass VLAN tags in and out of the guest environment

If the network was homogeneously ESX nodes and administratively controlled network equipment, you could likely enforce security between VMs with VLANs even with a dumb hub.

Obviously, airgapping and single-role wires will create better security than VLANs, because there always remains a chance that an undiscovered bug will allow breaching that L2 barrier, but that's true for everything.

Re:Set up VLANs

[Lunix Nutcase]

He's teaching them to program in Python and C++ not system administration.

Re:Set up VLANs

[Vrtigo1]

That, to me, defeats the entire point. Why even give the machines network adapters if there's nothing for them to talk to? It'd be much better in terms of experience, learning, practicality and fun if you just setup an isolated network for all of the student machines and create your own little Internet. That gives them the ability to setup client/server apps with other students and deal with security issues, just like they'd have to do in real life.

Setting everyone up by themself might let them do some basic lessons, but why teach them something they'll probably never experience in the real world?

Re:Set up VLANs

[AlphaWolf_HK]

That's not true at all. Yes there exists a VLAN hopping exploit, but it is easily prevented by modern switches. While VLANs weren't intended for security in the beginning, that has become one of their new purposes. Otherwise, layer 3 switches would probably never be used in any environment where security was major a concern, but that's simply not the case.

Another extension of the VLAN concept is PVLANs, whose purpose is for nothing else other than security, primarily used in hotels to prevent hacking, but has other uses as well, nearly all of them security related.

Re:Set up VLANs

[AlphaWolf_HK]

With a cheaper consumer grade switch, perhaps. However enterprise grade switches (which I'm going to assume he is using) there are all kinds of features that can prevent anything you described above, such as MAC flooding, VLAN hopping, broadcast storming, deliberate switching loops, and more.

Re:Set up VLANs

[LordLimecat]

No, they do not. Crossing a VLAN requires trunking and routing.

The best / most productive way to think of VLANs is to consider each one a separate switch and a separate subnet (cisco actually conflates the two terms; in Cisco-world, a subnet==a VLAN); broadcasts will span the VLAN, but will not leave it. If you are using private VLANs, broadcasts will only be heard by community and public nodes, but not by other isolated nodes.

Re:Set up VLANs

[tibit]

The whole point of VLANs is that they are separate ethernet broadcast domains, duh.

Re:Set up VLANs

[evilviper]

VLANs are not for security! Any two things plugged into the same switch, whether virtual or real, can talk to each other if sufficiently motivated.

Umm, no. Not unless your switch is defective, or massively misconfigured. VLANs are very secure, when done properly. And the same security measures needed to protect VLANs are the same ones you need to protect switching in general (see CAM overflows, arp spoofing, and such).

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml

If you leave your trunk/native VLAN at 1, you're in trouble. If you configure user-facing ports as auto-negotiate, or trunk without explicitly specifying allowed VLANs, you're in trouble.

Re:Set up VLANs

[ttucker]

That's not true at all. Yes there exists a VLAN hopping exploit, but it is easily prevented by modern switches. While VLANs weren't intended for security in the beginning, that has become one of their new purposes. Otherwise, layer 3 switches would probably never be used in any environment where security was major a concern, but that's simply not the case.

Another extension of the VLAN concept is PVLANs, whose purpose is for nothing else other than security, primarily used in hotels to prevent hacking, but has other uses as well, nearly all of them security related.

Some further research indicates that my initial reaction to VLAN and security is somewhat dated, and VLAN tech has improved drastically since. Still, there does seem to be a few places where poor configuration could lead to a spectacular breach, simply because any exploit of the switch allows an attacker to access any VLAN segment.

Re:Set up VLANs

[maelfius]

I would recommend using OpenStack and RDO if you can tie together the physical machines into a "cloud" like system (vs. say just running a single hypervisor software per computer like virtualbox).

Each student could be allocated their own project/tenant with appropriate quotas and limits. If setup with a VLAN type system, it is possible to isolate entire networks of VMs for a given project (allowing more than a single VM per student if the hardware can support it) and you can provide some basic images of where you want the students to start from.

http://openstack.redhat.com/Main_Page

I know it sounds like a bit of overkill, but it provides a lot of functionality that you can control from a more centralized location without the need of setting up VBox on every host.

The students can interact with the hosts (depending on how you do it) via the network directly or via the dashboard (vnc-like) web page.

Re:Set up VLANs

[evilviper]

it is impossible for two devices on different VLANs to communicate, short of a switch misconfiguration. Its probably second to air-gapping in terms of security

You're seriously over-stating the security of VLANs. While you should be safe if you follow the best practices, there are potential security issues to be aware of, and VLANs are certainly NOT more secure than layer-3 routing/firewalling.

Re:Set up VLANs

[cas2000]

then there's no good reason for them to have root.

depending on the work environment, devs may or may not have root on their own workstations, but definitely shouldn't have it on the development, testing, or production servers unless part of their job is systems administration (either because they're an assistant sysadmin or because their employer is a cheapskate and thinks that sysadmins and programmers are the same).

actually, i'm partly wrong - there's one good reason, to teach them how to cope with the mess caused by the kind of bad systems adminstration done by a programmer who sees it as a boring chore that uses up valuable dev time. but that would only work if they only had root on another students' VM rather than their own.

another good reason is that some students will realise that they prefer or are better skilled at sysadmin work than at programming, and devote their future studies and work to further that....programming and systems administration require similar skill sets, but quite different attitudes and aptitudes.

Re:Set up VLANs

[microbox]

then there's no good reason for them to have root.

For god's sake, a student should (ideally) have the opportunity to use the package management system to fiddle with different libraries.

Re:Set up VLANs

[Drakonblayde]

You're correct in that in and of themselves, VLAN's are not a security feature. Neither is NAT. VLAN's provide layer 2 segregation of network segments.

However, most of the major switch vendors have security features to apply to VLAN's that, when used in conjunction with VLAN's, makes them very secure.

Re:Set up VLANs

[Drakonblayde]

Blatantly incorrect. The vlan is what defines the broadcast domain. A broadcast (by default anyway) will reach every single port in a given vlan, and no other.

You really should do your research, this is absurdly easy to disprove.

Re:Set up VLANs

[Drakonblayde]

Some further research indicates that my initial reaction to VLAN and security is somewhat dated, and VLAN tech has improved drastically since. Still, there does seem to be a few places where poor configuration could lead to a spectacular breach, simply because any exploit of the switch allows an attacker to access any VLAN segment.

Well isn't that a bit obvious? If you can compromise a core router or distribution switch, yes, you can do alot of nasty things with network security. That has absolutely nothing to do with VLAN security, device hardening is a whole other ballgame.

Re:Set up VLANs

[sjames]

The vast majority of that paper essentially says if you configure the switch to blindly trust everyone, someone might abuse that trust. The rest is warnings about some less than sensible things some switches might do if you allow defaults.

Re:Set up VLANs

[TheCarp]

For me it was just an administration and programing course, and we didn't actually have VMs, each team had a physical box. Still we had some fun. When setting up the guest account one of the other teams made /home world writeable...ooops... I had fun with that.... took me a few minutes to move everyone's home dirs aside and replace them with new ones with a new .profile which would copy /bin/sh to a new dir and make it setuid to their own user...then fix their home dir and exec the shell again :)

Joke was on me, of course, as they ignored the advice that they should use their own named user accounts and not just log on as root all the time, none of the users ever logged in. However, the instructor saw what I had done and thought that team was messing with him, so he gave them an extra hard test at the end... accidentally giving them a problem that they couldn't solve. Oops :)

Re:Set up VLANs

[Marxist Hacker 42]

Why would you presume that a schoolteacher has either access to or budget for enterprise grade kit? Let alone a public school teacher in Vancouver where they have to have a casino night with GCC just to fund field trips?

Re:Set up VLANs

[LordLimecat]

Absolutely they are more secure; the "default" is that no traffic can reach any other VLAN in any circumstance, unless you wire two switch ports together (which would be pretty silly, and would also beat layer 3).

To put it another way, adding the firewall / layer 3 routing is a prerequisite to traffic even crossing that VLAN. Adding the firewall doesnt make it more secure, it makes it less secure, because now there is a mechanism that can route traffic between the VLANs. The "best case" would be adding a "deny any-any" rule on the firewall, which would accomplish the exact same thing as not having a layer-3 device there in the first place (except now you have another possible area for misconfiguration).

Re:Set up VLANs

[ttucker]

The vast majority of that paper essentially says if you configure the switch to blindly trust everyone, someone might abuse that trust. The rest is warnings about some less than sensible things some switches might do if you allow defaults.

I read, "VLANs used to be insecure because of these myriad vulnerabilities, but Cisco switches defend against them mostly by default/design, so it is not really that bad."

I also read, VLAN switches need to be treated the same as security critical router/firewalls, because they are now serving essentially the same role. Also, please keep paying for your proprietary switch's very expensive support contract, and plan to throw it away in 5 years when we build a new one.

Re:Set up VLANs

[evilviper]

You need to read-up on your VLAN security, because you don't seem to know what you're talking about. VLANs are NOT as secure as an air-gap. There are plenty of scenarios in which an attacker can forge VLAN tags or similar, and be able to hop from one VLAN to another without any restrictions (while this would NEVER be possible with a layer-3 router/firewall actually separating networks).

And saying that's all because of switch "misconfiguration" is just not true. There are some complex cases with VLANs, where things like VTP can be exploited, even if properly configured.

It's such that using VLANs to segregate secured and unsecured networks is simply not allowed by PCI-DSS and other security standards.

Re:Set up VLANs

[LordLimecat]

I didnt say they were as secure as airgap, i said its the next best thing.

There are plenty of scenarios in which an attacker can forge VLAN tags or similar,

Only if you did something ridiculously stupid, like set your access ports to allow trunking. If you set your client-facing ports to access, they will drop tagged packets as invalid (which they are, on a non-trunking port).

hop from one VLAN to another without any restrictions

This is NOT POSSIBLE. The scenario you described involves a trunk port. Tagging traffic, even if you were on a trunk port, would just have traffic on one vlan; you CANNOT get it to cross from one VLAN to another without a layer-3 device somewhere in the mix; the switches simply will not be able to route it because thats not what they do.

, where things like VTP can be exploited,

Generally you either turn VTP off, or you make darn sure its not on access ports. That certainly isnt a flaw with "VLANs" though, since thats a Cisco proprietary management system for VLANs and nothing inherent in the switching concept.

It's such that using VLANs to segregate secured and unsecured networks is simply not allowed by PCI-DSS

Theres a lot of ridiculous requirements set by PCI-DSS; thats neither here nor there. In a lab scenario, and even in the real world, VLAN is sufficient security for the vast majority of cases.

Re:Set up VLANs

[RockDoctor]

a casino night with GCC just to fund field trips

What The Fuck is a one of them? I'm going to have to RTFA now!

about (computer) programming

There's non-computers that you can programme, in a meaningful sense of "programme"? I can't think of such. "Programme" the video recorder? That hardly counts as "programming" (no branching logic). But that's just the reporter probably, who struggles to programme his dishwasher.

Nope, no mention of a "casino night" in TFA. And no onward links. So where did that come from (and WTF is a "casino night with GCC"?). I'd have thought that most bars and casinos in Canada wouldn't have allowed school students in. Though the ubiquity of those idiotic "slot machines" in Canadian bars makes the distinction pretty moot.

Re:Set up VLANs

[Marxist Hacker 42]

You would need google, so I'll just tell you. Early in my career, I worked for Casino Software Corporation of America, which had a contract with Great Canadian Casinos (GCC). GCC had this rather odd licensing scheme from local British Columbia government: the license wasn't granted to the company, but to local charities for no more than 48 hours, and charity volunteers had to do certain jobs in the Casino, such as the count room. When I did my month of on site tech support in Vancouver, they would quite often be local PTAs and individual classroom teachers, trying to make up for the money that the taxpayers were NOT providing the schools. Was a bit of a gamble though- one good jackpot could wipe out the entire night's earnings. They never lost money on the deal, but many of them would have to reapply for a new license.

Sorry to be obtuse. I was just expressing my impression that most public school teachers, especially in Cascadia where libertarian attitudes about taxes abound, can't afford enterprise grade kit. Thus, an enterprise grade switch is not an affordable solution to this problem.

Re:Set up VLANs

[evilviper]

Only if you did something ridiculously stupid, like set your access ports to allow trunking

Or if you leave your native VLAN as 1 (the default). Or if you don't explicitly turn on native VLAN tagging. Or if you don't remember to change the settings on EVERY port before you connect any of them. Or if you allow any access ports on the same VLAN that is the native vlan on trunks. Or if you run out of CAM space. Or...

VLANs can be configured to be secure, but in fact it's a hell of a lot of work and vigilance, as any little oversight can be a huge vulnerability.

Re:Set up VLANs

[LordLimecat]

You seem to be misunderstanding what VLAN1 vs tagging vs trunking are.

On Cisco hardware, VLAN 1 is a security risk because it is the management VLAN; any clients on there can SSH or telnet to your switch (if an IP has been set) and attempt to log in. It does not allow tagged traffic to traverse the switch any differently than on any other VLAN.

I did a bit of research to see what you referring to with native VLAN tagging, and came across this helpful refresher:
https://learningnetwork.cisco.com/thread/8721

Basically, on trunk ports only, untagged traffic is assumed to be on the native VLAN. The tagging / non-tagging can only occur on a trunk port, and can NOT "span" a VLAN-- even if your PC is set up with trunking software and you are on a trunk port, your traffic will technically "originate" on whatever VLAN you tag / dont tag it as. I suppose if you were MITMing between two trunking switches you could alter the tag, but the IP destination address would then be incorrect for the new VLAN, and would be dropped at the destination.

Without a router (even if its just a layer 3 switch with "ip route" enabled), there really is not a way for traffic to traverse VLANs. Cisco and most other vendors are pretty clear on this. And as I said regarding tagged traffic on non-trunk ports, that traffic is dropped. Pretty good summary here (references the 802.1Q standard)
https://supportforums.cisco.com/docs/DOC-17237
You'll note that there is an exception for "hybrid links" which I dont have much experience with, but as I recall this requires specifically desginating a voice VLAN on the switchport.

As for changing the settings on multiple ports....
>Config t
>interface range eth 0/1-24
>switchport access vlan 10

Switchports 1-24 are now VLAN 10, and will reject tagged traffic.

You ARE right that there is a little configuration to secure it, but it basically consists of
  * Turning off dynamic trunking (the default)
  * Setting VTP to transparent
  * switching your ports off of the native VLAN, OR not assigning an IP to your switch / only allowing console access, OR changing the native VLAN

Those 3 can be done in about 2 minutes, with maybe 5 commands.

Re:Set up VLANs

[LordLimecat]

Just a bit more info / helpful "attacks" paper by cisco.

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39061

Note that the two VLAN-specific attacks they mentioned both indicate that they require either explicit trunking or DTP auto.

Re:Set up VLANs

[evilviper]

You seem to be misunderstanding what VLAN1 vs tagging vs trunking are.

No, your ignorance of some of these issues is NOT a misunderstanding on my part...

Users don't need to be on a trunk port, they can just be on a VLAN that is used as the native vlan of some other trunk port, perhaps on some other switch (which should NEVER be VLAN 1 if you know what you're doing)... they can then embed a VLAN tag, and when it's sent to the next switch in the chain, over the trunk port, that user-inserted VLAN tag will be interpreted, and bingo, you've hopped VLANs.

The fact that you are apparently completely ignorant of some of these problems just reinforces my point that quite a bit of vigilance is needed to maintain any security at all on VLANs.

In any case, this discussion is incredibly tiresome. If you wish to remain ignorant of the security implications, be my guest.

Re:Set up VLANs

[LordLimecat]

I have a feeling you arent understanding what Im saying or I am commicating badly. I am saying that you cannot pull these threats off on a non-trunk port, and you seem to be saying there are security issues if a user is on a trunk port. I dont consider that to be a "threat" however, since you are just using trunking mechanisms to escape VLANs.

Having users on a trunk port is a misconfiguration. As i keep saying, you HAVE to have the user on a trunk port for this to be a threat, and that is not the default. DTP auto IS a default, but the first thing every Cisco tech learns is that you never never never keep DTP auto turned on; you explicitly make every port either an access port or a trunk port.

Hope that clarifies what Im saying.

For the OP's question, VLAN security is plenty sufficient, since he will (presumably) not be trunking at all, nor using a router, so none of these attacks are relevant.

Re:Set up VLANs

[evilviper]

I am saying that you cannot pull these threats off on a non-trunk port

And you are wrong...

Re:Set up VLANs

[RockDoctor]

Yeah, I'd got the bit about enterprise-grade kit not being available on as school-grade budget. (Or even a "grade school" budget ? Or am I getting several different foreign school system terminologies confused, when I've no need to learn even my country's school terminology.)

GCC as a casino corporation rather than the Gnu Compiler Collection ... that's a very curve ball to throw around in this forum! Impressively obscure.

where libertarian attitudes about taxes abound,

... you get teachers having to gamble to try to keep the school running. That's a truly wonderful lesson to be teaching the kids. Have they started hiring the teachers out as prostitutes yet, or is that next year's budget plan? That'd really teach the kids how money is vastly more important than anything at all else. I'm impressed, and I will be trying to get this schools-into-casinos-and-whorehouses bill into my legislature too. There's a certain degree of honesty in teaching values in such an unadulterated manner. "Totally dedicated to the fifty bucks," in the words of Frank Zappa ("Crew Slut" on Joe's Garage).

Safety?

[Joce640k]

The whole point of a VM is that being root isn't a safety concern.

Re:Safety?

[Anonymous Coward]

Unless they take down the network, e.g. running a rogue DHCP server. Or they use it to hack other systems on the network, e.g. password-sniffing the other student's credentials when they log in from their VMs.

Re:Safety?

[fwice]

if the VM has a full root account, with a network address on the global network at large, then it has the ability to, for example, run a priviledged NMAP scan on the entire network. Which can expose open ports or vulnerabilities on another machine that can then be used to leverage access.

Re:Safety?

[Anonymous Coward]

He means that if you give root access to a machine on an unprotected network all kinds of fun things can happen:
- user changes his IP address to be that of the gateway, or the file server
- user sniffs packets of unprotected network protocols (the windows file sharing servers don't seem to encrypt traffic)
- send strange packets that cause loops in routers etc.

So he want to create isolated networks where the kids can really play and not worry about breaking something important.

Re:Safety?

[denmarkw00t]

and run their own VMs in a segregated LAN

Sounds like they'll be on their own little LAN

Re:Safety?

[h4rr4r]

Only if you think your VM software is perfect.

I think all the popular products have at one time had exploits that allowed a guest root user to muck with the virt kernel or other guests.

Heck, if you are not smart enough to limit how much resources one VM can take a nice fork bomb is a good way to slow down the whole shebang.

Re:Safety?

[Anonymous Coward]

The examples I gave do not require you to be domain admin. Just root.

Re:Safety?

[Nerdfest]

They can always plug in their own laptop and do that anyway.

Re:Safety?

[Archangel Michael]

Which is why they need to setup their own VLAN to isolate the VMs to the classroom. VM traffic is isolated to non-routing VLANS. They call this setup a "sandbox", and it is generally a good practice for classroom work.

As for which VM technology to use ... VMWare, or ZEN or even Microsoft's version are usable. VMWare is sort of free, Xen definitely is. I'm not familiar with pricing on Microsoft's versions but schools tend to get steep discounts for server licenses. Look at OpenStack for management, I hear it is decent when it works.

Re:Safety?

[NatasRevol]

Not even root on some of your examples.

Re:Safety?

[Baton Rogue]

Unless they take down the network, e.g. running a rogue DHCP server.

Put the lab in a separate network, where this would not be an issue.

Or they use it to hack other systems on the network

Block access from the lab to the rest of the network, and/or get a separate DSL/cable internet for just the lab.

password-sniffing the other student's credentials when they log in from their VMs.

Use SSH for remote logins, and this will not be an issue. Even if a student does guess another student's VM account password, all they can do is screw up (or copy) someone else's work

Re:Safety?

[Joce640k]

Why would you have an account on a student's VM?

Re:Safety?

[Joce640k]

Unless they take down the network, e.g. running a rogue DHCP server. Or they use it to hack other systems on the network, e.g. password-sniffing the other student's credentials when they log in from their VMs.

So... nothing they couldn't do much easier/more safely by just pulling the network cable out of the physical machine and connecting it to their netbook?

Re:Safety?

[Joce640k]

All of that applies to non-virtual machines, too.

Re:Safety?

[h4rr4r]

Indeed. I am not suggesting otherwise.
I am only pointing out that VM software is not magic. It does the best it can, but cannot be relied upon to be infallible.

Re:Safety?

[Joce640k]

You know how I know you didn't even read the summary...?

Re:Safety?

[Joce640k]

if the VM has a full root account, with a network address on the global network at large, then it has the ability to, for example, run a priviledged NMAP scan on the entire network. Which can expose open ports or vulnerabilities on another machine that can then be used to leverage access.

Try reading the third line of the summary again. The bit where is says "segregated LAN" might interest you...

Re:Safety?

[LordLimecat]

I am not familiar with KVM or other Linux VM solutions.

I do know that during my VCP cert course, all students were provided with a VMWare ESXi infrastructure that was entirely virtual, contained in a vApp on a parent vSphere infrastructure. We all had our own connection on our own vSwitch, but no uplinks to everyone else, so there really wasnt much anyone could do to interfere with other students.

I suppose one of the students could try to defeat the vSwitch segregation via an exploit, but I think if they pull that off they dont need the class and deserve an instant A (assuming responsible disclosure).

Re:Safety?

[fwice]

Try reading the third line of the summary again. The bit where is says "segregated LAN" might interest you...

You made an incorrect blanket statement and I was pointing out a potential case to show this incorrectness.

You claim that having root on a VM is not a security concern -- and I am showing a case where that is incorrect -- even if that does not conform the submitter's problem at large.

Re:Safety?

[bobbied]

VM's are great for letting folks have "root" on a box safely for learning purposes. But I think one should consider what these boxes would be able to do on your standard corporate or school network. I assume that there is some kind of network security applied to the machines the students are allowed to touch. Having root access to a Linux box attached to the network will effectively bypass any existing security policies. I would be more worried about what the users can do to the local VM (Specifically to the network adapter settings).

Assuming you can control local VM configurations, or if you are using VM at the hardware level.....Training Linux boxes should be isolated on their own network segment (IP Subnet) and isolated broadcast domain. This will prevent your budding sysadmins from snooping on the network and learning things they shouldn't. The easiest way to do this is to put them on their own separate switch (unmanned switches) or VLAN (managed switches). If you need internet access for the learning experience, you will need additional equipment (a firewall/router) to allow that but I would allow only the minimum access outbound and probability put the training network behind a NAT to eliminate inbound connections.

I'm not sure if you would want to isolate each student's machine from the other students. I can see a lot of interesting, real world like, experiences for them trying to communicate between each others machines so I'd just put them all on the same subnet and watch the fun. Just DON'T put them on the same broadcast domain or on a routeable subnet as any "production" network.

Re:Safety?

[NemosomeN]

Considering these are probably VMs that have their own machine to play on, you'll need one hell of an exploit to have a fork bomb impact the performance of another VM.

VMware

[Anonymous Coward]

No matter what you use, unless it's hard to install and configure the slack-jawed neckbeards of Slashdot won't bless it with their magic wand.

Just get some flavor of VMware and move on with your life.

Re:VMware

[ttucker]

No matter what you use, unless it's hard to install and configure the slack-jawed neckbeards of Slashdot won't bless it with their magic wand.

Just get some flavor of VMware and move on with your life.

Yep, I love ESXi, it is fast and easy to install. It is also free. Just, if you plug it in to the school network, make sure to have it connected as its own zone to the firewall machine.

Vagrant

[Pinhedd]

Vagrant is a wrapper for Virtualbox and VMWare Workstation that accelerates the deployment of development environments.

http://www.vagrantup.com/

Re:Vagrant

[rvw]

Vagrant is a wrapper for Virtualbox and VMWare Workstation that accelerates the deployment of development environments.

http://www.vagrantup.com/

Please tell a bit more about when and in what situations you would want to use this instead of a plain Virtualbox VM.

Re:Vagrant

[Pinhedd]

It automates the setup of the isolated development environment. A company can put a Vagrantfile into a development repository along with any associated setup scripts. As long as the developer has VirtualBox/VMWare Workstation and Vagrant installed, they can type `Vagrant up` from within the repository and it will automatically setup the development environment within the development VM. This is a really easy way to ensure that everyone is working on the same page.

Re:Vagrant

[Anonymous Coward]

You can check in a Vagrantfile and Chef/Puppet scripts that create a working development, test, or production environment from a base OS install and Vagrant can spin them up with a single command. It simplifies creating a new development, build, or test environment, makes everything repeatable, and gives you assurance your stuff will run again when installed on a fresh box instead of a hand-crafted VM image. The Chef/Puppet stuff is applicable to production too, so through the course of dev/test you build up a cookbook that lets you deploy anything at the push of a button. No more huge, out-of-date documents saying "install these packages, configure this, create users, blah blah blah" that you spend hours scratching your head over. No more "works on my machine" puzzles. It's really the way to go.

Re:Vagrant

[FlipperPA]

+1 to Vagrant for local development. If there are any problems, you can easily just blow away the VM and start again. Vagrant scripts all of this with the same Chef repos you use for production. I modified and updated a Django Vagrant run-through I found on the net. It is free to the public on Github:

https://github.com/FlipperPA/djangovagrant

Naturally, this includes Python as well. I hope this helps gets you started, and thanks for going above and beyond with your students!

Re:Vagrant

[styrotech]

I was going to suggest that too.

Turn the problem on its head. Instead of supplying them with an actual virtual sandbox to play in (lots of work) - give them the ability to spin up a bunch of different virtual network/server configurations on their own machines.

Vagrant configs can specify multiple servers and networks etc.

They can easily be blown away and rebuilt, they can start sharing their own custom environments.

BTW: checkout salty vagrant. Salt is a Python based configuration management tool like Chef and Puppet but much simpler and lighter weight. And because you're teaching them Python and most Linux distros already have Python builtin, you don't need to install much else to bootstrap it.

Network Security

[Anonymous Coward]

I don't think you need to worry about OS security, since that is the point of using VMs. However, the "key" to this question is the definition of "segmented." There are host of nefarious and simple mistakes you can make to completely trash the network of the of the VMs. I would recommend disabling multicast.

Banning the use of fork() can't hurt either.

Re:Network Security

[ttucker]

I don't think you need to worry about OS security, since that is the point of using VMs. However, the "key" to this question is the definition of "segmented." There are host of nefarious and simple mistakes you can make to completely trash the network of the of the VMs. I would recommend disabling multicast.

Banning the use of fork() can't hurt either.

Yes, banning fork() can hurt, because how else are you supposed to learn about it. Also, running a forkbomb in a VM would have no effect at all on the VM host.

Re:Network Security

[NatasRevol]

running a forkbomb in a VM would have no effect at all on the VM host.

Well, if all the VMs run a forkbomb it might. Students do plan things like that once in a while. Like right before the start of class.

Re:Network Security

[Anonymous Coward]

Banning the use of fork() can't hurt either.

How do you expect the shell (or make) to spawn a new process without fork()?

Or rather, how do you expect sshd to spawn the shell, when the students try to log in?

Wait, scratch that... How do you expect sshd to fork() a new sshd process when the students connect?

No, wait... How do you expect init to do anything useful without fork()?

(Captcha: ponders)

Re:Network Security

[Andy Dodd]

So - have a lesson on forkbombs prepared for when that happens.

Re:Network Security

[ttucker]

So - have a lesson on forkbombs prepared for when that happens.

How about a lesson about how being little shitheads means doing something less fun/interesting in class.

VirtualBOX

[CheshireDragon]

Virtual Box is lightweight and it won't matter if they are root. A VM eliminates all that trouble.
"Oh you crashed the hell out of that machine, didn't you? oh well, reinstall."
Since you are segregating the network they will have no outside access and no re...WTF am I saying?...VLANs

Re:Virtualbox

[h4rr4r]

And is utter trash for anything that needs to be scalable.

It is fine for a desktop VM system, but it simply does not offer the management interfaces that other solutions have. Basically the options here are VMware and KVM. The first if you want a shiny GUI the latter if you are ok without one. Both will let you script everything they do, which will be very handy when you need to reset 100 VMs for the next batch of students.

Re:VirtualBOX

[h4rr4r]

Incorrect.

A nice forkbomb in a single VM can cause headaches for the rest of the environment. There have also been exploits to allow one to interfere with either the host kernel or other guests, we have no reason to suspect all those bugs are crushed. VirtualBox is a fine desktop VM software, it is not however suited to this task.

Re:Virtualbox

[Anonymous Coward]

And is utter trash for anything that needs to be scalable.

It is fine for a desktop VM system, but it simply does not offer the management interfaces that other solutions have. Basically the options here are VMware and KVM. The first if you want a shiny GUI the latter if you are ok without one. Both will let you script everything they do, which will be very handy when you need to reset 100 VMs for the next batch of students.

I run my entire local area network using VirtualBox VMs running on two physical servers which run Debian GNU/Linux. The various services are segregated into their own VirtualBox VMs such as DNS, DCHP, web server (externally acessible), web server (internal-only access), NFS, remote SSH access, etc. I manage all these VMs from the command-line and refuse to pussy around with any unnecessary GUI. Everything is scripted from VM creation to management. Stop this reliance upon point-and-click GUIs and teach the students to think and not be afraid of the GNU/Linux command-line.

Re:VirtualBOX

[Archangel Michael]

Forkbomb is only successful if you don't have limits on your VM environment. You have put limits on your environment, right?

Re:VirtualBOX

[NatasRevol]

A nice forkbomb in a single VM can cause headaches for the rest of the environment.

Then it's a very poor environment.

We're talking about one or many classes of students. If it's not built out to handle several VMs using their max CPU concurrently, then it's a very poor environment.

Heck, everyone compiling at the same time would shut things down if the environment is built poorly.

Re:Virtualbox

[h4rr4r]

Then you should be using KVM or Xen.
Virtualbox is not meant for that use and it shows it.

Re:VirtualBOX

[h4rr4r]

It has nothing to do with handling several servers or not. It has to do with the fact that if one VM can access all the CPUs it can keep them all busy.

The disk is the same thing, if you do not limit a VM to a fixed amount of IO it can simply tie up all access to the disk for another easy DOS attack. This goes for any and all shared resources. Not very hard to soak a 1Gb network link just to be a jerk.

Re:Virtualbox

[Anonymous Coward]

Wow, two whole servers. However did you scale so high?

Re:VirtualBOX

[NatasRevol]

If one VM can access ALL of the CPU or disk, then it's a very poor environment.

No sane sysadmin would set it up like that. And a good VM mgmt tool wouldn't let you easily.

Re:Virtualbox

[greg1104]

VirtualBox provides the VBoxManage tool for automating operations. It works perfectly fine for this sort of thing. One of my small servers at home is running 28 VMs with all management happening through the command line, and that hasn't even gotten close to whatever the upper limit is. You certainly can run a classroom worth of VMs on a modestly sized box.

The only major management feature that's much easier on VMWare than VirtualBox is moving VMs to new systems. That is very useful for large production VM deployments, but it doesn't sound necessary for this situation.

I use VirtualBox because there is an open source release that works across multiple platforms. VMWare is all closed, and Xen only works on UNIX-ish systems. Students in particular can benefit from running a VM copy of Linux on another host OS, because it provides a way to get familiar with the software on either a Windows or Mac laptop (which they probably own already). That requirement rules out Xen as a good example. And if you're going to introduce students to open source software via Linux, it's nice if you can present that lesson on an open source stack too.

Re:Virtualbox

[h4rr4r]

Which is why I also suggested KVM.

Virtualbox is neat, but it is very limited. It might be better to show them something that is actually used in industry.

Re:VirtualBOX

[h4rr4r]

I agree with your first point. All the current VM management tools do not prevent this behavior. I honestly am not in favor of that level of handholding, but I can see where some might be.

Re:Virtualbox

[crypticedge]

Can we stop promoting the use of Oracle owned software already? I really would like to see the evil beast die.

Re:Virtualbox

[lister king of smeg]

Can we stop promoting the use of Oracle owned software already? I really would like to see the evil beast die.

then use virtual box ose (open source eddition)

i wonder if we will ever see a "librabox" fork akin to the libre/openoffice(.org) split?

Re:Virtualbox

[crypticedge]

It's more than just that though, it's Java and dozens of other things. Even using things forked off it is too close to the beast to be comfortable.

No, we need to cut off all ties to it, and let it finally collapse in on itself.

Virtualbox

[lister king of smeg]

virtual box is great. its free/open-source well supported on windows mac and linux. itis easy to set up. has the ability to take snapshots on the vm to roll back at a moments notice. good documentation don't know what else you could need here.

VM is irrelevant

[onyxruby]

The fact that your using VM's is largely moot and goes back to the line of thought that VM's are somehow not 'real' computers. VM's run the same operating systems, software, have the same bugs, vulnerabilities and everything else as a physical computer. You need to patch them just like any other computer and you need to license them just like a regular computer. The fact that they are VM's really only makes two differences practical differences that matter, fist is that is easy to roll them back and second is that your aren't running on bare metal.

In other words you have a core issue that needs addressed of giving students root access to a computer. In an isolated environment this isn't necessarily a bad thing. Understand that they exploit root and see what they can do with it, however they are there to learn and if you can do so safely and without disruption of what your trying to teach then let them. Your focus needs to be on making it safe for those around them and that means making sure your VLAN and any related Internet access are properly setup. The lab is a lab and as long as you can make sure they aren't getting access to anyone persons computer than let them have at it.

A good rule of thumb is to roll your sessions back prior to the start of every single class. This always gives a fresh machine and the students will quickly learn how to set their VM just the way they want it.

Re:VM is irrelevant

[Archangel Michael]

VMs have one advantage that non-virtualized systems don't have. The ability to put several machines in their own sandboxed network, all managed by a single student who needs to demonstrate cooperating systems. Give every student a template of needed machines and a VM server and you have a small lab on every computer. One that is easily setup, cleared and re-setup for every class, and as needed.

VMs are a perfect solution for advanced computer systems management training.

Re:VM is irrelevant

[petermgreen]

The fact that they are VM's really only makes two differences practical differences that matter, fist is that is easy to roll them back and second is that your aren't running on bare metal.

The third is that the VM soloution is essentially an operating system in it's own right. Like any other operating system it can suffer from privilage escalation exploits.

Re:VM is irrelevant

[onyxruby]

Agreed, that contributes to the need for a properly set up VLAN. You can't rely on the fact that the machines are virtual to handle your security.

Re:VM is irrelevant

[Lunix Nutcase]

VMs are a perfect solution for advanced computer systems management training.

Which is not what is being taught.

I teach Python and C++ to high school students

Re:VM is irrelevant

[bobbied]

VMs are a perfect solution for advanced computer systems management training.

Which is not what is being taught.

I teach Python and C++ to high school students

How about your own personal Rasberry Pi? Best of both worlds....

Re:VM is irrelevant

[Natales]

Whatever dude. I touched my first "VM" in CMS in 1987 in an IBM 3870 system and it was outstanding, eye opening. Virtualization of any kind has always been about the "illusion" of owning something that you really don't. Heck, even in UNIX-based systems a regular account was a form of virtualization in a time-shared Mini. You can make a case that NAT is a form of network virtualization. It doesn't matter. The experience that a student can have using a "real system" is what matters. It's not important if the system itself is shared or not.

The network? that can also be virtualized these days. Check Nicira if you haven't. Technically, it's perfectly possible today to have a single student (tenant) to create a set of VMs completely isolated from each other, regardless if the system is based on open source or not (or a mix).

Disclaimer: I work for VMware.

Re:VM is irrelevant

[Archangel Michael]

It was more than just teaching programming. He also wanted access to other systems. You don't give access to production systems to students in cases like this. You build a sandboxed virtual world for them to play in. Pretending students aren't malicious is just ignorant wishful thinking. Most students are probably decent kids not wanting to cause harm, but accident prone and malicious students exist.

Re:VM is irrelevant

[onyxruby]

The experience that a student can have using a "real system" is what matters. It's not important if the system itself is shared or not.

I do believe that was my point, that VM's should be treated as "real" and not to get hung up on the fact that they are virtual.

SELinux on the host

[hpa]

Make sure you have SELinux enabled (and enforcing!) on the VM host, and keep the VMM software updated... there sometimes are security holes in VMM software which can be exploited. SELinux can help contain a breached VMM.

Re:SELinux on the host

[CaptainJeff]

This is true...
...if you have a valid policy set up for SELinux to enforce. This can be very difficult to construct, especially when you're trying to control the behavior of something like a VM.

For a student lab environment, this is likely to be overkill; if you have students in grades 9 thru 12 finding and exploiting holes in a VMM, you've got much bigger problems.

Re:SELinux on the host

[Anonymous Coward]

if you have students in grades 9 thru 12 finding and exploiting holes in a VMM, you've got ...

... really smart kids.

Re:SELinux on the host

[Anonymous Coward]

I highly doubt this is true. The last VM exploit I saw gave ring 0 on the host processor. SELinux is worthless at that point.

Re:SELinux on the host

[bobbied]

if you have students in grades 9 thru 12 finding and exploiting holes in a VMM, you've got ...

... really smart kids.

You can count on that one... So what do you do?

You need to have isolated this from the rest of the network using independent hardware/software, have really good backups that you can restore quickly, and be really good at monitoring things so you can catch them and pull the plug before they do any damage.

Personally, if I was teaching Linux System Administration and the students wanted to "try out" some of this stuff, I'd bless it, as long as the problems they caused where isolated to the lab and where discussed with me in advance. Any violation of those two rules would not be tolerated (though secretly I'd be saying "Yes!").

VLANs are your friend

[StoneyMahoney]

Just in case anyone gets a bit... shall we say "Adventurous" and tries to use their root access boxen to attack something they shouldn't, it might be worth isolating the VMs on their own VLAN away from the rest of the network, if you haven't already.

'Create' is the tricky part

[bill_mcgonigle]

Next year I'm planning on allowing students to create and run their own VMs

Running their own VM's is straightforward. Allowing the students to create their own VM's implies that they'll be root on the hypervisor.

Do you intend to run the hypervisor on the client machines of the DRBL system, or run a single hypervisor on the server and deploy the VM's there as DRBL clients?

To satisfy your requirements you probably want to run the hypervisor on the clients so they students can each have their own root on the hypervisor. This would require a hypervisor compatible with DRBL. I don't know how it works, but just from reading the description on the webpage, it sounds like it's geared to PXE booting a host OS.

If you go with Xen, you'll have to probably separately PXE boot Xen and then DRBL boot the Dom0. Which would probably work fine and get you decent performance, but it will expose the students to DRBL (is this what you want?)

If you go with KVM, the performance is a bit slower, but for a student shop that's probably OK, and you'll be able to DRBL-deploy the hypervisor and then let the students create their own non-DRBL (or DRBL) guests. This probably fits your model the best unless you have old hardware that KVM does not support - then you might need to go with the Xen-PXE-Boot model (because it can paravirtualize without hardware assistance).

You could also use VirtualBox, and while it offers a nice GUI, it's probably too simple for teaching your students about virtualization (it just feels like an app).

BTW, it sounds like you're doing great work based on that article. Kudos on your accomplishments and being an inspiration for others in your field.

Re:'Create' is the tricky part

[Solandri]

Allowing the students to create their own VM's implies that they'll be root on the hypervisor.

For most purposes (especially for teaching software), you can install a VM within a VM. You won't get the nifty virtualization features like direct hardware access (which means no 64-bit OSes). But several if not most virtualization software packages can do pure software emulation. Just for fun, I once used a Windows host to run a Linux guest, which ran an OS X guest, which ran a Windows guest.

Since submitter wishes to teach kids about setting up and running VMs, they're going to need root access. I don't see any problem with having them do it within a VM so they can both have root access yet not have control of the real physical host. Just be sure to inform them of the hardware virtualization features they'll be missing out on in a pure software virtualization environment.

Re:'Create' is the tricky part

[rarkian]

Yes I will be running the vm on the clients not the server. The server is a gateway/firewall fileserver. The clients in the classroom are actually in a VLAN. I have run VirtualBox before on the clients and it does work fine with DRBL. I thought about restricting the vm to run only natted virtual nics. I'm not even sure how to enforce that. How could I prevent them from bridging the virtual nic to the host nic? I think it's a module the host kernel loads that allows this but I'm not sure if that can be disabled and VirtualBox still function. Then I thought, forget it, why bother restricting the kids from running their own services on the classroom VLAN network. It would be a better learning environment if they could run their own services like their own http servers, sshd etc and allow their friends to use those services. Great way to learn, I think. If someone runs a dhcp server, that would be a problem but it would only affect my classroom not the entire school. Plus any vm they have up would end up being shutdown when the clients shutsdown at the end of the day. Do you think this is a good idea or am I being too trusting?

You can NAT the network off and and don't forwardi

[Joe_Dragon]

You can NAT the network off and and don't do port forwarding to the out side also have a quick kill where you just need to pull a cable to cut the VM's off from the rest of the network.

Linux in school??

[TheDarkener]

Don't let the higher-ups know you're running a rebel operating system, you might just get canned. What use is running Linux in school anyway, when the students should be learning REAL job skills (I.E. Microsoft Office)? /sarcasm

(Sorry, I have been tainted by the education "industry" when it comes to anything Linux in school).

Re:Linux in school??

[iggymanz]

good little corporate droid trainees should also have a cisco phone on their desk which is surrounded by fabric covered foamboard or cardboard.

VMWare, Ubuntu and Puppet

[i_want_you_to_throw_]

I see this as being similar to when we needed to have all of our developers in my company working in an environment that absolutely matched the production environment. Just use VMWare on each individual machine, run an Ubuntu image in that and best of all use a Puppet script to customize it and give 'em the goodies they need. The beauty of this is once the kids screw it up (and let's hope they do, they're learning after all) then you can rebuild this back to a pristine machine in no time. Good luck!

Re:VMWare, Ubuntu and Puppet

[i_want_you_to_throw_]

Ubuntu worked for us but of course you could use CentOS as well.

Re:You can NAT the network off and and don't forwa

[h4rr4r]

No, stop!

NAT is not the correct solution to this nor would it help. NAT does not stop anyone scanning outward, the NAT router will setup the address translation just as it should. VLANS are the correct answer. Pulling physical cables is too much work, and cannot be done remotely.

Straightforward

[Synerg1y]

First, you're going to want to set a segregated network that cannot talk to the main network (A DMZ), your router accomplishes this in most cases.

Second, there's 2 big options for you to look at: VMWare ESXi & Xen both are hypervisors that run on server hardware and can host as many VMs as the hardware can handle. Hyper-V may also be an option if you're part of the MSDN alliance. Install and configured chosen host software.

Third, set up individual VMs, you're on a DMZ, so giving root is fine, the main network cannot be reached. You should be able to create a template and spawn the rest of the VMs off that.

Fourth, have the students remote into their VMs.

Alternate perspective

[Sparticus789]

You could also look at it like this. If your students can crack their VM environment and run wild, hacking away, changing grades, and setting up Paypal fraud websites, then you have taught them very well and they will go on to a long and prosperous career, hopefully working for the good guys.

SmartOS, allows for advanced virtual networking

[exabrial]

SmartOS is pretty amazing. You can create virtual environments that share a kernel space, meaning that YOUR os is running directly on the hardware, making it _extremely_ fast with almost no overhead. The file system (ZFS) is also 'shared' using zones and pools so there's almost no cost there either. Migration a vm between SmartOS hosts is also a pretty amazing thing. You can also create virtual NICs and route/bond/segment/tapdance. SmartOS has it's roots in Solaris, so it's a little different than Linux, but for the most part anyone with Unix experience can figure it out.

oVirt

[knarfling]

Depending on your equipment and the time you want to spend, oVirt might be an answer.

Although it is still fairly new and is in development, it runs on CentOS6, is free, can handle multiple guest OSes, can create VM's from a template, and has a power users portal page where trusted students/employees can create their own VM from supplied templates. This way, no student would have access to the host OS, but could create a VM as needed. The downside is that it can get quite complicated to set up the system, and could take a bit of time to learn and set it up properly. Since it is free, you are also dependent upon community support.

You can access more info here.

ESXi

[meowgoesthecat]

ESXi. Its free, powerful, and offers a lot of pre-built appliances. I don't see any safety concerns if the network is segregated. If you have specific VM's that you want the students to learn within, keep screenshots of those so that you may roll anything back that gets damaged. This is great because it allows them do pretty much anything they want without creating a maintenance headache for you.

If you want to teach them about specific technologies using VMs that go hand and hand with programming (like source control, bugzilla, configuring web servers, etc), turnkeylinux.org offers many free linux appliances that will make your job easy.

Re:You can NAT the network off and and don't forwa

[Joe_Dragon]

Pulling physical cables is a quick and fast way to know they are not on the network and that is more of a way to backup to remote control. What about a firewall box on the link from the switch the VM's are on to the rest of the network?

VLANs, RH Virtualization Security manual, virt-man

[raymorris]

Thanks for going the extra mile with your students.

As AC said, a separate LAN or VLAN, or multiple separate LANs/VLANs handles most of what's posted below. For example, a rogue DHCP server would only be visible on that VLAN.

Red Hat has a Virtualization Security section in their manual:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/chap-Virtualization-Security_for_virtualization.html

CentOS/RHEL includes comprehensive support for KVM with virt-manager. While VirtualBox et al are fine for running one or two virtual machines on your desktop, for many VMs, with new ones created and removed each semester, the enterprise level support of KVM built into the distro is more appropriate. That support includes creating VLANs within the same management interface, for example, and integrates with the built in storage stack administration tools. Again, VirtualBox may be simpler to set up for one or to two machines, so I'm not saying it's not good - it's just not the best tool in this particular scenario. In this type of scenario, the KVM / virt-manager / virsh stack that RH baked in is probably a better match to the needs.

Re:You can NAT the network off and and don't forwa

[ttucker]

You can NAT the network off and and don't do port forwarding to the out side also have a quick kill where you just need to pull a cable to cut the VM's off from the rest of the network.

If you were joking, I got a pretty solid LOL out of it.

I'm aware of two popular VM's

[CosaNostra Pizza Inc]

Oracle Virtualbox and VmWare. I use VirtualBox, which is free.

Re:You can NAT the network off and and don't forwa

[h4rr4r]

It is not fast nor quick at 2am. Which is when one bored kid is going to try to find out how much fun he can have with an arp black hole or other such silliness.

What about it? Should there be one? Of course it should probably even limit traffic to just http and other services they absolutely must have, there should also be an IDS on their network segment. That does not change the fact that VLANing off these folks is the best practice and that NAT offers nothing extra for this. You would not be trying to protect the VMs, but be protecting others from them.

Re:You can NAT the network off and and don't forwa

[arth1]

Even VLANs allow for DoS attacks - the VLAN runs on the host, not the guest, and bypass the limits you set on the guest. A malicious user controlling one or more VMs can flood the VLAN(s) and cause the host to slow down (or worse).

Other ways to attack a host or other guests from a VM apart from networking include (but are not limited to) shared resources like USB, CD/DVD, serial, disk (sync flood!) and perhaps most of all, hardware accelerated graphics.
If you really have to protect the host and other VMs from each other, you need to turn off all shared resources, and run the VM hypervisor/manager under SELinux and configured(!) cgroups, preferably with each VM having its own disk.

Re:You can NAT the network off and and don't forwa

[h4rr4r]

Actually I was suggesting not sharing NICs and using VLANs on a managed switch, if at all possible. So each VM has its own NIC and VLAN. They would not be allowed to talk to each other.

I should have made my proposal more clear.

APT-Cacher, Squid

[SgtChaireBourne]

A good rule of thumb is to roll your sessions back prior to the start of every single class. This always gives a fresh machine and the students will quickly learn how to set their VM just the way they want it.

They can start each class with a fresh snapshot. In effect they would be restoring from backups. The configuration files from some other networked storage or their thumb drives and the applications themselves from the repositories. I've done something similar, but on bare metal, and after about half a dozen times they don't notice -- it had become such second nature to install and restore applications. Heck you might even have them practice installing the whole system from scratch. If you go that route, they can become quite proficient with installation and resource allocation. PXE booting a netinstall image helps there.

However, once you start to load packages from the net things can really slow down unless you prepare. The best way is to have a cache like APT-Cacher or Squid on your LAN or host system and have them configure their systems to use it for APT. For the cache to be most effective, you have to pre-load it before each class. That's easy and can be done while doing other things. It only takes time not attention. But once you have the cache loaded, installation will fly and can be done in 15 - 20 minutes. After that they weren't shy about installing on their own computers at home or helping their friends.

Re:APT-Cacher, Squid

[tibit]

Better yet, use squid and iptables to set up a transparent proxy. Then there's no need to configure any end-user systems at all.

It depends on what you're trying to protect

[dankney]

So far, I see lots of advice about VM breakouts and network isolation. If this were a production datacenter where uptime was a criteria, this is all well and good. I suspect that this isn't what you need to hear, however.

I see three things you could be attempting to protect:

1) The larger school network.
2) The VM host infrastructure.
3) The VMs themselves.

1) A student on a VM is no more dangerous to the network than one who can connect to the school wireless with a laptop or smartphone. If the lab uplinks to the same network as the broader access, your risk profile is unchanged.

2) Make sure the VMs can't route to the host and keep it patched. If a student managed to break out of a VM in a patched hosting environment, do some forensics and find the bug then sell it. It's probably worth more than you make in a year. Seriously, if they can do this, they deserve to win. You might as well worry about protecting against nation-state sponsored attacks.

3) Make sure that the class work is backed up (a git server, perhaps) and then don't worry about it. Seriously, just throw the VMs away after each class (or every night, etc) and start with a clean one the next time they log in. Don't spend time trying to outsmart a classroom full of bored highschoolers. Instead, make it so it doesn't matter when they break something.

Re:VLANs, RH Virtualization Security manual, virt-

[Anonymous Coward]

Excellent advice.

KVM is commercial-grade, and works amazingly well with Centos.

If some of your better students are up to the challenge, you can get them to co-operate with some large-scale VM management tools like OpenStack. They might even set-up the management systems to make it easy for you to repeat the process for your next batch of students! OpenStack is largely written in Python, so they can get extra creative.

Man

[jon3k]

I would have killed for this in high school. Kudos to you, what a great job.

Re:Man

[avandesande]

Me too- would have loved to have several instances of DOS running at once ;-)

Re:You can NAT the network off and and don't forwa

[arth1]

Not themselves - each other. And who else may be using the host machine.

administering VMs doesn't require root

[SuperBanana]

Allowing the students to create their own VM's implies that they'll be root on the hypervisor.

No, it doesn't. Virsh only requires to be told to let you manage VMs, done via group membership. There are also several web-based VM management tools so they don't even have to have shell access.

Also, you have heard of sudo, right? And limited command shells?

There's a lot of underwear-ringing here by people who have no fucking clue what they're talking about.

you must have missed yesterdays virtually idential

[maliqua]

the answer was prox mox, and the question has lost luster

Have you evaluated renting cloud time?

[MikeHalcrow]

There are a lot of good answers here to your direct question, but I'd like to step back and look into solutions that are recently available for the more general problem you are facing.

I have to wonder what it's costing the school district to acquire and maintain the hardware to run your classes. On top of that, you're having to worry about the overhead of securing/patching and maintaining backups.

(Disclaimer: I work for Google on Compute Engine.)

Have you evaluated whether an IaaS service like Google Compute Engine would be more convenient and cost-effective? Security, backups, and persistent storage are all taken care of for you. Google's base VMs are 13.2 cents per hour. For a class of 30, that's about $4 per class session. There are about 180 days in a school year, so that's $720 per class for the entire year. If you have 4 classes a day, that's about $3,000 for the entire year, assuming your VMs are all running the entire time every class session. In practice, if I were teaching the class, I'd lecture for 3 days a week and have VM time 2 days a week, with the option of the students being able to access their VMs outside of class from home, so the actual cost will probably be lower.

As far as hardware is concerned, Chromebooks are $250 each. I bet you're spending significantly more than that per machine in your labs. You can use the terminal tab in ChromeOS to SSH into the VM instances.

Have you considered an IaaS provider? If not, I'm curious to hear how the current offerings out there in the market fall short of the solution you're looking into now.

Re:Have you evaluated renting cloud time?

[smylingsam]

This is a very good suggestion! However as soemone who has looked into this technology, there are a few pitfalls to be aware of.

The tos can be easily violated closing down the whole school or installation or incurring extra bandwidth costs if someone breaches the cloud providers tos by loading viruses, opening a file drop or distribution drop site, proxy, game server or such. You can also risk these events if you plan to demonstrate programming methods that could have a bug that suddenly consumes excess bandwidth or someone interacts, by accident with the vm host causing a crash.

Since you are dealing with kids who test boundaries as a group --someone is bound to do something far more clever then you plan for. Get your plan ready to respond to such events before they occur if you go the cloud route make certain that one bad apple cant incur extra costs or cause a site wide outage. So talk to the cloud provider and find out how and when your site can incur extra costs or violate the tos due to student behavior.

Re:Have you evaluated renting cloud time?

[MikeHalcrow]

This is a very good suggestion! However as soemone who has looked into this technology, there are a few pitfalls to be aware of.

The tos can be easily violated closing down the whole school or installation or incurring extra bandwidth costs if someone breaches the cloud providers tos by loading viruses, opening a file drop or distribution drop site, proxy, game server or such. You can also risk these events if you plan to demonstrate programming methods that could have a bug that suddenly consumes excess bandwidth or someone interacts, by accident with the vm host causing a crash.

Since you are dealing with kids who test boundaries as a group --someone is bound to do something far more clever then you plan for. Get your plan ready to respond to such events before they occur if you go the cloud route make certain that one bad apple cant incur extra costs or cause a site wide outage. So talk to the cloud provider and find out how and when your site can incur extra costs or violate the tos due to student behavior.

Have the project administrator set firewall rules to only allow incoming SSH from the public Internet, and a then allow network communications between the VMs in the project.

Don't worry about consuming "extra" bandwidth between VMs. Google's internal network can handle anything the students throw at it. Ingress and egress network traffic within the same zone is free. See GCE pricing.

Also, don't worry about the VM hosts going down due to anything that happens in the guest. If a high school kid somehow figures out a way to bring one down, we'd like to talk to him about a possible career in virtualization and security. And we've been known to pay out rewards for that sort of thing.

Re:Have you evaluated renting cloud time?

[smylingsam]

wow that is a favorable billing structure for google computer! however the issue Im trying to raise is int he aup https://developers.google.com/cloud/terms/aup in which a number of things like running website mirrors, providing viruses, etc are violate the rules and may be met with automatic shutdown of one or more instances or possible accoutn suspension. While Google compute may view a ddos emanating from a student's use of a vm more favorably then amazon etc it still is question the op needs to factor into their considerations of hosted vm solutions. Once it's planed for (expect the best, plan for the worst!) and discussed during the planning and purchasing phase then I would say the provider is a keeper :>

Why manage it yourself at all?

[qzzpjs]

Point your students at VirtualBox's download page and give them a pre-created image for your lab. Let them learn how to setup the software, configure the image, etc. It would be a good lesson for them in visualization and your work would be minimal.

You could pre-setup the security in the image with a generic user, firewall access as needed, maybe a home folder on NFS. If they have problems, they can just start the image over again.

A bit of cloud security author advice

[MattW]

So, I co-wrote this book on virtual security and am a former VMware Cloud Solutions Architect. And I'll preface this advice by saying that, if you want to talk more in depth, feel free to ping me. First initial, last name at gmail will work. (The email I have attached to slashdot I glance at occasionally, but it gets almost purely spam and so I'd likely miss anything.)

From my perspective, the first question is which hypervisor to use:
- VMware is mature, you can get a free license for the base hypervisor (which is quite feature rich; this is no trial product) for up to 32GB per physical box, is widely used. If VMware remains as relevant in the future as it is now, it's actually a very solid skillset to have.
- If you have physical hosts over 32GB, VMware ceases to be free
- Some features require more advanced VMware stuff, including vCenter server, which isn't free - for example, VMware's live vm migration feature (vMotion)
- VMware is almost entirely closed on the internals; hypervisor is closed source (other than a not-useful-for-your-purposes "open source" bundle that contains their modified GPL code only); they have a bunch of APIs for internal functions (ie, tracking changed blocks on the virtual iscsi devices, for example), but those are generally restricted to partners; so if your students want to actually hack the virtualization layer, they can't. Then again, letting them do so wouldn't really be safe.
- On the other hand, VMware layers do have nice APIs that are reasonably accessible for doing non-internals stuff; things like powering VMs on and off, changing their allocated RAM and cpus, etc
- VMware has a nice set of tools, including CLI tools, which work well even with the free versions, that can allow you to move virtual machines in and out of specific hypervisors (not while the VMs are powered on), and into and out of VMware's desktop products (Workstation for Windows and Linux, Fusion for Mac). (google ovftool for the cross-platform CLI tool, for example; it can import/export to/from ESX, vCenter Server, Workstation, Fusion, and vCloud instances)
- VMware has a nice set of tools for snapshots and backups, even on the base hypervisor; for example, I have a personal ESX box at a provider and I use this tool to back up the VMs back and forth, which can be done from outside the OS without powering the VM down, and it's free.
- I found using some things I'd think of as mandatory for a lab environment (ie, thin provisioning) were just built-in on the VMware side and required a fair bit of extra work and added extra wrinkles

The virtual networking on VMware is dramatically more mature from my experience; my experience with Xen & KVM is now dated (it's been 2 years since I was in the thick of writing that book, which was the last time I was really in the thick of exploring the open-source hypervisor networking bits). I found that depending on the version of the hypervisor OS, which hypervisor, which kernel, which guest, etc, you could fall into all sorts of traps. I had some examples in the book where I showed, for example, generating and applying ebtables configurations to the host OS (the Xen Linux hypervisor OS) to block forged frames from coming across the bridge from one of the guest Linuxes, for example.

Compare that to the VMware side, you could in theory wire up everything to dumb hubs, even, and enforce network separation at the hypervisor layer with VLAN tags applied to the portgroups where you attach VMs. (Warning: not suggesting you blindly do that; but VLAN enforcement on the VMware side is fairly rigid if configured in a good way.)

My own book is a fun read for some of these concerns, although Haletky's book is probably the canonical work on the subject. (Although it is -slightly- dated from bein

Re:VLANs, RH Virtualization Security manual, virt-

[AlphaWolf_HK]

Another thing to add to this - my enterprise VM knowledge is pretty much limited to VMware, and I do know that if you use VMware, you can use the VMware Distributed Switch (VDS) which supports PVLANs. Place each individual set of VM's that belong to a given student into a community PVLAN, and make your default gateway a promiscuous PVLAN.

Re:You can NAT the network off and and don't forwa

[bobbied]

It's not really VLAN's that are the issue here.. It's "Broadcast domain" isolation. Separate sub-net and broadcast domain is required (usually accomplished using a VLAN on a managed switch, but not always). NAT is also somewhat useful depending on where you put the WAN connection in your network. But, you are correct, you *really* need a firewall/Router that manages the external network access to the *MINIMUM* necessary in *BOTH* directions and a NAT only works in one direction.

KVM

[loufoque]

KVM is the virtualization technology that works the best with Linux.

Have you looked at the Hak5 website.

[LWATCDR]

http://hak5.org/episodes/episode-820
They set up a server cluster for hacking competitions. It may well be worth your time too look at what they did.

This is what SELinux / MAC is for...

[Kahn_au]

You have a couple of options;

1) Use a container type environment without virtualisation like http://opensource.com/education/12/8/harvard-goes-paas-selinux-sandbox
2) Run your VM's on a RHEL based hyper visor with KVM and get the benefits of sVirt ( http://selinuxproject.org/page/SVirt ) isolation for free via libvirt.
3) Look at something more like OpenShift Origins to do PaaS with mandatory access control.

Either way, a huge kudos to you. I know I failed IT in high school because I disagreed with java>all and I am excited to see at least one educational institution heading in a much more promising direction.

Cheers,

Kahn

Re:VLANs, RH Virtualization Security manual, virt-

[raymorris]

libvirt, as used by CentOS, also has virtual switches. The libvirt virtual switches can do IP masquerading NAT, routing mode, or complete isolation mode.
http://wiki.libvirt.org/page/VirtualNetworking

VMS

[bbelt16ag]

I would suggest vmware KVM or XEN.

Virtual box + vagrant + sudo user

[ShadowFoxx]

Since each student will probably only need 1 or 2 vms virtual box from oracle would be just fine and free. It also works well with a developer / system admin practice tool call vagrant... Which allows one to spin up, roll back, and destroy virtual machines at will via command shell as if one was SSHed into thier vm. (Will force your students to learn how to manage thier machines without a GUI) and if they break something developing or just brick themselves administering its as easy as typing vagrant destroy and then vagrant up and back in business. As far as root access: Yes they should be given the power on their vm to root and then discouraged to use it. They should be encouraged to set up appropriate user/groups and permissions on their vm as consistent with Linux/unix best business practices and appropriately manage their sudoers file. They can elevate themselves when necessary via the sudo command, and disable telnet completely and disable root login through SSH. All this will start good hygiene and practices for day 1.