Standard-Sicherheit in Solr 8.4
Apache Solr 8.4 ist aus einem Grund eine wichtige, bemerkenswerte Version: die Standard-Sicherheitseinstellungen.
Ich bekenne mich schuldig, dass ich die Sicherheitsprobleme mit Solr aus verschiedenen Gründen (Ausreden, wirklich) weitgehend abgetan habe:
- Solr ist eine Suchmaschine, die über alle Daten verfügen muss, um nützlich zu sein.
- Ich komme aus der akademischen / wissensbasierten Denkweise von Open is Better.
- Solr verlässt sich in Bezug auf Ressourcen und Konfiguration auf die bereitgestellte Umgebung, was außerhalb der Kontrolle von Solr liegt und daher „nicht [unser] Problem“ ist.
Firewall It!
„Eine Firewall!“ war die erste Antwort auf die Frage „Wie sichere ich mein Solr?“ Das ist immer noch ein weiser Rat. Aber das ist leichter gesagt als getan bei einem System, das seit jeher standardmäßig offen läuft. Angriffe/Pannen von innerhalb der Firewall sind ohnehin an der Tagesordnung. Eine Firewall zu installieren ist nicht die Antwort auf die eigentliche Frage (obwohl „Natürlich sollten Sie eine Firewall einrichten“). Die Antwort ist, dass Solr seine eigene Sicherheit haben muss.
Sicherheit ist ein vielschichtiges Thema, das offene, gebundene Ports, vom Server zur Verfügung gestellte Endpunkte und deren Fähigkeiten, die Authentifizierung und Autorisierung von Benutzern, die auf das System zugreifen, bis hin zu den verfügbaren Daten und den Anforderungen an die Zugriffskontrolle für die einzelnen Daten und schließlich sogar die Ressourcen umfasst, die auf oder von den zur Verfügung gestellten Systemen verfügbar sind.
Was wurde in Solr 8.4 behoben?
Das Apache Solr-Team hat im letzten Jahr mit mehreren Sicherheitslücken zu kämpfen gehabt. Mit großer Anerkennung und Dankbarkeit gegenüber den anderen Solr-Committern, in diesem Fall insbesondere Ishan und Noble, habe ich den Schlamassel beseitigt, den ich in einer uralten Funktion angerichtet hatte, die ich zu Solr beigesteuert hatte, und direkt an der Behebung der Zero-Day-RCE-Schwachstelle (Remote Code Execution) gearbeitet.
Es gibt mehrere Kategorien von sicherheitsrelevanten Änderungen in dieser Version: Hinzufügung von sicherheitsrelevanten HTTP-Antwort-Headern, die Entfernung von eingebauten „contrib“-Modulen aus der Standardkonfiguration der Sammlung, die Härtung von VelocityResponseWriter und Funktionen zur Paket-/Pluginverwaltung.
Sicherheitsrelevante HTTP-Header
SOLR-13982 mehrere zusätzliche Header zu den HTTP-Antworten von Solr hinzugefügt, um die Ausführung von Inline-JavaScript, Cross-Site-Scripting (XSS) und Cross-Origin-HTML-Frames zu verhindern
Entfernung der „contrib“-Module aus der Standardkonfiguration der Sammlung
Wir haben es zugelassen, dass die Standardkonfiguration von Solr zu einer Ansammlung verschiedener Endpunkte wird, und zwar durch so genannte „Contrib“-Komponenten (in die Distribution integriert, aber separate Komponenten, die einfach hinzugefügt werden können). Diese Komponenten sind leistungsfähig (ermöglichen Skripting-Funktionen), werden aber nicht so gut unterstützt wie der Kerncode von Solr. Es ist selten, dass man all diese Dinge _wirklich_ ausführt, aber sie sind für alle standardmäßig mit `bin/solr create -c <collection>` erstellten Sammlungen seit jeher einsatzbereit.
Dies ist nun nicht mehr der Fall, mit den folgenden drastischen Änderungen am Standard-Configset ( SOLR-13978):
- Einbindung von Bibliotheken (<lib ../>) für Extraktion, solr-cell libs, clustering, velocity, LTR und Sprachkennung
- /browse, /tvrh und /update/extract Handler
- TermVector Komponente
(wenn jemand es möchte, kann es über die Konfigurations-APIs hinzugefügt werden) - XSLT-Antwortschreiber
- Velocity Response Schreiber
Wenn Sie diese Komponenten in Ihren Sammlungen verwenden möchten, müssen Sie nur noch die erforderlichen Teile zu einem vertrauenswürdigen Configset Ihrer Wahl hinzufügen, indem Sie das Configset über ZK-Operationen oder Config-APIs bearbeiten.
Außerdem können nicht vertrauenswürdige Configsets (solche, die über eine ungesicherte Configset-API hochgeladen werden) die Direktive <lib> nicht verwenden. (über SOLR-14071)
Ich arbeite an einem Update für die https://lucidworks.com/post/solr-5-new-binpost-utility/ Reihe von Artikeln aufgrund dieser Änderungen, da all diese Annehmlichkeiten, wie das einfache Erstellen einer Sammlung, das Einstellen von Daten und die visuelle Navigation in den Suchergebnissen mit ein paar Befehlen, nicht mehr selbstverständlich sind… zu Ihrem eigenen (Standard-)Wohl, wohlgemerkt.
Härtung des VelocityResponseWriters
Ich habe dieses Ding gebaut, um *alles* und *alles* machen zu können. Velocity ist eine Vorlagenbibliothek, die die Ausgabe von Verarbeitungsmakros rendert, die letztendlich Java-Objekte mit Methoden sind. Der VelocityResponseWriter packt alles in den Velocity _Kontext_, die „Daten“ (ähm, Objekte), die den Vorlagen zur Verfügung stehen, sind reichhaltig. Hier bin ich zu weit gegangen, oder besser gesagt, ich habe es mir leicht gemacht und den Templates alles gegeben, obwohl sie eigentlich nur ein paar Schlüssel/Wert-Strings zum Rendern benötigen und keine Objektgraphen, die zu `$rt.getRuntime().exec(…)` navigieren können. Oh die Macht!
Solr 8.3.1 war ein erster Versuch, dieses Problem zu lösen, ließ aber eine weitere Tür offen. Mit der Version 8.4 wurden alle bekannten und auch viele theoretisch und technisch mögliche Wege geschlossen. Da diese Komponente nicht mehr standardmäßig registriert ist, ist sie kein Vektorkandidat, der sofort einsetzbar ist.
Funktionen zur Verwaltung von Paketen/Plugins
SOLR-13821 gibt uns einen soliden Start für einen der heiligen Grale von Solr – eine sicherheitsbewusste Paketverwaltung. Pakete, die in .jar-Dateien gekapselt sind, müssen signiert sein und von einem vertrauenswürdigen Paketspeicher gehostet werden. Wir erwarten, dass die Komponenten, die aus der Standardkonfiguration entfernt wurden, im Zeitrahmen von Solr 9.0 als neue und verbesserte, leicht installierbare Pakete wieder auftauchen werden.
Seien Sie vorsichtig da draußen
Mit Solr 8.4 erhalten wir einen straffen, sicheren Kern, der nach wie vor alle leistungsstarken Komponenten für authentifizierte, vertrauenswürdige Konfigurationen bereitstellt. Das Team wird sich weiterhin um die Sicherheit bemühen und gleichzeitig alle notwendigen Funktionen sicher bereitstellen.