votre avatar

FuraxFox

est avec nous depuis le 9 mai 2017 ❤️

Bio

Oups.
On dirait que quelqu'un ici aime garder ses petits secrets, comme si de par hasard il y avait quelque chose à cacher...
Désolé, ô lectrice de passage, cher lecteur égaré, pas de révélation sensationnelle pour le moment sur ce profil.
Repassez plus tard ?

2 commentaires

Active Directory : face à un « risque croissant », l’ANSSI publie ses recommandations

Le 04/06/2020 à 11h 44

Active Directory est compliqué.
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 çahttps://www.ssi.gouv.fr/guide/guide-dhygiene-informatique/

Il faut régulièrement inspecter son Active Directory et faire le ménage de ce qui a sauté ou été mal configuré.
Ce document explique quoi regarder, et pourquoi.


Chiffrement et sécurité dans tous leurs états, du WEP à la distribution quantique de clés

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.
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 https://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_des_protocoles_Bluetooth#Modes_… 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.