Reverse Proxy für Websocket der VISU mit Apache

Hallo Zusammen,

ich wurde vor längerer Zeit gefragt, ob ich den Weg meiner Implementierung mit Apache hier niederschreiben könnte, was ich hiermit erledigen möchte.

Warum man das macht und wie das ganze mit NGINX funktioniert hat psilo sehr gut auf dieser Seite erklärt!

Deswegen möchte ich auch hier nur auf die Änderungen zu Apache eingehen und setzte also Voraus, dass man weiß was man erreichen will und auch über die genannte Seite von psilo geschaut hat!

Als kleine Änderung will ich hier gleich anmerken, dass ich keine extra Maschine als Reverse Proxy einsetzte, da ich bei mir soweit alles abgesichert habe und darin einige Erfahrung habe 🙂

Damit gehe ich also auch davon aus, dass ihr Apache auch für eure smartVISU einsetzt, wie ich es mache. Falls nicht müsst ihr natürlich apache nachinstallieren.

Unter Debian/Ubuntu/Raspbian funktioniert das mit:

sudo apt-get update
sudo apt-get install apache2

Unter Ubuntu 18.04 habe ich auch keine weiteren Module (wie libapache2-mod-XXX) für Apache benötigt. Ob dies bei allen Debian-basierenden Distributionen der Fall ist müsste man im Einzelfall prüfen. Man wird es auf jeden Fall merken, wenn sich die kommenden Befehle zum aktivieren der Module nicht durchführen lassen.

Nun müssen wir die folgenden Module aktivieren:

sudo a2enmod proxy_wstunnel
sudo a2enmod rewrite
sudo a2enmod setenvif

Bei Apache arbeite ich gerne nach dem modularen Prinzip, weswegen ich mir für die Einstellungen die ich brauche, einer eigene Konfigurationsdatei mit dem Namen /etc/apache2/smartvisu.conf angelegt habe, die ich hier entsprechend erläutern möchte.

<IfModule mod_rewrite.c>
   RewriteEngine on

   # Eine Umleitung vom Ordner zur index.php (es gab da mal einen Bug,
   # in der alten VISU, keine Ahnung ob das noch aktuell ist, schaden
   # tut es aber nicht, man kann es aber gerne auch weglassen)
   RewriteCond %{REQUEST_URI} ^/smartVISU$ [NC,OR]
   RewriteCond %{REQUEST_URI} ^/smartVISU/$ [NC]
   RewriteRule .* /smartVISU/index.php [R=302,L]

   # Mit dieser Definition wird der Reverse Proxy für Websocket aktiviert
   # Da wie oben schon erwähnt, die VISU und SH bei mir auf dem lokalen Host
   # läuft, verwende ich hier als Ziel auch localhost. Das kann man aber
   # natürlich Anpassen und soll auch nur als Beispiel dienen.
   <IfModule mod_proxy.c>

      ProxyPreserveHost On
      ProxyVia On

      # socket.io 1.0+ starts all connections with an HTTP polling request
      RewriteCond %{QUERY_STRING} transport=polling [NC]
      RewriteRule /(.*) http://localhost:2424/$1 [P]

      # When socket.io wants to initiate a WebSocket connection, it sends an
      # "upgrade: websocket" request that should be transferred to ws://
      RewriteCond %{HTTP:Upgrade} websocket [NC]
      RewriteRule /(.*) ws://localhost:2424/$1 [P]
   </IfModule>

   # Hier ist Platz für spezielle Ausnahmen (die wie unten mit SetEnvIf
   # gezeigt nicht abgebildet werden können), z.B. für eine Manifest-Datei die
   # ich mir in die VISU rein Programmiert habe. Hier wird beim Auffinden
   # des entsprechenden Query-Strings die Umgebungsvariable
   # no_auth_required auf 1 gesetzt, was dann weiter unten ausgewertet wird
   # und dann dazu führt, dass keine Anmeldung erforderlich ist
   RewriteCond %{QUERY_STRING} page=manifest
   RewriteRule ^/smartVISU/index.php - [E=no_auth_required:1]
   # !! Das ist natürlich nur ein Beispiel und wäre bei euch nicht erforderlich !!

