Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Security thoughts about running XenServer on a dedi
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Security thoughts about running XenServer on a dedi

Have a dedicated server and noted that I can reinstall with various flavors of linux or windows but also with XenServer. I have managed XenServers on premise before but never really thought about having control of one for a dedi. I usually just have VPS.

Obviously need more IPs but that's not a big deal.

My concern was more with security. On a linux VPS/dedi I can run even simple stuff like fail2ban/denyhost, etc to help limit the jerks. I can probably even run on those on XenServer as well.

I was just thinking more about the Citrix XenServer level vulnerabilities that come out as well as the remote administration. I guess I could use hosts.deny and hosts.allow to restrict everyone except me but naturally I'm on a dynamic IP most of the time so that's difficult unless I login through remote KVM and update that stuff as needed (PITA).

I don't have the ability to create a VPN or that would solve the whole problem.

Just figured I would ask if anyone else is running XenServer on a dedi and if you are what you can do to lock it down, etc.

I would be cool to have XenServer and then multiple VMs as I can easily see benefits for me but not if the risk is too great. I'll just stick with my normal linux stuff and buy another VPS/dedi if XenServer just doesn't make much sense.

Thanks!

Comments

  • You could ask your provider to firewall certain ports or block all except to whitelisted IP

  • singsingsingsing Member
    edited September 2015

    zookie said: My concern was more with security.

    An excellent concern to have. However, your threat model is unclear, which makes it difficult to recommend solutions.

    zookie said: I was just thinking more about the Citrix XenServer level vulnerabilities that come out as well as the remote administration.

    It is a concern with all virtualization software that guest code may be able to break the virtualization directly, or attack other parts of the environment indirectly, for example, by exploiting buffer overflows and other weaknesses in virtualized drivers.

    Pretty much the only solution to this is to subscribe to all the relevant mailing lists and advisories that go out and be ready to patch your virtualizer software at moment's notice (or pull the plug on your server's Internet (e.g., by iptables) if you can't get it patched in a reasonable timeframe).

    zookie said: I'll just stick with my normal linux stuff and buy another VPS/dedi if XenServer just doesn't make much sense.

    Buying VPS from a provider will not help you if you are worrying about virtualizer bugs. In fact, when such bugs are found you want to be running anywhere other than on a low-end VPS.

    zookie said: I don't have the ability to create a VPN or that would solve the whole problem.

    There any many ways to create VPNs, including the extremely lightweight solution of SSH TCP connection forwarding. This is what I do: make port 22 open to the world, and use connection forwarding for VNC, etc. I don't know your constraints, but it sounds like you should probably look at making sure you really haven't any stone unturned in figuring out a secure way to connect to Citrix's management interface.

    I don't have experience with Citrix XenServer myself; if the problem is that it doesn't provide you with the capability to control the virtualizer through SSH, I'd consider using a different software. I'm pretty sure Xen itself can be configured do this (I'm more of a QEMU fan myself).

  • singsing said: However, your threat model is unclear, which makes it difficult to recommend solutions.

    He forgot to add on his DED that DC techs can load stuff via USB ;)

  • doughmanes said: He forgot to add on his DED that DC techs can load stuff via USB ;)

    It's not unheard of to fill USB ports (and most any other kind of port) with epoxy glue to prevent casual snooping (an advanced adversary will have no trouble desoldering the port and soldering on a new one). But you must of course buy colo rather than dedi.

  • singsing said: It's not unheard of to fill USB ports (and most any other kind of port) with epoxy glue to prevent casual snooping (an advanced adversary will have no trouble desoldering the port and soldering on a new one). But you must of course buy colo rather than dedi

    But why, USB has no DMA....

  • Thanks for the replies. Here's another ridiculously long post. I didn't spell out the threat model as it is the same as everyone in this community. We are all, here, running dedicated hosting or VPS hosting, etc in one form or another. Many/most of those are linux VMs. In this case the option exists to run XenServer on the dedicated box and then have multiple VMs.

    The security concerns for this topic are all around XenServer and specifically, in this case, a XenServer that is publicly exposed.

    A publicly exposed hypervisor is something I would not normally even do. I work with hundreds of servers running vmware, xenserver, and hyper-v but not one single one is exposed to the internet at the hypervisor level. Sure they are all running SSL but still behind firewalls/VPNs. Maybe I'm answering my own question right there and I just shouldn't do it. But the idea of having multiple VMs at the LEB price point is appealing for my personal needs.

    I've read some of the information that I have found on securing and hardening XenServer installs. Helpful though still just not getting that warm fuzzy feeling by even having it exposed at all. Actually I would feel ok with it if I had a static IP and could lock things down both in the hypervisor as well as have the provider configure the firewall. But I don't.

    I'm not as concerned with the DC techs and the threats from the USB ports. Of the various security concerns, they are at the lower end of the list and I'm not any under delusion that I'm gong to make this box completely secure, just trying to take appropriate actions on a dedi box to limit inherent attacks (targeted or otherwise).

    I'm also not as concerned with a hypervisor driver issue within the guest VMs. In the game of odds, that is less likely than something like the Heartbleed vulnerability which while, ironically, did not affect current versions of XenServer at the time, did affect VMWare and a lot of other devices and installations. It took VMWare what seemed like forever to patch their hypervisor. It was like a week or almost two. A VMWare hypervisor sitting internally and especially on a management subnet, fairly low risk. A VMWare hypervisor sitting directly exposed to the internet. Quite a different sense of urgency to be sure.

    Every port accessible is a target and therefore XenServer's remote administration ports, although over SSL, are possibly going to get brute force attacked all day. I don't like strong passwords and up-to-date software being my only line of defense. For a LEB dedi/VPS I like tools that block IPs that continually try to find their way in. A low end version of an IDP such as fail2ban and denyhosts. And unattended-upgrades/yum-cron. And I think I can get some of this to run on a XenServer. Maybe I can even tweak fail2ban to watch XenServer logs. Not sure.

    Again I'm not trying to take an enterprise cost type approach (this is LEB/LET after all) and I'm not thinking I'm going to harden this, or any box, to the point that it can't be taken under the right circumstances, but I am trying to limit the exposure and since I've never personally exposed a hypervisor to the internet before I figured this was the place to see if anyone else had, if they have had any issues, and what security concerns or mitigation efforts they may have had.

    A VPN is ultimately my best option here. I have also used SSH tunneling and that too would be a good option. All have their own challenges with a dedi box that has been assigned an external IP. I can work with the provider to see what my options are.

    But if anyone is running with XenServer directly exposed to the internet, I'd like to hear any feedback you might have.

  • William said: But why, USB has no DMA....

    Power cycle + USB keyboard + USB flash drive + make BIOS boot from flash drive = win. Obviously, if you have a server with FireWire port just sticking out of it things are even simpler and you are doing it wrong.

  • singsingsingsing Member
    edited September 2015

    zookie said: I don't like strong passwords and up-to-date software being my only line of defense.

    PasswordAuthentication no.

    ssh-keygen -b 8192 -f strong.

    Done.

    If you want to be protected from ssh bugs (paranoia level 99), you can allow ssh connections only through an OpenVPN tunnel, itself authenticated and encrypted. This would require both systems to be broken simultaneously.

  • Thanks. Yes, that takes care of SSH but that's only SSH. With XenServer you have management over SSL that someone can try to brute force all day or find a vulnerability.

    The best option, possibly, would be a VPN so the hypervisor just isn't even exposed to the internet at all. That's how I would do it on-prem. I'm just not sure what my provider's options are on this front as all I have at the moment is a dedi box with a single external IP and that's not going to be enough. I'll get a ticket going.

  • servarica_haniservarica_hani Member, Patron Provider

    I would suggest doing this
    I assume you have 1 unplugged NIC for added security

    the idea we will run a vm on the hypervisor that has public access where you can run vpn
    then on that vm and hypervisor both will be on same network (dummy network since both on same subnet no need to switch anything)
    then we make only 1 managment ip on hypervisor on this local ip

    the big issue here
    if this vm is down you have no way of accessing the hypervisor except by kvm. so it is up to you to use this method

    here are the steps

    1- create external network on the server and assign it to the unused nic (if you dont have any unused nic then assign it to management nic (this will be less secure))

    2- add new managment interface to this new network and assign it any local ip in 10.X.X.X

    3- now add this new network to 1 vm which will run the vpn software. plus add the normal data network

    4- configure the nic on the vm and give it an ip in same subnet as the managment local ip you created in step 2

    5- try to ping to make sure it can access the ip of managment interface

    6- delete the public managment ip from hypervisor

    7- configure a vpn on the new vm you creaed

    Thanks

  • Hani,

    Like the creative thinking!

    I'll give this a try. As you said, should the VPN VM become unavailable I can always use KVM to change the management IP of the hypervisor to a public address long enough to resolve the problem.

    I'll let you know how it goes.

    Thanks!

Sign In or Register to comment.