Misurazione del Traffico Internet - Luca Deri

Misurazione del
Traffico Internet
Versione 1.2
Luca Deri <[email protected]>
ntop.org
Indice Generale
 Prima Parte
•
•
Dimostrazione dell’utilità del traffic measurement
Necessità di misurare il traffico sia per l’utente finale che per
l’operatore
 Seconda Parte
•
Introduzione all’Internet traffic measurement
 Terza Parte
•
Network troubleshooting: risoluzione dei comuni problemi di rete
ntop.org
v 1.2
2
Prima Parte
ntop.org
Prima Parte: Indice
 Definizione degli attori nel contesto della
misurazione del traffico di rete
 Capability degli apparati di rete
 Confronto dei vari approcci per la
misurazione del traffico di rete
ntop.org
v 1.2
4
Attori nella Misurazione
del Traffico di Rete
 Utenti vs. (Internet) Service Provider
Utente remoto (Dial-up) vs. TIN/Tiscali
• Microsoft vs. (TIN + Telecom Italia)
• UUNET vs. Telecom Italia
•
ntop.org
v 1.2
5
Requisiti Utente
 Monitoraggio della performance applicativa:
•
•
Perchè questa pagina web carica cosi’ lentamente?
Perchè il video multicast non è regolare?
 Verificare che il livello di servizio sia adeguato alla
infrastruttura di rete disponibile
•
Ho una banda sufficiente per le mie applicazioni?
 Verificare se c’è un attacco in corso
•
C’è un virus in rete che occupa tutta la banda?
ntop.org
v 1.2
6
Requisiti dei Service Provider
 Monitorare le attività ed il traffico di rete attuale
 Applicazione degli SLAs (Service Level
Agreements) pattuiti
 Rilevazione di fault e problemi di rete.
 Ingegnerizzare la rete per fornire una migliore
performance
 Pianificare per bisogni di banda futuri
 Ricevere feedback dai clienti
ntop.org
v 1.2
7
Problemi Aperti nel Campo del
Traffic Measurement?
 Capacità di misura molto limitata
•
•
•
Sono misurati solo alcuni protocolli
Le misure possono essere fatte solo su alcuni
dispositivi di rete
Le reti ad alta velocità aprono dei nuovi problemi di
performance
 Necessità di sviluppare sempre nuovi servizi ed
applicazioni basate sulle misurazioni quali:
•
•
IP Billing
QoS?
ntop.org
v 1.2
8
Caratteristiche degli Apparati
 End-system
•
•
Completamente sotto il controllo utente
Completamente instrumentabile dall’utente
 Apparati di Rete Standard
•
•
•
Accesso limitato agli operatori di rete
Set limitato di funzioni offerte
Insieme limitato di dati che possono essere collezionati
 Apparati di Rete Dedicati (Measurement Gears)
•
•
Instrumentabili per collezionare dati specifici
Problemi nella loro dislocazione fisica in modo da
“vedere” tutto il traffico di rete
ntop.org
v 1.2
9
Approcci per la
Misurazione del Traffico
 Active vs. Passive
 Inline vs. Offline
 Per-link vs. End-to-end
 Livelli di Aggregazione
ntop.org
v 1.2
10
Misure di Rete [1/3]
 Propagation Time
•
Quantità di tempo necessaria per trasmettere un quanto di dati (es.
pacchetto) da sorgente a destinazione una volta che i dati sono
già “sul filo”. Il tempo di propagazione dipende dal tipo di media
utilizzato (es. rame, fibra, etc.), dalla velocità del media (es.
10Mbit, 100Mbit) e dalla distanza.
 Queueing Delay
•
Quantità di tempo che attendono i dati dentro una device prima di
essere inviati o, una volta ricevuti, trasmessi alle applicazioni (high
layers).
 Transmission Time (Delay)
•
Quantità di tempo necessaria per inviare un quanto di dati (es.
pacchetto) da sorgente a destinazione, inclusi tutti i ritardi
intermedi (es. tempo di propagazione + tempo di queueing…)
ntop.org
v 1.2
11
Misure di Rete [2/3]
 Bandwidth
•
Misura che descrive la capacità di un link: quantità di dati che
possono essere trasmessi in un quanto di tempo. Es. Mbps, Kbps
 Bottleneck Bandwidth
•
Indica la bandwidth del link più lento in una misurazione end-toend. Percio’ la bandwidth totale è limitata dal bottleneck
bandwidth.
 Throughput
•
Misura della quantità di dati che possono essere inviati su un link
in una quantità di tempo. Spesso viene usato come fattore per la
stima della banda disponibile su un link anche se la bandwidth ed
il throughtput sono due misure molto diverse.
ntop.org
v 1.2
12
Misure di Rete [3/3]
 Latenza
•
Quantità di tempo che impiega un pacchetto per andare da
sorgente a destinazione. Di solito si misura in ms (millisecondi)
 Packet loss
•
Percentuale di pacchetti inviati su un link e non ricevuti dal
destinatario (es. sono stati scartati da un router intermedio). Si
specifica in % (pkt. Persi)/(pkt. Totali).
 Jitter
•
Varianza in un arco di tempo del ritardo tra un pacchetto ed il
successivo in un link monodirezionale.Di solito si misura in ms
(millisecondi)
ntop.org
v 1.2
13
Stima della Bandwidth
Bandwidth = 16 *(Pl-Ps)/(t2l-t2s-t1l+t1s) [misurata in bps]
Mittente






Link da Misurare
Destinazione
Pl = dimensione in bits del pacchetto più grande
Ps = dimensione in bits del pacchetto più piccolo
t1l = ping time di Pl sull’interfaccia più vicina
t1s = ping time di Ps sull’interfaccia più vicina
t2l = ping time di Pl sull’interfaccia più lontana
t2s = ping time di Ps sull’interfaccia più lontana
ntop.org
v 1.2
14
Active Measurement
 Le sonde (probes) sono connesse alla rete da monitorare
e vengono periodicamente letti i valori da essi misurati.
Le misurazioni avvengono iniettando traffico sulla rete.
 ping
•
Connettività, round-trip delay, loss
 traceroute
•
Connettività, path, hop-delay
 Applicazioni Utente
•
•
Performance a livello HTTP/FTP/Network (es. netperf)
Pacchetti di probe tra insiemi di host diversi (es. fping)
ntop.org
v 1.2
15
Passive Measurement
 Non viene iniettato traffico ai fini della
misurazione in quanto gli strumenti sono
totalmente passivi.
 Packet monitors
•
•
Tcpdump/Ethereal per Unix/Win32/MacOSX
Sistemi di misura dedicati
• OC3MON, IPMON
• Niksun, Netscout
 Statistiche di traffico ricavate da router/switch
•
•
Cisco NetFlow/Telnet Interface
SNMP
 Log generati da server
ntop.org
v 1.2
16
Inline vs. Offline
 Inline Measurements
Metodi che utilizzano un protocollo che
transita sulla stessa rete dove si effettuano
le misure (es. SNMP).
 Offline Measurements
Metodi che usano reti diverse da quella
dove transita il traffico da misurare (es.
lettura dei contatori di un router tramite CLI
utilizzando una porta seriale)
ntop.org
v 1.2
17
Per-Link Measurement
 Metrica disponibile solo sul link
•
•
# pacchetti, # bytes, # packets scartati su una
interfaccia del router nell’ultimo minuto
# flussi, # of pacchetti/bytes per flusso
 Non fornisce statistiche globali di rete ma è utile
agli ISP per le loro misurazioni di traffico.
 Esempi:
•
•
•
SNMP MIBs
RTFM (Real-Time Flow Measurement)
Cisco’s NetFlow
ntop.org
v 1.2
18
End-to-End Measurement
 Distinzione tra performance di rete ed applicativa
•
Wire-time vs. web-server performance
 Tutti gli measurements per la loro natura sono di
tipo end-to-end.
•
Statistiche per path
• I path sono simmetrici?
• Come si comportano I pacchetti di probe: il link si comporta
diversamente a seconda della lunghezza del pacchetto?
•
Base per la deduzione della performance a livello di
link
ntop.org
v 1.2
19
Aggregazione delle Misure
flow 1
flow 2
flow 3
flow 4
 Definizione di Flusso
•
Pacchetti con lo stesso (protocollo, src ip & port, dst ip
& port)
 Aggregazione di Flussi per
•
•
•
Porta, ToS (Type of Service), Protocollo (es. ICMP,
UDP), AS (Autonomous System)
Indirizzo sorgente e destinazione
Sottorete,ora del giorno
ntop.org
v 1.2
20
Vantaggi e Svantaggi
 Overhead vs. Accuratezza
•
•
•
Più misure sono fatte, più dati sono collezionati
Più sono aggregati I dati, più grande è la loro
granularità
Overhead (e.g. cpu load) sui router, switch, end-hosts
 Sicurezza vs. Condivisione
•
•
•
Accesso limitato alla rete interna
Occorre rispettare la privacy degli utenti
Le misure devono essere tenute protette in modo da
non rivelare informazioni sulla rete a potenziali hacker
ntop.org
v 1.2
21
Misure e Tecnologie
Le misure del traffico di rete possono essere fatte
utilizzando:
 protocolli generici di management (es. SNMP
Meter MIB)
 AAA-Protocols (Authentication, Authorization and
Accounting) disegnati esclusivamente per questo
compito
 Monitoring tools che tengono traccia dell’utilizzo
delle risorse di rete (es. Cisco NetFlow).
ntop.org
v 1.2
22
AAA-Protocols
Questi protocolli sono nati con Internet per:
 Autenticare gli utenti remoti che
intendevano accedere alla rete.
 Impostare meccanismi di sicurezza
compatibili con la policy locale (es. Utenti
ospiti non possono accedere a risorse
private).
 Tenere traccia dell’uso della rete (es. in
termini di tempo o traffico)
ntop.org
v 1.2
23
AAA-Protocols: Architettura
ntop.org
v 1.2
24
AAA-Protocols
 TACACS
Il primo protocollo di autenticazione ormai non più utilizzato .
 XTACACS (1990)
Protocollo di autenticazione successore di TACACS. Non più
utilizzato.
 TACACS+
Protocollo di autenticazione proprietario Cisco successore di
TACACS.
 RADIUS
Il protocollo AAA attualmente più diffuso.
 DIAMETER (1998)
Nuovo protocollo AAA in corso di sviluppo.
ntop.org
v 1.2
25
Seconda Parte
ntop.org
Motivazione
 Dare risposta alle seguenti domande:
Quali sono gli strumenti disponibili
• Come vengono fatte le misurazioni
• Cosa viene effettivamente misurato
• Come interpretare i dati raccolti
•
ntop.org
v 1.2
27
Panoramica della 2a Parte
 Analisi degli strumenti di misurazione più
diffusi:
ping, traceroute, tcpdump/Ethereal
• OCxMON/CoralReef
• SNMP, MIB
• RTFM, Cisco’s NetFlow
• Routing tables
•
ntop.org
v 1.2
28
Headers TCP/IP
0
Version
IP Header
15 16
31
HLEN
ToS
Total Length
Identification
flags
Fragment Offset
Time to Live
Protocol
Header Checksum
Source IP Address
Destination IP Address
Source Port Number
TCP Header
ntop.org
Header
Destination Port Number
Sequence Number
Acknowledgement Number
Reserved
TCP Flags
Window Size
TCP Checksum
Urgent Pointer
v 1.2
29
Internet Control Message Protocol
0
7 8
Type
15 16
Code
31
Checksum
contents depends on type and code
type
0
8
11
code
0
0
0
1
description
echo reply
echo request
time exceeded
time-to-live equals 0 during transit
time-to-live equals 0 during reassembly
query
x
x
error
x
x
 Utile per riportare errori o condizioni di traffico
anomale
ntop.org
v 1.2
30
ping
 Utilizzato per verificare la raggiungibilità di
un host
 Algoritmo: invio di pacchetti ICMP (o UDP)
Inviare un ICMP Echo Request verso l’host di
destinazione
• L’host di destinazione riceve la richiesta e
risponde con un ICMP Echo Reply
• Il comando ping stampa il RTT, TTL, e il # di
sequenza.
•
ntop.org
v 1.2
31
Esempio di ping
deri@ibook 6> ping fwpisa
PING fwpisa.netikos.com (172.22.4.9): 56 data bytes
64 bytes from 172.22.4.9: icmp_seq=0 ttl=254 time=3.395 ms
64 bytes from 172.22.4.9: icmp_seq=1 ttl=254 time=2.069 ms
64 bytes from 172.22.4.9: icmp_seq=2 ttl=254 time=2.02 ms
64 bytes from 172.22.4.9: icmp_seq=3 ttl=254 time=2.077 ms
^C
--- fwpisa.netikos.com ping statistics --4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 2.02/2.39/3.395 ms
ntop.org
v 1.2
32
traceroute
 Utilizzato per scoprire il forward path verso l’host
di destinazione.
 Algoritmo: utilizza ICMP ed il campo TTL
dell’header IP
•
•
•
•
Invia un pacchetto UDP con TTL=1
Il primo router ritorna un pacchetto ICMP di tipo Time
Exceeded.
Quindi il mittente invia un pacchetto UDP con TTL=2
ed ottiene una risposta dal secondo router.
Si reitera il processo finchè non viene contattato l’host
di destinazione o quando il TTL si esaurisce.
ntop.org
v 1.2
33
Esempio di traceroute
deri@ibook 8> traceroute www.ntop.org
traceroute to faeta.unipi.it (131.114.21.9), 30 hops max, 40 byte packets
1 193.43.104.11 (193.43.104.11) 5.667 ms 2.343 ms 1.963 ms
2 195.31.151.65 (195.31.151.65) 4.346 ms 3.246 ms 3.358 ms
3 r-fi21-telecom-finsiel.interbusiness.it (195.31.6.165) 17.78 ms
15.834 ms 15.633 ms
4 r-fi63-fa2.interbusiness.it (212.131.112.248) 20.323 ms 16.767 ms
15.401 ms
5 r-rm99-fi63.interbusiness.it (151.99.99.25) 18.348 ms 18.889 ms
18.592 ms
6 151.99.101.46 (151.99.101.46) 23.102 ms 22.107 ms 28.286 ms
7 garr-nap.inroma.roma.it (194.242.224.15) 23.42 ms 100.491 ms 25.391
ms
8 roma-rix1.garr.net (193.206.134.225) 191.507 ms 30.183 ms 23.639 ms
9 bo-rm-2.garr.net (193.206.134.37) 29.824 ms 358.839 ms 47.818 ms
10 pi-bo.garr.net (193.206.134.74) 42.362 ms 38.577 ms 34.124 ms
11 unipi-rc.pi.garr.net (193.206.136.18) 106 ms 230.589 ms 183.566 ms
12 eth01-gw.unipi.it (131.114.188.7) 159.475 ms 252.364 ms 236.723 ms
13 faeta.unipi.it (131.114.21.9) 111.036 ms * 78.675 ms
ntop.org
v 1.2
34
Utilizzo di ping e traceroute
 Utili per verificare la raggiungibilità ed il forward
path nella tabella di routing.
 Problemi aperti:
•
•
•
Path asimmetrici (es. in reti con routing dinamico)
ICMP filtering: in questo caso i comandi non
funzionano
Credibilità dei dati forniti dai tool: i pacchetti di probe
sono piccoli e quindi non possono essere veramente
usati per calcolare dati quali throughput e RTT.
ntop.org
v 1.2
35
Reverse Traceroute
 Al fine di calcolare il reverse traceroute sono disponibili
numerosi server accedibili di solito tramite interfaccia
web:
•
•
http:// www.slac.stanford.edu/comp/net/wan-mon/traceroute-srv.html
http://www.caida.org/analysis/routing/reversetrace/
(mappa mondiale dei reverse traceroute server)
ntop.org
v 1.2
36
tcpdump
 Utilizzato per catturare ed analizzare pacchetti (necessita
di diritti di root).
 Modalità di funzionamento: la scheda di rete viene
impostata in modalità promiscua e passivamente sono
catturati i pacchetti da essa ricevuta. è possibile
impostare dei filtri che limitano la cattura solo a certi
pacchetti.
 Output: ora, host/porta mittente e destinazione, protocollo,
payload.
 Download:
• Unix: http://www.tcpdump.org/
• Win32: http://netgroup-serv.polito.it/windump/
ntop.org
v 1.2
37
Esempio di tcpdump
[ibook:/Volumes/Scrapbook/boot] root# tcpdump
15:54:21.896086 pidc01.netikos.com.domain > 193.43.104.253.49163: 43144
NXDomain* 0/1/0 (121)
15:54:21.932486 193.43.104.253.49163 > pidc01.netikos.com.domain: 13120+
PTR? 37.104.43.193.in-addr.arpa. (44)
15:54:21.998994 172.22.5.9.netbios-ns > 172.22.7.255.netbios-ns:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
15:54:21.999014 172.22.5.9.netbios-ns > 172.22.7.255.netbios-ns:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
15:54:22.027432 braito.netikos.com.netbios-dgm > 172.22.7.255.netbios-dgm:
>>> NBT UDP PACKET(138) Res=0x110E ID=0x9AD2 IP=172 (0xac).22 (0x16).5
(0x5).37 (0x25) Port=138 (0x8a) Length=251 (0xfb) Res2=0x0
SourceName=BRAITO
NameType=0x00 (Workstation)
DestName=NETIKOS
NameType=0x00 (Workstation)
SMB PACKET: SMBtrans (REQUEST)
^C15:54:22.160100
[…]
137 packets received by filter
0 packets dropped by kernel
[ibook:/Volumes/Scrapbook/boot] root#
ntop.org
v 1.2
38
Ethereal [1/2]
 Sniffer simile a tcpdump dotato di molti decoder per la
maggtior parte dei protocolli di rete.
 Download: http://www.ethereal.com/ [Unix/Win32]
ntop.org
v 1.2
39
Ethereal [2/2]
Pacchetti
Decoder
Raw
ntop.org
v 1.2
40
Packet Capture: libpcap
sniffer
sniffer
kernel
TCP,UDP
filter
filter
Copia dei
pacchetti
Ethernet
Device driver
BPF driver
ntop.org
IP,ICMP
v 1.2
41
Esempio di uso di libpcap
pcapPtr = pcap_open_live(deviceName,
maxCaptureLen, setPromiscousMode,
pktDelay, errorBuffer);
while(pcap_dispatch(pcapPtr, 1,
processPacket, NULL) != -1);
void processPacket(u_char *_deviceId,
const struct pcap_pkthdr *h,
const u_char *p) {
…
}
ntop.org
v 1.2
42
Problemi con l’utilizzo di Sniffer
 Implicazioni di Sicurezza
•
•
•
Viene catturato tutto il traffico di rete e non solo quello
destinato all’host che ospita lo sniffer
Nel caso si utilizzino reti switched si riesce a catturare
solo una porzione del traffico totale (ARP poisoing)
Utilizzo limitato a coloro che hanno diritti di root
NOTA: questo accade anche con ICMP (es. ping) e per
questo tali comandi sono impostati con setuid.
 Performance
•
L’utilizzo di sniffer ha implicazioni sul carico della CPU
in quanto devono essere analizzati tutti i
pacchetti/protocolli e non solo quelli diretti all’host
ntop.org
v 1.2
43
Traffic Mirror: Soluzioni
Hardware:
 Hub (Copper Ethernet, Token Ring)
 Optical Splitter (Optical Fibers)
 Tap (Copper/Fiber)
Software:
 Switch Port Mirror (1:1, 1:N)
 Switch VLAN Mirror (N:1)
 Switch Traffic Filter/Mirroring (Juniper)
ntop.org
v 1.2
44
Network Taps
ntop.org
v 1.2
45
Packet Capture: Soluzioni
Utilizzo di schede di rete equipaggiate con NPU
(Network Process Unit):
1. Esecuzione di codice per traffic
accounting/management sulla scheda (es.Intel
IPX Family)
2. Accesso ad alta velocità ai pacchetti
direttamente sulla scheda via mmap() senza la
loro copia in memoria centrale tramite il bus
PCI (es. Endace DAG Card)
ntop.org
v 1.2
46
Packet Capture: DAG Card
ntop.org
v 1.2
47
Linux Packet Capture [1/4]
 Linux packet capture è inefficiente quando c’è
una grande quantità di traffico di rete.
Capture
Linux 2.4
Linux 2.6
FreeBSD
Mode
[w/o Polling]
w/Polling
w/Polling
Libpcap
0,1%
0,8%
74,7%
Libpcap
1,1%
Windows
28,6%
mmap()
Kernel
1,5%
9,7%
Module
La tabella illustra la % di pacchetti catturati sul totale inviato.
ntop.org
48
Linux Packet Capture [2/4]
 Linux kernel polling (Linux 2.6 + NAPI)
aiuta ma non è abbastanza.
 Molti OSs sono più performanti di Linux.
 Problema: senza una sostanziale
miglioramento delle performance, Linux
non è adatto alla cattura di pacchetti ad
alta velocità.
ntop.org
49
Linux Packet Capture [3/4]
 Soluzione: socket (PF_RING) ring buffer
mmap()-ed in user space
User Space
Kernel
mmap()
(senza lavoro
per il kernel)
Paccheti Catturati
ntop.org
50
Linux Packet Capture [4/4]
 Cattura a Gbit (> 200’000 pkt/sec) su
