m_ueberall
Danke für die Lösungsansätze.
Aktuell habe ich Checkmk normal ohne Docker etc installiert. Die Datenverbindungen zwischen Agent und Server sind secure.
Aber dass man von außen an */monitoring/ an die Login-Seite gelangt ist mir nicht so wohl dabei.
Daher habe ich aktuell omd temporär deaktiviert.
Funktioniert es in meinem Fall der Installation (wie ich Checkmk aufgesetzt habe) wenn man dies über via iptables/nftables löst?
Alles anzeigen
Ich selbst verwende Checkmk nicht; auf Basis der Installationsbeschreibung hier ist die Lösung tatsächlich noch einfacher, wenn Checkmk den "system-apache" als Reverse Proxy (auf Ports 80/443) verwendet, während der "site-apache" auf Port 5000 läuft.
Um diese Annahmen zu verifizieren, kann man als root nach Starten aller Apache-Instanzen auf der Konsole ein "LANG=C netstat -tulpen | grep -E '^[AP]|:5000'" eingeben (Abfrage, auf welche IP-Adressen/Ports der "site-apache" reagiert; "netstat" kann man via "apt-get -y install net-tools" installieren, wenn nicht vorhanden).
(1) Wenn der vorherige Befehl sowas zurückliefert wie "tcp […] 0.0.0.0:5000" bzw. "tcp6 […] :::5000", dann lauscht/reagiert der site-apache auch auf Abfragen von außen über die offizielle IP-Adresse. Das sollte man unterbinden – vorzugsweise über eine Konfigurationsänderung auf dem Host/Raspi selbst.
(2) Daneben ist zu beachten, dass der Reverse Proxy (der "system-apache" im referenzierten Post) grundsätzlich auch auf allen IP-Adressen lauscht und auf externe Abfragen antworten würde – selbst wenn man den "site-apache" oben auf localhost einschränken würde (wenn das nicht schon der Fall ist), darf/muss der Zugriff über den "system-apache" (zwangsweise) immer auch via 127.0.0.1 erfolgen (die alleinige Absicherung vom "site-apache", den Checkmk mitbringt, würde beim Zugriff über den Reverse Proxy/system-apache also immer "unterlaufen" werden). Ergo muss man auch die von "system-apache" gelesenen Konfigurationen, die checkmk mitbringt, insofern ändern, dass hier nur ein lokaler Zugriff möglich ist.
^ ^ Einschub: Nach Lesen obiger Konfiguration scheidet die iptables/nftables-Lösung dann aus, wenn Teile des "system-apache" (also andere auszuliefernden Seiten) immer verfügbar sein sollen und nur "*/monitoring/" lediglich lokal ausgeliefert werden soll – denn hier muss die Filterung/Zugriffssteuerung auf Apache-Ebene (Applikationsebene) erfolgen – iptables/nftables bzw. eine Einschränkung der IP-Adressen, auf welche der system-apache hört, läuft nur auf TCP/IP-Ebene.
(2b) Soll der "system-apache" und der "site-apache" vollständig nur lokal verfügbar sein (kein Problem, wenn man von außen zuvor via ssh auf den lokalen Rechner wechselt), dann empfiehlt sich für beide Instanzen eine Einstellung in /etc/apache2/ports.conf (für den "system-apache" -- keine Ahnung, wo der "site-apache" seine Konfiguration ablegt, nicht nachgeschlagen):
#Statt der Namen unten, die vom DNS-Server aufgelöst werden können müssen (wäre ggf. einzutragen!), kann man direkt "127.0.0.1" bzw. "::1" verwenden – hier nur zur Verdeutlichung, was man haben will:
Listen ip4-localhost:80
Listen ip4-localhost:443
Listen ip6-localhost:80
Listen ip6-localhost:443
(Alle anderen "Listen"-Direktiven sind natürlich aus der Datei "ports.conf" zu entfernen; nach Neustart der jeweiligen Apache-Instanz kann wieder "netstat -tulpen | grep -E ':80|:443|:5000'" zur Überprüfung herangezogen werden, wo es jetzt keine "0.0.0.0"- bzw. ":::"-Einträge mehr geben darf.)
(2c) Wenn man nicht darauf vertraut, dass obige Einstellungen Bestand haben nach Veränderung der Konfigurationsdateien, kann man zusätzlich via iptables/nftables die entsprechenden Ports 80, 443 (system-apache) und 5000 (site-apache) ggü. Zugriffen von anderen IP-Adressen blockieren. Hier ist aber zusätzlich zu beachten, dass man normalerweise daheim irgendeine Fritz-Box o.ä. vom Internet-Provider vor dem internen lokalen Netzwerk hat, und auch hier müsste man überhaupt explizit einmal die entsprechenden Ports (nur 80, 443) freischalten.
(2d) Zur Einschränkung auf Apache2/Anwendungsebene: In den von Checkmk eingebundenen Regeln sollte sich ein Konstrukt ähnlich dem Folgenden für den "Reverse Proxy" (system-apache) finden ("ähnlich" insofern, als dass irgendwo eine "Directory"-Definition stehen muss, die den Zugriff regelt – das unten ist keine Reverse-Proxy-Definition, die wäre länger; alternativ könnte ggf. auch eine "Location"-Definition zur Anwendung kommen):
<Directory /blahblubb/monitoring/>
DirectoryIndex index.php
Options -Indexes +FollowSymLinks
AllowOverride FileInfo Options
Require ip 192.168.0.0/16 172.16.0.0/16 10.0.0.0/8 127.0.0.1 ::1
</Directory>
Hier ist lediglich die letzte Zeile zu ergänzen – diese regelt, dass Apache alles unterhalb von /blahblubb/monitoring/ nur dann ausliefert, wenn die Anfrage (an den system-apache/Reverse Proxy über Port 80/443) von einer lokalen IP-Adresse kommt.
(
)
