NetFlow
a (monitorozás linkesítve) |
(hogyan kell netflow-adatokat gyűjteni) |
||
(egy szerkesztő 9 közbeeső változata nincs mutatva) | |||
148. sor: | 148. sor: | ||
Ezt a portot Half-Life nevű játék használja, úgyhogy a kolléga alighanem játékos, nem fájlcserélőzik (vagy legalábbis azt ebből nem látjuk). |
Ezt a portot Half-Life nevű játék használja, úgyhogy a kolléga alighanem játékos, nem fájlcserélőzik (vagy legalábbis azt ebből nem látjuk). |
||
Erre következtethetünk a csomagok viszonylag kis méretéből is (75-85 bájt). |
Erre következtethetünk a csomagok viszonylag kis méretéből is (75-85 bájt). |
||
+ | |||
+ | Az itt látható portszámok szerinti statisztika nem veszi figyelembe, hogy az adott folyamok a 152.66.214.x-es gépről indulnak ki, vagy ott végződnek. Így az itt látott folyamszámok egy része valószínűleg úgy állt elő, hogy a schönherzes gép a saját 1026-os portjáról küldött csomagokat egy másik gép 27015-ös portjára, amely pedig válaszolt neki - egy ilyen kommunikáció (legalább) két folyamot eredményez, és ezek egy-egy strigulát jelentenek az 1026-os ill. a 27015-ös portszám mellett. |
||
Ha akarnánk, természetesen az összes folyamot is megnézhetnénk, de egy nyers |
Ha akarnánk, természetesen az összes folyamot is megnézhetnénk, de egy nyers |
||
folyamlistában szemmel általában nem sok érdekeset fedezhetünk fel; ha nem tudjuk, mit keresünk, érdemesebb hagyni, hogy egy program |
folyamlistában szemmel általában nem sok érdekeset fedezhetünk fel; ha nem tudjuk, mit keresünk, érdemesebb hagyni, hogy egy program |
||
megtalálja nekünk a kiugró értékeket. |
megtalálja nekünk a kiugró értékeket. |
||
+ | |||
+ | == NetFlow-adatok gyűjtése == |
||
+ | |||
+ | A folyamadatok gyűjtéséhez két dolog kell: valami olyan, ami NetFlow-formában "exportálja" a forgalmi adatokat, és egy másik valami, ami file-ba menti őket (ezt hívják "collectornak"). |
||
+ | |||
+ | Az első célra alkalmas pl. az <tt>fprobe</tt>, amit Debianon meglepő módon az <tt>apt-get install fprobe</tt> paranccsal telepíthetünk. A <tt>/etc/default/fprobe</tt> fájlban kell megadni a collector IP-címét és portszámát; azt a hálózati interfészt, amin látható forgalomból NetFlow-adatokat akarunk exportálni; valamint opcionálisan beállíthatunk egy ''szűrőt''. |
||
+ | |||
+ | A szűrő segítségével pl. korlátozhatjuk az adatgyűjtést csak bizonyos IP-címtartományokat érintő folyamokra, vagy csak TCP-re stb.; mindenképpen érdemes azonban csak IP-re korlátozni, hiszen a többi csomagból, pl. ARP-csomagokból, nem képezhető értelmes folyamrekord. Ezt a következőképpen tehetjük meg: |
||
+ | |||
+ | <pre> |
||
+ | OTHER_ARGS="-fip" |
||
+ | </pre> |
||
+ | |||
+ | Collectornak használhatjuk az <tt>nfcapd</tt>-t, amely az <tt>nfdump</tt> csomag része, vagy a <tt>flow-tools</tt> csomagban levő <tt>flow-capture</tt> programot. Ezek különböző formátumban mentik el az adatokat; az nfcapd-féle formátumot a flow-tools programjai nem ismerik és fordítva, viszont az nfcapd-hez van egy konverter, ami a flow-tools-formátumú fájlokból nfcapd-formátumúakat tud csinálni. |
||
+ | |||
+ | A flow-capture egy lehetséges paraméterezése pl. a következő: |
||
+ | |||
+ | <pre> |
||
+ | flow-capture -b little -N2 -V7 -z9 -w /var/spool/netflow 0/0/1234 |
||
+ | </pre> |
||
+ | |||
+ | A kapcsolók jelentése: |
||
+ | |||
+ | * -b little: a kimenetet little endian byte-sorrendben kérjük. |
||
+ | * -N2: kétszintű (az aktuális évről ill. hónapról elnevezett könyvtárakból álló) könyvtárstruktúrába szeretnénk menteni az adatokat. N0 esetén nem lennének alkönyvtárak, így egy idő után kezelhetetlenül sok file lenne ugyanabban az egy könyvtárban. |
||
+ | * -V7: a kért NetFlow-formátum azonosítója. Nagyjából azt határozza meg, milyen adatok kerüljenek bele a folyamrekordokba. |
||
+ | * -z9: a legjobb elérhető tömörítést kérjük a kimeneten. |
||
+ | * -w /var/spool/netflow: ebbe a könyvtárba kérjük a folyamfájlokat (tartalmazó alkönyvtárakat). A könyvtárnak már léteznie kell. |
||
+ | * 0/0/1234: minden IP-címen figyelünk, bárhonnan jövő csomagot elfogadunk, és az 1234-es helyi portot használjuk. |
||
== Ajánlott irodalom == |
== Ajánlott irodalom == |
||
* [http://www.usenix.org/events/lisa00/full_papers/fullmer/fullmer_html/index.html The OSU Flow-tools Package and Cisco NetFlow Logs] |
* [http://www.usenix.org/events/lisa00/full_papers/fullmer/fullmer_html/index.html The OSU Flow-tools Package and Cisco NetFlow Logs] |
||
+ | |||
+ | == A 2009. április 2-i laborgyakorlat feladatai == |
||
+ | |||
+ | A netflow-adatok a <tt>/var/lib/netflow</tt> könyvtárban találhatóak; elvileg mindenkinek a Desktop könyvtárában található egy symlink, ami ide mutat. A netflow-könyvtár nem írható; ideiglenes file-okat a <tt>/tmp</tt> alatt célszerű létrehozni. |
||
+ | |||
+ | A feladatok a <tt>flow-tools</tt> csomag programjai és az <tt>nfdump</tt> segítségével oldhatók meg. |
||
+ | |||
+ | # Állapítsuk meg, kik forgalmazták a legtöbb byte-ot: |
||
+ | #* 2004. március 23-án 12:00 és 13:00 között; |
||
+ | #* 2004. március 23-án 13:00 és 14:00 között; |
||
+ | #* 2004. március 24-én 12:00 és 13:00 között; |
||
+ | #* 2004. március 24-én 13:00 és 14:00 között. Mekkora az átfedés? Ugyanazok a gépek a top talkerek minden intervallumban? A 10 top talker összesen a teljes forgalom mekkora hányadáért felelős az egyes időszakokban? Hány gép felelős a forgalom 80%-áért? |
||
+ | #* Vizsgáljuk meg külön, mi a helyzet, ha a legtöbb forgalmat küldő, a legtöbbet fogadó és az összesen legtöbbet forgalmazó gépeket tekintjük! |
||
+ | # Melyek ezekben az időszakokban az egymással legnagyobb forgalmat lebonyolító IP-párok? Látjuk a párok között a legtöbbet forgalmazó gépeket? Mit jelent, ha igen, és mit, ha nem? |
||
+ | # Ugyanezekben az időintervallumokban mely címekhez tartozott a legtöbb folyam? Van összefüggés aközött, hogy valaki sok byte-ot forgalmaz és hogy sok folyama van? |
||
+ | # Próbáljuk meg megtippelni, a listavezetők milyen jellegű alkalmazásokat futtattak! Ehhez segítség: |
||
+ | #* Hány különböző másik géppel kommunikáltak? |
||
+ | #* Mekkora csomagméretet használtak? |
||
+ | #* Hány csomag volt egy-egy folyamban? |
||
+ | #* Hogyan oszlik meg a forgalmukban a tcp és az udp? |
||
+ | #* Milyen eloszlást mutatnak a forrás- és célportszámok? |
||
+ | # Miért látunk 2007. februárjában sokkal több folyamot, mint 2007. januárjában? Mi okozza a különbséget? |
||
+ | |||
+ | A tippeket vitassátok meg egymással és a mérésvezetővel. Ne habozzatok a google segítségét is igénybe venni. Néhány kérdésre sem a flow-tools, sem az nfdump nem adja meg közvetlenül a választ -- ilyenkor sokat segít egy awk- vagy [[Shell-programozás|shellscript]]. Álljon itt pl. egy konkrét <tt>zsh</tt> parancssor (lehet, hogy <tt>bash</tt>-ben is működik, nem próbáltam ki): |
||
+ | |||
+ | <pre> |
||
+ | t=0.0; flow-cat -p ft-v07.2004-03-23.12* | flow-stat -f11 -p -P -S2 | sed 's/ */;/g;s/;$//' | grep -v '^#' | head -n 10 | cut -d\; -f3 | while read i; do ((t+=i)); done; echo $t |
||
+ | </pre> |
||
+ | |||
+ | Azt nem árulom el, mire való - akit érdekel, értse meg a működését, és a célja is nyilvánvalóvá válik. Bónuszfeladat: oldjuk meg a sed, a grep, a head és a cut által megoldott részfeladatokat egyetlen sed-paranccsal. :) |
||
+ | |||
+ | Az összes feladat megoldásához valószínűleg csak korábban szerzett rutin birtokában elegendő két óra; ha valamelyik részt eluntad, térj át nyugodtan egy másikra. A gyakorlat célja elsősorban nem az, hogy a fenti konkrét kérdésekre választ kapjunk, hanem az, hogy ráérezzetek a folyamszintű hálózati statisztikák felhasználásának lehetőségeire és korlátaira; valamint hogy kipróbáljátok azokat az eszközöket, amelyekkel a NetFlow feldolgozható. |
||
+ | |||
+ | Ha menet közben valami érdekességre bukkansz az adatokban, ne habozz a "hivatalos" feladatsor helyett inkább az érdekesség felderítésével foglalkozni (egyébként az utolsó kérdés éppen egy ilyen érdekességgel kapcsolatos). |
A lap jelenlegi, 2010. április 8., 13:49-kori változata
A NetFlow a Cisco által bevezetett megoldás arra, hogy routerek és okos switchek a rajtuk átáramló IP-forgalomról folyamszerű statisztikákat készítsenek. Mára a jelentős eszközgyártók általában támogatják. Valószínűleg ez a legelterjedtebb, legszélesebb körben használt folyamszintű hálózatmonitorozási megoldás.
Tartalomjegyzék |
[szerkesztés] 1 Háttér
- A routerekben szokott lenni egy ún. route cache.
- A router ebben tárolhatja, milyen routing-döntést hozott egy adott csomagra.
- Ha később hasonló csomag jön, nem kell újra végigmenni a routing-algoritmuson, elég a tartalom szerint címezhető cache-ből előrántani, melyik interface-en kell kiküldeni a csomagot.
- "Hasonló csomag": aminek a "folyamleírói" azonosak. Folyamleírók:
- Forráscím (IP)
- Célcím (IP)
- Harmadik rétegbeli protokoll azonosítója (TCP, UDP, ICMP, SCTP, IGMP, GRE, ...)
- TOS (Type of Service)
- Forrásport (UDP, TCP, SCTP esetén)
- Célport (UDP, TCP, SCTP esetén)
- Bejövő interface
- Ha két csomag ezen hét leírója megegyezik, akkor ugyanúgy kell őket route-olni, és használhatjuk a cache-t.
- Vegyük észre, hogy egy hálózati viszony két folyamként fog megjelenni: külön folyam az A->B és a B->A irányú kommunikáció.
- A cache-ből időnként törlődhetnek folyamleírók:
- ha megadott időn belül nem érkezik új csomag, ami az adott folyamhoz tartozna;
- ha a folyam elért egy bizonyos kort (mondjuk 30 perc), és még mindig a cache-ben van;
- ha megtelt a cache, de új folyamot kellene belerakni (ekkor kidobjuk mondjuk a legrégebbit, vagy azt, amelyikhez tartozó csomag a legrégebb óta nem jött);
- TCP-folyamok esetén, ha FIN- vagy RST-jelzőbitet látunk (hiszen ezek elvileg lezárják a kommunikációt).
[szerkesztés] 2 A NetFlow alapjai
- Ötlet: ha már úgyis nyilvántartjuk, milyen egyedi folyamokkal találkozunk, gyűjtsük össze ezeket az adatokat, hogy később elemezhessük őket!
- A NetFlow éppen ezt csinálja: a cache-ből kidobott folyamok adatait UDP vagy újabban SCTP fölött elküldi ("exportálja") egy gyűjtőnek ("collector").
- A hét fenti alapleírón kívül a következő adatok szerepelhetnek még (NetFlow-verziótól függően):
- Hány csomag volt a folyamban?
- Hány byte-ot szállított a folyam?
- Mikor került be a folyam a flow cache-be?
- Mikor ürítettük ki a folyamot a flow cache-ből?
- Melyik interface-en küldtük ki a folyam csomagjait?
- Az exportáló router IP-címe.
- További routing-információk: next-hop cím, forrás-AS-azonosító, cél-AS-azonosító, forrás-prefixmaszk, cél-prefixmaszk.
- A folyamban található TCP-csomagok vezérlőbitjeinek VAGY-kapcsolata (CWR, ECE, URG, ACK, PSH, RST, SYN, FIN).
- A protokoll legújabb verziója elvileg IETF-szabvány lesz IPFIX néven; a Cisco már használja és NetFlow V9-nek hívja.
- Az új verzió százas nagyságrendű különböző adatot tud szolgáltatni a folyamokról, pl. MAC-címeket is.
- Az üzemeltetőnek kell eldöntenie, melyikekre kíváncsi.
- Jelenleg a NetFlow V5 a legelterjedtebb.
[szerkesztés] 3 Mire használhatók a NetFlow-adatok?
- Nagyon sokat forgalmazó számítógépek ("top talker") megtalálása.
- Aki p2p fájlcserélőt futtat, annak ráadásul sok folyama is lesz.
- Forgalomalapú számlázás.
- Forgalmi anomáliával járó támadások felderítése (pl. flood, portscan).
- Hálózati események utólagos bizonyítása.
- Pl. ha valaki panaszkodik, hogy spamet küldtünk neki, megnézhetjük, valóban indítottunk-e TCP-kapcsolatot a szerver 25-ös portjára.
[szerkesztés] 4 A felhasználás kihívásai
- Egy session tetszőlegesen sok flow-ra is széteshet.
- Sok HTTP-kapcsolatot látunk, vagy egyetlen nagyon hosszút?
- A TCP-flagbitek (SYN, ACK, FIN) segítségével eldönthető, hogy egy folyam egy TCP-session eleje, közepe vagy vége (esetleg mindhárom).
- UDP esetén csak időzítés-alapú heurisztikákra hagyatkozhatunk.
- Pl. egy UDP-alapú, az 53-as porton működő, keveset forgalmazó VPN nemigen különböztethető meg a DNS-től.
- Nagyon nagy az adatok mennyisége.
- A BME border routerén egy napon nagyságrendileg 150-200 millió folyam halad át.
- Ezeknek az adatai tömörített formában kb. 4,5 gigabájtot tesznek ki.
- A belső folyamokat is tekintve az adatmennyiség még nagyobb.
- Ennyi adat online tárolása mondjuk egy évre visszamenőleg már nem annyira egyszerű (1,6 terabájt).
- De főként: a tömörített formátum feldolgozása lassú;
- irányított lekérdezés, pl. "kérem az 1.2.3.4 IP-hez tartozó összes folyamot március 1. és március 10. közöttről", kivárhatatlan.
- Ha viszont adatbázisban tároljuk az adatokat, a méretük megtöbbszöröződik.
- Nem egyszerű lekérdezésként megfogalmazni az "érdekes" eseményeket. Pl:
- Érdemes tudni arról, ha a szokásos 100 helyett csak 20 IP-vel bonyolítjuk le a forgalmunk 80%-át (lehet DoS, de mindenképpen furcsa).
- Csakhogy: ilyen adat nincs a NetFlow-ban, ezt nekünk magunknak kell kiszámolnunk.
- Érdemes tudni arról, ha a szokásos 100 helyett csak 20 IP-vel bonyolítjuk le a forgalmunk 80%-át (lehet DoS, de mindenképpen furcsa).
- Jó ötletnek tűnhet küszöbértékek beállítása, és riasztás küldése, ha ezeket túllépjük; pl. több, mint 700 megabit/s kimenő forgalom legyen gyanús.
- Csakhogy: lehet, hogy egy nyári vasárnap hajnalán már 300 megabit/s is gyanús, míg egy szeptemberi hétköznap délután a 680 megabit/s-on sem lepődünk meg.
- Általában inkább a statisztikák viselkedésének megváltozása, mint valamely konkrét értéke tájékoztat jól az anomáliákról.
- A megváltozás karakterizációja az átlagos rendszergazda matematikai felkészültségét meghaladó apparátust igényel:
- idősorok, trendek, szezonalitások;
- statisztikai próbák.
- Erős lehet a kísértés, hogy vásároljunk egy olyan "biztonság" feliratú dobozt, aminek a működését nemhogy nem értjük, de a gyártó részleteiben el sem árulja. :)
[szerkesztés] 5 (Fél)manuális felhasználás
A nehézségek ellenére számos adat jól kinyerhető a NetFlow-ból ad-hoc scriptek, ingyenes/nyílt eszköz vagy valamilyen drága, zenélős-kattogtatós "integrált, szinergikus, innovatív menedzsment-eszköz" segítségével. Néhány ingyenes eszköz elérhető pl. a http://www.networkuptime.com/tools/netflow/ és a http://www.switch.ch/network/projects/completed/TF-NGN/floma/software.html oldalon.
Nézzünk egy egyszerű "nyomozást" a flow-tools és az nfdump segítségével (a betűk az anonimizálást szolgálják).
Először is, nézzük meg, kik forgalmaztak a legtöbbet:
flow-cat -p /utvonal/file | flow-stat -f9 -p -S2 # IPaddr flows octets packets # 193.6.a.102 115 2512914697 1694209 152.66.b.39 69 1765003091 1244112 152.66.c.100 2149 1541438898 1058052 193.202.d.33 44 1385704520 926301 152.66.e.250 996 1087218163 753689 80.64.f.22 40 970139295 673341 152.66.g.111 415 848176708 637467 152.66.h.17 1647 801621838 569988 ...
A lista tetején található gép mintegy 2.5 gigabájtot forgalmazott abban a tízperces intervallumban, aminek az adatait az adott NetFlow-fájl tartalmazta. Írassuk ki százalékosan is:
flow-cat -p /utvonal/file | flow-stat -f9 -p -P -S2 # IPaddr flows octets packets # 193.6.a.102 0.009 6.131 2.835 152.66.b.39 0.005 4.306 2.082 152.66.c.100 0.165 3.761 1.770 193.202.d.33 0.003 3.381 1.550 152.66.e.250 0.077 2.653 1.261 80.64.f.22 0.003 2.367 1.127 152.66.g.111 0.032 2.069 1.067 152.66.h.17 0.127 1.956 0.954 ...
A teljes forgalom tíz százalékáért a két legtöbbet forgalmazó gép felelős a kb. százezerből, amelyiknek szerepel folyama ezekben az adatokban. Ez normális (!).
A teljes forgalom 50%-át a 29 legtöbbet forgalmazó gép generálja.
Érdemes megfigyelni, hogy folyamszám szempontjából az adatmennyiség listavezetője sehol sincs (kb. ezredik a folyamszám szerinti listán). A legtöbb folyama egy schönherzes gépnek van, amin nem lepődünk meg borzalmasan. Nézzük meg, a sok folyam egy nagyforgalmú szerverszolgáltatáshoz tartozik-e (ebben az esetben a forrásportok hisztogramjában lesz egy kiugró érték):
flow-cat -p flowfile | ft2nfdump | nfdump -s srcport 'ip 152.66.214.x' Top 10 Src Port ordered by flows: Date first seen Duration Proto Src Port Flows Packets Bytes pps bps bpp 200a-bc-23 16:05:23.705 258.123 any 1026 173132 176522 12.8 M 683 415708 75 200a-bc-23 15:32:08.196 2255.102 any 27015 36355 227938 18.7 M 101 69531 85 200a-bc-23 16:05:23.772 257.539 any 1028 32340 33481 2.4 M 130 78969 75 200a-bc-23 16:05:23.898 257.286 any 1032 25360 26135 1.9 M 101 61674 75 200a-bc-23 16:05:23.769 256.328 any 1027 25266 25842 1.9 M 100 61221 75 200a-bc-23 16:05:36.697 243.465 any 3004 16588 16929 1.2 M 69 42276 76 200a-bc-23 16:05:25.498 254.985 any 1025 14320 14428 1.0 M 56 34358 75 200a-bc-23 16:05:36.827 243.332 any 3006 12639 12822 974472 52 32037 76 200a-bc-23 16:05:23.771 256.389 any 1029 9591 9819 744714 38 23237 75 200a-bc-23 16:05:23.835 257.286 any 1030 8997 9359 708464 36 22028 75
Itt azt érdemes látni, hogy a leggyakoribb forrásport az 1026-os volt, ami tipikus kliensport (ez a második 1024 feletti port, úgyhogy ha egy alkalmazás nem mondja meg, milyen forrásportról szeretne kifelé beszélgetni, gyakran kapja ezt). A top10 folyammal összefüggő forrásportok közül a legtöbb byte-ot viszont a 27015-ös portról küldte a delikvens. Ezt a portot Half-Life nevű játék használja, úgyhogy a kolléga alighanem játékos, nem fájlcserélőzik (vagy legalábbis azt ebből nem látjuk). Erre következtethetünk a csomagok viszonylag kis méretéből is (75-85 bájt).
Az itt látható portszámok szerinti statisztika nem veszi figyelembe, hogy az adott folyamok a 152.66.214.x-es gépről indulnak ki, vagy ott végződnek. Így az itt látott folyamszámok egy része valószínűleg úgy állt elő, hogy a schönherzes gép a saját 1026-os portjáról küldött csomagokat egy másik gép 27015-ös portjára, amely pedig válaszolt neki - egy ilyen kommunikáció (legalább) két folyamot eredményez, és ezek egy-egy strigulát jelentenek az 1026-os ill. a 27015-ös portszám mellett.
Ha akarnánk, természetesen az összes folyamot is megnézhetnénk, de egy nyers folyamlistában szemmel általában nem sok érdekeset fedezhetünk fel; ha nem tudjuk, mit keresünk, érdemesebb hagyni, hogy egy program megtalálja nekünk a kiugró értékeket.
[szerkesztés] 6 NetFlow-adatok gyűjtése
A folyamadatok gyűjtéséhez két dolog kell: valami olyan, ami NetFlow-formában "exportálja" a forgalmi adatokat, és egy másik valami, ami file-ba menti őket (ezt hívják "collectornak").
Az első célra alkalmas pl. az fprobe, amit Debianon meglepő módon az apt-get install fprobe paranccsal telepíthetünk. A /etc/default/fprobe fájlban kell megadni a collector IP-címét és portszámát; azt a hálózati interfészt, amin látható forgalomból NetFlow-adatokat akarunk exportálni; valamint opcionálisan beállíthatunk egy szűrőt.
A szűrő segítségével pl. korlátozhatjuk az adatgyűjtést csak bizonyos IP-címtartományokat érintő folyamokra, vagy csak TCP-re stb.; mindenképpen érdemes azonban csak IP-re korlátozni, hiszen a többi csomagból, pl. ARP-csomagokból, nem képezhető értelmes folyamrekord. Ezt a következőképpen tehetjük meg:
OTHER_ARGS="-fip"
Collectornak használhatjuk az nfcapd-t, amely az nfdump csomag része, vagy a flow-tools csomagban levő flow-capture programot. Ezek különböző formátumban mentik el az adatokat; az nfcapd-féle formátumot a flow-tools programjai nem ismerik és fordítva, viszont az nfcapd-hez van egy konverter, ami a flow-tools-formátumú fájlokból nfcapd-formátumúakat tud csinálni.
A flow-capture egy lehetséges paraméterezése pl. a következő:
flow-capture -b little -N2 -V7 -z9 -w /var/spool/netflow 0/0/1234
A kapcsolók jelentése:
- -b little: a kimenetet little endian byte-sorrendben kérjük.
- -N2: kétszintű (az aktuális évről ill. hónapról elnevezett könyvtárakból álló) könyvtárstruktúrába szeretnénk menteni az adatokat. N0 esetén nem lennének alkönyvtárak, így egy idő után kezelhetetlenül sok file lenne ugyanabban az egy könyvtárban.
- -V7: a kért NetFlow-formátum azonosítója. Nagyjából azt határozza meg, milyen adatok kerüljenek bele a folyamrekordokba.
- -z9: a legjobb elérhető tömörítést kérjük a kimeneten.
- -w /var/spool/netflow: ebbe a könyvtárba kérjük a folyamfájlokat (tartalmazó alkönyvtárakat). A könyvtárnak már léteznie kell.
- 0/0/1234: minden IP-címen figyelünk, bárhonnan jövő csomagot elfogadunk, és az 1234-es helyi portot használjuk.
[szerkesztés] 7 Ajánlott irodalom
[szerkesztés] 8 A 2009. április 2-i laborgyakorlat feladatai
A netflow-adatok a /var/lib/netflow könyvtárban találhatóak; elvileg mindenkinek a Desktop könyvtárában található egy symlink, ami ide mutat. A netflow-könyvtár nem írható; ideiglenes file-okat a /tmp alatt célszerű létrehozni.
A feladatok a flow-tools csomag programjai és az nfdump segítségével oldhatók meg.
- Állapítsuk meg, kik forgalmazták a legtöbb byte-ot:
- 2004. március 23-án 12:00 és 13:00 között;
- 2004. március 23-án 13:00 és 14:00 között;
- 2004. március 24-én 12:00 és 13:00 között;
- 2004. március 24-én 13:00 és 14:00 között. Mekkora az átfedés? Ugyanazok a gépek a top talkerek minden intervallumban? A 10 top talker összesen a teljes forgalom mekkora hányadáért felelős az egyes időszakokban? Hány gép felelős a forgalom 80%-áért?
- Vizsgáljuk meg külön, mi a helyzet, ha a legtöbb forgalmat küldő, a legtöbbet fogadó és az összesen legtöbbet forgalmazó gépeket tekintjük!
- Melyek ezekben az időszakokban az egymással legnagyobb forgalmat lebonyolító IP-párok? Látjuk a párok között a legtöbbet forgalmazó gépeket? Mit jelent, ha igen, és mit, ha nem?
- Ugyanezekben az időintervallumokban mely címekhez tartozott a legtöbb folyam? Van összefüggés aközött, hogy valaki sok byte-ot forgalmaz és hogy sok folyama van?
- Próbáljuk meg megtippelni, a listavezetők milyen jellegű alkalmazásokat futtattak! Ehhez segítség:
- Hány különböző másik géppel kommunikáltak?
- Mekkora csomagméretet használtak?
- Hány csomag volt egy-egy folyamban?
- Hogyan oszlik meg a forgalmukban a tcp és az udp?
- Milyen eloszlást mutatnak a forrás- és célportszámok?
- Miért látunk 2007. februárjában sokkal több folyamot, mint 2007. januárjában? Mi okozza a különbséget?
A tippeket vitassátok meg egymással és a mérésvezetővel. Ne habozzatok a google segítségét is igénybe venni. Néhány kérdésre sem a flow-tools, sem az nfdump nem adja meg közvetlenül a választ -- ilyenkor sokat segít egy awk- vagy shellscript. Álljon itt pl. egy konkrét zsh parancssor (lehet, hogy bash-ben is működik, nem próbáltam ki):
t=0.0; flow-cat -p ft-v07.2004-03-23.12* | flow-stat -f11 -p -P -S2 | sed 's/ */;/g;s/;$//' | grep -v '^#' | head -n 10 | cut -d\; -f3 | while read i; do ((t+=i)); done; echo $t
Azt nem árulom el, mire való - akit érdekel, értse meg a működését, és a célja is nyilvánvalóvá válik. Bónuszfeladat: oldjuk meg a sed, a grep, a head és a cut által megoldott részfeladatokat egyetlen sed-paranccsal. :)
Az összes feladat megoldásához valószínűleg csak korábban szerzett rutin birtokában elegendő két óra; ha valamelyik részt eluntad, térj át nyugodtan egy másikra. A gyakorlat célja elsősorban nem az, hogy a fenti konkrét kérdésekre választ kapjunk, hanem az, hogy ráérezzetek a folyamszintű hálózati statisztikák felhasználásának lehetőségeire és korlátaira; valamint hogy kipróbáljátok azokat az eszközöket, amelyekkel a NetFlow feldolgozható.
Ha menet közben valami érdekességre bukkansz az adatokban, ne habozz a "hivatalos" feladatsor helyett inkább az érdekesség felderítésével foglalkozni (egyébként az utolsó kérdés éppen egy ilyen érdekességgel kapcsolatos).