Tout au long de l'histoire, d'innombrables échecs ont été provoqués par des planificateurs trop confiants dans la qualité de leurs solutions. Qu'il s'agisse de l'insubmersible Titanic ou de l'imprenable ligne Maginot de la Seconde Guerre mondiale, le fait d'accorder trop de confiance à une seule solution a provoqué de terribles catastrophes à maintes reprises.
Il en va de même dans le monde de la cybersécurité. Si vous n'avez qu'une seule solution de défense en matière de cybersécurité, vous vous exposez à des problèmes.
Les dangers d'une solution unique en matière de sécurité
Dans cet article, nous examinerons un cas particulier où cela s'est produit avec un fournisseur de commerce électronique. Cette entreprise a créé une nouvelle API de connexion pour son application mobile. Elle a renforcé sa sécurité en exigeant le cryptage RSA 1024 bits du mot de passe dans la charge utile de toute demande d'authentification.
C'est une bonne idée. Après tout, elle rend les attaques de type "man-in-the-middle" pratiquement inutiles puisque les informations d'authentification ne seraient pas lisibles par l'homme. Elles apparaissent sous la forme d'une chaîne de caractères codée en base64 et codée en RSA. Étant donné que les demandes d'authentification provenaient de leur propre application, il s'agissait d'une bonne approche. Le pouce en l'air.
Mais... il y a plus que cela. Ce qui n'était pas une bonne idée, c'était de penser que cette mesure de sécurité était tout ce dont ils avaient besoin. Au lieu de continuer à améliorer la sécurité avec des mesures telles que l'application d'un nombre maximum de tentatives de mots de passe infructueuses, ils ont décidé de l'expédier, puis de passer à d'autres travaux de développement.
Bien que tout semble aller pour le mieux, il y avait une faille importante dans leur solution. La clé publique de 1024 bits était facilement observable en utilisant JADX pour décompiler leur application mobile.
En sauvegardant la clé publique dans un fichier local, un attaquant peut faire défiler tous les mots de passe qu'il souhaite, en les chiffrant tous selon la clé publique de la cible et en annulant complètement le travail de sécurisation du point final d'authentification en premier lieu.
Comme il n'y avait pas de limite maximale de tentatives d'échec de mot de passe sur ce point de terminaison, j'ai écrit un script bash qui automatiserait une vérification sur autant de mots de passe que je le souhaitais. J'ai prouvé le problème à ce fournisseur de commerce électronique avec un simple compte à rebours jusqu'à mon mot de passe que j'avais mis en place pour démontrer le problème :
#!/bin/bash |
Voici le résultat de mon script :
Welcome 10 |
Voyons ce qu'il en est. Dans un for Je commence par un message de bienvenue annonçant le chiffre que j'insère pour tenter d'obtenir le mot de passe que j'ai défini pour cette démonstration de faisabilité. Ensuite, nous voyons le mot de passe et la valeur cryptée qui sera envoyée à l'API. (Vous ne pensiez tout de même pas que j'allais utiliser un mot de passe aussi simple, et encore moins le révéler ici, n'est-ce pas ?)
Enfin, j'affiche la réponse de l'API à ma vérification de mot de passe. Pour les six premières tentatives, j'obtiens une réponse infructueuse, mais lorsque j'arrive enfin à mon mot de passe hyper-sécurisé (😉 ) de faster4wardL'API me laisse entrer avec mon périmètre d'autorisation normal.
Voilà pour les charges utiles d'authentification cryptées RSA.
Comment éviter ce type d'erreur ?
Maintenant que nous avons identifié le problème, que pouvons-nous faire à la place ? Commençons par l'erreur fondamentale qui nous a conduits à cette situation. Il y a beaucoup de choses à faire pour sécuriser avec succès une application web, car il n'y a pas de solution miracle pour sécuriser une application ! Pour notre exemple spécifique ci-dessus, vous devez mettre en place d'autres mesures en plus du cryptage RSA fort.
- Assurez-vous que vos clés de chiffrement sont sécurisées.
- Appliquer un nombre maximum de tentatives de vérification du mot de passe qui échouent, ce qui entraîne le blocage du compte.
- Mettre en œuvre la limitation du débit des requêtes.
La sécurité d'un système exposé à l'internet doit s'appuyer sur le principe de la défense en profondeur : De multiples couches de défense doivent être déployées sur toute la surface de votre présence sur le web, et pas seulement sur les points que vous jugez les plus intéressants ou les plus évidents à défendre.
Heureusement, Linode offre de nombreuses fonctionnalités de sécurité intégrées à notre plateforme, et il existe de nombreuses normes industrielles pour s'attaquer à certains vecteurs d'attaque courants. Certaines de ces solutions s'appliquent à votre compte Linode, et d'autres s'appliquent directement à vos Linodes. Examinons les deux types de protection.
Protéger l'accès administrateur à votre compte Linode
Si quelqu'un peut accéder à votre compte Linode, c'est la fin de la partie. Pénétrer dans vos Linodes devient trivial. C'est pourquoi les comptes Linode sont construits avec la sécurité à l'esprit. Par défaut, chaque compte Linode doit être sécurisé par une vérification téléphonique. Linode exige également la configuration de questions et réponses de sécurité à des fins de récupération de compte.
Outre la vérification par téléphone, vous pouvez également configurer l'authentification à deux facteurs à l'aide d'un code d'authentification TOTP (mot de passe à usage unique basé sur le temps). Bien que cela ne soit pas obligatoire pour les comptes, il est fortement recommandé d'activer l'authentification à deux facteurs, car elle est beaucoup plus sûre qu'un simple mot de passe et des questions de sécurité, et encore plus sûre que les codes de vérification par téléphone.
Il existe un autre niveau de sécurité qui permet d'éviter complètement l'utilisation d'un mot de passe Linode. Vous pouvez utiliser une source d'authentification tierce (TPA). En utilisant cette méthode, vous pouvez configurer des méthodes sécurisées de connexion sur la source tierce de votre choix (pour l'instant, Google et GitHub sont pris en charge). Cela réduit les risques qu'une fuite de mot de passe vous fasse perdre l'accès à votre compte Linode.
Une dernière méthode pour protéger votre compte consiste à définir des utilisateurs spécifiques qui peuvent accéder à des parties spécifiques de votre compte. Cela vous permettra de définir certaines autorisations concernant ce que les sous-utilisateurs peuvent faire sur votre compte, réduisant ainsi encore davantage la possibilité qu'un pirate cause des dommages irréparables à votre compte.
L'introduction de cette séparation des préoccupations entre les utilisateurs accédant aux différentes parties de votre infrastructure est une bonne pratique. Bien entendu, si vous n'êtes qu'une seule équipe, cela n'est peut-être pas nécessaire. Néanmoins, si vous disposez d'une véritable séparation des préoccupations, cela vous permettra de vous assurer que des modifications non autorisées ne sont pas apportées à votre compte ou à votre infrastructure.
Sécurisez vos Linodes
Sécuriser votre compte est certes important, mais sécuriser vos serveurs et votre infrastructure l'est peut-être encore plus. Après tout, la plupart des attaquants essaieront d'entrer dans votre infrastructure par le biais de l'infrastructure plutôt que par le biais de votre fournisseur d'hébergement. Linode vous couvre ici aussi.
L'un des meilleurs endroits pour commencer est l'application Linode Marketplace. Que vous ayez besoin de déployer des solutions de sécurité comme Haltdos WAF pour arrêter le trafic malveillant aux portes de vos serveurs ou que vous souhaitiez installer en un clic une pile de surveillance comme une configurationPrometheus + Grafana , il n'y a rien de plus facile pour sécuriser et surveiller votre pile que l'application Marketplace.
Les applications tierces ne sont pas les seules solutions à votre disposition. Linode Cloud Firewall est une excellente solution qui est facilement configurée directement à partir du Cloud Manager. Utiliser à la fois Linode Cloud Firewall et un pare-feu sur votre Linode est également une bonne idée.
Une autre bonne pratique consiste à s'assurer que vos serveurs sont protégés contre les attaques DDoS. Avec Linode, vous défendez par défaut l'ensemble de votre infrastructure contre ces attaques, et ce gratuitement ! Vous n'avez même pas besoin de faire quoi que ce soit pour le configurer.
Conclusion
Il y a encore beaucoup à dire sur la sécurité, mais cela suffit pour l'instant. En résumé, évitez que votre solution intelligente à un problème ne vous fasse oublier les autres éléments qui pourraient manquer dans votre approche de la sécurité.
Commentaires