That's dangerous thinking. Any un-patched service can turn into a pivot point. If the same folks who managed more critical pieces of infrastructure log in there, it can almost certainly be used to pivot onto their other systems.
I think you're thinking too big here. This is a single scaleway machine, by itself. It has only one user(me), and one listening process(two if counting ssh). Even if you gained root access to it, there's literally nothing you could do I would care too much about, including taking it offline.
That wasn't meant to be a point of pride or accomplishment, more a testament to the reliability of Scaleway. I've been super happy with them.
It's just the security cargo cultists. Some were arguing that I should be turning on Spectre/Meltdown mitigation on my Hadoop cluster. It's my cluster, dude. My engineers have the right to run code on it. If they don't and they're running code on it, I've already lost the game. If you can even contact one of my machines the game is up. What even is the threat model here for Spectre/Meltdown.
They have no sense of risk. Just security cargo-cultists.
I don't know that it's cargo-cult behavior, but maybe it's a lack of perspective in general. I work in security, and yes, it's good practice to patch all the things, but only in that it's the easiest default policy that makes things happen. If you have to pick and choose, you need to understand things well enough to be able to judge.
As a security consultant, I think that kind of perspective is where I can help add value to our clients; our usual point of contact is a project manager, whose eyes tend to glaze over when given a big vulnerability report, or worse, a spreadsheet. To them, every line feels like some sort of crisis. Now if I can get them to patch in a timely fashion, there is at least no pile of years-old issues, and we can take the time to discuss the few that remain.
Very true. We have some cluster users on Gentoo, who are happy that they can simply flip off all those pesky performance-eating security mitigations system-wide. Not only in the kernel, but also userspace side PIC/PIE/SSP/etc.
> Even if you gained root access to it, there's literally nothing you could do I would care too much about, including taking it offline.
Well, the person who has to deal with it being used as a jump point or IRC relay hiding some third party's behavior might care.
Providing only one small service and OpenSSH and not being tied into other infrastructure directly means it's not really a desirable target for the rest of the project, but it also means it's not likely to cause too much of a problem if it gets a reboot every once in a while.
The added benefit is that if gives you the occasional point in time to make sure everything is runnnig cleanly with all the updated applied. You ensure SSH and the geolocation service are restarted after they get updates, right? What about after glibc updates? What about after a zlib update?
If you really want to make sure updates are applied, you want to make sure an prior version of updated code active in memory is cleared out. Knowing if that's been accomplished isn't always easy, but one easy way to do so is a reboot after an update.
Is it really dangerous to log into compromised machines, though?
I think unless one does something stupid like SSH agent forwarding or using shared passwords, it should be safe even if machine is totally compromised.
If you fetch a remote binary or script to your dev machine and run it, your dev machine could be compromised -- but I am not sure why would anyone want to do this.
If you specify X forwarding, then anyone can own you. But you should not have any X apps on the remote server to begin with.
If you are transferring files, then vulnerabilities in rsync/rcp could get you. But those would have to be on the client side, your desktop machine -- and hopefully this machine is well patched.
If you are using IP filters / the machine is on LAN, then yes, it could be bad. But in this case, the machine was on the public network.
There was old bug with "get window title" putting stuff into input buffer, but it was fixed years ago.
Don't get me wrong, I think you do want to keep the machines up to date, and one should always enable unattended updates.
But I also believe in defense-in-depth, so if one is "managing more critical pieces of infrastructure", they should always assume the remote machine they are managing is compromised, and always take precautions.
Generally speaking though you're correct though - keep your client up to date and you'll be protected from a hacked server.
Clients are in general expose much larger attack surfaces in many cases, so likely will have more frequent and significant security patches. There's a lot more to attack in a web browser than in say, Nginx.
