163 lines
9 KiB
Markdown
Executable file
163 lines
9 KiB
Markdown
Executable file
<!-- title: Sécurité des données, focus sur Nextcloud -->
|
||
<!-- category: Hébergement BSD -->
|
||
<!-- tag: planet -->
|
||
|
||
En 2007, j'ai ouvert un compte Dropbox avec l'offre gratuite de 2 Go. J'avais
|
||
parrainé des collègues et des amis pour gagner de l'espace de stockage. Oui je
|
||
le reconnais, j'avais vendu des amis au
|
||
[GAFAM](https://fr.wikipedia.org/wiki/GAFAM) contre quelques octets<!-- more --> : mes
|
||
~~parrainages~~ compromissions m'avaient permis d'atteindre 6 Go de stockage...
|
||
Vertigineux ;-) A cette époque, ma fibre libriste était encore latente, j'étais
|
||
fier d'avoir autant d'espace et je m'en servais pour partager des photos avec la
|
||
famille. Je ne me suis jamais senti assez en confiance pour partager des
|
||
documents importants.
|
||
|
||
En 2010, j'ai commencé à héberger mes services et en 2014 je démarrais avec
|
||
[Owncloud](https://owncloud.org) principalement pour la synchronisation des
|
||
contacts et du calendrier. Puis j'ai commencé à partager quelques fichiers, mais
|
||
rien d'important. En 2015, j'ai remplacé Owncloud par [Cozy](https://cozy.io),
|
||
de la fameuse startup française qui oeuvre pour que l'utilisateur reprenne le
|
||
contrôle de sa vie numérique et ne la brade plus aux GAFAM. Cozy va plus loin
|
||
que le partage de fichiers et c'est vraiment un projet à suivre de près. C'est
|
||
avec eux que j'ai commencé à prendre confiance et partager des documents
|
||
importants. Et en 2016, je suis revenu vers Owncloud ou plus exactement vers son
|
||
fork né des guéguerres internes : [Nextcloud](https://nextcloud.com).
|
||
|
||
Bref mon compte Dropbox ne me servait plus depuis un bail mais j'avais du mal à
|
||
décider sa fermeture... mince c'était quand même gratuit ;-) Aujourd'hui il est
|
||
officiellement clôturé.
|
||
|
||
Donc j'ai quelques Giga octets de données sur Nextcloud, notamment des documents
|
||
administratifs, et je suis responsable de la sécurité de mes données. Alors la
|
||
sécurité c'est un vaste sujet. Cela commence par une protection physique des
|
||
données. Si mon serveur était à la maison, j'aurais probablement chiffré le
|
||
disque dur en cas de vol. Là il est chez un fournisseur de confiance, dans un
|
||
datacenter sécurisé donc l'accès direct à mon disque dur est le moins probable.
|
||
|
||
|
||
|
||
La pierre angulaire de la sécurité c'est le système d'exploitation et ses
|
||
capacités intrinsèques à résister aux attaques. Ensuite c'est de la
|
||
configuration : le parefeu, le routage réseau, la virtualisation, des outils de
|
||
détection d'attaques qui vont permettre d'améliorer la sécurité du système. Mais
|
||
si le système d'exploitation est gâté à la base, tout ce qui suit est un
|
||
emplâtre sur une jambe de bois ! Enfin on se comprend :-)
|
||
|
||
|
||
|
||
Depuis quelques mois, mon serveur est propulsé par OpenBSD (et je ne suis pas
|
||
prêt de revenir en arrière). Avec de la lecture et des conseils, je l'ai
|
||
sécurisé du mieux que j'ai pu. Je n'entrerai pas dans les détails, je ne suis
|
||
pas assez qualifié pour donner des cours sur le sujet mais le résultat n'est pas
|
||
mal du tout.
|
||
|
||
Pour la sécurité de mes données, ce qui m'inquiète le plus ce sont les failles
|
||
potentielles des applications hébergées qui pourraient servir de porte d'entrée
|
||
royale pour accéder aux données. La parano venant, j'ai décidé d'attaquer le
|
||
sujet par étapes et aujourd'hui j'ai focalisé sur mon instance **Nextcloud**.
|
||
C'est une application Web avec son propre sous-domaine qui donne directement sur
|
||
ce bel écran de connexion :
|
||
|
||
|
||
|
||
J'accède à mes données en mobilité donc il n'est pas possible de restreindre
|
||
l'accès par adresse IP. Donc je suis dépendant du système d'authentification de
|
||
Nextcloud. Première étape, je dois savoir ce qui se passe. Nextcloud fournit un
|
||
rapport d'audit et on peut configurer les actions qui doivent y figurer.
|
||
|
||
|
||
|
||
C'est une fonction nécessaire mais pas suffisante. Le rapport est envoyé chaque
|
||
heure si des données ont changé, un peu tard si on s'est fait ~~ni~~ha-cker.
|
||
|
||
Exemple de rapport :
|
||
|
||
Bonjour,
|
||
|
||
Vous recevez cet email car l'activité suivante a eu lieu sur https://nextcloud.mondomaine.fr/
|
||
|
||
* Vous avez partagé Partage/Blog/documents avec un lien public - Aujourd’hui 16:54:04
|
||
* Partage/Blog/documents/moderncv.zip téléchargé par lien public - Aujourd’hui 16:54:48
|
||
* Vous avez créé Notes/todo.txt - Aujourd’hui 17:04:49
|
||
|
||
Ce que j'aimerais aussi avoir, c'est un moyen de bloquer les gars qui font du
|
||
[brute-force](https://fr.wikipedia.org/wiki/Attaque_par_force_brute) sur l'écran
|
||
de connexion pour trouver mon mot de passe. C'est faisable si l'application a la
|
||
bonne idée de noter dans un log quand une tentative de connexion échoue :
|
||
|
||
- Sous Linux, l'excellent outil fail2ban (ben oui c'est du Python) permet d'analyser un
|
||
log à la recherche de messages spécifiques, d'extraire l'adresse IP concernée et
|
||
de créer une règle de blocage dans le parefeu (iptables) pour une durée
|
||
déterminée.
|
||
- Sous OpenBSD, Thuban s'est inspiré de fail2ban pour créer [Vilain](https://yeuxdelibad.net/Blog/?d=2017/02/05/09/53/19-vilain-setoffe) qui
|
||
fonctionne de concert avec l'incroyable parefeu [pf](https://man.openbsd.org/pf.conf).
|
||
|
||
Ce qui suit est donc réalisé avec Vilain sous OpenBSD mais c'est facilement transposable sous Linux.
|
||
|
||
Je bloque les fâcheux pendant une heure avec cette règle pour Vilain qui
|
||
fonctionne aussi bien pour l'écran de connexion à l'interface Web que pour
|
||
l'accès aux fichiers avec WebDAV.
|
||
|
||
[nextcloud]
|
||
logfile = /var/www/htdocs/datacloud/nextcloud.log
|
||
regex = .*Bruteforce attempt from \\"(.*)\\" detected
|
||
|
||
Quid des partages par lien public ? En effet, Nextcloud permet aussi de partager
|
||
un fichier ou un dossier à quelqu'un qui n'a pas de compte avec un lien public.
|
||
La création d'un partage est aussi simple que ceci :
|
||
|
||
|
||
|
||
La sécurité repose essentiellement sur l'URL générée *au hasard* donc le partage
|
||
d'un document important sans spécifier de mot de passe est à proscrire.
|
||
D'ailleurs l'interface d'administration de Nextcloud permet d'interdire la
|
||
création de tels liens par les utilisateurs. J'utilise assez souvent ces liens
|
||
publics et je ne m'étais jamais posé la question de leur sécurité. Alors
|
||
mauvaise nouvelle, si on crée un lien avec mot de passe et que l'URL tombe dans
|
||
les mains d'un malfaisant (ou réussit à être devinée), il peut tranquillement
|
||
faire du brute-force sur le lien car Nextcloud n'écrit aucune info dans ses logs
|
||
sur ces erreurs d'authentification. Pas cool ça hein <i class="fa fa-ambulance" aria-hidden="true"></i>
|
||
|
||
|
||
La solution va venir du logs d'accès du serveur HTTP qui trace toutes les
|
||
requêtes HTTP et leur code retour. Pour un accès avec le bon mot de passe,
|
||
on aura un log comme celui-ci :
|
||
|
||
80.214.223.96 - - [02/Sep/2017:12:36:58 +0200] "POST /s/wKDvKK8vt6ZSU5E/authenticate HTTP/1.1" 303 5 "-" "Mozilla/5.0 (BB10; Kbd) AppleWebKit/537.35+ (KHTML, like Gecko) Version/10.3.3.2163 Mobile Safari/537.35+"
|
||
|
||
Alors que pour un accès refusé car le mot de passe est incorrect on aura ceci :
|
||
|
||
80.214.223.96 - - [02/Sep/2017:12:36:27 +0200] "POST /s/wKDvKK8vt6ZSU5E/authenticate HTTP/1.1" 200 16186 "-" "Mozilla/5.0 (BB10; Kbd) AppleWebKit/537.35+ (KHTML, like Gecko) Version/10.3.3.2163 Mobile Safari/537.35+"
|
||
|
||
Alors au premier abord, ça semble bizarre car l'erreur de mot de passe renvoie
|
||
un code HTTP 200 qui correspond à OK. C'est parce qu'en cas d'erreur, on reste
|
||
sur la page qui redemande le mot de passe, alors qu'en cas de succès le code de
|
||
retour est une redirection HTTP 303 vers la page qui affiche les documents du
|
||
partage. Le formatage de mes logs d'accès dépend de la configuration de mon
|
||
serveur HTTP (en l'occurence NginX) donc l'expression régulière qui permet
|
||
d'identifier les erreurs de mot de passe doit en tenir compte. Sur cette base je
|
||
peux rajouter la règle suivante à Vilain :
|
||
|
||
[nextcloud-share]
|
||
logfile = /var/www/logs/access-nextcloud.log
|
||
regex = (\d+\.\d+\.\d+\.\d+) \-.*POST /s/\w+/authenticate HTTP/1.1\" 200
|
||
|
||
Voilà, nous avons deux règles efficaces qui vont bloquer les attaquants à chaque
|
||
double échec d'authentification. C'est cool mais je voudrais aussi connaître le
|
||
nombre de mes ennemis, car si je suis soumis à des centaines d'attaques par jour
|
||
je réviserai peut-être ma façon de me protéger. Je vais donc m'envoyer un rapport
|
||
journalier de l'activité de Vilain :
|
||
|
||
- je modifie la configuration de Vilain pour qu'il écrive dans un log dédié et non plus dans */var/log/daemon*
|
||
- je configure un recyclage journalier pour ce log à minuit
|
||
- j'ajoute une tâche CRON à minuit moins 2 brouettes pour m'envoyer par e-mail le log de la journée
|
||
|
||
Quelque chose comme ça :
|
||
|
||
# /etc/newsyslog.conf
|
||
/var/log/vilain 640 5 * $D0 Z "rcctl restart vilain"
|
||
|
||
# crontab
|
||
55 23 * * * cat /var/log/vilain | mail -s "Vilain Rapport" yax
|
||
|
||
Oui je l'ai appelé le **Vilain Rapport**, au niveau de l'humour on ne se refait pas :-)
|