¿Cómo encontrar al culpable que bloquea los puertos TCP 80, 443 y 5223 en macOS?

Estos puertos, cruciales para iMessage y Facetime, están bloqueados: Puertos TCP 80, 443 y 5223 en macOS Sierra 10.12.2 (MacBookPro11,3). ( https://support.apple.com/en-us/HT202078 )

En Network Utility, realizo un escaneo y el único puerto abierto es 631.

Cuando corro:

python -m SimpleHTTPServer 80

Recibo algunas llamadas y luego dice que:

socket.error: [Errno 13] Permiso denegado

Algunos otros comandos de terminal devuelven respuestas similares.

¿Hay algún método que pueda usar para encontrar al culpable que está bloqueando estos puertos (y probablemente otros) en OSX? Estos puertos se necesitan específicamente para iMessage y Facetime.

No tengo Sophos ni ningún otro Firewall (que yo sepa).

Si algo estuviera bloqueando 80 y 443 no hubieras podido escribir esta pregunta :/
:80 y :443 son para servidores web y servidores web sobre SSL. No son cruciales para iMessage para Facetime. Y como ya se ha respondido, el problema con python es que debe ser root para vincularse a puertos con números bajos.

Respuestas (3)

Hay dos cosas que confundes:

  • FaceTime e iMessage requieren comunicación en los puertos especificados en el artículo para conexiones salientes.

  • Su mensaje "Permiso denegado" está relacionado con la apertura del puerto 80 para conexiones entrantes. No se debe a que ningún proceso lo bloquee, pero si desea que un proceso escuche en un puerto inferior a 1024, debe usar la raíz, por lo que:

    sudo python -m SimpleHTTPServer 80
    
Sí, necesito ver qué está bloqueando 80, 443 y 5223 probablemente usando un comando pfctl.
¿Por qué dices que "algo está bloqueando"?

Sus preguntas , así como otras preguntas, revelan un concepto erróneo de lo que son los puertos bloqueados/no bloqueados o cerrados/abiertos.

Si desea brindar un servicio en una red, necesita un proceso generalmente conectado a un socket de red y direcciones relacionadas que consisten en la dirección local (es decir, la dirección IP) y (para TCP y UDP) un número de puerto.

Por lo tanto, servir un sitio web requiere un proceso (por ejemplo, httpd o en su ejemplo python), un socket y una dirección y puerto relacionados (y algo de contenido). El puerto estándar de un servidor web es el 80.

Tan pronto como inicie un servidor web simple con sudo python -m SimpleHTTPServer 80(los números de puerto menores a 1024 deben ejecutarse como raíz), el puerto se abrirá y podrá acceder a él desde otro host o localmente.

Para obtener puertos abiertos de un host, puede instalar y ejecutar nmap . El comando para obtener todos los puertos TCP abiertos de una IP es:

nmap IP

o todos los puertos TCP abiertos y (la mayoría) UDP

sudo nmap -sT -sU IP

En un sistema Vanilla MacOS Client y después de iniciar el servidor HTTP simple de Python (que está conectado a todas las interfaces internas: localhost, en0 con la IP 192.168.0.2 aquí,...) obtendrá los siguientes resultados de nmap lanzados en el host local y no firewall local habilitado:

nmap 127.0.0.1   
Starting Nmap 7.31 ( https://nmap.org ) at 2017-01-22 22:12 CET
Nmap scan report for 127.0.0.1
Host is up (0.0043s latency).
Not shown: 750 closed ports, 249 filtered ports
PORT   STATE SERVICE
80/tcp open  http

nmap 192.168.0.2    
Starting Nmap 7.31 ( https://nmap.org ) at 2017-01-22 22:12 CET
Nmap scan report for 192.168.0.2
Host is up (0.0043s latency).
Not shown: 750 closed ports, 249 filtered ports
PORT   STATE SERVICE
80/tcp open  http

¡Después de detener el servidor de Python, no obtendrá ningún puerto TCP abierto aunque no haya un firewall habilitado! Tu Mac simplemente no proporciona ningún servicio. Los hosts de cliente Vanilla macOS generalmente no tienen ningún puerto TCP abierto. Sin embargo, puede habilitar algunos: por ejemplo, ssh en el puerto 22. Por cierto, si detecta un puerto 631 abierto, entonces es el uso compartido de impresoras (que es un servicio nuevamente).

sudo nmap -sT -sU 127.0.0.1
Starting Nmap 7.31 ( https://nmap.org ) at 2017-01-22 22:18 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00019s latency).
Not shown: 1891 closed ports, 78 open|filtered ports, 29 filtered ports
PORT    STATE SERVICE
80/tcp  open  http
123/udp open  ntp

sudo nmap -sT -sU 192.168.0.2
Starting Nmap 7.31 ( https://nmap.org ) at 2017-01-22 22:19 CET
Nmap scan report for 192.168.0.2
Host is up (0.00019s latency).
Not shown: 1811 closed ports, 186 open|filtered ports
PORT     STATE SERVICE
80/tcp   open  http
123/udp  open  ntp
5353/udp open  zeroconf

Un puerto cerrado significa que no se está ejecutando ningún servicio en portX. Los otros significados de los diferentes estados de los puertos se explican aquí: Conceptos básicos de exploración de puertos .

Un escaneo de puerto de 192.168.0.2 desde otro host en la misma red producirá los mismos resultados.


En una red SOHO sueles encontrar los siguientes dispositivos:

host1--------(switch-router(firewall))--------WAN/Internet
               |
host2-----------

Cada uno de los hosts puede tener un firewall (habilitado) o un filtro de paquetes, el enrutador generalmente siempre tiene un firewall habilitado.

Después de iniciar su servidor web Python en el host1, podrá detectar el escaneo del puerto 80 abierto desde el host1 y el host2. No puede detectar ningún puerto abierto en los hosts locales desde la WAN porque la LAN está protegida por el firewall del enrutador (y no se puede acceder a ella debido a su naturaleza privada).

Después de habilitar un cortafuegos1 en el host1 (con el bloque de regla de ejemplo pf soltar cualquiera en cualquier puerto 80 ), no podrá detectar ni acceder al escaneo del puerto 80 aún abierto con el host2 porque el cortafuegos1 bloquea el acceso.

Ahora reinicie el servidor Python con el puerto 8080. Ahora no detectará un puerto 80 abierto sino un puerto 8080 abierto de ambos hosts. El firewall1 solo bloquea el puerto 80 y el acceso es posible desde el host2. Si además agrega una regla de reenvío de puertos (= hacer un agujero en el firewall del enrutador) reenvía los paquetes entrantes al puerto 10080 al puerto host1 8080, obtendrá los siguientes resultados:

  • escaneando desde la WAN obtendrá un puerto abierto 10080 (aunque no existe ningún puerto abierto 10080 en los hosts de la LAN)
  • escaneando desde la LAN aún detectará un puerto abierto 8080 en el host1

Obtenga el estado de los firewalls de un host:

  • pf: entrar sudo pfctl -s all | grep Status. Si obtiene "habilitado", ingrese adicionalmente sudo pfctl -vnf /etc/pf.confpara obtener todos los anclajes y reglas. Si no ve ninguna regla de bloqueo (el estado pf predeterminado de OS X), nada está bloqueado.
  • Murus: mira el semáforo en la esquina superior derecha
  • Cortafuegos de aplicaciones: activar/desactivar en Preferencias del sistema > Seguridad > Cortafuegos
  • Little Snitch: verifique cualquier regla de bloqueo saliente
  • Otros cortafuegos (como NetBarrier) suelen comprobar algunos interruptores de encendido/apagado

iMessages no requiere ningún puerto de servicio abierto en su Mac. Dado que iMessages intenta establecer una conexión permanente con algunos servidores de Apple, sería bloqueado por el servidor de seguridad del host o del enrutador (o un servidor de seguridad dedicado), si cualquiera de ellos bloquea el tráfico saliente a estos servidores en los puertos 80, 443 , y 5223 - y/o el Servicio de notificación push de Apple entrante (IIRC, esto solo es posible con inspección profunda de paquetes y mitm).

En comparación, iniciar el servicio de Mensajes en macOS Server abrirá los puertos 80, 443 y 5222 en el host del servidor.


Al leer todas sus preguntas similares sobre iMessages, no creo que su problema esté relacionado con el macOS de su host, sino con algún tipo de Endpoint Protection instalado o un firewall muy restrictivo en la red. ¡O su IP/dispositivo/cuenta está bloqueada por Apple!

@typosruinjokes ¡No y sí! Si ha activado Compartir impresora en Preferencias del sistema > Compartir, el puerto 631 se abrirá para permitir que otros hosts impriman a través de su Mac en la impresora. <cmd> 127.0.0.2(con <cmd>= ping o nmap no debería funcionar en absoluto, si no lo ha agregado al archivo /ect/hosts o lo agregó con ìfconfig.
Gracias por esto. Perdón por la respuesta tardía, he estado enfermo. Antes de leer, quiero recordarles que nosotros (asistente de ingeniero de Apple en Cupertino y yo) estamos seguros de que el problema es con esta instalación de OSX, no con la red o el hardware. Instalamos un nuevo OS X en una partición en el disco duro interno de esta computadora. Pudo, a través de la misma red/enrutador/dirección IP, iniciar sesión en iMessages con la ID de Apple y funcionar sin problemas. Lo mismo con otros dispositivos en la red. Mi única sospecha es que la VPN PIA tiene un cliente OSX que ha causado otros problemas de naturaleza similar.
@typosruinjokes Hmm, ¿cuáles son las diferencias entre las dos instalaciones de OS X? ¿Diferentes versiones (por ejemplo, vainilla = Sierra = iMessages funcionando, "instalación corporativa" = El Capitan y Active Directory? ¿O integración OD? & VPN = iMessages no funcionando)? Sería útil mencionar todas las diferencias y proporcionar más información en sus preguntas. Por ejemplo, al leer su pregunta y comentarios, es la primera vez que menciona la instalación de un cliente VPN.
Era una instalación idéntica simple y antigua en la máquina. Sierra 10.12.2. Lo instalé con el asistente de ingeniería de Apple que quería asegurarse de que fuera el sistema operativo (no la red o el hardware). Y eso fue. re: cliente VPN. Olvídalo. Solo menciono el cliente VPN porque TAL VEZ cambió una configuración. Lo desinstalé hace un tiempo. Justo el otro día vi en un foro que causó problemas a algunas personas ( no este problema), así que lo mencioné. Envié al asistente de ingeniería de Apple. esta convo para revisar. Hablamos de nuevo el jueves. ¡Intentemos resolver esto antes de que él pueda!
Esto es nuevo:Starting Nmap 7.01 ( https://nmap.org ) at 2017-01-24 22:43 EST Nmap scan report for localhost (127.0.0.1) Host is up (0.00040s latency). Not shown: 1993 closed ports PORT STATE SERVICE 631/tcp open ipp 8080/tcp filtered http-proxy 8443/tcp filtered https-alt 123/udp open ntp 137/udp open|filtered netbios-ns 138/udp open|filtered netbios-dgm 5353/udp open|filtered zeroconf
@typosruinjokes Algo probablemente habilitó algún proxy local (8080 tcp/8443 tcp) o instaló TomCat que escucha en los mismos puertos o es un virus/troyano
¿Cómo pruebo para Tomcat? o un virus?
@typosruinjokes Puede obtener los pid de los procesos ingresando sudo lsof -i :8080ysudo lsof -i :8443
cuando hago este comando, no pasa nada. Debo mencionar esto también: cuando enciendo el reenvío de texto en mi iphone, dice que obtenga el código de mi macbook (el sistema en cuestión). ¡El problema es que mi macbook no muestra un código! Esto es sin duda parte del mismo problema.

Puede verificar si los puertos ya están en uso por otra aplicación usando el comando lsof -Pn -i4 | grep :YOURPORT. Por ejemplo, cuando lo ejecuto me sale:

$ lsof -Pn -i4 | grep :9300

testApp 66479 nombre de usuario 8u IPv4 0x176881bf1af12e39 0t0 UDP *:9300

Esto me muestra que 'testApp' está escuchando en el puerto 9300 bajo 'nombre de usuario'.