Pentium II (550 Mhz) senza schede
aggiuntive.
 Disponibile per Linux 2.4 e Linux 2.6 a
http://sourceforge.net/projects/ntop/
Test Playground
Constant 93’000 Pkt/sec traffic stream
Receiver: nBox with Intel 100Mbit NIC
ntop.org
51
Applicazioni a Livello Utente
 Mancanza di supporto da parte del kernel e
nessun accesso ad ICMP.
 Esempi di applicazioni
•
HTTP/FTP downloads [Paxson97]
• Bulk transfer di dati tra un insieme di host utilizzando
HTTP/FTP e raccolta di dati di performance eseguendo
contemporaneamente tool quali tcpdump e traceroute
•
Pacchetti UDP generati con distribuzione di Poisson
• Ping multipli attivi tra diversi router di una rete per il
monitoraggio dello SLA (es. calcolo del valore medio di packet
delay/loss)
ntop.org
v 1.2
52
OC3MON e OC12MON
 Sistema di monitoraggio passivo con analisi di
flussi per reti ad alta velocità
•
http://www.nlanr.net/NA/Oc3mon/
 Architettura Utilizzata
•
•
IBM PC con 2 FORE ATM NICs a velocità OC3 speed
NICs connessi con fibra ottica sulla quale passa traffico
di tipo IP-over-ATM
 Modalità di Monitoraggio
•
•
Raw cell capture (limitata dalla memoria disponibile e
dalla velocità di elaborazione degli host)
Flow analysis: analisi dei flussi catturati
ntop.org
v 1.2
53
CoralReef
 Insieme di librerie, classi Java ed applicazioni
per l’analisi passiva in realtime di traffico di rete
•
•
Capacità avanzate di analisi e generazione report circa
il traffico catturato.
http://www.caida.org/tools/measurement/coralreef/
Raw traffic stack
Flow stack
C/C++ Programs
Perl Programs
Flows Analysis
CRL.pm & Unpack.pm
Flow Interval Handler
libcoral
Coral Drivers
ntop.org
Trace Files
Tables
libpcap
v 1.2
54
Esempio di Report CoralReef
ntop.org
v 1.2
55
Radius [RFC 2139, 1997]
Radius è un acronimo per Remote Authentication Dial In
User Service (RADIUS) specificato in due RFC:
•
•
Protocollo ai Autenticazione
Rigney, C., Rubens, A., Simpson, W, and Willens, S.;
Remote Authentication Dial In User Service (RADIUS),
RFC 2138, January 1997.
Raccolta Dati di Accounting
Rigney, C.; RADIUS Accounting, RFC 2139, January
1997.
ntop.org
v 1.2
56
Radius
Radius è fondamentale perchè:
 E’ il protocollo più diffuso per implementare
l’autenticazione sugli apparati di rete.
 E’ il protocollo più utilizzato per il billing su linee
seriali (es. ADSL, Modem).
 Ha influenzato tutti i modelli di billing dati perchè
permette di fare accounting per tempo di
connessione o volume di dati.
 Praticamente tutti gli apparati di rete (esclusi i
low-end) lo supportano.
ntop.org
v 1.2
57
Il Protocollo Radius
Login Session
Access Request
Access Accept
Network Access
Accounting Request (Start)
Accounting Response
Server
(Radius Client)
Logout Session
Accounting
Server
(Radius Server)
Accounting Request (Stop)
Accounting Response
ntop.org
v 1.2
58
Il Protocollo Radius: Messaggi
•Code: Byte che contiene il comando/risposta RADIUS.
•Identifier: Byte che identifica il comando/rispsta RADIUS.
•Length: Lunghezza in bytes del pacchetto.
•Authenticator: Valore utilizzato per autenticare la risposta dal
RADIUS server.
•Attributes: Parametri del comando/risposta.
ntop.org
v 1.2
59
Il Protocollo Radius: Primitive
access-request, (client->server): richiesta di accesso a certi servizi (Es.
Autenticazione utente). Possibili risposte:
•
•
•
access-accept, (server->client): accesso garantito.
access-reject, (server->client), risposta negativa.
access-challenge, (server->client): risposta a fronte della quale il server si
aspetta una risposta da parte del client incapsulata in una nuova accessrequest.
accounting request, (client->server): richiesta di memorizzare dati di
accounting nel server. Possibile risposta:
•
accounting response, (server->client): il server conferma il client che I dati
di accounting (es. Bytes inviati) sono stati memorizzti con successo.
ntop.org
v 1.2
60
Il Protocollo Radius:
Contenuto dei Messaggi
 Access-request: username/password dell’utente remoto encriptati
con una shared key.
 Access-response: in caso positivo contiene informazioni quali
l’indirzzo IP, netmask, allowed session time, etc. del cient.
 Accounting-request (start): viene inviato quando l’utente effettua
realmente il login.
 Accounting-request (stop): il client invia al server le seguenti
informazioni:
•
•
•
•
•
•
# di bytes ricevuti dal client (input octets)
# di bytes inviati dal client (output octets)
Durata del collegamento (session time)
# di pacchetti ricevuti dal client (input packets)
# di pacchetti inviati dal client (output packets)
Motivo della disconnessione (es. User logout o time limit)
ntop.org
v 1.2
61
Real Time Flow Measurement
 Definisce: [RFC 2721, 2722]
Metodi per definire flussi
• Gerarchia di device (meters, meter readers,
managers) ai fini della misurazione dei flussi
• Meccanismi per configurare i meter, meter
reader e per collezionare dati da meter remoti
•
ntop.org
v 1.2
62
RTFM: Interazioni tra
Componenti
• Manager-Meter: configura e controlla il meter (es. definisce I flussi da
misurare)
• Manager-Meter Reader: configura e controlla il meter reader (es. definisce
cosa devono leggere da quali meter e con quale frequenza di polling)
• Meter-Meter Reader: colleziona dati di accounting memorizzati nel Meter
leggendo la Meter Flow Table
• Meter Reader - Analysis Application: se necessario I valori letti dal meter
reader possono essere analizzati ulteriormente attracenso un’applicazione di
analisi esterna (es. Aggregazione e filtraggio dati). Questa applicazione non
viene definita dall’architettura RTFM.
ntop.org
v 1.2
63
Esempio di Regole RTFM [1/2]
DEFINE D1 = 130.89.17.64/29;
DEFINE D2 = 130.89.17.72/29;
DEFINE D3 = 130.89.17.80/29;
IF (SourcePeerAddress == D1 && DestPeerAddress == D2) {
SAVE SourcePeerAddress/29; SAVE DestPeerAddress/29;
STORE FlowKind := '1'; COUNT;
} ELSE IF (SourcePeerAddress == D1 && DestPeerAddress ==
D3) {
SAVE SourcePeerAddress/29; SAVE DestPeerAddress/29;
STORE FlowKind := '2'; COUNT;
} ELSE NOMATCH;
FORMAT SourcePeerAddress " " DestPeerAddress " " ToOctets
" " FromOctets " " FlowKind;
ntop.org
v 1.2
64
Esempio di Regole RTFM [2/2]
Flow Kind
To Octets
From Octets
D1->D2
24543
64563
D1->D3
23456
5654
Tabella memorizzata nel Meter e prodotta a partire
dalla configurazione precendente
ntop.org
v 1.2
65
Cisco NetFlow [1/3]
 Approccio analogo a RTFM.
 Standard aperto per la misurazione di flussi IP
definito da Cisco Systems.
 Con RMON è lo standard industriale per la
misurazione del traffico di rete.
 Esistono varie versioni. La più diffusa è la
versione 5. La più recente è la versione 9.
 Le sonde NetFlow sono di solito implementate
nei router/switch ma esistono anche sonde
esterne (es. nProbe)
ntop.org
v 1.2
66
Cisco NetFlow [2/3]
 NetFlow non è basato su SNMP.
 Il probe invia le informazioni sui flussi al
collector utilizzando UDP.
 In ogni pacchetto possono essere
memorizzati più flussi (es. con NetFlow v5
si riescono a memorizzare 30 flussi per
pacchetto).
ntop.org
v 1.2
67
Cisco NetFlow [3/3]
 Memorizza statistiche sui flussi a livello di
interfaccia e li invia al collezionatore via UDP
 Aggregazione a livello di route
•
Es. AS, protocol port, src prefix, dst prefix, prefix
 Raccomandato sugli access routers più che sui
backbone router (troppo carico CPU)
 I flussi collezionati sono inviati ad un
FlowCollector
•
•
•
Non è possibile accedere ai dati via MIB/SNMP
è possibile aggregare ulteriormente flussi nel collector
Altri costruttori (es. Juniper) supportano NetFlow
ntop.org
v 1.2
68
Esempio di Report NetFlow
ntop.org
v 1.2
69
Cisco NetFlow v5 [1/2]
struct netflow5_record {
struct flow_ver5_hdr flowHeader;
struct flow_ver5_rec flowRecord[30];
} NetFlow5Record;
struct flow_ver5_hdr {
u_int16_t version;
u_int16_t count;
u_int32_t sysUptime;
u_int32_t unix_secs;
u_int32_t unix_nsecs;
u_int32_t flow_sequence;
u_int8_t engine_type;
u_int8_t engine_id;
};
ntop.org
/* Current version=5*/
/* The number of records in PDU. */
/* Current time in msecs since router booted */
/* Current seconds since 0000 UTC 1970 */
/* Residual nanoseconds since 0000 UTC 1970 */
/* Sequence number of total flows seen */
/* Type of flow switching engine (RP,VIP,etc.)*/
/* Slot number of the flow switching engine */
v 1.2
70
Cisco NetFlow v5 [2/2]
struct flow_ver5_rec {
u_int32_t srcaddr;
u_int32_t dstaddr;
u_int32_t nexthop;
u_int16_t input;
u_int16_t output;
u_int32_t dPkts;
u_int32_t dOctets;
u_int32_t First;
u_int32_t Last;
u_int16_t srcport;
u_int16_t dstport;
u_int8_t pad1;
u_int8_t tcp_flags;
u_int8_t prot;
u_int8_t tos;
u_int16_t dst_as;
u_int16_t src_as;
u_int8_t dst_mask;
u_int8_t src_mask;
u_int16_t pad2;
};
ntop.org
/* Source IP Address */
/* Destination IP Address */
/* Next hop router's IP Address */
/* Input interface index */
/* Output interface index */
/* Packets sent */
/* Octets sent */
/* SysUptime at start of flow */
/* and of last packet of the flow */
/* TCP/UDP source port number (.e.g, FTP, Telnet, etc.,or equivalent) */
/* TCP/UDP destination port number (.e.g, FTP, Telnet, etc.,or equivalent) */
/* pad to word boundary */
/* Cumulative OR of tcp flags */
/* IP protocol, e.g., 6=TCP, 17=UDP, etc... */
/* IP Type-of-Service */
/* dst peer/origin Autonomous System */
/* source peer/origin Autonomous System */
/* destination route's mask bits */
/* source route's mask bits */
/* pad to word boundary */
v 1.2
71
Flusso NetFlow v5 [1/2]
Cisco NetFlow
Version: 5
Count: 30
SysUptime: 1518422100
Timestamp: May 7, 1993 08:49:48.995294598
CurrentSecs: 736757388
CurrentNSecs: 995294598
FlowSequence: 9751
EngineType: 0
EngineId: 0
SampleRate: 0
pdu 1/30
[ …… ]
ntop.org
v 1.2
72
Flusso NetFlow v5 [2/2]
pdu 1/30
SrcAddr: 10.16.237.114 (10.16.237.114)
DstAddr: 213.92.16.87 (213.92.16.87)
NextHop: 10.158.100.1 (10.158.100.1)
InputInt: 4
OutputInt: 1
Packets: 5
Octets: 627
StartTime: 1518415.920000000 seconds
EndTime: 1518416.352000000 seconds
SrcPort: 3919
DstPort: 80
padding
TCP Flags: 0x1b
Protocol: 6
IP ToS: 0x00
SrcAS: 0
DstAS: 0
SrcMask: 16 (prefix: 10.16.0.0/16)
DstMask: 0 (prefix: 0.0.0.0/32)
padding
pdu 2/30
[ ……………………… ]
ntop.org
v 1.2
73
Flusso NetFlow v9 [1/2]
Cisco NetFlow
Version: 9
Count: 4
SysUptime: 1132427188
Timestamp: Aug 18, 2000 23:49:25.000012271
CurrentSecs: 966635365
FlowSequence: 12271
SourceId: 0
FlowSet 1/4
FlowSet 1/4
Template FlowSet: 0
FlowSet Length: 164
Template Id: 257
Field Count: 18
Field (1/18)
Type: LAST_SWITCHED (21)
Length: 4
Field (2/18)
Type: FIRST_SWITCHED (22)
Length: 4
Field (3/18)
[ …… ]
ntop.org
v 1.2
74
Flusso NetFlow v9 [2/2]
Cisco NetFlow
Version: 9
Count: 1
SysUptime: 1133350352
Timestamp: Aug 19, 2000 00:04:48.000012307
CurrentSecs: 966636288
FlowSequence: 12307
SourceId: 0
FlowSet 1/1
Data FlowSet (Template Id): 257
FlowSet Length: 52
pdu 1
EndTime: 1133334.000000000 seconds
StartTime: 1133334.000000000 seconds
Octets: 84
Packets: 1
InputInt: 15
OutputInt: 0
SrcAddr: 172.18.86.77 (172.18.86.77)
DstAddr: 11.10.65.130 (11.10.65.130)
Protocol: 1
IP ToS: 0x00
[ … ]
ntop.org
v 1.2
75
NetFlow v5 vs. v9
V5
V9
Fisso
User Defined
Estensibilità
No
Dimensione
Flusso
IPv6
48 Bytes
No
Si (Nuovi
Flowset Field)
Dipende dal
Formato
IP v4/v6
MPLS/VLAN
No
Si
Formato Flusso
ntop.org
v 1.2
76
sFlow [1/4]
 RFC 3176 proposto da InMon Inc.
 Definisce:
Il formato dei pacchetti sFlow (UDP, no
SNMP).
• Un MIB SNMP per accedere ai dati collezionati
con sFlow
•
 Architettura simile a NetFlow: il probe invia
i pacchetti sFlow al collector (no polling).
ntop.org
v 1.2
77
sFlow [2/4]
 La sonda sFlow è fondamentalmente uno
sniffer che cattura 1 pacchetto ogni X (es.
ratio 1:400): packet sampling.
 Tale pacchetto viene inviato al collector in
formato sFlow.
 Periodicamente la sonda invia altri
pacchetti sFlow che contengono statistiche
sull’interfaccia di rete al fine di fare la
normalizzazione dei dati.
ntop.org
v 1.2
78
sFlow [3/4]
typedef struct _INMFlow_sample {
u_int32_t sequence_number;
u_int32_t source_id;
u_int32_t sampling_rate;
u_int32_t sample_pool;
u_int32_t drops;
u_int32_t input;
u_int32_t output;
u_int32_t packet_data_tag;
INMPacket_data_type packet_data;
[..]
} INMFlow_sample;
ntop.org
/* Incremented with each generated flow */
/* fsSourceId */
/* fsPacketSamplingRate (e.g. 400 for 1:400) */
/* Total number of packets that could have been
sampled (i.e. packets skipped by sampling
process + total number of samples) */
/* Number of times a packet was dropped due to
lack of resources */
/* SNMP ifIndex of input interface.
0 if interface is not known. */
/* SNMP ifIndex of output interface,
0 if interface is not known. */
/* enum INMPacket_information_type */
/* Sampled packet payload */
v 1.2
79
sFlow [4/4]
 Con opportune formule statistiche, dopo
un piccolo periodo di tempo, un collector
sFlow riesce a fornire statistiche attendibili
sebbene venga analizzata solo una piccola
parte del traffico.
 sFlow è scalabile (basta incrementare il
ratio) anche su reti a 10 Gbit e superiori.
ntop.org
v 1.2
80
Routing Tables
 Essenziali per ogni analisi del traffico basato su
indirizzi
•
Flussi aggregati per prefix, AS, PoP, ingress/egress
interface.
 Modalità di collezionamento informazioni sulle
routing table
•
•
•
Interrogando protocolli di routing dinamico.
Passive routing protocol speaker: rimuove route
vecchie o non utilizzate.
Possibilità di accedere alle route di un router remoto
via router login o SNMP.
ntop.org
v 1.2
81
Topologia di Internet
EGP
Grande ISP
Grande ISP
ISP Medio
dialup
ISP
Piccolo ISP
EGP (External Gateway Protocol) - usato tra AS
(Autonomous Systems) per scambiare informazioni di
routing in modo da forwardare correttamente il traffico tra
ASs.
Esempio: BGP.
ntop.org
v 1.2
82
Scambio delle
Informazioni di Routing
Puoi raggiungere la
rete A tramite me
BGP
AS1
traffic to A
AS2
R1
A
Routing Table su R1:
dest next hop
A
R2
ntop.org
R3
R2
v 1.2
R
Border router
Internal router
83
Protocolli di Routing
IGP: Interior Gateway
Protocol.
Esempio: OSPF
I-BGP
R3
R2
A
AS1
E-BGP
Annuncio B
AS2
R1
AS3
R5
R4
R
Border router
B
Internal router
ntop.org
v 1.2
84
Routing Tables
 Tabelle BGP
Connettività tra AS e AS
• Esempi di tabelle BPG pubbliche:
http://www.antc.uoregon.edu/route-views
[Route Views Project]
•
 Tabelle OSPF
•
Connettività interna ad un AS
 Forwarding Tables
•
Mapping tra porte input -> output port.
ntop.org
v 1.2
85
Routing e Misurazione Traffico
 Al contrario degli utenti finali, per gli i
grandi ISP il traffico costa in base alla
destinazione (modello telefonico).
 Esistono accordi di “peering” con altri ISP
che permettono di avere prezzi particolari
se il traffico passa tramite loro.
 Dividere/aggregare per network/AS
permette di capire come gira il traffico e
quindi per stipulare accordi di peering.
ntop.org
v 1.2
86
Path Characterization
 Che cos’è
•
Capacità di caratterizzare le caratteristiche di un
cammino (path) end-to-end attraverso Internet.
 Misure per la Caratterizzazione
•
•
•
•
•
Bandwidth
Latenza
Packet loss
Jitter
One-way delay, RTT (Round Trip Time)
ntop.org
v 1.2
87
Path Characterization: Pathchar
 Pathchar [ftp://ftp.ee.lbl.gov/pathchar/]
•
•
Invia una serie di pacchetti di dimensioni diverse a
tutti i router della route da analizzare
Viene misurato il tempo di risposta minimo, e per ogni
hop:
• Hop delay
• Bandwidth
• Queueing
•
•
Studiando il RTT in funzione della dimensione del
pacchetto si riesce a calcolare la bandwidth
Lunghi tempi di calcolo a causa dei calcoli complessi
e del numero di pacchetti di probe da inviare ai fini di
ottenere misurazioni realistiche.
 Altri Package: pchar, pipechar.
ntop.org
v 1.2
88
Network Throughput: IPerf
 Iperf [http://dast.nlanr.net/Projects/Iperf/]
•
•
•
•
•
Architettura client/server: lo stesso binario viene
avviato in due modalità diverse.
Il client invia pacchetti TCP/UDP verso il server il quale
riceve I pacchetti
Il client puo’ specificare la porta, la dimensione della
TCP windows, la durata del test, e la quantità di dati da
inviare.
Statistiche: bandwidth, packet delay/loss, jitter.
Svantaggi:
• Il server deve essere installato sull’host di destinazione
• Il tool non puo’ essere utilizzato (in quanto non installabile) sui
router
ntop.org
v 1.2
89
Network Throughput: Bing
 Bing [http://www.cnam.fr/reseau/bing.html]
•
Banwidth Ping: tool per la misura della banda
disponibile basato su ping.
 Algoritmo
•
•
•
Siamo su A e dobbiamo calcolare la banda tra gli host L1 e L2:
A <----> ( Internet ) <---> L1 <---> L2
Il tool calcola il RTT A<->L1 e A<->L2. Da queste misurazioni si
calcola il RTT L1<->L2.
Ripetendo i calcoli per pacchetti di dimensioni diverse si riesce a
calcolare la bandwidth tra L1 e L2
 Limitazioni
•
•
L’algoritmo non funziona su route asimmetriche
Altri Package: Treno [http://ai3.asti.dost.gov.ph/sat/treno.html]
ntop.org
v 1.2
90
Traffic Data Collection [1/2]
 Il collezionamento periodico di dati è
fondamentale per:
•
•
•
•
Avere una storia del traffico passato ai fini di
reingegnerizzare la rete in base al traffico ed alle sue
variazioni (es. picchi)
Fare backtrace in caso di anomalie o di attacchi di rete
Generare informazioni per sistemi di IP accounting e
billing.
Produzioni di report periodici.
ntop.org
v 1.2
91
Traffic Data Collection [2/2]
 Politiche di Collezionamento
Intervallo di collezionamento non più piccolo di
5 minuti (minimo impatto su performance)
• Al fine di analizzare bene i dati è necessario
visualizzarli con intervalli di tempo diversi
•
Giorno
ntop.org
Mese
v 1.2
Anno
92
Data Collection: MRTG
 MRTG [http://www.mrtg.org/]
Multi Router Traffic Grapher: tool per
collezionare tramite SNMP dati di traffico da
router e produrre statistiche e grafici circa i dati
collezionati.
• Possibilità di collezionare dati anche da device
che non ‘parlano’ SNMP.
• Disponibilità di interfaccia Perl e WWW per
l’accesso ai dati collezionati.
•
ntop.org
v 1.2
93
Data Collection: RRD
 RRD [http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/]
•
•
•
Round Robin Database: Tool per memorizzare e
visualizzare serie di dati su cui è basato MRTG.
I dati sono memorizzati in maniera molto compatta in
maniera che non si espandano nel tempo (automatic
data aggregation) e con dimensione fissa del file.
Interfaccia Perl/C per l’accesso ai dati collezionato e
per produrre grafici.
ntop.org
v 1.2
94
Esempio di RRD Perl
$rrd = "$dataDir/$agent-$ifIndex.rrd";
if(! -e $rrd) {
RRDs::create ($rrd, "--start",$now-1, "--step",20,
"DS:bytesIn:COUNTER:120:0:10000000",
"DS:bytesOut:COUNTER:120:0:10000000",
"RRA:AVERAGE:0.5:3:288");
$ERROR = RRDs::error;
die "$0: unable to create `$rrd': $ERROR\n" if $ERROR;
}
RRDs::update $rrd, "$now:$ifInOctets:$ifOutOctets";
if ($ERROR = RRDs::error) {
die "$0: unable to update `$rrd': $ERROR\n";
}
ntop.org
v 1.2
95
Data Collection: Esempi
di Grafici MRTG/RRD
ntop.org
v 1.2
96
Integrated Monitoring: Cacti
Cacti [http://www.raxnet.net/products/cacti] è
un tool open source capace di:
 Collezionare dati tramite da SNMP ed altre
sorgenti non-SNMP.
 Configurazione via web e loro
memorizzazione in un database SQL.
 Memorizzazione dei dati collezionati
dentro files in formato RRD.
 Estensibilità mediante scripts + XML
ntop.org
v 1.2
97
Cacti: Data Collection
ntop.org
v 1.2
98
Cacti: Data Sources
ntop.org
v 1.2
99
Cacti: RRD Graph Templates
ntop.org
v 1.2
100
Cacti: Data Graph
ntop.org
v 1.2
101
Network Troubleshooting
 Localizzazione degli Amministratori
•
Dov’è un host ed a chi appartiene il dominio
dov’è registrato ?
 Problemi di Configurazione
•
Routing table e connettività
ntop.org
v 1.2
102
Dov’é un Host?
 Associazione tra indirizzo IP e nome
deri@tar:~$ nslookup 131.114.21.22
Server: localhost
Address: 127.0.0.1
Name:
jake.unipi.it
Address: 131.114.21.22
 Associazione tra host e Proprietario
nslookup -type=SOA
• WAIS [Wide Area Information System]
http://www.ai.mit.edu/extra/the-net/wais.html
• WHOIS [RFC-812]
•
ntop.org
v 1.2
103
Esempio di Utilizzo WHOIS
deri@ibook:~$ whois unipi.it
domain:
unipi.it
x400-domain: c=it; admd=garr; prmd=unipi;
org:
Università degli Studi di Pisa
org-unit:
Centro SERRA - Servizio per la Rete di Ateneo (SERRA Network)
descr:
SERRA provides network connections for the Pisa University
admin-c:
GP287-ITNIC
tech-c:
SS103-ITNIC
tech-c:
PC5-ITNIC
postmaster: SS103-ITNIC
zone-c:
SS103-ITNIC
zone-c:
PC5-ITNIC
nserver:
131.114.21.10 serra.unipi.it
nserver:
131.114.21.15 nameserver.unipi.it
nserver:
193.205.245.8 dns2.nic.it
dom-net:
131.114.0.0
remarks:
Fully-managed
mnt-by:
GARR-MNT
created:
before 960129
changed:
[email protected] 19940630
changed:
[email protected] 19970321
source:
IT-NIC
[…]
deri@ibook:~$
ntop.org
v 1.2
104
Configurazione di Rete
 Configurazione delle schede di rete
Unix
deri@jabber 151> ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
iprb0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 193.43.104.16 netmask ffffff00 broadcast 193.43.104.255
iprb0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.22.4.16 netmask ffff0000 broadcast 172.22.255.255
Windows
C:\> ipconfig /all
Configurazione IP di Windows
Nome host . . . . . . . . . : penguin.netikos.com
Server DNS. . . . . . . . . : 172.22.4.10
172.22.16.10
Tipo nodo . . . . . . . . . : Ibrido
ID Scope NetBIOS. . . . . . :
IP Routing abilitato. . . . : No
WINS Proxy abilitato. . . . : No
Risoluzione NetBIOS con DNS : Si
[….]
ntop.org
v 1.2
105
Configurazione del Routing
 Problema: necessità di verificare lo stato della
routing table attualmente utilizzata
 Solutione: netstat/route
deri@jabber 149> netstat -rn
Routing Table: IPv4
Destination
-------------------193.43.104.0
195.103.245.0
156.54.249.0
156.54.176.0
10.6.0.0
172.22.0.0
224.0.0.0
default
127.0.0.1
ntop.org
Gateway
Flags Ref
Use
Interface
-------------------- ----- ----- ------ --------193.43.104.16
U
1
638 iprb0
193.43.104.37
UG
1
997
172.22.4.9
UG
1
2
193.43.104.222
UG
1
0
172.22.4.78
UG
1
10
172.22.4.16
U
1
2989 iprb0:1
193.43.104.16
U
1
0 iprb0
193.43.104.11
UG
1
1521
127.0.0.1
UH
10 280460 lo0
v 1.2
106
Configurazione ARP
 La configurazione della ARP table è utile per:
•
•
Riconoscere se ci sono indirizzi duplicati (duplicated
ARP entry)
Verificare esitono problemi di risoluzione di indirizzi
come:
• Installazione abusiva di un ARP proxy
• Blocco ARP da parte di firewall, screening router
•
Utilizzo: Unix/Win32
deri@jake 201> arp -a
eth01-gw.unipi.it (131.114.21.8) at 00:E0:16:87:94:83 [ether] on eth0
pisanino.unipi.it (131.114.21.15) at 08:00:20:76:2C:79 [ether] on eth0
ntop.org
v 1.2
107
Stato Connessioni IP Locali [1/3]
 Motivazione
•
ènecessario conoscere lo stato delle connessioni
quando:
• Gli applicativi non si avviano in quanto trovano le porte
“occupate”
• C’è un gran traffico di rete e si deve capire chi stà parlando con
chi
• Una connessione è lenta e si pensa ci sia del traffico in coda in
attesa di essere inviato/ricevuto
• Ci sono troppe porte occupate e si deve capire se/quali ci sono
applicativi che utilizzano tali porte
ntop.org
v 1.2
108
Stato Connessioni IP Locali [2/3]
 Netstat
•
Applicativo che mostra in maniera simbolica lo stato
della rete e delle connessioni.
deri@localhost 23> netstat -an
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address
Foreign Address
(state)
tcp
0
0 193.43.104.253.49154
193.43.104.16.139
ESTABLISHED
tcp
0
0 127.0.0.1.911
127.0.0.1.1033
ESTABLISHED
tcp
0
0 *.3473
*.*
LISTEN
tcp
0
0 127.0.0.1.1033
127.0.0.1.846
ESTABLISHED
tcp
0
0 127.0.0.1.846
127.0.0.1.1033
ESTABLISHED
tcp
0
0 *.22
*.*
LISTEN
tcp
0
0 *.21
*.*
LISTEN
udp
0
0 *.49164
*.*
udp
0
0 127.0.0.1.49162
127.0.0.1.901
udp
0
0 127.0.0.1.49161
127.0.0.1.901
udp
0
0 *.901
*.*
udp
0
0 *.2222
*.*
udp
0
0 127.0.0.1.1033
*.*
udp
0
0 *.514
*.*
Active LOCAL (UNIX) domain sockets
Address Type
Recv-Q Send-Q
Inode
Conn
Refs Nextref Addr
1017f18 stream
0
0
0 1017ce8
0
0
1017ce8 stream
0
0
0 1017f18
0
0
1017ee0 stream
0
0 11651c8
0
0
0 /var/run/pppconfd
[…]
ntop.org
v 1.2
109
Stato Connessioni IP Locali [3/3]
 lsof [http://freshmeat.net/projects/lsof/]
•
lsof (list open files) è un tool Unix che mostra i
descrittori aperti e lo stato delle connessioni di rete
associate ai vari processi attivi.
deri@localhost 24> lsof -i
COMMAND
PID USER
FD
TYPE
loginwind 245 deri
6u inet
Finder
258 deri
10u inet
Finder
258 deri
11u inet
Finder
258 deri
12u inet
Finder
258 deri
13u inet
LaunchCFM 266 deri
40u inet
LaunchCFM 266 deri
41u inet
ntop.org
DEVICE SIZE/OFF NODE NAME
0x012864ec
0t0 TCP localhost:846->localhost:1033 (ESTABLISHED)
0x0121f970
0t0 UDP *:*
0x01284f6c
0t0 TCP *:* (CLOSED)
0x0121f8a0
0t0 UDP *:*
0x01284a0c
0t0 TCP *:* (CLOSED)
0x0128577c
0t0 TCP *:3473 (LISTEN)
0x0121fcb0
0t0 UDP *:2222
v 1.2
110
Stato Porte IP Remote [1/3]
 Definizione
•
Si definisce port scanning l’attività di riconoscere lo
stato delle porte di un host remoto
 Motivazione
In alcuni casi è necessario conoscere lo stato
delle porte TCP/UDP su un sistema remoto per:
•
•
•
Risolvere problemi di connettività (es. un’applic. locale
non riesce a connettere ad un server remoto)
Conoscere lo stato di un sistema remoto al fine di
violarlo (hackers only)
Verificare da remoto se un sistema ha attivato dei
servizi non previsti (e quindi dedurre se è stato violato
o configurato male)
ntop.org
v 1.2
111
Stato Porte IP Remote [2/3]
 Caveat
•
Visto che il port scanning è spesso un’attività ostile, è
bene effettuare tale attività solo su computer
autorizzati.
 OS Fingerprinting
•
Capacità di riconoscere il tipo di sistema operativo
effettuando un’analisi di tipo pattern matching su come
si comporta uno stack IP a fronte dell’invio di richieste
(es. portscan) legali (dal punto di vista dell’IP) o meno.
ntop.org
v 1.2
112
Stato Porte IP Remote [3/3]
 Tools:
•
•
•
strobe [ftp://ftp.debian.org/debian/dists/stable/source/net/]
hping [http://www.kyuzz.org/antirez]
Nmap [http://www.insecure.org/]
deri@jabber 150> nmap tar
Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )
Interesting ports on tar (193.43.104.13):
(The 1513 ports scanned but not shown below are in state: closed)
Port
State
Service
9/tcp
open
discard
13/tcp
open
daytime
21/tcp
open
ftp
22/tcp
open
ssh
23/tcp
open
telnet
25/tcp
open
smtp
37/tcp
open
time
[…]
Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
ntop.org
v 1.2
113
OS Fingerprinting
 Fingerprinting Attivo
Invio di pacchetti di probe ed identificazione
dell’host in base alle risposte ricevute. Es.nmap O <host>
 Fingerprinting Passivo
Identificazione dell’OS creando una stringa
(fingerprint) costruita utilizzando parametri dei
pacchetti TCP contenenti I flag di tipo SYN o
SYN/ACK. Es. Ettercap
(http://ettercap.sourceforge.net/)
ntop.org
v 1.2
114
OS Fingerprinting: Ettercap [1/2]
WWWW:MSS:TTL:WS:S:N:D:T:F:LEN:OS
WWWW: 4 digit hex field indicating the TCP Window Size
MSS : 4 digit hex field indicating the TCP Option Maximum Segment Size
if omitted in the packet or unknown it is "_MSS"
TTL : 2 digit hex field indicating the IP Time To Live
WS : 2 digit hex field indicating the TCP Option Window Scale
if omitted in the packet or unknown it is "WS"
S
: 1 digit field indicating if the TCP Option SACK permitted is true
N
: 1 digit field indicating if the TCP Options contain a NOP
D
: 1 digit field indicating if the IP Don't Fragment flag is set
T
: 1 digit field indicating if the TCP Timestamp is present
F
: 1 digit ascii field indicating the flag of the packet
S = SYN
A = SYN + ACK
LEN : 2 digit hex field indicating the length of the packet
if irrelevant or unknown it is "LT"
OS : an ascii string representing the OS
ntop.org
v 1.2
115
OS Fingerprinting: Ettercap [2/2]
# Esempio di host fingerprint
0200:0000:40:WS:0:0:0:0:S:LT:Linux 2.0.35 - 2.0.37
0200:05B4:40:00:0:0:0:0:S:2C:Linux 2.0.35 - 2.0.38
0200:05B4:40:00:0:0:0:0:S:LT:Linux 2.0.38
0200:05B4:40:34:0:0:0:0:S:LT:Linux 2.0.33
0200:05B4:40:WS:0:0:0:0:S:2C:Linux 2.0.34-38
0200:05B4:40:WS:0:0:0:0:S:LT:Linux 2.0.36
0200:05B4:FF:WS:0:0:0:0:A:2C:Router 3Com 812 ADSL
0564:0564:40:WS:1:0:1:1:A:38:Linux 2.4
0564:0564:80:WS:1:1:1:0:A:LT:Windows 2000
0564:6405:40:00:0:1:1:1:A:3C:Solaris
0564:6405:40:WS:0:1:1:1:A:38:Mac OS
ntop.org
v 1.2
116
Security Scanner [1/2]
 Motivazione
•
Uno dei metodi più efficaci per sapere se una
macchina è sicura o se è stata compromessa,
è di effettuare uno scan dei servizi ai fini di
trovare dei problemi di sicurezza.
 Implementazione
•
Effettuare lo scan remoto verificando se l’host
sotto esame ha vulnerabilità note o se gira
versioni insicure dei servizi.
ntop.org
v 1.2
117
Security Scanner [2/2]
 Tools
Satan [http://www.cs.ruu.nl/cert-uu/satan.html]
• Nessus [http://www.nessus.org/]
• Saint
[http://www.wwdsi.com/saint/]
•
ntop.org
v 1.2
118
Passive Network Monitoring:
ntop [www.ntop.org]
ntop.org
v 1.2
119