[buildzr]

Unless you have untrusted users with SSH you can get away with a lot. I've reviewed many major Linux patches for the past several years and found we weren't actually impacted by most of them.

For example, I don't need Zombieload/MDS patches as I don't have anyone running untrusted code on the servers, I didn't need the rds_tcp vulnerability patch from last week because I don't have RDS modules loaded on any of my servers. I didn't need client side OpenSSH patches on these servers either, nor OpenSSL patches for UDP SSL. Typically a quick check with ansible is all it takes to confirm if these things are or aren't real risks for you.

EDIT: Just looking at some CVE lists... It looks like assuming that the entire attack surface is the kernel and pre-auth openssh you may be in the clear running stock Ubuntu Server Minimal 14.04, a 5 year old OS today.

Kernel vulnerabilities resulting in code execution in the TCP stack or related code resulting in code execution are few and far between. OpenSSH vulnerabilities... well, the last pre-auth OpenSSH vulnerability, one of the two in it's entire lifetime had the severe consequence of... being able to check usernames too fast.

Please let me know if I've missed a big one, but I don't see anything that could even be used to do more than DoS a system like this running an old kernel and openssh server.

[chaosite]

The thing about Zombieload/MDS (well, not really those, they're really more theoretical attacks... But Meltdown/Spectre in general, and any other local root exploit) is that they turn a remote shell, and perhaps a very limited one, into a remote root shell.

Not having any ports open is one thing, but I do think your attack surface is larger than just the kernel and OpenSSH. Does Ubuntu not have UPNP open by default?

But things connecting from your computer to the outside world can also be exploited. Just the very first one I thought of, dhcpcd, has a recent CVE. And there are many more programs on a default Ubuntu install that connect to the outside world without user interaction -- are you willing to let a vulnerability in any one of those become a remote root shell?

[buildzr]

> The thing about Zombieload/MDS (well, not really those, they're really more theoretical attacks... But Meltdown/Spectre in general, and any other local root exploit) is that they turn a remote shell, and perhaps a very limited one, into a remote root shell.

There's also many, many other local exploits that don't get nearly as much PR in Linux and if an attacker wants to take advantage of one they can basically just wait. Local privescs are pretty common as the attack surface is massive.

Isolating to separate kernels in separate VMs or better, separate physical hardware is always better than relying on Linux's privilege separation. All but my development servers could be run as root with no significantly greater risk.

> Not having any ports open is one thing, but I do think your attack surface is larger than just the kernel and OpenSSH. Does Ubuntu not have UPNP open by default?

On Ubuntu server as configured by this provider at least, this is all I have exposed in netstat -nlput

> But things connecting from your computer to the outside world can also be exploited. Just the very first one I thought of, dhcpcd, has a recent CVE. And there are many more programs on a default Ubuntu install that connect to the outside world without user interaction -- are you willing to let a vulnerability in any one of those become a remote root shell?

Not really a serious concern, dhcpcd isn't running on any of my servers. Sorry if you have this confused, I meant Ubuntu server... not much runs really. Yes, of course I wouldn't suggest browsing the web or similar operations, which opens a massive attack surface, but for a server the attack surface is much narrower. Not much phoning home except perhaps an update check if you have that enabled.

[chaosite]

> Isolating to separate kernels in separate VMs or better, separate physical hardware is always better than relying on Linux's privilege separation.

Sure, you can also do more. You can also air-gap your machines and sneaker-net everything that's needed, or if your server needs to send updates you can send UDP over a tx-only link (use an optical link and only connect the tx.)

But there's a cost-benefit analysis here. Discounting MDS is one thing, I actually agree with Intel's risk assessment on it, biased as they are. But generally installing security updates on an LTS disro is easy and painless; there's no real reason not to do it.

> All but my development servers could be run as root with no significantly greater risk.

Are we operating under a different definition of "risk" here? Running servers as root definitely increases risk. As root you can do much more persistent damage when an attack does happen, basically putting the machine in a state where the only solution is to wipe and install from scratch.

[SXX]

> As root you can do much more persistent damage when an attack does happen, basically putting the machine in a state where the only solution is to wipe and install from scratch.

In any reasonable project or company server that malicious actors ever had access to is counted as completely compomissed no matter what permissions they had. There basically no other option than wipe and reinstall since OS cant really perform trusted self check. For all you know you can have rootkit living in bootloader.

Of course even hardware cant be trusted really, but this is another level of risk management while "wipe and reinstall" (or wipe and restore from backups) is an industry standard.

[scardine]

This. Nuke the entire site from orbit. It's the only way to be sure.

https://www.youtube.com/watch?v=aCbfMkh940Q

[chaosite]

Ubuntu Server's default install comes with (at least) a DHCP client and an NTP client. Maybe more things, those are just the two I checked.

Sure, you can use static IPs, and disable NTP, and take other steps to harden your server and reduce your attack surface. But remote exploits for random default programs are routinely discovered, so defense in depth is just a good idea.

[asveikau]

I am confused why you mention OpenSSH in a discussion about uptime and kernel patches. You don't need to reboot to patch sshd.

[buildzr]

That's my bad, I was thinking of some personal scenarios in which I've had low value servers running single applications connected to the internet for years without updates at all.