Часто возникает ситуация, когда в кластере работает много взаимодействующих между собой сервисов, но из-за спонтанности разработки эти взаимодействия могут быть нигде не документированы. То есть ни команды разработки, ни команды эксплуатации доподлинно не знают, какие приложения куда обращаются, как часто, и какую нагрузку создают эти обращения. И когда возникает проблема с производительностью какого-то сервиса, не совсем понятно, на что нужно обратить внимание.
Рубрика «netflow»
Мониторинг межсервисного взаимодействия Kubernetes с помощью протокола NetFlow
2022-12-15 в 7:12, admin, рубрики: devops, Go, Grafana, kubernetes, netflow, Блог компании Флант, Сетевые технологии, сети, системное администрированиеКейсы для применения средств анализа сетевых аномалий: обнаружение распространения вредоносного кода
2020-02-07 в 22:39, admin, рубрики: Cisco, nbad, netflow, nta, Блог компании Cisco, вредоносное ПО, вредоносный код, информационная безопасность, сканирование, сканирование портовПродолжу рассмотрение кейсов, связанных с применением решений по мониторингу ИБ с помощью решения класса NTA (Network Traffic Analysis). В прошлый раз я показал, как можно обнаруживать утечки информации, а в этот раз поговорим о выявлении вредоносного кода внутри корпоративной или ведомственной сети.
Обнаружение DDoS-атак «на коленке»
2019-12-01 в 14:20, admin, рубрики: ddos, flow-tools, juniper, netflow, python, информационная безопасность, Сетевые технологииПриветствую! Я работаю в небольшом интернет провайдере масштаба области. У нас транзитная сеть (это значит, что мы покупаем интернет у богатых провайдеров и продаем его бедным). Несмотря на небольшое количество клиентов и такое же небольшое количество трафика протекающего по нашей сети, довольно часто приходится иметь дело с весьма внушительными DDoS-атаками по 10-20Гбит/с. (чаще всего конечно это атаки гораздо меньшего калибра). И хотя некоторые из наших клиентов обзавелись уже системами обнаружения таких атак и могут самостоятельно отправить жертву в блек-холл, гораздо чаще обнаружение атаки и бан конкретного IP жертвы ложится на наши плечи (тем более, если атака способна забить наши внешние каналы).
О решении, которое помогает обнаруживать эти самые атаки и которое принято у нас в сети, я и хотел бы рассказать. Оно бесплатно, основывается на анализе данных NetFlow, поэтому просто и весьма эффективно.
Читать полностью »
VyOS OpenSource Router
2019-01-31 в 0:58, admin, рубрики: 802.1Q, Accel-ppp, Alibaba Cloud, Amazon EC2, Ansible, BGP, BGP-peer, citrix xenserver, CloudPack, clustering, Conntrack-Sync, Debian, dell, DHCP Client, DHCP Server, DMVPN, EdgeCore, FRRouting, gateway, Google Cloud Platform, GRE, IGMP-Proxy, IP6IP6, iperf, IPIP, IPIP6, ipsec, IPSec VTI, IPSec/GRE, IPv4, IPv6, ISC-DHCP, isc-dhcp-server, junos, keepalived, kvm, l2tp, L2TPv3, L2TPv3 Router, lacp, layer 2, lldp, mDNS, mDNS-repeater, Microsoft Azure, Microsoft Hyper-V, netflow, Nutanix AHV, open source, OpenNHRP, opensource, openstack, openvpn, ospf, OSPFv3, Packet Cloud, Policy-Based Routing, powerdns, PPPoE server, PPTP, QinQ, quagga, Ravello, RHEV, rip, RIPng, saltstack, sFlow, SIT, site-to-site vpn, snmp, squid, ssh, strongswan, supermicro, syslog, tftp, TFTP Server, virtualbox, VLAN, VMWare ESXi, vpn, VPN Gateway, VPN RA, vrrp, vxlan, vyatta, vyOS, WAN load-balancing, wireguard, xL2tpd, Сетевые технологии, СофтВ этой статье я хотел поднять не стандартную для меня тему о сетевом маршрутизаторе VyOS. Впервые я познакомился с этим проектом благодаря Нилу Андерсону (Neil Anderson) который составил гайд как у себя дома развернуть мини-лабораторию с NetApp симулятором и VyOS.
Ключевые проекты
VyOS это opensource проект на базе Debian Linux, который родился как форк от проекта Vyatta Core Edition of the Vyatta Routing software. Как и любой роутер VyOS оперирует на третьем уровне OSI и маршрутизирует North-South трафик. VyOS включает в себя следующие ключевые проекты:
- Debian 8, ядро 4.19
- FRRouting (в версии 1.1 и более древних использовался Quagga)
- ISC-DHCP
- Keepalived
- StrongSwan
- OpenVPN
- PowerDNS
- Wireguard
- OpenNHRP
- Accel-ppp
- xL2tpd
- Squid
- mDNS-repeater
- IGMP-Proxy
- iPerf
- более детальный список в Release notes
Сохранение трафика от сниффера Mikrotik’а
2018-07-06 в 12:34, admin, рубрики: mikrotik, netflow, sniffer, tcpdump, Сетевые технологии, системное администрированиеПро то как снять NetFlow с микротика с сохранением трафика на сервере в Инете найти не сложно. Но понадобилось сохранить и содержимое трафика, а вот тут возникли небольшие сложности.
В принципе, про сам режим sniffer'а все очень доступно описано на вики Микротика, сложности возникли с сохранением трафика на внешний сервер.
Дело в том, что перехваченные пакеты микротик готов отправляет на сервер, но инкапсулируя их в протокол Tazmen Sniffer Protocol (TZSP). А вот как потом извлечь их для работы, скажем, с тем же tcpdump'ом, вот это задача. Гугленье показало, что этот протокол "из коробки" понимает Wireshark, но тот же гугл сказал, что Wireshark не сохраняет принятые данные в файл. А это очень нужно было.
Хранилище логов для облачной платформы. Опыт внедрения ELK
2017-08-29 в 8:25, admin, рубрики: elk, kibana, netflow, open source, pci dss, Блог компании ТЕХНОСЕРВ, высокая производительность, информационная безопасность, мониторинг логов, облака, техносерв cloud
Всем привет! Сегодня мы продолжим рассказывать про облачное хранилище Техносерв Cloud, но уже с точки зрения эксплуатации. Ни одна ИТ-инфраструктура не обходится без инструментов мониторинга и управления, и наше облако не исключение. Для решения повседневных задач, связанных с мониторингом, мы используем продукты с открытым исходным кодом, одним из которых является стек ELK. В этой статье мы расскажем, как в нашем облаке устроен мониторинг журналов, и как ELK помог нам пройти аудит PCI DSS.
Stupidly Simple DDoS Protocol (SSDP) генерирует DDoS на 100 Гбит-с
2017-07-10 в 17:53, admin, рубрики: BCP38, BGP flowspec, ddos, IP-спуфинг, netflow, ssdp, udp, Серверное администрирование, Сетевые технологии, системное администрирование, хостинг, метки: SSDPВ мае мы поделились статистикой по самым популярным атакам с отражением. Тогда средний размер атаки SSDP был в районе 12 Гбит/с, а крупнейшая атака SSDP с отражением была такой:
- 30 Мп/с (миллионов пакетов в секунду)
- 80 Гбит/с (миллиардов бит в секунду)
- 940 тыс. IP-адресов для отражения
Всё изменилось пару дней назад, когда мы заметили необычно крупное умножение пакетов SSDP. Это достойно более тщательного расследования, поскольку атака преодолела символический рубеж в 100 Гбит/с.
График пакетов в секунду:
Анализ комуникации из Tor сети в инфраструктуру с помощью ELK стека
2017-05-15 в 5:33, admin, рубрики: elasticsearch, elk, netflow, nosql, python, Tor, информационная безопасностьElasticSeach достаточно гибкая платформа, и полученные в него данные можно обрабатывать многими способами, даже за пределами стека ELK. Для этого предоставлено более десятка различных API. Но для многих задач будет достаточно и возможностей Kibana.
Одной из таких я хотел бы поделиться с сообществом. Для меня, как и любого безопасника, важно видеть и понимать коммуникацию своей инфраструктуры с внешним миром. Одной из самых интересных является коммуникация с луковой сетью (Tor).
Реализация NetFlow сенсора на FPGA + CPU — гибко и быстро
2017-05-03 в 11:01, admin, рубрики: co-design, fpga, IPFIX, netflow, Анализ и проектирование системДобрый день! Как вы поняли из названия, вас ждет очередная статья про NetFlow, но на этот раз с необычной стороны — со стороны реализации NetFlow сенсора на FPGA.
Защита платежной инфраструктуры банка
2016-04-01 в 19:57, admin, рубрики: amp, AnyConnect, Cisco, CTD, Cyber Threat Defense, Firepower, ISE, NAC, netflow, TrustSec, zFlow, Банк России, Блог компании Cisco, информационная безопасность1-го апреля Банк России опубликовал (и это не шутка) обзр о несанкционированных переводах платежных средств, в котором привел данные не только об объемах и количестве несанкционированных операций, совершенных с использование электронных средств платежа (включая платежные карты и системы дистанционного банковского обслуживания), но и описал причины, которые привели к несанкционированным операциям и повышению риска их осуществления.
По мнению специалистов Банка России именно недостаточная защищенность внутренней инфраструктуры локальной вычислительной сети (ЛВС) операторов по переводу денежных средств, то есть банков, операторов услуг платежной инфраструктуры, а также использование в отношении их работников методов социальной инженерии (например, рассылки электронных сообщений, содержащих вредоносный код или ссылки на вредоносные сайты) могут привести к реализации атак на информационную инфраструктуру, в том числе на банкоматы кредитных организаций и серверы управления такими устройствами. И акцент в действиях злоумышленников смещается — если раньше они действовали против клиентов банков, атакуя рабочие места, с установленным программным обеспечением для перевода денежных средств (клиент-банк или Интернет-банк), включая и мобильные устройства, то в 2015-м году возросло число целевых атак на операционную (платежную инфраструктуру кредитных организаций и платежных систем.Читать полностью »