Apache Seiten nur aus VPN erreichbar machen?

[pcace]

Hallo,

ich habe da mal eine Frage: ich möchte den order /var/www/xyz nur aus dem adresbereich 10.8.x.x erreichbar machen.
Dazu habe ich mir eine .htaccess in den order gelegt mit folgendem Inhalt:

Code: Alles auswählen

<Limit GET POST PUT>
 Order Deny,Allow
 Deny from all
 Allow from 10.8.0
 Allow from 127.0
</Limit>

Das funktioniert insofern, dass nun alle adressen ein Forbidden bekommen. Im Log steht

Code: Alles auswählen

[Tue Dec 18 20:37:32.561664 2018] [access_compat:error] [pid 3599] [client 95.90.xxx.xxx:31298] AH01797: client denied by server configuration: /var/www/html/xxx/

Das bedeutet, dass scheinbar ich immernoch über meine Öffentliche IP versuche den Server zu erreichen, was aber nicht so recht stimmen kann, da ich alles was ich sende und empfange durch das vpn tunnel?!?!

Bin ich da hier im Webserver unterforum richtig, oder muss ich mich eher an das VPN machen?

Ich steh auf dem schlauch, vllt kann mir ja jemand einen schubs in die richtige Richtung geben...

Gruß

Pcace

[DeletedUserReAsG]

Wenn der httpd diese IP ins Log schreibt, dann wurde er von dieser IP aus kontaktiert. Ergo: deine VPN-Config ist kaputt.

[HZB]

Wenn Du nicht via /etc/hosts an der Namensauflösung geschraubt hast und Deinen Webserver via URL aufrufst ist das eher normal. Da kann auch VPN nichts machen.

[pcace]

Hmmm, ja denn wenn ich im VPN bin, wird meine extrene IP korrekter weise angegeben als die des Servers.
Was kann ich denn dann machen?
Die situation ist die, dass ich einen kleinen server betreibe, der für mich VPN, Mail und Webserver ist. Auf dem Webserver laufen neben ein paar wenigen öffentlich erreichbaren diensten (roundcube und nextcloud zum beispiel) ein paar server info sachen wie munin oder rspamd die seiten möchte ich eigentlich nicht öffentlich erreichbar haben, sondern nur aus dem vpn.

Ideen wie ich das machen kann?

Grüße,

Pcace

[habakug]

Hallo,

"Allow from" ist jetzt "Require ip".
Das "Deny from all" erzeugt das AH01797.

Gruss, habakug

[HZB]

Hmmm, ja denn wenn ich im VPN bin, wird meine extrene IP korrekter weise angegeben als die des Servers.
Was kann ich denn dann machen?
Die situation ist die, dass ich einen kleinen server betreibe, der für mich VPN, Mail und Webserver ist. Auf dem Webserver laufen neben ein paar wenigen öffentlich erreichbaren diensten (roundcube und nextcloud zum beispiel) ein paar server info sachen wie munin oder rspamd die seiten möchte ich eigentlich nicht öffentlich erreichbar haben, sondern nur aus dem vpn.

Ideen wie ich das machen kann?

Grüße,

Pcace

Ich befürchte fast das das so nicht gehen kann. Das würde mmn nur bei einem VPN Tunnel mit 2 Subnetzen gehen.
Dann könnte man im lokalen LAN die interne IP des Webservers angeben. Aber so hat er ja nur die offizielle.

Aber vielleicht könntest Du Dir den access mit einem Client Certificate basteln und nur das erlauben. Ist aber nur eine Idee und ich hab das noch nicht gemacht.

https://httpd.apache.org/docs/2.4/mod/m ... rifyclient

[pcace]

Hey, danke für die Info! Leider hat auch das noch nicht ganz zum Erfolg geführt!
Htaccess sieht so aus:

Code: Alles auswählen

<RequireAll>
Require all denied
Require ip 10.8
Require ip 10.8.0.2
</RequireAll>

Error so:

[Thu Dec 20 21:50:43.604474 2018] [authz_core:error] [pid 5643] [client 95.90.xxx.xxx:31302] AH01630: client denied by server configuration: /var/www/html/stats/

Also doch irgendwas an der VPN config?

Gruß

[HZB]

Schau mal generell ins access log mit welcher IP Dich Dein Apache sieht.

[habakug]

Hallo,

das kommt jetzt vom Modul authz_core.

Code: Alles auswählen

# cat /var/www/html/stats/.htaccess
# find /var/www/html -name .htaccess

Die <RequireAll>-Direktive bedeutet:

If none of the directives contained within the <RequireAll> directive fails, and at least one succeeds, then the <RequireAll> directive succeeds.

Das ist in diesem Fall wohl nicht so optimal...

Gruss, habakug

[1] http://httpd.apache.org/docs/trunk/mod/ ... _core.html

