Каждый администратор хочет знать, что происходит в его хозяйстве. Например, я для этих целей использую SNMP и MRTG. Плюсы такого подхода очевидны - мы имеем возможность прогнозировать наши потребности на основе данных, выдаваемых нашей системой мониторинга.

Это все, конечно, здорово, но MRTG не позволяет подробно отследить процессы, происходящие в сети. Если ваш канал E1 занят на 90%, то что стало причиной, какая машина или сервис вызвал такую нагрузку? Конечно, можно мониторить все машины в локальной сети, но для анализа трафика придется брать в руки tcpdump.

Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP. Конечно, такая информация будет не столь подробна, как tcpdump, но в комплексе представляет довольно подробную статистику.

Под "данными сеанса" я буду понимать совокупность пары адресов хостов, портов и объема данных. Один сеанс обозначим понятием "поток". Netflow может легко сказать вам, является ли поток в 1.5Mb/s легитимными данными от вашего Web-сервера или ваша система стала частью botnet и в данный момент DDoSит ONLamp.com. Один раз попробовав работать с Netflow, вы больше не будете представлять жизнь без этого.

Обратной стороной медали является то, что Netflow значительно более сложен в настройке, чем MRTG или любое другое, основанное на SNMP, решение. Наличие разннобразнейшей неверной и устаревшей документации еще больше запутывает дело.

Netflow имеет три основых компонента: сенсор, коллектор и система отображения данных. Сенсор - демон, который слушает сеть и фиксирует данные сеанса. Также как Snort или любая другая IDS, коллектор должен иметь возможность подключиться к хабу, "зеркалированному" порту коммутатора или любому другому устройству, для просмотра сетевого трафика. Если вы используете систему пакетной фильтрации на базе BSD или Linux, то это превосходное место для коллектора Netflow, так как весь трафик будет проходить через эту точку. Сенсор будет собирать информацию о сеансах и сбрасывать ее в коллектор.

Коллектор - второй демон, который слушает на UDP порту, указанному вами и осуществляет сбор информации от сенсора. Полученные данные он сбрасывает в файл для дальнейшей обработки. Различные коллекторы сохраняют данные в различных форматах.

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

Поскольку программное обеспечение сенсоров, коллекторов и систем отображения весьма разнообразно, то вы можете посчитать Netflow слишком сложным сложным. Для решения этой проблемы, я хотел бы предложить вам сценарий, в 90% случаев подходящих вам без кардинальных изменений. Предположим, что:

• У нас имеется машина с BSD или Linux, установленная в таком месте сети, чтобы быть использованной в качестве сенсора. Если коснуться вычислительной мощности, то, по моим данным, системы 500MHz CPU/256Mb RAM вполне хватит для обработки потока 20Mb/s без особых проблем. В данном случае я буду использовать FreeBSD.
• У нас имеется машина, которая будет служить коллектором и системой отображения. Это может быть тот же компьютер, что и в пунке выше, но учите, что нагруззка на систему в этом случае увеличится. Квалифицированные злоумышленники также имеют интерес в данных Netflow, так что вы должны разместить коллектор позади системы сетевой защиты. Имея web-сервер можно генерировать web-based отчеты Netflow. Я использую FreeBSD как коллектор и систему отображения, для работы на вашей системе, измените соответствующим образом пути к пакетам.