Nous a-t-on piratés?!?

Une cyberattaque peut s’avérer dramatique pour n’importe quelle organisation. C’est pourquoi, il est capital de connaître les mesures à prendre et les programmes vers lesquels on peut se tourner pour protéger une instance ou la restaurer, advenant le cas où elle aurait été compromise. Dresser un plan est crucial – nous nous concentrerons donc ici sur la préparation. En effet, il sera difficile de savoir qu’une instance a été piratée si aucun plan n’a été établi au préalable. Disposer d’un plan signifie qu’on pourra revenir rapidement et aisément à un stade antérieur, de préférence en sachant d’où venait l’attaque.

J’ai juste besoin de savoir comment récupérer mon instance OpenStack.

Détection d’un incident

Supposons que vous avez noté des activités inattendues ou suspectes sur l’instance, voire que l’équipe des administrateurs de l’ATIR vous ait signalé la possibilité d’un incident. Le moment est venu pour vous de passer à l’action. Deux mesures essentielles confirmeront vite si un compte a été compromis et vous permettront de l’identifier : (1) un contrôle des utilisateurs et (2) une vérification du système.

1. Contrôle des utilisateurs

Demandez-vous ce qui suit.

Se passe-t-il quelque chose d’anormal?
Des permissions étranges se sont-elles ajoutées aux programmes?
Un compte a-t-il tenté, en vain, de prendre le contrôle avec une commande comme sudo?

Commandes utiles:

Function	Command
Qui est connecté?	`$ who`
Pour vérifiez les permissions associées au programme et la dernière fois que les permissions ont été modifiées (remplacez /var/log par le chemin à vérifier).	`$ sudo ls -lc /var/log`
Pour gardez la liste des modifications apportées aux permissions.	`$ sudo auditctl -w /var/www/foo -p a`
Pour l’installer Auditd	`$ sudo apt update && sudo apt install auditd`

Les modifications apportées aux attributs seront enregistrées.

-w signifie « surveiller le fichier ou le répertoire »
-p a signifie « suivre les modifications apportées au fichier des attributs » (permissions)

Voici à quoi ressemble le journal qu’active cette commande.

tail -f /var/log/audit/audit.log.

type=SYSCALL msg=audit(1429279282.410:59): arch=c000003e syscall=268 success=yes exit=0

a0=ffffffffffffff9c a1=23f20f0 a2=1c0 a3=7fff90dd96e0 items=1 ppid=26951 pid=32041

auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5

ses=4294967295 comm="chmod" exe="/bin/chmod"

type=CWD msg=audit(1429279282.410:59): cwd="/root"

type=PATH msg=audit(1429279282.410:59): item=0 name="/var/www/foo" inode=18284 dev=00:13

mode=040700 ouid=0 ogid=0 rdev=00:00

Les deux derniers points sont des méthodes couramment employées pour accéder à votre système. L’assaillant se connectera souvent en passant par des utilisateurs ou des services mal protégés, puis en modifiera les autorisations pour s’en accorder de plus grandes.

2. Vérifiez l’utilisation du système.

Des outils comme uptime ou top permettent de vérifier la charge de l’instance et d’établir si certains services exploitent anormalement beaucoup de ressources. Le pirate cherchera à dissimuler ses activités avec des services qui se fondent dans l’environnement. Effectuez une recherche en ligne pour repérer les services qui ne vous paraissent pas familiers. Considérez comme suspects les services sur lesquels aucune source fiable ne peut vous renseigner. Le pirate pourrait vouloir utiliser les ressources de calcul (p. ex., minage des unités de traitement graphique) ou essayer de récupérer des données à diverses fins (p. ex., rançongiciel).

Pour ausculter le système de façon dynamique et en temps réel, utilisez la commande: $ top

Cliquez ici pour en savoir plus (information en anglais seulement).

Vous pouvez aussi vérifier le fichier des utilisateurs autorisés et déterminer qui s’est connecté à l’instance antérieurement (p. ex., avec la commande last ou un journal comme /var/log/auth.log). Tout semble-t-il normal? Vous ne reconnaissez pas une nouvelle entrée? Ces signes pourraient indiquer que le système a été compromis.

$ tail 1000f /var/auth/log

Vous en avez donc la confirmation : votre système à été piraté…

Plan d’intervention

L’étape suivante consiste à limiter les dégâts et à restaurer l’instance à un stade précédant le piratage. Pareille mesure gagnera en efficacité si elle a été planifiée et si on épouse des principes de cybersécurité solides, qui vous faciliteront la tâche au cas où la sécurité du système aurait été compromise.

1. Isolez l’instance.

Pour commencer, séparez l’instance de celles auxquelles elle pourrait être connectée ou avec lesquelles elle communique. Le pirate sait comment s’en servir pour accéder aux autres instances du réseau. S’il s’agit d’un rançongiciel, son auteur saura comme encrypter des éléments comme du stockage et des objets.

Les premières mesures à prendre quand une instance est compromise consistent à la désactiver et à signaler le problème à l’équipe des administrateurs de l’ATIR de CANARIE.

2. Vérifiez les données de l’instance.

Vérifiez le jeu ou les bases de données pour en déterminer l’authenticité et vous assurer que rien n’a été ajouté, supprimé ou modifié, de quelque façon que ce soit. Si vous parvenez à établir quand les données ont été altérées pour la première fois, vous pourrez vous servir de cette information pour identifier la dernière « sauvegarde sûre » qui servira de point de départ à la restauration.

3. Vérifiez les copies de sauvegarde.

Vous aurez – nous l’espérons – pris soin d’effectuer fréquemment des copies de sauvegarde, ce qu’il est sage de faire. Trouvez la copie « sûre » la plus récente. Il vaut la peine de garder un œil sur les copies de sauvegarde en réserve. Si les données sont sauvegardées automatiquement tous les jours à la même heure, par exemple, assurez-vous que le timbre de l’horodateur de la copie sûre la plus récente correspond bien à l’heure à laquelle s’effectuent normalement la sauvegarde. C’est une bonne façon de vérifier qu’elle n’a pas été altérée.

Vous avez un doute? Supprimez l’instance.

Malheureusement, rebâtir l’instance reste le meilleur moyen – le plus sécuritaire et aussi celui qu’on recommande – de rétablir la situation après une cyberattaque. Néanmoins, si vous suivez les pratiques exemplaires et recourez à la puissance de l’infrastructure-service (IaaS), cela ne vous demandera que quelques minutes. En supprimant l’instance puis en la redéployant, vous atténuerez considérablement les risques d’une compromission, advenant le cas où le pirate aurait créé une ou plusieurs portes dérobées pour accéder au système par la suite ou aurait introduit un logiciel malveillant qui ne pourra être détecté et qu’il déclenchera ultérieurement.

Options de sauvegarde

Étant donné l’importance des copies de sauvegarde après une cyberattaque, nous examinerons maintenant quelques solutions souvent employées en infonuagique.

Sauvegarde des données

On peut sauvegarder les données de diverses manières et ainsi en garder une trace chronologique. La première consiste à gérer les copies de sauvegarde comprimées de la base de données sur un volume distinct, sécurisé, ou sur un service de stockage quelconque (p. ex., S3). Une autre serait de créer des instantanés du système. Ces deux approches ont leurs avantages et leurs inconvénients.

Par « instantané », on entend l’image du serveur à un moment quelconque dans le temps. On pourra s’en servir pour bâtir un second serveur, configuré à l’identique, qui exécutera les mêmes fonctions que celles en activité au moment où l’instantané a été pris. C’est pourquoi il importe d’en garder plusieurs.

Songez à configurer la prise automatique d’instantanés sur AWS

En conservant plusieurs instantanés, vous pourrez revenir au moment que vous avez choisi dans le passé, ce qui s’avèrera extrêmement utile une fois qu’on aura établi la date à laquelle l’attaque est survenue.

Un des principaux bémols de l’instantané, contrairement aux copies de sauvegarde, est la probabilité, nettement plus grande, que le maliciel ait déjà été installé, donc que le problème ressurgisse. Parallèlement, l’instantané évite la réinstallation et la reconfiguration du logiciel.

Copies de sauvegarde externes

Qu’est-ce qui vaut mieux qu’une bonne copie de sauvegarde? Plusieurs! Copiez toujours plusieurs fois vos images ou vos données, et conservez-les ailleurs. Cette couche de protection supplémentaire s’avèrera fort utile si jamais une panne majeure affecte votre fournisseur de services infonuagiques.

Et si le compte Administrateur était compromis dans AWS? La meilleure manière de garder vos données à l’abri consiste à conserver vos copies de sauvegarde chez un tiers.

Restauration

Quand vous en saurez davantage sur ce qui a été compromis et comment, débute la restauration. Tel qu’indiqué plus haut, nous préconisons vivement de rebâtir l’instance de zéro, à moins que vous soyez absolument certain de posséder un instantané précédant la date où a eu lieu l’attaque.

Restauration à partir des données sauvegardées

Si vous avez sauvegardé vos données, la restauration peut se faire par la création d’une nouvelle instance, l’installation et la configuration du logiciel puis la saisie des données sauvegardées. Les approches comme l’infrastructure-code et la gestion de la configuration vous faciliteront la tâche.

Restauration à partir d’un instantané AWS

https://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/backup-recovery/restore.html

Restauration à partir d’un instantané dans OpenStack

Une autre façon de restaurer le système consiste à utiliser un instantané en suivant les six étapes que voici dans OpenStack (pour ceux qui utilisent une unité de traitement graphique dans l’ATIR).

Cliquer Instances sur le panneau gauche et sélectionner Lancer une instance.

Saisir les paramètres (Details) de l’instance.

Cliquer « suivant » (Next).
Dans le menu déroulant Select Boot Source (choisir la source de démarrage), sélectionner Instance Snapshot (instantané de l’instance).

Choisir le bon instantané en cliquant le bouton avec la flèche ascendante, à droite.

Cliquer Launch Instance (lancer l’instance), en bas à droite. L’instance devrait revenir et démarrer en l’espace de quelques minutes.

Prévenir la perte des instances

Nous vous recommandons d’adopter les trois mesure que voici pour éviter de perdre vos instances au départ :

ne pas utiliser de règle du genre 0.0.0.0/0 avec les ports à risque élevé comme ceux des protocoles RDP et SSH;
ne pas autoriser les comptes qui donnent accès à l’instance grâce à un mot de passe uniquement;
effectuer une mise à niveau et installer les rustines de sécurité tous les jours!

La seule façon de créer un instance récupérable consiste à bien comprendre ce qu’on installe et la manière dont on l’a configuré. Avant de structurer votre environnement ou de créer un programme quelconque, il est fortement recommandé de se demander comment quelqu’un pourrait les démolir.

Pour vous aider, posez-vous les questions qui suivent.

Mon serveur est-il accessible au public?
Qu’est-ce que j’utilise? Une base de données? Un serveur Web?
Le serveur est-il ouvert à tous ou des mises à niveau le sécurisent-elles?
Comment devrais-je sauvegarder mon serveur?
Comment devrais-je sauvegarder mes données?
Comment puis-je surveiller ce qui se passe sur mon serveur?

À présent, examinons quelques aspects fondamentaux de l’instance qui vous aideront à déterminer si le système a été compromis ou pas.

Journaux, SDI et SIEM

L’instance crée plusieurs journaux dont on peut se servir pour suivre les activités qui s’y déroulent. Il est bon de les examiner régulièrement ou de faire appel à d’autres services comme un système de détection des intrusions (SDI) ou un système d’information et de gestion des incidents en sécurité (SIEM) pour repérer et maîtriser les menaces.

Les grands fournisseurs de services d’infonuagique proposent leur propres solutions. AWS’ Detective service en est un exemple. Rappelez-vous que l’efficacité du SIEM ou du SDI dépend de la manière dont ces services ont été configurés et de la régularité avec laquelle on en examine les journaux. Un peu de réflexion et d’efforts sont nécessaires pour se doter d’une telle protection. On se demandera donc si on surveille ce qu’il faut afin de s’assurer que les ressources disponibles sont exploitées aussi efficacement que possible. Pour en apprendre davantage sur les SIEM ou les SDI, lisez la documentation du fournisseur, car chaque service est différent.

Autres outils et techniques

Voici quelques derniers points à prendre en compte, tant sur le plan de la prévention que pour détecter rapidement les activités anormales.

Outils

Logiciel prévenant les intrusions

Les logiciels comme fail2ban surveillent les journaux pour détecter les attaques par bourrage de mots de passe ou force brute. Ils signalent les accès non autorisés. Regardez le tutoriel de Digital Oceans pour en savoir plus (en anglais seulement).

Logiciel de surveillance et d’analyse

Les outils comme CloudWatch et GuardDuty, disponibles sur la plateforme AWS, vous aideront à suivre la situation et vous alerteront. Les solutions de ce genre signalent aussi les changements d’état.

https://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/monitoring-instance-state-changes.html

D’autres outils comme Grafana, Prometheus, Sensu et Nagios vérifieront l’instance et vous permettront de détecter les activités inhabituelles. Ils peuvent suivre diverses choses comme le temps exploitable, la charge, les entrées et les sorties, le trafic sur le réseau et ainsi de suite. On recommande ce type de surveillance, car les problèmes associés au serveur peuvent être diagnostiqués plus facilement. Ces outils s’installent vite et vous fourniront les preuves tangibles que vous avez été attaqué ou pas.

Techniques

Principe du plus petit privilège

Ce principe signifie que chaque utilisateur n’a accès qu’à ce qui lui faut pour effectuer son travail, pas plus. L’authentification précède l’autorisation d’accéder à des services spécifiques, réservés à ceux qui en ont strictement besoin.

https://repost.aws/knowledge-center/security-best-practices (en anglais)

https://blog.appsecco.com/top-10-docker-hardening-best-practices-f16c090e4d59 (en anglais)

Pare-feu et authentification

Un pare-feu bien configuré et des méthodes d’authentification concourront sensiblement à sécuriser l’instance et à la mettre à l’abri du piratage. Idéalement, on n’utilisera jamais de règle ouverte du genre 0.0.0.0/0 avec les protocoles SSH et RDP, ni avec les ports des bases de données et des applications d’administration spéciales.

Pour restreindre les risques de piratage, on établira des règles IP précises pour chaque administrateur.

Regardez le tutoriel du Nuage de l’ATIR sur la sécurité pour d’autres conseils relatifs à la sécurité sur une plateforme en nuage moderne. Vous y trouverez la description de nombreux outils et techniques comme l’isolement du réseau, l’authentification et divers modèles et architectures qui rendront votre instance aussi sûre que possible.

Restauration d’une instance piratée