Servizio esposto: dal socket Linux alla ACL di rete

Un servizio raggiungibile dipende da più livelli: il processo deve essere attivo, il socket deve ascoltare sull’indirizzo previsto, i filtri host e di rete devono consentire il traffico e deve esistere un percorso di routing valido. Questo scenario unisce Linux+, CCNA e CEH per diagnosticare il problema senza modifiche affrettate.

Lo scenario

Un’applicazione web di test risponde sul server con curl http://127.0.0.1:8080, ma un client della rete amministrativa non riesce a collegarsi. La tentazione è aprire subito una porta nel firewall. Prima serve però stabilire dove si interrompe il percorso.

1. Il processo è in esecuzione?
2. Esiste un socket in ascolto?
3. Su quale indirizzo e famiglia IP è vincolato?
4. Il firewall del server consente il traffico?
5. Una ACL o un altro controllo di rete lo blocca?
6. Routing di andata e ritorno sono corretti?

Linux+: osservare il socket con ss

sudo ss -lntup

Un risultato con 127.0.0.1:8080 descrive un socket IPv4 vincolato al loopback. Un risultato con 0.0.0.0:8080 indica invece tutte le interfacce IPv4 idonee. Questo aumenta la superficie raggiungibile, ma non dimostra che il traffico remoto superi firewall, ACL e routing.

sudo ss -lntp 'sport = :8080'

Il filtro limita l’output alla porta interessata. L’assenza di risultati può significare che il processo non ascolta, usa un’altra porta o famiglia, oppure si è terminato.

CEH: interpretare open, closed e filtered

In una verifica autorizzata, uno scanner descrive ciò che riesce a inferire dalle risposte. Open indica che un’applicazione risponde sulla porta; closed che l’host è raggiungibile ma non risulta un servizio disponibile; filtered che un filtro impedisce una determinazione affidabile.

Filtered non prova quale dispositivo stia filtrando. La causa può trovarsi sul server, su un firewall intermedio o in una ACL. Correlare la scansione con ss, log e configurazione evita di trasformare una singola osservazione in una conclusione.

CCNA: perché serve una ACL estesa

Una ACL standard distingue principalmente la sorgente. Per controllare una combinazione come “host sorgente, server destinazione, TCP e porta 22” serve una ACL estesa. Un esempio concettuale, da non applicare senza conoscere interfaccia e direzione, è:

deny tcp host 192.0.2.25 host 198.51.100.10 eq 22
permit ip any any

Gli indirizzi appartengono agli intervalli di documentazione. L’ultima regola ricorda che una ACL termina normalmente con un deny implicito: omettere il traffico legittimo può produrre un’interruzione. Posizione, direzione e impatto vanno verificati nel laboratorio della piattaforma specifica.

Mini-lab locale e sicuro

Nel primo terminale avvia un servizio temporaneo soltanto sul loopback:

python3 -m http.server 8080 --bind 127.0.0.1

Nel secondo terminale osserva socket e risposta:

ss -lntp 'sport = :8080'
curl -I http://127.0.0.1:8080

Il risultato atteso è un socket su 127.0.0.1:8080 e una risposta HTTP locale. Il nome del processo può richiedere privilegi aggiuntivi. Termina il server con Ctrl + C e ripeti ss: il socket non deve più apparire.

Metodo di diagnosi

1. Osserva il processo e il bind senza modificare nulla.
2. Verifica localmente il servizio.
3. Controlla firewall host, ACL e routing nel perimetro autorizzato.
4. Proponi la modifica minima e definisci prima il rollback.
5. Ripeti i test locali e remoti e conserva le evidenze essenziali.

Errori comuni

• Aprire il firewall quando il servizio ascolta soltanto sul loopback.
• Confondere una porta filtered con la prova che il servizio sia spento.
• Applicare una ACL senza considerare direzione e deny implicito.
• Vincolare il servizio a tutte le interfacce soltanto per far riuscire un test.
• Dimenticare il percorso di ritorno o la famiglia IPv6.

Fonti essenziali

Fonti primarie verificate il 12 ottobre 2026.

• Linux man-pages — ss(8)
• Cisco — ACLs Configuration Guide
• Nmap — Port Scanning Basics