Reprise du message précédent :

 
notre seigneur et sauveur

 
commit confirmed  

Jamais eu l'occasion d'y toucher, c'est bien cet OS ?
J'ai vu un bout de syntaxe qui ressemblait à des trucs imbriqués avec plein d'indentation pour 3 pauvres infos à afficher, ça m'avait pas trop encouragé à m'y intéresser

Tu connais ton périmètre et tes responsabilités dans ta nouvelle boîte ? On te demande parfois d'autres trucs que de tester  en prod, où tout est comme ça ?

c'est pas qu'une question de syntaxe, c'est la gestion de la conf dans son ensemble qui est mieux foutue. Les niveaux d'imbrication servent à définir des bouts de conf logiques qu'on peut visionner, éditer, écraser ou supprimer d'un bloc, ça peut sembler déroutant au début mais on s'y fait très vite à mon avis.
Si tu as du palo alto c'est sensiblement la même CLI

tient petite question réflexion, j'ai besoin d'avis externe à la cogip, mais de gens du domaine :
 
Contexe:
Moi: user kisikoné, qui pisse du code, chope une remarque de l'it tout les 6 mois car j'ai un soft pas "autorisé" (on est chez les 12 travaux d’astérixis à la cogip pour ces trucs là   )
Mon job: je design, code et met en services des bancs de test de désanusseur de poulpes (je bosse en industrie, service méthodes process).
Une partie de mon job consiste donc à mettre en prod des moyens informatique. On se tape des PC "indus" de chez Factory System/Advantech (on ne parlera pas de la "qualité" de ces machines... ). Souvent c'est nous qui faisons la mise en service du PC, l'IT n'est pas encore passé dessus. Globalement j'install tout mes softs, runtimes, je config partages smb, les ip, toussatoussa. La session est bien évidement admin.
 
Quand le moyen de test arrive dans l'usine, bien souvent j'ai droit à un LAN scada dédier, ce qui m'arrange, comme ça la machine n'est pas connecté au domaine, et donc pas la tripaille du package IT à base de parfeu bloqué, ports USB bloqué et AV qui me bouffe toute les ressources du poste (Mc Affee quoi...) Parfois la session est downgrader en luser (ce qui me vas une fois que tout est bien config). Évidement 0 connexion à internet ou domaine en direct sauf pour les maj windows et le remote control.
Il y a d'autres LAN mais qui ne sont pas lier au réseau usine, j'ai genre du LAN pour le PLC (automates), un ou plusieurs LAN pour mes instruments de mesure, cibles temps réelles...
 
