Průvodce programem ethereal (5)

Follow TCP Stream

Česky by se dal tento výraz přeložit jako „následuj proud TCP“ a přesně to tato funkce dělá. V případě, že se v zachycené komunikaci objevilo i nějaké TCP spojení, stačí kliknout na jeden TCP paket a zvolit možnost Follow TCP Stream (buď v menu Analyze nebo přes submenu, které lze zobrazit pravým tlačítkem myši). Následně se otevře nové okno, ve kterém se nám přehledně objeví obsah tohoto proudu.

Na něm vidíte HTTP požadavek a odpověď na něj. Jak si dále můžete všimnout, tento dialog má také své vlastní specifické funkce. První (zleva) tlačítko save as slouží k vyexportování obsahu do externího souboru, tlačítko Print (překvapivě) k tisku. Dále si zde můžeme vybrat, zda máme zájem o kompletní komunikaci (entire converstation), čí pouze o komunikaci v jednom směru (samozřejmě si můžete vybrat z obou možných variant). Také si můžete vybrat způsob, jakým se mají data kódovat. Můžeme si vybrat mezi klasickým ASCII (který je nastaven standardně), EBCDIC (viz. www.natural-innovations.com/com­puting/asciieb­cdic.html), hex dumpem ( tento zápis je téměř shodný s obsahem packet details pane v hlavním okně etherealu) a mezi poli dat v 16 soustavě generované pro jazyk C (C arrays). Při zobrazení tohoto okna se také automaticky vytvoří a aplikuje display filtr tak, že po zavření budou všechny pakety mimo tuto komunikaci vyfiltrované. A nebo po kliknutí na tlačítko Filter out this stream docílíme efektu přesně opačného, pakety z tohoto TCP spojení budou vyfiltrovány. Možná vás po přečtení těchto řádku napadá, k čemu je to vůbec dobré. Primární užití je zejména ve studování nešifrovaných TCP protokolů (http, ftp, pop3, smtp, …). Tato funkce se také velice hodí při odlaďování vlastního síťového software, špehování jiných uživatelů atd.

Packet reassembling

Jistě víte, že každý paket má určitou omezenou maximální velikost a že se velice často stává, že tato velikost pro přenos dat nestačí, a to třeba i při stahování jednoduché html stránky. Data se tedy rozkouskují do více paketů, které putují po síti samostatně a skládají se až u adresáta. Takže i v etherealu máte potom pakety takhle rozkouskované. A funkce pojmenovaná packet reassembling alias opětovné sestavování paketů dělá právě to, že tyto pakety „spojí“. Jak na to? Předvedeme si na to na příkladu u protokolu HTTP. Nejdříve musíme reassembling paketů povolit (verze vydané po září 2005 mají reassembling zapnut standardně), v možnostech (Preferences) programu nalezneme pod položkou Protocols protokol HTTP a zde reassembling povolíme. Poté musíme najít protokol nižší vrstvy, TCP, a zde reassembling povolit také. Změny aplikujeme a zachytíme (načteme ze souboru) nějaký http provoz. Nyní se pokusíme nalézt paket, který obsahuje část odpovědi HTTP serveru ( v sloupci Info v Packet list pane by měl mít text [TCP Segment of reassembled PDU]). U tohoto paketu rozbalíme v Packet details pane TCP protokol a poklikáme na položku [Reassembled PDU in frame: n]. To nás přesune na paket, ve kterém by měla data začínat a v Packet bytes pane tohoto paketu nalezneme několik tabů (záložek). Ty obsahují spojený obsah ze všech paketů.

Vlastní dekódování paketů

Jak jste si určitě všimli, ethereal každému paketu přiřadí nějaký protokol. Přitom každý protokol má svůj určitý dissector (rozkladač, skalpel), který z paketu vyjme potřebné informace a ty zobrazí. Ale je tu jeden problém, jak poznat, že tento paket obsahuje určitý protokol? Tvůrci etherealu se k věci postavili tak, že ethereal si podle určitých pravidel (např.: že http protokol zpravidla pracuje na tcp portu 80) tipuje. Ale může se jednoduše stát, že se ethereal splete, proto program umožňuje si tyto pravidla přenastavit. Už v některém z minulých dílů jsem se zmiňoval o dialogu Enabled protocols, kde jednoduše povolíme/zakážeme dekódovat určité pakety (zakazáním vlastně odstavíme v programu nastavená pravidla). To samotné by nám ale zase tak moc nepomohlo. Důležité je, že můžeme pomocí Decode As dialogu vytvářet pravidla svá.

Jak sami vidíte na obrázku, můžeme si vybrat, zda dekódovat (decode) či ne (do not decode), protokoly jsou rozděleny podle vrstev, u některých protokolů ( jako např.: TCP) musíme specifikovat ještě další nastavení (zdrojový, cílový port). Pak už stačí pouze kliknout na Apply (pro aplikaci) a na OK. Tlačítkem Show current (zobrazit aktuální pravidla) Decode As Show dialog(lze také zobrazit Analyze->User specified decodes…), ve kterém můžete vidět všechny uživatelsky definovaná pravidla a taky je zde všechny zrušit. Nevýhoda těchto pravidel je, že nastavení nelze uložit a po zavření programu všechny pravidla zmizí.

Name resolution důkladněji

Name resolution jsem již nakousl v jednom z minulých dílů, nyní informace zopakuji a doplním. Protože nám lidem se obecně lépe pamatují názvy a písmena než číslice, i ethereal se snaží zdánlivě nesrozumitelné adresy překládat na jména. Kde se tyto názvy berou? Existují dva způsoby. Buď ethereal najde odpovídající překlad ve svém souboru hosts ( ~/.ethereal/hos­ts a nebo C:\Documents and Settings\vas_pro­fil\Data aplikací\Ethe­real\hosts), nebo překládá voláním systémových funkcí. Překlad lze realizovat na několika úrovních, které lze libovolně a nezávisle na sobě zapínat a vypínat. Než si je představíme, tak ještě upozornění, soubory obsahují vždy pouze adresy, takže při opětovném otevírání jednoho souboru program překládá znova a také otevřete-li soubor v jiném programu, který například překlad adres neprodvádí, tak se zde objeví skutečně pouze adresy. Navíc tato činnost ethereal dost zpomaluje a také může prozradit jeho činnost – má-li být tajná.

Mac layer – tato vrtsva překládá přes ARP MAC adresy na IP adresy např.: 00:09:5b:01:02:03 → 192.168.0.1. Pokud toto selže, pokusí se přeložit název MAC adresu na název stroje např.: 00:09:5b:01:02:03 → homerouter. V případě, že se nepovede anti toto, pokusí se ethereal pomocí prvních třech bytů identifikovat výrobce dané síťovky např.: 00:09:5b:01:02:03 → Netgear₀₁:02:03. tato identifikace se provádí pomocí souboru manuf, který nalezneme v adresáři etherealu.

Network layer – Aneb překlad IP adres na DNS. Může se využívat buď DNS a nebo ADNS. Rozdíl mezi nimi je pouze v tom, že ADNS dotazy na DNS servery posílá asynchronně. Tuto vlastnost oceníte zejména při potížích s dostupností některého DNS serveru, zatímco klasický DNS čeká na výsledek nebo na chybové hlášení, ADNS nečeká a program může tedy dál pracovat. Bohužel ADNS nelze jednoduše v programu povolit/zakázat (alespoň podle mých informací) a musí se s programem zkompilovat, předkompilované verze by měly ADNS obsahovat. Samotné dotazování probíhá tak, že ethereal nejdříve prohlédne soubor hosts ( /etc/hosts resp. %WINDIR%\system32\drivers\etc\hosts), pokud neuspěje, zkusí požádat DNS server a pokud i toto selže, obrátí se na hosts soubor vlastní ( ~/.ethereal/hos­ts a nebo C:\Documents and Settings\vas_pro­fil\Data aplikací\Ethe­real\hosts).

Transport layer – tato vrstva překládá známe UDP/TCP porty na jména služeb, např.: 80 → http.

Hrátky s časem

O tomto tématu už jsem také částečně psal, ovšem znova pokládám za důležité pár věcí ještě upřesnit. Čas každého příchozího paketu je zaznamenán a uložen v pevném formátu do souboru pro pozdější analýzu. Ethereal nakládá s časem následujícím způsobem: datum je uloženo ve dnech od 1.1.1970 a čas je uložen v počtu nanosekund od půlnoci (ovšem libpcap/winpcap pracuje pouze řádově s mikrosekundami). Z těchto dvou informací následně ethereal generuje vámi specifikovaný formát času (o tom ale už byla řeč ve druhém dílu seriálu). Ale různé formáty souborů, se kterými umí ethereal pracovat, ukládají „časové značky“ různě a v různých přesnostech (od řádově sekund po nanosekundy). Například nejpoužívanější libpcap formát pracuje (jak už jsem zmiňoval) řádově v mikrosekundách.

A jak je to s časovými pásmy? Může nastat situace, že pracujete na různých místech ve světě a přecházíte z jednodo časového pásma do jiného. Ani to není problém. Všechny formáty souborů, se kterými ethereal umí pracovat, ukládají čas v UTC (viz cs.wikipedia.or­g/wiki/UTC), takže pouze při změně časového pásma stačí toto časové pásmo (a pouze to, samotný čas nepřenastavujte) nastavit v počítači a můžete vesele odchytávat dál.

Statistiky

Statistiky jsou poslední věci, o které jsem se prakticky nezmínil. Takže to teď nahradím. První možnost, Summary, zobrazí okno, které obecně informuje o zachycených paketech – soubor, ve kterém je komunikace umístěna, doba zachytávání, zařízení, ze kterého se zachytávalo, velikost zachycené komunikace a podobně. Okno Protocol Hierarchy zobazí stromovou strukturu protokolů. Každý sloupec obsahuje statistické info o určitém protokolu. myslím, že ktomu není potřeba cokoli dodávat.

Endpoints a Conversation

Co to je? Pokud máte zkušenosti s jinými síťovými nástroji, možná znáte tuto funkci pod názvem hostlist. Tato statistika je rozdělená na záložky podle síťových protokolů (ethernet, ipv4, tcp, udp, …) a v každé této záložce zobrazuje v prvním sloupci adresy a ke každé adrese počet paketů náležících právě této adrese, počet bytů, které byly přeneseny a tak dále. Dále máte možnost povolit nebo zakázat překlad adres (name resolution). Okno s touto statistikou si můžete prohlédnout zde pod textem. A conversation je komunikace mezi dvěma endpointy, například tedy komunikace mezi dvěmi IP adresami.

IO graphs

Ethereal je schopen vykreslovat i grafy. Možnosti nastavení grafů sice nejsou nijak obsáhlé, ale ethereal taky není žádný tabulkový editor. V jednom grafu může být maximálně 5 průběhů, jejich počet si zvolíte kliknutím na tlačítka graph 1–5. Každý graf je barevně odlišen (bohužel barvy jsou nastaveny napevno), pomocí display filtru ovlivňujeme samotnou křivku. Také si můžeme vybrat mezi třemi druhy grafu (čára, šrafování, výplň).

Nastavení os

Nastavení osy X se točí okolo měřítka. Tick interval – v sekundách, tímto určíme, jakou velikost má mít jeden dílek grafu, druhým Pixels per tick určíme velikost obrázku, kolik pixelů má být mezi dvěma čárkami grafu.

U osy Y nastavujete jednotku, tedy buď pakety, data(bytes), nebo můžeme zvolit možnost advanced, kterou zde ale popisovat nebudu. Scale je rozsah osy Y.

Service Responce Time

Je to doba mezi požadavkem síťové služby a korespondující odpovědí. Tato statistika je k dipozici u těchto protokolů:

• DCE-RPC
• Fibre Channel
• ITU-T H.225 RAS
• LDAP
• MGCP
• ONC-RPC
• SMB

Tato funkce sice obsahuje sice jisté možnosti, ale vzhledem k menší rozšířenosti těchto protokolů (dle mého subjektivního názoru) se tomuto tématu věnovat nebudu. Věnovat se nebudu ani specifickým statistikám k jednotlivým protokolům, protože znáte-li protokol, ovládání jeho statistiky pro vás nebude žádný problém.

Závěr

A tím seriál končí. Hodnotit jeho průběh mi nepřísluší a myslím, že každý by si měl udělat svůj obrázek sám. Určitě jsem nezmínil úplně všechno, ale nic důležitého jsem snad neopomněl. Pokud přeci jen na něco takového narazíte, zmiňte se o tom v diskuzi. Na úplný závěr si ještě neodpustím malé doporučení: ethereal je určitě skvělý program, ale možná jeho vlastní programový kód nepatří k nejčistším a nejlepším a v posledním roce se objevilo obrovské množství různě nebezpečných chyb v tomto programu. Proto já osobně doporučuji samotná data sniffovat v programu jiném (tcpdump), pakety ukládat do souboru a v etherealu pouze analyzovat. Samozřejmě v případě, že odchytáváte data příležitostně, např. při vylaďování svého software, je riziko zneužití minimální, ale pro nepřetržité sledování sítě se asi příliš nehodí.