Síťový tok - NetFlow

Architektura NetFlow

Síťový tok je funkce, která byla zavedena dne Cisco směrovače kolem roku 1996, které poskytují schopnost shromažďovat síťový provoz IP při vstupu nebo výstupu z rozhraní. Analýzou dat poskytovaných NetFlow může správce sítě určit věci, jako je zdroj a cíl provozu, třída služby a příčiny přetížení. Typické nastavení monitorování toku (pomocí NetFlow) se skládá ze tří hlavních komponent:[1]

  • Exportér toku: agreguje pakety do toků a exportuje záznamy toku do jednoho nebo více sběračů toku.
  • Průtokový kolektor: odpovědný za příjem, ukládání a předzpracování údajů o toku přijatých od vývozce toku.
  • Analýza aplikace: analyzuje například přijatá data toku v kontextu detekce narušení nebo profilování provozu.

Popis protokolu

Směrovače a přepínače, které podporují NetFlow, mohou sbírat IP statistiku provozu na všech rozhraních, kde je povolen NetFlow, a později tyto statistiky exportovat jako záznamy NetFlow alespoň do jednoho sběrače NetFlow - obvykle serveru, který provádí skutečnou analýzu provozu.

Síťové toky

Standard Cisco NetFlow verze 5 definuje a tok jako jednosměrná posloupnost paketů, které všechny sdílejí sedm hodnot, které definují jedinečný klíč toku:[2]

  1. Příchozí rozhraní (SNMP ifIndex)
  2. Zdroj IP adresa
  3. Destinace IP adresa
  4. IP protokol
  5. Zdrojový port pro UDP nebo TCP, 0 pro ostatní protokoly
  6. Cílový port pro UDP nebo TCP, typ a kód pro ICMP, nebo 0 pro jiné protokoly
  7. IP Typ služby

Všimněte si, že rozhraní Egress, IP Nexthop nebo BGP Nexthops nejsou součástí klíče a nemusí být přesné, pokud se trasa změní před vypršením toku nebo pokud se vyvažování zátěže provádí na každý paket.

Tato definice toků se také používá pro IPv6 a podobná definice se používá pro MPLS a Ethernet proudí.

Pokročilé implementace NetFlow nebo IPFIX, jako je Cisco Flexible NetFlow, umožňují uživatelsky definované tokové klíče.

Typický výstup nástroje příkazového řádku NetFlow (nfdump v tomto případě) při tisku mohou uložené toky vypadat takto:

 Datum začátku toku Trvání Proto Src IP Addr: Port Dst IP Addr: Port Pakety Bajty Toky 2010-09-01 00: 00: 00,459 0,000 UDP 127.0.0.1:24920 -> 192.168.0.1:22126 1 46 1 2010-09-01 00: 00: 00,363 0,000 UDP 192.168.0.1:22126 -> 127.0.0.1:24920 1 80 1

Export záznamů

Router vydá záznam toku, když zjistí, že je tok dokončen. Dělá to stárnutím toku: když router uvidí nový provoz pro stávající tok, vynuluje počítadlo stárnutí. Taky, Relace TCP ukončení toku TCP způsobí, že router vyprší tok. Směrovače lze také nakonfigurovat tak, aby vydávaly záznam toku v pevném intervalu, i když tok stále probíhá.

Protokol přenosu paketů

Záznamy NetFlow se tradičně exportují pomocí protokolu User Datagram Protocol (UDP ) a shromážděny pomocí sběrače NetFlow. Na odesílajícím routeru musí být nakonfigurována IP adresa sběrnice NetFlow a cílový port UDP. Běžnou hodnotou je UDP port 2055, ale lze použít i jiné hodnoty jako 9555 nebo 9995, 9025, 9026 atd.

