Plateformes et cloud
Comment une application est protégée des scans automatisés
Une application est protégée des scans automatisés par couches - un filtre placé devant elle qui arrête les requêtes nuisibles, des limites sur la vitesse d'envoi d'un visiteur, un contrôle régulier des journaux et une application qui vérifie tout ce qu'elle reçoit.
Si vous gérez une application sur Internet, quelqu'un la teste chaque jour, même si vous ne le voyez pas. Nous expliquons ici simplement ce que ces outils cherchent et comment fonctionne chaque mesure de protection. Vous saurez ainsi quelles questions poser quand vous parlez de sécurité avec votre équipe.
Qu'est-ce qu'un scan automatisé ?
Un scan automatisé est un programme qui visite des adresses en masse et pose la même question à chacune : y a-t-il ici un fichier oublié, une ancienne page d'administration, une faille connue ? Il ne sait pas qui vous êtes. Il sait seulement que l'adresse existe. Ce test ne coûte presque rien à celui qui le lance. C'est pourquoi tout site public le reçoit.
L'OWASP, la communauté ouverte de sécurité, le décrit comme un usage automatisé indésirable qui se poursuit « jour après jour ». Elle note aussi qu'il détourne souvent des fonctions normales d'une application, et non un élément défaillant. Cela correspond à ce que montrent les journaux d'un serveur. Une nouvelle application peut être testée peu après sa mise en ligne, bien avant que son public ne la connaisse.
La bonne question est donc : « que se passe-t-il quand on nous scanne ? ». Pour un simple site d'entreprise, la réponse est souvent : « rien d'important ». Pour une plateforme qui contient des données clients, une protection pensée dès le départ vaut la peine.
Que cherchent les scanners ?
Les scanners cherchent des erreurs assez courantes pour que l'essai vaille la peine. Leurs requêtes sont simples et répétitives, donc faciles à reconnaître. Le tableau montre des cibles typiques et ce que le scanner espère trouver pour chacune. C'est une liste que tout scanner parcourt, quel que soit le sujet du site.
Ce que le scanner demande | Ce qu'il espère trouver |
|---|---|
Un fichier nommé `.env` | Des mots de passe et des clés laissés dans un fichier de configuration |
Un dossier `.git` | Une copie du code source avec son historique |
`node_modules` et dossiers semblables | Des détails sur les versions de logiciels utilisées |
phpMyAdmin et d'autres pages d'administration | Une console de base de données avec un mot de passe faible |
Des pages en `.php`, sur un site sans PHP | D'anciennes failles connues dans un logiciel qui n'existe pas |
Des caractères étranges dans les formulaires et les adresses | Une application qui transmet tout ce qu'elle reçoit sans le vérifier |
Dans une application bien construite, ces fichiers n'existent pas, donc aucune de ces requêtes n'aboutit. Le problème, c'est le volume. Des milliers de requêtes de ce genre remplissent les journaux, consomment des ressources et cachent la seule requête qui compte. Quand on les arrête tôt, le tableau reste net.
En quoi un filtre placé devant l'application aide-t-il ?
Un filtre placé devant l'application examine chaque requête et arrête les nuisibles avant qu'elles ne l'atteignent. Sur AWS, c'est AWS WAF, un pare-feu applicatif web. En termes simples, c'est un filtre qui arrête le trafic nuisible selon des règles que vous définissez.
AWS le décrit comme un service qui surveille les requêtes HTTP et HTTPS envoyées aux ressources protégées. Il contrôle l'accès selon des critères comme l'adresse IP d'origine ou les valeurs dans l'adresse URL. Quand une requête correspond à une règle de blocage, elle reçoit une réponse HTTP 403, c'est-à-dire « interdit », ou une réponse personnalisée.
Nous pouvons écrire les règles nous-mêmes. Il existe aussi des groupes de règles prêts à l'emploi, entretenus par AWS. Dans l'infrastructure décrite dans l'étude de cas d'une plateforme de santé aux États-Unis, le filtre comptait 23 règles : des limites de requêtes par visiteur, des restrictions géographiques, des groupes prêts à l'emploi pour les mauvaises entrées courantes, des blocages explicites pour les requêtes qui demandent `.env`, `.git`, phpMyAdmin ou des fichiers PHP.
Comment ralentit-on les scanners tenaces ?
On ralentit les scanners tenaces avec deux mécanismes qui travaillent ensemble. Une règle fondée sur le débit compte les requêtes et limite celles qui arrivent trop vite. Un petit script automatique lit ensuite les journaux, repère ceux qui continuent à scanner et les bloque plus longtemps à chaque retour. Le premier gère les rafales, le second l'obstination.
AWS décrit le premier comme une règle qui compte les requêtes entrantes, les regroupe selon les critères de votre choix et applique une action quand un visiteur dépasse la limite dans la fenêtre de temps. Une personne qui navigue n'approche jamais une telle limite. Un scanner qui envoie des centaines de requêtes par minute l'atteint tout de suite.
Pour le second mécanisme, nous utilisons AWS Lambda. Il exécute du code en réponse à des événements ou selon un calendrier, sans que nous ayons à gérer de serveurs. Dans l'étude de cas citée, un script Python tournait toutes les trois minutes, repérait les scanners dans les journaux et les bloquait pour une durée croissante. La progression compte : la première infraction entraîne un blocage court, l'obstination un blocage plus long. Un blocage injustifié expire vite de lui-même.
Voici la marche à suivre pour un tel système :
Nous définissons ce qui est légitime. Nous listons les chemins réels, les méthodes et les pays d'où viennent vos utilisateurs.
Nous ajoutons les groupes de règles prêts à l'emploi. Ils couvrent des mauvaises entrées largement connues, sans que nous écrivions chaque motif.
Nous ajoutons des blocages explicites pour les fichiers et les pages que votre application ne sert jamais.
Nous ajoutons une limite de débit par visiteur, avec des exceptions seulement pour les rares points qui reçoivent légitimement beaucoup de requêtes, comme l'inscription.
Nous lançons le contrôle des journaux selon un calendrier, pour que les visiteurs récidivistes reçoivent des blocages plus longs.
Nous relisons les journaux chaque semaine au début, pour repérer les utilisateurs légitimes bloqués par erreur.
Comment voit-on ce qui se passe ?
On le voit en lisant les journaux, organisés à l'avance pour être faciles à lire. Amazon CloudWatch Logs Insights permet de chercher et d'analyser les journaux avec des requêtes. Nous préparons des requêtes enregistrées pour les questions habituelles : quelles requêtes ont renvoyé des erreurs 4xx ou 5xx, quels visiteurs ont été redirigés, quelles adresses paraissent suspectes, ce que le filtre a bloqué.
La documentation d'AWS précise que les requêtes peuvent être enregistrées, relancées et placées dans des tableaux de bord. Une enquête ponctuelle devient ainsi une routine. Un filtre a besoin d'un coup d'œil régulier pour rester à jour. Une requête enregistrée « requêtes bloquées cette semaine » se lit en une minute. Elle montre si les règles correspondent encore au trafic réel.
Les journaux répondent aussi aux questions après coup. Si un client dit « hier, je n'ai pas pu me connecter », vous voyez si le filtre l'a bloqué et pourquoi. Vous corrigez ensuite la règle à partir des faits.
Que doit faire l'application elle-même ?
L'application doit vérifier côté serveur tout ce qu'elle reçoit, quoi qu'ait laissé passer le filtre. Le filtre ne connaît pas les règles de votre entreprise. La fiche Input Validation de l'OWASP recommande de n'accepter que ce qui est prévu pour chaque champ, au lieu de lister chaque chaîne nuisible.
Le même guide explique que les contrôles faits dans le navigateur se contournent facilement. Ils servent à donner un retour immédiat à l'utilisateur, et le serveur doit les refaire. C'est pourquoi le filtre n'est qu'une couche de la protection. L'OWASP Top 10, la liste la plus connue des risques les plus critiques pour les applications web, décrit des risques liés à la façon dont les applications sont construites. Seule une bonne conception de l'application les résout, aucun pare-feu n'y suffit.
D'autres bonnes pratiques en font partie : des logiciels à jour, pour chaque utilisateur seulement l'accès dont il a besoin, des secrets stockés hors du code. Cela fait partie de notre façon de construire. Le côté infrastructure, c'est-à-dire le filtre, les journaux et les réglages d'accès, relève du service d'infrastructure sur AWS.
Où faut-il d'autres couches ?
Il faut d'autres couches pour tout ce qui échappe aux scans en masse. Le filtre ne corrige pas les erreurs dans le code, ni ne reconnaît un mot de passe volé. Il ne juge pas non plus une requête d'apparence tout à fait normale mais faite avec une mauvaise intention. Les attaques ciblées demandent leur propre protection.
Chaque couche a son travail. AWS GuardDuty, par exemple, est un service de détection des menaces. Il surveille l'activité et les journaux de votre compte AWS pour repérer des signes de comportement inhabituel. Les sauvegardes, le contrôle d'accès et un plan indiquant qui agit quand une alerte arrive comptent autant que chaque règle.
Ce que vous gagnez avec cette organisation est concret : l'essentiel du trafic automatisé s'arrête à faible coût, les journaux restent lisibles, les tentatives sérieuses, plus rares, se voient mieux. Si vous préparez une plateforme et voulez cette protection dès le départ, décrivez-la dans une demande de projet.
Questions fréquentes: Comment une application est protégée des scans automatisés
Un pare-feu ralentit-il l'application ?
Le filtre ajoute à chaque requête un petit contrôle que les visiteurs ne remarquent normalement pas. Chaque règle ajoute de la complexité, donc nous gardons peu de règles, et utiles. Nous testons l'ensemble avec des schémas de trafic réalistes avant de nous y fier.
Un utilisateur peut-il être bloqué par erreur ?
Oui, c'est pourquoi nous le prévoyons dès le départ. Les limites de débit se placent au-dessus du comportement humain normal. Les points qui reçoivent beaucoup de requêtes ont des exceptions, et les blocages du script expirent. Les premières semaines, nous contrôlons régulièrement ceux qui ont été bloqués.
Cette protection est-elle utile aux petits sites ?
Un simple site d'entreprise sans comptes utilisateurs ni données clients stockées présente un risque plus faible. Une installation plus légère lui suffit en général. Cette approche apporte le plus aux applications avec des comptes, des formulaires qui enregistrent des données ou des fichiers privés.
Qui s'en occupe après la livraison ?
Le compte AWS et ses réglages restent chez le client. Les règles et les scripts sont documentés, pour que nous ou n'importe qui d'autre puissions les entretenir. Pendant le projet, nous convenons de la surveillance qui se poursuit après la livraison.
Est-ce la même chose qu'un audit de sécurité annuel ?
Non. Les couches décrites ici fonctionnent en continu et gèrent le trafic automatisé de tous les jours. Un test de sécurité indépendant de l'application est un travail distinct, avec un autre but. Les deux se complètent.