Verifica cosa invia il tuo Mac in 10 minuti, dal Terminale

Non serve installare nulla per avere un quadro reale e aggiornato di con chi sta parlando il tuo Mac. Ogni strumento di questo laboratorio è già incluso in macOS. Nessuno di essi richiede di affidare il tuo traffico a terzi, e tutti e sei insieme richiedono circa dieci minuti una volta che conosci i comandi. Quello che non faranno, ed è importante dirlo, è indicarti quali di quelle connessioni vanno bene e quali no — per questo serve ancora il contesto, e alla fine saremo onesti su dove questi strumenti si fermano.

1. lsof — ogni connessione aperta, in questo momento

Su Unix, un socket di rete è un file, e lsof (list open files) li elenca. La pagina man di macOS descrive -i come la selezione dei file il cui indirizzo internet corrisponde a una specifica data — senza specificarne una, ogni socket internet. Aggiungi -n per saltare la risoluzione degli indirizzi in nomi host e -P per saltare la risoluzione delle porte in nomi di servizio; entrambi rendono il comando più veloce e l’output esatto invece che approssimativo.

$ 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

Leggilo da sinistra a destra: nome del processo e PID, l’indirizzo e la porta locali, -> e l’indirizzo e la porta remoti, e lo stato della connessione. ESTABLISHED significa una connessione attiva e bidirezionale in questo momento. Eseguito senza sudo vedrai comunque i tuoi processi; quelli di proprietà di root richiedono i privilegi. Cosa non può dirti: lsof è un’istantanea dell’istante in cui hai premuto Invio. Una connessione apertasi, che ha inviato pochi kilobyte e si è chiusa mezzo secondo prima che tu lanciassi il comando semplicemente non c’è — devi eseguirlo più volte, o passare allo strumento successivo, per coglierla.

2. nettop — la stessa vista, ma in diretta

nettop è la versione dal vivo della stessa idea. La sua pagina man la descrive come uno strumento che mostra "un elenco di socket o di rotte" con statistiche aggiornate periodicamente. -m route la fa passare dall’elencare i socket all’elencare la vista della tabella di routing; -m tcp o -m udp la limitano a un solo protocollo.

$ 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

Aggiungi -l 5 per catturare cinque campioni e uscire invece di mantenere una sessione interattiva, utile se vuoi reindirizzare l’output altrove. nettop risolve il problema dell’istantanea di lsof — puoi osservare una connessione comparire, trasferire dati e chiudersi — ma eredita lo stesso limite: un nome di processo e un PID, nulla su chi ha firmato il binario, e nessuna memoria una volta chiuso il terminale.

3. log stream — cosa dice il sistema stesso sulla rete

macOS mantiene un log unificato e strutturato di ciò che ogni processo sta facendo, e log stream ti permette di osservarlo dal vivo, filtrato. La pagina man descrive --predicate come il filtraggio delle voci usando clausole in stile NSPredicate su sottosistema, categoria, processo e contenuto del messaggio.

$ 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"

Questo è il meno accessibile dei sei strumenti — il volume è alto e la sintassi dei predicati ha una curva di apprendimento — ma è anche l’unico che fa emergere i cambiamenti di stato della rete a livello di sistema e gli eventi del ciclo di vita di una connessione mentre accadono, in un inglese (più o meno) semplice, etichettato con il sottosistema responsabile. Trattalo come qualcosa da filtrare con grep, non da leggere riga per riga: reindirizzalo attraverso grep per un nome di processo che ti interessa, o per una parola chiave come "Wi-Fi" o "VPN".

4. scutil --dns e dig — cosa sta davvero risolvendo il tuo Mac

Prima che avvenga una connessione, di solito c’è una richiesta DNS. scutil --dns, secondo la sua pagina man, "riporta la configurazione DNS attuale": quali resolver sono configurati, quale sia quello predefinito, e quali si applichino solo a domini specifici (DNS split, comune sulle 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 risponde direttamente a una singola domanda: a cosa risolve questo nome, adesso. La sua pagina man lo definisce "uno strumento flessibile per interrogare i server dei nomi DNS", apprezzato per "flessibilità, facilità d’uso e chiarezza dell’output."

$ dig example.com +short
# example output
93.184.216.34

Nessuno dei due strumenti ti dice quale app ha innescato la richiesta o cosa è successo dopo — il DNS ti dà solo l’indirizzo a cui un’app sta per connettersi (o si è già connessa); la connessione vera e propria è ciò che ti mostrano lsof, nettop o un log del firewall.

5. tcpdump — la verità di fondo, e quella che richiede sudo

Tutto quanto sopra legge uno stato che il sistema operativo tiene già. tcpdump è diverso: cattura i pacchetti direttamente da un’interfaccia, ed è per questo che la sua stessa documentazione è diretta sul requisito — "Leggere pacchetti da un’interfaccia di rete può richiedere privilegi speciali" — in pratica, sudo su macOS. Usa -i per scegliere l’interfaccia, -n per mantenere gli indirizzi in forma numerica, e un’espressione di filtro come port 53 per isolare il traffico 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)

