Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Pb script netsh sous Vista

7 réponses
Avatar
Michel Claveau
Bonsoir !

Chez certains clients, j'use et abuse de "Netsh exec", dans des batchs,
pour changer, à la demande, les configurations TCP/IP

Et, ça fonctionne très bien avec W2K et WXP.

Seulement, maintenant, je dois mettre en place ce genre scripts pour
des portables sous Vista.

Et, ça ne marche plus ! Les scripts se déroulent normalement, sans
erreur, mais les configs IP ne changent pas.
J'ai bien vérifié que les scripts étaient lancés en Administrateur, et,
d'autre part, je désactive systématiquement le CUA et le parefeux (qui
ne sert à rien en environnement professionnel).

Est-ce que d'autres ont déjà eu ce genre de problème ? Une idée de
solution ?

--
@-salutations

Michel Claveau

7 réponses

Avatar
Jacques Barathon [MS]
"Michel Claveau" <Enleverles wrote in message
news:
<...
d'autre part, je désactive systématiquement le CUA et le parefeux (qui ne
sert à rien en environnement professionnel).


Bigre, tu es très confiant! J'espère pour eux qu'ils ne se connectent jamais
en dehors de leur environnement professionnel.
Pour ce qui est de l'UAC, pour quelle raison le désactives-tu? Est-ce
simplement pour pouvoir lancer tes scripts plus facilement, ou est-ce une
demande des utilisateurs?

Est-ce que d'autres ont déjà eu ce genre de problème ? Une idée de
solution ?


A priori je ne vois pas. As-tu un exemple de script que je puisse tester sur
mon poste?

Jacques

Avatar
Michel Claveau
Bonjour !


Bigre, tu es très confiant!


Je suis plutôt réaliste. Il suffit qu'il y ait un routeur, avec du NAT,
pour que toutes les requêtes/tentatives d'intrusion externes soient
vouées à l'échec.
En effet, tout ce qui est "entrant", et pour lequel le routeur n'a pas
été explicitement configuré n'ira nulle part. Le routeur n'ayant aucune
indication sur le poste/IP à utiliser ne fera rien.

Dans le sens "sortant", un parefeux ne peut servir que si un poste
contient un malware voulant "sortir".

Donc, si un poste est infecté.

Et, dans ce cas, le parefeux bloquera simplement l'accès, sans traiter
le problème. Perso, je pense qu'il est préférable, dans ce genre de
cas, de supprimer le malware.

De plus, c'est incroyable, le nombre de problèmes lié aux parefeux
(logiciels, embarqués dans les ordinateurs) ; ça remplit des forums et
des newsgroups.

Bref, les PF logiciels surfent sur une vague
paranoïa-peur_de_l'inconnu-incompétence des utilisateurs, en leur
faisant croire que ça les protègera contre "quelque chose qui est dans
leur ordinateur à leur insu". Le paradoxe, c'est que, s'ils ne sont pas
capables de savoir ce qui tourne dans leur bécane, ils ne sauront
certainement pas configurer correctement leur PF...

Et aussi, je sais comment contourner tous ces parefeux, pour envoyer
des données à l'extérieur, sans que, ni l'utilisateur, ni un parefeu ne
voite rien (juste une indiqcation : il est plus facile de contourner le
PF avec FF qu'avec IE).

Enfin, s'il y a des problèmes de sécurité, j'utilise un logiciel de
surveillance des processus lancés, avec des listes d'approbation, et de
déni. C'est très efficace, moins intrusif, et facile à configurer.




UAC, pour quelle raison le désactives-tu ?


Quatre raisons :
1- tous les messages d'avertissement, de demande de confirmation,
etc. bloquent les automatisations. Or, une bonne partie de mon travail
consiste justement à élaborer des automatismes.
Parfois, supprimer un simple clic facilite grandement le travail
de certains utilisateurs ; a contrario, en rajouter va les
démoraliser...
2- Il arrive assez souvent qu'il faille lancer des choses en tant
qu'administrateur. Alors, si c'est pour configurer tous les scripts,
batch, icônes pour s'exécuter en tant qu'administrateur, autant mettre
l'utilisateur directement comme administrateur local.
3- je travaille à 99,99999 % pour des professionnels. Et, la plupart
des postes de mes clients font fonctionner 4 ou 5 logiciels. Et c'est
tout. Et, même, la moitié des ordinateurs ne font tourner qu'un seul
logiciel. D'ailleurs, ce ne sont pas les postes qui ont besoin d'aller
sur Internet, mais les logiciels, pour des fonctions internes.
il n'y a donc pas de raison de limiter ces postes.
4- cette raison, c'est juste pour qu'il y en ait bien quatre ; que le
compte soit bon.



As-tu un exemple de script que je puisse tester sur mon poste


Difficile d'exporter les configs de mes clients.
Mais, tu peux tester à partir de ça :

netsh dump>config_1.txt sauvegarde une configuration réseau, dans
le script netsh nommé "config_1.txt"

netsh exec config_1.txt met en place une configuration réseau,
d'après le script "config_1.txt"

C'est très pratique, par exemple, lorsque l'on doit souvent changer de
site.

Anecdote : il existe des logiciels commerciaux, vendus quelques
centaines d'euros, et qui ne font que ça (sauvegarder/restaurer une
config réseau.
Et, dire que si j'avais la fibre commerciale, je pourrais être plus
riche que BG...







--
@-salutations

Michel Claveau

Avatar
Méta-MCI
Salut !

Ma réponse avec MN n'étant visible pas passée, je tente un nouvel envoi,
avec OE.

______________________________________________


Bonjour !


Bigre, tu es très confiant!


Je suis plutôt réaliste. Il suffit qu'il y ait un routeur, avec du NAT, pour
que toutes les requêtes/tentatives d'intrusion externes soient vouées à
l'échec.
En effet, tout ce qui est "entrant", et pour lequel le routeur n'a pas été
explicitement configuré n'ira nulle part. Le routeur n'ayant aucune
indication sur le poste/IP à utiliser ne fera rien.

Dans le sens "sortant", un parefeu ne peut servir que si un poste contient
un malware voulant "sortir".

Donc, si un poste est infecté.

Et, dans ce cas, le parefeu bloquera simplement l'accès, sans traiter le
problème. Perso, je pense qu'il est préférable, dans ce genre de cas, de
supprimer le malware.

De plus, c'est incroyable, le nombre de problèmes lié aux parefeux
(logiciels, embarqués dans les ordinateurs) ; ça remplit des forums et des
newsgroups.

Bref, les PF logiciels surfent sur une vague
paranoïa-peur_de_l'inconnu-incompétence des utilisateurs, en leur faisant
croire que ça les protègera contre "quelque chose qui est dans leur
ordinateur à leur insu". Le paradoxe, c'est que, s'ils ne sont pas capables
de savoir ce qui tourne dans leur bécane, ils ne sauront certainement pas
configurer correctement leur PF...

Et aussi, je sais comment contourner tous ces parefeux, pour envoyer des
données à l'extérieur, sans que, ni l'utilisateur, ni un parefeu ne voit
rien (juste une indication : il est plus facile de contourner un PF avec FF
qu'avec IE).

Enfin, s'il y a des problèmes de sécurité, j'utilise un logiciel de
surveillance des processus lancés, avec des listes d'approbation, et de
déni. C'est très efficace, moins intrusif, et facile à configurer.




UAC, pour quelle raison le désactives-tu ?


Quatre raisons :
1- tous les messages d'avertissement, de demande de confirmation, etc.
bloquent les automatisations. Or, une bonne partie de mon travail consiste
justement à élaborer des automatismes.
Parfois, supprimer un simple clic facilite grandement le travail de
certains utilisateurs ; a contrario, en rajouter va les démoraliser...
2- Il arrive assez souvent qu'il faille lancer des choses en tant
qu'administrateur. Alors, si c'est pour configurer tous les scripts, batch,
icônes pour s'exécuter en tant qu'administrateur, autant mettre
l'utilisateur directement comme administrateur local.
3- je travaille à 99,99999 % pour des professionnels. Et, la plupart des
postes de mes clients font fonctionner 4 ou 5 logiciels. Et c'est tout. Et,
même, la moitié des ordinateurs ne font tourner qu'un seul logiciel.
D'ailleurs, ce ne sont pas les postes qui ont besoin d'aller sur Internet,
mais les logiciels, pour des fonctions internes.
il n'y a donc pas de raison de limiter ces postes.
4- cette raison, c'est juste pour qu'il y en ait bien quatre ; que le
compte soit bon.



As-tu un exemple de script que je puisse tester sur mon poste


Difficile d'exporter les configs de mes clients.
Mais, tu peux tester à partir de ça :

netsh dump>config_1.txt sauvegarde une configuration réseau, dans le
script netsh nommé "config_1.txt"

netsh exec config_1.txt met en place une configuration réseau, d'après
le script "config_1.txt"

C'est très pratique, par exemple, lorsque l'on doit souvent changer de site.

Anecdote : il existe des logiciels commerciaux, vendus quelques centaines
d'euros, et qui ne font que ça (sauvegarder/restaurer une config réseau.
Et, dire que si j'avais la fibre commerciale, je pourrais être plus riche
que BG...



MCI

Avatar
Méta-MCI
Ah ? Ben si, le message est passé. Mais, il a quand même mit près de 40
minutes à apparaître (je l'avais posté AVANT le message des parrainages,
malgré l'heure indiquée dans les headers, qui ne correspond pas au source
que j'ai envoyé.

Enfin, bon, l'essentiel, c'est qu'il soit arrivé.
Avatar
Jacques Barathon [MS]
"Michel Claveau" <Enleverles wrote in message
news:
Bonjour !


Bigre, tu es très confiant!


Je suis plutôt réaliste. Il suffit qu'il y ait un routeur, avec du NAT,
pour que toutes les requêtes/tentatives d'intrusion externes soient vouées
à l'échec.
En effet, tout ce qui est "entrant", et pour lequel le routeur n'a pas été
explicitement configuré n'ira nulle part. Le routeur n'ayant aucune
indication sur le poste/IP à utiliser ne fera rien.


Ca je sais, mais tu as parlé de portables, donc par nature appelés à se
trouver en dehors de ce contexte protégé du réseau d'entreprise. C'est là où
les choses se compliquent et où un pare-feu logiciel sur le poste lui-même
se révèle important.

Dans le sens "sortant", un parefeux ne peut servir que si un poste
contient un malware voulant "sortir".

Donc, si un poste est infecté.


Oui, c'est ce qui peut arriver si un portable sans pare-feu se connecte à
l'extérieur de l'entreprise, ou si l'utilisateur télécharge un fichier qui
échappe aux contrôles du pare-feu global de l'entreprise.

Et, dans ce cas, le parefeux bloquera simplement l'accès, sans traiter le
problème. Perso, je pense qu'il est préférable, dans ce genre de cas, de
supprimer le malware.


L'un n'empêche pas l'autre. Empêcher la contamination, c'est au moins
circonscrire le problème à un seul poste, au lieu de disséminer le problème
sur tout le réseau (d'autant plus qu'avec ton système, les autres postes ne
sont pas protégés puisqu'étant dans l'entreprise ils n'ont pas de pare-feu
non plus).

<...>
UAC, pour quelle raison le désactives-tu ?


Quatre raisons :
1- tous les messages d'avertissement, de demande de confirmation, etc.
bloquent les automatisations. Or, une bonne partie de mon travail consiste
justement à élaborer des automatismes.


Est-ce que tous les automatismes que tu élabores nécessitent des droits
d'administrateur? Si oui, sont-ils si fréquemment invoqués qu'autoriser leur
exécution relève de la contrainte insupportable?

Parfois, supprimer un simple clic facilite grandement le travail de
certains utilisateurs ; a contrario, en rajouter va les démoraliser...


Ben, ils sont fragiles tes utilisateurs :-)

2- Il arrive assez souvent qu'il faille lancer des choses en tant
qu'administrateur. Alors, si c'est pour configurer tous les scripts,
batch, icônes pour s'exécuter en tant qu'administrateur, autant mettre
l'utilisateur directement comme administrateur local.


Diable, "assez souvent"? Que font ces postes de si spécial? Sur mon poste,
je n'ai guère que deux ou trois demandes de confirmation UAC par jour, et
encore.

3- je travaille à 99,99999 % pour des professionnels. Et, la plupart des
postes de mes clients font fonctionner 4 ou 5 logiciels. Et c'est tout.
Et, même, la moitié des ordinateurs ne font tourner qu'un seul logiciel.
D'ailleurs, ce ne sont pas les postes qui ont besoin d'aller sur Internet,
mais les logiciels, pour des fonctions internes.


S'ils exécutent peu de logiciels, raison de plus pour être surpris par les
besoins si fréquents d'exécuter des tâches en tant qu'administrateur.

4- cette raison, c'est juste pour qu'il y en ait bien quatre ; que le
compte soit bon.


Enfin une bonne raison, là c'est indiscutable :-)

<...>
Difficile d'exporter les configs de mes clients.
Mais, tu peux tester à partir de ça :

netsh dump>config_1.txt sauvegarde une configuration réseau, dans le
script netsh nommé "config_1.txt"

netsh exec config_1.txt met en place une configuration réseau, d'après
le script "config_1.txt"


Je vois plusieurs problèmes potentiels en reproduisant le test sur mon poste
(Vista Ultimate US 32bits):

- La config sauvegardée ne contient pas les détails de configuration TCP/IP
des adaptateurs réseau. Je l'ai vérifié en éditant le fichier de config.
Résultat, si je change la config IP entre les deux commandes netsh, je me
retrouve dans une situation bancale (par exemple, si je passe l'adaptateur
en IP fixe, après restauration l'adresse fixe est supprimée mais
l'adaptateur pas repassé en DHCP).
- L'exécution du fichier de configuration donne quelques messages d'erreur,
notamment sur un paramètre "luid" qui n'existerait pas dans le contexte
invoqué...

Je n'ai pas une expérience suffisante de netsh en environnement pré-Vista
pour te dire si ce genre de problème est nouveau. Tu devrais peut-être
poster ce problème sur un groupe dédié à Vista, par exemple
microsoft.public.fr.windows.vista.reseau.

Jacques


Avatar
~Jean-Marc~ [MVP]
Salut Jacques Barathon [MS],
tu nous disais :
netsh dump>config_1.txt sauvegarde une configuration réseau,
dans le script netsh nommé "config_1.txt"

netsh exec config_1.txt met en place une configuration réseau,
d'après le script "config_1.txt"



(coupe-coupe)

Juste une info en passant :
le netsh dump>config_1.txt ne sauve pas les config IP, mais le
netsh int dump>config_1.txt le fait... ;-)
(j'ai constaté ça récemment sous XP SP2)

@+

--
~Jean-Marc~ MVP Shell/User Fr
( Vista x86 Ultimate )
- http://msmvps.com/blogs/docxp/ -
- http://docxp.mvps.org -


Avatar
Michel Claveau
Bonsoir !

netsh dump>config_1.txt sauvegarde une configuration réseau,



Juste une info en passant :
le netsh dump>config_1.txt ne sauve pas les config IP, mais le
netsh int dump>config_1.txt le fait... ;-)
(j'ai constaté ça récemment sous XP SP2)


Attention, j'ai dit que ça sauvagerdait (toute) la config réseau (pas
seulement IP)

Mais, la partie IP (interface) est bien incluse dans le dump. Je viens
de le vérifier sur une dizaine de scripts générés (sous XP-SP2).


Si cela ne figure pas chez toi, cela provient peut-être d'une
particularité qu'il serait intéressant de déterminer.








--
@-salutations

Michel Claveau