Neden 'Sistem' işlemi 443 numaralı bağlantı noktasını dinliyor?

45

Apache sunucumu başlatırken sorun yaşıyorum, çünkü 443 numaralı bağlantı noktası zaten kullanılıyor.

Görünüşe göre sistem süreci (PID 4) 443 numaralı bağlantı noktasını kullanıyor. IIS yüklü değil, services.msc (tahmin edilebileceği gibi) çalışan hiçbir Exchange sunucusu veya WWW-Servisleri veya IIS olmadığını gösteriyor. Hangi hizmetin bu bağlantı noktasını kullandığını nasıl bulacağımı bilmiyorum, her bir hizmeti birbiri ardına devre dışı bırakmak yerine, ve bunun yardımcı olacağından bile emin değilim.

Biri bana SSL portumu nasıl geri alabileceğimi gösterebilirse, minnettar olurum, teşekkürler :)

Not: Tabii ki "sadece Apache'yi SSL için başka bir porta değiştir", Apache'nin başlatılamaması sorununu çözecektir. Ama hala 443 numaralı hogging limanında neyin bu kadar ısrarcı olduğunu bilmek istiyorum. :)

Şimdiye kadar birbiri ardına 'zor yol' ve engelli servislerine gittim. "Yönlendirme ve RAS" hizmetinin suçlu olduğu ortaya çıktı.

Değerli girdi ve "WTF sistemim şimdi yapıyor mu?" İle mücadelede yeni araçlar için hepinize teşekkür ederim.

windows 
— Cornelius
kaynak
İlgili: superuser.com/questions/121901 Sen açılış portu 443'tür hangi hizmetin belirlemeye yardımcı olmak için verilen cevapların hiçbirinde kullanabilirsiniz
— heavyd
1
Ne yazık ki, hangi hizmetin bağlantı noktasını tam olarak açık tuttuğunu bulamadığım için (ya da çok aptalca), bir hizmet adı için "SC Config Servicename Type = own" kullanamıyorum. Netstat'ın çeşitli teşvikleri, tıpkı TCPView gibi, Sistem sürecinde beni işaret ediyor. PE'de olduğu gibi "Yığınlar", Win7'de görünüşte çalışmıyor ve svchost.exe örneğine bakmadığım için, TCP / IP sekmesinde "Hizmet" sütunum yok. Skype hatalı değil, çalışan başka bir VoIP veya P2P yazılımım da yok. Ama bağladığın diğer soru beni aydınlatıyordu; teşekkür ederim.
— Cornelius
Bilgi için teşekkürler! Benim için 443 numaralı bağlantı noktasını da bağlayan "Yönlendirme ve Uzaktan Erişim" hizmetiydi.
— Kodlayıcı,
3
Dostum, soruyu cevaplamaya çalışmayan cevapların miktarı bile inanılmaz. Yanlış bilgi miktarı da öyle. PID 4 dinliyorsa, öyle http.sys. Her zaman. Neyse ki, zaten içgörü kazanmanın bir cevabı var .
— Daniel B,

Yanıtlar:

18

Aşağıdakileri yükseltilmiş bir komut isteminden çalıştırın:

netstat -ab
— Tony Roth
kaynak
Biraz şaşırdım. Başka bir şey sadece "sistem süreci" suçlu gösterdi. Bu komut şimdi bu bağlantı noktasını tutan bir svchost.exe olduğunu iddia ediyor. : | PE / 'other' netstat çağrıları Sistem süreci altında nasıl bir araya getirildi? (Her ne kadar bağlantı noktası hala PID 4 / Sistem tarafından gösterildiği gibi gösteriliyor olsa da) :(
— Cornelius
emin değilim ama koşmak PE yükselmiş olabilir!
— tonyr, 29.03.2010
2
ayrıca aşağıdakiler size daha fazla fikir verebilir wmic süreci> test.txt
— tonyr roth 29:10
1
İşlem gezginini yönetici olarak çalıştırdım - ve port hala "Sistem" tarafından iddia edildiği gibi görünüyor; orada gerçekten çok daha fazla intel mevcut değil: | Şimdi istemeyerek yaptığım aptalca bir şey olacağını düşünüyorum;)
— Cornelius
4
Bu benim için çalışmıyor, 0.0.0.0:443 ile aynı çizgide . Mülkiyet bilgisi alamıyorum .
— MGOwen
33

Eminim Skype'dır. Taktıysanız, aşağıda gösterilen onay kutusundaki işareti kaldırın.

Alt metin

— Nifle
kaynak
3
+1. Diğer VoIP istemcileri (ve P2P dosya aktarma uygulamaları gibi diğer yazılımlar), Skype en yaygın "suçlu" olmasına rağmen, orada başka bir şey bulamazlarsa, 80 ve 443 numaralı portlarda dinleyecektir. Skype'ın neden bir süreç sahibi sistem olarak ortaya çıkacağını bilmiyorum.
— David Spillett
Ne yazık ki skype değil; ne de diğer VoIP müşterileri (yüklü değil) ne de P2P vb. kontrol ettim ve sadece "bir sisteme ait işlem" değil, "sistem süreci" (PID 4)
— Cornelius
İşin garibi, OP - 443 svchost tarafından alınmış gibi aynı sorunu yaşadım .. ve yine de Skype'ı kapattı.
— Blorgbeard 15
Bu problem vardı. Bu talimatlara uydu ve Skype olduğunu anladım: mydigitallife.info/…
— Cumartesi
Sadece açıklık uğruna: Bağlantı noktanız svchost tarafından tutulursa ve İşlem Gezgini'nde açıkça görülebiliyorsa, aynı sorun değildi. Bu nedenle, "Sistem" adındaki işlemin limana sahip olduğu görülüyor.
— Cornelius
12

Windows 7 makinemde 443 numaralı bağlantı noktasını "sistem" tarafından PID 4 ile kullanıyorum. Benim için çözüm, ağ bağlantıları klasöründe bulunan bir “Gelen Bağlantı” (VPN) silmek oldu.

Görünüşe göre yarattım ve kullandıktan sonra silmeyi unuttum ...

— hamburgbogans
kaynak
1
Evet, Windows 8.1'de de aynı sorunu vardı.
— Konstantin Pereiaslov
Sadece bunu kazandım7. TCP 443'ü dinlemeyi bıraktı, ancak 443 numaralı UDP bağlantı noktasını dinliyor olsa da yeterince iyi olabilir.
— barlop
1
Bu sorunu Windows Server 2008 R2 x64'te yaşadım. Görevinizi bulmam biraz zaman aldı ve bu sorunun resmindeki cevabına şaşırdım, çünkü bu aslında soruyu yanıtlamıyor. Teşekkür ederim!
— simontemplar
"Gelen Bağlantı" yı silmek yerine (tekrar ihtiyacım olursa tekrar nasıl yaratacağımı hatırlamıyorum) [_] Allow other computers to connect to this oneAğ ve Paylaşım Merkezi, Bağdaştırıcı Yapılandırması, Gelen Bağlantı, Özellikler altında işaretini kaldırdım .
— Alexander Gelbukh
11

Öncelikle, bu soruyu doğrudan cevaplayacağım ve bunu okuyan herkes, Sistem İşlemini kullanan Microsoft'a ait olmayan, üçüncü taraf uygulamalar hakkında konuşan yanıtları görmezden gelebilir.

  1. Sistem işlemi olarak listelenir PID 4 her günümüz Windows sisteminde. Çekirdek modu erişimi içindir. Bu, Apache gibi birçok 3. parti web ürününü hariç tutar.

  2. WinRM'nin (Windows Uzaktan Yönetimi) kuruluşundan bu yana, HTTP hizmeti ( % SystemRoot% \ system32 \ drivers \ http.sys ) Windows'un standart bir parçası olmuştur (Vista ve üstü / Server 2008 ve sonrası). http.sys, Sistem işlemi altında çalışır ( PID 4 ).

  3. Diğer Microsoft tarafından geliştirilen yazılımlar, IIS , SQL Raporlama Servisleri ve Microsoft Web Dağıtım Hizmeti ( http://support.microsoft.com/kb/2597817) gibi Sistem işlemlerinde % SystemRoot% \ system32 \ drivers \ http.sys dosyasını da kullanabilir ) ...

  4. WinRM 1.0 varsayılan bağlantı noktaları:
    HTTP = 80
    HTTPS = 443
    WinRM 2.0 ve daha büyük varsayılan bağlantı noktaları:
    HTTP = 5985
    HTTPS = 5986
    Aşağıdaki komutları kontrol edin:
    Winrm enumerate winrm / config / listener
    Winrm http://schemas.microsoft.com / wbem / WSMan / 1 / yapılandırma

Sorun giderme adımları:

Aradığınız portun işlem numarasını alın (bu durumda 443):

... "Erişim Engellendi" yi engellemek için eşlenmemiş bir Windows sürücüsünden:
netstat -aon | find ": 443"
Çıktı Sistem işlemi için aşağıdaki gibi görünmelidir :
C:> netstat -ano | find ": 443"
TCP 0.0.0.0:443 0.0.0.0:04 LISTENING 4
TCP [::]: 443 [: :]: 0 DİNLEME 4
Son sütun PID'dir (4).

  1. Koşu tasklist işlemde çalışan ne olduğunu bulmak için yardımcı kanıtlıyor:
    tasklist / SVC / FI "PID 4 eq"
    tasklist / m / FI "PID 4 eq"

  2. HTTP hizmeti için kayıt defterine bakın: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ HTTP \ Parameters \ UrlAclInfo
    Hangi uygulamanın çalıştığını ve hangi bağlantı noktalarını tuttuğunuzu size yönlendiren bir URL listesi (bağlantı noktası numaralarıyla birlikte):
    http : // +: 5985 / wsman / -> WinRM
    https: // +: 5986 / wsman / -> WinRM
    http: // +: 80 / Raporlar - -> SQL Raporlama Sunucusu
    http: // +: 80 / ReportServer / -> SQL Raporlama Sunucusu
    https: // server_fqdn: 443 / Raporlar / -> SQL Raporlama Sunucusu
    https: // server_fqdn: 443 / RaporlarSonver / -> SQL Raporlama Sunucusu
    http: // *: 2869 / - -> Basit Servis Bulma Protokolü servisi (SSDPSRV)
    http: // *: 5357 / ->Web Servisleri Dinamik Bulma (WS-Keşif)
    https: // *: 5358 / -> Web Servisleri Dinamik Bulma (WS-Keşif)

İlgili servisi sistemde bulabilir ve durdurabilir ve başka bir netstat ile onaylayarak istenen portun serbest bırakıldığını görebilirsiniz. ": 443" komutunu bulun .

— Kenya Graham
kaynak
6. noktaya gelince, bu limanları dinleyen süreci nasıl bulabiliriz?
— galmok
8

Genellikle bu, VMware ana bilgisayar aracı hizmetidir (VM-ana bilgisayardan misafir iletişimi için gereklidir) - vmware-hostd.exe.

Svchost.exe dosyasının hangi alt işlemin çalıştığını bulmanın iyi bir yolu Sysinternals ' İşlem Gezgini'ni kullanmaktır .

— Tony
kaynak
2
Gerçekten de VMware Workstation kurulu ise, Düzenle -> Tercihler -> Paylaşılan VM'leri kontrol edin. Muhtemelen VM paylaşımını etkinleştirmiş ve varsayılan port 443'tür. Paylaşımı devre dışı bırakabilir, portu değiştirebilir ve geri etkinleştirebilir veya ihtiyacınız yoksa devre dışı bırakabilirsiniz.
— gronostaj
@gronostaj Çok teşekkür ederim sadece bunu bulmaya çalışarak 3 saat geçiriyorum :(
— Simon Kirsten
7

WAS sunucuma 443 istek yönlendirirken de benzer sorunlarla karşılaştım. Bu sorudaki önerilere dayanarak yaptığım şey buydu:

  1. Yükseltilmiş cmd istemi koştu netstat -a -n -o | findstr 443
  2. 443’de dinleyen sürecin PID’ini
  3. İşlemi PID'den tanımlamak için İşlem Gezgini'ni kullanın.
  4. Benim durumumda uygulama dinleme oldu vmwarehostd.exe
  5. VMware Workstation sunucusunu durdurdu services.msc. WAS sunucusu tarafından yeniden başlatıldı.

Ve tüm 443 talepleri sonsuza dek mutlu bir şekilde 443'e geldi.

Not: Windows 8 kurulumumda yerleşik olan skype'ı zaten kaldırmıştım. Makinemde yönlendirme ve uzaktan erişim hizmeti devre dışı bırakıldı.

— praveen
kaynak
3
-1 Onun PID 4'ü çok daha zordu. "Pid'den işlemi tanımlamak için kullanılmış işlem gezgini" yazıyorsunuz. Sizinki PID 4 değildi, örneğin svchost ya da onun gibi bir şey. Seninki bir üçüncü parti exe idi. Görev yöneticisini daha yeni kullanabilirdin! Eğer zaten sütunu göstermiyorsanız o zaman görüntüle ... sütunu seçin Ancak şanslıydınız, PID'iniz PID 4 değildi. Ama kesinlikle senin durumunda basit görev yöneticisi bunu yapardı.
— barlop
5

Bir servis tarafından başlatılan bir işlem ise, netstat -abyardımcı olmaz.

Bu durumda netstat -ao | find /i "443"bir yönetici komut satırında deneyin . Bu size şöyle bir çıktı verecektir:

    TCP   0.0.0.0:443   your_hostname:0   LISTENING   PID

Sonra tasklist | find /i "<PID>"başka bir yönetici komut istemi yazın.

Benim durumumda PID 2912 idi ve emrim: 

tasklist | find /i "2912"

Komutumun çıktısı şuydu:

vmware-hostd.exe   2912 Services   0   39 856 K

Vay, bir işlevselliği kontrol etmek için VMware'i kurduğumu bile unuttum ...

— elbedoit
kaynak
1
Benim için bu PID 4 ... Sistem olmaktı. Hala bir ipucu yok :)
— Wouter
PID 4, genellikle çekirdek seviyesi anlamına gelen yerel bir Microsoft tabanlı Windows hizmeti anlamına gelir. Hizmetleri tek tek durdurmayı deneyin ve sorunu çözüp çözmediğini kontrol edin. Hizmeti devre dışı bırakın / @Wouter'ın soruna neden olduğu özelliği kaldırın. Olağan hizmetler vardır: Routing and RASbir şey belirterek IISya World Wide Puplishing, Exchange Windows Sync Share, Web Deployment Agent Service, SQL Server Reporting Services, File Server Storage Reports Managerve benzeri.
— elbedoit
1

Benim durumumda, web sayfalarını sunmak için Tomcat 6'yı dahili olarak kullanan F5 Networks'ten DataManager idi. Bu uygulamayı kaldırmayı unuttum. Bana sorarsan kötü tasarım kararı.

— Roman Zenka
kaynak
1

Kullanarak netstat -ao | find ":443", 443 numaralı bağlantı noktasının Sistem işlemi olan PID 4 tarafından kullanıldığını öğrendim. Bu Windows Server 2012'de iki kez başıma geldi ve aşağıdaki nedenlerden biriydi:

  1. IIS, durdurduğum Hizmetler'de "World Wide Web Publishing Service" olarak listeleniyordu.
  2. Çalışma Klasörleri özelliği yüklü, ben de kaldırdım.

Bu herkes için bir çözüm olmayabilir, ancak bazılarına yardımcı olabilir.

— anishpatel
kaynak
Bu cevap, elbette, elbedoit ya da tonyr tarafından gönderilen cevaplarda bulunmayan hiçbir yeni bilgiyi içermiyor
— Ramhound
1
Bu cevabı özellikle ekledim, çünkü Çalışma Klasörleri özelliğini kaldırmak benim için çalıştı ve bu yüzden problemin yazıldığı gibi potansiyel bir çözüm. Bu bilgiyi bunun yerine yorumda mı sunmalıyım?
— anishpatel
1
Soruda belirtilenle aynı sorunu yaşadım ve Tony'nin cevabı benim için işe yaramadı. elbedoit'in cevabı PID 4 olduğunda sorun olmaz (soruda belirtildiği gibi); Sorunu çözmek için sistem işlemlerini rasgele durduracak / yeniden başlatacak mısınız?
— anishpatel
1
Başka hiçbir cevap, sorunun bir çözümü olmayan Çalışma Klasörleri özelliğini kaldırır. Aynı sorunun başkalarına, bu çözümün kendileri için işe yarayıp yaramayacağını belirlemelerine yardımcı olmak için diğer cevaplardaki bilgileri tekrarladım (yani, PID'nin 4 olduğundan emin olun). PID 4 değilse, bu cevap kesinlikle yardımcı olmayacaktır. Bu cevap nasıl daha eksik, daha sonra doener veya tonyr'ın cevapları? Lütfen çözümümü nasıl daha iyi iletebileceğimi önerin.
— anishpatel
1
Evet! Aynı zamanda benim için Çalışma Klasörleri özelliği oldu! Bunu söylediğiniz için teşekkür ederiz. Gerçekten de Skype'tan veya başka bir hizmetten bahsetmek gibi eşit bir geçerli cevap ...
— Wouter
1

Benim durumumda 443 portunun kullanılması DTC (Dağıtılmış İşlem Koordinatörü) işlemi idi. Özellikle, DTC'de WS-AT'yi etkinleştirdim ve 443 port kullanıyordu.

Genel olarak, Sistem işlemi (PID 4) 443 / HTTPS bağlantı noktasını kullandığında, bunun bir iç Web sitesi olduğunu (benim durumumda DTC, ancak sanırım başka bir işlem de olabilir), bir IIS web sitesi değilse, anlıyorum. onu kullanarak.

— gurca
kaynak
0

Benim için, Windows Server 2016 güncellemesinden sonra, Apache 443 listelenen normal olayla başlayamadı.

Suçluyu "Windows Eşitleme Paylaşımı" Hizmeti (SyncShareSvc) olarak buldum. Devre dışı bıraktım ve Apache'yi başlatabildim.

— KEK
kaynak
0

Windows 8'de VPN işlevini kullanmanın (muhtemelen Windows 7 için aynı) 443 numaralı bağlantı noktasını kullandığını buldum.

Ayrıca, portum yine PMB.exe (Pando Media Booster) tarafından kapatıldı.

— user1788951
kaynak
-1

Wireshark size detayları anlatacak. http://www.wireshark.org/ Veya TCP Monitor: http://www.itsamples.com/tcp-monitor.html

Bu yardımcı olacak.

— adeelx
kaynak
tcp-monitor ne yazık ki bana hiç yardımcı olamadı; wireshark'a gelince - 443 numaralı limana yönlendirilmiş paketler üretemedim / yakalayamadım. :(
— Cornelius
1
Kalan tek seçenek İşlem Portresidir (sysinternals), size portlarla ilerlediğinizi gösterir. Wireshark bu satırdaki en iyi ürünlerden biri, ancak neden sizin için işe yaramadığını anlayamıyorum: s (WinPCAP yakalama sürücüsünü yüklediniz mi?)
— adeelx
Çok geç cevap, özür dilerim. Ancak kayıt olacak hiçbir şey bulamadım çünkü görünüşe göre koklayacak bir trafik yoktu. En azından sanırım.
— Cornelius
-1 Wireshark size limanda ne olduğunu belirlemeye yardımcı olacak hiçbir şey göstermeyecek .. limana giden paketler olmadıkça Ve o zaman bile, örneğin kişinin IP'yi ping etmesi ve bulmaya çalışması için daha fazla bilgi vermelisiniz Bu IP nedir.
— barlop
-1

Bir tür Sanal LAN sürücünüz varsa (OpenVM, VMware vb. Gibi) - başka bir şey vermeden önce bağlantı noktasını 'serbest bıraktığınızdan' emin olun ...

Sadece hızlı bir ipucu;)

— Ruslan Abuzant
kaynak
-2

VMware güncellemesi yüklemeye çalışırken de aynı sorunu yaşadım. Onu Skype'a kadar izledim. Yeni istemci varsayılan olarak 443'tür.

— Cal
kaynak
4
Bu sadece varolan bir cevabın tekrarı. Lütfen tekrar göndermek yerine mevcut cevapları güçlendirin.
— Chenmunka
@Chenmunka Belki de okumamıştı
— FindOutIslamNow
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.