Лучшие анализаторы Netflow.

Всем привет.

Системным инженерам и администраторам сетей, постоянно приходится сталкиваться с проблемами, причины которых не всегда очевидны. В этих случаях очень полезным будет провести беглый анализ сетевого трафика. Вашему вниманию представляется обзор лучших анализаторов и коллекторов Netflow, которые помогут значительно упростить нам жизнь.

Анализаторы и коллекторы NetFlow - это очень полезный инструментарий для мониторинга и анализа данных сетевого трафика, который поможет вам обнаружить возможные проблемы еще до того, как они станут реальной угрозой. Анализаторы NetFlow позволят вам определить те машины и устройства, которые негативно влияют на пропускную способность вашей сети, найти узкие места в вашей системе, а также, в конечном счете, повысить общую эффективность функционирования вашей сети.

Само понятие «NetFlow» относится к сетевому протоколу, разработанному компанией Cisco для сбора информации о трафике, проходящем через различные устройства в сети. Существует несколько версий протокола NetFlow (от 1 до 9), часть из которых уже устарели. На данный момент наиболее распространенными являются NetFlow версии 5, 7 и 9. Сейчас NetFlow представляет собой, фактически, промышленный стандарт и поддерживается не только оборудованием Cisco, но и многими другими устройствами от других производителей.

В то же время часть вендоров используют собственные версии NetFlow: к примеру, компания Juniper Networks называет свой протокол J-Flow, у компании Huawei — это NetStream. Несмотря на то, что эти «Flow» имеют разные имена, все они работают аналогичным NetFlow образом, предоставляя, в основном, одну и ту же информацию. Кроме того, на основе NetFlow версии 9 также был разработан открытый универсальный стандарт IPFIX (Internet Protocol Flow Information eXport) для передачи информации об IP-потоках.

Информация, которую собирает из IP-трафика NetFlow, включает в себя:

• IP-адрес источника;
• IP-адрес назначения;
• порт источника для UDP и TCP;
• порт назначения для UDP и TCP;
• тип и код сообщения для ICMP;
• номер интернет-протокола транспортного уровня, инкапсулированного в протокол IP;
• тип обслуживания (Type of Service, ToS);
• сетевой интерфейс.

Собирая и анализируя эту информацию, вы можете много узнать о функционировании вашей сети, а также использовать ее для разных целей, включая мониторинг пропускной способности, устранение неполадок в работе сети и обнаружение аномалий.

Когда в сети реализована поддержка протокола NetFlow, активируется работа двух основных компонентов: Flow Exporter и Flow Collector. Flow Exporter захватывает статистическую информацию о потоке и отправляет ее в коллектор. Он обычно настраивается на устройстве, таком, как маршрутизатор или коммутатор, а в некоторых случаях на одном устройстве используется несколько Flow Exporter для мониторинга разных потоков. Flow Collector получает данные о потоках и сохраняет их. Во многих современных решениях для анализа сетевого трафика функциональность коллектора и анализатора совмещена в одном решении — статистическая информация о потоках не только собирается и сохраняется, но также обрабатывается и анализируется, чтобы представить ее пользователям в удобном для понимания виде. В ряде случае Flow Collector может использоваться просто для получения данных, при этом их анализ осуществляется другим приложением с функциональностью анализатора.

Существует множество программных решений на основе протокола NetFlow, и в рамках этой статьи мы представим вам 5 лучших коммерческих и бесплатных анализаторов и коллекторов NetFlow. Большинство поставщиков программного обеспечения NetFlow, перечисленных ниже, имеют инструкции по включению NetFlow на устройства различных производителей. Кроме того, эта информация также должна содержаться в документации производителя вашего устройства.

Используем Flexible NetFlow.

Всем привет.

Мы уже знаем что NetFlow позволяет нам отслеживать потоки (flow) трафика в сети. Мы можем использовать эту информацию для решения таких проблем, как обнаружение узких мест, определения того, какие приложения используются, какую пропускную способность они используют и т.д.

Flexible NetFlow - это гибкий инструмент мониторинга трафика для задач оптимизации использования ресурсов, планирования производительности сети, определения оптимального уровня обеспечения качества обслуживания (QoS), а также для обнаружения событий сетевой безопасности.

Преимущества Cisco IOS Flexible NetFlow:

• Гибкость и масштабируемость данных о потоках по сравнению с традиционным NetFlow;
• Тонкие настройки идентификации трафика;
• Возможность сосредоточиться и контролировать конкретное сетевое поведение;
• Возможность отслеживать более широкий спектр информации о пакетах, создавая новую информацию о поведении сети;
• Улучшенное обнаружение сетевых аномалий и безопасности;
• Объединение нескольких технологий учета в один учетный механизм.

Компоненты Flexible NetFlow:

• Запись потока (Flow record) - потоки определяются множеством различных фрагментов информации о трафике; информация, используемая Flexible Netflow, может быть определена в пользовательских или стандартных записях.
• Экспортер потока (Flow exporter) -  сервер/ы, на который/которые будет экспортироваться информация о потоках.
• Монитор потока (Flow monitor) - компонент, который используется для обеспечения фактического мониторинга трафика на настроенном интерфейсе. Когда монитор потока применяется к интерфейсу, создается кэш монитора потока, который используется для сбора трафика на основе ключевых (key) и неключевых (nonkey) полей в настроенной записи.
• Шаблон потока (Flow Sampler) используется, когда имеется большой объем трафика для анализа, который потенциально может повлиять на производительность контролируемого устройства. В этой ситуации можно использовать шаблон потока, чтобы ограничить количество пакетов, которые будут анализироваться монитором потока. Например, 1 из каждых 2 пакетов может быть захвачен и проанализирован.

Пользовательские определения по практикуму от SEDICOMM:

CUSTOM-OUT - пользовательская запись исходящего потока

COLLECTOR-HOST - экспортер потока

INBOUND-MONITOR - монитор входящего потока

OUTBOUND-MONITOR - монитор исходящего потока

1. Итак, создадим два вида записей потока: стандартный (ipv4 original-input) и пользовательский (CUSTOM-OUT). Для создания пользовательской записи необходимо выполнить настройки:

flow record CUSTOM-OUT

description Custom Flow Record for outbound traffic

# key items

match ipv4 destination address

match transport destination-port

# no key items

collect counter bytes

collect counter packets

exit

Проверяем:

show flow record CUSTOM-OUT

Netflow и Syslog рядом.

Всем привет.

Для анализа работы сети полезно анализировать трафик проходящий через маршрутизаторы сети. Полагаю у вас есть парочка пограничных Cisco. Сами Cisco придумали технологию NetFlow. NetFlow представляет собой продвинутую систему сбора статистики о трафике на интерфейсах оборудования Cisco. 

Для анализа потоков NetFlow я выбрал NetFlow Analyzer. Система NetFlow Analyzer состоит из http-сервера, работающего по умолчанию на порту TCP 8080, к нему подсоединяются браузером для просмотра отчётов и администрирования, и сервера для сбора статистики, работающего по умолчанию на порту UDP 9996. 

Для того чтобы сервер смог собирать статистику с оборудования прежде всего на каждом из устройств Cisco нужно настроить NetFlow-экспорт данных трафика. Эта процедура состоит из двух шагов.

1. На каждом сетевом интерфейсе, с которого будет осуществляться сбор статистики, нужно прописать следующее (предполагается, что мы уже зашли командами conf t/ interface {interface} {interface_number}):

router(conf-if)#ip route-cache flow

router(conf-if)#bandwidth

router(conf-if)#exit

Лучше всего сконфигурировать это сразу на двух интерфейсах роутера, тогда ManageEngine NetFlow Analyzer будет корректно показывать и входящий, и исходящий трафик. Команда bandwidth, указывающая пропускную способность в килобитах/сек не обязательна, но желательна - она используется  в дальнейшем для построения %-ных отчётов и графиков загрузки канала интерфейса.

2. Настройка для роутера в целом сервера сбора трафика  на сервер на котором пашет NetFlow Analyzer. Для этого в конфигурацию добавляются следующие команды:

router(config)#ip flow-export destination 192.168.1.10 9996

Здесь 192.168.1.10 как раз указывают на мой сервер NetFlow Analyzer.

router(config)#ip flow-export version 5

При этом можно использовать параллельно и общепринятый трансфер логов в Syslog сервер. Настройка Syslog-логирования в Cisco не менее простая.

router#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

router(config)#logging trap ?

  <0-7>          Logging severity level

  alerts         Immediate action needed           (severity=1)

  critical       Critical conditions               (severity=2)

  debugging      Debugging messages                (severity=7)

  emergencies    System is unusable                (severity=0)

  errors         Error conditions                  (severity=3)

  informational  Informational messages            (severity=6)

  notifications  Normal but significant conditions (severity=5)

  warnings       Warning conditions                (severity=4)

router(config)#logging trap debugging

Можно указать другой уровень логирования, например только ошибки 3.

router(config)#logging facility local2

Желательно чтобы local2 был свободен на сервере Syslog-a.

router(config)#logging 192.168.1.11

Здесь 192.168.1.11 как раз указывают на мой сервер Syslog-a. Для теста я взял простой Visual Syslog Server.

router(config)#exit

Теперь собираем информацию по нашим маршрутизаторам, строим отчеты, анализируем. На сегодня все.

Мощное средство Cisco NBAR.

Всем привет.

До недавних пор считалось что анализировать сеть с помощью NetFlow - это вполне современно и функционально. Действительно, анализизаторы NetFlow многими считаются полезными инструментами для мониторинга и анализа сетевого трафика. Анализаторы NetFlow позволяют вам определить те машины и устройства, которые негативно влияют на пропускную способность вашей сети, найти узкие места в вашей системе, а также, в конечном счете, повысить общую эффективность функционирования вашей сети.

Напомню как можно задействовать  сбор данных в критических точках для обнаружения угроз в исходящем сетевом трафике через Cisco NetFlow. 

Шаблон для IOS системы:

 # conf t

(config)# mls netflow interface

(config)# mls flow ip interface-full

(config)# ip flow-export source <interface x/x>

(config)# ip flow-export version <#>

(config)# ip flow-export destination <ip address | esl record> <port>

(config-int)# ip flow ingress

#

Шаблон для NX-OS:

# conf t

(config)# feature netflow

(config)# flow record <record-name>

(config)# match ip ipv4 source address

(config)# match ip ipv4 destination address

!

(config)# flow exporter <exporter-name>

(config)# destination <ip address | esl-record>

(config)# transport UDP 2055

(config)# version <#>

(config)# source <interface>

(config)# flow monitor <monitor-name>

(config)# record <record-name>

(config)# exporter <exporter-name>

(config-int)# ip flow monitor <monitor-name> input

(config)# end

#

Дублирование netflow и syslog-событий на два адреса.

Всем привет.

Повторение - мать учения. Или мучения, а кому как. Так вот, на днях поступила команда где с маршрутизатора Cisсo в срочном порядке надо перевести все события на новый NetFlow-сервер.

В приницпе с этим не должно возникнуть никаких проблем. Я об этом писал ранее.

Но меня вчера заинтересовал вопрос возможности дублирования как syslog-событий так и netflow на два, или больше, адреса (сервера). Так как старый log-сервер у нас продолжал успешно работать как и раньше.

Оказалось что для  Cisсo надо просто указать адресацию повторно той же командой (веделено жирным шрифтом). Но всем на заметку пишу весь блок команд для настройки  syslog и netflow протоколов.

# Syslog ################################

Отправка логов на syslog сервер:

Asa53xx231#conf t

Asa53xx231(config)#logging facility local0

Asa53xx231(config)#logging host server1

Asa53xx231(config)#logging host server2

Asa53xx231(config)#exit

ИЛИ

Asa53xx231#conf t

