Страницы

вторник, 29 июня 2021 г.

Жизненный цикл Red Hat Ceph Storage

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

Различия этих подходов – это нечто искусственное, так как в большинстве случаев компании используют комбинацию из этих двух подходов. Жизненный цикл Red Hat Ceph Storage призван для решения обеих задач: быстрой и медленной. Далее мы более подробно рассмотрим жизненный цикл Red Hat Ceph Storage и его опции.

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

Рассмотрим пример совместимости между минорными релизами. Как только клиент развернул мажорный релиз Red Hat Ceph Storage (на данный момент это Red Hat Ceph Storage 4), он полностью уверен в том, что сможет обновлять релиз в течении трёх лет (или даже дольше в соответствии с новыми условиями), без необходимости обновлять интеграцию с остальными компонентами системы, или тестировать совместимость во временном окружении.


Жизненный цикл Ceph и Red Hat Ceph Storage.

Red Hat является лидирующим участником сообщества Ceph, которое выпускает новый мажорный релиз проекта ежегодно, обычно именуя их названиями головоногих – последние релизы назывались Luminous и Nautilus, а 31 марта 2021-го года был выпущен Pacific (16.2.0).

Продукты Red Hat создаются на базе проектов сообщества, тестируются в течении нескольких месяцев перед релизом и только после этого предоставляются корпоративным клиентам с поддержкой на три года. В соответствии с этим Luminous стал Red Hat Ceph Storage 3, Nautilus – Red Hat Ceph Storage 4, а проект Pacific станет Red Hat Ceph Storage 5, после тщательного тестирования командой качества.

Клиенты Red Hat могут рассчитывать на 36 месяцев стандартной поддержки мажорных релизов Red Hat Ceph Storage с добавлением новых возможностей в течении первых 12 месяцев. Как правило клиенты не столько заинтересованы в дополнительных возможностях, сколько в исправлении ошибок в течении стандартной поддержки.

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

Red Hat вот уже 6 лет соблюдает 12-ти и 36-ти месячный жизненный цикл мажорных версий Red Hat Ceph Storage.

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


Жизненный цикл программного обеспечения Red Hat Ceph Storage.

На сегодняшний день, Red Hat Ceph Storage успешно применяется для обеспечения быстро и медленно обновляемых решений. Это достигается тесной работой с клиентами по планированию и обеспечению актуальности решений, а также за счет предоставления по требованию опций более длинного жизненного цикла. Последняя опция опирается на предложение поддержки расширенного жизненного цикла от Red Hat (Extended Lifecycle Support, ELS).

Часть клиентов Red Hat переходит на новую мажорную версию Red Hat Ceph Storage в течении первого года с его начального релиза. Это очевидно – новая версия обладает большим набором возможностей, более устойчива и проста в поддержке.

Ceph Storage – это флагманский компонент программно-определенного хранилища в предложении программной инфраструктуры Red Hat. Он используется в Red Hat OpenStack Platform в крупных телекоммуникационных компаниях по всему миру. Применяется Ceph Storahe и в ряде развертываний Red Hat OpenShift в разных областях. Вместе с Red Hat OpenShift Container Storage, Ceph Storage хранит наиболее ценные данные, обеспечивая надёжное хранение для глобальных предприятий и организаций.

Также существуют клиенты, которые предпочитают оставаться на релизе Red Hat Ceph Storage дольше трёх лет. Например, из-за тесной интеграции Red Hat Ceph Storage с релизами Red Hat OpenStack Platform, клиенты, использующие облако до 5 лет, а затем заменяющие все целиком на оборудование и программное обеспечение следующего поколения, вместо обновления на месте.

Для таких клиентов Red Hat предлагает поддержку расширенного жизненного цикла (ELS), продлевая жизненный цикл релиза Ceph Storage.


Окончание жизненного цикла Red Hat Ceph Storage 3.

Поддержка расширенного жизненного цикла Red Hat Ceph Storage 3 должна была начаться вместе с окончанием периода стандартной поддержки релиза Red Hat Ceph Storage 3 в конце февраля 2021-го года. Но, как многие заметили, команда клиентских возможностей Red Hat (Customer Experience) с апреля продлила фазу полной поддержки Red Hat Ceph Storage 3 на 3 месяца. Это было сделано для клиентов, которые в виду эпидемии COVID-19 были вынуждены держать ограниченный штат с физическим доступом к центру обработки данных.

Команда управления продуктом (Product Management) заинтересована в том, чтобы клиенты использовали актуальную версию, обеспеченную обновлениями. Благодаря взаимодействию с клиентами команда вносит изменения в политику предложений, чтобы предложения Red Hat были актуальны для максимально широкого диапазона клиентов. На базе обратной связи в 2020-ом году были внесены изменения в программу поддержки расширенного жизненного цикла Red Hat Ceph Storage.

Для некоторых клиентов, внутренние требования не всегда соответствуют потребности оставаться на новейшем релизе Red Hat Ceph Storage, даже если релиз уже не получает исправления ошибок. Соответственно программам поддержки расширенного жизненного цикла (ELS), несмотря на прекращение выпуска исправлений ошибок, продолжает предоставлять поддержку в устранении неисправностей. Клиентам потребуется обновиться до более нового релиза только в случае, когда требуется установка обновления, устраняющего ошибки, что редко происходит в производственных окружениях, работающих несколько лет подряд.


Доступна 6-ая бета-версия Red Hat Ceph Storage 5.

Был анонсирован переход разработки Red Hat Ceph Storage 5 в фазу бета-версии. Нужно отметить, что бета-версия Red Hat Ceph Storage находится в раннем доступе и предоставляется без поддержки. Не рекомендуется обновлять производственные развертывания до релизов из раннего доступа.

Бета-версия Red Hat Ceph Storage 5 доступна через FTP с анонимным доступом. Образ контейнера с Red Hat Ceph Storage 5 доступен через Red Hat Container Catalog. Команда разработки будет рада услышать обратную связь через прямой контакт с Red Hat или через Red Hat Bugzilla.


Заключение.

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

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

вторник, 22 июня 2021 г.

Способы обновления Citrix Virtual Apps and Desktops (XenApp and XenDesktop)

Окончание жизненного цикла релиза с длительной поддержкой (LTSR) Citrix XenApp & XenDesktop 7.15 запланировано на 15 августа 2022 года. Если вы используете данную версию и еще не начали планировать обновление до актуальной версии Citrix Virtual Apps and Desktops, то самое время приступить к процессу. Обновление окружения Citrix позволит продолжить получать исправления безопасности, а также откроет доступ к новым функциям для расширения пользовательских возможностей.

Но обновление может стать испытанием, так как потребует значительных изменений в окружении, что выходит за рамки ежедневных операций поддержки. Не нужно относится к обновлению окружения как к стихийному бедствию, но оно требует тщательного планирования и контроля изменений, чтобы обновление не стало разрушительным для конечных пользователей. Далее будут рассмотрены различные доступные опции с детальным сравнением метода обновления на месте (In-place Upgrade) с параллельным обновлением (Parallel Upgrade).


Выбор версии.

Многие годы Citrix создавала различные опции обслуживания для соответствия потребностям каждого клиента: Citrix Cloud, текущий релиз (Current Release, CR) и релиз с длительной поддержкой (Long Term Service Release, LTSR). Каждый вариант отличается продолжительностью поддержки, компонентами, возможностями, а также способами предоставления исправлений.

Для клиентов, сфокусированных на целостности и стабильности окружения, релиз с длительным поддержкой (LTSR) предоставляет 5 лет основной поддержки и еще 5 лет дополнительной. Клиенты, заинтересованные в новейших возможностях, таких как оптимизация веб-камер, обнаружение EDT MTU и так далее – выбирают текущий релиз (Current Release), который требует более частого обновления. В свою очередь Citrix Cloud предлагает упрощенное управление за счет предоставления доступа к новейшему релизу с возможностями управления версиями рабочих нагрузок – виртуальных агентов доставки (VDA) и множество расширений интеграции с публичными облаками.

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


Обновление на месте (In-Place Upgrade) или параллельное обновление (Parallel Upgrade).

Вопрос обновления окружений Citrix крайне популярен. Благодаря FlexCast Management Architecture (FMA) обновление на месте проще. Но это вовсе не значит, что с данным процессом не связаны никакие риски. В первую очередь потребуется запланировать остановку окружения на время установки программного обеспечения. Для контроллеров доставки Citrix Virtual Apps and Desktops это потребует не только установки компонентов брокера, но и обновления схемы базы данных SQL. Это не повлияет на работу существующих подключений пользователей, но новые подключения в этот период времени не смогут установиться, что не приемлемо для некоторых организаций.

Дополнительно стек Citrix состоит из множества компонентов – сервер лицензий (License Server), Citrix StoreFront, Provisioning Services и прочих – все они имеют свои собственные требования для обновления и связанные с этим трудности. Например, сервер лицензий (License Server) может быть обновлен на месте, так как существует простой процесс установки (хотя неудачное обновление сервера лицензий может привести к серьезным проблемам в развертывании).

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

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


Обновление на месте (In-Place Upgrade).

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

Существуют зависимые компоненты, такие как сервер лицензий (License Server), которые должны быть обновлены перед обновлением сайта Citrix Virtual Apps and Desktops. Сайт Citrix Virtual Apps and Desktops, как и ферма Provisioning Services (PVS), состоит из ряда компонентов: клиентов (виртуальных агентов доставки (VDA)), серверов (контроллеров доставки (Delivery Controller)) и базы данных (базы данных сайта (Site DB), базы данных мониторинга (Monitoring DB) и базы данных журналирования настройки (Configuration Logging DB)), каждый из которых обновляется отдельно. Несмотря на то, что обновление на месте подходит во многих случаях, существуют ситуации, при которых обновление может завершиться неудачно и потребуется откат в начальное состояние. Также предусмотрена процедура минимизации простоя, во время обновления при помощи локального кэша хоста (Local Host Cache, LHC), который позволяет частично поддерживать бронирование сессий на время простоя базы данных.

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

У некоторых клиентов Citrix есть хорошо задокументированный и утвержденный процесс обновления окружения кумулятивными обновлениями (Cumulative Update) и/или версиями текущего релиза (Current Release, CR). Благодаря такой процедуре выявляются и устраняются проблемы в окружении, а также модернизируется документация, которая в последствии может быть использована для обновления на месте.

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

Преимущества обновления на месте (In-place Upgrade):

  • Требуется меньше планирования и проектирования.
  • Не требуются дополнительные серверные ресурсы.
  • Citrix поддерживает широкий диапазон версий для обновления, начиная с XenApp & XenDesktop 7.6 напрямую до требуемой версии и кумулятивного обновления.

Замечания к обновлению на месте (In-place Upgrade):

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

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


Параллельное обновление (Parallel Upgrade).

Для параллельного обновления, собирается новая инфраструктура на базе требуемой версии, отдельно от существующих компонентов. После того как новая инфраструктура будет протестирована, производственные нагрузки могут быть легко пересозданы или перенесены в новый сайт. Агрегация сайтов в StoreFront (Site Aggregation) объединяет опубликованные ресурсы из нескольких сайтов, что позволяет не изменять привычную работу пользователей, при этом администратор может спокойно переводить подключения в новое развертывание. Основное преимущество данного подхода, заключается в новом окружении (которое не наследует проблемы предыдущего) и рабочие нагрузки могут быть перемещены в новый сайт невидимо для пользователей.

Параллельное обновление, как правило, подходит для организаций, заинтересованных в дополнительных изменениях. Примером таких изменений может быть замена устаревших операционных систем (например, Windows Server 2008 R2 на 2016 или 2019), перемещение или консолидация центров обработки данных, уход от окружения с накопленными ошибками. Также параллельное обновление подходит для окружений, которые доставляют критически важное программное обеспечение, требующее около нулевой риск незапланированного простоя.

Преимущества параллельного обновления (Parallel Upgrade):

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