Lo schema da notare: una richiesta che esce sulla porta 53 seguita immediatamente da una risposta che rientra. Se esegui dig in un terminale mentre tcpdump gira in un altro, puoi osservare l’esatta richiesta e risposta prodotte dal tuo stesso comando — un buon modo per credere davvero a ciò che dicono le pagine man invece di darlo per buono sulla fiducia.

Un settimo strumento gratuito: Monitoraggio Attività

Vale la pena nominare l’unica opzione grafica di questo elenco, perché non tutto richiede un terminale. La scheda Rete di Monitoraggio Attività dà i totali — dati inviati e ricevuti per processo, e un grafico di throughput dal vivo — che è la prima tappa giusta per "qualcosa sta consumando banda e non so cosa". È anche l’illustrazione più chiara del limite che ogni strumento di questo articolo condivide: può dirti che un processo di supporto ha spostato due gigabyte durante la notte, e non ha nessuna colonna su dove siano finiti quei due gigabyte. Volume e destinazione sono due domande diverse, e macOS vi risponde con due strumenti diversi.

Mettere insieme i dieci minuti

1. sudo lsof -i -n -P — ottieni l’elenco attuale dei socket aperti, un solo passaggio, trenta secondi.
2. nettop -m route -l 5 — cattura qualche campione dal vivo per cogliere ciò che l’istantanea di lsof si è persa.
3. scutil --dns — conferma quale resolver stai effettivamente usando, specialmente se sei su una VPN o su un Wi-Fi pubblico.
4. dig <nome> +short, su qualsiasi cosa non familiare emersa al passo 1, per vedere a cosa risolve attualmente.
5. sudo tcpdump -i en0 -n port 53, per sessanta secondi, per osservare il traffico DNS allo stato grezzo mentre le app fanno il loro lavoro.
6. log stream --predicate con un grep per parola chiave, se qualcosa sopra ha sollevato una domanda a cui i cinque passi precedenti non hanno risposto.

Un esempio pratico

Supponiamo che il passo 1 faccia emergere un processo chiamato helperd con una connessione aperta verso un indirizzo che non riconosci. Non fermarti lì. Esegui dig -x <l’indirizzo> per una ricerca inversa — non sempre risolverà in qualcosa di leggibile, ma quando lo fa, un nome host come ads.example-cdn.net ti dice più cose in cinque secondi di quante te ne dirà mai l’IP grezzo. Esegui nettop -m tcp -l 3 e osserva se quella stessa connessione è ancora aperta qualche secondo dopo, e se i byte si stanno effettivamente muovendo o se è inattiva. Se è inattiva e si riapre a intervalli fissi, è la forma tipica di un controllo periodico più che di un trasferimento occasionale — da tenere a mente, non automaticamente da preoccuparsene, dato che i normali controlli di aggiornamento si comportano allo stesso modo. Poi controlla scutil --dns per confermare che il resolver che ha prodotto l’indirizzo a cui si è connesso helperd fosse quello che ti aspettavi, specialmente se sei sul Wi-Fi di qualcun altro. Cinque comandi, un processo, e sei passato da "non lo riconosco" a "ecco esattamente cosa so e non so su di esso" — che è l’obiettivo reale di una verifica come questa, più che un verdetto di buono o cattivo.

Cosa nessuno di questi strumenti ti dirà

Passa in rassegna tutti e sei e ti restano comunque tre lacune reali. Prima: l’identità oltre il nome del processo: nulla qui verifica se il binario chiamato "Mail" sia il Mail di Apple o qualcosa che si è rinominato, o se sia firmato del tutto — quella è una verifica separata con codesign e spctl. Seconda: la memoria: una volta chiusa la finestra del terminale, scompare anche tutto ciò che hai appreso; non esiste un log di "a cosa si è connesso il mio Mac martedì scorso" a meno che tu non ne costruisca uno tu stesso. Terza: il giudizio: nessuno di questi strumenti ha un’opinione su se una connessione sia attesa o meno. Un’app per prendere appunti che si connette a un indirizzo mai usato prima appare esattamente identica in lsof a una che si connette al suo solito server di sincronizzazione — distinguere le due cose è un riconoscimento di schemi che devi portare tu stesso, oppure che uno strumento deve portare per te.

Il ruolo di FireAI e di 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 è il prodotto di HisnLabs: un firewall con IA che funziona direttamente sul Mac. Mostra in linguaggio chiaro ogni connessione che le tue app effettuano e ti lascia decidere cosa esce dal tuo Mac — la sua IA lavora in locale, quindi il tuo traffico non viene mai inviato a noi né a nessun altro. Il team di ricerca sulla sicurezza di HisnLabs è quello che mantiene affidabili queste decisioni: cataloga quali domini sono semplice telemetria e quali un servizio reale, traccia il Paese e la rete dietro una connessione e addestra il modello locale (la funzione Autopilot) su schemi di traffico reali, senza che nulla lasci il tuo Mac.

Puoi leggere le scelte tecniche che ci stanno dietro, oppure provare FireAI per 17 giorni, su FireAI, di HisnLabs.