10.9. Diagnoseverktøy for nettverk
Når et nettverksprogram ikke kjører som forventet, er det viktig å kunne se under panseret. Selv når alt ser ut til å kjøre greit, kan det å kjøre en nettverksdiagnose bidra til å sikre at alt fungerer som det skal. Det finnes flere diagnoseverktøy for dette formålet; hvert opererer på et ulikt nivå. Det befinner seg forbi bokens siktemål å gjennomgå alle verktøy, så de mest kjente og brukte diskuteres i de neste delene.
10.9.1. Lokale diagnoser: netstat
La oss først nevne netstat
-kommandoen (i net-tools-pakken); den viser en umiddelbar oppsummering av maskinens nettverksaktivitet. Når det blir kjørt uten argument, lister denne kommandoen opp alle åpne tilkoblinger; denne listen kan være svært detaljert, siden det inneholder mange Unix-domene-socketer (mye brukt av bakgrunnsprosesser) som ikke involverer nettverket i det hele tatt (for eksempel dbus
-kommunikasjon, X11
-trafikk, og kommunikasjon mellom virtuelle filsystemer og skrivebordet).
Vanlige oppkallinger bruker derfor alternativer som endrer hvordan netstat
virker. De vanligst brukte valgene omfatter:
-t
, som filtrerer resultatene til å bare inkludere TCP-forbindelser;
-u
, som fungerer på samme måte for UDP-tilkoblinger; disse alternativene er ikke gjensidig ekskluderende, og en av dem er nok til å stoppe visning av Unix sine domenetilkoblinger;
-a
, for også å liste sockets (som venter på innkommende forbindelser);
-n
, for å vise resultatene numerisk: IP-adresser (ingen DNS-løsning), portnumre (ingen aliaser som definert i /etc/services
) og bruker-ID-er (ingen påloggingsnavn);
-p
, for å liste opp de prosessene som er involvert, er dette alternativet bare nyttig når netstat
kjøres som rot, siden vanlige brukere bare vil se sine egne prosesser;
-c
, for å kontinuerlig oppdatere listen med tilkoblinger.
Andre alternativer, dokumentert på manualsiden netstat(8), gir en enda bedre kontroll over resultatene som vises. I praksis blir de første fem alternativene så ofte brukt sammen at systemer og nettverksadministratorer praktisk talt skaffet netstat -tupan
som en refleks. Typiske resultater på en lett lastet maskin, kan se ut som følger:
#
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
Som forventet, dette lister etablerte tilkoblinger, i dette tilfelle to SSH-forbindelser, og programmer som venter på innkommende forbindelser (listet som LISTEN
), særlig Exim4 e-posttjeneren som lytter på port 25.
10.9.2. Fjerndiagnostikk: nmap
nmap
(i pakken med tilsvarende navn) er, på en måte, ekstern-motstykket som tilsvarer til netstat
. Den kan skanne et sett med «kjente» porter for en eller flere eksterne tjenere, og liste portene der det er funnet et program som svarer på innkommende tilkoblinger. Videre kan nmap
identifisere noen av disse programmene, noen ganger til og med versjonsnummeret. Motstykket til dette verktøyet er at, siden det kjører eksternt, kan det ikke gi informasjon om prosesser eller brukere. Det kan imidlertid operere med flere mål samtidig.
En typisk nmap
-påkalling bruker bare -A
-valget (slik at nmap
forsøker å identifisere versjoner av tjenerprogramvaren den finner) etterfulgt av én eller flere IP-adresser eller DNS-navn på maskiner som skal skannes. Igjen, det finnes mange muligheter til finkontroll av hvordan nmap
kjøres. Referer gjerne til dokumentasjonen i nmap(1) manualside.
#
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
Som forventet er for eksempel Apache og Postfix-programmene oppført. Merk at ikke alle programmer følger med på alle IP-adresser; siden Postfix kun er tilgjengelig på lo
-grensesnittet for filmontering. Det vises bare ved en analyse av localhost
, og ikke ved skanning av debian
(som viser videre til enp1s0
-grensesnittet på den samme maskinen).
10.9.3. Sniffers: tcpdump
og wireshark
Noen ganger må man se på hva som faktisk er i ledningen, pakke for pakke. Disse tilfellene ber om en «rammeanalysator», mer kjent som sniffer. Et slikt verktøy observerer alle pakkene som når et gitt nettverksgrensesnitt, og viser dem på en brukervennlig måte.
Det respekterte verktøyet i dette domenet er tcpdump
, og tilgjengelig som et standard verktøy på et bredt spekter av plattformer. Det gjør at mange typer nettverkstrafikk kan fanges opp, men gjengivelsen av denne trafikken er temmelig dunkel (obskur). Vi vil derfor ikke beskrive det nærmere.
Et nyere (og mer moderne) verktøy, wireshark
(i wireshark-pakken), har blitt den nye referansen i analyse av nettverkstrafikk på grunn av sine mange dekodingsmoduler med mulighet for en forenklet analyse av de pakkene som er fanget opp. Pakkene vises grafisk organisert etter protokollagene. Dette gjør det mulig for en bruker å visualisere alle protokoller som er involvert i en pakke. For eksempel, gitt en pakke som inneholder en HTTP-forespørsel, wireshark
viser, hver for seg, den informasjonen om det fysiske laget, Ethernet laget, IP-pakkeinformasjon, TCP-tilkoblingsparametere, og til slutt HTTP-forespørselen selv.
I vårt eksempel filtreres pakkene som reiser over SSH ut (med !tcp.port == 22
-filteret). Pakken som vises for øyeblikket ble utviklet på overføringslaget til SSHv2-protokollen.