Cas d'utilisation des outils d'analyse d'anomalies réseau: détection des fuites

Lors de l'un des événements, une discussion intéressante s'est ensuivie sur l'utilité des solutions NTA (Network Traffic Analysis) qui, à l'aide de l'infrastructure réseau de télémétrie Netflow (ou d'autres protocoles de flux), permettent de détecter un large éventail d'attaques. Mes adversaires ont fait valoir que lors de l'analyse des en-têtes et des informations connexes (et NTA n'analyse pas le corps des données par paquets, contrairement aux systèmes de détection d'attaque classiques, IDS), vous ne pouvez pas voir grand-chose. Dans cet article, j'essaierai de réfuter cette opinion et de rendre la conversation plus substantielle, je donnerai de vrais exemples lorsque le NTA aide vraiment à identifier diverses anomalies et menaces qui manquent sur le périmètre ou même au-delà du périmètre. Et je vais commencer par la menace qui est arrivée en tête du classement des menaces de l’année dernière et, je pense, le restera cette année.Il s'agira des fuites d'informations et de la capacité de les détecter via la télémétrie réseau.

Je ne considérerai pas la situation avec les mains tordues des administrateurs qui ont quitté Internet sans Elastic ou MongoDB. Parlons des actions ciblées des attaquants, comme ce fut le cas avec l'histoire acclamée des bureaux de crédit d'Equifax. Permettez-moi de vous rappeler que dans ce cas, les attaquants ont d'abord pénétré la vulnérabilité non corrigée vers le portail Web public, puis vers les serveurs de base de données internes. Restés inaperçus pendant plusieurs mois, ils ont pu voler des données sur 146 millions de clients de bureaux de crédit. Un tel incident pourrait-il être identifié à l'aide de solutions DLP? Probablement pas, car les DLP classiques ne sont pas adaptés à la tâche de surveillance du trafic à partir de bases de données à l'aide de protocoles spécifiques, et même à condition que ce trafic soit chiffré.Mais la solution de la classe NTA permet de détecter assez facilement de telles fuites en dépassant une certaine valeur seuil de la quantité d'informations téléchargées depuis la base de données. Ensuite, je vais montrer comment tout cela est configuré et découvert à l'aide de la solution Cisco Stealthwatch Enterprise.

Ainsi, la première chose que nous devons faire est de comprendre où nos serveurs de bases de données sont situés dans le réseau, de déterminer leurs adresses et de les regrouper. Dans Cisco Stealthwatch, la tâche d'inventaire peut être effectuée manuellement ou à l'aide d'un classificateur spécial qui analyse le trafic et, selon les protocoles utilisés et le comportement du nœud, vous permet de l'attribuer à l'une ou l'autre catégorie.



Une fois que nous avons des informations sur tous les serveurs de base de données, nous commençons une enquête pour savoir si nous perdons de grandes quantités de données du groupe de nœuds souhaité. Nous constatons que dans notre cas, les bases de données communiquent le plus activement avec les serveurs DHCP et les contrôleurs de domaine.



Les attaquants établissent souvent le contrôle de l'un des nœuds du réseau et l'utilisent comme tête de pont pour développer leur attaque. Au niveau du trafic réseau, cela ressemble à une anomalie: l'analyse du réseau à partir de ce nœud devient plus fréquente, les données sont capturées à partir du partage de fichiers ou l'interaction avec n'importe quel serveur. Par conséquent, notre prochaine tâche est de comprendre avec qui exactement nos bases de données communiquent le plus souvent.



Dans le groupe des serveurs DHCP, il s'avère qu'il s'agit d'un nœud avec l'adresse 10.201.0.15, interaction avec laquelle représente environ 50% de tout le trafic provenant des serveurs de base de données.



La prochaine question logique que nous nous posons dans le cadre de l'enquête est: «Et à quoi ressemble ce nœud comme 10.201.0.15? Avec qui interagit-il? À quelle fréquence? Quels protocoles? "



Il s'avère que le nœud qui nous intéresse communique avec divers segments et nœuds de notre réseau (ce qui n'est pas surprenant, car il s'agit d'un serveur DHCP), mais la question provoque trop d'interaction avec le serveur de terminal avec l'adresse 10.201.0.23. Est-ce normal? Il y a clairement une sorte d'anomalie. Un serveur DHCP ne peut pas communiquer si activement avec un serveur Terminal Server - 5610 flux et 23,5 Go de données.



Et cette interaction est réalisée via NFS.



Nous passons à l'étape suivante et essayons de comprendre avec qui notre serveur de terminal interagit? Il s'avère qu'il a une communication assez active avec le monde extérieur - avec des nœuds aux États-Unis, en Grande-Bretagne, au Canada, au Danemark, aux Émirats arabes unis, au Qatar, en Suisse, etc.



