Als Systemadministrator haben Sie vielleicht schon die Freude (?) erlebt, Ihre Systeme von einem Sicherheits- oder Risikomanagement-Experten prüfen zu lassen. Sicherheitstools, die von Prüfern verwendet werden, scannen im Allgemeinen Systeme und erstellen einen Bericht für den Prüfer, in dem die auf dem gescannten System gefundenen Schwachstellen hervorgehoben werden, den der Prüfer dann dem Team vorlegt, das die Systeme verwaltet. Es wird erwartet, dass das Administrations- und Managementteam die gemeldeten Schwachstellen beheben wird. Bei Enterprise-Linux-Distributionen sind die vom Prüfer empfohlenen Abhilfemaßnahmen jedoch möglicherweise nicht die beste Wahl für die Anwendung durch das Unternehmen.
Informationen abrufen
Beginnend mit einem Beispiel beginnen viele dieser Auditing-Tools damit, ein Zielsystem zu scannen und sich mit offenen Ports zu verbinden, um Daten über die von der Maschine angebotenen Dienste zu sammeln. Hier ist ein Beispiel für einen Portscan von meinem eigenen System, generiert von nmap Befehl:
[root@somebox ~]# nmap 10.200.157.174
Starting Nmap 6.40 ( http://nmap.org ) at 2020-01-29 13:40 CET
Nmap scan report for 10.200.157.174
Host is up (0.000010s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds
Aus dieser Ausgabe können Sie ersehen, dass die Ports 22, 80 und 111 für Dienste verfügbar sind, die eine Verbindung zu diesem System herstellen. Ein Sicherheitsüberwachungstool stellt dann wahrscheinlich eine Verbindung zu jedem dieser Ports her, um festzustellen, was auf ihnen ausgeführt wird, oder es verwendet möglicherweise ein Profilerstellungsprogramm, um diese Daten zu sammeln und zu analysieren. Ich werde telnet verwenden Befehl, sich mit dem Port 80 dieser Maschine zu verbinden, um festzustellen, was dort läuft:
[root@somebox ~]# telnet 10.200.157.174 80
Trying 10.200.157.174...
Connected to 10.200.157.174.
Escape character is '^]'.
help
HTTP/1.1 400 Bad Request
Date: Wed, 29 Jan 2020 12:46:39 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux)
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
Connection closed by foreign host.
Nachdem die Verbindung hergestellt war, musste ich eine Anfrage an den Dienst stellen. In diesem Fall habe ich das Wort „Hilfe“ eingegeben, das je nach Dienst ein Befehl sein kann. Für den Dienst, der auf Port 80 dieses Systems läuft, ist help jedoch kein verstandener Befehl. Als Ergebnis wird ein Fehler erzeugt. In der Kopfzeile sehen Sie einige Informationen über das System und den Dienst. Insbesondere ist der Dienst an diesem Port die Apache-Version 2.4.6.
Sicher genug, wenn ich diese Informationen verifiziere, indem ich mir eine yum list anschaue , Apache Version 2.4.6 ist die Version, die auf dem Computer installiert ist und ausgeführt wird:
[root@somebox ~]# yum list httpd
… output truncated…
Installed Packages
httpd.x86_64 2.4.6-89.el7_6.1 @rhel-x86_64-workstation-7.6
Umgang mit dem Bericht des Wirtschaftsprüfers
Hier beginnen die Dinge interessant zu werden. Meiner Erfahrung nach landet der Prüfbericht auf dem Schreibtisch und es heißt so etwas wie:
Alte Version von Apache (2.4.6) erkannt, die mehrere Schwachstellen aufweist, die in neueren Versionen von Apache geschlossen wurden.
Empfehlung:Installieren Sie die aktualisierte Version von Apache, 2.4.41, die neueste.
An diesem Punkt sollten Sie als Unternehmens-Linux-Bereitstellung aufhören. Verstehen Sie, dass der Bericht des Prüfers hervorhebt, dass dieses System gemäß den System-Scan-Informationen möglicherweise offene Schwachstellen aufweist. Der Bericht des Prüfers ist richtig, dass die Installation der neuesten Apache-Version von apache.org dieses Problem lösen würde. Da es sich jedoch um ein Unternehmens-Linux-System handelt, sind diese potenziellen Schwachstellen wahrscheinlich bereits in der Version von Apache geschlossen, die derzeit auf dem System bereitgestellt wird.
Beachten Sie, dass die Version auf dem System 2.4.6-89.el7_6.1 ist, wobei 2.4.6 die tatsächliche Versionsnummer und die zusätzliche Versionsnummer ist für dieses Paket ist 89.el7_6.1. Enterprise-Linux-Distributionen nehmen häufig Korrekturen für Probleme aus neueren Releases und portieren diese Korrekturen in eine ältere Codebasis zurück und kompilieren dann eine aktualisierte Version dieses älteren Softwarepakets. Bei Red Hat Enterprise Linux, dem Betriebssystem auf meinem Beispielsystem, verfolgen die Ingenieure, die das Apache-Paket verwalten, diese angewendeten Änderungen über diese zusätzliche Versionsnummer im RPM-Paket.
Einige Wirtschaftsprüfer wissen das bereits, und einige Tools berücksichtigen auch diese Art der Softwareverwaltung. Manchmal arbeiten Sie jedoch mit jemandem zusammen, der ein weniger ausgefeiltes Scan-Tool verwendet. Nicht nur das, diese Person ist sich möglicherweise auch nicht bewusst, dass die ältere Version von Apache auf diesem System die richtige ist Version auf diesem Rechner installiert sein muss und dass die Sicherheitslücken, mit denen sich Sicherheits- oder Risikomanagement-Mitarbeiter befassen würden, bereits geschlossen sind. Und als Systemadministrator müssen Sie häufig erklären, warum Ihre Organisation entgegen der Empfehlung des Prüfers nicht die aktuellste Version dieses Pakets installieren sollte.
Meiner Erfahrung nach lässt sich dieser Punkt am besten veranschaulichen, indem man sich die zusätzlichen Daten ansieht, die in der Linux-Version dieses Softwarepakets für Ihr Unternehmen enthalten sind. Viele Unternehmens-Linux-Distributionen verwenden Funktionen wie das RPM-Änderungsprotokoll, um diese Daten hervorzuheben. Hier sind die Informationen aus meinem Beispielsystem:
[root@somebox ~]# rpm -q httpd --changelog
* Tue Jun 25 2019 Lubos Uhliarik <> - 2.4.6-89.1
- Resolves: #1719722 - CVE-2018-1312 httpd: Weak Digest auth
nonce generation in mod_auth_digest
… output truncated …
Laut der oben verlinkten CVE-Meldung wurde diese Schwachstelle in Apache erst nach 2.4.29 behoben. Sie können jedoch in der Ausgabe des Änderungsprotokolls dieses Pakets sehen, dass ein Fix für CVE-2018-1312 zurückportiert und auf die derzeit installierte Codebasis angewendet wurde, die auf Apache 2.4.6 basiert. Diese Tatsache bedeutet, dass mein Beispielsystem nicht angreifbar ist auf diesen Exploit, obwohl es sich um eine ältere Version der Apache-Software handelt.
Warum ist das alles wichtig? Wenn Sie eine Unternehmens-Linux-Distribution verwenden, tun Sie dies wahrscheinlich, weil Sie Änderungen, potenzielle Konflikte und andere Software-Nichtübereinstimmungsprobleme auf ein Minimum beschränken möchten. Ein Upgrade von Apache, wie in der Audit-Empfehlung angegeben, würde dem Ziel zuwiderlaufen, Änderungen auf ein Minimum zu beschränken. Wenn Sie ein Kunde mit kommerziellem Support sind, würde Ihr Anbieter Apache-bezogene Probleme auf diesem Computer wahrscheinlich nicht mehr unterstützen, wenn Sie zu einer Version wechseln, die nicht mit seiner Distribution geliefert wird.
Abschluss
Um einen Prüfbericht wie im obigen Beispiel zu überstehen, müssen Sie mit dem Prüfer zusammenarbeiten, um sicherzustellen, dass er versteht, wie Unternehmens-Linux-Pakete gewartet werden (dass die auf dem Port angezeigte Version möglicherweise nicht mit der auf dem System installierten Version übereinstimmt). , und dass der Enterprise-Linux-Packager im Allgemeinen ältere Versionen dieser Pakete verwaltet, um Schwachstellen zu berücksichtigen, die ein Prüfer, Computersicherheitsexperte oder ein Risikomanagementmitarbeiter finden könnte. Die Verwendung von Daten wie Änderungsprotokollinformationen kann dabei helfen, dieses Konzept der Rückportierung und Enterprise-Linux-Paketverwaltung zu demonstrieren.
Möchten Sie Red Hat Enterprise Linux ausprobieren? Jetzt kostenlos herunterladen.