Product SiteDocumentation Site

10.9. Strumenti di diagnosi di rete

Quando un'applicazione di rete non funziona come previsto, è importante poter vedere "sotto il cofano". Anche quando tutto sembra funzionare senza problemi, l'esecuzione di una diagnosi di rete può contribuire a garantire che tutto funzioni come dovrebbe. Esistono diversi strumenti di diagnosi per tale scopo; ognuno opera su un livello diverso. La discussione di tutti gli strumenti è oltre lo scopo di questo libro, così, nelle sezioni successive, ci si focalizzerà sullo strumento più conosciuto e comunemente usato.

10.9.1. Diagnosi locale: netstat

Menzioniamo per primo il comando netstat (nel pacchetto net-tools), che mostra una sintesi immediata delle attività di rete di una macchina. Quando viene invocato senza alcun argomento, questo comando elenca tutte le connessioni aperte. L'elenco può essere molto dettagliato poiché comprende numerosi socket di dominio Unix (ampiamente utilizzati dai demoni), che non coinvolgono affatto la rete (per esempio, la comunicazione dbus, il traffico X11 e le comunicazioni tra i filesystem virtuali e desktop).
Pertanto, invocazioni comuni utilizzano opzioni che alterano il comportamento di netstat. Le opzioni utilizzate più frequentemente sono:
  • -t, che filtra i risultati per includere solo le connessioni TCP;
  • -u, che funziona in modo analogo per le connessioni UDP; queste opzioni non si escludono a vicenda, e una di loro è sufficiente per non visualizzare le connessioni di dominio Unix;
  • -a, per elencare anche i socket in ascolto (in attesa di connessioni in ingresso);
  • -n, per visualizzare i risultati in forma numerica: gli indirizzi IP (senza risoluzione DNS), i numeri di porta (senza alias come definiti in /etc/services) e gli ID utente (senza nomi di login);
  • -p, per elencare i processi coinvolti; questa opzione è utile solo quando netstat viene eseguito come root, poiché gli utenti normali vedranno solo i propri processi;
  • -c, per aggiornare continuamente la lista delle connessioni.