Z důvodů efektivity router tradičně nesleduje již exportované záznamy o toku, takže pokud je NetFlow paket zrušen kvůli přetížení sítě nebo poškození paketů, všechny obsažené záznamy jsou navždy ztraceny. Protokol UDP neinformuje směrovač o ztrátě, takže může odesílat pakety znovu. To může být skutečný problém, zejména s NetFlow v8 nebo v9, které mohou agregovat mnoho paketů nebo toky do jednoho záznamu. Ztráta jednoho paketu UDP může mít obrovský dopad na statistiku některých toků.

Proto některé moderní implementace NetFlow používají přenosový protokol Stream Control (SCTP ) exportovat pakety tak, aby poskytovaly určitou ochranu před ztrátou paketů, a ujistěte se, že jsou šablony NetFlow v9 přijaty před exportem souvisejícího záznamu. Upozorňujeme, že TCP by pro NetFlow nebyl vhodný, protože přísné řazení paketů by způsobilo nadměrné ukládání do vyrovnávací paměti a zpoždění.

Problém SCTP spočívá v tom, že vyžaduje interakci mezi každým kolektorem NetFlow a každým směrovačem exportujícím NetFlow. Mohou existovat omezení výkonu, pokud se směrovač musí vypořádat s mnoha kolektory NetFlow a kolektor NetFlow se musí vypořádat s mnoha směrovači, zvláště když některé z nich nejsou k dispozici kvůli poruše nebo údržbě.

SCTP nemusí být efektivní, pokud NetFlow musí být exportován do několika nezávislých sběratelů, z nichž některé mohou být testovací servery, které mohou kdykoli selhat. UDP umožňuje jednoduchou replikaci paketů NetFlow pomocí síťových odboček nebo zrcadlení L2 nebo L3. Jednoduché zařízení bez státní příslušnosti může v případě potřeby také filtrovat nebo změnit cílovou adresu paketů NetFlow UDP. Protože export NetFlow téměř využívá pouze páteřní síťové odkazy, ztráta paketů bude často zanedbatelná. Pokud k tomu dojde, bude to většinou na propojení mezi sítí a kolektory NetFlow.

Záhlaví paketů

Všechny pakety NetFlow začínají hlavičkou závislou na verzi, která obsahuje alespoň tato pole:

  • Číslo verze (v1, v5, v7, v8, v9)
  • Pořadové číslo pro detekci ztráty a duplikace
  • Časová razítka v okamžiku exportu, jako doba provozu systému nebo absolutní čas.
  • Počet záznamů (v5 nebo v8) nebo seznam šablon a záznamů (v9)

Evidence

Záznam NetFlow může obsahovat širokou škálu informací o provozu v daném toku.

NetFlow verze 5 (jedna z nejčastěji používaných verzí, následovaná verzí 9) obsahuje následující:

  • Index vstupního rozhraní používaný SNMP (ifIndex v IF-MIB).
  • Index výstupního rozhraní nebo nula, pokud je paket zrušen.
  • Časová razítka pro čas začátku a konce toku, v milisekundách od posledního spuštění.
  • Počet bajtů a paketů pozorovaných v toku
  • Vrstva 3 záhlaví:
    • Zdrojové a cílové adresy IP
    • ICMP Typ a kód.
    • IP protokol
    • Typ služby (ToS) hodnota
  • Čísla zdrojových a cílových portů pro TCP, UDP, SCTP
  • U toků TCP sjednocení všech příznaků TCP pozorovaných po dobu životnosti toku.
  • Vrstva 3 Směrování informace:
    • IP adresa okamžitého dalšího hopu (nikoli BGP nexthop) na trase do cíle
    • Zdrojové a cílové IP masky (délky předpon v CIDR notace)

Pro ICMP toků, zdrojový port je nula a kódy polí cílového čísla portu zpráva ICMP typ a kód (port = typ ICMP * 256 + kód ICMP).

Zdroj a cíl Autonomní systém Číselná pole (AS) mohou hlásit cílové AS (poslední AS z AS-Path) nebo bezprostřední soused AS (první AS z AS-Path) v závislosti na konfiguraci routeru. Číslo AS bude ale nulové, pokud tato funkce není podporována, trasa není známa nebo není oznámena BGP, nebo AS je místní AS. Neexistuje žádný výslovný způsob, jak tyto případy rozlišit.

NetFlow verze 9 může obsahovat všechna tato pole a může volitelně obsahovat další informace, jako je Přepínání štítků s více protokoly (MPLS) štítky a IPv6 adresy a porty,

Analýzou dat toku lze vytvořit obraz toku provozu a objemu provozu v síti. Formát záznamu NetFlow se v průběhu času vyvíjel, a proto bylo zahrnuto číslo verze. Společnost Cisco udržuje podrobnosti o různých číslech verzí a rozložení paketů pro každou verzi.

Rozhraní

NetFlow je obvykle povolen na základě jednotlivých rozhraní, aby se omezilo zatížení komponent routeru zapojených do NetFlow nebo aby se omezilo množství exportovaných záznamů NetFlow.

NetFlow obvykle zachycuje všechny pakety přijaté příchozím rozhraním IP, ale některé implementace NetFlow používají filtry IP k rozhodnutí, zda lze NetFlow paket pozorovat.

Některé implementace NetFlow také umožňují pozorování paketů na výstupním rozhraní IP, ale toto je nutné používat opatrně: všechny toky z jakéhokoli příchozího rozhraní s povoleným NetFlow do jakéhokoli rozhraní s povoleným NetFlow lze započítat dvakrát.

Vzorek NetFlow

Standardní NetFlow byl navržen pro zpracování všech IP paketů na rozhraní. Ale v některých prostředích, např. na páteřních sítích internetu, to bylo příliš nákladné, kvůli extra zpracování požadovanému pro každý paket a velkému počtu současných toků.

Cisco tedy představilo vzorkovaný NetFlow na Cisco 12000, a to se nyní používá ve všech špičkových směrovačích, které implementují NetFlow.

Pouze jeden balíček z n se zpracovává, kde n, vzorkovací frekvence, je určena konfigurací routeru.

Přesný proces výběru závisí na implementaci:

  • Každý balíček n paket v deterministickém NetFlow, jak se používá na Cisco 12000.
  • Jeden paket náhodně vybraný v intervalu n packet, in Random Sampled NetFlow, used on modern Cisco routers.

Některé implementace mají složitější metody vzorkování paketů, například vzorkování podle toku na katalyzátorech Cisco Martinez.

Vzorkovací frekvence je často stejná pro všechna rozhraní, ale u některých směrovačů ji lze upravit na každé rozhraní. Když se používá Sampled NetFlow, záznamy NetFlow musí být upraveny pro efekt vzorkování - zejména objemy provozu jsou nyní spíše odhadem než skutečný naměřený průtok.

Vzorkovací frekvence je uvedena v poli záhlaví NetFlow verze 5 (stejná vzorkovací frekvence pro všechna rozhraní) nebo v záznamech možností NetFlow verze 9 (vzorkovací frekvence na rozhraní)

Verze

VerzeKomentář
v1První implementace, nyní zastaralá a omezená na IPv4 (bez IP maska a AS čísla ).
v2Interní verze společnosti Cisco, nikdy vydána.
v3Interní verze společnosti Cisco, nikdy vydána.
v4Interní verze společnosti Cisco, nikdy vydána.
v5Nejběžnější verze, dostupná (od roku 2009) na mnoha směrovačích různých značek, ale omezena na IPv4 proudí.
v6Společnost Cisco již nepodporuje. Informace o zapouzdření (?).
v7Stejně jako verze 5 s polem zdrojového routeru. Používá se (pouze?) Na přepínačích Cisco Catalyst.
v8Několik agregačních formulářů, ale pouze pro informace, které jsou již obsaženy v záznamech verze 5
v9Na základě šablony, dostupné (od roku 2009) na některých nedávných směrovačích. Většinou se používá k hlášení toků jako IPv6, MPLS, nebo dokonce prostý IPv4 s BGP nexthop.
v10Používá se k identifikaci IPFIX. Ačkoli je IPFIX silně založen na NetFlow, v10 nemá s NetFlow nic společného.

NetFlow a IPFIX

NetFlow byl původně implementován společností Cisco a popsán v „informačním“ dokumentu, který nebyl na cestě ke standardům: RFC 3954 - Export Cisco Systems NetFlow Services verze 9. Samotný protokol NetFlow byl nahrazen Internet Protocol Flow Information eXport (IPFIX ). Na základě implementace NetFlow verze 9 je IPFIX na cestě ke standardům IETF RFC 5101 (zastaral RFC 7011 ), RFC 5102 (zastaral RFC 7012 ) atd., Které byly zveřejněny v roce 2008.

Ekvivalenty

Mnoho prodejců kromě Cisco poskytují podobnou technologii monitorování toku sítě. NetFlow může být převládající název v oblasti monitorování toku, protože Cisco dominantní podíl na trhu v síťovém průmyslu. NetFlow je považován za ochrannou známku společnosti Cisco (i když od března 2012 není uvedena v ochranných známkách společnosti Cisco[3]):

Také sběr softwaru pro vývojové nástroje[5] umožňuje zpracovávat a spravovat exporty NetFlow ze směrovačů Cisco a Juniper.[6]

Podpěra, podpora

Prodejce a typModelyVerze NetFlowImplementaceKomentáře
Směrovače Cisco IOS-XRCRS, ASR9000 starý 12000v5, v8, v9Software běží na lince CPU CPUKomplexní podpora pro IPv6 a MPLS
Směrovače Cisco IOS10000, 7200, starý 7500v5, v8, v9Software běžící na procesoru Routepodpora IPv6 nebo MPLS vyžaduje nedávný model a IOS
Cisco Katalyzátor spínače7600, 6500, 4500v5, v8, v9Vyhrazený hardware TCAM, také používaný pro ACL.Podpora protokolu IPv6 na špičkových modelech RSP720 a Sup720, ale maximálně 128K nebo 256K toků na kartu PCF.[7]
Cisco Nexus spínače5600, 7000, 7700v5, v9Vyhrazený hardware TCAM, také používaný pro ACL. Toky až 512 tis. Podpora IPv4 / IPv6 / L2.MPLS není podporován
Starší směrovače JuniperŘada M., Řada T., Řada MX s DPCv5, v8Software běžící na Routing Engine, tzv softwarový tokIPv6 a MPLS nejsou podporovány
Starší směrovače JuniperŘada M., Řada T., Řada MX s DPCv5, v8, v9Software běžící na službě PIC, tzv hardwarový tok nebo odebrány vzorkyIPv6 nebo MPLS podporované na MS-DPC, MultiService-PIC, AS-PIC2
Jalovec směrovačeŘada MX s MPC-3D, budoucí FPC5 pro T4000v5, IPFIXHardware (trio chipset), tzv vložený tokIPv6 vyžaduje JUNOS 11.4R2 (cíl zadního portu), podpora MPLS neznámá, MPC3E vyloučeno do 12.3, nesprávné pole času zahájení způsobující nesprávný výsledek propustnosti dat [8]
Alcatel-Lucent směrovače7750SRv5, v8, v9, v10 IPFIXSoftware běžící na modulu centrálního procesoruIPv6 nebo MPLS pomocí linkových karet IOM3 nebo lepší
Huawei směrovačeNE5000E NE40E / X NE80Ev5, v9Software běžící na servisních kartáchPodpora pro IPv6 nebo MPLS není známa
Enterasys PřepínačeSérie[9] a N-Serie[10]v5, v9Vyhrazený hardwarePodpora protokolu IPv6 není známa
Flowmon SondyFlowmon Sonda 1000, 2000, 4000, 6000, 10000, 20000, 40000, 80000, 100000v5, v9, IPFIXSoftwarově nebo hardwarově akcelerovánoKomplexní podpora pro IPv6 a MPLS, rychlost připojení
Nortel PřepínačePřepínač směrovače Ethernet řady 5500 (ERS5510, 5520 a 5530) a 8600 (na bázi šasi)v5, v9, IPFIXSoftware běží na lince CPU CPUKomplexní podpora protokolu IPv6
PC a serveryLinux FreeBSD NetBSD OpenBSDv5, v9, IPFIXSoftware jako fprobe,[11] ipt-netflow,[12] pflow,[13], flowd[14], Netgraph ng_netflow[15] nebo softflowdPodpora protokolu IPv6 závisí na použitém softwaru
Servery VMwarevSphere 5.x[16]v5, IPFIX (> 5.1)[17]SoftwarePodpora protokolu IPv6 není známa
Mikrotik RouterOSRouterOS 3.x, 4.x, 5.x, 6.x [18]v1, v5, v9, IPFIX (> 6,36RC3)Software a hardware směrovačeProtokol IPv6 je podporován v9. RouterOS aktuálně neobsahuje čísla BGP AS.

Varianty

Protokolování událostí NetFlow od společnosti Cisco

Představeno se spuštěním Cisco ASA 5580 produktů, Protokolování událostí zabezpečení NetFlow využívá pole a šablony NetFlow v9 k efektivnímu poskytování telemetrie zabezpečení ve vysoce výkonných prostředích. Protokolování událostí zabezpečení NetFlow má lepší měřítko než syslog a zároveň nabízí stejnou úroveň podrobností a podrobnosti v protokolovaných událostech.[Citace je zapotřebí ]

Monitorování na základě samostatných sond

Architektura NetFlow pomocí samostatných sond.

Sběr NetFlow pomocí samostatných sond NetFlow je alternativou ke sběru toku ze směrovačů a přepínačů. Tento přístup může překonat některá omezení monitorování NetFlow pomocí routeru. Sondy jsou transparentně připojeny k monitorovanému spoji jako pasivní zařízení pomocí portu TAP nebo SPAN zařízení.

Historicky je monitorování NetFlow snadnější implementovat ve vyhrazené sondě než ve směrovači. Tento přístup má však také některé nevýhody:

  • sondy musí být nasazeny na každém odkazu, který musí být dodržen, což způsobuje další náklady na hardware, nastavení a údržbu.
  • sondy nebudou hlásit samostatné informace o vstupním a výstupním rozhraní, jako by to byla zpráva z routeru.
  • sondy mohou mít problémy se spolehlivým hlášením polí NetFlow souvisejících se směrováním, jako AS čísla nebo IP masky, protože lze jen stěží očekávat, že budou používat přesně stejné informace o směrování jako směrovač.

Nejjednodušší způsob, jak vyřešit výše uvedené nevýhody, je použít a zařízení pro snímání paketů inline před routerem a zachytit veškerý výstup NetFlow z routeru. Tato metoda umožňuje ukládání velkého množství dat NetFlow (obvykle dat po mnoho let) a nevyžaduje rekonfiguraci sítě.

Sběr NetFlow od vyhrazených sond je vhodný pro sledování kritických spojů, zatímco NetFlow na směrovačích poskytuje síťový pohled na provoz, který lze použít pro plánování kapacity, účetnictví, monitorování výkonu a zabezpečení.

Dějiny

NetFlow byla původně technologie přepínání paketů Cisco pro směrovače Cisco, implementovaná v IOS 11.x kolem roku 1996. Původně se jednalo o softwarovou implementaci pro Cisco 7000, 7200 a 7500,[19] kde to bylo považováno za vylepšení oproti tehdy aktuálnímu Cisco Fast Switching. Netflow vynalezli Darren Kerr a Barry Bruin [20]od společnosti Cisco (americký patent č. 6 243 667).

Myšlenka byla, že první paket toku vytvoří záznam přepínání NetFlow. Tento záznam by pak byl použit pro všechny pozdější pakety stejného toku, dokud nevyprší tok. Pouze první paket toku by vyžadoval prozkoumání směrovací tabulky, aby se našla nejkonkrétnější shodná trasa. Jedná se o nákladnou operaci v softwarových implementacích, zejména těch starých bez Přeposílání informační základny. Záznam přepínání NetFlow byl ve skutečnosti nějaký druh záznamu mezipaměti trasy a staré verze IOS stále odkazují na mezipaměť NetFlow jako mezipaměť trasy IP.