[Mozie]

Hi liebe Community,

Das Problem ist vermutlich relativ einfach zu lösen.

Wenn ich das richtig verstehe, hast du einen gemieteten vServer mit einer öffentlichen IP.
Auf diesem Läuft ein VPN-, Email-, Webserver, ...

Meine Erfahrungen mit VPN sind folgende:
Ist eine VPN-Verbinmdung aufgebaut, wird eine weitere virtuelle Netzwerkschnittstelle bspw. ppp0 mit der IP (Bsp.) 10.0.X.X erzeugt. Somit ist eine Kommunikation mit dem localhost über diese IP grundsätzlich möglich. Über ip-tables werden nun Regeln erzeugt, welche die Verbindung zur externen Netzwerkschnittstelle (eth0) ermöglichen.(im Kernel muss natürlich Forwarding aktiviert sein) Somit kannst du über deinen VPN externe Seiten aufrufen.

Wenn deine VPN-Software ähnlich funktioniert, sollte es ausreichen, wenn du in der apache-site den virtuellen Host von *:80 oder *:443 auf deine IP des VPNs beschränkst. Bspw. 10.0.X.X:80 / 443

Apache hört nun nur noch auf diese IP. Das bedeutet aber auch, dass du über deinen VPN die interne IP des Servers (10.0.X.X) aufrufen musst und nicht deine Externe.

Dies könnte man noch lösen, indem man iptables dazu bringt Anfragen von der externen IP, die aus dem vpn kommen, umzubiegen auf den localhost.

Aber das ist ne andere Baustelle. Erstmal sollte es so funktionieren. Wenn nicht, solltest du vorerst deinen VPN richtig konfigurieren.

Ich hoffe ich konnte dir einige Denkanstöße geben.

Viele Grüße
Michael

[pcace]

Ahso,

in der Accesslog steht das hier... ...also auch die eigentlich öffentliche IP. Aber irgendwie verstehe ich das nicht so recht. Warum kommt da nicht die öffentliche VPN serverip???

Code: Alles auswählen

95.90.xxx.xxx - - [21/Dec/2018:11:15:50 +0100] "GET /stats/ HTTP/1.1" 403 518 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36"

Hat noch jemand ideen wie ich das entspannt lösen kann das Problem?

Gruß

[bluestar]

Läuft dein VPN-Server auf dem Webserver (also gleiche Maschine, gleiche IP) ?

[pcace]

Ja so ist es!

Gruß

[bluestar]

Dann wirst du für deinen Server einen zweiten DNS-Namen benötigen, der auf die interne IP des Servers zeigt.

Das Ganze funktionert dann wie folgt:

1) Rufst du deinen Server über den öffentlichen Namen (mit öffentlicher IP) auf, so kommst du nicht in die geschützten Verzeichnisse => unabhängig davon ob das VPN aktiv ist oder nicht.

2) Rufst du deinen Server über den zweiten Namen auf, der auf die interne IP des Servers zeigt, dann bekommst du ohne VPN eine Fehlermeldung und mit VPN kommst auf den Server und auch auf die geschützten Verzeichnisse.

[MSfree]

Dann wirst du für deinen Server einen zweiten DNS-Namen benötigen, der auf die interne IP des Servers zeigt.

Spontan hätte ich gesagt, daß kein weiterer DNS-Name nötig ist.

Die Quell-IP sollte der Server (Apache) eigentlich immer sehen. Allerdings ist die Quelle im Falle von VPN nicht die IP des Tunnels, also 10.x.y.z sondern die IP des LAN, von dem der Tunnel aufgebaut wurde, also üblicherweise 192.168.x.y.

Es sei denn, man verwendet NAT, um vom lokalen Netz in den Tunnel zu "NATen", dann sieht der Apache 10.x.y.z.

Ein weiteres Problem könnte noch sein, daß auf dem vServer ein weiteres NAT läuft, das die aus dem Tunnel kommenden Pakete auf die IP des Server "NATet".

[bluestar]

Das Problem liegt an anderer Stelle begründet... Ich vermute mal das der VPN-Tunnel von seinem Client (irgendwo in einem LAN 192.168.x.x) via NAT auf die IP-Adresse des Apache & VPN-Server geht.

Damit der Traffic zu dem Apache durch das VPN läuft, müsste er die öffentliche IP des Apache "explizit" durch den VPN Tunnel routen, damit schießt sich das Setup in den Kopf. Die VPN-Pakete zu der IP dürfen nämlich nicht durch den VPN-Tunnel geroutet werden.

Das Problem lässt sich auch "ohne" zweiten DNS-Eintrag lösen, allerdings benötigt der TE dann für den VPN-Dienst eine eigene IP-Adresse, in dem Falle ist es möglich die 2. IP-Adresse worauf der Apache lauscht, durch das VPN zu routen.