Altre opzioni, documentate nella pagina di manuale netstat(8), forniscono un controllo più preciso sui risultati visualizzati. Nella pratica, le prime cinque opzioni sono utilizzate così spesso insieme che il comando netstat -tupan è diventato quasi un riflesso tra gli amministratori di sistema e di rete. Il risultato tipico, su una macchina con poco carico, può apparire come il seguente:
# netstat -tupan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      397/rpcbind     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      431/sshd        
tcp        0      0 0.0.0.0:36568           0.0.0.0:*               LISTEN      407/rpc.statd   
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      762/exim4       
tcp        0    272 192.168.1.242:22        192.168.1.129:44452     ESTABLISHED 1172/sshd: roland [
tcp6       0      0 :::111                  :::*                    LISTEN      397/rpcbind     
tcp6       0      0 :::22                   :::*                    LISTEN      431/sshd        
tcp6       0      0 ::1:25                  :::*                    LISTEN      762/exim4       
tcp6       0      0 :::35210                :::*                    LISTEN      407/rpc.statd   
udp        0      0 0.0.0.0:39376           0.0.0.0:*                           916/dhclient    
udp        0      0 0.0.0.0:996             0.0.0.0:*                           397/rpcbind     
udp        0      0 127.0.0.1:1007          0.0.0.0:*                           407/rpc.statd   
udp        0      0 0.0.0.0:68              0.0.0.0:*                           916/dhclient    
udp        0      0 0.0.0.0:48720           0.0.0.0:*                           451/avahi-daemon: r
udp        0      0 0.0.0.0:111             0.0.0.0:*                           397/rpcbind     
udp        0      0 192.168.1.242:123       0.0.0.0:*                           539/ntpd        
udp        0      0 127.0.0.1:123           0.0.0.0:*                           539/ntpd        
udp        0      0 0.0.0.0:123             0.0.0.0:*                           539/ntpd        
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           451/avahi-daemon: r
udp        0      0 0.0.0.0:39172           0.0.0.0:*                           407/rpc.statd   
udp6       0      0 :::996                  :::*                                397/rpcbind     
udp6       0      0 :::34277                :::*                                407/rpc.statd   
udp6       0      0 :::54852                :::*                                916/dhclient    
udp6       0      0 :::111                  :::*                                397/rpcbind     
udp6       0      0 :::38007                :::*                                451/avahi-daemon: r
udp6       0      0 fe80::5054:ff:fe99::123 :::*                                539/ntpd        
udp6       0      0 2001:bc8:3a7e:210:a:123 :::*                                539/ntpd        
udp6       0      0 2001:bc8:3a7e:210:5:123 :::*                                539/ntpd        
udp6       0      0 ::1:123                 :::*                                539/ntpd        
udp6       0      0 :::123                  :::*                                539/ntpd        
udp6       0      0 :::5353                 :::*                                451/avahi-daemon: r
Come previsto, vengono elencate le connessioni stabilite, due connessioni SSH in questo caso, e le applicazioni in attesa di connessioni in ingresso (indicate come LISTEN), in particolare il server di posta elettronica Exim4 in ascolto sulla porta 25.

10.9.2. Diagnosi da remoto: nmap

nmap (nel pacchetto dal nome analogo) è in un certo senso l'equivalente remoto di netstat. Può eseguire la scansione di una serie di porte "note" per uno o più server remoti, ed elencare le porte su cui un'applicazione risponde alle connessioni in ingresso. Inoltre, nmap è in grado di identificare alcune di queste applicazioni e a volte anche il loro numero di versione. La contropartita di questo strumento è che, poiché funziona da remoto, non può fornire informazioni su processi o utenti; tuttavia può operare su più target contemporaneamente.
Una tipica invocazione di nmap utilizza solo l'opzione -A (in questo modo nmap tenta di identificare le versioni del software per i server che trova), seguita da uno o più indirizzi IP o dai nomi DNS di macchine su cui effettuare la scansione. Ancora una volta, sono disponibili molte altre opzioni per controllare con precisione il comportamento di nmap; consultare la documentazione nella pagina di manuale nmap(1).
# nmap debian
Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:58 CET
Nmap scan report for debian (192.168.122.57)
Host is up (0.000087s latency).
Not shown: 996 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
79/tcp  open  finger
80/tcp  open  http
113/tcp open  ident

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
# nmap -A localhost
nmap -A localhost
Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:56 CET
Stats: 0:01:16 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan
Service scan Timing: About 83.33% done; ETC: 20:57 (0:00:15 remaining)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000086s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 994 closed ports
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 8.4p1 Debian 5 (protocol 2.0)
|_auth-owners: foobar
25/tcp  open  smtp    Postfix smtpd
|_auth-owners: foobar
|_smtp-commands: debian, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, CHUNKING, 
| ssl-cert: Subject: commonName=debian
| Subject Alternative Name: DNS:debian
| Not valid before: 2022-02-22T14:48:42
|_Not valid after:  2032-02-20T14:48:42
|_ssl-date: TLS randomness does not represent time
79/tcp  open  finger?
|_auth-owners: foobar
|_finger: ERROR: Script execution failed (use -d to debug)
80/tcp  open  http    Apache httpd 2.4.52 ((Debian))
|_auth-owners: foobar
|_http-server-header: Apache/2.4.52 (Debian)
|_http-title: Apache2 Debian Default Page: It works
113/tcp open  ident   Liedentd (Claimed user: foobar)
|_auth-owners: foobar
631/tcp open  ipp     CUPS 2.3
|_auth-owners: foobar
| http-robots.txt: 1 disallowed entry 
|_/
|_http-server-header: CUPS/2.3 IPP/2.1
|_http-title: Home - CUPS 2.3.3op2
Service Info: Host:  debian; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 87.91 seconds
Come previsto, sono elencate, ad esempio, le applicazioni SSH, Apache e Postfix. Da notare che non tutte le applicazioni sono in ascolto su tutti gli indirizzi IP; poiché Postfix è accessibile solo sull'interfaccia di loopback lo, appare solo durante l'analisi di localhost e non durante la scansione di debian (che corrisponde all'interfaccia enp1s0 sulla stessa macchina).

10.9.3. Sniffer: tcpdump e wireshark

A volte si ha la necessità di osservare ciò che realmente transita sul cavo, pacchetto per pacchetto. In questi casi è richiesto un "analizzatore di frame", più noto come sniffer. Tale strumento rileva tutti i pacchetti che raggiungono una determinata interfaccia di rete e li visualizza in una maniera più facile da consultare.
Il venerabile strumento in questo settore è tcpdump, disponibile come strumento standard su una vasta gamma di piattaforme. Esso consente molte tipologie di cattura del traffico di rete, ma la rappresentazione di questo traffico resta piuttosto oscura. Pertanto non verrà approfondito.
Uno strumento più recente (e moderno), wireshark (nel pacchetto wireshark), è diventato il nuovo punto di riferimento nell'analisi del traffico di rete grazie ai suoi molti moduli di decodifica che permettono una analisi semplificata dei pacchetti catturati. I pacchetti vengono visualizzati graficamente con un'organizzazione in base ai livelli di protocollo. Questo consente all'utente di visualizzare tutti i protocolli coinvolti in un pacchetto. Ad esempio, prendendo un pacchetto contenente una richiesta HTTP, wireshark visualizza, separatamente, le informazioni relative al livello fisico, il livello Ethernet, le informazioni del pacchetto IP, i parametri di connessione TCP, ed infine la richiesta HTTP stessa.
L'analizzatore del traffico di rete wireshark

Figura 10.1. L'analizzatore del traffico di rete wireshark

Nel nostro esempio, i pacchetti che viaggiano su SSH vengono filtrati (con il filtro !tcp.port == 22). Il pacchetto attualmente visualizzato è stato sviluppato sul livello di trasporto del protocollo SSHv2.