NetFlow
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ó-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:
- 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 ö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őin 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, kidobjuk a legrégebbit;
- 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):
- 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.
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.
- É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. :)
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).
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.