Замечания к параллельному обновлению (Parallel Upgrade):

  • Дополнительные серверные ресурсы требуются для параллельного построения новой инфраструктуры.
  • Потребуется детальное планирование и проектирование.
  • Machine Creation Services (MCS) привязаны к определенному сайту. Поэтому пулированные каталоги могут быть пересозданы в новом сайте достаточно просто, так как они базируются на мастер-образе. Выделенные рабочие столы потребуют процедуры удаления рабочих столов из оригинального сайта и повторной регистрации в новом сайте, а также настройки для них соответствующей группы доставки (Delivery Group).
  • Агрегация нескольких сайтов может обеспечить бесшовное переключение между сайтами.


Миграция в Citrix Cloud.

Применение Citrix Cloud быстро увеличивается за счет преимуществ безопасности, пользовательских возможностей и гибкости настройки. Данный процесс обновления похож на процесс параллельного обновления, где Citrix Cloud предоставляет сервис Citrix Virtual Apps and Desktops, обеспечивающий новый сайт, куда могут быть перемещены и/или где могут быть пересозданы существующие нагрузки.

Преимущества миграции в Citrix Cloud:

  • Citrix Cloud и сервис Citrix Virtual Apps and Desktops исключают потребность в будущих обновлениях инфраструктуры.
  • Citrix предоставляет плоскость управления в качестве сервиса.
  • Новейшие разработки появляются в облаке первыми.
  • Упрощенное и сокращенное управление Citrix.
  • Простой путь подключения к публичным облачным окружениям.

Клиенты могут объединить плоскость управления Citrix Cloud со стабильными версиями релиза с длительным обслуживанием (LTSR) виртуальных агентов доставки (VDA) и использовать преимущества поддержки релиза в 10 лет.

С другой стороны, новые сценарии применения требуют новейших расширений, поставляемых в версиях текущего релиза (CR). Версии виртуальных агентов доставки (VDA) между рабочими нагрузками могут быть комбинированы в зависимости от требований окружения. Для упрощения миграции был выпущен инструмент Automated Configuration Tool (ACT), который позволяет мигрировать каталоги машин, группы доставки, приложения и политики.

Изменения архитектуры при миграции в Citrix Cloud представлены на схеме.

Замечания к миграции в Citrix Cloud:

  • Процесс обновления похож на параллельное обновление, так как Citrix Cloud и Citrix Virtual Apps and Desktops находятся в разных сайтах.
  • Данный подход соответствует будущей архитектуре и направлению развития продуктов Citrix.
  • Citrix Cloud обеспечивает новейшие возможности через облачные релизы со стороны плоскости управления.
  • Клиенты могут поддерживать релизы с длительным обслуживанием (LTSR) на виртуальных агентах доставки (VDA) для обеспечения критических рабочих нагрузок.
  • Citrix Cloud требует новую модель лицензирования (также Citrix предоставляет гибридные права на время миграции).
  • На данный момент Automated Configuration Tool (ACT) не поддерживает все сценарии и в ряде случаев потребуется ручная настройка.
  • Высокая доступность и время бесперебойной работы зависит от сервиса Citrix Cloud и локального кэша хоста (Local Host Cache, LHC), а также от выходящей в скором времени в релиз возможности Service Continuity.


Заключение.

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

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

Напоследок хотелось бы сказать, что несмотря на то, что до окончания поддержки Citrix XenApp and XenDesktop 7.15 осталось больше года – не стоит откладывать планирование и реализацию проекта обновления в долгий ящик.

P.S. Уже доступен текущий релиз Citrix Virtual Apps and Desktops 2106 о его новых возможностях и других новинках рабочего пространства Citrix я расскажу в следующий раз.

четверг, 17 июня 2021 г.

Продвинутые функции и скрипты Windows PowerShell 5

Здравствуйте, коллеги!

Настало время продолжить наше погружение в удивительный мир написания команд на языке Windows PowerShell. В предыдущих двух группах веб-кастов мы разбирали базовые функции и базовые скрипты в Windows PowerShell 5. На этот же раз мы будем разбирать продвинутые возможности функций и скриптов, а также ряд связанных вопросов. Данная группа уже вся записана, она будет состоять из 9 веб-кастов:
  1. Продвинутые функции и скрипты Windows PowerShell 5.
  2. Атрибут CmdletBinding в функциях и скриптах Windows PowerShell 5.
  3. Атрибут OutputType в функциях и скриптах Windows PowerShell 5.
  4. Атрибуты параметров в функциях и скриптах Windows PowerShell 5.
  5. Псевдонимы параметров в функциях и скриптах Windows PowerShell 5.
  6. Проверка параметров в функциях и скриптах Windows PowerShell 5.
  7. Динамические параметры в функциях и скриптах Windows PowerShell 5.
  8. Значение параметров по умолчанию в Windows PowerShell 5.
  9. Документирование функций и скриптов в Windows PowerShell 5.

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

Подробности и видео: LebedevUM.

P.S. Все веб-касты в хронологическом порядке: Windows PowerShell 5.

В следующем веб-касте мы подробнее рассмотрим атрибут CmdletBinding.


среда, 16 июня 2021 г.

Обеспечение безопасности инфраструктуры разрешения имен DNS при помощи Citrix ADC

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

Далее мы рассмотрим, как Citrix ADC может помочь защитить инфраструктуру DNS против известных уязвимостей.


Отравление кэша (Cache Poisoning).

Для уменьшения шанса атакующего на фальсификацию ответа (спуфинг), клиенты DNS должны случайным образом определить идентификатор транзакции и запроса DNS, а также эфемерный порт источника, используемый для отправки запроса DNS. Это требует от злоумышленника быстро угадать 32-ух битное целое число. Но если клиент DNS отправляет подряд несколько запросов серверу разрешения имен, то атакующий для успешной фальсификации ответа должен угадать только 16-ти битный идентификатор запроса (так как эфемерный порт источника UDP является константой).

Citrix ADC позволяет настроить ограничение числа запросов с одинаковым 4-ым полем в заголовке UDP. После достижения порогового значения, Citrix ADC начинает сбрасывать поступающие запросы UDP. Данный лимит можно настроить при помощи следующей команды:

set dns parameter -maxPipeline ЗНАЧЕНИЕ

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

Также можно включить DNSSEC для зоны, размещаемой на Citrix ADC, чтобы избежать отравления кэша (Cache Poisoning).


Атаки амплификации (Amplification Attacks).

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

Одним из способов защиты инфраструктуры от атак амплификации DNS является белые (Whitelist) или черные списки (Blacklist) клиентских IP-адресов. Если защита на базе IP-адресов не подходит, можно определить шаблон атаки, настроить соответствующие политики при помощи выражений политик Citrix ADC и принудительно заставить клиентов, повторно инициировать запросы DNS по TCP. Дополнительно можно настроить конечные точки DNS на IP-адресах передачи любому из узлов (Anycast) для защиты от распределенных атак на доступность (DDoS).


Атака амплификации корневых ссылок (Root Referral Amplification Attack).

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

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

set dns parameter -dnsRootReferral DISABLED


Атака амплификации на базе запроса ANY (ANY Query-Based Amplification Attack).

Тип запроса ANY возвращает все записи для указанного доменного имени. Это обозначает значительно больший размер ответа по сравнению с остальными запросами. Атакующие используют запросы ANY для выполнения распределенных атак на доступность (DDoS) уязвимой сетевой инфраструктуры. Для противостояния подобным угрозам можно настроить ограничивающие политики (Rate-Limiting) для запрещения запросов ANY сверх установленного лимита.

add stream selector dns_anyquery_amplification "dns.req.question.type.eq(ANY)"

add ns limitIdentifierdns_ampl_attack_limitid -threshold 1000 -timeSlice 10000 -selectorName

dns_anyquery_amplification

add dns policy dns_amp_attack_pol "sys.check_limit(\"dns_ampl_attack_limitid\")"

dns_default_act_Drop

bind dns global dns_amp_attack_pol -priority 10add ns variable dns_tcp_requests -type ulong -scope transaction


Атака амплификации DNS на базе NXDOMAIN (NXDOMAIN-Based Amplification Attack).

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

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

Citrix ADC может выступать в качестве авторитетного сервера имен для зон DNS и может устранить атаки амплификации на базе NXDOMAIN при помощи следующих опций настройки:

set dns parameter -NXDomainRateLimitThreshold ЗНАЧЕНИЕ

Если Citrix ADC настроен в качестве прокси, запросы с NXDOMAIN как правило не попадают в кэш. Фоновые серверы переполняются большим числом запросов, чем они могут обработать и в результате перестают обрабатывать корректные запросы. Когда Citrix ADC получает ответ NXDOMAIN, он кэшируется, в итоге выталкивая из кэша корректные записи.

Можно защитить кэш DNS против атак NXDOMAIN за счет выделения только малой части памяти для кэширования негативных записей и за счет установки TTL негативных записей в более низкое значение (рекомендуется использовать значение не более 1 или 2-ух минут). Пример конфигурации:

set dns parameter -maxNegativeCacheSize 200 -maxnegcacheTTL 120

Обратите внимание в примере выше, параметр maxNegativeCache задается в мегабайтах, а maxnegcacheTTL – в секундах.


Туннелирование DNS (DNS Tunneling).

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

Техники обнаружения туннелей DNS, такие как анализ полезной нагрузки и анализ траффика могут помочь при устранении данной угрозы. Анализ полезной нагрузки DNS исследует один или более запросов на предмет индикаторов туннеля. При помощи анализа траффика учитываются объем и шаблоны на протяжении отрезка времени. Число, частота и прочие атрибуты запросов могут также учитываться. При помощи богатой инфраструктуры политик DNS в Citrix ADC можно реализовать обнаружение на базе полезной нагрузки и трафика.

Если Citrix ADC находится перед фермой серверов LDNS, необходимо устранить возможность туннелирования DNS, чтобы ресурсы использовались только для разрешенных сценариев применения DNS. Решение, представленное ниже, основано на предположении, что длина доменных имен должна быть короче 200 байт и размер полезной нагрузки запросов DNS не должен превышать 256 байт.

add dns policy dns_tunnel_payload_1 "dns.req.question.domain.length.gt(200)" dns_default_act_Drop

add dns policy dns_tunnel_payload_2 "dns.length.gt(256)" dns_default_act_Drop

bind dns global dns_tunnel_payload_1 20 -gotoPriorityExpression next -type REQ_DEFAULT

bind dns global dns_tunnel_payload_2 30 -gotoPriorityExpression next -type REQ_DEFAULT


Атака TCP Slowloris.

Атакующий может отправить запрос DNS по частям и стек сервера будет ожидать завершения запроса в рамках определенного периода простоя. Однако атакующий может не послать все данные целиком или отправлять части с большим интервалом между ними. Это может привести к отказу в обслуживании корректных запросов (из-за потребления памяти на сервере имен для поддержки соединений TCP в рамках периода ожидания множества частей запросов). Следующая конфигурация Citrix ADC позволит устранить подобные атаки:

set dns parameter -splitPktQueryProcessing DROP


Заключение.

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

Узнать больше о политиках DNS, можно при помощи документации Citrix по темам политик ответчика (Responder Policy) для DNS и политик перезаписи (Rewrite Policy) для DNS.

четверг, 10 июня 2021 г.

Управление скриптами Windows PowerShell 5

Вот и настал черед для заключительного веб-каста в теме базовых скриптов Windows PowerShell.

В веб-касте представлены команды на языке Windows PowerShell, возможности управления скриптами при помощи переменной $env:Path, а также использование простых библиотек на основе технологии «Dot-sourcing» или «Dotting».

Подробности и видео: LebedevUM.

P.S. Это заключительный 5-ый веб-каст в группе, поэтому если вы не знакомы с базовыми скриптами, рекомендую обратить внимание на предыдущие веб-касты группы:

Все веб-касты в хронологическом порядке: Windows PowerShell 5.

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

[IMG]

среда, 9 июня 2021 г.

Оптимизированные под память файловые группы в SQL Server 2019

Пришло время для очередного веб-каста по SQL Server 2019. А здесь мы добрались до файловых групп, оптимизированных под память (Memory-Optimized File Group) и технологии размещения базы данных в оперативной памяти (In-memory Database).

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

Подробности и видео: LebedevUM.

P.S. Если вы хотите подробнее познакомиться с другими типами файловых групп в SQL Server 2019, рекомендую посмотреть следующие веб-касты:

понедельник, 7 июня 2021 г.

Обратное проксирование NGINX в CentOS 8

Очередной веб-каст, посвященный NGINX в CentOS 8. На этот раз в центре внимания возможности обратного проксирования (Reverse Proxy).

В веб-касте вы найдете описание сервера NGINX и предварительных требований для развертывания обратного прокси в CentOS 8. Центральное место в веб-касте отведено установке NGINX и настройке обратного проксирования в CentOS 8. Дополнительно в веб-касте демонстрируется настройка SELinux, для разрешения проксирования трафика.

Подробности и видео: LebedevUM.

P.S. Это уже 4-ый веб-каст в группе, поэтому если вы не знакомы с веб-сервером NGINX, рекомендую посмотреть предыдущие веб-касты группы:

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

четверг, 3 июня 2021 г.

Предварительная версия образа контейнера Windows Server для Windows Server 2022

29 апреля 2022 года была анонсирована предварительная версия образа контейнера базовой операционной системы Windows Server, собранного из Windows Server 2022 с возможностями рабочего стола (Desktop Experience). Для того чтобы попробовать образ контейнера на базе хоста контейнеров с Windows Server 2022 – внутренняя сборка 20344, воспользуйтесь следующей командой:

docker pull mcr.microsoft.com/windows/server/insider:10.0.20344.1

Прямая ссылка на репозиторий образов в Docker Hub: https://hub.docker.com/_/microsoft-windows-server-insider/.

Причины создания нового образа.


На данный момент существует три образа контейнеров с базовой операционной системой Windows, которые покрывают широкий спектр клиентских потребностей:
  • Nano Server – ультра-легкий образ контейнера для современной разработки новых приложений.
  • Server Core – образ контейнера среднего размера, лучше всего подходящий для переноса приложений Windows Server.
  • Windows – образ контейнера самого большого размера с практически полной поддержкой интерфейса разработки приложений (API) Windows для специальных рабочих нагрузок.
Образы контейнеров Nano Server и Server Core широко применяются и постоянно увеличивают свое присутствие. В последний год по увеличившейся активности в сообществе GitHub и количеству обращений в поддержку наблюдается увеличение интереса и к образу Windows.

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

Некоторые из ограничений изначально присутствовали в контейнерах ещё на этапе проектирования, так как образ контейнера Windows построен из полной редакции клиентской версии операционной системы Windows и настроен для запуска на Windows Server. Но команда разработки продолжает вкладываться в контейнеры Windows, пришло время создать новый образ на базе полной редакции Windows Server, чтобы обеспечить больше возможностей. В качестве «полной редакции» будет выступать Windows Server 2022 с возможностями рабочего стола (Desktop Experience). Формально, его можно рассматривать как ядро сервера (Server Core) с пользовательским интерфейсом рабочего стола (Desktop UI). В результате, был создан образ контейнера, который будет добавлен во все связанные репозитории Microsoft Container Registry (MCR) и страницы Docker Hub. Нужно отметить, что несмотря на то, что данный образ создан из редакции с возможностями рабочего стола (Desktop Experience), контейнеры Windows не имеют графического пользовательского интерфейса, и новый образ этого не изменит.

Имя нового образа.


Контейнеры Windows сами по себе не являются независимыми продуктами, они являются компонентами Windows Server. Вне зависимости от выбранного имени, команде разработки необходимо показать связь, а также избежать неудобства от дублирования. В MCR можно увидеть имя «mcr.microsoft.com/windows/server», этот образ еще называют «Windows Server Base OS Image», а также сокращенно: «Server Base Image» или «Server Image».

Особенности нового образа.


Новый образ будет доступен только вместе с Windows Server 2022. В случае использования образов Windows из предыдущих релизов, которые не сняты с поддержки, таких как: полугодовые релизы Windows Server сборки 1809, 1909, 2004 и 20H2 – эти образы не изменятся в рамках их циклов поддержки. Новый же образ не доступен с предыдущими релизами.

Быстрое сравнение между всеми четырьмя образами.

Образ контейнера Основной сценарий применения Сжатый размер Windows Server 2022 Windows Server 2016, 2019 Полугодовые релизы Windows Server 1809, 1909, 2004, 20H2
Nano Server
Современные приложения, такие как приложения .NET Core.
Ограниченная совместимость приложений.
112 MB X X
Server Core
Приложения .NET Framework.
Улучшенная совместимость приложений.
1.2 GB X X X
Windows
Приложения .NET Framework.
Лучшая совместимость приложений с ограничениями.
3.4 GB X
Server
Приложения .NET Framework.
Наилучшая совместимость приложений.
3.1 GB X



Примечание.

Поддерживаемая версия на сегодняшний день – это список релизов Windows Server, на которых образ контейнера поддерживается или будет поддерживаться. Например, образ Nano Server вышел вместе с полугодовыми релизами Windows Server сборки 1809, 1909, 2004 и 20H2, а также будет поддерживаться в релизе Windows Server 2022. Данный список может меняться, так как некоторые релизы будут достигать срока окончания поддержки.


Главные преимущества и возможности нового образа.


По сравнению с текущим образом Windows:
  • Меньший размер. Размер уменьшился с 3.4 GB до 3.1 GB.
  • Улучшенные производительность и устойчивость. Многие годы команда разработки улучшала производительность и устойчивость образов контейнера Server Core, благодаря широкому внутреннему и внешнему применению. Данный образ наследует все улучшения от Server Core.
  • Поддержка канала длительного обслуживания (LTSC). Планируется поддержка данного образа сроком в пять лет основной поддержки.
  • Серверные возможности. Процесс проверки еще не завершен, но новый образ контейнера будет поддерживать больше серверных сценариев/возможностей.
    • Подключения IIS. Существует ограничение в 10 подключениях. Новый образ не будет иметь данного ограничения.
    • Интерфейс разработки приложений Web Management Services (WMSVC). На данный момент проверка ещё не закончена, но, как ожидается, новый образ будет полностью поддерживать WMSVC API.
  • Более полная поддержка интерфейса разработки приложений (API).
  • Поддержка GPU. Анонс поддержки GPU состоялся ещё в апреле 2019-го года. Команда разработки уже завершила проверку поддержки GPU на новом образе.

Начать использовать.


Шаг 1. Установить предварительную версию Windows Server 2022 (Insider).

Чтобы начать использовать, потребуется установка Windows Server 2022 на базе предварительной сборки 20344. Загрузить предварительную версию Windows Server 2022 можно на странице Download Windows Server Insider Preview. При помощи загруженного ISO (или VHD) необходимо создать виртуальную машину.

Шаг 2. Установить Docker.

При работе с предварительной версией Windows Server 2022, воспользуйтесь следующими командами PowerShell для установки Docker:

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Package -Name docker -ProviderName DockerMsftProvider
Restart-Computer -Force

После перезагрузки машины, выполните команду «docker info», чтобы убедиться в корректности установки Docker.

Шаг 3. Выгрузить новый образ.

docker pull mcr.microsoft.com/windows/server/insider:10.0.20344.1

Шаг 4. Запустите новый образ.

docker run -it mcr.microsoft.com/windows/server/insider:10.0.20344.1 cmd


Примечание.

На хосте Windows Server, контейнеры по умолчанию запускаются в режиме изоляции процесса (Process-isolation Mode). Дополнительную информацию по режимам изоляции можно получить по ссылке: Windows Server Container Isolation Modes.

Если вы хотите попробовать то же самое на машине с Windows 10, воспользуйтесь следующей инструкцией: Use Containers with Windows Insider Program, но обязательно убедиться, что вы используете новейший внутренний релиз (Insider) Windows 10, например сборку 21364. На хосте Windows 10 контейнеры по умолчанию запускаются в режиме изоляции Hyper-V (Hyper-V Isolation Mode).

Заключение.


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

Команда разработки будет рада, если вы попробуете новый образ контейнера и оставите обратную связь в сообществе GitHub или наприте ее напрямую: win-containers@microsoft.com.