Cisco *

Привет, Хабр. Заканчиваю цикл статей, посвященных запуску курса "Сетевой инженер" от OTUS, по технологии VxLAN EVPN по маршрутизации внутри фабрики и использовании Firewall для ограничения доступа между внутренними сервисами

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

С августа 2017 года, когда компания Cisco приобрела компанию Viptela, основной предлагаемой технологией организации распределенных корпоративных сетей стала Cisco SD-WAN. За прошедшие 3 года SD-WAN технология прошла множество изменений, как качественного, так и количественного характера. Так значительно расширились функциональные возможности и появилась поддержка на классических маршрутизаторах серий Cisco ISR 1000, ISR 4000, ASR 1000 и виртуального CSR 1000v. В то же время многие заказчики и партнеры Cisco продолжают задаваться вопросом – в чем заключаются отличия Cisco SD-WAN от уже привычных подходов на базе таких технологий, как Cisco DMVPN и Cisco Performance Routing и насколько эти отличия важны?

Здесь сразу следует сделать оговорку, что до появления SD-WAN в портфолио Cisco, DMVPN совместно с PfR составляли ключевую часть в архитектуре Cisco IWAN (Intelligent WAN), которая в свою очередь представляла собой предшественника полновесной SD-WAN технологии. При общем сходстве, как самих решаемых задач, так и способов их решения, IWAN так и не получил необходимого для SD-WAN уровня автоматизации, гибкости и масштабируемости и со временем развитие IWAN значительно снизилось. В то же время сами технологии-составляющие IWAN никуда не делись, и многие заказчики продолжают их успешно использовать в том числе на современном оборудовании. В итоге сложилась интересная ситуация – одно и то же оборудование Cisco позволяет выбрать наиболее подходящую технологию построения WAN (классическую, DMVPN+PfR или SD-WAN) в соответствии с требованиями и ожиданиями заказчиков.

Не так давно я писал про мониторинг Netflow/IPFIX и про Cisco StealthWatch — аналитическое решение, которое позволяет детектировать такие события, как сканирования, распространение сетевых червей, шпионское ПО, нелегитимные взаимодействия и различного рода аномалии.

Ссылки на все статьи в цикле:
1) StealthWatch: базовые понятия и минимальные требования. Часть 1
2) StealthWatch: развертывание и настройка. Часть 2
3) StealthWatch: анализ и расследование инцидентов. Часть 3
4) StealthWatch: интеграция с Cisco ISE. Часть 4
5) Stealthwatch Cloud. Быстрое, удобное и эффективное решение для облачных и корпоративных инфраструктур. Часть 5

Мониторинг облачной инфраструктуры давно уже не является новой задачей, так у каждого крупного игрока, есть свои инструменты — Amazon CloudWatch или Amazon S3, Google Stackdriver, Azure Monitor. Эти инструменты отлично подходят для мониторинга приложений, производительности и инфраструктуры в целом, но они не закрывают задачи по безопасности (да и сами провайдеры облаков не сильно ей обеспокоены): распространение зловредного ПО, ботнет-коммуникации, обнаружение аномалий, попытки сканирования, нелегитимный доступ (включая варианты с использованием легитимных учетных данных) и многое другое.

В более ранних статьях было рассмотрено несколько обширных тем касательно решения по мониторингу Cisco StealthWatch. Напомню, что StealthWatch — решение по мониторингу трафика в сети на предмет инцидентов безопасности и легитимности сетевого взаимодействия. В основе работы StealthWatch лежит сбор NetFlow и IPFIX с маршрутизаторов, коммутаторов и других сетевых устройств.

Ссылки на все статьи в цикле:
1) StealthWatch: базовые понятия и минимальные требования. Часть 1
2) StealthWatch: развертывание и настройка. Часть 2
3) StealthWatch: анализ и расследование инцидентов. Часть 3
4) StealthWatch: интеграция с Cisco ISE. Часть 4
5) Stealthwatch Cloud. Быстрое, удобное и эффективное решение для облачных и корпоративных инфраструктур. Часть 5

Мониторинг, в частности Cisco StealthWatch, — это прежде всего решение по детектированию угроз и атак. Все мониторинговые решения не подразумевают в себе предотвращение угроз, однако часто это требуется. У StealthWatch есть интеграция “из коробки” с Cisco ISE (Identity Services Engine). Интеграция состоит в том, что StealthWatch обнаруживает инцидент безопасности, а Cisco ISE вносит в хост карантин до момента, пока администратор руками его из карантина не вынесет.

В данной статье рассматривается настройка интеграции и пример срабатывания.

Cisco StealthWatch — это аналитическое решение в области ИБ, которое обеспечивает всесторонний мониторинг угроз в распределенной сети. В основе работы StealthWatch лежит сбор NetFlow и IPFIX с маршрутизаторов, коммутаторов и других сетевых устройств. В результате сеть становится чувствительным сенсором и позволяет администратору заглянуть туда, куда не могут добраться традиционные методы защиты сети, например, Next Generation Firewall.

Ссылки на все статьи в цикле:
1) StealthWatch: базовые понятия и минимальные требования. Часть 1
2) StealthWatch: развертывание и настройка. Часть 2
3) StealthWatch: анализ и расследование инцидентов. Часть 3
4) StealthWatch: интеграция с Cisco ISE. Часть 4
5) Stealthwatch Cloud. Быстрое, удобное и эффективное решение для облачных и корпоративных инфраструктур. Часть 5

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

Всем привет!

Уже и не думал что вернусь к этому кейсу, но Cisco Open Air Wireless Marathon подтолкнул меня вспомнить и рассказать про личный опыт, когда чуть больше года назад мне довелось потратить довольно много времени над изучением проблемы с беспроводной сетью на базе Cisco и телефонами iPhone. Мне поручили разобраться над вопросом одного из руководителей: «Почему после перезагрузки iPhone не может автоматически подключиться к Wi-Fi сети, а при ручном подключении просит ввести логин и пароль?».

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

---

Привет, хабр. В настоящее время я являюсь руководителем курса "Сетевой инженер" в OTUS.
В преддверии старта нового набора на курс "Сетевой инженер", я подготовил цикл статей по технологии VxLAN EVPN.

Существует огромное множество материалов по работе VxLAN EVPN, поэтому я хочу собрать различные задачи и практики решения задач в современном ЦОД.

---

В первой части цикла по технологии VxLAN EVPN хочу рассмотреть способ организации L2 cвязанности между хостами поверх сетевой фабрики.

Все примеры будем выполнять на Cisco Nexus 9000v, собранных в топологию Spine-Leaf. Останавливаться на настройке Underlay сети в рамках этой статьи мы не будем.

Если Вы не раз сталкивались с большими списками доступа или входящими в них object-группами, то наверняка уже задавались вопросом, существует ли инструмент, позволяющий определить, пропустит ли access-лист определённый пакет и какие строки сработают.

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

Безусловно, никто не запрещает использовать регулярные выражения для поиска определённых строк списка доступа прямо с консоли сетевого устройства. Но данный метод предоставит очень поверхностный результат. Например, он не отобразит доступ хоста, попадающего в сетевую маску или порт, попадающий под диапазон. Тем более, таким образом нельзя отобразить все существующие доступы между двумя заданными узлами или сетями. Опытный сетевой администратор осведомлён о безрезультативности метода простого парсинга access-листа для таких задач.

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

Я сфокусируюсь на том, что помимо стандарта предлагает ведущий вендор в области корпоративных беспроводных сетей, компания, в которой я тружусь уже почти 12 лет — Cisco. Именно то, что вне рамок стандарта, заслуживает пристального внимания, именно здесь проявляются интересные возможности.

Будущее Wi-Fi 6 уже сейчас видится многообещающим:

• Wi-Fi – самая популярная технология беспроводного доступа по количеству используемых устройств. Относительно недорогой чипсет позволяет встраивать его в миллионы недорогих устройств IoT, что способствует еще большему его распространению. На текущий момент уже десятки различных оконечных устройств поддерживают Wi-Fi 6.
• новость о развитии Wi-Fi 6 в диапазон 6 ГГц является воистину беспрецедентной. FCC выделяет дополнительные 1200 МГц для безлицензионного использования, что существенно расширит возможности Wi-Fi 6, а также последующих технологий, например уже обсуждаемому Wi-Fi 7. Возможности гарантировать производительность приложений, помноженная на доступность широкого спектра поистине открывает огромные перспективы. В каждой стране есть свое регулирование и в РФ пока никаких новостей по поводу освобождения 6 ГГц не слышно, однако будем надеяться, что глобальное движение не пройдет незамеченным и для нас.

Привет, Хабр! Эта статья написана по мотивам решения задания на недавно прошедшем онлайн-марафоне DevNet от Cisco. Участникам предлагалось автоматизировать анализ и визуализацию произвольной сетевой топологии и, опционально, происходящих в ней изменений.

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

Всем заинтересовавшимся добро пожаловать под кат!

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

Продолжая серию статьей по теме организации Remote-Access VPN доступа не могу не поделиться интересным опытом развертывания высокозащищенной конфигурации VPN. Задачу нетривиальную подкинул один заказчик (есть выдумщики в Русских селениях), но Challenge Accepted и творчески реализован. В результате получился интересный концепт со следующими характеристиками:

1. Несколько факторов защиты от подмены оконечного устройства (с жесткой привязкой к пользователю);
   
   • Оценка соответствия ПК пользователя назначенному UDID разрешенного ПК в базе аутентификации;
   • С MFA, использующей UDID ПК из сертификата для вторичной аутентификации через Cisco DUO (Можно прикрутить любую SAML/Radius совместимую);
2. Многофакторной аутентификацией:
   
   • Сертификат пользователя с проверкой полей и вторичной аутентификации по одному из них;
   • Логин (неизменяемый, взятый из сертификата) и пароль;
3. Оценкой состояния, подключающегося хоста (Posture)

Используемые компоненты решения:

• Cisco ASA (Шлюз VPN);
• Cisco ISE (Аутентификация / Авторизация / Аккаунтинг, Оценка Состояния, CA);
• Cisco DUO (Многофакторная Аутентификация) (Можно прикрутить любую SAML/Radius совместимую);
• Cisco AnyConnect (Многоцелевой агент для рабочих станций и мобильных ОС);

Привет, Хабр!

Быть облачным провайдером — значит постоянно аккумулировать новые знания и экспертизу. За годы работы мы сформировали достаточно большое количество практик, которых стараемся придерживаться для обеспечения наилучшего уровня сервиса. Одна из них — использование решений комплекса Cisco Unified Computing System. Под катом я хочу рассказать, почему, на наш взгляд, UCS является одним из лучших решений для провайдеров, и обсудить некоторые особенности работы и кейсы использования системы.

Добрый день, друзья!

Компания Cisco совместно с Linxdatacenter приглашает вас принять участие в двухдневном техническом вебинаре по продукту Cisco HyperFlex.

Описание

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

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

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

Целевая аудитория

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

Даты вебинара: 21 – 22 апреля 2020 г.
Время вебинара: 10-00 — 13-15

Программа

Недавно я столкнулся с проблемой выбора среды для изучения некоторых фич маршрутизаторов Cisco. Раньше я пользовался GNS3, а сейчас решил посмотреть, что изменилось в мире. Как выяснилось, прогресс шагнул далеко вперёд. Погружаясь в пучину статей и форумов, я обнаружил что огромное количество информации из них уже устарело. Чтобы не запутаться в многообразии ПО, я сделал себе небольшую шпаргалку (актуальность — март 2020 г.). Теперь я хочу выложить её на суд общественности. Во-первых, чтобы не пропадала (мне кажется, кому-то это может пригодиться, так как в одном месте я упоминания всех средств разом так и не нашёл). Во-вторых, возможно, в комментариях мне укажут на ошибки в описаниях и это позволит улучшить обзор.

Многие компании переходят на использование облачных сервисов в своем бизнесе по всему миру, это и офисные приложения, сервисы BigData, чат/видео/аудио коммуникация с целью проведения митингов/обучения и многие другие. Однако ввиду массового перевода на удаленную работу сотрудников так или иначе требуется получать доступ к корпоративной сети (если конечно заказчик не полностью работает на облачной платформе), для того чтобы сделать доступ безопасным, как правило, используются сервисы типа Remote-Access VPN.
Классически такие сервисы могут либо полностью направлять весь трафик удаленного клиента в VPN туннель, либо выборочно направлять или исключать из туннеля трафик основываясь на IPv4/IPv6 подсетях.

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

• Как организовать файлообмен Box/Dropbox/SharePoint напрямую в облако со скоростью домашнего канала интернет, минуя медленный корпоративный VPN?
• Как организовать соединение Webex/Skype напрямую с абонентом, не проводя его через HQ VPN-шлюз, создавая задержки связи и снижая качество связи?
• Как заставить только определенные облачные сервисы работать вне VPN туннеля, чтобы пользователь их использовал напрямую через домашний интернет и контролировать остальные не доверенные службы централизованно?
• Как эффективно снизить нагрузку на VPN-шлюз не проводя через него трафик доверенных облачных приложений?

В данной статье я бы хотел привести пошаговую инструкцию того как можно быстро развернуть самую масштабируемую на текущий момент схему Remote-Access VPN доступа на базе AnyConnect и Cisco ASA – VPN Load Balancing Cluster.

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

День добрый. Это вторая часть цикла из двух статей. В первой части мы ловили Zabbix-ом трапы PortSecurity от коммутаторов, а здесь мы, можно сказать, решаем обратную задачу — снимаем блокировку порта коммутатора щелчком мыши в фронтенде Zabbix-а.

Так получилось, что эта задача решалась два раза, двумя разными инструментами и с разницей в несколько месяцев. Сначала использовался Ansible, который вполне успешно справлялся. Но в один прекрасный момент он сломался (опять) и та же самая задача была решена простым Python-ом с использованием широко известной в узких кругах сетевой библиотекой Napalm.