Сегодня стало очевидно, что контроль наложения правил в сети стал необходим для отслеживания, насколько эффективно эти правила соблюдаются. Опыт показывает, что, к сожалению, в реальности теория регулировки сети политиками и правилами часто далека от реальности. Причинами этого являются, в частности, неправильная конфигурация, плохая архитектура, аварии оборудования, пренебрежения политиками и уязвимости используемого оборудования. Количество переменных факторов в современных сетях не позволяет гарантировать эффективность работы системы наложения правил. Мониторинг реального состояния позволяет восстановить ситуацию. NetFlow как источник достоверной информацииКогда вам надо восстановить факты, очень важно иметь надежный источник информации. Механизм наложения правил в условиях аварии является плохим свидетелем по двум причинам. Во-первых, если он скомпрометирован, то надежность его логов очень сомнительна. Во-вторых, это механизм был обойден (например, ма
...
Читать дальше »
|
В последние десять лет системы безопасности в основном фокусируются на просмотре входящего интернет-трафика, что позволяет обнаруживать широкий ряд событий, нарушающих безопасность, таких как спам, фишинг, DDoS, SQL injection и переполнение буфера. За последние пару лет исследования, проведенные такими организациями, как Verizon, Symantec Research, Gartner, Mandiant, привели к тому, что стало понятно, что контролировать надо и выходящий трафик. Это позволяет обнаруживать соединения с ботнетами, серверами типа command-and-control, утечки данных и нарушения политик безопасности. Что касается мониторинга "перпендикулярного" (скажем, подсеть-подсеть) трафика, то об этом почему-то забывают, хотя эти исследования могут помочь определить влияние атаки. Проблема в том, чтобы нормально осуществлять такой мониторинг, необходимо множество зондов (пробов). Технологии типа NetFlow или IPFIX упрощают эту проблему, поскольку в качестве таких зондов можно использовать уже суще
...
Читать дальше »
|
Многих интересует "проблема"
дублирования потоков. Вопрос связан с мнением, что дублирование потоков
не эффективно, потребляет излишние ресурсы и поэтому должно быть
исключено. Дублирование потоков присуще и стратегии сбора NetFlow и здесь
мы хотим показать, что это хорошая вещь и вот почему:
- Сетевые потоки это и есть то, что обеспечивает видимость сети, а у нас никогда не бывает слишком много информации.
Потоковые данные предоставляют жизненно необходимые данные о трафике и
статистику интерфейсов роутеров и коммутаторов на каждом слое сети. Это
позволяет нам анализировать данные Layer 3,4 и 7 для каждого интерфейса,
чтобы решать проблемы, понимать потребление полосы, планировать
емкость, проводить анализ сетевой сегментации и т.п. Кроме того, могут
собираться важные данные, включая информацию MPLS, BGP и пиринговые
данные. Мы можем получать информацию о качестве сервиса и VLAN. Не
важно, где вы собираете Ne
...
Читать дальше »
|
Диаграммы Ganglia показывают метрики состояния и производительности, которые собираются при помощи sFlow.  Комбинация Ganglia и sFlow позволяет создать масштабируемое решение для мониторинга производительности больших компьютерных кластеров на базе GPU, исключая необходимость сбора GPU-метрик. Вместо этого все метрики хоста и GPU эффективно принудительно направляются прямо в центральный коллектор Ganglia. Эта копия экрана показывает новые метрики GPU, включая: • Процессы • Утилизация GPU • Утилизацию памяти • Ошибки ECC • Питание • Температуру Подробно основные шаги, которые необходимо предпринять для конфигурирования Ganglia как коллектора sFlow описаны в статье
...
Читать дальше »
|
 Обсудим несколько методов идентификации того, как много приложения Google "отъедают" от вашего канала связи. Каков диапазон IP-адресов Google?Когда вы собираетесь организовать мониторинг приложений Google для бизнеса или приложений Google для образования, первое, что необходимо сделать - это идентифицировать сети Google. Проблема в том, что Google может изменять свой сетевой диапазон в любое время, поэтому вам приходится "стрелять в движущуюся мишень". К счастью, Google и обеспечивает нас простым методом обнаружения своих IP-адресов в любой момент времени. Вы можете сделать это, использую команду dig, которая является частью сервиса BIND DNS и может быть найдена во многих бесплатных сервисах dig. ‘dig -t txt _netblocks.google.com’
Это похоже на вопрос: "Каков диапазон IP-адресов Google?". В ответе вы сможете найти все сети Google. Имейте в виду, что эти сети мог
...
Читать дальше »
|
Переключение с Ingress на EgressНачало темы смотрите в этом посте. Что если вам как-то по определенным причинам потребуется экспортировать как ingress, так и egress NetFlow с нескольких коммутаторов Cisco. Что по этому поводу скажут ваши сетевые специалисты? Полагаю, ничего. Они будут в затруднении. Положим вам хочется, чтобы анализатор трафика показывал оба типа NetFlow отдельно, а также чтобы он показывал утилизацию сети с помощью как ingress, так и egress NetFlow (либо IPFIX). А что тогда с сохраненной историей в базе данных? Ведь вся история на этот момент - это именно входящий (ingress) трафик.  Еще шаг вперед. После двух недель сбора выходящих потоков вы решаете определить с помощью NetFlow тренд выходящего трафика за последние 30 дней. При использовании истории вам придется учитывать переход с
...
Читать дальше »
|
Системные требования для коллектора NetFlow значительно выше, чем для обычных программ. Очень часто, даже самые лучшие серверы работают медленно. Как правило это связано с неправильной конфигурацией жестких дисков. Вы должны помнить, что диск ограничен в количестве операций записи в единицу времени и если коллектор не может писать на диск достаточно быстро, это может вызвать многочисленные проблемы. Это основная проблема медленной работы коллекторов NetFlow. Большая сеть может иметь тысячи потоков в секунду и каждый из них должен быть записан на диск. Реальная проблема заключается в том, что в среднем стандартный диск, работающий со скоростью 7200 RPM, достигает максимум 100 IOPS (операций чтения/записи в секунду). Просто поставив диски, работающие на скорости 15000 RPM, вы можете удвоить производительность, но даже такой диск может не справиться при большом количеств
...
Читать дальше »
|
Вы рассматриваете конфигурацию экспорта NetFlow с выходящими (egress) потоками? А знаете ли вы, почему вам следует или не следует экспортировать выходные потоки? Большинство из нас экспортирует NetFlow v5, который поддерживает только входящие потоки. Это означает, что трафик, приходящий на интерфейс, контролируется и экспортируется в датаграммы NetFlow. А что с трафиком, который выходит из интерфейса? А вот он не контролируется с помощью NetFlow v5. Большинство производителей контролируют входящие потоки на приемном интерфейсе. При этом, используя эту информацию, вы можете определить выходную утилизацию на любом интерфейсе, если (это важно!) вы включили NetFlow на всех интерфейсах коммутатора или маршрутизатора. Давайте рассмотрим ситуацию, когда NetFlow включен на интерфейсах 1 и 2 из трех интерфейсов маршрутизатора. Трафик, приходящий на интерфейс 3, который
...
Читать дальше »
|
Интерес к системам мониторинга облачных сервисов растет по мере увеличения интереса бизнеса к этому типу услуг. Здесь мы расскажем о нескольких возможностях мониторинга облака путем использования маршрутизаторов Cisco и системы мониторинга производительности на базе Flexible NetFlow или экспорта Medianet. Flexible NetFlow (FnF) рекламируется Cisco как технология, позволяющая контролировать качество медийных приложений. Новый FnF-экспорт позволяет получить детали TCP round trip time, а для VoIP он обеспечивает измерение джиттера и метрик потерь пакетов. В первом примере мы используем вариант, когда сотрудники компании используют облачные сервисы типа Vonage. Ниже, мы видим первые 10 из 23 страниц вызовов.  А выше вы можете видеть, что большая часть вызовов имеет низкое значение джиттера. И обратите внимание, что вы можете сортировать данные по значению потерь пакетов путем кликания на заголово
...
Читать дальше »
|
Коллектор NetFlow, поддерживающий большие объемы данных - это то устройство, которое просто необходимо для сервис-провайдеров и университетов. Из-за природы трафика, который производится этими типами организаций, производится просто гигантское количество потоков. Люди, посещающие поисковые сайты типа Google, или те из нас, кто просто кликает на различные линки в Facebook или YouTube, чаще всего создают новый поток с каждым кликом. VoIP, BitTorrent, Skype, iCloud и другие прелести нового Интернета, которые присутствуют в сети, создают все новые и новые потоки. Если рассматривать это с точки зрения отчетности на базе NetFlow или IPFIX, производители понимают, что только 2-3 параметра входят в игру, когда встает вопрос о масштабировании систем на базе NetFlow: • Количество устройств, экспортирующих потоки • Количество интерфейсов, во всех этих устройствах • Общее количество потоков в секунду Высокоскоростной сбор Net
...
Читать дальше »
| |
Меню сайта