Si les bons côtés de l’expansion du numérique reviennent régulièrement à l’ordre du jour, il ne faut malheureusement pas oublier les mauvais. Le fait est que, grâce à internet, la protection des données, qu’elles soient personnelles ou pas, est devenue un véritable problème. De nombreuses personnes et entreprises se plaignent d’attaques informatiques de plus en […]
The post Comment se protéger contre les cyberattaques ? first appeared on UnderNews.
Le rapport Voice of the CISO de Proofpoint révèle que deux tiers des RSSI dans le monde ne se sentent pas prêts à gérer une cyberattaque. 58 % des RSSI considèrent le facteur humain comme la principale vulnérabilité cyber, en particulier dans un contexte où le mode de travail hybride engendre de nouveaux défis pour les équipes en charge de la cybersécurité.
The post Plus de la moitié des RSSI Français considèrent le facteur humain comme la plus grande vulnérabilité de leur entreprise first appeared on UnderNews.
Voitures, vélos, scooters... : la mobilité de demain se lit sur Vroom ! https://www.numerama.com/vroom/vroom//
L'article En 2020, le rançongiciel est resté « l’attaque la plus répandue » est apparu en premier sur Numerama.
Que ce soit avec Office 365 et Exchange Online, ou une autre solution de messagerie, lorsque l'on parle d'e-mails, il y a deux termes qui reviennent encore et encore, constamment : sécurité et délivrabilité.
En tant qu’administrateur infrastructure, on souhaite éviter autant que possible de recevoir les mails de type spam, phishing, contenant des pièces jointes frauduleuses. Alors on met en place des filtres anti-phishing, antispam. On cherche aussi à sécuriser les e-mails au départ de notre serveur de messagerie, et faire en sorte qu’ils soient sains. Et puis on souhaite enfin s’assurer que nos mails passent les filtres de sécurité des serveurs de messagerie distants sans encombre, et arrivent directement dans la boîte mail du destinataire, sans passer par la case spam.
Avec Office 365, il y a plusieurs manières (complémentaires) d’arriver à nos fins. L’une d’entre elles est de passer par le trio gagnant des enregistrements DNS : « SPF », « DKIM » et « DMARC ».
Bon, je vous vois venir, vous allez me dire que lorsque vous configurez un nouveau domaine dans Office 365, vous devez obligatoirement configurer un enregistrement SPF dans votre zone DNS, et que cet enregistrement sert déjà à améliorer la sécurité et la délivrabilité de vos mails. Alors, à quoi bon s’embêter avec DKIM et DMARC ?
On va la faire courte : SPF est bien entendu nécessaire, mais n’est absolument pas suffisant. C’est là que DKIM et DMARC entrent en jeu.
Je vous explique.
SPF (ou Sender Policy Framework) est une norme adoptée à l’international qui permet de réduire les spams au niveau de votre serveur.
Concrètement, l’enregistrement SPF sert à authentifier l’expéditeur d’un courrier électronique. Cela permet de vérifier que le serveur qui envoie un mail à partir d’une adresse mail en @mondomaine.com est bien un serveur légitime.
Le nom de domaine de l’émetteur est extrait de l’en-tête du mail reçu (« MAIL FROM : »), et une requête DNS est émise sur ce domaine pour connaître la liste des serveurs de messagerie légitimes qui peuvent émettre des mails pour ce domaine précis. On compare alors cette liste de serveurs à l’adresse IP du serveur qui a émis le message.
Par exemple dans mon cas, comme mes domaines sont configurés sur Office 365, seuls les serveurs Exchange Online du tenant Office 365 sont autorisés à envoyer des mails à mon nom.
Du coup, si jamais quelqu’un essaye de se faire passer pour moi en envoyant un mail en mon nom, son serveur ne sera pas reconnu comme légitime et le mail pourra donc être classifié comme mail frauduleux / spam.
SPF est donc devenu un indispensable pour :
Cependant, SPF ne sait pas gérer les transferts de mail, et c’est là que les enregistrements DKIM entrent en jeu.
L’enregistrement SPF est un enregistrement dans votre zone DNS publique de type TXT qui contient la liste des serveurs de messagerie autorisés à envoyer un mail pour votre domaine.
Voici une bonne pratique à respecter en toute circonstance : incluez toujours vos serveurs sous la forme server.mondomaine.com, ne listez pas les adresses IP une par une.
Vous pouvez vérifier la validité de votre enregistrement SPF en utilisant cet outil gratuit.
Renseignez dans le champ votre nom de domaine, puis cliquez sur le bouton « Valider DNS ».
Vous obtiendrez alors un résultat complet de l’analyse de votre enregistrement SPF.
Dans mon cas, ma configuration SPF est validée, et le serveur spf.protection.outlook.com (correspondant à Office 365) est bien celui qui est déclaré. Tout est parfait!
DKIM est un acronyme pour Domain Keys Identified Mail. Cette technologie permet d’envoyer un message chiffré, et de s’assurer que celui-ci n’a subi aucune altération durant sa transition entre le serveur émetteur et le serveur récepteur.
Rassurez-vous, le contenu du mail n’est pas chiffré, et votre destinataire pourra continuer à lire le message sans vous demander de clé de déchiffrement.
Au moment où vous envoyez votre mail, le serveur émetteur le chiffre via sa clé DKIM privée. Le serveur récepteur va lui vérifier la clé DKIM publique (l’enregistrement DKIM de votre zone DNS), et comparer celle-ci avec ce qu’il a reçu. Si le test est concluant, alors le serveur émetteur est bien qui il prétend être, l’identité de l’émetteur est prouvée et le mail peut donc être délivré dans la boîte mail du destinataire.
DKIM permet donc de s’affranchir des attaques de type « man in the middle ».
Note : Cette signature DKIM se gère dans l’en-tête du mail envoyé. Cela est donc transparent pour l’utilisateur final. Comme cette signature reste dans l’en-tête, cela permet de continuer à certifier l’exactitude du mail initial si celui-ci est transféré à une tierce personne.
Je vous conseille fortement de mettre en place DKIM en plus de vos enregistrements SPF. Pourquoi ?
Parce que DKIM prouve que le contenu du mail ainsi que les en-têtes n’ont subi aucune altération : le mail est donc authentique et légitime : personne ne l'a envoyé à votre place, et le serveur de messagerie distant est maintenant en capacité de le vérifier.
Tout d’abord, ouvrez une console PowerShell et commencez par vous connecter à votre serveur Exchange Online :
Import-Module ExchangeOnlineManagement Connect-ExchangeOnline
Avant de commencer, vérifions ensemble que mondomaine.com soit bien déclaré comme un nom de domaine utilisable par Exchange :
Get-AcceptedDomain
Vous devriez voir mondomaine.com dans la liste.
Nous allons ensuite initialiser la configuration DKIM de notre nom de domaine mondomaine.com :
New-DkimSigningConfig -DomainName mondomaine.com -Enabled $false
Note : Vous pouvez utiliser le paramètre -Keysize 2048 dans la commande précédente, pour forcer la taille de votre clé DKIM à 2048 bits. Pas de panique toutefois, si vous ne l'avez pas fait, vous pourrez toujours y apporter des modifications plus tard en production.
Bien. Maintenant, il nous reste à générer les enregistrements DNS « DKIM » que nous devrons ajouter dans notre zone DNS publique.
Pour cela, tapez la commande :
Get-DkimSigningConfig -Identity mondomaine.com | Format-List Selector1CNAME, Selector2CNAME
Dans mon cas, je vais donc devoir créer 2 enregistrements CNAME sur ma zone DNS :
Prenons 30 secondes pour analyser la structure des enregistrements selector1 et selector2 à créer. Ces deux enregistrements se composent comme suit :
selector<id>-<domaine>-<extension>._domainkey.<tenantOffice365>.onmicrosoft.com
Pour le domaine mondomaine.com, cela donnerait donc :
Il ne nous reste plus qu'à créer ces deux enregistrements CNAME dans notre zone DNS avec le paramétrage suivant :
Note : Pensez bien à ajouter un point (.) à la fin du nom de domaine, pour indiquer que vous souhaitez pointer vers selector1-mondomaine-com._domainkey.mondomaine.onmicrosoft.com (domaine externe).
Attendez maintenant quelques secondes, le temps que votre zone DNS se réplique, puis lancez la commande suivante afin d’activer l’utilisation de DKIM pour mondomaine.com.
Set-DkimSigningConfig -Identity mondomaine.com -Enabled $true
Note : Si vous obtenez une erreur, soit une faute s’est glissée dans votre enregistrement DNS de type CNAME (pensez à bien vérifier le point final), soit vous n’avez pas attendu assez longtemps pour que la réplication de votre zone DNS soit effectuée.
Pour vérifier la bonne configuration de DKIM sur votre domaine, je vous conseille d’utiliser ce lien.
Renseignez l’un des 2 sélecteurs configurés, ainsi que votre nom de domaine, puis cliquez sur le bouton « Valider DNS ».
Note : Ne saisissez que selector1, l'outil va compléter automatiquement le reste de l'enregistrement DNS. Si vous saisissez selector1._domainkey, le test échouera.
Vous pouvez donc voir que dans mon cas l’enregistrement DKIM du sélecteur 1 est valide.
Note : Pensez bien à refaire cette étape pour chacun des sélecteurs DKIM configurés pour votre domaine.
Vous pouvez également, lorsque vous êtes connectés à votre serveur Exchange en PowerShell, exécuter la commande suivante :
Get-DkimSigningConfig -Identity mondomaine.com
Je n'obtiens pas d'erreur, mon domaine est donc correctement configuré avec DKIM.
DMARC est un acronyme pour Domain-based Message Authentication, Reporting, and Conformance. DMARC utilise SPF et DKIM pour authentifier les expéditeurs d’emails, et fournit une protection supplémentaire.
En effet, SPF et DKIM permettent d’authentifier un expéditeur (ou non). Mais ils ne donnent aucune indication sur la conduite à tenir dans le cas d’une usurpation d’identité avérée.
C’est là que DMARC entre en jeu : lorsqu’on configure cet enregistrement DNS, on lui indique une politique à tenir. Cela permet au serveur de messagerie de savoir quoi faire de ces mails : faut-il les rejeter ? les mettre en quarantaine ? Ne rien faire mais l’historiser ?
A vous de le décider, et ça se passe dans DMARC.
Afin de configurer DMARC pour votre domaine, il n’est pas nécessaire de faire des manipulations PowerShell : tout se passe dans votre zone DNS.
Il vous faut créer l’enregistrement TXT suivant dans votre zone DNS :
Quelques explications :
Pct=100 indique que cette règle s’applique à 100% des emails.
adkim=s indique que la règle d'alignement avec DKIM est stricte. Seuls les mails partant du domaine mondomaine.com sont valides. Les mails en provenance d'un sous-domaine de mondomaine.com ne sont pas considérés comme valides.
aspf=s indique que la règle d'alignement avec SPF est stricte. L'en-tête "De" du mail doit correspondre exactement au nom de domaine de la commande SMTP "MAIL FROM".
Le paramètre rua est optionnel. Si vous l'indiquez comme ici, cela permettra d'envoyer des rapports sur l'activité DMARC à l'adresse mail [email protected].
Vous pouvez remplacer <policy> par 3 valeurs. Il s’agit ici de configurer la stratégie à appliquer sur le serveur de messagerie si un mail est rejeté par DMARC :
Note : Je vous conseille de commencer par la stratégie none. Cela vous permet d’analyser l’impact de DMARC sur les mails reçus lorsque vous le passerez en mode quarantaine. On ne sait pas exactement la quantité de messages que l’on risque de perdre (non délivrés dans la boîte de réception du destinataire) via une stratégie DMARC restrictive, commencez donc par la stratégie de surveillance « none ».
Afin de vérifier que votre enregistrement DMARC est bien configuré sur votre zone, je vous invite à utiliser ce lien.
Renseignez alors le nom du domaine à vérifier, et cliquez sur le bouton « Valider DNS ».
Si vous avez suivi mes recommandations sur l’implémentation de DMARC, vous devriez donc avoir un enregistrement présent avec une stratégie de type « none ».
Avant de nous quitter, vérifions maintenant ce qui se passe dans l’en-tête des mails en sortie de notre serveur de messagerie.
Je me suis donc envoyé un mail de mon adresse [email protected] à mon adresse Gmail personnelle, puis j’ai affiché l’intégralité du message pour pouvoir consulter l’en-tête.
On peut voir que le mail a bien été envoyé à partir d’un serveur Exchange Office365, nommé FRA01-PR2-obe.outbound.protection.outlook.com, et qu’il a été réceptionné par le serveur mx.google.com.
On peut également voir 4 mentions importantes dans la section Authentication-Results :
Ces mentions indiquent que la configuration SPF, DKIM et DMARC mise en place ensemble est fonctionnelle, et que ce mail est légitime. Autrement dit :
Note : On peut également voir deux points supplémentaires :
Vous n’avez maintenant plus aucune excuse pour ne pas correctement configurer vos enregistrements SPF, DKIM et DMARC.
Et si vous êtes amenés à expliquer à vos collègues ou à votre DSI l’intérêt de configurer ces enregistrements, retenez simplement que cela :
Sachez engin que Google, Microsoft et Yahoo travaille sur un nouveau standard pour toujours plus renforcer la sécurité et la délivrabilité des mails, j’ai nommé BIMI.
The post Office 365 : comment améliorer la délivrabilité et la sécurité de vos e-mails ? first appeared on IT-Connect.De millions d'appareils se retrouvent vulnérables à des failles de sécurité liées au Wi-Fi et qui touchent tous les protocoles, autant le WEP que le WPA3.
Le chercheur en sécurité Mathy Vanhoef (Université de New York Abu Dhabi) a dévoilé cet ensemble de failles de sécurité qu'il a baptisé FragAttacks (fragmentation and aggregation attacks). Ces failles de sécurité rendent les terminaux vulnérables, que ce soit les smartphones, les PC portables, les points d'accès sans-fil, mais aussi tous les appareils connectés de l'Internet des objets que l'on a tous, ou presque, à la maison. Le protocole WEP est vulnérable depuis longtemps à diverses failles, et il est touché par ces failles une fois de plus, mais les versions plus récentes des protocoles comme le WPA3 sont également affectées.
Comment expliquer qu'autant d'appareils et de versions de protocoles soient concernés ? Toujours d'après Mathy Vanhoef, il y a trois vulnérabilités découvertes qui sont des défauts de conception au sein de la norme WiFi. Néanmoins, elles sont difficiles à exploiter. Sa plus grande inquiétude réside dans les failles liées à des défauts d'implémentations du WiFi dans les appareils, car là les appareils eux-mêmes sont exposés directement.
D'après Mathy Vanhoef, un attaquant qui se trouve à portée d'un appareil vulnérable peut exploiter ces failles de sécurité pour réaliser une attaque et voler des données. D'ailleurs, il a publié une vidéo sur YouTube où il montre trois exemples d'exploitation de ces failles FragAttacks.
Au final, on obtient un bulletin d'alerte qui regroupe un ensemble de 12 CVE dont voici la liste : CVE-2020-24586, CVE-2020-24587, CVE-2020-24588, CVE-2020-26139, CVE-2020-26140, CVE-2020-26141, CVE-2020-26142, CVE-2020-26143, CVE-2020-26144, CVE-2020-26145, CVE-2020-26146, et CVE-2020-26147.
Pour en savoir plus sur ces CVE
Un site "FragAttacks" est en ligne, je vous invite à le consulter si vous souhaitez obtenir des détails techniques supplémentaires. Dans tous les cas, cela fait 9 mois qu'il a découvert ces vulnérabilités et que les différents acteurs sont au courant dans le but de préparer des correctifs de sécurité. Certains fabricants proposent déjà des correctifs depuis plusieurs mois, notamment Aruba, Cisco, Dell, Intel, Microsoft ou encore Juniper. Sur GitHub, Mathy Vanhoef a recensé les bulletins des éditeurs :
The post FragAttacks : des failles WiFi qui menacent des millions d’appareils ! first appeared on IT-Connect.À l'occasion du Patch Tuesday de mai 2021, Microsoft a corrigé une faille de sécurité critique dans la pile du protocole HTTP et plus particulièrement dans le pilote HTTP.sys. Cette faille est dite "wormable" c'est-à-dire qu'elle peut être exploitée par un ver informatique. Désormais, il existe un exploit pour tirer profit de cette faille de sécurité.
Référencée sous le nom CVE-2021-31166, la faille de sécurité touche la pile du protocole HTTP (HTTP.sys) intégrée à Windows 10 et Windows Server. Il s'avère que la faille touche HTTP.sys, un pilote en mode noyau qui permet à Windows de gérer les requêtes HTTP. Ce pilote est exploité par IIS (serveur Web), mais aussi par WinRM pour la gestion à distance, ainsi que SSDP.
Cette vulnérabilité est désormais corrigée par Microsoft et elle touche exclusivement Windows 10 en version 2004 et 20H2, ainsi que Windows Server 2004 et 20H2 également. Pour Windows Server, cela concerne aussi les installations en mode Core. Les versions antérieures ne sont pas concernées.
Microsoft recommande de patcher toutes les machines affectées dès que possible, car un attaquant, non authentifié, peut exploiter cette faille. En exploitant cette faille, il peut exécuter du code malveillant sur votre serveur, le tout à distance. Par "toutes les machines affectées", j'entends tous les serveurs et postes de travail qui exécutent une version de Windows concernée, et pas seulement celles qui exécutent un serveur IIS puisqu'il y a divers composants qui s'appuient sur ce pilote HTTP.sys.
Un chercheur en sécurité nommé Axel Souchet a publié un code de l'exploit sur GitHub en guise de proof-of-concept. Dans son exemple, l'attaque mène à un déni de service puisque la machine ciblée génère un écran bleu de la mort (BSoD).
Suite à la publication du code de cet exploit, le risque c'est qu'un ver informatique soit créé et qu'il soit en mesure de se déplacer de machine en machine en tirant profit de la faille CVE-2021-31166.
Voici le message publié par Axel Souchet sur Twitter :
I've built a PoC for CVE-2021-31166 the "HTTP Protocol Stack Remote Code Execution Vulnerability": https://t.co/8mqLCByvCp
— Axel Souchet (@0vercl0k) May 16, 2021
La bonne nouvelle dans tout ça, c'est que la faille de sécurité touche les toutes dernières versions de Windows 10 et Windows Server : deux versions pas forcément adoptées par les entreprises pour le moment.
A vos mises à jour !
The post Windows : un exploit existe pour la faille wormable située dans le pilote HTTP.sys first appeared on IT-Connect.
Voitures, vélos, scooters... : la mobilité de demain se lit sur Vroom ! https://www.numerama.com/vroom/vroom//
L'article Un hacker peut prendre le contrôle de ce babyphone mis en avant sur Amazon est apparu en premier sur Numerama.
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article Pour se préserver, le milieu cybercriminel fait mine de découvrir que les rançongiciels, c’est mal est apparu en premier sur Numerama.
QNAP alerte ses clients sur une nouvelle vague d'attaques qui touchent les NAS de la marque. En cause, des mots de passe faibles, mais une faille dans Roon inquiète et pourrait être exploitée par un ransomware.
Le fabricant de NAS QNAP informe que certains de ses clients sont victimes du ransomware eChoraix, sans préciser combien. QNAP précise que les appareils qui utilisent un compte avec un mot de passe faible sont vulnérables à cette attaque. Voici les recommandations de QNAP pour vous protéger contre cette attaque (et les attaques de manière générale, en fait) :
Sur son site, QNAP détaille la marche à suivre pour mettre en œuvre ses recommandations.
Nous apprenons également que le paquet Roon de QNAP contient une faille de sécurité Zero Day activement exploitée. Cependant, il n'y aurait pas de liens entre les attaques avec le ransomware eChoraix et cette faille dans Roon. En tout cas, pas pour le moment, mais ce n'est peut être qu'une question de temps...
Qu'est-ce que Roon sur QNAP ? Le paquet tiers Roon de QNAP sert à transformer votre NAS en véritable jukebox puisqu'il permet de créer un serveur musical pour gérer votre bibliothèque musicale et de lire de la musique facilement.
Le serveur Roon est un paquet tiers et la version affectée par cette faille de sécurité est la version 2021-02-01 (et les versions précédentes). D'ailleurs, ce paquet est disponible aussi chez d'autres fabricants comme Synology et ASUSTOR. En attendant que Roon Labs distribue une mise à jour de son paquet Roon, il est recommandé de désactiver le Roon Server sur votre NAS. D'autant plus qu'il est probable que votre Server Roon soit accessible sur Internet, si vous l'utilisez en mobilité.
Ce n'est pas la première fois que le ransomware eChoraix s'attaque aux NAS QNAP : il y avait déjà eu une vague d'attaques en juin 2019 et en juin 2020. Ce ransomware est également connu sous le nom de QNAPCrypt.
Le mois dernier, il y avait déjà eu une vague d'attaques sur les NAS QNAP avec le ransomware Qlocker. Ce dernier exploitait une faille de sécurité au sein du paquet Multimedia Console de QNAP. En cinq jours, ce ransomware avait généré plus de 260 000 dollars de gain.
Enfin, il y a quelques jours, QNAP a également corrigé une vulnérabilité importante au sein de l'application Malware Remover. Si vous avez un NAS QNAP : il est temps de passer en revue votre configuration
La semaine dernière, Adobe a publié un ensemble de correctifs à destination de ses produits dans le but de corriger 44 failles de sécurité, dont une faille Zero Day activement exploitée dans Adobe Reader.
Adobe a publié un total de 12 correctifs pour combler 44 failles de sécurité au total, dans différents produits dont voici la liste : Experience Manager, InDesign, Illustrator, InCopy, Adobe Genuine Service, Acrobat et Reader, Magento, Creative Cloud Desktop, Media Encoder, After Effects, Medium, et enfin Animate.
Intéressons-nous à la vulnérabilité qui touche Adobe Reader et qui est la plus critique, même si les autres ne doivent pas être négligées pour autant.
La faille de sécurité CVE-2021-28550 est une faille Zero Day activement exploitée par les pirates informatiques et qui touche Adobe Reader, le célèbre lecteur PDF d'Adobe. Cette faille de sécurité touche aussi bien Adobe Reader sous Windows que sous macOS, autant pour la version gratuite que la version payante. Néanmoins, les attaques relevées jusqu'ici concernent uniquement des machines sous Windows.
Les chercheurs en sécurité de la Zero Day Initiative expliquent que du code malveillant aurait pu être exécuté sur la machine cible si l'utilisateur dispose d'une version vulnérable d'Adobe Reader. Le code malveillant sera exécuté dans le contexte du processus d'Adobe Reader. Pour mener à bien cette attaque, il suffit à l'attaquant de créer un fichier PDF piégé et conçu pour exécuter le code malveillant à l'ouverture.
Au-delà de cette faille de sécurité Zero Day, il y a eu d'autres failles de sécurité importantes corrigées dans Adobe Reader.
Si vous utilisez Adobe Acrobat ou Adobe Reader, ne tardez pas pour mettre à jour le logiciel sur votre machine. Pour Acrobat DC et Acrobat Reader DC, la version patchée est la version 2021.001.20155.
Pour rappel, Microsoft a également publié son Patch Tuesday de Mai 2021, vous pouvez retrouver toutes les informations utiles dans notre article : Patch Tuesday Mai 2021
The post Une faille Zero Day découverte dans Adobe Reader : un correctif est disponible first appeared on IT-Connect.
Voitures, vélos, scooters... : la mobilité de demain se lit sur Vroom ! https://www.numerama.com/vroom/vroom//
L'article Comment vérifier sans risque la solidité de son mot de passe ? est apparu en premier sur Numerama.
Bulletin d’actualité du 10/05/2021 Nous voici de nouveau ensemble dans notre rendez-vous de fin de semaine pour revenir sur les différents bulletins de sécurité publiés par le CERT-FR ! Durant la période du 3 mai au 9 mai 2021, le CERT-FR (Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques en France) a …
Voitures, vélos, scooters... : la mobilité de demain se lit sur Vroom ! https://www.numerama.com/vroom/vroom//
L'article FragAttacks : 12 vulnérabilités dans les objets Wi-Fi provoquent un flot de mises à jour est apparu en premier sur Numerama.
Voitures, vélos, scooters... : la mobilité de demain se lit sur Vroom ! https://www.numerama.com/vroom/vroom//
L'article Un remboursement de 490€ des impôts ? Attention à cet email de phishing est apparu en premier sur Numerama.
Faisant suite à mon autre article "Détails des durcissements des sysctl sous Linux : sysctl système".
Nous allons dans cet article nous intéresser aux durcissements recommandés par l'ANSSI sur les sysctl réseau dans son guide Recommandation de configuration d'un système GNU/Linux. Je vais dans cet article suivre la même approche que dans l'article précédent, dans lequel vous trouverez également quelques exemples d'utilisation de la commande sysctl pour lire et écrire des paramètres.
Pour les paramètres sysctl au niveau réseau, celles-ci peuvent être appliquées à plusieurs niveaux, ce qui détermine le nom précis du paramètre à modifier. On peut par exemple différencier les paramètres s'appliquant sur les interfaces IPv4 (net.ipv4.X.X) ou IPv6 (net.ipv6.X.X), mais également spécifier une interface précise (net.ipv4.eth0), les mots-clés all et default sont utilisés respectivement pour appliquer un paramètre sur toutes les interfaces ou pour les interfaces nouvellement créées (configuration par défaut si rien n'est spécifié).
Ça, c'était la théorie, la réalité est un chouilla plus obscure (voir ce mail https://marc.info/?l=linux-kernel&m=123606366021995&w=2) et je vous déconseille, pour résumer, de paramétrer des valeurs différentes pour le all et le default d'une même sysctl sous peine de vous retrouver avec des comportements difficiles à déboguer ou à comprendre.
Le premier durcissement généralement recommandé en ce qui concerne les sysctl réseau est la désactivation de l'IP forwarding. Ce sysctl, lorsqu'il est à 1, permet au serveur de faire transiter des paquets d'une interface vers une autre, à l'image d'un routeur. Lorsque cette fonctionnalité n'est pas utile au fonctionnement du serveur, il est recommandé de désactiver l'IP forwarding :
FreshRSS 
net.ipv4.ip_forward = 0
Ainsi, le serveur ne sera pas autorisé à faire du routing, c'est-à-dire faire suivre des paquets d'une interface vers une autre, et ne pourra être utilisé comme un routeur entre deux réseaux. Dans le cas où votre serveur dispose de deux interfaces, dont une vers un réseau non maitrisé (Internet par exemple), les paquets provenant d'internet ne pourront atteindre directement les autres serveurs du réseau non exposé (deuxième interface de votre serveur), car le serveur ne fera pas suivre ces paquets, même s'il connait la route par lesquels ils sont censés passer.
Dans le cas où ce sysctl est à 1 (IP forwarding activé), alors les paquets reçus par le serveur sans lui être destinés, mais pour lesquels il connait une route seront automatiquement envoyés sur cette route, le serveur pourrait alors servir de pont entre deux réseaux sans que cela ne soit voulu.
À noter que ce paramétrage ne protège pas de tout, si votre serveur est compromis ou si l'application web qu'il héberge est ciblée par une attaque SSRF (Server Side Request Forgery), alors les IP du réseau "interne" pourront tout de même être atteintes.
Le filtrage par chemin inverse ou Reverse Path Filtering est un mécanisme du noyau Linux consistant à vérifier si l'adresse source indiquée dans les paquets reçus par une interface est routable par cette interface. En d'autres termes, lorsque notre serveur va recevoir un paquet sur une interface, il va l'ouvrir, regarder quelle est son adresse IP source, puis utiliser sa table de routage pour voir s’il contient une route capable de joindre cette IP source pour l'interface par laquelle il a reçu ce paquet (qui deviendra une IP destination en cas de réponse :)). On pourrait décrire ce mécanisme comme un contrôle de cohérence du serveur qui reçoit un paquet, le serveur cherche à vérifier s'il est normal ou cohérent de recevoir un paquet avec telle IP source sur cette interface.
Dans le cas où ce "contrôle de cohérence" échoue, le paquet est supprimé ("droppé" pourrait-on dire en bon français). L'ANSSI recommande d'activer cette fonctionnalité en mettant une valeur 1 aux sysctl suivants :
net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1
À noter que les systèmes Red Hat possèdent une option supplémentaire (2) permettant d'accepter un paquet si son IP source est routable par n'importe quelle interface du serveur, et non pas uniquement par l'interface ayant réceptionné le paquet analysé.
Le reverse path filtering est en réalité un mécanisme créé pour limiter les attaques par Déni de Service (Denial of Service ou DoS). L'une des techniques de déni de service profite du Three way Handshake TCP combiné à de l'IP spoofing. Plus clairement, l'attaquant va envoyer des milliers de paquets TCP SYN au serveur avec des adresses IP usurpées ou n'existant pas. Le serveur va alors renvoyer à ces adresses IP un paquet SYN/ACK et n'obtiendra jamais de réponse. Ainsi, les connexions resteront ouvertes pendant un long moment, ce qui les rendra indisponibles pour de nouvelles connexions légitimes. Un peu comme si l'on réservait toutes les tables d'un restaurant sur une semaine sans venir y manger :).
Ce mécanisme est décrit précisément dans la RFC3704 : https://tools.ietf.org/html/rfc3704
Lorsqu'une telle attaque intervient avec un rp_filter activé, la plupart des paquets seront droppés dès leur réception, car le système remarquera qu'ils ne sont pas légitimes pour arriver sur une interface réseau donnée.
L'ICMP (Internet Control Message Protocol) est un protocole qui ne se réduit pas au ping, les paquets echo request (paquet ICMP de type 8) et echo reply (paquet ICMP de type 0) observés lorsqu'on fait un ping ne sont qu'une petite partie des capacités de ce protocole. Parmi les fonctions méconnues de ce dernier, les paquets ICMP de type 5, nommés Redirect Messages sont utilisés afin d'avertir un hôte nous ayant envoyé un message qu'une autre route est possible (et plus rapide) pour joindre l'hôte qu'il cherche à contacter.
Ce mécanisme se nomme l'ICMP redirect est n'est utilisé qu'à de rares occasions (voire jamais) sur un système d'information moderne correctement configuré, et comme tout en sécurité, si c'est inutile, c'est à désactiver.
net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0
En soit, ce mécanisme de l'ICMP redirect permet donc à un hôte recevant un paquet de faire passer son correspondant par un autre chemin réseau, en lui indiquant une nouvelle route qu'il intégrera durablement dans sa table de routage, un attaquant utilisant ce mécanisme envers un système peut donc modifier le chemin qu'emprunterons les futurs paquets, et pourquoi pas provoquer une attaque de type Man in the Middle ou une simple interruption de service. C'est pourquoi l'ANSSI recommande de désactiver l'acceptation et l'envoi de paquets ICMP redirect.
Le sysctl secure_redirects correspond à une option permettant à l'hôte d'accepter un paquet ICMP redirect uniquement si celui provient de l'adresse IP d'une des passerelles enregistrées au niveau de la configuration réseau. On cherche ici a maintenir l'utilisation de l'ICMP redirect, mais à réduire les hôtes pouvant nous envoyés de tels paquets à une liste de confiance.
Pour l'expéditeur d'un paquet IP, le mécanisme du source routing consiste en la possibilité de définir la route prise par ce paquet sur le réseau. Alors que dans la plupart des cas, un paquet IP est envoyé par son expéditeur sur la passerelle réseau, qui définit ensuite en fonction de sa table de routage quel sera le prochain saut ou la prochaine passerelle à atteindre. Dans le cas d'un source routing, l'expéditeur peut inclure dans le paquet IP une liste d'adresses IP par lequel le paquet devra passer et ainsi modifier la décision nominale des différentes passerelles du réseau qui seront traversées. En d'autres termes, l'expéditeur peut manipuler une partie de la décision des passerelles concernant le routage des paquets. Également, le chemin par lequel le paquet est passé peut être transmis à son destinataire, qui prendra potentiellement ce chemin pour ses réponses. Les guides de bonnes pratiques recommandent de désactiver cette fonctionnalité :
net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0
Dans les faits, le source routing au niveau d'un paquet IP n'est presque jamais utilisé, il peut être utile pour du débogage (notamment pour du traceroute). En plus d'aider à dresser une cartographie du réseau, le source routing reste intéressant pour un attaquant, car il peut permettre de joindre une machine sur un réseau qui n'est, selon les tables de routages habituelles, pas accessibles au travers un serveur ayant deux interfaces réseau par exemple.
L'IANA définit un paquet "martien" comme un paquet qui arrive sur une interface n'utilisant pas le réseau source ou destination du paquet reçu. Pour Linux, il s’agit de tout paquet qui arrive sur une interface qui n’est en aucun cas configurée pour ce sous-réseau.
net.ipv4.conf.all.log_martians = 1
L'objectif de la journalisation des IP "anormales" est justement de pouvoir investiguer, voire alerter et réagir sur un comportement réseau qui n'est pas usuel. Il est en effet courant qu'un attaquant produise ce genre de comportements anormaux lors d'une phase de cartographie, d'une analyse comportementale d'un hôte ou d'un service pour en déterminer la nature (version, technologie précise), voir de causer un bug ou d'exploiter une vulnérabilité.
Dans les faits, la journalisation d'un tel paquet aura aussi de grandes chances de provenir d'une erreur de configuration au niveau des routes et des routeurs du réseau, le but pourrait donc également être d'avertir les administrateurs d'un potentiel problème de routage.
La RFC 1337 est une RFC de type Informationnal (non obligatoire en somme) qui décrit un bug théoriquement possible sur des connexions TCP, ce bug est nommé "TIME-WAIT Assassination hazards". En somme, il s'agit d'une "lacune" dans la conception de TCP/IP qui rend possible la fermeture d'une connexion en TIME-WAIT par un paquet provenant d'une ancienne session TCP (arrivé en retard ou en dupliqué à cause d'une latence quelconque). Ce cas de figure théorique peut donc perturber des communications établies entre un client et un serveur :
net.ipv4.tcp_rfc1337 = 1
Cette protection vise donc à se protéger d'une anomalie potentielle dans les communications TCP, qui n'est pas le fruit d'une attaque ciblée visant à avoir un résultat précis.
Certains routeurs sur Internet ignorent les normes établies dans la RFC 1122 et envoient de fausses réponses aux trames de diffusion. Normalement, ces violations sont journalisées via les fonctions de journalisation du noyau, mais si vous ne voulez pas voir ces messages d'erreur dans vos journaux, vous pouvez activer cette variable, ce qui conduira à ignorer totalement tous ces messages d'erreur.
La RFC 1122 normalise ce que toute machine terminale (host, par opposition à routeur) connectée à l'Internet devrait savoir. Je vous invite à consulter la description de Stéphane Borztmeyer sur son blog pour plus de détails : RFC 1122: Requirements for Internet Hosts - Communication Layers
net.ipv4.icmp_ignore_bogus_error_responses = 1
L'objectif est donc simplement d'économiser un tout petit peu d'espace disque et d'éviter la présence de certains évènements inutiles dans les journaux. Peu d'impact en termes de sécurité donc.
Les ports éphémères sont les ports utilisés comme port source lorsqu'un système initie une connexion vers un serveur (alors nommés "port client"). Ces ports peuvent également être utilisés par certains protocoles dans une seconde phase d'échange avec le client après un premier échange sur un port "officiel". C'est notamment le cas pour les protocoles TFTP ou RPC. Sur les serveurs à haut trafic (reverse proxy ou load balancer), il est recommandé d'élargir la plage de port par rapport à celle par défaut :
net.ipv4.ip_local_port_range = 32768 65535
À noter que 65535 est la valeur la plus haute pouvant être acceptée. La valeur la plus basse (ici 32768) peut aller jusqu'à 0, gardez cependant à l'esprit que de nombreux ports sont réservés à des usages spécifiques (22 pour SSH, 80 pour HTTP, etc.). Il est donc plus sage de ne pas empiéter sur ces ports-là.
Le gain n'est pas très significatif, mais ce faisant, nous permettons au serveur d'établir plus de connexions et limitons ainsi les risques de saturation de ces ports pouvant être provoqués intentionnellement (attaque par déni de service) ou non (trafic réseau exceptionnellement élevé).
Les SYN cookies sont des valeurs particulières des numéros de séquences initiales générés par un serveur (ISN: Initial Sequence Number) lors d'une demande de connexion TCP. Les bonnes pratiques de sécurité recommandent leur activation au niveau des échanges réseau :
net.ipv4.tcp_syncookies = 1
L'activation des SYN cookies au niveau du système permet de se protéger des attaques par inondation de requêtes SYN (SYN flooding) qui consiste à ouvrir un très grand nombre de connexions sur un serveur à l'aide de requêtes SYN, sans jamais donner suite au Three Way Handshake TCP (SYN, SYN/ACK, ACK). Le serveur maintient donc un ensemble de connexions en attente (attente de réception d'un ACK après envoi d'un SYN/ACK), ce qui finit par saturer les connexions disponibles pour les clients légitimes.
Ce mécanisme permet au serveur de garder la "tête froide" lorsqu'il est ciblé par une telle attaque, mais il n'est pas conçu pour améliorer les capacités du serveur dans un contexte normal de fonctionnement (autre qu'une attaque par SYN flood).
Attention toutefois : les SYN cookies ne sont en théorie pas conforme au protocole TCP et empêchent l'utilisation d'extension TCP, ils peuvent entraîner une dégradation sérieuse de certains services (par exemple le relais SMTP). Si vous voulez tester les effets des SYN cookies sur vos connexions réseau, vous pouvez paramétrer ce sysctl sur 2 pour activer sans condition la génération de SYN cookies.
Dans le cas où l'IPv6 n'est pas activement utilisé au sein de vos réseaux locaux (c'est très très souvent le cas), il est tout simplement recommandé de désactiver la prise en compte de l'IPv6 au niveau du noyau Linux.
net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1
La désactivation pure et simple de l'IPv6 permet de réduire la surface d'attaque du serveur, ce qui est l'un des principaux fondements de la sécurité. Dans bien des cas, l'IPv6 peut être utilisé pour détourner du trafic réseau, réaliser des attaques par déni de service ou contourner des politiques de filtrage lorsqu'il n'est pas activement utilisé et pris en compte dans la configuration et le durcissement global d'un système d'information.
Dans le cas, très rare selon moi, où vous utilisez de manière active l'IPv6 dans vos infrastructures internes, différents paramètres peuvent être utilisés afin de durcir la configuration de vos systèmes.
En IPv6, les router advertisements sont des paquets régulièrement envoyés par les routeurs d'un réseau pour s'annoncer aux éventuels nouveaux venus. Les informations contenues dans les router advertisements permettent à un nouvel hôte connecté de récupérer les caractéristiques essentielles du réseau, passerelles par défaut, routes et le préfixe servant à se forger une adresse IPv6 en auto configuration.
Dans le cas où les adresses IPv6 sont établies de manière statique sur vos réseaux, il est recommandé de désactiver la prise en charge des router advertisements afin de ne pas laisser la possibilité à un attaquant d'utiliser leur prise en charge sur les systèmes du réseau pour lui-même déterminer la configuration IPv6 de ces systèmes . En effet, quoi de plus simple que de se faire passer pour un routeur ou une passerelle pour réaliser une attaque par l'homme du milieu ?
# Ne pas accepter les router preferences par router advertisements net.ipv6.conf.all.accept_ra_rtr_pref = 0 net.ipv6.conf.default.accept_ra_rtr_pref = 0 # Pas de configuration automatique des prefix par router advertisements net.ipv6.conf.all.accept_ra_pinfo = 0 net.ipv6.conf.default.accept_ra_pinfo = 0 # Pas d’apprentissage de la passerelle par router advertisements net.ipv6.conf.all.accept_ra_defrtr = 0 net.ipv6.conf.default.accept_ra_defrtr = 0 # Pas de configuration auto des adresses à partir des router advertisements net.ipv6.conf.all.autoconf = 0 net.ipv6.conf.default.autoconf = 0
En IPv6, le router sollicitation est un type de message qui permet à un hôte de demander à tous les routeurs présents sur le réseau local de lui envoyer un Router Advertisement, afin qu'il l'enregistre dans sa liste de voisins et qu'il puisse récupérer les éléments essentiels du réseau IPv6. Dans le cas où les adresses IPv6 sont paramétrées en statique, il est recommandé de désactiver ce mécanisme :
net.ipv6.conf.all.router_solicitations = 0 net.ipv6.conf.default.router_solicitations = 0
Pour être plus précis, ce sysctl configure le nombre de router sollicitation à envoyer sur le réseau avant de considérer qu'il n'y a pas de routeur sur le réseau. Désactiver ce comportement lorsque les adresses IPv6 sont statiques permet donc d'éviter du trafic inutile, mais également qu'un attaquant puisse répondre à ces sollicitations en vue de se faire passer pour un routeur IPv6 auprès de votre serveur, lui facilitant ainsi le travail pour la réalisation d'une attaque de type man in the middle.
L'adressage IPv6 permet d'utiliser plusieurs adresses par interface. À moins que vous n'ayez un besoin particulier nécessitant plusieurs adresses IPv6 unicast global par interface, il est recommandé de paramétrer ce sysctl à 1, ce qui limite à 1 le nombre d'adresses unicast global par interface (16 possibles dans la configuration par défaut).
net.ipv6.conf.all.max_addresses = 1 net.ipv6.conf.default.max_addresses = 1
Attention, positionner ces sysctl à 0 rend illimité le nombre d'adresses possibles, ce qui finira par avoir un impact sur les performances de votre serveur.
J'ai toutefois du mal à trouver des risques concrets relatifs à la non-application de ce paramètre. D'après ma compréhension du paramètre dans son état par défaut et du fonctionnement de l'IPv6, sa non-application entrainera la possibilité pour un attaquant de générer la création d'une adresse IPv6 sur sa cible puisque dans un environnement "normal", les 16 slots disponibles sur l'interface IPv6 ne seront pas toutes utilisées. En principe on laisse donc au travers la configuration par défaut, des paramètres non utilisés qui n'attendent qu'à recevoir les faux router avertissements d'un attaquant. Alors que si le nombre d'adresses IPv6 est limité à 1 par interface est que celle-ci est déjà configurée lors de la venue de l'attaquant (en statique qui plus est), ce dernier n'aura pas de porte d'entrée possible.
N'hésitez pas à ajouter des informations de compréhension supplémentaires dans les commentaires si vous en avez à ce sujet :).
Voilà, nous avons fait le tour des durcissements sysctl recommandés par l'ANSSI dans son guide Recommandations de configuration d'un système GNU/Linux. Vous aurez compris que les raisons de certains durcissements sont faciles à appréhender alors que d'autres sont plus bien abstraits ou répondent à des cas très spécifiques. Quoi qu'il en soit j'espère vous avoir apporté une lumière supplémentaire sur ces éléments.
N'hésitez pas à signaler toute erreur ou précision technique dans les commentaires
Nous allons dans cet article nous intéresser aux durcissements du noyau proposés par le guide de configuration de l'ANSSI à travers les sysctl. Les guides de bonnes pratiques et de configuration de l'ANSSI sont pour la plupart très pertinents, mais il arrive qu'ils manquent de détails et que la cohérence de certains durcissements puisse être difficile à appréhender. Je vais donc ici m'efforcer de décortiquer les recommandations 22 et 23 du Guide Recommandation de configuration d'un système GNU/Linux de l'ANSSI qui portent sur les paramétrages des sysctl réseau et système en vue du durcissement d'un noyau Linux. Nous parlerons dans cet article des sysctl système et un prochain article portera sur les sysctl réseau.
J'essaierai notamment de mettre en avant les implications en termes de sécurité et les attaques qu'un durcissement permet d'éviter, sans oublier les potentiels effets de bords si ceux-ci sont connus et les éventuelles questions qui restent en suspens après avoir tenté de creuser ce sujet.
Sur les OS Linux, sysctl est utilisé afin de consulter et modifier les paramètres du noyau, cela nous permet donc de configurer certains comportements du noyau comme la prise en compte de l'IPv6 sur nos interfaces réseau ou l'activation de l'ASLR. Les paramètres utilisables sont ceux listés dans le répertoire /proc/sys.
On parle souvent de sysctl pour décrire une clé de configuration paramétrable par la commande sysctl. Ne soyez donc pas étonné de lire "On configure le sysctl net.ipv4.ip_forward à 0" pour indiquer que la clé de configuration net.ipv4.ip_forward doit être définie à 0, par exemple
Pour les systèmes utilisant systemd, la configuration des sysctl se trouve dans /etc/sysctl.d/.conf, /usr/lib/sysctl.d/.conf. et /etc/sysctl.conf.
Attention, depuis récemment (2017) il se peut que certains systèmes utilisant systemd n'appliquent plus les configurations sysctl indiquées dans /etc/sysctl.conf. Seuls les fichiers ayant une extensions .conf et situés dans les répertoires /etc/sysctl.d ou /usr/lib/sysctl.d sont appliqués.
A lire également : Détails des durcissements des sysctl sous Linux : sysctl réseau
Il existe deux possibilités de modification d'un sysctl, soit de façon temporaire, c'est à dire valable jusqu'au prochain redémarrage, soit de façon persistante, c'est à dire qui persiste après un redémarrage.
Pour modifier une configuration sysctl de façon temporaire, on peut modifier à chaud la valeur stockée dans le fichier correspondant au sysctl à modifier, par exemple :
# echo 1 > /proc/sys/kernel/sysrq
Ou utiliser la commande sysctl pour faire cette même opération :
# sysctl -w kernel.sysrq=1
Pour modifier un sysctl de façon persistante, il faut aller modifier le fichier configuration (/etc/sysctl.d/99-sysctl.conf, ou autre fichier finissant par .conf dans le même dossier) et y modifier ou ajouter notre valeur pour le sysctl souhaité :
Pour être techniquement plus précis, une configuration modifiant un sysctl est appelée clé. Ici la clé est donc net.ipv4.conf.default.log_martians et 0 est la valeur associée à cette clé.
Pour afficher l'ensemble des sysctl actuellement utilisées et appliquées, la commande suivante est à utiliser :
# sysctl -a
Enfin pour récupérer un sysctl précis, la commande suivante est à utiliser :
# sysctl -n net.ipv4.conf.eth1.log_martians
Les SysReq ou Magic System Request Key sont une fonctionnalité du noyau Linux permettant, via une combinaison de touche réalisable à tout moment, de lancer des commandes bas niveau, par exemple afin de pouvoir redémarrer un système bloqué sans corrompre le système de fichiers ou tuer un programme paralysant les ressources du système. Parmi les actions réalisables :
À noter que même si les SysReq sont activées, une partie seulement de ces actions sont réalisables dans la configuration par défaut. D'autres requièrent une configuration spécifique. Cette combinaison de touche clavier doit être réalisée sur un terminal "physique", entendez par là qu'une connexion SSH ne sera pas suffisante, en théorie :).
Il existe en effet une petite astuce permettant d'exécuter des SysReq depuis une connexion distante, et cela en utilisant directement une fonctionnalité "native" de sysctl, le fichier /proc/sysrq-trigger. Si l'on souhaite redémarrer le système par exemple, il faut envoyer l'instruction "b", et donc :
echo "b" > /proc/sysrq-trigger
Ce fichier n'est cependant modifiable que par l'utilisateur root :
[email protected]:~$ ls -al /proc/sysrq-trigger --w------- 1 root root 0 juil. 28 2018 /proc/sysrq-trigger
Pour gérer cela, il faut se rendre dans le fichier /proc/sys/kernel/sysrq ou utiliser la clé kernel.sysrq dans un fichier de configuration sysctl.
Positionner la valeur 1 permet d'activer l'utilisation des SysReq (valeur par défaut sur une majorité de systèmes), positionner la valeur 0 interdit toute utilisation des SysReq. Lorsque la valeur est autre que 0 ou 1, c'est que certaines commandes sont autorisées, d'autres non, à utiliser en connaissance de cause donc. À nouveau, comme cette fonctionnalité est très rarement utilisée, voir inconnue des sysadmins la plupart du temps, mieux vaut la désactiver :
kernel . sysrq = 0
L'ANSSI recommande en effet de positionner la valeur de cette clé à 0 afin de désactiver totalement leur utilisation. On peut imaginer les effets de bords possibles grâce à ces commandes, notamment en ce qui concerne la possibilité de tuer des processus, afficher les registres CPU, démonter un système de fichier, redémarrer la machine, etc. À noter que le plus grand danger reste l'exploitation de ces SysReq à partir d'un terminal physique par un utilisateur non privilégié, mais leur utilisation n'est pas forcément restreinte au terminal physique comme je l'ai indiqué précédemment.
La frontière entre physique et virtuel s'étant quelque peu estompée ces dernières années, j'ignore par exemple si l'on peut lancer des SysReq à partir d'un clavier virtuel, dans le cas d'un accès distant VNC, via une console d'hyperviseur type VMWare/Proxmox, etc.
Par défaut, le système va réaliser un core dump (extraction de la mémoire) des processus s'arrêtant brusquement, cela est notamment pratique pour du debug, avoir une photo à l'instant du crash permet de voir quelles données ou actions ont potentiellement causé ce crash.
Cependant, ces dumps sont exécutés par le kernel et écrits sur le système avec les droits de l'utilisateur courant (celui ayant lancé la commande). Dans le cadre de l'utilisation d'un exécutable setuid ou setgid, l'extraction mémoire contiendra les informations d'un programme exécuté avec les droits d'un autre utilisateur, probablement avec un plus haut niveau de privilège que l'utilisateur courant ou root, mais sera écrit sur le système avec les droits de l'utilisateur courant (non privilégié). Ainsi, des informations sensibles, permettant potentiellement une élévation de privilège, pourront se trouver dans ce type de fichier et lisible par l'utilisateur courant.
Afin de contrôler ce comportement, on peut utiliser la clé fs.suid_dumpable afin de ne pas produire de core dump pour les exécutables possédant un bit setuid ou setgid.
fs.suid_dumpable = 0
L'ANSSI recommande de passer la valeur de la clé fs.suid_dumpable à 0 pour désactiver tout core dump sur les exécutables possédant un bit setuid ou setgid, et ainsi éviter d'éventuelles fuites de données sensibles concernant les attributs, les fichiers accédés ou d'autres actions d'un utilisateur privilégié.
Une des vulnérabilités courantes sous Linux concernant les liens symboliques est le symlink-based time-of-check-time-of-use race (ou symlink race condition). Il s'agit d'un delta de temps entre le moment où un fichier est contrôlé (pour voir si les droits d'accès sont suffisants) et celui où il est utilisé par un programme.
Pendant le laps de temps où ces deux opérations sont effectuées, un utilisateur malveillant peut créer un lien symbolique portant le nom de ce fichier et ainsi manipuler une partie de l'exécution du programme, qui s'exécute idéalement avec un plus haut niveau de privilège. Un exemple courant fourni comme explication est le suivant :
Dans cet exemple, le programme contrôle les permissions d'un fichier file avec l'instruction access() en C. Puis, dans un deuxième temps si les permissions le permettent, il va écrire dans ce fichier. Dans le cadre d'une attaque, l'attaquant va laisser le fichier tel quel pour la première opération (par exemple créer lui-même le fichier file en permission 777 pour que le programme constate qu'il peut y écrire). Puis, il va remplacer ce fichier par un lien symbolique pointant vers /etc/passwd. Le programme s'exécutant avec un haut niveau de privilège va alors exécuter sa deuxième instruction et écrire dans le fichier file, qui sera en réalité/etc/passwd.
Un très bon labo est mis à disposition sur ce Gitlab Ranjelikasah/ace-Condition-Seedsecurity, je vous le recommande si vous souhaitez expérimenter par vous-même
Ce type d'attaque est notamment dangereuse sur les setuid/setgid, qui permettent d'exécuter un binaire avec les droits root (ou d'un autre utilisateur en fonction de leur configuration). C'est pourquoi il est recommandé de durcir ces sysctl qui ont plusieurs effets concernant les liens symboliques et les setuid.
Concernant les hardlinks et pour un utilisateur système créant un lien, l'une des conditions suivantes doit être remplie :
Concernant les symlinks et les processus qui sont amenés à suivre des liens symboliques vers des répertoires world-writable qui ont le sticky bit activé :
Si vous avez bien compris le fonctionnement de l'attaque présentée, vous comprendrez rapidement quelle devient impossible si ces conditions sont imposées via le durcissement sysctl :
fs.protected_symlinks = 1 fs.protected_hardlinks = 1
Ce paramétrage permet en somme de durcir les conditions d'utilisation des symlinks et des hardlinks afin de se protéger des différentes attaques permettant une élévation de privilège
L'ASLR (Address Space Layout Randomization) est un mécanisme permettant de limiter les effets et de complexifier l'exploitation des attaques de type buffer overflow (dépassement de tampon). L'objectif est ici de placer la zone de données dans la mémoire virtuelle de façon aléatoire, changeant ainsi sa position à chaque exécution.
L'exploitation de buffer overflow consiste notamment à contrôler une partie des registres CPU afin de modifier le flux d'exécution d'un programme. Cela passe, entre autres, par le contrôle du registre EIP (Extended Instruction Pointer) qui permet d'indiquer à quel offset (adresse mémoire) la prochaine instruction à exécuter se trouve. En contrôlant le registre EIP, l'attaquant peut indiquer au programme de sauter à un offset précis et dont le contenu est sous son contrôle, notamment s'il a réussi à injecter du code malveillant (shellcode) à cet endroit de la mémoire. En modifiant la répartition et le positionnement des instructions, de la pile (stack), du tas (heap) et autres, en mémoire, l'attaquant n'est plus en capacité de pointer vers son shellcode car celui-ci ne sera jamais au même endroit à chaque exécution.
Pour activer l'ASLR, on peut utiliser la clé kernel.randomize_va_space et y positionner la valeur 2, qui permet de positionner de façon aléatoire (aka randomiser :/ ) la stack (pile), les pages CDSO (virtual dynamic shared object), la mémoire partagée et le segment de données (data segment), qui contient les variables globales et statiques initialisées par le programme. Positionner la valeur 1 aura le même effet, sauf pour le segment de données. La valeur 0 désactive l'ASLR.
kernel.randomize_va_space = 2
Pour plus d'information sur les buffer overflow, je vous oriente vers les très bons articles (en français) d'0x0ff :
Une vulnérabilité de type NULL pointer dereference est le fait pour un programme d'utiliser un pointeur non initialisé (valant NULL) ou pointant vers une adresse mémoire inexistante (0x00000000). De fait, lorsque ce programme utilisera ce pointeur dans ses instructions, cela causera un crash. Dans le contexte d'exécution du noyau ou d'un programme à haut niveau de privilège, le fait de déclencher intentionnellement l'utilisation d'un pointeur NULL par un attaquant lui permet de faire crasher le programme, voir le système.
Cependant, si l'attaquant parvient à identifier l'adresse mémoire du pointeur en question et à la manipuler pour y insérer les données de son choix avant qu'elle ne soit utilisée activement par le noyau ou un programme à haut niveau de privilège, alors il pourra contrôler son utilisation dans le programme exécuté, menant à une potentielle élévation de privilège.
En C, un pointeur est une variable qui permet de stocker non pas une valeur ("ABC" ou 12,28), mais une adresse mémoire. Lorsqu'un programme démarre, le système lui alloue une zone mémoire dans laquelle il peut s'organiser. Cette zone mémoire est constituée de "cases" de 8 bits (octets). Chacune de ces cases (appelées blocs) est identifiée par un numéro : son adresse. On peut alors accéder à une variable soit par son nom "agePersonne", soit par l'adresse du premier bloc alloué à la variable en question, c'est-à-dire son pointeur.
Il se trouve que le noyau a tendance à plutôt utiliser les adresses mémoires dites "basses", si l'attaquant parvient à manipuler les pointeurs visant des blocs d'adresses mémoires "basses", alors il a plus de chances de trouver un bloc d'adresse qui sera ensuite utilisé par le noyau.
La clé vm.mmap_min_addr est donc une constante qui permet d'empêcher les utilisateurs non privilégiés de créer des mapping mémoires en dessous de cette adresse. Elle permet de définir l'adresse minimale qu'un processus n'ayant pas les droits root peut mapper, adresse que nous allons rehausser par rapport à sa valeur par défaut (0) :
vm.mmap_min_addr = 65536
Attention toutefois à bien tester le fonctionnement de vos programmes et applications avec ce paramètre avant de passer en production.
Sous Linux (et Windows), le PID (Process IDentifier) est un numéro unique assigné à un processus en cours d'exécution. Il permet son identification parmi d'autres processus pour leur gestion, par exemple lorsque l'on utilise les commandes ps ou kill.
Comme pour les ports clients, les PID sont en nombre limité sur un système. Il se peut donc que toute la plage de PID disponible soit saturée par un dysfonctionnement ou une attaque. Dès lors, aucun autre processus ne pourra être créé, car il n'aura aucun PID à utiliser. L'ANSSI recommande d'élargir la plage du nombre de PID disponible sur un système afin d'éviter ou de limiter de tels scénarios :
kernel.pid_max = 65536
Cette configuration permet donc de prévenir d'une saturation de PID entrainant une impossibilité de créer de nouveau processus. Sur les systèmes 32 bits, la valeur max est de 32 768 alors que pour les systèmes 64 bits, elle est de 2^22 (4 194 304, ça fait beaucoup de processus). À noter toutefois que les PID sont "recyclés", c'est-à-dire que lorsqu'un processus avec un certain PID se termine, ce PID peut être réutilisé plus tard par un autre processus. Ce durcissement vise donc à élargir le nombre de processus tournant simultanément sur votre système, ce qui ne sera le cas qu'en cas d'attaque ou pour des serveurs à très haute performance.
Un attaquant qui cherche à compromettre un noyau en cours d'exécution en écrasant les structures de données du noyau ou en forçant un jump (saut) vers un code de noyau spécifique doit, dans les deux cas, avoir une idée de l'emplacement des objets cibles en mémoire. Des techniques comme l'ASLR ont été créées dans l'espoir de "dissimuler" cette information, mais cet effort est vain si le noyau divulgue des informations sur l'endroit où il a été placé en mémoire. Il existe en effet plusieurs cas de figure où des adresses mémoires relatives au kernel peuvent être affichées (fuitées) vers l'espace utilisateur, qui obtient alors des informations intéressantes sur les pointeurs à cibler dans le cadre d'une attaque.
L'ANSSI recommande de paramétrer la directive suivante à 1 afin que, dans certains cas, les adresses mémoires relatives au noyau affichées par un programme soit dissimulées (remplacées par des 0) :
kernel.kptr_restrict = 1
Attention toutefois, cette dissimulation n'est effective uniquement si le programme utilise la notation %pK (au lieu de %p pour un pointeur "normal"). C'est-à-dire que le développeur a marqué le pointeur vers une adresse noyau comme tel et indique donc au système que l'information doit être protégée. Dans le cas où un programme ne respecte pas cette bonne pratique, le durcissement au niveau du sysctl est inutile.
Enfin, si l'utilisateur possède la capabilities CAP_SYSLOG dans le contexte d'exécution du programme, les adresses mémoire kernel seront affichées normalement (paramétrez la sysctl à 2 si vous souhaitez éviter ce cas de figure).
Sous Linux, la commande dmesg permet de voir les journaux (plus précisément la mémoire tampon des messages) relatifs au kernel, par exemple ceux créés par les drivers, lors du démarrage du système ou au branchement d'un nouveau périphérique. Ces messages sont ensuite stockés dans le fichier /var/log/messages.
L'ANSSI recommande de configurer le sysctl suivant à 1 afin de n'autoriser que les utilisateurs privilégiés à consulter ce type d'information via la commande dmesg :
kernel.dmesg_restrict = 1
L'objectif est ici de dissimuler les informations relatives aux journaux du noyau de la vue des utilisateurs, ceux-ci peuvent en effet dans certains cas contenir des informations sensibles pouvant être utilisées dans le cadre de futures attaques.
Voici un exemple de l'utilisation de la commande dmesg par un utilisateur non privilégié avec le paramétrage à 1, puis à 0 :
Sous Linux, le sous-système perf est une commande très complète et puissante qui permet de mesurer les performances d'un programme ou du système. Il réalise ces mesures en étant au plus proche de l'hardware, ce qui nécessite un niveau de privilège élevé.
L'ANSSI recommande le paramétrage à 2 de la sysctl suivante afin de limiter l'accès des utilisateurs non privilégiés à cette commande :
kernel.perf_event_paranoid = 2
Ainsi, un utilisateur non privilégié ne sera pas en mesure d'utiliser cette commande, qui peut notamment impacter les performances du système. Ce paramétrage est effectif sauf si l'utilisateur en question possède la capabilities CAP_SYS_ADMIN.
Également, les deux sysctl suivantes doivent être paramétrées à 1 :
kernel.perf_event_max_sample_rate = 1 kernel.perf_cpu_time_max_percent = 1
Ces deux sysctl servent à gérer combien de ressource et de temps CPU le système de performance peut utiliser. Il s'agit d'un pourcentage (1% du temps CPU). Ces configurations visent à limiter l'impact du sous-système perf sur le système lors de son utilisation. Attention, mettre ces deux sysctl à 0 fait tout simplement sauter toute limite, ce qui serait contre-productif
Quoi qu'il en soit l'idée derrière le paramétrage de ces deux sysctl est de limiter l'impact du sous-système perf. sur les performances du système.
Rendez-vous dans le prochain article pour l'étude des durcissement des sysctl réseau :). N'hésitez pas à signaler toute erreur ou précision technique dans les commentaires
Pour ce Patch Tuesday de Mai 2021, Microsoft a corrigé 55 vulnérabilités, dont 4 considérées comme critiques et 3 failles Zero Day.
Commençons par les trois failles Zero Day corrigées au sein des produits Microsoft. Bien qu'elles étaient connues publiquement, elles ne sont pas exploitées dans le cadre d'attaques. Les trois failles en question sont les suivantes :
Il s'agit d'une faille dans .NET et Visual Studio qui permet une élévation de privilèges. Cela concerne les framework .NET 5.0 et .NET Core 3.1, tandis que pour Visual Studio, il y a plusieurs versions touchées : Visual Studio 2019 version 16.X sur Windows et Visual Studio 2019 version 8.9 sur macOS.
Cette faille de sécurité au sein d'Exchange a été découverte lors de la compétition de hacking Pwn2Own 2021 par l'équipe Devcore. Il s'agit d'une attaque complexe à mettre en œuvre d'après Microsoft et qui nécessite des privilèges élevés. D'ailleurs, lors de la compétition Pwn2Own, l'équipe de Devcore a effectué une élévation de privilèges avant de pouvoir exploiter cette faille.
Voici les versions d'Exchange Server concernées :
Microsoft Exchange Server 2013 Cumulative Update 23 Microsoft Exchange Server 2016 Cumulative Update 19 et Cumulative Update 20 Microsoft Exchange Server 2019 Cumulative Update 9 et Cumulative Update 8
Cette troisième et dernière faille Zero Day touche la boîte à outils Microsoft Neural Network Intelligence (NNI). Il s'agit d'une faille qui permet une exécution de code à distance. Abhiram V. de chez Resec System a corrigé cette faille directement sur le Github du projet, en poussant une nouvelle version du fichier common_utils.py.
Pour information, voici les noms des KB pour Windows 10 :
- Windows 10 version 1507 — KB5003172 (OS Build 10240.18932)
- Windows 10 version 1607 — KB5003197 (OS Build 14393.4402)
- Windows 10 version 1703 — Fin de support
- Windows 10 version 1709 — Fin de support
- Windows 10 version 1803 — KB5003174 (OS Build 17134.2208)
- Windows 10 version 1809 — KB5003171 (OS Build 17763.1935)
- Windows 10 version 1909 — KB5003169 (OS Build 18363.1556)
- Windows 10 version 2004 et 20H2 — KB5003173 (OS Build 19041.985 et 19042.985)
Mise à part les failles Zero Day, Microsoft a corrigé des vulnérabilités dans d'autres produits comme Windows 10, Office ou encore Internet Explorer. La liste des produits est longue et variée comme d'habitude.
Attention à ces quatre failles considérées comme critiques :
- CVE-2021-31166 - Pile du protocole HTTP
- CVE-2021-26419 - Internet Explorer
- CVE-2021-31194 - Windows OLE
D'ailleurs, la faille Hyper-V est particulièrement inquiétante : l'attaque s'effectue par le réseau, et Microsoft précise sur son site que le niveau de complexité pour l'exploiter est faible et qu'il ne faut pas spécialement de privilèges élevés. La Zero Day Initiative a attribué un score CVSS de 9.9 sur 10 à cette faille de sécurité.
La Zero Day Initiative alerte également les entreprises sur la faille qui touche la pile du protocole HTTP. En effet, cette faille permet à un attaquant non authentifié d'exécuter du code dans le noyau de Windows. Un paquet spécialement conçu peut affecter une machine non patchée. En plus, à la question "Is this wormable ?" Microsoft a précisé "Yes" sur son site donc on peut considérer que cette faille de sécurité est exploitable par un ver informatique.
Retrouvez la liste complète des mises à jour sur cette page : Microsoft - Sécurité Mai 2021
Bon, maintenant, il ne reste plus qu'à espérer qu'il n'y ait pas de trop de problèmes sur nos machines dans les prochains jours après l'installation des patchs... En tout cas, pour le moment c'est Outlook qui est en difficulté : Outlook : une mise à jour vous empêche de lire ou d'écrire un nouvel e-mail
The post Patch Tuesday – Mai 2021 : 55 vulnérabilités et 3 failles Zero Day corrigées first appeared on IT-Connect.
Abonnez-vous à notre chaîne YouTube pour ne manquer aucune vidéo !
L'article 4 questions sur la cyberattaque qui paralyse le plus grand oléoduc des États-Unis est apparu en premier sur Numerama.
Si vous faites un peu dans le serveur de mails, vous connaissez peut-être Exim, un MTA (mail transfer agent) fonctionnant sous Linux et installé par défaut sur pas mal de distrib dont Debian, qui permet de redistribuer les courriers lui arrivant via SMTP ou via d’autres MTA.
Si je vous parle de ça, c’est parce qu’il est important de mettre à jour Exim dès que possible sur vos serveurs pour la simple et bonne raison que les chercheurs de chez Qualys y ont trouvé de nombreuses vulnérabilités super critiques.
En combinant ces vulns, il est ainsi possible d’exécuter du code non autorisé sur la machine et obtenir ainsi des privilèges root. Sur 21 des vulnérabilités découvertes, 10 peuvent être exploitées à distance comme ce qui est montré dans la vidéo ci-dessous et les 11 autres, localement.
Toute une analyse a été postée sur le site de Qualys et je vous invite à la lire, mais également à mettre d’urgence à jour vos versions d’Exim. Certaines de ces failles sont présentes depuis la création de l’outil, soit 17 années. C’est chaud.
Évidemment Exim a été informé en suivant la règle du responsible disclosure et tout a été patché. Le détail des attaques est donc disponible librement ici.
A vous maintenant de faire le nécessaire pour patcher vos machines.
Merci à Th0ny pour l’info.
Vous recherchez un poste de développeur (back, front, fullstack), Devops, dans la cybersécurité ou dans les télécoms ?
Plus de 100 postes sont disponibles dans les Côtes-d’Armor à Lannion. En ce moment plus d’une dizaine d’entreprises recrutent avec Laou des :
Laou est une plateforme spécialisée dans le recrutement IT en région. En plus de vous trouver un job, Laou s’occupe gratuitement de : – Vous trouver votre futur logement – Faciliter votre déménagement – Aider votre conjoint à trouver un job – Vous faire découvrir la ville
