Owncloud absichern / live schalten

[Autokiller677]

Hallo Zusammen,

ich hoffe, die Frage passt hierhin.

Ich will meine Owncloud mal aus dem LAN ins WWW entlassen, allerdings soll der Server natürlich nicht gleich zur Spammaschine werden.

Auf dem Server läuft Debian 8 Stable auf aktuellem Patchstand. Owncloud läuft auf Apache2 und mysql.

Bisher habe ich die "Standard" Vorkehrungen getroffen, um den Apache abzusichern:
-Keine Versionsinfos auf Fehlerseiten
-Keine Directory Indexes
-Deny all und eine explizite Ausnahme für /owncloud
-SSL only (nur PFS mit Eliptic Curves), auf Port 80 lauscht er erst gar nicht

Apache läuft unter www-data, die Owncloud Daten liegen nicht unter /var/www, sondern auf /mnt/data/... auf einer anderen Platte. Die Daten sind allerdings ugo=rwx, da sie auch per Samba ohne Auth im Netzwerk bereitgestellt werden (read only)

Frage: Was sollte man noch unternehmen, um den Server abzusichern? Freigegeben wird wohl nur Port 443, daher sollte SSH etc. keine Angriffsfläche bieten (aber auch hier, no-root, no-empty-passwords).

Bringt es etwas, die Owncloud auf eine anderes Verzeichnis zu legen, also statt me.com/owncloud sowas wie me.com/dsfr643fdko? Ich weiß, dass security by obscurity nicht so toll ist, aber mir ist kein Weg bekannt, alle existierenden Directories zu listen, wenn Indexes abgeschaltet sind. Meinem Verständnis nach sollte das die Angriffsfläche auf den Apache minimieren, denn wer die Owncloud-Seite nicht sieht, weiß auch nicht, dass es sie nicht gibt und kann auch nichts Brute-Forcen.

Ist Geoblocking sinnvoll? Zugriffe sind nur aus D (genau genommen nur aus dem Bundesland) zu erwarten.

Habe ich noch etwas vergessen oder kann man mit diesen Maßnahmen einen Apache ohne große Sorgen ins Netz stellen?

 

[Autokiller677]

Hast du dafür auch einen Begründung oder ist das nur persönliche Präferenz?

 

[sinio]

Frage: Was sollte man noch unternehmen, um den Server abzusichern? Freigegeben wird wohl nur Port 443, daher sollte SSH etc. keine Angriffsfläche bieten (aber auch hier, no-root, no-empty-passwords).

Bringt es etwas, die Owncloud auf eine anderes Verzeichnis zu legen, also statt me.com/owncloud sowas wie me.com/dsfr643fdko? Ich weiß, dass security by obscurity nicht so toll ist, aber mir ist kein Weg bekannt, alle existierenden Directories zu listen, wenn Indexes abgeschaltet sind. Meinem Verständnis nach sollte das die Angriffsfläche auf den Apache minimieren, denn wer die Owncloud-Seite nicht sieht, weiß auch nicht, dass es sie nicht gibt und kann auch nichts Brute-Forcen.

Du könntest noch fail2ban einsetzen (unabhängig davon, ob apache2 oder nginx), um so Brute-Force-Angriffe ins Leere laufen zu lassen. Anleitungen dazu hier und hier.

Eine zusätzliche Geo-IP-Sperre halte ich nicht für sinnvoll. Was ist, wenn du doch einmal vielleicht aus dem Urlaub oder bei Bekannten in einem anderen Bundesland drauf zugreifen willst? Ich denke, da nimmst du dir einiges an Komfort.

 

[besterino]

Mir hilft eine recht großflächige Adressraumsperre mit Fail2ban. Nach einiger Zeit lassen die Meldungen eben deutlich nach.

 

[zos]

Wenn nur Du selbst und nicht eine Gruppe von Nutzern die ownCloud-Installation nutzt, wäre ein Zugang lediglich per VPN in Dein Heimnetz ebenfalls eine Möglichkeit (so wie z. B. in meinem Fall).

Einnmal eingerichtet, ist der VPN-Tunnel nur "einen Klick" / "einen Touch" entfernt. Dann bist Du im internen Netz und hast vollen Zugriff, ohne das überhaupt ein Webserver von außen erreichbar ist. Wenn Du natürlich viele Nutzer hast, ist den weniger Technik affinen das schon der eine Klick zuviel.

 

[Autokiller677]

Persönliche Präferenz sicher ja, doch fand bei mir und anderen Computerfreunden mit Nginx in den letzen Jahren noch keine feindliche Übernahme statt, was damals mit dem Apache trotz aller Sorgfalt vorgekommen ist. Daneben steckt eine Nginx Webserver auf vergleichsweise kleiner Hardware schon gut DDOS-Szenarien weg.

Obgleich Nginx wesentlich jünger ist als der Apache, ist es beileibe kein kleines Nischenprodukt. Ansehen lohnt sich. Durch die Bank ist zudem vieles an Konfiguration einfacher und schneller. Abschließend ein kleiner Auszug aus einem digitalocean.com Artikel:

"... Nginx does not interpret .htaccess files, nor does it provide any mechanism for evaluating per-directory configuration outside of the main configuration file. This may be less flexible than the Apache model, but it does have its own advantages.
The most notable improvement over the .htaccess system of directory-level configuration is increased performance. For a typical Apache setup that may allow .htaccess in any directory, the server will check for these files in each of the parent directories leading up to the requested file, for each request. If one or more .htaccess files are found during this search, they must be read and interpreted. By not allowing directory overrides, Nginx can serve requests faster by doing a single directory lookup and file read for each request (assuming that the file is found in the conventional directory structure). ..."

Ok, .htaccess benutze ich eh nicht und wie gesagt läuft nur Owncloud drauf. Performancemäßig dürfte der Unterschied nicht spürbar sein. Konfiguration ist beim Apache halt schon erledigt.

Ansonsten nehme ich mal mit, dass bei dir nginx etwas sicherer lief als Apache, wobei mir Google das jetzt nicht als allgemeines Problem bestätigt.

Du könntest noch fail2ban einsetzen (unabhängig davon, ob apache2 oder nginx), um so Brute-Force-Angriffe ins Leere laufen zu lassen. Anleitungen dazu hier und hier.

Eine zusätzliche Geo-IP-Sperre halte ich nicht für sinnvoll. Was ist, wenn du doch einmal vielleicht aus dem Urlaub oder bei Bekannten in einem anderen Bundesland drauf zugreifen willst? Ich denke, da nimmst du dir einiges an Komfort.

Ich hab das Bundesland die letzten 4 und das Land die letzten 7 Jahre nicht verlassen, das Szenario wäre daher recht unwahrscheinlich. Ich will jetzt auch nicht unbedingt auf den PLZ Bereich einschränken, aber vielleicht eben auf Westeuropa oder so. Wenn ich im Urlaub bin ist der Server eh aus, daher spielt es da ebenfalls keine Rolle.

Fail2Ban werde ich mir auf jeden Fall mal anschauen, das sieht praktisch aus.

Wenn nur Du selbst und nicht eine Gruppe von Nutzern die ownCloud-Installation nutzt, wäre ein Zugang lediglich per VPN in Dein Heimnetz ebenfalls eine Möglichkeit (so wie z. B. in meinem Fall).

Einnmal eingerichtet, ist der VPN-Tunnel nur "einen Klick" / "einen Touch" entfernt. Dann bist Du im internen Netz und hast vollen Zugriff, ohne das überhaupt ein Webserver von außen erreichbar ist. Wenn Du natürlich viele Nutzer hast, ist den weniger Technik affinen das schon der eine Klick zuviel.

Nope, meine Eltern nutzen die Owncloud noch, für sie ist es PC-Backup und Card / CalDav Server, daher ist dauernd VPN zuschalten nicht möglich. Ich habe auch schon überlegt, das über den VPN der Fritzbox zu regeln, aber dann spackt es rum, wenn man im Zielnetz selbst im WLAN ist usw. Wäre vielleicht irgendwie machbar, aber es soll halt auch halbwegs einfach bleiben.

 

