Vous avez désormais une infrastructure système et réseau hautement disponible dans AWS. Malheureusement, ce matin, de manière étrange, votre site est considérablement lent. Vous avez pourtant ajouté des machines, et même augmenté la taille de la base de données, mais rien n’y fait, et votre chef commence à s’agacer des plaintes des utilisateurs.
Par un heureux hasard, ce midi vous avez mangé avec Michel, de l’équipe CSRIT (Computer Security Incident Response Team), ou “Michel de la sécu” comme on l’appelle, et tandis que devant votre milkshake banane-fraise vous parliez de votre matinée, Michel a décidé de venir cet après-midi à vos côtés pour vous aider.
Michel, c’est quelqu’un de vachement sympa (normal, il s’appelle Michel), mais il a commencé à vous poser plein de questions sur comment vous analysiez les trames réseau, comment vous stockiez les logs des machines, et quels étaient les mécanismes de remédiation en cas d’anomalie détectée. Vous avez fini par lui avouer que vous n’aviez rien de tout cela, mais heureusement, c’était dans ses cordes, alors il vous a montré.
Conservez et interrogez l’historique de votre réseau
Collectez des données
La première étape, est de comprendre ce qu’il se passe, et pour cela il vous faut de l’information. La manière la plus simple d’avoir de l’information sur votre réseau est de mettre en place de l’écoute passive, c’est-à-dire de regarder dans le réseau les paquets qui transitent. Il existe de nombreux outils, comme Wireshark, dédiés à cet usage, et dans AWS, il existe un composant “tout prêt” appelé VPC Flow Logs.
Pour mettre en oeuvre VPC Flow Logs, vous allez devoir créer un réceptacle pour votre historique réseau. Il existe deux types de destination possible pour votre historique réseau généré par VPC Flow Logs :
CloudWatch Logs ;
S3.
Nous allons diriger nos logs vers S3, car nous allons en avoir beaucoup, et le stockage y sera moins cher que dans CloudWatch Logs.
Allez dans l’interface S3, et créez un bucket avec un nom de votre choix. Revenez dans le service VPC, et cliquez sur votre VPC.
Dans le panneau en dessous de la description du VPC, vous trouverez la configuration pour Flow Logs.
Cliquez sur Create flow log et configurez comme suit :
Filter: All
Destination: Send to an S3 bucket
S3 bucket ARN: l’identifiant du bucket créé précédemment, de la forme arn:aws:s3:::bucket_name
Cliquez sur Close. Le connecteur est alors en place :
Attendez quelques minutes et allez voir dans le bucket. Vous devriez avoir des fichiers qui sont apparus.
Au passage, vous pourrez constater que AWS vous a ajouté une bucket policy, afin de lui permettre de publier des éléments dans le bucket.
Récupérez les données d’historique
Téléchargez un des fichiers présents dans le dossier : AWSLogs/_id_du_compte_aws_/vpcflowlogs/_region_/_année_/_mois_/_jour_ et décompressez-le ; son contenu devrait ressembler, une fois mis en colonnes, à ceci :
C’est quoi tous ces trucs ?!
Ces informations détaillent ce qu’il s’est passé dans votre réseau. Chaque connexion, acceptée ou rejetée, va générer une ligne. Cette ligne sera ensuite associée avec d’autres lignes d’historique réseau, pour former un fichier qui sera stocké dans S3. Sur une infrastructure de production, vous aurez énormément de lignes, et il vous faudra très certainement utiliser le combo AWS Glue + Amazon Athena ou bien des outils comme Splunk, pour pouvoir les analyser.
Cherchez dans l’historique réseau
Comme il y a beaucoup de trafic, nous allons faire appel à Athena pour chercher des éléments dans l’historique.
Pour commencer, allez dans le service Athena en passant comme d’habitude par l’onglet Services. Il faut tout d’abord, comme dans une base de données classique, créer une table qui contiendra les données relatives à notre trafic réseau. Pour cela, dans la fenêtre “Query”, exécutez cette commande, en remplaçant :
your_log_bucket par le nom du bucket ;
123456 par le numéro de votre compte AWS. Si vous ne savez pas, vous pouvez aller voir dans le bucket, cela correspond à un sous-dossier ;
eu-west-1 par la région AWS de votre VPC (eu-west-1 correspond à l’Irlande).
CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
version int,
account string,
interfaceid string,
sourceaddress string,
destinationaddress string,
sourceport int,
destinationport int,
protocol int,
numpackets int,
numbytes bigint,
starttime int,
endtime int,
action string,
logstatus string
)
PARTITIONED BY (dt string)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ' '
LOCATION 's3://your_log_bucket/AWSLogs/123456/vpcflowlogs/eu-west-1/'
TBLPROPERTIES ("skip.header.line.count"="1");
Cliquez ensuite sur Run query. Cette commande crée une table appelée vpc_flow_logs avec toutes les colonnes qui nous seront utiles par rapport à l’historique réseau.
Une fois le traitement terminé, vous retrouverez votre table dans le panneau de gauche :
Vous avez peut être constaté que nous avons créé une partition. Nous allons devoir créer une partition pour la date d’aujourd’hui, afin de faire des requêtes dans nos données.
Exécutez la requête suivante, en remplaçant :
your_log_bucket par le nom du bucket ;
123456 par le numéro de votre compte AWS. Si vous ne savez pas, vous pouvez aller voir dans le bucket, cela correspond à un sous-dossier ;
eu-west-1 par la région AWS de votre VPC (eu-west-1 correspond à l’Irlande) ;
YYYY par l’année en cours ;
MM par le mois en cours ;
dd par le jour à interroger.
ALTER TABLE vpc_flow_logs
ADD PARTITION (dt='YYYY-MM-dd')
location 's3://your_log_bucket/AWSLogs/{account_id}/vpcflowlogs/{region_code}/YYYY/MM/dd';Une fois la base de données et la partition du jour mises en place, vous pouvez faire des requêtes à l’intérieur de la base. Par exemple, si nous cherchions à comprendre ce qui bloque un flux réseau, il faudrait y rechercher les requêtes rejetées de notre VPC, comme ceci :
SELECT *
FROM vpc_flow_logs
WHERE action = 'REJECT'
LIMIT 100;Pour aller plus loin
Vous l’avez constaté, il est relativement fastidieux de devoir créer une partition pour chaque jour à interroger. Pour vous aider à indexer automatiquement les données de votre bucket S3, il existe un service appelé Glue qui permet de parcourir et faire remonter les nouvelles données dans votre base Athena. Des informations à ce propos sont disponibles dans la documentation officielle.
Identifiez un incident de réseau
Sur l’infrastructure de la société Cat’seyes, il semble y avoir beaucoup de trafic réseau ; c’est probablement la cause du ralentissement de votre site web. Michel, assis à côté de vous, repère alors en parcourant les lignes de logs avec Athena, qu’un très grand nombre de requêtes sortent de vos machines en destination d’une seule adresse. Cela n’a aucun sens dans votre cas d’utilisation d’un site web. Michel avance alors que peut-être vos machines ont été piratées et que quelqu’un essaie de faire du déni de service, en les utilisant pour cibler une autre infrastructure.
En premier lieu, il vous faut bloquer l’attaque, tout en conservant le trafic du site web qui est légitime. La manière la plus simple de bloquer le trafic au sein de votre VPC est de rajouter une liste de contrôle d’accès réseau, aussi appelé nACL.
Pour cela, dans le service VPC cliquez sur Network ACL dans la partie Security. Vous trouverez une liste existante pour votre VPC. Afin d’ajouter une règle, cliquez dessus et dans l’onglet Outbounds Rules, cliquez sur Edit outbound rules puis Add Rule.
Choisissez donc un numéro de règle inférieur à 100, sélectionnez All traffic et ajoutez l’IP que vous avez identifiée comme malveillante.
En manière de cyber sécurité, une surveillance active est nécessaire. Vous devrez être capable de détecter des anomalies, et d'y remédier. Néanmoins, vous devez également mettre en place les éléments permettant de vous protéger des attaques en amont, afin de ne pas prendre le risque de laisser passer un attaquant. Je vous propose de voir tout de suite comment prévenir ces attaques.
Assurez la conformité
Cette semaine, la société a lancé sa chaîne de télévision et diffuse en ligne des contenus vidéo. Malheureusement, pour des raisons de droits d’auteur, vous n’avez pas le droit de les diffuser sur l’île de Tuvalu. Cette situation est cocasse, dans la mesure où l’île de Tuvalu est le pays qui possède l’extension .tv. Il vous faut néanmoins, donc, bloquer toutes les requêtes faites par les habitants de l’île à votre site web.
Ajouter tous les blocs d’adresses IP de l’île de Tuvalu dans votre liste de contrôle d’accès réseau est fastidieux, mais parmi la palette d’outils fourni dans AWS, Michel en connaît un, appelé AWS WAF.
AWS WAF se base sur trois éléments logiques pour permettre de filtrer le trafic :
WEB ACL : c’est l’équivalent des nACL, mais au niveau du pare-feu applicatif AWS WAF. C’est l’élément qui va bloquer ou autoriser le trafic ;
Rule : il s’agit d’une règle d’accès à votre pare-feu. C’est l’élément qui va permettre de regrouper des conditions pour que le WEB ACL dise “oui” ou “non” ;
Condition : il s’agit de l’élément qui contient la logique d’identification des paquets réseau. Il existe plusieurs types de conditions, basés sur les adresses IP, ou l’apparence des requêtes.
Vous allez donc mettre en place un blocage géographique de l’île. Pour activer une restriction géographique, allez dans le service AWS WAF and Shield, et cliquez sur AWS WAF. Cliquez sur Geo match et Create condition, puis choisissez :
Name : le nom de votre règle ;
Region : votre région Amazon ;
Location type : choisissez Country ;
Location : choisissez Tuvalu - TV.
Cliquez sur Create. Vous avez créé une condition, il faut à présent créer une règle à y associer. Cliquez sur Rules, puis Create rule. Choisissez ensuite :
Name : un nom de règle de votre choix ;
Cloudwatchmetric name : le nom de la métrique correspondant à la règle ;
Rule Type : choisissez does originate from a geographic location in, et sélectionnez votre condition.
Cliquez sur Create.
Afin que la règle soit effective, vous allez créer un ACL web basé sur cette règle. Cliquez sur Web ACL puis Create web ACL. Lisez les concepts, puis cliquez sur Next. Complétez les éléments :
Web ACL name : un nom de votre choix ;
CloudWatch metric name : un nom de votre choix ;
Region : votre région AWS ;
Resource type to associate with web ACL : choisissez Application Load Balancer ;
AWS resource to associate : sélectionnez votre Load Balancer.
Cliquez sur Next.
Passez l’écran de création de conditions : nous en avons déjà une. Cliquez sur Next. Dans la section Add rules to a web ACL, sélectionnez votre règle, cliquez sur Add Rule et configurez comme ceci :
dans le tableau d’actions, sélectionnez Block, car vous souhaitez bloquer le trafic qui sera intercepté par cette règle ;
dans l’action par défaut, laissez Allow, car vous souhaitez que le trafic qui ne correspond pas à la règle de blocage soit autorisé.
Cliquez alors sur Review and create puis Confirm and create.
En résumé
vous avez la possibilité de mettre en place de l’historisation au niveau réseau, avec un outil appelé VPC flow logs ;
pour analyser la grande quantité d’historique remontée par VPC Flow Logs, il est possible d’utiliser Athena ;
à l’aide des logs réseau que vous pourrez analyser, il est possible d’identifier des menaces à l’intérieur de votre infrastructure ;
vous pouvez bloquer des adresses IP spécifiques à l’aide des listes de contrôle d’accès réseau ou nACL ;
Afin de mettre en place un blocage géographique, il est possible de mettre en place sur votre équilibreur de charge un pare-feu applicatif appelé AWS WAF ;
AWS WAF est capable d’identifier le trafic en provenance d’un pays, mais aussi d’analyser le format des requêtes pour identifier des anomalies ou les attaques comme les injections SQL.
Ça y est, le trafic est bloqué sur votre Load Balancer ! Cependant, Michel n’en a pas fini avec vous, il est un peu irrité que vous n’ayez rien vu : vous auriez dû avoir des mécanismes de surveillance au niveau système. C’est ce que nous allons voir au chapitre suivant.
