C’est rendu pire par le fait que des pratiques courantes (et recommandées) il y a quelques années sont devenues obsolètes. Pire encore, l’installation de certaines applications fait sauter des mesures de sécurités (des droits d’accès, des inclusions dans des groupes privilégiés, des mise à valeurs dangereuses de champs optionnels…). Et la moindre de ces erreurs, dans un annuaire qui compte des centaines de milliers de noeuds peut mener à la compromission totale d’un système d’information. Des outils offensifs comme Bloodhound existent juste pour les rechercher automatiquement.
Un AD récent (2016 et suivant), hors de la boite est plutôt sécurisé. Mais quand on commence à y connecter tout un système d’information le niveau peut descendre vite.
Il ne suffit pas d’avoir de bonnes pratiques d’admin (mot de passes forts, double authent, postes dédié…) voir le guide d’hygiène de l’ANSSI pour ça République FrançaiseIl faut régulièrement inspecter son Active Directory et faire le ménage de ce qui a sauté ou été mal configuré.
Dans les protocoles rarement chiffrés on va trouver les partages de fichiers (SMB, NFS par exemple). Comme le DNS, ils peuvent être chiffrés dans leurs versions récentes. Mais si ils ne le sont pas c’est parce-que la gestion des clés est une plaie à configurer, que la moindre erreur conduit à un déni de service et que c’est pénible à déboguer.
Après il y a tous les protocoles de niveau inférieur DHCP, ARP, Ethernet … ou il n’y pas des masses de solution. La spécificité du sans fil est qu’on ne peut pas en contrôler l’accès physique, ce qui rend le chiffrement plus important. Mais dès qu’un réseau couvre un espace assez vaste le même problème se pose pour les câbles que pour les ondes.
Bluetooth Wikipedia et Zigbee peuvent utiliser du chiffrement très correct. Mais leur mise en oeuvre est rarement bonne chez les implémenteurs. Qui plus est, négocier des clés sur des appareils avec peu ou pas d’interface utilisateur est un vrai problème (essayer de rentrer un code à 10 chiffres sur un casque audio bluetooth). C’est d’ailleurs un problème commun de tout ce qui est “internet des objets”. En général, on a 2 approches: clés fixes (appareils Bluetooth Low Energy qui ont tous ou presque 000000 comme clé), ou désactiver la sécurité temporairement, le temps d’appairer des appareils via une manipulation physique (l’appairage est alors un échange de clés). Ce sont des problèmes intéressants…. donc pas faciles ;-)
Je n’ai pas compris la question sur DNS HTTPS.
En espérant que ça réponse un peu à des questions.
2 commentaires
Active Directory : face à un « risque croissant », l’ANSSI publie ses recommandations
04/06/2020
Le 04/06/2020 à 11h 44
Active Directory est compliqué.
République FrançaiseIl faut régulièrement inspecter son Active Directory et faire le ménage de ce qui a sauté ou été mal configuré.
C’est rendu pire par le fait que des pratiques courantes (et recommandées) il y a quelques années sont devenues obsolètes. Pire encore, l’installation de certaines applications fait sauter des mesures de sécurités (des droits d’accès, des inclusions dans des groupes privilégiés, des mise à valeurs dangereuses de champs optionnels…). Et la moindre de ces erreurs, dans un annuaire qui compte des centaines de milliers de noeuds peut mener à la compromission totale d’un système d’information. Des outils offensifs comme Bloodhound existent juste pour les rechercher automatiquement.
Un AD récent (2016 et suivant), hors de la boite est plutôt sécurisé. Mais quand on commence à y connecter tout un système d’information le niveau peut descendre vite.
Il ne suffit pas d’avoir de bonnes pratiques d’admin (mot de passes forts, double authent, postes dédié…) voir le guide d’hygiène de l’ANSSI pour ça
Ce document explique quoi regarder, et pourquoi.
Chiffrement et sécurité dans tous leurs états, du WEP à la distribution quantique de clés
03/04/2020
Le 04/04/2020 à 13h 19
Dans les protocoles rarement chiffrés on va trouver les partages de fichiers (SMB, NFS par exemple). Comme le DNS, ils peuvent être chiffrés dans leurs versions récentes. Mais si ils ne le sont pas c’est parce-que la gestion des clés est une plaie à configurer, que la moindre erreur conduit à un déni de service et que c’est pénible à déboguer.
Wikipedia et Zigbee peuvent utiliser du chiffrement très correct. Mais leur mise en oeuvre est rarement bonne chez les implémenteurs. Qui plus est, négocier des clés sur des appareils avec peu ou pas d’interface utilisateur est un vrai problème (essayer de rentrer un code à 10 chiffres sur un casque audio bluetooth). C’est d’ailleurs un problème commun de tout ce qui est “internet des objets”. En général, on a 2 approches: clés fixes (appareils Bluetooth Low Energy qui ont tous ou presque 000000 comme clé), ou désactiver la sécurité temporairement, le temps d’appairer des appareils via une manipulation physique (l’appairage est alors un échange de clés). Ce sont des problèmes intéressants…. donc pas faciles ;-)
Après il y a tous les protocoles de niveau inférieur DHCP, ARP, Ethernet … ou il n’y pas des masses de solution. La spécificité du sans fil est qu’on ne peut pas en contrôler l’accès physique, ce qui rend le chiffrement plus important. Mais dès qu’un réseau couvre un espace assez vaste le même problème se pose pour les câbles que pour les ondes.
Bluetooth
Je n’ai pas compris la question sur DNS HTTPS.
En espérant que ça réponse un peu à des questions.