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

[drmike]

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]

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

 

[lbft]

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]

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]

Vultr does use cloud-init on your VPS 

 

[Zigara]

Vultr does use cloud-init on your VPS 

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

 

[drmike]

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]

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]

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]

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]

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]

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:

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.

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]

According to eva2000!  opcorn: 

 

[eva2000]

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]

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]

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]

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]

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]

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???

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]

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.