10.8. Strumenti di diagnosi di rete
Quando un'applicazione di rete non viene eseguita 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.
10.8.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.8.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 mirtuel
Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-09 16:46 CET
Nmap scan report for mirtuel (192.168.1.242)
Host is up (0.000013s latency).
rDNS record for 192.168.1.242: mirtuel.internal.placard.fr.eu.org
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 2.41 seconds
#
nmap -A localhost
Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-09 16:46 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000013s latency).
Other addresses for localhost (not scanned): 127.0.0.1
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 3 (protocol 2.0)
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
25/tcp open smtp Exim smtpd 4.84
| smtp-commands: mirtuel Hello localhost [127.0.0.1], SIZE 52428800, 8BITMIME, PIPELINING, HELP,
|_ Commands supported: AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100024 1 36568/tcp status
|_ 100024 1 39172/udp status
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.7 - 3.15
Network Distance: 0 hops
Service Info: Host: mirtuel; OS: Linux; CPE: cpe:/o:linux:linux_kernel
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.54 seconds
As expected, the SSH and Exim4 applications are listed. Note that not all applications listen on all IP addresses; since Exim4 is only accessible on the lo
loopback interface, it only appears during an analysis of localhost
and not when scanning mirtuel
(which maps to the eth0
interface on the same machine).
10.8.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.
A more recent (and more modern) tool, wireshark
(in the wireshark package), has become the new reference in network traffic analysis due to its many decoding modules that allow for a simplified analysis of the captured packets. The packets are displayed graphically with an organization based on the protocol layers. This allows a user to visualize all protocols involved in a packet. For example, given a packet containing an HTTP request, wireshark
displays, separately, the information concerning the physical layer, the Ethernet layer, the IP packet information, the TCP connection parameters, and finally the HTTP request itself.
In our example, the packets traveling over SSH are filtered out (with the !tcp.port == 22
filter). The packet currently displayed was developed at the HTTP layer.