# Does your VPS provider install patches in your container in stealth?



## drmike (Sep 25, 2014)

In light of the latest BASH exploit I've been patching and updating things.

Someone pointed me to Vultr and their approach where it appears they maintain inside the container access:



> Yes, we have unattended security updates enabled by default for Ubuntu and Debian. This is not the case for CentOS.
> 
> However, for critical issues like this you should always make sure to check yourself.


Appears they have unattended security updates inside folks containers if others are reading correctly and so am I....

Are other providers doing similar in-container approaches like this?   This generally seems proactive but worrisome to me.


----------



## WebSearchingPro (Sep 25, 2014)

Looks like Vultr is using this based on inspection of a fresh VM from them https://wiki.debian.org/UnattendedUpgrades


----------



## lbft (Sep 25, 2014)

It doesn't have to mean they have access to your container, just that their default template is configured for automatic updates (see Debian and Ubuntu documentation on the unattended-upgrades package, but basically apt-get install unattended-upgrades and then dpkg-reconfigure -plow unattended-upgrades).


----------



## Zigara (Sep 25, 2014)

Debian and Ubuntu packages are signed. It's not as if your provider can force an update into your machine.

You seem to also be forgetting the fact that your provider has 100% access to your VM's memory, filesystem, etc..


----------



## yolo (Sep 25, 2014)

Vultr does use cloud-init on your VPS


----------



## Zigara (Sep 25, 2014)

yolo said:


> Vultr does use cloud-init on your VPS


Yes, they need to setup the initial ssh keys, hostname, etc somehow.


----------



## drmike (Sep 25, 2014)

I am unsure what gets labeled as security updates vs. the many updates I see in such normally.

My issue isn't per se the container access part, it's just that updates are being done without folks being aware.  Along the way random breakage I suppose could happen.  It's one more random thing a bunch of containers are doing that the owner/renter thereof may not be aware of.

Conceptually interesting.  Unsure about customer and real world use though.


----------



## sundaymouse (Sep 25, 2014)

If you are paranoid about privacy, rent a dedicated server. It is still open to providers on things like console/IPMI access, but you are not residing on a host node anymore.


----------



## lbft (Sep 25, 2014)

The default option should always be more secure rather than less secure. If people want to carefully manage the installation of updates on their server (and they absolutely should, but unmanaged services are often used by people who really need full management) they can remove the package easily.


----------



## TruvisT (Sep 25, 2014)

We only touch a clients if they give us permission to manage their security. However, we spend a lot of time interacting with our clients on social media answering questions and more to ensure they know about current threats and help them install patches.


----------



## blergh (Sep 26, 2014)

This is OT, but i just have to say i LOL'd when reading "interacting with our clients on social media" and "manage their security"


----------



## eva2000 (Sep 26, 2014)

drmike said:


> In light of the latest BASH exploit I've been patching and updating things.
> 
> Someone pointed me to Vultr and their approach where it appears they maintain inside the container access:
> 
> ...


Yup Vultr CentOS VPS, are installed via install routines with fresh yum updates at initial launch of their VPS. You can confirm this when you launch the VPS console for the Vultr instance after initial deployment. So by the time you first SSH into CentOS Vultr VPS, you should have all current YUM updates  

This is at initial deploy, not sure about after the VPS has deployed


----------



## vpsukraine (Sep 26, 2014)

According to *eva2000!  opcorn:** *


----------



## eva2000 (Sep 26, 2014)

k found Vultr's comment on unattened security updates https://discuss.vultr.com/discussion/comment/1606#Comment_1606

so Debian and Ubuntu get's unattended updates after initial VPS launch while CentOS only gets yum update at initial VPS launch and nothing afterawards


----------



## k0nsl (Sep 26, 2014)

Aha...that explains a lot of my recent ‘breakages’ on several Vultr VPSes...anyway, not a big deal - but I’m moving away from them, because of other reasons..


----------



## perennate (Sep 26, 2014)

k0nsl said:


> Aha...that explains a lot of my recent ‘breakages’ on several Vultr VPSes...anyway, not a big deal - but I’m moving away from them, because of other reasons..


Presumably they only have automatic security updates (which, by the way, is an option that Ubuntu installer and possibly Debian as well prompts you for during installation from ISO). So security updates broke your VPS?


----------



## SkylarM (Sep 26, 2014)

It's quite possible to simply run a script on the host node that would effectively update all VPS under the node for the purpose of specific updates, however in light of privacy concerns we opt not to do that. In the case of OpenVZ, the following command would work for the bash issue:



> for CT in $(vzlist -H -o ctid); do vzctl exec $CT "yum -y update bash && ldconfig";  done


But again, privacy issues are at the forefront here. Would most customers view this as invasive or not? It IS unauthorized changes to your VPS, even with good intentions.


----------



## Amitz (Sep 26, 2014)

So why did I have to install the bash updates on my debian VMs at Vultr myself? Shouldn't that have been done by their automatic script?


----------



## drmike (Sep 26, 2014)

Amitz said:


> So why did I have to install the bash updates on my debian VMs at Vultr myself? Shouldn't that have been done by their automatic script?


Good question, can someone else confirm same experience with Vultr.  Perhaps the scheduled job hadn't ran yet???



SkylarM said:


> But again, privacy issues are at the forefront here. Would most customers view this as invasive or not? It IS unauthorized changes to your VPS, even with good intentions.


What a nugget of info @SkylarM !   These are unauthorized changes to customer VPS.   Imagine the horror if such an update mass broke containers.   There would be the customer irritation, the privacy violated per se (WHY ARE YOU IN MY HOUSE FOOL), then the cleanup work.   Quite a pile of liability for a company to assume.  

So the saying goes:  The path to hell is paved with good intentions.


----------



## tonyg (Sep 26, 2014)

For what it's worth:

I setup a test VM with Vultr (Debian 7 x86) and noticed constant remote server connections from port 80.

I proceeded to block the connections with iptables.
Started having issues updating the system and it turns out that all/most of these IPs are Debian update servers.

128.61.240.73
128.61.240.89
128.61.240.73
108.59.6.136
205.234.175.175
128.31.0.36
149.20.20.6
195.234.148.10

Somehow these Debian servers are connecting constantly to my IP.
By the way, I installed from original Debian ISOs and DON'T have unattended-upgrades.


----------



## Amitz (Sep 26, 2014)

tonyg said:


> For what it's worth:
> 
> I setup a test VM with Vultr (Debian 7 x86) and noticed constant remote server connections from port 80.
> 
> ...


Honestly, that would feel spooky to me. It may be with good intentions, but I would prefer to have full control myself about what happens on my rented server. Maybe that is why I rent less and less VMs and more and more dedicated servers...


----------



## DomainBop (Sep 26, 2014)

> Maybe that is why I rent less and less VMs and more and more dedicated servers...


I blame LET for the fact that my dedicated server count now exceeds my VPS count.  It doesn't make me want to rent a VPS when I see VPS providers saying "_"Hosting providers utilizing OpenVZ virtualization technology to provide "virtual private server" web hosting services are under no obligation to abide by data privacy laws as due to the nature of OpenVZ virtualization..."_


----------

