Una regola del firewall descrive ciò che dovrebbe essere consentito; una connessione dall’esterno verifica che cosa risponde davvero. Su un server con un IPv4 pubblico, puoi avviare questa verifica con curl -4 https://qsa.sh: qsa.sh rileva l’IP di origine della richiesta e analizza quell’indirizzo dalla propria infrastruttura.
La scansione gratuita copre le 1.000 porte TCP principali, identifica servizi e versioni sulle porte aperte ed esegue controlli delle vulnerabilità. Non installa un agente né richiede l’installazione di strumenti sul server. Il risultato è una prima valutazione dell’esposizione, non un audit completo: confronta i risultati con le regole di rete e con ciò che il server è in ascolto localmente.
1. Esegui il comando dal server
Connettiti alla macchina che vuoi controllare ed esegui:
# Fuerza IPv4 para que qsa.sh acepte la conexión
curl -4 https://qsa.shL’opzione -4 forza l’uso di IPv4. È necessaria se il server ha anche IPv6: al momento qsa.sh rifiuta le connessioni con origine IPv6. Il prefisso https:// cifra la richiesta; funziona anche la variante HTTP, ma questo tutorial usa HTTPS.
Prima di inviare pacchetti, lo strumento mostra l’IP rilevato e avvia un conto alla rovescia di 15 secondi per annullare. Verifica che l’indirizzo corrisponda all’origine che intendi controllare. Se non è quello corretto o non hai l’autorizzazione per analizzarlo, premi Ctrl-C: la scansione non verrà avviata.
Il flusso è semplice: la richiesta parte dal server, qsa.sh identifica il suo IP pubblico e i propri nodi di scansione verificano quell’indirizzo dall’esterno. I risultati tornano nel terminale. Non è necessario inserire un IP di destinazione: viene analizzato l’indirizzo da cui arriva la richiesta.
flowchart LR
A["Servidor"] --> B["Petición curl por IPv4"]
B --> C["qsa.sh detecta la IP"]
C --> D["Cuenta atrás de 15 segundos"]
D --> E["Escaneo externo autorizado"]
E --> F["Resultados en la terminal"]2. Salva una copia leggibile del risultato
L’output predefinito può includere colori. Per salvarlo in un file di testo, richiedi un output senza colori e inoltralo a tee:
# Guarda la salida en un archivo fechado y también la muestra en pantalla
curl -4 -sN "https://qsa.sh/?nocolor=1" | tee "exposure-$(date +%F).txt"-sN attiva la modalità silenziosa di curl e disabilita il buffering dell’output, così i risultati trasmessi possono essere visualizzati man mano che arrivano. Il parametro nocolor=1 evita i codici colore nel file. La documentazione di qsa.sh indica che i risultati della scansione gratuita vengono trasmessi e non salvati nei suoi sistemi; questo comando crea una copia locale sotto il tuo controllo.
3. Scopri che cosa copre la scansione
L’output gratuito raccoglie tre tipi di risultati. Per prima cosa vengono elencate le porte TCP che hanno accettato una connessione dalla rete di scansione. Poi nmap prova a identificare il servizio e la relativa versione, mentre lo script vulners cerca corrispondenze con CVE note sulla base della stringa della versione. Infine, nuclei controlla esposizioni e configurazioni, come i percorsi .env o .git, le credenziali predefinite e i problemi TLS.
Quando leggi i risultati, tieni presenti due limiti. La scansione gratuita verifica le 1.000 porte TCP principali, non tutte le 65.535; per questo motivo un servizio su una porta esclusa da questa selezione non comparirà. Inoltre, una corrispondenza con una CVE basata sulla versione rilevata è un indizio da verificare, non la conferma che il pacchetto installato sia vulnerabile: prima di pianificare un aggiornamento, controlla la versione corretta nel bollettino di sicurezza della tua distribuzione.
Lo strumento mostra le porte, le versioni rilevate, un conteggio per gravità e i tre risultati principali per esteso. Se devi coprire tutte le porte, qsa.sh offre opzioni a pagamento con coperture diverse; non sono necessarie per la verifica iniziale descritta in questo tutorial.
4. Confronta il risultato con i socket locali
Sullo stesso server, esegui ss per visualizzare i socket TCP in ascolto:
# Muestra sockets TCP en escucha y el proceso asociado
sudo ss -tlnpL’elenco locale e la scansione esterna rispondono a domande diverse. ss indica che cosa è in ascolto sulla macchina; la scansione indica quali porte TCP hanno accettato connessioni dalla rete esterna di qsa.sh. Un socket associato a 0.0.0.0, [::] o * è in ascolto su tutte le interfacce, ma sono le regole di rete e dell’host a determinare se il traffico dall’esterno può raggiungerlo.
Segna ogni porta aperta che non ti aspettavi di esporre e controlla quale servizio la occupa. Se una regola del provider sembra consentirla o bloccarla diversamente, verifica anche dove è applicata e quali altre regole agiscono sulla risorsa. Per esempio, in AWS le regole dei gruppi di sicurezza associati si sommano; una vecchia regola che consente la porta può continuare ad avere effetto finché quel gruppo rimane associato.
5. Se necessario, ripeti la verifica da un’altra macchina
qsa.sh analizza esclusivamente l’IP da cui riceve la richiesta. Non consente di specificare un altro indirizzo, controllare separatamente un bilanciatore di carico o verificare l’IPv6 di un server. In questi casi, l’articolo di qsa.sh propone di eseguire gli strumenti open source da una macchina esterna alla rete del server e di analizzare solo gli indirizzi che si è autorizzati a verificare.
Su Debian o Ubuntu, installa le dipendenze indicate e gli strumenti:
# Instala nmap y la dependencia libpcap
sudo apt install -y nmap libpcap-dev
# Instala naabu y nuclei con Go
go install -v github.com/projectdiscovery/naabu/v2/cmd/naabu@latest
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
# Actualiza las plantillas de nuclei
nuclei -update-templatesIl comando di installazione di Go presuppone che Go sia disponibile e che i binari installati si trovino nel tuo PATH. Nel blocco precedente, rimuovi lo spazio iniziale prima di go install se il terminale lo interpreta come parte del comando.
Dalla macchina esterna, sostituisci l’indirizzo di esempio con l’IPv4 pubblico che sei autorizzato a controllare. I tre comandi riproducono le fasi di individuazione delle porte, identificazione del servizio e controlli di nuclei:
# Sustituye esta dirección de ejemplo por la IPv4 autorizada
TARGET=203.0.113.10
# Descubre los 1.000 puertos TCP principales
naabu -host "$TARGET" -top-ports 1000 -silent -o ports.txt
# Identifica los servicios y consulta coincidencias de CVE
nmap -Pn -sV --script vulners -p "$(cut -d: -f2 ports.txt | paste -sd, -)" "$TARGET"
# Ejecuta nuclei sobre los hosts y puertos encontrados
nuclei -l ports.txt -s critical,high,mediumL’indirizzo 203.0.113.10 è un valore di esempio: modificalo prima di eseguire il blocco. Per provare tutte le porte TCP con naabu, la guida di qsa.sh indica di sostituire -top-ports 1000 con -p -. Lo strumento può usare una scansione SYN con privilegi di root e una scansione CONNECT senza privilegi.
Errori frequenti nell’interpretazione dei risultati
L’IP rilevato è un gateway NAT. Se il server accede a Internet tramite un gateway NAT, qsa.sh vede l’indirizzo pubblico di quel gateway. In AWS, le istanze dietro un gateway NAT pubblico non ricevono connessioni in ingresso non richieste da Internet. Di conseguenza, l’analisi di quell’IP descrive il gateway, non necessariamente l’esposizione in ingresso dell’istanza. Prima individua l’indirizzo che riceve le connessioni che vuoi controllare.
Il server è in ascolto, ma la porta non compare. Questo non dimostra di per sé che non esista un servizio: lo strumento gratuito copre le 1.000 porte TCP principali e le regole di accesso possono limitare chi riesce a raggiungere la porta. Possono inoltre intervenire regole dell’host, gruppi o firewall associati alla risorsa e porte pubblicate dai container. La discrepanza è un segnale che invita a controllare questi livelli, non un motivo per presumere che una delle due viste sia errata.
Hai controllato IPv4, non IPv6. Le regole per IPv4 e IPv6 possono essere diverse; qsa.sh controlla solo IPv4. Per verificare IPv6, individua l’indirizzo globale del server e prova da un’altra macchina con connettività IPv6. Un server chiuso su IPv4 potrebbe avere un’esposizione diversa su IPv6.
Il servizio si trova dietro un bilanciatore di carico. Una scansione avviata dall’istanza controlla il suo indirizzo, non l’indirizzo pubblico del bilanciatore. Controlla quest’ultimo separatamente da un’altra macchina. Allo stesso modo, se una porta è accessibile solo dall’ufficio o dalla VPN, potrebbe non comparire dalla rete di scansione di qsa.sh: è il comportamento previsto per una restrizione basata sull’origine.
Dopo aver trovato una porta inattesa
Decidi se il servizio deve essere pubblico. In caso contrario, la guida di qsa.sh consiglia di chiudere l’accesso nel firewall cloud e in quello dell’host e di associare il servizio a 127.0.0.1 o a un’interfaccia privata. Per un database o una cache, valuta la rimozione della regola pubblica e l’accesso tramite rete privata, VPN o tunnel SSH; se la porta è pubblicata da un container, controlla anche la relativa mappatura.
Applica la modifica e ripeti la scansione. Confronta nuovamente le porte esterne con i socket locali e le regole che ti aspettavi fossero attive. Il controllo successivo è semplice e concreto: verificare che la porta che hai deciso di chiudere non accetti più connessioni dall’esterno.
Fonti: DEV Community, qsa.sh, qsa.sh, Amazon Web Services
