Страницы

вторник, 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]