Bonjour à tous
 
Je bosse dans une entreprise où les serveurs ne sont pas tous dans le domaine. On me dit que c'est une question de sécurité..  
Il y a de l applicatif, serveur de fichier...
J aimerais avoir votre avis sur la chose ?  
Si oui l'intérêt ? Et si non pourquoi ?
 
Merci à tous  

comment font t'ils pour les administrateur ?pour s'y connecter un compte générique pour tout le monde ?
c'est le meilleur moyen d'oublier des maj,d'oublier des installations d'antivirus ou autre...
sinon, dmz externe ?

Un serveur hors domaine. Curieux.
Comment ils font pour y avoir accès ?

 
L’intérêt est de ne pas être impacté par un piratage de l'AD.
L'inconvénient est de ne pas gérer le serveur de manière centralisée via les outils du domaine. Ce qui ne signifie pas qu'on ne peut pas le gérer à distance et de manière centralisée.
 
Tout se juge au cas par cas.
Un serveur RDS qui n'est pas dans l'AD, c'est pas possible.
Mais un serveur applicatif dont l'application ne tire pas bénéfice à ce que l'OS soit en domaine, pourquoi pas.
 
Bien sûr, plus ton parc est important, plus la gestion peut être complexifiée de ne pas avoir des serveurs dans l'AD.
Et puis la sécu cela va plus loin que cela.

Je vois ça de plus en plus, mais pour moi non seulement c'est une illusion en terme de sécurité, mais c'est même un pis-aller en terme de sécurité.
La compromission d'un domaine n'évite en rien la compromission de machines en workgroup. Pire, les machines en workgroup sont bien plus vulnérables que des machines en domaine - pas de Kerberos, pas de délégation AD centralisée, pas de gestion des GPO centralisée ni de GPP, etc. etc.
Mention spéciale aux machines en workgroup hébergeant des applicatifs tournant avec des comptes de service à haut privilèges : il suffit alors de casser une seule machine (quelques minutes tout au plus) pour compromettre tout le domaine.
 
C'est une très mauvaise pratique. La réponse aux attaques à élévation de privilèges, c'est de mettre en place les réponses techniques qui existent (parfois depuis des années, mais qui ne sont simplement jamais activées), pas de mettre en place une solution de contournement crade.

Je suis aussi pour les serveurs dans le domaine mais je voulais avoir des avis.. Merci à tous pour vos commentaires très intéressants !

 
 
Attention, certains serveurs ne doivent pas être joints au domaine. Par exemple ceux qui entrent dans la sauvegarde et sa restauration. Ou encore ceux ouverts sur Internet via DMZ ou autre solution.

Non justement, c'est une fausse bonne idée.

 
Si absolument, c'est une vraie bonne idée.

Déroule tes arguments techniques alors.

 
Merde, moi qui trouvais que ton intervention en manquait ... c'est ça que j'aurai du te demander
 
Ben, c'est pas dur, je sépare l'infra de prod de celle qui permet de la gérer.
Donc la partie hyperviseur et backup = séparée de l'infra de prod.

je vois pas le rapport avec devoir les mettre en workgroup

 
Moi non plus.
Perso je les place sur un domaine géré via Synology. T'en penses quoi ?

Si tu es perdu quand je parle de Kerberos et de délégation ce débat ne va pas aller très loin c'est sûr.
 
Donc tu as ton AD, et ton domaine basé sur Samba (à la base on parlait domaine vs workgroup).
Et tu gères comment l'authentification entre les deux ? Tu as une relation d'approbation ? Comment sont gérés les comptes de service et les permissions ?
Si je casse ton Samba, c'est open bar sur les deux domaines ?
Plus largement, quelle est la valeur ajoutée de cette configuration exotique en terme de sécurité ? Concrètement, ça ressemble à une red forest bricolée, avec tous les inconvénients mais sans les avantages.

Je pense que tu cherches la merde et que niveau sécurité c'est obsolète

 
Pourquoi je serai perdu ?
Tu penses maitriser ces notions à toi tout seul ?
 
Qui plus est, je ne vois pas le rapport.
Je t'indique que l'infra de prod et celle qui la gère ne s'authentifient pas sur la même base.
Et que c'est plus sécu. Tu ne veux pas le faire, OK. Inutile de me prendre à partie.

 
Comment on fait quand un modo est grossier et vindicatif ? Cela t'arrive très souvent, avec de nombreux forumeurs; qui s'en plaignent. Moi aussi.

 
Ca n'a rien à voir avec mon status de modo. Tu provoques, tu dis de la merde faut en assumer les conséquences.
Ton samba niveau fonctionnalité et sécurité d'AD c'est genre ce qui se faisait il y a plus de 10 ans.
Pas de group managed service account, pas de kerberos armoring, pas de (resource based) constrained delegation, des trucs assez de base pourtant de sécurité

Mais pourquoi c'est plus sécu ? Donne tes arguments, on est là pour ça.
Je t'ai posé de vraies questions, tu esquives tout. Une discussion technique, c'est plus que de l'esbrouffe.
 
J'ai l'impression que tu es en mode craquage complet. Respire un coup, au pire, tu ne seras pas le premier à te planter dans l'histoire de l'IT.

C'est tout simplement plus sécu car le domaine le plus exposé est celui qui contient les membres du domaine.
Si atteint (ce qui s'opère dans plein de cas de ransomware), l'infra qui gère les hyperviseurs et système de backup n'est pas impacté. Et peu importe que cette infra s'authentifie en workgroup, AD ou samba.

C'est simple, documenté et valide.
Tu refuses de l'admettre ou de simplement laisser de coté car tu es victime de tes propres invectives. Je te fais pas le coup du yoga à ton tour. Sans intérêt.

Non. N'importe qui d'autre avec les mêmes termes et aussi dédaigneux aurait été TT depuis longtemps.
T'en es pas à ton coup d'essai.

Le plus exposé ne veut pas dire le plus sécurisé. Typiquement, tes VM en workgroup qui peuvent être cassées en brute force en quelques secondes, et qui contiennent des comptes à haut privilèges, c'est le jackpot : elles permettent de compromettre l'intégralité de l'infrastructure avec un minimum d'efforts.
En fait ta méthode, c'est de l'obfuscation. Tu masques certaines de tes machines critiques en les sortant du domaine, mais pour un attaquant un minimum intelligent, ça ne suffira jamais. Surtout quand ces machines utilisent des protocoles obsolètes ou des stratégies insuffisantes pour se prémunir.
 
Maintenant si c'est documenté balance tes sources

 
Casser une VM en workgroup en quelques secondes, c'est de la magie.
Je t'en mets une accessible sur Internet et je te mets au défi.
Je ne vois pas par quel biais on "casse une VM en workgroup en quelques secondes". Pour m'être un peu intéressé au brute force même avec des tables rainbow, c'est impossible si le MDP est fort. Pour peu même que le process qui gère l'auth n'ait pas des mécanismes anti-brute force (délai de tentative, blocage du compte, etc.).
 
Quant à la doc, y'en a plusieurs. Vu qu'on cause sauvegarde et que je l'utilise, je te donne celle de Veeam : https://bp.veeam.com/vbr/VBP/Securi [...] mains.html

Je te laisse comparer la robustesse de LM/NTLM avec Kerberos, vu que tu soutiens mordicus que le premier est plus résistant que le second.
Et bon courage pour appliquer les recommandations Microsoft sur les protocoles, les mots de passe, les permissions et le modèle du plus petit privilège dans un workgroup.
 
D'ailleurs ta doc confirme ce que l'on a dit plus haut : si tu veux vraiment de la sécu, tu utilises une red forest.
Là où je ne suis pas d'accord avec eux, c'est quand ils écrivent que le combo workgroup + domaine est plus sécurisé que le domaine simple.
 
En fait, ils ne considérent jamais que le workgroup pourrait être compromis en premier. Alors que c'est factuellement plus facile, plus intéressant, plus rapide. Et que cette architecture implique d'abaisser significativement l'ensemble de la sécurité du domaine pour fonctionner tout simplement.
 
Ils se rattrapent quand même en précisant que cette architecture est plus adapté dans de petits environnements.

 
Je note que tu es pas foutu de répondre sur les arguments techniques que je te donne hein...
Que tu préfère garder tes œillères et te conforter dans ta méconnaissance/mauvaise foi.
 

  tout est dit

 
Je ne soutiens rien. Tu fais les questions, les réponses et tu t'en félicites.
Si tu ne veux pas du Workgroup; tu fais un AD. mais à part.
 
Et non ils ne considèrent pas que le workgroup peut être attaqué en premier. Surement car Veeam c'est des petits joueurs face au modo de HFR et son poto.
Ou alors c'est que ton workgroup il est juste pas accessible sur ton réseau de prod.
Prise en main d'un poste infecté via messagerie, MAJ infectée pour un applicatif, faille dans le routeur WAN ou serveur Exchange percé, on s'en moque. L'infra des hyperviseurs et de sauvegarde n'est pas la même que celle de prod. Et ne s'appuie pas sur son AD avec les liens réseaux nécessaires.
 
T'as pas l'impression qu'avec les groupes du CAC40 infectés et ceux censés les protéger, comme des ESN type Sopra Steria à l'arrêt total pendant X jours, il faut arrêter d'avoir le melon et parier sur l’infaillibilité d'AD, son Kerberos et son hardening ?

Ah donc ton infra de backup communique avec ton infra de prod, mais sans être accessible. Et puis tes comptes de service ils sont sûrement invisibles et s'authentifient par magie. Ils n'ont pas besoin de délégation, magie là aussi. Une sorte d'Application-Aware gazeux. Woké.
 
On a jamais parlé d'infaillibilité. On a par contre mentionné que les cryptos ne sont pas une fatalité, et qu'ils existent nativement tout un tas de fonctionnalités Windows pour les contrecarrer, ou à défaut rendre leur utilisation plus difficile, mais qui ne sont quasiment jamais impléméntées. Mais pour ça il faut prendre conscience que la sécurité, ça va au-delà du pare-feu, ce qui est un phénomène très récent (et pas encore très répandu). Puis accepter de mettre du pognon dedans, ce qui est encore moins répandu. Et changer les habitudes, genre arrêter de configurer un compte de service de backup admin du domaine sans aucune restriction ni supervision, avec un mot de passe faible/moyen qui change en moyenne tous les dix ans, et avec lequel on va attaquer tous les serveurs du domaine. Pour ensuite se plaindre d'Active Directory et que c'était mieux avant en workgroup sous Windows 95.
Mais vu que tu en as gros (pour une raison qui m'échappe) et que la notion de d'arguments techniques est dans le fossé, on va effectivement s'arrêter là    
 

Mon infra de BKP elle ne communique pas avec mon infra de prod mais avec les hyperviseurs.
Et pour l'interaction avec les OS afin de déclencher VSS par exemple, cela se passe via VIX (sous Veeam pour ma part).
Remarque on peut aussi passer via RPC en n'ouvrant que ce flux de l'infra de BKP vers celle de prod (les VMs avec l'AD, les applis, etc.).

En tout cas je suis trop content car j'ai de la matière sur le sujet, merci les gars