Advice on Virtualising Standalone machine

[Bunce]

Hi All.

Our Finance department currently utilise a standalone machine to submit financial data to a Government Department. It currently sits underneath one of the Finance staff membets desks, and is patched directly to our DMZ. Its not connected to our Production LAN. The client software uses a custom VPN client and requires use of a USB smart-card kept physically by the staff member.

As rebuilding this machine as it runs out of warranty is a nuisance and the physical (not to mentioned security) issues raised by maintaining a second PC underneath the members desk are a problem I was thinking of virtualising this box.

- Our ESX servers have an uplink to the DMZ so placing the box on the DMZ isn't an issue.

- Getting the staff member access to the machine can be done and secured via the VI Client or the Virtual Centre web interface

- Mapping the smart card f(rom the users Production LAN box?) to the VM presents an issue as I don't believe VI supports USB mappings.

- I'm also uncertain that they would allow us to take the smart card even if secured in our server room should there be some type of USB hub we could plug it into..

So I'm guessing that leaves me a coupld of options:

- Try to implement some sort of USB-Over-IP solution between the users box and the VM, however this would require communication from the Production LAN to the DMZ and hence would require a path through the firewall.

- Perhaps use a Remote Desktop connection from the user machine on the LAN to the VM and try to se the 'Smart Card' redirection offered via the RDP client? This would also require a path through the firewall.

Wondering if anyone had any other suggestions? The machine are XP/Vista and we're in Windows shop using ISA as our firewall. Using ESX 3.5, VC2.5.

Thanks in advance,

A

[RParker]

I wouldn't use ESX, I would put it as a VM on VM Server, that way you can still utilize the USB port.

[khughes]

I agree since you need to use a smartcard usb it would be easier to just go the route of installing vm server or purchasing workstation and running it on a desktop machine. You can shut it down and back it up every now and then so if that box ever does die you can just restore the VM and fire it back up in no time.

• Kyle

[Bunce]

hmm - thats true. Thanks.

I guess the only minor downsides would be:

• her machine would need a 2nd NIC to patch through to the DMZ,

• she wouldn't be able to access the VM from any of our machines (our users seem to roam/travel quite a bit)

• we'd need to reinstall VMServer / Workstation and relocate the VM when her machine needs to be replaced (or if she relocates), although this is a lot easier than rebuilding the whole box.

But they're all relatively minor issues.

Thanks again.

[khughes]

Why would a second NIC be needed, you can just install server/workstation on your current box or the box you replace it with? How do you your users access it now? Even though it is still a virtual machine, you should still be able to access it the same way

• Kyle

[Bunce]

The current standalone Finance box is patched (physically) through to the DMZ. Her production machine is patched though to our LAN (she has 2 machines under her desk)

If I were to virtualize the FInance box, and run it under VMServer or Workstation on her LAN machine, then there needs to be a way for the VM to connect to the DMZ -> hence second network card which would be bridged (virtually) to the VM and patched physically to the DMZ as was the previous physical Finance box..

Is there another way this could be done?

[khughes]

I re-read your origional post and now can understand your thinking for putting it on the workers primary computer (as the 2nd computer under is an annoyance). The problem is by putting this 2nd NIC on the computer that is attached to the DMZ could cause some security issues. I'm not sure if you can pipe the NIC connection straight from a vm server nic to a physical nic like you can in ESX. I looked at my workstation program on my desktop and you can't tell it which physical NIC to use.

My thoughts (before re-reading your origional post) was to virtualize the box, and then run it from the same box you virtualized it from, maybe blow it out and then run it from there I don't know. That was my thinking at least. You should definatly look into the security issues you or your department might have connecting a box up to a live LAN network and a live DMZ network at the same time. Thats a big big big no no here

• Kyle

[Bunce]

Agreed on the security issues, although from memory in VM-Workstation at least, you could bridge a virtual NIC to a Physical, and actually disable the NIC on the physical box, and have it still work..

But yeah - still sound a bit risky..

[davidm3281]

I think having a box that is located outside your server room and tied directly to your DMZ is a huge security hole. I hope you don't have examiners come in and want to see your physical and logical network topology. What is to stop this user from plugging her own machine into the DMZ? What safe-guards are in place to ensure the machine is properly patched?

I personally think you should virtualze this machine and get it out of the user's office. You have a few options, of course:

Use VM Server or Workstation -- but I'd recommend ESX Foundation. It just runs better and you have a lot more options with image backups, etc.

If user must remote into server, buy a remote control product. We personally use RemotelyAnywhwere to provide console access to our servers to support folks, etc. What's really nice about it is that security can be setup on a per user or group level and user auditing enabled to capture screen recordings of their activity and dump to a centralized location.

You can also consider using RDP and allow user to remote desktop directly into server console or user session. You could use RecordTS for the same type of user auditing/recording as well. Works nicely and we use this, too, for our terminal services environment. For even more security, you could buy a wise thin-client device and only allow its IP to RDP into the server. This way she'd have to use the dumb terminal and not her PC to get into the server to perform her tasks.

Regarding USB requirement. We use USBAnywhere which is a USB-over-TCP network device. In your case, you could locate this directly in the user's office on your internal network, if needed. As long as the server could route to it, you should be fine. I have about 6 of these in our office that we use from ESX for USB Hasps and it works fine.

If you're having to rebuild the box.... you'd be far better off using ESX and may be leveraging your hardware investment for other virtual projects that reside on the DMZ.

This is how I got started. I started with one new physical server that we installed ESX on and later migrated as much as I could to it in order to free up other servers....

[TomHowarth]

I think having a box that is located outside your server room and tied directly to your DMZ is a huge security hole. I hope you don't have examiners come in and want to see your physical and logical network topology. What is to stop this user from plugging her own machine into the DMZ? What safe-guards are in place to ensure the machine is properly patched?

I personally think you should virtualze this machine and get it out of the user's office. You have a few options, of course: Use VM Server or Workstation -- but I'd recommend ESX Foundation. It just runs better and you have a lot more options with image backups, etc.

There is a requirment for Smarcard authentication, ESX does not have a usb stack.

If user must remote into server, buy a remote control product. We personally use RemotelyAnywhwere to provide console access to our servers to support folks, etc. What's really nice about it is that security can be setup on a per user or group level and user auditing enabled to capture screen recordings of their activity and dump to a centralized location.

This is a machine accessing an External resourse, the secruity requirement is external to the user, they have no say in how access security will be handled, just here is your smartcard login.

You can also consider using RDP and allow user to remote desktop directly into server console or user session. You could use RecordTS for the same type of user auditing/recording as well. Works nicely and we use this, too, for our terminal services environment.

again userful information but not pertanent to the original users problem of how to have access to a DMZ and be able to utilise a USB smartcard via Virtualisation.

For even more security, you could buy a wise thin-client device and only allow its IP to RDP into the server. This way she'd have to use the dumb terminal and not her PC to get into the server to perform her tasks.

posible, but I feel the the smart card is used for application access not machine access.

Regarding USB requirement. We use USBAnywhere which is a USB-over-TCP network device. In your case, you could locate this directly in the user's office on your internal network, if needed. As long as the server could route to it, you should be fine. I have about 6 of these in our office that we use from ESX for USB Hasps and it works fine.

USBAnywhere could be used however it would have to stay in the DMZ environment.

If you're having to rebuild the box.... you'd be far better off using ESX and may be leveraging your hardware investment for other virtual projects that reside on the DMZ.

Sometime another technology is a better option, I used to regularly adviseclient to install a VM server host to run a virtual License server or VC this allows for easier recovery if the license server host or phyiscal box has gone down, I now advice a Free ESXi host for the same job.

This is how I got started. I started with one new physical server that we installed ESX on and later migrated as much as I could to it in order to free up other servers....

This is not a Server but a single device. the Original post already has a Virtual Infrastructure in place.

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth

VMware Communities User Moderator