Üdv,
Volna egy nagyobbacska (kb 10 db /24-es alháló) hálózat, ahol a routereken átmenő forgalmat
per IP alapon monitorozni kellene. Tekintve, hogy Mikrotik CCR 1009 routerekből és Dell managelhető
switchekből álló hálózatról van szó nem okoz problémát a csomagok átadása egy dedikált portra
feldolgozásra/elemzésre. (aka. port mirroring switchen/mikrotiken vagy traffic-flow/netflow a mikrotiken)
Utólag felmerült az esetleges IDS elemzés is csak hogy tuti legyen a dolog. :D
Pár kört már futottam a témában és találtam is használhatónak tűnő megoldást...
A kérdés az volna, hogy tudtok-e esetleg jobbat.
- 1. Mikrotik / Simple queue + Graph
Kipróbáltam, működik egyenlőre túl nagy CPU overhead-et nem mértem,
de nem is volt túl nagy forgalom rajta. Valószínűsítem, hogy a PPS emelkedésével
nem elhanyagolható méretben nőne a CPU terhelés is, amit nem szeretnék.
További hátránya, hogy semmiféle figyelmeztetést nem tud küldeni max scriptelgetve. - 2. Mikrotik / Simple queue + nagios/icinga v. cacti
A grafikonozás feladatát levettük a Mikrotikről de azért így is sok lehet az a 2500+ queue. - 3. Mikrotik / traffic-flow + ntopng
A router mentesült a legtöbb feladatától és egy dedikált gép végzi az elemzést. Egész szimpatikus.
Figyelmeztetést ez se küld persze de legalább a forgalmakat és statisztikákat ehető formában adja.
IDS funkciója persze nincs. - 4. Mikrotik / port mirror + ntopng + IDS
Ntopng és az IDS becsücsül szépen egy dedikált gépen promisc módba és teszi a dolgát.
Grafikonok vannak / statisztika okés / figyelmeztetés ha nagy forgalom van .... na az nincs.
Viszont van némi IDS funkcióra lehetőség mondjuk Snort vagy más hasonló termék segítségével.
Nekem eddig a 4. megoldás tűnt az életképesnek és használhatónak.
Morfondírozok még a mostanában egyre "trendibb" ELK megoldásokon is.
Még IDS rendszerből is van egész használható és pofás.
https://www.stamus-networks.com/open-source/#selks
ui: tudom rendszergazdának elég a konzol is, de a megoldás nem rendszergazdának kell hanem
egyszeri üzemeltetőnek, aki könnyen átláthatóan akarja az adatokat és nem fekete háttéren/szuperzőőőd betűvel :D Eyecandy forewer :D
- 7029 megtekintés
Hozzászólások
sub
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+++++
- A hozzászóláshoz be kell jelentkezni
Előre szólok: Mikrotiket annyira nem ismerem.
Szerintem ez a port mirror/netflow megoldás nem előnyös, ha az aggregált forgalom eléri/meghaladja 1 port áteresztőképességét. A 4. megoldás ésszerűnek tűnik. Kérdésem, hogy mit értel nagy forgalom alatt (csomag/mp, bit/mp, router cpu terhelés stb.)? Ezekről riasztást tudsz küldeni e-mailben SNMP-t felhasználva.
- A hozzászóláshoz be kell jelentkezni
Az aggregált forgalom miatt nem kell aggódni egyenlőre mivel 1G-s lábon 100M uplink lóg.
Nagy forgalom alatt pedig kimondottan azt értem ha mondjuk egy vírusos gép elkezd kifele szemetelni.
Mondjuk elpukkant egy szolíd DOS-t valami külső IP cím felé vagy kintről indítanak befelé valami csúnyát.
- A hozzászóláshoz be kell jelentkezni
MRTG esetleg?
Vagy ha Tik, akkor Dude? Szép színes, meg minden. :D
- A hozzászóláshoz be kell jelentkezni
Dude, Cacti, Pnp4nagios....mindnek ugyanaz a gondja....
Script eredményét, SNMP OID értékét monitoroz tehát alaphelyzetben
az ethernet interface a legnagyobb felbontás, amit tudnak.
Itt pedig pont az lenne a cél, hogy lássa az üzemeltető pontosan ha
XYZ IP címről nem megszokott mértékű forgalom áramlik és sajnos
egy interfacen több IP cím is csücsülhet.
Az MRTG-t nem használtam sose de ahogy elnézem kb ugyanazt tudja mint a fenti 3.
---
Ha le kéne egyszerűsíteni a feladatot akkor olyan mintha egy internet
szolgáltató akarja számlálni és grafikonozni az ügyfelei forgalmát vagy
mondjuk egy hosting cég akarja IP alapon monitorozni a forgalmat az ügyfeleinél.
pl: digitalocean a VPS szerverein is a csomaghoz mérten limitálja a havi forgalmat.
Ennél jobb példákat nem tudok mondani.
- A hozzászóláshoz be kell jelentkezni
Pl ilyen uzentet szeretnel latni? Outbound Congestion.
Zabbix eseten: 8*{Template SNMP Network Device Interfaces:ifOutOctets[{#SNMPVALUE}].last()}/{Template SNMP Network Device Interfaces:ifSpeed[{#SNMPVALUE}].last()}>0.8
- A hozzászóláshoz be kell jelentkezni
Valami hasonlót de mint mondottam volt az interface felbontás kevés sajnos. Egyedi IP cím felbontás kell.
Ezért hullottak el a "szokásos" megoldások.... mindnek a legkisebb felbontás az interface.
Azzal egyik se tudott mit kezdeni, hogy az interfacen lóg 3 db /24-es vlan és azok közül 1 db IP címmel van gond.
- A hozzászóláshoz be kell jelentkezni
Azt hittem 1kliens/port az osszerendeles, ha van olyan ahol ettol elter, akkor a fenti megoldas nem jo. Marad flow-s megoldas.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Nálunk a core-router portja van tükrözve a suricata-nak. Valamin a core-switch sflow-t küldi a collectornak ami ebben az esetben traffic sentinel. Persze ezen kivul meg van a szokasos snmp a fobb portokra, csomopontokra.
Itt emlitettem: http://hup.hu/node/139379#comment-1847174
Fedora 21, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
én traffic flow-t használnék mérésre.
Ha igazán tutit akarsz, akkor a router elé teszel egy switchet, ami képes L3 szűrésre, így flood esetén
az adott IP már nem éri el a routert - mindezt ASIC-ból.
Uez a switch lehet flow collector is.
Az egy másik kérdés, hogy a CCR mit kezd a 2500 queue-val. (nem tudom)
- A hozzászóláshoz be kell jelentkezni
Próbaképpen felhúztam 500 Simple queue-t a CCR-re és eddig nem dobott hátast tőle..... eddig....
Persze terhelés jelenleg túró így nem is releváns az adat.
Az biztos, hogy core router-t nem ezzel terhelnék. Nem ez a feladata.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
az ? behal tole :D
nekunk 36 magos van koncentratornak, es mikor ~1000 koruli queue volt mivel pppoe koncentrator igencsak elkezdtek leesni a savszelessegek, ugraltak stb. kenytelenek voltunk maskepp megoldani a savszelkorlatozast.
Fedora 21, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
ha jól tippelek, akkor queueing esetén előnyösebb egy sok MHz-el bíró (x86) masina, mint egy nagyon sokmagos valami.
- A hozzászóláshoz be kell jelentkezni
mikrotiknal mindenkepp :>
Sajnos odaig nem jutottam hogy sima linux IMQ-val dobjak össze egy teszt koncentrátort. Mivel x86-on is gyengebb a mikrotik mint egy mezei linux. Eddigi tapasztalataim szerint.
Fedora 21, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni