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

drmike

100% Tier-1 Gogent
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.
 

lbft

New Member
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

New Member
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..
 
Last edited by a moderator:

drmike

100% Tier-1 Gogent
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

New Member
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

New Member
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.
 
Last edited by a moderator:

TruvisT

Server Management Specialist
Verified Provider
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.
 

eva2000

Active Member
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
 
Last edited by a moderator:

k0nsl

Bad Goy
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.. :rolleyes:
 

perennate

New Member
Verified Provider
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.. :rolleyes:
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

Well-Known Member
Verified Provider
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.
 
Last edited by a moderator:

Amitz

New Member
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

100% Tier-1 Gogent
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

New Member
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.
 
Last edited by a moderator:
Top