Reprise du message précédent :

 
Ouvre un ticket chez Plam

Kindly décrit mieux ce que t'a fait alors, avec l'ordre

C’est quoi vSphere sur les hôtes ? Un vCenter sur un des ESXi ? Ensuite, bien que ça soit possible et supporté, l’expérience fait qu’on préfère laisser un vmk0 sur un vSwitch Standard
 
Les flux entre vCenter (vpxd) et ESXi (vpxa) sont bons ? Genre le 902 ?

Propre.  

 
mais bien sur suis je bete
 
kindly doing it now
 

 
Oui, en gros on va voir plusieurs "datacenter" (au sens vmware)
le vsphere tournera sur des hotes d'admin, en ha, et gerera a la fois le datacenter d'admin et de production.
 
actuellement je teste avec 3 esxi d'admin, qui donc ont le vshpere installé dessus.
 
ah ca m'arrange pas ca, c'est ultra relou a gérer avec terraform les switchs standards. c'est quoi la raison ?  
 
les flux sont exactement les memes entre avant et apres
 
en gros avant j'ai vshpere > vlan > vswitch > vmk0 > vswitch > meme vlan > esxi
apres j'ai vshpere > meme vlan > dvswitch > vmk0 > dvswitch > meme vlan > esxi
 
donc si les flux passaient avant je vois pas trop pk ils passeraient plus apres  
 
d'autant que je ping sans probleme les esxi depuis le vsphere en shell. Et je peux sans probleme leur modifier des confs (via terraform ou non)
 
ce que j'ai fait :
 
vswitch et vmk0 sur vmnic4
dvswitch crée sur vmnic5
ajout d'un distributed port group avec le meme vlan sur dvswitch
dans la gui, je migre le vmk0 sur le dvswitch et sur le distributed port group, avec migration egalement de la vm vsphere pour l'hote qui l'heberge
migration ok je migre vmnic4 sur le dvswitch

Vous voyez, quand je disais que les noms des produits vmware c'était le bordel

d'ailleurs, j'ai trouvé son erreur. Il a pris un produit de la mauvaise boite au milieu:
 
vshpere  
vlan
dvswitch  
vmk0  
dvswitch  
vlan
 
DMware, c'est le système de messagerie interne de twitter, rien à voir avec de la virtu

j'ignore si c'est que pour la blague ou pas pwarlk mais le fait est qu'en plus le vrai nom c'est
vsphere distributed switch, ce qui donne donc vdswitch.

 
Désolé mais tu ne réponds pas à la question... ou alors j'ai mal compris.
 
C'est quoi vSphere ? C'est le ou les vCenter ?  
 
T'as une capture d'écran de l'inventaire flouté qu'on voit les différents niveau ? Datacenters > Clusters?
 
Sinon MP si c'est sensible/confidentiel. Et si t'as du support, je peux t'ouvrir le ticket et faire une prise en main si besoin.

 
C'était purement pour la blague. J'avais aussi "et VLAN dans sa gueule", mais c'était encore moins drôle
Mais c'est jamais dérangeant de partager des connaissances.

 
oui le vcenter desole
 
c'est bon ecoute je l'ai refait ca marche cette fois j'ai pas d'alarme
 

https://msandbu.org/printnightmare-cve-2021-1675/
Faille 0day qui pique, qui rend possible pour tout utilisateur connecté au domaine d'exécuter du code en tant que local system sur les contrôleurs de domaine

Visiblement , la simple preco (assez ancienne d'ailleurs) d'arreter et de désactiver le spooler sur les DC permet d'eviter la propagation.

Euh.
Non.
Ça permet que la faille sur le DC soit pas exploitable. Ça la corrige pas sur le reste du SI.
Et puis y'a pas de propagation en soit, c'est une faille, pas un malware

Super on va pouvoir imprimer des KOALAS

 Ce génie

La préco est de ne jamais mutualiser serveur d'impression et DC pour commencer. Il y a déjà eu une faille de ce genre il y a des années, jamais corrigée (solution: migrer le serveur d'impression autre part que sur un DC).

 
Et même de ne jamais mutualiser un DC avec quoi que ce soit d'autre, même un service Microsoft genre DHCP.  
L'ANSSI dans ses précos pour les environnements à risque c'est de n'avoir, en plus d'aucune mutualisation et bien entendu comme pour tous les autres serveurs pas d'accès à/depuis internet, aucun code non MS. C'est à dire que si tu utilises Cortex XDR / Crowdstrike >> pas sur ton DC, si le DC est virtualisé >> sur un host HyperV, etc.

Attend, on t'a pas encore dit qu'il faut pas héberger sur le même hyperviseur des charges avec des besoins de sécu ou des expositions réseaux différentes.
En gros, sur un hyperviseur avec un DC, tu n'héberge que des vm tiers 0 administrées que par des personnes d'un niveau de confiance et de privilèges homogène.
Voir par exemple le guide d'administration sécurisée.

Salut,
Je dois envoyer des données en sftp à 50 milliards de partenaires.
Sa vous choque d'imposer à l'ensemble des partenaires le même login / clef publique de connexion ?

Oui.

Et sachant que c'est 50 milliards de partenaires ca finira par être publique donc pourquoi mettre un auth ?

autant faire du bittorrent dans ce cas

Alors que je rencontre régulièrement des DC mutualisés avec tout et n'importe quoi : filer, IIS, PKI, SQL, voir l'appli métier de Robert le dev.
Je pense qu'ils s'agit plus des précos de Microsoft que de l'ANSSI. Ces derniers te conseillent plutôt de coller tes machines critiques en workgroup pour mieux les protéger

Y'a des cas où ça fait sens. Genre ton infra de backup Veeam, ou ton vault de bastion d'admin cyberark.

Oui ?!?
Edit, j'ai lu avec le doigt. C'est toi qui envois.
Pas forcément, mais ça va rendre très chiant la rotation de la clé tous les X mois de ton côté. A tout les coups certains réagiront plus ou moins vite pour le changement, et tu va devoir gérer d'avoir les deux clés privées en même temps pour différents partenaires.

Triggered

Je pense que c'est la pire idée qui soit pour plein de raisons pour le premier point. Diminuer significativement la sécurité d'une machines les plus critiques de l'infra, tout en y collant des comptes superadmins d'un domaine, j'ai du mal à y voir la logique.

Qu'elle ne soit pas impactée quand ton domaine se fait ouvrir, ce qui arrive beaucoup.
Alors y'a des solutions plus élégantes hein, je dit pas le contraire. Cependant, elles sont pas tant diffusées que ça.
Du coup, par exemple chez Cyberark, le vault c'est aucune communication à part les autres composants Cyberark (et en option une cible pour les backups et 2/3 services, genre du ntp de mémoire), le firewall local verrouillé par l'application à son installation, les services locaux désactivés, pas d'application autre que le vault... Évidement pas d'accès distant, sauf depuis une IP configurée à l'installation pour une station d'admin dédiée (et que via le protocole de l'appli, pas en rdp).

Je vois pas en quoi tu diminue la sécurité de la machine dans ce scénario là.

Par contre, installer un windows serveur, le laisser en workgroup, installer une random appli et penser que c'est mieux, non, effectivement c'est être à côté de la plaque. Mais c'est pas de ça que je parle, donc je t'invite à consulter les doc de hardening veeam ou Cyberark pour qu'on parle de la même chose

On est d'accord, c'est très différent du scénario que je rencontre régulièrement (et de plus en plus): une machine Veeam en workgroup, avec un compte admin du domaine pour le AA, pas de renforcement, pas de gestion, pas d'audit. Et à côté de ça le domaine complètement à poil, sans aucune protection dont certaines sont dispos depuis des années : HVCI, Kerberos armoring, gMSA, audit, délégation, protection des partages SMB, SCT etc.

Ah bah oui mais non, du coup on parle de deux scénarios complètement différent
Non, ce que tu décris, c'est juste un truc a l'arrache à côté d'un truc a l'arrache   . Au final que ce soit dans le domaine ou pas, je suis pas sûr que ça change grand chose  

C'est encore plus facile en fait. Plus besoin d'escalader les comptes du domaine : brute force sur le mot de passe admin local de la machine (en NTLM), jackpot direct avec le compte admin du domaine...

Tu veux brute forcer quoi au juste ? Sachant que tu peux directement booter et éditer la ruche SAM "offline" pour squeezer les mots de passe locaux ?

Pas si le disque est chiffré  

Ça c'est quand t'a un accès physique ou un dump de la vm. C'est quand même pas trop l'approche classique en ce moment

On parle bien d'une faille client qui fait que sur un poste local, en ayant les droits admin locaux, on puisse faire une élévation sur l'admin local du DC.

Euh, non. Tu as raté des postes. On parle de la conséquence d'avoir une machine en workstation hors domaine disposant des creds d'admin de domaine stockés quelque part pour une application X ou Y.

 
Genre les mecs qui dépensent trois francs six sous vont faire ça sur les "petits" sites où ils ont un seul hyperviseur.