Nieznany proces nasłuchuje na porcie 8080

Problem: coś nasłuchuje na porcie 8080

• Jeśli załaduję stronę za pomocą Safari, otrzymam pustą stronę (strona jest biała, ale „Opracuj → Pokaż źródło strony” jest wyszarzone)

• Jeśli telnet do portu 8080 dostanie odpowiedź

  $ telnet 127.0.0.1 8080
  Trying 127.0.0.1...
  Connected to localhost (127.0.0.1).
  Escape character is '^]'.
  

Ale

• lsof nie pokazuje żadnego procesu nasłuchującego na porcie 8080

  $ sudo lsof -iTCP -sTCP:LISTEN -P -n | grep 8080
  $
  

• netstat nie pokazuje żadnego procesu korzystającego z portu 8080

  $ netstat -n  | grep 8080
  $
  

• Mogę otworzyć program 8080 programowo (np. Z serwerem WWW) bez żadnego błędu dotyczącego używania portu

• nmap nie wyświetla użytego portu

  sudo nmap 127.0.0.1
  
  Starting Nmap 6.01 ( http://nmap.org ) at 2012-10-03 16:16 CEST
  Nmap scan report for localhost (127.0.0.1)
  Host is up (0.000081s latency).
  Not shown: 990 closed ports
  PORT      STATE SERVICE
  22/tcp    open  ssh
  631/tcp   open  ipp
  1023/tcp  open  netvenuechat
  3283/tcp  open  netassistant
  3306/tcp  open  mysql
  3689/tcp  open  rendezvous
  5001/tcp  open  commplex-link
  5003/tcp  open  filemaker
  5432/tcp  open  postgresql
  50003/tcp open  unknown
  
  Nmap done: 1 IP address (1 host up) scanned in 10.92 seconds
  

To samo dzieje się w przypadku portu 80, ale nie dotyczy innych portów (np. 81 lub 8081).

Pytanie Który proces odpowiada na te porty, gdy żaden inny proces ich nie otwiera? Jaki jest cel tego zachowania?

Edytować

• jeśli otworzę port za pomocą programu, można go normalnie użyć. Po zamknięciu portu pojawia się ponownie dziwne zachowanie. Przykład:

  • dostęp do portu 8080 zapewnia połączenie z nieznanym procesem
  • Otwieram port za pomocą tomcat
  • dostęp do portu 8080 przechodzi do tomcat i wszystko jest w porządku
  • Zamykam port (zakończ tomcat)
  • port jest wymieniony jako nieużywany (patrz wyżej)
  • dostęp do portu 8080 zapewnia połączenie z nieznanym procesem

• reguły zapory pokazują, że port nie jest zablokowany

  $ sudo ipfw show
  00001    926004   100891783 allow ip from me to any dst-port 80,8080,3128,5001,5003,443
  65535 125057043 94341114828 allow ip from any to any
  

Edytuj 2

• program nasłuchujący nie jest serwerem HTTP (tzn. nie reaguje na GET index.html HTTP/1.0żądanie)

Zauważyłem ten bardzo problem na moim Macbooku. Próbowałem użyć portu 8080 do niektórych testów i otrzymałem błąd, że inny proces już na nim nasłuchuje. Moje wywołanie nmapzwróciło różne wyniki w zależności od tego, czy korzystałem, sudoczy nie. To nie miało dla mnie sensu.

Byłem naprawdę zaniepokojony, gdy nie mogłem dowiedzieć się, jakie procesy nasłuchują na tych portach sudo lsof -P -n -iTCP | grep LIST. Doprowadziło mnie to do przekonania, że ​​złośliwe oprogramowanie celowo ukrywało się.

Ostatecznie usunąłem pliki, /Library/LaunchDaemons/dopóki nie zawęziłem ich do winowajcy. Aplikacją odpowiedzialną za wszystkie te otwarte porty był Cisco AnyConnect Secure Mobile Client. Niestety, aby klient Cisco VPN mógł działać, musi mieć otwarte wszystkie te porty. Najwyraźniej jest również odpowiedzialny za dodanie reguły zapory, o której informowałeś ipfw show.

Nadal zastanawia mnie, dlaczego nie pokazuje, który proces jest odpowiedzialny za otwarte porty podczas używania lsof. Żadna aplikacja nie powinna być w stanie uniknąć umieszczenia na liście przy użyciu tej metody. Być może przyczyna nieuwzględnienia procesu zostanie wymieniona w innym pytaniu dotyczącym wymiany stosów.

Tego ranka natknąłem się na ten problem, narzekałem na Twitterze i powiedziano mi, że problem został rozwiązany w najnowszych wersjach Any Connect . Uaktualniłem do nowej wersji i nie mam już tajemniczego procesu powiązania z portem 8080. Jak dotąd dobrze.

W moim przypadku mam to od lsof.

GeneralSe 57613  root  8u  IPv6 0x2ffc9f7c6daebd5b  0t0  TCP *:8080 (LISTEN)

Więc po wejściu do LaunchDaemon znalazłem te pliki i usunąłem je.

com.GeneralSearchSignDaemon.plist
com.GeneralSearchSignP.plist

Następnie port staje się wolny.

Myślę, że ten proces jest związany z Przędzą, ale nie został rozwiązany automatycznie, nawet po usunięciu Przędzy.