Mot-clé - nextcloud

Fil des billets

mardi 14 février 2017

Activate logging and find logs for {Rainloop in Nextcloud}

You can activate Rainloop logging by toggling the enable parameter to On (from Off) in the logs section in the file /path/to/nextcloud/data/rainloop-storage/_data_/_default_/configs/application.ini

[logs]
enable = On

Then logs are then available in /path/to/nextcloud/data/rainloop-storage/_data_/_default_/logs/.

dimanche 12 février 2017

Installer Rainloop sur Nextcloud

Rainloop s'installe extrêmement facilement sur Nextcloud 11 pour transformer votre gestionnaire cloud favori en webmail fort pratique.

Activer l'application

La première étape consiste à activer l'application dans le magasin à application de Nextcloud. D'abord, cliquer sur le menu en haut à gauche puis sur le bouton "+ Apps" pour ouvrir le magasin à application. Screenshot_2017-02-12_16-24-48.png

Dans la catégorie "Social & communication", on trouve l'application Rainloop qu'il suffit alors d'activer : Screenshot_2017-02-12_16-23-33.png

Accéder à l'administration de Rainloop

Après activation, réfrénez cette envie irrépressible de cliquer sur l'icône "Email" apparue aux côtés de vos applications (ça ne servira à rien sans quelques paramétrages préalables) et rendez-vous dans la page d'administration de Nextcloud, section "Additionnal settings". Là, dans le paragraphe "RainLoop Webmail" fraîchement apparu, cliquez sur "Go to RainLoop Webmail admin panel". Alternativement, vous pouvez appeler cette URL http://cloud.url/index.php/apps/rainloop/app/?admin (en remplaçant http://cloud.url par une URL valide et conforme à votre cas).

Au premier usage, le nom d'utilisateur de l'administration est "admin" et le mot de passe "12345". Nul besoin de vous inviter à modifier cela !

Paramétrer Rainloop

Les paramétrages et optimisations de Rainloop abondent. Pour aller à l'essentiel, rendez-vous dans la section "Domains".

Le principe est simple : vous allez paramétrer (et de fait autoriser) les utilisateurs de Rainloop (dans Nextcloud) à se connecter à un IMAP/SMTP selon le domaine de leur adresse courriel. Par exemple, vos utilisateurs ont des adresses alice@mondomaine.fr et bob@mondomaine.fr. Nous allons donc ajouter le domaine "mondomaine.fr" et paramétrer l'IMAP et le SMTP pour ce domaine :

Screenshot_2017-02-12_16-37-32.png

Désormais, sur leur compte Nextcloud, quand Alice et Bob ouvriront Rainloop, ils pourront saisir leur adresse (respectivement alice@mondomaine.fr et bob@mondomaine.fr) et Rainloop saura quels paramétrages IMAP/SMTP utiliser pour rapatrier le contenu de leur boîte courriel.

lundi 17 octobre 2016

Nextcloud, bruteforce attacks and reverse proxy

Nextcloud 10 introduced several security improvements : noteworthily a protection against bruteforce attacks. Simple process: if Nextcloud detects several login attemps from a same IP address then all future auth requests from that subnet will be slower (up to 30 seconds of lag time).

In the logs, we will see:

{"reqId":"b4hUi89HUuji","remoteAddr":"10.20.30.40","app":"core","message":"Bruteforce attempt from "10.20.30.40" detected for action "login".","level":1,"time":"2016-10-17T04:08:55+00:00","method":"PROPFIND","url":"\/remote.php\/carddav\/","user":"--"}

and then we know that the IP address 10.20.30.40 is presumably trying to bruteforce our Nextcloud! Interestingly, we may also ban this IP with Fail2ban.

Behind a reverse proxy?

If the connections to Nextcloud are managed by a reverse proxy (e.g. Pound or Nginx), then Nextcloud should be properly configured to use as remote address the true remote address and not the address from the reverse proxy! If not the case, all connections will be slowed by the brute force mitigation system!

We explain how to properly configure Nextcloud in the next section.

Nextcloud and X-Forwarded-For

Let's say the reverse proxy is 192.168.1.1 and it is set-up to forward the original address in the X-Forwarded-For header.

We need to open Nextcloud config file (e.g. /var/www/nextcloud/config/config.php) and add two lines:

  'trusted_proxies' => array('192.168.1.1'),
  'forwarded_for_headers' => array('HTTP_X_FORWARDED_FOR'),

The first line identifies the trusted proxy (only when the requests come from a trusted proxy will their headers be studied, this prevents headers forgery to escape brute force protection). The second line indicates which header should be taken as the remote address: X-Forwarded-For is HTTP_X_FORWARDED_FOR when exposed through $_SERVER to Nextcloud.

This is it! Now Nextcloud properly takes into account the remote address when served by a reverse proxy.

Addendum

Here is the commit that added the X-forwarded-for capacity to ownCloud/Nextcloud: https://github.com/owncloud/core/pull/10653/files.

D'ownCloud à Nextcloud : à ne pas oublier lors de la migration !

Voici deux points importants à ne pas oublier de modifier lors d'une migration d'ownCloud vers Nextcloud !

Rotation des logs

Si vous effectuez une rotatation des logs, par exemple avec logrotate comme raconté ici, alors il est nécessaire de modifier le nom du fichier de log qui devient sans surprise nextcloud.log!

/var/www/owncloud/data/owncloud.log {
        weekly
        missingok
        rotate 8
        compress
        notifempty
        create 640 www-data www-data
}

devient par exemple :

/var/www/nextcloud/data/nextcloud.log {
        weekly
        missingok
        rotate 8
        compress
        notifempty
        create 640 www-data www-data
}

Exécution du cron périodique

Si, comme cela est recommandé, cron exécute toutes les 15 minutes le script de maintenance de ownCloud, alors il faut transposer cela sur l'instance Nextcloud !

# m h  dom mon dow   command
*/15  *  *  *  * php -f /var/www/owncloud/cron.php

devient

# m h  dom mon dow   command
*/15  *  *  *  * php -f /var/www/nextcloud/cron.php

(à modifier avec crontab -e -u www-data si cela a été paramétré dans le crontab de l'utilisateur www-data)

Nextcloud, protection contre les attaques 'force brute' derrière un reverse proxy

Nextcloud 10 a introduit différentes améliorations de sécurité : notamment une protection contre les attaques de type force brute. Le principe en est simple : si l'instance détecte de multiples essais de connexion avec un mot de passe erroné depuis une même adresse IP, alors les requêtes de connexion de cette adresse ne recevront une réponse qu'après un temps d'attente d'une trentaine de secondes, rendant l'attaque par force brute délicate à mener.

Dans les logs, on verra alors des lignes similaires à :

{"reqId":"b4hUi89HUuji","remoteAddr":"10.20.30.40","app":"core","message":"Bruteforce attempt from "10.20.30.40" detected for action "login".","level":1,"time":"2016-10-17T04:08:55+00:00","method":"PROPFIND","url":"\/remote.php\/carddav\/","user":"--"}

qui nous apprennent que l'adresse 10.20.30.40 a fait un grand nombre d'essais de connexion ! Si l'on voulait renforcer la protection contre l'attaque de force brute, on pourrait alors également bannir cette adresse IP avec Fail2ban.

Et derrière un reverse proxy ?

Cependant, si l'on travaille derrière un reverse proxy (par ex. Pound ou Nginx) et si Nextcloud n'a pas été bien paramétré, alors l'adresse distante 'remoteAddr' sera celle du reverse proxy (192.168.1.1 dans l'exemple ci-dessous) :

{"reqId":"b4hUi89HUuji","remoteAddr":"192.168.1.1","app":"core","message":"Bruteforce attempt from "192.168.1.1" detected for action "login".","level":1,"time":"2016-10-17T04:08:55+00:00","method":"PROPFIND","url":"\/remote.php\/carddav\/","user":"--"}

Dès lors, toute attaque par la force brute pénalisera toutes les connexions qui passent par le reverse proxy ! Heureusement, il est possible d'indiquer à Nextcloud d'utiliser l'adresse fournie par le reverse proxy, par exemple dans le champ 'X-Forwarded-For', comme adresse distante !

Nextcloud et X-Forwarded-For

Pour l'exercice, considérons que l'adresse IP du reverse proxy est 192.168.1.1 et qu'il est paramétré pour indiquer l'adresse source dans le champ X-Forwarded-For.

Dès lors, ouvrons le fichier de configuration de Nextcloud (par ex. /var/www/nextcloud/config/config.php) et ajoutons ces 2 lignes :

  'trusted_proxies' => array('192.168.1.1'),
  'forwarded_for_headers' => array('HTTP_X_FORWARDED_FOR'),

La première ligne indique l'adresse IP du reverse proxy (Nextcloud ne doit regarder les en-têtes forwarded_for que pour les paquets provenant d'un reverse proxy autorisé, sans quoi un astucieux attaquant pourrait transmettre des paquets avec des en-têtes X-Forwarded-For forgées et aléatoires).

La seconde ligne indique quel est le champ à chercher dans les en-têtes : X-Forwarded-For dans notre cas (donc HTTP_X_FORWARDED_FOR dans les en-têtes $_SERVER retournées en PHP à Nextcloud).

Le tour est joué : au lieu de lire l'adresse IP du reverse proxy, Nextcloud lit désormais celle de l'hôte d'origine que lui fournit le reverse proxy et la protection contre les attaques de force brute se fait contre les adresse malfaisantes !

Complément

Le commit qui a ajouté cette fonctionnalité à ownCloud/Nextcloud se trouve ici.

vendredi 14 octobre 2016

Migration d'ownCloud à Nextcloud : aucun problème à signaler

Ce matin, je me suis décidé à migrer d'ownCloud vers Nextcloud. Il y a plusieurs raisons à cela :

  • j'avais le sentiment (peut-être erroné) que le rythme d'évolution d'ownCloud a considérablement baissé depuis le fork
  • la mise à jour automatique d'ownCloud avait cessé de fonctionner (?) depuis 9.0.4
  • certaines fonctionnalités nouvelles de Nextcloud m'intéressaient (par exemple la gestion plus fine des droits)
  • l'herbe paraît toujours plus verte ailleurs
  • un peu de changement ça peut faire du bien

Je souhaite répondre ici à certaines questions que je me posais et auxquelles je n'ai pas trouvé de réponse claire avant migration.

1) La migration sera-t-elle vraiment indolore ?

Mon instance compte une vingtaine d'utilisateurs et 150 Go de données. La migration effectuée en suivant cette documentation depuis oC 9.0.4 s'est passée sans aucune difficulté. Elle s'est déroulée avec la même facilité qu'une mise à jour manuelle d'ownCloud. Ne pas oublier de sauvegarder la base de données et le dossier ownCloud avant par prudence !

2) L'application Rainloop sera-t-elle fonctionnelle ?

Je n'utilise que quelques applications spécifiques en sus des applications officielles, Parmi elle, Rainloop est devenue la plus importante. Bien que Rainloop n'apparaisse pas (encore ?) dans le magasin des applications de Nextcloud (https://apps.nextcloud.com/), j'ai lu ça et là que la version pour ownCloud fonctionnait parfaitement sur Nextcloud. Et, en pratique c'est le cas !

J'ai téléchargé la version 4.26 disponible sur https://apps.owncloud.com/content/show.php/RainLoop+Webmail?content=165254, l'ai déployée dans le dossier 'apps' de nextcloud, j'ai rendu le dossier accessible par www-data (qui exécute les scripts PHP sur mon serveur Debian) puis ai pu activer Rainloop dans le menu 'Apps' après avoir coché la case 'Enable experimental apps'.

Screenshot_2016-10-14_08-22-20.png

3) Est-ce que le calendrier et les contacts fonctionnent sans perte de données après migration ?

Oui, aucun souci.

4) Il n'y a pas (encore ?) de paquet pour le client Nextcloud disponible sur le site. Je n'ai pas envie de le compiler. Le client ownCloud fonctionne-t-il ?

Oui, sans aucune différence avec client 2.2.x et Nextcloud 10.0.1. Il semble qu'au moins jusqu'à la version 2.2.4 le client Nextcloud est la copie conforme du client ownCloud avec seulement des noms et des icônes modifiées. Source : https://help.nextcloud.com/t/use-owncloud-client-with-nextcloud-10/4117

5) Vais-je déplorer quelque chose après migration ?

Pour le moment, je n'ai rien à déplorer.

dimanche 20 mars 2016

ownCloud/Nextcloud, Pound et MKCALENDAR

A compter de la version 9.0, ownCloud/Nextcloud utilise le mot clé MKCALENDAR dans l'application Calendrier. Ce mot clé est utilisé pour provoquer la création d'un nouveau calendrier/nouvel agenda sur l'interface en ligne. Or, ce mot HTTP n'est pas reconnu dans la version de Pound, le load balancer, disponible sur Debian Jessie.

Première approche de solution

On peut noter que ce point a été traité par les développeurs de Debian ici. Ainsi, la version 2.6-6.1, disponible sur Debian Testing/Unstable accepte le mot clé MKCALENDAR.

Il est donc possible d'installer le paquet de Testing/Unstable (à condition d'avoir bien paramétré /etc/apt/sources.list et /etc/apt/preferences) à l'aide de la commande :

apt-get -t unstable install pound

Seconde approche de solution

La version de Pound utilisée dans Jessie et Sid est pour l'instant la version 2.6 qui souffre de certaines faiblesses (même si les mainteneurs ont fait un travail formidable pour prendre en compte les bugs critiques et améliorer la sécurité). Dès lors, certains préféreront peut-être utiliser la version 2.7 stable disponible mais non proposée par Debian pour le moment.

Il faudra alors compiler manuellement Pound (ce qui n'est pas très compliqué). Mais stupeur, la version 2.7 de Pound ne supporte pas MKCALENDAR. Il faut donc patcher le fichier config.h pour inclure MKCALENDAR ! Là encore ce n'est pas bien compliqué.

Bonne compilation de Pound !

ownCloud/Nextcloud 9 : activer le cache APCu pour améliorer (un peu) les performances

Pour améliorer les performances d'ownCloud/Nextcloud, il est très facile d'activer un memcache facilement en quelques actions seulement :

  • on installe le paquet php5-apcu avec la commande (sous Debian, sinon il faudra adapter le gestionnaire de paquet et le nom du paquet) :
apt install php5-apcu
  • on redémarre Apache :
service apache2 restart
  • on ajoute alors cette ligne dans le fichier de configuration d'ownCloud/Nextcloud :
'memcache.local' => '\OC\Memcache\APCu',

Et le tour est joué !

samedi 19 décembre 2015

Utiliser Let’s Encrypt avec ownCloud/Nextcloud, Piwik, Dotclear, Drupal, Wordpress, des applications Rails et des sites statiques !

Depuis le début du mois, il est possible d'utiliser "Let's Encrypt" pour obtenir des certificats TLS/SSL pour sécuriser ses sites et services en ligne (bien que le système soit toujours annoncé en bêta). Ce matin, je décidais donc de m'y mettre et de remplacer mes certificats StartSSL.

Depuis Mai 2016, le service Let's Encrypt n'est plus en bêta et les limitations de la bêta évoquées ici ne sont plus mordantes !

Depuis Mai 2016, le client letsencrypt est devenu certbot (https://certbot.eff.org/) ! les commandes évoquées plus bas sont sans doute valables en remplaçant letsencrypt-auto par certbot !

Première étape : comprendre le fonctionnement

Le principe est assez simple et n'est pas très différent de celui déjà rencontré pour l'obtention de certificats auprès des opérateurs "classiques" (les StartSSL et consors). Classiquement, (i) on démontre la possession réelle du nom de domaine, (ii) on génère une clé privée et une clé publique et on transmet la clé publique à l'opérateur de certification qui (iii) fournit en retour un certificat attestant le lien entre le nom de domaine et la paire de clés crypto utilisées pour l'établissement de communications sécurisées. Avec Letsencrypt, ces étapes ont lieu mais automatiquement. Dans l'utilisation commune, Letsencrypt vient avec un script Python (letsencrypt-auto) qui va faire tout le travail :

  • le script va créer un fichier mondomaine.tld/.well-known/acme-challenge/chaîne-choisie-au-hasard et le serveur distant cherchera à accéder à ce fichier pour authentifier la possession/maîtrise du domaine mondomaine.tld
  • puis le script génère et échange les clés cryptographiques avec l'autorité de certification Letsencrypt
  • et le certificat est rapatrié
  • enfin, dans certains cas, le script se charge même de l'installer !

Par rapport à ce qui est fourni habituellement par les acteurs privés :

  • la chaîne de bout en bout est plus transparente et libre
  • le certificat est gratuit
  • le certificat n'a une validité que de 90 jours (mais le renouvellement est gratuit et peut être géré automatiquement par le script tous les 2 mois par exemple)
  • les certificats n'autorisent pas les wildcards (e.g. *.mondomaine.tld) ce qui a déjà été fort amplement débattu partout sur le web mais ne semble pas devoir changer.

Deuxième étape : installer Let’s Encrypt

Nous allons commencer par le cas simple d'un site statique. Le script letsencrypt se télécharge sur la machine d'hébergement à l'aide de git :

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

puis on peut lancer le script (qui va effectuer les installations supplémentaires nécessaires) par :

./letsencrypt-auto

Cela fonctionne très bien sur Debian Jessie et sans doute les autres systèmes récents (c'est la version de Python qui semble être un des facteurs limitants pour les "vieilles" distributions). On reviendra sur ce point plus loin.

Troisième étape : utiliser Let’s Encrypt pour un site statique

Commençons par le cas simple d'un site statique hébergé dans /var/www/mon-site/ et servi par Apache.

./letsencrypt-auto certonly -a webroot --webroot-path /var/www/mon-site/ -d mondomaine.tld

certonly car nous demandons à Let’s Encrypt de générer le certificat et de s'arrêter là (donc de ne pas l'installer lui-même). -a webroot car nous indiquons à Let’s Encrypt où se trouve la racine du site afin qu'il puisse y placer le fichier de "challenge" (.well-known/acme-challenge/chaîne-choisie-au-hasard). Et -d mondomaine.tld pour indiquer le domaine. Il est possible d'indiquer plusieurs domaines s'ils partagent le même webroot par exemple :

./letsencrypt-auto certonly -a webroot --webroot-path /var/www/mon-site/ -d mondomaine.tld -d www.mondomaine.tld

Dans ce cas le certificat contiendra les 2 domaines en SAN (Subject Alternative Names).

Au premier lancement, le script demande de saisir l'adresse courriel qui sera rattachée au compte (et qui recevra les éventuelles notifications de péremption des domaines non renouvelés).

Et hop, le script travaille et un certificat tout neuf (et valide !) est déposé dans /etc/letsencrypt/live/mondomaine.tld/fullchain.pem. La clé privée correspondante se trouve dans /etc/letsencrypt/live/mondomaine.tld/privkey.pem. Ce certificat peut alors être utilisé comme il l'a toujours été (par ex. appelé dans la configuration d'Apache ou de votre load balancer) - je détaille ici comment l'utiliser avec le load balancer Pound.

Let’s Encrypt et un blog dotclear

Aucune surprise ni difficulté avec dotclear :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/blog/dotclear -d blog.bandinelli.net

et hop, /etc/letsencrypt/live/blog.bandinelli.net/fullchain.pem est créé ! Une commande pour un certificat, c'est classe et pratique !

Let’s Encrypt et Piwik

Aucune surprise ni difficulté avec Piwik :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/racine/piwik -d piwik.mondomaine.tld

et hop, /etc/letsencrypt/live/piwik.mondomaine.tld/fullchain.pem est créé !

Let’s Encrypt et Wordpress

Aucune surprise ni difficulté avec Wordpress :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/racine/wordpress -d mondomaine.tld

et hop, /etc/letsencrypt/live/mondomaine.tld/fullchain.pem est créé !

Let’s Encrypt et Drupal 7

Une petite astuce est nécessaire ici : par défaut le moteur de Drupal demande au serveur web de réécrire toutes les adresses et empêche l'accès à certaines adresses. Ainsi, le fichier .htaccess se trouvant à la racine d'un site Drupal contient la ligne suivante :

RewriteRule "(^|/)\." - [F]

Cette ligne ordonne à Apache de renvoyer vers la page "Accès interdit" toute requête qui débuterait par ".". Il faut bien évidemment désactiver cette sécurité pour Letsencrypt :

RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule "(^|/)\." - [F]

La condition RewriteCond désactive la redirection qui suit pour le challenge de letsencrypt seulement.

Une fois cela effectué, on peut utiliser la commande classique pour obtenir le certificat valide dans /etc/letsencrypt/live/mondomaine.tld/fullchain.pem :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/site/drupal/ -d mondomaine.tld

Let’s Encrypt et ownCloud/Nextcloud

Une petite astuce est nécessaire ici : par défaut le moteur d'ownCloud demande au serveur web de réécrire toutes les adresses et empêche l'accès à certaines adresses. Ainsi, le fichier .htaccess se trouvant à la racine d'une instance ownCloud/Nextcloud contient la ligne suivante :

RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

elle renvoie vers 404 tous les appels à un chemin démarrant par ".". Il est bien sûr nécessaire de désactiver cette ligne conditionnellement :

RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

Ensuite, sans surprise, pour obtenir le certificat valide dans /etc/letsencrypt/live/mondomainecloud.tld/fullchain.pem :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/owncloud/ -d mondomainecloud.tld

Let’s Encrypt et une application Ruby on Rails

Aucune surprise ni difficulté avec une application Ruby on Rails servie en production par Unicorn, à condition de bien choisir le dossier public comme webroot :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/application/public -d domaine.tld

et hop, /etc/letsencrypt/live/domaine.tld/fullchain.pem est créé !

Let’s Encrypt sur une vieille distribution ?

Si Let's Encrypt ne peut être lancé sur votre machine de production car elle dispose de versions trop anciennes des fichiers, rien n'est perdu ! Il est en effet possible de fournir au script un webroot qui serait par exemple partagé via SSH ! Par exemple :

apt install sshfs
mkdir /mnt/webroot-distant
sshfs user@machine:/path/to/webroot /mnt/webroot-distant
./letsencrypt-auto certonly -a webroot --webroot-path /mnt/webroot-distant -d mondomaine.tld

Conclusion

Très efficace et rapide, comment ne pas tomber sous le charme de Letsencrypt ? Il reste à valider : la procédure de renouvellement et la pérennité dans le temps de la structure. Pour y aider, on peut toujours faire un petit don sur la page d'accueil de Let’s Encrypt !

vendredi 2 janvier 2015

Entretenir et sécuriser Nextcloud/ownCloud avec logrotate et fail2ban

On ne présente plus ownCloud/Nextcloud, plateforme de stockage et partage de fichiers fort aboutie. Pour ceux qui hébergent leur propre instance d'ownCloud/Nextcloud, voici deux petites astuces pour bien entretenir et sécuriser l'installation.

La rotation des logs

La rotation des logs évite que le fichier owncloud.log n'occupe une place trop importante sur votre serveur. On pourra utiliser logrorate pour effectuer la rotation automatique et régulière.

Dans /etc/logrotate.d/owncloud, on placera le paramétrage (assez explicite) suivant :

/var/www/owncloud/data/owncloud.log {
        weekly
        missingok
        rotate 8
        compress
        notifempty
        create 640 www-data www-data
}

et le tour est joué. On prendra bien sûr le soin d'adapter le chemin vers le fichier et le nom de l'utilisateur créateur du fichier (ici www-data car c'est l'utilisateur propriétaire du serveur web sous Debian) ! Si l'on utilise Nextcloud plutôt qu'ownCloud, on remplacera owncloud.log par nextcloud.log sans surprise !

Surveillance avec fail2ban

Fail2ban est capable de détecter des connexions non autorisées et de bannir (via iptables) l'adresse IP offensante. Un éventuel attaquant n'aura ainsi pas tout le loisir de tester les combinaisons nom d'utilisateur / mot de passe à son aise. Concrètement, on paramètre fail2ban pour vérifier régulièrement un fichier de log et pour détecter dans ce fichier les tentatives d'accès frauduleuses (i.e. qui se répètent). Puis, quand une tentative frauduleuse est repérée, on bannit l'adresse IP correspondante.

Nous allons créer un nouveau filtre pour fail2ban dans /etc/fail2ban/filter.d/owncloud.conf :

[Definition] 
#Pour owncloud <8
failregex = {"app":"core","message":"Login failed:(.*)IP: '<HOST>'
#Pour owncloud 8
failregex = {"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>', X-Forwarded-For: '.*'\)","level":2,"time":".*"}

Si l'accès est contrôlé par un proxy, on pourra modifier la règle pour repérer l'adresse IP associée au champ X-Forwarded-for :

[Definition]
#Pour owncloud <8
failregex = {"app":"core","message":"Login failed:(.*)X-Forwarded-For: '<HOST>'
#Pour owncloud 8
failregex = {"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '.*', X-Forwarded-For: '<HOST>'\)","level":2,"time":".*"}

On peut alors créer une nouvelle règle dans /etc/fail2ban/jail.local :

[owncloud]
enabled  = true
port     = http,https
filter   = owncloud
logpath  = /var/www/owncloud/data/owncloud.log
maxretry = 6

et désormais, toute tentative d'accès répétée conduira à l'exclusion de l'IP douteuse !

PS Merci à Arnaud Collarde pour la mise à jour de l'expression régulière pour ownCloud 8.