Lynis – Security auditing and hardening tool, for Unix-based systems • Hacker News Board

Re: Lynis – Security auditing and hardening tool, for Unix-based systems

#21

Post by INTPenis » Sun, Nov 10, 2024, 12:15 PM UTC

viraptor wrote: post #16

INTPenis wrote: post #8

Earlier quoted context omitted.

I just heard about this tool but someone else said it simply enumerates defaults already present in most distros. I can tell you one thing that makes real changes to RHEL at least, CIS Benchmark. It hardens your system by tightening up file permissions, user logins, disables old protocols, sets partition flags and more. But the best hardening imho doesn't follow any set standard, rather application dependent isolatio…

CIS itself may have good ideas, but the implementation is mostly bullshit. Compare the actual differences between a CIS Ubuntu docker images and a plain one. There's 3 valid changes you can do by hand and the rest is snake oil that makes the image larger as a bonus.

I wouldn't say it's mostly BS, it's mostly common sense stuff that distros should have done already.

I don't know about the Ubuntu CIS image but I had to go through the whole CIS PDF for a job once, and implement it all with Ansible on RHEL. I can guarantee that it makes useful changes, and it truly makes a difference to how you use the system.

But in general this type of hardening is mostly used to fulfill some contract, and it's designed around how Linux was used 20 years ago.

My personal preference is to 1) treat linux servers as appliances and stop letting people login, 2) use containers, MACs, MCS and other such isolation tailored for specific services, 3) network ACL and segmentation up the wazoo, 4) MFA access control and 5) encrypt all the things.

Re: Lynis – Security auditing and hardening tool, for Unix-based systems

#22

Post by patrakov » Sun, Nov 10, 2024, 4:20 PM UTC

Rules like https://cisofy.com/lynis/controls/AUTH-9282/ are something that NIST calls outdated and dangerous password practice, but foreign security bodies mandate. Go figure.

Also, the suggestion from https://cisofy.com/lynis/controls/NAME-4404/ is just wrong on systems with nss_myhostname (from systemd) configured.

Re: Lynis – Security auditing and hardening tool, for Unix-based systems

#23

Post by musicale » Mon, Nov 11, 2024, 7:00 AM UTC

patrakov wrote: post #22

Rules like https://cisofy.com/lynis/controls/AUTH-9282/ are something that NIST calls outdated and dangerous password practice, but foreign security bodies mandate. Go figure. Also, the suggestion from https://cisofy.com/lynis/controls/NAME-4404/ is just wrong on systems with nss_myhostname (from systemd) configured.

I've noticed that many ineffective and damaging security policies (mandating crowdstrike, increasingly arcane password requirements etc.) that businesses adopt seem to be implemented for "compliance" with ... what exactly? Sets of rules and regulations, apparently written by people who don't understand security, don't care about system reliability, availability, or usability, or have a business interest in dubious security solutions.

Re: Lynis – Security auditing and hardening tool, for Unix-based systems

#24

Post by patrakov » Tue, Nov 12, 2024, 5:42 AM UTC

musicale wrote: post #23

patrakov wrote: post #22

Rules like https://cisofy.com/lynis/controls/AUTH-9282/ are something that NIST calls outdated and dangerous password practice, but foreign security bodies mandate. Go figure. Also, the suggestion from https://cisofy.com/lynis/controls/NAME-4404/ is just wrong on systems with nss_myhostname (from systemd) configured.

I've noticed that many ineffective and damaging security policies (mandating crowdstrike, increasingly arcane password requirements etc.) that businesses adopt seem to be implemented for "compliance" with ... what exactly? Sets of rules and regulations, apparently written by people who don't understand security, don't care about system reliability, availability, or usability, or have a business interest in dubious se…

It's a chain. Take PCI DSS v4.0 for example.

Requirement 2.2.1 says: "Configuration standards are developed, implemented, and maintained to Be consistent with industry-accepted system hardening standards or vendor hardening recommendations."

Then in the third column, it mentions explicitly: "Sources for guidance on configuration standards include but are not limited to: Center for Internet Security (CIS), International Organization for Standardization (ISO), National Institute of Standards and Technology (NIST), Cloud Security Alliance, and product vendors."

CIS, at least in the past, was a significant source of overzealous pseudo-hardening. Yet, that's what auditors' automated tools check compliance with, as that's the only configuration standard with a written procedure, often a command that can be copy-pasted, to check compliance with each rule. And I am not allowed to object to the recommendations or not follow the "best practices" because otherwise the next breach will be fully on me (in financial terms).