La suspicion a été causée par le fait de l'interaction P2P avec Porto Rico, qui représentait 90% de tout le trafic. De plus, notre serveur terminal a transmis plus de 17 Go de données à Porto Rico via le 53e port, qui est connecté avec le protocole DNS. Pouvez-vous imaginer que vous avez un tel volume de données transmises via DNS? Et je vous rappelle que selon les recherches de Cisco, 92% des logiciels malveillants utilisent DNS pour masquer leur activité (téléchargement de mises à jour, réception de commandes, déchargement de données).



Et si le protocole DNS de l'UIT n'est pas seulement ouvert, mais non inspecté, alors nous avons un énorme trou dans notre périmètre.



Dès que le nœud 10.201.0.23 nous a causé de tels soupçons, voyons à qui il parle encore?



Notre «suspect» échange la moitié de tout le trafic avec le nœud 10.201.3.18, qui est placé dans un groupe de postes de travail d'employés du service commercial et marketing. Dans quelle mesure ceux-ci sont-ils typiques de notre organisation pour que le serveur de terminal "communique" avec l'ordinateur du vendeur ou de l'agent de commercialisation?



Nous avons donc mené une enquête et découvert l'image suivante. Les données du serveur de base de données ont été «versées» sur un serveur DHCP avec leur transfert ultérieur via NFS vers un serveur terminal à l'intérieur de notre réseau, puis vers des adresses externes à Porto Rico en utilisant le protocole DNS. Il s'agit d'une violation manifeste des politiques de sécurité. Dans le même temps, le serveur de terminaux a également interagi avec l'un des postes de travail du réseau. Qu'est-ce qui a causé cet incident? Un compte volé? Appareil infecté? Nous ne savons pas. Cela nécessitera la poursuite de l'enquête, qui était basée sur la solution de classe NTA, qui permet d'analyser les anomalies du trafic réseau.



Et maintenant, nous voulons savoir ce que nous ferons des violations identifiées de la politique de sécurité? Vous pouvez effectuer une analyse régulière selon le schéma ci-dessus, ou vous pouvez configurer la stratégie NTA afin qu'elle signale immédiatement quand des violations similaires sont détectées. Cela se fait soit via le menu général correspondant, soit pour chaque connexion détectée lors de l'enquête.



Voici à quoi ressemblera la règle de détection d'interaction, dont la source est le serveur de base de données et la destination est tous les nœuds externes, ainsi que tous les nœuds internes, à l'exclusion des serveurs Web.



Si un tel événement est détecté, le système d'analyse du trafic réseau génère immédiatement un signal d'alarme de correspondance et, selon les paramètres, l'envoie à SIEM, en utilisant les moyens de communication avec l'administrateur, ou peut même bloquer automatiquement la violation détectée (Cisco Stealthwatch le fait en interagissant avec Cisco ISE )



Rappelez-vous, lorsque j'ai mentionné le cas d'Equifax, j'ai mentionné que les attaquants utilisaient un canal crypté pour vider les données. Pour DLP, ce trafic devient une tâche insoluble, mais pour les solutions de classe NTA, ils ne le font pas - ils suivent tout trafic excédentaire ou interaction non autorisée entre les nœuds, quel que soit le chiffrement.



Un seul cas a été montré ci-dessus (dans les documents suivants, nous considérerons d'autres exemples d'utilisation de NTA à des fins de sécurité de l'information), mais en fait, les solutions modernes de la classe Network Traffic Analysis vous permettent de créer des règles très flexibles et de prendre en compte non seulement les paramètres de base de l'en-tête du paquet IP:



mais aussi effectuer une analyse plus approfondie, jusqu'à associer l'incident au nom d'utilisateur d'Active Directory, rechercher des fichiers malveillants par hachage (par exemple, obtenu comme indicateur de compromis auprès de SOSOPKA, FinCERT, Cisco Threat Grid, etc.), etc.



Il est facile à mettre en œuvre. Par exemple, voici à quoi ressemble la règle habituelle pour détecter tous les types d'interaction entre les serveurs de base de données et les nœuds externes en utilisant n'importe quel protocole au cours des 30 derniers jours. Nous constatons que nos bases de données «communiquent» avec des nœuds externes au segment SGBD en utilisant les protocoles DNS, SMB et port 8088.



En plus du formulaire tabulaire de présentation des résultats des investigations ou recherches, nous pouvons également les visualiser. Pour notre scénario, un fragment du diagramme de flux réseau peut ressembler à ceci:



et directement à partir de la même carte, nous pouvons gérer des politiques - bloquer les connexions ou automatiser le processus de création de règles de surveillance pour les flux qui nous intéressent.



Voici un exemple assez intéressant et vivant d'utilisation des outils de surveillance Netflow (et d'autres protocoles de flux) pour la cybersécurité. Dans les notes suivantes, j'ai l'intention de montrer comment vous pouvez utiliser NTA pour détecter du code malveillant (par exemple, Shamoon), des serveurs malveillants (par exemple, la campagne DNSpionage), des programmes d'accès à distance (RAT), contourner les proxys d'entreprise, etc.

Source: https://habr.com/ru/post/undefined/