Le port 80 est utilisé par SYSTEM (PID 4), qu'est-ce que c'est?

J'essaie d'utiliser le port 80 pour mon serveur d'applications, mais lorsque j'effectue "netstat -aon", j'obtiens

TCP 0.0.0.0:80 0.0.0.0:0 ECOUTE 4

Lorsque je recherche le processus dans le gestionnaire de tâches, il montre que PID 4 est SYSTEM, c'est tout, pas d'extension ... rien, juste "SYSTEM". Que se passe t-il ici?

J'ai peur de mettre fin à ce processus, que dois-je faire?

Bien que des personnes signalent des services spécifiques (par exemple, le "service d'agent de déploiement Web"), cela ne parvient pas à résoudre la cause première. Si vous désactivez simplement les services qui déclenchent le problème, il est probable qu'il réapparaîtra à l'avenir sous une forme légèrement différente. Il vaut donc la peine de comprendre ce qui ne va pas, car cela conduit à une meilleure solution.

Ce problème se produit lorsqu'un serveur d'applications souhaite un contrôle total du port 80. Cela entre en conflit avec une fonctionnalité de Windows conçue pour permettre à plusieurs processus de gérer les demandes sur le port 80. Il est tout à fait possible d'avoir un nombre illimité de processus recevant tous des demandes HTTP sur le port. 80, car Windows dispose d'un mécanisme de répartition HTTP intégré. Chaque processus peut indiquer à Windows les URL qu'il souhaite gérer.

Cependant, si un serveur d'applications ignore totalement cela, vous êtes de retour dans le monde des sockets old-school moins flexible où un seul processus peut recevoir des demandes destinées à un port particulier.

Cela peut être bien - si vous ne voulez vraiment rien d'autre qu'un processus particulier gérant la requête HTTP sur le port 80, alors il devient tolérable d'utiliser un serveur d'applications qui ne prend pas en charge les mécanismes plus flexibles offerts par Windows. (Et certains serveurs d'applications populaires ont cette limitation. Par exemple, AFAIK, Tomcat est incapable de bien jouer avec les autres et insiste pour avoir le port 80 pour lui tout seul. Donc, si vous utilisez le serveur d'applications de quelqu'un d'autre, il peut être difficile de l'adapter pour utiliser le mécanisme préféré.)

Windows tente de prendre en charge de tels services inflexibles en ne liant pas son mécanisme de répartition au port 80 jusqu'à ce que quelque chose le demande activement. (C'est pourquoi vous ne verrez pas nécessairement un problème au départ, mais vous pouvez rencontrer ce problème après une sorte de mise à jour ou de changement de configuration.) Mais compter sur ce n'est pas une solution très solide - vous avez essentiellement confiance en la chance que rien tente d'écouter sous le port 80 avant le lancement de votre serveur d'applications. (Il existe plusieurs raisons pour lesquelles un processus peut tenter de s'inscrire pour certaines URL sur le port 80 de manière spéculative, puis le désactiver s'il n'est pas autorisé.)

Donc, si vous voulez qu'un service ait un accès exclusif au port 80, vous feriez mieux de le dire à Windows. Il n'est pas vraiment suffisant d'essayer de désactiver tous les services qui pourraient essayer d'utiliser le mécanisme de partage de port habituel, car il est difficile d'être sûr que vous les avez tous trouvés. (En particulier lorsque les mises à jour Windows semblent modifier ce qui est activé par défaut.) Il est probablement recommandé de désactiver celles que vous connaissez, mais il est préférable de procéder de la même manière: désactivez les services dont vous ne voulez pas et assurez-vous également que ce n'est pas le cas. possible pour ceux que vous ne connaissiez pas de vous trébucher.

Par défaut HTTP.SYS(le mécanisme de répartition HTTP de partage de port sous-jacent dans Windows) est capable d'écouter sur toutes les adresses. Mais vous pouvez le lui dire. Cette page montre une façon de le faire: http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/

C'est une façon relativement légère de le faire, car elle permet toujours d'écouter sur localhost pour IPv6. Il libère simplement le port IPv4 80. Vous pouvez aller plus loin avec une configuration plus spécialisée. (Vous pouvez même désactiver HTTP.SYScomplètement, mais cela pourrait casser des choses en utilisant des ports autres que 80, donc cela pourrait causer des problèmes.)

Mais quoi que vous fassiez, le but est de vous assurer que HTTP.SYSvous n'écoutez pas sur le port 80 sur l'adresse IP qui vous intéresse. Une fois que vous avez fait cela, vous n'avez pas à vous soucier de la désactivation des services, ni à vous soucier des autres changements réintroduisant le problème. Si vous vous êtes assuré que le point de terminaison dont vous avez besoin est effectivement hors limites pour le partage de port, vous devez constater que le processus système cesse de s'y lier.

Le coupable était le service d'agent de déploiement Web.

Meilleure solution que net stop httpd'arrêter les services nommés "Web Deployment Agent Service".

Il s'agit très probablement d' IIS 6.0 ou d'une version ultérieure.

La pile de protocoles HTTP (HTTP.sys), qui s'exécute en mode noyau , reçoit les demandes des clients et les achemine vers la file d'attente de demandes appropriée. Les processus de travail, qui s'exécutent en mode utilisateur, extraient les demandes directement de leurs propres files d'attente de demandes de noyau, éliminant les sauts de processus qui se produisent dans IIS 5.0 (et qui se produisent également en mode d'isolation IIS 5.0) lorsque le serveur Web envoie une demande à un niveau élevé. -isolement, application hors processus. Étant donné que ces sauts de processus supplémentaires sont éliminés en mode d'isolation du processus de travail, IIS peut fournir l'isolation des applications sans sacrifier les performances.

Essayez d'arrêter le HTTP.SYSen entrant dans Device Manager/Non Plug and Play Driverset sélectionnez HTTP, essayez de l'arrêter et vous verrez des services qui déclenchent ce HTTP pour utiliser le port 80.

La dernière fois que j'ai vérifié, vous ne pouvez pas mettre fin au processus "système", et si vous le faites, je suppose que cela aura des effets catastrophiques. Je ne vais pas l'essayer sur le PC sur lequel je suis en ce moment non plus!

Il semblerait que quelque chose à l'intérieur de Windows écoute: 80 - Je vais deviner que cela pourrait être quelque chose de malveillant. La meilleure façon de le savoir est de:

a) Ouvrez un navigateur Web sur localhost et voyez ce qui se passe

b) Démarrez Telnet et telnet à localhost 80 et exécutez un HTTP GET de base (par exemple GET /) et voyez ce qu'il renvoie

B est la meilleure option si vous pensez que vous pourriez héberger des logiciels malveillants, car vous ne voulez pas vraiment vous infecter à nouveau. Mais peut-être que cela n'aura pas d'importance.

J'ai trouvé la réponse à cette question sur: /superuser/352017/pid4-using-port-80

Plus précisément, lorsqu'il s'agit du processus système 4, vous devez désactiver le pilote HTTP.sys qui est démarré à la demande par un autre service, tel que Windows Remote Management ou Print Spooler sous Windows 7 ou 2008.

1. Allez dans le gestionnaire de périphériques, sélectionnez «afficher les périphériques cachés» dans le menu / vue, allez dans «Pilote non Plug-and-Play» / HTTP, double-cliquez dessus pour le désactiver (ou définissez-le sur manuel, certains services en dépendent).

Redémarrez et utilisez netstat -nao | recherchez «: 80» pour vérifier si 80 est toujours utilisé.

J'ai également essayé de récupérer le port en exécutant simplement un "net stop http" mais le port n'a jamais semblé être libéré. Ce qui précède a fonctionné pour moi cependant, et je n'ai pas eu besoin des autres services qui dépendaient de ce conducteur.

Le partage de synchronisation Windows est ce qui nous a tués sur Windows 2012 R2. Une fois que nous avons désactivé cette fonctionnalité, tout s'est bien passé.

Dans mon cas, cela était dû au fait que l'anti-virus Carbon Black prenait en quelque sorte une mainmise sur le port 80. J'ai passé des heures à essayer de le comprendre, donc je me sens obligé de partager juste au cas où cela conduirait un autre pauvre âme à la lumière :) 't savent comment il a été corrigé exactement, allez demander à votre équipe serveur / réseau!

J'ai résolu cela grâce à une question de stackoverflow. Suivez ce lien pour trouver la solution pour que IIS arrête d'écouter sur le port 80 une adresse IP spécifiée.