
Lynis – Security auditing tool for Unix/Linux systems - blacksqr
https://cisofy.com/lynis/
======
teddyh
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.

①
[http://csrc.nist.gov/publications/secpubs/curry.pdf](http://csrc.nist.gov/publications/secpubs/curry.pdf)

~~~
mboelen
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.

~~~
teddyh
> _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.

~~~
mboelen
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 :)

------
tux
Arch package available in AUR at
[https://aur.archlinux.org/packages/lynis/](https://aur.archlinux.org/packages/lynis/)

------
reiger
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.

~~~
mboelen
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.

------
ki11a11hippies
"Host based scans provides more in-depth audit."

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.

