Et tout le WAF ne suffit pas: comment nous avons amélioré le service de protection du site Web 

salut! Je m'appelle Kirill et au centre de cybersécurité DataLine, je développe un service de protection des applications Web (WAF) : je communique avec les spécialistes de la sécurité de l'information et de l'informatique du client, je connais leurs tâches et je suis responsable du bon fonctionnement du service. En moins d'un an après la mise en place de WAF, je me suis assuré que si vous avez un site Web, il sera attaqué. Et pas toujours ce que vous pensez.



Nous avons affiné la solution plusieurs fois: nous avons mieux étudié les vecteurs d'attaque et le comportement des attaquants, ajouté et configuré de nouvelles défenses, amélioré les règles d'interaction client. Je vais vous expliquer comment notre service s'est développé sur la base de FortiWeb et ce dont vous avez besoin pour protéger votre application Web.    







Contexte du service



Pour nos propres sites, nous avons autrefois choisi FortiWeb de Fortinet, nous connaissions déjà les subtilités de son utilisation. Sous mes yeux se trouvait l'expérience WAF-as-a-service dans le cloud chez Fortinet. 



En Occident, le modèle de libre-service est répandu pour WAF. Le client dispose d'une instance dédiée pour l'auto-configuration dans le cloud souhaité (AWS, Azure et GCP), bien sûr, pas en Fédération de Russie. Ce modèle a ses propres difficultés: 



  • Un spécialiste de la sécurité des informations côté client doit comprendre en profondeur les fonctionnalités de sécurité des applications Web. 

  • Le spécialiste d'un client a besoin de connaître les capacités et les paramètres d'un WAF spécifique afin de créer des profils de protection. De manière amiable, travailler avec WAF nécessite un ingénieur distinct pour constamment modifier les paramètres.  

  • Il doit interagir en permanence avec les développeurs du site et décider quelles vulnérabilités fermer sur le WAF, lesquelles corriger dans le code lui-même. Pourtant, le WAF est une mesure compensatoire, et certains problèmes sont mieux traités au niveau du développement



Les grandes entreprises avec un personnel important peuvent faire face à ces trois points. Nous voulions prendre en compte les demandes des petites entreprises. Ces clients se sont vus proposer un service clé en main géré par nos ingénieurs. Ils ont commencé à le collecter à partir des questions d'architecture. 



Le service a été placé dans un cloud conforme à la norme PCI DSS. Ce certificat est important pour les sites qui utilisent des données de paiement: détaillants, prestataires de services, sociétés de traitement. 





Le service WAF est également entré dans le champ d'application PCI DSS.



La tolérance aux pannes de service a été considérée séparément. Pour FortiWeb, le fournisseur a fourni plusieurs options de cluster. Nous avons testé différentes méthodes de synchronisation de session et choisi le mode Active Backup: une machine virtuelle FortiWeb reste la principale et dépose une partie du trafic vers la seconde. Dans ce cas, lorsqu'un nœud tombe, le service n'est pas disponible pendant plus de 10 secondes. Configuré l'emplacement des machines pour qu'elles montent toujours sur des hôtes différents. 



Ensuite, nous avons résolu le problème de la séparation des clients dans le cloud. FortiWeb ne prend pas en charge la multi-location: nous ne pouvons pas segmenter WAF en domaines, comme nous l'avons faitavec notre NGFW-as-a-Service propulsé par FortiGate. Ce qui reste, c'est la séparation des politiques. Si nous laissons de telles politiques à la merci des clients, il y a un risque d'influencer nos voisins. Par conséquent, nos ingénieurs SI responsables du service créent eux-mêmes des sites clients pour WAF et surveillent les paramètres du service. Et pour les clients, nous fournissons un outil séparé avec des rapports et des statistiques.



Par conséquent, le service lui-même ne se limitait pas uniquement au WAF, nous y avons ajouté: 



  • Scanner de vulnérabilité Qualys,

  • Protection DDoS de Qrator,

  • ELK pour la collecte de statistiques, la visualisation et l'analyse des données.



Je vais vous en dire un peu plus sur chaque composant.



Nous analysons les sites à la recherche de vulnérabilités 



Pour rechercher des vulnérabilités dans le code des sites, nous avons ajouté Qualys, une solution de scan et d'analyse de la sécurité des applications web. Nous avions déjà déployé un service d'analyse des vulnérabilités séparé, il ne restait plus qu'à le configurer pour qu'il fonctionne avec WAF. 



La première fois, nous lançons le scanner avant de configurer le site pour WAF et d'envoyer le rapport aux développeurs d'applications. Ce n'est qu'après cela que nous fermons les vulnérabilités sur WAF qui ne peuvent pas être éliminées au niveau du code.



Ensuite, nous mettons en place une analyse mensuelle et envoyons un rapport au client. Et pour l'avenir, nous testons un schéma où le rapport sera immédiatement téléchargé directement sur FortiWeb. 



Comprendre le nettoyage du trafic



FortiWeb protège bien contre les attaques de la couche application, par exemple: si une application Web est attaquée avec un grand nombre de requêtes GET, DoS-Protection sur WAF aidera. Mais en plus de cela, vous avez besoin d'une solution distincte pour les attaques DDoS en dessous du niveau, par exemple, SYN-flood. Certains clients ont leur propre anti-DDoS, que nous intégrons à notre service WAF. Mais c'est plutôt un cas particulier.



Pour les autres cas, le service dispose de Qrator.Ingress - une solution pour protéger l'infrastructure contre les attaques DDoS. Il protège la liaison L2 à L4, analyse et nettoie le trafic. 



Nous avons créé des interfaces 10 Gigabit avec Qrator pour envoyer du trafic déjà nettoyé vers WAF via un canal sécurisé. Le schéma de service ressemble maintenant à ceci:







L'infrastructure du client peut vivre n'importe où, sur n'importe quel hébergement. Après la mise en place d'un site pour WAF, seul le trafic vérifié par le service est envoyé vers cet hébergement. Voici un schéma simplifié de son fonctionnement:



  1. Nous avons un sous-réseau "blanc" que nous annonçons sur le canal avec Qrator.  

  2. Nous attribuons 1 nouvelle adresse IP au client à partir de ce sous-réseau. 

  3. Sur WAF, nous créons une politique de serveur et des politiques de routage de contenu HTTP pour le site, y ajoutons des noms de domaine et indiquons où les envoyer. 

  4. FortiWEB met fin aux connexions TLS sur lui-même, nous y chargeons donc une chaîne de certificats. 

  5. Ensuite, nous demandons au client de modifier l'enregistrement DNS du site et de spécifier l'adresse IP du réseau Qrator pour les noms de domaine requis. 



Quelle est la ligne de fond? Lorsqu'un utilisateur lance un navigateur et accède à une ressource protégée par WAF, son trafic DNS est d'abord acheminé vers les centres de nettoyage dans Qrator. Ensuite, le trafic est acheminé vers WAF via le canal sécurisé. Et ce n'est qu'après vérification que l'utilisateur a accès au serveur Web du client. Voici le chemin complet: 







Mais même si le site est démarré pour WAF, cela ne signifie pas qu'il est protégé. Vous devez configurer le profil de protection Web - un ensemble de règles et de paramètres de protection pour le site. Cela se fait séparément pour chaque client. 



La situation avec les attaques est telle que vous ne pouvez pas configurer un profil une seule fois et vous ne pouvez pas l'oublier. Par conséquent, nous analysons la situation sur chaque site et améliorons la protection: nous ajoutons de nouveaux mécanismes de sécurité, ajustons le profil pour qu'il n'y ait pas de faux positifs. Pour la configuration initiale, nous utilisons les informations que nous avons reçues du scanner de vulnérabilité Qualys. 



Travailler en équipe: étudier les attaques avec un client



L'administration du service par nos ingénieurs comprend la définition de politiques et, si nécessaire, le blocage manuel des attaques. C'est la responsabilité des spécialistes de FortiWeb qui comprennent les nuances de la protection des sites Web. Mais en même temps, nos ingénieurs ne peuvent pas connaître toute la logique de l'application client. Si nous bloquons immédiatement toute activité suspecte, nous pouvons bloquer accidentellement un utilisateur légitime. Nous travaillons donc en collaboration avec les spécialistes du client et développons une stratégie commune pour repousser les attaques. 



Parmi les clients, il y a des entreprises sans grands départements informatiques et de sécurité de l'information. Le développement d'applications pour eux est souvent effectué par des sous-traitants, il faut donc un certain temps pour corriger les vulnérabilités du code. Sur WAF, vous pouvez proposer des solutions de contournement et neutraliser rapidement les attaques qui se sont produites. Dans ce cas, nous avons élaboré des règlements et prescrit le moment de considérer la situation critique et d'agir immédiatement, et le moment de convenir des serrures avec le client. 



La surveillance en collaboration avec ELK nous aide à suivre les situations critiques. La dernière fois, nous avons déjà parlé de son fonctionnement technique. ELK nous permet de gérer les informations de sécurité sans ajouter un système SIEM (Security Information and Event Management) coûteux au service. 



Sur la surveillance, nous mettons en place des alertes pour une réponse immédiate. La première ligne de support travaille 24 heures sur 24, après notification, évalue immédiatement la situation selon la réglementation et agit à son niveau, ou transfère l'incident aux ingénieurs de sécurité. 



Si le client lui-même est prêt à suivre le travail du WAF, nous lui donnons accès au système d'analyse basé sur ELK. Dans cette solution, nous mettons en place des autorisations pour des index spécifiques. Le client gérera les analyses et les rapports sans influencer le WAF lui-même.



Quel est le résultat et comment il se développera davantage 



En conséquence, nous disposons d'une solution complète de protection des applications Web. En plus de la protection utilisant WAF, nous pouvons configurer l'équilibrage des serveurs Web, la mise en cache, les redirections et, ainsi, décharger le site principal.



Pour l'avenir, nous avons prévu une marge de mise à l'échelle. Pour l'équilibrage, connectons FortiADC, un contrôleur pour la livraison d'applications et l'équilibrage de charge dans des systèmes hautes performances. Il prend en charge le déchargement SSL des serveurs et améliore les performances des applications Web.



Le service est facturé en fonction de la bande passante et convient aux sites peu lourds. Si le client a des gigabits de trafic, nous proposons non pas un service cloud, mais une solution privée. Pour rendre le service transparent pour les clients, nous prévoyons d'afficher les données WAF dans leur compte personnel.



Si vous souhaitez connaître les détails, je serai heureux de répondre à vos questions dans les commentaires. Ou inscrivez -vous au séminaire WAF du 26 novembre - l'occasion de poser des questions non seulement à nous, mais aussi aux spécialistes techniques de Qualys, Fortinet et Qrator.



All Articles