How secure is FreeBSD in a Linux VM?

[Sparda]

So, some of you who care/notice things on web pages may have noticed that my avatar was missing for about a week. This was due to some kind of hardware failure in the  server (some thing wasn't good in the hard drive). Non the less it's up and running again (and I managed to rescue in my www directory).

However, I have made some substantial changes. My second server is now my only physical server, serving internal stuff. But (if the title didn't give it away) my web server is still running on FreeBSD but now in a VM on the remaining server. The server is running Ubuntu server (yep UBUNTU!) and FreeBSD is hosted in VMware Server (the intent still been that internal server stuff and servers with internet exposed services should be kept separated 'physically')

I was just wondering how easy it would be for some one to tell (using service finger printing) that FreeBSD is running in a VM and figure out what it's host OS is.

I can see straight away that this server would be completely vulnerable to any problems that turn up in the VMware kernel module. I was wondering to what degree a problem in the Linux kernel would compromise the server.

Any one got any clues?

[mubix]

You are only vulnerable on port that you make public, IP (TCP/UDP), and the services that you run on them. Lock down that public facing server, put your internal only VMs to attach to your internal interface on the server and you should be good. If you are running only one interface you could be looking at problems. A quick net diagram would be awesome, and you can skew it a bit.

[Sparda]

http://sparda.hopto.org/hak5/network.png[/img]

Looks some thing like that (crudely cobbled together in Kivio)

[VaKo]

If your using bridged networking for the freeBSD vm and the host isn't accessible externally I can't see that there would be a problem. Any exploit would need to be run against the Ubuntu server so if you can't talk to it from outside your LAN it would be much harder to attack it.

I also run all my freeBSD boxes on VMware, but in my case I'm using windows 2003 as the host OS. Each VM has its own IP in the 10.0.6.* range, and in the case of my web server, port 80 is forwarded to the VM's IP. To me this seems pretty secure but I'm not sure.

[Sparda]

I guess my concerns are rather moot. I set it up just as you describe VaKo. I suppose the only extra work using a VM involves is looking out for security issues that arise in the VM software it's self.

However, if a multi-platform VMware server kernel module attack does appear, it would be hard for an attacker to use effectively. Very few servers on the Internet actually run in a VM, even with a bot net, a scatter random server hitting attack would yield very low returns. Since I have an IP in a consumer ISP range, my server is of very low value to an attacker (unless they want to specifically target me).

[mubix]

Well there already have been a few "breakout" trojans that sense beiing in a VM and exploit the bridging/natting implementation. But then again, they have to have elevated access on the box first. Unlikely but not impossible. Best practice is to keep vigilant on your patches and firewall/ids/ips logs.

Oh and you comfy blanket of being on a commercial ISP. I have seen scan reports showing higher amounts of scans on commercial ISPs than on US DoD IPs.

[Sparda]

Oh and you comfy blanket of being on a commercial ISP. I have seen scan reports showing higher amounts of scans on commercial ISPs than on US DoD IPs.

I don't see it as a comfort, more of a deterrent. If my computer is in a 'low value' IP range and the attack isn't very automated and the port(s) I have open are of relatively 'low value' (default VNC port worth much more then 80 for example), then it's unlikely for an attacker to target me. The attacker doing a small cost benefit analyses in his head as it where.

[VaKo]

Well there already have been a few "breakout" trojans that sense beiing in a VM and exploit the bridging/natting implementation. But then again, they have to have elevated access on the box first. Unlikely but not impossible. Best practice is to keep vigilant on your patches and firewall/ids/ips logs.

Oh and you comfy blanket of being on a commercial ISP. I have seen scan reports showing higher amounts of scans on commercial ISPs than on US DoD IPs.

That wouldn't surprise me, most corporations will be fairly up on there IT security, its the millions of mindless drones who have home computers you have to worry about. No firewall, some crappy usb DSL modem, cracked copy of windows that can't be updated, ie6  + porn sites, and they still do there online shopping and banking on them. Absolute goldmine for criminals.

As for the VMware security issues, do you have links to any information on breakout exploits? And would running an firewall/ids/ips in another VM placed in front of the publically facing server help or would you need to have a physically separate box? I don't know an awful lot about an IDS's place in a network, which is quite a hole in my knowledge tbh.

[Sparda]

would running an firewall/ids/ips in another VM placed in front of the publically facing server help or would you need to have a physically separate box? I don't know an awful lot about an IDS's place in a network, which is quite a hole in my knowledge tbh.

That just gave me a fun idea. If you (for example) set your web server VM to host only networking, then have another VM running an IDS with host only networking and bridged networking... sounds fun aye? The only overall advantage been that your web server VM is slightly more protected amusing the IDS is working properly. Other wise the host OS is still as vulnerable as it where before.

[VaKo]

I've tried using a install of pfsense with 2 virtual nics, VMnet0 and VMnet3, and setting whatever is behind it to use VMnet3 as its vnic. This means that it can only talk to the outside world via pfsense, would I replace pfsense with a virtual firewall/router that is also an IDS or just add an IDS running in promiscuous mode to VMnet3? I think i need to read up on how an IDS works, unless you can make a virtual network tap.