Da bleibt nur die Frage an den TE, hat er die Möglichkeit bei dem Hoster eine zweite IP-Adresse für den Server zu bekommen, falls nicht bleibt die Option mit dem zweiten DNS-Eintrag.

Man könnte natürlich auch die DNS-Anfragen durch das VPN umleiten und über Bind Views den VPN-Rechnern einfach für den DNS-Namen des Servers eine andere IP zurückliefern, aber da schießt man mit Kanonen auf Spatzen und erntet wieder neue Probleme...

[MSfree]

Damit der Traffic zu dem Apache durch das VPN läuft, müsste er die öffentliche IP des Apache "explizit" durch den VPN Tunnel routen, damit schießt sich das Setup in den Kopf. Die VPN-Pakete zu der IP dürfen nämlich nicht durch den VPN-Tunnel geroutet werden.

Es würde reichen, nur die HTTP(S)-Pakete durch den Tunnel zu leiten. Mit ein paar iptables-Regeln ist das eigentlich kein Problem:

Auf der Clientseite des VPN-Tunnels sollten folgende Regeln ausreichen:

Code: Alles auswählen

iptables -t nat -A -PREROUTING -p tcp -d öffentliche-IP --dport 80 -j DNAT --to-destination 10.x.y.z
iptables -t nat -A -PREROUTING -p tcp -d öffentliche-IP --dport 443 -j DNAT --to-destination 10.x.y.z

(ohne Gewähr)

Damit sollten eigentlich alle Anfragen auf Port 80 (HTTP) und Port 443 (HTTPS) an die öffentliche IP-Adresse des Servers an das Ende des Tunnels (hier läuft ja auch der Apache) geroutet werden.

Solche Regeln könnte man vermutlich sogar vom VPN-Server in Form eine Skriptes pushen. Windows-tauglich ist so eine Lösung allerdings nicht.

[bluestar]

Auf der Clientseite des VPN-Tunnels sollten folgende Regeln ausreichen:

Code: Alles auswählen

iptables -t nat -A -PREROUTING -p tcp -d öffentliche-IP --dport 80 -j DNAT --to-destination 10.x.y.z
iptables -t nat -A -PREROUTING -p tcp -d öffentliche-IP --dport 443 -j DNAT --to-destination 10.x.y.z

(ohne Gewähr)

Naja nicht so ganz, dann erreicht er ja gar keine anderen Server mehr über Port 80 bzw. 443.

Falls du masochistische Neigungen hast, so gibt es auch noch IPSEC im Transport-Mode, damit kannst du tatsächlich den Client-Traffic für die Server-Ports 80 & 443 verschlüsseln.

[MSfree]

Naja nicht so ganz, dann erreicht er ja gar keine anderen Server mehr über Port 80 bzw. 443.

Doch, zumindest theoretisch, denn

iptables -t nat -A -PREROUTING -p tcp -d öffentliche-IP --dport 80 -j DNAT --to-destination 10.x.y.z

schränkt das Forwarding ja auf die öffentliche IP des Apache und Port 80 ein, analog die zweite Regel mit Port 443. Ich bin mir nur nicht ganz sicher, ob diese Kombination aus -d öffentliche-IP --dport 80 von iptables akzeptiert wird.

[pcace]

Das wird mir hier alles viel zu kompliziert ich hab es jetzt per htpasswd gemacht. Die htaccess sieht jetzt so aus:

Code: Alles auswählen

<RequireAll>
  AuthType Basic
  AuthName "Authentication Required"
  AuthUserFile "/var/www/html/.htpasswd"
  Require valid-user
</RequireAll>

Spricht da etwas dagegen? (ausser vllt, das man das pw unverschlüsselt bei http überträgt... )


Gruß

Pcace

[bluestar]

Code: Alles auswählen

  AuthUserFile "/var/www/html/.htpasswd"

Leg die Datei nach /etc, sonst kann man deine htpasswd Datei herunterladen.

Spricht da etwas dagegen? (ausser vllt, das man das pw unverschlüsselt bei http überträgt... )

Nimm certbot und nutze kostenlose SSL-Zertifikate von LetsEncrypt.

Unverschlüsselt ist Mist

[pcace]

Gut. ich glaube so sollte das klappen.

johannes-froelich.de --> redirect nach https?
cloud.johannes-froelich.de/mail.johannes-froelich.de--> redirect nach https?
johannes-froelich.de/munin --> auch https, aber nur mit pw?

Gruß und Dank für die Hilfe!

[HZB]

Also es schaut schon ganz gut aus.

Ich würde es noch etwas mehr absichern. zB Server Token usw.
Ein Fail2ban auf das Apache Error log kann ich nur dringend empfhlen.
Macht brute force auf die geschützten seiten schwieriger.