[MusicJunkie666]

Fail2Ban (ordentlich konfigurieren!) + alles Up-To-Date halten sollte mMn für den Großteil aller Angriffe ausreichen.

Geo-Blocking finde ich persönlich nicht allzu sinnvoll; Länder wie China, Russland, Korea auszusperren kann aber praktisch sein, da nach meiner Erfahrung die meisten automatisierten Angriffe ("Bots") daher kommen.

 

[NTB]

Womit macht man GeoBlocking? Gibt es da auch sowas schönes wie fail2ban?

 

[NTB]

Ach vom Webserver? Ich dachte, das wird seitens der Firewall gemacht. Hmm, aber bringt das dann überhaupt so viel?

 

[Autokiller677]

Ok, um nochmal kurz zu beantworten was ich gemacht habe, falls es für jemand anderen nochmal interessant ist:

- Fail2Ban installiert
- Owncloud so konfiguriert, dass logs nach /var/log/syslog geschrieben werden, hierfür in /var/www/owncloud/config/config.php

'logtimezone' => 'Europe/Berlin',
'log_type' => 'syslog' ,
'log_authfailip' => true,

eingefügt

- /etc/fail2ban/filter.d/owncloud.conf mit

[Definition]
failregex = .*ownCloud.*Login failed: '.*' \(Remote IP: '<HOST>\)
ignoreregex =

erstellt

- fail2ban konfiguriert (/etc/fail2ban/jail.local erstellt, nicht in jail.conf geschrieben => so gibts keine Probleme bei updates)

[DEFAULT]
bantime = 3600
findtime = 3600
destemail = <username>@localhost
action = %(action_mwl)s

[ssh-ddos]

enabled = true

#[apache]

#enabled = true

[apache-noscript]

enabled = true

[apache-overflows]

enabled = true

[apache-modsecurity]

enabled = true

[apache-nohome]

enabled = true

[owncloud]

enabled = true
port = 80,443
protocol = tcp
filter = owncloud
maxretry = 3
logpath = /var/log/syslog

-iptables konfiguriert: Aus dem LAN alles erlauben (Input & Output), Input auf Port 443 von überall erlauben, und als letzte Regel: Jeden Input verbieten. Damit wird alles aufgefangen, dass nicht durch die vorherigen Regeln explizit erlaubt war.

-mod_geoip für Apache installiert und entsprechend konfiguriert (/etc/apache2/mods-available/geoip.conf)

<IfModule mod_geoip.c>
  GeoIPEnable On
  GeoIPDBFile /usr/share/GeoIP/GeoIP.dat

# whitelisting with AllowCountry and deny from all, allow from ... (see below)
SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountry

# blacklisting with BlockCountry and deny from ... (see below)
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
# ... place more countries here

</IfModule>

<Location /owncloud>
# whitelisting
Deny from all
Allow from env=AllowCountry

#blacklisting
#Deny from env=BlockCountry
</Location>

Ich hoffe, damit habe ich alles wichtige abgesichert. Die FritzBox macht Portforwarding nur auf 443, so dass SSH etc. eh keine Angriffsfläche sein sollten. Zusätzlich erlaubt auch iptables keinen externen Zugriff auf Port 22.

Sollte noch jemandem ein grober Schnitzer auffallen, bin ich natürlich über jede Rückmeldung dankbar.

 

[Handle]

Performancemäßig dürfte der Unterschied nicht spürbar sein.

Und wie das spürbar ist, gerade auf schwacher Hardware läuft Nginx deutlich performanter. Die Konfiguration von Nginx ist auch nicht wirklich aufwendig, wenn man sich damit einmal beschäftigt hat.
Hier sind Tipps um die Owncloud-Performance zu verbessern, die beziehen sich allerdings auf Nginx. Kann man evtl. für Apache adaptieren, wenn du denn wirklich dabei bleiben möchtest.

Edit: Danke für die fail2ban-Config.