По мотивам хитростей.

Часто бывает, что канал загружен, а кем — неизвестно. В этом случае помогает команда

sh ip cache flow


В продолжении темы о ядерной подсистеме графов Netgraph FreeBSD Netgraph на примере Ethernet тоннеля попробуем посчитать трафик используя протокол Сisco netflow.

В прошлом обзоре мы познакомились с модулями ng_bridge, ng_ether и ng_ksocket и построили на их базе Ethernet тоннель через интернет, а сегодня я расскажу как, используя дополнительные модули netgraph, посчитать трафик, проходящий по этому тоннелю.

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

Аномальным для нас будет на момент снятия статистики:

1. Более 20 исходящих коннектов по 25 порту с 1 IP.
2. Более 100 исходящих коннектов по 80 порту с 1 IP.
3. Более 100 исходящих коннектов по 53 порту с 1 IP.
4. Придумывайте сами, всё гибко.

Статистику будем вынимать из кэша netflow маршрутизаторов. Будет ли это Cisco или FreeBSD — не важно. О настройке netflow на FreeBSD я рассказывал в предыдущих своих статьях.

По вопросу статистики в общем, и netflow в частности, есть довольно много довольно обширных статей (изучение которых требует приличного времени). Здесь я приведу свои скрипты as-is для не очень сложного ТЗ по сбору и отправке месячной статистики арендаторам.

Вводная

Несколько арендаторов получают интернет через NAT (сам NAT завязан через policy-routing на двух провайдеров). У каждого арендатора свой вилан. Вилан «разворачивается» в сеть арендатора через управляемый коммутатор. Каждому арендатору выдаётся свой сегмент локальной сети с запретом ходить в соседние сегменты.

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

Инструменты: используется netflow на циске, flow-tools на линуксе, MTA, cron.

Просмотрев большинство тематических постов на хабре был безмерно удивлён тому факту, что крайне скудно освещена тема использования ОС Unix/Linux на службе интернет провайдеров (Internet service provider). Данной статьёй я частично попытаюсь восполнить данный пробел.

Введение

Практически перед каждым администратором сети встает задача учета трафика. Либо это нужно для биллинга, либо просто для мониторинга активности.
Для решения этой задачи можно использовать стандартный протокол NetFlow (RFC 3954), который поддерживается производителями сетевого оборудования (Cisco, Juniper, 3Com и др.), а также Linux, *BSD и прошивкой DD-WRT. Netflow позволяет передавать данные о трафике (адрес отправителя и получателя, порт, количество информации и др.) с сетевого оборудования (сенсора) на коллектор. Коллектор, в свою очередь, сохраняет полученную информацию. В качестве коллектора можно использовать обычный сервер. Проиллюстрирую схему картинкой из википедии:



Когда я взялся настраивать NetFlow, оказалось что opensource решения для реализации коллектора плохо работают с Cisco ASA, а в Интернете очень мало информации, что в этом случае делать. Я решил восполнить этот пробел: подружить FreeBSD / Linux с Cisco ASA можно за 20 минут.

Общие сведения

• ipt-netflow — это самый быстрый netflow-сенсор (счётчик) для Линукса.
• Состоит из двух модулей: для ядра и для iptables.
• В стандартные ядро и iptables пока не входит — требует сборки из исходных текстов!
• Обсуждается включение в Debian — см. lists.debian.org/debian-mentors/2011/04/msg00070.html и bugs.debian.org/cgi-bin/bugreport.cgi?bug=620511

Всем доброго времени суток! Разбираясь с NetFlow, таким простым, удобным и часто используемым протоколом, я осознал, что он не такой уж и простой, и подводных камней при его эксплуатации хватает.
Под катом я собрал все, что для начала необходимо знать о NetFlow и его настройках на Cisco, отдал дань eucariot, пишущему отличные статьи о сетях, и… Картинки, немного веселых картинок.

NetFlow это сетевой протокол, созданный компанией Cisco Systems для учёта сетевого трафика. Наиболее распространёнными версиями данного протокола являются 5 и 9. Девятая версия более гибкая так как используются шаблоны, согласно которым присылаются данные. В пятой версии данные присылаются согласно спецификации.


Система сбора информации о трафике по протоколу NetFlow состоит из следующих компонентов:

• Сенсор. Устройство (маршрутизатор, L3-коммутатор) собирающее статистику по проходящему через него трафику;
• Коллектор. Занимается сбором данных от сенсора и помещает их в хранилище;
• Анализатор. Анализирует данные, которые собрал коллектор и формирует отчёты.

О разработки части функций анализатора на C#, а точнее разбор пакетов NetFlow я и расскажу

Введение

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

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

Первое, с чего пришлось начать, это с изучения данной статьи — http://habrahabr.ru/post/127613/ (автору gag_fenix большущий респект). Это единственная нормальная и полная статья о том, как можно получить и учитывать трафик на сетевом оборудование Cisco ASA с использованием nfdump. В этой статье отлично описана только реализация о том, как можно настроить оборудование на передачу пакетов NetFlow на хост, а также каким образом можно использовать полученные данные для последующего анализа. Сам же анализ трафика и его учет не рассматривается в статье.

Перед тем, как читать дальше, настоятельно рекомендую хорошо изучить вышеуказанную статью, так как некоторые особенности настройки будут опускаться. В статье рассмотрим такие вопросы о том, как вести учет по NetFlow (используя MySQL на коллекторе), как посчитать VPN трафик, какой тип пакетов учитывать, как избежать «удвоения» и «дублирования» трафика, и как использовать мое приложение.

Решение Cyber Threat Defense (CTD) способно выявлять и блокировать сложные атаки, включая атаки нулевого дня, утечки конфиденциальной информации и ботнеты. Это новые механизмы борьбы с продвинутыми угрозами с помощью анализа сетевой активности, которые будут раскрыты в статье на примере OpenSSL HeartBleed.

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

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

Если вас интересует тема мониторинга сети или есть желание сравнить мою работу с имеющейся у вас, приглашаю под кат.

За прошедшие почти 10 месяцев с релиза 1.0.0 была очень большая работа по улучшению программы.

Из основных изменений стоит отметить следующие:

• Возможность выявлять самые популярные виды атак: syn_flood, icmp_flood, udp_flood, ip_fragmentation_flood
• Добавление поддержки протокола Netflow, поддерживаются 5, 9 и 10 (IPFIX) версии
• Добавление поддержки протокола sFLOW v5, который поддерживается большинством современных сетевых коммутаторов
• Добавлена поддержка использования netmap (поддерживаются Linux и FreeBSD, для Linux предоставляется специальная версия драйвера ixgbe: github.com/pavel-odintsov/ixgbe-linux-netmap) для захвата пакетов. Данный режим обеспечивает наивысшую производительность захвата трафика наряду с PF_RING ZC.
• Добавлена поддержка PF_RING ZC (к сожалению, этот режим требует отдельной лицензии на библиотеку PF_RING)

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

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

ElasticSeach достаточно гибкая платформа, и полученные в него данные можно обрабатывать многими способами, даже за пределами стека ELK. Для этого предоставлено более десятка различных API. Но для многих задач будет достаточно и возможностей Kibana.

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

Добрый день!

Как вы поняли из названия, вас ждет очередная статья про NetFlow, но на этот раз с необычной стороны — со стороны реализации NetFlow сенсора на FPGA.

В мае мы поделились статистикой по самым популярным атакам с отражением. Тогда средний размер атаки SSDP был в районе 12 Гбит/с, а крупнейшая атака SSDP с отражением была такой:

• 30 Мп/с (миллионов пакетов в секунду)
• 80 Гбит/с (миллиардов бит в секунду)
• 940 тыс. IP-адресов для отражения

Всё изменилось пару дней назад, когда мы заметили необычно крупное умножение пакетов SSDP. Это достойно более тщательного расследования, поскольку атака преодолела символический рубеж в 100 Гбит/с.

График пакетов в секунду:

Источник

Всем привет! Сегодня мы продолжим рассказывать про облачное хранилище Техносерв Cloud, но уже с точки зрения эксплуатации. Ни одна ИТ-инфраструктура не обходится без инструментов мониторинга и управления, и наше облако не исключение. Для решения повседневных задач, связанных с мониторингом, мы используем продукты с открытым исходным кодом, одним из которых является стек ELK. В этой статье мы расскажем, как в нашем облаке устроен мониторинг журналов, и как ELK помог нам пройти аудит PCI DSS.

С точки зрения обеспечения кибербезопасности перед нами обычно стоит всего три основные задачи, которые, конечно, потом разбиваются на более мелкие подзадачи и проекты, но, немного утрируя, по-крупному, задач всего три:

• предотвращение угроз
• обнаружение угроз
• реагирование на угрозы.

Какие бы решения мы не рассматривали они укладываются в эти три задачи, которые мы должны реализовывать в любом месте корпоративной сети. Вот этот жизненный цикл борьбы с угрозами (ДО — ВО ВРЕМЯ — ПОСЛЕ) и положен в основу деятельности службы ИБ компании Cisco. Причем обращу внимание, что так как в компании Cisco отсутствует понятие периметра, то мы стараемся реализовать описанные выше три задачи везде — в ЦОДах, в облаках, в сегменте Wi-Fi, на мобильных устройствах сотрудников, в точках выхода в Интернет и, конечно же, в нашей внутренней сети, о мониторинге которой мы сегодня и поговорим.

Про то как снять NetFlow с микротика с сохранением трафика на сервере в Инете найти не сложно. Но понадобилось сохранить и содержимое трафика, а вот тут возникли небольшие сложности.
В принципе, про сам режим sniffer'а все очень доступно описано на вики Микротика, сложности возникли с сохранением трафика на внешний сервер.

Дело в том, что перехваченные пакеты микротик готов отправляет на сервер, но инкапсулируя их в протокол Tazmen Sniffer Protocol (TZSP). А вот как потом извлечь их для работы, скажем, с тем же tcpdump'ом, вот это задача. Гугленье показало, что этот протокол "из коробки" понимает Wireshark, но тот же гугл сказал, что Wireshark не сохраняет принятые данные в файл. А это очень нужно было.