Dans le précédent article, nous avons vu comment sécuriser les middlewares, ou plutôt comment les maintenir à jour. Cela dit, c’est bien joli de sécuriser des middlewares, mais si le système d’exploitation sous ceux-ci n’est pas tenu à jour il restera encore des failles de sécurité dans votre application. Comme dans les autres articles, nous n’avons pas pour vocation d’être exhaustifs ici, juste d’énoncer des points de départ. Pour ceux qui veulent approfondir, vous pouvez vous référer à cet ouvrage.
Débloque les + belles offres tech en 10 mins
La première règle à appliquer consiste à exécuter votre serveur d’applications avec le minimum de privilèges requis pour que l’application puisse s’exécuter. Autrement dit, exécuter une application en tant que root est une mauvaise idée, du fait que si le serveur d’applications présente une faille de sécurité qu’un pirate exploite, il obtiendra automatiquement les privilèges d’exécution root, pas vraiment satisfaisant. Mais alors, vous me direz, « mon appli doit écouter sur le port 80 donc je dois lancer mon Tomcat en root »… En fait il n’y a pas besoin, le Tomcat peut parfaitement écouter sur le port 8080 et que devant vous placiez un proxy, par exemple Apache, qui lui redirige les requêtes. En prime vous pourrez stocker sur ce proxy toutes les ressources statiques, ce qui allégera d’autant le Tomcat. C’est pas beau ?
Passons maintenant à d’autres bonnes pratiques.
Toujours installer les patches de sécurité sur votre système
Je vais vous raconter une histoire : il y a 8 ans, pensant bien faire, un développeur Debian a supprimé un bout de code dans OpenSSL parce que Valgrind lui avait remonté un warning à ce sujet. Bilan, en 2008 le pot-aux-roses a été découvert, et on s’est rendu compte que le warning en question était un faux positif et que le « corriger » nuisait en fait gravement à l’algorithme de génération de clefs SSH. C’est ainsi qu’au lieu d’avoir potentiellement plusieurs dizaines de milliards de clefs possibles, on n’en avait plus que 256000, soit un nombre de clef très facile à casser par force brute. Dès lors une mise à jour d’urgence a été livrée pour corriger le problème, mais dans une ancienne entreprise j’ai vu des serveurs qui n’avaient toujours pas appliqué ladite mise à jour. Autrement dit ils étaient parfaitement vulnérables à une attaque par force brute en cas d’authentification par clef.
Il s’agit d’un exemple extrême, mais il illustre parfaitement la nécessité d’avoir toujours un système à jour en terme de sécurité. Alors, vous me direz, mais comment vérifier que ça ne va pas casser toute mon application ? Là encore le fix est simple : ayez toujours un environnement de préproduction prêt pour tester ces modifications. Il s’agit ensuite d’exécuter des tests automatisés pour la charge et la non régression, et de laisser l’application fonctionner pendant quelques jours pour vérifier qu’aucun problème de stabilité n’est détecté. L’environnement de préproduction doit avoir strictement les mêmes spécifications logicielles et matérielles que celui de production.
Ne démarrez qu’un minimum de services
Là encore, il arrive sur certains serveurs qu’un nombre conséquent de services inutiles soit démarré. On retrouve plus souvent le cas avec des machines Windows qui ont généralement une interface graphique, mais de temps à autres on peut retrouver aussi une machine Unix avec un serveur X démarré de manière totalement inutile. Pourquoi l’éviter ? Tout d’abord parce que ça consomme des ressources, alors que sur un serveur la majeure partie de celles-ci doivent être affectées à l’application ou les applis à exécuter. Mais surtout car chaque application inutile qui fonctionne contient ses failles, et est donc un vecteur d’intrusions potentiel. Imaginez par exemple qu’un X-Window fonctionne sur votre serveur, et qu’un pirate pénètre sur le réseau de celui-ci : il suffit à l’intrus d’exploiter une faille de X pour prendre le contrôle de votre serveur et faire ce qu’il veut dessus.
Quelques bonnes pratiques d’administration
De plus en plus, les serveurs sont regroupés dans des data centers chez des hébergeurs tels qu’OVH ou Ecritel. Le souci est que pour vous connecter à ceux-ci vous devez passer par Internet, qui est une zone pouvant potentiellement être piratée par une attaque du type Man-in-the-middle, ou encore par un pirate qui aurait exécuté une attaque SSH en force brute sur votre serveur.
Un bon moyen de se prémunir de ce souci est d’utiliser un VPN. Celui-ci permettra d’avoir les ports d’administration de vos serveurs uniquement accessibles depuis les machines dûment autorisées sur le VPN, tout en les fermant sur l’extérieur. Malheureusement, ce n’est pas toujours possible.
Pour les machines Unix administrées par SSH, la première chose à faire est d’interdire le login de l’utilisateur root à distance. Il faut plutôt se logguer avec un utilisateur ayant des droits d’accès restreints, et qui passera en root avec la commande su -. Pour éviter les bots il est de bon aloi de faire écouter le serveur SSH sur un autre port que le 22. La configuration de votre serveur SSH est très bien expliquée ici, aussi je ne vais pas m’étendre dessus.
De même, tous les transferts de données depuis vos postes vers vos serveurs doivent s’effectuer de manière sécurisée, avec sftp, de façon à éviter d’échanger les données d’authentification de vos serveurs en clair sur le réseau.
Ah et dernier point pour vous simplifier le travail si vous avez des parcs importants à gérer : les outils du type Puppet ou Ansible sont vos amis, de même qu’une crontab qui pourra lancer une mise à jour automatique des serveurs à une heure donnée, en utilisant pour ce faire des dépôts mirrorés à vous qui ne contiennent que les verions de softs approuvées.
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