Tato technologie byla pro místní sítě výhodná. To platilo zejména v případě, že část provozu musela být filtrována pomocí ACL protože ACL musel vyhodnotit pouze první paket toku.[21]

Přepínání NetFlow se brzy ukázalo jako nevhodné pro velké směrovače, zejména pro páteřní internetové směrovače, kde byl počet současných toků mnohem důležitější než v místních sítích a kde některý provoz způsobuje mnoho krátkodobých toků, například Domain Name System požadavky (jejichž zdrojový port je z bezpečnostních důvodů náhodný).

Jako přepínací technologie byl NetFlow nahrazen kolem roku 1995 Přeposílání Cisco Express. To se poprvé objevilo na směrovačích Cisco 12000 a později nahradilo přepínání NetFlow na pokročilém IOS pro Cisco 7200 a Cisco 7500.

Od roku 2012 se technologie podobné přepínání NetFlow stále používají ve většině bran firewall a softwarových směrovačů IP. Například funkce conntrack z Netfilter rámec používaný Linux.

Viz také

Reference

  1. ^ Hofstede, Rick; Čeleda, Pavel; Trammell, Brian; Drago, Idilio; Sadre, Ramin; Sperotto, Anna; Pras, Aiko (2014). „Vysvětlení monitorování toku: Od zachycování paketů po analýzu dat pomocí NetFlow a IPFIX“. Průzkumy a návody pro komunikaci IEEE. 16 (4): 2037–2064. doi:10.1109 / COMST.2014.2321898.
  2. ^ https://pliki.ip-sa.pl/wiki/Wiki.jsp?page=NetFlow
  3. ^ „Ochranné známky společnosti Cisco“.
  4. ^ „Produkty sFlow: Síťová zařízení“. sFlow.org.
  5. ^ https://github.com/adsr/flow-tools
  6. ^ https://github.com/adsr/flow-tools/blob/master/README
  7. ^ „Vlastnosti produktu Cisco RSP720 Sup720 NetFlow“. cisco.com. Červenec 2010. Citováno 2012-03-08.
  8. ^ "pps a bps nesprávné na Juniper j-flow". Srpna 2012. Citováno 2016-03-17.
  9. ^ "NetFlow na Enterasys S-Serie" (PDF). enterasys.com. Únor 2012. Citováno 2012-03-04.
  10. ^ "NetFlow na Enterasys N-Serie" (PDF). enterasys.com. Únor 2012. Citováno 2012-03-04.
  11. ^ "fprobe".
  12. ^ „ipt-netflow“.
  13. ^ Henning Brauer; Joerg Goltermann (29.03.2014). "pflow - rozhraní jádra pro export dat pflow". BSD Cross Rererence. OpenBSD. Citováno 2019-08-09. Shrnutí ležel.
  14. ^ "flowd-0.9.1.20140828 - sběrač NetFlow". Porty OpenBSD. 2019-07-17. Citováno 2019-08-09.
  15. ^ Gleb Smirnoff (2005). „ng_netflow - implementace Cisco NetFlow“. BSD Cross Rererence. FreeBSD. Citováno 2019-08-09. Shrnutí ležel.
  16. ^ http://blogs.vmware.com/networking/2011/08/vsphere-5-new-networking-features-netflow.html
  17. ^ http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-51-Network-Technical-Whitepaper.pdf
  18. ^ http://wiki.mikrotik.com/wiki/Manual:IP/Traffic_Flow
  19. ^ http://www.cisco.com/en/US/docs/ios/11_2/feature/guide/netflow.html
  20. ^ https://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_presentation0900aecd80311f49.pdf
  21. ^ NetFlow, sFlow a Flow Extensibility, část 1
  22. ^ Phaal, Peter; Lavine, Marc (červenec 2004). „sFlow verze 5“. sFlow.org. Citováno 2010-10-23.

externí odkazy