"Ho trovato una porta aperta."
È una frase che, nel mondo della sicurezza informatica, può sembrare immediatamente preoccupante.
In realtà, una porta aperta non è automaticamente una vulnerabilità.
Un server web, per esempio, normalmente deve avere almeno una porta accessibile per permettere agli utenti di collegarsi.
Il vero problema è capire quale servizio sta ascoltando, perché è esposto e se dovrebbe esserlo.
Cosa significa "porta aperta"?
Un server può mettere a disposizione diversi servizi attraverso porte differenti.
Per esempio:
80 → HTTP
443 → HTTPS
22 → SSH
25 → SMTP
3306 → MySQL/MariaDB
5432 → PostgreSQL
6379 → Redis
Questa associazione è solo indicativa: una porta può essere utilizzata da servizi diversi e un servizio può essere configurato su una porta non standard.
Quando diciamo che una porta è "aperta", stiamo sostanzialmente dicendo che un servizio è raggiungibile attraverso quella porta.
Una porta aperta è sempre un problema?
No.
Pensiamo a un normale sito web:
443/tcp
Se il sito deve essere raggiungibile via HTTPS, questa porta deve essere accessibile.
Chiuderla significherebbe impedire il normale funzionamento del sito.
La domanda corretta è quindi:
"Questa porta deve essere accessibile da Internet?"
Il problema dei servizi infrastrutturali
La situazione cambia quando troviamo servizi che normalmente non hanno bisogno di essere pubblicamente raggiungibili.
Per esempio:
3306 → database
5432 → database
6379 → cache
9200 → servizio di ricerca
Non significa automaticamente che siano vulnerabili.
Ma un servizio infrastrutturale esposto direttamente su Internet merita quasi sempre una verifica.
In molti casi dovrebbe essere accessibile soltanto:
Internet
↓
Web server
↓
Rete interna
↓
Database
e non:
Internet
↓
Database
Il principio del minimo accesso
Una buona configurazione cerca di esporre soltanto ciò che è necessario.
Se un servizio deve essere utilizzato esclusivamente dall'applicazione web, non c'è generalmente motivo per renderlo direttamente accessibile a tutta Internet.
Il concetto è semplice:
meno servizi esposti inutilmente = meno superficie da proteggere.
Porte non standard
Un errore comune è pensare che utilizzare una porta diversa da quella normalmente associata a un servizio renda il sistema sicuro.
Per esempio:
SSH → 2222
invece della porta normalmente utilizzata:
SSH → 22
Cambiare porta può ridurre parte del rumore generato da scansioni automatiche, ma non sostituisce:
- autenticazione robusta;
- aggiornamenti;
- firewall;
- limitazione degli accessi;
- monitoraggio.
Una porta "nascosta" non è una porta sicura per definizione.
Come verificare una porta?
In un sistema che si è autorizzati a controllare, uno strumento semplice può essere:
nc -zv example.com 443
Per verificare una porta specifica:
nc -zv example.com 3306
Questi controlli servono a capire se una porta risponde.
Non dimostrano che il servizio sia vulnerabile.
Per una valutazione completa bisogna capire cosa c'è dietro quella porta e come è configurato.
Una porta può essere aperta ma filtrata
Anche il concetto di "porta aperta" non è sempre così semplice.
Un firewall può:
- permettere l'accesso da determinati indirizzi;
- bloccare altri;
- limitare il traffico;
- applicare regole differenti a seconda della rete.
Per esempio:
Internet → blocco
VPN → accesso
In questo caso il servizio potrebbe essere attivo ma non realmente esposto all'intera Internet.
È una distinzione importante quando si interpretano i risultati di una scansione.
Il contesto conta
Immaginiamo questi due risultati:
443/tcp → HTTPS
e:
3306/tcp → database
Non possiamo dire semplicemente:
"Il primo è sicuro e il secondo è vulnerabile."
Il primo potrebbe avere una grave vulnerabilità applicativa.
Il secondo potrebbe essere intenzionalmente esposto e adeguatamente protetto.
La porta ci fornisce un'indicazione, non il verdetto finale.
Servizi obsoleti
Un'altra situazione da tenere sotto controllo riguarda i servizi legacy.
Per esempio:
22 → SSH
80 → HTTP
443 → HTTPS
8080 → vecchia applicazione
Se 8080 appartiene a un'applicazione che non viene più utilizzata, è un candidato ideale per una verifica.
Un servizio non necessario non dovrebbe rimanere esposto semplicemente perché "funziona ancora".
Porte aperte e inventario
Una buona pratica consiste nel confrontare ciò che dovrebbe essere esposto con ciò che è effettivamente osservabile.
Per esempio:
| Porta | Servizio | Necessaria | Proprietario | Azione | | ----- | -------- | ---------- | ------------ | ------------------ | | 443 | HTTPS | Sì | Web | Mantenere | | 22 | SSH | Sì | IT | Limitare accesso | | 3306 | Database | No | IT | Verificare | | 8080 | Legacy | No | — | Valutare rimozione |
Questo è molto più utile del semplice elenco delle porte.
La domanda giusta
Una scansione può dirti:
"3306 è raggiungibile."
La gestione della sicurezza deve trasformarlo in:
"3306 è raggiungibile,
appartiene al database X,
non dovrebbe essere pubblico,
il team IT ne è responsabile."
A quel punto hai un'informazione realmente utile.
In sintesi
Una porta aperta non è automaticamente una vulnerabilità.
Può essere:
- necessaria;
- intenzionale;
- limitata a determinate reti;
- protetta correttamente.
Diventa interessante quando:
- il servizio non dovrebbe essere pubblico;
- nessuno sa perché sia esposto;
- appartiene a un sistema legacy;
- utilizza software obsoleto;
- espone un componente infrastrutturale direttamente a Internet.
La sicurezza non consiste quindi nel chiudere tutte le porte.
Consiste nel sapere perché ogni porta è aperta.
MiHakero può aiutare a individuare i servizi pubblicamente raggiungibili e a trasformare un semplice elenco di porte e servizi in una visione più utile della superficie esposta.