1 votos

¿Cómo encontrar al culpable del bloqueo de 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 el 631.

Cuando corro:

python -m SimpleHTTPServer 80

Recibo unas cuantas llamadas y luego se lee eso:

socket.error: [Errno 13] Permiso denegado

Algunos otros comandos de terminal devuelven respuestas similares.

¿Hay algún método que pueda utilizar para encontrar al culpable de bloquear estos puertos (y probablemente otros) en OSX? Estos puertos son necesarios específicamente para iMessage y Facetime.

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

3 votos

Si algo estuviera bloqueando la 80 y la 443 no habrías podido escribir esta pregunta :/

0 votos

: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 necesitas ser Root para enlazar con puertos de baja numeración.

5voto

haiggoh Puntos 73

Hay dos cosas que confundes:

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

  • Tu mensaje de "Permiso denegado" está relacionado con la apertura del puerto 80 para conexiones entrantes. No es por ningún proceso que lo bloquee, pero si quieres hacer que un proceso escuche en un puerto menor a 1024, necesitas usar Root, así que:

    sudo python -m SimpleHTTPServer 80

0 votos

Sí, necesito ver lo que bloquea 80, 443 y 5223 probablemente usando un comando pfctl.

3 votos

¿Por qué afirma que "algo está bloqueando"?

4voto

klanomath Puntos 19587

Su preguntas así como otros preguntas revelan una idea errónea de lo que son los puertos bloqueados/no bloqueados o cerrados/abiertos.

Si se quiere prestar un servicio en una red, se necesita un proceso que suele estar conectado a un zócalo de red y unas 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 un puerto relacionados (y algo de contenido). El puerto estándar de un servidor web es el 80.

En cuanto se inicia un servidor web simple con sudo python -m SimpleHTTPServer 80 (los números de puerto inferiores a 1024 tienen que ser ejecutados como Root) el puerto se abrirá y podrás acceder a él desde otro host o localmente.

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

nmap IP

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

sudo nmap -sT -sU IP

En un sistema MacOS Client vainilla 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 lanzado en el host local y no cortafuegos 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 Python no obtendrá ningún puerto TCP abierto aunque no haya ningún cortafuegos activado. Tu Mac simplemente no proporciona ningún servicio. Los clientes Vanilla MacOS no suelen tener ningún puerto TCP abierto. Sin embargo, puedes habilitar algunos: por ejemplo, ssh en el puerto 22. Por cierto, si detecta un puerto 631 abierto, entonces se trata de compartir impresoras (que es un servicio, de nuevo).

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 hay ningún servicio funcionando en el puertoX. Los otros significados de los diferentes estados de los puertos se explican aquí: Fundamentos de la exploración de puertos .

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


En una red SOHO suelen encontrarse los siguientes dispositivos:

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

Cada uno de los hosts puede tener un firewall o filtro de paquetes (habilitado), el router suele tener siempre 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. Usted no puede detectar cualquier puerto abierto en los hosts locales desde la WAN porque la LAN está protegida por el firewall del router (y no es alcanzable debido a su naturaleza privada).

Después de habilitar un firewall1 en el host1 (con la regla de ejemplo pf bloquear la caída de cualquier a cualquier puerto 80 ) no podrá detectar o acceder a la quietud Abrir escaneo del puerto 80 con el host2 porque el firewall1 bloques acceso.

Ahora relanza el servidor Python con el puerto 8080. Ahora detectará que no hay ningún puerto 80 abierto, sino un puerto 8080 abierto desde ambos hosts. El firewall1 sólo bloquea el puerto 80 y el acceso es posible desde el host2. Si adicionalmente añades una regla de reenvío de puertos (= perforar un agujero en el firewall del router) reenviar los paquetes entrantes al puerto 10080 al puerto 8080 del host1 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 8080 abierto en el host1

Obtiene el estado de los firewalls de los hosts:

  • pf: entrar sudo pfctl -s all | grep Status . Si le aparece "habilitado", introduzca adicionalmente sudo pfctl -vnf /etc/pf.conf para obtener todas las anclas y reglas. Si no ves ninguna regla de bloqueo (el estado por defecto de OS X pf) no hay nada bloqueado.
  • Murus: comprueba el semáforo en la esquina superior derecha
  • Firewall de aplicaciones: activar/desactivar en Preferencias del Sistema > Seguridad > Firewall
  • Little Snitch: comprueba cualquier regla de bloqueo de salida
  • Otros cortafuegos (como NetBarrier) suelen controlar algunos interruptores de encendido/apagado

iMessages no requiere ninguna Abrir puerto de servicio en su Mac. Dado que iMessages intenta establecer una conexión "keep-alive" con algunos servidores de Apple, podría ser bloqueado por el firewall del host o del router (o por un firewall dedicado), aunque si alguno de ellos bloquea saliente el tráfico hacia estos servidores en los puertos 80, 443 y 5223 - y/o el que llega a Servicio de Notificación Push de Apple (IIRC esto sólo es posible con la inspección profunda de paquetes y mitm).

En comparación, el inicio de los Mensajes servicio en Servidor MacOS abrirá los puertos 80, 443 y 5222 en el servidor.


Leyendo todas tus preguntas similares sobre iMessages no creo que tu problema esté relacionado con el MacOS de tu anfitrión sino con algún tipo de Endpoint Protection instalado o con un firewall muy restrictivo en la red. O tu IP/dispositivo/cuenta está bloqueada por Apple.

0 votos

@typosruinjokes ¡No y sí! Si has habilitado Compartir Impresora en Preferencias del Sistema > Compartir, se abrirá el puerto 631 para que otros hosts puedan imprimir a través de tu Mac en la impresora. <cmd> 127.0.0.2 (con <cmd>= ping o nmap no debería funcionar en absoluto, si no lo has añadido al archivo /ect/hosts o lo has añadido con ìfconfig.

0 votos

Gracias por esto. Perdón por el retraso en la respuesta he estado enfermo. Antes de leer, quiero recordarles que nosotros (el ingeniero asistente de Apple en Cupertino y yo) estamos seguros el problema es con esta instalación de OSX, no la red o el hardware. Nosotros instalé un OS X nuevo en una partición del disco duro interno de este ordenador. Fue capaz, a través de la misma red/router/dirección IP, de iniciar sesión en iMessages con el ID de Apple y funcionar sin problemas. Lo mismo ocurre con otros dispositivos de la red. Mi única sospecha es que la VPN PIA tiene un cliente OSX que ha causado a otros problemas de naturaleza similar.

0 votos

@typosruinjokes Hmm ¿cuáles son las diferencias entre las dos instalaciones de OS X? ¿Diferentes versiones (por ejemplo, vanilla=Sierra=iMessages funcionando, "instalación corporativa"=El Capitan& Active Directory? o integración de OD? & VPN=iMessages no funciona)? Sería útil mencionar todo diferencias y proporcionar más información en sus preguntas. Por ejemplo, al leer tu pregunta y los comentarios, es la primera vez que mencionas la instalación de un cliente VPN.

3voto

HeroCC Puntos 131

Puede comprobar si los puertos ya están en uso por otra aplicación utilizando 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 'username'.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X