CRED atteint un niveau élevé d'inspection du réseau grâce à la mise en miroir du trafic VPC

8 septembre 2021 : Amazon Elasticsearch Service a été renommé Amazon OpenSearch Service. Voir les détails.

Article d'invité rédigé par Himanshu Das, Security Lead, CRED

CRED cherche à donner aux personnes les moyens d'améliorer leur vie grâce à ses avantages de carte de crédit réservés aux membres, à des récompenses exclusives et à des expériences de grandes marques. CRED, une communauté de confiance composée de particuliers, de commerçants et d'institutions solvables, a repensé l'expérience des cartes de crédit pour les personnes desservant environ des millions de payeurs de cartes de crédit.

Traitant des tonnes de transactions et de données sensibles, CRED a toujours mis l'accent sur la sécurité. Il existe deux types d'entreprises : l'une où la sécurité est considérée comme une question secondaire et l'autre où la sécurité est de la plus haute importance. Qu'en est-il des intermédiaires, demandez-vous ? Chez CRED, nous croyons sincèrement qu'il n'y a pas d'intermédiaires. Et c'est probablement la raison pour laquelle nous appartenons à ce dernier camp. CRED est une entreprise axée sur la sécurité, dont elle fait sa priorité unique à tout moment.

« L'utilisation d'AWS nous a non seulement permis de maintenir la stabilité et la haute disponibilité de notre infrastructure, mais également de garantir la sécurité à chaque couche » ~ Avinash Jain, Security Engineering, CRED.

Mise en miroir du trafic AWS VPC : surveillance des intrusions réseau dans un sous-réseau VPC public à l'aide d'un NIDS

La COVID a frappé tout le monde et a affecté les gens à leur manière. En ce qui concerne les organisations, les employés ont été invités à travailler à domicile (WFH), et comme de nombreux secteurs d'activité travaillent désormais à distance, le schéma des connexions des utilisateurs au réseau de l'entreprise s'est bouleversé. Au lieu de se connecter localement, la plupart des utilisateurs se connectent désormais à distance. Et pour permettre aux employés d'accéder aux fonctions critiques de l'entreprise, la connectivité VPN est obligatoire.

Étant donné que l'instance VPN est maintenue dans une zone démilitarisée (DMZ) pour permettre aux employés du monde entier de s'y connecter et d'accéder aux applications internes, on assiste à un afflux inattendu de connexions WFH, ce qui rend les réseaux VPN plus vulnérables à toutes sortes d'attaques de type Layer7/Layer3.

Dans ce billet de blog, nous expliquerons comment nous avons renforcé la sécurité et la surveillance de notre instance VPN publique, qui a été conservée dans le VPC public, en gardant un œil attentif sur les modèles de trafic ou les contenus inhabituels susceptibles de signaler une intrusion sur le réseau à l'aide de la Mise en miroir du trafic Amazon VPC et d'un système de détection des intrusions sur le réseau.

La mise en miroir du trafic VPC duplique le trafic entrant et sortant pour les instances Amazon EC2 au sein d'un VPC sans qu'il soit nécessaire d'installer quoi que ce soit sur les instances elles-mêmes. L'idée est d'envoyer ce trafic dupliqué au système de détection d'intrusion réseau (NIDS) à des fins d'analyse et de surveillance. Voici à quoi ressemble le schéma d'architecture de la surveillance des intrusions sur le réseau :

Tout trafic arrivant sur le serveur VPN est envoyé vers la cible miroir (équilibreur de charge réseau) qui sert de destination au trafic miroir. La mise en miroir du trafic VPC fournit une fonctionnalité intéressante de filtres miroir qui permettent de spécifier le trafic entrant ou sortant (par rapport à la source) qui doit être capturé (accepté) ou ignoré (rejeté). Depuis la cible miroir, nous envoyons le trafic dupliqué vers le système NIDS à l'aide de Suricata, un moteur open source de détection des menaces réseau qui fournit des fonctionnalités telles que la détection des intrusions (IDS), la prévention des intrusions (IPS) et la surveillance de la sécurité du réseau. Nous avons choisi Suricata parce qu'il fonctionne très bien avec l'inspection approfondie des paquets et la mise en correspondance des modèles, ce qui le rend incroyablement utile pour la détection des menaces et des attaques. Il est également multithreading, qui fournit la capacité théorique de traiter un plus grand nombre de règles sur des réseaux plus rapides, avec des volumes de trafic plus importants, sur le même matériel.

Pour une résilience et une disponibilité accrues, nous envoyons le trafic dupliqué vers une instance EC2 dotée d'une configuration Suricata. Nous utilisons les instances Amazon EC2 T3 à cette fin. Ce choix est intentionnel, car nous savions qu'il y aurait un trafic élevé à tout moment et que la performance et l'efficacité étaient les deux autres critères que nous voulions atteindre. Toutes ces exigences ont été satisfaites par des instances T3 qui fournissent un niveau de performance de base du processeur avec la capacité d'augmenter l'utilisation de ce dernier à tout moment et aussi longtemps que nécessaire.

Surveillance et journalisation

L'agent Filebeat est installé sur les instances de Suricata, qui est un expéditeur léger permettant de transférer et de centraliser les données de journal. Suricata surveille en permanence le trafic, les règles Suricata (/etc/suricata/rules) déclenchent des alertes, puis Filebeat envoie des journaux d'alertes à la pile ELK où logstash traite les données JSON. Nous utilisons le module Suricata dans un Amazon OpenSearch Service autohébergé (successeur d'Amazon Elasticsearch Service), qui exécute les tâches suivantes pour nous :

●   Utilisation d'un nœud d'ingestion pour analyser et traiter les lignes de journal, en façonnant les données dans une structure adaptée à la visualisation dans Kibana

●   Déploiement des tableaux de bord pour visualiser les données du journal

Nous pouvons surveiller la distribution géographique du trafic entrant dans notre système à l'aide de la visualisation de la carte de coordonnées de Kibana. Le champ event_type indique le type de journal Suricata. À l'aide d'une visualisation sous forme de graphique circulaire, nous pouvons voir la répartition des principaux types de journaux enregistrés dans le système.

Comme on peut le voir sur l'image, nous avons classé les alertes en fonction de leur gravité : élevée, moyenne et faible. La catégorisation des événements est gérée à deux endroits :

1. L'une au niveau des « Filtres de miroir » du VPC

2. L'autre en utilisant les règles de Suricata pour identifier le protocole et classer les anomalies dans les événements.

Pour l'instant, nous utilisons le jeu de règles par défaut fourni par Suricata. Il comprend la vérification de la réputation des IP malveillantes, les agents utilisateurs suspects, les intrusions basées sur la signature, la violation des politiques, les anomalies du trafic et bien d'autres choses encore. L'un des exemples donnés dans la visualisation du diagramme circulaire montre que Suricata a trouvé une activité Tor sur le réseau ainsi que d'autres anomalies du réseau. Le processus de remédiation passe par un cadre central de journalisation, d'alerte et de décision. Nous avons configuré les paramètres ci-dessous pour la visibilité sur le tableau de bord.

o   Nombre d'alertes

o   Top 10 des signatures d'alerte

o   Top 20 des adresses IP sources d'alerte

o   Top 20 des adresses IP de destination d'alerte

o   Gravité de l'alerte

o   Chronologie des alertes

o   Événement DNS dans le temps

Résultat final

La mise en miroir du trafic VPC nous permet de surveiller beaucoup plus facilement le trafic réseau au sein de nos VPC AWS. Grâce à la mise en miroir du trafic VPC, nous sommes désormais en mesure de surveiller efficacement le trafic réseau, d'analyser les modèles de trafic et de détecter de manière proactive le trafic malveillant. Certains des avantages qu'il offre sont les suivants :

• Détecter les anomalies de réseau et de sécurité : extraction du trafic intéressant depuis n'importe quelle charge de travail dans un VPC et acheminement vers les outils de détection de votre choix, puis détection et réponse aux attaques plus rapidement que ne le permettent les outils traditionnels basés sur les journaux.
• Obtenir des informations opérationnelles : utilisation de la mise en miroir du trafic VPC pour obtenir la visibilité et le contrôle du réseau qui vous permettront de prendre des décisions de sécurité en toute connaissance de cause.
• Implémenter des contrôles de conformité et de sécurité : respect des exigences réglementaires et de conformité qui imposent la surveillance, la journalisation, etc.

Suricata est une excellente option open source pour surveiller les réseaux afin de détecter les activités malveillantes. Nous améliorerons notre intégration à Suricata avec des règles et des tableaux de bord supplémentaires à l'avenir.