Asa53xx231(config)#logging trap ?

  <0-7>          Logging severity level

  alerts         Immediate action needed           (severity=1)

  critical       Critical conditions               (severity=2)

  debugging      Debugging messages                (severity=7)

  emergencies    System is unusable                (severity=0)

  errors         Error conditions                  (severity=3)

  informational  Informational messages            (severity=6)

  notifications  Normal but significant conditions (severity=5)

  warnings       Warning conditions                (severity=4)

Поиск первой даты публикации.

Всем привет.

Нередко авторы публикуют статьи в сети и не указывают дату ее публикации. Вот например здесь https://networkguru.ru/5-best-netflow-analyzer-collector/ хороший материал про 5 лучших анализаторов и коллекторов Netflow.

Как узнать когда впервые автор ее вынес в сеть?

Не сложно. Идем в поисковик Google и вписываем фразу в кавычках "5 лучших анализаторов и коллекторов Netflow". Переходим по опциям поиска «Инструменты /За год» жмем «Поиск». Получаем ответ где наша искомая статья с датой публикации  28 ноября 2018.

Скорее всего это уже повторная редакция. Переходим по опциям поиска «Инструменты /За период…»  и ставим крайнюю дату периода поиска на год раньше, 2017-й. Жмем «Поиск». 

Так и есть, получаем ответ где наша искомая статья с датой публикации  28 августа 2015. Поищем может она публиковалась еще раньше. Ставим крайнюю дату периода поиска на 27 августа 2015. 

И получаем «Нет результатов.»

Делаем вывод что наша искомая статейка впервые была опубликована  под названием "5 лучших анализаторов и коллекторов Netflow" именно 28 августа 2015.

Вуаля! Задачка решена.

Полигон ELK.

Всем привет.

Использование rsyslog для хранения log-сообщений сетевого оборудования, и loganalyzer для их отображения, обозначило необходимость поиска, соответствующей современным требованиям, альтернативы. В результате анализа различных решений был сделан выбор в пользу open-source компонентов стека ELK. Был ли этот выбор полностью осознанным - скорее нет, ибо популярность ELK стека бьет все рекорды. Поэтому не пощупать его своими руками было бы неразумно. Тем более у меня была давняя задача разобраться с IDS SELKS изнутри, где ELK, как вы заметили, является основой.

Итак, основными элементами ELK являются: Elasticsearch (search engine – для хранения и быстрого поиска структурированных данных), Logstash (collector – для приема в различном формате данных, их фильтрации и преобразования, и последующей отправки в различные базы данных) и Kibana (инструмент для визуализации), которые и составляют акроним ELK. Это в классическом варианте исходя из названия, но в последнее время сюда активно подмешивают Filebeat, который идет как в в паре с Logstash, так и вместо него.

Подробное описание работы этих компонентов не планировалось в рамках данной статьи. Интересующая информация по стеку очень хорошо представлена на официальном сайте, в т.ч. в виде подробной документации, а также в огромном количестве статей и публикаций. Именно по ним я поднимал весь стек пошагово. За основу была взята подробная инструкция здесь, ему помагал материал отсюда и отсюда. Каждый автор решал свою практичечкую задачу поэтому мне пришлось компилировать нужное по ходу. Обычно ELK разворачивают на одном сервере  (как с SELKS), но я решил что это будет слишком просто, поэтому  в моем полигоне Elasticsearch один хост, Kibana второй хост, и Logstash+FileBeat третий. До кластера руки не дошли, но я уверен, что это будет создать не так уж и трудно.

В ходе работ было проведено: 

• установка Elasticsearch
• установка Kibana
• установка Logstash
• установка Filebeat для отправки логов в Logstash
• установка и настройка Winlogbeat
• установка плагина Filebeat для отправки netflow Cisco
• настройка безопасности и авторизация в Kibana (несколько вариантов)
• проксирование подключений к Kibana через Nginx
• автоматическая очистка индексов в elasticsearch.

А теперь мои шаги:

1) Проверить для всех хостов стека с Ubuntu 

sudo timedatectl set-timezone Europe/Kiev

sudo apt-get install --reinstall systemd

2) Установить для всех хостов ELK стека

sudo apt-get install apt-transport-https

sudo wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a  /etc/apt/sources.list.d/elastic-7.x.list

# Также ставим JDK for Elasticsearch (Host0) & Logstash (Host1)

sudo apt install default-jdk -y

java -version

3) Настройка Elasticsearch (Host0, IP 192.168.1.11, port 9200,9300) 

- /etc/elasticsearch/elasticsearch.yml:

network.host: 0.0.0.0 (or 192.168.1.11)

http.port: 9200

transport.host: localhost

transport.tcp.port: 9300

NetFlow Analyzer и SSL.

Всем привет.

Была у меня необходимость выполнить перевод доступа к frontend-у NetFlow Analyzer на SSL.

Инструкция разработчика пишет что надо выполнить два шага:
- сгенерировать сертификат server.keystore
- изменить файл  server.conf в том плане чтобы закрыть секцию отвечающую за прослушивание порта 8080 и открыть секцию отвечающую за прослушивание порт 8443.

Так и делаем, не забывая оглядываться.

Инсталлируем JRE если JAVA еще не установлена на сервере NetFlowAnalyzer-а.

С помощью утилиты keytool создаем самоподписанный сертификат для приложения Java. Для этого используется та же команда,  что и для создания новой пары ключей, но с параметром days, задающим срок действия сертификата. Данная команда создаст пару 2048-битных RSA-ключей, действительных на протяжении 365 дней, с указанным псевдонимом в заданном файле ключей (server.jks):

%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA –validity 365  -keystore server.jks

Копируем наш сертификат под именем server.keystore в <NetFlowAnalyzer_Home>/server/default/conf

Далее в файле server.conf находим  секцию «Define a non-SSL Coyote HTTP/1.1 Connector on port 8080» и комментируем всю секцию коннектора

 <!-- Connector URIEncoding="UTF-8"
acceptCount="100"
connectionTimeout="20000"
debug="3"
disableUploadTimeout="true"
enableLookups="false"
maxSpareThreads="75" maxThreads="150" minSpareThreads="25"
port="8080" redirectPort="8443"/ -->

Далее находим  секцию «Define a SSL Coyote HTTP/1.1 Connector on port 8443» и снимаем комментарий всю секцию коннектора

    <Connector port="8443"
SSLEnabled="true" URIEncoding="UTF-8" acceptCount="100" address="0.0.0.0" clientAuth="false"
compressableMimeType="text/html,text/xml" compression="force" compressionMinSize="1024"
connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false"
keystoreFile="./conf/server.keystore" keystorePass="Iloveforza"
maxSpareThreads="75" maxThreads="150" minSpareThreads="25"
noCompressionUserAgents="gozilla, traviata"
protocol="HTTP/1.1" scheme="https" secure="true" sslProtocol="TLS"/>
 

При этом не забываем указать пароль keystorePass который мы указывали при генерации сертификата.

Перезапускаем службу «NetFlow Analyzer».

Теперь frontend нашего NetFlowAnalyzer-a откликается на https://forzaserver:8443

Все.

Идентификация интерфейсов в NetFlow Analyzer.

Всем привет.

Когда статистика моего роутера Cisco появляется в NetFlow Analyzer, то она прежде всего привязана к интерфейсам самого роутера. Эти интерфейсы видны под странными именами IfIndexN, где N-цифра. Какой реально это интерфейс на роутере, не сразу очевидно:

Прояснить ситуацию может команда show snmp mib ifmib ifindex:

router#show snmp mib ifmib ifindex
FastEthernet0: Ifindex = 1
Null0: Ifindex = 6
FastEthernet1: Ifindex = 2
Vlan1: Ifindex = 7
FastEthernet2: Ifindex = 3
FastEthernet3: Ifindex = 4
FastEthernet4: Ifindex = 5
Tunnel160: Ifindex = 8

Успехов.

Using Python for Network Forensics #1.

Hi all.

Today I would like to present for us excerpt from book "Mastering Python Forensics", Copyright © 2015 Packt Publishing, written by authors Dr. Michael Spreitzenbarth and Dr. Johann Uhrmann. It's concerning using Python for network forensics. You are welcome!

