Ce qu'il ne faut pas faire

Module 10: Rester en sécurité · Temps de lecture : 12 minutes

Objectif pédagogique : À la fin de cette leçon, vous reconnaissez les erreurs qui mènent le plus souvent à un serveur piraté ou hors service, vous savez expliquer pourquoi elles sont dangereuses et vous savez ce qu'il faut faire à la place.

Notions clés : connexion root avec mot de passe, mot de passe faible ou par défaut, base de données ouverte, API Docker sur le port 2375, docker.sock dans un conteneur, chmod 777, curl | bash, secrets dans Git, panneau d'administration sans authentification à deux facteurs, pare-feu « coupé un instant », pas de mises à jour, pas de sauvegarde

Pourquoi une leçon sur les erreurs ?

La plupart des serveurs ne sont pas piratés par un attaquant génial exploitant une faille inconnue. Ils sont piratés par des bots qui parcourent tout Internet à la recherche d'erreurs connues : un mot de passe facile à deviner, une base de données ouverte, un programme qui n'a pas été mis à jour depuis des mois. En évitant les erreurs de cette leçon, vous sortez du viseur de ces bots. C'est l'essentiel de la protection que vous pouvez obtenir.

Pour chaque erreur, vous trouverez pourquoi elle est dangereuse et ce qu'il faut faire à la place. Vous avez appris presque tout cela dans les leçons précédentes ; cette leçon le récapitule.

1. Connexion root avec un mot de passe

Le problème. Chaque serveur reçoit toute la journée des tentatives de connexion sur root (leçon 5.3). Si root peut se connecter avec un mot de passe, ce mot de passe est la seule chose qui sépare un bot du contrôle total. Les mots de passe réutilisés ou trop courts finissent tôt ou tard par être devinés, ou figurent déjà dans une liste divulguée.

Faites plutôt ceci. Connexion uniquement par clés : PasswordAuthentication no et KbdInteractiveAuthentication no, root au mieux avec une clé (PermitRootLogin prohibit-password) ou pas du tout (no), et travail quotidien en tant qu'utilisateur ordinaire avec sudo (leçons 2.2 et 3.2). Vérifiez depuis l'extérieur quelles méthodes de connexion votre serveur propose (exercice Z2.2).

2. Une base de données, un cache ou un cluster de recherche ouvert sur Internet

Le problème. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch ou OpenSearch (9200) et MongoDB (27017) sont conçus pour des programmes de confiance dans un réseau de confiance. S'ils écoutent sur 0.0.0.0 sans pare-feu, les scanners les trouvent vite. Redis indique dans sa propre documentation qu'il ne doit pas être exposé à Internet et que toute personne y ayant accès peut effacer l'ensemble des données ; avec la commande CONFIG, un attaquant peut même écrire des fichiers sur le serveur. Les bases de données et clusters de recherche ouverts sont depuis des années une cause connue de grandes fuites de données et de messages de « rançon » à la place de vos données.

Faites plutôt ceci. Faites écouter ces services sur 127.0.0.1 (leçon 5.1), gardez-les derrière le pare-feu (leçon 5.2) et, dans Docker, ne les publiez pas ou seulement sur 127.0.0.1 (leçon 9.3). Pour y accéder vous-même depuis votre ordinateur portable : un tunnel SSH (leçon 2.3). Vérifiez depuis l'extérieur (exercice Z5.1).

3. L'API Docker ouverte ou docker.sock dans un conteneur

Le problème. Quiconque peut piloter le démon Docker est en pratique root sur le serveur : la documentation Docker précise que seuls des utilisateurs de confiance doivent pouvoir piloter le démon et considère l'accès au démon comme équivalent à un accès root. Deux variantes de cette erreur :

• Le démon écoute sur un port TCP sans TLS (habituellement 2375). Toute personne qui atteint ce port peut lancer des conteneurs contenant le disque de votre serveur.
• Un conteneur reçoit /var/run/docker.sock comme volume (« comme ça, il peut gérer lui-même des conteneurs »). Si ce conteneur est piraté, c'est tout le serveur qui est perdu.

Le groupe docker équivaut lui aussi à root (leçon 9.2) : n'y placez que des administrateurs.

Faites plutôt ceci. Faites fonctionner Docker uniquement via le socket local. L'administration à distance passe par SSH (docker context avec ssh://) ou, si TCP est vraiment indispensable, par TLS sur le port 2376 avec des certificats clients. Ne montez docker.sock que dans un conteneur en qui vous avez entièrement confiance et dont vous avez réellement besoin, et de préférence en lecture seule via un proxy restrictif.

4. chmod 777 pour faire disparaître un message d'erreur

Le problème. « Permission denied » lors d'un envoi de fichier, et un forum conseille : chmod -R 777 /var/www. Dès lors, chaque utilisateur et chaque processus du serveur peut écrire n'importe quoi dans votre site web, y compris une extension piratée ou un autre compte. Du code accessible en écriture au serveur web peut, via une faille, être remplacé par une porte dérobée.

Faites plutôt ceci. Déterminez qui doit écrire et où (leçon 3.1) : en général uniquement l'utilisateur du serveur web, dans un seul dossier pour les envois ou le cache. Le code appartient à un autre propriétaire que le serveur web, avec des droits 644/755, et les envois en 750/640 ou similaire.

5. curl ... | bash et des logiciels venus de n'importe où

Le problème. Un script que vous exécutez en root sans l'avoir lu peut tout faire : ajouter des sources et des clés, écraser des fichiers, ouvrir un service. Même avec de bonnes intentions, vous ne savez ensuite plus ce qui a changé, et la prochaine mise à niveau de version casse quelque chose (leçon 4.3).

Faites plutôt ceci. Téléchargez le script et lisez-le. Installez de préférence depuis les dépôts de votre distribution ou la source officielle de l'éditeur, avec sa propre clé (Signed-By, leçon 4.1). Notez ce que vous installez et pourquoi.

6. Pas de mises à jour, ou des mises à jour « plus tard »

Le problème. Les failles sont corrigées puis exploitées, souvent en quelques jours. Un serveur qui ne reçoit pas de mises à jour pendant des mois, ou qui tourne sur une version qui n'est plus prise en charge, présente une liste de brèches connues. Les conteneurs ne sont pas mis à jour par apt.

Faites plutôt ceci. Activez les mises à jour de sécurité automatiques (leçon 4.2), prévoyez un moment fixe pour les redémarrages, notez la date de fin de support de votre version dans votre agenda (leçon 4.3) et mettez régulièrement vos conteneurs à jour (leçon 9.4).

7. Pas de sauvegarde, ou une sauvegarde jamais testée

Le problème. Un instantané sur le même stockage n'est pas une sauvegarde (leçon 8.1). Une sauvegarde stockée sur le serveur lui-même disparaît avec lui en cas de piratage ou de rançongiciel. Et une sauvegarde qui n'a jamais été restaurée est un espoir, pas une certitude.

Faites plutôt ceci. Des sauvegardes chiffrées hors du serveur (restic, leçon 8.2), une surveillance qui vérifie qu'elles s'exécutent, et au moins un test de restauration par trimestre.

8. Des panneaux d'administration ouverts à tous, sans authentification à deux facteurs

Le problème. Un panneau d'administration de base de données (comme phpMyAdmin), de Docker (comme Portainer), de votre application ou de votre coffre-fort de mots de passe est une cible attrayante : un seul mot de passe donne accès à tout. Des mots de passe par défaut comme admin/admin et des inscriptions restées ouvertes (Vaultwarden, leçon 9.4) facilitent encore la tâche.

Faites plutôt ceci. N'exposez pas les panneaux d'administration sur Internet : accédez-y via un tunnel SSH ou uniquement depuis une adresse fixe. Si un panneau doit malgré tout être public : https, un mot de passe fort et unique issu de votre gestionnaire de mots de passe, l'authentification à deux facteurs et les inscriptions fermées. Changez toujours les mots de passe par défaut.

9. Des secrets dans Git ou dans votre fichier compose

Le problème. Un mot de passe, une clé d'API ou une clé privée placé dans un fichier qui se retrouve dans un dépôt Git reste à jamais dans l'historique, même si vous le supprimez ensuite. Les dépôts publics sont fouillés par des bots à la recherche précisément de ce genre de clés.

Faites plutôt ceci. Placez les secrets dans un fichier séparé avec les droits 600 (EnvironmentFile, leçon 6.3 ; .env avec Docker Compose, leçon 9.3), listé dans .gitignore. Si un secret a malgré tout fuité : remplacez-le immédiatement (un nouveau mot de passe, une nouvelle clé), car un simple nettoyage dans Git ne suffit pas.

10. Le pare-feu coupé « un instant », tout en root, et aucune note

Le problème. « Je coupe le pare-feu un instant pour tester » finit par être oublié. « Je le fais vite en root » devient une habitude. Et un serveur dont personne ne sait ce qui y tourne ni pourquoi est impossible à administrer ou à restaurer.

Faites plutôt ceci. Testez avec une règle temporaire et étroite (un seul port, une seule adresse source), puis supprimez-la. Travaillez en tant qu'utilisateur ordinaire avec sudo. Tenez à jour un court dossier serveur : ce qui tourne, quels ports sont ouverts, où se trouvent les sauvegardes, quand arrive la fin de support de la version (leçon 10.4).

En pratique

Toutes ces erreurs peuvent être commises sur n'importe quel VPS, chez WebOké comme chez d'autres fournisseurs : ce qui se passe à l'intérieur de votre serveur, c'est vous qui le gérez. Le fournisseur peut en revanche déconnecter un serveur du réseau s'il envoie du spam ou mène des attaques, car cela touche d'autres clients. La prévention compte donc aussi pour votre propre disponibilité.

Résumé

• La plupart des piratages exploitent des erreurs connues, pas des failles inconnues.
• Connexion par clés, connexion par mot de passe désactivée ; bases de données, caches et API Docker jamais ouverts sur Internet ; pas de docker.sock dans des conteneurs auxquels vous ne faites pas entièrement confiance.
• Pas de chmod 777 ni de curl | bash : sachez qui a le droit de faire quoi et ce que vous installez.
• Mises à jour automatiques, sauvegardes hors du serveur et testées, panneaux d'administration derrière un tunnel ou avec authentification à deux facteurs.
• Secrets hors de Git et hors des fichiers compose ; un secret divulgué est un secret à remplacer.

Quiz

Exercice

Exercice Z10.2: De quelle erreur s'agit-il ? Le fichier d'exemple casussen-z10-2.md contient huit courts cas de serveurs qui présentent un problème. Pour chaque cas, choisissez de quelle erreur il s'agit dans la liste de cette leçon (A à J) et quelle est la meilleure première étape. Le programme compare vos réponses à la clé de correction, puis affiche l'explication de chaque cas.

Pour aller plus loin

• Sécuriser votre VPS : les cinq premières minutes
• Gestionnaire de mots de passe et passkeys : voici comment sécuriser vos connexions
• Documentation Docker, Docker security (Docker daemon attack surface) : https://docs.docker.com/engine/security/
• Documentation Docker, Protect the Docker daemon socket : https://docs.docker.com/engine/security/protect-access/
• Redis, Security : https://redis.io/docs/latest/operate/oss_and_stack/management/security/