Reprise du message précédent :
Oui ceux à proximité de chez moi

 
complètement interdit chez nous jusqu’à fin juin

Une grosse métropole 200k habitants chez qui on installait un soft.
Les mecs ont pris une attaque cryptolocker le week end dernier, ils annoncent 4 semaines d’indisponibilités du réseau.
Le SI doit pas être tranquille.

 
A ta place, je ne serai pas serein.,,

Angers, non ?

 
De notre coté le soft était en place, rien a voir avec l'infra réseau, au pire on réinstallera.
 

On vas dire que c'est possible que ce qoit dans cette zone géographique

il y a une nouvelle collectivité aujourd'hui qui est en train de se faire ruyker.

 
Oui enfin on sait tous que c'est toi qui a introduit le cryptolocker

Ca doit bien se faire ca, le presta qui vient pépouze installer son soft. Il en profite pour laisser son crypto dans un coin. Si pas trop con, il le fait déclencher quelques semaines plus tard. A lui le pognon

Il y a un histoire sur Hfr avec un cdp comme ça où le gars était parti en laissant imprimer des koalas ou un truc du genre aléatoirement dans son ancienne cogip bien après son départ non ?  

Ouais, genre tâche planifiée pour 2-3 semaines après son départ.
Un collègue l’avait appelé pour lui demander si c’était bien lui (la tâche s’était déclenchée sur toutes les imprimantes de l’usine / atelier).

Génial n'empêche
 
Examen Ebios passé aujourd'hui. C'est pas forcément simple mais pas aussi compliqué que prévu.
 
Le RSSI adjoint qui nous avait dit "nan mais ça dure 3 heures vous aurez jamais le temps de lever la tête".
 
Mwai. Soit je suis passé à côté d'un truc soit il a voulu mettre la pression volontairement

Clairement c'est pas impossible, simplement dans notre contexte aucun interet, 90% de notre chiffre ce fait sur les prestas de formations et d'accompagnements, limite si on réinstalle ça sera même pas une demi journée de facturée si on rogne pas ça simplement sur les jours qui restent.

 
historiquement on avait que du debian
mais petit a petit on passe (passait) tout sur centos.
 
comme tu dis, et comme dit au dessus, l'interet pour moi de centos c'est que c'est un redhat sans support.
quand tu fais par exemple de l'infra as code, ca te permet d'avoir qu'un seul code, de réutiliser ce que tu as codé sans modif etc. T'as un environnement de test sur centos, un env de prod sur redhat, le code est le meme, tu changes juste les repos et c'est bon.
 
c'est pas possible avec debian
 
sans compter que bcp de soft a DIME ne sont pas supporté sur debian

Question conne
Un firewall qui bloque tls v1.0. Il le bloque dès le début ?
Un message client hello serait donc bloqué tout de suite et on ne verrai pas le reste de l'handshake dans un tcpdump ?

Ca se bloque la version de TLS sur les FW ?

en envoyant un TCP reset tant qu'à faire, comme ça c'est quasiment impossible à troubleshooter pour le client  

OK, thx. J'essaie d'envoyer des données à un hal connect:précoce et ça marche pas.
Le support demande s'il y a un blocages firewall tls même avec un handshake réussi  

ça peut aussi bloquer sur la base du SNI, ou n'importe quel autre bit que les gens du réseau auront jugé inapproprié

De toute façon, on le sait tous, c'est toujours la faute du réseau

à la décharge de lusers, quand on met en place ce genre de filtrage c'est normal que les gens suspectent le réseau au moindre pet de travers.

Ya E-SNI maintenant  

 
Tiens pendant que t'es là, tu aurai de la doc technique/archi général sur comment VMware fait de la HA avec la RAM entre deux VMs ?
 
Chez Xen, ya deux approches :

• Remus : copie de la RAM en permanence (ce qui est pas très efficace, c'est un genre de migration à chaud sans fin) et VM en état de pause en destination, prête à prendre le relais jusqu'à ce que la source décède
• COLO : les deux VMs tournent, et tout changement envoyé par le réseau et écriture disque est répliqué sur les 2. Quand ya une divergence, la VM repiquée est « reset » à l'état de la VM source.

VMware c'est lequel des deux, ou alors une 3ème solutions ?

 
ça on y a le droit aussi. Et les dérogs pour les applications qui sont trop vieilles pour pas supporter le bon TLS (et chez nous, montée de version OS majeure = nouvelle machine, avec toutes les versions de produits et outils également incrémentées).

Y’a eu La Rochelle dernièrement, mais y’a pas 200000 habitants.  

D'après la formation que j'écoutais hier, c'est une recopie des i/o.
Donc plutôt ta seconde solution.

 
dans tous les cas ca reste quand meme des mauvaises solutions, au mieux du paliatif

Quelle différence conceptuelle majeure vois-tu, par rapport à un cluster actif-actif ? Mis à part bien entendu le fait que ce soit une condition système qui entraine le crash de l'élément HA actif et qui donc par nature entrainera le crash de l'élément passif ?

(pour ma part je préfère largement les vrais clusters pour plein de raisons, mais de là à qualifier HA de mauvaise solution, je vois pas trop dans les environnements dans lesquels tu peux pas faire autrement)

 
En même temps c'est l'approche la moins coûteuse en terme de ressources, mais c'est assez moche à écrire (le degré de complexité).
 

 
Je demande pas par hasard : on vient de me faire une demande en ce sens, mais c'est pas très courant.

Bah quand tu as un gros besoin de dispo et que l'application sais pas le faire en natif... Ou avec des contraintes pas beaucoup plus jolies (genre un L2 entre les deux appliances)...

 
Ouais voilà.  
Chez un client y'a peu de temps y'avait un système super compliqué pour l'impression (qui est ultra critique) et un serveur littéralement pivot ne pouvait pas être collé en cluster à cause de contraintes de l'éditeur, une indispo étant quasi impensable. Bah on a fait face avec les outils qu'on avait

N'embaucher a l'IT  des mecs marié,  gays ou mormon, ou des femmes  

Ou instaler en face de l''IT un pool de secrétaires sous compétentes dans un bureau surchauffé

Enfin bref ... Rendre l'appat sans intérêt ou moins appétissant que la gamelle habituel  

Ou tenir compte du risque dans l'analyse de risque. Et appliquer des solutions pour le réduire si nécessaire (séparation des rôles, chiffrement des données, ...).
Dans une grosse boîte, c'est pas parceque t'es admin que t'a accès à tous et n'importe quoi.

C’est pas ça le HA chez VMware. Le HA, c’est redémarrage de la VM sur un autre host si le premier tombe.  
 
Pour du « full synchro », c’est du FT (Fault Tolerance). C’est consommateur, et ça a pas mal de limites techniques selon la version de vSphere (4 VMs en FT maxi dans un cluster, limites de 4 vCPU, etc.). Et même VMWare en recommande un usage très parcimonieux. Ça sert uniquement de palliatif pour un service critique qui ne comporterait pas lui-même de solution de haute disponibilité (Cluster, services répliqués, etc)

 
meme par rapport a un cluster actifl/passif.
ce n'est quu'ne bete replication. tout "cluster" applicatif apporte certe de la haute dispo, mais pas que.
ca permet de faire des maj systeme sans coupure de service (un noeud puis l'autre)
si l'appli est bien faite, des maj applicatives sans coupure de service  
si ton serveur A crash, ton serveur B prend le relai plutot que crasher lui aussi dans la foulée
si t ufais une guez sur le serveur A, tu tues pas forcement non plus automatiquement le serveur B
 

 
mauvaise solution est exagéré, disons plutot que pour moi c'est au mieux un paliatif a n'utiliser qu'en cas d'impossibilité totale de faire autrement

 
par exemple ca.
 
je prefere toujours les solutions HA applicatives, plutot que les solutions qui reposent sur un HA hardware ou software bas niveau.

Vu les deux description de Plam, c'est bien de FT dont je parlais
+ T'a d'autres options sur la HA que "si l'hôte tombe" : heartbeat de l'agent, état de l'os guest...

Oui désolé je connais pas les noms vmware FT donc, mais en me reprenant sur le terme j'ai pas eu de réponse sur le fond (enfin si mais sur un post précédent )

La formation dure combien de temps pour passer une certification EBIOS ?

Deux jours pour Ebios Risk Manager. Mais je présume que ça dépend de l'organisme de formation.

J'aime bien Ebios, c'est orienté opérationnel, contrairement à ISO 27005 qui est très général et dont le système général est très discutable...

RTFM : https://docs.vmware.com/en/VMware-v [...] 2ED21.html