VMware Horizon Community
MrBeatnik
Hot Shot
Hot Shot

Recording events within linked clones

Hi folks.

Ok, so a user has started up a linked clone, logged on, and been up to no good.

General nefarious activities; hacking, browsing for illicit material, downloading pirate material (not the ARRRRRRR type).

The user finishes, logs off, and the clone is destroyed.

View 5.0. Our setup would probably be using FusionIO type cards, rather than backend SAN, for our linked clones.

We are an educational environment, so "open access" clones would be the norm for us.

Normally, with physical machines, our systems (IDS and other logging types) would notify us of the user and machine.

We could then go to the physical machine and check the local event logs, and recover deleted items from the disk. Particularly important if we have been asked to do so as part of some investigation...

Anyway, how would we go about getting a similar process with linked clones?

What do you use to ensure log/monitor linked clones? If you needed to investigate some activity, how would you go about it?

How can you prove that a particular user was doing a particular activity at a particular time?

Thanks.

Reply
0 Kudos
4 Replies
dvhorvath
Enthusiast
Enthusiast

One possibility might be to avoid refreshing the linked clones on logoff, and set them to refresh at a set interval instead. If you could determine that you would need to keep X number of days' worth of activity on each linked clone, you could set the refresh interval for that number of days. That would allow you to keep the sort of historical data you're looking for, but could open the machines up to other vulnerabilities if you're not careful. You'd really need to have up-to-date antivirus software and definitions on your linked clones for this to work.

Also, it may not be possible to completely prevent certain types of activities on these machines, but it might be possible to throttle the available bandwidth for those activities to such a degree that they're not really usable. You could make the case that while it is possible to use P2P software on your network, it's just not pleasant to do so. 😉

Without knowing a lot more about your environment specifically, those are the only ideas I could come up with. It sounds like a really tricky balance between openness and freedom on the one hand, and efficiency and ease of administration on the other. Good luck!

Dave

Reply
0 Kudos
MrBeatnik
Hot Shot
Hot Shot

Thanks for taking the time to reply!

There is still an issue with deleting the clones after x amount of days; if the user was to do the actions on the day of deletion, then we are back to square one, plus there are the other vulnerabilities as you point out. As for bandwidth restrictions... well we do want to make the service as close as possible to the current physical service. Whist we have methods to restrict activities (filters etc), we don't want to make any changes that might see a significant change just for the VDI service; although just targetting bandwidth to P2P would probably work, the other naughty activities might be the bigger concern.

We are a University and Windows 7 in all student machines. Most machines are in open access areas.

Most students do some work from time to time, but the biggest usage is IE with Facebook and Youtube, etc.

We have an AD environment.

Please let me know if you need any other info that might help you help me Smiley Happy

We will be looking at the Events DB so we at least have a good log of who logged on where, and when, which can tie in with out other reporting services. I was also considering dumping the Windows Event Logs from the session to a store of some kind, but this wont capture other items of interest.

Can I presume from your answer, and no other replies, that this has not been a concern in other setups that are out there?

Reply
0 Kudos
dvhorvath
Enthusiast
Enthusiast

I worked at a University for years, so I know exactly what you're up against here. It's easy in a business environment to just use web filters and packet shapers to protect people from themselves, but in an environment where you have to honor academic freedom and open access to information, IT becomes something of a nightmare. And it gets worse with VDI, because now a user could be logged into a VM from literally anywhere in the world, so it's not even like in the old days when you could link improper activity to a physical location.

I see what you mean about refreshing the systems on a schedule, too. There's no way to do that on a rolling schedule, to get rid of anything more than X days old and keep the rest, which would really be ideal here but just not how it works.

But I just thought of a really hair-brained scheme that might help track naughty behavior, as you put it. You could log information as a user connects to a View desktop, including the date, time, username, IP address of the View desktop and the IP address of the client device being used to connect. That's exposed in the Volatile Environment section of the HKCU registry hive. Granted, some of that is already in the View Events database, but it seems to me it would be easier to write all of that together to a new database specifically designed for this. Then, if you were able to filter all of the View desktops through a web proxy that could also maintain information about sites visited by IP address, you'd be able to cross-reference the web sites that shouldn't be visited with the time and IP address in your log file to determine what user was logged in at the time, and even what client device they were using. It's a little convoluted, but if it worked you could go back to refreshing the desktops at logoff, as all of the logging information would be decoupled from the user's session. And, since all of the View desktops should be on their own VLAN or subnet anyway, you could also target just those systems for packet shaping to limit P2P bandwidth at the same time.

I'm not trying to offer any solutions here; I think your situation is much too complex and specific to be able to do that. But it seems like a friendly back and forth conversation about it can only help to bring up new and different ways of approaching the problem. Please keep us all posted and let us know how you tackle this one. I think a lot of people will find it interesting.

Dave

Reply
0 Kudos
MrBeatnik
Hot Shot
Hot Shot

Thanks.

We will be meeting with our security team to find out exactly what type of information they want, and what is feasible.

I'll update the thread when I have any info.

Reply
0 Kudos