Come monitorare una porta TCP (e quando avvisare se è aperta)

Il monitoraggio delle porte è due lavori in uno. A volte vuoi sapere che un servizio è in ascolto, come un database o un relay SMTP. A volte vuoi sapere che una porta resta bloccata dal firewall, come SSH su un'istanza esposta a internet. La stessa sonda risponde a entrambe le domande, ma gli avvisi scattano su risultati opposti. Questa guida copre quando usare ciascuna modalità, su cosa avvisare e le porte che colgono di sorpresa.

Come funziona davvero un monitor di porta TCP

Un monitor di porta TCP apre un socket verso il target sulla porta scelta e attende il completamento dell'handshake a tre vie. Se l'handshake riesce, la porta è aperta. Se la connessione viene rifiutata, la porta è chiusa. Se la connessione va in timeout, qualcosa tra il prober e il tuo host sta scartando il pacchetto, di solito un firewall.

La sonda non parla alcun protocollo sopra il socket. Non negozia TLS, non scambia banner SSH e non esegue query al database. Ti dice solo se la porta risponde. Per la salute a livello applicativo è necessario un controllo HTTP o personalizzato sopra.

Quando vuoi la porta APERTA

Usa il monitoraggio delle porte come sonda di salute del servizio quando non puoi fare facilmente un controllo HTTP. Cinque casi comuni si presentano.

• Server di database sulla porta 5432 (Postgres), 3306 (MySQL), 6379 (Redis), 27017 (MongoDB). Se il listener si blocca, tutti i servizi dipendenti si rompono, ma non puoi eseguire una sonda HTTP.
• Relay SMTP sulla porta 25 o 587. I controlli del banner SMTP rilevano crash del listener che gli endpoint di salute interni non vedono.
• Server di gioco e altri protocolli TCP personalizzati che non parlano HTTP.
• Bilanciatori di carico interni che espongono una porta di salute non-HTTP ai servizi a monte.
• Endpoint VPN su porte UDP-ma-anche-TCP come 443 per OpenVPN-TCP e WireGuard.

Quando vuoi la porta CHIUSA

Il monitoraggio invertito delle porte è una salvaguardia di sicurezza. Imposti il monitor in modo che avvisi quando la porta diventa aperta, perché non dovrebbe mai essere aperta dalla rete pubblica. Lo schema rileva le cose che vanno storte durante una normale settimana di modifiche all'infrastruttura.

Qualcuno apre temporaneamente una regola firewall per il debug e dimentica di ripristinarla. Un servizio Kubernetes ottiene un tipo LoadBalancer per errore. Una nuova istanza riceve il security group sbagliato. Una modifica a un modulo Terraform espone una porta che doveva essere interna. In ogni caso, il monitor di porta invertito rileva l'esposizione entro un intervallo di controllo.

Le porte ad alto valore da monitorare in modalità invertita subito

Cinque porte meritano un controllo invertito per qualsiasi host esposto a internet che non dovrebbe esporle.

• 22 (SSH) sui server applicativi di produzione. L'accesso solo tramite bastion host è la norma, e una porta SSH accidentalmente aperta compare nei log delle scansioni di massa entro poche ore.
• 3306 (MySQL) e 5432 (Postgres). Le porte di database pubbliche sono responsabili di una quota significativa degli attacchi di credential stuffing.
• 6379 (Redis). Un Redis aperto senza autenticazione è una delle configurazioni errate più sfruttate del settore.
• 27017 (MongoDB). Stessa storia di Redis. Configurazione predefinita, nessuna autenticazione, porta pubblica equivalgono a perdita di dati.
• 9200 (Elasticsearch). I cluster aperti vengono scansionati, sfruttati per mining e tenuti in ostaggio in poche ore.

Soglie di avviso per il monitoraggio delle porte

La salute del servizio (la porta dovrebbe essere APERTA) richiede lo stesso schema di soglia di HTTP: avvisa dopo 3 fallimenti consecutivi, sopprimi i brevi flap. I blip di rete che chiudono una singola sonda sono rumore.

La sicurezza (la porta dovrebbe essere CHIUSA) richiede l'opposto. Avvisa alla prima rilevazione. Una porta SSH o Redis accidentalmente aperta è un evento di massima allerta. I bot scansionano costantemente la rete pubblica, e la finestra tra esposizione e compromissione su una porta ben nota si misura in minuti.

Una checklist iniziale per il monitoraggio delle porte di sicurezza

Per ogni IP esposto a internet gestito dal tuo team, imposta monitor invertiti su 22, 3306, 5432, 6379 e 27017 con un intervallo di 60 secondi. Indirizza gli avvisi al tuo canale di sicurezza separatamente dagli avvisi di salute del servizio. Una volta al trimestre, esegui una vera scansione delle porte sui tuoi IP come controllo. Il costo è basso, la copertura è ampia e i modi di guasto che rileva sono catastrofici.