NetFlow

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2010. április 8., 12:49-kor történt szerkesztése után volt.

(eltér) ←Régebbi változat | Aktuális változat (eltér) | Újabb változat→ (eltér)

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

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:
      1. Forráscím (IP)
      2. Célcím (IP)
      3. Harmadik rétegbeli protokoll azonosítója (TCP, UDP, ICMP, SCTP, IGMP, GRE, ...)
      4. TOS (Type of Service)
      5. Forrásport (UDP, TCP, SCTP esetén)
      6. Célport (UDP, TCP, SCTP esetén)
      7. 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).

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):
    1. Hány csomag volt a folyamban?
    2. Hány byte-ot szállított a folyam?
    3. Mikor került be a folyam a flow cache-be?
    4. Mikor ürítettük ki a folyamot a flow cache-ből?
    5. Melyik interface-en küldtük ki a folyam csomagjait?
    6. Az exportáló router IP-címe.
    7. 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.
    8. 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.

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.

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.
  • 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. :)

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.

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.

7 Ajánlott irodalom

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.

  1. Á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!
  2. 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?
  3. 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?
  4. 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?
  5. 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).

Személyes eszközök