Pour la fin des soldes, l'Apple MacBook Air M1 de 2020 est disponible à moins de 900 euros sur Amazon : une bonne opportunité pour ceux qui veulent se laisser tenter par un ultraportable de chez Apple !
Très silencieux, le MacBook Air équipé de la puce Apple M1 a marqué un nouveau départ pour l'ultraportable d'Apple : il s'agissait du premier modèle avec une puce imaginée et fabriquée par Apple. Désormais, cette puce a fait ses preuves : à la fois efficace et puissante, elle est suffisamment performante pour convenir dans les années à venir.
Sur le site officiel d'Apple, le MacBook Air M1 de 2020 est vendu 1 199 euros TTC, dans la configuration proposée en promotion sur Amazon. A l'occasion de cette promotion,son tarif est de 897,68 euros sur Amazon. Ce qui correspond à une remise de 25% ! Sur du matériel Apple, ce n'est pas tous les jours.
Au-delà de la puce M1 (8 coeurs), le MacBook Air bénéficie d'un écran Retina de 13,3 pouces, d'un SSD de 256 Go en guise de stockage intégré et de 8 Go de RAM. A cela s'ajoute d'autres caractéristiques comme la clavier rétroéclairé, la caméra HD compatible FaceTime, ou encore l'authentification biométrique Touch ID. En ce qui concerne l'autonomie, Apple annonce jusqu'à 18 heures : une chose est sûre, sa batterie tiendra une journée complète !
Grâce à cette puce, il est important de noter que ce modèle ne chauffe quasiment pas même s'il n'y a pas de ventilateur. Du coup, c'est aussi un appareil très silencieux, ce qui est un avantage supplémentaire.
Côté système d'exploitation, il est bien entendu compatible avec la dernière version de macOS, à savoir macOS Ventura.
Un groupe de pirates informatiques connu sous le nom d'APT29 (Midnight Blizzard) et lié aux services de renseignements russes est à l'origine d'une campagne d'attaques qui vise des dizaines d'entreprises et organisations partout dans le monde. Pour mener à bien ces attaques, les pirates utilisent des tenants Microsoft 365 compromis et Microsoft Teams.
D'après l'équipe Microsoft Threat Intelligence, qui est à l'origine d'un rapport au sujet de cette campagne d'attaques, les pirates cherchent à cibler des entreprises spécifiques, notamment dans le domaine de l'informatique, de l'industrie et des médias, en plus de cibler des organisations gouvernementales. Microsoft a même une idée précise du nombre de victimes : "Actuellement, notre enquête indique que cette campagne a touché moins de 40 organisations mondiales uniques."
Pour mettre au point cette attaque, les pirates utilisent des tenants Microsoft 365 compromis lors de précédentes cyberattaques. Ceci permet aux pirates de bénéficier d'un environnement prêt à l'emploi et de créer un nouveau sous-domaine "onmicrosoft.com" (domaine par défaut sur les tenants sans domaine vérifié) laissant penser qu'il s'agit d'un support technique. Par exemple, les cybercriminels ont utilisé le domaine "teamsprotection.onmicrosoft.com". Au total, Microsoft a identifié 5 domaines de ce type. L'objectif étant de piéger les utilisateurs finaux.
Source : Microsoft
La première étape consiste à envoyer un message sur Microsoft Teams à l'utilisateur ciblé. Ainsi, l'utilisateur est invité à accepter ou refuser une invitation de la part de "Microsoft Identity Protection", qui est le nom emprunté par les cybercriminels. Facile de se faire piéger !
Source : Microsoft
La seconde étape consiste à convaincre l'utilisateur de valider l'authentification MFA sur son mobile à l'aide de l'application Microsoft Authenticator. Il doit appuyer sur la valeur que lui demande le cybercriminel, et qui est celle attendue par Microsoft, puisque si l'on choisit le mauvais code, l'authentification échoue. Au final, le pirate peut accéder au compte Microsoft 365 de l'utilisateur puisqu'il a complété toute la chaine d'authentification. Ceci implique que le cybercriminel connaisse déjà le mot de passe de l'utilisateur.
Ceci laisse la porte ouverte à l'exfiltration de données, mais aussi à des tentatives plus avancées où le pirate peut chercher à contourner les politiques d'accès conditionnelles en intégrant une machine au tenant Microsoft Entra ID à l'aide du compte de l'utilisateur.
Le fait que ces messages externes puissent parvenir aux utilisateurs de Microsoft Teams fait penser à la méthode utilisée par l'outil TeamsPhisher.
La faille de sécurité CVE-2023-3519 qui affecte Citrix NetScaler ADC et NetScaler Gateway continue de faire parler d'elle ! Malheureusement, plusieurs centaines de serveurs ont été compromis par les cybercriminels grâce à cette vulnérabilité !
Au total, on parlait de plus de 15 000 serveurs le 24 juillet dernier. Désormais, cette tendance est à la baisse, car le nombre de serveurs vulnérables est passé à moins de 9 800 serveurs ! À cette même date, il y avait 314 serveurs vulnérables identifiés en France : désormais, il reste encore 279 serveurs vulnérables (voir ici).
Toujours d'après la Shadowserver Foundation, les cybercriminels ont compromis au moins 640 serveurs Citrix en exploitant cette vulnérabilité par l'intermédiaire d'une exécution de code à distance. En réalité, il pourrait y avoir beaucoup plus de serveurs compromis. Sur les serveurs compromis, le web shell China Chopper a été déployé par les cybercriminels.
Sur LinkedIn, la Shadowserver Foundation évoque des cyberattaques en cours : "Nous observons des campagnes d'exploitation en cours pour Citrix ADC/Gateway CVE-2023-3519. Veillez à vérifier la présence de webshells dans vos instances. Nous signalons les appliances compromises avec des webshells dans votre réseau dans notre rapport Compromised Website."
De son côté, l'agence américaine CISA met en alerte les entreprises depuis plusieurs semaines : "Le webshell a permis aux pirates de découvrir l'Active Directory (AD) de la victime, de collecter et d'exfiltrer des données AD. Les pirates ont tenté de se déplacer latéralement vers un contrôleur de domaine, mais les contrôles de segmentation du réseau de l'appliance ont bloqué le mouvement."
Quelles sont les versions vulnérables ? Comment se protéger ?
Cet article est l'occasion de rappeler une nouvelle fois quelles sont les versions vulnérables. Les mises à jour sont disponibles depuis le 18 juillet 2023.
Voici la liste officielle des versions vulnérables de Citrix :
NetScaler ADC et NetScaler Gateway 13.1 avant la version 13.1-49.13
NetScaler ADC et NetScaler Gateway 13.0 avant la version 13.0-91.13
NetScaler ADC 13.1-FIPS avant la version 13.1-37.159
NetScaler ADC 12.1-FIPS avant la version 12.1-55.297
NetScaler ADC 12.1-NDcPP avant la version 12.1-55.297
Les versions qui intègrent les correctifs de sécurité sont mises en gras dans la liste ci-dessus !
Dans ce tutoriel, nous allons apprendre à publier un serveur Apache Guacamole via un reverse proxy ! Le serveur Apache Guacamole sera accessible en HTTPS, avec un certificat valide et gratuit obtenu auprès de Let's Encrypt. Pour cette démo, un pare-feu sous pfSense est utilisé et sur ce dernier nous installerons le reverse proxy HAProxy.
Si l'on reprend le schéma présenté au sein du tutoriel d'introduction, le reverse proxy va être mis en place sur l'équipement nommé "Pare-feu" sur le schéma ci-dessous. L'objectif sera d'accéder à Apache Guacamole via l'URL suivante : https://guaca.it-connect.tech/ - Sans avoir besoin d'ajouter "/guacamole/#/" à la fin de l'URL.
En fait, pour publier Apache Guacamole avec un reverse proxy, il y a deux solutions :
S'appuyer sur un reverse proxy externe, comme c'est le cas ici puisque la fonction est hébergée par une autre machine (firewall)
S'appuyer sur un reverse proxy local, que l'on installe directement sur le serveur Apache Guacamole (non abordé dans cet article)
Avant de lire cet article, il est recommandé de lire celui-ci :
Par ailleurs, en complément, voici un autre tutoriel où j'ai évoqué en détail la mise en place d'un reverse proxy HAProxy sur pfSense. Pour ce tutoriel, la configuration est similaire sauf que l'application derrière le reverse proxy est différente. C'est pour cette raison que c'est un peu moins détaillé dans cet article.
Sur l'interface du pare-feu pfSense, il convient d'installer deux paquets : le paquet ACME pour la gestion du certificat Let's Encrypt et le paquet HAProxy pour le reverse proxy.
Pour installer ces paquets, accédez au menu suivant : System > Package Manager > Available Packages.
Ici, il conviendra de rechercher et d'installer les paquets cités précédemment. Ce qui donnera :
B. Certificat Let's Encrypt
La gestion du certificat s'effectue via : Services > Acme Certificates. Accédez à ce service via l'interface de pfSense.
Créer une clé d'authentification
Commencez par nommez cette clé, par exemple "certs.it-connect.tech" (le nom DNS n'a pas besoin d'être résolvable) et choisissez "Let's Encrypt Production ACME v2" au niveau de l'option "ACME Server".
Cliquez sur le bouton "Create new account key" pour générer une clé d'authentification et cela va remplir le champ "Account key" juste au-dessus. Nous devons enregistrer cette clé, donc je vous invite à cliquer sur "Register ACME account key". Normalement, un petit icône validé doit venir s'afficher sur le bouton, comme ceci :
Cliquez sur "Save" et vous obtenez ceci dans "Account keys" :
Demander le certificat
Cliquez sur l'onglet "Certificates" pour faire une demande de certificat via le bouton "Add". Là encore, un formulaire doit être complété. Indiquez un nom au certificat, ici "guaca.it-connect.tech", sélectionnez votre compte ACME créé précédemment et dans "Domain SAN list", indiquez bien le nom de domaine pour lequel vous souhaitez obtenir le certificat.
La méthode de validation "DNS-Manual" permet de valider que l'on est bien propriétaire du nom de domaine grâce à un enregistrement DNS de type "TXT" qu'il faudra créer.
Validez.
Créer l'enregistrement DNS TXT
Dans l'onglet "Certificates", il y a une nouvelle entrée qui apparaît. Il s'agit du certificat, mais il n'a pas été généré pour le moment.
Cliquez sur le bouton "Issue". Du texte va s'afficher dans une zone sur fond vert. Ce qui est important, c'est de repérer la section où l'on vous indique l'enregistrement TXT à créer dans la zone DNS de votre domaine. Vous l'aurez compris, il faut créer l'enregistrement DNS avant de continuer (donc rendez-vous sur votre interface OVHcloud, Gandi, Ionos, etc...).
Voici un exemple :
Demander le certificat Let's Encrypt
Une fois que c'est fait, vous pouvez demander votre certificat Let's Encrypt. Donc, cette fois-ci, cliquez sur le bouton "Renew" qui se situe juste à gauche du bouton "Issue".
Une nouvelle zone sur fond vert s'affiche, avec l'état de l'opération. Logiquement, on vous indique que le certificat a été généré avec succès et qu'il est désormais stocké en local sur le pare-feu.
Pour finir la partie certificat, cliquez sur l'onglet "General Settings" et cochez l'option "Cron Entry" pour activer la tâche planifiée (dans la crontab) afin de le renouveler automatiquement.
Ce certificat va pour voir être présenté au client qui voudront se connecter via guaca.it-connect.tech, afin de sécuriser la connexion, et cela sera fait par HAProxy. En parlant d'HAProxy, passons à la configuration du reverse proxy.
C. Reverse proxy HAProxy
Pour la configuration du reverse proxy, tout se joue dans : Services > HAProxy.
Il faut commencer par cocher l'option "Enable HAProxy" dans l'onglet "Settings" afin d'activer le service HAProxy sur le pare-feu. Cliquez sur "Save" en bas de page.
Ensuite, il y a deux parties à configurer :
Le Backend, c'est ce qui se passe derrière le reverse proxy, cela correspond donc aux différents serveurs qui hébergent les ressources, ici, notre serveur Apache Guacamole avec le site guaca.it-connect.tech.
Le Frontend, c'est ce qui se passe en frontal sur le reverse proxy, c'est-à-dire la partie publique. Ceci permet d'indiquer de quelle façon le reverse proxy doit se présenter aux clients, et surtout comment il doit traiter les requêtes. Il faudra lui indiquer comment gérer les requêtes à destination de "https://guaca.it-connect.tech".
Désormais, passons à la configuration.
Créer un backend
Il faut commencer par créer un backend, ce qui consiste à déclarer le serveur Apache Guacamole : Backend > Add. Sous "Server list", il faut déclarer le serveur, de cette façon :
Mode : Active (c'est un serveur actif dans le pool)
Name : le nom de l'hôte pour s'y retrouver, en l'occurrence "srv-guacamole" pour reprendre le nom du serveur
Forwardto : "Address+Port" puisque l'on va interroger ce serveur Web via son adresse IP et un numéro de port spécifique
Address : l'adresse IP du serveur Apache Guacamole, pour ma part "192.168.99.12"
Port : le port sur lequel est en ligne Apache Guacamole, à savoir 8080
Il n'est pas nécessaire d'effectuer d'autres modifications. Par défaut, la section "Health checking" est configurée pour que HAProxy vérifie en HTTP sur le port 8080 si notre serveur Apache Guacamole est bien en ligne.
Continuez à descendre dans la page et cliquez sur "Save".
Créer un frontend
Basculez sur l'onglet "Frontend" et cliquez sur le bouton "Add".
Après avoir donné un nom, tel que "Acces-Guaca", configurez la section "External address".
Listen address : choisissez "WAN address (IPv4)", car on va traiter les requêtes qui arrivent sur l'interface WAN du PfSense
Port : indiquez "443", car on va publier notre site en HTTPS
SSL Offloading : cochez cette option, car cela correspond à notre architecture, c'est-à-dire du HTTPS entre le reverse proxy et les clients, et du HTTP entre le reverse proxy et Guacamole. Le SSL Offloading correspond à ce processus du transformation du flux.
En complément, sélectionnez l'option "http / https (offloading)" pour la valeur "Type". Cela veut dire que le reverse proxy va travailler au niveau de la couche HTTP/HTTPS.
Passez à la section "Default backend, access control lists and actions".
Pour l'option "Access Control lists", ajoutez une ligne, c'est-à-dire une nouvelle règle (ACL). Comme ceci :
Name : nom de l'ACL, par exemple "guaca".
Expressions : on choisit "Host starts with:" (même si "Host matches:" fonctionne aussi), car on cherche à repérer la présence d'une URL qui commence par notre domaine dédié à Guacamole
Value : on précise le nom du sous-domaine du site, à savoir "guaca.it-connect.tech"
Puis, vous devez indiquer ce que l'on doit faire lorsque cette règle matche en créant une nouvelle action dans "Actions", comme ceci :
Action : on sélectionne "Use backend" et on choisit notre backend créé précédemment, cela permet d'utiliser notre Backend lorsque la requête va correspondre à l'ACL
Condition acl names : on spécifie "guaca", car c'est le nom de l'ACL
Descendez dans la page. Cochez l'option "Use forwardfor option" pour ajouter le champ "X-Forwarded-For" à l'en-tête HTTP. Pour rappel, cela permettra au serveur Apache Guacamole de connaître l'adresse IP d'origine du client, et pas seulement l'adresse IP du serveur reverse proxy. C'est très important dans Apache Guacamole pour que les informations soient complètes au niveau du suivi des sessions. Sinon, ce sera toujours l'adresse IP du reverse proxy qui sera renseignée, ce qui est un problème, car on ne pourrait pas bien tracer les accès.
Descendez... jusqu'à la section "SSL Offloading" puisqu'il faut choisir le certificat au niveau de l'option "Certificate". Ici, sélectionnez le certificat Let's Encrypt créé précédemment.
Voilà, c'est terminé pour la configuration du Frontend. Cliquez sur "Save".
D. Port de gestion de pfSense
Pour que notre reverse proxy HAProxy traite les requêtes qui arrivent sur le port 443 de l'interface WAN de PfSense, il faut que l'on crée une règle de pare-feu. Le problème, c'est que par défaut le port 443 est utilisé par défaut pour l'interface d'administration. Afin d'éviter un conflit (et potentiellement d'exposer l'interface d'administration PfSense), on va modifier le port utilisé.
Sous le menu "System", cliquez sur "Advanced". Dans l'onglet "Admin Access", modifiez l'option "TCP port" pour définir un autre port. Par exemple, le port 8443. Validez et accédez de nouveau à votre PfSense en spécifiant le nouveau port à la fin de l'URL : https://<adresse-IP>:8443.
E. Règles de firewalls
Venons-en à la création de la règle de pare-feu pour HAProxy, ce dernier doit être en mesure de recevoir les requêtes sur le port 443. Pour cela, sous le menu "Firewall", cliquez sur "Rules" puis choisissez la zone "WAN".
Créez une nouvelle règle en cliquant sur le bouton "Add" et autorisez les flux HTTPS (443) vers le pare-feu afin qu'ils soient gérés par HAProxy. Dans le cas où HAProxy doit aussi gérer des requêtes HTTP, il conviendra de créer une règle similaire pour le port 80.
Ce qui donne la règle suivant :
Remarque : pour que nos flux HTTPS soient traités par notre reverse proxy, je ne veux pas voir de règles de NAT pour rediriger le port 443 vers le serveur interne. - Sinon, cela permettrait de bypasser le reverse proxy est d'atteindre directement le serveur Apache Guacamole, ce qui n'est pas le but : nous n'avons pas fait tout ça pour rien !
Le reverse proxy est prêt !
F. Utiliser un port personnalisé pour l'accès HTTPS (facultatif)
Dans cet exemple, l'accès sera effectué en HTTPS sur le port 443 qui est le port par défaut de ce protocole. Il est tout à fait possible de configurer un autre port, par exemple le port 40443. Pour cela, il y a deux modifications à effectuer :
Dans HAProxy, le port du Frontend doit être modifié pour l'External address afin d'utiliser 40443 (ou autre chose) à la place de 443
Dans les règles de pare-feu sur l'interface WAN, la règle créée précédemment pour le port 443 doit être modifiée pour spécifier le nouveau port à utiliser
Bien sûr, cette étape est facultative, mais c'est un moyen de masquer un peu plus l'application grâce au fait que l'on n’utilise pas un port par défaut. Mais, je rappelle que le reverse proxy va renvoyer vers notre serveur Apache Guacamole uniquement les requêtes sur l'URL "https://guaca.it-connect.tech" donc il faut connaître le nom de domaine de l'application.
III. Configuration d'Apache Guacamole
La dernière étape consiste à affiner la configuration du serveur Apache Guacamole ! Ensuite, ce sera l'heure de tester !
A. Tomcat9 et l'IP d'origine
Avec la configuration actuelle, et malgré l'activation de l'option pour gérer le champ "x-forwarded-for" dans l'en-tête HTTP, on obtiendrait ceci côté Apache Guacamole :
En fait, l'hôte distant serait toujours égal à l'adresse IP du reverse proxy, que ce soit avec un client du réseau local ou un client distant. Pour que l'adresse IP d'origine du client soit visible dans Apache Guacamole, il faut adapter la configuration de Tomcat.
Depuis la ligne de commande du serveur Apache Guacamole, éditez le fichier de configuration de Tomcat9.
La seule valeur à modifier, c'est celle du champ "internalProxies" où vous devez indiquer l'adresse IP de votre reverse proxy (correspondante à l'interface qui communique avec Guacamole). Ici, ce sera "192.168.99.1".
Ce bloc s'ajoute à la fin du fichier de configuration, à cet endroit pour être précis :
Sauvegardez et relancez le service Tomcat9.
sudo systemctl restart tomcat9
Suite à cette modification, c'est bien l'adresse IP d'origine du client qui est visible dans Apache Guacamole !
B. Supprimer "guacamole" dans l'URL
Dernier point de configuration : se débarrasser de "/guacamole/" dans l'URL pour que l'on soit en mesure d'accéder à Apache Guacamole via l'URL "https://guaca.it-connect.tech". Bien sûr, cette étape est facultative.
Pour cela, il faut renommer la WebApp d'Apache Guacamole, au niveau du répertoire de Tomcat9.
Commencez par accéder au répertoire des WebApps
cd /var/lib/tomcat9/webapps
Puis, arrêtez le service Tomcat9 :
sudo systemctl stop tomcat9
Actuellement, nous avons :
Le fichier guacamole.war qui correspond à la WebApp de Guacamole
Le répertoire guacamole qui contient les données de cette WebApp
Le répertoire ROOT qui contient la page par défaut de Tomcat9
L'objectif va être de faire en sorte que "guacamole.war" devienne "ROOT.war" pour prendre la place de la page par défaut. Ainsi, on pourra accéder à son interface sans préciser de suffixe dans l'URL.
Commencez par supprimer le répertoire "guacamole" (attention, je dis bien le répertoire).
sudo rm guacamole/ -Rf
Puis, renommez le dossier "ROOT" en "ROOT-ORIGINAL" pour "libérer la place". Et, renommez la WebApp de Guacamole :
En image, cela donne l'enchaînement de commandes suivant :
Désormais, suite à cette manipulation, Apache Guacamole est accessible en direct sans préciser "/guacamole/" :
IV. Tests : Apache Guacamole derrière un reverse proxy
Même si les copies d'écran précédentes prouvent qu'Apache Guacamole est bien accessible sur sa nouvelle adresse, via le reverse proxy et avec un certificat valide, vous devez bien sûr tester. En appliquant cette configuration, Apache Guacamole est accessible, aussi bien via le réseau local qu'en externe, à partir d'une URL unique.
La connexion entre le reverse proxy et le client est sécurisée via le protocole HTTPS et un certificat.
V. Conclusion
Suite à la lecture de ce tutoriel, vous êtes en mesure de publier un serveur Apache Guacamole derrière un reverse proxy basé sur le trio magique "pfSense + HAProxy + ACME" ! N'hésitez pas à regarder la vidéo ainsi que les liens intégrés en début d'articles pour avoir plus de précisions.
Si cela vous intéresse, je peux envisager la publication d'un tutoriel sur le déploiement d'un reverse proxy en local sur le serveur Apache Guacamole.
Un groupe de pirates sponsorisé par la Chine est suspecté d'être à l'origine d'une série de cyberattaques contre des industries basées en Europe de l'Est. L'objectif de ces attaques : voler les données sur les systèmes air-gapped.
Kaspersky a mis en ligne un nouveau rapport qui évoque une série d'attaques qui a débuté en avril 2022 et lors desquelles les pirates sont parvenus à exfiltrer des données à partir de système air-gapped. Pourtant, par définition, un système air-gapped se veut isolé du réseau de l'entreprise et d'Internet pour des raisons de sécurité. Selon l'implémentation, cette isolation peut être physique. Comment les pirates sont-ils parvenus à exfiltrer des données sur ces systèmes sous cloche ?
Ce nouveau malware attribué au groupe de pirates APT31 alias Zirconium est associé à des attaques réalisées en plusieurs phases : "Au total, nous avons identifié plus de 15 implants et leurs variantes mis en place par les cybercriminels dans diverses combinaisons.", précise Kaspersky. Ainsi, il y a trois grandes catégories d'implants correspondantes à différentes phases de l'attaque.
Première phase pour bénéficier d'un accès permanent à distance, et procéder à la collecte initiale de données
Deuxième phase pour la collecte de données et de fichiers, y compris à partir de systèmes air-gapped
Troisième phase pour télécharger des données vers le C2
Pour parvenir à exfiltrer des données à partir de systèmes air-gapped, les cybercriminels s'appuient sur la propagation USB : ce qui implique que les informations transitent par des périphériques USB. Il est vrai qu'un périphérique USB peut être connecté sur une machine du réseau local, puis sur un système air-gapped, et inversement, ce qui permet de faire transiter des informations grâce à l'infection préalable du périphérique USB.
Sur le périphérique USB, les données sont stockées dans le répertoire "$RECYCLE.BIN" pour que ce soit discret. Avant tout cela, un premier module présent sur une machine va infecter les lecteurs amovibles en copiant un exécutable légitime de McAfee, mais vulnérable à la technique du DLL hijacking, ainsi qu'une DLL malveillante qui sert de charge utile. Ces fichiers sont cachés, tandis qu'un fichier LNK (raccourci), visible quant à lui, est créé de manière à déclencher l'infection si l'utilisateur l'ouvre.
Cette méthode montre qu'en l'absence de connectivité au reste du réseau Ethernet de l'entreprise, l'USB représente une belle opportunité.
Les données récupérées sont stockées dans une archive compressée avant d'être chargée vers un espace de stockage Dropbox ou Yandex Disk contrôlé par les pirates. Dans certains cas, c'est un serveur VPS qui a été utilisé pour réceptionner les données.
- Sinon, cela permettrait de bypasser le reverse proxy est d'atteindre directement le serveur Apache Guacamole, ce qui n'est pas le but : nous n'avons pas fait tout ça pour rien !
