Instrukcja konfiguracji i obsługi NfSen na przykładzie ISP i retencji danych.
Retencja danych. Pojęcie z którym zna się każdy ISP. Wiemy, że musimy logować ale nie zawsze wiemy jak. Wiem że wielu z Was używa np. sysloga i zapisuje wszystko w plikach tekstowych. Rozwiązanie się sprawdza, ale wyszukiwanie i ogranizacja tych logów bywa kłopotliwa. Poza tym pojawia się problem z urządzeniami, które nie potrafią logować do zewnętrznego sysloga. Rozwiązaniem może być netflow.
Netflow, to protokół opracowany przez Cisco. Krótko mówiąc są to informacje o strumieniu danych, przepływających przez router czy inne urządzenie sieciowe. Takie dane za pomocą agenta (router) przesyłamy do kolektora gdzie są archiwizowane. Danymi z kolektora możemy operować np. za pomocą interfejsu graficznego. Takim narzędziem jest NfSen czyli graficzna nakładka na popularne oprogramowanie NfDump. NfDump to natomiast zbiór oprogramowania służący do gromadzenia i operowania na danych netflow.
Instalacja NfSen i NfDump
NfSen choć jest już trochę „czerstwym” oprogramowaniem, to świetnie sprawdza się do tego co potrzebujemy jako ISP. Jak to wygląda i jak wykorzystać w praktyce? Zacznijmy od przygotowania systemu. Ja do tego celu wybrałem dystrybucję CentOS. Instalujemy potrzebne pakiety:
yum install epel-release
yum install -y httpd php wget gcc make rrdtool-devel rrdtool-perl perl-MailTools perl-Socket6 flex byacc perl-Sys-Syslog perl-Data-Dumper
Następnie instalujemy NfDump. Istotne jest aby nasza wersja wspierała NSEL/NEL. Bez tego nie będziemy mieli informacji o translacjach NAT. W przypadku kompilacji NfDump ze źródeł, trzeba użyć odpowiedniego parametru podczas kompilacji np:
./configure --enable-nfpcapd --enable-readpcap --enable-sflow --enable-nftrack --enable-nsel --enable-nel
W CentOS pakiet rpm NfDump posiada już odpowiednie moduły:
[root@localhost support]# rpm -q -i nfdump Name : nfdump Version : 1.6.17 Release : 1.el7 Architecture: x86_64 Install Date: śro, 28 sie 2019, 14:06:42 Group : Applications/System Size : 779849 License : BSD and GPLv2+ Signature : RSA/SHA256, pon, 30 kwi 2018, 01:16:31, Key ID 6a2faea2352c64e5 Source RPM : nfdump-1.6.17-1.el7.src.rpm Build Date : pon, 30 kwi 2018, 00:17:11 Build Host : buildhw-02.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : https://github.com/phaag/nfdump Bug URL : https://bugz.fedoraproject.org/nfdump Summary : NetFlow collecting and processing tools Description : Nfdump is a set of tools to collect and process NetFlow data. It's fast and has a powerful filter pcap like syntax. It supports NetFlow versions v1, v5, v7, v9 and IPFIX as well as a limited set of sflow. It includes support for CISCO ASA (NSEL) and CISCO NAT (NEL) devices which export event logging records as v9 flows. Nfdump is fully IPv6 compatible.
Wystarczy wiec zainstalować pakiet:
yum install nfdump
Dodajemy użytkownika netflow:
useradd netflow usermod -a -G apache netflow
Tworzymy katalogi dla nfsen:
mkdir -p /data/nfsen mkdir -p /opt/nfsen mkdir -p /var/www/html/nfsen
Uruchamiamy serwer www:
systemctl enable httpd systemctl start httpd
Pobieramy teraz NfSen, rozpakowujemy i kopiujemy plik konfiguracyjny:
wget https://sourceforge.net/projects/nfsen/files/stable/nfsen-1.3.8/nfsen-1.3.8.tar.gz tar xf nfsen-1.3.8.tar.gz cp nfsen-1.3.8/etc/nfsen-dist.conf /opt/nfsen/nfsen.conf
Przechodzimy do edycji pliku /opt/nfsen/nfsen.conf. Upewniamy się czy ścieżki do katalogów są poprawne, ewentualnie zmieniamy je pod swoją konfigurację:
$BASEDIR = "/data/nfsen"; [...] $HTMLDIR = "/var/www/html/nfsen/"; [...] $PREFIX = '/usr/bin';
W moim wypadku musiałem również zmienić użytkownika, który ma uprawnienia do zarządzania serwerem www:
$WWWUSER = "apache"; $WWWGROUP = "apache";
Warto odhaszować poniższą linijkę:
$EXTENSIONS = 'all';
Teraz przechodzimy do konfiguracji źródeł naszych danych. Poniżej przykład z Cisco ASR1001-X, gdzie osobno zbieram dane wejściowe, wyjściowe z routera oraz informacje o NAT:
%sources = (
'IN' => { 'port' => '9995', 'col' => '#0000ff', 'type' => 'netflow' },
'OUT' => { 'port' => '9996', 'col' => '#000fff', 'type' => 'netflow' },
'NAT' => { 'port' => '9997', 'col' => '#00ffff', 'type' => 'netflow' },
W przypadku Mikrotika zbieram całość w jednym źródle:
%sources = (
'MT' => { 'port' => '9996', 'col' => '#0000ff', 'type' => 'netflow' },
Po przygotowaniu pliku konfiguracyjnego możemy zainstalować NfSen. Wchodzimy do katalogu w którym rozpakowaliśmy pobrane wcześniej źródła i wykonujemy polecenie:
./install.pl /opt/nfsen/nfsen.conf
Tworzymy plik startowy:
vi /etc/init.d/nfsen
Do którego wklejamy zawartość:
#!/bin/bash
DAEMON=/data/nfsen/bin/nfsen
case "$1" in
start)
$DAEMON start
;;
stop)
$DAEMON stop
;;
status)
$DAEMON status
;;
restart)
$DAEMON stop
sleep 1
$DAEMON start
;;
*)
echo "Usage: $0 {start|stop|status|restart}"
exit 1
;;
esac
exit 0
Sprawdzamy czy działa:
chmod +x /etc/init.d/nfsen /etc/init.d/nfsen start
Jeżeli wszystko się udało, to pod linkiem http://192.168.10.100/nfsen/nfsen.php powinniśmy zobaczyć interfejs NfSen.
Dostęp do panelu www nie wymaga autoryzacji. Możemy to zmienić. Do pliku /etc/httpd/conf/httpd.conf dodajemy:
AllowOverride AuthConfig (zamiast AllowOverride None)
Następnie tworzymy użytkownika i nadajemy hasło:
htpasswd -c /etc/httpd/.htpasswd user1 New password: Re-type new password: chown apache:apache /etc/httpd/.htpasswd chmod 0660 /etc/httpd/.htpasswd
I edytujemy plik /var/www/html/.htaccess
AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/httpd/.htpasswd Require valid-user
Na koniec restartujemy usługę httpd:
systemctl restart httpd
Konfiguracja routerów
Poniżej przykład dla Cisco ASR1001-X odpowiadający powyższej konfiguracji NfSen. Zaczynamy od konfiguracji flow exportera i flow monitora:
flow exporter FLOW_EXP_IN destination 192.168.10.100 transport udp 9995 ! ! flow exporter FLOW_EXP_OUT destination 192.168.10.100 transport udp 9996 ! ! flow monitor FLOW_MON-IN exporter FLOW_EXP_IN record netflow ipv4 original-input ! ! flow monitor FLOW_MON-OUT exporter FLOW_EXP_OUT record netflow ipv4 original-output !
Flow monitory dodajemy do konkretnych interfejsów np:
interface TenGigabitEthernet0/0/0.4090 description peering:KAT-EPIX-OP encapsulation dot1Q 4090 ip flow monitor FLOW_MON-IN input ip flow monitor FLOW_MON-OUT output
W moim przypadku ASR1001-X również natuje, dlatego potrzebujemy dodatkowo skonfigurować:
ip nat log translations flow-export v9 udp destination 192.168.10.100 9997
W Mikrotiku konfiguracja wygląda tak (vlan 4070 to mój WAN):
/ip traffic-flow set cache-entries=4k enabled=yes interfaces=vlan4070 /ip traffic-flow target add dst-address=192.168.10.100 port=9996 version=9
Powinniśmy na naszym hoście z NfSen widzieć już ruch:
[root@localhost support]# tcpdump -i eth0 -n dst port 9995 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 16:41:27.411143 IP 192.168.10.1.49171 > 192.168.10.100.palace-4: UDP, length 1376 16:41:27.411166 IP 192.168.10.1.49171 > 192.168.10.100.palace-4: UDP, length 1376 16:41:27.411169 IP 192.168.10.1.49171 > 192.168.10.100.palace-4: UDP, length 1376 16:41:27.411171 IP 192.168.10.1.49171 > 192.168.10.100.palace-4: UDP, length 76
Obsługa NfSen
Jeżeli wszystko działa prawidłowo, to cała obsługa sprowadza się tylko do interfejsu www. Interesująca jest dla nas zakładka Graphs, w której mamy wykresy obrazujące ruch z naszych routerów. Widzimy flowy, pakiety i ilość ruchu.
Powyższy screen fajnie obrazuje anomalia w sieci. Te dwa wysokie słupki wczoraj i przedwczoraj to siejący rejestrator CCTV. Tylko na wykresie flow można to było zobaczyć, bo ilość pps wcale nie podniosła wykresu. Tak więc zyskujemy dodatkowe źródło monitoringu naszej sieci.
To co nas najbardziej interesuje jest w zakładce Details. To tutaj będziemy szukać informacji związanych z retencją danych. Załóżmy, że potrzebujemy znaleźć kto wczoraj o godzinie 16:15:00 łączył się z adresem 8.8.8.8 na porcie 53. Ustawiamy sobie na wykresie zakres czasu jaki nas interesuje:
Ja wybrałem przedział 16:10-16:20. Teraz w sekcji Netflow Processing budujemy sobie filtr i wybieramy opcję List Flows:
Jak nie trudno się domyślić, wyników będzie bardzo dużo. Zawęźmy wyniki wiedząc, że publicznym adresem IP z naszej sieci był adres 176.X.X.138. Czyli do naszego filtru dodajemy and src xip 176.X.X.138. W wyniku otrzymujemy następujące dane:
2019-10-20 16:15:00.791 CREATE Ignore UDP 192.168.116.60:60156 -> 8.8.8.8:53 176.X.X.138:60156 -> 8.8.8.8:53
Jak widać powyżej dostajemy informacje o adresie prywatnym, porcie źródłowym, adresie i porcie docelowym, a także o adresie na który był wykonywany NAT. Czyli mamy komplet informacji potrzebny do ustalenia hosta w naszej sieci. Jeszcze inny przykład filtru to szukanie po docelowym adresie IP i porcie źródłowym.
W zakładce Stats możemy określić jak długo chcemy przechowywać dane oraz ewentualnie zmienić kolory wykresów.
Podsumowanie
Jak widać możliwości jakie daje NfDump jest naprawdę sporo, a NfSen mimo, że nie wygląda już zbyt współcześnie, to jest naprawdę wygodnym narzędziem. Jeżeli komuś nie odpowiada NfSen, to cały pakiet NfDump można również obsługiwać z konsoli.
Na koniec jeszcze kilka słów na temat miejsca potrzebnego na dane z kolektora. Przykładowo sieć z ruchem ~700Mb/s generująca ok 700 flows/s w szczycie, potrzebuje dobowo ok 1,2GB danych. Daje nam to rocznie ok 460GB. Przykład sieci ze screenów to już 3,5Gb/s ruchu i ok 6 tysięcy flows/s, tutaj mamy ok 10GB dziennie. Czyli na cały rok potrzebujemy blisko 4TB miejsca. Z pewnością jest to więcej niż w przypadku logów z firewalla, chociaż tak naprawdę wszystko zależy od tego co logujemy.
