This is a new server I provisioned on my VPS in racknerd. The command looks safe, but I’m wondering if these commands were executed on its own? Or someone has logged in to my VPS? This is also not normal, isn’t it?
From the location of that script usr lib virt-sysprep looks to be a script put in the image by the provided to do a few things on first boot.
Would have thought it was normal, but you can always ask them to double check
I’d say they made the image, started it, did minor adjustments and didn’t delete the command history before stopping it and starting to deploy the image.
Remember to log out of the console, as I’ve personal experience of seeing someone at Racknerd type commands into it (presumably by mistake but possibly because that’s SOP - this was shortly before they shut down the server claiming it was responsible for a networking issue after being hacked. Never found evidence it was hacked but Linux can glitch from time to time. So it’s possible they were taking advantage of the fact I was looking at the console at the time to see what the state of the machine was and then realized I was watching.)
Note I’m referring to the console here, not random ssh sessions. While there may be technical ways for them to hijack those, there’s not a lot of point in doing so, there are easier ways to gain access to VMs via, say, backdoor passwords.
so what are the options for the customers like us if we don’t want them to access our server? how do i know if they logged in using a different method other than ssh?
In all honesty, there’s nothing you can do with any VPS (or cloud - AWS, Azure, etc) provider to prevent them from accessing your server as you’re reliant on them to make sure there are no back doors in their images or hardware, and they have a vested interest (maintenance etc) in making sure they have at least some access. But it’s usually rare they do actually log in.
You can tighten up security a little bit by:
Avoiding use of the console and logging out of it when AFK
Checking /etc/passwd and /etc/shadow for passwords for accounts that should be inaccessible, and removing them.
Verifying pam.conf doesn’t provide access to an external authentication system under the VPS operator’s control.
But those three still rely upon there being no back doors embedded deeper into the OS.
In the end, if it’s confidentiality you need, you’re better off setting the VPS up as a proxy to data that’s held on a server you have full control over (ie one that’s in your house), with no secrets kept on the VPS itself. That can be a tough one to set up and is beyond the scope of a simple Lemmy post…
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
From the location of that script usr lib virt-sysprep looks to be a script put in the image by the provided to do a few things on first boot. Would have thought it was normal, but you can always ask them to double check
i contacted support and they provided me this doc page
https://support.solusvm.com/hc/en-us/articles/360007449180-How-to-modify-first-boot-script-in-the-TDN-KVM-template-in-SolusVM-
good point, it’s just a test server for now so I’ll try to reinstall OS and check if same commands will show in history
I confirm that VPS companies use custom images with additional scripts. I’ve seen those a few times.
wait, the 3rd command is
vi. I mean that’s not an automated script, it should be executed manually, right?Perhaps it is listed in reverse chronological order; edit, check content, change permissions (for deployment)?
I’d say they made the image, started it, did minor adjustments and didn’t delete the command history before stopping it and starting to deploy the image.
Looks harmless, although a tad sloppy.
Good point, what happens if you run that command ? It might also just left over from when they made the custom image and forgot to clean it all up ?
deleted by creator
This looks like a provisioning command to expand disk to fill allocated space of your VPS.
Looks like stuff put in place by the VPS provider that would run on the first startup to create a swap partition and resize the main partition.
Remember to log out of the console, as I’ve personal experience of seeing someone at Racknerd type commands into it (presumably by mistake but possibly because that’s SOP - this was shortly before they shut down the server claiming it was responsible for a networking issue after being hacked. Never found evidence it was hacked but Linux can glitch from time to time. So it’s possible they were taking advantage of the fact I was looking at the console at the time to see what the state of the machine was and then realized I was watching.)
Note I’m referring to the console here, not random ssh sessions. While there may be technical ways for them to hijack those, there’s not a lot of point in doing so, there are easier ways to gain access to VMs via, say, backdoor passwords.
so what are the options for the customers like us if we don’t want them to access our server? how do i know if they logged in using a different method other than ssh?
In all honesty, there’s nothing you can do with any VPS (or cloud - AWS, Azure, etc) provider to prevent them from accessing your server as you’re reliant on them to make sure there are no back doors in their images or hardware, and they have a vested interest (maintenance etc) in making sure they have at least some access. But it’s usually rare they do actually log in.
You can tighten up security a little bit by:
But those three still rely upon there being no back doors embedded deeper into the OS.
In the end, if it’s confidentiality you need, you’re better off setting the VPS up as a proxy to data that’s held on a server you have full control over (ie one that’s in your house), with no secrets kept on the VPS itself. That can be a tough one to set up and is beyond the scope of a simple Lemmy post…