Русский
Русский
English
Статистика
Реклама

Сетевые технологии

Перевод Взлом Wi-Fi-сетей, защищённых WPA и WPA2

24.12.2020 16:21:15 | Автор: admin
Автор статьи, перевод которой мы сегодня публикуем, хочет рассказать о том, как взломать Wi-Fi-сеть, для защиты которой используются протоколы WPA и WPA2.


Статья написана исключительно в ознакомительных целях


Аппаратное и программное обеспечение


Я буду пользоваться дистрибутивом Kali Linux, установленным на VMware Workstation.

Кроме того, в моём распоряжении имеется Wi-Fi-адаптер Alfa AWUS036NH 2000mW 802.11b/g/n. Вот его основные характеристики:

  • Стандарты: IEEE 802.11b/g/n, USB 2.0.
  • Скорости передачи данных: 802.11b 11 Мбит/с, 802.11g 54 Мбит/с, 802.11n 150 Мбит/с.
  • Разъём для подключения антенны: 1 x RP-SMA.
  • Частотные диапазоны: 2412~2462 МГц, 2412~2472 МГц, 2412~2484 МГц.
  • Питание: 5В.
  • Безопасность: WEP 64/128, поддержка 802.1X, WPS, WPA-PSK, WPA2.

Шаг 1


Нужно запустить Kali Linux в VMware и подключить к системе Wi-Fi-адаптер Alfa AWUS036NH, выполнив следующую последовательность действий:

VM > Removable Devices > Ralink 802.11n USB Wireless Lan Card > Connect


Подключение Wi-Fi-адаптера к ОС, работающей в VMware

Шаг 2


Теперь обратите внимание на средства управления Wi-Fi-подключениями в Kali Linux.


Управление Wi-Fi-подключениями в Kali Linux

Шаг 3


Откройте терминал и выполните команду airmon-ng для вывода сведений об интерфейсах беспроводных сетей.


Вывод сведений об интерфейсах беспроводных сетей

Шаг 4


Как видно, интерфейсу назначено имя wlan0. Зная это, выполним в терминале команду airmon-ng start wlan0. Благодаря этой команде Wi-Fi-адаптер будет переведён в режим мониторинга.


Перевод адаптера в режим мониторинга

Шаг 5


Теперь выполните такую команду: airodump-ng wlan0mon. Это позволит получить сведения о Wi-Fi-сетях, развёрнутых поблизости, о том, какие методы шифрования в них используются, а так же о SSID.


Сведения о Wi-Fi-сетях

Шаг 6


Теперь воспользуемся такой командой:

airodump-ng -c [channel] bssid [bssid] -w /root/Desktop/ [monitor interface]

В ней [channel] надо заменить на номер целевого канала, [bssid] на целевой BSSID, [monitor interface] на интерфейс мониторинга wlan0mon.

В результате моя команда будет выглядеть так:

airodump-ng -c 6 bssid 4C:ED:FB:8A:4F:C0 -w /root/Desktop/ wlan0mon


Выполнение команды

Шаг 7


Теперь нужно подождать. Утилита airodump будет мониторить сеть, ожидая момента, когда кто-нибудь к ней подключится. Это даст нам возможность получить handshake-файлы, которые будут сохранены в папке /root/Desktop.

Вот как выглядит работа утилиты до того момента, как кто-то подключился к исследуемой сети.


Программа наблюдает за сетью

А вот что происходит после того, как то-то к сети подключился, и программе удалось получить нужные данные.


Получение необходимых данных

Шаг 8


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

Речь идёт об использовании следующей команды:

aireplay-ng -0 2 -a [router bssid] -c [client bssid] wlan0mon

Здесь [router bssid] нужно заменить на BSSID Wi-Fi-сети, а [client bssid] на идентификатор рабочей станции.

Эта команда позволяет получить handshake-данные в том случае, если вам не хочется ждать момента чьего-либо подключения к сети. Фактически, эта команда атакует маршрутизатор, выполняя внедрение пакетов. Параметр -0 2 можно заменить другим числом, например, указать тут число 50, или большее число, и дождаться получения handshake-данных


Использование утилиты aireplay-bg

Шаг 9


Теперь воспользуемся такой командой:

aircrack-ng -a2 -b [router bssid] -w [path to wordlist] /root/Desktop/*.cap

  • -a2 означает WPA.
  • -b это BSSID сети.
  • -w это путь к списку паролей.
  • *.cap это шаблон имён файлов, содержащих пароли.

В моём случае эта команда выглядит так:

aircrack-ng -a2 -b 4C:ED:FB:8A:4F:C0 -w /root/Desktop/ww.txt /root/Desktop/*.cap

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


Успешный взлом пароля

Как вы контролируете безопасность своих беспроводных сетей?



Подробнее..

Новый портал для автоматизации от Check Point

23.12.2020 04:14:35 | Автор: admin

Приветствую читателей блога TS Solution, в последний месяц уходящего года продолжаем рассказывать вам о новостях в мире Check Point. Сегодня речь пойдет о новом едином портале - СheckMates Toolbox, он содержит в себе многочисленные инструменты по автоматизации для ежедневной работы администраторов. Контент верифицируется самим вендором, это говорит о долгосрочной поддержке данного проекта.

Коротко о главном

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

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

Вернемся же к проекту СheckMates Toolbox, его цель предоставить конечному пользователю единое пространство для того чтобы делиться инструментами и решениями при работе с оборудование Check Point, на момент выхода статьи существуют разделы:

  • SmartEvent;

  • Compliance;

  • Scripts;

  • SmartConsole Extensions;

  • Cloud Deployment.

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

SmartEvent

Раздел содержит шаблоны для просмотра событий. Напомню, что блейд SmartEvent установленный на ваш Management Server или отдельный cервер, требует отдельной лицензии и коррелирует логи, далее создает отчеты по аналогии с SIEM-подобными системами.

Архитектура SmartEvent для любознательных

Correlation Unit (CU) В реальном времени считывает записи из текущего лог-файла сервера и анализирует их с помощью Correlation Policy, генерируя события безопасности, которые отправляет на Event Server.

Analyzer Server Загружает на Correlation Unit политики Event Policy, сохраняет полученные от Correlation Unit события безопасности в своей базе данных, взаимодействует с Security Management Server для организации блокировки источника угрозы на шлюзах безопасности Check Point. Подгружает с Security Management Server необходимые объекты. Предоставляет данные для генерации отчётов Reporting Server.

Analyzer Client Организует интерфейс взаимодействия и управления c Event Server, выводит информацию собранную на Event Server в различных представлениях.

Мы же используя СheckMates Toolbox, находясь в разделе SmartEvent, скачаем репорт - Unknown-Applications-Detection

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

Compliance

Раздел содержит лучшие мировые практики в области ИБ, которые вы можете использовать на Check Point, благодаря блейду Compliance ( требуется соответствующая активная лицензия ).

На портале представлено большое количество стандартов, загрузить их на ваш Management Server возможно из: Manage & Settings Blades Compliance Settings

Scripts

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

В рамках статьи мы расскажем о нескольких интересных проектах, ознакомиться с другими вы всегда можете самостоятельно.

CPme

CCЛКА!

1) Соответственно, для загрузки требуется:

curl_cli https://raw.githubusercontent.com/0x7c2/cpme/main/cpme-install.sh -k | bash

2) запуск самой утилиты:

[Expert@CPGWSMS:0]# cpme

3) В меню возможен выбор:

4) пройдемся по разделам - Gaia Operating System (1)

Легко можно проверить доступность сервисов Check Point (3) и прочее:

5) Большое количество проверок самой системы - Health Analysis (2):

6) Полезны также будут Troubleshooting Options (7):

7) Отдельно отметим возможность собрать HTML-отчет (10), который вы можете просмотреть:

Remote Access VPN Statistics - OneLiner

ССЛКА!

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

Его также можно выполнять как Task ( отправляя из SmartConsole ).

Show AntiSpoofing Networks via CLI

ССЛКА!

Bash-скрипт, который собирает статистику работы Anti-Spoofing с ваших активных интерфейсов шлюза (Security Gateway). Для тех кто забыл или не знаком с технологией, она позволяет предотвратить подмену адресации со стороны источника или назначения, за счет того, что шлюз Check Point имеет информацию о типе трафика (внутренний, внешний и т.д.).

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

SmartConsole Extensions

В данном разделе содержатся шаблоны для Extensions. Это позволяет оперативно получать различную системную информацию от вашего Security Gateway или Management Server в самой SmartConsole.

Чтобы активировать опцию необходимо перейти: Manage & Settings Preferences SmartConsole Extensions

Где загрузим соответствующий URL: https://dannyjung.de/ds.json

Он взят из примера:

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

Cloud Deployment

Раздел для автоматизации развертывания продуктов Check Point в облачных провайдерах. На момент выхода статьи он только появился и содержал лишь 1 решение.

Предложенный bash-скрипт позволит развернуть Cloud Guard в облаке Google в полуавтоматическом режиме.

Вместо заключения

Сегодня мы познакомились с новым порталом, который удобно систематизирует полезные инструменты от сообщества, существует проверка со стороны Check Point. Если вам необходимы дополнительные материалы по продуктами вендора, то можете обратиться к статье с обучающими ресурсами. Мы же будем продолжать знакомить Вас с новостями из мира Check Point и другими продуктами, оставайтесь с нами, до скорого!

Следите за обновлениями в наших каналах (Telegram,Facebook,VK,TS Solution Blog)!

Подробнее..

PIVOT3- УМНЕ ИНФРАСТРУКТУРНЕ РЕШЕНИЯ

24.12.2020 18:19:54 | Автор: admin

Всем привет! Данная статья 2 по счету в блоге от команды ОЛЛИ ИТ на Хабре. Я искренне рада данной возможности, и надеюсь, что материалы нашего блога будут для вас полезны.

Для тех, кто никогда об этом не слышал

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

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

Гиперконвергенцияберет свое начало в концепции конвергентной инфраструктуры.

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

На сегодняшний день наиболее распространенными системамигиперконвергенцииявляютсяNutanix,CiscoHyperflex,Vmware vSAN,Dell VxRAIL (комплекс сервера + ПО Vmware vSAN),HuaweiFusionCube,StarWindVirtual SAN и другое.Все они среди прочего доступны в России.

Но мало кто знает оPivot3!

Компания Pivot3 была основана несколькими ветеранами IT индустрии из компаний Compaq, VMware и Adaptec, движимыми идеей упрощения ЦОДов благодаря объединению ресурсов хранения, обработки и передачи данных в едином, мощном, легко встраиваемом решении, которое бы сокращало расходы, операционные риски, и упрощало управление в целом.Pivot3создаетгиперконвергентныерешения для критически важных инфраструктур в безопасных и интеллектуальных средах, таких как: университетские городки, города, аэропорты,call-центры, компании с большим штатом разработчиков,транспортные и федеральные объектыи т.д.

РешенияPivot3, разработанные специально для рабочих нагрузок на основе видео, таких как:видеонаблюдение, аналитика, визуализация и VDI, снижают совокупную стоимость владения, снижают риски иответственность, упрощаютуправление за счет автоматизации.Pivot3-этоединственная инфраструктураHCI,созданнаядля быстрой и удобной работы с большими объемами видеоданных.Ключевая и важная инновация-управление производительностью на основе политик, всестороннее использованиеNVMeи эффективное хранение.

ГиперконвергентныерешенияPivot3

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

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

Ниже представленыпримерыпреимуществгиперконвергентнойинфраструктуры* (HCI).

Гиперконвергентнаяинфраструктура (HCI)*

  • Комбинация вычислительных ресурсов и ресурсов хранения;

  • Стандартная платформаx86;

  • Модульность;

  • На базегипервизораотVMware;

  • Большая гибкость;

  • Лучшая эффективность использования;

  • Подходит для VDI инфраструктуры;

  • Высокие показатели компрессии идедупликацииданных.

Почемустоит обратить внимание наPivot3?

  • Длязадачи, где обычно требуется 4узла,Pivot3необходимо всего3;

  • Производительность базы данныхзначительно увеличилась(БД Микс пакеты 8k, комбинация запись/чтение, 100% случайное, глубина очереди 128, средние IOPS и задержка);

  • Отклик приложений;

  • Большее количество транзакций(больше 10);

  • Большая плотность данных на один узел;

  • Pivot3можетобеспечитьболеевыгоднуюэкономическуюценность, по сравнению сдругимипроизводителями, например-Nutanix.

    Pivot3: Направленность на производительность

    Прорыв в производительности дляHCI:

    HCIAcceleratorNodes

  • NVMePCIeflashинтегрирован в многоуровневую архитектуру хранения;

  • Постоянный уровень хранения,R&Wкэш;

  • Управление расширенным QoS для повышения эффективности иприоритезации.

Многоуровневое хранение

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

Сравним показатели!

В качестве примерасравним общие данные эффективности оборудования на примереPivot3.

1) Многоуровневое хранение

Одноуровневая архитектуруHCI

  • Устаревшая архитектура SAS/SATA является ограничивающим фактором для производительности;

  • Сложности с консолидацией разных типов задач.

    А теперь сравним ее смногоуровневойархитектуройPivot3:

  • NVMeобеспечивает оперативный отклик;

  • QoSавтоматически подбирает оптимальный уровень размещения данных для соответствияSLA;

  • Результат эффективная консолидация разных типов задач.

Помимо многоуровневой архитектуры,Pivot3обладаетболее эффективнойутилизациейресурсов:

Часть ресурсов берётся уVMs:

  • Более высокие накладные расходыHCIOS;

  • Доступ к хранилищу черезгипервизор.

Более эффективно, большеVMs:

  • Меньше накладных расходовHCI OS;

  • Обходгипервизораозначает повышенную производительность хранилища.

Распределённая производительность

Традиционная архитектураHCI

  • Объём хранения,IOPSи ширина канала ограничены;

  • ВозможностиVMограничены производительностью конкретного узла.

Распределённая архитектураPivot3

  • Объём хранения,IOPSи ширина канала агрегируются;

  • VMдоступны все имеющиеся ресурсы.

    Pivot3 + Citrix

    Помимо всего перечисленного важно отметить, чтоCitrixиPivot3 объявили об укреплении сотрудничества для поддержки Citrix Virtual Desktops на платформе интеллектуальнойгиперконвергентнойинфраструктуры (HCI)Pivot3, что довольно актуально на сегодняшний день в связи с переходом сотрудников на удаленную работу.

Сеть технологических партнёров, с которыми сотрудничаетPIVOT3

Решения для ЦОДов Решения для ЦОДов Решения для видеонаблюдения Решения для видеонаблюдения

Продуктовые линейкиотPivot3

Вычислительные HCI решения в ЦОДВычислительные HCI решения в ЦОД
  • Оптимизация для работы вЦОДах;

  • Консолидация множественных задач с разнообразными требованиями к ресурсам;

  • Архитектура для полнофункционального использованияNVMe;

  • Автоматизированное управление на основе политик;

  • Широкий функционал по управлению данными корпоративного класса.

HCI решения для видеонаблюденияHCI решения для видеонаблюдения
  • Оптимизация для видеонаблюдения;

  • Архитектура для сохранения целостности видеоконтента и предотвращения простоев системы и потерь данных;

  • Масштабирование вычислительной мощности, ресурсов хранения или канала линейно и/или независимо;

  • Доставка видеоконтента на любые устройства;

  • Сертификация у основных производителей ПО для управлениявидеоконтентом.

    ***

    В заключениеможно сказать, что современные решения HCI от компанииPivot3сочетают в себе высокопроизводительныефлеш-каналыпередачи данных NVMe PCIe, механизмы обеспечения качества обслуживания на основе политик (QoS), распределенные ресурсы производительности и мобильность гибридных облачных систем для достижения максимальных рабочих показателей, гибкости имасштабируемости.

Подробнее..

4. Фишинг в 2020. Пример атаки и обзор решений в мире

25.12.2020 10:05:30 | Автор: admin

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

  1. Обучение пользователей основам ИБ. Борьба с фишингом.

  2. Обучение пользователей основам ИБ. Phishman.

  3. Обучение и тренировка навыков по ИБ. Антифишинг.

Сводка с полей

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

Например, вендор Check Point в одном из своих отчетов сообщает, что только в ноябре 2020 года - количество фишинговых кампаний увеличилось более чем в 2.5 раза по сравнению с октябрем 2020 года.

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

Разбор атаки

Тема письма: Cyber Monday | Only 24 Hours Left!

Отправитель: Pandora Jewellery (no-reply\@amazon.com)

Содержимое:

На первый взгляд, мы получили легитимную рассылку, приглашающую нас осуществить покупки украшений на сайте Pandora. Но замечаем несоответствие:

  • Рассылка с домена Amazon является подменой с применением механизма spoofing.

  • Ошибка в слове Jewellery в теме письма. (прим. корректное написание - jewelry).

  • Если попытаться перейти на сайт по ссылке в письме, то открывается URL: www[.]wellpand[.]com. Сам сайт был зарегистрирован как раз осенью 2020 года и имитирует содержимое оригинального сайта компании Pandora.

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

  1. Бесплатный сыр бывает только в мышеловке. При покупке того или иного товара нужно объективно оценивать его стоимость, например, если вам предлагают новый Iphone со скидкой 80%, скорее всего, это обман.

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

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

  4. Социальная инженерия важна. Обращайте внимание на стиль написания полученного письма (синтаксические и орфографические ошибки и прочее).

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

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

Обзор решений

Ранее мы познакомили вас с некоторыми продуктами из категории Security Awareness Computer-Based Training, в том числе с Open-source решением GoPhish и отечественными продуктами: Phishman, Антифишинг. Пришло время обратиться ко всем известному Gartner и кратко ознакомиться с топ-5 (в рамках статьи был выбран регион Europe, Middle East And Africa, от 1 к 5).

KnowBe4

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

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

Запуск одного из тестов

1) Выбор теста

2) Конфигурация обучающей кампании фишинга

3) Выбор шаблона для рассылки

5) Настройка страницы для переадресации "жертв"

6) Панель мониторинга и сбора статистики

Общее впечатление:

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

Kaspersky-Cybersecurity Awareness Training

Платный продукт от широко известной для российской публики компании - Лаборатория Касперского.

Его отличие от других решений в том, что обучение подготовлено для самих IT-специалистов в рамках которого рассматривается :

  • Цифровая криминалистика. Формирование и улучшение практических навыков поиска цифровых улик киберпреступлений и анализа различных типов данных для восстановления хронологии атак и определения их источников.

  • Анализ вредоносного ПО. Подготовка специалистов по IT-безопасности анализировать вредоносное ПО, находить индикаторы компрометации (IoC), создавать сигнатуры для обнаружения вредоносного ПО на зараженных компьютерах и восстанавливать зараженные и зашифрованные файлы.

  • Реагирование на инциденты.

  • Эффективное обнаружение угроз с помощью YARA (подготовленные правила и сопоставление фактов с целью выявления событий безопасности).

Общее впечатление:

Данный сервис как платформа позволит вашим сотрудникам обучаться противостоять наиболее актуальным и современным типам атак. Решение требует определенного уровня подготовки и наличия навыков в IT, в том числе ИБ. Активно используется большими компаниями (банки, промышленность и т.д.).

OutThink Human Risk Management Platform (SaaS)

Платный продукт позиционирует себя как результат долгих исследований в Security Group (ISG), Royal Holloway, University of London. Эксперты компании суммарно имеют опыт более 100 лет в ИБ, науке о поведении человека, психологии и Data Science.

Общее впечатление:

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

Infosec IQ

Платное решение от Европейской компании LX Labs, который предлагают более 700 ресурсов для обучения персонала, более 1000 шаблонов для симуляции фишинг-сообщений и удобный интерфейс для взаимодействия.

Общее впечатление:

Прост, масштабируем и эффективен - так один из заказчиков отзывается о продукте на сайте Gartner. Если говорить о технической стороне вопроса, то отмечается удобная интеграция с AD (Active Directory), простой запуск фишинговых кампаний, поддержка быстрого перехода к статистике через кнопку управления в Outlook. Если вас заинтересовало решение, то вы можете запросить демо у вендора по ссылке.

Keepnet Labs

Одноименный вендор предлагает различные решения в области ИБ:

  • Incident Responder. Позволяет пользователям отправлять на проверку подозрительные email-сообщения, после чего они могут блокироваться на постоянной основе.

  • Email threat simulator. Решение позволяет периодически проверять вашу инфраструктуру (файрволл, антиспам, антивирус и т.д.) на уязвимости в настройках, благодаря которым могут пройти атаки в рамках фишинга.

  • Threat Intelligence. Умный движок постоянно изучает сайты на предмет их взлома или утечки информации с целью выявить компрометацию ваших персональных корпоративных данных.

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

  • Awareness Educator. Обучающий портал, который может быть интегрирован в Phishing Simulator.

  • Threat Sharing. В рамках этого решения есть возможность установить доверительные отношения и передавать данные между компаниями согласно определенным правилам и обеспечивая их безопасную доставку.

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

Общее впечатление:

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

Вместо заключения

Сегодня мы рассмотрели один классический праздничный пример фишинг атаки и кратко познакомились с мировыми лидерами в области Security Awareness Computer-Based Training, под постом будет запущено голосование о приглянувшемся для вас продукте, возможно сделаем на него полноценный обзор. Почитать и протестировать решения (GoPhish, Phishman и Антифишинг) вы можете обратившись к нам на почту.

Подробнее..

Активное внедрение стандарта Интернета RPKI полезно ли?

26.12.2020 10:13:54 | Автор: admin

Сейчас почитал, поразмыслил и начал понимать, что, возможно, я рано сегодня порадовался отличной статистике внедрения RPKI в массы в этом году.

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

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

Суть здесь вот в чём. Внедряемый стандарт подписей рассылок интернет-адресов основывается на иерархической системе сертификатов. То есть это почти та же система, только с дополнениями в виде номеров сетей и анонсов ip-адресов. Данный стандарт предполагает, что ведущие держатели мировых сетевых мощностей будут доверять только анонсам сетевых маршрутов от их непосредственных исполнителей, т.е. тех, кто эти маршруты будет собственно осуществлять, либо их непосредственных начальников. Неформально если - теперь сложно будет ходить "налево".

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

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

Связность в европе и окрестностяхСвязность в европе и окрестностях

Также в группу голов можно смело заносить крупных поставщиков контента, типа Netflix, Amazon, Vkontakte и Google. А также их крупнейших посредников - точки обмена трафиком, или пиринг-центры, представляющие из себя ассоциации разных интернет- и контент-провайдеров разного уровня. Именно во многом благодаря их существованию Интернет более-менее распределён, а значит устойчив к сбоям и, что немаловажно, к монополиям.

Во многом за счёт последних скорости интернета выше, а цены ниже. Именно они вносят значительный вклад в представление Сети как графовой распределённой структуры, у которой нет основных 3-4 владельцев, в основном американских (хотя надо отдать должное, скандинавская Telia Sonera на первом месте сейчас). Так вот, внедряемый стандарт основан на иерархии подписей маршрутов, аналогично иерархии подписей сертификатов сайтов.

Основа протоколаОснова протокола

И выдача маршрутов (как мне сейчас представляется) соотносится с современным положением вещей примерно так же как сама нынешняя система сертификатов PKI соотносится с распределёнными системами типа блокчейна. Ну или другая аналогия, политическая - как однополярный мир соотносится с многополярным. Программистская аналогия - как централизованный и распределённый контроли версий ПО. Финансовая: как Бреттон-Вудская, ныне Ямайская, система (золотодолларовый стандарт) соотносится с золотым стандартом начала 20-го века.

Вернёмся к Интернету.

Дерево связей протокола RPKIДерево связей протокола RPKI

По принятому протоколу доверие маршрутам обеспечивается только согласно иерархическим лицензиям, выданным от основных их владельцев - крупнейших телекомов бэкбона Интернета. То бишь из тех "голов", что я перечислял, влияние перетекает только к первой немногочисленной группе "владельцев" интернета. А различные региональные игроки остаются в стороне. Существующие ассоциации (пиринговые центры) наподобие российских MSK-IX или DATAIX, пока что довольно влиятельные, потеряют возможность обмениваться трафиком, так как их участники не смогут обмениваться маршрутами, нарушая границы своих иерархий, то есть обмен налево будет затруднён. А это и был основной смысл существования этих точек обмена. В результате контроль над трафиком уйдёт к крупнейшим телекомам. Российские телекомы не глобальны и впадут в зависимость от западных. Точки обмена трафиком просто распадутся. Установится монополия (или если хотите олигополия) в сфере коммуникаций, маршруты будут прокидываться через головы, они станут длиннее, а значит связь будет во многих случаях медленнее. Ну и конечно вырастут цены. За большую цену вы получите худшую связь.

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


Я надеюсь, что на Хабре найдутся специалисты, которые могут развеять мои сомнения и опасения. Или объяснят, что, например преимуществ у новой технологии больше чем недостатков (если они есть).

Удачного всем дня!

Подробнее..

Самый беззащитный уже не Сапсан. Всё оказалось куда хуже

13.01.2021 10:12:44 | Автор: admin
Больше года назад хабравчанин keklick1337 опубликовал свой единственный пост Самый беззащитный это Сапсан в котором рассказывает как он без серьёзных ухищрений получил доступ ко внутренней сети РЖД через WiFi Сапсана.

В ОАО РЖДпрокомментировали результатыэтого расследования. Есть результаты проверки. Почему удалось взломать? Наверное, потому, что злоумышленник. Наверное, из-за этого Ну, он из фана. Юный натуралист. Там уязвимостей, которые бы влияли на утечку каких-то критических данных, нет. Мультимедийный портал Сапсанов функционирует как положено и не нуждается в доработке, заявил Евгений Чаркин.

То есть вместо того, чтобы выразить благодарность за обнаруженную уязвимость, автора обозвали злоумышленником и Юным натуралистом.

К сожалению, но специалисты РЖД, начиная с директора по информационным технологиям, отнеслись к статье очень пренебрежительно, проигнорировав важное указание автора:
Также оттуда в сеть РЖД есть впн. Если захотите найдёте её там сами.

И вот, год спустя я попал в сеть РЖД даже не садясь в Сапсан.


Видимо, только этот котэ добросовестно охраняет вокзал.

Как именно я попал в сеть РЖД с пруфами, чего не сделал директор по информационным технологиям ОАО РЖД Чаркин Евгений Игоревич и возможные последствия под катом.

Всё началось с гипотезы


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

Таким образом меня посетила идея проверить гипотезу: Есть ли жизнь за прокси?

Я запустил nmap по диапазону адресов по порту 8080. Далее из полученного результата прошёлся прокси-чеккером в поисках публичного прокси без авторизации и из положительных результатов выбрал самый близкий ко мне по пингу.

Запустил сканер через него по адресам 172.16.0.0/12 порт 8291 (mikrotik winbox). И! Я его нашёл! Без пароля!



То есть за роутером с прокси есть ещё один Mikrotik без пароля. Гипотеза подтверждена: за прокси могут быть целые незащищённые сети.

Только на тот момент я недооценивал масштаб незащищённости, который я случайно нашёл.

В поисках Немо владельца системы


Так как я придерживаюсь принципов Grey hat (Обо мне mysterious Russian-speaking grey-hat hacker Alexey и статья на Хабре) и съел собаку на безопасности Mikrotik, то я принялся искать владельца системы, чтобы связаться с ним.

Кстати, заходите в Телеграм чат RouterOS Security t.me/router_os

Недолго думая я поднял исходящий VPN до себя. Всё же комфортней через нормальный туннель дальше изучать сеть и искать признаки владельца системы. HTTP connect ещё тот геморрой

За интерфейсами ether1 и bridge ничего интересного не обнаружил. Найденные камеры были абсолютно не информативными.



А вот сканирование vpn, отмеченные красным на скрине выше, выдало более 20 000 устройств
Причём более 1000 штук микротики. Огромное количество устройств с заводскими паролями.

Вот некоторые из найденных сервисов с паролями по умолчанию:

1. Камеры наружного наблюдения подавляющее большинство.



Ещё камеры






Даже офисы внутри



Камер, по скромным ощущениям, не менее 10 000 штук. Производители разные: beward, axis, panasonic и т.д.

2. Ip-телефоны и FreePBX сервера также большое количество.




3. IPMI серверов:

Asus

Dell (их подавляющее большинство)


Supermicro

Из серверов виртуализации встречаются ESXi, Proxmox и oVirt



Много узлов кластера Proxmox (по поднятым сервисам и трафиком между ними.)

4. Преобразователи ethernet во 'что угодно' (Moxa UniPing etc)


5. Системы управления ИБП



6. Внутренние сервисы





Что-то похожее на мониторинг состояния систем обеспечения здания.


Система управления кондиционированием и вентиляцией


Различные системы управления табло на перронах :-)

Эта самая красивая


Некий терминал, но внутри модифицированный дебиан.

Таких нашёл около 20


Кстати, аптайм у него почти год:




6. Сетевое оборудование



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

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

Не полный кусок лога по прокси.



Такое ощущение, что интегратор, который строил сеть, специально оставил этот доступ.

И все же кто же хозяин?


Думаю, что уже все и так догадались.

Это я пробежался по верхушкам в рандомном порядке. Потратил я на это чуть больше 20 минут, чем автор статьи про Сапсан.

Это здец. Сеть просто в решето.

Причём это устройства по всей РФ.

Например, вот это вокзал Уфы

Антропово Костромской области


Развёрнута профессиональная система видеонаблюдения.

Нашёл презентацию по вокзалам.

macroscop


Находил Кемерово, Новосибирск, Омск и т.д. По внешнему виду вокзалы сложно определить. К тому же я поездом уже лет 5 не ездил.

Как же так получилось?


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



То есть это один из шлюзов в мир из сети РЖД. Ну и в сеть РЖД тоже

Получилась вот такая картина:

  1. Вероятно, что это один из офисов РЖД, который прилинкован к основой сети через l2tp.
  2. Я попадаю в сеть где межсетевые экраны отсутствуют как класс.
  3. Запускаю интенсивное сканирование хостов у меня соединение не рвётся. Значит о системах обнаружения вторжения (IDS/IPS) РЖД тоже ничего не слышал. Микротик может замечательно интегрироваться, например Suricata
  4. Обнаружил кучу устройств без защиты. Это говорит, что службы сетевой безопасности в РЖД так же нет.
  5. Много устройств с дефолтными паролями. То есть политики паролей тоже нет.
  6. С Микротиков внутри сети я легко поднял туннели. То есть исходящий трафик не контролируется.
  7. Я вижу все интерфейсы управления в одной сети с клиентскими сервисами. Админы РЖД ничего не знают о Management VLAN

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

Так дайте ответ, Евгений Игоревич, какой Юный натуралист проводил расследование и не заметил гнездо со слонами?



У меня лично есть всего три варианта ответа на этот вопрос:

1. У Вас исходно плохая команда.

Проверку проводил тот же отдел, который и проектировал/обслуживает систему. Отрицая проблему, они или сохраняют свою работу, или преследуют иные цели.



2. Вы доверились не тому специалисту. Аудит проводил некомпетентный сотрудник.



3. Вы и так знаете о проблеме, но по каким-то неведомым причинам не можете ее публично признать и решить.



Стоимость уязвимости


Что есть защищенная система? Защищенная система это та система, взлом которой стоит дороже, чем ценность информации, которая там есть. Вот и все, подытожил директор по информационным технологиям ОАО РЖД.

Предлагаю применить Вашу систему оценки в теории на примере системы видеонаблюдения РЖД.

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

Рандомно выбранная из списка установленных модель стоит ~13к рублей.



А закупки по 44-ФЗ отличаются, как непредсказуемой конечной стоимостью, так и временем проведения самой процедуры и получения продукта. Я потратил 8 часов для сбора информации для этой статьи. Найдено ~10к камер. Производителей камер, которые установлены, немного максимум штук 10.

Гипотетическому злоумышленнику потребуется:

  1. Модифицировать прошивки, заблокировав сетевой порт на 10 прошивках. Думаю, что на это у специалиста уйдёт три рабочих дня;
  2. ННаписать сканер, который будет анализировать устройство и заливать соответствующую прошивку. Заложим ещё 2 дня;
  3. Запустить этот сканер-прошивальщик, чтобы не смогли найти источник и заблокировать часа два.

Таким образом за неделю работы специалиста по взлому РЖД потеряет минимум 130 миллионов рублей. Отсюда стоимость одного часа работы злоумышленника будет равна ~2,5 млн. рублей.

Двигаемся дальше.

Быстро заменить камеры на работающие РЖД не сможет. В резерве столько нет. Купить новые из-за обязанности объявления торгов так же не получится. Таким образом вся железная дорога будет без видеонаблюдения не меньше месяца.

А вот это уже опасность террористической угрозы. Чтобы её хоть как-то снизить потребуется на 10 тысячах объектов существенно усилить охрану. То есть даже на маленькую ж.д. станцию потребуется дополнительно 6 человек охраны

Кажется счёт уже уходит за миллиарды

Что нужно изменить, чтобы снизить вероятность возможных последствий?


Далее чисто мой взгляд на решение данной ситуации. Он ничего общего не имеет с мировыми best practices.

Так же, сразу оговорюсь, что проблема касается только обнаруженной мною сети видеонаблюдения. В других сегментах сети РЖД, очень надеюсь, всё намного лучше.

1. Нанять сетевых аудиторов, которые помогут найти и закрыть самые зияющие дыры.

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

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

2.2. разработать новую полноценную инфраструктуру, отвечающую всем требованиям безопасности и план поэтапной миграции.

3. Нанять подрядчика, который будет реализовывать в жизни данные проекты и передавать на эксплуатацию сетевикам РЖД.

4. После сдачи проектов провести аудит безопасности инфраструктуры.

5. По окончанию пентестов своими силами объявить Bug Bounty

Чтобы мотивировать аудиторов и внутренних специалистов работать качественно, надо объявить лимит на количество и серьёзность уязвимостей, которые могу найти участники программы Bug Bounty. Если внешние специалисты найдут багов меньше лимита, то свои аудиторы получают премии. Если багов будет больше лимита, то штрафовать.

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

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

Заключение


Я не единственный кто нашёл данные уязвимости. Очень много признаков, что в этой сети кто-то живёт.

Например, вот эти линки я уже встречал не раз на роутерах, никак не относящихся к РЖД.



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

В случае с Сапасаном, чтобы через полученный VPN доступ можно было увидеть только один сервис с которым взаимодействует пользователь системы, а не всю сеть РЖД

Я старался достаточно жирно намекнуть на узкие места не раскрывая деталей и надеюсь, что специалисты РЖД их всё же увидят.

Связаться со мной можно через телеграм t.me/monoceros
Обсудить данную статью приглашаю в профильный чат по Микротикам в Телеграм RouterOS Security: t.me/router_os

Кстати, Евгений Игоревич, с повышением!



Источник

Подробнее..

Перевод 7 основных ошибок безопасности при переходе на облачные приложения

18.01.2021 16:06:50 | Автор: admin
image

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

Вступление


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

Есть хорошие и плохие способы осуществить эту миграцию в облако. Многие подводные камни не новы. Например, на одной встрече Gartner 2019 два ИТ-менеджера заявили, что их развертывание Office 365 было приостановлено из-за необходимости обновления устаревшего оборудования. Теперь то, как мы используем и совместно используем наши домашние компьютеры, изменилось. Наши компьютеры больше не личные. Этот же компьютер может поддерживать виртуальную школу вашего ребенка и приложения вашего супруга.

Летний опрос CyberArk показал, что более половины респондентов сохраняют свои пароли в браузерах корпоративных ПК. Конечно, это не обещает ничего хорошего ни для какой политики безопасности.

Вот семь основных ошибок, которые негативно влияют на безопасность, и несколько советов, как их избежать.

1. Использование VPN для удаленного доступа


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

Гораздо лучше заменить VPN сетями с нулевым доверием, где идентичность является плоскостью управления и обеспечивает контекст доступа.

2. Создание неправильного облачного портфеля


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

Доступны ли версии для запуска определенных приложений, зависящих от определенных конфигураций Windows и Linux? Есть ли у вас подходящие соединители и средства защиты аутентификации для работы с локальными приложениями и оборудованием, которое вы не переносите? Если у вас есть устаревшее приложение для мэйнфреймов?

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

3. Ваша политика безопасности не подходит для облака


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

Johnson & Johnson сделали это несколько лет назад, когда перенесли большую часть своих рабочих нагрузок в облако и централизовали свою модель безопасности. Есть помощь: Netflix только что выпустил инструмент с открытым исходным кодом, который они называют ConsoleMe. Он может управлять несколькими учетными записями Amazon Web Services (AWS) в одном сеансе браузера.

4. Не тестировать планы аварийного восстановления


Когда вы в последний раз тестировали свой план аварийного восстановления (DR)? Возможно, это было слишком давно, особенно если вы были заняты повседневными проблемами, связанными с поддержкой домашних работников.

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

Еще одна важная часть любого плана аварийного восстановления это непрерывное тестирование на предмет частичных сбоев облака. Скорее всего, у вас будут перебои в работе. Даже Amazon, Google и облака Microsoft испытывают это время от времени. Netflix был одним из первых мест, где несколько лет назад стала популярной общая инженерия хаоса с помощью инструмента под названием Chaos Monkey. Он был разработан для тестирования инфраструктуры AWS компании путем постоянного и случайного отключения различных рабочих серверов.

Используйте эти уроки и инструменты, чтобы разработать собственное тестирование отказов, особенно тесты, связанные с безопасностью, которые выявляют слабые места в вашей облачной конфигурации. Ключевой элемент делать это автоматически и постоянно, чтобы выявлять узкие места и недостатки инфраструктуры. Помимо использования инструментов с открытым исходным кодом от Netflix, есть коммерческие продукты, такие как Verodin / Mandiant's Security Validation, SafeBreachs Breach and Attack Simulation, инструменты моделирования Cymulate и AttackIQ's Security Optimization Platform.

5. Не оптимизирована аутентификация для портфеля с преобладающим облачным сервисом


У вас может быть учетная запись и управление доступом, SIEM, CASB или одно инструмент входа в систему, который был приобретен в эпоху локальных сетей. Теперь не соответствует вашим потребностям в проверке подлинности, преимущественно облачном мире, и мире удаленного доступа.

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

6. Устаревший Active Directory


Идентичность это теперь новый периметр, и данные распространяются повсюду, заявили Дэвид Махди и Стив Райли из Gartner в своей презентации.

Вы должны предоставить людям правильный доступ к нужным ресурсам, в нужное время и по правильной причине.

Разумеется, здесь стоит многое исправить. Это означает, что ваша Active Directory (AD) может не отражать реальность как из списка текущих и авторизованных пользователей, так и из текущих и авторизованных приложений и серверов.

Переход в облако будет более плавным, если вы будете переносить наиболее точную информацию.

7. Отказ обратиться за помощью


Многие поставщики управляемых услуг безопасности (MSSP) специализируются на такого рода миграциях, и вы не должны стесняться обращаться к ним за помощью.

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

Безопасные города без зоопарка

29.12.2020 18:11:47 | Автор: admin
image

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

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

С чем едят АПК Безопасный город

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

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

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

Реализовать в ядре все протоколы, включая проприетарные, значит перманентно отодвигать сроки внедрения и неразумно раздувать бюджет проекта. А ведь это касается не только региональных и муниципальных систем видеонаблюдения, но и систем оповещения населения, и мониторинга транспорта, тревожных кнопок, экологического контроля, прогнозирования и так далее. Список колоссальный! Что можно сделать?



По существу

Обратимся к нормативным документам. Единые требования к техническим параметрам сегментов аппаратно-программного комплекса Безопасный город (28.06.2017) лаконично констатируют, что в ядре платформы Безопасный город должно быть 2 ключевые подсистемы: Региональная интеграционная платформа (РИП) и Единый центр оперативного управления (ЕЦОР). Просто, недешево и минимально функционально. Только анализ данных и управление, остальное интеграции.

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

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

Внедрение АПК Безопасный город постепенно набирает обороты, однако, есть проблемы. Это и затягивание сроков сдачи, и искажение, увеличение, раздувание в процессе задач по контрактам и банальный недостаток финансирования. С чем связанны эти особенности реализации? Как мы можем влиять на внедрение?

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

Добавим ингредиентов

Вспомним, что сейчас для закладки Безопасного города нужно только 2 ключевые подсистемы: РИП для создания единого информационного пространства и ЕЦОР для управления потоками данных и управления ситуацией. Наш опыт разработки и внедрение АПК Безопасный город говорит о том, что этого крайне мало и в ядро системы необходимо добавить несколько критически важных подсистем. Без этих ингредиентов кашу Безопасных городов нормально не заваришь. Критически-важную инфраструктуру надо создавать по новому рецепту.

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

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



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

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

Была проведена работа по обеспечению взаимодействия с системами видеоаналитики различных вендоров, включая систему распознавание номеров (ГРЗ), которая работает на обычных камерах видеонаблюдения. Далее ее сработки передаются в АИС регионального подразделения МВД. В целом в систему были заведены потоки всего спектра имеющихся в регионе устройств: от аналоговых камер до рубежей системы фотовидеофиксации. Апогеем данного проекта является интеграция видеопортала и РИП АПК БГ. Это позволило передавать информацию о всех камерах региона, транслировать онлайн-видео, архив, а также передавать события по срабатыванию видеоаналитики в единый центр.

Во-вторых, важным элементом в приготовлении безопасных городов является подсистема мониторинга стационарных и подвижных объектов. Надо и пробки видеть, и доступные транспортные средства, и датчики мониторинга на неподвижных объектах, и про экологию не забывать. Только по камерам оценить резервы и спрогнозировать ситуацию не получится. И все эти данные также приходят из разных подсистем и все их нужно объединять в рамках ядра АПК БГ, и не просто объединять, а где-то и управлять. Вот и получатся, что подсистема мониторинга просто обязана входить в список продуктов, необходимых для приготовления первоклассного АПК БГ.

И третьей ключевой подсистемой АПК БГ, пока не входящей в состав ядра является система оповещения населения. В России она давно создается и РАСЦО, и КСЭОН, но при интеграции с безопасным городом возникают проблемы и с управлением этим хозяйством, и с обратной связью. Сопряжение есть, отправка команды вроде бы идет, но понять, дошло ли сообщение до оператора внешней системы оповещения, и услышали ли его люди, зачастую невозможно.

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



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

Что станет изюминкой?

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

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

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

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



И на десерт

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

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

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

Кабысдох DoH-припарка от русского firewall

23.01.2021 00:18:58 | Автор: admin
# wtf cf-hls-media.sndcdn.comcf-hls-media.sndcdn.com is an alias for d1ws1c3tu8ejje.cloudfront.net.d1ws1c3tu8ejje.cloudfront.net has address 13.33.240.123 13.33.240.123 заблокирован

С в очередной раз замолчавшего радио и начался тот день, когда я допилил DNS-over-HTTPS сервер для облегчения фантомных болей от творчества Роскомнадзора.

Боли эти хорошо описаны @ValdikSS в статье В России сохраняются проблемы с доступностью сайтов, но никто их не замечает.

Думать особо не приходится, суть проблем проста и решение тоже не очень сложно: достаточно выкидывать из DNS ответов заблокированные IP адреса а, если адресов не осталось, заменять их на подходящие адреса с того же CDN. Такое издевательство над DNS позволяют как минимум Cloudflare и Amazon Cloudfront.

Например, если в условном DNS-ответе от AKAMAI пришли адреса 23.1.14.0 и 23.1.20.2, а первый из них заблокирован РКН, то в таком случае DNS-сервер может отдать клиенту только один адрес из двух, и браузер не будет тупить в попытке установить соединение с заблокированным IP. Это не обход блокировок, скорее наоборот. Но оно измеримо уменьшает боль. Я был бы рад такую конструкцию увидеть у Яндекс.DNS в Безопасном режиме, но всё же не думаю, что Яндекс готов реализовать такую в меру серую фичу.

Валить в панике из страны? Заворачивать весь трафик в VPN? Зачем! Интернет в России ещё не настолько поломан, чтоб добавлять 50-100ms ко всем своим Zoom-созвонам во времена повсеместной самоизоляции. Можно ещё попытаться что-то починить, да посмеяться над тем, что осталось.

Но хочу предупредить, модель такого DNS-сервера по имени kabysdoh.gulag.link запущена на виртуалке в Санкт-Петербурге, поэтому её использование из других регионов России может добавить существенную задержку к вашим DNS-запросам. При наличии архива XML-выгрузок Роскомнадзора, можно взять исходный код с GitHub и запустить Unbound в подходящей локации. Поддержку Knot Resolver я с @ValdikSS допилю в каком-нибудь обозримом будущем.

Мобильные устройства на Android поддерживают DNS-over-TLS, который доступен по адресу kabysdoh.gulag.link, а Mozilla Firefox поддерживает DNS-over-HTTPS по адресу https://kabysdoh.gulag.link/dns-query. Скриншоты примерной конфигурации можно увидеть ниже (про все возможные опции DoH в Firefox можно прочитать на wiki):

У меня на сегодня всё! Надеюсь, кому-то данная конструкция будет полезна. И помните, once you step into the waters of modifying in-flight DNS messages it seems like crocodiles all the way down.

Подробнее..

Всё о проекте Спутниковый интернет Starlink. Часть 22. Проблемы электромагнитной совместимости c другими спутниками

20.01.2021 00:15:59 | Автор: admin
Предлагаю ознакомиться с ранее размещенными материалами по проекту Starlink (SL):

Часть 1. Рождение проекта Часть 2. Сеть SL Часть 3. Наземный комплекс Часть 4. Абонентский терминал Часть 5. Состояние группировки SL и закрытое бета-тестирование Часть 6. Бета-тестирование и сервис для абонентов Часть 7. Пропускная способность сети SL и программа RDOF Часть 8. Монтаж и включение абонентского терминала Часть 9. Сервис на рынках вне США Часть 10. SL и Пентагон Часть 11. SL и астрономы Часть 12. Проблемы космического мусора Часть 13. Спутниковая задержка в сети и доступ к радиочастотному спектру Часть 14. Межспутниковые каналы связи Часть 15. Правила предоставления услуг Часть 16. SL и погода Часть 17. Второе поколение SL Часть 18. SL на рынке COTM Часть 19. Что у SL в будущем Часть 20. Внутреннее устройство терминала SL Часть 21. SL и проблемы поляризаци

Проблемы электромагнитной совместимости спутниковых сетей относятся к наиболее сложным и деликатным вопросам, которыми занимается Международный союз электросвязи (ITU), который является филиалом Организации Объединенных Наций в Женеве.

В России буквально 5 человек понимают проблему во всех ее деталях и могут отстаивать интересы российских операторов владельцев ИСЗ (искусственных спутников земли) на уровне МСЭ.

Поэтому я предоставлю слово Борису Абрамовичу Локшину. Он стоял у истоков российского телевидения непосредственного вещания, известного у нас как НТВ-Плюс, Триколор, Орион, МТС ТВ все они пришли позже и в технике шли по проложенной ранее колее Авторитет в отрасли у Борис Абрамовича (весьма скромного в жизни) просто огромный..

ВОПРОС: Низкоорбитальные системы ШПД Starlink, OneWeb работают в диапазонах Ku и Ka фиксированной спутниковой службы, которые используют и среднеорбитальные, и высокоэллиптические системы. Имеет ли решение задача ЭМС негеостационарных систем? Ваш прогноз на будущее?

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

Именно на отсутствие помех ГСО-сетям проверяют поданные заявки МСЭ (международный союз электросвязи) и Федеральная комиссия по связи (FCC) США. Опасной с точки зрения возникновения помех от низкоорбитальных систем является полоса вдоль экватора примерно от 2535 град. с.ш. до 2535 град. ю.ш., в зависимости от параметров многоспутниковой системы. Пролетая над этой территорией, низкоорбитальные спутники попадают в основной луч земных станций ГСО-сетей и могут создать помехи. Единственный способ исключения помех выключение спутника при пролете над экваториальной областью. Значительно сложнее ситуация при оценке ЭМС между НГСО-системами.

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

Насколько мне известно, никто пока не публиковал результаты анализа ЭМС двух низкоорбитальных систем, но на оценочном уровне представляется, что в каждом диапазоне частот может работать только одна такая система, использующая весь возможный частотный ресурс. Другие системы могут присоединиться к ней только на основе договоренности о совместном использовании общего ресурса с разделением по частоте, поляризации или пространству. Из сказанного, в частности, вытекает еще один весомый аргумент в пользу отказа от попытки создания в России собственной низкоорбитальной системы ШПД. К моменту подачи заявки в МСЭ уже будут действовать одна или несколько зарубежных систем, и отечественная система окажется последней в ряду других заявок, так что вероятность получения глобальных частот в Ku-или Ка-диапазоне будет крайне малой.

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


Пару слов от меня.

Отдельно можно поговорить о OneWEB, которая утверждает, что имеет приоритет на частоты Кu-диапазона для низкоорбитальных спутниковых систем. Это старая история про компанию WorldVu, которая всем известна как OneWEB, считающая, что МСЭ ранее предоставил WorldVu права на использование радиочастотного спектра (около 2 гигагерц Ku-диапазона с использованием негеостационарных спутников на высоте от 800 до 950 километров. WorldVu считает, что унаследовала права на частотный спектр компании SkyBridge, созданной в конце 1990-х годов, и хотевшей использовать Кu-диапазон для предоставления услуг связи на низкой орбите.

SkyBridge обанкротилась отчасти из-за слишком высокой стоимости необходимых ей спутников и наземных терминалов. Однако до того, как SkyBridge обанкротилась и исчезла как компания, она провела интенсивные переговоры с существующими операторами спутников на ГСО о том, не будут ли десятки спутников SkyBridge на низкой орбите (около 1000 км) мешать работе телекоммуникационных спутников на геостационарной орбите в 36 000 км над экватором.

В конечном итоге МСЭ согласилась (скоординировала частоты) с тем, что SkyBridge может работать таким образом, чтобы избежать помех для спутников на более высоких орбитах, использующих тот же спектр Ku-диапазона, путем регулярной корректировки уровней мощности своего сигнала.

Выделение Международным союзом электросвязи (ITU спектра Кu-диапазона SkyBridge никуда не делось и после того, как SkyBridge обанкротиалсь и перешла WorldVu, которая выкупила активы SkyBridge (и, соответственно, ее права на этот спектр). Согласно нормативной документации ITU, у компании WorldVu было время до 2020 года, чтобы начать развертывание своих спутников, с чем OneWEB успешно справилась в августе 2019 года, после чего и выпустила вот такой пресс релиз.

London, August 7, 2019 OneWeb, whose mission is to connect everyone everywhere, is pleased to announce it has succeeded in bringing into use its spectrum rights in the Ku- and Ka-band spectrum.To achieve this milestone, OneWebs satellites have been transmitting at the designated frequencies in the correct orbit for more than 90 days, enabling OneWeb to meet the requirements to secure spectrum bands over which it has priority rights under ITU rules and regulations.These rights will now be confirmed as the UK administration, which has filed our satellite system with the ITU, will complete the required Notification and Registration process of the companys LEO network.

Таким образом, если у кого и есть право первой ночи или приоритет на Кu-диапазон на НГСО, то именно у OneWEB.

Однако, в США, насколько я в курсе, FCC уже отказалась признать приоритет OneWEB и направила его и TeleSat LEO договариваться между собой и со SpaceХ о том, как они будут делить этот радиочастотный спектр между собой, чтобы не ставить друг другу помехи И это было тогда, когда Джефф Безос еще только писал свою заявку на Куйпер Так что теперь, когда ФСС одобрила заявку Куйпера, им надо будет делить это на четырех
Подробнее..

Перевод Решение проблем связанности микросервисов с помощью сетевых журналов

25.12.2020 14:07:02 | Автор: admin


Сеть является основой для распределенных приложений. Распределенное приложение имеет несколько микросервисов, каждый из которых работает в наборе Подов, часто расположенных на разных Нодах. Проблемные области в распределенном приложении могут быть на уровне сети (Flow, сетевые журналы), или на уровне недоступности ресурсов приложения (Метрики) или недоступности компонентов (трассировка).

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



Сетевые Журналы Имеют Несколько Сценариев Использования


Сетевые журналы могут использоваться для выполнения уникальных требований различных команд (DevOps, SecOps, Platform, Network). Ценность сетевых журналов Kubernetes заключается в собранной информации, такой как подробный контекст о конечной точке / endpoint (например, поды, метки, пространства имен) и сетевые политики, развернутые при настройке соединения. В ИТ-среде команды DevOps, SecOps, Network и Platform могут использовать сетевые журналы для своих сценариев использования, которые полезны в их домене знаний. Ниже мы покажем несколько примеров.



Генерирование Политик и Обнаружение Угроз с Помощью Журналов Потоков Данных в Calico Enterprise.


Calico Enterprise генерирует контекстные журналы сетевых потоков при каждом подключении к поду. Журнал сохраняется в файл на ноде, который затем обрабатывается агентом fluentd и отправляется в настроенное место назначения.



Как показано на приведенной выше диаграмме, журналы по умолчанию отправляются в движок Elasticsearch, который поставляется с Calico Enterprise. Вы можете настроить пересылку журналов потоков на вашу SOC платформу. Мы рекомендуем Вам иметь единую платформу для всех ваших журналов. Журналы это важнейший инструмент мониторинга и анализа для команды эксплуатации, которая уже имеет четко определенные процессы, построенные на централизованной платформе журналирования. Это важно для вашего планирования.

Характеристики Журнала Потока Данных


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

  • Предлагаемые рекомендации для создания политик позволяют разработчикам автоматически генерировать сетевые политики для защиты своих сервисов
  • Рабочий процесс для политик (рекомендации, предварительный просмотр, поэтапные политики) позволяет командам SecOps и DevOps эффективно создавать политики и развертывать их ненавязчивым образом
  • Обнаружение угроз позволяет командам SecOps отследить каждый flow по определенному IP-адресу или домену и выявить угрозы


Стандартный журнал потока в Calico Enterprise содержит в себе всю необходимую контекстную информацию:

  • Контекст Kubernetes (под, пространство имен, метки, политики)
  • IP-адрес отправителя для внешних источников, если он доступен через ingress
  • Start_time, end_time, action, bytes_in, bytes_out, dest_ip, dest_name, dest_name_aggr, dest_namespace, dest_port, dest_type, dest_labels, reporter, num_flows, num_flows_completed, num_flows_started, http_requests_allowed_in, http_requests_denied_in, packets_in, packets_out, proto, policies, source_ip, source_name, source_name_aggr, source_namespace, source_port, source_type, source_labels, original_source_ips, num_original_source_ips


Журнал DNS агрегируется для каждого пода с течением времени и содержит следующую информацию:

  • Start_time, end_time, type, count, client_ip, client_name, client_name_aggr, client_namespace, client_labels, qname, qtype, qclass, rcode, rrsets, servers


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

Сократите операционные расходы за счет оптимизации хранилища журнала потоков



Calico Enterprise собирает различные журналы (network / flow, audit, DNS). Журналы потоков являются самыми дорогими с точки зрения хранения, занимая более 95% общего объема хранилища. Нередко на каждую полностью загруженную ноду приходится 5k flow в секунду При скромных 200 байтах на flow это превращается в 1 МБ/с (мегабайт). Суточная потребность в хранилище для каждой ноды составляет 86 ГБ для журналов потоков. Для кластера из 100 узлов ежедневное требование к журналу потоков становится 8 ТБ+!!! Очевидно, что это не масштабируется. И что еще более важно, действительно ли вам нужно хранить так много данных? Как правило, ценность данных, содержащихся в журналах, экспоненциально уменьшается с течением времени и имеет значение только для устранения неполадок и обеспечения соответствия требованиям.

По этой причине Calico Enterprise имеет по умолчанию агрегацию, которая снижает требования к хранению журнала потоков более чем в 100 раз! Мы делаем это без ущерба для данных (видимость, мониторинг, поиск и устранение неисправностей), которые получают наши клиенты из журналов потоков. Журналы агрегируются по порту назначения в течение определенного периода времени. Таким образом, вам не нужно беспокоиться о стоимости хранения журналов потоков при использовании настроек по умолчанию в Calico Enterprise. Еще один способ, которым Calico Enterprise может помочь вам снизить требования к объему хранилища, это исключение. Вы можете легко настроить определенные пространства имен или инсталляции, которые будут исключены из создания журналов потоков.

Заинтересованы в детальном изучении журналов потоков?


Журналы потоков включены по умолчанию. Обратитесь к следующей документации для детальной настройки:

Подробнее..

Шифрование передаваемых данных в Calico Enterprise

25.12.2020 18:10:30 | Автор: admin


Мы рады сообщить, что Calico Enterprise, ведущее решение для сетей Kubernetes, безопасности и видимости в гибридных и мультиоблачных средах, теперь включает в себя шифрование передаваемых данных.

Calico Enterprise известен своим богатым набором средств сетевой безопасности для защиты контейнерных рабочих нагрузок путем ограничения трафика К и ОТ доверенных источников. Они включают в себя, но не ограничиваются, внедрением существующих практик контроля безопасности в Kubernetes, контролем egress с помощью DNS политик, расширением межсетевого экрана на Kubernetes, а также обнаружением вторжений и защитой от угроз. Однако по мере развития Kubernetes мы наблюдаем потребность в еще более глубоком подходе к защите конфиденциальных данных, который подпадает под требования нормативно-правового соответствия / compliance.

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

Некоторые нормативные стандарты устанавливают требования к защите данных и соблюдению требований к организациям и указывают на использование средств шифрования, в том числе SOX, HIPAA, GDPR и PCI. Например, стандарт безопасности данных индустрии платежных карт (PCI DSS) применяется к организациям, которые работают с фирменными кредитными картами, и был создан для усиления контроля за данными держателей карт с целью сокращения случаев мошенничества. PCI DSS требует от организаций шифрования номеров счетов кредитных карт, хранящихся в их базах данных, и обеспечения безопасности данных при передаче. Проверка соответствия проводится ежегодно или ежеквартально.



Calico Enterprise решает эту проблему, используя WireGuard для внедрения шифрования передаваемых данных. WireGuard согласуется с подходом Tigera batteries-included" к сетям Kubernetes, безопасности и наблюдаемости. WireGuard работает в качестве модуля ядра Linux и обеспечивает лучшую производительность и более низкую загрузку процессора, чем протоколы туннелирования IPsec и OpenVPN. Независимые тесты производительности Kubernetes CNI показали, что Calico с включенной функцией шифрования работает в 6 раз быстрее, чем любое другое решение на рынке.

WireGuard работает как модуль внутри ядра Linux и обеспечивает лучшую производительность и более низкую загрузку процессора, чем протоколы туннелирования IPsec и OpenVPN. Включить шифрование передаваемых данных на Calico Enterprise очень просто все, что вам нужно это развернутый на операционной системе хоста кластер Kubernetes с WireGuard. Полный список поддерживаемых операционных систем и инструкции по установке вы найдете на веб-сайте WireGuard.

Тесты производительности CNI


Являясь отраслевым стандартом для сетей Kubernetes и сетевой безопасности, Calico обеспечивает работу более миллиона нод Kubernetes каждый день. Calico единственный CNI, имеющий возможность поддерживать три data plane из одной, унифицированой контрольной панели. Независимо от того, что вы используете eBPF, Linux или Windows data plane; Calico обеспечивает невероятно высокую производительность и исключительную масштабируемость, что подтверждают последние бенчмарк-тесты.

Последний бенчмарк сетевых плагинов Kubernetes (CNI) по сети 10 Гбит/с опубликовал Алексис Дюкастель, CKA/CKAD Kubernetes и основатель InfraBuilder. Тест основывался на версиях CNI, которые были актуальны и обновлены по состоянию на август 2020 года. Были протестированы и сравнены только те CNI, которые можно настроить с помощью одного yaml-файла, включая:

  • Antrea V. 0. 9. 1
  • Calico v3. 16
  • Canal v3.16 (сетевые политики Flannel + Calico)
  • Cilium 1.8.2
  • Flanel 0.12.0
  • Kube-router последняя версия (2020-08-25)
  • WeaveNet 2.7.0

Среди всех протестированных CNI Calico стал явным победителем, продемонстрировав превосходство практически во всех категориях и получив превосходные результаты, которые приведены в таблице ниже. Фактически, Calico является предпочтительным выбором CNI в случаях первичного использования, представленных автором в резюме отчета.



Ознакомьтесь с полными результатами последних бенчмарк-тестов Kubernetes CNI. Вы также можете запустить бенчмарк на собственном кластере, с помощью инструмента Kubernetes Network Benchmark Tool от InfraBuilder.
Подробнее..

Установка NTP сервера для включения его в pool.ntp.org

08.01.2021 08:12:11 | Автор: admin

Большинство дистрибутивов операционных систем на базе Linux и многих сетевых устройств используют для установки часов сервера вида *.pool.ntp.org.

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

Как сказано на сайте https://www.ntppool.org/ru/ - это огромный кластер серверов точного времени, предоставляющий надежный и простой в использовании NTP-сервис для миллионов клиентов и его услугами пользуются десятки миллионов систем по всему миру.

Как же установить свой сервер, что для этого требуется?

Требуется обычный сервер со статическим реальным IP адресом с актуальной операционной системой будь то Linux/BSD или подобное устройство которое в состоянии стабильно работать роли ntp-сервера по протоколу NTP https://ru.wikipedia.org/wiki/NTP который работает через интернет-сети на по порту 123/udp

Из-за небольшого потребления ресурсов и канала (до 10-15 килобит в секунду) подойдет практически любая конфигурация, например, VPS/VDS на базе KVM с минимальными ресурсами.

Цитирую с сайта https://www.ntppool.org/ru/join.html

В настоящее время большинство серверов получают порядка 5-15 NTP-пакетов в секунду. Несколько раз в день могут возникать пики по 60-120 пакетов в секунду. Переводя в килобиты, получаем примерно 10-15Кбит/с в среднем и порядка 50-120Кбит/с на пиках нагрузки. В пул постепенно входит все больше серверов, поэтому резкое возрастание нагрузки в будущем не ожидается. Таким образом, вам вряд ли потребуется полоса больше 384-512Кбит (на прием и отдачу)

Устанавливаем NTP-сервер

В большинстве дистрибутивов Linux он входит в стандартные репозитории операционной системы и достаточно выполнить его установку

apt install ntp для Debian/Ubuntu или yum install ntp для CentOS

Теперь откройте файл конфигурации в вашем /etc/ntp.conf и там в 99% случаев будут сервера из пула:

pool 0.debian.pool.ntp.org iburst

pool 1.debian.pool.ntp.org iburst

pool 2.debian.pool.ntp.org iburst

pool 3.debian.pool.ntp.org iburst

Просто закомментируйте их символом #, сервер который будет входить в пул не должен синхронизироваться с ними

После чего перейдите по ссылкам http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers и http://support.ntp.org/bin/view/Servers/StratumOneTimeServers выберете там сервера для синхронизации

Также рекомендуется использовать google по запросу вида ntp server ваша_страна

Рекомендуется использовать не меньше 4 и не больше 6 серверов

Руководствуйтесь правилом 2+2+2 -

2 сервера - StratumOne

2 сервера - StratumTwo

2 сервера - в геолокациях соседними с вашей

Работу сервера следует проверить командой ntpdate -q имя-сервера должен быть ответ вида

root@gw:~# ntpdate -q ntp4.vniiftri.ru

server 89.109.251.24, stratum 1, offset 0.001008, delay 0.08249

8 Jan 03:50:07 ntpdate[1414]: adjust time server 89.109.251.24 offset 0.001008 sec

Что означает что сервер работает, есть ответ и он представляет собой сервер первого яруса (stratum 1)

Подробнее об ярусах (stratum) можно прочитать по ссылке http://personeltest.ru/aways/habr.com/ru/post/79461/

Сервера которые являются эталонными часами (атомными, GPS-спутник) являются сервера так называемого нулевого уровня (stratum 0)

Сервера которые синхронизируются с ними напрямую (например, через GPS-приемник) имеют уровень 1

Следом идут сервера 2 и 3 чего вполне достаточно для синхронизации времени часов большинства компьютерных систем

Проверка работоспособости

После добавления новых серверов (предварительно проверенных через ntpdate -q) следует перезапустить ntp-сервер (service ntp restart) и проверить его работу командой ntpq -pn

root@gw:~# ntpq -pn

remote refid st t when poll reach delay offset jitter

==============================================================================

-51.15.74.121 131.176.107.13 2 u 48 64 17 1.009 -0.030 0.246

193.190.230.37 .EXT. 1 u 41 64 17 4.825 -0.263 0.853

+145.238.203.14 .MRS. 1 u 41 64 17 14.549 -0.857 0.127

-89.109.251.24 .MRS. 1 u 44 64 17 46.043 0.501 1.539

+62.231.6.98 .GPS. 1 u 43 64 17 41.770 -1.292 0.647

-80.60.208.118 193.67.79.202 2 u 43 64 17 8.324 -1.364 1.338

Когда есть сервер который начинается с * - значит синхронизирован успешно.

Понаблюдайте за работой ntp сервера некоторое время. Оставьте сервера с минимальным delay и jitter, рекомендуется потратить на это около часа времени и отобрать действительно лучшие сервера.

Также проверьте работу сервера с внешнего подключения через интернет выполнив ntpdate -q ip-адрес тем самым убедитесь что все работает, udp/123 нигде не фильтруется

Добавлние сервера в пул pool.ntp.org

Дальше следует перейти на сайт https://www.ntppool.org/ru/join.html и добавить сервер - все предельно просто после быстрой регистрации

Сервер работает по IP адресу, доменное имя можно указать на этапе добавления и оно будет использоваться только в момент первоначальной настройки и для отображения в списке.

После чего выполняется проверка стабильности работы сервера (так называемый score) и как он станет больше 10 - ваш сервер будет добавлен в пул.

Наблюдать пакеты можно командой tcpdump port 123 - будут видны запросы с различных сетей различных провайдеров, в основном конечно с клиентских устройств (интернет-роутеров)

04:00:50.531801 IP gw.mytimeserver.net.ntp > 82-217-46-231.cable.dynamic.v4.ziggo.nl.59634: NTPv4, Server, length 48

04:00:50.888803 Imytimeserver.netP 51.144.84.29.ntp > gw.mytimeserver.net.ntp: NTPv4, Client, length 48

04:00:50.888998 IP gw.mytimeserver.net.ntp > 51.144.84.29.ntp: NTPv4, Server, length 48

04:00:51.621673 IP 46.11.105.3.54627 > gw.mytimeserver.net.ntp: NTPv4, Client, length 48

04:00:51.621916 IP gw.mytimeserver.net.ntp > 46.11.105.3.54627: NTPv4, Server, length 48

04:00:52.037807 IP 51.136.36.226.ntp > gw.mytimeserver.net.ntp: NTPv4, Client, length 48

04:00:52.052103 IP gw.mytimeserver.net.ntp > 40.68.72.138.ntp: NTPv4, Server, length 48

В связи с этим настоятельно рекомендую провайдерам интернет-услуг установить в своей сети ntp-сервер и включить его в ntp-пул.

Полезные ссылки

https://www.ntppool.org/ru/

http://www.ntp.org/

https://ru.wikipedia.org/wiki/NTP

Подробнее..

RADIUS немного о Mikrotik, NPS и не только

10.01.2021 16:05:45 | Автор: admin
  • Цель статьи

  • Определение

  • Компоненты

  • Общие понятия

  • Сфераприменения

    • -login

    • -VPN (ppp*)

    • -wifi

    • -dot1x

  • диагностика

  • выводы

Цель

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

Определение, назначение, общие сведения

RADIUS - это протокол, для авторизации, аутентификации и учёта (AAA).

Позволяет повысить безопасность сети и централизованно управлять доступами.

Сервер RADIUS может иметь свою базу данных с учетными данными (например файлы илиmysql) или работать в паре с другим сервером, например Active Directory.

Кроме AAA позволяет передать некоторые дополнительныеданные (настройки) клиенту прошедшему аутентификацию, в том числе vendor-specific attributes (VSA). У Mikrotik такие тоже есть, позже пройдемся по самым интересным.

Существуют много популярных приложенийрадиус сервера, самый популярные: freeRADIUSи Служба NPS (Network Policy Server) Windows Server. Более подробно мырассмотрим второй вариант.

Компоненты кейса

  • Суппликант - устройство которое намеренопройти процедуру авторизации и аутентификации.

  • Аутентификатор - устройство к которому подключается суппликант, которое получаету суппликанта данные авторизации и которое проверяет их на RADIUS сервере. NB! Является клиентом для радиус-сервера.

  • RADIUS сервер (он же радиус сервер, он же сервер аутентификации).

Настройка

Установку роли описывать не буду, существует 100500 статей в картинках, например: тыц

  1. Добавлениерадиус клиента на радиус-сервере Намнужно заполнить "понятное имя", IP адрес и придумать пароль (а.к.а. "секрет"), которыйпонадобится при настройке аутентификатора (mikrotikв нашем случае)

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

Политики имеют порядок и обрабатываются по нему одна за другой. Если подключение не соответствует условиям политики, то проверяется следущаяи так далее. К примеру, это поможет разделить правила обработки для проводных\беспроводных и впн клиентов. {.is-warning}

  1. Добавление политики запросов на подключение

  2. Добавление сетевой политики

Некоторые типовые кейсы применения радиус сервера :

  1. централизованная аутентификация на устройствах поддерживающихaaa

  2. аутентификация для vpn (pptp\l2tp)

  3. аутентификация вwifi

  4. аутентификация устройств при подключении к порту rj45 - dot802.1x

Итак подробнее, + некоторые плюшки. Для всех наших пунктов нам нужнонастроить радиус клиента вmikrotik

/radius add address=10.10.11.100 comment="PVE AD" secret=STRONG_SECRET_PASSWORD service=ppp,login,hotspot,wireless,dhcp,ipsec,dot1x timeout=600ms

address -Адрес радиус сервера secret - пароль, который мы совсем недавно настраивали для радиус клиента service -сервисы в mikrotik, которые могут использовать радиусдля аутентификации.

Отдельно стоит отметить пункт timeout=600ms, если вы используете радиусчерез медленные каналы с большими задержками, стоит увеличитьэто значение.

Теперь можно начинать настраиватьинтересные вещи.

1. настроим входна микротик

/user aaaset accounting=yes default-group=read use-radius=yes

Стоит уделить внимание параметру default-group он означаетгруппу по умолчанию,вкоторая применится к пользователю.

Теперь настроим NPS:

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

ОбратимсякWikimikrotik, мы можем заметить RADIUS атрибут, который позволяет определитьдоступы какой группыприменятся к пользователюкоторый аутентифицируется на устройстве черезRADIUS. *Mikrotik-Group - Router local user group name (defines in /user group) for local users; HotSpot default profile for HotSpot users; PPP default profile name for PPP users. * воспользовавшись промт'оммы понимаем что этот атрибут позволяет задать нам имя встроенной группы при авторизации , или задать имя профиля при аутентификациив сервисыvpn или hostspot. этот атрибут мы буем использовать и позже.что бы отделить мух от котлет приавторизации для впн мы будем использовать дополнительные условия, но это позже.

итак, как мы этого добьемся мы можем создать вSystem -> users ->groupдве группы со специфичными параметрами доступа, а можем и воспользоваться уже существующими, к примеруfullиread.

Но все это ничего без второй части, нам необходимо настроитьNPS. Давайте создадим в остнастке Пользователи и компьютерыДве группы пользователей admins-network иadmins-junior. И два пользователяnet-juniorи net-admin,добавим их в соответствующие группы.

Политику запроса на подключение мы уже создали, перейдем к сетевым политикам. в Оснастке NPSсоздадим двеполитики mikrotik-login-juniorиmikrotik-admin-network ,в условиях первойзададим :

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

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

В методах проверки подлинности указываем :

Политика mikrotik-admin-networkбудет отличаться тем что в условияхвыберем группу admins-networkа значение отрибутаMIKROTIK_GROUPзададим как full Результат ожидаемый, мы залогинилисьв микротик под полными правами:

/user active print detailFlags: R - RADIUS, M - by-romon 0 R when=jan/05/2021 10:36:52 name="net-admin" address=10.10.15.7 via=winbox     group=full 1 R when=jan/05/2021 10:37:04 name="net-admin" address=10.10.15.7 via=telnet     group=full

Перейдем к впн, и к стразу более интересному сценарию.

Предположим мы хотим отделитьадминов, от остальных работников. Выдадим админам профиль с подсетью которая будет иметь доступ к management vlanи не только, и выдадимотстальным сотрудникам профильс подсетью которая будет меть ограниченый доступ только к 1c, RDP, etc.. . Предположим, мы используюем для впнl2tp\ipsec/ Для этого создадим в микротик два профиля в PPP -> profile

/ip pool add name=pool_l2tp_admin ranges=10.10.21.10-10.10.21.250/ip pool add name=pool_l2tp_users ranges=10.10.22.10-10.10.22.250/ppp profile add dns-server=10.10.21.1 local-address=10.10.21.1 name=l2tp-vpn-admin remote-address=pool_l2tp_admin use-compression=no use-encryption=yes/ppp profile add dns-server=10.10.22.1 local-address=10.10.22.1 name=l2tp-vpn-users remote-address=pool_l2tp_users use-compression=no use-encryption=yes

В настройки правил форейвола дляограничения доступа подсетей япожалуй не буду углубляться,подразумевается что вы понимаете как изодной подсети запретить доступ кресурсу икак разрешить. (с)предпологается, что вы немного сетевик. Касательно примера подсети10.10.21.0/24необходимо разрешить форвард в подсети серверов и managementа подсети 10.10.22.0/24необходимо разрешить только доступк корпоративным сервисам, но не к сетям управления.

Настроим NPS. В остнастке Пользователи и компьютеры создадим 2 группы пользователей vpn-admins иvpn-users, знакомого нам net-adminвключим в 1ю группу, а net-buhво вторую. Политика запросов на подключение у нас будет использоваться та же. А политики сети созадим. В Условиях важно не только задать группу пользователей, но и тип порта NAS

Знакомым нам образом добавим атрибут указывающий какой профиль микротика использовать.

Методы проверки подлинности используем как и в прошлый раз. В настройках Сервера VPNрекомендуется указать точно такой же тип.

На вскидку полезными так же могут отказаться атрибуты : Mikrotik-Rate-Limit - дляограничения скорости vpnклиентов

Настроим тестовое поключение и увидим что получилиIPиз пуладля сетевых администраторов.

Теперь настроим политику дляобычных пользователей:

Результат - пользователь получилipизнужной подсети

Wifiи Dot1x

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

  • настроить службу центрасертификацииWindowsтыц, актуально и для следующего пункта

  • настроить GPO для распространения CAсертификата домена тыц

  • GPOавтоматического получения сертификата компьютераdocs.microsoft

  • GPOвключение службы dot1X (проводная автонастройка) исоздать Политики проводных сетей (802.3) для выбора способа проверки подлинности тыц

  • GPOАвтоматическое подключение кWifiдо логина пользователя тыц

Данные пункты не маленькиечто бы включать их в эту статью, но достаточно освещены в статьях интернета.

wifi

Настройку WiFiкаждый настраивает как ему удобно. Я к примеру,предпочитаю CapsMan,дажеесли это будетединственная APв сети. В любом случае нас интересует только Security Profile/Security Cfg.

Создадим политику сети: В условиях выберем Тип порта NAS= Беспроводная - IEEE 802.11

А в методах проверки подлинности следующее.

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

Какие радиус атрибуты могут быть нам полезны:

  • Framed-Pool - можемдля отдельных групп пользователей использоватьсвойipпули выполнять какие то манипуляции на основе этого вфорейволе

  • Filter-Id - применять какое то правило форейвола сразу к клиенту

  • Mikrotik-Wireless-VLANID - указать в какойvlanдолжен попасть клиент (Возможно, однажды, по заявкампользователейя дополню статью примером с ипользованиемvlanвwifi)

  • устанавливать лимитыпо обьему или/и скорости трафика

  • имногие другие параметры из вики, либо их комбинации с условиями сетевой политики, смотря сколько у вас фантазии :)

dot1x

Зачем нужен dot1X и как его настроить.. очень много интересных слов можно было бы тут написать, но все сказанодо нас. Например на каналеодного прекрасного тренераили wiki

Половина смысла с саркальной точки зрения в dot1xв том, что в случае успешной проверки подлинности наше устройство попадетв влан указанный нами в микротике или в влан который мы поличим в качестве атрибута у радиуса. Еслипроверка подлинности пройдет с отказом или ответ не будет получен от радиуса (например в случае его недоступности), то порт перейдет в изолироованный режим (будет заблокирован любой трафик на порту) или в случае если указан Reject VLAN IDто попадет в влан,для которогомы настроили(я надеюсь все таки настроили) максимально безопасные правилафорейвола для чужеродных устройств .

Начнем с микротика:

Настроим политики сети: В условиях необходимо отобрать проводные клиенты

Параметры аутентификации:

В настройках атрибутами выдадим рабочий влан

К примеру вот так выглядит отказ вавторизации:

А вот так успешное подключение:

Диагностика

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

  • логи mikrotik

    Идем в system logging add topics=radius,debug action=memory disabled=noи пробуем что то делать, в log printпоявятся записи связанные с радиусом. -логи Службы

  • политики сети и доступа

    я уже приводил пример, еще раз - искатьздесь, и читать внимательно сообщения

  • возможны проблемы из заwindows брандмауерапочинить можно

Get-NetFirewallRule -DisplayGroup "Сервер политики сети" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any

илидляанглоязычной версии:

Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any 
  • radclientиз пакета freeradius-utils. Позволяет из командной строки проверить некоторые типы авторизации, к примеру подключение кvpn

Тест:

echo "User-Name = USER,User-Password=PASSWORD,NAS-Port-Type=Virtual" | radclient -s 10.10.11.100:1812 auth SHARE_NPS_SECRET -x

Вывод программы:

Sent Access-Request Id 177 from 0.0.0.0:42354 to 10.10.11.100:1812 length 56       User-Name = "USER"       User-Password = "PASSWORD"       NAS-Port-Type = Virtual       Framed-Protocol = PPP       Cleartext-Password = "PASSWORD"Received Access-Accept Id 177 from 10.10.11.100:1812 to 10.10.15.7:42354 length 94       Mikrotik-Group = "pptp-nps"       Framed-Protocol = PPP       Service-Type = Framed-User       Class = 0xa1cd098c00000137000102000a0a0b6400000000ec967e14be8346ce01d6d63b3e2ca9d70000000000000092Packet summary:       Accepted     : 1       Rejected     : 0       Lost         : 0       Passed filter : 1       Failed filter : 0

Выводы

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

Если какой то из пунктов непонятен, пишите. попробую показать или помочь разобраться.

Если в статье нашли ошибки, неточности или знаете как сделать лучше тоже пишите.

Благодарности:

Спасибо @aslancherkesov за злого редактора и свежий взгляд на буквы.

Подробнее..

Не нравится свой интернет-провайдер? Стань им сам опыт американца по имени Джаред Мауч

14.01.2021 00:13:39 | Автор: admin

Качество работы некоторых интернет-провайдеров не выдерживает никакой критики. Подобные компании можно найти в любой стране. Чаще всего проблема в том, что организация является монополистом в своем регионе, поэтому делает, что хочет. Есть на эту тему отличная серия из South Park, которая называется Informative Murder Porn. И хотя в ней показан провайдер кабельного ТВ, сюжет актуален и для интернет-отрасли.

Так вот, в пригороде Мичигана один из клиентов провайдера интернет-услуг остался настолько недоволен сервисом, что сам стал интернет компанией. Он пробросил оптоволокно, сделал разводку, зарегистрировал предприятие и получил скоростной интернет не только для себя, но и стал обеспечивать связью соседей. Имя этого человека Джаред Мауч.

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

С чего все началось?


Мауч перебрался в новый дом в пригороде Мичигана в 2002 году. На то время он получит от местного провайдера канал T1 со скоростью в 1,5 Мбит/с, чего было вполне достаточно. Но по мере того, как совершенствовались сетевые технологии, Мауч ожидал, что и сеть в регионе будет модернизироваться. Но нет.

В итоге он переключился на провайдера, предоставляющего услуги беспроводной интернет-связи на скорости в 50 Мбит/с. Также он связался с Comcast, крупнейшей ИТ-компанией из США, спросив, во что обойдется продолжить оптоволокно к его дому. Компания сообщила, что в этом случае придется выложить $50 000. Мауч, как человек небедный, был готов потратить $10 000, но не полсотни тысяч долларов. Как он сам говорил позже, суммы в $50 000 не ожидал, и такую кучу денег непонятно за что платить не хотел.


Пять лет назад еще один крупный провайдер, AT&T, предложил DSL-линию. Но в этом случае скорость обещали ту же, что у него уже была раньше 1,5 Мбит/с. Смысла менять шило на мыло просто не было. Ну а потом провайдер и вовсе отказался от DSL, забросив и планы по модернизации своей инфраструктуры в ряде регионов.


Маучу все это надоело, и четыре года назад он решить стать интернет-провайдером сам. Несколько месяцев назад план удалось реализовать сетевой архитектор продолжил около 10 км оптоволокна и выполил все необходимые для проведения ШПД-интернета в своей дом работы. Более того, 70% его соседей стали его же клиентами. Раньше они использовали мобильные гаджеты для подключения к интернету.

Что за компания?


Американец назвал ее Washtenaw Fiber Properties LLC, зарегистрировав в качестве провайдера телефонной связи (в США только так можно предоставлять интернет клиентам). Правда, телефонных услуг он не предоставляет, равно как не проводит и кабельное.

На все про все Мауч потратил $145 000, что, конечно, немало даже для небедного человека. Но эти деньги он может постепенно вернуть, предоставляя услуги связи все большему количеству клиентов в своем регионе.


$95 000 ушло на прокладку двух интернет-каналов. Один из них сейчас используется для проведения оптоволокна, второй свободен, так что Мауч надеется в недалеком будущем сдать в аренду какой-либо IT-компании, которая придет в этот регион. Протяженность линии от точки подключения до дома Мауча 10 км. Обе магистрали находятся на глубине около 2 м, правда, в некоторых случаях углубляются до 5м, чтобы обойти трубопроводы разного назначения.


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

В домах клиентов Mauch устанавливает медиаконвертер Mikrotik RBFTC11 с модулем Ubiquiti PON-to-Ethernet. Клиенты могут использовать свои собственные беспроводные маршрутизаторы или покупать их у Mauch по себестоимости. Он решил не сдавать оборудование в аренду, поскольку это не выгодно для клиентов.

Кстати, некоторые из них добровольно потратили по несколько тысяч долларов США, чтобы снизить затраты Мауча. За это они получили скидки и премиум-обслуживание (бесплатное пиво по субботам?). Выше уже говорилось о том, что потратить пришлось много. Но американец планирует выйти в ноль уже через 3,5 года он продумал бизнес-модель, так что особой проблемы с возвратом денег нет.


Что касается тарифов, то за канал с пропускной способность в 50 Мбит/с американец просит $65 (для США это вполне нормально), $75 за канал в 250 Мбит/с и $99 за 500 Мбит/с. Если дом клиента удален от магистрали, то клиенту приходится платить за прокладку оптоволокна.


Не обошлось и без проблем разные согласования, поломки и даже кража важного оборудования, которое полиция потом нашла благодаря объявлению, созданному вором на Facebook, мешали нормальному ходу реализации проекта. Но Мауч справился и теперь провайдер работает, обеспечивая интернетом свыше 30 домов поблизости. Каждый месяц появляются новые клиенты.

А что насчет жалоб клиентов?


Их нет, по крайней мере, пока. Клиенты довольны, никаких обрывов связи или прочих проблем нет. Единственные несколько запросов, которые поступали увеличение беспроводной зоны доступа в ряде домов. Клиенты просили установить им более мощные роутеры, вместо тех, которые были куплены ими самими.

Официально Мауч не предоставляет каналов связи с пропускной способностью выше 500 Мбит/с. Но в реальности, поскольку клиенты не выбирают всю скорость, зачастую показатель достигает 1 Гбит/с.

Кстати, соседям американца повезло. Жителям пригородов и удаленных от городов регионов приходится туго. Около 17,3% населения в таких локациях не имеют возможности подключиться к ШПД. В крайнем случае это дорогая связь по мобильной сети.

Планы на будущее



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


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

Подробнее..

Перевод Автомобильный Ethernet Marvell делает ставку на Gbit Ethernet PHY с поддержкой MACsec

21.01.2021 20:07:17 | Автор: admin
image

Для создания платформы сетевой инфраструктуры на развивающемся рынке сетевых транспортных средств, компания Marvell полагается на технологию Ethernet.

На этой неделе компания объявила о создании первой в отрасли PHY-микросхемы, работающей на основе гигабитной Ethernet-сети. В эту микросхему также встроена технология контроля доступа к медиаданным (MACsec), обеспечивающая безопасность на втором уровне.

Технология MACsec обеспечивает защиту всех этапов передачи данных в автомобильных сетях. Новая PHY-микросхема защищена от угроз безопасности на 2 уровне (перехватов, атак посредника и атак повторного воспроизведения).

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

Уилл Чу, вице-президент и генеральный менеджер автомобильного бизнес-подразделения Marvell, сказал EE Times: Сейчас мы переносим наш опыт в области передовой инфраструктуры для обработки данных на автомобильный рынок.

Marvell твердо намерена занять лидирующие позиции на рынке автомобильных Ethernet-сетей. Компаний первой на рынке представила 1000BASE-T1 PHY защищенный автомобильный коммутатор с поддержкой гигабитного однопарного Ethernet-подключения и мультигигабинтную PHY-микросхему. В мае Marvell также приобрела Aquantia лидера в области мультигигабитных Ethernet-подключений.

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

Впрочем, как заметил Иэн Ричс, вице-президент по общей практике в области automotive в Strategy Analytics, суровая реальность такова, что на сегодняшний день интерфейсы для работы с гигабитными Ethernet-сетями слабо распространены. В основном такие интерфейсы встраивают в премиумные или новейшие платформы.

Безопасность и энергоэффективность


image

Новая PHY-микросхема 100/1000 BASE-T1 88Q222xM от Marvell обеспечивает поддержку мультигигабитных подключений, а также в нее встроена технология MACsec.

Эта микросхема также поддерживает стандарт TC10 от Open Alliance, который описывает переход в спящий режим и пробуждение. Эта технология помогает снизить энергопотребление сетевых модулей в автомобиле. Чу утверждает, что энергоэффективность становится все более важной автомобильной характеристикой.

Отвечая на вопрос о новом гигабитном PHY с поддержкой MACsec от Marvell, Ричс из Strategy Analytics сказал EE Times следующее: Чем выше скорость, тем больше данных. Чем больше данных, тем выше вероятность возникновения проблем с безопасностью. Также он объяснил нам, что MACsec зрелый и надежный стандарт, позволяющий обнаруживать подозрительную активность в Ethernet-сетях, что позволяет обеспечивать защиту от перехватов, атак воспроизведения и атак посредников. Наличие подобных легкодоступных методов, основанных на стандартах, позволит OEM-производителями разрабатывать комплексные решения для кибербезопасности, которые нужны как рынку, так и регулирующим органам.

Marvell утверждает, что 88Q22xM это самая экономичная с точки зрения энергии PHY с поддержкой гигабитного Ethernet-подключения. Это значит, что 88Q22xM даст OEM-производителям возможность разрабатывать энергоэффективные автомобильные сетевые архитектуры.

Движущие факторы внедрения гигабитных Ethernet-подключений в транспортные средства


Учитывая все обстоятельства, станут ли электромобили первыми транспортными средствами на рынке, использующими Ethernet-подключение? Рич из Strategy Analytics утверждает, что сам по себе рынок электромобилей не является основной движущей силой внедрения Ethernet в автомобильной отрасли.

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

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

Автомобильный рынок в условиях пандемической экономики


Отраслевые аналитики прекрасно осведомлены о влиянии экономики Covid-19 на автомобильный рынок. Эгиль Юлиуссен, автор колонки Egils Eye в EE Times написал так: Продажи автомобилей по всему миру резко упали и будут держаться ниже недавних показателей в течение примерно пяти лет (а может и больше в зависимости от региона).

Ричс из Strategy Analytics согласен с этой оценкой. Разработка некоторых новых платформ будет замедлена в связи с сокращением бюджета и реструктуризацией, причиной чему стала пандемия Covid-19. В настоящий момент мы даем прогнозы до 2027 года. Мы по-прежнему ожидаем, что полноценная сетевая архитектура на основе контроллеров доменов и гигабитного Ethernet-подключения будет представлена в меньшей доле новых автомобилей.

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

Чу из Marvell делает более глобальную оценку. Насколько ему известно, 30 OEM-производителей уже изучают способы внедрения Ethernet в автомобили, и 10 ведущих компаний уже начали внедрять Ethernet в свои продукты три года назад. Мы знаем, что для автомобильных OEM-производителей внедрение гигабитных Ethernet-сетей это вопрос времени

Marvell также утверждает, что 88Q222x производится в соответствии с автомобильными системами менеджмента качества и обеспечивает поддержку систем функциональной безопасности, благодаря чему OEM-производители могут реализовывать стандарт ISO 26262 на системном уровне. Микросхема проходит испытания с прошлого месяца. По словам Чу, массовое производство начнется в течение трех лет. 88Q22x будет изготавливаться TSMC с использованием автомобильного техпроцесса 16 нм FinFET.




image

Вакансии
НПП ИТЭЛМА всегда рада молодым специалистам, выпускникам автомобильных, технических вузов, а также физико-математических факультетов любых других высших учебных заведений.

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

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

Если вам интересно попробовать свои силы в решении тех задач, которые у нас есть, пишите в личку.



О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

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

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

Подробнее..

История систем управления световым оборудованием

24.12.2020 14:22:40 | Автор: admin
Источник

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

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

Зарождение светомузыки


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

Одним из первый электронных музыкальных инструментов, который также создавал светомузыку, можно считать оптофоническое пианино (оптофон) художника Владимира Баранова, созданное в 1916 году.

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

До 1970-х годов интерес к светомузыке проявляли в основном ученые и художники.

Аналоговая эпоха


Оптофон Владимира Баранова. Источник.

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

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

Светомузыка, имеющая синхронизацию со звуком, делится на две группы:

  • автоматические светомузыкальные устройства (АСМУ);
  • программируемые синхронные автоматы (ПСА).

Чаще всего автоматические светомузыкальные приборы основаны на принципах фильтрации диапазона частот в отдельные частотные каналы, которые подаются на соответствующие световые установки. Классическое сопоставление частот с цветами это линейное сопоставление частот АЧХ с порядком следования цветов в видимом спектре:

  • красный низкие частоты (диапазон до 200 Гц);
  • желтый средне-низкие частоты (диапазон от 200 до 800 Гц);
  • зеленый средние частоты (от 800 до 3500 Гц);
  • синий высокие частоты (выше 3500 Гц).

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

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

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

Стойки с диммерами. Источник

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

Советский световой пульт СУТО. Источник

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

С появлением компьютеров производители стали добавлять цифровую составляющую в пульты управления.

DMX512


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

Институт театральных технологий США (United States Institute for Theatre Technology, USITT) в 1986 году разработал стандарт DMX512, предназначенный для унификации общения пультов управления и конечных устройств.

Кабель с разъемом DMX512 XLR. Источник

В основе DMX512 лежит промышленный интерфейс EIA/TIA-485, более известный как RS-485. Данные отправляются в виде дифференциального сигнала, что значительно снижает влияние наводок в цепи. Стандарт предписывает использовать кабели с пятью жилами:

  • экран;
  • отрицательный сигнальный провод;
  • положительный сигнальный провод;
  • отрицательный резервный провод;
  • положительный резервный провод.

Тем не менее, ревизии стандарта 1986 и 1990 годов не определяют назначение резервной пары, поэтому допустимо ее отбросить и использовать трехжильные провода, например, микрофонный кабель. Однако фантомное питание микрофона (+48 В) способно повредить DMX-совместимое оборудование, а DMX-сигналы от консоли могут повредить микрофон. Поэтому стандарт предписывает использовать именно коннекторы XLR-5.

Одна линия DMX512 вмещает 512 каналов, то есть один провод DMX512 эквивалентен 512 проводам аналогового интерфейса 0-10 В.

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

DMX512 поддерживает последовательное подключение устройств. Так, от пульта управления может идти одна линия, которая подключается ко входу первого устройства, а второе устройство подключается к выходному порту первого. У такого способа, однако, есть ограничения. Во-первых, суммарное потребление каналов не должно превышать 512 каналов. Во-вторых, на линии допустимо не более 32 устройств. Она обязательно должна заканчиваться терминатором, если в последнем устройстве нет внутренней терминации.

Оптический изолятор DMX512. Источник

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

Консоль предоставляет несколько DMX-портов. Каждый DMX-порт, также называемый DMX-областью (DMX Universe), предоставляет до 512 каналов. Каждый канал передает ровно один байт данных, то есть число от 0 до 255. Передача DMX-кадра с максимальной длиной занимает 23 мс, что ограничивает скорость обновления до 44 раз в секунду.

Стандарт DMX512 не изменялся с 1990 года. Однако в 1998 году Ассоциация развлекательных услуг и технологий (Entertainment Services and Technology Association, ESTA) начала пересматривать стандарт с целью попасть в стандарты ANSI. В 2004 году DMX512 был стандартизирован как DMX512-A, а затем был повторно пересмотрен в 2008. Наиболее актуальная версия на момент написания статьи ANSI E1.11-2008, USITT DMX512-A.

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

DMX512 over Ethernet


Решение проблемы ограниченности DMX-линий оказалось достаточно простым. Необходимо сменить среду передачи данных на Ethernet, который уже зарекомендовал себя и используется повсеместно. Благодаря такому решению можно передавать множество DMX-областей в одном кабеле. Для подключения устройств с DMX-коннекторами используются специальные конвертеры, которые извлекают из пакетов DMX-данные и отправляют подключенным устройствам.

На данный момент существуют два конкурирующих решения по отправке DMX512 в среде Ethernet:

  • Art-Net;
  • sACN.

Рассмотрим каждый из них.

Art-Net


Компания Artistic License в 1998 году выпустила первую версию Art-Net протокол для передачи DMX-данных через IP. В основе протокола были широковещательные сообщения, чтобы избавить пользователей от настройки сети. Art-Net I проектировалась на сетях 10 Мбит/с, которые выдерживали в среднем до 10 DMX-областей, а эффективный предел составлял 40 Мбит/с. Однако с широким распространением RGB-светодиодов количество каналов росло, и подход с широковещательными сообщениями создавал сильную нагрузку на сети.

Чтобы хоть как-то исправить эту проблему, в 2006 вышла следующая версия Art-Net II. В основе также лежали широковещательные сообщения, но консоль сопоставляла DMX-области с конкретными устройствами и переходила к адресной рассылке. При этом предельное количество DMX-областей расширилось до 256. В следующих релизах число выросло до 32768.

Art-Net не стал официально признанным стандартом, но используется по сей день. Современная версия Art-Net IV позволяет работать с устройствами, которые поддерживают только стандартизированный протокол sACN.

ACN и sACN


Протоколы Architecture for Control Networks (ACN) и Streaming ACN (sACN) это стандартизированный в 2006 году набор протоколов для управления развлекательным оборудованием в живых выступлениях и/или в крупных масштабах.

ACN определяет модульную сетевую архитектуру, включающую в себя два сетевых протокола, язык для описания устройств (Device Description Language, DDL) и профили для взаимодействия (E1.17 Profiles for Interoperability). Набор протоколов ACN изначально был разработан для работы поверх UDP/IP, поэтому он будет также работать в сетях IP, Ethernet и 802.11 (Wi-Fi).

Благодаря модульности ACN легко расширяется. Одно из расширений, ANSI E1.31, также известное как Streaming ACN (sACN), используется для отправки DMX-данных через ACN-совместимые сети. В сравнении с Art-Net sACN поддерживает до 65535 DMX-областей.

Заключение


Методы создания световых шоу значительно эволюционировали с момента их появления. В аналоговую эпоху не было единого стандарта, но относительная совместимость интерфейсов смягчала проблему. С переходом на цифру появилось множество несовместимых проприетарных протоколов, которые были успешно вытеснены стандартизированным DMX512. На данный момент наблюдается переход DMX в среду Ethernet в виде двух конкурирующих протоколов E1.31 и Art-Net. Кто выйдет победителем покажет время.

Подробнее..

Конвергенция Wi-Fi и IoT для современных кампусных сетей

29.12.2020 20:14:34 | Автор: admin
Привет, Хабр! Сегодня мы предлагаем поговорить не столько о продуктах и технологиях Huawei, сколько о гибридных решениях, которые строятся на базе точек доступа Wi-Fi и устройств интернета вещей.



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



Если ещё пять-семь лет назад концепция интернета вещей казалась далёкой от практического применения, сейчас IoT вовсю внедряют в корпоративные сети и городскую инфраструктуру. К примеру, в Москве как раз в наши дни реализуется колоссальный проект по создания системы умного освещения, в которой включение и выключение каждого светильника производится дистанционно сигналом через сеть 5G. Не оставлен в стороне и транспорт: автобусы или такси удобно снабдить множеством датчиков, позволяющих не только отслеживать параметры самих транспортных средств, но и собирать статистику, например, по загруженности дорог.

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

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



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

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

Помочь заказчикам, испытывающим потребность в развёртывании и сетей беспроводного доступа Wi-Fi, и сетей IoT, призвана конвергентная архитектура. Она основана на применении точек доступа Huawei, допускающих расширение функциональности с помощью дополнительных аппаратных элементов. В такой точке доступа имеется отдельный слот, куда при необходимости вставляется стандартизированный IoT-модуль, например Zigbee или сканер меток RFID. Существуют и такие точки доступа, которые уже в базовой комплектации включают в себя миниатюрный Bluetooth-маяк. Эта дополнительная функциональность позволяет точке доступа не только работать по прямому назначению раздавать Wi-Fi в диапазонах 2,4 и 5 ГГц, но и собирать информацию, общаясь с IoT-устройствами (смартфонами, носимыми метками, электронными ценниками, терминалами съёма данных и пр.).

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



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

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

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



Системы внутреннего позиционирования и навигации


Архитектура подобных IoT-систем состоит из нескольких уровней. На нижнем располагаются терминалы, смартфоны, ноутбуки, активные или пассивные метки (RFID, BLE и пр.). Выше находятся точка доступа Wi-Fi со встроенным модулем IoT, кампусная сеть и контроллер доступа. Венчает пирамиду управляющее всей системой программное обеспечение. В решениях внутренней навигации, к примеру, в роли такого ПО выступает специальная платформа отслеживания, которая связана с мобильным приложением, установленным на смартфоне сотрудника или клиента.

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



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



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

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



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

Если прикладная задача требует погрешности определения координат цели на уровне не более 3 м, рациональнее будет построить систему позиционирования с использованием установленного в точке доступа Bluetooth-маячка.



Системы управления активами


Перейдём к следующей прикладной задаче, которая решается с помощью интернета вещей и конвергентных систем Wi-Fi + IoT.

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

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

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



Чем здесь будет полезна конвергентная система Wi-Fi + IoT? Решение, построенное на основе точек доступа Huawei с установленными в них IoT-модулями, умеет собирать данные с активных и пассивных меток, размещённых на оборудовании. Метки контроля тока, например, помогают понять реальный статус использования активов по потреблению ими электричества. Метка позиционирования позволяет в реальном времени контролировать местонахождение интересующих нас устройств. А благодаря ручному считывателю RFID-меток можно отказаться от бумажных стикеров с номерами и проводить инвентаризацию, просто пронося сканер мимо промаркированных объектов на определённом расстоянии. Данные с метки поступают в терминал, который отправляет их в сеть Wi-Fi и далее к системам вышестоящего уровня.

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



Рассмотрим частный случай системы контроля ценных активов, которая построена на основе активных меток. Такая метка постоянно сообщает свой статус IoT-модулю в точке доступа Wi-Fi. Соответственно, отчёт о наличии и использовании того или иного актива в конкретной локации можно получить мгновенно в режиме онлайн. Как следствие, серьёзно сокращаются и трудозатраты в сравнении с инвентаризацией по классике.

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



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



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



Системы электронных ценников


С каждым годом добавляется прикладных задач, решение которых может быть основано на связке Wi-Fi + IoT. Так, наши клиенты и заказчики всё больше интереса проявляют к внедрению систем электронных ценников в розничной торговле.

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

Решение, конечно, есть. В уже развёрнутой современной сети Wi-Fi магазина в точки доступа Huawei устанавливаются модули управления электронными ценниками. Оператору магазина остаётся только разместить в торговом зале миниатюрные ESL ценники на основе цветной или монохромной электронной бумаги. Они несут информацию о цене, могут менять свой цвет (например, чтобы выделить скидочные товары), оборудованы светодиодной системой привлечения внимания, но, главное, все они управляются централизованно. Так что, когда потребуется оперативно изменить ценники в огромной торговой сети, достаточно будет поменять одно число в ERP-системе предприятия.



С точки зрения архитектуры решение довольно простое. На нижнем уровне находятся сами электронные ценники, которые обмениваются данными с расположенной уровнем выше точкой доступа Wi-Fi, снабжённой IoT-модулем. Ещё выше корпоративная сеть и контроллер, управляющий сетевыми устройствами. Параллельно с ним работает система управления ESL. На самом верху функционирует ERP-система торговой сети, формирующая запросы на изменение цен.

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

Главные технологии корпоративных ADN-сетей в исполнении Huawei начало

18.01.2021 16:06:50 | Автор: admin
В 2021 году Huawei делает ставку на дальнейшее развитие корпоративных ADN-сетей. Что это за зверь, коротко обрисуем в этой статье по итогам доклада с прошедшего в конце 2020 года онлайн-форума Worldwide IP Club сообщества, которое мы создали для обсуждения инноваций и для нетворкинга в телекоме.



Чтобы разобраться с Huawei Enterprise ADN, полезно будет сперва сделать краткий экскурс в те вызовы, с которыми сталкиваются корпоративные сети в наши дни.



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

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

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

I. Разрозненность ресурсных ёмкостей (network silos), из-за которой сервисы оказываются отъединены от сетевой инфраструктуры, возникает неразбериха с чересчур многочисленными сетевыми задачами, конфигурация самой сети переусложняется, а O&M теряет эффективность.

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

III. Разделённость сервисов бизнес-уровня и сетевой инфраструктуры. В результате невозможно полноценное функционирование NaaS (Network as a Service) ни в отдельной зоне, ни между зонами сети. Под шквалом бесчисленных метрик сетевой активности, предупреждений и логов администратор оказывается не в состоянии гарантировать в любой момент времени безукоризненно точную работу сервисов.

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



Чтобы справляться с перечисленными проблемами, Huawei создала решение на основе концепции сети с автономным управлением (autonomous driving network ADN), именуемое iMaster NCE. В него заложена функциональность цифрового двойника, end-to-end анализа намерений (более подробно о концепции intent-driven network мы уже писали на Хабре), а также технология интеллектуального принятия решений.

  • Принцип intent-driven. На протяжении всего жизненного цикла сети те, кто ею управляет, могут использовать простой WYSIWYG-инструментарий для того, чтобы держать её под полным своим контролем.
  • Интеллектуальное принятие решений. Система упрощает человеку выбор оптимальных решений. Например, на этапе развёртывания сервиса она способна подсказать подходящие сетевые настройки и конфигурации, а при анализе проблем даёт возможность быстро найти первопричину неполадки и сама предлагает шаги по её устранению.
  • Цифровой двойник. В iMaster NCE включена функциональность многоуровневого моделирования и управления KPI инфраструктуры с опорой на большие данные, которая оперирует виртуальными слепками любых физических устройств, входящих в состав сети. При этом решение осуществляет двунаправленное картирование между сетью и её двойником.


С помощью ADN, таким образом, удаётся осуществить пять важных преобразований.

  1. Упразднить сетецентричный, пассивный подход к управлению инфраструктурой и заменить его таким, при котором проактивно анализируются намерения её пользователей, благодаря чему, в частности, удаётся нивелировать зависимость от специфики конкретной реализации сети. iMaster NCE развёртывает сквозную автономную оптимизацию сети по замкнутому циклу.
  2. Отказаться от автоматизации частичной, на базе жёстких предварительных настроек, в пользу автоматизации гибкой, завязанной на многоуровневом моделировании. В результате от и до автоматизируются проектирование и построение сети, O&M-процессы и дальнейшее совершенствование инфраструктуры.
  3. Перейти от ручных проверок к поддержанию устойчивой работоспособности сервисов с помощью интеллектуальных технологий. Модель в числе прочего предусматривает симуляцию последствий события до того, как оно произойдёт в действительности, равно как и окончательное подтверждение действий постфактум, с возможностью откатить изменения.
  4. Сделать шаг от реактивного управления сетью к интеллектуальному проактивному мониторингу и анализу изменений. Администраторы сети видят проблему в зачатке ещё до того, как она повлияет на тот или иной сервис и её заметят пользователи, и могут оперативно разобраться с ней.
  5. Заменить работу с опорой на человеческий фактор, преимущественно на опыт экспертов, применением модели, где преобладает принятие решений с помощью умных технологий, в том числе при проектировании сети, мониторинге, анализе и оптимизации сетевых взаимодействий




Главное же в модели анализа намерений (intent-driven) перевод бизнес-запросов пользователей на сетевой уровень. У процесса выделяются три значимые составляющие.

  1. Формирование отвлечённой модели намерений (intent abstraction). В корпоративных сетях большая часть намерений относится к взаимодействиям между пользователями, конечными устройствами и приложениями. Как следствие, необходима модель, которая будет обобщать их требования на протяжении всего жизненного цикла сети и обеспечивать их кастомизацию, основанную на сценарном подходе.
  2. Преобразование намерений (intent conversion). Высокоуровневые бизнес-намерения необходимо спроецировать на сетевой уровень и в конечном счёте конвертировать в прикладные рекомендации. Эта трансформация достигается за счёт двух технологий.
    • Умные рекомендации, основанные на алгоритмах моделирования, с учётом топологии сети и её ресурсов, поведенческих моделей, предпочтительных политик и пр., и адаптационном движке, который включает в себя механизм поиска решений (solver), компилятор и граф знаний.
    • Онлайн-проектирование на основе концепции цифрового двойника. Платформа не только предлагает решение, но и предоставляет для его проверки и обкатки песочницу с наглядной симуляцией, которая позволяет довести это решение до ума.
  3. Не зависящее от вендоров хранилище сетевых моделей. Это базис для работы с намерениями и автоматизации сетевой инфраструктуры. Сюда входят:
    • модели автоматизации корпоративной сети;
    • вендор-независимые модели абстрактного описания сетевых элементов;
    • сторонние модели (SDN, OVS и др.);
    • модели, задаваемые пользователями.




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

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

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

Бегло пройдёмся по базовым сценариям применения метода.

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


Вкратце сетевой анализ осуществляется в такой последовательности.

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




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

Пара примеров того, как это работает. Допустим, из какого-то бизнес-подразделения компании поступает сигнал о том, что у них отвалился доступ к приложению. Платформа iMaster NCE, прежде всего благодаря динамическому моделированию топологии сети, позволяет легко запросить и изучить в наглядном представлении все метрики, касающиеся приложения. Также благодаря навигатору маршрутизации удобно проследить на всех уровнях сети, откуда и куда шёл и идёт трафик, по принципу end-to-end вплоть до конкретного физического устройства, например смартфона (проверяется досягаемость участков и элементов сети, петли и чёрные дыры маршрутизации и т. д.). В свою очередь, благодаря комплексной визуализации работы аналитического инструментария можно оперативно проверять, в порядке ли записи по конкретным устройствам в таблицах маршрутизации, а также мониторить уведомления, логи и записи об изменениях конфигурации. А с помощью рекомендованного службой RunBook решения (разумеется, администратор волен предпочесть поступить так, как сочтёт нужным) при необходимости быстро восстанавливается работоспособность составных частей сети и сервисов и устраняются неисправности в ней.

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

  • стабильно ли функционирует оборудование в порядке ли платы, вентиляторы, блоки питания, процессоры, память и т. д.;
  • нет ли проблем в соединениях между входящими в сеть физическими устройствами, в том числе в норме ли статусы портов и трафик, длина очередей и коэффициент оптического затухания, не слишком ли велик процент битых пакетов и пр.;
  • работают ли агрегация M-LAG, маршрутизация посредством OSPF, BGP и др.;
  • всё ли хорошо с наложенной сетевой инфраструктурой, включая текущие статусы BD, VNI, VRF, EVPN и SRV6;
  • штатно ли осуществляется переадресация на уровне сервисов, и в частности каковы настройка TCP-соединения.


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

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



Работа умного мониторинга подкрепляется использованием интеллектуального метода анализа сетевой ситуации, основанного на графах знаний.

За счёт моделирования абстрактное описание сетевых элементов может быть преобразовано в конкретные запросы в плоскости объектной модели.

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

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



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

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

  1. Синергия между облачными ресурсам и тем, что находится во внутреннем контуре организации: мы располагаем единой моделью знаний о сетевых взаимодействиях и стандартами, которые позволяют передавать эти знания и данные между on-premise и cloud-частью гибридной инфраструктуры и далее совершенствовать ML-алгоритмы, на которых основан iMaster NCE.
  2. Анализ осуществимости решений. Многомерное дерево решений помогает подбирать максимально целесообразные альтернативные решения.
  3. Анализ влияния. Платформа умеет с высокой точностью прогнозировать результаты, которые способно повлечь за собой принятие тех или иных рекомендаций, применительно к сети в целом и к отдельным сервисам.
  4. Моделирование решений. Система подсказывает администратору оптимальный способ устранения неисправности.


***


Инженеры Huawei продолжают совершенствовать ADN-решения, чтобы повышать степень самостоятельности сетевой инфраструктуры и её способности к самовосстановлению, и мы непременно будем писать о новых разработках в этом направлении. А ознакомиться с решением iMaster NCE-Fabric вживую можно в нашем демооблаке с помощью пресейл-инженеров Huawei.
Подробнее..

Трансиверы для Marea передача данных между континентами достигла рекордных 30 Тбитc на пару волокон

18.01.2021 16:06:50 | Автор: admin
Оптический кабель Marea

Межконтинентальный подводный кабель связи Marea один из самых быстрых на сегодняшний день установил новый рекорд. Скорость передачи данных по оптоволокну, проложенному по дну Атлантического океана, составила 30 Tбит/с. Все благодаря новому поколению трансиверов Infinera Infinite Capacity Engine 6 (ICE6). Считается, что полностью свой потенциал Marea раскроет к 2025 году.

Залечь на дно Атлантики


Трансконтинентальный кабель стал выдающимся с самого начала. Обычно на прокладку подобных магистралей уходит около 5 лет. Проект Marea, ставший результатом союза Microsoft, Facebook и телекоммуникационной компании Telxius, был реализован за два года.

Магистраль состоит из восьми пар оптоволоконных кабелей, защищенных слоями меди, жесткого пластика и водонепроницаемым покрытием. По две пары используют Microsoft и Facebook. Одна пара была приобретена AWS в 2019 году. Остальные находятся в распоряжении провайдера Telxius для аренды более мелких компаний, которые не могут себе позволить целый кабель.

Длина Marea 6600 км, средняя глубина пролегания составляет 3,35 км. Магистраль соединяет американский и европейский континенты, начинаясь на побережье города Вирджиния-Бич (США) и заканчиваясь в Бильбао (Испания). Общий вес кабеля превышает 4500 тонн, что сравнимо с весом 34 голубых китов. При этом диаметр кабеля всего в 1,5 раза больше, чем у обычного садового шланга.

Скрученный кабель Marea

По оценке Microsoft, скорость передачи данных по кабелю Marea в 16 млн раз выше в сравнении со среднестатистическим домашним интернетом. На старте пропускная способность магистрали оценивалась в 160 Тбит/c (к слову, с такой скоростью можно одновременно транслировать 71 млн видео в HD-разрешении). Но уже спустя год после ввода кабеля в эксплуатацию, в 2018 году, цифра выросла до 200 Тбит/с. А еще годом позже скорость передачи данных в пересчете на пару волокон достигла 26,2 Тбит/с. Рост произошел за счет новых на тот момент трансиверов Infinera Infinite Capacity Engine 4 (ICE4).

Новый зафиксированный рекорд также стал возможен благодаря развитию линейки трансиверов. С новым ICE6 пропускная способность пары волокон Marea составила 30 Тбит/с.

Предельная цифра линейных скорость трансивера ICE6 составляет 800 Гбит/с в каждом направлении. Сейчас рекордный показатель Marea достигает до 700 Гбит/с на линк, что достаточно близко к максимуму. Новый ICE6 также удешевит и упростит пользование магистралью за счет сокращения модулей в береговых трансиверных станциях до 60%.

Трансконтинентальные связи


На сегодняшний день континенты связывают более 1,2 млн км подводных оптоволоконных кабелей. Этой длины достаточно, чтобы опоясать нашу планету по экватору около 30 раз! Первый подводный интернет-кабель был проложен в 1988 году.

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

Схема проложенных оптоволоконных связей

Так, тот же Google заявил о намерении проложить кабель, который соединит США, Великобританию и Испанию. Магистраль будет носить имя Грейс Хоппер в честь известной ученой и программистки. По словам компании, кабель будет использовать новейшую технологию для передачи сигнала, но подробности Google пока не раскрывает. В планах закончить проект к 2022 году.

Facebook же воссоединяется не только с Евразией. В мае прошлого года соцсеть заявила о желании проложить 37-километровый кабель, чтобы предоставить доступ к интернету в 16 странах Африки (1,3 млрд жителей континента). Прокладкой кабеля займется компания Alcatel Submarine Networks, которой владеет Nokia. Скоростью не обидят: скорость связи обещает быть в три раза выше, чем у существующих подводных кабелей до Африки. Даешь быстрый Instagram для Африки!

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


Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru