Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Scripting Microsoft PowerShell Script Firewall

PowerShell Script Firewall

29 réponses
Avatar
Robby
Bonjour,

Est-il possible de savoir les ports ouverts d'un ordi distant du firewall XP
SP2 ?
Avec un script gwmi ou autre ?

Merci d'avance,
Robby
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Jacques Barathon [MS]
"Jean" wrote in message
news:
l'accès à un firewall distant, sais-tu si cette méthode est applicable?


Je ne pratique pas le remote scripting, mais j'ai vu ceci :

http://msdn2.microsoft.com/en-us/library/aa366439.aspx

je ne sais pas si ça fait avancer le schmilblik :-)


Pas sûr. Je crois que le Remote Admin en question n'est pas lié à
l'administration à distance du firewall lui-même. C'est simplement
l'activation d'une exception sur le firewall permettant l'administration à
distance du poste (par exemple via MMC ou toute autre interface
d'administration).

Jacques


Avatar
Robby
Desolé pour la reponse au dessous,
mais ca marche bien, il y avait une erreur $_:
je ne sais pas pourquoi j'ai mis les 2 points.
Enfin merci Jacques et Jean pour votre aide et rapidité et efficacité.
Peut-etre à bientot.

"Jacques Barathon [MS]" a écrit dans le
message de news:
"Robby" wrote in message
news:
Jacques,
J'ai fait le fichier unique, en effet toutes les infos sont dedans mais
je ne sais pas quelles ordinateurs ca concerne.
Pourrias-tu m'aider ?
Encore merci,


Tu peux ajouter du texte avant et/ou après l'exécution de psexec, soit en
redirigant chaque ligne vers le fichier de sortie, soit en encadrant les
commandes par $(...) et en redirigeant l'ensemble vers le fichier. Je te
donne un exemple avec cette dernière méthode. Pour faciliter la
lisibilité, j'écris la suite de commandes sur plusieurs lignes:

get-content postes.txt | foreach {
$(
"$_ :"
psexec $_ netsh firewall show portopening
"=" * 67
) | out-file ports.txt -append
}

Il y aurait également moyen d'utiliser la méthode de Jean (accès au
firewall via l'objet COM). Même si l'objet COM n'est pas directement
attaquable à distance (du moins je ne vois pas comment, mais mes
connaissances en la matière sont limitées je l'avoue) il est toujours
possible d'utiliser la même technique que ci-dessus, c'est-à-dire faire
exécuter la tâche à distance via psexec.

L'avantage de la solution de Jean est qu'avec un minimum d'adaptation elle
pourrait te permettre de stocker les infos de manière un peu plus
exploitable qu'un simple fichier texte, par exemple sous la forme d'un
fichier CSV ou en XML, de manière à pouvoir reprendre les infos dans Excel
ou toute autre appli pour les analyser. On pourrait également le faire
dans le script ci-dessus en décortiquant la sortie de netsh, mais c'est un
peu plus compliqué.

L'inconvénient de la solution de Jean est qu'elle est écrite en
PowerShell. Hé oui, ça peut être un inconvénient ;-) : si tu veux
l'exécuter sur tous les postes il faut au préalable installer PowerShell
sur ces mêmes postes. Evidemment, on peut sans doute traduire tout ça en
VBScript.

Mais bon, si la solution ci-dessus te convient, pas de souci.

Jacques



Avatar
Robby
Jacques,
Je refaits un test avec plusieurs PCs,
mais voila que le script reste bloqué sur un ordi et il ne continu pas.
pourrais t-on forcer le script à derouler si il bloque sur un pc ?
Merci d'avance,

"Jacques Barathon [MS]" a écrit dans le
message de news:
"Robby" wrote in message
news:
Jacques,
J'ai fait le fichier unique, en effet toutes les infos sont dedans mais
je ne sais pas quelles ordinateurs ca concerne.
Pourrias-tu m'aider ?
Encore merci,


Tu peux ajouter du texte avant et/ou après l'exécution de psexec, soit en
redirigant chaque ligne vers le fichier de sortie, soit en encadrant les
commandes par $(...) et en redirigeant l'ensemble vers le fichier. Je te
donne un exemple avec cette dernière méthode. Pour faciliter la
lisibilité, j'écris la suite de commandes sur plusieurs lignes:

get-content postes.txt | foreach {
$(
"$_ :"
psexec $_ netsh firewall show portopening
"=" * 67
) | out-file ports.txt -append
}

Il y aurait également moyen d'utiliser la méthode de Jean (accès au
firewall via l'objet COM). Même si l'objet COM n'est pas directement
attaquable à distance (du moins je ne vois pas comment, mais mes
connaissances en la matière sont limitées je l'avoue) il est toujours
possible d'utiliser la même technique que ci-dessus, c'est-à-dire faire
exécuter la tâche à distance via psexec.

L'avantage de la solution de Jean est qu'avec un minimum d'adaptation elle
pourrait te permettre de stocker les infos de manière un peu plus
exploitable qu'un simple fichier texte, par exemple sous la forme d'un
fichier CSV ou en XML, de manière à pouvoir reprendre les infos dans Excel
ou toute autre appli pour les analyser. On pourrait également le faire
dans le script ci-dessus en décortiquant la sortie de netsh, mais c'est un
peu plus compliqué.

L'inconvénient de la solution de Jean est qu'elle est écrite en
PowerShell. Hé oui, ça peut être un inconvénient ;-) : si tu veux
l'exécuter sur tous les postes il faut au préalable installer PowerShell
sur ces mêmes postes. Evidemment, on peut sans doute traduire tout ça en
VBScript.

Mais bon, si la solution ci-dessus te convient, pas de souci.

Jacques



Avatar
Jacques Barathon [MS]
"Robby" wrote in message
news:
Jacques,
Je refaits un test avec plusieurs PCs,
mais voila que le script reste bloqué sur un ordi et il ne continu pas.
pourrais t-on forcer le script à derouler si il bloque sur un pc ?


La commande psexec a un paramètre -n qui permet de donner un délai maximal
pour l'établissement de la connexion avec la machine distante. Je n'ai pas
testé, mais tu peux peut-être t'en servir pour résoudre ce problème.

Si ça ne suffit pas, peux-tu donner plus de détails sur l'étape à laquelle
le script bloque?

Jacques

Avatar
Robby
J'ai essayé avec -n 90, mais ca reste bloqué.
le script se lance:
il y a une ligne "connecting nomdel'ordi "qui s'affiche rapidement et
ensuite elle disparait, alors normalement elle reste affichée pendant
quelques secondes ~90 le temps qu'elle fasse sa requette.
ensuite le script ne se termine jamais, je suis obligé de faire ctrl-c.
Vois-tu ?

"Jacques Barathon [MS]" a écrit dans le
message de news:
"Robby" wrote in message
news:
Jacques,
Je refaits un test avec plusieurs PCs,
mais voila que le script reste bloqué sur un ordi et il ne continu pas.
pourrais t-on forcer le script à derouler si il bloque sur un pc ?


La commande psexec a un paramètre -n qui permet de donner un délai maximal
pour l'établissement de la connexion avec la machine distante. Je n'ai pas
testé, mais tu peux peut-être t'en servir pour résoudre ce problème.

Si ça ne suffit pas, peux-tu donner plus de détails sur l'étape à laquelle
le script bloque?

Jacques



Avatar
Jacques Barathon [MS]
"Robby" wrote in message
news:
J'ai essayé avec -n 90, mais ca reste bloqué.
le script se lance:
il y a une ligne "connecting nomdel'ordi "qui s'affiche rapidement et
ensuite elle disparait, alors normalement elle reste affichée pendant
quelques secondes ~90 le temps qu'elle fasse sa requette.
ensuite le script ne se termine jamais, je suis obligé de faire ctrl-c.
Vois-tu ?


Pas bien, non. As-tu la ligne "Starting psexec service on nomdel'ordi" après
la connexion?
As-tu vérifié que le PC est bien accessible en dehors de tout script, par un
simple ping ou par un psexec lancé en manuel?

Pour contrer ce genre de blocage de manière automatique, il faut changer de
tactique dans la façon de dérouler le script. Une tactique parmi d'autres
peut consister à créer une instance de la classe System.Diagnostics.Process,
la faire exécuter la requête pour un poste et surveiller son temps
d'exécution. Si le process met plus de x secondes avant de rendre la main,
on le termine de force et on passe au suivant.

C'est très faisable, mais là maintenant je n'ai pas le temps de faire un
premier jet. Je regarderai demain (jeudi) dans l'après-midi, à moins que
quelqu'un ait une réponse efficace d'ici là.

Jacques

Avatar
Robby
Merci Jacques,
En effet le ping fonctionne bien et je me connecte sur le poste à distance
sans pb.
Justement lors de mes tests, j'ai vu qu'il fallait ~90 secondes pour la
requete s'execute normalement.
Donc Ok pour cet AM,
A tout à l'heure.

"Jacques Barathon [MS]" a écrit dans le
message de news: %
"Robby" wrote in message
news:
J'ai essayé avec -n 90, mais ca reste bloqué.
le script se lance:
il y a une ligne "connecting nomdel'ordi "qui s'affiche rapidement et
ensuite elle disparait, alors normalement elle reste affichée pendant
quelques secondes ~90 le temps qu'elle fasse sa requette.
ensuite le script ne se termine jamais, je suis obligé de faire ctrl-c.
Vois-tu ?


Pas bien, non. As-tu la ligne "Starting psexec service on nomdel'ordi"
après la connexion?
As-tu vérifié que le PC est bien accessible en dehors de tout script, par
un simple ping ou par un psexec lancé en manuel?

Pour contrer ce genre de blocage de manière automatique, il faut changer
de tactique dans la façon de dérouler le script. Une tactique parmi
d'autres peut consister à créer une instance de la classe
System.Diagnostics.Process, la faire exécuter la requête pour un poste et
surveiller son temps d'exécution. Si le process met plus de x secondes
avant de rendre la main, on le termine de force et on passe au suivant.

C'est très faisable, mais là maintenant je n'ai pas le temps de faire un
premier jet. Je regarderai demain (jeudi) dans l'après-midi, à moins que
quelqu'un ait une réponse efficace d'ici là.

Jacques



Avatar
Jacques Barathon [MS]
"Jacques Barathon [MS]" wrote in message
news:%
<...>
Pour contrer ce genre de blocage de manière automatique, il faut changer
de tactique dans la façon de dérouler le script. Une tactique parmi
d'autres peut consister à créer une instance de la classe
System.Diagnostics.Process, la faire exécuter la requête pour un poste et
surveiller son temps d'exécution. Si le process met plus de x secondes
avant de rendre la main, on le termine de force et on passe au suivant.


Bon, voici un script assez peu élaboré et difficile à tester en l'absence
d'une situation analogue à la tienne. Dis-moi si ça marche:

--- get-ports.ps1 ---
param (
[string]$computerlist,
[string]$logfile,
[int]$timeout = 120
)

get-content $computerlist | foreach {

"$_ :" >> $logfile

$ps = new-object System.Diagnostics.Process
$ps.StartInfo.FileName = "psexec.exe"
$ps.StartInfo.Arguments = "netsh $_ firewall show portopening"

$ps.StartInfo.UseShellExecute = $false
$ps.StartInfo.RedirectStandardOutput = $true

$ps.Start() > $null

while (!$ps.HasExited) {
$ps.StandardOutput.ReadLine() >> $logfile
if ([datetime]::now -gt $ps.StartTime.AddSeconds($timeout)) {
$ps.Kill()
}
}

"=" * 67 >> $logfile
}
--- fin ---

Tu dois lancer le script en précisant le nom du fichier qui contient la
liste des postes, un timeout en secondes (120 par défaut) et le nom du
fichier dans lequel il faut stocker le résultat. Par exemple:

PS> .get-ports postes.txt ports.txt 90

Comme je le disais, je n'ai pu tester que sur des postes qui répondent
normalement (ou alors avec des noms de machines inexistants auquel cas
psexec rend la main rapidement). A toi de voir si ça permet de débloquer ta
situation.

Si ça ne marche pas avec tes postes, c'est sans doute parce que la ligne
"$ps.StandardOutput.ReadLine() >> $logfile" bloque en attendant un retour.
Il faudra alors gérer différemment la redirection dans un fichier, par
exemple en l'incluant dans le process $ps lui-même.

Jacques

Avatar
Robby
Jacques, c'est ok ca fonctionne super et merci pour ton travail.

"Jacques Barathon [MS]" a écrit dans le
message de news:
"Jacques Barathon [MS]" wrote in message
news:%
<...>
Pour contrer ce genre de blocage de manière automatique, il faut changer
de tactique dans la façon de dérouler le script. Une tactique parmi
d'autres peut consister à créer une instance de la classe
System.Diagnostics.Process, la faire exécuter la requête pour un poste et
surveiller son temps d'exécution. Si le process met plus de x secondes
avant de rendre la main, on le termine de force et on passe au suivant.


Bon, voici un script assez peu élaboré et difficile à tester en l'absence
d'une situation analogue à la tienne. Dis-moi si ça marche:

--- get-ports.ps1 ---
param (
[string]$computerlist,
[string]$logfile,
[int]$timeout = 120
)

get-content $computerlist | foreach {

"$_ :" >> $logfile

$ps = new-object System.Diagnostics.Process
$ps.StartInfo.FileName = "psexec.exe"
$ps.StartInfo.Arguments = "netsh $_ firewall show portopening"

$ps.StartInfo.UseShellExecute = $false
$ps.StartInfo.RedirectStandardOutput = $true

$ps.Start() > $null

while (!$ps.HasExited) {
$ps.StandardOutput.ReadLine() >> $logfile
if ([datetime]::now -gt $ps.StartTime.AddSeconds($timeout)) {
$ps.Kill()
}
}

"=" * 67 >> $logfile
}
--- fin ---

Tu dois lancer le script en précisant le nom du fichier qui contient la
liste des postes, un timeout en secondes (120 par défaut) et le nom du
fichier dans lequel il faut stocker le résultat. Par exemple:

PS> .get-ports postes.txt ports.txt 90

Comme je le disais, je n'ai pu tester que sur des postes qui répondent
normalement (ou alors avec des noms de machines inexistants auquel cas
psexec rend la main rapidement). A toi de voir si ça permet de débloquer
ta situation.

Si ça ne marche pas avec tes postes, c'est sans doute parce que la ligne
"$ps.StandardOutput.ReadLine() >> $logfile" bloque en attendant un retour.
Il faudra alors gérer différemment la redirection dans un fichier, par
exemple en l'incluant dans le process $ps lui-même.

Jacques



1 2 3