Lynis – Security auditing tool for Unix/Linux systems
cisofy.com
cisofy.com
All talk of "hardening" and "scanning" is symptomatic of this faulty way of thinking.
However, I fear that these kinds of things will continue to exist, for one simple reason: Running these programs and applying these fixes manually feels useful to the sysadmin. It gives the sysadmin a little boost of self-esteem, merely for, essentially, pushing a button. If instead these fixes were applied upstream, there would be no need for hardening or scanning, and the program would be useless, but this would deprive sysadmins of their free feeling of usefulness.
The tool exists to simplify testing many individual tests. We don't simply use existing benchmarks or guides, but also have tests of our own. For example, if you have configured at least two name servers, or that your time is properly configured, and no false-tickers are present. Things which no upstream vendor even can configure for you.
Another common use case: you are the new system administrator and have to deal with the "great" work of the previous one. The tool helps to determine the quality of the previous person, in just a matter of minutes.
I've already got a use in mind for it where it could certainly help me save some time. Thanks for your work!
If the upstream software author won’t fix it, and the Debian Maintainer (packager) won’t fix it, and if the Debian Technical Committee chooses not to overrule the Debian Maintainer, then it’s probably not actually a problem.
> if you have configured at least two name servers, or that your time is properly configured, and no false-tickers are present. Things which no upstream vendor even can configure for you.
This, on the other hand, does sound like a nice set of features, but this is then no longer a “Security audit” tool. Ideally, of course, these kinds of checks should be integrated into their respective programs/packages.
> you are the new system administrator and have to deal with the "great" work of the previous one.
Either you know that you can’t trust the previous sysadmin, in which case you have to reinstall anyway, or you start out trusting them, in which case you wait until you actually find something bad, and only then reinstall. I don’t really think this use case is very useful.
The main focus of Lynis is security auditing. Since some parts are so important for integrity of the systems or forensics, we do check them. Proper timing is one of them, proper DNS configuration is another one. Some things you want to put into your monitoring system as a regular test, other will be handled by the tooling itself. What we find, is that Lynis often detects incorrect configurations. That is exactly the purpose of the tool. Helping those, who didn't know, or thought things were fine.
Appreciate your stance, understand it and even agree with most of it. The tool is there to help to achieve what we both see as an ideal world: secure permissions by default, proper configurations, correct monitoring and integrity of data. Till the time we achieved that, I'm glad to see many were able to move up a few steps to this ideal world. Till then, happy hardening :)
I see this a lot in environments I've worked in, where the NIST 800-53 and DISA STIGs are the order of the day. Nearly all admins and auditors both immeditally jump to the list of checks, and start going down the list. It can be manually, or with an assessment tool, but for every instance where the value in bit position "X" doesn't match what's in the book, it's a "finding, and must be changed".
I think tools like these are useful, but they're almost always used in the wrong way. I tell my admins that these tools aren't to assess the risk to a system (which is far more complicated a measurement than a single checklist) but an awareness tool. The lists are to make you aware of services and entries you're exposing in the system. They're not inherently vulnerabilities if they're part of a well-conceived service who's proper operation and potential risks have been accounted for. When I read output from these, I think "Hey, this says I'm running HTTP without encryption. These are the potential implications of this decision. Is this the functionality I intended?" If so, document (if it isn't already) and move on. If it's not intended (oops, I wanted this to be HTTPS only!) then I know I have a configuration issue.
I'm aggravated when I get some laundry list of "findings" and being told they need to be reduced to 0. Simply smashing the "remediate all" button is going to leave them with a broken system. It's a hard fight trying to explain that they were never intended for this.
On solaris 11.2+ man compliance, and follow one set of the vendor recommendations (normal, high assurance, pci-dss).
The SCAP ecosystem exists, I see no need in this day and age to use shell scripts for configuration parsing.
I would love to hear how a host-based scanner is more in-depth than a Nessus or Rapid 7 scan running on a sudo account.