Ogni dispositivo collegato a internet espone un numero finito di punti di contatto. Il port scanning è l’insieme delle tecniche che servono a stabilire quali di questi punti rispondono e quali restano muti.

È la prima operazione che compie chi vuole capire com’è fatta un’infrastruttura, e vale sia che dietro quell’indirizzo ci sia un server, un firewall, un centralino telefonico o una stampante di rete. La stessa attività, condotta con un mandato, è anche il primo passo di qualunque verifica di sicurezza seria.

  1. Porte e protocolli: che cosa si sta interrogando
  2. I tre stati che una porta può assumere
  3. Perché TCP e UDP si comportano in modo diverso
  4. Cosa rivela una scansione oltre all’elenco
  5. Il conteggio delle porte non misura il rischio
  6. La scansione come attività autorizzata
Scansione delle porte di rete su un host esposto su internet

Porte e protocolli: che cosa si sta interrogando

Le comunicazioni fra dispositivi in rete si appoggiano su due protocolli di trasporto: TCP, che stabilisce una connessione e ne verifica l’integrità, e UDP, che invia pacchetti senza preoccuparsi di sapere se sono arrivati.

Entrambi usano la stessa coppia di coordinate.
L’indirizzo IP individua la macchina, la porta individua il servizio in ascolto su quella macchina. È un numero a sedici bit, quindi le possibilità sono 65.536 per ciascuno dei due protocolli, e per convenzione sono divise in tre fasce: le prime 1.024 assegnate ai servizi standard, la fascia intermedia registrata da applicazioni specifiche e l’ultima riservata alle connessioni temporanee che il sistema apre e chiude da sé.

Le convenzioni sono note e questo è il punto da cui parte ogni ricognizione.
Una risposta sulla 443 suggerisce traffico web cifrato, sulla 3389 un desktop remoto, sulla 1433 un database. Non sono certezze, perché nulla vieta di far girare un servizio su una porta arbitraria, ma nella pratica quasi nessuno lo fa e le convenzioni reggono.

Vale la pena tenere presente che la porta è solo l’ingresso. La solidità di quello che c’è dietro dipende da tutt’altro: la versione del software, la sua configurazione, il modo in cui gestisce l’autenticazione. Un certificato SSL valido sulla 443 dice che la connessione è cifrata, non che l’applicazione sottostante sia sicura.

I tre stati che una porta può assumere

Interrogando una porta si ottiene una fra tre risposte possibili, e la differenza fra loro conta più di quanto sembri.

La porta è aperta quando risponde accettando la comunicazione. C’è un servizio in ascolto ed è raggiungibile.

È chiusa quando la macchina risponde ma segnala che nessun servizio è in ascolto su quel numero. La risposta è comunque un’informazione: conferma che l’indirizzo è attivo e che fra voi e quella macchina non c’è nulla che filtri.

È filtrata quando non arriva nessuna risposta. Un firewall ha scartato il pacchetto in silenzio, senza dire niente a nessuno. Dal punto di vista di chi osserva dall’esterno questo stato è il meno informativo, e per questo è quello che conviene presentare su tutto ciò che non deve essere raggiungibile.

stati porta aperta chiusa filtrata

La distinzione fra chiusa e filtrata è la ragione tecnica per cui una configurazione di firewall che scarta invece di rifiutare riduce la quantità di informazioni che l’infrastruttura regala. È una delle prime cose che si verificano quando si affronta la protezione di una rete aziendale, e una delle più trascurate.

Perché TCP e UDP si comportano in modo diverso

Su TCP l’interrogazione è relativamente semplice, perché il protocollo prevede una procedura di apertura in tre passaggi: richiesta, conferma, riconoscimento. Basta osservare a che punto la procedura si interrompe per capire lo stato della porta, e non serve nemmeno portarla a termine: molti strumenti si fermano al secondo passaggio, il che rende l’operazione più rapida e lascia meno tracce nei registri delle connessioni.

Su UDP la faccenda è più incerta. Il protocollo non prevede conferme, quindi l’assenza di risposta è ambigua: può significare che la porta è aperta e il servizio non ha nulla da dire, oppure che un firewall ha scartato il pacchetto. Le scansioni UDP sono per questo più lente e meno affidabili, e vengono spesso tralasciate.

È una lacuna che conta, perché su UDP viaggiano servizi rilevanti. Il DNS, il protocollo di sincronizzazione oraria, i tunnel VPN di alcune implementazioni. Un inventario dell’esposizione che considera solo TCP ne perde una parte, ed è una delle ragioni per cui uno strumento gratuito che restituisce un elenco in tre secondi non equivale a una verifica.

Sapete quali servizi della vostra rete rispondono da internet?

