Connaître le process associé à un paquet ignoré sur Windows
8 octobre 2017
J’ai cette semaine donné deux formations sur la sécurité informatique ou cybersécurité au Futuroscope de Poitiers. Et j’ai eu la drôle de surprise sur ma machine qui exécute une version d’évaluation de Windows Server 2016 de trouver les traces de bien drôles de requêtes. J’ai voulu en savoir plus.
Journaliser les paquets ignorés
| Afin de visualiser tous les paquets ignorés (DROP), vous devez lancer la console wf.msc. Dans les propriétés du pare-feu accessibles par un clic droit à la racine de la console, cliquez sur Personnaliser au niveau de Enregistrement. au niveau des trois onglets Profil de domaine, Profil privé et Profil public. |  |
 |
Par défaut, les logs du pare-feu Windows sont stockés dans le fichier %systemroot%\system32\LogFiles\Firewall\pfirewall.log. Il peut être intéressant d’indiquer un fichier différent pour chacun des trois profils. |
Un extrait du journal
Ni le numéro de process, ni le nom du process n’apparaissent dans ce fichier !
2017-10-07 12:30:45 DROP TCP 192.168.1.100 131.253.61.82 57381 443 0 - 0 0 0 - - - SEND 2017-10-07 12:30:45 DROP TCP 192.168.1.100 131.253.61.102 57382 443 0 - 0 0 0 - - - SEND 2017-10-07 12:30:45 DROP TCP 192.168.1.100 131.253.61.100 57383 443 0 - 0 0 0 - - - SEND 2017-10-07 12:30:45 DROP TCP 192.168.1.100 131.253.61.80 57384 443 0 - 0 0 0 - - - SEND 2017-10-07 12:30:45 DROP TCP 192.168.1.100 131.253.61.66 57385 443 0 - 0 0 0 - - - SEND 2017-10-07 12:30:45 DROP TCP 192.168.1.100 131.253.61.70 57386 443 0 - 0 0 0 - - - SEND
Indétermination du process
Pour déterminer le process à l’origine de cette sortie de paquets, j’ai dû modifier, à partir de la console gpedit.msc, la stratégie Auditer l’accès aux objets accessible à partir de Configuration de l’ordinateur > Paramètres Windows > Stratégies locales > Stratégies d’audit. comme suit :
Il suffit ensuite d’aller dans le journal Sécurité de l’observateur d’événements Windows (eventvwr.msc ou eventvwr.exe).
Un script PowerShell pour visualiser le process associé au paquet ignoré
Je vous recommande de nettoyer le journal d’événements Sécurité avant d’exécuter ce script PowerShell et d’attendre quelques secondes.
Clear
$res=@()
$events=Get-EventLog -LogName Security|Where {$_.InstanceId -in 5157,5158}|Select -Property TimeGenerated,Message,InstanceId
ForEach($event in $events)
{
$date=$event.TimeGenerated
$paquet=$event.InstanceId
If($paquet -eq '5158')
{
$paquet='ALLOW'
}
ElseIf($paquet -eq '5157')
{
$paquet='DROP'
}
$rows=($event.Message -split '`n')
ForEach($row in $rows)
{
If($row -match 'application.:.([\\a-z0-9\. \)\(]+)')
{
$app=$Matches[1]
}
If($row -match 'Direction[^:]+:[^%]+%%([0-9]+)')
{
$dir=$Matches[1]
If($dir -eq '14592')
{
$dir='Entrant';
}
ElseIf($dir -eq '14593')
{
$dir='Sortant';
}
}
If($row -match 'Adresse source[^:]+:[^a-f0-9:]+([a-f:\.0-9]+)')
{
$addrsrc=$Matches[1]
}
If($row -match 'Port source[^:]+:[^0-9]+([0-9]+)')
{
$portsrc=$Matches[1]
}
If($row -match 'Adresse de destination[^:]+:[^a-f0-9:]+([a-f:\.0-9]+)')
{
$addrdst=$Matches[1]
}
If($row -match 'Port de destination[^:]+:[^0-9]+([0-9]+)')
{
$portdst=$Matches[1]
}
If($row -match 'Protocole[^:]+:[^0-9]+([0-9]+)')
{
$prot=$Matches[1]
}
<#
If($prot -eq '6' -and ($portsrc -eq '443' -or $portdst -eq '443') -and $addrdst -eq '192.168.1.100')
#>
#{
$res+=[PSCustomObject]@{date=$date;paquet=$paquet;app=$app;prot=$prot;dir=$dir;addrsrc=$addrsrc;portsrc=$portsrc;addrdst=$addrdst;portdst=$portdst}
#}
}
$rows=$null
}
$events=$null
#$res|Out-GridView
#$res|Where {$_.paquet -eq 'DROP' -and $_.app -notmatch '^System$|svchost'}|Out-GridView
$res|Where {$_.paquet -eq 'DROP'}|Out-GridView
$res=$null
# Clear-EventLog vous permet de nettoyer votre journal d'événements
#Clear-EventLog -LogName Security
De bien drôles de paquets
Il s’agit d’un retour de paquets issus de la consultation d’un site à partir d’un port dynamique différent de celui par lequel le paquet d’origine est sorti. C’est assez incompréhensible et il faut que je creuse ! Je tiens tout de même à vous rassurer : ces paquets ont été bloqués par mes règles de pare-feu Windows, dans lequel nous pouvons préciser le process !
Peut-être, une explication…
Je pensais qu’il s’agissait d’un problème lié au mode multiprocess de Firefox. La sortie sur le Tcp/80 ou Tcp/443 se fait sur un port différent du fait qu’il n’utilise pas le même process à l’aller qu’au retour. En fait, c’est pas ça !