Dans la plupart des cas, les serveurs d’applications Web doivent être accessibles au public, ce qui signifie qu’ils sont exposés à toutes sortes de menaces.
Bon nombre de ces menaces sont prévisibles et facilement évitables, tandis que d’autres sont inconnues et peuvent vous prendre au dépourvu. Pour minimiser la possibilité de ce dernier cas, nous proposons une liste de conseils essentiels pour garder les serveurs d’applications Web aussi sécurisés que possible.
Avant de commencer avec la liste des conseils, vous devez comprendre qu’un serveur d’applications Web n’est pas une île. Le serveur est le composant central de la ferme d’applications Web qui permet l’hébergement et l’exploitation d’une application Web. Par conséquent, pour sécuriser, il faut prendre en compte tous les composants qui l’entourent et sécuriser l’ensemble de l’environnement applicatif web.
Un environnement de base pour l’hébergement et l’exécution d’applications Web comprend le système d’exploitation (Linux, Windows), le logiciel de serveur Web (Apache, Nginx), un serveur de base de données. Si l’un de ces composants est piraté, les attaquants pourraient y accéder et effectuer toutes les actions malveillantes qu’ils souhaitent.
Un premier conseil de base pour sécuriser un environnement tel que celui décrit ci-dessus est de lire les consignes de sécurité et la liste des meilleures pratiques pour chacun des composants. Cela étant dit, passons en revue un certain nombre de directives de sécurité de bon sens qui s’appliquent à presque tous les environnements d’applications Web.
Table des matières
Le pare-feu démystifié
Vous pourriez être tenté de vérifier rapidement cet élément en pensant : « J’ai de la chance, j’ai déjà un pare-feu protégeant mon réseau ». Mais tu ferais mieux de tenir tes chevaux.
Votre pare-feu peut prendre soin des frontières de votre réseau, en gardant les méchants à l’extérieur et les gentils à l’intérieur, mais il est certain qu’il laisse une porte grande ouverte aux attaquants pour s’introduire dans votre serveur d’applications Web.
Comment?
Simple : votre pare-feu réseau doit au moins autoriser le trafic entrant sur les ports 80 et 443 (c’est-à-dire HTTP et HTTPS), et ne sait pas qui ou quoi passe par ces ports.
Pour protéger votre application, vous avez besoin d’un pare-feu d’application Web (WAF) qui analyse spécifiquement le trafic Web et bloque toute tentative d’exploitation de vulnérabilités telles que les scripts intersites ou l’injection de code. Un WAF fonctionne comme un antivirus et un antimalware typique : il recherche des modèles connus dans le flux de données et le bloque lorsqu’il détecte une requête malveillante.
Pour être efficace, le WAF doit avoir sa base de données constamment mise à jour avec de nouveaux modèles de menaces, afin de pouvoir les bloquer. Le problème avec la prévention des attaques basée sur des modèles est que votre application Web peut être l’une des premières cibles d’une nouvelle menace dont votre WAF n’est pas encore conscient.
Pour ces raisons, votre application Web a besoin de couches de protection supplémentaires en plus du pare-feu réseau.
Rechercher les vulnérabilités spécifiques au Web
Encore une fois, ne pensez pas que votre serveur d’applications Web est sans vulnérabilité simplement parce que votre analyseur de sécurité réseau le dit.
Les analyseurs de réseau ne peuvent pas détecter les vulnérabilités spécifiques à l’application. Pour détecter et éliminer ces vulnérabilités, vous devez soumettre les applications à une série de tests et d’audits, tels que des tests d’intrusion, l’analyse de la boîte noire et l’audit du code source. Cependant, aucune de ces méthodes n’est à l’épreuve des balles. Idéalement, vous devriez en effectuer autant que possible pour éliminer toutes les vulnérabilités.
Par exemple, les scanners de sécurité, comme Invicti, assurez-vous qu’aucun code exploitable n’atteint l’environnement de production. Mais il pourrait y avoir des vulnérabilités logiques qui ne peuvent être détectées que par un audit manuel du code. L’audit manuel, en plus de coûter cher, est une méthode humaine et donc sujette aux erreurs. Une bonne idée pour faire ce type d’audit sans gaspiller beaucoup d’argent est de l’intégrer dans le processus de développement, principalement en éduquant vos développeurs.
Formez vos développeurs
Les développeurs ont tendance à penser que leurs applications fonctionnent dans des mondes idéaux, où les ressources sont illimitées, les utilisateurs ne font pas d’erreurs et il n’y a pas de personnes aux intentions impitoyables. Malheureusement, à un moment donné, ils doivent faire face à des problèmes du monde réel, en particulier ceux concernant la sécurité de l’information.
Lors du développement d’applications Web, les codeurs doivent connaître et mettre en œuvre des mécanismes de sécurité pour s’assurer qu’ils sont exempts de vulnérabilités. Ces mécanismes de sécurité doivent faire partie du guide des meilleures pratiques auquel l’équipe de développement doit se conformer.
L’audit de la qualité des logiciels est utilisé pour garantir la conformité aux meilleures pratiques. Les meilleures pratiques et l’audit sont les seuls moyens de détecter les vulnérabilités logiques, telles que (par exemple) le passage de paramètres non chiffrés et visibles à l’intérieur d’une URL, qu’un attaquant pourrait facilement modifier pour faire ce qu’il veut.
Désactiver les fonctionnalités inutiles
En supposant que les applications Web sont aussi exemptes d’erreurs que possible et que la ferme Web est sécurisée, voyons ce qui peut être fait sur le serveur lui-même pour le protéger des attaques.
Un conseil de base et de bon sens consiste à réduire le nombre de points d’entrée potentiellement vulnérables. Si des attaquants peuvent exploiter l’un des composants du serveur Web, l’ensemble du serveur Web pourrait être en danger.
Faites une liste de tous les ports ouverts et des services ou démons en cours d’exécution sur votre serveur et fermez, désactivez ou éteignez ceux qui ne sont pas nécessaires. Le serveur ne doit pas être utilisé à d’autres fins que l’exécution de vos applications Web. Pensez donc à déplacer toutes les fonctionnalités supplémentaires vers d’autres serveurs de votre réseau.
Utiliser des environnements distincts pour le développement, les tests et la production
Les développeurs et les testeurs ont besoin de privilèges sur les environnements sur lesquels ils travaillent qu’ils ne devraient pas avoir sur le serveur d’applications en direct. Même si vous leur faites aveuglément confiance, leurs mots de passe pourraient facilement fuir et tomber entre des mains indésirables.
Outre les mots de passe et les privilèges, dans les environnements de développement et de test, il existe généralement des portes dérobées, des fichiers journaux, du code source ou d’autres informations de débogage susceptibles d’exposer des données sensibles, telles que les noms d’utilisateur et les mots de passe de la base de données. Le processus de déploiement de l’application Web doit être effectué par un administrateur, qui doit s’assurer qu’aucune information sensible n’est exposée après l’installation de l’application sur le serveur en direct.
Le même concept de ségrégation doit être appliqué aux données de l’application. Les testeurs et les développeurs préfèrent toujours travailler avec des données réelles, mais ce n’est pas une bonne idée de leur accorder l’accès à la base de données de production, ou même à une copie de celle-ci. Outre les problèmes de confidentialité évidents, la base de données peut contenir des paramètres de configuration qui révèlent les paramètres internes du serveur, tels que les adresses de points de terminaison ou les noms de chemin, pour n’en nommer que quelques-uns.
Gardez votre logiciel serveur à jour
Aussi évident que cela puisse paraître, c’est l’une des tâches les plus négligées. SUCURI a découvert que 59 % des applications CMS étaient obsolètes, ce qui présente des risques.
De nouvelles menaces apparaissent chaque jour, et la seule façon de les empêcher de mettre en péril votre serveur est de toujours installer les derniers correctifs de sécurité.
Nous avons mentionné précédemment que les pare-feu réseau et les scanners de sécurité réseau ne suffisent pas à empêcher les attaques sur les applications Web. Mais ils sont nécessaires pour protéger votre serveur contre les menaces de cybersécurité courantes, comme les attaques DDoS. Assurez-vous donc que ces applications sont toujours à jour et qu’elles protègent efficacement votre application métier.
Restreindre l’accès et les privilèges
Une mesure de sécurité de base consiste à maintenir le trafic d’accès à distance, tel que RDP et SSH, chiffré et tunnellisé. C’est également une bonne idée de conserver une liste réduite d’adresses IP à partir desquelles l’accès à distance est autorisé, en s’assurant que toute tentative de connexion à distance à partir de toute autre adresse IP est bloquée.
Les administrateurs accordent parfois aux comptes de service tous les privilèges possibles car ils savent que, ce faisant, « tout fonctionnera ». Mais ce n’est pas une bonne pratique car les attaquants peuvent utiliser les vulnérabilités des services pour pénétrer le serveur. Si ces services s’exécutent avec des privilèges d’administrateur, ils peuvent s’emparer de l’ensemble du serveur.
Un bon équilibre entre sécurité et praticité nécessite que chaque compte – à la fois les comptes de connexion et les comptes de service – dispose des privilèges dont il a besoin pour effectuer son travail, et rien d’autre.
Par exemple, vous pouvez définir différents comptes pour qu’un administrateur effectue différentes tâches : un pour effectuer des sauvegardes, un autre pour nettoyer les fichiers journaux, d’autres pour modifier la configuration des services, etc. Il en va de même pour les comptes de base de données : une application n’a généralement besoin que des autorisations pour lire et écrire des données, et non pour créer ou supprimer des tables. Par conséquent, il doit s’exécuter avec un compte avec des privilèges limités pour effectuer les tâches qu’il doit effectuer.
Gardez un œil sur les journaux du serveur
Les fichiers journaux sont là pour une raison.
Les administrateurs doivent les surveiller régulièrement pour détecter tout comportement suspect avant qu’il ne cause des dommages. En analysant les fichiers journaux, vous pouvez découvrir de nombreuses informations pour vous aider à mieux protéger l’application. Si une attaque devait se produire, les fichiers journaux pourraient vous montrer quand et comment elle a commencé, aidant ainsi à mieux contrôler les dégâts.
Vous devez également disposer d’une procédure automatisée pour supprimer les anciens fichiers journaux ou pour élaguer les informations obsolètes, afin d’éviter qu’elles ne consomment tout l’espace de stockage disponible sur le serveur.
Astuce bonus : tenez-vous informé
Il existe de nombreuses informations gratuites et utiles sur Internet que vous pouvez utiliser au profit de votre application Web. Ne manquez aucun nouveau message sur des blogs de sécurité réputés (comme celui-ci) et restez informé de ce qui se passe dans l’industrie de la sécurité et du Web.
Tutoriels, cours, vidéos et livres sont également des sources de connaissances utiles. Entraînez-vous à passer une ou deux heures par semaine juste pour rester informé des nouvelles de l’industrie – Cela vous donnera la tranquillité d’esprit de savoir que vous faites ce qu’il faut pour assurer la sécurité de vos applications.