Audita lo que envía tu Mac en 10 minutos, desde la terminal

No necesita instalar nada para obtener una imagen real y actual de con qué está hablando su Mac. Todas las herramientas de este laboratorio se entregan con macOS. Ninguno de ellos requiere que usted confíe su tráfico a un tercero, y los seis juntos tardan unos diez minutos en ejecutarse una vez que conoce los comandos. Lo que no harán, y esto importa, es decirle cuáles de esas conexiones están bien y cuáles no; para eso aún necesita contexto, y al final seremos honestos acerca de dónde terminan estas herramientas.

1. lsof: cada conexión abierta, ahora mismo

En Unix, un socket de red es un archivo y lsof (lista de archivos abiertos) los enumera. La página de manual de macOS describe -i como una selección de archivos cuya dirección de Internet coincida con una especificación determinada, sin ninguna, en cada toma de Internet. Agregue -n para omitir la resolución de direcciones a nombres de host y -P para omitir la resolución de puertos a nombres de servicios; ambos hacen que el comando sea más rápido y la salida sea exacta en lugar de aproximada.

$ sudo lsof -i -n -P
# example output, trimmed to a few representative lines
COMMAND   PID   USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
Mail      612   alice   9u  IPv4  0x...      0t0  TCP 192.168.1.10:54321->17.57.145.13:993 (ESTABLISHED)
Slack     980   alice  22u  IPv4  0x...      0t0  TCP 192.168.1.10:54400->35.186.224.25:443 (ESTABLISHED)
mDNSResp   88   root    4u  IPv4  0x...      0t0  UDP *:5353

Léalo de izquierda a derecha: nombre del proceso y PID, la dirección y el puerto local, -> y la dirección y el puerto remotos, y el estado de la conexión. ESTABLISHED significa una conexión bidireccional activa en este momento. Ejecute sin sudo y seguirá viendo sus propios procesos; los de propiedad raíz lo necesitan. Lo que esto no puede decirle: lsof es una instantánea del instante en que presionó Enter. Una conexión que se abrió, envió unos pocos kilobytes y se cerró medio segundo antes de ejecutar el comando simplemente no está allí; debe ejecutarla repetidamente o pasar a la siguiente herramienta para detectarla.

2. nettop: la misma vista, pero en vivo

nettop es la versión en vivo de la misma idea. Su página de manual lo describe como que muestra "una lista de sockets o rutas" con estadísticas actualizadas periódicamente. -m route cambia de enumerar sockets a enumerar la vista de tabla de enrutamiento; -m tcp o -m udp lo restringen a un protocolo.

$ nettop -m route
# interactive; press q to quit, or use -l N to print N samples and exit
# example output, trimmed
  time                     interface  state       bytes_in  bytes_out
23:41:02.123 Mail.612      en0        Established     4.2K      1.1K
23:41:02.123 Slack.980     en0        Established    18.6K      6.4K

Agregue -l 5 para tomar cinco muestras y salir en lugar de realizar una sesión interactiva, lo cual es útil si desea canalizar la salida a algún lugar. nettop soluciona el problema de instantáneas de lsof (puede ver aparecer una conexión, transferir datos y cerrarse), pero hereda el mismo límite: un nombre de proceso y un PID, nada sobre quién firmó el binario y ninguna memoria una vez que cierra el terminal.

3. flujo de registros: lo que dice el propio sistema sobre la red

macOS mantiene un registro unificado y estructurado de lo que hace cada proceso, y log stream te permite verlo en vivo y filtrado. La página de manual describe --predicate como filtrado de entradas utilizando cláusulas de estilo NSPredicate contra el contenido del subsistema, categoría, proceso y mensaje.

$ log stream --predicate 'eventMessage contains "network" or subsystem == "com.apple.network"' --info
# live stream; Ctrl-C to stop. Example line, trimmed:
2026-09-14 23:41:05.001 process=nesessionmanager subsystem=com.apple.network "TCP Connection ... state changed to Ready"

Esta es la menos accesible de las seis herramientas (el volumen es alto y la sintaxis de predicados tiene una curva de aprendizaje), pero también es la única que muestra los cambios de estado de la red a nivel del sistema y los eventos del ciclo de vida de la conexión a medida que ocurren, en un lenguaje sencillo y etiquetado por el subsistema responsable. Trátelo como algo para grep, no para leer línea por línea: canalícelo a través de grep para obtener un nombre de proceso que le interese o una palabra clave como "Wi-Fi" o "VPN".

4. scutil --dns y dig: lo que realmente está resolviendo tu Mac

Antes de que se produzca una conexión, normalmente se realiza una búsqueda de DNS. scutil --dns, según su página de manual, "informa la configuración DNS actual": qué solucionadores están configurados, cuál es el predeterminado y cuáles se aplican solo a dominios específicos (DNS dividido, común en VPN).

$ scutil --dns
# example output, trimmed
DNS configuration
resolver #1
  nameserver[0] : 192.168.1.1
  if_index : 12 (en0)
  flags    : Request A records, Request AAAA records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

dig responde directamente a una sola pregunta: ¿a qué se refiere este nombre en este momento? Su página de manual lo llama "una herramienta flexible para interrogar servidores de nombres DNS" valorada por su "flexibilidad, facilidad de uso y claridad de resultados".

$ dig example.com +short
# example output
93.184.216.34

Ninguna herramienta le dice qué aplicación activó la búsqueda o qué sucedió después: DNS solo le brinda la dirección a la que una aplicación está a punto de conectarse (o ya lo hizo); la conexión en sí es lo que le muestra lsof, nettop o un registro de firewall.

5. tcpdump: la verdad fundamental y la que necesita sudo

