Comment ELK aide les ingénieurs en sécurité à lutter contre les attaques de sites Web et à bien dormir

Notre Cyber ​​Defense Center est chargé de sécuriser l'infrastructure Web des clients et de repousser les attaques sur les sites clients. Nous utilisons les pare-feu d'applications Web (WAF) FortiWeb pour nous défendre contre les attaques. Mais même le WAF le plus cool n'est pas une panacée et ne protège pas «hors de la boîte» d'attaques ciblées. 



Par conséquent, en plus de WAF, nous utilisons ELK . Il permet de rassembler tous les événements en un seul endroit, accumule des statistiques, les visualise et nous permet de voir l'attaque ciblée dans le temps.



Aujourd'hui je vais vous raconter plus en détail comment nous avons traversé le «sapin de Noël» avec WAF et ce qui en est issu.









L'histoire d'une attaque: comment tout fonctionnait avant de passer à ELK

Dans notre cloud, le client a déployé l'application derrière notre WAF. De 10 000 à 100 000 utilisateurs connectés au site par jour, le nombre de connexions atteint 20 millions par jour. 3 à 5 d'entre eux étaient des cybercriminels et ont tenté de pirater le site. 



FortiWeb a bloqué assez facilement une forme de force brute régulière à partir d'une adresse IP. Le nombre de visites du site par minute était supérieur à celui des utilisateurs légitimes. Nous avons simplement mis en place des seuils d'activité à partir d'une adresse et repoussé l'attaque.



Il est beaucoup plus difficile de gérer les «attaques lentes» lorsque les attaquants agissent lentement et se déguisent en clients réguliers. Ils utilisent de nombreuses adresses IP uniques. Une telle activité ne ressemblait pas à une force brute massive pour WAF, il était plus difficile de la suivre automatiquement. Il y avait également un risque de blocage des utilisateurs normaux. Nous avons recherché d'autres signes d'attaque et mis en place une politique pour bloquer automatiquement les adresses IP en fonction de cet attribut. Par exemple, de nombreuses sessions illégitimes avaient des champs communs dans les en-têtes de requête http. J'ai souvent dû rechercher manuellement de tels champs dans les journaux d'événements FortiWeb. 



Cela s'est avéré long et peu pratique. Dans la fonctionnalité standard de FortiWeb, les événements sont enregistrés sous forme de texte dans 3 journaux différents: attaques détectées, informations sur les demandes et messages système sur le fonctionnement du WAF. Des dizaines, voire des centaines d'événements d'attaque peuvent survenir en une minute.



Pas tellement, mais vous devez parcourir manuellement plusieurs journaux et parcourir plusieurs lignes: 





dans le journal des attaques, nous voyons les adresses des utilisateurs et la nature de l'activité. 

 

Il ne suffit pas d'analyser simplement la table du journal. Pour trouver les informations les plus intéressantes et les plus utiles sur la nature d'une attaque, vous devez regarder à l'intérieur d'un événement spécifique: Les





champs en surbrillance aident à détecter une "attaque lente". Source: capture d'écran du site Web de Fortinet



Eh bien, le problème le plus important est que seul un spécialiste FortiWeb peut le comprendre. Si, pendant les heures de travail, nous pouvions encore surveiller les activités suspectes en temps réel, l'enquête sur les incidents de nuit pourrait être retardée. Lorsque les politiques de FortiWeb pour une raison quelconque ne fonctionnaient pas, les ingénieurs de nuit en service ne pouvaient pas évaluer la situation sans avoir accès au WAF et ont réveillé le spécialiste de FortiWeb. Nous avons parcouru les journaux pendant plusieurs heures et avons trouvé le moment de l'attaque. 



Avec de tels volumes d'informations, il est difficile de comprendre la situation dans son ensemble et d'agir de manière proactive. Ensuite, nous avons décidé de collecter des données en un seul endroit afin de tout analyser sous une forme visuelle, trouver le début de l'attaque, identifier sa direction et sa méthode de blocage. 



De quoi avez-vous choisi



Tout d'abord, nous nous sommes penchés sur les solutions déjà utilisées pour ne pas multiplier inutilement les entités. L'



une des premières options était Nagios , que nous utilisons pour surveiller l' infrastructure d'ingénierie , infrastructure réseau et alerte sur les situations d'urgence. Les agents de sécurité l'utilisent également pour avertir les préposés en cas de trafic suspect, mais il ne sait pas comment collecter des journaux dispersés et disparaît donc. 



Il y avait une option pour tout agréger en utilisant MySQL et PostgreSQL ou une autre base de données relationnelle. Mais pour extraire les données, vous deviez sculpter votre application. 



Notre société utilise également FortiAnalyzer comme collecteur de journaux .de Fortinet. Mais dans ce cas, il ne correspondait pas non plus. Premièrement, il est plus adapté pour fonctionner avec le pare-feu FortiGate . Deuxièmement, de nombreux paramètres faisaient défaut et leur interaction nécessitait une excellente connaissance des requêtes SQL. Et troisièmement, son utilisation augmenterait le coût du service pour le client.   



C'est ainsi que nous sommes arrivés à l'open source en la personne d' ELK



Pourquoi choisir ELK 



ELK est un progiciel open source:



  • Elasticsearch est une base de données de séries chronologiques qui vient d'être créée pour travailler avec de grandes quantités de texte;

  • Logstash est un moteur de collecte de données qui peut convertir les journaux au format souhaité; 

  • Kibana est un bon visualiseur ainsi qu'une interface assez conviviale pour gérer Elasticsearch. Vous pouvez l'utiliser pour créer des graphiques qui peuvent être visionnés par les ingénieurs en service la nuit. 



Le seuil d'entrée ELK n'est pas élevé. Toutes les fonctionnalités de base sont gratuites. Que faut-il d'autre pour le bonheur.



Comment avez-vous tout mis en un seul système?



Nous avons formé des indices et n'avons laissé que les informations nécessaires . Nous avons chargé les trois magazines FortiWEB dans ELK - le résultat était des index. Ce sont des fichiers avec tous les journaux collectés pendant une période, par exemple, une journée. Si on les visualisait immédiatement, on ne verrait que la dynamique des attaques. Pour plus de détails, vous devez «tomber» dans chaque attaque et regarder des champs spécifiques.







Nous avons réalisé que nous devons d'abord configurer l'analyse des informations non structurées. Nous avons pris de longs champs sous forme de chaînes comme «Message» et «URL» et les avons analysés pour obtenir plus d'informations pour la prise de décision. 

, .   - . , 2 . 


Après analyse, ils ont commencé à chercher quelles informations stocker et visualiser. Il n'était pas conseillé de tout laisser dans le journal: la taille d'un index était grande - 7 Go. ELK a mis du temps à traiter le dossier. Cela dit, toutes les informations n'étaient pas utiles. Quelque chose a été dupliqué et a pris de l'espace supplémentaire - il était nécessaire d'optimiser. 



Au début, nous avons simplement parcouru l'index et supprimé les événements inutiles. Cela s'est avéré être encore plus gênant et plus long que de travailler avec des magazines sur FortiWeb lui-même. Le seul avantage du "sapin de Noël" à ce stade est que nous avons pu visualiser une longue période de temps sur un seul écran. 



On n'a pas désespéré, on a continué à manger le cactusétudie ELK et pensait que nous serions en mesure d'extraire les informations nécessaires. Après avoir effacé les indices, nous avons commencé à visualiser ce qui est. C'est ainsi que nous nous sommes retrouvés avec de grands tableaux de bord. Widgets piqués - clairement et élégamment, un vrai YOLKa! 







Le moment de l'attaque a été enregistré . Il fallait maintenant comprendre à quoi ressemble le début de l'attaque sur le graphique. Pour le trouver, nous avons regardé les réponses du serveur à l'utilisateur (codes retour). Nous nous sommes intéressés aux réponses du serveur avec les codes suivants (rc): 



Code (rc)

Nom

La description

0

LAISSEZ TOMBER

La demande du serveur est bloquée

200

D'accord

Demande traitée avec succès

400

Mauvaise Demande

Mauvaise Demande

403

Interdit

Autorisation refusée

500

Erreur Interne du Serveur

Le service est indisponible





Si quelqu'un a commencé à attaquer le site, le ratio de codes a changé: 



  • 400 , 200 , - . 

  • 0 , FortiWeb «» . 

  • 500, IP- – . 



Au troisième mois, nous avons mis en place un tableau de bord pour suivre cette activité.







Afin de ne pas tout surveiller manuellement, nous avons mis en place une intégration avec Nagios, qui interroge ELK à intervalles réguliers. S'il enregistrait l'atteinte des valeurs seuils par des codes, il envoyait une notification aux agents de service concernant une activité suspecte. 



Combiné 4 graphiques dans le système de surveillance . Maintenant, il était important de voir sur les graphiques le moment où l'attaque n'est pas bloquée et l'intervention de l'ingénieur est nécessaire. Sur 4 graphiques différents, notre œil était flou. Par conséquent, nous avons combiné les graphiques et avons commencé à tout observer sur un seul écran.



Au cours de la surveillance, nous avons observé comment les graphiques de différentes couleurs ont changé. Une touche de rouge indiquait que l'attaque avait commencé, tandis que les graphiques orange et bleu indiquaient la réaction de FortiWeb:





Tout va bien ici: il y a eu une explosion d'activité "rouge", mais FortiWeb a fait face et le calendrier d'attaque s'est avéré nul.



Nous avons également dessiné un exemple de graphique pour nous-mêmes qui nécessite une intervention:





Ici, nous voyons que FortiWeb a augmenté l'activité, mais le graphique d'attaque rouge n'a pas diminué. Vous devez modifier les paramètres WAF.



Les enquêtes sur les incidents nocturnes sont également devenues plus faciles. Le graphique montre immédiatement le moment où il est temps de venir à la défense du site. 





C'est ce qui arrive parfois la nuit. Graphique rouge - l'attaque a commencé. Bleu - Activité FortiWeb. L'attaque n'a pas été complètement bloquée, nous avons donc dû intervenir.



Où allons-nous



Nous formons maintenant les administrateurs en service à travailler avec ELK. Les préposés apprennent à évaluer la situation sur le tableau de bord et à prendre une décision: il est temps de faire appel à un spécialiste FortiWeb, sinon il y aura suffisamment de politiques WAF pour repousser automatiquement une attaque. De cette façon, nous réduisons la charge de travail des ingénieurs en sécurité de l'information la nuit et divisons les rôles de support au niveau du système. L'accès à FortiWeb reste uniquement au centre de la cyberdéfense, et seulement ils modifient les paramètres WAF en cas de besoin urgent.



Nous travaillons également sur le reporting pour les clients. Nous prévoyons que les données sur la dynamique du travail WAF seront disponibles dans le compte personnel du client. ELK rendra la situation plus transparente sans avoir à se rendre au WAF lui-même.



Si le client souhaite surveiller sa propre protection en temps réel, ELK sera également utile. Nous ne pouvons pas donner accès à WAF, car l'intervention du client dans les travaux peut affecter les autres. Mais vous pouvez élever un ELK séparé et le donner à "jouer". 



Ce sont les scénarios d'utilisation de «l'arbre de Noël» que nous avons accumulé récemment. Partagez vos idées à ce sujet et n'oubliez pas de tout configurer correctement pour éviter les fuites des bases de données. 



All Articles