Неизвестный процесс прослушивания на порту 8080

Проблема: что-то слушает на порту 8080

• Если я загружаю страницу с Safari, я получаю пустую страницу (страница белая, но «Разработка → Показать исходный код страницы» неактивна)

• Если я telnet к порту 8080 я получаю что-то отвечая

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

Но

• lsof не показывает процесс прослушивания через порт 8080

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

• netstat не показывает процесс, использующий порт 8080

  $ netstat -n  | grep 8080
  $
  

• Я могу открыть порт 8080 программным способом (например, с помощью веб-сервера) без каких-либо ошибок об использовании порта

• nmap не перечисляет порт как используемый

  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
  

То же самое происходит для порта 80, но не для других портов (например, 81 или 8081).

Вопрос Какой процесс отвечает на эти порты, когда никакой другой процесс не открывает их? Какова цель этого поведения?

редактировать

• если я открываю порт с помощью программы, то порт можно использовать как обычно. Как только порт закрыт, появляется странное поведение. Пример:

  • доступ к порту 8080 доставить соединение неизвестному процессу
  • Я открываю порт с котом
  • доступ к порту 8080 идет к Tomcat и все в порядке
  • Я закрываю порт (выход из кота)
  • порт указан как неиспользуемый (см. выше)
  • доступ к порту 8080 доставить соединение неизвестному процессу

• правила брандмауэра просто показывают, что порт не заблокирован

  $ 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
  

Редактировать 2

• прослушивающая программа не является HTTP-сервером (т.е. не реагирует на GET index.html HTTP/1.0запрос

Я заметил эту самую проблему на моем Macbook. Я пытался использовать порт 8080 для некоторого тестирования, и я получил ошибку, что другой процесс уже прослушивал его. Мой вызов nmapдал разные результаты в зависимости от того, использовал я sudoили нет. Это не имело смысла для меня.

Я был действительно обеспокоен, когда я не мог понять, какие процессы прослушивали эти порты sudo lsof -P -n -iTCP | grep LIST. Это заставило меня поверить, что вредоносное ПО преднамеренно скрывалось.

Я заканчивал тем, что удалял файлы, /Library/LaunchDaemons/пока не сузил их до виновника. Приложение, ответственное за все эти открытые порты, было Cisco AnyConnect Secure Mobile Client. К сожалению, для того, чтобы этот клиент Cisco VPN работал, он должен открыть все эти порты. Очевидно, он также отвечает за добавление правила брандмауэра, о котором вы сообщили ipfw show.

Это все еще поражает, почему не показывает, какой процесс отвечает за открытые порты при использовании lsof. Ни одно приложение не должно быть в состоянии избежать того, чтобы быть перечисленным, используя этот метод. Возможно, причина отсутствия процесса будет указана в другом вопросе об обмене стеками.

Я столкнулся с этой проблемой сегодня утром, пожаловался в Твиттере, и мне сказали, что проблема была исправлена ​​в последних версиях Any Connect . Я обновился до новой версии, и у меня больше нет тайного процесса привязки к порту 8080. Пока все хорошо.

В моем случае я получил это от lsof.

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

Поэтому после поиска в LaunchDaemon я нашел эти файлы и удалил их.

com.GeneralSearchSignDaemon.plist
com.GeneralSearchSignP.plist

Тогда порт становится свободным.

Я думаю, что этот процесс связан с пряжей, но он не был решен автоматически, даже если я удалил пряжу.