OT: Server vom Internet schützen
Hallo zusammen, dies ist eine Fortsetzung des Threads "OT: Server up-to-date halten", aber mit anderer Fragestellung. Der Server hängt hinter einer Fritzbox und in der werden nur https und ssh an den Server weitergeleitet. Aber nicht mit den Standardports sondern mit Ports jenseits von 30000. Das ist zwar kein perfekter Schutz aber ich denke es könnte etwas vor Portscans schützen. Auf dem Server wird Nextcloud und ein Apache betrieben, die aber ausschliesslich über https erreichbar sind. In der Vergangenheit, als ich noch bei Nokia gearbeitet habe, durfte ich mich zwar mit Apache beschäftigen, aber das Thema Sicherheit vom Internet war nie ein Thema, denn alles war nur im Intranet. Der Firewall auf dem Server ist aktuell ausgeschaltet und als ich ihn angeschaltet habe bin ich nicht mehr auf Nextcloud gekommen. Als ich mich das Letzte Mal mit FW über Yast2 beschäftigt habe, sah die GUI etwas anders aus als jetzt bei 15.2 (War schon etwas länger her) Gibt es einen Doku, in der nicht zu kompliziert beschrieben ist, wie ich in YAST2 der FW für ein bestimmtes Protokoll konfigurieren muss, bzw. wie man den konfigurieren kann/soll... Ich habe es bei Zohne "public" probiert, weil das die Zohne ist, in der eth0 auftaucht und als Standard gekennzeichnet ist. Ich habe den FW gestartet, bei Public zusätzlich "https" erlaubt und auf übernehmen geklickt. Danach bin ich nicht mehr auf Nextcloud (im intranet) gekommen. Das war gestern. Heute habe ich den FW nur gestartet und jetzt funktioniert die Verbindung zu Nextcloud. komisch. Ist das jetzt sicher genug ? Kann ich das sinnvoll testen ? Apache: Vom Internet soll eigentlich nur Web-Seiten über https erreichbar sein. Der Apache ist jedoch auch für cgi-bin/Perl konfiguriert. Das brauche ich aber nur im Intranet. Kann man irgendwie verhindern, dass er auf diesbezügliche Anfragen aus dem Internet antwortet bzw. irgendwie reagiert ? Das cgi-bin Zeugs nur für http konfigurieren aber nicht für https? Danke für Tipps. viele Grüße Werner
On 10.08.21 14:07, Werner Franke wrote:
Vom Internet soll eigentlich nur Web-Seiten über https erreichbar sein.
Der Apache ist jedoch auch für cgi-bin/Perl konfiguriert. Das brauche ich aber nur im Intranet. Kann man irgendwie verhindern, dass er auf diesbezügliche Anfragen aus dem Internet antwortet bzw. irgendwie reagiert ?
https://httpd.apache.org/docs/2.4/howto/access.html Viele Grüße Ulf
Hi Ulf, Am 10.08.21 um 14:44 schrieb Ulf Volmer:
On 10.08.21 14:07, Werner Franke wrote:
Vom Internet soll eigentlich nur Web-Seiten über https erreichbar sein.
Der Apache ist jedoch auch für cgi-bin/Perl konfiguriert. Das brauche ich aber nur im Intranet. Kann man irgendwie verhindern, dass er auf diesbezügliche Anfragen aus dem Internet antwortet bzw. irgendwie reagiert ?
ich denke an der Schraube habe ich schon mal gedreht. Ganz gleich welche IP ich benutzt habe, keine wurde abgewiesen. Ich muss mir das aber nochmal ansehen. Wahrscheinlich habe ich was falsch gemacht. Danke und Gruss Werner
Hi Ulf, Am 10.08.21 um 14:44 schrieb Ulf Volmer:
On 10.08.21 14:07, Werner Franke wrote:
Vom Internet soll eigentlich nur Web-Seiten über https erreichbar sein.
Der Apache ist jedoch auch für cgi-bin/Perl konfiguriert. Das brauche ich aber nur im Intranet. Kann man irgendwie verhindern, dass er auf diesbezügliche Anfragen aus dem Internet antwortet bzw. irgendwie reagiert ?
<Directory "/srv/www/cgi-bin"> AllowOverride all Options +ExecCGI -Includes +FollowSymLinks AddHandler cgi-script .cgi .pl <RequireAll> #--------------------------------------- Nicht ueber's Internet # Require all granted Require not ip 192.168.178.1 </RequireAll> </Directory> Das geht zwar jetzt, aber ich bekomme ein "Access forbidden!" Also sieht man vom Internet aus, das da was ist, man nur nicht darf. Grund weiter zu bohren... Besser wäre es aber, wenn nur bei richtigen URLs und nur wenn der Zugriff erlaubt ist, eine Reaktion kommt. Sonst Seite wurde nicht gefunden Geht das ? Gruss Werner
On 13.08.21 19:57, Werner Franke wrote:
Am 10.08.21 um 14:44 schrieb Ulf Volmer: <Directory "/srv/www/cgi-bin"> AllowOverride all Options +ExecCGI -Includes +FollowSymLinks AddHandler cgi-script .cgi .pl <RequireAll> #--------------------------------------- Nicht ueber's Internet # Require all granted Require not ip 192.168.178.1 </RequireAll> </Directory>
Das geht zwar jetzt, aber ich bekomme ein "Access forbidden!"
Das ist das zu erwartende Verhalten, ja.
Also sieht man vom Internet aus, das da was ist, man nur nicht darf. Grund weiter zu bohren...
Besser wäre es aber, wenn nur bei richtigen URLs und nur wenn der Zugriff erlaubt ist, eine Reaktion kommt. Sonst
Seite wurde nicht gefunden
Geht das ?
Ich wüsste jetzt nicht, wie. Also ohne eine WAF oder so. Viele Grüße Ulf
On Tue, 10 Aug 2021 14:07:49 +0200 Werner Franke <werner_franke@arcor.de> wrote:
Apache: Vom Internet soll eigentlich nur Web-Seiten über https erreichbar sein.
Der Apache ist jedoch auch für cgi-bin/Perl konfiguriert. Das brauche ich aber nur im Intranet. Kann man irgendwie verhindern, dass er auf diesbezügliche Anfragen aus dem Internet antwortet bzw. irgendwie reagiert ?
Das cgi-bin Zeugs nur für http konfigurieren aber nicht für https?
Ich gehe mal davon aus, dass Nextcloud kein Perl braucht. Wenn sowas wie Container keine Option (oder Overkill) ist, würde ich mit IP-based virtual hosting arbeiten. Auf dem Linux-Server richtest Du ein IP-Alias und in der Apache-Konfiguration virtual-host-Konfigurationen für jede IP-Adresse ein. "Default" wird deaktiviert. Die eine IP-Adresse und somit die damit verbundene virtual-Host-Konfig ist per Port-Forward über die Fritzbox von außen erreichbar und dort richtest Du die Nextcloud-Konfiguration ein. Die andere ist nicht von außen erreichbar und dort richtest Du Deine perl-Applikation ein. Am besten gibst Du beiden noch einen eigenen Namen im internen DNS-Server, so vorhanden. Wenn Du Letencrypt verwendest, dann bietet er Dir bei der initialen Einrichtung beide vhost-Konfigs an und da musst Du halt nur die für externen Zugriff auswählen. Hinsichtlich ssh solltest Du nur public key authentication erlauben. Bei "root" vielleicht gar kein ssh-Login erlauben und stattdessen über persönliche Accounts als Zwischenstation arbeiten. Wenn Du intern unbedingt weiterhin mit Passwort arbeiten willst oder sonstwie ssh-Restriktionen auf externe Zugriffe beschränken willst, wird's etwas aufwendiger, geht aber im Prinzip auch. Einen schönen Überblick über die unerlaubten Zugriffe liefert Dir Logwatch. Da siehst Du auch, welche User "bekannt" sind und man sieht auch erfolgreiche ssh-Logins, die vielleicht gar nicht erwünscht waren. Das failed-Login-Rauschen reduziert man z.B. über denyhosts - z.B. drei vergebliche Login-Versuche und die IP wird für mehrere Tage auf tcp-Level gesperrt. Andere nehmen fail2ban, welches auch für http/https geeignet ist. Gruß, Tobias.
Hi Tobias, Am 10.08.21 um 19:53 schrieb Tobias Crefeld:
On Tue, 10 Aug 2021 14:07:49 +0200 Werner Franke <werner_franke@arcor.de> wrote:
Apache: Vom Internet soll eigentlich nur Web-Seiten über https erreichbar sein.
Der Apache ist jedoch auch für cgi-bin/Perl konfiguriert. Das brauche ich aber nur im Intranet. Kann man irgendwie verhindern, dass er auf diesbezügliche Anfragen aus dem Internet antwortet bzw. irgendwie reagiert ?
Das cgi-bin Zeugs nur für http konfigurieren aber nicht für https?
Ich gehe mal davon aus, dass Nextcloud kein Perl braucht. Nein, Nextcloud braucht das nicht, aber ich habe eine kleine Anwendung gemacht und mit Perl kenne ich mich am Besten aus.
Wenn sowas wie Container keine Option (oder Overkill) ist, würde ich mit IP-based virtual hosting arbeiten. Auf dem Linux-Server richtest Du ein IP-Alias und in der Apache-Konfiguration virtual-host-Konfigurationen für jede IP-Adresse ein. "Default" wird deaktiviert. Die eine IP-Adresse und somit die damit verbundene virtual-Host-Konfig ist per Port-Forward über die Fritzbox von außen erreichbar und dort richtest Du die Nextcloud-Konfiguration ein. Die andere ist nicht von außen erreichbar und dort richtest Du Deine perl-Applikation ein. Am besten gibst Du beiden noch einen eigenen Namen im internen DNS-Server, so vorhanden. Wenn Du Letencrypt verwendest, dann bietet er Dir bei der initialen Einrichtung beide vhost-Konfigs an und da musst Du halt nur die für externen Zugriff auswählen.
Soweit ich das oben verstehe soll der Server also 2 verschiedene IPs haben, oder ist das nur in der Apache Konfig? Einen DNS Server habe ich aber nicht. Nur die Fritzbox bzw die hosts-files. Ich habe im Büro zwar einen Apache (2.2) betreut und der hatte auch mehrere vhosts, aber was man da so angeben kann weiss ich nicht. Ich war froh dass es dann so wie ich es konfiguriert hatte, funktioniert hat. Gibt es irgendwo ein Beispiel für sowas ?
Hinsichtlich ssh solltest Du nur public key authentication erlauben. Bei "root" vielleicht gar kein ssh-Login erlauben und stattdessen über persönliche Accounts als Zwischenstation arbeiten.
SSH ist nur mit key erlaubt und für root gar nicht.
Wenn Du intern unbedingt weiterhin mit Passwort arbeiten willst oder sonstwie ssh-Restriktionen auf externe Zugriffe beschränken willst, wird's etwas aufwendiger, geht aber im Prinzip auch.
Einen schönen Überblick über die unerlaubten Zugriffe liefert Dir Logwatch. Da siehst Du auch, welche User "bekannt" sind und man sieht auch erfolgreiche ssh-Logins, die vielleicht gar nicht erwünscht waren. Das failed-Login-Rauschen reduziert man z.B. über denyhosts - z.B. drei vergebliche Login-Versuche und die IP wird für mehrere Tage auf tcp-Level gesperrt. Andere nehmen fail2ban, welches auch für http/https geeignet ist.
vielen Dank,
On Thu, 12 Aug 2021 18:59:48 +0200 Werner Franke <werner_franke@arcor.de> wrote:
Soweit ich das oben verstehe soll der Server also 2 verschiedene IPs haben, oder ist das nur in der Apache Konfig?
Sowohl als auch. Die zweite IP-Adresse brauchst Du, damit der Server selber auf diese Adresse reagiert und Apache kann per virtual host configuration auf die jeweilige IP-Adresse "hören".
Ich habe im Büro zwar einen Apache (2.2) betreut und der hatte auch mehrere vhosts, aber was man da so angeben kann weiss ich nicht. Ich war froh dass es dann so wie ich es konfiguriert hatte, funktioniert hat.
Gibt es irgendwo ein Beispiel für sowas ?
"apache virtual host" in die Suchmaschine Deines geringsten Misstrauens eingeben! Ein bisserl unübersichtlich ist es, welche Parameter global angegeben werden, welche nur global konfiguriert werden können und welche per virtual host konfiguriert werden können. Da muss man die Apache-Doku schon sehr genau lesen. Wenn Du pro vhost eigene Logfiles für Access und Errors definierst, bekommst Du schnell mit, welche Requests von welcher Teilkonfiguration verarbeitet werden. Gruß, Tobias.
Hallo! Am Dienstag, 10. August 2021, 14:07:49 CEST schrieb Werner Franke:
Apache: Vom Internet soll eigentlich nur Web-Seiten über https erreichbar sein.
Das richtet doch das Nextcloud Setup eh automatisch so ein, oder?
Der Apache ist jedoch auch für cgi-bin/Perl konfiguriert. Das brauche ich aber nur im Intranet. Kann man irgendwie verhindern, dass er auf diesbezügliche Anfragen aus dem Internet antwortet bzw. irgendwie reagiert ?
Die Require Direktive kann bspw. verwendet werden, um Anfragen nur von intern zuzulassen. Die kannst du auf beliebige virtuelle oder physische Verzeichnisse setzen. Ein Require braucht es immer, ohne gibt es keinen Zugriff. Typischerweise ist Require all granted gesetzt. Also alles erlaubt. Du kannst aber dennoch ein Unterverzeichnis auf interne Zugriffe beschränken mit bspw. Require ip 10.0.1.0/24 für ein Subnetz. Weitere Details dazu in den Apache Docs: https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#require
Das cgi-bin Zeugs nur für http konfigurieren aber nicht für https?
Wenn ohnehin nur von intern Zugriff möglich ist, bleibt es dir überlassen http zu verwenden. Grüße Richard
Hallo zusammen, Am 10.08.21 um 14:07 schrieb Werner Franke:
Hallo zusammen,
dies ist eine Fortsetzung des Threads "OT: Server up-to-date halten", aber mit anderer Fragestellung.
Der Server hängt hinter einer Fritzbox und in der werden nur https und ssh an den Server weitergeleitet. Aber nicht mit den Standardports sondern mit Ports jenseits von 30000. Das ist zwar kein perfekter Schutz aber ich denke es könnte etwas vor Portscans schützen.
Auf dem Server wird Nextcloud und ein Apache betrieben, die aber ausschliesslich über https erreichbar sind. In der Vergangenheit, als ich noch bei Nokia gearbeitet habe, durfte ich mich zwar mit Apache beschäftigen, aber das Thema Sicherheit vom Internet war nie ein Thema, denn alles war nur im Intranet.
Nachdem in der c't 23 vom 23.10.2021 ein interessanter Artikel über "Hacking-Tools: Gefährlich und nützlich" enthalten ist und da speziell der Teil "Gute Tools, böse Tools" für mich passte, habe ich auf meinem Dektop PC eine Kali-Linux VirtualBox VM angelegt und meinen Heimzugang mit dem Tool DIRB getestet. (Ich verwende in den Beispielen unten eine geänderte URL) dirb https://werner.spdns.org:40443 Es wurden zuerst sehr viele Einträge gemeldet. Auch welche, von denen ich bisher nichts gewusst habe. Daraufhin habe ich den Apache2.4 soweit angepasst, dass die Meissten verschwunden sind. Aber die 3 unten bekomme ich nicht weg. dirb https://werner.spdns.org:40443 ----------------- DIRB v2.22 By The Dark Raver ----------------- START_TIME: Thu Nov 11 11:51:25 2021 URL_BASE: https://werner.spdns.org:40443/ WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt ----------------- GENERATED WORDS: 4612 ---- Scanning URL: https://wfr1dns.spdns.org:30443/ ---- + https://werner.spdns.org:40443/cgi-bin (CODE:403|SIZE:7573) + https://werner.spdns.org:40443/git (CODE:403|SIZE:7573) + https://werner.spdns.org:40443/phpMyAdmin (CODE:403|SIZE:7573) Meine DocumentRoot ist "/srv/www/htdocs" root@hpserver (-bash) ll /srv/www/htdocs drwxr-xr-x 2 root root 4,0K 1. Nov 18:28 cgi-bin -rw-rw-r-- 1 root root 45 17. Dez 2020 .htusers drwxr-xr-x 14 root root 4,0K 1. Okt 04:05 nextcloud drwxr-xr-x 9 root root 4,0K 1. Nov 18:25 phpMyAdmin root@hpserver (-bash) ll /srv/www drwxr-xr-x 2 root root 4,0K 1. Nov 18:28 cgi-bin -rw-rw-r-- 1 root root 17 1. Nov 17:11 .htaccess drwxr-xr-x 5 root root 4,0K 11. Nov 18:22 htdocs root@hpserver (-bash) more .htaccess Options -Indexes "git" kommt wahrscheinlich über /etc/apache2/conf.d/gitweb.conf, wobei ich mich nicht erinnern kann, das ich das installiert habe. Habe es erstmal gelassen. In meiner Apache Config für den <VirtualHost *:443> des Servers habe ich definiert: <Directory "/srv/www/htdocs"> Options FollowSymLinks Options -Indexes : : </Directory> Ein <Directory /srv/www> Options -Indexes AllowOverride All </Directory> bringt auch nichts. Ich nehme mal an, dass der Apache die Einträge liefert. Kann ich verhindern dass von der URL überhaupt etwas gelistet wird. Wenn ja, was könnte helfen ? Den phpMyAdmin habe ich so eingestellt, dass er sich jetzt nur bei internen IPs meldet. Der war vorher auch vom Internet erreichbar. Hat jemand noch einen Tipp für mich. Danke und Grüße Werner
On 11.11.21 18:37, Werner Franke wrote:
---- Scanning URL: https://wfr1dns.spdns.org:30443/ ----
https://werner.spdns.org:40443/cgi-bin (CODE:403|SIZE:7573)
https://werner.spdns.org:40443/git (CODE:403|SIZE:7573)
https://werner.spdns.org:40443/phpMyAdmin (CODE:403|SIZE:7573)
Meine DocumentRoot ist "/srv/www/htdocs"
root@hpserver (-bash) ll /srv/www/htdocs drwxr-xr-x 2 root root 4,0K 1. Nov 18:28 cgi-bin -rw-rw-r-- 1 root root 45 17. Dez 2020 .htusers drwxr-xr-x 14 root root 4,0K 1. Okt 04:05 nextcloud drwxr-xr-x 9 root root 4,0K 1. Nov 18:25 phpMyAdmin
root@hpserver (-bash) ll /srv/www drwxr-xr-x 2 root root 4,0K 1. Nov 18:28 cgi-bin -rw-rw-r-- 1 root root 17 1. Nov 17:11 .htaccess drwxr-xr-x 5 root root 4,0K 11. Nov 18:22 htdocs
root@hpserver (-bash) more .htaccess Options -Indexes
dirb geht eine Liste von Verzeichnisnamen durch, die er dann schlicht durchprobiert. Das Abschalten der Indexierung hilft Dir hier also nicht. Aber Du bekommst ja ein 403 (Forbidden), also alles gut.
Wenn ja, was könnte helfen ?
Hänge eine zweite Apache Instanz (oder einen nginx) als Reserve Proxy vor Deinen Apache und sorge dafür, dass nur dieser aus dem Internet erreichbar ist. Viele Grüße Ulf
participants (4)
-
Richard Hafenscher -
Tobias Crefeld -
Ulf Volmer -
Werner Franke