Hacker News Reader

Comment by jeffbee | Hacker News Reader

It's weird to begin such an exercise without stating what the point of "the server" is supposed to be. Is it a ... web server? Interactive unix logins for developers? Mail relay? What does it do? This is the key point of the analysis because "securing" a server consists in making it incapable of doing anything not in the set of things it is meant to do. Notably, starting from this side of the problem can lead you away from "standard machine image". Starting with a kitchen-sink Linux distro like Ubuntu is not the road to hardness.

View on HN

It's really not weird, that's not how security works.

What the application is doing is relevant to application security, but the whole point of securing the OS is to eliminate the necessity for "trusting" the application.

When you are securing an operating system, you must assume the application that is exposed to the operating environment (be that the internet, local LAN, even simply user logged into the workstation in the case of a GUI or CLI app) is compromised.

The primary goal of most security measures is preventing and detecting privilege escalation and lateral movement within the OS or network.

There are a lot of best practices that apply in general to securing an operating system. If you want to dig deeper, one of the best resources for this information is provided by CIS (Center for Internet Security).

CIS has hardening standards for most OS's yes even including Ubuntu. https://www.cisecurity.org/benchmark/ubuntu_linux

These are standards that many security conscious organizations apply to their servers. The US government takes it a step further with DISA's STIGs.

DISA STIG's are similar to CIS's benchmarks, but result in an even more locked down environment and place extreme restrictions on which crypto libraries are allowed to be used.

In short, securing the OS is a standard best practice that all organizations should be doing. Unfortunately most startups lack engineers with the expertise in building custom linux images so a lot of folks are quite unfamiliar with hardening procedures.

You should absolutely NOT use a non-standard OS because you think it will be more secure. It's a much better idea to use known industry standard security benchmarks on supported Linux distributions than trying to bake your own standard some non Debian/RHEL based bistro.

IME the checklists and guides can be a useful resource but are mostly “cover your a$$” documentation, often time falling into cargo cult suggestions just to add more check-boxes.

You must be using the wrong 'checklists' (they aren't checklists, they are implementation guidelines). CIS benchmarks and DISA STIGs provide concrete actions that lead to a more secure system. Sure some of them might not apply specifically to your environment, but in general they are an excellent starting point.

Some of the line items can be a bit arcane or not as relevant in cloud environments, etc... but that's a far cry from calling them CYA.

Nothing cargo cult about enabling SE Linux, restricting access with IP tables, configuring AuditD and AIDE.

> Nothing cargo cult about enabling SE Linux, restricting access with IP tables, configuring AuditD and AIDE.

These are great ways to massively overcomplicate your system. Generally speaking, having encountered these tools, do not use them unless you're willing to dedicate about 2x the time you would otherwise spend administering the system.

Just because you had difficulty does not mean you should give such advice to others. There is nothing difficult about configuring any of these systems if you know what you are doing.

Time consuming & tedious & error-prone != difficult.

I'm still not sure on how disabling the crypto algorithms that the NSA prefers to not break helps us stay more secure...

If a single line item that seems irrelevant to you makes you think the whole process of security hardening is useless, you are a fool.

Frankly you sound like the tired BOFH trope, if you don't see the benefits of security hardening I hope you are never responsible for anything important infrastructure wise in your organization.

The second sentence

> But I write software for the web

I'm going to guess it's a web server but it's just a guess.

2nd and 3rd sentence

“ But I write software for the web, which means I’m never far from a server, and sometimes I’m the only one around.

So even if I didn’t want the job, I have it, and I need to take the security of these hosts seriously.”

Basic Linux server hardening is not a bad idea or skill to learn. Learning the basics manually help feed into understanding and using higher level solutions.

100%

As long as you are using Debian, RHEL, Ubuntu, or CentOS implementing a basic minimum security baseline is as simple as following the CIS or DISA STIG guides for your OS.

There are plenty of scripts on GitHub that do this (AUDIT THEM FIRST), or you can even just use premade images from CIS in the cloud provider of your choice.

Almost every server sits on the internet and has one or two (sometimes a couple more) ports open listening for their apps internet traffic.

What the traffic is seems irrelevant to 99.99% of servers out there, imo. Yes there's some questions of what deployments look like and what capabilities operators have but those are details outside the general concern of being safely online. IMO.

> Almost every server sits on the internet

I'm going to counter that the overwhelming majority of hosts in existence do not, in fact, "sit on the internet".

Ideally the traffic would be siphoned thru a load balancer/reverse proxy of some kind rather than the dest service endpoint/port being directly exposed to the internet

Sure. But everyone else here was talking about servers. Which, you know,... serve. Are in some way on the internet.

Host/Servers are in the above case the same thing. And servers can "serve" also on local lan, no internet required

> Almost every server sits on the internet ...

Nope. Not by a long shot.

> What the traffic is seems irrelevant to 99.99% of servers out there, imo. Yes there's some questions of what deployments look like and what capabilities operators have but those are details outside the general concern of being safely online. IMO.

The following vulnerabilities listing just for the week of 2023-07-17 prove otherwise:

https://www.cisa.gov/news-events/bulletins/sb23-205

Reply on news.ycombinator.com