In this chapter, we will focus on the parts of the forensic investigation that are specific to the network layer. We will choose one of the most widely used Python packages for the purpose of manipulating and analyzing network trafic (Scapy) as well as a newly released open source framework by the U.S. Army Research Laboratory (Dshell). For both the toolkits, we have selected the examples of
interesting evidence. This chapter will teach you the following:
•  How to search for IOC in network traffic
•  How to extract files for further analysis
•  How to monitor accessed files through Server Message Block (SMB)
•  How to build your own port scanner

So, how we are using Dshell during an investigation.

Dshell is a Python-based network forensic analysis toolkit that is developed by the U.S. Army Research Laboratory and released as open source at the end of 2014. It can help in making the forensic investigations on the network layer a little easier. The toolkit comes with a large number of decoders that can be used out of the box and are very helpful. Some of these decoders are as follows:
•  dns: Extracts and summarizes DNS queries/responses
•  reservedips: Identifies the DNS resolutions that fall in the reserved IP space
•  large-flows: Displays the netflows that have at least transferred 1MB
•  rip-http: Extracts the files from the HTTP traffic
•  protocols: Identifies non-standard protocols
•  synrst: Detects failed attempts to connect (SYN followed by a RST/ACK).

Dshell can be installed in our lab environment by cloning the sources from GitHub at, https://github.com/USArmyResearchLab/Dshell and running install-ubuntu.py.
This script will automatically download the missing packages and build the executables that we will need afterwards. Dshell can be used against the pcap files that have been recorded during the incidents or as a result of an IDS alert. A packet capture (pcap) file is either created by libpcap (on Linux) or WinPcap (on Windows). In the following section, we will explain how an investigator can make use of Dshell by demonstrating the toolkit with real-world scenarios that are gathered from
http://malware-traffic-analysis.net.

Настройка https соединения для сервера Zabbix.

Всем привет.

Продолжаем тему HTTPS. Прошлый раз у нас был NetFlow Analyzer, а сегодня будет сервер Zabbix.

Защищенное HTTPS соединение, в настоящее время, является важным элементом для обеспечения безопасной передачи данных между клиентом и сервером. Для создания такого соединения необходимо установить на сервер SSL-сертификат, который можно или купить, или создать самому, используя собственный центр сертификации.

Для начала необходимо скопировать на сервер с Zabbix сертификат и закрытый ключ в директорию /etc/ssl/:

#копируем сам сертификат в директорию /etc/ssl/certs/ 

cp server.pem /etc/ssl/certs/ 

#копируем закрытый ключ в директорию /etc/ssl/private/

cp server.key /etc/ssl/private/

#делаем доступным файл закрытого ключа только для Администратора

chmod 0600 /etc/ssl/private/server.key

Необходимо активировать mod_ssl и включить HTTPS по умолчанию. Для этого в консоли LInux (из-под root) вводим следующие команды:

a2enmod ssl

a2ensite default-ssl

Для включения Alias (для настройки редиректа с http и https) необходимо выполнить команду:

a2enmod alias

Осталось настроить конфиги и перезапустить сервер. 

В файле /etc/apache2/sites-available/000-default.conf вносим следующие изменения:

 ServerName zabbix.forza.com

 ServerAlias www.zabbix.forza.com

 Redirect permanent / https://forza.com

 DocumentRoot /usr/share/zabbix

В файле /etc/apache2/sites-available/default-ssl.conf включаем SSLEngine и указываем путь до сертификата и закрытого ключа:

 SSLEngine on

 SSLProtocol all -SSLv2

 SSLCertificateFile      /etc/ssl/certs/server.pem

 SSLCertificateKeyFile /etc/ssl/private/server.key
 DocumentRoot /usr/share/zabbix

В файле Ports.conf комментируем строку чтобы наш сервер больше не слушал http:

#Listen 80

В принципе настройка HTTPS на этом завершена, перезапускаем сервис Apache:

service apache2 restart

Все готово.