This is the same kind of thinking which has not changed since 1990 when Improving the Security of Your Unix System¹ was published. It was good in 1990, but even five years later seemed to be an obsolete kind of thinking, and today seems positively archaic. If there are known security problems, they should be fixed in the operating system itself. If there are known bad defaults in software as distributed, this should be fixed by the packagers for the distributions.
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.
I agree, the way of thinking about these tools is faulty.
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.
As the author of the tool, I can share that these tools are still very much needed. Why? Upstream vendors will never set values that are strict. Because in that case, people would have too much difficulty to get things working.
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.
Don't worry, a lot of people use these types of tools for the right reasons and in the understanding that there is a bigger picture. They just don't feel the need to get all preachy about it.
I've already got a use in mind for it where it could certainly help me save some time. Thanks for your work!
> Upstream vendors will never set values that are strict. Because in that case, people would have too much difficulty to get things working.
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.
Not everyone comes with the same skill set or expertise. If you work at a big multinational, reinstalling hundreds or even thousands of systems, is no option. Lynis, free to use, simply helps you determining the sanity level in a quick way.
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 :)
With only a quick glance at the checks/code, this will suggest stupid things on Solaris. Solaris 11 has configuration compliance checker that is far more complete (and uses the correct interfaces) than 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.
Appreciate the honest opinion. While you have valid points, not everyone wants to install SCAP for example. Besides that, the related SCAP might even not be available for your OS version. If the OS has a great compliance checker built-in, we definitely will advise using that as well.
10 comments
[ 4.3 ms ] story [ 35.7 ms ] threadAll 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.
① http://csrc.nist.gov/publications/secpubs/curry.pdf
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.
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 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.
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.