Un vulnerability assessment parte dall’inventario di ciò che è effettivamente esposto, su TCP e su UDP, e ne verifica versioni, configurazioni e vulnerabilità note. Il risultato arriva in un report con le priorità di intervento.

Scoprite il servizio di Vulnerability Assessment

Cosa rivela una scansione oltre all’elenco

L’elenco delle porte aperte è il risultato più immediato ma non il più significativo.
Un servizio che risponde tende a presentarsi, e quello che dice di sé è materiale prezioso per chi lo interroga.

Molti servizi restituiscono spontaneamente un’intestazione con nome del prodotto e numero di versione. Altri si fanno riconoscere dal modo in cui rispondono a richieste leggermente irregolari, perché ogni implementazione ha le sue particolarità. Lo stesso vale per il sistema operativo sottostante, identificabile dalle caratteristiche dei pacchetti che invia.

Il passaggio successivo è meccanico. Nome del prodotto più numero di versione permettono di consultare gli archivi pubblici delle vulnerabilità e stabilire se quel software ha problemi noti. È lo stesso percorso descritto nell’articolo su che cosa sono gli exploit: la vulnerabilità viene pubblicata, il codice per sfruttarla circola in poche ore, e le scansioni automatiche individuano chi non ha aggiornato.

Gli esempi non mancano.
Le vulnerabilità critiche su Microsoft Exchange hanno colpito server di posta esposti in tutto il mondo, e la vicenda di BlueKeep sul desktop remoto ha mostrato che cosa succede quando un protocollo nato per la rete interna finisce pubblicato su internet. In nessuno dei due casi le aziende colpite erano state scelte: erano raggiungibili e indietro con le patch.

Il conteggio delle porte non misura il rischio

Qui sta l’errore più comune quando si legge il risultato di una scansione.

Sapere che la 443 è aperta su un vostro indirizzo non dice nulla sul rischio: è la porta del traffico web cifrato, ed è aperta su qualunque organizzazione che abbia un sito. La domanda utile riguarda il servizio dietro: quale software è, quale versione monta, se la sua configurazione espone funzioni che dovrebbero restare interne.

Ne consegue che un’azienda con sei porte aperte e servizi aggiornati sta meglio di una con due porte aperte e un concentratore VPN fermo a una versione con vulnerabilità pubblicate. Il conteggio misura la cosa sbagliata.

C’è poi un terzo livello, che nessuno strumento automatico raggiunge: che cosa consegna quel servizio a chi riesce a superarlo. Una porta che apre su un’applicazione isolata e una che apre su un sistema collegato all’intera rete interna hanno lo stesso aspetto in una scansione e un peso completamente diverso nella realtà. È la differenza fra un incidente circoscritto e uno che si propaga ed è il motivo per cui la riduzione della superficie di attacco lavora su due fronti, non solo su quello che è visibile.

La scansione come attività autorizzata

Lo stesso insieme di tecniche cambia natura in base al mandato che lo accompagna. Condotta senza autorizzazione contro sistemi di terzi, la ricognizione è un’attività illecita. Condotta su perimetro definito e con un incarico scritto, è il punto di partenza di qualunque verifica.

Nella pratica professionale la scansione non è il lavoro, è il suo primo quarto d’ora. Serve a costruire l’inventario da cui partire, e tutto ciò che conta viene dopo: l’identificazione dei servizi, il confronto con le vulnerabilità pubblicate, la valutazione di quali fra queste siano effettivamente sfruttabili in quella specifica configurazione, e la distinzione fra un falso positivo e un problema reale.

È anche la ragione della differenza fra due attività che vengono spesso confuse.
Un vulnerability assessment stabilisce quali vulnerabilità sono presenti sul perimetro.
Un penetration test verifica se e fino a dove è possibile arrivare partendo da esse, concatenando debolezze che prese una per una sembrerebbero innocue. Per le applicazioni web esposte il lavoro si specializza ulteriormente, e diventa un web application penetration testing.

La scelta fra queste attività dipende dal perimetro e dal livello di conoscenza che si mette a disposizione di chi verifica, come mostra la distinzione fra approccio black box, dove il tester parte dalle stesse informazioni di un attaccante esterno e approccio white box, dove riceve documentazione e credenziali.

Se invece la domanda che vi interessa è che cosa significa scoprire che qualcuno sta scansionando i vostri indirizzi, l’abbiamo affrontata nell’articolo su che cosa sapere su un port scanning attack.

Fin dove si arriva partendo da un servizio esposto?

Un penetration test parte da un punto di ingresso realistico e verifica quali sistemi interni risultano effettivamente raggiungibili, sulla base di prove e non di ipotesi.

Scoprite il servizio di Penetration Test


    Dichiaro di aver letto e compreso l'Informativa sul trattamento dei dati