</IfModule>

# Hier definiere ich wann man sich anmelden muss und wann nicht und
# das gilt dabei für den kompletten Webserver Stamm also ab der Wurzel.
# Das ist !Wichtig!, da so auch automatisch die Websocket-Verbindung
# per Basic Auth geschützt wird!
<Location />
   # Hier kann ich dann wieder Dinge freigeben, die ohne Anmeldung funktionieren sollen
   # (wie auch weiter oben im Beispiel, nur das es mit SetEnvIf etwas einfacher geht)
   # z.B. kann sich jeder meine Temperatur Statistik im Unterordner /mytemplogger ohne
   # Anmeldung ansehen, dazu setzte ich wieder die Umgebungsvariable no_auth_required auf 1
   SetEnvIf Request_URI ^/mytemplogger no_auth_required=1

   # Dann definiere ich die Basic Auth Parameter
   AuthName "Private"
   AuthType Basic
   AuthUserFile /etc/apache2/htpasswd
   Require valid-user

   # Hier gebe ich an, dass man sich über die lokalen Netze nicht anmelden muss,
   # dass muss also jeder für sich Anpassen. Wer kein IPv6 hat kann die /64 Adressen
   # natürlich auch weg lassen
   Require ip 192.168.XX.0/24 2a02:810c:XXX:XXX::/64 fd00:XXXX:XXXX:XXXX::/64 fe80::/64
   # Und hier wird die Ausnahme mit der Umgebungsvariable definiert, so kann man einfacher
   # Seiten oder Aufrufe als Ausnahme definieren
   Require env no_auth_required

</Location>

Dann müssen wir uns natürlich die zuvor verwendete /etc/apache2/htpasswd anlegen:

htpasswd -cB /etc/apache2/htpasswd BENUTZER
New password: MEINSUPERPASSWORD
Re-type new password: MEINSUPERPASSWORD
Adding password for user visu

# Und dann die Rechte anpassen:
chmod 660 /etc/apache2/htpasswd

Wobei BENUTZER der Benutzername ist den man anlegen möchte. Es können natürlich mehrere Benutzer angelegt werden. Man sollte aber hier wirklich ein sicheres Passwort verwenden, da dies nicht vor Brute-Force Angriffen geschützt ist. Wobei man ganz klar die Webseite nochmal in mehreren wegen etwas weiter Schützen kann. Aber dazu später mehr.

Nun kann man auf jeden fall schon seine Konfiguration für den virtuellen Host anpassen. Im Standardfall wäre dass die /etc/apache2/sites-enabled/000-default.conf oder eben die von euch genutzte Datei. Da ich bei mir mehrere virtuelle Hosts habe, die jewels ein eigenes Zertifikat (Stichwort SSL) haben (für internen Host – ohne SSL, für externen Host – mit SSL, für den vom Internet und Intern aus erreichbaren IPv6 Host – mit SSL), kann ich jetzt die smartvisu.conf überall einbinden und hab eine zentrale Stelle für die Anpassungen.

Die nötige Anpassung zum Einbinden der Konfiguration sieht wie folgt aus:

Innerhalb des <VirtualHost></VirtualHost> Blocks muss nur noch folgende Zeile eingefügt werden:

Include /etc/apache2/smartvisu.conf

Jetzt könnte man den Apache2 neustarten und testen.

service apache2 restart

Nützliche Tipps zur Absicherung

Zum Absichern gibt es mehrere Faktoren – vieles hier setzt zwar auf Verschleierung/Tarnung (was eine gute Methode ist, Angriffe gar nicht erst aufkommen zu lassen), aber natürlich nicht ausschließlich:

• ) Die Webseite auf jeden Fall mit SSL absichern!! Auch ich verwende für die externen Zugriffe den kostenfreien Service von Let’s Encrypt. Möglich wäre aber auch ein self-signed Zertifikat (Anleitungen gibt es dazu wie Sand am Meer) aber eben nicht so schön und nicht ganz so sicher, oder wer von euch prüft schon den Fingerabdruck den Zertifikats?!
• ) die Brute-Force Angriffe auf die Basic-Anmeldung kann man ganz einfach mit fail2ban Abfangen/-mildern (Abmildern deswegen, da es möglich wäre auch ein Angriff von mehreren IPs zu koordinieren, was fail2ban nicht abfangen könnte), was ich trotzdem nur jeden empfehlen kann, weswegen ich es auch kurz erklären möchte:
  Zuerst installiert man das Paket mit sudo apt-get install fail2ban
  dann erstellen wir uns eine local.conf, in dem wir das definieren was nicht in der Standardkonfiguration erfasst ist. Man könnte zwar auch die Standardkonfiguration unter /etc/fail2ban/jail.conf bearbeiten, aber übersichtlicher wird es mit meiner vorgeschlagenen Variante. Dazu öffnen wir mit dem Editor unserer Wahl die Datei /etc/fail2ban/jail.d/local.conf und aktivieren die Jail für die Definition von apache-auth wie folgt:

  [apache-auth]
  enabled = true
  

  und danach können wir fail2ban neu laden mit sudo fail2ban-client reload und den Status prüfen mit sudo fail2ban-client status.
  
  Wichtig: Hat man den Protokollpfad seines Apache Vhosts modifiziert, muss man den Pfad für die Jail nochmals prüfen und ggf. in unserer local.conf überschreiben. Prüfen kann man das nochmal in der Datei /etc/fail2ban/jail.conf bzw. /etc/fail2ban/paths-arch.conf (dort steht bei meinem Ubuntu die Variable apache_error_log).

• ) Keine Standard-Ports für den Zugriff auf den Webserver von Extern verwenden. Das hält die ganzen Scanner davon ab die Seite zufällig zu finden. Natürlich wird ein gezielter Angriff (mit Port-Scan) die Seite trotzdem aufdecken, egal welcher Port verwendet wird. Dies wiederum könnte man mit Port Knocking (fwknop/knockd) ausschalten, finde ich aber überflüssig, da es das ganze wieder unnötig verkompliziert.
• ) zusätzlichen Schutz würde auch noch eine zwei-Faktor Anmeldung bringen, z.B. über den Google Authenticator, der den offener Standard OATH (Initiative for Open Authentication) umsetzt und leicht verwendet werden kann. Dazu verweise ich aber z.B. auf diese Anleitung.
• ) Client Zertifikate wären natürlich auch möglich, halte ich aber auch für Übertrieben/zu kompliziert und diese können genau so gut über einen Trojaner geklaut werden – dann lieber 2-Faktor 😉
• ) den Webserver vor Zugriffen aus dem Ausland schützen wäre natürlich auch unter Apache möglich, alternativ mit iptables. Aber mal ehrlich, wenn ich im Urlaub bin will ich auch darauf zugreifen und nicht extra dran denken müssen es frei zu schalten.
• ) die Seite nicht öffentlich im Web verlinken, da b) sonnst auch keinen Sinn macht. Nicht dass wir was zu verbergen haben – aber wie heist es so schön: Schlafende Hunde soll man nicht wecken
• ) dafür sorgen dass das System aktuell gehalten wird – Stichpunkt UnattendedUpgrades, was es sowohl unter Debian und Ubuntu gibt. Auch sollte nur eine Distribution eingesetzt werden, welche auch noch vom Anbieter unterstützt wird.
• ) Keine öffentliche (also ohne Anmeldung zugängliche) Index Seite auf dem internen Webserver anlegen, wo mögliche öffentliche Inhalte „sichtbar“ verlinkt sind. Auch sollten die öffentlichen Inhalte (wenn überhaupt unbedingt benötigt – man kann diese ja auch nur Intern erreichbar machen) nicht über Standard-Ordner laufen, wie z.B. wp (WordPress), Joomla, phpmyadmin, Webmail usw…
  Die Gefahr dabei besteht, dass in den gehosteten Inhalten, eine Sicherheitslücke dafür sorgt, dass jemand sich Zugriffsrechte auf den Webserver erschleichen kann, was dann wieder durch Intensivierung des Angriffs über eine Rechteausweitung zu ROOT-Rechte führen kann!!

TODO: Konfiguration LetsEncrypt