Мониторинг сети с использование утилиты TCPView и netstat. Анализаторы сетевых пакетов Анализ сетевой активности

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

Есть множество утилит, которые собирают сетевой трафик, и большинство из них используют pcap (в Unix-подобных системах) или libcap (в Windows) в качестве ядра. Другой вид утилит помогает анализировать эти данные, так как даже небольшой объем траффика может генерировать тысячи пакетов, в которых трудно ориентироваться. Почти все эти утилиты мало отличаются друг от друга в сборе данных, основные отличия заключаются в том, как они анализируют данные.

Анализ сетевого трафика требует понимания того, как работает сеть. Нет никакого инструмента, который бы волшебным образом заменил знания аналитика об основах работы сети, такие как "3-х этапное рукопожатие" TCP, которое используется для инициирования соединения между двумя устройствами. Аналитики также должны иметь некоторое представление о типах сетевого трафика в нормально функционирующей сети, таких как ARP и DHCP. Это знание важно, потому что аналитические инструменты просто покажут вам то, о чем вы их попросите. Вам решать, что нужно просить. Если вы не знаете, как обычно выглядит ваша сеть, может быть сложно понять, что вы нашли то, что нужно, в массе собранных вами пакетов.

Лучшие снифферы пакетов и анализаторы сети

Промышленные инструменты

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

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

Это очень большой набор инструментов управления IT. В этой статье более уместна утилита Deep Packet Inspection and Analysis которая является его составной частью. Сбор сетевого трафика довольно прост. С использованием таких инструментов, как WireShark, базовый анализ также не является проблемой. Но не всегда ситуация полностью понятна. В очень загруженной сети может быть трудно определить даже очень простые вещи, например:

Какое приложение в сети создает этот трафик?
- если приложение известно (скажем, веб-браузер), где его пользователи проводят большую часть своего времени?
- какие соединения самые длинные и перегружают сеть?

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

Другие технологии управления сетями с большим объемом данных включают NetFlow и sFlow. У каждой есть свои сильные и слабые стороны,

Вы можете узнать больше о NetFlow и sFlow.

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

Основы

Основным инструментом для сбора сетевого трафика является

Это приложение с открытым исходным кодом, которое устанавливается практически во всех Unix-подобных операционных системах. Tcpdump - отличная утилита для сбора данных, которая имеет очень сложный язык фильтрации. Важно знать, как фильтровать данные при их сборе, чтобы в итоге получить нормальный набор данных для анализа. Захват всех данных с сетевого устройства даже в умеренно загруженной сети может породить слишком много данных, которые будет очень трудно проанализировать.

В некоторых редких случаях достаточно будет выводить захваченные tcpdump данные прямо на экран, чтобы найти то, что вам нужно. Например, при написании этой статьи я собрал трафик и заметил, что моя машина отправляет трафик на IP-адрес, который я не знаю. Оказывается, моя машина отправляла данные на IP-адрес Google 172.217.11.142. Поскольку у меня не было никаких продуктов Google, и не был открыт Gmail, я не знал, почему это происходит. Я проверил свою систему и нашел следующее:

[ ~ ]$ ps -ef | grep google user 1985 1881 0 10:16 ? 00:00:00 /opt/google/chrome/chrome --type=service

Оказывыается, что даже когда Chrome не работает, он остается запущенным как служба. Я не заметил бы этого без анализа пакетов. Я перехватил еще несколько пакетов данных, но на этот раз дал tcpdump задачу записать данные в файл, который затем открыл в Wireshark (подробнее об этом позже). Вот эти записи:

Tcpdump - любимый инструмент системных администраторов, потому что это утилита командной строки. Для запуска tcpdump не требуется графический интерфейс. Для производственных серверов графический интерфес скорее вреден, так как потребляет системные ресурсы, поэтому предпочтительны программы командной строки. Как и многие современные утилиты, tcpdump имеет очень богатый и сложный язык, который требует некоторого времени для его освоения. Несколько самых базовых команд включают в себя выбор сетевого интерфейса для сбора данных и запись этих данных в файл, чтобы его можно было экспортировать для анализа в другом месте. Для этого используются переключатели -i и -w.

# tcpdump -i eth0 -w tcpdump_packets tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C51 packets captured

Эта команда создает файл с захваченными данными:

file tcpdump_packets tcpdump_packets: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 262144)

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

3. Windump

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

Самое существенное различие между Windump и tcpdump заключается в том, что Windump нуждается в библиотеке Winpcap, установленной до запуска Windump. Несмотря на то, что Windump и Winpcap предоставляются одним и тем же майнтайнером, их нужно скачивать отдельно.

Winpcap - это библиотека, которая должна быть предварительно установлена. Но Windump - это exe-файл, который не нуждается в установке, поэтому его можно просто запускать. Это нужно иметь в виду, если вы используете сеть Windows. Вам не обязательно устанавливать Windump на каждой машине, поскольку вы можете просто копировать его по мере необходимости, но вам понадобится Winpcap для поддержки Windup.

Как и в случае с tcpdump, Windump может выводить сетевые данные на экран для анализа, фильтровать таким же образом, а также записывать данные в файл pcap для последующего анализа.

4. Wireshark

Wireshark является следующим самым известным инструментом в наборе системного администратора. Он позволяет не только захватывать данные, но также предоставляет некоторые расширенные инструменты анализа. Кроме того, Wireshark является программой с открытым исходным кодом и перенесен практически на все существующие серверные операционные системы. Под названием Etheral, Wireshark теперь работает везде, в том числе в качестве автономного переносимого приложения.

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

При первом запуске Wireshark позволяет либо загрузить существующий файл pcap, либо запустить захват трафика. В последнем случае вы можете дополнительно задать фильтры для уменьшения количества собираемых данных. Если вы не укажете фильтр, Wireshark будет просто собирать все сетевые данные с выбранного интерфейса.

Одной из самых полезных возможностей Wireshark является возможность следовать за потоком. Лучше всего представить поток как цепочку. На скриншоте ниже мы можем видеть множество захваченных данных, но меня больше всего интересовал IP-адрес Google. Я могу щелкнуть правой кнопкой мыши и следовать потоку TCP, чтобы увидеть всю цепочку.

Если захват трафика производился на другом компьютере, вы можете импортировать файл PCAP с помощью диалога Wireshark File -> Open. Для импортированных файлов доступны те же фильтры и инструменты, что и для захваченных сетевых данных.

5. tshark

Tshark - это очень полезное звено между tcpdump и Wireshark. Tcpdump превосходит их при сборе данных и может хирургически извлекать только те данные, которые вам нужны, однако его возможности анализа данных очень ограничены. Wireshark отлично справляется как с захватом, так и с анализом, но имеет тяжелый пользовательский интерфейс и не может использоваться на серверах без графического интерфейса. Попробуйте tshark, он работает в командной строке.

Tshark использует те же правила фильтрации, что и Wireshark, что не должно удивлять, так как они по сути являются одним и тем же продуктом. Приведенная ниже команда говорит tshark только о том, что необходимо захватить IP-адрес пункта назначения, а также некоторые другие интересующие нас поля из HTTP-части пакета.

# tshark -i eth0 -Y http.request -T fields -e ip.dst -e http.user_agent -e http.request.uri 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /images/title.png 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /images/styles/phoenix.css 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /images/code/jquery_lightbox/jquery_lightbox/js/jquery-1.2.6.pack.js 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /images/styles/index.css 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /images/images/title.png 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /favicon.ico 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /favicon.ico

Если вы хотите записать трафик в файл, используйте для этого параметр-W, а затем переключатель -r (чтение), чтобы прочитать его.

Сначала захват:

# tshark -i eth0 -w tshark_packets Capturing on "eth0" 102 ^C

Прочитайте его здесь же, или перенесите в другое место для анализа.