Todo lo anterior indica el estado que ya mantiene el sistema operativo. tcpdump es diferente: captura paquetes directamente desde una interfaz, por lo que su propia documentación es directa sobre el requisito: "Leer paquetes desde una interfaz de red puede requerir que tenga privilegios especiales"; en la práctica, sudo en macOS. Utilice -i para elegir la interfaz, -n para mantener las direcciones numéricas y una expresión de filtro como port 53 para aislar el tráfico DNS:

$ sudo tcpdump -i en0 -n port 53
# example output, trimmed
23:41:10.221331 IP 192.168.1.10.54812 > 192.168.1.1.53: 41213+ A? example.com. (30)
23:41:10.244109 IP 192.168.1.1.53 > 192.168.1.10.54812: 41213 1/0/0 A 93.184.216.34 (46)

El patrón a notar: una consulta enviada al puerto 53 seguida inmediatamente por una respuesta. Si ejecuta dig en una terminal mientras tcpdump se ejecuta en otra, puede observar la consulta y la respuesta exactas que produjo su propio comando, una buena manera de creer realmente lo que dicen las páginas de manual en lugar de tomarlas por fe.

Una séptima herramienta gratuita: Monitor de actividad

Vale la pena nombrar la única opción gráfica de esta lista, ya que no todo necesita un terminal. La pestaña Red de Activity Monitor le brinda totales (datos enviados y recibidos por proceso, y un gráfico de rendimiento en vivo), que es la primera parada adecuada para "algo está consumiendo el ancho de banda y no sé qué". También es la ilustración más clara del límite que comparten todas las herramientas de este artículo: puede indicarle que un proceso auxiliar movió dos gigabytes durante la noche y no tiene una columna que indique adónde fueron esos dos gigabytes. El volumen y el destino son dos preguntas diferentes y macOS las responde con dos herramientas diferentes.

Juntando los diez minutos

1. sudo lsof -i -n -P: obtiene la lista actual de sockets abiertos, una pasada, treinta segundos.
2. nettop -m route -l 5: tome algunas muestras en vivo para captar cualquier cosa que lsof haya perdido.
3. scutil --dns: confirma qué solucionador estás utilizando realmente, especialmente si estás conectado a una VPN o a una red Wi-Fi pública.
4. dig <name> +short, sobre cualquier elemento desconocido del paso 1, para ver en qué se resuelve actualmente.
5. sudo tcpdump -i en0 -n port 53, durante sesenta segundos, para observar el tráfico DNS sin procesar a medida que las aplicaciones realizan sus actividades.
6. log stream --predicate con una palabra clave grep, si algo de lo anterior generó una pregunta, los cinco anteriores no respondieron.

Un ejemplo trabajado

Digamos que el paso 1 muestra un proceso llamado helperd que mantiene una conexión abierta a una dirección que no reconoce. No te detengas ahí. Ejecute dig -x <the address> para realizar una búsqueda inversa; no siempre se resolverá en algo legible, pero cuando lo haga, un nombre de host como ads.example-cdn.net le dirá más en cinco segundos que la IP sin formato. Ejecute nettop -m tcp -l 3 y observe si esa misma conexión todavía está abierta unos segundos más tarde y si los bytes realmente se están moviendo a través de ella o si está inactiva. Si está inactivo y se vuelve a abrir en un intervalo fijo, esa es la forma de un registro periódico en lugar de una transferencia única; vale la pena recordarlo, pero no preocuparse automáticamente, ya que los verificadores de actualizaciones comunes se comportan de la misma manera. Luego verifique scutil --dns para confirmar que el solucionador que produjo cualquier dirección a la que se conectó helperd era la que esperaba, especialmente si está en la red Wi-Fi de otra persona. Cinco comandos, un proceso, y habrá pasado de "No reconozco esto" a "esto es específicamente lo que sé y lo que no sé al respecto", que es el objetivo real de una auditoría como esta, más que un veredicto de bueno o malo.

Lo que ninguna de estas herramientas te dirá

Si recorre los seis, todavía le quedarán tres espacios reales. Primero, la identidad más allá del nombre de un proceso: nada aquí verifica si el binario llamado "Correo" es el correo de Apple o algo que se cambió de nombre, o si está firmado; eso es una búsqueda separada con codesign y spctl. Segundo, la memoria: una vez que se cierra la ventana de la terminal, también se cierra todo lo que has aprendido; no hay ningún registro de "a qué se conectó mi Mac el martes pasado" a menos que cree uno usted mismo. En tercer lugar, el juicio: ninguna de estas herramientas tiene opinión sobre si se espera una conexión. Una aplicación para tomar notas que se conecta a una dirección que nunca antes ha usado se ve exactamente igual en lsof que una que se conecta a su servidor de sincronización habitual; diferenciarlas es el reconocimiento de patrones que debe realizar usted mismo o una herramienta que debe realizar por usted.

El papel de FireAI y de HisnLabs

Everything in this lab is free and built into macOS, and none of it names the process behind a connection or remembers it after the terminal closes — which is the specific, narrow gap FireAI’s per-app rules and connection history are built to close.

FireAI es el propio producto de HisnLabs: un cortafuegos con IA integrada para Mac. Muestra, en lenguaje claro, cada conexión que hacen tus aplicaciones y te deja decidir qué sale de tu Mac; su IA funciona en el propio equipo, así que tu tráfico nunca se envía a HisnLabs ni a nadie más. El equipo de investigación en seguridad de HisnLabs es quien mantiene esas decisiones fiables: cataloga qué dominios son simple telemetría frente a un servicio real, sigue el país y la red detrás de una conexión, y entrena el modelo local (la función Autopilot) con tráfico real, sin que nada salga de tu Mac.

Puedes leer las decisiones técnicas detrás de esto, o probar FireAI durante 17 días, en FireAI, de HisnLabs.