Processo desconhecido conhecido na porta 8080

O problema: algo está escutando na porta 8080

• Se eu carregar a página com o Safari, recebo uma página em branco (a página é branca, mas "Revelar → Mostrar fonte da página" fica acinzentado)

• Se eu telnetar para a porta 8080, recebo algo respondendo

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

Mas

• lsof não mostra nenhum processo escutando na porta 8080

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

• netstat não mostra nenhum processo usando a porta 8080

  $ netstat -n  | grep 8080
  $
  

• Posso abrir a porta 8080 programaticamente (por exemplo, com um servidor web) sem nenhum erro sobre a porta estar em uso

• nmap não lista a porta conforme usada

  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
  

O mesmo acontece para a porta 80, mas não para outras portas (por exemplo, 81 ou 8081).

Pergunta Qual processo está respondendo a essas portas quando nenhum outro processo as está abrindo? Qual é o objetivo desse comportamento?

Editar

• se eu abrir a porta com um programa, a porta poderá ser usada normalmente. Depois que a porta é fechada, o comportamento estranho reaparece. Exemplo:

  • acesso à porta 8080 entregar uma conexão com um processo desconhecido
  • Eu abro a porta com tomcat
  • acessos à porta 8080 vai para o tomcat e está tudo bem
  • Fecho a porta (saia do tomcat)
  • a porta está listada como não usada (veja acima)
  • acesso à porta 8080 entregar uma conexão com um processo desconhecido

• as regras do firewall apenas mostram que a porta não está bloqueada

  $ 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

• o programa de escuta não é um servidor HTTP (ou seja, não reage a uma GET index.html HTTP/1.0solicitação

Percebi esse mesmo problema no meu Macbook. Eu estava tentando usar a porta 8080 para alguns testes e recebi o erro de que outro processo já estava escutando. Minha chamada de nmapretornou resultados diferentes, dependendo de eu estar usando sudoou não. Isso não fazia sentido para mim.

Fiquei realmente preocupado quando não consegui descobrir o que os processos estavam ouvindo nessas portas usando sudo lsof -P -n -iTCP | grep LIST. Isso me levou a acreditar que havia um software malicioso intencionalmente se escondendo.

Acabei removendo os arquivos /Library/LaunchDaemons/até reduzi-lo ao culpado. O aplicativo responsável por todas essas portas abertas foi o Cisco AnyConnect Secure Mobile Client. Infelizmente, para que este cliente VPN da Cisco funcione, ele deve ter todas essas portas abertas. Aparentemente, também é responsável pela adição de regras de firewall com a qual você reportou ipfw show.

Ainda me surpreende por que não mostra qual processo é responsável pelas portas abertas ao usar lsof. Nenhum aplicativo deve conseguir evitar ser listado usando esse método. Talvez o motivo do processo não esteja listado seja respondido em outra pergunta de troca de pilha.

Encontrei este problema esta manhã, reclamei no Twitter e me disseram que o problema foi corrigido nas versões recentes do Any Connect . Atualizei para a nova versão e não tenho mais um processo misterioso vinculado à porta 8080. Até agora, tudo bem.

No meu caso, eu tenho isso de lsof.

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

Então, depois de cavar o LaunchDaemon, encontrei esses arquivos e os excluí.

com.GeneralSearchSignDaemon.plist
com.GeneralSearchSignP.plist

Em seguida, o porto fica livre.

Eu acho que esse processo está conectado ao Yarn, mas não foi resolvido automaticamente, mesmo que eu o tenha removido.