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

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

Процедура обновления Check Point с R80.20R80.30 до R80.40

04.09.2020 10:14:53 | Автор: admin

Более двух лет назад мы писали о том, что перед каждым администратором Check Point рано или поздно встает вопрос обновления на новую версию. В данной статье было описано обновление с версии R77.30 до R80.10. К слову, в январе 2020-го R77.30 стала сертифицированной версией ФСТЭК. Однако за 2 года в Check Point многое изменилось. В статье Check Point Gaia R80.40. Что будет нового? описаны все нововведения, коих много. В данной статье процедура обновления будет описана максимально подробно.

Как известно, существует 2 варианта внедрения Check Point: Standalone и Distributed, то есть без выделенного сервера управления и с выделенным. Вариант Distributed является крайне рекомендованным по нескольким причинам:

  • минимизируется нагрузка на ресурсы шлюза;

  • можно не планировать окно для обслуживания, чтобы провести работы с сервером управления;

  • адекватная работа SmartEvent, так как в Standalone варианте едва ли он будет работать;

  • кластер из шлюзов крайне рекомендуется строить в Distributed конфигурацией.

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

Обновление Security Management Server (SMS)

Существует 2 способа обновления SMS:

  • с помощью CPUSE (через Gaia Portal)

  • с помощью Migration Tools (требуется чистая установка - fresh install)

Обновление с помощью CPUSE не рекомендуется коллегами из Check Point, так как у вас не обновится версия файловой системы и ядро. Однако данный способ не требует миграции политик и является намного более быстрым и простым, нежели второй способ.

Чистая установка и миграция политик с помощью Migration Tools - вот рекомендуемый метод. Помимо новых файловой системы и ядра ОС часто бывает, что база данных SMS засоряется, и чистая установка в этом плане - отличный выход, чтобы добавить скорости работы серверу.

1) Первым шагом при любом обновлении является создание бэкапов и снэпшотов. Если у вас имеется физический сервер управления, то бэкап следует сделать из веб-интерфейса Gaia Portal. Зайдите во вкладку Maintenance > System Backup > Backup. Далее вы указываете место сохранения бэкапа. Это может быть SCP, FTP, TFTP сервер или же локально на устройстве, однако тогда придется позже это бэкап скинуть на сервер или компьютер.

Рисунок 1. Создание бэкапа в Gaia PortalРисунок 1. Создание бэкапа в Gaia Portal

2) Далее следует сделать снэпшот во вкладке Maintenance > Snapshot Management > New. Отличия бэкапов от снэпшотов заключается в том, что снэпшоты хранят в себе больше информации, в том числе все установленные хотфиксы. Тем не менее, лучше сделать и то, и то.

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

Рисунок 2. Создание снэпшота в Gaia PortalРисунок 2. Создание снэпшота в Gaia Portal

3) Сохранить конфигурацию устройства из Gaia Portal. Можно заскриншнотить все вкладки настроек, которые есть в Gaia Portal, либо же из Clish ввести команду save configuration <filename>. Далее следует файл с помощью WinSCP или другого клиента забрать к себе на ПК.

Рисунок 3. Сохранение конфигурации в текстовый файл)Рисунок 3. Сохранение конфигурации в текстовый файл)

Примечание: если WinSCP не дает подключиться, смените пользователю shell на /bin/bash либо в веб-интерфейсе во вкладке Users, либо введя команду chsh s /bin/bash <username>.

Обновление с помощью CPUSE

4) Первые 3 шага являются обязательными для любого варианта обновления. Если же вы решили пойти по более простому пути обновления, то в веб-интерфейсе перейдите во вкладку Upgrades (CPUSE) > Status and Actions > Major Versions > Check Point R80.40 Gaia Fresh Install and Upgrade. Нажмите правой клавишей мыши на данное обновление и выберите Verifier. Запуститься процесс проверки на несколько минут, по истечении которых вы увидите сообщение, что устройство может быть обновлено. Если вы видите ошибки, их необходимо исправить.

Рисунок 4. Обновление через CPUSEРисунок 4. Обновление через CPUSE

5) Обновите до последней версии CDT (Central Deployment Tool) - утилиту, которая запущена на сервере управления и позволяет устанавливать обновления, пакеты обновлений, управлять бэкапами, снэпшотами, скриптами и многим другим. Неактуальная версия CDT может привести к проблемам в обновлении. Скачать CDT можно по ссылке.

6) Поместив скачанный архив на SMS в любую директорию через WinSCP, подключитесь по SSH к SMS и зайдите в экспертный режим. Напомню, что пользователь WinSCP должен иметь shell /bin/bash!

7) Введите команды:

cd /somepathtoCDT/

tar -zxvf <NameofCDTPackage>.tgz

rpm -Uhv --force CPcdt-00-00.i386.rpm

Рисунок 5. Установка Central Deployment Tool (CDT)Рисунок 5. Установка Central Deployment Tool (CDT)

8) Следующим шагом является установка образа R80.40. Правой клавишей мыши на обновление Download, затем Install. Имейте в виду, что обновление занимает минут 20-30, и сервер управления будет недоступен какое-то время. Следовательно, имеет смысл согласовать окно для обслуживания.

9) Все лицензии и политики безопасности сохраняются, поэтому далее вам следует скачать новую SmartConsole R80.40.

10) Подключитесь к SMS новой SmartConsole и установите политики безопасности. Кнопка Install Policy в левом верхнем углу.

11) Ваш SMS обновлён, далее следует установить самый последний хотфикс. Во вкладке Upgrades (CPUSE) > Status and Actions > Hotfixes нажмите на правую клавишу мыши Verifier, затем Install Update. Устройство само уйдет в перезагрузку после установки обновления.

Рисунок 6. Установка последнего хотфикса через CPUSEРисунок 6. Установка последнего хотфикса через CPUSE
Обновление с помощью Migration Tools

4) Для начала следует так же обновить до последней версии CDT - пункты 5, 6, 7 из раздела Обновление с помощью CPUSE.

5) Установите пакет Migration Tools необходимый для миграции политик с сервера управления. По данной ссылке можно найти Migration Tools для версий: R80.20, R80.20 M1, R80.20 M2, R80.30, R80.40. Скачивать следует Migration Tools той версии, на которую вы хотите обновиться, а не той, которая у вас сейчас! В нашем случае это R80.40.

6) Далее в веб-интерфейсе SMS идем во вкладку Upgrades (CPUSE) > Status and Actions > Import Package > Browse > Выбираем скачанный файл > Import.

Рисунок 7. Импорт Migration ToolsРисунок 7. Импорт Migration Tools

7) Из экспертного режима на SMS проверьте, что пакет Migration Tools установлен с помощью команды (вывод команды должен совпадать с числом в названии архива Migration Tools):

cpprod_util CPPROD_GetValue CPupgrade-tools-R80.40 BuildNumber 1

Рисунок 8. Проверка установки Migration ToolsРисунок 8. Проверка установки Migration Tools

8) Перейдите в папку $FWDIR/scripts на сервере управления:

cd $FWDIR/scripts

9) Запустите pre-upgrade verifier (проверочный скрипт) с помощью команды (если есть ошибки, исправьте их перед дальнейшими шагами):

./migrate_server verify -v R80.40

Примечание: если видите ошибку Failed to retrieve Upgrade Tools package, но вы проверили, что архив успешно импортирован (см. пункт 4), используйте команду:

./migrate_server verify -v R80.40 -skip_upgrade_tools_check

Рисунок 9. Запуск скрипта проверкиРисунок 9. Запуск скрипта проверки

10) Экспортируйте политики безопасности с помощью команды:

./migrate_server export -v R80.40 /<Full Path>/<Name of Exported File>.tgz

Рисунок 10. Экспорт политики безопасностиРисунок 10. Экспорт политики безопасности

Примечание: если видите ошибку Failed to retrieve Upgrade Tools package, но вы проверили, что архив успешно импортирован (пункт 7), используйте команду:

./migrate_server export -skip_upgrade_tools_check -v R80.40 /<Full Path>/<Name of Exported File>.tgz

11) Посчитайте MD5 хэш-сумму и сохраните себе вывод команды:

md5sum /<Full Path>/<Name of Exported File>.tgz

Рисунок 11. Высчитывание MD5 хэш-суммыРисунок 11. Высчитывание MD5 хэш-суммы

12) С помощью WinSCP переместите данный файл к себе на компьютер.

13) Введите команду df -h и сохраните себе процентное соотношение директорий, исходя из занимаемого места.

Рисунок 12. Процентное соотношение директорий на SMSРисунок 12. Процентное соотношение директорий на SMS

14.1) В случае, если у вас реальный SMS

14.1.1) С помощью Isomorphic Tool создается загрузочная USB флешка с образом Gaia R80.40.

14.1.2) Рекомендую подготовить минимум 2 загрузочные флешки, так как бывает, что не всегда читается флешка.

14.1.3) От имени администратора на компьютере запустите ISOmorphic.exe. В пункте 1 выбираете скачанный образ Gaia R80.40, в пункте 4 флешку. Пункты 2 и 3 изменять не надо!

Рисунок 13. Создание загрузочной флешкиРисунок 13. Создание загрузочной флешки

14.1.4) Выбираете пункт Install automatically without confirmation и важно указать модель вашего сервера управления. В случае с SMS следует выбрать 3 или 4 строка.

Рисунок 14. Выбор модели устройства для создания загрузочной флешкиРисунок 14. Выбор модели устройства для создания загрузочной флешки

14.1.5) Далее вы выключаете аплайнс, вставляете флешку в USB порт, подключаетесь консольным кабелем через COM порт к устройству и включаете SMS. Процесс установки происходит сам собой. IP-адрес по умолчанию - 192.168.1.1/24, а данные для входа admin / admin.

14.1.6) Следующим шагом следует подключение к веб интерфейсу на Gaia Portal (адрес по умолчанию https://192.168.1.1), где вы проходите инициализацию устройства. Во время инициализации вы в основном нажимаете Next, ибо почти все настройки можно поменять в будущем. Однако вы можете изменить сразу IP-адрес, настройки DNS и hostname.

14.2) В случае, если у вас виртуальный SMS

14.2.1) Ни в коем случае не следует удалять старый SMS, создайте новую виртуальную машину с такими же ресурсами (CPU, RAM, HDD) с тем же IP-адресом. Кстати, RAM и HDD можете добавить, так как версия R80.40 чуть более требовательна. Дабы не было конфликта IP-адресов, выключите старый SMS и начните установку нового.

14.2.2) Во время установки Gaia настройте актуальный IP-адрес и выделите под директорию /root адекватное количество места. Процентное соотношение директорий у вас должно примерно сохраниться, используйте вывод df -h.

15) На моменте выбора типа установки Installation Type выбирайте первый вариант, так как, скорее всего, у вас не MDS (Multi-Domain Server). Если MDS, то значит вы управляли многими доменами из под разных сущностей SMS одновременно. Выбирать в это случае следует второй пункт.

Рисунок 15.Выбор типа установки GaiaРисунок 15.Выбор типа установки Gaia

16) Самый важный момент, который нельзя исправить без переустановки - выбор сущности. Следует выбрать Security Management и нажать Next. Далее все по умолчанию.

Рисунок 16. Выбор типа сущности при установке GaiaРисунок 16. Выбор типа сущности при установке Gaia

17) Как только устройство перезагрузится, подключитесь к веб интерфейсу по https://192.168.1.1 или другому IP-адресу, если вы меняли его.

18)Перенесите настройки из скриншотов во все вкладки Gaia Portal, в которых что-то было настроено или же из clish выполните команду load configuration <filename>.txt. Данный файл конфига следует предварительно закинуть на SMS.

Примечание: ввиду того, что ОС новая, WinSCP не даст подключиться под админом, смените пользователю shell на /bin/bash либо в веб-интерфейсе во вкладке Users, либо введя команду chsh s /bin/bash <username> или создайте нового пользователя.

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

md5sum /<Full Path>/<Name of Exported File>.tgz

20) Повторите пункт 6 и установите Upgrade Tools на новый SMS в Gaia Portal во вкладке Upgrades (CPUSE) > Status and Actions.

21) Введите команду в экспертном режиме:

./migrate_server import -v R80.40 -skip_upgrade_tools_check /<Full Path>/<Name of Exported File>.tgz

Рисунок 17. Импорт политики безопасности на новый SMSРисунок 17. Импорт политики безопасности на новый SMS

22) Включите сервисы командой cpstart.

23) Скачайте новую SmartConsole R80.40 и подключитесь к серверу управления. Зайдите в Menu > Manage Licenses and Packages (SmartUpdate) и проверьте, что у вас сохранилась лицензия.

Рисунок 18. Проверка установленных лицензийРисунок 18. Проверка установленных лицензий

24) Установите политику безопасности на шлюз или кластер - Install Policy.

Обновление Security Gateway (SG)

Шлюз безопасности можно обновить через CPUSE, так же как и сервер управления, или установить заново - fresh install. Из моей практики в 99% случаев все заново устанавливают Security Gateway ввиду того, что это занимает практически столько же времени, как и обновление через CPUSE, однако вы получаете чистую обновленную ОС без багов.

По аналогии с SMS сперва требуется создать бэкап и снэпшот, а также сохранить настройки из Gaia Portal. Обратитесь к пунктам 1, 2 и 3 в разделе "Обновление Security Management Server".

Обновление с помощью CPUSE

Обновление Security Gateway через CPUSE происходит точно так же, как и обновление Security Management Server, поэтому, обратитесь в начало статьи.

Важный момент: обновление SG требует перезагрузки! Поэтому проводите обновление в окно для обслуживания. Если у вас кластер, обновите сначала пассивную ноду, затем переключите роли и обновите другую ноду. В случае с кластером окна для обслуживания можно избежать.

Установка новой версии ОС на Security Gateway

1.1) В случае, если у вас реальный SG

1.1.1) С помощью Isomorphic Tool создается загрузочная USB флешка с образом Gaia R80.40. Образ тот же самый, что и на SMS, однако немного иначе выглядит процедура создания загрузочной флешки.

1.1.2) Рекомендую подготовить минимум 2 загрузочные флешки, так как бывает, что не всегда читается флешка.

1.1.3) От имени администратора на компьютере запустите ISOmorphic.exe. В пункте 1 выбираете скачанный образ Gaia R80.40, в пункте 4 флешку. Пункты 2 и 3 изменять не надо!

Рисунок 19. Создание загрузочной флешкиРисунок 19. Создание загрузочной флешки

1.1.4) Выбираете пункт Install automatically without confirmation, и важно указать модель вашего Security Gateway - строки 2 или 3. Если это физическая песочница (SandBlast Appliance), то выбираем строку 5.

Рисунок 20. Выбор модели устройства для создания загрузочной флешкиРисунок 20. Выбор модели устройства для создания загрузочной флешки

1.1.5) Далее вы выключаете аплайнс, вставляете флешку в USB порт, подключаетесь консольным кабелем через COM порт к устройству и включаете шлюз. Процесс установки происходит сам собой. IP-адрес по умолчанию - 192.168.1.1/24, а данные для входа admin / admin. Сперва следует обновлять пассивную ноду, затем установить на нее политику, переключить роли и потом обновить другую ноду. Скорее всего, понадобится окно для обслуживания.

1.1.6) Следующим шагом следует подключение к веб интерфейсу на Gaia Portal, где вы проходите первую инициализацию устройства. Во время инициализации вы в основном нажимаете Next, ибо почти все настройки можно поменять в будущем. Однако вы можете изменить сразу IP-адрес, настройки DNS и hostname.

1.2) В случае, если у вас виртуальный SG

1.2.1) Создайте новую виртуальную машину с такими же ресурсами (CPU, RAM, HDD) или больше, так как версия R80.40 чуть более требовательна. Дабы не было конфликта IP-адресов выключите старый шлюз и начните установку нового с тем же IP-адресом. Старый SG можно спокойно удалить, так как ничего ценного на нем нет, ибо все самое главное - политика безопасности - находится на сервере управления.

1.2.2) Во время установки ОС настройте актуальный IP-адрес и выделите под директорию /root адекватное количество места.

3) Подключитесь по HTTPS порту к шлюзу и начните процесс инициализации. На моменте выбора типа установки Installation Type выберите первый вариант - Security Gateway and/or Security Management.

Рисунок 21. Выбор типа установки GaiaРисунок 21. Выбор типа установки Gaia

4) Важнейший момент - выбор сущности (Products). Следует выбрать Security Gateway и, если у вас кластер, поставить галочку Unit is a part of a cluster, type: ClusterXL. Если у вас кластер VRRP, то выберите такой тип, но это маловероятно.

Рисунок 22. Выбор типа сущности при установке GaiaРисунок 22. Выбор типа сущности при установке Gaia

5)В следующем шаге задайте одноразовый пароль SIC для установления доверия с сервером управления. С помощью этого пароля генерируется сертификат, и по шифрованному каналу взаимодействия сервер управления будет общаться со шлюзом. Галочку Connect to your Management as a Service следует ставить, если сервер управления находится в облаке. Мы буквально недавно написали об этом статью и о том, насколько удобен и прост облачный менеджмент сервер.

Рисунок 23. Создание SIC Рисунок 23. Создание SIC

6) Начните процесс инициализации на следующей вкладке. Как только устройство перезагрузится, подключитесь к веб интерфейсу и перенесите настройки из скриншотов во все вкладки Gaia Portal, в которых что-то было настроено или же из clish выполните команду load configuration <filename>.txt. Данный файл конфига следует предварительно закинуть на шлюз безопасности.

Примечание: ввиду того, что ОС новая, WinSCP не даст подключиться под админом, смените пользователю shell на /bin/bash либо в веб-интерфейсе во вкладке Users, либо введя команду chsh s /bin/bash <username> или создайте нового пользователя с таким shell.

7) Откройте SmartConsole R80.40 и зайдите в объект шлюза безопасности, который вы только что переустановили. Откройте вкладку General Properties > Communication > Reset SIC и введите пароль, заданный в пункте 5.

Рисунок 24. Установка доверия с новым шлюзом безопасностиРисунок 24. Установка доверия с новым шлюзом безопасности

8) Версия Gaia у объекта должна смениться, если не изменится, то поменяйте ее руками. Затем установите политику на шлюз.

9) В Gaia Portal зайдите во вкладку Upgrades (CPUSE) > Status and Actions > Hotfixes и установите последний хотфикс. Устройство уйдет в перезагрузку во время установки!

10) В случае кластера, смените роли нод и проделайте те же шаги для другой ноды.

Заключение

Я постарался сделать максимально понятный и всеобъемлющий гайд по обновлению с версии R80.20/R80.30 до актуальной на данный момент R80.40, так как многое изменилось. Версия Gaia R81 уже появилась в демо режиме, однако процедура обновления более или менее остается идентична. Руководствуясь официальным гайдом от Check Point, вы и сами сможете разобраться во всех тонкостях.

По всем вопросам вы можете обращаться к нам. Мы будем рады помочь с самыми сложными обновлениями и кейсами в рамках нашей технической поддержки CPSupport. Также на нашем сайте есть возможность заказать аудит настроек Check Point или оставить бесплатную заявку на технический кейс.

Большая подборка материалов по Check Point от TS Solution. Следите за обновлениями (Telegram, Facebook, VK, TS Solution Blog, Яндекс.Дзен).

Подробнее..

2. Group-IB. Комплексная защита сети. TDS Sensor

10.09.2020 10:11:09 | Автор: admin


Добрый день, коллеги! Продолжаем цикл статей, посвященный решениям информационной безопасности от компании Group-IB. В предыдущей статье мы кратко осветили комплексное решение для защиты от сложных киберугроз от компании Group-IB. Данная публикация будет посвящена модулю Threat Detection System (TDS) Sensor. Напомним, что TDS Sensor модуль для глубокого анализа сетевого трафика и выявления угроз на сетевом уровне, а также для интеграции с различными подсистемами, входящий в программный комплекс TDS. В данной статье рассмотрим продукт с точки зрения функциональной части и архитектуры внедрения.

TDS Sensor



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

Так как TDS Sensor это решение класса anti-APT, оно заточено под обнаружение целевых атак и сетевых аномалий. Это не решения класса IPS, оно не предназначено под обнаружение сканирования портов, обнаружение брутфорса или попытки SQL injection. Организациям, которым требуются защита от целевых атак уже необходимо обладать внутри своей инфраструктуры IPS/IDS решениями. Отличительной особенностью решений класса anti-APT является обнаружение попыток передачи каких-то данных во вне периметра, коммуникации с командными центрами злоумышленников (Command & Control, CnC), передачи вредоносных файлов. Поэтому сигнатуры разработаны именно под этот специфический трафик. Рассмотрим примерную схему целевой атаки, для большей ясности.

APT-атака




Схема APT атаки:

  1. Злоумышленник собирает данные относительно организации и ее сотрудниках, в которую хочет проникнуть. Чаще всего используются методы социальной инженерии и данные из различных открытых и закрытых интернет источников;
  2. Далее злодей находит конкретного сотрудника, которому отправляет письмо с вредоносным файлом. Либо загружает все тот же вредоносный файл на сервер через взлом различных контрагентов, получая доступ к файловому хранилищу. Чтобы обойти системы защиты, злоумышленники комбинируют способы проникновения загружают зашифрованный архив, а пароль отправляют жертве по почте. Или отправляют архив с паролем к нему раздельными письмами;
  3. Далее жертва скачивает себе на компьютер стоящий в локальной сети вредонос. Это может быть shell code, эксплойт или троян. С высокой вероятностью такой трафик не будет проверяться средствами ИБ. Может, например, стоять IPS/IDS решение, которое проблему скорее всего не обнаружит;
  4. Вредонос исполняется и связывается с командным сервером злоумышленника (C&C). При чем этот трафик может выглядеть легитимно, например https сессия или ssl туннель;
  5. Далее идет распространение действий злоумышленника по сети, вплоть до доступа к ценным информационным активам организации;
  6. И наконец, злоумышленник получает доступ к данным, до которых рвался все это время. Тоже будет выглядеть как легитимный трафик.

Теперь рассмотрим как можно защититься от вышеперечисленных методов:

  1. Проводить обучение цифровой грамотности сотрудникам компании. Также проводить имитации атак для тренировки и сотрудников и ИБ специалистов. А также противодействие утечкам информации за контролируемую зону организационными и техническими методами;
  2. Обязательно проверять почтовый трафик и файловые хранилища периметровыми СЗИ (NGFW) или решениями класса anti-APT внутри защищаемой сети. Также обязательно наличие изолированной среды для проверки вредоносного ПО, так называемой песочницы для обнаружения новых неизвестных зловредов, на которых ещё нет сигнатур. Но в случае использования зашифрованных архивов будет тяжело детектировать вредонос в силу распределенности атаки. Поэтому, в случае целевой атаки, профессиональные злодеи смогут обойти стандартные средства защиты и пройдут дальше;
  3. Использовать агентские решения, которые будут проверять файлы, поступающие на локальный ПК. Скорее всего атака будет остановлена на этом уровне. Если установлен агент. Но, как известно, агенты работают далеко не на всех ПК, поэтому есть вероятность того, что вредонос может выполниться на таких хостах;
  4. Проверять трафик взаимодействия локального ПК с командным центром злодея по сигнатурам или по базам доменов C&C серверов. IPS/IDS решения не подходят. Здесь есть 2 варианта решения: межсетевой экран с функцией antibot или anti-APT решение. Последнее намного лучше заточено под атаки, так как специализируется именно на обнаружение целевых атак за счет более обширной и релевантной базы сигнатур;
  5. Проверять внутренний трафик должно стоять устройство NGFW внутри локальной сети (что в действительно, есть очень у малого числа компаний) или anti-APT решение (еще реже). Последнее может обнаруживать аномалии во внутреннем трафике. Бить тревогу. Если дошло до этого уровня, то все очень плохо, зловред уже очень долго сидит в сети. Тут можно только посоветовать нанять внешнюю команду по реагированию на ИБ инциденты и в дальнейшем пилотировать решение класса anti-APT.

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

  1. Выявление взаимодействия зараженных устройств с командным центрам злоумышленников (сигнатуры + база C&C доменов);
  2. Обнаружение распространения вирусов и эксплойтов в корпоративной сети (сигнатуры + обнаружение аномалий);
  3. Обнаружение вирусов (проверка файлов в изолированной среде);
  4. Выявление вредоносной активности на хостах (агентские решения на локальных местах).

Решение по третьему и четвертому пункту буду рассмотрены в последующих статьях, TDS Sensor покрывает 1 и 2 случай.

Далее рассмотрим функционал TDS Sensor и его возможности по обнаружению вредоносной активности.

Тестирование TDS Sensor


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



Распространение вредоносного ПО и эксплойтов в корпоративной сети


Для того чтобы протестировать обнаружение эксплойтов, в качестве примера я взял сканирование хостов с помощью сканера Openvas в формате full and very deep ultimate. Эта конфигурация добавляет опасные плагины (попытка проэксплуатировать различные уязвимости), которые могут вызвать возможные сбои в работе службы или системы.



Смотрим в TDS Huntbox сработал ли TDS Sensor и выявлены ли какие-либо инциденты. Обнаружен эксплойт EXPLOIT Possible ETERNALBLUE Probe MS17-010 (MSF style), более подробно можно почитать по ссылке.



Также можно выполнить тест от Group-IB.
Для этого переходим на сайт threattest.group-ib.tech с макета и начинаем проверку. Описание безвредных вредоносов предоставлено в консоли:



Смотрим реакцию на TDS Huntbox:



Можно посмотреть более детальное описание:



Взаимодействие зараженных устройств с командным центрам злоумышленников


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



Проверяем на TDS Huntbox был ли инцидент:



Как видим, система зафиксировала сначала запрос к dns серверу DNS Lookup, а затем переход на вредоносный сайт.

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

Архитектура внедрения


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



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

Проверка почты


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

  • получение писем по SMTP;
  • получение писем с помощью механизма скрытой копии (BCC)

Получение писем по SMTP




TDS Sensor выступает как Mail Transfer Agent (или SMTP Relay), получая копию всей входящей почты через SMTP, либо стоя в разрез между почтовыми серверами. В последнем случае появляется возможность блокировать письма с вредоносными вложениями.

Получение писем с помощью механизма скрытой копии (BCC)


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

Анализ файловых хранилищ




Режим подразумевает поведенческий анализ хранимых и/ или изменяемых файлов внутри файловых хранилищ с помощью TDS Polygon. Подключение к хранилищу реализуется с помощью модуля TDS Sensor и поддерживает два варианта работы с файловыми объектами:

  • сканирование всех хранящихся объектов и в том числе изменяемых или объектов, к которым запрашивается доступ;
  • сканирование только изменяемых объектов или объектов, к которым запрашивается доступ с момента интеграции.

Перед изменением объекта и/или перед отправкой данного объекта по запросу пользователю, TDS Sensor скачивает файл и передает на анализ в TDS Polygon. По факту получения вердикта проанализированный объект либо смещается обратно в файловое хранилище, либо, если получен положительный вердикт (файл является ВПО) объект удаляется.

В настоящее время поддерживаются следующие протоколы интеграции:

  • WebDav;
  • SMB;
  • FTP;
  • NFS;

Анализ зашифрованного трафика


В ходе APT-атак, пользователь получает зараженный документ или переходит по фишинговой ссылке с высокой вероятностью по протоколу https. Затем троян или шелл код связывается с командным центром и скачивает вредоносное ПО или предоставляет окно для проникновения в инфраструктуру также по зашифрованному соединению. Соответственно обеспечение процесса информационной безопасности невозможно без вскрытия https соединений. Зеркалирование шифрованного трафика на TDS Sensor не позволит понять что передается в сессии. Поэтому требуется TDS Decryptor, который возьмет на себя расшифровывание сессий и передачу трафика на TDS Sensor.



TDS Decryptor встраивается в сетевые потоки клиента таким образом, чтобы выявлять факты инициации SSL/TLS-сессий, подменять сертификаты (Man-in-the-Middle) для них и обеспечивать расшифровку SSL-трафика, позволяя повышать видимость и уровень контроля трафика защищаемой инфраструктуры. TDS Decryptor поддерживает современные алгоритмы и стандартов шифрования, в том числе ГОСТ (GOST2012-GOST8912-GOST8912, GOST2001-GOST89-GOST89);

Также можно произвести интеграцию TDS Sensor и с другими решениями ИБ:

  • Интеграция с ICAP-прокси/DLP*;
  • Интеграция с SIEM и другими системами для анализа событий ИБ.
  • Интеграция с системами мониторинга (SNMP мониторинг)

Очень интересной особенностью системы является интеграция с тикет-системой в СERT-GIB:

  1. При обнаружении инцидента автоматически будет создан кейс;
  2. Инженер Group-IB возьмет кейс в работу и выдаст детальную информацию по инциденту с рекомендациями по устранению проблемы;
  3. В случае критических кейсов оповещают об угрозе специалистов в течении получаса, лично проверяли.

Заключение:


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

В будущем мы планируем опубликовать подробные обзоры на каждый модуль TDS отдельно, с различными примерами тестов. Так что следите за обновлениями (Telegram, Facebook, VK, TS Solution Blog), Яндекс.Дзен. Также можете посмотреть совместный вебинар от TS Solution и Group-IB на тему защиты промышленных объектов.
Подробнее..

7. NGFW для малого бизнеса. Производительность и общие рекомендации

11.09.2020 10:13:26 | Автор: admin

Наступило время для завершения цикла статей о новом поколение SMB Check Point (1500 cерия). Мы надеемся, что для вас это был полезный опыт и вы продолжите быть с нами в блоге TS Solution. Тема для заключительной статьи мало затрагиваемая, но не менее важная - тюнинг производительности SMB. В ней мы затронем возможности по конфигурации аппаратной и программной части работы NGFW, опишем доступные команды и способы взаимодействия.

Все статьи цикла о NGFW для малого бизнеса:

  1. Новая линейка CheckPoint 1500 Security Gateway

  2. Распаковка и настройка

  3. Беспроводная передача данных: WiFi и LTE

  4. VPN

  5. Облачное управление SMP

  6. Smart-1 Cloud

На текущий момент существует не так много источников информации о тюнинге производительности для SMB решений ввиду ограничений внутренней ОС - Gaia 80.20 Embedded. В нашей статье мы будем использовать макет с централизованным управлением ( выделенный Management Server ) - он позволяет применить большее количество инструментов при работе с NGFW.

Аппаратная часть

Прежде чем затрагивать архитектуру Check Point семейства SMB, вы всегда можете обратиться к вашему партнеру, чтобы он использовал утилиту Appliance Sizing Tool, для подбора оптимального решения согласно заданным характеристикам (пропускная способность, ожидаемое количество пользователей и т.д).

Важные заметки при взаимодействие с аппаратной частью вашего NGFW
  1. NGFW решения семейства SMB не имеют возможности аппаратного апгрейда системных компонентов (CPU, RAM, HDD), в зависимости от модели есть поддержка SD-карт, это позволяет расширить емкость диска, но не значительно.

  2. Работа сетевых интерфейсов требует контроля. В Gaia 80.20 Embedded не так много инструментов для мониторинга, но вы всегда можете использовать общеизвестную команду в CLI через режим Expert

    # ifconfig

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

  3. Для полноценной Gaia есть команда:

    > show diag

    С ее помощью возможно получить информацию о температуре аппаратного обеспечения.К сожалению, в 80.20 Embedded данной опции нет, укажем наиболее популярные SNMP-traps:

    Название

    Описание

    Interface disconnected

    Отключение интерфейса

    VLAN removed

    Удаление Vlan

    High memory utilization

    Высокая утилизация RAM

    Low disk space

    Мало место на HDD

    High CPU utilization

    Высокая утилизация CPU

    High CPU interrupts rate

    Высокая частота прерываний

    High connection rate

    Высокий поток новых подключений

    High concurrent connections

    Высокий уровень конкурентных сессий

    High Firewall throughput

    Высокий уровень пропускной способности Firewall

    High accepted packet rate

    Высокий уровень приема пакетов

    Cluster member state changed

    Изменение состояния кластера

    Connection with log server error

    Потеря связи с Log-Server

  4. Работа вашего шлюза требует контроля RAM. Для работы Gaia (Linux подобная OC) это нормальная ситуация, когда расход RAM доходит до 70-80% использования.

    В архитектуре SMB-решений не предусмотрено использования SWAP-памяти, в отличие от более старших моделей Check Point. Тем не менее, в системных файлах Linux был замечен <vm.swapsiness>, что говорит о теоретической возможности изменять параметр SWAP.

Программная часть

На момент выхода статьи актуальная версии Gaia - 80.20.10. Вам нужно знать, что присутствуют ограничения при работе в CLI: в режиме Expert поддерживаются некоторые Linuх команды. Для оценки работы NGFW требуется оценка работы демонов и служб, более подробно об этом можно узнать в статье моего коллеги. Мы же рассмотрим возможные команды для SMB.

Работа с Gaia OS
  1. Просмотр шаблонов SecureXL

    # fwaccel stat

  2. Просмотр загрузки по ядрам

    # fw ctl multik stat

  3. Просмотр количества сессий (соединений).

    # fw ctl pstat

  4. *Просмотр состояния кластера

    # cphaprob stat

  5. Классическая Linux-команда TOP

Логирование

Как вы уже знаете, есть три способа работы с логами NGFW (хранение, обработка) : локально, централизованно и в облаке. Последние два варианта подразумевают наличие сущности - Management Server.

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

    # tail -f /var/log/messages2

  2. Cообщения об ошибках в работе блейдов (достаточно полезный файл при поиске проблем)

    # tail -f /var/log/log/sfwd.elg

  3. Просмотр сообщений из буфера на уровне ядра системы.

    # dmesg

Конфигурация блейдов

Данный раздел не будет содержать полноценных инструкций по настройке вашего NGFW Сheck Point, он лишь содержит наши рекомендации, подобранные опытным путем.

Application Control / URL Filtering
  • Рекомендовано избегать в правилах условия ANY, ANY (Source, Destination).

  • В случае задания кастомного URL-ресурса более действенно будет использовать регулярное выражения типа: (^|..)checkpoint.com

  • Избегайте чрезмерного использования логирования по правилам и показа страниц блокировки (UserCheck).

  • Убедитесь, что корректно работает технология SecureXL. Большая часть трафика должна проходить через accelerated / medium path. Также не забывайте фильтровать правила по наиболее используемым (поле Hits ).

HTTPS-Inspection

Ни для кого не секрет, что 70-80% пользовательского трафика приходится на HTTPS-соединения, соответственно, это требует ресурсов от процессора вашего шлюза. Кроме этого, HTTPS-Inspection участвует в работе IPS, Antivirus, Antibot.

Начиная с версии 80.40 появилась возможность работать с HTTPS-правилами без Legacy Dashboard, вот некоторый рекомендуемый порядок правил:

  • Bypass для группы адресов и сетей (Destination).

  • Bypass для группы URL-адресов.

  • Bypass для внутренних IP и cетей с привилегированным доступом (Source).

  • Inspect для необходимых сетей, пользователей

  • Bypass для всех остальных.

* Всегда лучше выбирать вручную сервисы HTTPS или HTTPS Proxy, не оставлять Any. Логировать события по правилам Inspect.

IPS

Блейд IPS может вызывать ошибку при инсталляции политики на вашем NGFW , если используется слишком много сигнатур. Согласно статье от Check Point, архитектура SMB устройств не рассчитана для запуска полного рекомендуемого профиля настроек IPS.

Чтобы решить или предотвратить проблему, выполните следующие шаги:

  1. Клонируйте Optimized профиль под названием Optimized SMB ( либо другим на ваше усмотрение ).

  2. Отредактируйте профиль, перейдите в раздел IPS Pre R80.Settings и выключите Server Protections.

  3. По вашему усмотрению вы можете деактивировать CVE старше 2010, данные уязвимости могут быть редко обнаружены в малых офисах, но влияют на производительность. Чтобы отключить некоторые из них , перейдите в Profile IPS Additional Activation Protections to deactivate list

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

В рамках цикла статей о новом поколение NGFW семейства SMB (1500) мы постарались осветить основные возможности решения, продемонстрировали на конкретных примерах настройку важных компонентов безопасности. Будем рады ответить на любые вопросы о продукте в комментариях. Остаемся с вами , спасибо за внимание!

Большая подборка материалов по Check Point от TS Solution. Чтобы не пропустить новые публикации следите за обновлениями в наших социальных сетях (Telegram,Facebook,VK,TS Solution Blog,Яндекс.Дзен).

Подробнее..

Cisco ISE Введение, требования, установка. Часть 1

18.09.2020 10:20:14 | Автор: admin

1. Введение

У каждой компании, даже самой малой есть потребность в проведении аутентификации, авторизации и учета пользователей (семейство протоколов ААА). На начальном этапе ААА вполне себе хорошо реализуется с использованием таких протоколов, как RADIUS, TACACS+ и DIAMETER. Однако с ростом количества пользователей и компании, растет и количество задач: максимальная видимость хостов и BYOD устройств, многофакторная аутентификация, создание многоуровневой политики доступа и многое другое.

Для таких задач отлично подходит класс решений NAC (Network Access Control) - контроль сетевого доступа. В цикле статей, посвященному Cisco ISE (Identity Services Engine) - NAC решению для предоставления контроля доступа пользователям к внутренней сети с учетом контекста, мы подробно рассмотрим архитектуру, инициализацию, настройку и лицензирование решения.

Кратко напомню, что Cisco ISE позволяет:

  • Быстро и просто создавать гостевой доступ в выделенной WLAN;

  • Обнаруживать BYOD устройства (например, домашние ПК сотрудников, которые они принесли на работу);

  • Централизовать и применять политики безопасности к доменным и не доменным пользователям с помощью меток групп безопасности SGT (технология TrustSec);

  • Проверять компьютеры на наличие установленного определенного ПО и соблюдение стандартов (posturing);

  • Классифицировать и профилировать оконечные и сетевые устройства;

  • Предоставлять видимость оконечных устройств;

  • Отдавать журналы событий logon/logoff пользователей, их учетки (identity) на NGFW для формирования user-based политики;

  • Нативно интегрироваться с Cisco StealthWatch и вносить в карантин подозрительные хосты, участвующие в инцидентах безопасности (подробнее);

  • И другие стандартные для ААА сервера фичи.

Про Cisco ISE уже писали коллеги по отрасли, поэтому в дальнейшем советую ознакомиться: практика внедрения Cisco ISE, как подготовиться к внедрению Cisco ISE.

2. Архитектура

В архитектуре Identity Services Engine есть 4 сущности (ноды): нода управления (Policy Administration Node), нода распределения политик (Policy Service Node), мониторинговая нода (Monitoring Node) и PxGrid нода (PxGrid Node). Сisco ISE может быть в автономной (standalone) или распределенной (distributed) инсталляции. В Standalone варианте все сущности находятся на одной виртуальной машине или физическом сервере (Secure Network Servers - SNS), когда в Distributed - ноды распределены по разным устройствам.

Policy Administration Node (PAN) - обязательная нода, которая позволяет выполнять все административные операции на Cisco ISE. Она обрабатывает все системные конфигурации, связанные с ААА. В распределенной конфигурации (ноды можно устанавливать как отдельные виртуальные машины) у вас может быть максимум две PAN для отказоустойчивости - Active/Standby режим.

Policy Service Node (PSN) - обязательная нода, которая обеспечивает доступ к сети, состояние, гостевой доступ, предоставление услуг клиентам и профилирование. PSN оценивает политику и применяет ее. Как правило, PSN устанавливается несколько, особенно в распределенной конфигурации, для более избыточной и распределенной работы. Конечно же, эти ноды стараются устанавливать в разных сегментах, чтобы не терять возможности обеспечения аутентифицированного и авторизованного доступа ни на секунду.

Monitoring Node (MnT) - обязательная нода, которая хранит журналы событий, логи других нод и политик в сети. MnT нода предоставляет расширенные инструменты для мониторинга и устранения неполадок, собирает и сопоставляет различные данные, в также предоставляет содержательные отчеты. Cisco ISE позволяет иметь максимум две MnT ноды, тем самым формируя отказоустойчивость - Active/Standby режим. Тем не менее, логи собирают обе ноды, как активная, так и пассивная.

PxGrid Node (PXG) - нода, применяющая протокол PxGrid и обеспечивающая общение между другими устройствами, которые поддерживают PxGrid.

PxGrid - протокол, который обеспечивает интеграцию продуктов ИТ- и ИБ-инфраструктуры разных вендоров: систем мониторинга, систем обнаружения и предотвращения вторжений, платформ управления политиками безопасности и множества других решений. Cisco PxGrid позволяет обмениваться контекстом в однонаправленном или двунаправленном режиме со многими платформами без необходимости использования API, тем самым позволяя использовать технологию TrustSec (SGT метки), изменять и применять ANC (Adaptive Network Control) политику, а также осуществлять профилирование - определение модели устройства, ОС, местоположение и другое.

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

Ниже схематично изображена работа разных сущностей Cisco ISE в корпоративной сети.

Рисунок 1. Архитектура Cisco ISEРисунок 1. Архитектура Cisco ISE

3. Требования

Cisco ISE может быть внедрен, как и большинство современных решений виртуально или физически как отдельный сервер.

Физические устройства с установленным ПО Cisco ISE называются SNS (Secure Network Server). Они бывают трех моделей: SNS-3615, SNS-3655 и SNS-3695 для малого, среднего и большого бизнеса. В таблице 1 приведена информация из даташита SNS.

Таблица 1. Сравнительная таблица SNS для разных масштабов

Параметр

SNS 3615 (Small)

SNS 3655 (Medium)

SNS 3695 (Large)

Количество поддерживаемых оконечных устройств в Standalone инсталляции

10000

25000

50000

Количество поддерживаемых оконечных устройств для каждой PSN

10000

25000

100000

CPU (Intel Xeon 2.10 ГГц)

8 ядер

12 ядер

12 ядер

RAM

32 Гб (2 x 16 Гб)

96 Гб (6 x 16 Гб)

256 Гб (16 x 16 Гб)

HDD

1 х 600 Гб

4 х 600 Гб

8 х 600 Гб

Hardware RAID

Нет

RAID 10, наличие RAID контроллера

RAID 10, наличие RAID контроллера

Сетевые интерфейсы

2 х 10Gbase-T

4 х 1Gbase-T

2 х 10Gbase-T

4 х 1Gbase-T

2 х 10Gbase-T

4 х 1Gbase-T

Касательно виртуальных внедрений, поддерживаются гипервизоры VMware ESXi (рекомендуется минимум VMware версия 11 для ESXi 6.0), Microsoft Hyper-V и Linux KVM (RHEL 7.0). Ресурсы должны быть примерно такие же, как и в таблице выше, либо больше. Тем не менее, минимальные требования виртуальной машины для малого бизнеса: 2 CPU с частотой 2.0 ГГц и выше, 16 Гб RAM и 200 Гб HDD.

Для уточнения остальных деталей развертывания Cisco ISE обратитесь к нам или к ресурсу 1, ресурсу 2.

4. Установка

Как и большинство других продуктов Cisco, ISE можно протестировать несколькими способами:

  • dcloud облачный сервис предустановленных лабораторных макетов (необходима учетная запись Cisco);

  • GVE request запрос с сайта Cisco определенного софта (способ для партнеров). Вы создаете кейс со следующим типичным описанием: Product type [ISE], ISE Software [ise-2.7.0.356.SPA.x8664], ISE Patch [ise-patchbundle-2.7.0.356-Patch2-20071516.SPA.x8664];

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

1) Создав виртуальную машину, если вы запросили ISO файл, а не OVA шаблон, у вас вылезет окно, в которой ISE требует выбрать установку. Для этого вместо логина и пароля следует написать "setup"!

Примечание: если вы развернули ISE из OVA шаблона, то данные для входа admin / MyIseYPass2 (это и многое другое указано в официальном гайде).

Рисунок 2. Установка Cisco ISEРисунок 2. Установка Cisco ISE

2) Затем следует заполнить необходимые поля, такие как IP-адрес, DNS, NTP и другие.

Рисунок 3. Инициализация Cisco ISEРисунок 3. Инициализация Cisco ISE

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

Рисунок 4. Веб-интерфейс Cisco ISEРисунок 4. Веб-интерфейс Cisco ISE

4) Во вкладке Administration > System > Deployment можно выбрать, какие ноды (сущности) включены на том или ином устройстве. Нода PxGrid включается здесь же.

Рисунок 5. Управление сущностями Cisco ISEРисунок 5. Управление сущностями Cisco ISE

5) Затем во вкладке Administration > System > Admin Access > Authentication рекомендую настроить политику паролей, метод аутентификации (сертификат или пароль), срок истечения учетной записи и другие настройки.

Рисунок 6. Настройка типа аутентификацииРисунок 6. Настройка типа аутентификацииРисунок 7. Настройки политики паролейРисунок 7. Настройки политики паролейРисунок 8. Настройка выключения аккаунта по истечение времениРисунок 8. Настройка выключения аккаунта по истечение времениРисунок 9. Настройка блокировки учетных записейРисунок 9. Настройка блокировки учетных записей

6) Во вкладке Administration > System > Admin Access > Administrators > Admin Users > Add можно создать нового администратора.

Рисунок 10. Создание локального администратора Cisco ISEРисунок 10. Создание локального администратора Cisco ISE

7) Нового администратора можно сделать частью новой группы или уже предустановленных групп. Управления группами администраторов осуществляется в этой же панели во вкладке Admin Groups. В таблице 2 сведена информация об администраторах ISE, их правах и ролях.

Таблица 2. Группы администраторов Cisco ISE, уровни доступа, разрешения и ограничения

Название группы администраторов

Разрешения

Ограничения

Customization Admin

Настройка гостевого, спонсорского порталов, администрирование и кастомизация

Невозможность изменять политики, просматривать отчеты

Helpdesk Admin

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

Нельзя изменять, создавать и удалять отчеты, алармы и логи аутентификации

Identity Admin

Управление пользователями, привилегиями и ролями, возможность смотреть логи, отчеты и алармы

Нельзя изменять политики, выполнять задачи на уровне ОС

MnT Admin

Полный мониторинг, отчеты, алармы, логи и управление ими

Невозможность изменять никакие политики

Network Device Admin

Права на создание, изменение объектов ISE, просмотр логов, отчетов, главного дашборда

Нельзя изменять политики, выполнять задачи на уровне ОС

Policy Admin

Полное управление всеми политиками, изменение профилей, настроек, просмотр отчетности

Невозможность выполнять настройки с учетными данными, объектами ISE

RBAC Admin

Все настройки во вкладке Operations, настройка ANC политики, управление отчетностью

Нельзя изменять другие кроме ANC политики, выполнять задачи на уровне ОС

Super Admin

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

Не может изменить, удалить другого профиля из группы Super Admin

System Admin

Вс настройки во вкладке Operations, управление системными настройками, политикой ANC, просмотр отчетности

Нельзя изменять другие кроме ANC политики, выполнять задачи на уровне ОС

External RESTful Services (ERS) Admin

Полный доступ к REST API Cisco ISE

Только для авторизации, управления локальными пользователями, хостами и группами безопасности (SG)

External RESTful Services (ERS) Operator

Права на чтение REST API Cisco ISE

Только для авторизации, управления локальными пользователями, хостами и группами безопасности (SG)

Рисунок 11. Предустановленные группы администраторов Cisco ISEРисунок 11. Предустановленные группы администраторов Cisco ISE

8) Дополнительно во вкладке Authorization > Permissions > RBAC Policy можно редактировать права предустановленных администраторов.

Рисунок 12. Управление правами предустановленных профилей администраторов Cisco ISEРисунок 12. Управление правами предустановленных профилей администраторов Cisco ISE

9) Во вкладке Administration > System > Settings доступны все системные настройки (DNS, NTP, SMTP и другие). Вы можете их заполнить здесь, в случае если пропустили при первоначальной инициализации устройства.

5. Заключение

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

В следующей статье мы рассмотрим создание учетных записей, интеграцию с Microsoft Active Directory, а также создание гостевого доступа.

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

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

Подробнее..

OSINT или как посмотреть на свою сеть глазами хакера

21.09.2020 10:09:24 | Автор: admin


Добрый день! Сегодня я вам расскажу какую информацию об организации можно обнаружить в открытых источниках и как ей может воспользоваться потенциальный злоумышленник. Многие из вас наверняка слышали об OSINT (Open Source INTelligence, перечень мероприятий, направленный на сбор информации из открытых источников), который чаще всего используется для сбора информации о конкретном человеке. Но также OSINT можно использовать для поиска информации о конкретных организациях для оценки защищенности. Ведь согласитесь, полезно посмотреть, что о вас есть в открытом доступе и как вы выглядите со стороны потенциального злоумышленника.


Популярные ресурсы, где проходит сбор информации


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


Так что же можно найти в свободном доступе?

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


Я же постараюсь выделить из обширного объема информации наиболее интересную для ИБ специалистов. Искать будем:

  • Корпоративные почтовые адреса
  • Факты компрометации почтовых адресов
  • Субдомены, зарегистрированные за компанией
  • IP-адреса и автономные системы компании
  • Открытые порты и сервисы, находящиеся на них, а также подбор уязвимостей и эксплойтов для обнаруженных сервисов
  • Скрытые директории сайтов
  • Конфиденциальные документы

Чем же можно воспользоваться для поиска этой информации?

В интернете существует огромное количество инструментов для поиска почтовых адресов компании по доменам, например:


hunter.io до недавнего времени инструмент был полностью бесплатным, но к сожалению времена меняются.



Расширение браузера Email Finder от Snov.io на данный момент имеет огромный функционал в бесплатной версии и находит огромное количество доменных учетных записей, но надолго ли?..



theHarvester собирает как почтовые адреса, так и субдомены, открытые порты а также данные о виртуальных хоcтах. Предустановлен в Kali Linux.



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

Провести проверку можно на многим известном сервисе haveibeenpwned.com.



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



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

Тут стоит отметить, что инструмент имеет платный API. Без него, конечно, можно проверить все почтовые адреса, но придется подавать их на вход по одному, что займет уйму времени. При покупке API (3,5$ в месяц, чисто символическая плата) получим возможность использовать его в различных скриптах и соответственно существенно ускорить и автоматизировать процесс анализа.

В дальнейшем можно воспользоваться ботом в telegram @mailsearchbot.



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

Следующим этапом необходимо собрать информацию о субдоменах. Инструментов, позволяющих это сделать очень много, например:


theHarvester



dnsdumpster.com умеет рисовать красивые графы взаимосвязей и выгружать результаты в Excel, но имеет ограничение на выдачу только 100 субдоменов.



pentest-tools.com советую познакомиться с сайтом поподробнее, так как тут можно не только субдомены искать. В lite версии имеет ограничение на 2 сканирования в день, но легко обходится TORом)



Тут также имеет смысл комбинировать инструменты для определения наибольшего количества субдоменов. Зачастую в паре с субдоменом идет IP-адрес, который в дальнейшем можно скормить шодану (shodan.io) для получения списка открытых портов и сервисах, торчащих в интернете.



В дальнейшем можно подобрать уязвимости и эксплойты по определенным версиям сервисов, используя такие ресурсы, как:


cvedetails.com большая пополняемая база CVE по сервисам и их версиям. Тут могут возникнуть некоторые сложности с поиском необходимых сервисов так, как они повторяются (например существуют две разные страницы сервиса Microsoft IIS с разными уязвимостями).



exploit-db.com большая пополняемая база эксплойтов. Тут стоит обратить внимание, что есть подтвержденные администрацией сайта эксплойты и не проверенные.



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


bgp.he.net топорно выглядит, но показывает данные по любым автономным системам.



ididb.ru в большей степени заточен на сбор информации об автономных системах Рунета.



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

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



Переходим к заключительному этапу поиск скрытых директорий и файлов сайта. Тут нам пригодятся:

  • Google Dorks
  • DirBuster

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



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



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

Популярные курсы/книги для обучения


  • Курс видеоматериалов для ознакомления с OSINT
  • Сертифицированный курс по OSINT и конкурентной разведке
  • Советую посмотреть в YouTube записи выступлений Масаловича Андрея Игоревича, преподавателя предыдущего курса. Он настоящий профессионал своего дела, расскажет много интересного. Также советую ознакомиться с его сайтом, на котором вы можете найти большое количество видеоматериалов и книг по данной тематике


Топ 5 проблем, которые нам удается обнаружить в рамках OSINT-а


На моей практике удавалось:

  • Получить возможность управлять сайтом от имени администратора поскольку была возможность провалиться в директорию, которая минует авторизацию администратора. Естественно я там ничего трогать не стал, но еслиб это был не я, а потенциальный злоумышленник? Закрывать нужно такие директории.
  • Обнаружить торчащие в интернет базы данных, которые к тому же были очень древние и крайне дырявые. Подбор эксплойта под такие базы задача крайне простая. Не нужно вытаскивать БД наружу.
  • Обнаружить RDP, FTP, SSH и NTP сервисы, доступ к которым из неограниченного пула адресов нежелателен. Тут вырисовывается проблема простых паролей для учетных записей, а brute force никто не отменял. Не нужно выставлять такие сервисы наружу, если нет явной необходимости..
  • Обнаружить конфиденциальные документы. Например документы, относящиеся к организации внутриобъектового режима, находящиеся в открытом доступе не лучшая затея.
  • Подобрать актуальные пароли от почтовых адресов. Я сам не проверяю актуальность обнаруженных паролей, но иногда после ознакомления с отчетом сотрудники компании обращаются с вопросом: что же делать, если пароль действительно актуальный? В таких случаях его естественно нужно менять, а так же менять пароли на всех сайтах, где регистрация проходила от данного почтового ящика и надеяться на лучшее. А вообще меняйте пароли почаще.


Заключение


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

Что делать, если нет возможности провести OSINT самому?


Мы можем провести OSINT для Вашей организации совершенно бесплатно, обращайтесь.
Если данная тематика вам интересна, то следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!
Подробнее..

Cisco ISE Создание пользователей, добавление LDAP серверов, интеграция с AD. Часть 2

25.09.2020 10:10:53 | Автор: admin

Приветствую во второй публикации цикла статей, посвященному Cisco ISE. В первой статье были освещены преимущества и отличия Network Access Control (NAC) решений от стандартных ААА, уникальность Cisco ISE, архитектура и процесс установки продукта.

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

1. Немного терминологии

User Identity - учетная запись пользователя, которая содержит информацию о пользователе и формирует его учетные данные для доступа к сети. Следующие параметры, как правило, указываются в User Identity: имя пользователя, адрес электронной почты, пароль, описание учетной записи, группу пользователей и роль.

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

User Identity Groups - предустановленные группы пользователей, которые уже имеют определенную информацию и роли. Следующие User Identity Groups существуют по умолчанию, в них можно добавлять пользователей и группы пользователей: Employee (сотрудник), SponsorAllAccount, SponsorGroupAccounts, SponsorOwnAccounts (спонсорские учетки для управления гостевым порталом), Guest (гость), ActivatedGuest (активированный гость).

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

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

2. Создание локальных пользователей

1) В Cisco ISE есть возможность создать локальных пользователей и использовать их в политике доступа или даже дать роль администрирования продуктом. Выберите Administration > Identity Management > Identities > Users > Add.

Рисунок 1. Добавление локального пользователя в Cisco ISEРисунок 1. Добавление локального пользователя в Cisco ISE

2) В появившемся окне создайте локального пользователя, задайте ему пароль и другие понятные параметры.

Рисунок 2. Создание локального пользователя в Cisco ISEРисунок 2. Создание локального пользователя в Cisco ISE

3) Пользователей также можно импортировать. В этой же вкладке Administration > Identity Management > Identities > Users выберите опцию Import и загрузите csv или txt файлик с пользователями. Для того, чтобы получить шаблон выберите Generate a Template, далее следует его заполнить информацией о пользователях в подходящем виде.

Рисунок 3. Импорт пользователей в Cisco ISEРисунок 3. Импорт пользователей в Cisco ISE

3. Добавление LDAP серверов

Напомню, что LDAP - популярный протокол прикладного уровня, позволяющий получать информацию, производить аутентификацию, искать учетные записи в каталогах LDAP серверов, работает по порту 389 или 636 (SS). Яркими примерами LDAP серверов являются Active Directory, Sun Directory, Novell eDirectory и OpenLDAP. Каждая запись в каталоге LDAP определяется DN (Distinguished Name) и для формирования политики доступа встает задача подтягивания (retrieval) учетных записей, пользовательских групп и атрибутов.

В Cisco ISE возможно настроить доступ ко многим LDAP серверам, тем самым реализуя избыточность. В случае, если первичный (primary) LDAP сервер недоступен, то ISE попробует обратиться к вторичному (secondary) и так далее. Дополнительно, если имеется 2 PAN, то то для первичной PAN можно сделать приоритетным один LDAP, а для вторичной PAN - другой LDAP.

ISE поддерживает 2 типа лукапа (lookup) при работе с LDAP серверами: User Lookup и MAC Address Lookup. User Lookup позволяет делать поиск пользователю в базе данных LDAP и получать следующую информацию без аутентификации: пользователи и их атрибуты, группы пользователей. MAC Address Lookup позволяет так же без аутентификации производить поиск по MAC адресу в каталогах LDAP и получать информацию об устройстве, группу устройств по MAC адресам и другие специфичные атрибуты.

В качестве примера интеграции добавим Active Directory в Cisco ISE в качестве LDAP сервера.

1) Зайдите во вкладку Administration > Identity Management > External Identity Sources > LDAP > Add.

Рисунок 4. Добавление LDAP сервераРисунок 4. Добавление LDAP сервера

2) В панели General укажите имя LDAP сервера и схему (в нашем случае Active Directory).

Рисунок 5. Добавление LDAP сервера со схемой Active DirectoryРисунок 5. Добавление LDAP сервера со схемой Active Directory

3) Далее перейдите в Connection вкладку и укажите Hostname/IP address AD сервера, порт (389 - LDAP, 636 - SSL LDAP), учетные данные доменного администратора (Admin DN - полный DN), остальные параметры можно оставить по умолчанию.

Примечание: используйте данные домен админа во избежание потенциальных проблем.

Рисунок 6. Ввод данных LDAP сервераРисунок 6. Ввод данных LDAP сервера

4) Во вкладке Directory Organization следует указать область каталогов через DN, откуда вытягивать пользователей и группы пользователей.

Рисунок 7. Определение каталогов, откуда подтянуться группы пользователейРисунок 7. Определение каталогов, откуда подтянуться группы пользователей

5) Перейдите в окно Groups > Add > Select Groups From Directory для выбора подтягивания групп из LDAP сервера.

Рисунок 8. Добавление групп из LDAP сервераРисунок 8. Добавление групп из LDAP сервера

6) В появившемся окне нажмите Retrieve Groups. Если группы подтянулись, значит предварительные шаги выполнены успешно. В противном случае, попробуйте другого администратора и проверьте доступность ISE c LDAP сервером по LDAP протоколу.

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

7) Во вкладке Attributes можно опционально указать, какие атрибуты из LDAP сервера следует подтянуть, а в окне Advanced Settings включить опцию Enable Password Change, которая заставит пользователей изменить пароль, если он истек или был сброшен. В любом случае нажмите Submit для продолжения.

8) LDAP сервер появился в соответствующий вкладке и в дальнейшем может использоваться для формирования политик доступа.

Рисунок 10. Перечень добавленных LDAP серверовРисунок 10. Перечень добавленных LDAP серверов

4. Интеграция с Active Directory

1) Добавив Microsoft Active Directory сервер в качестве LDAP сервера, мы получили пользователи, группы пользователей, но не логи. Далее предлагаю настроить полноценную интеграцию AD с Cisco ISE. Перейдите во вкладку Administration > Identity Management > External Identity Sources > Active Directory > Add.

Примечание: для успешной интеграции с AD ISE должен находиться в домене и иметь полную связность с DNS, NTP и AD серверами, в противном случае ничего не выйдет.

Рисунок 11. Добавление сервера Active DirectoryРисунок 11. Добавление сервера Active Directory

2) В появившемся окне введите данные администратора домена и поставьте галочку Store Credentials. Дополнительно вы можете указать OU (Organizational Unit), если ISE находится в каком-то конкретном OU. Далее придется выбрать ноды Cisco ISE, которые вы хотите соединить с доменом.

Рисунок 12. Ввод учетных данныхРисунок 12. Ввод учетных данных

3) Перед добавлением контроллеров домена убедитесь, что на PSN во вкладке Administration > System > Deployment включена опция Passive Identity Service. PassiveID - опция, которая позволяет транслировать User в IP и наоборот. PassiveID получает информацию из AD через WMI, специальных AD агентов или SPAN порт на коммутаторе (не лучший вариант).

Примечание: для проверки статуса Passive ID введите в консоли ISE show application status ise | include PassiveID.

Рисунок 13. Включение опции PassiveID Рисунок 13. Включение опции PassiveID

4) Перейдите во вкладку Administration > Identity Management > External Identity Sources > Active Directory > PassiveID и выберите опцию Add DCs. Далее выберите галочками необходимые контроллеры домена и нажмите OK.

Рисунок 14. Добавление контроллеров доменаРисунок 14. Добавление контроллеров домена

5) Выберите добавленные DC и нажмите кнопку Edit. Укажите FQDN вашего DC, доменные логин и пароль, а также опцию связи WMI или Agent. Выберите WMI и нажмите OK.

Рисунок 15. Ввод данных контроллера доменаРисунок 15. Ввод данных контроллера домена

6) Если WMI не является предпочтительным способом связи с Active Directory, то можно использовать ISE агентов. Агентский способ заключается в том, что вы можете установить на сервера специальные агенты, которые будут отдавать login события. Существует 2 варианта установки: автоматический и ручной. Для автоматической установки агента в той же вкладке PassiveID выберите пункт Add Agent > Deploy New Agent (DC должен иметь доступ в Интернет). Затем заполните обязательные поля (имя агента, FQDN сервера, логин/пароль доменного администратора) и нажмите OK.

Рисунок 16. Автоматическая установка ISE агентаРисунок 16. Автоматическая установка ISE агента

7) Для ручной установки Cisco ISE агента требуется выбрать пункт Register Existing Agent. К слову, скачать агента можно во вкладке Work Centers > PassiveID > Providers > Agents > Download Agent.

Рисунок 17. Скачивание ISE агентаРисунок 17. Скачивание ISE агента

Важно: PassiveID не читает события logoff! Параметр отвечающий за тайм-аут называется user session aging time и равняется 24 часам по умолчанию. Поэтому следует либо делать logoff самому по окончании рабочего дня, либо же писать какой-то скрипт, который будет делать автоматический logoff всем залогиненым пользователям.

Для получения информации logoff используются "Endpoint probes" - оконечные зонды. Endpoint probes в Cisco ISE существует несколько: RADIUS, SNMP Trap, SNMP Query, DHCP, DNS, HTTP, Netflow, NMAP Scan. RADIUS probe с помощью CoA (Change of Authorization) пакетов отдает информацию о смене прав пользователя (для этого требуется внедренный 802.1X), а настроенный на коммутаторах доступа SNMP, даст информацию о подключенных и отключенных устройствах.

Ниже приведен пример, актуальный для конфигурации Cisco ISE + AD без 802.1X и RADIUS: пользователь залогинен на Windows машине, не делая logoff, логиниться с другого ПК по WiFi. В этом случае сессия на первом ПК по-прежнему будет активна, пока не случится тайм-аут или не произойдет принудительный logoff. Тогда если у устройств разные права, то последнее залогиненное устройство будет применять свои права.

8) Дополнительно во вкладке Administration > Identity Management > External Identity Sources > Active Directory > Groups > Add > Select Groups From Directory вы можете выбрать группы из AD, которые хотите подтянуть на ISE (в нашем случае это было сделано в пункте 3 Добавление LDAP сервера). Выберите опцию Retrieve Groups > OK.

Рисунок 18 а). Подтягивание групп пользователей из Active DirectoryРисунок 18 а). Подтягивание групп пользователей из Active Directory

9) Во вкладке Work Centers > PassiveID > Overview > Dashboard вы можете наблюдать количество активных сессий, количество источников данных, агентов и другое.

Рисунок 19. Мониторинг активности доменных пользователейРисунок 19. Мониторинг активности доменных пользователей

10) Во вкладке Live Sessions отображаются текущие сессии. Интеграция с AD настроена.

Рисунок 20. Активные сессии доменных пользователейРисунок 20. Активные сессии доменных пользователей

5. Заключение

В данной статьей были рассмотрены темы создания локальных пользователей в Cisco ISE, добавление LDAP серверов и интеграция с Microsoft Active Directory. В следующей статье будет освещен гостевой доступ в виде избыточного гайда.

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

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

Подробнее..

Что нового в линейке высокопроизводительных маршрутизаторов NetEngine

08.09.2020 14:23:50 | Автор: admin
Настало время раскрыть подробности о новых маршрутизаторах операторского класса Huawei NetEngine 8000 об аппаратной базе и программных решениях, которые позволяют строить на их базе сквозные подключения end-to-end с пропускной способностью 400 Гбит/с и отслеживать качество сетевых сервисов на субсекундном уровне.





От чего зависит, какие технологии нужны для сетевых решений


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

  • распространением широкополосной мобильной связи 5G;
  • ростом облачных нагрузок как в приватных, так и в публичных ЦОДах;
  • расширением мира IoT;
  • увеличением востребованности искусственного интеллекта.


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



Семейство NetEngine 8000


Устройства, входящие в семейство NetEngine 8000, разделены на три основные серии. Маркированные литерой X это высокопроизводительные флагманские модели для операторов связи или под высоконагруженные ЦОДы. Серия M рассчитана на воплощение различных metro-сценариев. А устройства с индексом F предназначены прежде всего для реализации распространённых DCI-сценариев (Data Center Interconnect). Большинство из восьмитысячников могут быть частью туннелей end-to-end с пропускной способностью 400 Гбит/с и поддерживать гарантированный уровень услуги (Service Level Agreement SLA).



Факт: сегодня только Huawei производит полный спектр оборудования для организации сетей класса 400GE. На иллюстрации выше показан сценарий построения сети для крупного enterprise-заказчика или большого оператора. В последнем случае используются высокопроизводительные маршрутизаторы ядра NetEngine 9000, а также новые маршрутизаторы NetEngine 8000 F2A, способные агрегировать большое количество подключений 100, 200 или 400 Гбит/с.

Metro-фабрики реализуются на базе устройств серии М. Подобные решения позволяют без смены платформы адаптироваться к тому десятикратному росту объёма трафика, который ожидается в течение ближайшей декады.



Huawei самостоятельно производит оптические модули с пропускной способностью 400 Гбит/с. Построенные на них решения на 1015% дешевле аналогичных по ёмкости, но использующих 100-гигабитные каналы. Тестирование модулей началось ещё в 2017 году, а уже в 2019-м состоялось первое внедрение оборудования на их основе; сейчас африканский оператор связи Safaricom ведёт коммерческую эксплуатацию такой системы.



Огромная пропускная способность NetEngine 8000, которая, возможно, в 2020 году кажется избыточной, обязательно понадобится уже в не самом отдалённом будущем. Кроме того, маршрутизатор подходит для использования в качестве крупной точки обмена, какая наверняка пригодится как операторам второго уровня, так и крупным enterprise-структурам в фазе бурного роста и создателям решений для электронного правительства.



Также Huawei способствует распространению целого ряда новых технологий, среди которых протокол маршрутизации SRv6, заметно упрощающий доставку операторского VPN-трафика. Технология FlexE (Flexible Ethernet) обеспечивает гарантированную пропускную способность на втором уровне модели OSI, а iFIT (In-situ Flow Information Telemetry) позволяет точно отслеживать параметры выполнения условий SLA.



С точки зрения провайдера, SRv6 можно применять от уровня контейнера в ЦОДе, построенном на NFV (Network Functions Virtualization), до, например, беспроводной среды широкополосного доступа. Корпоративным заказчикам сквозное использование нового протокола понадобится при построении магистральных (опорных) сетей. Технология, подчеркнём, не проприетарная и используется разными вендорами, что устраняет риски возникновения несовместимости.



Так выглядит таймлайн коммерциализации технологии SRv6 для поддержки 5G-решений. Практический кейс: арабская компания Zain Group в процессе перехода к использованию 5G модернизировала свою сеть, увеличив пропускную способность магистральных каналов, а также улучшила управляемость инфраструктуры за счёт внедрения SRv6.



Как применять эти технологии


В качестве технологического зонтика, покрывающего вышеперечисленные решения, ранее использовалось три разнородных продукта. U2000 применялся в качестве NMS для transmission-домена и IP-домена. Дополнительно в SDN-системах задействовались системы uTraffic и гораздо более известная Agile Controller. Однако подобная комбинация оказалась не очень удобной применительно к маршрутизаторам операторского класса, поэтому теперь эти продукты объединены в инструмент CloudSoP.



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



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



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



Провели настройку приступаем к созданию и запуску в эксплуатацию дополнительных VPN-сервисов. Серьёзное преимущество решения Huawei в том, что, в отличие от стандартного MPLS Traffic Engineering, оно позволяет синхронизировать пути туннелей без каких-либо дополнительных надстроек.



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



Конечно, полученный объём трафика надо каким-то образом переварить. Для этого используется дополнительная технология машинного обучения. На основании предварительно загруженных паттернов самых распространённых сетевых неисправностей система контроля способна делать прогнозы по вероятностям возникновения эксцессов. Например, поломки модуля SFP (Small Form-factor Pluggable) или внезапного всплеска трафика в сети.



А так выглядит горизонтально масштабируемая (scale-out) система управления на основе ARM-серверов TaiShan и базы данных GaussDB. У отдельных нод аналитической системы есть понятие роли, что позволяет гранулярно расширять диагностические сервисы при росте трафика или увеличении числа узлов сети.
Иными словами, всё, что было хорошего в мире СХД, постепенно приходит в область управления сетями.


Яркий пример внедрения наших новых технологий Промышленный и коммерческий банк Китая (ICBC). В нём развёрнута опорная сеть высокопроизводительных маршрутизаторов, которым присвоены определённые роли. Согласно NDA, мы вправе дать на схеме только общее представление о структуре сети. В неё входят три больших ЦОДа, связанных туннелями end-to-end, и 35 дополнительных площадок (ЦОДы второго уровня). Используются как стандартные подключения, так и SR-TE.



Трёхслойная интеллектуальная архитектура IP WAN


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

Вот короткое видео, рассказывающее о возможностях NetEngine 8000 и использованных в нём технических решениях:


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



Ради чего всё это? Звучит как фантастика, но уже сейчас для нас 14,4 Тбит/с на слот показатель вполне достижимый. И эта умопомрачительная пропускная способность востребована. В частности, всё теми же финансовыми и энергетическими компаниями, многие из которых располагают сегодня опорными сетями, созданными с применением технологии DWDM (Dense Wavelength Division Multiplexing). В конце концов, растёт и количество приложений, требующих всё более высоких скоростей.

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





Аппаратная основа и её требования


На схемах показаны доступные в настоящее время модули маршрутизаторов LPUI с интегрированными картами и их характеристики.



А так выглядит roadmap с новыми вариантами модулей, которые будут доступны в течение ближайших двух лет. При разработке решений на их основе важно учитывать энергопотребление. Сейчас стандартные ЦОДы строятся из расчёта 710 кВт на стойку, в то время как применение маршрутизаторов терабитного класса подразумевает потребляемую мощность в несколько раз выше (до 3040 уВт в пике). Это влечёт за собой необходимость проектировать специализированную площадку или создавать в имеющемся ЦОДе отдельную высоконагруженную зону.



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



Не одни только флагманы


Как бы ни впечатляли флагманские модели, больше всего инсталляций приходится на box-решения серий М и F.

Наиболее востребованные сейчас сервисные маршрутизаторы модели M8 и M14. Они позволяют в рамках одной платформы работать и с низкоскоростными, таким как E1, и с высокоскоростными интерфейсами (100 Гбит/с сейчас и 400 Гбит/с в ближайшем будущем).



Производительности M14 вполне достаточно, чтобы удовлетворить все запросы обычных enterprise-заказчиков. С помощью него можно строить стандартные решения L3VPN для связи с провайдерами, хорош он и в качестве дополнительного инструмента, например, для сбора телеметрии или применения SRv6.



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



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



Модель M8 несколько меньше M14, в производительность также уступает старшей модели, но сценарии использования у них очень похожи.



Набор совместимых с M8 физических карт позволяет, к примеру, настроить подключение к P-устройствам по интерфейсу 100 Гбит/с, использовать технологию FlexE и всё это зашифровать.



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



Доступных карт для M6 поменьше, а максимальная производительность составляет 50 Гбит/с, что, впрочем, заметно выше, чем у стандартных решений в индустрии на 40 Гбит/с.



Отдельного упоминания заслуживает и самая младшая модель M1A. Это небольшое решение, которое может оказаться кстати там, где ожидается расширенный температурный диапазон эксплуатации (-40 +65 С).




Несколько слов о линейке F. Модель NetEngine 8000 F1A стала одним из самых популярных продуктов Huawei в 2019 году, не в последнюю очередь благодаря тому, что оснащена портами с пропускной способностью от 1 до 100 Гбит/с (до 1,2 Тбит/с суммарно).



Подробнее о SRv6


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

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



Ответом индустрии на этот вызов и стало создание технологии SRv6, к появлению которой приложили руку компании Huawei и Cisco.



Одним из ограничений, которые необходимо было снять, являлась необходимость использовать для маршрутизации стандартных пакетов принцип per-hop behavior (PHB). Наладить межоператорское взаимодействие посредством Inter-AS MP-BGP с дополнительными сервисами (VPNv4) достаточно сложно, поэтому таких решений очень мало. SRv6 позволяет изначально проложить путь пакета через весь сегмент, не прописывая специальных туннелей. Да и программирование самих процессов упрощается, что значительно облегчает крупные развёртывания.