Mon soucis      
Récemment, j'ai eu un autre site (à l'étranger) qui me l'a fait à l'envers . Pendant les congés, personne n'est dispo, pas d'astreintes de l'IT      
Le pc qu'on ma donné est passé chez l'IT, connecté au Domaine, donc user pas admin, ça veut dire tapper ce putain de login admin sur un clavier qwerty toutes les 30s pour la moindre action   .  
Évidement le parfeu bloque mDNS et le DCHP link local, donc la détection des périf Ethernet ne fonctionne pas, ports USB bloqué, donc obligé d'utiliser le remote control (Bomgar/Beyond trust, 70Go à transfert à ~800ko/s   ).  
Je config donc tout comme je peut, mais sur la session locale du pc (surtout la base de donnée via le ODBC. (bug de merde qui fait que c'est par user et non system). Ça me bouffe bien 3 jours, mais j'ai un truc qui tourne au petit oignons, bien propre et tout, j'ai même ranger les icônes sur le bureau, pour dire    
Et au lundi suivant, j'ai un mec de l'it qui arrive sur la ligne, va sur le pc et me fait une bascule en session du domaine. Évidement sans m'en parlé, sans me demander si il y a des trucs à config. Évidement le mec parle pas anglais....   (Il à pris sont savons quand même   )
Donc on (je) re perds du temps à tout reconfig, en prod vus que l'usine est revenue de congés....
Sauf que cette putain de session de merde à un full accès internet, c'est une putain de config de pc bureautique...             Donc niveau "risque" pour la cogip de pas avoir de fuite de donnée ou juste de pas planter la prod... (Évidement le mot de passe est imprimé à la dymo sur l'écran   )
 
Ma question:
 
Les PC indus en prod pour vous:

• connecter au domaine COGIP, même package/config qu'un poste bureautique
• connecter en scada, même package/config qu'un poste bureautique
• connecter en scada, pas de package imposé

Bonus: WIN PRO (et donc maj tout le temps + reboot) ou WIN LTSC ? (on est en ltsc, sauf ce même site qui nous met des win pro, gérer par symantec et donc reboot souvent, et donc ip mal config qui saute et donc prod à l’arrêt, mais ça les gênent pas...)
 
 
#désolé   il fallait que je vide mon sac  

Wah. Pourquoi y'a personne côté sécu qui est passé voir ?

En fait j'imagine déjà la réponse mais je veux bien l'avoir quand même

 
c'est impossible de répondre à une question de ce genre de façon pertinente, en simplifiant un problème aussi complexe en 3 lignes on ne peut rien sortir d'exploitable à mon avis.  
Rien que "domaine COGIP", suivant les boîtes ça peut être du windows 2008 géré par dédé qui fait ça quand il a le temps, ou une infra tenue à jour avec des postes clients bien gérés et surveillés de près, du 802.1X partout, de l'accès web authentifié et bien managé, du trafic DNS surveillé etc. En fonction de ça les choix ne seront pas les mêmes en cas de use case "à part" comme des PC indus ou autre.

C’est pas le n3 qui va changer physiquement le switch et refaire le brassage.
Au niveau 2 tu dois changer le switch, recabler reagencer.
Ça demander juste de mapper les ports

on est sur le 2eme choix
 
multi site/pays, les laptop, les smartphone, tout le monde est dessus.
 
mais ce qui m'a choqué, c'est que pour une grosse cogip on à pas un site qui fait la même chose sur le plateau de prod, on sens qu'il ont pas une procédure/méthodo obligatoire. (alors qu'on est les rois des standards )
 
j'ai même un site qui me balance la traça, le réseau automate de la station, le scada  et le remote control sur le meme LAN.
autant dire qu'a la première backup, même les protocoles temps réel EtherCat, Profinet IO & co sont pas content

 
oui donc vous êtes pas dans le deuxième cas en tout cas c'est pas ce que j'appelle "bien géré"...

a lire ca ... jai eu un haut le coeur    
 
bordel mettre le reseau automate et lan general sur le meme broll, c'est un motif de "licenciement" a coup de clef a molette sur la tronche chez moi  
ici le LAN et les réseaux automates sont totalement étanche  je parle pas de Vlan mais bien de  switch physiquements séparé    

Pour le coup, j'ai bcp plus utilisé la commande system-view que conf t.
Mais j'ai surtout travaillé sur des Switch dell aussi.

le concept même de "lan général" est souvent déjà le signe d'un problème

@jungledede Je te réponds plus tard.

Ça va être bien sympa quand vous allez manger une grosse attaque cyber

 
Pareil c'était la base.
 
Certains postes de supervision ou hébergeant la BDD/OPC/SCADA avaient une deuxième NIC pour admin sur un VLAN dédié.
 
D'une manière générale les terminaux / pupitres / PLC and co sur IP n'avaient dans la mesure du possible pas de passerelles (usuellement, pas besoin de remonter plus haut que la couche précitée).
 
Pour le problèmes des MAJs ça dépendait de beaucoup de facteurs. Déjà de savoir si l'OS est toujours supporté  , puis de pas mal d'autres choses ensuite, entre autre la position du fabricant/fournisseur de l'environnement sur cette question : beaucoup désactivaient tout simplement le pare feu et WU sur le master. Et vu qu'isolé, mises à jour à la mano périodiquement, ce qui devient vite chiant quand tu as des dizaines d'endpoints à mettre à jour.

Aucun besoin de communication entre les deux?

LeKeiser il me rappelle un peu moi plus jeune. En moins bien évidement. Garde espoir. Mais bon, j'ai fini dev.  
 
Dev à la jungledede, en moins pire. On a des trucs ignobles à cause des precos fabricant / fournisseur mais c'est pas mon équipe qui est responsable donc osef. Nous on fait des désanusseurs de poulpe in house. On a notre VLAN, les PC sont quasi standard, DB / API / reporting web sont sur des serveurs standard.

Faut qu’il s’accroche, y a plein de chose à apprendre sur le tas, souvent en faisant des conneries

Je l'imagine pas dev du tout  

Oui, dev pour lui j'en sais rien.
 
Il a l'air de connaître pas mal de trucs, mais pas assez pointu sur un sujet et/ou diplôme jugé trop bas en France.

jungledede t'as quand même un peu l'air d'un kissikoné. Tout ton bordel de droits admin pour l'install et la configuration, et tu a l'ait de dire que c'est à la main, je suis sceptique. Tu devrais avoir une install automatisée, donc faisable par l'IT sans aucune intervention de ta part.

On ne mélange pas l’indus et la bureautique

Rarement   et quand ce besoin existe  ( réseau supervision à l'échelle de l'usine par exemple)
Ben on prend des automates avec deux interfaces réseaux, chacune câblée séparément sur les deux réseaux  

L'automate "vois" et "discute" avec ses stations interbus/profibus/modbus-IP/whatever
L'automate peux causer avec ses petits copains automates/La supervision/BDD etc

Mais jamais, jamais au grand jamais un module modbus ne peut voir  directement la supervision   Pas même un ping  

Personne n'utilise une diode ? J'ai du jouer avec ya qq années

En industrie " on" est du genre conservateur voir rétrograde  
La séparation physique est une solution plus rapide, facile à mette en place et qui demande pas un spécialiste réseau pour le gérer  

Suffit d'être asses bon pour tenir à jour un tableau Excel des IP utilisés  

J'ai vu de tout et n'importe quoi (et souvent n'importe quoi), mais il n'y a pas vraiment de "vraies" bonnes réponses entre domaine commun, domaine séparé et workgroup managé. Généralement c'est du workgroup non managé dans l'immense majorité des cas, ce qu'il faut précisément éviter
Je n'ai jamais vu de boîte indus capable d'aligner les ressources (humaines/financières/process/management) pour gérer avec la même rigueur et la même efficacité des environnements bureautique et indus étanches. Dans la plupart des cas, gérer le premier est déjà hors de portée, le second disposant d'une IT en phase avec le XIXe siècle
Pour LTSC je vois de moins en moins l'intérêt sauf scénario ultra-spécifique, les coûts sont exhorbitants pour une valeur ajoutée réduite à peau de chagrin.
 
Ensuite je ne te cache pas que tu contribues largement aux problèmes que tu décris. Dev kissikoné fier de l'être avec des droits admin, c'est un des pires scénarios qui soient (pour ta boîte, et pour toi). Tu ne connais même pas le principe d'un master, ça fait flipper. Mais bon, vu ce que tu décris des process, de la gouvernance et de l'IT de ta boîte, c'est raccord Je me dis que tu bosses peut-être dans la même que Le Keiser

La plupart des gens l'appellent Popaul, mais tu fais ce que tu veux quelque part

Intéressant ces blocs logiques, je regarderai plus en détail si j'en ai un qui me passe sous la main  
Palo Alto ça va venir bientôt, j'ai pas encore une grande expérience de la CLI, seulement quelques commandes.

 
D'un côté je suis un peu d'accord, de l'autre au bout d'un moment quand l'organisation refuse de faire les choses bien, le luser en bas de la chaîne de décision il fait ce qu'il peut pour avancer dans son boulot, et on peut pas vraiment lui en vouloir. Je ne dis pas que c'est le cas ici je n'en sais rien, mais c'est un cas courant je pense.

Oh, ça va! Il a juste dit logiciel pas autorisé.  
 
Une de mes premières cogip on avait un partage pour nos logiciels, internet et l'espace disque c'était pas ça dans le temps. Mes collègues étaient bordéliques, du coup j'avais réorganisé ça avec à la racine trois dossiers: free, license, warez. L'IT a tilté au bout de bien 1 an, ils m'ont "retrouvé" parce que j'étais le propriétaire des dossiers, mais les warez n'étaient pas de moi.

Pas de gouvernance, pas d'accompagnement utilisateur, (users et techs), pas de formations, pas de mode projet, de l'IT avec la bite et le couteau parce que c'est un centre de coûts, le cocktail classique.

Quand ils vont se prendre un ransomware qui va bien ça va être très cher. C'est pas faux du coup.

Sélection naturelle

Oui, après, si tu passes entre les grosses m****, c'est formateur  

Si tu pilotes du Palo en CLI, you are doing it wrong

On fait du soft car c'est plus souple pour nous et ça garde la compétance indus en interne, mais personne n'est softeux / info de formation. On est inge electronic / mesure a La base.

Ça fait 2 ans que je pousse pour utiliser un gît pour vous dire.
Clairement je suis le kisikone, j'ai des idée de comment mieux mieux faire, mais je sais pas forcément /pas le temps / pas mon job.

On est pas du tout dans le même métier que l'it maiws on depends d'eux, voir on devrais bosser en ensemble, sauf que ils comprennent /connaissent pas notre job. Fin c'est galère quoi.

Pour les soft, open source interdis... Sombre histoire de qui paie si y'a une fuite /ransom à cause du dis soft.

J'ai galèrer pour faire autorisé visual studio 22 et vs code...
Des logiciels interdis, il m'en reste pas des masses, j'ai libre office vus qu'on a plsi la suite office (full cloud, mais des fois t'as un vieux doc sur ton pc), gimp pour une retouche qui passe pas dans paint, sonic visualizer pour voir des courbes de fichier audio, audacity, aimp (il m'ont refusé foobar..) win merge, gittyup.
Pas du illegal ni du qui crains

Même les soft que j'achète c'est la galère
Visual studio on dois passer par un presta pour avoir l'abonnement et le "contrat de maintenance"

L'industrie auto, c'est vive le passé et l'obsolescence. Vive le port série...
Tu veut plus que ça, tu rame pour faire comprendre ton besoin.

Et je suis le geek de l'équipe. Éditer les fichier de config au note pad Et le versioning a base de g-drive et dossier zip a numéro ne choque personne...
Alors quand je me pointe pour faire de la doc en markdown / export Web Au lieux du doc+pdf...

Fin c'est aussi pour ça que je traîne par la, savoir ce qui se fait / théorie / "état de l'art".

Dans les cogip on est tous dans le même bateau. Si on crache pas de pièce en fin de ligne, on est pas payé. Donc faut qu'on s'aide et bosse ensemble du mieux qu'on peut.

What could go wrong ?

De mon côté je suis en train de m'intéresser à la partie réponse à incident.

Faut que je try hard du sed

Tout il est comme ça. Le précédent admin occupait tout plein de postes : la gestion du réseau, des backups, des systèmes, des VM, des... Alors ça marche, ça tourne, ça roule. Mais je suis surpris que rien ne soit vraiment logique. Ni documenté.  
Donc je crois que mon périmètre attendu, c'est le même. Faire tout et que ça marche.  
 
Par exemple : les VM sont répliquées automatiquement selon un script ou des scripts qu'il a fait. Et elles sont sauvegardées par VEEAM selon des policies qu'il a faites. Mais rien n'a été documenté. Aucune procédure. Alors pour l'instant, je vis avec. Mais va falloir que j'aille jeter un oeil pour voir ce que je dois faire en cas de problème. Et ça risque de piquer les yeux.  
 
Le réseau, j'en ai parlé. Il fonctionne. Mais avec de projet NAC, il y a whatmille switchs à changer, à upgrader, à... Si il y avait des schémas, des trucs que je pourrai suivre, ça serait déjà ça. Mais non. Il y a des sites où il n'y a rien sur le réseau. Je veux dire qu'il y a bien un fichier Excel avec la plage IP de production, là où devraient se trouver les IP des serveurs & Cie. Mais il est vide    Il y un Excel avec les switchs mais il date et il y a des switchs qui n'y sont plus.  
 
Bref, il y a beaucoup à faire.  
Comme certains l'ont dit ici, c'est un bon poste pour me faire les dents. Alors je n'aurai pas votre expérience après, mais je ne peux que progresser de mon niveau actuel. Donc c'est intéressant. Et motivant.
Rien que ce petit problème de création de VM, j'ai pas mal appris, et grâce à vous, ça a pu se faire

Utilise netdisco