Proceso desconocido escuchando en el puerto 8080

El problema: algo está escuchando en el puerto 8080

• Si cargo la página con Safari, aparece una página en blanco (la página es blanca pero "Desarrollar → Mostrar fuente de la página" está atenuada)

• Si hago telnet al puerto 8080 obtengo algo respondiendo

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

Pero

• lsof no muestra ningún proceso escuchando en el puerto 8080

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

• netstat no muestra ningún proceso utilizando el puerto 8080

  $ netstat -n  | grep 8080
  $
  

• Puedo abrir el puerto 8080 mediante programación (p. Ej., Con un servidor web) sin ningún error sobre el puerto en uso

• nmap no enumera el puerto como usado

  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
  

Lo mismo sucede para el puerto 80 pero no para otros puertos (por ejemplo, 81 u 8081).

Pregunta ¿Qué proceso responde a estos puertos cuando ningún otro proceso los abre? ¿Cuál es el propósito de este comportamiento?

Editar

• Si abro el puerto con un programa, el puerto se puede usar normalmente. Una vez que se cierra el puerto, reaparece el extraño comportamiento. Ejemplo:

  • el acceso al puerto 8080 proporciona una conexión a un proceso desconocido
  • Abro el puerto con tomcat
  • los accesos al puerto 8080 van a tomcat y todo está bien
  • Cierro el puerto (salgo de tomcat)
  • el puerto aparece como no utilizado (ver arriba)
  • el acceso al puerto 8080 proporciona una conexión a un proceso desconocido

• las reglas del cortafuegos solo muestran que el puerto no está bloqueado

  $ 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
  

Editar 2

• el programa de escucha no es un servidor HTTP (es decir, no reacciona a una GET index.html HTTP/1.0solicitud

Noté este mismo problema en mi Macbook. Intenté usar el puerto 8080 para algunas pruebas y recibí el error de que otro proceso ya lo estaba escuchando. Mi invocación de nmapdevolvió resultados diferentes dependiendo de si estaba usando sudoo no. Esto no tenía sentido para mí.

Estaba realmente preocupado cuando no podía entender qué procesos estaban escuchando en estos puertos sudo lsof -P -n -iTCP | grep LIST. Esto me llevó a creer que había un software malicioso que se ocultaba intencionalmente.

Terminé eliminando archivos /Library/LaunchDaemons/hasta que lo reduje al culpable. La aplicación responsable de todos estos puertos abiertos fue Cisco AnyConnect Secure Mobile Client. Desafortunadamente, para que este cliente Cisco VPN funcione, debe tener todos estos puertos abiertos. Aparentemente, también es responsable de la adición de la regla de firewall con la que informó ipfw show.

Todavía me sorprende por qué no muestra qué proceso es responsable de los puertos abiertos cuando se usa lsof. Ninguna aplicación debería poder evitar ser incluida en la lista utilizando este método. Quizás la razón por la cual el proceso no figura en la lista se responderá en otra pregunta de stackexchange.

Me encontré con este problema esta mañana, me quejé en Twitter y me dijeron que el problema se ha solucionado en versiones recientes de Any Connect . Actualicé a la nueva versión, y ya no tengo un proceso misterioso vinculante al puerto 8080. Tan bueno hasta ahora.

En mi caso, tengo esto de lsof.

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

Entonces, después de profundizar en LaunchDaemon, encontré estos archivos y los eliminé.

com.GeneralSearchSignDaemon.plist
com.GeneralSearchSignP.plist

Entonces el puerto se vuelve libre.

Creo que este proceso está conectado con Yarn pero no se resolvió automáticamente, incluso si eliminé Yarn.