Kibana stellt seit Version 4 den Web-Server selbst. Dieser fungiert auch als (transparenter) Proxy zwischen dem Klienten und Elasticsearch. Dennoch scheint kaum einer (der Entwickler), sich Gedanken um die Sicherheit gemacht zu haben. Hinz und Kunz werden beim Versuch, auf Kibana zuzugreifen, von nichts und niemandem (außer vielleicht der Firewall) aufgehalten. Das ist – vor allem in (größeren) Produktionsumgebungen – nicht unbedingt die wünschenswerteste Situation. Dennoch muss deswegen noch lange niemand gleich Kibana patchen (oder sich vor den nächsten Zug werfen). Diese Lücke kann auch ein Reverse Proxy schließen.
Was ist ein Reverse Proxy?
Während ein konventioneller Proxy einem Klienten die Verbindung zu n Diensten ermöglicht – also für den Klienten von ihm gestellte Anfragen an Dienste weiter reicht – macht ein Reverse Proxy das Gegenteil. Er nimmt von n Klienten Anfragen, die für einen Dienst bestimmt sind, entgegen (und reicht diese entsprechend weiter).
Anwendungsbeispiele:
- Cache
- Lastverteiler
- Honeypot
- (zusätzliche) Firewall
Abschirmung von Kibana
Der Apache HTTPd kann bspw. als Reverse Proxy dienen und muss dafür wie folgt konfiguriert werden:
ProxyPass / http://127.0.0.1:5601/ ProxyPassReverse / http://127.0.0.1:5601/
Dadurch wird Apache angewiesen, alle (`/
‘) Anfragen an Kibana weiterzuleiten und die Antworten entsprechend an die Klienten zurück zu senden.
Natürlich ist das an und für sich noch keine Abschirmung. Allerdings kann Apache (ganz einfach) mit Passwort-Authentifizierung, SSL u.v.m. ausgestattet werden.
Beispielkonfiguration:
<VirtualHost *:443> SSLEngine on SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key ProxyPass / http://127.0.0.1:5601/ ProxyPassReverse / http://127.0.0.1:5601/ <Location /> AuthType Basic AuthName "Top secret" AuthBasicProvider file AuthUserFile /etc/httpd/passwd Require valid-user </Location> </VirtualHost>
Und schon können wir etwas ruhiger schlafen. 🙂
0 Comments