Problemy z funkcją „flow-export active-refresh interval” w urządzeniach Cisco ASA
![[Image: cisco-asa-netflow-flow-export-active-ref...oblems.png]](http://it.emca.pl/images/stories/2013/forum/cisco-asa-netflow-flow-export-active-refresh-interval-problems.png)
Jeśli właśnie zaktualizowałeś oprogramowanie Cisco ASA i natrafiłeś na problemy z funkcją „flow-export active-refresh interval”, to nie jesteś osamotniony z tym problemem. Sprawa dotyczy wersji 8.5(1), 8.6(1), 8.7(1), 9.0(1) oraz 9.1(1). Co ciekawe, w tych wersjach pojawiło się jednocześnie wiele przydatnych funkcji z zakresu Netflow Security Event Logging (NSEL). Więc o co tu chodzi?
Najwyraźniej funkcjonalność związana z dwukierunkowym przesyłem strumieni oraz możliwość wykorzystania komendy „flow-export active refresh-interval” (interwał 1 minuta) zostały w jakiś sposób pominięte w nowszych wersjach softu Cisco. Warto wiedzieć, do czego te rzeczy służą:
Dwukierunkowy NetFlow: Większość rozwiązań bazujących na protokołach NetFlow lub IPFIX jest jednokierunkowa. Oznacza to, że połączenie TCP między dwoma hostami skutkuje dwoma strumieniami – np. A do B i z B do A. Brzmi to mało wydajnie, ale już wyjaśniam dlaczego musi tak być. Otóż generalnie oprogramowanie do analizy strumieni działa tak, że jest w stanie obsłużyć jeden strumień na jednym interfejsie. Stąd dwa strumienie – dla połączeń przychodzących i wychodzących. A powinno być tak, że obsługa strumieni dwukierunkowych jest zaimplementowania w oprogramowaniu zgodnie ze standardem RFC 5103, gdzie jeden strumień reprezentuje przepływ z A do B i jednocześnie z B do A. Naturalnie rozmiar takiego strumienia się podwaja, ale jednocześnie ilość strumieni jest dwukrotnie mniejsza, co ma znaczenie przy analizatorach obsługujących dużą ilość strumieni NetFlow. Jak dotąd, jedynie SonicWall IPFIX jest jedynym dostawcą, który wprowadził standard DFC 5103.
Cisco ASA natomiast wprowadził zamieszanie w wersjach softu powyżej 8.4(5). Nowsze wersje bowiem owszem, eksportują w jednym strumieniu informacje o przesyle w obie strony, ale podają informację o łącznej ilości danych przesłanych w obie strony. Nie dowiemy się natomiast, ile było wysłane z A do B, a ile z B do A.
Komenda "flow-export active refresh-interval": eksportery NetFlow posiadają funkcję określającą jak często strumień jest wysyłany do analizatora NetFlow. W przypadku ruterów Cisco jest to komenda „ip flow-cache timeout active”. Z kolei w Cisco ASA NetFlow jest to „flow-export active-refresh interval”. Problem w tym, że ta komenda jest dostępna tylko dla wersji Cisco ASA v8.4(5). We wszystkich innych wersjach eksport strumienia następuje dopiero po zakończeniu konwersacji. Staje się to problematyczne przy długich, ciągłych strumieniach. Trzeba wówczas czekać, aż tzw. tunel zostanie przerwany i wówczas eksportować dużą ilość danych za jednym razem, zamiast robić to co np. minutę. Na szczęście wieści z Cisco są takie, że komenda flow-export active refresh-interval będzie ponownie wprowadzona do wersji ASA v9.1(2).
Jeszcze słowo o dwukierunkowym NetFlow. Cisco ASA był pierwszym firewall-em który miał funkcję eksportera NetFlow, ale na rynku są też inni dostawcy podobnych rozwiązań. Dell SonicWALL i firewall-e firmy Palo Alto Networks również obsługują dwukierunkowy NetFlow. W przypadku SonicWALL akurat jest standard IPFIX który jest nieco innym standardem. Może też spotkać się z firewall-em Fortinet z eksporterem sFlow, jak również Barracudą ze wsparciem IPFIX.
Jak widać, Cisco ASA był pierwszy na rynku, ale od tego czasu konkurencja nie próżnuje. Inni producenci oferują w większości również bogate funkcje w zakresie informacji kontekstowych strumieni, takich jak nazwa użytkownika, status ACL (lista kontroli dostępu), adres MAC itd. Zaznaczam - „większość” dostawców, ponieważ np. eksporter sFlow Fortinet takich informacji nie podaje, a do tego jego dokładność jest problematyczna z uwagi na to, że strumień jest próbkowany.
Jeśli natrafiliście na problemy podobne do opisanych, zapraszamy do dyskusji.
Paul@PLIXER
Link do oryginalnego postu.
Jeśli właśnie zaktualizowałeś oprogramowanie Cisco ASA i natrafiłeś na problemy z funkcją „flow-export active-refresh interval”, to nie jesteś osamotniony z tym problemem. Sprawa dotyczy wersji 8.5(1), 8.6(1), 8.7(1), 9.0(1) oraz 9.1(1). Co ciekawe, w tych wersjach pojawiło się jednocześnie wiele przydatnych funkcji z zakresu Netflow Security Event Logging (NSEL). Więc o co tu chodzi?
Quote:NSEL – wyjaśnienie
Funkcja „flow update” została stworzona po to, by móc okresowo zliczać bajty w danym strumieniu. Można ten okres (interwał) wydłużać lub skracać. Można również ustalić do jakiego analizatora zostanie wysłany strumień danych w jakim rozmiarze. W naszym oprogramowaniu występuję komenda „flow-export active refresh-interval”. Jest ona modyfikacją następującej komendy: „flow-export event-type”. Zaznaczam, że nasza funkcja nie jest dostępna w następujących wersjach oprogramowania Cisco ASA: 8.5(1), 8.6(1), 8.7(1), 9.0(1) oraz 9.1(1).
Najwyraźniej funkcjonalność związana z dwukierunkowym przesyłem strumieni oraz możliwość wykorzystania komendy „flow-export active refresh-interval” (interwał 1 minuta) zostały w jakiś sposób pominięte w nowszych wersjach softu Cisco. Warto wiedzieć, do czego te rzeczy służą:
Dwukierunkowy NetFlow: Większość rozwiązań bazujących na protokołach NetFlow lub IPFIX jest jednokierunkowa. Oznacza to, że połączenie TCP między dwoma hostami skutkuje dwoma strumieniami – np. A do B i z B do A. Brzmi to mało wydajnie, ale już wyjaśniam dlaczego musi tak być. Otóż generalnie oprogramowanie do analizy strumieni działa tak, że jest w stanie obsłużyć jeden strumień na jednym interfejsie. Stąd dwa strumienie – dla połączeń przychodzących i wychodzących. A powinno być tak, że obsługa strumieni dwukierunkowych jest zaimplementowania w oprogramowaniu zgodnie ze standardem RFC 5103, gdzie jeden strumień reprezentuje przepływ z A do B i jednocześnie z B do A. Naturalnie rozmiar takiego strumienia się podwaja, ale jednocześnie ilość strumieni jest dwukrotnie mniejsza, co ma znaczenie przy analizatorach obsługujących dużą ilość strumieni NetFlow. Jak dotąd, jedynie SonicWall IPFIX jest jedynym dostawcą, który wprowadził standard DFC 5103.
Cisco ASA natomiast wprowadził zamieszanie w wersjach softu powyżej 8.4(5). Nowsze wersje bowiem owszem, eksportują w jednym strumieniu informacje o przesyle w obie strony, ale podają informację o łącznej ilości danych przesłanych w obie strony. Nie dowiemy się natomiast, ile było wysłane z A do B, a ile z B do A.
Komenda "flow-export active refresh-interval": eksportery NetFlow posiadają funkcję określającą jak często strumień jest wysyłany do analizatora NetFlow. W przypadku ruterów Cisco jest to komenda „ip flow-cache timeout active”. Z kolei w Cisco ASA NetFlow jest to „flow-export active-refresh interval”. Problem w tym, że ta komenda jest dostępna tylko dla wersji Cisco ASA v8.4(5). We wszystkich innych wersjach eksport strumienia następuje dopiero po zakończeniu konwersacji. Staje się to problematyczne przy długich, ciągłych strumieniach. Trzeba wówczas czekać, aż tzw. tunel zostanie przerwany i wówczas eksportować dużą ilość danych za jednym razem, zamiast robić to co np. minutę. Na szczęście wieści z Cisco są takie, że komenda flow-export active refresh-interval będzie ponownie wprowadzona do wersji ASA v9.1(2).
Jeszcze słowo o dwukierunkowym NetFlow. Cisco ASA był pierwszym firewall-em który miał funkcję eksportera NetFlow, ale na rynku są też inni dostawcy podobnych rozwiązań. Dell SonicWALL i firewall-e firmy Palo Alto Networks również obsługują dwukierunkowy NetFlow. W przypadku SonicWALL akurat jest standard IPFIX który jest nieco innym standardem. Może też spotkać się z firewall-em Fortinet z eksporterem sFlow, jak również Barracudą ze wsparciem IPFIX.
Jak widać, Cisco ASA był pierwszy na rynku, ale od tego czasu konkurencja nie próżnuje. Inni producenci oferują w większości również bogate funkcje w zakresie informacji kontekstowych strumieni, takich jak nazwa użytkownika, status ACL (lista kontroli dostępu), adres MAC itd. Zaznaczam - „większość” dostawców, ponieważ np. eksporter sFlow Fortinet takich informacji nie podaje, a do tego jego dokładność jest problematyczna z uwagi na to, że strumień jest próbkowany.
Jeśli natrafiliście na problemy podobne do opisanych, zapraszamy do dyskusji.
Paul@PLIXER
Link do oryginalnego postu.