На схеме представлен кейс по внедрению SRv6. Две глобальные сети были объединены несколькими разными протоколами. Чтобы получить сервис от какого-либо виртуального или аппаратного сервера, требовалось большое количество переключений (handover) между VXLAN, VLAN, L3VPN и пр.
После внедрения SRv6 оператор располагал туннелем end-to-end даже не до аппаратного сервера, а до Docker-контейнера.


Подробнее о технологии FlexE


Второй уровень модели OSI плох тем, что он не предоставляет те необходимые сервисы и тот уровень SLA, в которых нуждаются провайдеры. Они, в свою очередь, хотели бы получить некий аналог TDM (Time-division multiplexing), но на Ethernet. Для решения проблемы применялось множество подходов, позволявших добиться лишь очень ограниченных результатов.



Flex Ethernet служит именно для того, чтобы гарантировать качество уровня SDH (Synchronous Digital Hierarchy) и TDM в IP-сетях. Это стало возможным благодаря работе с forwarding plane, когда мы таким образом модифицируем L2-среду, чтобы она становилась максимально производительной.



Как работает любой стандартный физический порт? Имеется определённое количество очередей и tx-кольцо. Попавший в буфер пакет ждёт своей обработки, что не всегда удобно, особенно при наличии elephant- и mice-потоков.

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



Дополнительный MAC-слой выделяется на уровне передачи информации, что позволяет создать жёсткие физические очереди, которым можно назначать определённые SLA.



Так это выглядит на уровне внедрения. В дополнительном слое фактически реализован TDM-фрейминг. Благодаря такой метавставке есть возможность гранулярно раздавать очереди и формировать TDM-услуги через Ethernet.



Один из сценариев использования FlexE подразумевает очень жёсткое следование SLA путём формирования тайм-слотов для выравнивания пропускной способности или предоставления ресурсов для критических сервисов.



Ещё один сценарий позволяет работать с дефектами. Вместо простого хеширования передачи информации мы формируем отдельные каналы практически на физическом уровне, в отличие от виртуальных, создаваемых QoS (Quality of Service).



Подробнее об iFIT


Как и FlexE, iFIT является лицензируемой технологией Huawei. Она позволяет проводить проверку SLA на очень гранулярном уровне. В отличие от стандартных механизмов IP SLA и NQA, iFIT оперирует не синтетическим, а живым трафиком.



Доступна iFIT на всех устройствах, которые поддерживают телеметрию. Для этого используется дополнительное поле, не занятое стандартными Option Data. Туда записывается информация, которая позволяет понять происходящее в канале.

***


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

I want to break free. Обзор беспроводной DECT гарнитуры Snom A170

24.09.2020 08:13:47 | Автор: admin
Доброго дня, коллеги.
Прошлой статьей мы завершили цикл обзоров на настольные телефоны, предлагаем теперь поговорить о гарнитурах, предоставляемых нашей компанией. Начнем с модели DECT-гарнитуры Snom A170. Посмотрите краткое видео о гарнитуре и приступайте к чтению!



Стандарт DECT


А почему собственно DECT?, наверняка спросит нас читатель. Давайте рассмотрим стандарт DECT в целом и его преимущества и недостатки по сравнению с другими возможными вариантами.
DECT (англ. Digital Enhanced Cordless Telecommunication) технология беспроводной связи на частотах 18801900 МГц. Технология, на данный момент очень широко распространена в решениях беспроводных домашних и офисных телефонов, а также беспроводных гарнитур. Популярность DECT для передачи голоса обусловлена несколькими факторами:

  • Стандарт DECT изначально предназначен именно для передачи голоса и используется только с этой целью. Это означает что нет необходимости думать о приоритизации трафика или загруженности частотного диапазона, его будут занимать исключительно устройства для передачи голоса.
  • Дальность действия. Дальность действия устройств, работающих по данному протоколу, ограничена в первую очередь мощностью передатчика. Максимальная мощность по данному стандарту ограничена 10 мВт, что дает возможность разнесения приемного и передающего устройства до 300 м в прямой видимости и до 50 метров в помещениях. Переключения между источниками сигнала при этом осуществляются быстрее чем в том же Wi-Fi, не позволяя пользователю услышать, что переключение произошло. Говоря о дальности действия нельзя сказать, что она принципиально больше, чем у конкурирующих технологий, но радиус действия источника сигнала DECT достаточно большой, чтобы обеспечить пользователю свободу перемещений или построить сеть на основе множества источников сигнала, покрыв значительную площадь.
  • Количество каналов. А значит и количество одновременно работающих устройств. Стандарт DECT подразумевает наличие 10 частотных радиоканалов, казалось бы, немного. Но каждый из частотных каналов подразделяется на 12 временных каналов, давая в сумме больше сотни каналов для передачи голоса.

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

Распаковка и комплектация


Перейдем теперь к рассмотрению самой DECT-гарнитуры.



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



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



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



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

  • Кабель USB-Mini USB для подключения к ПК
  • Кабель RJ9-RJ9 для передачи аудио между телефоном и гарнитурой
  • Специализированный кабель EHS для подключения к телефонам Snom
  • Кабель EHS для подключения к стандартизированному разъему

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

Дизайн


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



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



Остальное управление гарнитурой осуществляется с базовой станции. Базовая станция гарнитуры выглядит также современно и элегантно.



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



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



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

Функционал и эксплуатация


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



С телефоном же все еще проще подключаем гарнитуру в соответствующие разъемы и начинаем пользоваться. Для переключения между устройствами мы используем клавиши PC и PHONE на базовой станции. При нажатии клавиши загорается зеленым ее индикатор и можно пользоваться гарнитурой в удобных нам целях.
Максимальное расстояние между гарнитурой и базой в процессе эксплуатации 50 метров. Этого более чем достаточно, чтобы чувствовать себя свободно в пределах достаточно просторного офиса и заметно больше, чем может дать Bluetooth гарнитура.
Качество передаваемого и принимаемого гарнитурой звука на высоте. Естественно, для прослушивания музыки желательно включить широкополосный режим на базовой станции. В этом случае вы не заметите разницы в сравнении с проводными гарнитурами, но сможете спокойно перемещаться по помещению.



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

Подведем итог


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

Конференция ENOG17 состоится online

19.09.2020 00:21:00 | Автор: admin

В этом году ENOG17 и Региональная Встреча RIPE NCC будут проходить с 9 по 13 ноября в форме виртуального мероприятия.

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

Впервые конференция ENOG прошла в 2011 году в Москве. С тех пор она проводилась в разных городах и странах: России (Москва, Санкт-Петербург и Казань), Украине (Киева и Одесса), Азербайджане (Баку), Армении (Ереван), Беларуси (Минск), Грузии (Тбилиси). В онлайн-формате конференция проводится впервые, хотя формат удаленных докладов для неё не нов (например, в 2018 году Женя Линькова из Google в Москве рассказывала про IPv6 в корпоративных сетях из Австралии).

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

Программному комитету конференции ищет доклады о проблемах, инструментах, опыте работы и тенденциях в таких областях, как:

  • Ключевые интернет- и сетевые технологии

    • Новые протоколы и технологии: сегментная маршрутизация, QUIC, 5G и др.

    • Протоколы внутренней и внешней маршрутизации

    • Опыт внедрения новых технологий (например, IPv6 и DNSSEC), тенденции и статистика

    • Программно-определяемые сети и автоматизация сети

    • Интернет вещей (IoT)

  • Тенденции развития интернета

    • Новые технологии, области их использования и эволюция экосистем Интернета

    • Интернет-измерения, аналитика и прогнозы развития Интернета

  • Координация, управление и регулятивная практика в интернете

    • Относящееся к Интернету законодательство и его влияние, многосторонняя модель, препятствия и возможности

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

  • Пиринг и точки обмена трафиком

    • Коммерческие, технические и социальные аспекты сетевого взаимодействия

  • Эксплуатация сетей и сетевая безопасность

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

    • Предотвращение DDoS-атак

  • Доставка контента (CDN)

    • Технологии, архитектура и бизнес-модели

Если вы хотите предложить свой доклад для включения в программуENOG17, пожалуйста, предоставьте тезисы доклада и черновой вариант презентации с помощью онлайн-системы:
https://www.enog.org/ru/submit-topic/submission-form/.

Докладчики должны указать, сколько времени требуется на доклад. Обычно время выделяется согласно формату доклада:

  • Пленарный доклад: 20-25 минут презентации и 5-10 минут обсуждения

  • Учебные курсы и мастер-классы: до трех часов

  • BoF-сессия: приблизительно один час в вечернюю сессию

  • Блиц-доклад: 10 минут в сумме на презентацию и обсуждение

(Конечно, при необходимости можно обсудить и создание нового формата)

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

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

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

Если вы можете порекомендовать интересный доклад и докладчика, пришлите, пожалуйста, свое предложение в Программный комитет.

Подробнее..

Перевод Становится ли веб медленнее со временем?

14.09.2020 12:17:21 | Автор: admin


В недавней истории на Hacker News утверждалось, что скорости веб-страниц не повышаются даже с увеличением скоростей Интернета.

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

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


Интерпретация данных HTTP Archive


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


Однако скорость подключения, использованная HTTP Archive, не увеличилась за это время.

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


C 2013 года метрика onLoad увеличилась на 55%, с 12,7 с до 19,7 с. Если вы купили телефон в 2013 году и с тех пор подключались к Интернету через 3G, то веб стал для вас медленнее.

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

Зачем смотреть на onLoad?


Событие load передаётся страницей, когда скачаны все ресурсы страницы, такие как скрипты и изображения.

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

Другая страница может изначально и не рендерить ничего полезного, а только начинать загружать дополнительные ресурсы и рендерить контент уже сильно после события onLoad. Тем не менее, такая страница будет казаться быстрой.

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

Зачем вообще смотреть на эту метрику? Потому что она использовалась долгое время и HTTP Archive отслеживал её с 2010 года. Более новые метрики, например, First Contentful Paint или Time to Interactive, были добавлены в HTTP Archive только в 2017 году.

Стоит ли ожидать, что увеличение пропускной способности приведёт к ускорению загрузки страниц?


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

Однако эмулируемое HTTP Archive 3G-подключение на 1,6 Мбит/с очень медленное, поэтому стоит ожидать значительного повышения скорости при увеличении пропускной способности. Среднестатистический веб-сайт скачивает в 2020 году 1,7 МБ данных, то есть при скорости подключения HTTP Archive на скачку потребуется не менее 9 секунд.

Другие тонкости HTTP Archive


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

Тесты не всегда выполнялись на одном устройстве. Изначально использовался физический iPhone 4, а сегодня тесты выполняются на эмулируемом Android-устройстве.

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

Скорость на настольных компьютерах


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


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


Давайте рассмотрим четыре фактора:

  • пропускную способность сети
  • сетевую задержку
  • скорости процессоров
  • скорость браузеров

Пропускная способность мобильных сетей США


На этом графике показана средняя пропускная способность мобильных сетей США в разные годы по данным различных источников. Она увеличилась с 1 Мбит/с до примерно 30 Мбит/с.


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

Задержка в мобильных сетях США


По этому параметру данные найти было сложнее, но результаты показывают, что задержка снизилась примерно с 200 мс (2011 год) до 50 мс (2020 год).


Скорости процессоров мобильных устройств


Мне не удалось найти данные по средним скоростям мобильных устройств в США. Однако Алекс Рассел и Surma опубликовали график рейтинга GeekBench 4 вместе с годами выпуска различных телефонов.

Даже бюджетные телефоны стали в 4 раза быстрее, а iPhone стал мощнее в 20 раз.


Как изменились браузеры?


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

Судя по этому графику из блога V8, потребление ресурсов процессора на одну страницу сократилось в четыре раза.


Работа с сетью


Улучшилась и работа браузеров с сетью. Например, после введения в 2015 году HTTP/2 64% запросов обрабатывается по HTTP/2.


Как изменились веб-сайты?


Давайте взглянем на данные из HTTP Archive, чтобы понять, как поменялись веб-сайты.

Вес страницы


За промежуток времени с 2013 по 2020 год вес страницы для мобильных увеличился на 337%. В основном это вызвано увеличением количества изображений и кода на JavaScript.

Объём других ресурсов тоже сильно увеличился подозреваю, что в основном это видео.


График начинается с 2013 года, потому что в октябре 2012 года HTTP Archive изменил методологию измерений. До этого вес страницы недооценивался, потому что тест прекращался после срабатывания события загрузки страницы, даже если после него загружались другие данные.

Время исполнения JavaScript


Если несмотря на ускорение мобильных сетей страницы становятся медленнее, то наиболее вероятным виновником этого будет JavaScript. К сожалению, HTTP Archive начал собирать эти данные только в конце 2017 года, и с тех пор они кажутся стабильными.


Снижение в середине 2018 года, вероятно, связано с изменением корпуса тестируемых URL.

Обратите внимание, что абсолютная длительность исполнения (0,5 с) меньше, чем мы обычно встречаем в инструментах наподобие Lighthouse. Такие инструменты обычно замедляют исполнение JavaScript для эмулирования мобильного устройства, но в тестах HTTP Archive эта система была неисправной. Поэтому хотя это значение может быть реалистичным для телефонов среднего ценового диапазона, обычно считается, что бюджетные телефоны примерно в четыре раза медленнее.

Отвечаем на вопрос, стал ли веб более медленным


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

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

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

  1. Данные реальных пользователей из Chrome UX Report (CrUX)
  2. Наивное моделирование на основании изменений веб-сайтов и устройств

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

Данные из Chrome User Experience Report


Большим ограничением данных CrUX является то, что их начали собирать только с конца 2017 года. Но мы всё равно можем использовать их, чтобы посмотреть, стал ли веб медленнее за последние два с половиной года.

Стоит учесть, что в отличие от HTTP Archive, CrUX изучает весь домен, а не только главные страницы.

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

(Я беру среднее, а не медианное значение среди нескольких веб-сайтов, что не совсем правильно.)

Время загрузки страниц в США


Данные CrUX по США не демонстрируют ухудшения скорости страниц.

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


Метрики paint выглядят довольно стабильными. Largest Contentful Paint (время загрузки основного контента) это новая метрика, которая собирается только с середины 2019 года.

Остальной мир


Тенденция снижения метрики onLoad в США соответствует и мировым данным. Однако существуют значительные различия во времени загрузки страниц в разных странах, например, время onLoad в Индии почти вдвое выше, чем в Южной Корее.


Мы можем использовать данные CrUX, чтобы шире понять данные HTTP Archive. В январе 2020 года HTTP Archive сообщил, что медианное (50-й перцентиль) время загрузки на основании синтетических данных равно 18,7 с.

В противовес ему CrUX считает, что время загрузки составляет всего 5,8 с и это 75-й перцентиль.

(Стоит учесть, что мировые значения (Global) взяты просто как среднее и не взвешены по населению.)

Моделирование времени загрузки страниц


Мы можем создать теоретическую модель того, как изменения устройств, сетей и веб-сайтов влияют на общую скорость.

Модель будет неидеальной, но, надеемся, даст нам какое-то понимание.

Теоретическое время скачивания страниц


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

Скачивание файла размером с медианный мобильный веб-сайт в 2013 году заняло бы 1,7 с. Если скорость нашего соединения с того времени не изменилась, то сегодня на это бы потребовалось 4,4 с. Но при современной средней скорости подключения на это нужно всего 0,9 с.


На практике, веб-сайт не будет состоять из единственного запроса, а на скорость загрузки страницы будут влиять и другие факторы, например, скорость обработки процессором и задержка сервера. Время onLoad по данным HTTP Archive в 2-3 раз выше этой нижней границы.

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

(Я начинаю отсчёт с 2013, а не с 2011 года, потому что метрика веса страницы HTTP Archive начала измеряться единообразно только с этого времени.)

Процессор


Я не совсем понимаю, как подходить к этому параметру, но сделаю некоторые предположения.

У человека, использовавшего в 2013 году Galaxy S4, а теперь использующего Galaxy S10, вычислительная мощь процессора увеличилась в пять раз. Предположим, что с тех пор браузеры стали в четыре раза эффективнее. Если напрямую перемножить эти два числа, то мы получим улучшение в 20 раз.

С 2013 года вес JavaScript на странице увеличился в 3,7 раза, с 107 КБ до 392 КБ. Вероятно, с тех пор улучшились и минификация со сжатием, поэтому тот же объём кода на JavaScript умещается теперь в меньшее количество байтов. Давайте округлим этот коэффициент до шести. Вообразим, что вес JavaScript на странице пропорционален времени исполнения JavaScript.

В результате мы всё равно получим повышение скорости в 3,3 раза.

Заключение


Сегодня веб-сайты исполняют больше кода и они в разы объёмнее, чем веб-сайты десять лет назад. Тем не менее, я не считаю, что мобильный веб в восприятии пользователей в целом стал медленнее.

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


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

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



На правах рекламы


VDSina предлагает недорогие серверы с посуточной оплатой, каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!

Подробнее..

Microsoft отчиталась об успешном проведении эксперимента по созданию подводного дата-центра

15.09.2020 14:04:30 | Автор: admin
Летом 2018 года в рамках второй фазы испытаний проекта Natick по производству и эксплуатации экологичных и автономных сетевых систем, команда инженеров затопила в прибрежных водах Шотландии контейнер с небольшим дата-центром внутри.



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

Microsoft Project Natick это многолетние исследование по изучению методов производства и эксплуатации экологически устойчивых предварительно укомплектованных ЦОД стандартизированного формата и размера, которые можно быстро развернуть и оставить на годы с выключенным светом на морском дне.

Официальный блог проекта

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

Проект Natick начался еще в 2015 году. Тогда команда инженеров Microsoft разработала концепцию дата-центра в затопленном контейнере и провела испытания первого прототипа, названного Leona Philpot.


Leona Philpot пробный дата-центр в контейнере разработки Microsoft, август 2015 года

Именно на Leona Philpot инженеры Microsoft опробовали систему охлаждения оборудования за счет естественной внешней среды морской воды. Испытания проводились в Тихом океане, в 1 километре от побережья США. Конкретные локации не упоминаются, но, судя по пейзажам на фотографиях, слишком далеко на север инженеры тогда не забрались: вполне вероятно, первые испытания проводились вблизи побережья Калифорнии.

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


Сборка Leona Philpot на берегу перед погружением

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

Испытания длились с августа по октябрь 2015 года, заняли 105 дней и показали, что в целом концепция жизнеспособна и ее можно развивать: на сборку и установку контейнерного дата-центра требуется три месяца против года на строительство очереди дата-центра, развертывание не вызывает особых сложностей, так как человечество уже давно использует погружные аппараты, а управлять дата-центром можно удаленно с редкими инспекциями внешнего состояния корпуса. Сам дата-центр в контейнере является типовым решением и может продаваться предварительно укомплектованным.

В 2018 году эксперимент повторился. На этот раз инженеры собрали конфигурацию, близкую к коммерческой: выросло число серверов внутри контейнера, да и сам контейнер стал по размерам больше похож на железнодорожную цистерну, чем на бочку. Если быть точным, то это и есть цистерна. За основу корпуса взяли доработанный транспортный контейнер стандарта ISO, который активно используется по всему миру в грузоперевозках. Такое решение сняло вопрос не только по производству корпусов дата-центра, но и по его транспортировке стандартной логистикой к месту погружения. Планируемый ресурс бесперебойной работы итогового продукта пять лет под водой. Прототип получил название Northern Isles Северные острова.


Основные разработчики проекта Natick, слева направо: Майк Шепперд, старший инженер по исследованиям и разработкам, Сэм Огден, старший инженер-программист, Спенсер Фауэрс, старший технический специалист, Эрик Петерсон, исследователь и Бен Катлер, менеджер проекта

Теперь дата-центр затопили в холодных водах Шотландии, недалеко от Оркнейских островов. Контейнер опустили на морское дно, на глубину 35 метров, а подключался он к земле силовым и оптоволоконным кабелем.

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

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



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


Фото загруженной в контейнер мегастойки из 12 серверных стоек, в общей сложности на 864 сервера, 2018 год

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


Дата-центр после двух лет нахождения на морском дне

И вот, вчера, 14 сентября, Microsoft отчиталась о результатах своего эксперимента после подъема дата-центра.

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

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



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



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

Кроме того, разработка Microsoft может подстегнуть и развитие зеленой энергетики, то есть вызвать каскадный эффект. Пока инженерам приходится тащить питание вместе с оптоволоконным кабелем с суши, но при развитии автономных приливных электростанций дата-центры проекта Natick можно будет запитывать от них. Это не только укладывается в концепцию зеленого ДЦ, но и значительно повышает автономность дата-центра, делая его в плане питания практически независимым от происходящего на берегу.



На правах рекламы


Виртуальные серверы с защитой от DDoS-атак и новейшим железом, серверы размещены в одном из лучших российских дата-центров DataPro. Всё это про наши эпичные серверы. Максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe! Поспешите заказать.

Подробнее..

Разбираемся с FreePBX и интегрируем его с Битрикс24 и не только

09.09.2020 16:16:51 | Автор: admin

Битрикс24 - это огромный комбайн, который совмещает и CRM, и документооборот, и учет и еще много разных вещей, которые очень нравятся менеджерам и не очень нравятся IT персоналу. Портал используют очень много небольших и средних компаний, в том числе небольшие клиники, производственники и даже салоны красоты. Основной функцией, которую "любят" менеджеры является интеграция телефонии и CRM, когда любой звонок сразу фиксируется в CRM, создаются карточки клиента, при входящем отображается информация о клиенте и сразу видно кто он такой, что ему можно продать и сколько он должен. Но телефония от Битрикс24 и ее интеграция с CRM стоит денег, иногда немалых. В статье я расскажу опыт интеграции с открытыми инструментами и популярной IP АТС FreePBX, а также рассмотрю логику работы различных частей

Я работаю на аутсорсе в компании, которая занимается продажей и настройкой, интеграцией IP телефонии. Когда меня спросили, можем ли мы вон той вот и вот этой вот компании предложить что то для интеграции Битрикс24 с АТС, которые стоят у клиентов, а также с виртуальными АТС на различных VDS компании, я пошел в Гугл. И он мне конечно же выдал ссылку на статью в хабр, где есть и описание, и github, и вроде все работает. Но при попытке попользоваться этим решением вылезло, что Битрикс24 уже не тот, что ранее, и надо многое переделывать. Кроме того, FreePBX это вам не голый астериск, тут думать надо как совместить удобство использования и хардкорный диалплан в конфиг-файлах.

Изучаем логику работы

Итак для начала, как все это должно работать. При поступления звонка извне на АТС (событие SIP INVITE от провайдера) начинается обработка диалплана(плана набора, dialplan) - правил, что и в каком порядке делать со звонком. Из первого пакета можно получить много информации, которую потом можно использовать в правилах. Отличным инструментом для изучения внутренностей SIP является анализатор sngrep (ссылка) который просто ставится в популярных дистрибутивах через apt install/yum install и подобное, но можно и из исходников собрать. Посмотрим лог звонка в sngrep

В упрощенном виде диалплан занимается только первым пакетом, иногда также в процессе разговора совершается перевод звонков, нажатия кнопок (DTMF), разные интересности типа FollowMe, RingGroup, IVR и прочего.

Что внутри Invite пакета

Собственно большинство простых диалпланов работают с первыми двумя полями и вся логика крутится вокруг DID и CallerID. DID - куда звоним, CallerID - кто звонит.

Но ведь у нас фирма а не один телефон - и значит в АТС скорее всего есть группы вызова (одновременный/последовательный звонок нескольких аппаратов) на городских номерах (Ring Group), IVR (Здравствуйте, вы позвонили... Нажмите один для...), Автоответчики (Phrases), Временные условия (Time Conditions), Переадресация на другие номера или на сотовый (FollowMe, Forward). Это значит, что однозначно определить кому на самом деле придет вызов и с кем будет разговор при поступлении вызова очень сложно. Вот пример начала прохождения типового вызова в АТС наших клиентов

После успешного входа звонка в АТС происходит путешествие его по диалплану в разных "контекстах". Контекст с точки зрения Asterisk - это нумерованный набор команд, каждая из которых содержит фильтр по набранному номеру (он называется exten, для наружного вызова на начальном этапе exten=DID). Командами в строке диалплана может быть все что угодно - внутренние функции (например позвонить внутреннему абоненту - Dial(), положить трубку - Hangup()), условные операторы (IF, ELSE, ExecIF и подобные), переходы к другим правилам этого контекста (Goto, GotoIF), переход другим контекстам в виде вызова функций (Gosub, Macro). Отдельно стоит директива include имя_контекста, которая добавляет команды другого контекста в конец текущего контекста. Команды, включенные через include всегда выполняются после команд текущего контекста.

Вся логика работы FreePBX построена на включении друг в друга разных контекстов через include и вызов через Gosub, Macro и обработчики Handler. Рассмотрим контекст входящих вызовов FreePBX

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

Типовая схема настройки типичной офисной АТС показана ниже. При вызове во входящих маршрутах ищется DID, по нему проверяются временные условия, если все в порядке - запускается голосовое меню. Из него по кнопке 1 или таймауту выход на группу дозвона операторов. После окончания звонка вызывается макрос hangupcall, после которого ничего уже в диалплане выполнить не удастся, кроме специальных обработчиков (hangup handler).

Где в этом алгоритме звонка мы должны поставлять информацию о начале звонка в CRM, где начинать запись, где оканчивать запись и отсылать ее вместе с информацией о звонке на CRM?

Интеграция с внешними системами

Что такое интеграция АТС и CRM? Это настройки и программы, которые конвертируют данные и события между двумя этими платформами и пересылают друг другу. Самым распространенным способом взаимодействия независимых систем является API, а самым популярным способом доступа к API является HTTP REST. Но только не для asterisk.

Внутри Asterisk есть:

  • AGI - синхронный вызов внешних программ/компонентов, используется в основном в диалплане, есть библиотеки типа phpagi, PAGI

  • AMI - текстовый TCP сокет, работающий по принципу подписки на события и ввода текстовых команд, напоминает SMTP изнутри, умеет отслеживать события и управлять вызовами, ,есть библиотека PAMI - самая популярная для создания связи с Asterisk

Пример вывода AMI

Event: NewchannelPrivilege: call,allChannel: PJSIP/VMS_pjsip-0000078bChannelState: 4ChannelStateDesc: RingCallerIDNum: 111222CallerIDName: 111222ConnectedLineNum: ConnectedLineName: Language: enAccountCode:Context: from-pstnExten: sPriority: 1Uniqueid: 1599589046.5244Linkedid: 1599589046.5244

  • ARI - смесь того, другого, все через REST, WebSocket, в формате JSON - но вот со свежими библиотеками и обертками не очень, на вскидку нашлись (phparia, phpari) которые становились в своем развитии года 3 назад.

Пример вывода ARI при инициации звонка

{ "variable":"CallMeCallerIDName", "value":"111222", "type":"ChannelVarset", "timestamp":"2020-09-09T09:38:36.269+0000", "channel":{ "id":"1599644315.5334", "name":"PJSIP/VMSpjsip-000007b6", "state":"Ring", "caller":{ "name":"111222", "number":"111222" }, "connected":{ "name":"", "number":"" }, "accountcode":"", "dialplan":{ "context":"from-pstn", "exten":"s", "priority":2, "appname":"Stasis", "appdata":"hello-world" }, "creationtime":"2020-09-09T09:38:35.926+0000", "language":"ru" }, "asteriskid":"48:5b:aa:aa:aa:aa", "application":"hello-world" }

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

  • Отследить начало вызова, куда его перевели, вытащить CallerID, DID, времена начала и конца, может быть данные из директории (для поиска связи телефона и пользователя CRM)

  • Начать и окончить запись звонка, сохранить в нужном формате, сообщить по окончании записи где лежит файл

  • Инициировать звонок по внешнему событию (из программы), позвонить внутреннему номеру, внешнему и соединить их

  • Опционально: интегрировать с CRM, группами дозвона и FollowME для автоматического перевода звонков при отсутствии на месте(по информации CRM)

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

Придумываем интеграцию заново

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

Вот пример задания своей переменной для времени начала звонка (s - это специальный номер в диалплане, который выполняется ДО начала поиска по DID)

[ext-did-custom]exten => s,1,Set(CallStart=${STRFTIME(epoch,,%s)})
Пример AMI события по этой строке

Event: Newchannel

Privilege: call,all

Channel: PJSIP/VMS_pjsip-0000078b

ChannelState: 4

ChannelStateDesc: Ring

CallerIDNum: 111222

CallerIDName: 111222

ConnectedLineNum:

ConnectedLineName:

Language: en

AccountCode:

Context: from-pstn

Exten: s

Priority: 1

Uniqueid: 1599589046.5244

Linkedid: 1599589046.5244

Application: Set AppData:

CallStart=1599571046

Поскольку FreePBX перезаписывает файлы extention.conf и extention_additional.conf, мы будем использовать файл extention_custom.conf

Полный код extention_custom.conf
[globals];; Проверьте пути и права на папки - юзер asterisk должен иметь права на запись;; Сюда будет писаться разговорыWAV=/var/www/html/callme/records/wav MP3=/var/www/html/callme/records/mp3;; По этим путям будет воспроизводится и скачиваться записьURLRECORDS=https://www.host.ru/callmeplus/records/mp3;; Адрес для калбека при исходящем вызовеURLPHP=https://www.host.ru/callmeplus;; Да пишем разговорыRECORDING=1;; Это макрос для записи разговоров в нашу папку. ;; Можно использовать и системную запись, но пока пусть будет эта - ;; она работает[recording]exten => ~~s~~,1,Set(LOCAL(calling)=${ARG1})exten => ~~s~~,2,Set(LOCAL(called)=${ARG2})exten => ~~s~~,3,GotoIf($["${RECORDING}" = "1"]?4:14)exten => ~~s~~,4,Set(fname=${UNIQUEID}-${STRFTIME(${EPOCH},,%Y-%m-%d-%H_%M)}-${calling}-${called})exten => ~~s~~,5,Set(datedir=${STRFTIME(${EPOCH},,%Y/%m/%d)})exten => ~~s~~,6,System(mkdir -p ${MP3}/${datedir})exten => ~~s~~,7,System(mkdir -p ${WAV}/${datedir})exten => ~~s~~,8,Set(monopt=nice -n 19 /usr/bin/lame -b 32  --silent "${WAV}/${datedir}/${fname}.wav"  "${MP3}/${datedir}/${fname}.mp3" && rm -f "${WAV}/${fname}.wav" && chmod o+r "${MP3}/${datedir}/${fname}.mp3")exten => ~~s~~,9,Set(FullFname=${URLRECORDS}/${datedir}/${fname}.mp3)exten => ~~s~~,10,Set(CDR(filename)=${fname}.mp3)exten => ~~s~~,11,Set(CDR(recordingfile)=${fname}.wav)exten => ~~s~~,12,Set(CDR(realdst)=${called})exten => ~~s~~,13,MixMonitor(${WAV}/${datedir}/${fname}.wav,b,${monopt})exten => ~~s~~,14,NoOp(Finish if_recording_1)exten => ~~s~~,15,Return();; Это основной контекст для начала разговора[ext-did-custom];; Это хулиганство, делать это так и здесь, но работает - добавляем к номеру '8'exten =>  s,1,Set(CALLERID(num)=8${CALLERID(num)});; Тут всякие переменные для скриптаexten =>  s,n,Gosub(recording,~~s~~,1(${CALLERID(number)},${EXTEN}))exten =>  s,n,ExecIF(${CallMeCallerIDName}?Set(CALLERID(name)=${CallMeCallerIDName}):NoOp())exten =>  s,n,Set(CallStart=${STRFTIME(epoch,,%s)})exten =>  s,n,Set(CallMeDISPOSITION=${CDR(disposition)});; Самое главное! Обработчик окончания разговора. ;; Обычные пути обработки конца через (exten=>h,1,чтототут) в FreePBX не работают - Macro(hangupcall,) все портит. ;; Поэтому вешаем Hangup_Handler на окончание звонкаexten => s,n,Set(CHANNEL(hangup_handler_push)=sub-call-from-cid-ended,s,1(${CALLERID(num)},${EXTEN}));; Обработчик окончания входящего вызова[sub-call-from-cid-ended];; Сообщаем о значениях при конце звонкаexten => s,1,Set(CDR_PROP(disable)=true)exten => s,n,Set(CallStop=${STRFTIME(epoch,,%s)})exten => s,n,Set(CallMeDURATION=${MATH(${CallStop}-${CallStart},int)});; Статус вызова - Ответ, не ответ...exten => s,n,Set(CallMeDISPOSITION=${CDR(disposition)})exten => s,n,Return;; Обработчик исходящих вызовов - все аналогичено[outbound-allroutes-custom];; Записьexten => _.,1,Gosub(recording,~~s~~,1(${CALLERID(number)},${EXTEN}));; Переменныеexten => _.,n,Set(__CallIntNum=${CALLERID(num)})exten => _.,n,Set(CallExtNum=${EXTEN})exten => _.,n,Set(CallStart=${STRFTIME(epoch,,%s)})exten => _.,n,Set(CallmeCALLID=${SIPCALLID});; Вешаем Hangup_Handler на окончание звонкаexten => _.,n,Set(CHANNEL(hangup_handler_push)=sub-call-internal-ended,s,1(${CALLERID(num)},${EXTEN}));; Обработчик окончания исходящего вызова[sub-call-internal-ended];; переменныеexten => s,1,Set(CDR_PROP(disable)=true)exten => s,n,Set(CallStop=${STRFTIME(epoch,,%s)})exten => s,n,Set(CallMeDURATION=${MATH(${CallStop}-${CallStart},int)})exten => s,n,Set(CallMeDISPOSITION=${CDR(disposition)});; Вызов скрипта, который сообщит о звонке в CRM - это исходящий, ;; так что по факту окончанияexten => s,n,System(curl -s ${URLPHP}/CallMeOut.php --data action=sendcall2b24 --data ExtNum=${CallExtNum} --data call_id=${SIPCALLID} --data-urlencode FullFname='${FullFname}' --data CallIntNum=${CallIntNum} --data CallDuration=${CallMeDURATION} --data-urlencode CallDisposition='${CallMeDISPOSITION}')exten => s,n,Return

Особенность и отличием от оригинального диалплана авторов исходной статьи -

  • Диалплан в формате .conf, так как этого хочет FreePBX (да он умеет .ael, но не все версии и не всегда это удобно)

  • Вместо обработки окончания через exten=>h введена обработка через hangup_handler, потому что FreePBX диалплан заработал только с ним

  • Поправлена строка вызова скрипта, добавлены кавычки и внешний номер звонка ExtNum

  • Обработки вынесена в _custom контексты и позволяют не трогать и не править конфиги FreePBX - входящие через [ext-did-custom], исходящие через [outbound-allroutes-custom]

  • Нет привязки к номерам - файл универсален и нуждается в настройке только пути и ссылка на сервер

Для начала работы нужно еще пустить скрипты в AMI по логину и паролю - для этого в FreePBX тоже есть _custom файл

Файл manager_custom.conf
;;  это логин[callmeplus];; это парольsecret = trampampamturlaladeny = 0.0.0.0/0.0.0.0;; я работаю с локальной машиной - но если надо, можно и другие прописатьpermit = 127.0.0.1/255.255.255.255read = system,call,log,verbose,agent,user,config,dtmf,reporting,cdr,dialplanwrite = system,call,agent,log,verbose,user,config,command,reporting,originate

Эти оба файла надо поместить в /etc/asterisk, затем перечитать конфиги (или перезапустить астериск)

# astrisk -rv  Connected to Asterisk 16.6.2 currently running on freepbx (pid = 31629)#freepbx*CLI> dialplan reload     Dialplan reloaded.#freepbx*CLI> exit

Теперь перейдем к PHP

Инициализация скриптов и создание сервиса

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

Как только звонок поступает, возникает событие NewExten начиная с родительского контекста [from-pstn], затем идут все события по порядку следования строк в контекстах. При получении информации из заданных в диалплане _custom переменных CallMeCallerIDName и CallStart вызывается

  1. Функция запроса UserID, соответствующий внутреннему номеру, куда пришел звонок. А если это группа дозвона? Вопрос политический, надо создать звонок всем сразу (когда звонят все сразу) или создавать по мере обзвона при поочередном звонке? У большинства клиентов стоит стратегия Fisrt Available, поэтому с этим нет проблем, звонит только один. Но решать вопрос надо

  2. Функция регистрации звонка в Битрикс24, которая возвращает CallID, необходимый потом для сообщения о параметрах звонка и ссылке на запись. Требует или внутренний номер или UserID

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

Поскольку модуль CallMeIn.php должен работать непрерывно, для него был создан SystemD файл запуска callme.service, который надо положить в /etc/systemd/system/callme.service

[Unit]Description=CallMe[Service]WorkingDirectory=/var/www/html/callmeplusExecStart=/usr/bin/php /var/www/html/callmeplus/CallMeIn.php 2>&1 >>/var/log/callmeplus.logExecStop=/bin/kill -WINCH ${MAINPID}KillSignal=SIGKILLRestart=on-failureRestartSec=10s#тут надо смотреть,какие права на папки#User=www-data  #Ubuntu - debian#User=nginx #Centos[Install]WantedBy=multi-user.target

инициализация и запуск скрипта происходит через systemctl или service

# systemctl enable callme# systemctl start callme

Сервис будет сам перезапускаться по необходимости (при падениях). Сервис слежения за входящими не требует установки веб сервера, нужен только php (который точно есть на сервере FeePBX). Но при отсутствии доступа к записям звонков через Веб сервер (еще и с https) не будет возможности прослушивать записи разговоров.

Теперь поговорим про исходящие звонки. У скрипта CallMeOut.php две функции:

  • Инициация звонка при поступлении запроса на php скрипт (в том числе по кнопке "Позвонить" в самом битриксе). Без веб сервера не работает, запрос поступает через HTTP POST, в запросе содержится токен

  • Сообщение о звонке, его параметрах и записях в Битрикс. Происходит по инициативе Asterisk в диалплане [sub-call-internal-ended] при окончании звонка

Веб сервер нужен только для двух вещей - загрузка файлов записей битриксом (по HTTPS) и вызов скрипта CallMeOut.php. Можно использовать встроенный сервер FreePBX, файлы для которого лежат /var/www/html, можно установить другой сервер или прописать другой путь.

Веб сервер

Оставим настройку веб сервера на самостоятельное изучение (тыц, тыц, тыц). Если у вас нет домена, можно попробовать FreeDomain( https://www.freenom.com/ru/index.html), которые на халяву дадут вам имя для вашего белого IP (не забудьте пробросить порты 80, 443 через роутер, если внешний адрес есть только на нем). Если вы только создали DNS домен, то надо подождать (от 15 минут до 48 часов) пока все сервера прогрузятся. По опыту работы с отечественными порвайдерами - от 1 часа до суток.

Автоматизация установки

На github начата разработка инсталятора, чтоб можно было устанавливать еще проще. Но гладко было на бумаге - пока устанавливаем все это вручную, благо после ковыряния во всем этом стало кристально ясно , что с кем дружит, кто куда ходит и как это дебажить. Инсталлятора пока нет (

Docker

Если хочется быстро попробовать решение - есть вариант с Docker - быстро создать контейнер, дать ему порты наружу, подсунуть файлы настроек и попробовать (это вариант с LetsEncrypt контейнером, если сертификат уже есть, просто нужно перенаправить обратный прокси на веб сервер FreePBX (ему мы дали другой порт - 88), LetsEncrypt в докере по мотивам этой статьи

Запускать файл надо в скачанной папке проекта (после git clone), но предварительно залезть в конфиги астериска (папка asterisk) и прописать там пути к записям и URL вашего сайта

version: '3.3'services:  nginx:    image: nginx:1.15-alpine    ports:      - "80:80"      - "443:443"    volumes:      - ./nginx/ssl_docker.conf:/etc/nginx/conf.d/ssl_docker.conf  certbot:    image: certbot/certbot  freepbx:    image: flaviostutz/freepbx    ports:      - 88:80 # для настройки      - 5060:5060/udp      - 5160:5160/udp      - 127.0.0.1:5038:5038 # для CallMeOut.php#      - 3306:3306      - 18000-18100:18000-18100/udp    restart: always    environment:      - ADMIN_PASSWORD=admin123    volumes:      - backup:/backup      - recordings:/var/spool/asterisk/monitor      - ./callme:/var/www/html/callme      - ./systemd/callme.service:/etc/systemd/system/callme.conf      - ./asterisk/manager_custom.conf:/etc/asterisk/manager_custom.conf      - ./asterisk/extensions_custom.conf:/etc/asterisk/extensions_custom.conf#      - ./conf/startup.sh:/startup.shvolumes:  backup:  recordings:

Этот файл docker-compose.yaml, запускается через

docker-compose up -d

Если nginx не запустился, значит что то не так с конфигурацией в папке nginx/ssl_docker.conf

Другие интеграции

А почему бы заодно не сунуть несколько CRM в скрипты, подумали мы. Изучили несколько API других CRM, особенно бесплатной встроенной в некоторые АТС - ShugarCRM и Vtiger, и да! можно, принцип тот же. Но это уже другая история, которую потом будем заливать на гитхаб отдельно.

Ссылки

Дисклеймер: любые совпадения с реальность вымышлены и это был не я,

Подробнее..

Построение сетевой инфраструктуры на базе Nebula. Часть 1 задачи и решения

24.09.2020 12:15:14 | Автор: admin


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


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


Для чего нужен очередной облачный сервис?


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


Сеть новая заботы старые


При вводе в эксплуатацию нового узла сети после монтажа и подключения оборудования начинается первоначальная настройка. С точки зрения большого начальства ничего сложного: Берем рабочую документацию по проекту и начинаем настраивать... Это так здорово говорится, когда все сетевые элементы стоят в одном ЦОД. Если же они разбросаны по филиалам, начинается головная боль с обеспечением удаленного доступа. Такой вот замкнутый круг: чтобы получить удаленный доступ по сети, нужно настроить сетевое оборудование, а для этого нужен доступ по сети...


Приходится придумывать различные схемы для выхода из вышеописанного тупика. Например, ноутбук с доступом в Интернет через USB 4G модем подключается через патчкорд к настраиваемой сети. На этом ноутбуке поднимается VPN клиент, и через него сетевой администратор из штаб-квартиры пытается получить доступ к сети филиала. Схема не самая прозрачная даже если привезти ноутбук с заранее настроенным VPN на удаленную площадку и попросить его включить, далеко не факт что всё заработает с первого раза. Особенно если речь о другом регионе с другим провайдером.


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


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


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


Примечание. Самые печальные проколы начинаются со слов: Да что там этот Zabbix (Nagios,OpenView и т.д.) настраивать? Я сейчас вот его быстренько подниму и готово!


От внедрения к эксплуатации


Рассмотрим конкретный пример.


Получено тревожное сообщение о том, что где-то не отвечает точка доступа WiFi.


Где она находится?


Разумеется, у хорошего сетевого администратора есть свой личный справочник, в котором всё записано. Вопросы начинаются, когда этой информацией нужно делиться. Например, надо срочно послать гонца, чтобы разобраться на месте, а для этого нужно выдать что-то вроде: Точка доступа в бизнес-центре на улице Строителей, дом 1, на 3-м этаже, кабинет N 301 рядом с входной дверью под потолком.


Допустим, нам повезло и точка доступа питается через PoE, а коммутатор позволяет её перезагрузить удаленно. Ехать не надо, но нужен удаленный доступ до коммутатора. Остается настроить проброс портов через PAT на маршрутизаторе, разобраться с VLAN для подключения извне и так далее. Хорошо, если все настроено заранее. Работа, может, и не сложная, но делать нужно.


Итак, точку по питанию перезагрузили. Не помогло?


Допустим, что-то не так в аппаратной части. Теперь ищем информацию о гарантии, начале эксплуатации и других интересующих деталях.


Кстати о WiFi. Использование домашнего варианта WPA2-PSK, в котором один ключ на все устройства в корпоративной среде не рекомендуется. Во-первых, один ключ на всех это попросту небезопасно, во-вторых, когда один сотрудник увольняется, то приходится менять этот общий ключ и заново выполнять настройки на всех устройствах у всех пользователей. Чтобы избежать подобных неприятностей, существует WPA2-Enterprise с индивидуальной аутентификацией для каждого пользователя. Но для этого нужен RADIUS сервер ещё одна инфраструктурная единица, которую надо контролировать, делать резервные копии и так далее.


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


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


Как это выглядит при использовании Nebula?


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


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


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


Разумеется, необходимую инфраструктуру для хранения информации, как учетной, так и настроек предоставляет Zyxel Nebula.



Рисунок 1. Отчет безопасности Nebula Control Center.


А что с настройкой доступа? Открытием портов, пробросом трафика через входящий шлюз, всем тем, что администраторы безопасности ласково называют: наковырять дырок? К счастью, этого всего делать не нужно. Устройства под управлением Nebula устанавливают исходящее соединение. И администратор для настройки подключается не к отдельному устройству, а к облаку. Nebula выступает посредником между двумя соединениями: с устройством и с компьютером сетевого администратора. Это означает, что этап с вызовом приходящего админа можно свести к минимуму, либо пропустить вовсе. И никаких дополнительных дырок на файрволе.


А как же RADUIS сервер? Ведь нужна какая-то централизованная аутентификация!


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


Отдельно стоит сказать о WPA2-Enterprise, для которого нужен отдельный сервис аутентификации. У Zyxel Nebula есть собственный аналог DPPSK, который позволяет использовать WPA2-PSK с индивидуальным ключом для каждого пользователя.


Неудобные вопросы


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


А это точно безопасно?


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


Использование шифрования для защиты трафика от посторонних глаз это читателям более или менее знакомо.


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


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


Насколько Nebula дороже или дешевле приходящего админа?


Всё познается в сравнении. Базовые функции Nebula доступны бесплатно. Собственно, что может быть ещё дешевле?


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


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


Если же говорить на тему выгодно или не выгодно приобретать платный пакет услуг (Pro-Pack), то примерный ответ может звучать так: если организация маленькая, можно обойтись базовой версией, если организация растет, то имеет смысл подумать о Pro-Pack. Различие между версиями Zyxel Nebula можно посмотреть в таблице 1.


Таблица 1. Различия наборов функций базовой версии и версии Pro-Pack для Nebula.



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


А что с защитой трафика?


Nebula использует протокол NETCONF для обеспечения безопасности работы с сетевым оборудованием.


NETCONF может работать поверх нескольких транспортных протоколов:



Если сравнивать NETCONF с другими методами, например, управление через SNMP следует отметить, что NETCONF поддерживает исходящее TCP-соединение для преодоления барьера NAT и считается более надежным.


Что с поддержкой оборудования?


Разумеется, не стоит превращать серверную в зоопарк с представителями редких и вымирающих видов оборудования. Крайне желательно, чтобы оборудование, объединенное технологией управления, закрывало все направления: от центрального коммутатора до точек доступа. Инженеры Zyxel позаботились о такой возможности. Под управлением Nebula работает множество устройств:


  • центральные коммутаторы 10G;


  • коммутаторы уровня доступа;


  • коммутаторы с PoE;


  • точки доступа;


  • сетевые шлюзы.



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


Постоянное развитие


Сетевые устройства с традиционным методом управления имеют только один путь совершенствования изменение самого устройства, будь то новая прошивка или дополнительные модули. В случае с Zyxel Nebula есть дополнительный путь для улучшений через совершенствование облачной инфраструктуры. Например, после обновления Nebula Control Center (NCC) до версии 10.1. (21 сентября 2020) пользователям доступны новые возможности, вот некоторые из них:


  • владелец организации теперь может передать все права владения другому администратору в той же организации;


  • новая роль под названием Представитель владельца, которая имеет те же права, что и владелец организации;


  • новая функция обновления прошивки в масштабах всей организации (функция Pro-Pack);


  • в топологию добавлены две новые опции: перезагрузка устройства и включение и выключение питания порта PoE (функция Pro-Pack);


  • поддержка новых моделей точек доступа: WAC500, WAC500H, WAC5302D-Sv2 и NWA1123ACv3;


  • поддержка аутентификации по ваучерам с печатьюQR-кодов (функцияPro-Pack).



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


  1. Telegram chat Zyxel


  2. Форум по оборудованию Zyxel


  3. Много полезного видео на канале Youtube


  4. Zyxel Nebula простота управления как основа экономии


  5. Различие между версиями Zyxel Nebula


  6. Zyxel Nebula и рост компании


  7. Сверхновое облако Zyxel Nebula экономичный путь к безопасности?


  8. Zyxel Nebula Options for Your Business


Подробнее..

Прогресс внедрения IPv6 за 10 лет

27.09.2020 12:08:21 | Автор: admin
Наверное, все, кто занимается внедрением IPv6 или, по крайней мере, интересуется этим набором протоколов, знает про график IPv6 трафика Google. Аналогичные данные собирают Facebook и APNIC, но почему-то именно на данные Google принято ориентироватся (хотя, например, там не видно Китая).
График подвержен заметным флуктуациям в выходные показания выше, а в будние дни заметно ниже, сейчас разница превосходит 4 процентных пункта.
Мне стало любопытно, что будет, если убрать этот шум и можно ли будет увидеть что-то интесное, если очистить данные от недельных флуктуаций.

Я скачал файлик с Google и посчитал скользящее среднее. Результаты за 29 февраля я выкинул, как выравнивать, не придумал, и, кажется, это ни на что не влияет.
Вот результат:


Вот тут hi-res.

Из интересных наблюдений:
на графике 2020 года хорошо заметен момент начала массовых карантинов третья неделя марта;
первая неделя мая сопровождается всплеском на пару процентных пунктов, видимо, не только в России принято в это время не работать.
непонятна природа предшествующего всплеска, произошедшего на третьей неделе апреля в 2017, на четвёртой неделе марта в 2016 и в 2018 и на четвертой неделе апреля в 2019 году. Я думаю, это какой-то праздник, связанный с лунным календарём, но что именно не знаю? Ортодоксальная Пасха? Какой-то национальный праздник в Индии? Буду рад идеям.
всплеск в конце ноября, вероятно, связан с Днём Благодарения в США.
после всплесков в конце августа обычно случается полтора месяца стагнации или даже отката назад, чем дальше, тем заметнее. К середине октября этот эффект пропадает. Я полагаю, это связанно с началом учебного года, университетские кампусы не в достаточной степени поддерживают IPv6. Потом другие силы компенсируют это падение.
и, конечно, конец года самый большой всплеск.

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

Какие ещё неочевидные вещи вы заметили?
Подробнее..

Recovery mode Древний костыль на старом костыле

23.09.2020 20:15:33 | Автор: admin

Начну без обиняков, как-то раз меня постигло откровение(ну не сильно мощное скажу по-честному) и возникла идея напечатать программу которая передает изображение с клиента на сервер. Достаточно просто да? Ну для программиста со стажем так и будет. Условия просты - не использовать сторонние библиотеки. В принципе немного сложнее, но если учесть что придется разбираться и искать примеры, ну такое себе занятие. Я решил, что эта задача мне по плечу. Плюс желательно чтобы было кода столько, чтобы его можно было запостить на форуме, в случае если понадобится помощь. В первую очередь мой взгляд пал на FTP, к слову ОС в которой разрабатывается Windows. Плюс FTP в том, что можно через него передать не только изображение, а любой файл. Скачав Filezilla Server, расшарив одну директорию на чтение/запись и создав юзера с паролем, попробовал подключится Filezilla Client все работало. Создал простенький пример кода на С/С++:

#include <iostream>void main(){FILE* fs;fopen_s(&fs, "1.txt", "w");if (fs){    fwrite("user\r\npassword\r\nsend D:\\share\\1.txt\r\nbye", 1, sizeof("user\r\npassword\r\nsend D:\\share\\1.txt\r\nbye"), fs);    fwrite("\000", 1, sizeof("\000"), fs);    fclose(fs);}system("ftp -s:1.txt 127.0.0.1");}

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

Не найдя ответа на куче форумов, я оставил данный код и решил использовать интерфейс для сетей сокеты. У меня уже был опыт передачи массива char'ов для другой программы. Кстати можете почитать у Таненбаума, Компьютерные сети, в главе про транспортный уровень. Там есть пример клиента и сервера, правда не для соединения "много клиентов - один сервер", а только "один клиент - один сервер". Поскольку передача идет через Интернет, то нужно зашифровать хоть как-то данные. Для этого используется блочный шифр - сеть Фейстеля. Плюсом на сервере надо сделать несколько(больше одного клиента) клиентов. Для этого воспользуемся Thread'ами, изображение для передачи будет брать скриншот экрана с клиента шифроваться и передаваться на сервер, на котором будет расшифровано и сразу же выведено на экран через дефолтную программу для открытия *.tga изображения.

Код сервера:

#include <iostream>#include <WinSock.h>#pragma comment (lib,"WS2_32.lib")#include <fstream>#include <algorithm>#include <string>#include <iterator>#include <vector>void error(const char* msg){    //perror(msg);    std::cout<<'\n'<<WSAGetLastError();    WSACleanup();    std::cin.ignore();    exit(1);}void bzero(char*buf, int l){    for (int i = 0; i < l; i++)        buf[i] = '\0';}struct arg_s{    unsigned char* buffer2;    bool exit;};char** buffer;struct arg_sa{    struct arg_s* lalk;    int current;};#define type struct arg_saint sockfd, * newsockfd;//слушающий и массив клиентских сокетовint buflen2 = 10292000;//максимальный размер изображения в байтах для RGBA*Width*Heightstruct sockaddr_in *cli_addr;int* clilen;int currentclient,cc;//сс-клиент по счету(для записи инкремента имени файла клиента изображения)typedef unsigned long long uint64_t;typedef unsigned int uint32_t;#define N 8//размер блока#define F32 0xFFFFFFFFuint32_t RK[N];//раундовые ключи#define size64 sizeof(uint64_t)#define ROR(x,n,xsize)((x>>n)|(x<<(xsize-n)))#define ROL(x,n,xsize)((x<<n)|(x>>(xsize-n)))#define RKEY(r)((ROR(K,r*3,size64*8))&F32)const uint64_t K = 0x96EA704CFB1CF671;//ключ шифрованияstruct hostent* server;uint32_t F(uint32_t subblk, uint32_t key){    return subblk + key;//функция шифрования}void createRoundKeys(){    for (int i = 0; i < N; i++)        RK[i] = (ROR(K, i * 8, size64 * 8)) & F32;}uint64_t decrypt(uint64_t c_block)//расшифровка блоков сетью фейстеля{    //select subblocks    uint32_t left = (c_block >> 32) & F32;    uint32_t right = c_block & F32;    uint32_t left_, right_;//subblock in the end of round    for (int r = N - 1; r >= 0; r--)    {        uint32_t fk = F(left, RK[r]);        left_ = left;        right_ = right ^ fk;        if (r > 0)//swap places to next round        {            left = right_;            right = left_;        }        else //last round not swap        {            left = left_;            right = right_;        }    }    //collect subblock in block    uint64_t block = left;    block = (block << 32) | (right & F32);    return block;}void session_(LPVOID args)//функция потока ля каждого клиента{    int current = currentclient++;    bzero((char*)&(cli_addr[current]), sizeof(&(cli_addr[current])));    newsockfd[current] = accept(sockfd, (struct sockaddr*)&(cli_addr[current]), &(clilen[current]));    if (newsockfd[current] < 0)    {        error("Error on accept\n");    }    char* s = new char[100];    int n = recv(newsockfd[current], s, 100, 0);    int buflen2 = atoi(s);//получаем число байтов изображения    FILE* f;    std::string name = "Screen";    cc++;    _itoa_s(cc, s, 100, 10);    name += s;    name += ".tga";    fopen_s(&f,name.c_str(), "wb");//создаем файл изображения с увеличиваещимся на 1 именем, чтобы не перезаписать    if (f != NULL)    {        unsigned char tgaHeader[12] = { 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 };        unsigned char header[6];        n = recv(newsockfd[current], buffer[current], sizeof(tgaHeader), 0);        fwrite((unsigned char*)buffer[current], 1, sizeof(tgaHeader), f);        bzero(buffer[current], buflen2);        n = recv(newsockfd[current], buffer[current],sizeof(header), 0);        fwrite((unsigned char*)buffer[current], 1, sizeof(header), f);//записали хидеры        bzero(buffer[current], buflen2);        n = recv(newsockfd[current], buffer[current], buflen2, 0);//получили байты самого изображения        //        //расшифровка байтов        createRoundKeys();        unsigned long long id;        std::vector<uint64_t>* plaintext = new std::vector<uint64_t>();        int i = 0;        while (i<buflen2)        {            memcpy(&id, (buffer[current]) + i, N);            plaintext->push_back(decrypt(id));            i += 8;        }        std::cout << "i=" << i << std::endl;        i = 0;        char str_[N + 1];        memset(str_, 0, N);        str_[N] = '\0';        for (std::vector<uint64_t>::iterator it = plaintext->begin(); it != plaintext->end(); ++it)        {            memcpy(str_, &*it, N);            fwrite((unsigned char*)str_, sizeof(unsigned char), N/*strlen(str_)*/, f);            i += 8;        }        std::cout << "i=" << i << std::endl;        //конец рашифровки байтов        //fwrite((unsigned char*)buffer[current], sizeof(char), buflen2, f);        fclose(f);    }    system(name.c_str());//открываем изображение *.tga встроенным редактором}int main(){    cc = 0;    WSADATA ws = { 0 };    if (WSAStartup(MAKEWORD(2, 2), &ws) == 0)    {        currentclient = 0;        int maxclients = 2;//максимальное число клиентов        cli_addr = new struct sockaddr_in[maxclients];        clilen = new int[maxclients];        buffer = new char* [maxclients];        for (int i = 0; i < maxclients; i++)        {            clilen[i] = sizeof(cli_addr[i]);        }        sockfd = socket(AF_INET, SOCK_STREAM, 0);//tcp сокет        if (sockfd < 0)            error("ERROR opening socket");        struct sockaddr_in serv_addr;        bzero((char*)&serv_addr, sizeof(serv_addr));        serv_addr.sin_family = AF_INET;        serv_addr.sin_addr.s_addr = INADDR_ANY;        int port = 30000;//порт        serv_addr.sin_port = htons(port);        if (bind(sockfd, (struct sockaddr*)&serv_addr, sizeof(serv_addr)) < 0)            error("ERROR on binding");        if (listen(sockfd, 10) < 0)            error("ERROR listen");        HANDLE* thread;//массив потоков для каждого клиента отдельный        struct arg_sa* args;        while (true)        {            newsockfd = new int[maxclients];            thread = (HANDLE*)malloc(sizeof(HANDLE) * maxclients);            args = new struct arg_sa[maxclients];            for (int i = 0; i < maxclients; i++)            {                args[i].lalk = new struct arg_s();                buffer[i] = new char[buflen2];            }            int i = -1;            while (++i < maxclients)            {                Sleep(1);                args[i].current = i;                args[i].lalk->exit = false;                thread[i] = CreateThread(0, 0, (LPTHREAD_START_ROUTINE)(session_), args, 0, 0);            }                for (int i = 0; i < maxclients; i++)                    WaitForSingleObject(thread[i], INFINITE);//ждем завершения всех потоков            i = -1;            while (++i < maxclients)            {                shutdown(newsockfd[i], 0);                TerminateThread(thread[i], 0);            }            //delete[] newsockfd;            //free(thread);            currentclient = 0;            for (int i = 0; i < maxclients; i++)            {                //delete args[i].lalk;                //delete[] args[i].lalk->buffer;            }            //delete[] args;        }        shutdown(sockfd, 0);        WSACleanup();        return 0;    }    std::cin.ignore();}

Вкратце в вечном цикле создаются потоки для каждого клиента и ждут accept пока клиенты подключится. После чего WaitForSingleObject ждет пока они все передадут. У каждого клиента свой сокет и свой буфер передачи. То есть на сервере M+1 сокет, где M количество клиентов. После завершения всех передач, всё повторяется.

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

#include <iostream>#include <WinSock.h>#include <vector>#pragma comment (lib,"WS2_32.lib")void error(const char* msg){    //perror(msg);    std::cout << '\n' << WSAGetLastError();    WSACleanup();    std::cin.ignore();    exit(1);}void bzero(char* buf, int l){    for (int i = 0; i < l; i++)        buf[i] = '\0';}typedef unsigned long long uint64_t;typedef unsigned int uint32_t;#define N 8#define F32 0xFFFFFFFFuint32_t RK[N];//раундовые ключи#define size64 sizeof(uint64_t)#define ROR(x,n,xsize)((x>>n)|(x<<(xsize-n)))#define ROL(x,n,xsize)((x<<n)|(x>>(xsize-n)))#define RKEY(r)((ROR(K,r*3,size64*8))&F32)const uint64_t K = 0x96EA704CFB1CF671;//ключ шифрованияvoid createRoundKeys(){    for (int i = 0; i < N; i++)        RK[i] = (ROR(K, i * 8, size64 * 8)) & F32;}uint32_t F(uint32_t subblk, uint32_t key){    return subblk + key;//функция шифрования}uint64_t encrypt(uint64_t block)//зашифровка блоков сетью Фейстеля{    //select subblocks    uint32_t left = (block >> 32) & F32;    uint32_t right = block & F32;    uint32_t left_, right_;//subblock in the end of round    for (int r = 0; r < N; r++)    {        uint32_t fk = F(left, RK[r]);        left_ = left;        right_ = right ^ fk;        if (r < N - 1)//swap places to next round        {            left = right_;            right = left_;        }        else//last round not swap        {            left = left_;            right = right_;        }    }    //collect subblock in block    uint64_t c_block = left;    c_block = (c_block << 32) | (right & F32);    return c_block;}int main(){    keybd_event(VK_LWIN, 0, 0, 0);    keybd_event('M', 0, 0, 0);    keybd_event('M', 0, KEYEVENTF_KEYUP, 0);    keybd_event(VK_LWIN, 0, KEYEVENTF_KEYUP, 0);//эти строки сворачивают все приложения    Sleep(1000);//чтобы сделать скриншот рабочего стола    WSADATA ws = { 0 };    if (WSAStartup(MAKEWORD(2, 2), &ws) == 0)    {        int sockfd;        sockfd = socket(AF_INET, SOCK_STREAM, 0);        struct sockaddr_in serv_addr, cli_addr;        bzero((char*)&serv_addr, sizeof(serv_addr));        bzero((char*)&cli_addr, sizeof(cli_addr));        serv_addr.sin_family = AF_INET;        const char* add = "127.0.0.1";//адрес сервера        serv_addr.sin_addr.s_addr = inet_addr(add);        int port = 30000;//порт        serv_addr.sin_port = htons(port);        int servlen = sizeof(serv_addr);        int n = connect(sockfd, (struct sockaddr*)&serv_addr, servlen);                //ниже код делает скриншот        HDC ScreenDC = GetDC(0);        HDC MemoryDC = CreateCompatibleDC(ScreenDC);        int ScreenHeight = GetSystemMetrics(SM_CYSCREEN);        int ScreenWidth = GetSystemMetrics(SM_CXSCREEN);        ScreenWidth = ((ScreenWidth - 1) / 4 + 1) * 4;        BITMAPINFO BMI;        BMI.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);        BMI.bmiHeader.biWidth = ScreenWidth;        BMI.bmiHeader.biHeight = ScreenHeight;        BMI.bmiHeader.biSizeImage = ScreenWidth * ScreenHeight * 3;        BMI.bmiHeader.biCompression = BI_RGB;        BMI.bmiHeader.biBitCount = 24;        BMI.bmiHeader.biPlanes = 1;        DWORD ScreenshotSize;        ScreenshotSize = BMI.bmiHeader.biSizeImage;        unsigned char* ImageBuffer;        HBITMAP hBitmap = CreateDIBSection(ScreenDC, &BMI, DIB_RGB_COLORS, (void**)&ImageBuffer, 0, 0);        SelectObject(MemoryDC, hBitmap);        BitBlt(MemoryDC, 0, 0, ScreenWidth, ScreenHeight, ScreenDC, 0, 0, SRCCOPY);        DeleteDC(MemoryDC);        ReleaseDC(NULL, ScreenDC);        FILE* sFile = 0;        unsigned char tgaHeader[12] = { 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 };        unsigned char header[6];        unsigned char tempColors = 0;        fopen_s(&sFile, "S.tga", "wb");        if (!sFile) {            exit(1);        }        header[0] = ScreenWidth % 256;        header[1] = ScreenWidth / 256;        header[2] = ScreenHeight % 256;        header[3] = ScreenHeight / 256;        header[4] = BMI.bmiHeader.biBitCount;        header[5] = 0;        fwrite(tgaHeader, 1, sizeof(tgaHeader), sFile);        fwrite(header, sizeof(header), 1, sFile);        //конец записали изображение в файл                //шифруем блоками полезную нагрузку изображения кроме хидеров        createRoundKeys();        std::vector<uint64_t>* msg = new std::vector<uint64_t>(),*crpt = new std::vector<uint64_t>();        unsigned long long id;        int i = 0;        while (i < BMI.bmiHeader.biSizeImage)        {            memcpy(&id, (ImageBuffer + i), N);            msg->push_back(id);            i += 8;        }        std::cout << "i=" << i << std::endl;         uint64_t cipher;        i = 0;        char str_[N + 1];        memset(str_, 0, N);        str_[N] = '\0';        for (std::vector<uint64_t>::iterator it = msg->begin(); it != msg->end(); ++it)        {            cipher = encrypt(*it);            memcpy(str_, &cipher, N);            fwrite((unsigned char*)str_, sizeof(unsigned char), N, sFile);            i += 8;        }        std::cout << "i=" << i << std::endl;        //        //fwrite(ImageBuffer, BMI.bmiHeader.biSizeImage, 1, sFile);        std::cout << BMI.bmiHeader.biSizeImage << std::endl;        fclose(sFile);        DeleteObject(hBitmap);        FILE* f;        fopen_s(&f, "S.tga", "rb");        int count = 0;        if (f != NULL)        {            while (getc(f) != EOF)                count++;//считаем байты изображения в счетчик чтобы потом передать            fclose(f);        }        count -= 18;        std::cout << count<< std::endl;        char* s = new char[100];        _itoa_s(count, s, 100, 10);        n = send(sockfd, s, 100, 0);//передаем счетчик        char* buffer = new char[count];        fopen_s(&f, "S.tga", "rb");        size_t bytes;        if (f != NULL)        {            memcpy(buffer, tgaHeader, sizeof(tgaHeader));            n = send(sockfd, buffer, sizeof(tgaHeader), 0);            bzero(buffer, count);            memcpy(buffer, header, sizeof(header));            n = send(sockfd, buffer, sizeof(header), 0);            bzero(buffer, count);//передаем хидеры            for(int i=0;i<18;i++)                fgetc(f);            bzero(buffer, count);            bytes = fread(buffer, sizeof(unsigned char), count, f);            n = send(sockfd,buffer, count, 0);//передаем шифрованные байты изображения            fclose(f);        }        Sleep(1000);        shutdown(sockfd, 0);        WSACleanup();        //system("del S.tga");        delete[] buffer,s;        return 0;    }    //std::cin.ignore();}

Вот результат работы клиента файл скриншота S.tga, зашифрованный

Видно, что это рабочий стол

А вот результат который был передан на сервер и расшифрован Screen.tga

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

Спасибо за внимание!

Подробнее..

VxLAN фабрика. Часть 2.5

08.09.2020 14:23:50 | Автор: admin

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



Многие тут вещи будут скорее базового уровня в понятиях VxLAN и не должны вызывать трудностей.



I. как VxLAN фабрика узнает о MAC адресах?


Да мы уже разобрали, что MAC и IP адреса передаются через EVPN route-type 2. Но как EVPN узнает о них?


Все довольно просто и работает аналогично логике обычного VLAN:


  • Кадр от источника попадает на порт коммутатора (VTEP)
  • Коммутатор, если не знает MAC источника записывает его в свою таблицу TCAM
  • Так как коммутатор выполняет роль VTEP, то информацию о MAC и IP адресах источника он передает через EVPN route-type 2 (каким именно образом зависит от настройки фабрики. В нашем случае используется Route-reflector(RR), поэтому информация отправляется к RR и от него к остальном VTEP)


С источником все понятно, а что делать с Destination? Ведь Host-источник скорее всего не знает MAC адрес назначения и пошлет ARP запрос.
Появляется два варианта:


  1. не использовать функцию Suppress-ARP
  2. использовать функцию Suppress-ARP

В первом случае все довольно просто, но не оптимально. При получении Broadcast запроса VTEP отправит его дальше в рамках того VNI, от куда пришел запрос. То есть по всей фабрики разойдется этот запрос в виде Unicast сообщений.



Во втором случае, при получении ARP запроса VTEP сам отвечает ARP reply, а ARP REQ дальше не отправляется.



Однако такая логика работает только если VTEP уже знает Destination MAC. Если адрес не известен, то пойдем по первому пути. Более подробно работу и настройку Suppress-ARP я касался в первой части цикла.


II. Зачем используется UDP?


Вопрос не менее интересный и ответить довольно просто. Для этого вспомним логику работы VxLAN фабрики.


К кадру, прилетающему на порт VTEP, добавляется VxLAN метка с номером VNI. Далее получившийся кадр запаковывается в UDP, инкапсулируется в новый IP пакет и передается поверх Underlay сети.


Так почему же нельзя оригинальный кадр с меткой VxLAN запаковать в IP и необходимо использовать UDP?


А все из-за одного поля в заголовке протокола IP Protocol, который указывает, какой именно протокол находится выше. Примеры протоколов и их номера (wiki):


ICMP - 1TCP - 6UDP - 17GRE - 47

И в этом кроется весь секрет VxLAN не имеет такой номер, а значит протокол IP не сможет о нем рассказать и уважающая себя сеть такой пакет не пропустит, поэтому инженеры обошли эту проблему с использованием протокола UDP.



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


III. Разница между ingress-replication и Multicast


Тема довольно объемная и в качестве краткого пояснения ответ дать не получится. Поэтому работа Multicast будет рассмотрена в рамках одной из следующей статьи цикла. Однако я попробую дать краткое описание различий двух технологий.


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


при использовании ingress-replication при получения широковещательного трафика (например ARP запрос) запрос инкапсулируется внутрь VxLAN и передается каждому VTEP в VxLAN через Unicast сообщения (для примера откажемся от RR). Так как VTEP будет больше 1, то широковещательный трафик будет дублироваться:



В случае использования Multicast, каждый VTEP для каждого VNI подписывается на определенную Multicast группу. И теперь, при получении широковещательного трафика, VTEP инкапсулирует ARP запрос в IP пакет. В заголовках IP пакета в качестве адреса назначения используется multicast адрес группы для этого VNI, а адрес источника IP адрес интерфейса NVE. Например, VNI 10000 ассоциируем c multicast группой 225.1.10.10



Таким образом у нас пропадает дублирование широковещательного трафика. Плюс, при должной оптимизации трафика, работа через Multicast будет более масштабируема. Единственная сложность underlay сеть должна поддерживать Multicast трафик.


Если у вас возникает вопрос Зачем вообще понадобился EVPN, если все может отлично работать через Multicast, ведь это более масштабируемое решение?


Ответ тут дать довольно затруднительно и вам придется решить самостоятельно какую технологию использовать. На данный момент, Multicast действительно является более масштабируемым решением. Но EVPN постоянно дорабатывается и в нем появляются новые route-type для передачи все большей информации о сети для более гибкой настройки. Дополнительно, EVPN строится на основе BGP, а значит есть возможность использовать все методы оптимизации, что есть и в самом BGP (например в моем стенде уже используется RR, для уменьшения BUM трафика и оптимизации анонсируемой информации).


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




OSPF ipv6. Практические навыки



Подробнее..

Перевод Восхождение интернета, ч.1 экспоненциальный рост

11.09.2020 12:04:11 | Автор: admin


<< До этого: Эра фрагментации, часть 4: анархисты

В 1990-м Джон Куотерман, консультант по сетевым технологиям и эксперт в области UNIX, опубликовал всеобъемлющий обзор состояния компьютерных сетей на тот момент. В небольшом разделе, посвящённом будущему вычислительных систем, он предсказал появление единой глобальной сети для электронной почты, конференций, передачи файлов, удалённого входа в систему так же, как сегодня существует всемирная телефонная сеть и всемирная почта. Однако особой роли интернету он не придал. Он предположил, что эта всемирная сеть скорее всего, будет управляться правительственными службами связи, кроме США, где ею будут управлять региональные подразделения Bell Operating Companies и операторы междугородней связи.

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

Передача эстафеты


Первое критически важное событие, приведшее к появлению современного интернета, произошло в начале 1980-х, когда Агентство оборонных коммуникаций (Defense Communication Agency, DCA) [ныне DISA] решило разбить ARPANET на две части. DCA взяло на себя контроль над сетью в 1975 году. К тому времени было ясно, что для отдела технологий обработки информации (IPTO) ARPA организации, занимающейся исследованием теоретических идей не было никакого смысла участвовать в развитии сети, использовавшейся не для исследования коммуникаций, а для повседневного общения. ARPA неудачно попыталась спихнуть контроль над сетью частной компании AT&T. DCA, отвечающее за военные системы связи, казалась наилучшим вторым вариантом.

В первые несколько лет новой ситуации ARPANET процветала в режиме благостного игнорирования. Однако к началу 1980-х стареющая инфраструктура коммуникаций министерства обороны отчаянно нуждалась в обновлении. Проект предполагаемой замены, AUTODIN II, подрядчиком которого DCA выбрало компанию Western Union, судя по всему, проваливался. Тогда главы DCA назначили полковника Хайди Хайдена ответственным за выбор альтернативы. Он предложил использовать в качестве основы для новой сети передачи оборонных данных технологию коммутации пакетов, которая уже была в распоряжении DCA в виде ARPANET.

Однако с передачей военных данных по ARPANET существовала очевидная проблема сеть изобиловала длинноволосыми учёными, иные из которых активно выступали против компьютерной безопасности или секретности к примеру, Ричард Столлман со своими сотоварищами-хакерами из лаборатории искусственного интеллекта MIT. Хайден предложил разделить сеть на две части. Он решил оставить учёных-исследователей с финансированием от ARPA на ARPANET, а компьютеры, работающие на оборонных предприятиях, выделить в новую сеть под названием MILNET. У подобного митоза было два важных последствия. Во-первых, раздел военной и не военной частей сети стал первым шагом к передаче интернета под гражданское, а впоследствии и под частное управление. Во-вторых, это стало доказательством жизнеспособности плодотворной технологии интернета протоколов TCP/IP, впервые придуманных лет за пять до этого. DCA было нужно, чтобы все узлы ARPANET перешли со старых протоколов на поддержку TCP/IP к началу 1983-го. На тот момент немногие сети использовали TCP/IP, но после этот процесс объединил две сети прото-интернета, что позволило трафику сообщений при необходимости связывать исследовательские и военные предприятия. Чтобы гарантировать долгосрочность протокола TCP/IP в военных сетях, Хайден основал фонд объёмом в $20 млн для поддержки компьютерных производителей, которые будут писать ПО для реализации TCP/IP в своих системах.

Первый шаг в постепенной передаче интернета от военного к частному контролю также даёт нам неплохую возможность попрощаться с ARPA и IPTO. Его финансирование и влияние, шедшие под управлением Джозефа Карла Робнетта Ликлайдера, Айвена Сазерленда и Роберта Тейлора, напрямую и опосредованно привело к появлению всех ранних разработок в области интерактивных вычислений и компьютерных сетей. Однако создав стандарт TCP/IP в середине 1970-х, оно последний раз сыграло ключевую роль в истории компьютеров.

Следующим важным вычислительным проектом, организованным DARPA, станет конкурс автономных средств передвижения 2004-2005 годов. Самым знаменитым проектом до этого будет стратегическая компьютерная инициатива на основе ИИ 1980-х годов на миллиард долларов, которая породит несколько полезных военных приложений, но практически никак не повлияет на гражданское общество.

Решающим катализатором в потере влияния организации стала война во Вьетнаме. Большинство учёных-исследователей считали, что борются за правое дело и защищают демократию, когда исследования эпохи Холодной войны финансировали военные. Однако те, кто вырос в 1950-е и 1960-е года потеряли веру в военных и их цели после того, как последние увязли в болоте Вьетнамской войны. Среди первых был и сам Тейлор, ушедший из IPTO в 1969, унося свои идеи и связи в Xerox PARC. Контролируемый демократами Конгресс, обеспокоенный разрушительным влиянием военных денег на базовые научные исследования, принял поправки, согласно которым деньги на оборону необходимо было тратить исключительно на военные исследования. ARPA отразило это изменение в культуре финансирования в 1972 году, переименовавшись в DARPA управление перспективных исследовательских проектов Министерства обороны США.

Поэтому эстафета перешла к гражданскому национальному научному фонду (NSF). К 1980-му году с бюджетом в $20 млн, NSF отвечал за финансирование примерно половины федеральных компьютерных исследовательских программ в США. И большая часть этих средств вскоре будет направлена на новую национальную компьютерную сеть NSFNET.

NSFNET


В начале 1980-х Ларри Смарр, физик из Иллинойского университета, посетил Институт им. Макса Планка в Мюнхене, где работал суперкомпьютер Крей, к которому был разрешён доступ европейским исследователям. Раздосадованный отсутствием схожих ресурсов для учёных США, он предложил, чтобы NSF профинансировал создание нескольких суперкомпьютерных центров по всей стране. Организация ответила на притязания Смарра и других исследователей со схожими жалобами, создав в 1984 году отдел по передовым научным вычислениям, что привело к финансированию пяти подобных центров с пятилетним бюджетом в $42 млн. Они протянулись от Корнеллского университета на северо-востоке страны до Сан-Диего на юго-западе. Находившийся между ними университет штата Иллинойс, где работал Смарр, получил собственный центр, национальный центр суперкомпьютерных приложений, NCSA.

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

Изначально NSF передал задачи по созданию и поддержке сети NCSA из Иллинойского университета как источнику первоначального предложения создания национальной суперкомпьютерной программы. В свою очередь NCSA взял в аренду те же самые линии связи на 56 кбит/с, что ARPANET использовала с 1969 года, и запустила сеть в 1986 году. Однако эти линии быстро забились трафиком (подробности этого процесса можно найти в работе Дэвида Миллса "Опорная сеть NSFNET"). И снова повторилась история ARPANET быстро стало очевидно, что основной задачей сети должен быть не доступ учёных к компьютерным мощностям, а обмен сообщениями между людьми, имевшими к ней доступ. Можно простить авторов ARPANET за то, что они не знали, что подобное может произойти но как могла повториться та же ошибка почти через двадцать лет? Одно из возможных объяснений состоит в том, что гораздо легче оправдать семизначный грант на использование вычислительных мощностей, стоимость которых составляет восьмизначные суммы, чем оправдать трату таких сумм на вроде бы такие несерьёзные цели, как возможность обмениваться электронными письмами. Нельзя сказать, что NSF сознательно вводил кого-то в заблуждение. Но как антропный принцип утверждает, что физические константы Вселенной такие, какие они есть, потому, что иначе нас бы просто не было, и мы не могли бы их наблюдать, так и мне не пришлось бы писать о компьютерной сети с государственным финансированием, если бы не было подобных, несколько фиктивных оправданий её существованию.

Убедив себя в том, что сама по себе сеть обладает, по меньшей мере, такой же ценностью, как и суперкомпьютеры, оправдывающие её существование, NSF обратился к сторонней помощи, чтобы обновить костяк сети, проведя линии с пропускной способностью T1 (1,5 Мбит/с). Стандарт Т1 был основан компанией AT&T в 1960-х, и должен был обслуживать до 24 телефонных звонков, каждый из которых кодировался в цифровой поток 64 кбит/с.

Контракт выиграла Merit Network, Inc. в партнёрстве с MCI и IBM, и за первые пять лет получила от NSF грант на $58 млн для строительства и поддержки сети. MCI обеспечивала инфраструктуру связи, IBM вычислительные мощности и ПО для роутеров. Некоммерческая компания Merit, управлявшая компьютерной сетью, связывавшей между собой кампусы Мичиганского университета, принесла с собой опыт поддержки научной компьютерной сети, и придала всему партнёрству университетский дух, благодаря чему его легче воспринимали NSF и учёные, использовавшие NSFNET. Тем не менее, передача обслуживания от NCSA к Merit была очевидным первым шагом на пути к приватизации.

Изначально MERIT расшифровывалась как Michigan Educational Research Information Triad [мичиганская образовательная триада исследования информации]. Штат Мичиган добавил $5 млн от себя, чтобы помочь домашней сети на Т1 разрастись.



Через магистраль Merit шёл трафик более десяти региональных сетей, от нью-йоркской исследовательской и образовательной сети NYSERNet, связанной в Итаке с Корнеллским университетом, до калифорнийской федеративной исследовательской и образовательной сети CERFNet, подключённой в Сан-Диего. Каждая из этих региональных сетей связывалась с бесчисленным количеством местных кампусных сеток, поскольку в лабораториях колледжей и офисах преподавателей работали сотни машин под управлением Unix. Такая федеральная сеть сетей стала затравочным кристаллом современного интернета. ARPANET связывала между собой только исследователей в области информатики с хорошим финансированием, работавших в элитных научных заведениях. А к 1990-му году почти любой студент университета или преподаватель уже мог выходить в онлайн. Перекидывая пакеты от узла к узлу через местный Ethernet, потом дальше в региональную сеть, потом через большие расстояния со скоростью света по магистрали NSFNET они могли обмениваться емейлами или чинно беседовать в Usenet с коллегами с других концов страны.

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

Взлёт


За весь этот период количество компьютеров, подключённых к NSFNET и связанным с ней сетями а всё это мы теперь уже можем называть интернетом росло каждый год примерно в два раза. 28 000 в декабре 1987, 56,000 в октябре 1988, 159 000 в октябре 1989, и так далее. Такая тенденция продолжалась вплоть до середины 1990-х, а потом рост немного замедлился. Как, интересно, учитывая эту тенденцию, Куотерман мог не заметить, что интернету суждено править миром? Если недавняя эпидемия нас чему и научила, так это тому, что человеку очень сложно представить себе экспоненциальный рост, поскольку он не соответствует ничему, с чем мы сталкиваемся в повседневной жизни.

Конечно же, название и концепция интернета появилась ещё до NSFNET. Интернет протокол придумали в 1974, и ещё до NSFNET существовали сети, общавшиеся по IP. Мы уже упоминали ARPANET и MILNET. Однако мне не удалось найти никаких упоминаний интернета единой, простирающейся на весь мир сети сетей до появления трёхъярусной NSFNET.

Количество сеток внутри интернета росло с похожей скоростью от 170 в июле 1988 года до 3500 осенью 1991. Поскольку научное сообщество не знает границ, многие из них находились за рубежом, начиная со связей с Францией и Канадой, налаженных в 1988-м. К 1995 году в интернет можно было выйти почти из 100 стран, от Алжира до Вьетнама. И хотя количество машин и сетей подсчитать гораздо легче, чем количество реальных пользователей, по разумным оценкам к концу 1994 их было 10-20 млн. В отсутствии подробных данных о том, кто, зачем и в какое время использовал интернет, довольно трудно аргументировано подтвердить то или иное историческое е объяснение такого невероятного роста. Небольшая коллекция историй и анекдотов вряд ли может объяснить, как с января 1991 по январь 1992 года к интернету подключилось 350 000 компьютеров, а за следующий год 600 000, а за следующий ещё 1,1 млн.

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

Сначала пришли учёные. NSF намеренно распространяла вычисления по как можно большему количеству университетов. После этого каждый учёный хотел присоединиться к проекту, потому, что все остальные были уже там. Если до вас могли не дойти емейлы, если вы могли не увидеть и не поучаствовать в самых последних обсуждениях на Usenet, вы рисковали пропустить анонс важной конференции, шанс найти наставника, не заметить передовое исследование до его публикации, и так далее. Ощущая принуждение к присоединению к научным беседам в онлайне, университеты быстро подключались к региональным сеткам, которые могли подсоединить их к магистрали NSFNET. К примеру, NEARNET, покрывавшая шесть штатов региона Новая Англия, к началу 1990-х приобрела более 200 участников.

Одновременно доступ начал просачиваться от преподавателей и аспирантов в гораздо более многочисленное сообщество студентов. К 1993 году примерно 70% первокурсников Гарварда завели себе электронные адреса. К тому времени интернет в Гарварде физически дошёл до всех уголков и связанных с ним институтов. Университет пошёл на значительные расходы для того, чтобы провести Ethernet не просто в каждое здание учебного заведения, но и во все студенческие общежития. Наверняка оставалось совсем немного времени до того момента, когда кто-нибудь из студентов первым ввалился в свою комнату после бурной ночи, упал в кресло и с трудом настучал электронное сообщение, об отправке которого пожалел на следующее утро будь то признание в любви или яростная отповедь врагу.

На следующей волне, около 1990 года, начали прибывать коммерческие пользователи. В тот год был зарегистрирован 1151 домен .com. Первыми из коммерческих участников стали исследовательские департаменты технологических компаний (Bell Labs, Xerox, IBM и т.д.). Они, по сути, использовали сеть в научных целях. Бизнес-общение их руководителей шло по другим сетям. Однако к 1994 году существовало уже более 60 000 имён в домене .com, и зарабатывание денег на интернете началось по-настоящему.

К концу 1980-х компьютеры начали становиться частью повседневной рабочей и домашней жизни граждан США, и важность цифрового присутствия для любого серьёзного бизнеса стала очевидной. Емейл предлагал способ простого и чрезвычайно быстрого обмена сообщениями с коллегами, клиентами и поставщиками. Списки рассылки и Usenet предлагали как новые способы быть в курсе событий в профессиональном сообществе, так и новые формы очень дешёвой рекламы для широкого спектра пользователей. Через интернет можно было получить доступ к огромному разнообразию бесплатных баз данных юридическим, медицинским, финансовым и политическим. Устраивавшиеся на работу вчерашние студенты, жившие в подключённых общежитиях, полюбили интернет так же, как и их работодатели. Он предлагал доступ к куда как большему набору пользователей, чем любой из отдельных коммерческих сервисов (и снова закон Меткалфа). После оплаты месячного доступа к интернету, практически всё остальное вы могли получить бесплатно, в отличие от значительной стоимости оплаты за использованные часы или за отправленные сообщения, которую просили CompuServe и прочие подобные сервисы. Среди ранних участников рынка интернета были компании, рассылавшие программы по почте например, The Corner Store из Литчфилда, Коннектикут, рекламировавшаяся в группах Usenet, и The Online Bookstore, магазин электронных книг, основанный бывшим редактором издательства Little, Brown and Company, и более чем на десять лет опередивший Kindle.

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

Более крупные онлайн-сервисы развивались по той же схеме. К 1993 году все сервисы национального масштаба в США Prodigy, CompuServe, GEnie и молодая компания America Online (AOL) предлагали пользователям, которых в сумме насчитывалось 3,5 млн, возможность отправлять емейл на интернет-адреса. И только отстающий Delphi (с 100 000 подписчиков) предлагал полноценный выход в интернет. Однако в последовавшие несколько лет ценность доступа к интернету, продолжавшему расти с экспоненциальной скоростью, быстро перевесила доступ к собственным форумам, играм, магазинам и другому контенту самих коммерческих сервисов. 1996-й стал переломным годом к октябрю 73% пользователей, выходивших в онлайн, пользовались WWW, по сравнению с 21% за год до этого. Был придумал новый термин портал, описывающий рудиментарные остатки от услуг, предоставлявшихся AOL, Prodigy и остальными компаниями, которым люди платили деньги только за то, чтобы получить доступ в интернет.

Секретный ингредиент


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

Конечно, правительственные субсидии сыграли свою роль. Кроме финансирования магистральных линий связи, когда NSF решил всерьёз вложиться в развитие сети независимо от своей программы развития суперкомпьютеров, он не мелочился. Концептуальные лидеры программы NSFNET, Стив Вулф и Джейн Кавинес, решили строить не просто сеть суперкомпьютеров, но новую информационную инфраструктуру для американских колледжей и университетов. Поэтому они учредили программу Connections [связи], бравшую на себя часть расходов на подключение университетов к сети в обмен на то, что те обеспечат как можно большему количеству людей доступ к сети на своих кампусах. Это ускорило распространение интернета как прямо, так и косвенно. Косвенно поскольку многие из региональных сеток породили коммерческие предприятия, использовавшие ту же самую инфраструктуру, построенную на субсидии, чтобы продавать коммерческим организациям доступ в интернет.

Но и у Minitel были субсидии. Однако более всего интернет отличался своей многослойной децентрализованной структурой и свойственной ему гибкостью. IP позволял сетям с совершенно различными физическими свойствами работать с одной и той же системой адресов, а TCP обеспечивал доставку пакетов до получателя. И всё. Простота основной схемы работы сети позволяла надстраивать над ней практически любые приложения. Что важно, любой пользователь мог внести вклад в виде новой функциональности, если у него получалось убедить других пользоваться его программой. К примеру, передача файлов по протоколу FTP была одним из наиболее популярных способов использования интернета в ранние годы, однако найти сервера, предлагавшие интересующие вас файлы, кроме как через сарафанное радио было невозможно. Поэтому предприимчивые пользователи создавали различные протоколы для каталогизации и ведения списков FTP-серверов например, Gopher, Archie и Veronica.

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

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

Естественно, наиболее ярким примером многослойной структуры и децентрализации стал всемирный веб. Два десятилетия системы от компьютеров с разделением времени 1960-х до сервисов подобных CompuServe и Minitel вращались около небольшого набора основных услуг обмена информацией емейла, форумов и чатов. Веб стал чем-то принципиально новым. Ранние годы веба, когда он полностью состоял из уникальных страниц, сделанных вручную, ничем не напоминают его сегодняшнее состояние. Однако прыжки от ссылке к ссылки уже тогда обладали странной притягательностью, и давали предприятиям возможность обеспечивать чрезвычайно дёшевую рекламу и службу поддержки пользователей. Никто из архитекторов интернета не планировал появление веба. Он стал плодом творчества Тима Бернерса-Ли, британского инженера европейского центра ядерных исследований (ЦЕРН), создавшего его в 1990-м году с целью удобного распространения информации между исследователями лаборатории. Однако же он с лёгкостью жил на базе TCP/IP и использовал систему доменных имён, созданную для других целей, для повсеместно распространившихся URL. Любой человек с доступом к интернету мог сделать сайт, и к середине 90-х казалось, что все так и сделали мэрии городов, местные газеты, малые предприятия и любители всех мастей.

Приватизация


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

Что ещё почитать


  • Janet Abatte, Inventing the Internet (1999)
  • Karen D. Fraser NSFNET: A Partnership for High-Speed Networking, Final Report (1996)
  • John S. Quarterman, The Matrix (1990)
  • Peter H. Salus, Casting the Net (1995)
Подробнее..

VxLAN фабрика. Часть 3

16.09.2020 14:04:44 | Автор: admin

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



Предыдущие части цикла можно найти по ссылкам:



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


Рассмотрим два варианта маршрутизации между VRF:


  1. Маршрутизация, не выходя из VxLAN фабрики;
  2. Маршрутизация на внешнем оборудовании.

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



Какие недостатки в такой топологии?


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


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


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


И ответ кроется в таких функциях как export и import маршрутной информации (настройку данной технологии рассматривали во второй части цикла). Кратко повторю:


При задании VRF в AF необходимо указать route-target для import и export маршрутной информации. Указать его можно в автоматическом режиме. Тогда в значение попадет ASN BGP и L3 VNI, привязанный к VRF. Это удобно, когда у вас в фабрике используется только одна ASN:


vrf context PROD20  address-family ipv4 unicast    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000    route-target import auto

Однако если у вас больше одной ASN и необходимо передавать маршруты между ними, то более удобным и масштабируемым вариантом будет ручная настройка route-target. Рекомендация в ручной настройке первое число, использовать удобное Вам, например, 9999.
Второе следует сделать равным VNI для этого VRF.


Настроим следующим образом:


vrf context PROD10  address-family ipv4 unicast    route-target export 9999:99000              route-target import 9999:99000    route-target import 9999:77000         ! Пример 1 import из другого VRF    route-target import 9999:77000         ! Пример 2 import из другого VRF

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


Leaf11# sh ip route vrf prod<.....>192.168.20.0/24, ubest/mbest: 1/0    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Рассмотрим второй вариант маршрутизации между VRF через внешнее оборудование, например Firewall.


Можно предположить несколько вариантов работы через внешнее устройство:


  1. Устройство знает, что такое VxLAN и мы можем добавить его в часть фабрики;
  2. Устройство ничего не знает об VxLAN.

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


Рассмотрим второй вариант, когда наш Firewall ничего не знает о VxLAN (сейчас, конечно, появляется оборудование с поддержкой VxLAN. Например, Checkpoint анонсировал его поддержку в версии R81. Почитать об этом можно тут, однако это все на стадии тестирования и нет уверенности в стабильности работы).


При подключении внешнего устройства у нас получается следующая схема:



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


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


В результате схема с Firewall:



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


Хорошо. Подключили Firewall, добавили его во все VRF. Но как теперь заставить трафик с каждого Leaf идти через этот Firewall?


На Leaf, подключенному к Firewall, никаких проблем не возникнет, так как все маршруты локальные:


0.0.0.0/0, ubest/mbest: 1/0    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

Однако как быть с удаленными Leaf? Как передать им внешний маршрут по-умолчанию?


Верно, через EVPN route-type 5, как и любой другой префикс по VxLAN фабрике. Однако с этим не все так просто (если мы говорим про cisco, как у других вендоров не проверял)


Анонсировать маршрут по-умолчанию необходимо с Leaf, к которому подключен Firewall. Однако для передачи маршрута, Leaf должен сам его знать. И тут возникает некоторая проблема (возможно только у меня), маршрут необходимо прописать статикой в том VRF, где вы хотите анонсировать такой маршрут:


vrf context PROD10    ip route 0.0.0.0/0 10.254.13.55

Далее в настройке BGP задать этот маршрут в AF IPv4:


router bgp 65001    vrf prod        address-family ipv4 unicast            network 0.0.0.0/0

Однако это не все. Таки образом маршрут по-умолчанию не попадет в семейство l2vpn evpn. Дополнительно к этому необходимо настроить редистрибуцию:


router bgp 65001    vrf prod        address-family ipv4 unicast            network 0.0.0.0/0            redistribute static route-map COMMON_OUT

Указываем какие именно префиксы попадут в BGP через редистрибуцию


route-map COMMON_OUT permit 10  match ip address prefix-list COMMON_OUTip prefix-list COMMON_OUT_GATE seq 10 permit 0.0.0.0/0

Теперь префикс 0.0.0.0/0 попадает в EVPN route-type 5 и передается остальным Leaf:


0.0.0.0/0, ubest/mbest: 1/0    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

В таблице BGP так же можем наблюдать полученный route-type 5 с маршрутом по-умолчанию через 10.255.1.5:


* i[5]:[0]:[0]:[0]:[0.0.0.0]/224                      10.255.1.5                        100          0 i*>i                   10.255.1.5                        100          0 i

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


Если же у вас остались вопросы/предложения на тему, рассмотреть какой-либо функционал EVPN напишите, рассмотрим дополнительно.

Подробнее..

Жизнь в паутине сетевые истории диких времён

25.09.2020 08:22:03 | Автор: admin

Сегодня, когда я достаю с полочки очередной пирожок с воспоминашками, интернет стал чем-то самим собой разумеющимся, вроде воды в кране. Родилось и выросло поколение постоянно включённого вайфая, не видавшее картинок, грузящихся снизу вверх, не писавшее ATL0 в терминал модема, и при упоминании "голого деда" испытывающее совсем другие эмоции.
И как же это прекрасно! За пару десятилетий прогресс прокатился по планете, эволюционировав от телефонной лапши и паутины коаксиала до мощных оптоволоконных корневищ; от еле-еле высасываемых из эфира байт до гигабитных каналов в каждую квартиру. Собственный, всегда включённый интернет-терминал лежит в кармане даже у любого гастарбайтера, не находящего необычности в том, чтобы регулярно общаться по видеосвязи с роднёй в горном ауле. Могли мы себе это представить двадцать, тридцать лет назад? А ведь мы всё ещё движемся дальше: через какое-то время спутниковая сеть покроет всю планету, а терминалы связи можно будет ставить себе прямо в мозг. Не берусь судить, как это изменит жизнь всего человечества, но дырочку в своей черепушке сверлить уже готовлюсь.

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

Первый клик в паутину

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

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

Там-то, в штабе, стоял компьютер, вечно занимаемый третьими "героями" кроме тех минут, когда удавалось добыть денег на выход в сеть! Это было целое священнодействие: словно колокольный звон перед молитвой играл модем волшебную мелодию коннекта, а затихнув, являл в трей девяносто восьмой винды чудотворную иконку установленного соединения! Здесь я впервые причастился: у кого-то назревали именины, под что родилась идея скачать и распечатать в подарок открытку. Для того времени и того места это была действительно крутая и оригинальная идея!

Так что первое, что я увидал в сети, совершенно меня не впечатливший сайт с дурацкими открытками.

Экспозиция к происходящему

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

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

Компьютер был куплен, как и положено, "для учёбы". Родители понимали, что кроме IT ни на что другое я не годен, и действительно старались обеспечить мне условия для поступления "на программиста". Но чем дальше тем больше они сомневались в принятом решении. Очень скоро начались классические истории с прятанием проводов питания и угрозами "выкинуть комплюхтерн к чертям" иначе отлипнуть от чудесной машины я просто не мог. Забавно вспоминать об этом после того, как батя подсел на пасьянсы: мы поменялись ролями и провода прятать приходилось уже мне.

Я кое-как поступил. Отгремели первые студенческие пьянки, образовались новые знакомства, и выяснилось, что я не один такой повёрнутый. Нам, провинциальным гиканам, хотелось объединяться в сеть, и если расстояния не позволяли даже думать о витой паре, то телефон был тогда в каждой квартире.
Нужен был только модем. Самый дешёвый Lucent Agere Winmodem стоил тогда ровно 500 рублей мой студенческий бюджет на несколько месяцев. Заниматься подработкой во время учёбы я себе позволить не мог, просить у родителей мне было стыдно... но мне просто повезло. Отправляясь в универ на ненавистную первую пару физкультуры я увидал в подъезде пятисотрублёвую купюру! Валяясь на грязном полу, она излучала неземное сияние, манила и обещала мне сбычу мечт...

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

Бип-бип, щхщхщхпхххщщщщщ, мазафака! Фото из сети.Бип-бип, щхщхщхпхххщщщщщ, мазафака! Фото из сети.

Хотя подобные софтмодемы считались "неполноценными" из-за программной реализации обработки сигнала, именно эта модель для PCI работала на наших линиях куда лучше дорогих внешних модемов. Я собирал к нему драйвера под Red Hat и заводил в BeOS, я прошивал его на V.92 и тюнил коннект AT-командами. Он обеспечил мне часы и дни сидения в бесплатных провайдерских чатах, игру в старкрафт по IPX, он работал факсом и автоответчиком, и, конечно, доставлял всю радость тогдашних интернетов. Немного надеюсь, что где-то в родительском доме эта платка всё ещё лежит, хотя пользы от неё сейчас никакой, разве что воткнуть в ретро-системник для полноты комплекта.

Паутина окутывает город

С доступом к сетям у нас в городке было так себе. FIDO уже вымерло, для локалок поблизости не набиралось желающих, зато коммутируемый доступ в интернет предоставляли целых три провайдера: пасынок совкового Волгателекома (он же "дград"), прогрессивный "Вариант-Информ" ("винф"), и тот, третий, который в моём районе не работал. Стоил доступ около доллара в час, плюс-минус пять рублей в зависимости от провайдера и времени суток, и в первое время даже заплатить за него было целой проблемой. Нужно было ехать в абонентскую кассу и там внести деньги на счёт; у "винфа" через пару лет появились карты с кодами, сделавшие процесс пополнения более-менее удобным.
Качество самого соединения сильно плясало от АТС и качества телефонной лапши. 33600 бит/с считалось очень хорошей скоростью, чаще было 28800, а то и 9600 бит/с. Это примерно 15 минут на скачивание одного мегабайта данных! Но даже таких крох хватало для очень неторопливого просмотра тогдашнего веба, а для IRC-чатов было уже вполне достаточно. Больше напрягали обрывы связи, занятый телефон и необходимость платить за время. И вообще платить...

Но была у нас и халява, как без неё! И "дград", и "винф" давали возможность бесплатного гостевого доступа, как бы для проверки счёта. "Дград" ограничивал гостевую сессию по времени, "винф" по количеству свободных модемов в пуле. И те малые бесплатные ресурсы, доступные с "халявы", так или иначе становились прибежищем всех обладателей модемов в городе.
Особенно тут был хорош "винф": бесплатно были доступны форум, IRC, и сетка их игровухи (о которой я уже рассказывал). Вокруг этого выросло очень большое комьюнити, просуществовавшее много лет; онлайн-знакомства переходили в реал, куда переносилась и свойственная сетевому общению свобода. Люди разных возрастов и убеждений не просто находили общий язык, но и вели себя как равные. Libert, galit, Fraternit!

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

Наименее шокирующее фото сопутствующих событий тех времён из личного архива автора.Наименее шокирующее фото сопутствующих событий тех времён из личного архива автора.

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

Совсем уж у избранных счастливчиков был спутниковый интернет, идущий довеском к "тарелке". Конечно, он работал только на приём, канал для отправки данных нужен был отдельный (тот же GPRS в этом плане был идеален). Хотя стоимость спутникового трафика зашкаливала, обладатели "тарелок" пробавлялись бесплатной "рыбалкой" ловлей файлов в общем потоке данных. Когда какой-нибудь турок скачивал себе киношку, сигнал с этими данными шёл на всю зону приёма, оставалось только вычленить файл, чем занимался специальный софт. Именно у "рыбаков" водилась самая дикая порнуха и самые ранние пиратские релизы, и именно к ним приходилось идти, если требовалось скачать какой-то серьёзный объём данных.

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

Факин шилд

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

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

Я у мамы рос кулхакер! Фото снова из интернета, но у кого не было такой стопки?Я у мамы рос кулхакер! Фото снова из интернета, но у кого не было такой стопки?

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

Как-то среди студенчества стал расползаться слух о волшебном логине фирмы "Шилд" с бесконечным количеством денег на счету. Слух однажды подтвердился: на одном из тех самых локальных форумов вбросили эти логин/пароль (какая-то очень простая пара, вроде shild/shild). И денег на этом счету были десятки тысяч.
Эх, какое началось раздолье! Под "халявным" логином сидел, наверное, весь город. Я тоже замарался пару раз из жадности и любопытства, но спалиться особо не боялся (номера нашей АТС не определялись по городу, не должны были определяться и у провайдера). Однако, мне точно было известно, что некоторые товарищи дорвались, и пользуются этой учёткой непрерывно.

Наблюдать за ситуацией было любопытно. В течение нескольких месяцев повторялось одно и то же: счёт загонялся в минус, через некоторое время пополнялся до прежних значений, но снова ненадолго. Только по прошествии значительного количества времени у учётки сменили пароль и город покрылся пеленой печали, в которой пребывал, благодаря вашему покорному слуге, недолго.
Конечно, брутфорсить эту учётку было бы стопроцентной глупостью, я этого и не делал. Больше по фану я попытался войти под паролем "qwerty" да твою ж мать, подошло! Возгордившись, я (анонимно, конечно) слил пароль в городской IRC...
Вторая волна не заставила себя ждать. Оголодавшие за пару дней халявщики, отбросив всякую осторожность ринулись в сеть. Никакие рассуждения о палеве не вразумляли глупых сих, а зря позже выяснилось, что после смены пароля фирмачи начали что-то подозревать, обратились к провайдеру, который только тогда включил логирование номеров соединений.

Где-то через месяц учётку закрыли насовсем. Из Ульяновского управления "К" приехал следователь, кого-то вызвали повесткой на допрос (что невообразимо шокировало родителей), ходили слухи, что у кого-то даже конфисковали компьютер. После появления столь шокирующих новостей в городском сетевом обществе началась буквальная агония: каждый хоть на полшишечки пользовался учёткой и теперь боялся кары.
Я ситуацию переживал без особого страха, ощущая во всём этом какой-то налёт хакерской романтики. Но, конечно, поудалял весь "палевный" софт, диски серии "Всё для хакера" попрятал за шкаф, модем выдрал и спрятал ещё дальше. Даже батю научил, что говорить в случае, если на меня как-то выйдут.
А ещё я принялся вести своё расследование.
Это было легко. Ополоумевшие от страха "шилдоюзеры" легко сдавали все связи, я быстро отследил цепочки, по которым передавался злосчастный логин ещё до засветки в паблике.

Автор ведёт расследование (восстановленное изображение).Автор ведёт расследование (восстановленное изображение).

В центре паутины находились трое первокурсников, кто-то из которых и слил доступ. Я позвонил каждому из них, пробив телефоны через своего человека в деканате; при звонке я представлялся тем самым ульяновским следователем, прося рассказать всё без утайки. Разоблачить меня можно было элементарно, но у страха глаза велики ни один из студентиков не заподозрил ничего, все трое пошли на "сделку со следствием", сдав друг друга, что называется, с потрохами. Митник мог бы мной гордиться!
К сожалению, я не сделал записей разговоров, но хотя бы узнал, что пароль утёк через четвёртого первокурсника родственника директора той самой фирмы. Он по-братски поделился паролем со своими друзяшками, а что знают трое знает весь город.

Уверен, что если это смог выяснить я, то настоящий обученный следователь знал об этом уже на второе утро. Тут, вроде бы, и сказке конец, но расслаблять булки было рано, ведь людей на допросы всё ещё вызывали.
Была организована презабавная встреча "анонимных халявщиков": все друг друга знали, если не лично, то по сетевому общению, но делали вид, что оказались тут случайно. Кто-то привёл папу, кто-то привёл маму, кто-то привёл юриста.
Юрист, степенная и рассудительная женщина, внимательно выслушала всю фактологию, по которой получалось, что первоначально учётная запись была опубликована добровольно, за что вину должен нести распространитель. С теми, кто халявничал после смены пароля, ситуация была не такой однозначной, но и тут юрист посоветовала дожидаться обвинений и доказательств, сказав, что сейчас следователь пытается всех запугать. Рекомендация была очевидна: ждать, либо саморассоса, либо конкретики.

Все с этим согласились. Все, кроме Вовиной мамы.

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

"И батон наперевес, как устанет так и ест!""И батон наперевес, как устанет так и ест!"

Наш Вова мог бы с успехом сняться в том мультике в роли самого себя. Конечно, вряд ли армия возместила бы ему недостаток отцовского воспитания, но какие-то основы самостоятельности наверняка бы впихнула. Этого мы не знаем, потому что Вову "поступили" в ВУЗ.

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

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

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

Халявщики never changes

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

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

И снова на локальном форуме появляется вброс о халяве: логин для этого пула, под которым можно входить только в собственную сеть ВТ (волжане, у вас ёкает в груди при слове "симикс"?), но зато бесплатно, что-то вроде привычных уже нам гостевых доступов. А сеть Волгателекома это сотни и тысячи ADSL-абонентов, с кучей FTP, чатов, p2p, и, чем чёрт не шутит, шлюзами в ICQ! В глазах халявщиков это было ничем не хуже нормального интернета.
Конечно, можно было зайти в тарифный раздел сайта ВТ и там найти всю информацию об этом доступе. Он был дёшев, в три-четыре раза дешевле классической повремёнки, но всё же не бесплатен. Поэтому первое время логин использовали достаточно осторожно. Но счета не приходили месяц, другой... Народ дорвался: на "бесплатную локалку" подсел почти весь город, пользоваться ей было чем-то самим собой разумеющимся. Круглосуточно занятые телефоны, гигабайты скачиваемых смешнявок, полное цифровое раздолье! И ладно бы велись дети нет, взрослого контингента тоже было достаточно.

Как вы догадываетесь, ВТ отработало ситуацию в своём стиле. Спустя где-то полгода после вброса, людям пришли счета сразу за всё время. Суммарные цифры там были такие, что никаким "шилдам" не снилось; тьма спустилась на славный город Димитровград, вой и стоны наполнили стены жилищ его!
Поскольку я сам на этот раз был осторожен и не вляпался, то за историей наблюдал больше со стороны. Но историю обсасывали в локальной прессе и, естественно, в локальной сети: под развод а ничем другим я ситуацию назвать не могу попало больше тысячи человек, это всколыхнуло общественность. Вроде бы, некоторое время шли суды и бодания, должникам отключали телефоны, а те проклинали "воблу"; в конце концов, стороны замирились часть долга списали, часть возместили вскладчину.
Зато я непосредственно видел другую часть событий, в газеты не попавшую. Влетевшим на бабки очень нужен был виноватый: автор первоначального вброса подходил на эту роль идеально. Его реальный адрес вычислили, и инициативная группа карателей отправилась устраивать линчевание. В реальной жизни грозный сетевой воин оказался унылым школотроном, которого бить побрезговали.

Приключения с "воблой"

Году к 2005 волготелекомовский ADSL докатился и до нашего города, и при первой же возможности я к нему подключился. Не то, чтоб до той поры у нас не водились другие xDSL-провайдеры, но их услуги частные лица позволить себе не могли. С ВТ в этом плане было легче: хотя стоимость подключения и трафика были весьма ощутимы, упомянутые чуть выше локальные ресурсы были действительно бесплатны. Более того, наличие таких ресурсов чуть ли не напрямую заявлялось в рекламе мол, подключайся, и тебе будет доступен наш трёхтеррабайтный FTP-варезник!

Именно за этим люди и подключались. На "фексе" том самом файлообменнике действительно было всё, чего могла пожелать душа тогдашнего задрота. Образы свежих игр, рипы фильмов, ломаный софт, музло, прон! Нафиг при таких богатствах вообще нужен интернет? Конечно, какой-то смешной объём внешнего трафика в абонентку включался, но поверх его приходилось платить по хитрым схемам, в зависимости от того, с кем у ВТ был пиринг. Какие-то ресурсы были копеечные, а на каких-то ты мог влететь на несколько рублей за мегабайт. Вокруг "фекса" и "внешки" и происходили основные бурления.

Скажем, после того, как вас заманило сладкой рекламой, вы обнаруживали, что файлообменник, в общем-то, нелегальный и официально такого ресурса не существует. А раз так то его доступность не гарантируется. Сервер постоянно был оффлайн, а когда поднимался, то из-за количества присосавшихся пользователей работать с ним было невозможно. Однажды какой-то особо умный клиент написал жалобу руководству ВТ: как, мол, так, мне обещали варез и порнуху, где это всё? Админ получил втык (как бы за размещение нелегального ресурса) и пригрозил закрыть файлообменник.
Но это тоже был не выход: народ-то шёл именно на "фекс"! Тогда поступили так: количество публичных коннектов к серверу урезали, разделы с порно и варезом убрали. Но у админа лично можно было купить себе учётку для постоянного доступа без ограничений. Но не думаю, что он сумел на этом нажиться очень скоро сеть заполонили p2p-сервисы, в которых можно было скачать всё, что угодно.

И вот с p2p связана другая часть постоянных сетевых истерик. Те же торренты, если их никак не ограничить, будут скачиваться с любых пиров, которые найдутся через DHT. А как я упоминал внешний трафик был опасно дорог. И хотя существовали подробные инструкции о том, как настроить фаерволл и качалку для локального существования кто эти инструкции вообще читает? Так что каждый божий день на местном форуме появлялись плакательные топики "я попал на трафик"/"вылетел во внеху, родители убьют"/"я никуда не лазил, за що?!". Многие попадали не по разу, ну и не будем их винить себя спросите, вы смогли бы вообще существовать в такой дикости?

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

Ульяновцы на коленях молят об анлиме.Ульяновцы на коленях молят об анлиме.

Слёзные жалобы сработали, но ВТ не было бы ВТ, будь всё честно. Клиенту обещалась скорость доступа, скажем, в мегабит, а на деле он получал 128 килобит в лучшем случае. Когда клиент жаловался, то получал отписку: скорость обещалась ДО мегабита, всё соблюдено! Тогда эта разводка только появилась, но очень быстро была взята на вооружение буквально всеми провайдерами.
Но и это не всё! Как только вы умудрялись скачать на этой скорости пару гигабайт, скорость падала ещё и ещё, до считанных килобит. Какие волны ненависти это рождало не передать словами; иногда ненависть рождала жалобы в ФАС, ведомство устраивало проверку, на время которой ВТ снимало все ограничения а потом заворачивало краник обратно.
Ульяновску приходилось терпеть но не Димитровграду. Местный админ то ли не хотел ставить ограничения, то ли оборудование не позволяло но в нашем городке все имели свои честные шесть-восемь мегабит даже на самых урезанных безлимитных тарифах.

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

  1. Залогиниться на модем и ввести его в режим перепрошивки. Это открывало на нём TFTP-сервер.

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

  3. Переместить залитый файл в /bin, выставить ему права на исполнение и прописать автозапуск в init.

  4. Перегрузить модем в обычный режим.

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

P.S.

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

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

Ну и ещё одна история, уже лично моя: я во времена "до безлимита" написал traffic meter, который считал (но не блочил) внешку в реалтайме. И была такая фишка список локальных айпишников можно было скачать с веб-страницы ВТ, в прогу был встроен автоматический обновлятор этого дела. Я даже сайт запилил для программки, и написал там типа "программа для подсчёта трафика, считает внешку, настроены списки для ВТ". И вот кому-то она насчитала неправильно, и тот "кто-то" опять таки не нашёл ничего умнее, чем нажаловаться в ВТ типа вот тут программа "ваша", считает не правильно, верните бабос! А ВТ уже писала мне письма с угрозами, типа "какого хера". Ну я сигнал понял, сайт снёс, исходники выкинул на форум, типа я не я и хата не моя.

Интересно, есть тут кто-то, сидевший в те времена на "винфе", "дграде", "симиксе"? Или, быть может, у вас есть свои сетевые истории, которыми незазорно поделиться? Может таскали pwl с незакрытых сетевых шар в локалке? Сканили подсеть провайдера, а потом объяснялись с админом? Просиживали бессонные ночи, общаясь в чатах с десятками таких же ненормальных?

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

Подробнее..

Из песочницы Яндекс облако и MikroTik MultiWAN

26.09.2020 18:09:56 | Автор: admin

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


Есть VPC которая администрируется внутренними сервисами и раздает внешние ip внутренним ВМ через шлюз подсети за NATом, что не очень удобно для централизованного администрирования.


Схема внутренней сети и получения внешнего ip в яндекс облаке выглядит следующим образом:



Привязать для всей подсети один внешний постоянный ip можно через NAT-instance или любую ВМ настроив forward, но пробрасывать порты в сеть придётся через изменения конфигурации в самой ВМ и так для каждой подсети. Нужна была реализация управления сетями/подсетями и доступом в одном месте (на момент написания статьи группа безопасности VPC находилась в стадии Preview).


Если коротко, то хотел реализовать такую схему:



Перейду сразу к описанию процесса настройки.


Для примера берем настройки в облаке такие:


Internal1-a  10.1.0.0/24Internal2-a  10.1.1.0/24Internal1-b  10.1.2.0/24Internal2-b  10.1.3.0/24Internal1-c  10.1.4.0/24Internal2-c  10.1.5.0/24

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


Gateway  X.X.X.1Internal DNS  X.X.X.2

Создаем ВМ с образом RouterOS.


В облаке выбираем Cloud Marketplace -> Сетевая инфраструктура -> Cloud Hosted Router и сразу добавляем внешние ip адреса к каждому сетевому интерфейсу


RouterOSEther1  10.1.0.254Ether2  10.1.1.254

Создаем ВМ и подключаемся к ether1 через консоль или клиентом winbox. Создаем пользователя с полными правами, отключаем пользователя admin и добавляем rsa public key.


Далее настраиваем все через CLI. Все действия можно сделать и в winbox, меню соответствует команде, заходим в меню ip выбираем route и т.д.


Если посмотрим в таблицу маршрутизации, то увидим маршруты


/ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit  #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE 0 ADS  0.0.0.0/0                          10.1.0.1                  1 1 ADC  10.1.1.0/24        10.1.1.254      ether2                    0 2 ADC  10.1.0.0/24        10.1.0.254      ether1                    0

По умолчанию маршрут в интернет идет с порта ether1 через шлюз 10.1.0.1 который за NAT выкидывает во внешнюю сеть. Если сейчас опросить все внешние ip адреса, то ответит только первый.


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


Добавляем маршруты


/ip routeadd dst-address=0.0.0.0/0 gateway=10.1.1.1 distance=2 add dst-address=10.1.2.0/24 gateway=10.1.0.1 distance=1  add dst-address=10.1.3.0/24 gateway=10.1.1.1 distance=1  add dst-address=10.1.5.0/24 gateway=10.1.1.1 distance=1  add dst-address=10.1.4.0/24 gateway=10.1.0.1 distance=1 

По умолчанию зоны доступности подсетей b и c должны быть доступны через шлюз подсети зоны доступности a.


Настраиваем firewall.


Входящие соединения внутренних сетей


/ip firewall filteradd chain=input action=accept src-address=10.1.5.0/24 add chain=input action=accept src-address=10.1.1.0/24 add chain=input action=accept src-address=10.1.3.0/24 add chain=input action=accept src-address=10.1.2.0/24 add chain=input action=accept src-address=10.1.0.0/24 add chain=input action=accept src-address=10.1.4.0/24 

Разрешаем ping


/ip firewall filteradd chain=input action=accept protocol=icmp 

Разрешаем проброс вперед


/ip firewall filteradd chain=forward action=accept src-address=10.1.5.0/24 \dst-address=0.0.0.0/0 add chain=forward action=accept src-address=10.1.1.0/24 \dst-address=0.0.0.0/0 add chain=forward action=accept src-address=10.1.3.0/24 \dst-address=0.0.0.0/0 add chain=forward action=accept src-address=10.1.2.0/24 \dst-address=0.0.0.0/0 add chain=forward action=accept src-address=10.1.0.0/24 \dst-address=0.0.0.0/0 add chain=forward action=accept src-address=10.1.4.0/24 \dst-address=0.0.0.0/0 

Остальные входящие соединения сбрасываем


/ip firewall filter add chain=input action=drop log=no

Меняем очередность правил


/ip firewall filter move numbers="[old rule no]" \destination="[new rule no]"

Любуемся результатом


/ip firewall filter print

Реализация выхода в интернет в данном случае через шлюз внутренней сети и у нас нет портов с прямым внешним ip адресом, поэтому реализуем разделение через MultiWAN. Очень хорошо этот метод описан в презентации РЕАЛИЗАЦИЯ MULTIWAN (ссылка на презентацию в конце статьи)


В конфигурации ВМ отсутствуют WAN порты, которые нужно добавить в конфигурацию firewall mangle, поэтому создадим 2 записи в interface list


/interface listadd name="WAN1"add name="WAN2"

Настраиваем firewall mangle


/ip firewall mangleadd chain=input action=mark-connection \new-connection-mark=con-WAN1 passthrough=yes in-interface-list=WAN1add chain=input action=mark-connection \new-connection-mark=con-WAN2 passthrough=yes in-interface-list=WAN2add chain=output action=mark-routing \new-routing-mark=WAN1 passthrough=yes connection-mark=con-WAN1 add chain=output action=mark-routing \new-routing-mark=WAN2 passthrough=yes connection-mark=con-WAN2 

Добавляем маршруты


/ip routeadd dst-address=0.0.0.0/0 gateway=10.1.0.1 distance=1 routing-mark=WAN1 add dst-address=0.0.0.0/0 gateway=10.1.1.1 distance=1 routing-mark=WAN2 

Добавляем правила маршрутизации, все что не попадает под правило идет через порт ether1, добавлять можно как подсети, так и отдельные хосты


/ip route ruleadd src-address=10.1.3.0/24 action=lookup-only-in-table table=WAN2 add src-address=10.1.5.0/24 action=lookup-only-in-table table=WAN2

На данном этапе все 2 внешних ip отзываются, но внутренние сети не работают правильно или вообще не работают.


Настроим маршрутизацию для каждого из двух контуров в консоли яндекс облака:
Virtual Private Cloud -> Облачные сети -> в каждой Подсети выключаем NAT в интернет -> Таблицы маршрутизации -> Создать, если создано изменить -> добавляем маршрут Префикс назначения: 0.0.0.0/0, Next hop: 10.1.0.1/10.1.1.1 для каждого контура свой шлюз -> сохраняем.


Осталось последнее действие, нужно замаскировать все подсети под внутренний адрес роутера


/ip firewall natadd chain=srcnat action=masquerade src-address=10.1.0.0/24 dst-address=0.0.0.0/0 add chain=srcnat action=masquerade src-address=10.1.1.0/24 dst-address=0.0.0.0/0 add chain=srcnat action=masquerade src-address=10.1.2.0/24 dst-address=0.0.0.0/0 add chain=srcnat action=masquerade src-address=10.1.3.0/24 dst-address=0.0.0.0/0 add chain=srcnat action=masquerade src-address=10.1.4.0/24 dst-address=0.0.0.0/0 add chain=srcnat action=masquerade src-address=10.1.5.0/24 dst-address=0.0.0.0/0

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


В итоге реализовали следующую схему:



Можно запускать клиентов/партнеров/внешние сервисы к внутренним ВМ через два внешних ip адреса:


/ip firewall natadd chain=dstnat action=netmap to-addresses=10.1.5.20 \to-ports=10050 protocol=tcp src-address=7.7.7.1 in-interface-list=WAN2 port=10055 add chain=dstnat action=netmap to-addresses=10.1.0.5 \to-ports=3306 protocol=tcp src-address=7.7.7.2 in-interface-list=WAN1 port=11050

где 7.7.7.1/7.7.7.2 внешние ip клиентов.


Далее настраиваем по своему усмотрению, создаем ipsec, режим сети в фаерволе, настраиваем входящие соединения.


Минимум по настройки разделения подсетей и направление трафика через конкретный внешний адрес выполнен.


Лицензию для MikroTik RouterOS необходимо приобрести, иначе скорость портов будет 100 Мбит/с и ограничения по функционалу
https://wiki.mikrotik.com/wiki/Manual:License


Спасибо за внимание!


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


РЕАЛИЗАЦИЯ MULTIWAN

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru