Category: Uncategorized

Добрый день уважаемые читатели. Эта статья посвящена теме того как выявлять инструмент атак на Windows инфраструктуру.

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

Для этого мы пишем IDS правила, и на сегодняшний день их уже 4000. Часть из них мы публикуем в нашем открытом твиттере Attack Detection.

План статьи

В начале мы рассмотрим 3 популярных инструмента для проведения атак на Windows инфраструктуру, затем возьмем по 2 модуля из каждого и разберем как они работают, какую сетевую активность создают и как их можно обнаружить. И в качестве завершения статьи мы покажем Mapping техник из данных инструментов на матрицу атак ATT&CK.

Инструменты, о которых мы сегодня будем говорить называются Impacket, CME и Coadic.

Impacket представляет собой набор Python модулей, и является основой разработки инструментов для атак. он поддерживает большое количество протоколов, которые используются в Windows инфраструктуре, и поставляется сразу с 46-ю готовыми модулями. Также комьюнити его активно развивает, о чем свидетельствует более 700 форков на Github.

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

И, наконец, третий инструмент – Koadic, он самый новый. Был представлен на 25-м Devcon, летом 2017 года. И является продолжателем популярного в последние годы тренда living of the land, что означает использование встроенной в Windows функциональности, только вместо PowerShell он выполняет команды удаленно с помощью Windows Scripting host, который нам известен по интерпретатором JS кода и VB скрипт.

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

Детальный разбор

Данные инструменты также активно используются APT группировками. Например DragonFly использовала Impacket и CME в октябре 2017 года для атак на энергетическую структуру США.

Группировка Sofacy адаптировала под свои нужды новый инструмент Koadic, и в июне 2018 года провела атаки на правительственные организации Северной Америки и Европы.

Группировка Muddy Water продолжает атаковать военные организации Ирака и Саудовской Аравии.

Impacket

И так, начнем с первого инструмента. Функциональность Impacket весьма широка. Начиная от разведки внутри ActiveDirectory и сбора данных с внутренних MS SQL серверов, продолжая техниками для получения учетных записей. Эти учетные записи можно использовать для удаленного выполнения команд. Impacket умеет это делать через 4 разных транспорта.

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

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

Здесь мы видим запрос в ветку Control/LSA. Аналогичным образов выглядит запрос в ветку НТДС. Для обнаружения нам важно имя ключа.

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

Secretsdump использует достаточно примечательное имя. Исходный код дает ответ на то откуда оно такое. Оно берет в код 8 случайных буквенных символов и добавляет к нему “.tmp”, что мы и видим в трафике. Когда значение получено и выгружено в файл, мы можем видеть процесс загрузки этого файла на машину атакующего. отсюда становится понятно, что для сохранения файла и последующей загрузки атакующий использует system32 шару.

Как и многие другие инструменты для пост эксплуатации, Impacket имеет модули для удаленного выполнения команд. Мы остановимся на smbexec И он будет вторым модулем который мы рассмотрим.

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

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

Так выглядит запрос на открытие сервиса контроль-менеджера. Примечательно в нем то, что поле machine name имеет значение dummy. Ответ на это мы нашли в исходном коде и убедились в том что это хард код.

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

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

Impacket является мощным инструментом, но как и все программы он призван автоматизировать, поэтому он имеет свои характерные особенности, которые мы с вами сейчас увидели на примере работы пары модулей. Здесь конкретные winreg запросы, использование SCM API с характерным формированием команд, и формат имен файлов и SMB шара system32.

Мы реализовали подобную экспертизу на наш продукт. PTN Work attack discovery. Он предназначен для выявления атак в сетевом трафике, расследования инцидентов. Вот как детекты выглядят на практике.

Здесь мы видим результат анализа модуля secretsdump. Здесь происходит открытие SCM. Мы видим запросы в ветку LSA CMS Security и НТДС. Также мы можем видеть анализ дампа трафика с smbexec.

Здесь мы видим обращение к SCM.

CrackMapExec

Вторым инструментом, который мы сегодня рассмотрим является CrackMapExec. В будущем мы будем называть его просто CME.

Чем опасен Empire

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

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

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

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

СМЕ модель как раз решает эту проблему. Он создает сервис с использованием atsvc и smb. Далее жертва получает бладхаунд скрипт и исполняет его. После сбора данные отправляются на машину атакующего.

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

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

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

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

Бладхаунд выполнил запрос, а привилегированных SID 500/512/519, то есть администратора и административных группах. Он запросит какие активные сессии есть за этими учетными записями. Это требуется для того чтобы выбрать приоритетные машины для проведения дальнейшей атаки на них.

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

Атакующему необходимо подключиться к namespace виндовс root\SecurityCenter2 чтобы сделать необходимые запросы. Далее происходит запрос классов антиспайвеар продукт и антивирус продукт. По умолчанию у виндовс за эти функции отвечает виндовс дефендер, что подтверждает ответ клиента. Сам запрос выглядит всегда одинаково, и такую активность достаточно легко обнаруживать.

Мы с вами посмотрели на 2 модуля CME. У каждого из них есть свои артефакты. В них входит и специфичные запросы и создание определенного вида задач atsvc с применением обфускации. Характерные для бладхаунд запросы, которые отличные от обычных запросов в виндовс сетях. Также мы увидели не типичную активность через СМБ.

СМЕ не стал исключением и мы научили PTN Work attack discovery обнаруживать его активность.

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

Продолжаем рассматривать лимитирование трафика с использованием нескольких простых скриптов. Сразу перейдем к следующему методу.

1.Настройка одного ПК с помощью HTB-дисциплины за счет виртуального интерфейса IFB

В данном примере будем настраивать сеть с прицелом на следующий результат:

• Скорость входящего трафика: 8 Мбит
• Скорость исходящего трафика: 4 Мбит
• Адаптеры: enp0s3 – внешний

Сразу создаем скрипт:

Предоставляем права для запуска:

Осуществляем старт:

Запускаем проверку:

Скриншот с полученным результатом:

Как видите, в заданные условия мы вложились. Идем дальше.

2.Настройка нескольких ПК с помощью HTB-дисциплины за счет виртуального интерфейса IFB

В данном примере будем настраивать сеть с прицелом на следующий результат:

• Скорость входящего трафика: 8 Мбит
• Скорость исходящего трафика: 4 Мбит
• Адаптеры: enp0s3 – внешний, enp0s8 – внутренний

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

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

Как видите, мы получили ограничение по скорости на вход до 4 Мбит, а на выход – 512 Кб. И все это для всех подключенных устройств в сети по адресу 10.168.50.2/255.255.255.0
Для автозапуска перемещаем скрипт по следующему пути:

3.Настройка с помощью iptables и маркировки устройств

В данном примере будем настраивать сеть с прицелом на следующий результат:

• Скорость входящего трафика: 1 Мбит
• Скорость исходящего трафика: 3 Мбит
• Адаптеры: enp0s3 – внешний, enp0s8 – внутренний

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

Теперь создаем новый файл в директории /etc/sysconfig/shaper.sh с следующим содержанием:

Можно произвести старт:

В итоге, получаем следующий результат:

4.Настройка шлюза с помощью упрощенного шейпера трафика

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

Прописываем следующие строчки в файле:

Тестируем:

Обратите внимание, что мы настроили шейпер трафика на вход до 1 Мбит, а на выход – до 5 Мбит.

5. Настройка с помощью упрощенного шейпера трафика Shaper Control Tool

В данном примере тоже нет жестких параметров по ограничению исходящего и входящего трафика. Однако, мы будем использовать утилиту Shaper Control Tool и два адаптера eth0 на вход и eth1 на выход.

Начнем с установки Shaper Control Tool. В случае с шестой версией CentOS, используйте следующие команды:

А если вы работаете на седьмой версии ОС, то нужно использовать другие команды:

Теперь внесем изменения в файл конфигурации в директории /etc/sc/sc.conf. В итоге, у вас должно выйти следующее:

Проведем инициализацию:

Сформируем БД:

И впишем в файл IP-адрес имеющегося сервера:

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

Проведем синхронизацию всех настроек для БД:

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

6.Дополнительные команды

Для настройки шейпера трафика можно использовать несколько дополнительных команд, которые доступны tc в ОС Linux. Мы приведем самые полезные из них:

• tc – специальная утилита, которая позволяет настроить шейпинг трафика с помощью ядра системы. Вы можете найти ее в пакете iproute2, установка которого была описана ранее. Для использования всех дополнительных команд, вам нужно установить утилиту, после чего работать с доступными командами и интерфейсами.
  imq – виртуальный интерфейс, который позволяет настроить сетевой адаптер для управления очередью трафика. По сути, он нужен для контроля скриптов htb, cbq и tbf, которые мы использовали в своих примерах. Однако, чтобы правильно активизировать данную опцию, нужно пропатчить ядро системы. Довольно устаревший метод, на смену которому пришел ifb.
• ifb – выполняет аналогичные функции, что и виртуальный интерфейс imq.
• htb – позволяет управлять очередью трафика. Является очень распространенным инструментом среди администраторов благодаря своей эффективности и простоте.
• cbq – инструмент для отладки контроля трафика в очереди.
• tbf – инструмент для отладки контроля трафика в очереди.
• red – инструмент для отладки контроля трафика в очереди.
• sfq – практически тот же инструмент для отладки контроля трафика в очереди, но разница лишь в том, что он распределяет пакеты в случайном порядке.

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

Удалить все правила можно с помощью следующих команд:

7.Описание алгоритма для настройки шейпера трафика

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

• Для начала создадим дисциплину в корне, чтобы организовать нужный интерфейс. Также не забываем указывать класс для не распознанного трафика:
  
• Формируем новый класс для определения иерархии. Также задаем ширину канала:
  
• Формируем еще один класс, чтобы организовать шейпинг трафика для пользователя:
  
• Настраиваем конфигурацию дисциплины лимитирования для каждого отдельного пользователя:
  
• Настраиваем фильтры, чтобы идентифицировать поступающей трафик от пользователя. Для этого нам пригодится тот же iptables:
  
  Альтернативный вариант для www:
  
  Еще один вариант для www:
  

На этом мы завершаем данный материал. Надеемся, все описанные примеры помогут вам в создании шейпера трафика для вашей сети!

Задача модели разделения ответ­ственности Office 365 — прояснить, за что несет ответствен­ность корпорация Microsoft и какая доля ответственности падает на компании.

Первый вопрос, который мы слышим постоянно: «Почему необходимо выполнять резервное копирование данных Office 365 Exchange Online, SharePoint Online и One Drive для бизнеса?» И немедленно следом обычно звучит: «Microsoft позаботится об этом». Позаботится? Вы в этом уверены?

Модель разделения ответственности Office 365

Чтобы внести ясность в этот вопрос, мы подготовили модель разделения ответ­ственности Office 365. Ее цель — помочь читателям и всем, кто имеет отношение к данной технологии, точно очертить для себя область ответственности Microsoft и понять, какие обязанности возлагаются на пользователя. В конце концов, это же ваши данные!

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

Эти сведения в основном получены из центра управления безопасностью Microsoft Office 365, и вы можете ознакомиться с ними самостоя­тельно.

В нижней половине показана ответственность компании, или, точнее, ее ИТ-подразделения (рисунок 1).
Начнем с рассмотрения основной зоны ответственности каждой группы. Ответственность Microsoft в основном сосредоточена на глобальной инфраструктуре и обязанности поддерживать ее в работоспо­собном состоянии для миллионов потребителей, стабильно обеспечивая бесперебойное функциони­рование «облачных» служб и про­дуктивную работу пользователей во всем мире.

Ответственность ИТ-подразде­ления — обеспечить полный доступ и контроль над данными, независимо от их местонахождения. Эта ответ­ственность не исчезает по волшебству просто потому, что компания приняла бизнес-решение использо­вать приложение SaaS (рисунок 2). Перед нами вспомогательная технология, с помощью которой каждая группа выполняет свои основные обязанности.

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

Но репликация — не резервная копия. Более того, эта реплика даже не ваша; она принадлежит компании Microsoft. Чтобы уяснить этот момент, ответьте для себя на вопрос: «Что дает полную защиту, резервная копия или реплика?»

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

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

Для полной защиты необходимы как резервная копия, так и реплика. Этот базовый принцип является фундаментом стратегии защиты данных компании, как показано на рисун­ке 3.
Кто-то из читателей может спросить: «А как же быть с корзиной Office 365?» Да, Microsoft предусматрива­ет несколько вариантов «Корзины»

И они могут быть полезны для огра­ниченного восстановления данных. Но для полного контроля над данными понятие «ограниченное» не подходит. Для действительного полного доступа и управления критически важными для бизнеса данными необходимо полное сохранение данных.

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

Следующая часть модели разделения ответственности Office 365 — без­опасность. Она структурирована как объединенный блок (не отдельные блоки), поскольку ответственность за безопасность несут как Microsoft, таки ИТ-подразделение.

Microsoft защищает Office 365 на уровне инфраструктуры. Зашита охватывает физическую безопас­ность центров обработки данных, проверку подлинности и иденти­фикацию в «облачных» службах, а также пользовательские и админи­стративные элементы управления, встроенные в интерфейс Office 365 (рисунок 5).

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

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

Даже если данные находятся в Office 365, на ИТ-подразделение возлагается роль владельца данных. Эта ответ­ственность сопровождается разного рода внешним давлением со стороны отрасли, а также требованиями соот­ветствия, исходящими от юристов и кадровиков (рисунок 6).

В итоге вы должны лучше понять, что именно и почему защищает Microsoft в Office 365. Без резер­вирования Office 365 ваш доступ и возможности управления вашими собственными данными ограниченны. Вы можете пострадать от непродуманной политики хранения и потерь данных. Кроме того, вы подвергаетесь серьезным внутренним и внешним угрозам, а также рискуете нарушить право­вые нормы.

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

Источник: журнал «Windows IT Pro/RE»

Зачастую ИТ-специалисты ошибочно полагают, что, если Microsoft Office 365 размещается в «облаке», отпадает необходимость в дополнительной копии данных. Хотя Microsoft и предусматривает различные способы поддержки для технического обеспечения работы почтовых ящиков Office 365, они остаются вашими данными, и защищать их — ваша прямая обязанность. Что мне нравится в современных технологиях, так это способность практически безупречно производить преобразования. Вспомним в качестве пример а Microsoft Exchange и Microsoft Office 365.

Несколько лет назад Microsoft Office 365 стал привлекательным вариантом для множества приложений, эффективно используемых любой организацией. Это сравнительно плавный переход, поскольку обе­спечивается техническое функци­онирование многих компонентов с похожими приемами использова­ния, таких как: настольное приложение Outlook, сетевой клиент Web Access, приложение для мобильных устройств и т.д.

Однако есть одна характерная черта программного обеспечения, предо­ставляемого как услуга (SaaS): осу­ществление перехода у организаций занимает некоторое время. Я могу рассказать о многих переговорах, проводившихся после анонсирова­ния продукта Veeam под названием Veeam Backup for Microsoft Office 365. Переговоры продолжались на протяжении нескольких лет — параллельно с миграцией.

И хотя случаи развертывания и проблемы у всех разные, но все истории в основном похожи. Например, когда я впервые посещал клиентов, они часто говорили, что реализуют пилотный проект Microsoft Office 365 с несколькими пользователя­ми из ИТ-подразделения. Когда я навещал их на следующий год, они сообщали, что почти наполовину закончили с миграцией. На третий год я, вероятно, услышу от них же, что 90% уже перевели.

Важно поддерживать пользователей на протяжении всего процесса. И это возможно, продукт Veeam позволяет добавлять локальные почтовые организации Exchange к Veeam Backup for Microsoft Office 365. Даже если вы только начинаете использовать Office 365, Veeam Backup для Microsoft Office 365 может сразу применяться для защиты всех локальных данных.

Это очень важно, поскольку можно в полном объеме поддерживать организацию на протяжении всего процесса миграции. Схема, представленная на приведенном рисунке, описывает гибридную организацию, которая использует параллельно классиче­ские установки Exchange и Microsoft Office 365.

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

Совмещенные в этом решении приложения (почта и календарь) распо­лагаются и локально, и в простран­стве SaaS. Наличие согласованного подхода является хорошей практикой в политике резервного копирования: она гарантирует, что ни один почтовый ящик не будет пропущен при резервном копировании входе процесса миграции нескольких продуктов в организации. Такой единый подход также предусматри­вает перемещение между Office 365 и локально установленными системами Exchange.

Возможно, самое примечательное преимущество объединенного подхода—это восстановление. Способы восстановления при помощи продуктов Veeam всегда были простыми, и Veeam Backup for M icrosoft Office 365 не является исключением.

Процессы восстановления происходят под руководством Veeam Backup for M icrosoft Office 365, который представляет собой тот же механизм, что используется для резервного копирования локальных систем Exchange, как показано на экране.

Мастер восстановления запускает интуитивно понятный процесс вос­становления данных либо в Office 365, либо в локальной системе Exchange. Экспорт данных также поддерживается, и, таким образом, создание файла PST или списка объектов тоже можно выполнить.

Источник: журнал «Windows IT Pro/RE»

Специалисты Microsoft планируют открыть исходный код Open Network Emulator, системы, которая имитирует всю сеть, обеспечива­ющую функционирование гипермасштабной «облачной» платформы компании. Microsoft использовала ее примерно в течение года для тестиро­вания изменений, вносимых в сеть, прежде чем развернуть их в производстве.

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

Проработав более года с системой, имитирующей всю глобальную сеть, обслуживающую «облако» Azure, компания Microsoft решила открыть исходный код эмулятора. Система Open Network Emulator (ONE) имитирует все аппаратные и программные устройства, составляющие сеть, и их межсоединения. Она выполняется в контейнерах Docker и на виртуальных машинах и предназначена для тестирования изменений, вносимых инженерами в сеть, перед их развертыванием в действующей сети.

«Передача технологии в общий доступ поможет крупным компаниям повысить время доступности сети и одновре­менно у исследователей появится инструмент для модели­рования гипермасштабных сетей, подобных построенным Microsoft, Google и Amazon, и их совершенствования без соприкосновения с реальными сетями», —объясняет Виктор Баль, директор подразделения Microsoft Research по мобильности и сетевым технологиям.

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

В то время она называлась CrystalNet — хрустальный шар, в котором видно будущее сети, и специалисты Microsoft уже тогда думали о том, чтобы сделать технологию общедоступной. «Наша сеть разнородная, сложная и постоянно под­вергается изменениям. В такой среде даже небольшие проблемы, вызванные отказами устройств, ошибками в программном обеспечении, ошибками в настройках и ненадежными инструментами управления, могут быстро привести к крупным авариям,— объясняется в описании ONE, представленном на конференции Sigcomm.— Поэтому способность оценить влияние каждого планируемого изменения, прежде чем оно внедрено в производство, критически важна для поддержания и повышения надежности сети».

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

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

Теперь, когда сетевые инженеры Azure вносят изменения, эти изменения применяются сначала к модели, но для них этот шаг не прозрачен. «Они даже не знают, вносят ли они изменение в сеть,— поясняет Баль.— В действительности они изменяют эмулятор. Он настолько удачно имитирует базовую сеть, что они не видят отличий».Если изменение не приводит ни к каким ошибкам в модели, то оно автоматически переносится в рабочую сеть.

Источник: журнал «Windows IT Pro/RE»

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

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

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

Чем же методология DevOps обязана открытому исходному коду?

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

Мир DevOps был бы совсем другим без открытых инструментов, таких как Jenkins, Kubernetes, Chef, и контейнеров DOCKER. В то же время, однако, существует ряд важных технологий DevOps, которые не относятся к числу открытых.

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

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

DevOps и открытый исходный код: концептуальная связь

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

Быстрый выпуск программного обеспечения

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

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

Результатом такого медленного темпа разработки и распространения про­граммного обеспечения стало то, что программисты в то время действовали в соответствии с известным принципом, предложенным Фредом Бруксом в книге «Мифический чело­веко-месяц». По словам Брукса, хорошее программное обеспечение — это как изысканное блюдо. Его создание требует времени. Лучше потратить много времени на работу над проектом и попытаться разобраться во всех ошибках до очередного релиза, чем снабжать пользователей быстрыми обновлениями.

Затем, в 1991 году, на сцену вышел проект ядра Linux. Линус Торвальдс, тогдашний 20-летний разработчик Linux, мыслил совершенно иначе, чем большинство программистов того времени. Он выпустил в свободное плавание свой исходный код, прошедший лишь минимальную проверку, рассчитывая на помощь пользователей в исправлении много­численных ошибок, с которыми они неизбежно должны были столкнуться.

Сегодня об этом забыли, но в свое время это стало важнейшим событием. Редакторы Linux Journal тогда писали, что количество и частота выпуска новых версий Linux, драй­веров и утилит «поражает всех, кто знаком с традиционными циклами разработки UNIX».

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

Оперативность и гибкость

Способность создавать гибкие наборы инструментов и при необходимо­сти переключаться с одного инструмента на другой — важное свойство DevOps, обеспечивающее динамичную разработку ПО. Развертывание программного обеспечения гораздо менее эффективно, если вы жестко привязаны к конкретным средствам разработки и платформам.

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

Желание уйти от жесткой привязки было одной из причин завоевания открытыми платформами, такими как Linux и веб-сервер Apache, столь высокой популярности в 1990-х, когда поставщики закрытого программно­го обеспечения строили свои бизнес-стратегии на основе привязки клиентов. Оно также стимулировало обратную разработку платформ, таких как протокол Microsoft SMB, с помощью открытых проектов вроде Samba.

Еще большим благом, чем собственно открытый исходный код, является то, что движение открытого кода способствовало широкому внедрению открытых стандартов. Сегодня даже компании — разработчики про­граммного обеспечения, чей бизнес строго закрыт, вынуждены уважать открытые стандарты и протоколы, потому что в противном случае рынок не примет их всерьез. С точки зрения DevOps это хорошо.

«Чем больше людей изучают код, тем проще найти ошибки»

Одним из девизов сообщества разра­ботчиков программного обеспечения с открытым исходным кодом в 90-х годах стало то, что Эрик Рэймонд назвал законом Линуса, согласно которому (в формулировке Рэймонда), «чем больше глаз, тем быстрее ошибки всплывут на поверхность». Рэймонд имел в виду, что чем больше людей изучают код, тем проще выявить все его уязвимые места.

Такое видение предполагает постоянное и непрерывное сотрудни­чество, которое сегодня является центральным принципом DevOps. Концепция DevOps относит к числу приоритетных задач удаление «барьеров», ограничивающих прозрачность процесса развертывания программ­ного обеспечения и препятствую­щих свободному взаимодействию инженеров разных специальностей.

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

Речь не идет о предоставлении открытого доступа к исходному коду всем желающим, а не только программистам. Но идея, согласно которой специалист по информаци­онно-техническому обслуживанию (IT Ops), которому предоставлена возможность тесно сотрудничать с разработчиками, способен выявить проблему кода, не очевидную для разработчика, имеет много общего с законом Линуса.

Работа над ошибками

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

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

В определенном смысле, в рамках концепции DevOps и непрерывного развертывания, всякая неудача — благо, так как она помогает органи­зациям быстрее внедрять инновации.

Работа над ошибками — концепция, популяризации которой способствова­ли разработчики открытого программ­ного обеспечения. Быстрые циклы выпуска версий платформ, таких как Linux, несли в себе риск возникно­вения ошибок выше среднего, но это был негативный побочный эффект быстрого внедрения инноваций, заключенных в подобных проектах.

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

Именно из-за принятия неудач, в частности, Mozilla Firefox смог пре­вратиться в один из наиболее широко используемых веб-браузеров, несмотря на то что в 1999 году, вскоре после рождения открытого проекта Mozilla, его ведущий разработчик заявил, что это «полный провал».Таким образом, DevOps и открытое программное обеспечение — разные идеологии и движения в сфере ИТ. Однако у них есть общие ключевые концептуальные особенности.

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

Источник: журнал “Windows IT Pro/RE”

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

Разделим процесс на этапы. Всего их будет три:

• Настройка контейнеров 101;
• Как использовать контейнер для других циклов разработки ПО;
• Как интегрировать контейнеры в Continuous Delivery.

Настройка контейнеров 101

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

Не стоит путать контейнер с виртуальной машиной!

Почему именно контейнеры?

Они обладают несколькими существенными преимуществами:

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

Дополнительные возможности

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

Процесс оркестрации

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

Возможность масштабирования

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

Как использовать контейнер для других циклов разработки ПО

Основные преимущества контейнеров проявляются и на различных этапах разработки.

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

Continuous Delivery

А теперь поговорим о самой реализации. Начнем работу следующим решением:

Здесь тоже все делится на три основных этапа:

• Сборка проекта
• Процесс доставки
• Запуск проекта

Еще один взгляд на реализацию:

Итак, начнем.

Docker

Здесь все просто: запускаем Docker на любой удобной для вас ОС. Мы используем Linux.

Docker Registry

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

Docker Registry и GitLab

Теперь подключаем Docker Registry к GitLab. Для этого используем на фирменной утилите Docker HTTPS, а затем интегрируем сам GitLab. Нам было достаточно подключить сертификат по пути /etc/gitlab/ssl и добавить несколько строчек кода в /etc/gitlab/gitlab.rb:

registry_external_url ‘https://docker.domain.com’
gitlab_rails [‘registry_api_url’] = “https://docker.domain.com”

Заметьте, что теперь вам откроется раздел Registry со всеми подробными инструкциями.

Домен

Нам необходимо создать образ под все отдельно взятые ветки, чтобы синхронизировать элементы между собой и публиковать обновления в Docker Registry. Также, можно разместить версии по разным адресам. Чтобы это реализовать, нужно настроить перенаправление запросов к основному домену docker.domain.com.

Nginx

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

GUI Инструменты

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

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

GitLab runner

Это решение понадобится для управления скриптами, которые так или иначе будут встречаться при использовании дополнительных серверов. Для развертывания, используйте executor Shell вместо Docker.

Настройка Continuous Delivery

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

Сборка

Соберем образ, используя gitlab-ci.yml. Все файлы стоит хранить на том же сервере, чтобы обезопасить систему от взлома.

GitLab.xml

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

iris.key

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

pwd.txt

Здесь вы найдете пароль, который также не стоит размещать в репозитории.

load_ci.script

Файл со скриптом, позволяющий подключить аутентификацию для InterSystems IRIS, подгрузить файл GitLab.xml и инициализировать настройку коллбэков, после чего запустится основной код:

gitlab-ci.yml

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

Теперь реализуем Docker Image:

Обратите внимание, что под $CI_COMMIT_REF_NAME мы подразумеваем название самой ветки.

Dockerfile

Создадим Dockerfile, который используется для предыдущего процесса:

Запуск

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

А теперь запускаем новый контейнер-окружение:

Отметим, что Nginx, размещенный в отдельном контейнере, самостоятельно будет перенаправлять поступающие запросы, используя VIRTUAL_HOST.
Отдельные данные нужно держать в InterSystems IRIS. Это реализуется с помощью следующей конфигурации:

• Реализуем iris.cpf как основной файл.
• Размещаем приложения в /csp.
• Размещаем настройки Apache в /httpd/httpd.conf
• Создаем /mgr, куда размещаем базы данных IRISSYS, IRISTEMP, IRISAUDIT, IRIS, USER, файл IRIS.WIJ. Также перемещаем журналы в /journal хранящую журналы, временные файлы в /temp, а логи в messages.log, journal.log, SystemMonitor.log.

Вот что должно получиться в итоге:

Теперь нам понадобится еще одна БД с маппингом области приложения. То есть, используем %Installer, чтобы создать ее и загрузить туда код. Затем создаем маппинг в области пользователя и выполняем остальные настройки:

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

Запускаем процесс тестирования:

Процесс доставки

Осуществляем публикацию:

Образ доступен на GitHub: