Warum lauscht der 'System'-Prozess auf Port 443?

45

Ich habe Probleme beim Starten meines Apache-Servers, da Port 443 bereits belegt ist.

Es stellt sich heraus, dass der Systemprozess (PID 4) den Port 443 verwendet. Ich habe IIS nicht installiert, die Datei services.msc zeigt (vorhersehbar) weder einen aktiven Exchange-Server noch WWW-Services oder IIS an. Ich habe keine Ahnung, wie ich herausfinden soll, welcher Dienst diesen Port verwendet, abgesehen davon, dass nur jeder Dienst nach dem anderen deaktiviert wird, und ich bin mir nicht einmal sicher, ob dies helfen würde.

Ich wäre dankbar, wenn mich jemand darauf hinweisen könnte, wie ich meinen SSL-Port zurückbekomme, danke :)

PS: Natürlich würde "Apache nur auf einen anderen Port für SSL umstellen" das Problem lösen, dass Apache nicht gestartet werden kann. Aber ich würde immer noch gerne wissen, was so hartnäckig daran ist, Port 443 zu hacken. :)

Mittlerweile bin ich den „harten Weg“ gegangen und habe Dienste für Behinderte nacheinander in Anspruch genommen. Es stellte sich heraus, dass der "Routing and RAS" -Dienst der Schuldige war.

Vielen Dank für den wertvollen Input und die neuen Tools im Kampf gegen "WTF macht mein System jetzt?".

windows 
— Cornelius
quelle
Verwandte: superuser.com/questions/121901 Sie eine der Antworten gegeben nutzen könnten um zu ermitteln, welcher Dienst ist 443. Eröffnung Port
— heavyd
1
Leider kann ich "SC Config Servicename Type = own" nicht für eine Verzögerung von Servicename verwenden, da ich nicht (oder nur zu dumm) herausfinden kann, welcher Dienst den Port genau offen hält. Die verschiedenen Beschwörungsformeln von Netstat weisen mich wie gesagt auf den Systemprozess hin, genau wie TCPView. "Stacks", wie für PE, funktionieren anscheinend nicht auf Win7 und da ich keine svchost.exe-Instanz betrachte, habe ich keine "Service" -Spalte auf der Registerkarte "TCP / IP". Skype ist nicht schuld und ich habe auch keine andere VoIP- oder P2P-Software im Einsatz. Aber die andere Frage, die Sie in Verbindung brachten, war für mich aufschlussreich. Dankeschön.
— Cornelius
Danke für die Information! Für mich war es der "Routing and Remote Access" -Dienst, der auch Port 443 gebunden hatte.
— Codler
3
Mann, die Menge der Antworten, die nicht einmal versucht werden, die Frage zu beantworten, ist unglaublich. So ist die Menge an Fehlinformationen. Wenn PID 4 zuhört, ist es http.sys. Immer. Zum Glück gibt es bereits eine Antwort darauf, wie man Einsicht gewinnt .
— Daniel B

Antworten:

18

Führen Sie an einer Eingabeaufforderung mit erhöhten Rechten Folgendes aus:

netstat -ab
— Tonyr Roth
quelle
Ich bin ein bisschen überrascht. Alles andere zeigte nur "den Systemprozess" als Täter. Dieser Befehl behauptet nun, dass es sich um eine svchost.exe handelt, die diesen Port enthält. : | Wie kommt es, dass PE / 'andere' netstat-Aufrufe es unter den Systemprozess subsumieren? (Obwohl der Port weiterhin als von PID 4 / System gehalten angezeigt wird.) Wie kann ich weitere Informationen überprüfen? :(
— Cornelius
Ich bin mir nicht sicher, aber führe PE vielleicht erhöht aus!
— Tonyr Roth
2
auch das folgende kann dir mehr einblick geben wmic process> test.txt
— tonyr roth
1
Ich habe Process Explorer als Administrator ausgeführt - und der Port wird weiterhin angezeigt, wie von "System" angegeben. nicht wirklich viel mehr informationen gibt es dort: | Inzwischen denke ich, dass es etwas wirklich Dummes sein wird, was ich unwissentlich getan habe;)
— Cornelius
4
Das funktioniert bei mir nicht, unter der Zeile mit 0.0.0.0:443 bekomme ich gerade keine Besitzinformationen .
— MGOwen
33

Ich wette, es ist Skype. Deaktivieren Sie das unten gezeigte Kontrollkästchen, wenn Sie es installiert haben.

Alt-Text

— Nifle
quelle
3
+1. Andere VoIP-Clients (und andere Software wie P2P-Dateiübertragungs-Apps) lauschen auf den Ports 80 und 443, wenn sie dort nichts anderes finden, obwohl Skype der häufigste "Täter" ist. Ich bin mir nicht sicher, warum Skype als systemeigener Prozess angezeigt wird.
— David Spillett
Leider ist es kein Skype; noch andere VoIP-Clients (keine installiert) noch P2P usw. usw. Ich habe das überprüft und es ist nicht nur "ein systemeigener Prozess", es ist "der Systemprozess" (PID 4)
— Cornelius
Seltsamerweise hatte ich das gleiche Problem, als das OP-443 von svchost übernommen wurde .. und dennoch wurde es durch das Ausschalten von Skype behoben.
— Blorgbeard
Hatte dieses Problem. Befolgen
— Samstag
Nur aus Gründen der Klarheit: Wenn Ihr Port von svchost gehalten und in Process Explorer deutlich sichtbar ist, war es nicht dasselbe Problem, das ich hatte. Daher bestand ich darauf, klar zu machen, dass der Prozess mit dem Namen "System" den Hafen zu besitzen schien.
— Cornelius
12

Ich hatte das Problem, dass Port 443 von "System" mit PID 4 auf meinem Windows 7-Computer verwendet wurde. Die Lösung für mich war, eine "Incoming Connection" (VPN) zu löschen, die im Netzwerkverbindungsordner vorhanden war.

Es scheint, dass ich es erstellt und vergessen habe, es nach der Verwendung zu löschen ...

— Macher
quelle
1
Ja, hatte das gleiche Problem auf Windows 8.1.
— Konstantin Pereiaslov
habe gerade das win7. Es hat aufgehört, TCP 443 abzuhören, obwohl es immer noch UDP-Port 443 abhört, obwohl das gut genug sein kann.
— Barlop
1
Ich hatte dieses Problem unter Windows Server 2008 R2 x64. Ich habe eine Weile gebraucht, um Ihren Beitrag zu finden, und ich bin überrascht über die offizielle Antwort auf diese Frage, da sie die Frage überhaupt nicht beantwortet. Danke!
— Simontemplar
Anstatt die "Eingehende Verbindung" zu löschen (ich kann mich nicht erinnern, wie ich sie erneut erstellen soll, wenn ich sie erneut benötige), deaktivierte ich das Kontrollkästchen [_] Allow other computers to connect to this oneunter "Netzwerk- und Freigabecenter", "Adapterkonfiguration", "Eingehende Verbindung", "Eigenschaften".
— Alexander Gelbukh
11

Zunächst werde ich diese Frage direkt beantworten, und jeder, der dies liest, kann alle Antworten ignorieren, die sich auf Anwendungen von Drittanbietern beziehen, die nicht von Microsoft stammen und den Systemprozess verwenden.

  1. Der Systemprozess wird auf jedem modernen Windows-System als PID 4 aufgeführt . Es ist für den Zugriff im Kernel-Modus vorgesehen. Dies schließt die meisten Webprodukte von Drittanbietern wie Apache aus.

  2. Seit der Einführung von WinRM (Windows Remote Management) ist der HTTP- Dienst ( % SystemRoot% \ system32 \ drivers \ http.sys ) ein Standardbestandteil von Windows (Vista und höher / Server 2008 und höher). http.sys wird unter dem Systemprozess ( PID 4 ) ausgeführt.

  3. Andere von Microsoft entwickelte Software verwendet möglicherweise auch% SystemRoot% \ system32 \ drivers \ http.sys im Rahmen des Systemprozesses, z. B. IIS , SQL Reporting Services und Microsoft Web Deployment Service ( http://support.microsoft.com/kb/2597817) ) ...

  4. Die Standardports von WinRM 1.0 lauteten:
    HTTP = 80
    HTTPS = 443
    Die Standardports von WinRM 2.0 und höher sind:
    HTTP = 5985
    HTTPS = 5986
    Überprüfen Sie mit den folgenden Befehlen:
    WinRM listet winRM / config / listener auf
    WinRM ruft http://schemas.microsoft.com auf / wbem / wsman / 1 / config

Schritte zur Fehlerbehebung:

Rufen Sie die Prozessnummer des Ports ab, nach dem Sie suchen (in diesem Fall 443):

... von einem nicht zugeordneten Laufwerk von Windows, um "Zugriff verweigert" zu vermeiden:
netstat -aon | find ": 443" Die
Ausgabe sollte für den Systemprozess folgendermaßen aussehen :
C:> netstat -ano | find ": 443"
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4
TCP [::]: 443 [: :]: 0 LISTENING 4
Die letzte Spalte ist die PID (4).

  1. Das Ausführen der Jobliste , um herauszufinden, was in dem Prozess ausgeführt wird, erweist sich als nicht hilfreich:
    Jobliste / SVC / FI "PID Gl. 4"
    Jobliste / m / FI "PID Gl. 4"

  2. Suchen Sie in der Registrierung nach dem HTTP-Dienst: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ HTTP \ Parameters \ UrlAclInfo
    Es wird eine Liste von URLs (mit den Portnummern) angezeigt, die Sie dazu führen können, welche Anwendung ausgeführt wird und welche Ports enthält:
    http : // +: 5985 / wsman / -> WinRM
    https: // +: 5986 / wsman / -> WinRM
    http: // +: 80 / Reports / -> SQL Reporting Server
    http: // +: 80 / ReportServer / -> SQL Reporting Server
    https: // server_fqdn: 443 / Reports / -> SQL Reporting Server
    https: // server_fqdn: 443 / ReportsServer / -> SQL Reporting Server
    http: // *: 2869 / - -> SSDPSRV (Simple Service Discovery Protocol)
    http: // *: 5357 / ->Dynamische Webservices-Ermittlung (WS-Ermittlung)
    https: // *: 5358 / -> Dynamische Webservices-Ermittlung (WS-Ermittlung)

Sie können dann den entsprechenden Dienst auf dem System suchen und stoppen und sehen, dass der gewünschte Port freigegeben ist, indem Sie mit einem anderen netstat -aon | bestätigen Befehl ": 443" suchen .

— Kenia Graham
quelle
Wie lässt sich in Bezug auf Punkt 6 feststellen, dass der Prozess auf diese Ports wartet?
— Galmok
8

Häufig handelt es sich hierbei um den VMware-Host-Agent-Service (erforderlich für die Kommunikation zwischen VM-Host und Gast) vmware-hostd.exe.

Eine gute Möglichkeit, um herauszufinden, welcher Unterprozess svchost.exe ausgeführt wird, ist die Verwendung von Sysinternals Process Explorer .

— Tony
quelle
2
Wenn Sie tatsächlich VMware Workstation installiert haben, überprüfen Sie unter Bearbeiten -> Einstellungen -> Freigegebene VMs. Wahrscheinlich ist die VM-Freigabe aktiviert und der Standardport ist 443. Sie können die Freigabe deaktivieren, den Port ändern und wieder aktivieren oder sie einfach deaktiviert lassen, wenn Sie sie nicht benötigen.
— Gronostaj
@gronostaj Vielen Dank, ich verbringe nur 3 Stunden damit, dies zu finden :(
— Simon Kirsten
7

Ich hatte ähnliche Probleme beim Weiterleiten von 443-Anfragen an meinen WAS-Server. Aufgrund der Empfehlungen in dieser Frage habe ich Folgendes getan:

  1. Von erhöhter cmd-Eingabeaufforderung lief netstat -a -n -o | findstr 443
  2. Identifizierte die PID des Prozesses, der auf 443 lauscht
  3. Verwendung des Prozess-Explorers zur Identifizierung des Prozesses anhand der PID.
  4. In meinem Fall war die Anwendung zuhören vmwarehostd.exe
  5. Stoppen Sie den VMware Workstation-Server von services.msc. Vom WAS-Server neu gestartet.

Und alle 443 Anfragen gingen glücklich zu 443 über die Zeit danach.

PS: Ich hatte bereits Skype deinstalliert, das mit meiner Windows 8-Installation eingebaut wurde. Der Routing- und RAS-Dienst wurde auf meinem Computer deaktiviert.

— Praveen
quelle
3
-1 Sein war PID 4, es war viel schwieriger. Sie schreiben "Verwendeter Prozess-Explorer, um den Prozess anhand der PID zu identifizieren." <- Ihre war nicht PID 4, zB svchost oder so. Ihre war eine 3rd Party Exe. Sie hätten einfach den Task-Manager verwenden können! Wenn Sie die Spalte nicht bereits anzeigen, dann view..choose column Aber Sie hatten Glück, dass Ihre PID nicht PID 4 war. Ich weiß nicht, ob der Prozess-Explorer dort helfen kann, obwohl der Task-Manager dies nicht kann. Aber in Ihrem Fall hätte es sicherlich ein einfacher Task-Manager getan.
— Barlop
5

Wenn es sich um einen Prozess handelt, der von einem Dienst gestartet wurde, netstat -abhilft dies nicht.

In diesem Fall versuchen Sie es netstat -ao | find /i "443"in einer Administrator-Befehlszeile. Dies gibt Ihnen eine Ausgabe wie diese:

    TCP   0.0.0.0:443   your_hostname:0   LISTENING   PID

Geben Sie dann eine tasklist | find /i "<PID>"andere Administrator-Eingabeaufforderung ein.

In meinem Fall war die PID 2912 und mein Befehl war: 

tasklist | find /i "2912"

Die Ausgabe meines Befehls war:

vmware-hostd.exe   2912 Services   0   39 856 K

Wow, ich habe sogar vergessen, dass ich VMware installiert habe, um die Funktionalität zu überprüfen ...

— elbedoit
quelle
1
Für mich war das PID 4 ... System. Immer noch keine Ahnung :)
— Wouter
PID 4 steht normalerweise für einen nativen Microsoft-basierten Windows-Dienst, dh für die Kernel-Ebene. Beenden Sie die Dienste nacheinander, und überprüfen Sie, ob das Problem behoben wurde. Deaktivieren Sie den Dienst / deinstallieren Sie die Funktion, die das Problem bei @Wouter verursacht hat. Übliche Dienstleistungen: Routing and RAS, alles unter Hinweis darauf , IISoder World Wide Puplishing, Exchange Windows Sync Share, Web Deployment Agent Service, SQL Server Reporting Services, File Server Storage Reports Managerund ähnliches.
— Elbedoit
1

In meinem Fall war es DataManager von F5 Networks, der Tomcat 6 intern für die Bereitstellung seiner Webseiten verwendet. Ich habe vergessen, diese App zu deinstallieren. Schlechte Designentscheidung, wenn Sie mich fragen.

— Roman Zenka
quelle
1

Mit netstat -ao | find ":443"fand ich heraus, dass Port 443 von PID 4, dem Systemprozess, verwendet wird. Dies ist mir unter Windows Server 2012 zweimal passiert, und zwar aus einem der folgenden Gründe:

  1. IIS wurde ausgeführt und unter "Dienste" als "WWW-Publishing-Dienst" aufgeführt, den ich gestoppt habe.
  2. Die Arbeitsordner-Funktion wurde installiert, daher habe ich sie deinstalliert.

Dies ist möglicherweise nicht für alle eine Lösung, kann aber einigen helfen.

— Anishpatel
quelle
Diese Antwort fügt nicht wirklich neue Informationen hinzu, die nicht bereits in den Antworten enthalten waren, die von elbedoit oder tonyr
— Ramhound,
1
Ich habe diese Antwort speziell hinzugefügt, da die Deinstallation der Funktion "Arbeitsordner" für mich funktioniert hat und daher eine potenzielle Lösung für das Problem darstellt, wie es geschrieben wurde. Sollte ich diese Informationen stattdessen in einem Kommentar präsentieren?
— Anishpatel
1
Ich hatte das gleiche Problem wie in der Frage angegeben, und die Antwort von Tonyr hat bei mir nicht funktioniert. Die Antwort von elbedoit hilft nicht, wenn Sie PID 4 haben (wie in der Frage angegeben). Werden Sie zufällig Systemprozesse stoppen / neu starten, um das Problem zu beheben?
— Anishpatel
1
In keiner anderen Antwort wird die Deinstallation der Funktion "Arbeitsordner" erwähnt, die eine Lösung für die Frage darstellt. Ich habe die Informationen aus den anderen Antworten wiederholt, um anderen mit demselben Problem zu helfen, festzustellen, ob diese Lösung für sie funktioniert (dh um sicherzustellen, dass die PID 4 ist). Wenn die PID nicht 4 ist, wird diese Antwort definitiv nicht helfen. Wie ist diese Antwort unvollständiger als die Antworten von Doener oder Tonyr? Bitte schlagen Sie vor, wie ich meine Lösung besser kommunizieren kann.
— Anishpatel
1
Ja! Es war für mich auch die Funktion "Arbeitsordner"! Vielen Dank für die Erwähnung. Es ist in der Tat eine ebenso gültige Antwort als Erwähnung von Skype oder einem anderen Dienst ...
— Wouter
1

In meinem Fall war es der DTC-Prozess (Distributed Transaction Coordinator), um den 443-Port zu verwenden. Insbesondere habe ich WS-AT in DTC aktiviert und es verwendete den 443-Port.

Im Allgemeinen verstehe ich, dass wenn der Systemprozess (PID 4) den 443 / HTTPS-Port verwendet, es ein interner Prozess von Windows ist (in meinem Fall DTC, aber ich denke, es kann auch ein anderer Prozess sein), wenn es keine IIS-Website ist es benutzen.

— Gurca
quelle
0

Für mich konnte Apache 443 nach dem Windows Server 2016-Update nicht mit dem angegebenen normalen Ereignis gestartet werden.

Ich habe festgestellt, dass der Schuldige der "Windows Sync Share" -Dienst (SyncShareSvc) ist. Ich habe Apache deaktiviert und konnte es starten.

— JEC
quelle
0

Ich habe festgestellt, dass bei Verwendung der VPN-Funktionalität in Windows 8 (wahrscheinlich dasselbe für Windows 7) Port 443 verwendet wurde.

Außerdem hat mein Port durch PMB.exe (Pando Media Booster) wieder geschlossen.

— user1788951
quelle
-1

Wireshark wird Ihnen die Details mitteilen. http://www.wireshark.org/ Oder TCP Monitor: http://www.itsamples.com/tcp-monitor.html

Das wird helfen

— adeelx
quelle
tcp-monitor konnte mir leider nicht wirklich weiterhelfen; Was Wireshark betrifft, konnte ich keine Pakete für Port 443 generieren / erfassen. :(
— Cornelius
1
Die einzige verbleibende Option ist der Prozess-Explorer (sysinternals), mit dem Sie Prozesse mit Ports anzeigen können. Wireshark ist eines der Top-Produkte in dieser Reihe, aber ich kann nicht verstehen, warum es bei Ihnen nicht funktioniert hat: s (Haben Sie den WinPCAP-Capture-Treiber installiert?)
— adeelx
Sehr späte Antwort, sorry. Aber ich konnte nichts zum Aufzeichnen bringen, weil anscheinend einfach kein Verkehr zu riechen war. Zumindest nehme ich das an.
— Cornelius
-1 Wireshark zeigt Ihnen nichts an, was helfen könnte, zu identifizieren, was sich auf dem Port befindet. Es sei denn, es gehen Pakete auf den Port. Und selbst dann sollten Sie weitere Informationen bereitstellen, z was diese IP ist.
— Barlop
-1

Wenn Sie über einen virtuellen LAN-Treiber (wie OpenVM, VMware usw.) verfügen, müssen Sie den Port freigeben, bevor Sie ihn an eine andere Stelle weitergeben.

Nur ein kurzer Hinweis;)

— Ruslan Abuzant
quelle
-2

Ich hatte das gleiche Problem beim Versuch, ein VMware-Update zu installieren. Ich habe es auf Skype ausfindig gemacht. Der neue Client ist standardmäßig 443.

— Cal
quelle
4
Dies ist nur eine Wiederholung einer bestehenden Antwort. Bitte stimmen Sie vorhandenen Antworten zu, anstatt sie erneut zu posten.
— Chenmunka
@Chenmunka Vielleicht hat er es nicht gelesen
— FindOutIslamNow
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.