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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I can. Happens a lot. Many hosts don't keep their templates upgraded, let alone remind newbie users to upgrade when the first spin things up. In the past there have been a number of templates at hosting companies I have found to be insecure and end up rooted with a rootkit installed if you didn't pay attention and reinstall/harden things immediately. I had one server at a provider where I ordered the deal at 11PM in the evening and then went to bed because it wasn't provisions yet, and by the time I woke up and logged in the thing was rooted and in contact with a C&C server.
I hardly ever use a providers template unless the service is managed and I know they are going to keep things up to date for me.
Not saying this was the cause, just trying to point out that you shouldn't rule it out.
my 2 cents.
Cheers!
what would you do if not using the template?
https://github.com/marcan/takeover.sh
EDIT2:
so yeah j/k but not really ...
(I am given to understand that it's easier to just
dd
a netboot.xyz image to the disk and take it from there.)I haven't felt the need to do this quite yet myself since I tend to use KVM from providers with capability to install from ISO.
But there's a few I can think of where this type of next-level finagling might come in handy - if you know what you're doing and/or are willing to put some effort into figuring it out if (when) it goes off in a direction different than one hoped for.
EDIT3:
ie, be prepared to reckon with the awful realization that:
"When you're up to your ass in alligators, it's easy to forget that your original intention was to drain the swamp."
but don't let that stop you.
Most likely issue to expect is need to enter network configuration settings - so will want to figure those details out ahead of time, and keep that information handy.
Or ... just to stick with using KVM virtualization from providers that support installing from ISO.
That's easy enough to arrange, usually.
So I run the latest Debian everywhere with the provider provided template under the assumption the latest version of Debian with aptitude updates installed as soon as the VPS booted was a 100% secure / nearly impossibly to exploit (Debian by default has no listening services exposed to the outside world aside SSH in the latest version on the other providers I've used AFAIK). This is the first provider I've ever used out of the box with the latest Debian that got compromised. I didn't install any services from memory. I don't want to blame the template since I haven't the slightest idea what happened nor do I know what's in their Debian template now.
Time for centos
@Xei - just curious (maybe I missed it) when did you setup the vps, and which location?
Seriously, how to audit and monitor server? Is there any easy to follow guide(s), so we can learn to stop compromised server behind it is too late?
I posted a few links from Digital Ocean above, such as
https://www.digitalocean.com/community/tutorials/7-security-measures-to-protect-your-servers
I am sure there are plenty more / good places to start. Hopefully someone else will suggest something better.
Some years ago I remember finding OWASP a (somewhat) useful resource for application development guidelines (stuff like avoiding SQL injection and cross-site scripting, etc etc) but perhaps that's not the best place to start for server admin concerns. And I haven't checked them out recently to see if they're still relevant or not. But take a look.
And do please dig around a bit more yourself. It will be a useful and enlightening experience.
The basics are not hidden knowledge, really - there seems to be a bit of the "leading a horse to water" dynamic at play here I think.
It may seem overwhelming at first but if one spends some quality time working to learn, the important points that are often repeated in many guides should soon become familiar territory.
EDIT2:
I hear TempleOS is very nice this time of the year.
Try this guide: https://community.hostdoc.co.uk/viewtopic.php?id=10
+1 for TempleOS.
Most reliable network stack ever.
Looks like the very end of November it was a Black Friday special, I am sure I logged in after it was provisioned and at least updated and upgraded via aptitude. Location was New York. If it was a default template or issue with the emails going out unsecured I think it'd be a lot more widespread. Then again HTTPD was on my server in the log I received and I didn't install that so that means it may be in their base image. If someone has services with them and they're bored they can see what services are running in their latest Debian distro.
Excellent luck - I just happen to have one of those BF Buffalo ovz's ... installed with Debian 9
(or was it Debian 8?)template. Updatedoccasionallyjust once but idlingwith just a few extras such as tmux and htopnothing "extra" except for sudo installed.I'm going to check its history and current activitahs now ... brb
EDIT2:
Okay. Here we go. I think this one was my very first BF purchase from virmach last year.
640 MB ram, 30 GB disk, OVZ in Buffalo for $5.97/year.
Looks like I installed Debian 9 from template, updated it just once, and installed only sudo.
I see it has fail2ban running (pretty sure I didn't install that, I generally don't need it)
no apache
I'm open to any suggestions for taking a closer look at the template.
Just as a little side note/by the way as:
I have lost count of the amount of servers I have had to suspend due to them being hacked and the response I get from the end user is along the lines of:
"WHAT, IMPOSSIBLE, I never even logged in to the server this is ridiculous!"
It must be in the hundreds, plural.
There's a provider around here who by default has the container turned off when it's provisioned, makes sense.
I'd go further and insist SSH is by key only. It removes that plausible deniability of the box being compromised by 'a 3rd party', which may even be the same party as who bought the box. Nothing like pleading ignorance.
my best attempt is to make the hdd unbootable and poweroff.
I am looking forward to a tutorial.
I notice
xauth
package is installed on my Buffalo ovz - not sure why (maybe to support tunneling X over ssh?)EDIT2: or just a dependency for some other package ... y tho?
i wouldn't like to disappoint you dear eol.
Why?
tutorial: If the disk is named /dev/sda then something like
should do the trick (to make it unbootable)
But you knew that, right?
Yes.
I was hoping for a different solution.
Thanks.
Yeah ... figured you'd be looking at some next level shit.
fucking magnets, how do they work?
EDIT2:
Industrial degausser, now an integral part of every proper provisioning pipeline.
Not sure what to do about ssd disks though.
EDIT3:
https://www.schneier.com/blog/archives/2011/03/erasing_data_fr.html
the above is the simplest and enough.
EDIT2:
Fail.
Some good suggestions in the comments here:
https://www.schneier.com/blog/archives/2011/03/erasing_data_fr.html
Need remote hands willing to work with thermite and/or hydrofluoric acid though ...
EDIT2:
This "new improved" solution might be easier to arrange (though probably wouldn't wipe the ssd, would most likely render the system more or less unbootable, maybe permanently.)
https://www.schneier.com/blog/archives/2016/09/usb_kill_stick.html
Nice one.
That's a terrible assumption and I don't know where you got that from.
The templates are typically made once and then become years old. YOU need to update it once it boots.
I know AWS and the big boys can run user supplied scripts when deploying servers and some lower VPS providers support SSH key injection so their keys work from first boot.
But it would be an awesome feature to run an ansible script or just my typical bash script that configures my preferences on first boot of a newly deployed server.
Basically there's no way to probably ever authoritatively say what the cause was which I had already guessed. That's neat to know that Apache wasn't in the base template when you used it (means it was probably installed post compromise if I had the same image as you) I do wonder if you installed fail2ban, check history? I wish there was a way for me to log all SSH history per server with Kitty so I could reference it to see exactly every command I ever issued.
Immediately after the latest Debian install (9.x) I do apt-get update && apt-get upgrade. I think the way I wrote it it seemed like I assumed that was done, I do not! That's all I do to make sure it's 'secure', and apt-get install sshguard. I used to check for extraneous services like smtpd or httpd but I hadn't seen that on recent Debian distributions so I stopped checking for them. My guess is Debian doesn't include those in v8 or v9 at least, I could be totally wrong though.
Out of the box doesn't mean out of the box and after I updated to the latest updates.
You're fucking confusing at best, lying at worst. Either way, it's an unmanaged service to the provider, but not to you, and you're dropping the ball.