Hai un sito online e sai perfettamente qual è il suo dominio.
Ma sai anche quali altri servizi sono raggiungibili da Internet?
Potrebbero esserci un'API, un pannello amministrativo, un vecchio sottodominio, un ambiente di staging o un server che nessuno ricorda più di avere.
È una situazione più comune di quanto sembri.
Per questo, quando si parla di sicurezza esterna, una delle prime attività da fare è capire che cosa è realmente visibile e raggiungibile da Internet.
Partire dal dominio non basta
Supponiamo di avere:
example.com
Visitando il sito vediamo una normale homepage.
Potremmo quindi pensare che sia tutto qui.
In realtà potrebbero esistere:
api.example.com
app.example.com
admin.example.com
staging.example.com
dev.example.com
old.example.com
Alcuni potrebbero essere fondamentali.
Altri potrebbero essere stati creati anni fa.
Altri ancora potrebbero essere stati pensati per essere temporanei.
Il primo passo consiste quindi nel costruire un quadro più completo possibile degli asset pubblici.
1. Cercare i sottodomini
I sottodomini sono spesso il primo elemento da controllare.
Possono essere utilizzati per scopi molto diversi:
www.example.com
api.example.com
app.example.com
mail.example.com
staging.example.com
dev.example.com
Non è possibile stabilire dal solo nome se un sottodominio rappresenti un rischio.
Per esempio, api.example.com potrebbe essere assolutamente necessario.
staging.example.com, invece, potrebbe essere un ambiente di test che non dovrebbe più essere accessibile pubblicamente.
La cosa importante è sapere che esiste.
2. Controllare gli indirizzi IP
Un dominio può puntare a uno o più indirizzi IP.
Questo può aiutare a capire come è distribuito il servizio e quali infrastrutture sono esposte.
Un esempio molto semplificato potrebbe essere:
example.com
↓
203.0.113.10
api.example.com
↓
203.0.113.20
In una realtà più complessa potrebbero esserci molti più asset.
Anche qui, l'indirizzo IP pubblico non è di per sé un problema: è semplicemente una parte dell'infrastruttura che deve essere conosciuta e gestita.
3. Verificare le porte esposte
Una volta individuato un host, è possibile verificare quali servizi risultano raggiungibili.
Per esempio:
80/tcp
443/tcp
22/tcp
Potremmo avere:
80/tcp → HTTP
443/tcp → HTTPS
22/tcp → SSH
La presenza della porta 443 è perfettamente normale per un sito HTTPS.
La porta 22, invece, può meritare una valutazione diversa a seconda del contesto.
La domanda non dovrebbe essere:
"La porta è aperta?"
ma:
"Perché questo servizio è raggiungibile pubblicamente?"
4. Capire cosa c'è dietro una porta
Una porta aperta ci dice che qualcosa sta rispondendo.
Il passo successivo è capire cosa.
Potremmo trovare un web server, un servizio SSH, un database o un altro servizio di rete.
L'identificazione della tecnologia permette poi di fare controlli più specifici.
Per esempio:
443/tcp
↓
HTTPS
↓
Nginx
↓
Applicazione PHP
Questa informazione è molto più utile del semplice fatto che "la porta 443 è aperta".
5. Cercare applicazioni web
Un'organizzazione può avere più applicazioni pubbliche.
Ad esempio:
example.com
portal.example.com
app.example.com
admin.example.com
Non tutte saranno necessariamente collegate dalla homepage.
Un vecchio portale può continuare a rispondere anche se nessuno lo utilizza più.
Un pannello amministrativo potrebbe essere raggiungibile direttamente.
Un'applicazione di test potrebbe essere rimasta online.
Questi sono esempi di situazioni che vale la pena conoscere.
6. Controllare le API
Le API sono diventate una parte fondamentale delle applicazioni moderne.
Un sito può utilizzare decine o centinaia di endpoint API senza che questi siano immediatamente visibili all'utente.
Per esempio:
/api/login
/api/users
/api/products
/api/orders
Un endpoint pubblico non è necessariamente un problema.
Molte API sono progettate proprio per essere raggiungibili da Internet.
Bisogna però capire:
- cosa fa l'endpoint;
- se richiede autenticazione;
- quali dati restituisce;
- chi dovrebbe poterlo utilizzare;
- se esistono versioni obsolete;
- se la documentazione è esposta intenzionalmente.
7. Attenzione agli ambienti di staging
Questa è una delle situazioni che personalmente controllerei sempre.
Potremmo avere:
www.example.com
staging.example.com
Il primo è il sito di produzione.
Il secondo è utilizzato per i test.
Fin qui tutto normale.
Il problema può nascere quando lo staging viene dimenticato oppure lasciato accessibile senza le stesse attenzioni dedicate alla produzione.
Un ambiente di test potrebbe contenere:
- funzionalità non definitive;
- debug attivo;
- software meno aggiornato;
- dati di test;
- configurazioni temporanee.
Non significa che uno staging pubblico sia automaticamente vulnerabile.
Significa che deve essere una scelta consapevole.
8. Guardare le informazioni tecniche
Un'applicazione può rivelare informazioni sulla propria tecnologia attraverso le risposte HTTP, il codice HTML o altri elementi pubblicamente accessibili.
Ad esempio:
Server: nginx
X-Powered-By: PHP
Oppure possono essere riconoscibili framework, CMS e altre tecnologie.
Queste informazioni possono essere utili durante l'analisi perché permettono di collegare un servizio a specifici software e, successivamente, verificare eventuali problemi noti.
9. Cercare configurazioni che meritano attenzione
Non tutto quello che troviamo durante una scansione è una vulnerabilità.
Alcuni risultati sono semplicemente segnali che meritano una verifica.
Per esempio:
- un security header mancante;
- directory listing attivo;
- informazioni tecniche eccessive;
- un endpoint diagnostico;
- un pannello pubblico;
- una configurazione di debug;
- un certificato da verificare.
Questa distinzione è importante.
Un buon sistema di sicurezza non dovrebbe generare allarmi indiscriminati, ma aiutare a capire quali risultati sono realmente rilevanti.
10. Verificare le vulnerabilità note
Dopo aver identificato software e versioni è possibile verificare la presenza di vulnerabilità note.
Qui entrano in gioco concetti come:
CVE, CVSS, security advisory e cataloghi di vulnerabilità.
Per esempio, se un servizio utilizza una versione specifica di un software, è possibile verificare se quella versione è associata a vulnerabilità conosciute.
Ma anche in questo caso bisogna fare attenzione alle conclusioni.
La presenza di una CVE associata a una versione non equivale automaticamente alla compromissione del sistema.
È un'indicazione che richiede una valutazione nel contesto reale.
Un modo semplice per ragionare sulla superficie
Possiamo riassumere l'intero processo così:
DOMINIO
↓
SOTTODOMINI
↓
IP
↓
PORTE
↓
SERVIZI
↓
APPLICAZIONI / API
↓
TECNOLOGIE
↓
CONFIGURAZIONI
↓
VULNERABILITÀ NOTE
Ogni livello aggiunge un pezzo del puzzle.
Il risultato finale non dovrebbe essere semplicemente una lista di problemi.
Dovrebbe essere una fotografia comprensibile di ciò che l'organizzazione espone verso Internet.
E se trovo qualcosa che non riconosco?
È probabilmente la domanda più interessante.
Supponiamo di trovare:
old-api.example.com
e nessuno sappia cosa sia.
Non conviene concludere immediatamente che sia una vulnerabilità.
Prima bisogna capire:
- chi lo gestisce;
- a cosa serve;
- perché è pubblico;
- quale software utilizza;
- se è ancora necessario;
- se contiene dati;
- se presenta vulnerabilità o configurazioni problematiche.
Potrebbe essere un servizio legittimo.
Potrebbe essere un vecchio progetto.
Potrebbe essere un ambiente dimenticato.
Il punto è che adesso sappiamo che esiste.
La parte più importante: cosa affrontare per primo?
Scoprire 20 risultati non significa necessariamente doverne correggere 20 contemporaneamente.
Un servizio pubblico intenzionale e aggiornato potrebbe richiedere meno attenzione di un vecchio ambiente di staging che utilizza software obsoleto.
Per questo, dopo la fase di discovery, diventa importante la prioritizzazione.
Bisogna considerare almeno:
- natura dell'asset;
- esposizione;
- tecnologia utilizzata;
- presenza di vulnerabilità note;
- configurazione;
- importanza del servizio;
- possibilità di ridurre l'esposizione.
La sicurezza non consiste soltanto nel trovare problemi.
Consiste anche nel capire quali problemi meritano di essere affrontati per primi.
Una checklist pratica
Se vuoi fare un primo controllo della superficie esterna di un dominio:
[ ] Dominio principale
[ ] Sottodomini
[ ] Indirizzi IP
[ ] Porte pubbliche
[ ] Servizi esposti
[ ] Applicazioni web
[ ] API
[ ] Ambienti di staging
[ ] Ambienti di sviluppo
[ ] Pannelli amministrativi
[ ] Tecnologie utilizzate
[ ] Configurazioni da verificare
[ ] Vulnerabilità note
[ ] Asset sconosciuti
[ ] Asset non più necessari
Questo elenco non sostituisce un security assessment completo, ma rappresenta un buon punto di partenza per capire cosa c'è realmente dall'altra parte della connessione.
Conclusione
Quando si parla di sicurezza esterna, la prima domanda non dovrebbe essere necessariamente:
"Quali vulnerabilità ho?"
Prima ancora conviene chiedersi:
"Cosa ho effettivamente esposto?"
Domini, sottodomini, server, porte, applicazioni, API e servizi possono creare una superficie molto più ampia di quella che immaginiamo.
Una volta conosciuta questa superficie, diventa molto più semplice capire quali elementi sono normali, quali richiedono una verifica e quali potrebbero rappresentare un rischio concreto.
Ed è proprio questo il punto di partenza dell'Attack Surface Management.
Controlla la tua esposizione con MiHakero
MiHakero analizza ciò che è pubblicamente raggiungibile da un dominio, comprese applicazioni web, API e servizi, per individuare esposizioni inattese, configurazioni da verificare e vulnerabilità note rilevabili dall'esterno.