Salut à tous, aujourd’hui j’ai eu un besoin d’envoyer un CSV en HTTP en PowerShell. J’ai fait ça pour automatiser un envoi de fichier de résultat de script entre 2 serveurs. Ma grosse contrainte était que je pouvais pas faire du mode ‘Push’ (cf. transfert SCP sans mot de passe) comme je partais d’une zone de sécurité moindre que celle de destination. Et comme, le fichier source venait d’un Windows, je ne voulais pas mettre en place un serveur Web IIS sur le serveur pour un pauvre fichier CSV à transférer 2 fois par jour…
Du coup, j’ai bricolé quelques lignes à la fin de mon script PowerShell pour exposer le fichier en HTTP et permettre au serveur destination de venir les « Puller » pour respecter le sens d’établissement du flux.
Et sans transition le script pour envoyer un CSV en HTTP en PowerShell :
Function New-SimpleHTTPListener {
Param (
[Parameter()] [Int] $Port = 7443
)
Begin{
$listener = New-Object System.Net.HttpListener
$prefix = "http://localhost:$Port/"
$listener.Prefixes.Add($prefix)
}
Process{
try{
$listener.Start()
Write-Host "Listening on $Port ..."
$pathwd = Get-Location
while ($listener.IsListening) {
$context = $listener.GetContext()
if ($context.Request.HttpMethod -eq 'GET' -and $context.Request.RawUrl -eq '/quit')
{
$listener.Close()
break;
}
$HTTPresponse = $context.Response
$HTTPresponse.StatusCode = "200"
$HTTPResponse.Headers.Add("Content-Type","text/csv")
$RequestUrl = $context.Request.Url.OriginalString
$data = [System.Text.UTF8Encoding]::UTF8.GetBytes([System.IO.File]::ReadAllText("$pathwd" + '\' + ($RequestUrl.Split('/')[-1])))
$HTTPresponse.ContentLength64 = $data.Length
$output = $HTTPresponse.OutputStream
$output.Write($data,0,$data.Length)
$output.Close()
}
}catch{
Write-Warning "Error with Server : $_"
}Finally{
Write-Warning "terminating Server : $_"
$listener.Stop()
}
}
End{
}
}
New-SimpleHTTPListenerAlors clairement, c’est du bon gros « quick and dirty » :
- Ça demande que votre serveur destination passe un peu après la fin d’exécution du script sur le serveur source et indique au script qu’il a bien récupéré le fichier.
- Aucune gestion d’erreur, ça crash dès que vous appeler un fichier non présent par exemple.
- Il n’y a pas de chiffrement, ni d’authentification (même si je vous ai déjà montré comment faire ici et là).
Mais dans les faits j’ai gagné 3 semaines de demande de dérogation et d’ouverture du flux ! 🙂
Bref, ce petit use case pour envoyer un CSV en HTTP en PowerShell me permet d’illustrer un point important, c’est que lorsque la sécurité est trop rigide dans une organisation, les utilisateurs (et les admins) finissent toujours par préférer contourner que respecter.
Les gens vont au plus simple, les objectifs qu’on leur fixe ne sont pas de « travailler en sécurité » mais plutôt « que le projet soit terminé dans les temps, en sécurité, si possible… Et puis tant qu’il n’y a pas d’incident on s’en tape un peu en fait » .
Ce qui me permet de conclure sur ce petit rappel à mes confrères puriste de la SII : les pratiques évoluent d’abord malgré nos avertissements, et la sécurité s’adapte ensuite de toute façon. C’est chiant mais c’est notre taf (voir la règles des 5 ‘C’), le jour où tous les projets et évolutions arriveront en mode « security by design », on en aura plus, du taf… ^^
Sur ce geekez à bien à contourner vos politiques de sécurité !