# tshark -r tshark_packets -Y http.request -T fields -e ip.dst -e http.user_agent -e http.request.uri 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /contact 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /reservations/ 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /reservations/styles/styles.css 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /res/code/jquery_lightbox/jquery_lightbox/js/jquery-1.2.6.pack.js 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /res/styles/index.css 172.20.0.122 Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 /res/images/title.png

Это очень интересный инструмент, который скорее попадает в категорию инструментов сетевого криминалистического анализа, а не просто снифферов. Сфера криминалистики, как правило, занимается расследованиями и сбором доказательств, и Network Miner выполняет эту работу просто отлично. Также, как wireshark может следовать потоку TCP, чтобы восстановить всю цепочку передачи паков, Network Miner может следовать потоку для того, чтобы восстановить файлы, которые были переданы по сети.

Network Miner может быть стратегически размещен в сети, чтобы иметь возможность наблюдать и собирать трафик, который вас интересует, в режиме реального времени. Он не будет генерировать свой собственный трафик в сети, поэтому будет работать скрытно.

Network Miner также может работать в автономном режиме. Вы можете использовать tcpdump, чтобы собрать пакеты в интересующей вас точке сети, а затем импортировать файлы PCAP в Network Miner. Далее можно будет попробовать восстановить какие-либо файлы или сертификаты, найденные в записанном файле.

Network Miner сделан для Windows, но с помощью Mono он может быть запущен в любой ОС, которая поддерживает платформу Mono, например Linux и MacOS.

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

7. Fiddler (HTTP)

Технически не является утилитой для захвата сетевых пакетов, но он так невероятно полезен, что попал в этот список. В отличие от других перечисленных здесь инструментов, которые предназначены для захвата трафика в сети из любого источника, Fiddler скорее служит инструментом отладки. Он захватывает HTTP трафик. Хотя многие браузеры уже имеют эту возможность в своих средствах разработчика, Fiddler не ограничивается трафиком браузера. Fiddler может захватить любой HTTP-трафик на компьютере, в том числе и не из веб-приложений.

Многие настольные приложения используют HTTP для подключения к веб-службам, и помимо Fiddler, единственным способом захвата такого трафика для анализа является использование таких инструментов, как tcpdump или Wireshark. Однако они работают на уровне пакетов, поэтому для анализа необходимо реконструировать этии пакеты в потоки HTTP. Это может потребовать много работы для выполнения простых исследований и здесь на помощь приходит Fiddler. Fiddler поможет обнаружить куки, сертификаты, и прочие полезные данные, отправляемые приложениями.

Fiddler является бесплатным и, так же, как Network Miner, он может быть запущен в Mono практически на любой операционной системе.

8. Capsa

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

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

Capsa доступна только для Windows 2008/Vista/7/8 и 10.

Заключение

Несложно понять, как с помощью описанных нами инструментов системный админимтратор может создать инфраструктуру мониторинга сети. Tcpdump или Windump могут быть установлены на всех серверах. Планировщик, такой как cron или планировщик Windows, в нужный момент запускает сеанса сбора пакетов и записывает собранные данные в файл pcap. Далее системный администратор может передать эти пакеты центральной машине и анализировать их с помощью wireshark. Если сеть слишком велика для этого, имеются инструменты корпоративного уровня, такие как SolarWinds, чтобы превратить все сетевые пакеты в управляемый набор данных.

Оригинальное название: A Summary of Network Traffic Monitoring and Analysis Techniques

Ссылка на оригинальный текст: http://www.cse.wustl.edu/~jain/cse567-06/ftp/net_monitoring/index.html

Рекомендации: представленный перевод не является профессиональным. Возможны отступления от текста, неправильная трактовка тех или иных терминов и понятий, субъективное мнение переводчика. Все иллюстрации внесены в перевод без изменения.

Алиша Сессил

Обзор методов анализа и мониторинга сетевого трафика

Так как продолжают расти частные внутренние сети компаний, чрезвычайно важно, чтобы сетевые администраторы знали и умели управлять вручную различными типами трафика, который путешествует по их сети. Мониторинг и анализ трафика необходимы для того, чтобы более эффективно диагностировать и решать проблемы, когда они происходят, таким образом не доводя сетевые сервисы до простоя в течении длительного времени. Доступно много различных инструментов, которые позволяют помочь администраторам с мониторингом и анализом сетевого трафика. Данная статья обсуждает методы мониторинга ориентированные на маршрутизаторы и методы мониторинга не ориентированные на маршрутизаторы (активные и пассивные методы). Статья даёт обзор трёх доступных и наиболее широко используемых методов мониторинга сети, встроенных в маршрутизаторы (SNMP, RMON и Cisco Netflow) и предоставляет информацию о двух новых методах мониторинга, которые используют сочетание пассивного и активного методов мониторинга (WREN и SCNM).

1. Важность мониторинга и анализа сети

Сетевой мониторинг (мониторинг сети) - это сложная задача, требующая больших затрат сил, которая является жизненно важной частью работы сетевых администраторов. Администраторы постоянно стремятся поддержать бесперебойную работу своей сети. Если сеть «упадёт» хотя бы на небольшой период времени, производительность в компании сократится и (в случае организаций предоставляющих государственные услуги) сама возможность предоставления основных услуг будет поставлена под угрозу. В связи с этим администраторам необходимо следить за движением сетевого трафика и производительностью на всей сети и проверять, появились ли в ней бреши в безопасности.

2. Способы мониторинга и анализа

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

2.1. Методы мониторинга основанные на маршрутизаторе

Методы мониторинга основанные на маршрутизаторе - жёстко заданы (вшиты) в маршрутизаторах и, следовательно, имеют низкую гибкость. Краткое описание наиболее часто используемых методов такого мониторинга приведены ниже. Каждый метод развивался много лет прежде чем стать стандартизованным способом мониторинга.

2.1.1. Протокол простого сетевого мониторинга (SNMP), RFC 1157

SNMP - протокол прикладного уровня, который является частью протокола TCP/IP. Он позволяет администраторам руководить производительностью сети, находить и устранять сетевые проблемы, планировать рост сети. Он собирает статистику по трафику до конечного хоста через пассивные датчики, которые реализуются вместе с маршрутизатором. В то время, как существуют две версии (SNMPv1 и SNMPv2), данный раздел описывает только SNMPv1. SNMPv2 построен на SNMPv1 и предлагает ряд усовершенствований, таких как добавление операций с протоколами. Стандартизируется ещё один вариант версии SNMP. Версия 3 (SNMPv3) находится на стадии рассмотрения.

Для протокола SNMP присущи три ключевых компонента: управляемые устройства (Managed Devices), агенты (Agents) и системы управления сетью (Network Management Systems - NMSs). Они показаны на рис. 1.

Рис. 1. Компоненты SNMP

Управляемые устройства включают в себя SNMP-агента и могут состоять из маршрутизаторов, переключателей, коммутаторов, концентраторов, персональных компьютеров, принтеров и других элементов, подобных этим. Они несут ответственность за сбор информации и делают её доступной для системы управления сетью (NMS).

Агенты включают в себя программное обеспечение, которое владеет информацией по управлению, и переводят эту информацию в форму, совместимую с SNMP. Они закрыты для устройства управления.

Системы управления сетью (NMS) выполняют приложения, которые занимаются мониторингом и контролем устройств управления. Ресурсы процессора и памяти, которые необходимы для управления сетью, предоставляются NMS. Для любой управляемой сети должна быть создана хотя бы одна система управления. SNMP может действовать исключительно как NMS, или агент, или может исполнять свои обязанности или др.

Существует 4 основных команды, использующиеся SNMP NMS для мониторинга и контроля управляемых устройств: чтение, запись, прерывание и операции пересечения. Операция чтения рассматривает переменные, которые хранятся управляемыми устройствами. Команда записи меняет значения переменных, которые хранятся управляемыми устройствами. Операции пересечения владеют информацией о том, какие переменные управляемых устройств поддерживают, и собирают информацию из поддерживаемых таблиц переменных. Операция прерывания используется управляемыми устройствами для того, чтобы сообщить NMS о наступлении определённых событий.

SNMP использует 4 протокольные операции в порядке действия: Get, GetNext, Set и Trap. Команда Get используется, когда NMS выдаёт запрос на информацию для управляемых устройств. SNMPv1-запрос состоит из заголовка сообщения и единицы данных протокола (PDU). PDU-сообщения содержит информацию, которая необходима для удачного выполнения запроса, который будет либо получать информацию от агента, либо задавать значение в агенте. Управляемое устройство использует SNMP агентов, расположенных в нём, для получения необходимой информации и затем посылает сообщение NMS"у, с ответом на запрос. Если агент не владеет какой либо информацией по отношению к запросу, он ничего не возвращает. Команда GetNext будет получать значение следующего экземпляра объекта. Для NMS также возможно посылать запрос (операция Set), когда устанавливается значение элементов без агентов. Когда агент должен сообщить NMS-события, он будет использовать операцию Trap.

Как говорилось ранее, SNMP - протокол уровня приложений, который использует пассивные сенсоры, чтобы помочь администратору проследить за сетевым трафиком и производительностью сети. Хотя, SNMP может быть полезным инструментом для сетевого администратора, он создаёт возможность для угрозы безопасности, потому что он лишён возможности аутентификации. Он отличается от удалённого мониторинга (RMON), который обсуждается в следующем разделе, тем, что RMON работает на сетевом уровне и ниже, а не на прикладном.

2.1.2. Удалённый мониторинг (RMON), RFS 1757

RMON включает в себя различные сетевые мониторы и консольные системы для изменения данных, полученных в ходе мониторинга сети. Это расширение для SNMP информационной базы данных по управлению (MIB). В отличии от SNMP , который должен посылать запросы о предоставлении информации, RMON может настраивать сигналы, которые будут «мониторить» сеть, основанную на определённом критерии. RMON предоставляет администраторам возможности управлять локальными сетями также хорошо, как удалёнными от одной определённой локации/точки. Его мониторы для сетевого уровня приведены ниже. RMON имеет две версии RMON и RMON2. Однако в данной статье говорится только о RMON. RMON2 позволяет проводить мониторинг на всех сетевых уровнях. Он фокусируется на IP-трафике и трафике прикладного уровня.

Хотя существует 3 ключевых компонента мониторинговой среды RMON, здесь приводятся только два из них. Они показаны на рис. 2 ниже.

Рис. 2. Компоненты RMON

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

RMON использует 9 различных групп мониторинга для получения информации о сети.

• Statistics - статистика измеренная датчиком для каждого интерфейса мониторинга для данного устройства.
• History - учёт периодических статистических выборок из сети и хранение их для поиска.
• Alarm - периодически берёт статистические образцы и сравнивает их с набором пороговых значений для генерации события.
• Host - содержит статистические данные, связанные с каждым хостом, обнаруженным в сети.
• HostTopN - готовит таблицы, которые описывают вершину хостов (главный хост).
• Filters - включает фильтрацию пакетов, основываясь на фильтровом уравнении для захвата событий.
• Packet capture - захват пакетов после их прохождения через канал.
• Events - контроль генерации и регистрация событий от устройства.
• Token ring - поддержка кольцевых лексем.

Как установлено выше, RMON, строится на протоколе SNMP. Хотя мониторинг трафика может быть выполнен при помощи этого метода, аналитические данные об информации, полученные SNMP и RMON имеют низкую производительность. Утилита Netflow, которая обсуждается в следующем разделе, работает успешно со многими пакетами аналитического программного обеспечения, чтобы сделать работу администратора намного проще.

2.1.3. Netflow, RFS 3954

Netflow - это расширение, которое было представлено в маршрутизаторах Cisco, которые предоставляют возможность собирать IP сетевой трафик, если это задано в интерфейсе. Анализируя данные, которые предоставляются Netflow, сетевой администратор может определить такие вещи как: источник и приёмник трафика, класс сервиса, причины переполненности. Netflow включает в себя 3 компонента: FlowCaching (кеширующий поток), FlowCollector (собиратель информации о потоках) и Data Analyzer (анализатор данных). Рис. 3 показывает инфраструктуру Netflow. Каждый компонент, показанный на рисунке, объясняется ниже.

Рис. 3. Инфраструктура NetFlow

FlowCaching анализирует и собирает данные о IP потоках, которые входят в интерфейс, и преобразует данные для экспорта.

Из Netflow-пакетов может быть получена следующая информация:

• Адрес источника и получателя.
• Номер входящего и выходящего устройства.
• Номер порта источника и приёмника.
• Протокол 4 уровня.
• Количество пакетов в потоке.
• Количество байтов в потоке.
• Временной штамп в потоке.
• Номер автономной системы (AS) источника и приёмника.
• Тип сервиса (ToS) и флаг TCP.

Первый пакет потока, проходящий через стандартный путь переключения, обрабатывается для создания кэша. Пакеты с подобными характеристиками потока используются для создания записи о потоке, которая помещается в кэш для всех активных потоков. Эта запись отмечает количество пакетов и количество байт в каждом потоке. Кэшируемая информация затем периодически экспортируется в Flow Collector (сборщик потоков).

Flow Collector - ответственен за сбор, фильтрование и хранение данных. Он включает в себя историю об информации о потоках, которые были подключены при помощи интерфейса. Снижение объёма данных также происходит при помощи Flow Collector"а при помощи выбранных фильтров и агрегации.

Data Analyzer (анализатор данных) необходим, когда нужно представить данные. Как показано на рисунке, собранные данные могут использоваться для различных целей, даже отличных от мониторинга сети, таких как планирование, учёт и построение сети.

Преимущество Netflow над остальными способами мониторинга, такими как SNMP и RMON, в том, что в ней существует программные пакеты, предназначенные для различного анализа трафика, которые существуют для получения данных от Netflow-пакетов и представления их в более дружелюбном для пользователя виде.

При использовании инструментов, таких как Netflow Analyzer (это только один инструмент, который доступен для анализирования Netflow-пакетов), информация, приведённая выше, может быть получена от Netflow-пакетов для создания диаграмм и обычных графиков, которые администратор может изучить для большего понимания о его сети. Наибольшее преимущество использования Netflow в отличии от доступных аналитических пакетов в том, что в данном случае могут быть построены многочисленные графики, описывающие активность сети в любой момент времени.

2.2. Технологии не основанные на маршрутизаторах

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

2.2.1. Активный мониторинг

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

Главным образом использование инструментов, такие как команда ping, которая измеряет задержку и потери пакетов, и traceroute, которая помогает определить топологию сети, является примером основных активных инструментов измерения. Оба эти инструмента посылают пробные ICMP-пакеты до точки назначения и ждут, когда эта точка ответит отправителю. Рис. 4 - пример команды ping, которая использует активный способ измерения, посылая Echo-запрос от источника через сеть в установленную точку. Затем получатель посылает Echo-запрос обратно источнику от которого пришёл запрос.

Рис. 4. Команда ping (Акстивное измерение)

Данный метод может не только собирать единичные метрики об активном измерении, но и может определять топологию сети. Ещё один важный пример активного измерения - утилита iperf. Iperf - это утилита, которая измеряет качество пропускной способности TCP и UDP протоколов. Она сообщает пропускную способность канала, существующую задержку и потери пакетов.

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

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

2.2.2. Пассивный мониторинг

Пассивный мониторинг в отличии от активного не добавляет трафик в сеть и не изменяет трафик, который уже существует в сети. Также в отличии от активного мониторинга, пассивный собирает информацию только об одной точке в сети. Измерения происходят гораздо лучше, чем между двумя точками, при активном мониторинге. Рис. 5 показывает установку системы пассивного мониторинга, где монитор размещён на единичном канале между двумя конечными точками и наблюдает трафик когда тот проходит по каналу.

Рис. 5. Установка пассивного мониторинга

Пассивные измерения имеют дело с такой информацией, как: трафик и смесь протоколов, количество битов (битрейт), синхронизация пакетов и время между прибытием. Пассивный мониторинг может быть осуществлён, при помощи любой программы, вытягивающей пакеты.

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

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

2.2.3. Комбинированный мониторинг

После прочтения разделов выше, можно благополучно переходить к заключению о том, что комбинирование активного и пассивного мониторинга - лучший способ, чем использование первого или второго по отдельности. Комбинированные технологии используют лучшие стороны и пассивного, и активного мониторинга сред. Две новые технологии, представляющие комбинированные технологии мониторинга, описываются ниже. Это «Просмотр ресурсов на концах сети» (WREN) и «Монитор сети с собственной конфигурацией» (SCNM).

2.2.3.1. Просмотр ресурсов на концах сети (WREN)

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

Основной уровень быстрой обработки пакетов отвечает за получение информации, связанной с входящими и исходящими пакетами. Рис. 6 показывает список информации, которая собирается для каждого пакета. К Web100 добавляется буфер для сбора этих характеристик. Доступ к буферу осуществляется при помощи двух системных вызовов. Один вызов начинает трассировку и предоставляет необходимую информацию для её сбора, пока второй вызов возвращает трассировку из ядра.

Рис. 6. Информация, собранная на главном уровне трассировок пакетов

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

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

Когда трафик мал, WREN будет активно вводить трафик в сеть сохраняя порядок следования потоков измерения. После многочисленных исследований, найдено, что WREN представляет похожие измерения в перенасыщенных и в не-перенасыщенных средах.

В текущей реализации WREN, пользователи не принуждаются только к захвату трассировок, которые были инициированы ими. Хотя любой пользователь может следить за трафиком приложений других пользователей, они ограничены в информации, которая может быть получена от трассировок других пользователей. Они могут только получить последовательность и подтверждение чисел, но не могут получить актуальные сегменты данных из пакетов.

В общем, WREN - это очень полезная установка, которая использует преимущества и активного, и пассивного мониторинга. Хотя эта технология находится на раннем этапе развития, WREN может предоставить администраторам полезные ресурсы в мониторинге и анализе их сетей. Монитор Собственного конфигурирования сети (SCNM) - другой инструментарий, который использует технологии и активного, и пассивного мониторинга.

2.2.3.2. Сетевой монитор с собственной конфигурацией (SCNM)

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

Аппаратное средство устанавливается в критических точках сети. Оно отвечает за пассивный сбор заголовков пакетов. Программное обеспечение запускается на конечной точке сети. Рис. 7, приведённый ниже, показывает программный компонент SCNM среды.

Рис. 7. Программный компонент SCNM

Программное обеспечение отвечает за создание и посылку активированных пакетов, которые используются для старта мониторинга сети. Пользователи будут посылать в сеть пакеты активации, содержащие детали о пакетах, которые они хотят получить для мониторинга и сбора. Пользователи не нуждаются в знании местоположения SCNM-хоста, принимая за истину то, что все хосты открыты для «прослушки» пакетов. На основе информации, которая существует в рамках активационного пакета, фильтр помещается в поток сбора данных, который также работает в конечной точке . Собираются заголовки пакетов сетевого и транспортного уровня, которые соответствуют фильтру. Фильтр будет автоматически введён в тайм аут, после точно заданного времени, если он получает другие пакеты приложения. Служба выборки пакетов, которая запускается на SCNM-хосте, использует команду tcpdump (подобно программе выборки пакетов) в порядке полученных запросов и записи трафика, который соответствует запросу.

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

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

В заключение скажем, что SCNM - это ещё один способ комбинированного мониторинга, который использует и активный, и пассивный методы, чтобы помочь администраторам мониторить и анализировать их сети.

3. Заключение

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

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

Любой администратор рано или поздно получает инструкцию от руководства: «посчитать, кто ходит в сеть, и сколько качает». Для провайдеров она дополняется задачами «пустить кого надо, взять оплату, ограничить доступ». Что считать? Как? Где? Отрывочных сведений много, они не структурированы. Избавим начинающего админа от утомительных поисков, снабдив его общими знаниями, и полезными ссылками на матчасть.
В данной статье я постараюсь описать принципы организации сбора, учёта и контроля трафика в сети. Мы рассмотрим проблематику вопроса, и перечислим возможные способы съема информации с сетевых устройств.

Это первая теоретическая статья из цикла статей, посвящённого сбору, учёту, управлению и биллингу трафика и IT-ресурсов.

Структура доступа в сеть Интернет

В общем случае, структура доступа в сеть выглядит следующим образом:

• Внешние ресурсы – сеть Интернет, со всеми сайтами, серверами, адресами и прочим, что не принадлежит сети, которую вы контролируете.
• Устройство доступа – маршрутизатор (аппаратный, или на базе PC), коммутатор, VPN-сервер или концентратор.
• Внутренние ресурсы – набор компьютеров, подсетей, абонентов, работу которых в сети необходимо учитывать или контролировать.
• Сервер управления или учёта – устройство, на котором работает специализированное программное обеспечение. Может быть функционально совмещён с программным маршрутизатором.

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

Сетевой трафик

Для начала необходимо определить, а что же подразумевается под «сетевым трафиком», и какую полезную статистическую информацию можно извлечь из потока пользовательских данных.
Доминирующим протоколом межсетевого взаимодействия пока остается IP версии 4 . Протокол IP соответствует 3му уровню модели OSI (L3). Информация (данные) между отправителем и получателем упаковывается в пакеты – имеющие заголовок, и «полезную нагрузку». Заголовок определяет, откуда и куда идет пакет (IP-адреса отправителя и получателя), размер пакета, тип полезной нагрузки. Основную часть сетевого трафика составляют пакеты с полезной нагрузкой UDP и TCP – это протоколы 4-го уровня (L4). Помимо адресов, заголовок этих двух протоколов содержит номера портов, которые определяют тип службы (приложения), передающего данные.

Для передачи IP-пакета по проводам (или радио) сетевые устройства вынуждены «оборачивать» (инкапсулировать) его в пакет протокола 2го уровня (L2). Самым распространенным протоколом такого типа является Ethernet . Фактическая передача «в провод» идет на 1м уровне. Обычно, устройство доступа (маршрутизатор) не занимается анализом заголовков пакетов на уровне, выше 4го (исключение – интеллектуальные межсетевые экраны).
Информация из полей адресов, портов, протоколов и счетчики длин из L3 и L4 заголовков пакетов данных и составляет тот «исходный материал», который используется при учёте и управлении трафиком. Собственно объем передаваемой информации находится в поле Length («Длина пакета») заголовка IP (включая длину самого заголовка). Кстати, из-за фрагментации пакетов вследствие механизма MTU общий объем передаваемых данных всегда больше размера полезной нагрузки.

Суммарная длина интересных нам в данном контексте IP- и TCP/UDP- полей пакета составляет 2...10% общей длины пакета. Если обрабатывать и хранить всю эту информацию попакетно, не хватит никаких ресурсов. К счастью, подавляющий объем трафика структурирован так, что состоит из набора «диалогов» между внешними и внутренними сетевыми устройствами, так называемых «потоков». Например, в рамках одной операции пересылки электронного письма (протокол SMTP) открывается TCP-сессия между клиентом и сервером. Она характеризуется постоянным набором параметров {IP-адрес источника, TCP-порт источника, IP-адрес получателя TCP-порт получателя} . Вместо того, чтобы обрабатывать и хранить информацию попакетно, гораздо удобнее хранить параметры потока (адреса и порты), а также дополнительную информацию – число и сумму длин переданных пакетов в каждую сторону, опционально длительность сессии, индексы интерфейсов маршрутизатора, значение поля ToS и прочее. Такой подход выгоден для ориентированных на соединение протоколов (TCP), где можно явно перехватить момент завершения сессии. Однако и для не ориентированных на сессии протоколов можно проводить агрегацию и логическое завершение записи о потоке по, например, таймауту. Ниже приведена выдержка из SQL-базы собственной системы биллинга , осуществляющей протоколирование информации о потоках трафика:

Необходимо отметить случай, когда устройство доступа осуществляет трансляцию адресов (NAT , маскарадинг) для организации доступа в Интернет компьютеров локальной сети, используя один, внешний, публичный IP-адрес. В этом случае специальный механизм осуществляет подмену IP-адресов и TCP/UDP портов пакетов трафика, заменяя внутренние (не маршрутизируемые в Интернете) адреса согласно своей динамической таблице трансляции. В такой конфигурации необходимо помнить, что для корректного учета данных по внутренним хостам сети съём статистики должен производиться способом и в том месте, где результат трансляции ещё не «обезличивает» внутренние адреса.

Методы сбора информации о трафике/статистике

Снимать и обрабатывать информацию о проходящем трафике можно непосредственно на самом устройстве доступа (ПК-маршрутизатор, VPN-сервер), с этого устройства передавая ее на отдельный сервер (NetFlow, SNMP), или «с провода» (tap, SPAN). Разберем все варианты по-порядку.

ПК-маршрутизатор

Рассмотрим простейший случай – устройство доступа (маршрутизатор) на базе ПК c ОС Linux.

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

• перехват (копирование) пакетов, проходящих через сетевую карту сервера, при помощи библиотеки libpcap
• перехват пакетов, проходящих через встроенный межсетевой экран
• использование сторонних средств преобразования попакетной статистики (полученной одним из двух предыдущих методов) в поток агрегированной информации netflow

Libpcap

В первом случае копия пакета, проходящего через интерфейс, после прохождения фильтра (man pcap-filter) может быть запрошена клиентской программой на сервере, написанной с использованием данной библиотеки. Пакет поступает вместе с заголовком 2го уровня (Ethernet). Можно ограничить длину захватываемой информации (если нас интересует только информация из его заголовка). Примерами таких программ могут быть tcpdump и Wireshark . Существует реализация libpcap под Windows . В случае применения трансляции адресов на ПК-маршрутизаторе такой перехват можно осуществлять только на его внутреннем интерфейсе, подключенном к локальным пользователям. На внешнем интерфейсе, после трансляции, IP-пакеты не содержат информации о внутренних хостах сети. Однако при таком способе невозможно учесть трафик, создаваемый самим сервером в сети Интернет (что важно, если на нем работают веб– или почтовый сервис).

Работа libpcap требует поддержки со стороны операционной системы, что в настоящее время сводится к установке единственной бибилиотеки. При этом прикладная (пользовательская) программа, осуществляющая сбор пакетов, должна:

• открыть необходимый интерфейс
• указать фильтр, через который пропускать принятые пакеты, размер захватываемой части (snaplen), размер буфера,
• задать параметр promisc, который переводит сетевой интерфейс в режим захвата вообще всех проходящих мимо пакетов, а не только адресованных MAC-адресу этого интерфейса
• установить функцию (callback), вызываемую на каждый принятый пакет.

При передаче пакета через выбранный интерфейс, после прохождения фильтра эта функция получает буфер, содержащий Ethernet, (VLAN), IP и т.д. заголовки, общим размером до snaplen. Поскольку библиотека libcap копирует пакеты, заблокировать их прохождение при ее помощи невозможно. В таком случае программе сбора и обработки трафика придется использовать альтернативные методы, например вызов скрипта для помещения заданного IP-адреса в правило блокировки трафика.

Межсетевой экран

Захват данных, проходящих через межсетевой экран, позволяет учесть и трафик самого сервера, и трафик пользователей сети, даже при работе трансляции адресов. Главное в этом случае – правильно сформулировать правило захвата, и поставить его в нужное место. Данным правилом активируется передача пакета в сторону системной библиотеки, откуда приложение учета и управления трафиком может его получить. Для ОС Линукс в качестве межсетевого экрана применяют iptables, а средства перехвата – ipq, netfliter_queue или ulog . Для OC FreeBSD – ipfw с правилами типа tee или divert . В любом случае механизм межсетевого экрана дополняется возможностью работы с пользовательской программой следующим способом:

• Пользовательская программа - обработчик трафика регистрирует себя в системе, используя системный вызов, или библиотеку.
• Пользовательская программа или внешний скрипт устанавливает правило в межсетевой экран, “заворачивающее” выбранный трафик (согласно правилу) вовнутрь обработчика.
• На каждый проходящий пакет обработчик получает его содержимое в виде буфера памяти (с заголовками IP и т.д. После обработки (учёта) программе необходимо также сообщить ядру операционной системы, что делать далее с таким пакетом - отбросить или передать далее. Как вариант, возможно передать ядру видоизмененный пакет.

Поскольку IP-пакет не копируется, а пересылается в программное обеспечение для анализа, становится возможным его «выброс», а следовательно, полное или частичное ограничение трафика определенного типа (например, до выбранного абонента локальной сети). Однако в случае, если прикладная программа перестала отвечать ядру о своем решении (зависла, к примеру), трафик через сервер просто блокируется.
Необходимо отметить, что описанные механизмы при существенных объемах передаваемого трафика создают избыточную нагрузку на сервер, что связано с постоянным копированием данных из ядра в пользовательскую программу. Этого недостатка лишен метод сбора статистики на уровне ядра ОС, с выдачей в прикладную программу агрегированной статистики по протоколу NetFlow .

Netflow

Этот протокол был разработан фирмой Cisco Systems для экспорта информации о трафике с маршрутизаторов с целью учета и анализа трафика. Наиболее популярная сейчас версия 5 предоставляет получателю поток структурированных данных в виде UDP-пакетов, содержащих информацию о прошедшем трафике в виде так называемых flow records:

Объем информации о трафике меньше самого трафика на несколько порядков, что особенно актуально в больших и распределенных сетях. Конечно же, блокировать передачу информации при сборе статистики по netflow невозможно (если не использовать дополнительные механизмы).
В настоящее время становится популярным дальнейшее развитие этого протокола – версия 9, основанная на шаблонной структуре flow record, реализации для устройств других производителей (sFlow). Недавно был принят стандарт IPFIX, который позволяет передавать статистику и по протоколам более глубоких уровней (например, по типу приложения).
Реализация netflow-источников (агентов, probe) доступна для ПК-маршрутизаторов, как в виде работающих по описанных выше механизмам утилит (flowprobe, softflowd), так и непосредственно встроенных в ядро ОС (FreeBSD: ng_netgraph , Linux: ). Для программных маршрутизаторов поток статистики netflow можно принимать и обрабатывать локально на самом маршрутизаторе, или отправлять по сети (протокол передачи – поверх UDP) на принимающее устройство (коллектор).


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

Функции экспорта netflow поддерживают маршрутизаторы Cisco Systems, Mikrotik, и некоторые другие. Аналогичный функционал (с другими протоколами экспорта) поддерживается всеми крупными производителями сетевого оборудования.

Libpcap “снаружи”

Немного усложним задачу. Что, если ваше устройство доступа – аппаратный маршрутизатор другого производителя? Например, D-Link, ASUS, Trendnet и т.д. На нем, скорее всего, невозможно поставить дополнительное программное средство съема данных. Как вариант – интеллектуальное устройство доступа у вас есть, но настроить его не представляется возможным (нет прав, или оно управляется вашим провайдером). В таком случае можно собирать информацию о трафике непосредственно в точке стыка устройства доступа с внутренней сетью, пользуясь «аппаратными» средствами копирования пакетов. В таком случае непременно потребуется отдельно стоящий сервер с выделенной сетевой картой для приема копий Ethernet-пакетов.
Сервер должен использовать механизм сбора пакетов по методу libpcap, описанному выше, и наша задача - на вход выделенной для этого сетевой карты подать поток данных, идентичный выходящему из сервера доступа. Для этого можно использовать:

• Ethernet – хаб (hub): устройство, просто пересылающее пакеты между всеми своими портами без разбора. В современных реалиях его можно найти где-нибудь на пыльном складе, и применять такой метод не рекомендуется: ненадежно, низкая скорость (хабов на скорости 1 Гбит/с не бывает)
• Ethernet – коммутатор с возможностью зеркалирования (мирроринга, SPAN портов . Современные интеллектуальные (и дорогие) коммутаторы позволяют копировать на указанный порт весь трафик (входящий, выходящий, оба) другого физического интерфейса, VLANа, в том числе удаленного (RSPAN)
• Аппаратный раздвоитель , который может потребовать установки для сбора двух сетевых карт вместо одной – и это помимо основной, системной.

Естественно, вы можете настроить SPAN-порт и на самом устройстве доступа (маршрутизаторе), если оно это позволяет – Cisco Catalyst 6500, Cisco ASA. Вот пример такой конфигурации для коммутатора Cisco:
monitor session 1 source vlan 100 ! откуда берем пакеты
monitor session 1 destination interface Gi6/3! куда выдаем пакеты

SNMP

Что, если маршрутизатора под нашим контролем нет, с netflow связываться нет желания, нас не интересуют детали трафика наших пользователей. Они просто подключены в сеть через управляемый коммутатор, и нам надо просто грубо оценить объем трафика, приходящегося на каждый из его портов. Как вы знаете, сетевые устройства с возможностью удаленного управления поддерживают, и могут отобразить счетчики пакетов (байт), проходящих через сетевые интерфейсы. Для их опроса правильно будет использовать стандартизованный протокол удаленного управления SNMP . При помощи его можно достаточно просто получить не только значения указанных счетчиков, но также другие параметры, такие как имя и описание интерфейса, видимые через него MAC-адреса, и другую полезную информацию. Это делается как утилитами командной строки (snmpwalk), графическими SNMP-браузерами, так и более сложными программами мониторинга сети (rrdtools , cacti , zabbix , whats up gold и т.д.). Однако, данный метод имеет два существенных недостатка:

• блокировка трафика может производиться только путем полного отключения интерфейса, при помощи того же SNMP
• счетчики трафика, снимаемые по SNMP, относятся к сумме длин Ethernet-пакетов (причем unicast, broadcast и multicast по-отдельности), в то время как остальные описанные ранее средства дают величины относительно IP-пакетов. Это создает заметное расхождение (особенно на коротких пакетах) из-за оверхеда, вызванного длиной Ethernet-заголовка (впрочем, с этим можно приближенно бороться: L3_байт = L2_байт - L2_пакетов*38).

VPN

Отдельно стоит рассмотреть случай доступа пользователей к сети путем явного установления соединения к серверу доступа. Классическим примером может служить старый добрый dial-up, аналогом которого в современном мире являются VPN-службы удаленного доступа (PPTP, PPPoE, L2TP, OpenVPN, IPSEC)


Устройство доступа не только маршрутизирует IP-трафик пользователей, но также представляет из себя специализированный VPN-сервер, и терминирует логические туннели (часто зашифрованные), внутри которых передается пользовательский трафик.
Для учета такого трафика можно пользоваться как всеми средствами, описанными выше (и для глубокого анализа по портам/протоколам они хорошо подходят), так и дополнительными механизмами, которые предоставляют средства управления VPN-доступом. В первую очередь речь пойдет о протоколе RADIUS . Его работа – достаточно сложная тема. Мы же кратко упомянем, что контролем (авторизацией) доступа к VPN-серверу (RADIUS-клиенту) управляет специальное приложение (RADIUS-сервер), имеющее за собой базу (текстовый файл, SQL, Active Directory) допустимых пользователей с их атрибутами (ограничения по скорости подключения, назначенные IP-адреса). Помимо процесса авторизации, клиент периодически передает серверу сообщения аккаунтинга, информацию о состоянии каждой текущей работающей VPN-сессии, в том числе счетчики переданных байт и пакетов.

Заключение

Сведем все описанные выше методы сбора информации о трафике воедино:

Подведем небольшой итог. На практике существует большое количество методов присоединения управляемой вами сети (с клиентами или офисными абонентами) к внешней сетевой инфраструктуре, с использованием ряда средств доступа – программных и аппаратных маршрутизаторов, коммутаторов, VPN-серверов. Однако практически в любом случае можно придумать схему, когда информация о переданном по сети трафике может быть направлена на программное или аппаратное средство его анализа и управления. Возможно также, что это средство позволит осуществлять обратную связь с устройством доступа, применяя интеллектуальные алгоритмы ограничения доступа для отдельных клиентов, протоколов и прочего.
На этом закончу разбор матчасти. Из неразобранных тем остались:

• как и куда попадают собранные данные о трафике
• программное обеспечение для учета трафика
• чем отличается биллинг от простой “считалки”
• как можно накладывать ограничение на трафик
• учёт и ограничение посещенных веб-сайтов

Теги: Добавить метки

Анализ сетевого трафика

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

Во многих протоколах данные передаются в открытом, незашифрованном виде. Анализ сетевого трафика позволяет перехватывать данные, передаваемые по протоколам FTP и TELNET (пароли и идентификаторы пользователей), HTTP (Hypertext Transfer Protocol - протокол передачи гипертекстовых файлов - передача гипертекста между WEB-сервером и браузером, в том числе и вводимые пользователем в формы на web-страницах данные), SMTP, POP3, IMAP, NNTP (электронная почта и конференции) и IRC - Internet Relay Chat (online-разговоры, chat). Так могут быть перехвачены пароли для доступа к почтовым системам с web-интерфейсом, номера кредитных карт при работе с системами электронной коммерции и различная информация личного характера, разглашение которой нежелательно.

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

Анализ сетевого трафика позволяет:

• 1. Во-первых, изучить логику работы распределенной ВС, то есть получить взаимно однозначное соответствие событий, происходящих в системе, и команд, пересылаемых друг другу ее объектами, в момент появления этих событий (если проводить дальнейшую аналогию с инструментарием хакера, то анализ трафика в этом случае заменяет и трассировщик). Это достигается путем перехвата и анализа пакетов обмена на канальном уровне. Знание логики работы распределенной ВС позволяет на практике моделировать и осуществлять типовые удаленные атаки, рассмотренные в следующих пунктах на примере конкретных распределенных ВС.
• 2. Во-вторых, анализ сетевого трафика позволяет перехватить поток данных, которыми обмениваются объекты распределенной ВС. Таким образом, удаленная атака данного типа заключается в получении на удаленном объекте несанкционированного доступа к информации, которой обмениваются два сетевых абонента. Отметим, что при этом отсутствует возможность модификации трафика и сам анализ возможен только внутри одного сегмента сети. Примером перехваченной при помощи данной типовой удаленной атаки информации могут служить имя и пароль пользователя, пересылаемые в незашифрованном виде по сети.

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

Подмена доверенного объекта или субъекта распределенной ВС

Одной из проблем безопасности распределенной ВС является недостаточная идентификация и аутентификация ее удаленных друг от друга объектов. Основная трудность заключается в осуществлении однозначной идентификации сообщений, передаваемых между субъектами и объектами взаимодействия. Обычно в распределенных ВС эта проблема решается следующим образом: в процессе создания виртуального канала объекты РВС обмениваются определенной информацией, уникально идентифицирующей данный канал. Такой обмен обычно называется «рукопожатием» (handshake). Однако, отметим, что не всегда для связи двух удаленных объектов в РВС создается виртуальный канал. Практика показывает, что зачастую, особенно для служебных сообщений (например, от маршрутизаторов) используется передача одиночных сообщений, не требующих подтверждения.

Как известно, для адресации сообщений в распределенных ВС используется сетевой адрес, который уникален для каждого объекта системы (на канальном уровне модели OSI - это аппаратный адрес сетевого адаптера, на сетевом уровне - адрес определяется в зависимости от используемого протокола сетевого уровня (например, IP-адрес). Сетевой адрес также может использоваться для идентификации объектов распределенной ВС. Однако сетевой адрес достаточно просто подделывается и поэтому использовать его в качестве единственного средства идентификации объектов недопустимо.

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

• · атака при установленном виртуальном канале,
• · атака без установленного виртуального канала.

В случае установленного виртуального соединения атака будет заключаться в присвоении прав доверенного субъекта взаимодействия, легально подключившегося к объекту системы, что позволит атакующему вести сеанс работы с объектом распределенной системы от имени доверенного субъекта. Реализация удаленных атак данного типа обычно состоит в передаче пакетов обмена с атакующего объекта на цель атаки от имени доверенного субъекта взаимодействия (при этом переданные сообщения будут восприняты системой как корректные). Для осуществления атаки данного типа необходимо преодолеть систему идентификации и аутентификации сообщений, которая, в принципе, может использовать контрольную сумму, вычисляемую с помощью открытого ключа, динамически выработанного при установлении канала, случайные многобитные счетчики пакетов и сетевые адреса станций. Однако на практике, например, в ОС Novell NetWare 3.12-4.1 для идентификации пакетов обмена используются два 8-битных счетчика - номер канала и номер пакета; в протоколе TCP для идентификации используются два 32-битных счетчика.

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

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

Посылка ложных управляющих сообщений может привести к серьезным нарушениям работы распределенной ВС (например, к изменению ее конфигурации). Рассмотренная типовая удаленная атака, использующая навязывание ложного маршрута, основана на описанной идее.

Подмена доверенного объекта РВС является активным воздействием, совершаемым с целью нарушения конфиденциальности и целостности информации, по наступлению на атакуемом объекте определенного события Данная удаленная атака может являться как внутрисегментной, так и межсегментной, как с обратной связью так и без обратной связи с атакуемым объектом и осуществляется на сетевом и транспортном уровнях модели OSI.

Внедрение в распределенную ВС ложного объекта путем использования недостатков алгоритмов удаленного поиска

В распределенной ВС часто оказывается, что ее удаленные объекты изначально не имеют достаточно информации, необходимой для адресации сообщений. Обычно такой информацией являются аппаратные (адрес сетевого адаптера) и логические (IP-адрес, например) адреса объектов РВС. Для получения подобной информации в распределенных ВС используются различные алгоритмы удаленного поиска, заключающиеся в передаче по сети специального вида поисковых запросов, и в ожидании ответов на запрос с искомой информацией. После получения ответа на запрос, запросивший субъект РВС обладает всеми необходимыми данными для адресации. Руководствуясь полученными из ответа сведениями об искомом объекте, запросивший субъект РВС начинает адресоваться к нему. Примером подобных запросов, на которых базируются алгоритмы удаленного поиска, могут служить SAP-запрос в ОС Novell NetWare, ARP- и DNS-запрос в сети Internet.

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

Другой вариант внедрения в РВС ложного объекта использует недостатки алгоритма удаленного поиска и состоит в периодической передаче на атакуемый объект заранее подготовленного ложного ответа без приема поискового запроса. В самом деле, атакующему для того, чтобы послать ложный ответ, не всегда обязательно дожидаться приема запроса (он может, в принципе, не иметь подобной возможности перехвата запроса). При этом атакующий может спровоцировать атакуемый объект на передачу поискового запроса, и тогда его ложный ответ будет немедленно иметь успех. Данная типовая удаленная атака чрезвычайно характерна для глобальных сетей, когда у атакующего из-за нахождения его в другом сегменте относительно цели атаки просто нет возможности перехватить поисковый запрос.

Ложный объект РВС - активное воздействие, совершаемое с целью нарушения конфиденциальности и целостности информации, которое может являться атакой по запросу от атакуемого объекта а также безусловной атакой. Данная удаленная атака является как внутрисегментной, так и межсегментной, имеет обратную связь с атакуемым объектом и осуществляется на канальном и прикладном уровнях модели OSI.

Использование ложного объекта для организации удаленной атаки на распределенную ВС

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

Селекция потока информации и сохранение ее на ложном объекте РВС

Одной из атак, которую может осуществлять ложный объект РВС, является перехват передаваемой между субъектом и объектом взаимодействия информации. Важно отметить, что факт перехвата информации (файлов, например) возможен из-за того, что при выполнении некоторых операций над файлами (чтение, копирование и т.д.) содержимое этих файлов передается по сети, а, значит, поступает на ложный объект. Простейший способ реализации перехвата - это сохранение в файле всех получаемых ложным объектом пакетов обмена.

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

Модификация информации

Одной из особенностей любой системы воздействия, построенной по принципу ложного объекта, является то, что она способна модифицировать перехваченную информацию. Следует особо отметить, что это один из способов, позволяющих программно модифицировать поток информации между объектами РВС с другого объекта. Ведь для реализации перехвата информации в сети необязательно атаковать распределенную ВС по схеме «ложный объект». Эффективней будет атака, осуществляющая анализ сетевого трафика, позволяющая получать все пакеты, проходящие по каналу связи, но, в отличие от удаленной атаки по схеме «ложный объект», она не способна к модификации информации.

• · модификация передаваемых данных;
• · модификация передаваемого кода.

Одной из функций, которой может обладать система воздействия, построенная по принципу «ложный объект», является модификация передаваемых данных. В результате селекции потока перехваченной информации и его анализа система может распознавать тип передаваемых файлов (исполняемый или текстовый). Соответственно, в случае обнаружения текстового файла или файла данных появляется возможность модифицировать проходящие через ложный объект данные. Особую угрозу эта функция представляет для сетей обработки конфиденциальной информации.

Другим видом модификации может быть модификация передаваемого кода. Ложный объект, проводя семантический анализ проходящей через него информации, может выделять из потока данных исполняемый код. Известный принцип неймановской архитектуры гласит, что не существует различий между данными и командами. Следовательно, для того, чтобы определить, что передается по сети - код или данные, необходимо использовать определенные особенности, свойственные реализации сетевого обмена в конкретной распределенной ВС или некоторые особенности, присущие конкретным типам исполняемых файлов в данной локальной ОС.

Представляется возможным выделить два различных по цели вида модификации кода:

• · внедрение РПС (разрушающих программных средств);
• · изменение логики работы исполняемого файла. В первом случае при внедрении РПС исполняемый файл модифицируется по вирусной технологии: к исполняемому файлу одним из известных способов дописывается тело РПС, а также одним из известных способов изменяется точка входа так, чтобы она указывала на начало внедренного кода РПС. Описанный способ, в принципе, ничем не отличается от стандартного заражения исполняемого файла вирусом, за исключением того, что файл оказался поражен вирусом или РПС в момент передачи его по сети! Такое возможно лишь при использовании системы воздействия, построенной по принципу «ложный объект». Конкретный вид РПС, его цели и задачи в данном случае не имеют значения, но можно рассмотреть, например, вариант использования ложного объекта для создания сетевого червя - наиболее сложного на практике удаленного воздействия в сетях, или в качестве РПС использовать сетевые шпионы.

Во втором случае происходит модификация исполняемого кода с целью изменения логики его работы. Данное воздействие требует предварительного исследования работы исполняемого файла и, в случае его проведения, может принести самые неожиданные результаты. Например, при запуске на сервере (например, в ОС Novell NetWare) программы идентификации пользователей распределенной базы данных ложный объект может так модифицировать код этой программы, что появится возможность беспарольного входа с наивысшими привилегиями в базу данных.

Подмена информации

Ложный объект позволяет не только модифицировать, но и подменять перехваченную им информацию. Если модификация информации приводит к ее частичному искажению, то подмена - к ее полному изменению.

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

Предположим, что ложный объект контролирует событие, которое состоит в подключении пользователя к серверу. В этом случае он ожидает, например, запуска соответствующей программы входа в систему. В случае, если эта программа находится на сервере, то при ее запуске исполняемый файл передается на рабочую станцию. Вместо того, чтобы выполнить данное действие, ложный объект передает на рабочую станцию код заранее написанной специальной программы - захватчика паролей. Эта программа выполняет визуально те же действия, что и настоящая программа входа в систему, например, запрашивая имя и пароль пользователя, после чего полученные сведения посылаются на ложный объект, а пользователю выводится сообщение об ошибке. При этом пользователь, посчитав, что он неправильно ввел пароль (пароль обычно не отображается на экране) снова запустит программу подключения к системе (на этот раз настоящую) и со второго раза получит доступ. Результат такой атаки - имя и пароль пользователя, сохраненные на ложном объекте.

Отказ в обслуживании

Одной из основных задач, возлагаемых на сетевую ОС, функционирующую на каждом из объектов распределенной ВС, является обеспечение надежного удаленного доступа с любого объекта сети к данному объекту. В общем случае в распределенной ВС каждый субъект системы должен иметь возможность подключиться к любому объекту РВС и получить в соответствии со своими правами удаленный доступ к его ресурсам. Обычно в вычислительных сетях возможность предоставления удаленного доступа реализуется следующим образом: на объекте РВС в сетевой ОС запускаются на выполнение ряд программ-серверов (например, FTP -сервер, WWW-сервер и т.п.), предоставляющих удаленный доступ к ресурсам данного объекта. Данные программы-серверы входят в состав телекоммуникационных служб предоставления удаленного доступа. Задача сервера состоит в том, чтобы, находясь в памяти операционной системы объекта РВС, постоянно ожидать получения запроса на подключение от удаленного объекта. В случае получения подобного запроса сервер должен по возможности передать на запросивший объект ответ, в котором либо разрешить подключение, либо нет (подключение к серверу специально описано очень схематично, так как подробности в данный момент не имеют значения). По аналогичной схеме происходит создание виртуального канала связи, по которому обычно взаимодействуют объекты РВС. В этом случае непосредственно ядро сетевой ОС обрабатывает приходящие извне запросы на создание виртуального канала (ВК) и передает их в соответствии с идентификатором запроса (порт или сокет) прикладному процессу, которым является соответствующий сервер.

Очевидно, что сетевая операционная система способна иметь только ограниченное число открытых виртуальных соединений и отвечать лишь на ограниченное число запросов. Эти ограничения зависят от различных параметров системы в целом, основными из которых являются быстродействие ЭВМ, объем оперативной памяти и пропускная способность канала связи (чем она выше, тем больше число возможных запросов в единицу времени).

Основная проблема состоит в том, что при отсутствии статической ключевой информации в РВС идентификация запроса возможна только по адресу его отправителя. Если в распределенной ВС не предусмотрено средств аутентификации адреса отправителя, то есть инфраструктура РВС позволяет с одного объекта системы передавать на другой атакуемый объект бесконечное число анонимных запросов на подключение от имени других объектов, то в этом случае будет иметь успех типовая удаленная атака «Отказ в обслуживании». Результат применения этой удаленной атаки - нарушение на атакованном объекте работоспособности соответствующей службы предоставления удаленного доступа, то есть невозможность получения удаленного доступа с других объектов РВС - отказ в обслуживании!

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

И последней, третьей разновидностью атаки «Отказ в обслуживании» является передача на атакуемый объект некорректного, специально подобранного запроса. В этом случае при наличии ошибок в удаленной системе возможно зацикливание процедуры обработки запроса, переполнение буфера с последующим зависанием системы и т.п.

Типовая удаленная атака «Отказ в обслуживании» является активным воздействием, осуществляемым с целью нарушения работоспособности системы безусловно относительно цели атаки. Данная УА является однонаправленным воздействием как межсегментным, так и внутрисегментным, осуществляемым на транспортном и прикладном уровнях модели OSI.

трафик пароль защита сетевой

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

Программа для контроля трафика в офисе

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

Программа для контроля трафика в школе

ИКС – это универсальный Интернет-шлюз с инструментами для защиты образовательной сети, учета трафика, управления доступом и развертывания почтового, прокси и файлового сервера.

Программа для контроля трафика дома

ИКС Lite - это бесплатный Интернет шлюз, который обеспечивает все потребности работы с Интернет дома. ИКС Lite является полнофункциональной версией Интернет Контроль Сервера, включающей в себя лицензию на 8 пользователей.

Виды сетей

• Домашние — объединяют компьютеры в одной квартире или доме.
• Корпоративные — связывают рабочие машины предприятия.
• Локальные сети — часто имеют замкнутую инфраструктуру.
• Глобальные — связывают целые регионы и могут включать в себя локальные сети.

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

Фирмы, которые не знакомы с понятием «трафик контроль», несут колоссальные убытки или полностью ограничивают доступ к информации. Есть более простой способ экономить безопасно — программа по контролю трафика в локальной сети.

Отслеживание трафика

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

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

Выгоды для руководителя

Программа контроля трафика:

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

Выгоды для системного администратора

Мониторинг трафика в локальной сети позволяет:

• ограничить доступ пользователей к нежелательной информации;
• оперативно получать данные об объёме трафика — исключение перегрузки сети;
• предотвратить проникновение в сеть вирусов и выявить нарушителей режима безопасности.

Варианты реализации контроля

Контроль интернет-трафика в корпоративной сети можно организовать несколькими способами:

1. Купить межсетевой экран с возможностью разграничения трафика.
2. Настроить прокси-сервера с NAT-драйверами с функциями по учёту трафика.
3. Использовать различные виды надстроек.

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

Преимущества ИКС

1. Статистические исследования выявили, что сотрудники 1/3 рабочего времени тратят на выход в интернет в личных целях. Специальный интернет-шлюз ИКС поможет предотвратить нецелевой доступ.
2. Система контроля расхода трафика ведёт учёт на любых операционных системах пользователей.
3. ИКС предлагает гибкие настройки.
4. Составляет подробные отчёты в удобной форме.

Скачать бесплатно!

Начните прямо сейчас — скачать демо-версию программы для контроля интернет-трафика с нашего сайта. Вы сможете использовать все функции нашего решения без ограничений в течение 35 дней! После окончания тестового периода нужно просто приобрести полную версию, оформив заказ или связавшись с нашими менеджерами.

Тип организации

Выберите тип организации Образовательное учреждение Бюджетное учреждение Коммерческая организация

Цены НЕ РАСПРОСТРАНЯЮТСЯ на частные негосударственные учреждения и учреждения послевузовского профессионального образования

Лицензия ИКС

Редакция

Не требуется ИКС Стандарт ИКС ФСТЭК

Для расчета стоимости ФСТЭК обратитесь в отдел продаж

Тип поставки

ИКС ИКС + SkyDNS ИКС + Kaspersky Web Filtering

Тип лицензии

Новая лицензия Расширение лицензии Техподдержка

Количество пользователей

Расширение лицензии