Wie man Lynis-Berichte liest, um die Linux-Sicherheit zu verbessern

Die für locate erforderliche Datenbank konnte nicht gefunden werden. Führen Sie updatedb aus oder locate.updatedb um diese Datei zu erstellen. [FILE-6410]

Es sieht so aus, als müsste ich nur den Befehl updatedb ausführen , aber wenn ich sicher gehen will, kann ich Lynis' show details verwenden Möglichkeit:

# lynis show details FILE-6410
2020-06-16 20:54:33 Durchführen der Test-ID FILE-6410 (Checking Locate database)
2020-06-16 20:54:33 Test :Lokalisierungsdatenbank prüfen
2020-06-16 20:54:33 Ergebnis:Datei /var/lib/mlocate/mlocate.db nicht gefunden
2020-06-16 20:54:33 Ergebnis:Datei /var/lib/locate/locatedb nicht gefunden
2020-06-16 20:54:33 Ergebnis:Datei /var/lib/locatedb nicht gefunden
2020-06-16 20:54:33 Ergebnis :Datei /var/lib/slocate/slocate.db nicht gefunden
2020-06-16 20:54:33 Ergebnis:Datei /var/cache/locate/locatedb nicht gefunden
2020-06-16 20:54:33 Ergebnis:Datei /var/db/locate.database nicht gefunden
2020-06-16 20:54:33 Ergebnis:Datenbank nicht gefunden
2020-06-16 20:54:33 Vorschlag:Die für „locate“ benötigte Datenbank konnte nicht gefunden werden. Führen Sie „updatedb“ oder „locate.updatedb“ aus, um diese Datei zu erstellen. [test:FILE-6410] [Details:-] [Lösung:-]
2020-06-16 20:54:33 ====

Diese Details weisen darauf hin, dass Lynis verschiedene Dateien nicht finden konnte. Dieser Fall ist sehr eindeutig. Ich kann updatedb ausführen Befehl und überprüfen Sie diesen Test erneut:

# updatedb
# lynis --testet FILE-6410

Darüber hinaus zeigt die erneute Überprüfung der Details, welche Datei gefunden wurde, die den Test bestanden hat:

# lynis show details FILE-6410 
2020-06-16 21:38:40 Durchführen der Test-ID FILE-6410 (Checking Locate database)
2020-06-16 21:38:40 Test :Lokalisierungsdatenbank prüfen
2020-06-16 21:38:40 Ergebnis:Lokalisierungsdatenbank gefunden (/var/lib/mlocate/mlocate.db)
2020-06-16 21:38:40 Ergebnis :Datei /var/lib/locate/locatedb nicht gefunden
2020-06-16 21:38:40 Ergebnis:Datei /var/lib/locatedb nicht gefunden
2020-06-16 21:38:40 Ergebnis:Datei /var/lib/slocate/slocate.db nicht gefunden
2020-06-16 21:38:40 Ergebnis:Datei /var/cache/locate/locatedb nicht gefunden
2020-06 -16 21:38:40 Ergebnis:Datei /var/db/locate.database nicht gefunden
2020-06-16 21:38:40 ====

Tiefer tauchen

Viele von Lynis' Vorschlägen sind nicht so einfach wie dieser. Wenn Sie sich nicht sicher sind, worauf sich ein Ergebnis oder ein Vorschlag bezieht, kann es schwierig sein, zu wissen, wie Sie das Problem beheben können. Angenommen, Sie führen Lynis auf einem neuen Linux-Server aus, und es gibt mehrere Elemente, die sich auf den Secure Shell (SSH)-Daemon beziehen, von denen sich eines auf MaxAuthTries bezieht Einstellung:

* Erwägen Sie die Härtung der SSH-Konfiguration [SSH-7408] 
    - Details  :MaxAuthTries (6 --> 3)
      https://cisofy.com/lynis/controls/SSH-7408/ 

 Um dies zu beheben, müssen Sie den Speicherort der SSH-Konfigurationsdateien kennen. Ein erfahrener Linux-Administrator weiß vielleicht bereits, wo er sie finden kann, aber wenn Sie es nicht wissen, gibt es eine Möglichkeit, zu sehen, wo Lynis sie gefunden hat.
 
Lynis-Testskripte suchen
 

 Lynis unterstützt viele Betriebssysteme; Daher kann Ihr Installationsort variieren. Verwenden Sie auf einem Red Hat Enterprise Linux- oder Fedora Linux-System rpm So finden Sie die Testdateien:
 
# rpm -ql lynis 
 

 Dies listet alle Testdateien auf und meldet ihren Speicherort in lynis/include Verzeichnis. Durchsuchen Sie dieses Verzeichnis nach der TEST-ID, die Sie wissen möchten (in diesem Fall SSH-7408):
 
# grep SSH-7408 /usr/share/lynis/include/*
/usr/share/lynis/include/tests_ssh:   # Test        :SSH-7408
 
SSH-Probleme finden
 

 Die Datei mit dem Namen tests_ssh enthält die TEST-ID, und hier finden Sie die Scan-Funktionen rund um SSH. Werfen Sie einen Blick auf diese Datei, um die verschiedenen Funktionen zu sehen, die vom Lynis-Scanner aufgerufen werden. Der erste Abschnitt definiert eine Liste von Verzeichnissen in einer Variablen namens SSH_DAEMON_CONFIG_LOCS . Die folgenden Abschnitte sind dafür verantwortlich, den Status des SSH-Daemons zu überprüfen, seine Konfigurationsdatei zu finden und seine Version zu identifizieren. Ich habe den Code, der nach der Konfigurationsdatei sucht, im Abschnitt für Test SSH-7404 gefunden, der als „Speicherort der SSH-Daemon-Konfigurationsdatei bestimmen“ beschrieben ist. Dieser Code enthält ein for  Schleife, die die Elemente in der Liste nach einer Datei namens sshd_config durchsucht . Ich kann diese Logik verwenden, um meine eigene Suche durchzuführen:
 
# find /etc /etc/ssh /usr/local/etc/ssh /opt/csw/etc/ssh -name sshd_config
/etc/ssh/sshd_config
/etc/ssh/sshd_config 
find:'/usr/local/etc/ssh':Keine solche Datei oder dieses Verzeichnis
find:'/opt/csw/etc/ssh':Keine solche Datei oder dieses Verzeichnis
 

 Die weitere Untersuchung dieser Datei enthüllt den Code, der sich auf das Auffinden von SSH-7408 bezieht. Dieser Test deckt MaxAuthTries ab und einige andere Einstellungen. Jetzt kann ich die Variable in der SSH-Konfigurationsdatei finden:
 
# grep MaxAuthTries /etc/ssh/sshd_config
#MaxAuthTries 6
 
Rechtliche Bannerprobleme beheben
 

 Lynis meldete auch einen Befund im Zusammenhang mit den legalen Bannern, die angezeigt werden, wenn Sie sich bei einem System anmelden. Auf meinem Home-Desktop-System (wo ich nicht erwarte, dass sich viele andere Leute anmelden) habe ich mich nicht darum gekümmert, das Standard-issue zu ändern Dateien. Ein Unternehmens- oder Regierungssystem muss wahrscheinlich ein rechtliches Banner einfügen, um Benutzer zu warnen, dass ihre Anmeldungen und Aktivitäten aufgezeichnet und überwacht werden können. Lynis meldet dies mit den Tests BANN-7126 und BANN-7130:
 
* Hinzufügen eines rechtlichen Banners zu /etc/issue, um nicht autorisierte Benutzer zu warnen [BANN-7126] 
      https://cisofy.com/lynis/controls/BANN-7126/

* Rechtsbanner zu /etc/issue.net hinzufügen, um nicht autorisierte Benutzer zu warnen [BANN-7130] 
      https://cisofy.com/lynis/controls/BANN-7130/
 

 Ich finde nicht viel auf meinem System, auf dem Fedora 32 Workstation läuft:
 
# cat /etc/issue /etc/issue.net
\S
Kernel \r auf einem \m (\l)

\S
 Kernel \r auf einem \m (\l)
 

 Ich könnte etwas wie „Draußen bleiben“ oder „Nichts kaputt machen“ hinzufügen, aber die Beschreibung des Tests liefert nicht genügend Informationen, um das Problem zu lösen, also habe ich mir die Lynis-Skripte noch einmal angesehen. Mir ist aufgefallen, dass der include Verzeichnis enthielt eine Datei namens tests_banners; Dies schien ein guter Ort zu sein, um nachzusehen. Mit etwas Hilfe von grep , habe ich die zugehörigen Tests gesehen:
 
# grep -E 'BANN-7126|BANN-7130' /usr/share/lynis/include/tests_banners
    # Test        :BANN-7126
    Registrieren --test-no BANN-7126 - -preqs-met ${PREQS_MET} --weight L --network NO --category security --description "Inhalt der Bannerdatei prüfen"
    # Test        :BANN-7130
    Register --test-no BANN-7130 --preqs-met ${PREQS_MET} --weight L --network NO --category security --description "Überprüfe den Inhalt der Issue.net-Bannerdatei"
 

 Nachdem ich den zugehörigen Code in der Datei für den Test untersucht hatte, fand ich heraus, dass beide Tests einige vordefinierte Rechtsbegriffe mit einem for durchlaufen Schleife:
 
for ITEM in ${LEGAL_BANNER_STRINGS}; do 
 

 Diese rechtlichen Begriffe werden in der Variable LEGAL_BANNER_STRINGS gespeichert oben in der Datei definiert. Wenn Sie nach oben scrollen, wird die vollständige Liste angezeigt:
 
LEGAL_BANNER_STRINGS="audit access authori condition connect consent continu criminal enforce evidence forbidden intrusion law legal legislat log monitor owner penal policy policies privacy private prohibited record restricted secure subject system terms warning" 
 

 Meine anfänglichen Vorschläge ("draußen bleiben" und "nichts kaputt machen") hätten den Test nicht bestanden, da sie keine Wörter aus dieser Liste enthalten.
 

 Diese Bannernachricht enthält mehrere der erforderlichen Wörter und wird daher diesen Test bestehen und Lynis daran hindern, sie zu melden:
  

 Achtung, indem Sie sich weiterhin mit diesem System verbinden, stimmen Sie zu, dass der Eigentümer ein Protokoll aller Aktivitäten speichert. Unbefugter Zugriff ist verboten.
  

 Beachten Sie, dass diese Nachricht sowohl zu /etc/issue hinzugefügt werden muss und /etc/issue.net .
 
Wiederholbar machen
 

 Sie könnten diese Änderungen manuell vornehmen, aber Sie sollten stattdessen eine Automatisierung in Betracht ziehen. Beispielsweise müssen möglicherweise viele Einstellungen geändert werden, oder Sie müssen diese Änderungen regelmäßig auf vielen Servern vornehmen. Das Erstellen eines Härtungsskripts wäre eine großartige Möglichkeit, diesen Prozess zu rationalisieren. Für SSH-Konfigurationen einige sed Befehle in Ihrem Härtungsskript werden diese Ergebnisse beheben. Oder Sie können eine Echo-Anweisung verwenden, um die legalen Banner hinzuzufügen:
 
sed -i '/MaxAuthTries/s/#MaxAuthTries 6/MaxAuthTries 3/' /etc/ssh/sshd_config

echo "Legal Banner" | tee -a /etc/issue /etc/issue.net
 

 Die Automatisierung ermöglicht es Ihnen, ein wiederholbares Skript zu erstellen, das in Ihrer gesamten Infrastruktur gespeichert und verwaltet werden kann. Sie können dieses Skript auch in Ihre anfängliche Serverbereitstellung integrieren.
 
Härten Sie Ihr System
 

 Diese Art von Übung kann Ihre Skripterstellungsfähigkeiten verbessern, indem Sie dem vorhandenen Code folgen und Ihre eigenen Skripts schreiben. Da es sich um Open Source handelt, macht Lynis es einfach, unter der Haube zu sehen, wie Ihr System überprüft wird und was seine Berichte bedeuten. Das Endergebnis wird ein gut gehärtetes System sein, mit dem Sie jederzeit angeben können, wann diese Prüfer vorbeikommen.