Quando si parla di sicurezza di un server, prima o poi compare una domanda:
Quali porte sono aperte?
È una domanda utile, ma da sola non racconta tutta la storia.
Una porta aperta non è necessariamente una vulnerabilità.
La cosa davvero importante è capire quale servizio sta ascoltando, perché è esposto e se dovrebbe essere raggiungibile da Internet.
Un server web, per esempio, deve normalmente esporre una porta per permettere agli utenti di raggiungere il sito.
Un database, invece, potrebbe non avere alcun motivo per essere direttamente accessibile da Internet.
La differenza sta nel contesto.
Cosa significa "porta aperta"?
Un server può utilizzare diverse porte per comunicare attraverso la rete.
Per esempio:
80 → HTTP
443 → HTTPS
22 → SSH
25 → SMTP
53 → DNS
3306 → MySQL
5432 → PostgreSQL
Questi numeri identificano le porte.
Quando diciamo che una porta è "aperta", in termini molto semplici significa che un servizio è raggiungibile attraverso quella porta e sta accettando connessioni secondo le regole configurate.
Una porta aperta è una vulnerabilità?
No.
È una delle distinzioni più importanti da fare.
Per esempio:
443/tcp → HTTPS
su un sito web pubblico è assolutamente normale.
Il sito deve essere raggiungibile.
Il problema sarebbe eventualmente un'altra cosa:
- software vulnerabile;
- configurazione errata;
- autenticazione debole;
- servizio non necessario;
- versione obsoleta;
- esposizione non prevista.
Per questo un buon controllo non dovrebbe limitarsi a dire:
"Hai 5 porte aperte."
Dovrebbe spiegare che cosa rappresentano quelle porte.
Il servizio conta più del numero
Immaginiamo questo server:
443/tcp → HTTPS
22/tcp → SSH
3306/tcp → MySQL
La porta 443 è probabilmente necessaria.
La porta 22 può essere ragionevole, ma va valutata in base a come viene utilizzata e a chi deve poter accedere.
La porta 3306, invece, potrebbe meritare una verifica particolare se il database non dovrebbe essere direttamente esposto.
Il numero della porta, quindi, è solo l'inizio dell'analisi.
Servizi pubblici e servizi interni
Una buona domanda da porsi è:
Questo servizio deve essere raggiungibile da qualsiasi punto di Internet?
Prendiamo un database.
Un'applicazione web potrebbe avere:
Internet
↓
HTTPS
↓
Web Server
↓
Application
↓
Database
Il database non deve necessariamente essere esposto direttamente.
Un'architettura del genere:
Internet
↓
Web Server
↓
Database
può avere senso perché il database viene utilizzato dall'applicazione, non direttamente dagli utenti Internet.
Naturalmente ogni infrastruttura è diversa, ma il principio è importante:
un servizio dovrebbe essere esposto solo quando esiste una ragione per farlo.
Porte non standard
Non tutti i servizi utilizzano necessariamente la porta tradizionale.
Per esempio, un pannello amministrativo potrebbe essere raggiungibile attraverso:
8443
8080
8000
9000
Quindi controllare soltanto le porte più conosciute può non essere sufficiente per comprendere completamente la superficie di un server.
OWASP include proprio l'analisi delle porte non standard tra le attività di identificazione della superficie di attacco.
Un esempio concreto
Immaginiamo di trovare:
203.0.113.10
80/tcp
443/tcp
8080/tcp
Potremmo avere:
80 → HTTP
443 → HTTPS
8080 → applicazione web
Il server potrebbe utilizzare 8080 intenzionalmente.
Oppure potrebbe essere una vecchia applicazione di test.
Oppure un pannello amministrativo.
Senza identificare il servizio non possiamo sapere quale delle tre situazioni sia corretta.
Cosa bisogna controllare?
Quando viene individuata una porta pubblica, è utile porsi almeno queste domande:
1. Quale servizio risponde?
2. Quale software utilizza?
3. Quale versione?
4. Perché è pubblico?
5. Chi dovrebbe poter accedere?
6. È ancora necessario?
7. È correttamente configurato?
8. Esistono vulnerabilità note?
Queste domande trasformano una semplice scansione delle porte in un'analisi molto più utile.
Il caso SSH
SSH è un buon esempio.
Una porta:
22/tcp
aperta su un server amministrato da remoto può essere perfettamente normale.
Ma potrebbe essere utile verificare:
- chi può effettuare il login;
- se viene utilizzata autenticazione tramite chiavi;
- se l'accesso root diretto è consentito;
- se il servizio è aggiornato;
- se esistono limitazioni sull'accesso;
- se l'esposizione pubblica è realmente necessaria.
In alcuni ambienti può avere senso limitare l'accesso SSH a specifici indirizzi IP o utilizzare una VPN.
Il punto non è quindi:
"SSH aperto = vulnerabilità."
Il punto è:
"SSH è esposto: è una scelta intenzionale e adeguatamente protetta?"
Il caso dei database
Un database è un altro esempio interessante.
Potremmo trovare:
3306/tcp → MySQL
5432/tcp → PostgreSQL
Questo non significa automaticamente che sia possibile accedere ai dati.
Potrebbero esserci autenticazione, firewall, ACL o altre protezioni.
Ma un database direttamente esposto verso Internet merita sicuramente una verifica.
In molte architetture non è necessario renderlo pubblicamente raggiungibile.
La soluzione migliore può essere semplicemente non esporlo.
Porte aperte e firewall
Il firewall svolge un ruolo importante nel controllo dell'esposizione.
Un server può avere un servizio in ascolto, ma impedire le connessioni provenienti da Internet attraverso regole firewall.
Possiamo quindi distinguere tra:
Servizio in ascolto
↓
Porta raggiungibile internamente
e:
Servizio in ascolto
↓
Firewall
↓
Porta pubblicamente raggiungibile
Dal punto di vista della superficie esterna, è la seconda situazione quella particolarmente interessante.
Perché è utile controllare periodicamente le porte?
Perché l'infrastruttura cambia.
Un amministratore può installare un nuovo servizio:
Nuova applicazione
↓
Nuova porta
↓
Nuova esposizione
Oppure può disinstallarlo senza rimuovere correttamente una configurazione.
Anche le migrazioni possono lasciare vecchi servizi attivi.
Per questo CISA raccomanda pratiche di asset discovery continuo e validazione degli asset internet-facing, proprio per mantenere una visione aggiornata di sistemi e servizi esposti.
Da porta a vulnerabilità
Una possibile sequenza di analisi è:
443/tcp
↓
HTTPS
↓
Nginx
↓
Versione
↓
Configurazione
↓
Vulnerabilità note
Oppure:
3306/tcp
↓
MySQL
↓
Versione
↓
Accessibilità
↓
Configurazione
↓
Vulnerabilità note
Questo dimostra ancora una volta perché il numero della porta da solo non è sufficiente.
Quando una porta aperta diventa interessante?
Possiamo pensare a tre casi differenti.
1. Servizio previsto
443/tcp → HTTPS
Il servizio è necessario e correttamente configurato.
Non c'è necessariamente un problema.
2. Servizio previsto ma da verificare
22/tcp → SSH
Il servizio è necessario, ma è opportuno verificare configurazione e accessi.
3. Servizio inatteso
8080/tcp → vecchia applicazione
Nessuno sa perché sia pubblico.
In questo caso l'asset merita un'indagine.
La differenza tra questi tre casi è molto più utile di un semplice elenco di porte.
Non tutti i risultati hanno la stessa priorità
Immaginiamo di trovare:
443/tcp → HTTPS
22/tcp → SSH
8080/tcp → applicazione sconosciuta
3306/tcp → MySQL
Non avrebbe molto senso considerare automaticamente tutti e quattro i risultati equivalenti.
Il contesto potrebbe suggerire priorità differenti.
Per esempio, un database pubblico e non previsto potrebbe meritare una verifica immediata, mentre la porta HTTPS del sito principale è semplicemente parte del normale funzionamento del servizio.
La sicurezza richiede quindi contesto e prioritizzazione, non soltanto discovery.
Una checklist per i servizi esposti
[ ] Quali porte sono raggiungibili?
[ ] Quali servizi rispondono?
[ ] Quali versioni utilizzano?
[ ] Il servizio deve essere pubblico?
[ ] Chi dovrebbe poter accedere?
[ ] Esistono controlli di accesso?
[ ] Esistono servizi legacy?
[ ] Esistono porte non standard?
[ ] Sono presenti database esposti?
[ ] Sono presenti pannelli amministrativi?
[ ] Esistono vulnerabilità note?
[ ] Ci sono servizi che possono essere rimossi?
La domanda più importante
Quando trovi una porta aperta, non fermarti al numero.
Chiediti:
"Perché questo servizio è raggiungibile da Internet?"
Se conosci la risposta, hai già una parte importante del contesto.
Se invece nessuno sa perché quella porta sia aperta, hai appena trovato qualcosa che vale la pena approfondire.
Conclusione
Una porta aperta non è automaticamente una vulnerabilità.
È un'indicazione che qualcosa è raggiungibile.
La vera analisi comincia dopo:
Porta
↓
Servizio
↓
Tecnologia
↓
Configurazione
↓
Necessità dell'esposizione
↓
Vulnerabilità
Conoscere quali servizi sono realmente esposti permette di costruire una visione più accurata della superficie di attacco e di concentrarsi sugli elementi che meritano davvero attenzione.
Controlla i servizi esposti con MiHakero
MiHakero analizza la superficie pubblica di domini, applicazioni web, API e servizi per aiutarti a individuare esposizioni inattese e configurazioni che meritano una verifica.
Perché sapere che una porta è aperta è utile.
Ma sapere perché è aperta e cosa c'è dietro è molto più utile.