Sniffing v rukou správce sítě

Sniffing je často spojován s aktivitou hackera, který odposlouchává data nic netušících uživatelů. Pojďme se však podívat na praktické ukázky, kdy sniffing pomáhá řešit problémy.

V naší modelové síti je brána (router- PC s Linuxem) připojená rozhranim eth0 k internetu a eth1 do LAN. Na eth0 je veřejná IP adresa kterou pridělil provider a na eth1 IP 1.1.1.1 + nahozená síť 1.1.1.0/24 (PC v síti používají IP adresy 1.1.1.2 - 1.1.1.254 s defaultní bránou 1.1.1.1). Rozhraní eth1 je propojeno s ostatními PC v síti switchem u něhož předpokládejme, že je vždy OK. IP adresu 1.1.1.2 používá uživatel kterému stále něco nefunguje :) a na IP adrese 1.1.1.254 je spuštěn veřejně přístupný webový server (na routeru 1.1.1.1 se provádí forward portů).

Použitým snifferem je program tcpdump (www.tcpdump.org), který je součástí mnoha distribucí linuxu. Jeho popis nechme stranou, avšak vysvětlení námi použitých parametrů (options) je důležité:

n - ve výpisu nepřekládá IP adresy na hostname
i - označení interface
port - číslo sledovaného portu
host - v našem případě IP adresa sledovaného PC
w - v našem případě se nic nebude ukládat do mezipaměti

Tcpdump zobrazuje IP adresy a porty ve formátu ip_adresa.port.. Výpisy programu tcpdump níže jsou zkráceny.

Nyní už k praktickým ukázkám.

Uživatel s IP adresou 1.1.1.2 si stěžuje, že mu nefunguje připojení k internetu a upřesňuje, že se mu nedaří zobrazit webové stránky.

Na bráně si spustíme v jednom okně terminálu PING na klientovu IP adresu a ve druhém okně tcpdump:

tcpdump -ni eth1 host 1.1.1.2

V okně terminálu můžeme vidět tento výstup:

Výpis znamená, že zdrojový počítač s IP adresou 1.1.1.1 posílá protokolem ARP přes broadcast (ke všem počítačům) požadavek na získání MAC adresy cílového počítače s IP 1.1.1.2, ten však nevrací odpověď. Problém je na úrovní síťové vrstvy.

Pokud se na odeslaný PING (ICMP Echo request) vrací odpověď (ICMP Echo reply) což vypadá v tcpdump takto:

... tak je potřeba prozkoumat komunikaci na úrovni aplikace uživatele. Tady už se jedná o přenos dat mezi TCP nebo UDP porty. Na bráně (IP 1.1.1.1) si opět spustíme tcpdump:

tcpdump -ni eth1 host 1.1.1.2 and port 80 // výraz "and" znamená spojení filtru (v našem případě "host" a "port")

V době kdy je tcpdump spuštěn si uživatel zkusí webovým prohlížečem načíst stránku webu o kterém víme, že je právě funkční - např. google.com.. Pokud tcpdump nezobrazí žádná data, tak padá podezření na špatně nastavený webový prohlížeč, který neposílá na webový server žádné požadavky. Správná komunikace by v tcpdump vypadala takto:

Ve výpisu je důležité písmeno "P" (PUSH), což je hodnota tcpflags a znamená, že paket nese data. Důležité je taky to, že jde komunikace oběma směry. Písmeno "F" znamená ukončení spojení (FIN).

To že je jinak připojení v pořádku si ještě můžeme potvrdít tak, že se podíváme na komunikaci uživatelského PC s DNS serverem. Spustíme si na bráně tcpdump tak, aby sledoval komunikaci na portu 53 (DNS):

tcpdump -ni eth1 host 1.1.1.2 and port 53

Uživatel si "pingne" hostname stroje, k terým od posledního spuštění PC ještě nekomunikoval (resolver ho nema v cache - např. security-portal.cz :)). Tcpdump by měl zobrazit tato data:

Ve výpisu je vidět, že se PC s IP adresou 1.1.1.2 dotazuje DNS serveru s IP adresou 81.30.225.2 na A záznam domény security-portal.cz.. DNS server odpovídá, že se jedná o IP adresu 87.236.197.80..

Tím jsme došli k tomu, že uživateli nefunguje webový prohlížeč a kauzu nefunkčního připojení můžeme uzavřít.

Podívejme se na jiný modelový příklad. Na stroji s IP adresou 1.1.1.254 je spuštěn webový server, na bráně 1.1.1.1 se provádí forward portů. Správce webového serveru si stěžuje, že najednou nemá připojeného žádného uživatele a žádá nápravu.

Opět pomůže tcpdump spuštěný na bráně tak, aby zobrazoval komunikaci týkající se IP 1.1.1.254 a (and) portu 80 (HTTP):

tcpdump -ni eth1 host 1.1.1.254 and port 80

V takovém případě bývají nejčastěji vidět tyto dva výpisy:

Opět sledujeme hodnotu tcpflags. Písmeno "S" (SYN) znamená, že klient zahajuje spojení a písmeno "R" (RESET) že ho cílový systém aktivně odmítá. Důvod je zpravidla jednoduchý - webový server nebo TCP Wrap je shozen.

Může se zobrazit rovněž tento výpis:

Tady je vidět, že požadavky na webový server sice přicházejí, ale odezvy z něho neodchází. Důvodem bývá buď "vytuhlý" webový server, nebo špatně nastavený firewall.

Pokud by nebyla v tcpdump vidět žádná data, tak může být problém na bráně, pravděpodobně s forwardem portů.

Dejme si další modelový příklad - na bráně běží monitorovací engine, který kreslí grafy. Jednou z hodnot v grafu je rovněž množství odeslaných a přijatých paketů. Správce zjistil, že u PC s IP adresou 1.1.1.2 došlo k prudkému nárustu množství odeslaných a přijatých paketů, což nevěstí nic dobrého. Nejčastěji se jedná o tři příčiny - v uvedeném PC je vir který hledá oběti, exploit který prohledává síť a hledá službu kterou by mohl napadnout, nebo živatel skenuje porty. Opět pomůže tcpdump spuštěný na bráně:

tcpdump -ni eth1 host 1.1.1.2

Virus nebo exploit, který prohledává síť a hledá zranitelnou službu na portu 135:

Za pozornost stojí, že se jedná o odesílání dat "naslepo" (hodně pokusů o zahájení spojení) a že je cílový port jen jeden, v našem případě 135.

Skenování portů vypadá takto:

Tady je důležité, že se jedná o jednu cílovou IP adresu (194.228.2.1) a různé cílové porty (85, 86, 87 ...). Dále je vidět, že probíhá komunikace s cílovým počítačem, který "žije" (viz tcpflags "R", tzn. aktivně odmítané připojení).

Jak najít počítač, který odesílá SPAM?

Pokud budeme mít štěstí, tak opět pomocí tcpdump. Předpokládejme, že uživatelé v síti používají pro odesílání pošty SMTP server, který běží na bráně 1.1.1.1.. Na bráně si spustíme:

tcpdump -ni eth1 port 25 and no host 1.1.1.1 // výraz "and no" znamená negaci, tzn. vyloučení ze sledování

Pokud některý z počítačů odesílá SPAM, tak se zobrazí bohatá komunikace s IP adresama v internetu na cílovém portu 25/TCP a zdrojová IP adresa, např. 1.1.1.2. Tady ale ještě jisté, že se jedná o SPAM. Pomůžeme si tak, že se podíváme, komu je pošta adresována.

Nejdříve si musíme uložit veškerou sledovanou komunikaci na disk, protože vysledovat cílové e-mailové adresy v paketech přímo v reálném čase prostě nejde :)) Tcpdump spustíme v tomto formátu:

tcpdump -ni eth1 host 1.1.1.2 and port 25 -s 0 -w /smtp.bin

Tcpdump tady zachytává komunikaci, ve které figuruje IP adresa 1.1.1.2 a port 25.. Žádná data se neukládají do mezipaměti a veškerá komunikace vyhovující pravidlům se ukládá do souboru /smtp.bin.. Rád bych tady vysvětlil parametr -s . Tcpdump bez toho parametru zachytává vždy 80 bytů z každého paketu, který postačí k analýze síťového provozu (IP, ICMP, TCP a UDP). Pokud u tohoto parametru použijeme hodnotu "0", tak tcpdump zachytává vše, co zachytit stihne.

Pokud se chceme do souboru /smtp.bin následně podívat, tak nedoporučuji použít textový editor, protože se rozhodí okno terminálu. Použijeme program strings, který dokáže ze souboru vytáhnout tisknutelné znaky a zobrazit je v terminálu. My však necheme vidět celý obsah souboru, takže výpis omezíme programem grep na řetězec "RCPT" což znamená, že se nám vypíšou všechny řádky, kde se tento řetězec nachází. Příkaz bude následující:

strings /smtp.bin | grep RCPT

Vidět bychom mohli něco podobného:

Tady už hraničí podezření s jistotou, že nám ze sítě odchází SPAM.

Tak a na závěr si pojďme vydloubnout ze síťové komunikace nějaké loginy. Pro pochopení si to opět ukažme na uživateli s IP adresou 1.1.1.2 který si stěžuje, že se nemůže připojit k našemu POP3 serveru, který běží na bráně (IP 1.1.1.1). Spustíme si tcpdump:

tcpdump -ni eth1 host 1.1.1.2 and port 110 -s 0 -w /pop.bin

Nyní tcpdump ukládá do souboru /pop.bin komunikaci, ve které figuruje IP adresa 1.1.1.2 a port 110. Požádáme uživatele, aby se několikrát pokusil připojit k POP3 serveru (stáhl si poštu). Jakmile to udělá, tak se podíváme do souboru tímto příkazem:

strings /pop.bin | grep -E "user|pass"

Tímto příkazem si zobrazíme řádky ze souboru /pop.bin, které obsahují řetězec user nebo pass. Výsledek může být následující:

Nyní stačí porovnat přihlašovací údaje které používá klient s těmi které jsou nastaveny na serveru.

No a možnosti jsou různé. Odposlechneme si na bráně a interface které je připojeno k poskytovateli připojení k internetu všechnu odchozí poštu. Tu si uložíme do souboru smtp.bin.. Následně si do souboru smtp.txt vytáhneme jen tisknutelné znaky (resp. čitelný text) a tento soubor si odešleme na svůj server: