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

Блог компании инфосистемы джет

Сезон охоты открыт разбираемся в тонкостях Threat Hunting

02.10.2020 14:18:50 | Автор: admin
Threat Hunting, он же проактивный поиск угроз, регулярно становится предметом дискуссий ИБ-специалистов. Споры возникают как вокруг того, что именно считать хантингом, так и о том, какие методы и подходы лучше использовать. Под катом мы рассмотрим все эти элементы и поделимся видением Threat Hunting, которое прижилось у нас в Jet CSIRT.



К чему приводит путаница вокруг Threat Hunting


В 2019 г. аналитики Authentic8 провели большой опрос ИБ-специалистов, которые занимаются проактивным поиском угроз в средних и крупных организациях, чтобы выяснить, как этот процесс выстроен в их компаниях. Об успешном опыте заявили далеко не все респонденты: почти 11% опрошенных отметили, что с введением Threat Hunting не заметили улучшений с точки зрения информационной безопасности. В то же время опрос показал довольно опасные тенденции. Например, среди самых популярных методов проактивного поиска угроз были названы использование индикаторов компрометации (Indicator of Compromise, IoC) и применение алертов от систем безопасности, что напрямую противоречит всем best practices от ведущих специалистов и организаций.


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

Исходя из результатов опроса, можно сделать вывод, что до сих пор не все специалисты правильно понимают, что такое Threat Hunting. Об этом говорит и малочисленное использование гипотез при проведении хантинга. Так, лишь 35% опрошенных опираются на hypothesis-driven хантинг, и за последние три года этот показатель значительно снизился. Применяя неправильные подходы, компании испытывают разочарование в Threat Hunting и лишаются возможности усилить безопасность защищаемой инфраструктуры.

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


Алгоритм проведения охоты, основанной на гипотезах

Четыре ответа на вопрос Зачем охотиться?


Целей, которые ставят перед собой специалисты по Threat Hunting, насчитывается достаточно много. Вот какие мы в Jet CSIRT выделяем для себя:

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

С чего начинается охота на угрозы?


В отличие от процесса реагирования, который детально описан в NIST 800-61, у Threat Hunting нет четкой стандартизации. Поэтому для проведения проактивного поиска угроз компаниям приходится создавать собственные подходы на основе общедоступных практик построения хантинга.

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

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

В чем их отличия? При реактивном подходе аналитик приступает к реагированию на инцидент, получив информацию о нем из средств детектирования или мониторинга (SIEM, IPS/IDS, AV и т. д.) либо из других источников: от сотрудников, подрядчиков, органов надзора. При проактивном подходе аналитик пробует вручную, с помощью доступных инструментов (SIEM, EDR, DLP, анализаторы трафика и т. д.), найти в инфраструктуре следы компрометации, на основании которых можно сформировать или скорректировать правила для автоматического выявления обнаруженных инцидентов. Особенность этого метода заключается в том, что его нельзя полностью автоматизировать.

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

Структура Threat Hunting достаточно обширна, в статье мы ограничимся следующей:


Структура Threat Hunting

Выбираем подход к охоте


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

TaHiTi


Этот подход объединил в себе элементы Threat Hunting и Threat Intelligence (TI). TI в нем служит основным источником сбора информации и выдвижения гипотезы. Сам подход состоит из трех процессов: инициализация, хантинг и подведение итогов.

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


    Триггеры процесса инициализации
  2. Хантинг. На этом этапе специалист уточняет всю необходимую информацию и на основе всех собранных данных выдвигает гипотезу. Она может быть принята, отвергнута или оказаться неубедительной. В последнем случае аналитик может вернуться к предыдущему шагу для уточнения данных или наполнения выдвинутой гипотезы новой информацией. После этого на основе данных и гипотезы проводится расследование. Каждый раз, сталкиваясь с недостатком информации, специалист возвращается к этапу инициализации для сбора дополнительных данных, тем самым делая процесс хантинга итеративным.
  3. Подведение итогов. Завершив все операции, аналитик создает отчет с перечнем выполненных действий. В нем также могут быть описаны рекомендации по улучшению блокирующих мер (от простых изменений конфигурации до изменений архитектуры), ведению журнала, сценариям использования мониторинга безопасности и процессам (улучшения в управлении уязвимостями или конфигурацией). В документе должен обязательно присутствовать раздел пост-инцидентная активность с объяснением того, как охота помогла аналитику стать лучше.

Endgame


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

  1. Для начала необходимо предположить гипотезу. Она должна быть достаточно подробной, чтобы аналитик, проводящий охоту, мог доказать или опровергнуть ее. Источников доказательства выдвинутой гипотезы может быть несколько: имена процессов, пути, хеши, аргументы командной строки. Мы рекомендуем выбрать два-три источника.
  2. Второй шаг проведение аналитики по собранным доказательствам. Специалист группирует, обогащает и анализирует данные для проведения хантинга. Результат проделанных операций включает в себя выявление аномальных действий или последовательностей событий, связанных с атаками.
  3. Третий шаг является основным элементом в подходе Endgame. Он заключается в автоматизации первых двух шагов. На этом этапе аналитик должен выстроить процесс для сокращения времени хантинга и задокументировать все его составляющие.
  4. Далее остается подвести результаты хантинга. По методу Endgame, одним из показателей эффективности охоты является количество и серьезность выявленных инцидентов и проблем.

Два вида хантинга: структурированный vs. неструктурированный


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

Неструктурированный хантинг


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

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

  1. Какие поля, вероятнее всего, будут содержать свидетельства компрометации?
    Речь идет о полях и атрибутах выбранного источника данных, которые могут содержать доказательства атаки. В событиях прокси-сервера это, вероятнее всего, User-Agentы, URLы, IP-адреса и FQDN.
  2. Что будет являться аномалией?
    Тут нужно определить критерии аномальности выбранных атрибутов и полей. В нашем случае это могут быть названия атрибутов, имитирующие легитимные или не часто встречающиеся сущности и т. д.
  3. Как можно найти доказательства в данных?
    Чтобы найти доказательства для подтверждения гипотезы, могут понадобиться различные манипуляции с данными. Возможно, найти аномалии удастся с помощью простого поиска, или же для этого придется сделать статистический анализ данных, проанализировать частоту появления интересующих событий, применить методы визуализации для обнаружения подозрительных сущностей.

Структурированный хантинг


Структурированный хантинг это поиск угроз на основе гипотез об атаках, которые могли произойти в инфраструктуре. Этот вид имеет четко выстроенную структуру поиска и опирается на данные и знания об атаках, которые совершают злоумышленники. Для проведения такого типа проактивного поиска аналитику нужно откуда-то черпать знания о реальных атаках, нужен некий фреймворк, который поможет ему понять, как действуют злоумышленники. На сегодняшний день наиболее популярным фреймворком для проактивного поиска угроз является MITRE ATT&CK.

Для примера возьмем гипотезу о том, что злоумышленники могли использовать механизм BITS (MITRE ID: T1197) для скачивания вредоносных нагрузок, постоянного исполнения вредоносного кода или же уничтожения следов после его исполнения. Механизм BITS обычно применяется приложениями и сервисами, которые работают в фоновом режиме и используют свободную полосу пропускания. Задачи BITS содержатся во внутренней базе, никак не модифицируют реестр и не зависят от перезагрузок системы. Управление такими задачами может осуществляться через Powershell или специальный инструмент BITSadmin.


Фрагмент статьи на сайте MITRE

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

  1. Какие данные нужны для проверки гипотезы?
    Для ответа на этот вопрос нужно понять, какие требуются события и из какого источника. В нашем примере, вероятно, мы сможем найти интересующую информацию в журнале аудита Windows Security в событиях EventID:4688 (A new process has been created) или Sysmon EventID:1.
  2. Какие следы атаки можно найти?
    Для этого можно обратиться к той же статье на MITRE. В разделе Detection написано, в каком направлении следует двигаться для того, чтобы найти подозрительную активность:
  3. Каким образом можно обнаружить эти следы?
    Ответ на этот вопрос будет таким же, как и в предыдущем примере.

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

EvenID:4688 AND ProcessName contains BITSAdmin.exe AND CommandLine in [Transfer, 'Create', 'AddFile', 'SetNotifyFlags', 'SetNotifyCmdLine', 'SetMinRetryDelay', 'SetCustomHeaders', 'Resume']

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

EvenID:4688 AND ProcessName contains *bits*

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

Где искать источники для гипотез


  1. MITRE ATT&CK Matrix. Уже упомянутая база знаний о применяемых техниках, тактиках и процедурах (TTP), которые злоумышленники применяют в реальных атаках. Помимо рекомендаций по обнаружению, MITRE также содержит ссылки на отчеты, где та или иная TTP была замечена in-the-wild:


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

  2. MITRE Cyber Analytics Repository. Репозиторий аналитики, основанный на MITRE ATT&CK, содержащий псевдокод запросов для поиска определенных TTP, который сразу же можно применять в своей системе. Вот пример, позволяющий обнаружить удаление теневых копий Windows:

    process-search Process:Create
    vssadmin_processes = filter processes where(
    command_line = * delete shadows and
    image_path = C:\Windows\System32\vssadmin.exe)
    output vssadmin_processes
  3. Знание о данных. Информация о типах и источниках данных в инфраструктуре, а также об аномалиях, которые можно найти в этих данных.
  4. Знание инфраструктуры. Информация о слабых местах или уязвимых активах защищаемой инфраструктуры и понимание того, как злоумышленник может их проэксплуатировать. Например, зная, что в тестовом контуре имеются непропатченные активы и это может стать лазейкой для хакеров, можно построить гипотезу о том, как злоумышленник может использовать их расположение для проведения атаки.
  5. Результаты пентестов. Результаты практического анализа защищенности инфраструктуры, исследований векторов проникновения в сеть. По сути, тот же самый репозиторий аналитики, который содержит информацию об атаках именно на вашу инфраструктуру. Лучшего источника для проверки гипотез и придумать сложно.
  6. Threat Intelligence. Аналитические отчеты о новых угрозах и видах атак, сведения, полученные от ИБ-организаций, производителей ИБ-решений, из киберкриминалистических расследований.
  7. ИБ-осведомленность. Оценка актуальных угроз в сфере ИБ, геополитической ситуации, угроз ИБ для сферы деятельности защищаемой инфраструктуры.
  8. Гипотеза также может быть сформирована на основе подозрений коллег, руководства или заказчика, на основе методов OSINT (информация, полученная из групп, форумов, теневых площадок), наблюдений, собственной интуиции и предположений.

Кейс: гипотеза об эксплуатации уязвимости SIGRed


Особое внимание в качестве источника идей для хантинга привлекает Threat Intelligence. Чтобы продемонстрировать, как TI может служить основой для гипотез при проактивном поиске угроз, давайте рассмотрим недавно обнаруженную уязвимость SIGRed. В своем отчете специалисты Check Point Software Technologies подробно разобрали ее суть.

Исходя из отчета, можно прийти к выводу, что уязвимость детектируется по подозрительным дочерним процессам службы DNS Windows и нетипичным DNS-ответам (>6k бит), указывающим на попытки переполнения буфера. Такое заключение будет служить основой для гипотезы.

Вот как может выглядеть гипотеза: Злоумышленники могли проэксплуатировать уязвимость SIGRed (CVE-2020-1350) и получить права администратора домена защищаемой инфраструктуры.

Руководствуясь подходом структурированного Threat Hunting (Attack Based), ответим на вопросы для проведения поиска.

  1. Какие данные нужны, чтобы найти следы компрометации?
    Согласно отчёту Check Point Software Technologies, можно выделить два способа детектирования атаки SIGRed:

    • Порождение процессом dns.exe неидентифицированных подозрительных процессов. В этом случае поиск может выглядеть примерно так (применимо только для Windows 10):

      EvenID:4688 AND ParentProcessName:dns.exe AND process.name != conhost.exe
    • Выявление слишком тяжелого DNS-ответа, которое свидетельствует о переполнении буфера. В этом случае поиск может выглядеть примерно так:

      EventType: NetworkTraffic AND DestinationPort:53 AND ReceivedBytes>60000

    Соответственно, для проведения поиска нам нужны данные запуска процессов Windows (EID:4688, Sysmon EID:1) и сетевого трафика (например, Zeek, Suricata).
  2. Какие следы атаки можно обнаружить в данных?
    • В первом случае мы можем обнаружить неидентифицированные процессы, порождаемые dns.exe, что может говорить о попытках исполнения RCE в результате эксплуатации уязвимости SIGRed.
    • Во втором мы можем обнаружить большие ответы DNS, что может указывать на попытки переполнения буфера нашего DNS-сервера удаленным злоумышленником.
  3. Какие манипуляции с данными необходимо проделать, чтобы выявить следы атаки?
    • Мы можем сделать поиск всех процессов, порождаемых dns.exe, и вывести их командлайны. Выполнить визуальный осмотр, при необходимости сделать группировку по наиболее частым и отфильтровать легитимную активность.
    • В случае с сетевым трафиком достаточно выполнить поиск. Обнаружение ответов DNS более 60000 байт будет требовать дальнейшего разбирательства.

Этот пример проактивного поиска следов SIGRed всё же достаточно просто автоматизировать для выявления в будущем, поскольку он сконцентрирован на частном случае конкретной уязвимости. Многие компании, адаптировавшие Threat Hunting, даже следуют золотому принципу hunt once detect forever, однако он далеко не всегда применим.

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

***

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

Авторы: Никита Комаров и Александр Ахремчик, Центр мониторинга и реагирования на инциденты ИБ Jet CSIRT компании Инфосистемы Джет
Подробнее..

Must have для SOC как выбрать сценарный подход к выявлению угроз

09.10.2020 12:10:51 | Автор: admin
Для запуска корпоративного SOC или ситуационного центра управления ИБ мало внедрить систему мониторинга (SIEM). Помимо этого, нужно предусмотреть кучу всего, что понадобится команде SOC в работе. Методики детектирования, правила корреляции, наработки по реагированию всё это должно укладываться в единый подход к выявлению инцидентов. Без этих вещей рано или поздно в команде будут возникать рядовые вопросы на уровне, что и как работает, кто за что отвечает, какие есть белые пятна и куда развиваться, как показать результат работы и развития.

Я решил поделиться тем, как мы с командой Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT сами формировали такой сценарный подход и как используем его на практике для защиты наших клиентов. Сегодня расскажу, что мы взяли за основу, как решали сложности и к чему в итоге пришли. Забегая вперед, отмечу, что наш подход не следует воспринимать как абсолютную истину. В случае с корпоративным SOC он может быть в каких-то местах полезным, а в каких-то избыточным.



Шаг 1. Выбор требований к подходу


Первым делом мы выделили шесть основных требований, которым должен был отвечать наш сценарный подход.

  • Гибкость логики
    Нам было важно иметь возможность быстро скорректировать логику корреляционного правила, например, добавить определённый профиль или исключение.
  • Реализация на любой SIEM-системе
    Мы изначально создавали Jet CSIRT мультивендорным, чтобы в качестве основного ядра можно было использовать практически любую SIEM-систему. Потому и большинство наработок нужно было унифицировать под любую систему мониторинга.
  • Применимость при масштабировании инфраструктуры
    Мы сразу предусмотрели возможность развития и расширения инфраструктуры, при которых наши наработки не должны были выпадать из выстроенных процессов.
  • Понятное представление
    Нам также нужно было иметь возможность предоставлять клиентам информацию по детектируемым угрозам в простом понятном виде, без кода и усложнений.
  • Возможность покрыть разные наборы различных систем и средств защиты
    Инфраструктуры наших клиентов построены с применением разных систем, средств защиты, ПО и их конфигураций. Поэтому мы хотели, чтобы сценарный подход максимально покрывал эти системы, основываясь на их типе или классе.
  • Возможность выбора сценариев по заданным критериям
    Наконец, мы уделяли большое значение легкости выбора сценариев по заданным критериям: тип контролируемой системы, вид контролируемой активности и т. п.

Шаг 2. Поиск основы


Для разработки подхода мы обратились к лучшим практикам:

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

  • Чтобы обеспечить возможность объединения активностей по определенным критериям, решили ориентироваться на APT Kill chain и Insider Kill chain.
  • Для понимания, что и какими методами детектируется, использовали категории, техники и тактики MITRE ATT&CK.
  • Взяли на вооружение наработки по логике корреляционных правил, в том числе и тех, что уже были созданы в Jet CSIRT.

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

Сценарий представляет собой общее описание условий вредоносной, нежелательной или контролируемой активности и объединяет условия по виду активности и набору заданных маркеров: этапы Kill chain, ID техник, название тактик MITRE и другие.

Ниже пример выделения схожих техник MITRE и дальнейшего выделения источников информации для объединения набора правил.

Пример объединения правил в набор

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

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

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


Шаг 3. Работа со сценариями


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


Содержание карточки сценария

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



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


Пример раздела с логической структурой


Пример правил для SIEM

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


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

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

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


Миграция по клиентам

Шаг 4. Развитие сценариев


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

  • Наши собственные исследования на основе открытых и закрытых отчетов по целевым атакам и информации о новом вредоносном ПО.
  • Собственный опыт предоставления услуг по мониторингу и реагированию, участия в расследовании инцидентов, реагировании на атаки и пост-инцидентной активности.
  • Новые техники и тактики из MITRE ATT&CK, которая постоянно растет и развивается.
  • Целевые запросы от клиентов, в которых ту или иную задачу требуется решить средствами системы мониторинга.

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


Развитие сценариев

По итогам


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

  • Мы систематизировали и структурировали все знания, а также объединили атомарные техники выявления угроз в группы, чтобы нам было проще ориентироваться в возможностях детектирования угроз.
  • Новые члены команды могут без каких-либо сложностей изучить, что и как работает в Jet CSIRT. С появлением методики нам удалось максимизировать спектр детектирования угроз.
  • Мы добились легкого представления детектируемых угроз для ИБ-специалистов, не знакомых с SIEM-системами.
  • Нам удалось исключить проблему с потерей наработок, когда какие-либо файлы с информацией могли быть уничтожены, утеряны или храниться у их создателей.
  • Мы унифицировали обработку инцидентов: на все имеющиеся сценарии написали полные плейбуки с необходимыми действиями и мерами.
  • У нас появилась возможность быстро и без каких-либо трудностей воспользоваться любым из реализованных правил без доступа к определенной SIEM-системе. Мы реализовали контроль версий и вносимых изменений в состав логики и добавляемых исключений для сценария.

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

Автор: Дмитрий Лифанов, ведущий аналитик Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT компании Инфосистемы Джет
Подробнее..

Заменит ли автоматизация пентестеров?

16.10.2020 10:22:46 | Автор: admin
Тестирование на проникновение (penetration testing, pentest) вероятно, самая показательная дисциплина информационной безопасности. Показательная во всех аспектах: про хакеров снимают фильмы, их деятельность помогает подсветить настоящие проблемы информационной безопасности компании (real security), а в ИБ-сообществе всегда с трепетом и почетом относятся к этим ребятам!



Однако, с точки зрения заказчиков пентестов, даже у такой интересной деятельности есть нюансы: квалифицированные специалисты стоят дорого, реализовывать практики Red и Blue Team может позволить себе не каждая компания, а сами проверки носят периодический характер (хорошо, если больше одного раза в год) и не могут охватить инфраструктуру в полном масштабе. Мысли об автоматизации такой деятельности появились давно, а со временем были разработаны и продукты, которые воплощают эти идеи в реальность! Интересно? Тогда добро пожаловать под кат!

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

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

Так что же это за решения такие, и что они делают? Если систематизировать по принципам работы и достигаемым результатам, то можно выделить три ключевые группы:

  • Аналитический пентест решения, которые позволяют строить гипотезы о возможном развитии атаки при наличии знаний о том, как можно эксплуатировать уязвимость для получения доступа к наиболее ценным ресурсам компании.
  • Тестирование средств защиты решения, которые содержат большое количество всевозможных проверок для конкретного вектора атаки или элемента ИТ-инфраструктуры. Например, что будет, если я запущу вот эти N exploits на рабочей станции? Сколько из них остановит антивирус или EDR?
  • Автоматизированный пентест последний, но не по значению! Решения, которые позволяют имитировать действия реального хакера. Включая эксплуатацию уязвимостей. Страшно? Не бойтесь, ещё ни одна сеть не пострадала при проведении тестирований пока что!

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

  • Аналитический pentest Cronus CyBot;
  • Тестирование средств защиты Cymulate;
  • Автоматизированный pentest Pcysys PenTera.

Каждый вебинар будет состоять из двух частей:

  • Вводная (слайды, слайды, слайды, увы). Расскажем, что собой представляет решение, что умеет и как его можно использовать.
  • Live demo. Запустим у вас на глазах и сломаем что-нибудь!

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

И главный вопрос, который мы поставили в заголовок статьи: Заменит ли автоматизация пентестеров?. Да или Нет? Ответы, мнения и точки зрения вы получите на наших вебинарах! А заодно у вас будет возможность высказать свою точку зрения мы всегда рады и открыты для дискуссии!

22 октября 16:00. Cronus CyBot: аналитическое тестирование защищённости


Решение Cronus CyBot выявляет уязвимости, моделирует варианты развития атак и определяет в инфраструктуре, вебе и приложениях наиболее критичные недостатки, устранение которых повысит безопасность ценных активов компании. На вебинаре рассмотрим функциональные возможности Cronus CyBot и ответим на вопросы: как работает продукт, какие задачи решает, как использовать результаты работы на практике. Проведем live-демонстрацию решения и ответим на вопросы.

Зарегистрироваться на вебинар

29 октября 16:00. Cymulate: проверка эффективности системы защиты по различным векторам


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

Зарегистрироваться на вебинар

12 ноября 16:00. PenTera: непрерывный комплексный пентест инфраструктуры


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

Зарегистрироваться на вебинар

До встречи в эфире!
Подробнее..

Обзор Cisco Umbrella защита на уровне DNS и не только

24.11.2020 12:18:29 | Автор: admin

Мы постоянно тестируем новые решения для наших проектов и недавно решили разобраться, что под капотом у Cisco Umbrella. Сам вендор заявляет, что это облачное решение для защиты угроз со стороны интернета из пяти компонентов:

  • защищенный рекурсивный DNS;

  • веб-прокси с возможностью отправки подозрительных файлов на анализ в песочницу;

  • L3/L4/L7 межсетевой экран (Cloud Delivery Firewall);

  • Cloud Access Security Broker (CASB);

  • инструмент для проведения расследований.

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

Защищенный рекурсивный DNS

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

Можно ограничивать доступ к ресурсам на основе URL (фактически уже HTTP-трафик), а можно делать это на шаг раньше исходя из DNS-запроса.

Cisco Umbrella в данном случае выступает как облачный рекурсивный DNS.

Решение может детектировать и блокировать DNS-обращения по таким категориям:

  • скомпрометированные системы;

  • связь с серверами управления (C2C);

  • Malware и Phishing;

  • автосгенерированные домены;

  • новые домены;

  • построение DNS-туннелей (DNS Exfiltration).

С точки зрения архитектуры, это выглядит так:

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

Пользователей как-то нужно перенаправить в облако для анализа их DNS-запросов, и здесь есть два способа.

1) У пользователей на площадках прописан локальный DNS (обычно адрес домен-контроллера). Нам достаточно просто прописать адреса Cisco Umbrella в настройках DNS Forwarders:

2) Удаленным пользователям достаточно установить AnyConnect (модуль Roaming Client) или Umbrella Lightweight Client, в котором будут прописаны адреса DNS и подцеплен профиль организации.

Доступность указанных адресов 208.67.222.222 и 208.67.220.220 обеспечивается с помощью BGP Anycast (когда одни и те же маршруты анонсируются из разных географических точек).

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

Если провести небольшой тест измерения задержки утилитой dig при обращениях через Cisco Umbrella и публичный Google DNS (8.8.8.8), то получим следующие результаты.

Таблица 1. Результаты измерения задержки через Umbrella

Имя сайта

Замер 1

Замер 2

Замер 3

Замер 4

Замер 5

Среднее

1

mos.ru

89

39

41

94

86

69,8

2

admomsk.ru

46

96

90

39

95

73,2

3

state.gov

53

59

39

47

44

48,4

4

gov.cn

43

127

45

135

62

82,4

5

gov.uk

62

55

63

67

52

59,8

6

governo.it

59

64

66

58

39

57,2

Таблица 2. Результаты измерения задержки через Google

Имя сайта

Замер 1

Замер 2

Замер 3

Замер 4

Замер 5

Среднее

1

mos.ru

24

35

34

32

29

30,8

2

admomsk.ru

50

28

50

52

28

41,6

3

state.gov

29

51

289

56

39

92,8

4

gov.cn

375

30

30

557

359

270,2

5

gov.uk

74

68

32

75

89

67,6

6

governo.it

102

26

93

27

91

67,8

Как видно, Cisco Umbrella не вносит каких-то значительных дополнительных задержек по сравнению с публичными DNS.

Дашборд управления настройками располагается по адресу https://dashboard.umbrella.com/o/<OrgID>/#/overview, где <OrgID> это персональный номер вашей организации, выданный Cisco.

Со стороны Cisco Umbrella достаточно добавить ваш белый IP (адрес или несколько адресов, с которых площадка выходит в интернет) в список Networks, для roaming clients (удаленных пользователей) ничего дополнительно добавлять не надо.

Если у вас несколько домен-контроллеров, то скрипт автоконфигурирования (регистрации в Cisco Umbrella) и настройки DNS Forwarders необходимо будет настроить на них всех, а OpenDNS AD Connector (о нем позже) поставить только на отдельных VM.

Когда на домен-контроллере настроены DNS-forwarders, а у удаленных пользователей установлен Roaming Client, можно проверить, что вы находитесь под защитой Umbrella, перейдя по адресу https://welcome.umbrella.com.

Всё, вы под защитой!

Что же идет по умолчанию в этой защите? Посмотрим Default Policy.

Политика по умолчанию и её основные компоненты

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

Applied to All Identities значит, что политика применяется ко всем, кто посылает запросы через Umbrella (в пределах вашей организации). Если делать свою политику, то можно указать много разных типов, к чему ее применять: AD группы пользователей, Roaming Computers, IP-адреса и др.

Security Setting Applied означает блокируемые категории:

Следует отметить, что DNS-политика по умолчанию не строится по принципу implicit deny (все запрещено), блокируются только категории Malware, C2C, Phishing Attacks.

Content Setting Applied подразумевает, какие DNS-запросы блокируются на основе содержащегося контента.

Если домен категоризирован как содержащий Drugs, он будет целиком попадать в эту категорию, даже если по ссылке www.example.com/Sports будет располагаться спортивный вестник о последних достижениях местной команды. А вот если блокировка на основе контента будет применяться в Web Policy, а не DNS Policy, то здесь как раз будет разграничение в зависимости от конкретного URL.

Application Settings Applied означает блокировку в зависимости от используемого приложения.

Destination list блокировка по конкретному FQDN, IP-адресу, URL (для Web-Policy).

Если вы добавили что-то в Global Allow List в виде IP-адреса или, например, FQDN, то это этот ресурс по категории или контенту уже не будет блокироваться (если он подпадает под эту категорию/контент).

Настройка File Analysis доступна, если вы включили в Advanced Settings функцию Intelligent Proxy. По умолчанию она отключена.

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

При включенной же опции Intelligent Proxy Umbrella будет возвращать вам адрес облачной прокси, через который будет проксироваться трафик с сертификатом Cisco (нужно установить сертификат Cisco в доверенные и включить опцию SSL Decryption). Большое количество очень популярных доменов, например, Google или Facebook, не проксируются из-за низкой вероятности размещения там вредоносного контента.

Grey домены

Grey домены включают в себя домены одновременно с нормальным и вредоносным контентом, поэтому Cisco категоризирует их как risky domains.

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

При включенной настройке файлы будут отправляться на анализ в облачную песочницу Threat Grid Malware Analysis (для веб-политик) либо анализироваться статически в случае применения в DNS-политиках.

Например, при попытке скачать eicar файл у меня появилась надпись Этот сайт был заблокирован прокси Сisco Umbrella:

Block Page веб-страница, которая будет отображаться у пользователя при блокировке запроса. Настроить отображаемую страницу можно в разделе Block Page Appearance.

Можно модифицировать страницу блокировки, например, отразить, что запрос заблокирован из-за отнесения к конкретной категории или содержащегося контента, указать e-mail админа для контакта.

Создание политики на основе пользователей Active Directory

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

Cisco Umbrella тоже пошла по этому пути: интеграция с AD возможна путем установки OpenDNS коннектора на виртуальную машину для отправки LDAP-запросов к домен-контроллеру, либо на сам домен-контроллер.

Домен-контроллер регистрируется в дашборде Cisco Umbrella автоматически (путем запуска wsf-скрипта на домен-контроллере):

Я установил OpenDNS-коннектор на домен-контроллер. После этого в политиках, в разделе Identity, можно указать конкретного пользователя или группу, для которых будет применяться политика:

Попробую разрешить пользователю категорию Malware, а на уровне всей сети запрещу её.

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

Для пользователя Barney получаю результат Разрешено:

Для обращения с домен-контроллера или любого другого пользователя получаю результат Запрещено:

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

1) Через управление доменом в дашборде Umbrella.

2) Через установку отдельной VM Umbrella Virtual Appliance:

Umbrella Virtual Appliance выступает в роли DNS-forwarder, локальные DNS-запросы отправляет на локальный DNS, внешние DNS запросы в Cisco Umbrella.

VA внедряет уникальные идентификаторы для каждого пользователя, которые Umbrella в свою очередь использует для контроля и детальной видимости:

А так выглядит лог без VA (локальные IP-адреса не видны):

Защита удаленных пользователей (Roaming Users) обеспечивается либо включением модуля Umbrella Roaming в Cisco AnyConnect, либо установкой Lightweight Umbrella roaming-клиента.

Интересный факт: Сisco Umbrella можно обойти, если прописать на рабочей станции нужные записи до закрытых ресурсов в hosts.

Лучшие практики при работе с DNS-политиками

1) Политики надо делать неперекрывающимися. Например, если вы сделаете явно allow destination list, а по категории у вас он вредоносный, трафик будет разрешен.

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

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

4) Используйте в политиках группы All Networks, All Roaming Computers. Когда появится новый Roaming Computer, он просто автоматически подпадет под эту политику. Также желательно сделать разные политики для локальной сети и для Roaming Computers. Когда пользователь будет уходить из офиса, он будет подпадать под другую политику безопасности (возможно, более строгую).

Эти рекомендации применимы также и к работе с веб-политиками, которые я разберу ниже.

Работа в режиме веб-прокси

Решение может работать не только как рекурсивный DNS, но и как облачный веб-прокси.

Трафик в облачный веб-прокси от пользователей направляется точно так же, как и в земной с помощью PAC-файлов (proxy auto-config). Сам PAC-файл можно разместить в Umbrella. Проксируется только HTTP/HTTPS-трафик (TCP 80/443).

Вы можете задаться вопросом: А как аутентифицировать пользователей в облачном прокси? Ведь мы не можем здесь применить Kerberos/NTLM.

Ответ на него кроется как раз на картинке выше SAML.

В качестве IDP (Identity Provider) можно использовать как раз земной AD (ADFS) с установленным AD-коннектором, который я рассматривал в разделе защиты DNS.

В веб-политиках можно использовать все то же самое, что и в DNS-политиках, а также:

1)Антивирусная защита файлов с помощью движка Cisco AMP (Advanced Malware Protection) и отправка их в песочницу Threat Grid Malware Analysis. Ограничения здесь максимум 200 файлов в день с размером файла не более 50 Мб.

2) Контроль по типам файлов (File Type Control). Позволяет блокировать скачивание в зависимости от категории (исполняемые файлы, изображения, аудио и т.п.) и конкретного расширения (js, jpeg, exe и т. п.).

Вот так будет выглядеть попытка скачать файл из заблокированной категории Executables:

3)Tenant Control (CASB) позволяет явно разрешить использование корпоративного тенанта и запретить использование личного доступа для облачных сервисов Office 365, Google G Suit, Slack. То есть, например, пользователям надо ходить в облачный офис 365 по корпоративным нуждам, но по личным нам надо его прикрыть. Классический Application Control здесь не сработает, поэтому:

Tenant Control работает просто: Umbrella смотрит в authentication request, и если видит там корпоративный домен, явно разрешенный в политике, то пропускает трафик.

Вот так выглядит меню настройки:

Я добавил в список разрешенных доменов свой тестовый домен в Office 365 mx365x986845.onmicrosoft.com. Все остальные домены по умолчанию запрещены.

Попробую зайти в Office 365.

После корректного ввода пароля я успешно попадаю на главную страницу Office 365:

А теперь я попробую зайти в свою корпоративную учетную запись:

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

Причем сообщение от Microsoft, а не от Cisco Umbrella. Немного погуглив это сообщение на английском языке, я нашел следующее в документации Microsoft: You can't get there from here. This message means your organization has put a policy in place that's preventing your device from accessing your organization's resources. Прелести русификации я оценил :)

Из недостатков данного облачного веб-прокси можно отметить отсутствие IPS-профилей.

Cloud Delivery Firewall

Решение может также дополнительно выступать в роли L3/L4/L7 межсетевого экрана в облаке, для этого потребуется завернуть трафик с площадки через IPSec-туннель.

Важное ограничение: в политиках МСЭ можно писать только приватные IP-адреса в поле Source и публичные адреса в поле Destination и никак иначе. То есть применение здесь вполне конкретное только ограничение доступа для внутренних ресурсов наружу.

Еще один нюанс: максимально допустимая полоса на каждый туннель 250 Mбит/с. Если потребуется передавать больше трафика, нужно будет строить дополнительные туннели и балансировать между ними нагрузку (например, ECMP).

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

Пример настроенного правила:

Такой МСЭ может в принципе подойти организациям, на площадках которых нет своего МСЭ и есть только каналы в интернет (т.е. нет выделенных каналов до ЦОД, где можно централизованно выпускать пользователей в интернет).

Работа с отчетностью и расследованиями

В Umbrella представлен довольно хороший функционал для проведения расследований и анализа отчетности.

Можно смотреть как общее состояние по компании:

Так и детальное (кто-куда-когда-почему):

Имеется много разных типов отчетов (App Discovery, Threats, Top Destinations и другие). Отчеты можно выгружать в форматах csv и pdf, выгрузку отчетов можно делать автоматически, например, еженедельно, с отправкой на почту.

Пример выдержки из отчета App Discovery:

Функционал для помощи в расследованиях располагается на отдельном ресурсе https://investigate.umbrella.com/.

Работает это очень просто: вводите FQDN, ASN, IP, hash и получаете риск-скоринг и другую полезную информацию:

  • данные записей WHOIS;

  • атрибуция ASN;

  • геолокация;

  • репутация доменов и IP;

  • анализ вредоносных файлов;

  • связи между доменами;

  • обнаружение аномалий (DGA, FFN);

  • шаблоны запросов DNS.

Вот так выглядит риск-скоринг домена по версии Cisco:

WHOIS-информация и геолокация:

Семплы, собранные Cisco AMP Threat Grid и ассоциированные с данным хостом, приведены ниже и кликабельны внутри дашборда:

Можно сразу провести анализ по хешу:

В части работы с логами в SIEM вас ждет разочарование: выгрузка логов возможна с задержкой в 10 мин только в Amazon S3 bucket, а уже оттуда в SIEM.

Итоги

С момента покупки OpenDNS Cisco неплохо прокачала функционал этого решения и добавила много новых фич: веб-прокси, CASB, отправка файлов на анализ в песочницу. Решение занимает нишу защиты от угроз со стороны интернета и ограничения доступа к внешним ресурсам. Архитектура позволяет использовать решение как для удаленных, так и для on-site пользователей.

Полезные ссылки
Подробнее..

ТОП-3 ИБ-событий недели по версии Jet CSIRT

27.11.2020 16:12:57 | Автор: admin
Самыми значимыми на этой неделе стали новости об атаках на компании Belden и E-Land, а также об обнаружении в открытом доступе внушительного списка IP-адресов уязвимых FortiGate SSL VPN-шлюзов. Подробнее о каждом событии под катом.



Поставщик оборудования АСУ ТП Belden подвергся кибератаке


Компания Belden сообщила о кибератаке, в результате которой злоумышленникам удалось украсть информацию о её сотрудниках и партнерах. Пресс-релиз об инциденте опубликован на сайте businesswire.com. Подробности атаки не раскрываются, однако по описанию можно предположить, что компания стала жертвой вымогательского ПО. Belden крупнейший производитель оборудования АСУ ТП в США, а его штат насчитывает более 9 тысяч сотрудников.

Торговая компания E-Land подверглась атаке шифровальщика


Крупный южнокорейский ритейлер E-Land был вынужден приостановить обслуживание части магазинов из-за атаки вымогательского ПО. Инцидент подтвердил президент компании Чан-Хён Сок (Chang-Hyun Seok). По его словам, компания решила отключить часть ИТ-систем для сдерживания распространения ВПО. Ни одна из группировок пока не взяла ответственность за атаку.

В открытый доступ попал список из почти 50 тысяч IP уязвимых FortiGate SSL VPN-шлюзов


ИБ-исследователь @Bank_Security обнаружил на одной из площадок список из 49577 IP VPN-шлюзов FortiGate, уязвимых к CVE-2018-13379 (path traversal, позволяющий получить доступ к системным файлам). Кроме адресов, в списке содержатся учетные данные, украденные из шлюзов. Уязвимость была раскрыта более года назад, однако, судя по списку, в сети до сих пор работает много уязвимых устройств, принадлежащих в том числе крупным финансовым и правительственным организациям.
Подробнее..

Сдать OSCE вызов принят

21.12.2020 12:20:35 | Автор: admin


Что бы вы ответили на такое предложение? Есть тема, которую большинство ИБ-шников обходят стороной, называется бинарная эксплуатация. Для начала нужно решить тестовое задание: всего-то отреверсить ассемблерный код и сгенерировать ключ за 60 дней на стенде 2000-ыx годов. Дальше готовиться можно по книге, но она поможет разобраться в теме лишь процентов на 20. Потом будет истощающий силы экзамен из четырёх задач на 48 часов, и сразу после него дадут 24 часа на подготовку отчёта на английском языке. И всё это удовольствие стоит 1800$.

Я сказал: Дайте два!

Итак, дальше я расскажу, как готовился и сдавал увлекательный экзамен на международный сертификат в области тестирования на проникновение Offensive Security Certified Expert, или сокращённо OSCE, от Offensive Security.

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

  1. находить и эксплуатировать веб-уязвимости, например, XSS или Path Traversal, с развитием до полной компрометации операционной системы;
  2. проводить сетевые атаки GRE Sniffing, SNMP, обходить Access Lists, используя Spoofed SNMP Requests;
  3. находить с помощью фаззинга места переполнения (buffer overflow) и использовать их для входа в программу, обходить механизмы защиты (stack overflow, bypassing ASLR, egghunter, bad characters и т. п.), а также обходить статические механизмы защиты антивируса.

Что за зверь OSCE: разбираем на примере


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

Решение


  1. Сначала разбираем протокол на сетевом уровне: необходимо проанализировать его составляющие и выделить все места, которые имеет смысл модифицировать. Потом пишем фаззер, который будет подставлять различные значения во все эти места и пытаться выслать их серверу.
  2. Спустя время определённый строковый буфер с определёнными символом и (или) длиной вызовет stack overflow, а это нарушит работу программы и приведёт к её критическому завершению.
  3. Дальше с помощью этого буфера следует разместить payload (полезную нагрузку) в виде ассемблерных команд в бинарном виде, но не просто разместить команды в стеке, а перехватить управление регистром EIP. Для этого можно либо просто найти корректное смешение в буфере, либо попытаться вызвать исключение SEH.
  4. После перехвата управление EIP необходимо передать на последовательность своих команд. Сложность тут в том, что данные в памяти располагаются каждый раз по новому адресу. Поэтому следует найти в оперативной памяти такой участок статичного адреса, который будет ссылаться на регистр, а тот в свою очередь на адрес в памяти (с возможностью записи и выполнения), где можно будет также расположить свои данные.

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

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

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

Как я сдавал экзамен


Мне удалось сдать OSCE со второй попытки. В первый раз это было в июне у меня не получилось нормально подготовиться к экзамену из-за загруженности на проектах, но как настоящий пентестер я решил сделать всё на лету. В итоге за 48 часов, 10 из которых ушло на сон, решил только 1,5 задачки.

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

В итоге вторая попытка была в ноябре: за 12 часов экзамена я выпил 7 стаканов чая, пару таблеток от головной боли, вкусно поужинал, прогулялся во дворе и все 4 задания были решены. Благо, они были похожи на те, что мне попались при первой попытке. После приятного сна ещё часов 5 ушло на формирование отчёта, а спустя сутки мне сказали, что экзамен успешно сдан и можно просить повышение зарплаты у руководства.

Обновление правил сертификации


В октябре 2020 года Offensive Security заявила, что планирует обновить курс OSCE. Уже сейчас эту сертификацию нельзя оплатить, а статус OSCE по новым правилам можно будет получить только по результатам сдачи трёх экзаменов:

  1. Advanced Web Attacks and Exploitation (AWAE)
  2. Evasion Techniques and Breaching Defenses (PEN-300)
  3. Windows User Mode Exploit Development (WUMED) будет анонсирован в 2021

Выходит, что я зря старался и теперь имею устаревший сертификат? А вот и нет, компания придерживается позиции Anyone who has earned an OSCE will always retain it, что означает Любой, кто получил OSCE, сохранит его навсегда. Наверное, многие за это и выбирают Offensive Security. Да, дорого, да, методички слабые, да, экзамен изматывает и содержит много подводных камней, но хоть раз что-то сдав, ты несёшь этот титул до конца своих дней! В отличие от кучи других сертификаций, где каждые 2-3 года придётся и дальше платить деньги за продление и новые экзамены.

FAQ


Что в итоге мне дала сертификация?


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

Что дальше?


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

Стал бы я сдавать экзамен за свой счёт?


Наша компания уделяет большое внимание развитию hard и soft скиллов команды, поэтому мне удалось пройти сертификацию за счёт работодателя. В противном случае, пожалуй, я бы решился на такой челлендж только ради самого сертификата. Для получения только знаний (и экономии личных финансов) разумнее было бы изучить утёкшие материалы и блоги других пентестеров на medium.com, воссоздать и пройти стенд, а также обратить внимание на другие курсы, например, SLAE.

Буду ли я дальше сдавать экзамены Offensive Security?


Конечно, меня в целом устраивает подход try harder, и интересны их новые курсы, а всё остальное можно пережить.

P. S. Спасибо коллегам и моей девушке, которые поддерживали меня!
Подробнее..

DRP Обратная сторона интернет-погружения компании, или Как бороться с цифровыми рисками

01.04.2021 18:23:17 | Автор: admin
Представьте, что ваш рекрутер опубликовал в интернете вакансию администратора корпоративных внешних веб-ресурсов и выложил в ней детали о составе стека используемых компонентов вплоть до версий отдельных плагинов. Или же кто-то слил в сеть данные ваших клиентов, либо вы внезапно обнаружили, что подрядчик опубликовал в открытом доступе на Github бэкап сайта с валидными учетными данными к вашей СУБД. Всё это опасности цифровых следов, которые компании оставляют в глобальной сети, пытаясь усилить свое присутствие и влияние в интернете. Чем быстрее и масштабнее организация осваивает онлайн, тем больше она приковывает к себе внимание злоумышленников, будь то киберпреступники или недобросовестные конкуренты, и тем выше для нее цифровые риски (Digital Risk).
Мы решили поделиться своим видением того, как управлять такими рисками в контексте кибербезопасности. Поскольку тема обширная, мы не станем пытаться объять необъятное в одном посте, а сделаем цикл из нескольких частей. Сегодня расскажем о том, что представляет собой процесс Digital Risk Protection, и разберем одну из его составляющих мониторинг цифровых следов.


Что такое Digital Risk Protection


Цифровые риски нельзя назвать каким-либо принципиально новым вызовом для служб информационной безопасности. Но развитие социальных сетей и Dark Web подталкивает ИБ-специалистов всё чаще выходить за рамки периметровой защиты и обращать свой взор на внешнюю сторону баррикад. Встретить цифровые угрозы во всеоружии поможет Digital Risk Protection (DRP). Это проактивная стратегия противодействия внешним угрозам, в основе которой лежит мониторинг цифрового следа организации в различных сегментах интернета.
Отправной точкой процесса DRP считается Цифровой след (Digital footprint), то есть совокупность данных о действиях субъекта в цифровом пространстве. Это те самые примеры, с которых мы начали эту статью. Цифровые следы могут быть активными и пассивными. К первым относится информация, размещенная компанией преднамеренно, как в примере с вакансией с излишними деталями об используемом технологическом стеке. Вторые можно разбить на два типа: информация, опубликованная компанией непреднамеренно, например, если кто-то из коллег открыл порты в интернет, и опубликованная третьими лицами та же размещенная злоумышленниками клиентская база данных, или выложенный подрядчиком в открытый доступ на GitHub бэкап сайта.
При организации процесса DRP службе безопасности необходимо сделать акцент на мониторинге пассивного цифрового следа как менее управляемого со стороны организации, но в то же время нельзя недооценивать опасность активного цифрового следа.
DRP идет рука об руку с данными киберразведки, то есть Threat Intelligence (TI). В некоторых организациях процесс DRP даже частично или полностью реализуется как часть TI-стратегии. Несмотря на различия этих процессов, по нашему мнению, не столь важно, в какой парадигме реализуется DRP. Главным критерием успешности будет именно качество его выполнения. К тому же бизнесу будет гораздо понятнее, зачем инвестировать в отдельные DRP-направления, чем отдельные компоненты TI.

Процессы DRP и TI. Источник: securityboulevard.com

В поисках цифрового следа: мониторинг


DRP включает в себя три основные процедуры: мониторинг (обнаружение), аналитику и реагирование (смягчение). Обнаружение это основа всего процесса, именно на этом этапе необходимо определиться с ответами на три ключевых вопроса: что, где и как искать?

Что искать?


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

Для большей структурированности удобно разделить активы на три типа:



Где искать?


В качестве источника для поиска нужно рассматривать все три части интернета: Open/Surface Web, Deep Web и Dark Web.



Различные сегменты интернета. Источник: wikimedia.org
Спойлер Три части интернета
Open/Surface Web индексируемая часть интернета, доступная для поиска через стандартные поисковые системы.
Deep Web неиндексируемая часть интернета, доступная для поиска через стандартные поисковые системы. В ней расположено в несколько раз больше информации, чем в Open Web.
Dark Web неиндексируемая часть интернета, доступна через специализированное ПО.
Где именно в них искать цифровые следы, представляющие наибольшую угрозу? По нашему опыту, стоит охватить все области, в которых можно найти цифровые активы или элементы цифрового следа организации. В отдельных случаях источники информации могут скрываться за определенным технологическим решением.
Итак, вот как может выглядеть список общих источников информации:
Поисковые системы
Социальные медиа (социальные сети, мессенджеры)
Элементы внешней инфраструктуры
Отраслевые и криминальные форумы
Сайты объявлений о вакансиях
Dark web (I2P, ToR и т. п.)
Специализированные базы данных

Как искать?


На этом этапе нужно перейти к непосредственному сбору информации, представляющей интерес для последующего анализа. Условно существуют два метода получения информации: с применением автоматизированных инструментов и без их использования.
Ручной поиск не означает, что необходимо выделить человека, который днями и ночами будет анализировать выбранные источники данных. Ключевая особенность метода в том, что основным источником информации будут сотрудники организации. В первую очередь необходимо подключить к DRP-процессу отделы маркетинга и HR, то есть специалистов, которые напрямую взаимодействуют с внешним миром. Выстраивание прозрачного процесса взаимодействия для получения информации о потенциально мошеннических сайтах и негативных обсуждениях в социальных сетях не потребует больших затрат и при этом может принести пользу как никакое другое решение.
Без использования автоматизированных средств поиска цифрового следа практически невозможно организовать процесс DRP на должном уровне. Для этих целей можно использовать как платные, так и бесплатные инструменты. Помимо качества получаемой информации, важно обратить внимание на возможность интеграции. Как минимум необходимо настроить почтовые уведомления, оптимальным вариантом будет интеграция инструментов мониторинга с решениями, используемыми для создания единой точки входа для получения информации об инцидентах.
Применение общедоступных автоматизированных инструментов для поиска цифрового следа позволяет посмотреть на организацию со стороны злоумышленника. ИБ-специалистам важно понимать техники и приемы, применяемые атакующими на этапе разведки, то есть в процессе сбора информации. Для этого полезно изучить матрицу MITRE ATT&CK, а именно части Reconnaissance (Разведка) и Resource Development (Разработка ресурсов), которые ранее входили в отдельный домен PRE-ATT&CK. Эти инструменты помогут выстроить перманентный процесс сбора разведывательной информации, что позволит покрыть часть техник этапа разведки или как минимум быть со злоумышленником в равных условиях.
Основное преимущество платных инструментов заключается в удобстве использования, более широкой накопленной базе и возможности легкой интеграции с существующими решениями. По нашему опыту, некоторые источники информации будет сложно покрыть без использования платных средств. Яркий тому пример мониторинг Dark Web.

Выбираем инструменты для мониторинга


На полностью ручной контроль присутствия компании в интернете ИБ-специалистам попросту не хватит часов в сутках. Для ускорения и упрощения поиска цифровых следов появился целый рынок решений и услуг Digital Risk Protection (DRP). Его целевая аудитория, говорят в Gartner, вырастет в ближайшие пять лет до 10% с 1% в 2020 году. Решения класса обеспечивают видимость различных сегментов сети для выявления потенциальных угроз и предоставляют контекстную информацию об участниках этих угроз, тактиках и процессах, используемых для проведения противоправных действий. Поставщики таких решений в основном предоставляют доступ к веб-порталу, который агрегирует информацию о цифровом присутствии организации. Продукты DRP, как правило, поддерживают интеграцию с различными средствами защиты и позволяют минимизировать затраты на аналитику и реагирование.



Выбор инструментов через сервис-провайдера


Один из способов выбрать DRP-решение обратиться к MSSP. В этом случае можно реализовать под ключ множество уникальных и сложных запросов без необходимости поиска и тестирования инструментов, а также содержания команды аналитиков.
Для нас, как MSSP, отправной точкой в поиске инструментов и создании кастомных решений являлось определение основных DRP-направлений, интересных рынку. По нашему мнению, такими направлениями являются:
Защита бренда (Brand Protection) обнаружение мошеннических ресурсов (фишинговых доменов, страниц в социальных сетях, мобильных приложений и т.п.), использующих бренд организации с целью выполнения противоправных действия. Хотели бы отметить, что защита бренда в контексте процесса DRP это в первую очередь про кибербезопасность, а не мониторинг негативных комментариев и повышение узнаваемости бренда. Данные аспекты деятельности необходимо транслировать на профильные отделы, например, маркетинг, с привлечением специалистов аналитического отдела, для подтверждения факта целенаправленной информационной компании против организации, проведения расследований.
Мониторинг конфиденциальных данных (Sensitive Data Monitoring) обнаружение следов чувствительной информации в различных сегментах сети Интернет (Open/Deep/Dark web), относящихся к деятельности организации.
Мониторинг активов (Assets monitoring) обнаружение и мониторинг внешних активов организации, связанных с непосредственной инфраструктурой (хосты, порты, сертификаты).
OSINT сбор и анализ информации из открытых источников с целью обогащения инцидентов, полученных в рамках DRP-процесса, формирования первоначального цифрового ландшафта организации, проведения аналитики и комплексного расследования.

Самостоятельный выбор решений


провести самостоятельный анализ рынка, протестировать отобранные инструменты, выполнить интеграцию с существующими ИБ/ИТ системами (SIEM, ticketing/IRP системой) и т.п.
Подход в поиске инструментов для организации, выполняющей данный процесс самостоятельно, будет отличаться, так как задачи, стоящие перед ними, являются более конкретными. Оптимальным вариантом будет придерживаться следящей глобальной стратегии:
1) в случае необходимости реализации комплексной задачи, затрагивающей все направления, оптимальным решением будет использование DRP-решения как основного инструмента мониторинга внешних источников;
2) в случае необходимости покрытия отдельных направлений использовать:
специализированные системы мониторинга (Dark Web monitoring tools, Brand protection tools, External asset monitoring tools, Data leakage detection tools и т.п.)
Open source (в том числе OSINT-инструменты)
OSINT-инструменты в чистом виде рассматриваются в первую очередь как средства обогащения информации, проведения комплексных расследований, но в отдельных случаях и при отсутствии готовых решений их можно использовать как средства мониторинга или ситуационной осведомленности.

Обзор общедоступных инструментов


Перечислим популярные общедоступные инструменты (в отдельных случаях условно бесплатные) и решения, которые можно использовать для мониторинга цифрового следа организации:
Have I Been Pwned сервис, позволяющий получить информацию о факте компрометации учетных данных с возможностью реализации мониторинга доменного имени (при подтверждении прав на его владение). Наличие/появление в базе учетной записи сотрудника еще не говорит о факте компрометации. При использовании в организации сложных и часто меняющихся паролей вероятность его использования сотрудником значительно снижается. В любом случае, факт наличия учетных записей сотрудников в общедоступных базах является веской причиной пересмотреть политику осведомленности информационной безопасности.



С помощью инструментов поиска похожих доменных имен можно получать актуальную информацию о фактах киберсквоттинга, мошенничества, планирующихся целевых/фишинговых кампаниях. Примером инструмента подобного рода является dnstwist (http://personeltest.ru/aways/github.com/elceef/dnstwist, dnstwist.it).



В рамках реализации стратегии Brand Protection необходимо проводить мониторинг социальных сетей, мобильных приложений, поисковой выдачи на предмет наличия мошеннических действий. Для таких целей можно использовать специализированные инструменты для мониторинга интернет пространства. Примером такого инструмента является Social Searcher (http://personeltest.ru/aways/www.social-searcher.com/).



Подобного рода инструменты могут покрыть не только маркетинговые потребности, но и стать отличным решением выявления неправомерных действий, отражающихся на репутации/прибыли компании. В отдельных случаях количество предложений/стоимость услуги может стать одной из метрик эффективности отдела информационной безопасности (то же самое можно отнести к предложениям в darkweb).
К сожалению, не все инструменты, находящиеся в свободном доступе, могут покрыть необходимые источники информации (специфичные для российского рынка) в таком случае можно использовать бесплатные фреймворки для веб-краулинга (Scrapy, BeautifulSoup), позволяющие автоматизировано собирать необходимую информацию из веб-страниц для последующего анализа. При должном уровне автоматизации можно проводить анализ поисковой выдачи, социальных медиа, GitHub на предмет наличия следов компрометации, мошеннических действий. Уже реализованные краулеры можно найти на github.com, применив навыки гуглежа.
Как никогда актуальным является мониторинг GitHub на предмет наличия чувствительной информации. С данной задачей отлично справляется gitGraber (http://personeltest.ru/aways/github.com/hisxo/gitGraber). Данный инструмент характеризует не только гибкость в настройках, но и предусмотренную интеграцию с Discord, Slack, Telegram.



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





Конечно, это не является окончательным списком всевозможных инструментов для организации отдельных частей процесса DRP. Для поиска бесплатных инструментов мониторинга рекомендуем обратиться к многочисленным статьям на тему Инструментов OSINT, множество телеграм-каналов обсуждают различные приемы и техники получения информации об организации. Одним из вариантов поиска бесплатных инструментов является обращение к онлайн-репозиторию GitHub. Выполнив поиск в топиках по ключевым словам typosquatting, Osint и т.п., можно найти большое количество инструментов, которые применимы для покрытия обозначенных источников информации.
Обязательно рекомендуем ознакомиться с замечательным Справочником по инструментам и ресурсам OSINT, расположенным по адресу i-intelligence.eu/uploads/public-documents/OSINT_Handbook_2020.pdf, в котором вы с большой вероятностью найдете подходящий инструмент для реализации своей конкретной задачи.
О том, как подойти к процессу аналитики цифровых угроз и выстроить процесс реагирования, расскажем в следующий раз.
До скорой встречи!

Автор: Игорь Фиц, аналитик Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT компании Инфосистемы Джет
Подробнее..

ТОП-3 ИБ-событий недели по версии Jet CSIRT

28.05.2021 16:10:14 | Автор: admin


Сегодня пятница, а значит, специалисты Jet CSIRT снова собрали для вас ключевые новости в области ИБ. В ТОП-3 исправление критических уязвимостей у Apple и у VMware, а также взлом японских правительственных организаций. Подборку новостей собрал Игорь Фиц, аналитик Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT компании Инфосистемы Джет.
Подробнее читайте под катом.

VMware исправила критические уязвимости в vCenter Server


VMware обнаружила и устранила уязвимость (CVE-2021-21985) удаленного выполнения кода (RCE) в клиенте vSphere (HTML5). Уязвимость возникла из-за отсутствия проверки входных данных в подключаемом модуле VSAN Health Check, который по умолчанию включен в vCenter Server. Для эксплуатации CVE-2021-21985 злоумышленнику нужно иметь доступ к 443 порту. Помимо RCE, VMware исправила уязвимость CVE-2021-21986, которая связана с механизмом аутентификации в подключаемых модулях vCenter Server. Исходя из критичности найденных проблем, VMware призывает пользователей vCenter немедленно обновить vCenter Server версий 6.5, 6.7 и 7.0.

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


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

Apple исправила уязвимости нулевого дня


Компания Apple выпустила обновление безопасности, исправляющее три уязвимости нулевого дня, которые злоумышленники использовали в реальных атаках. Эксплуатация CVE-2021-30713 позволяет обойти стандартную защиту конфиденциальности TСС и тем самым получить полный доступ к диску, записи экрана и другим функциям системы, не запрашивая явного согласия от пользователя. Две другие уязвимости (CVE-2021-30663 и CVE-2021-30665) затрагивают браузерный движок WebKit на устройствах Apple TV 4K и Apple TV HD и могут привести к удаленному выполнению кода на атакованных девайсах.
Подробнее..

Охотимся на БОССОВ

08.06.2021 16:18:29 | Автор: admin

Какая ваша любимая компьютерная игра? Lineage, Doom, Cuphead, WOW, другая? Я обожаю играть в старые игры для приставок Dendy или Sega, например, в Марио, где, проходя уровень за уровнем, добираешься до финального босса. Игровой сюжет большинства консольных игр построен в целом одинаково: преодолей все преграды, страдай и не выключай приставку неделями, чтобы заставить босса отдать тебе принцессу.

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

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

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

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

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

Обычные пользователи

Топ-менеджмент ожидания

Топ-менеджмент реальность

Повышение осведомлённости: систематические обучения, дополнительные меры повышения компетенций (интерактивные обучающие курсы, систематические рассылки и пр.)

Отдельные семинары с разбором бизнесовых кейсов

Киберучения

Ничего, так как не трогаем лишний раз руководство

Hardening рабочих станций: минимизация прав учетной записи, применение строгих политик GPO, принудительная установка обновлений, защита BIOS и пр.

Выделение в отдельный VLAN, реализация шифрования хранимых данных на устройстве, тонкая настройка GPO

MacOS без политик или собственное неуправляемое Windows-устройство

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

Аутентификация на основе второго фактора, мониторинг нетипичной активности

Использование принципа Пользователям hard, руководству попроще

Защита почтового трафика: SandBox, anti-spam, редирект внешних ссылок и пр.

Контроль переопределения транспортных правил в отношении VIP-почтовых ящиков, реализация s-mime или другой технологии защиты электронной переписки

Любимый некорпоративный почтовый клиент

Endpoint protection: антивирусная защита, MDM и пр.

EDR

Установка своего антивируса и удаление всего лишнего, чтобы безопасники не следили

Безопасное удаленное управление: включение опции запроса на подключение для утилит удаленного доступа, реализация LAPS и пр.

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

Тот же самый пароль на vnc, что и у остальных работников компании

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

Внешние атаки (модель внешний злоумышленник)

Компрометация внешних корпоративных ресурсов

Размытость корпоративного периметра и множественные точки входа (OWA-интерфейс электронной почты, MS Office 365, корпоративный портал, confluence и т.д.) сейчас характерны для большинства компаний. Получить доступ к данным на внешних ресурсах глобально можно тремя способами:

- стучаться эксплойтами во все уязвимые сервисы;

- попытаться сбрутить нужную нам учетную запись;

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

Если у хакера достаточно мотивации, времени и ресурсов, он сможет добиться своего любым из этих способов, но трудоемкость технических атак гораздо выше. Самый простой путь сэкономить время и нервы скомпрометировать почту руководителя, после чего заняться чисто механической работой: заходить на все доступные извне ресурсы (ERP, CRM, BI и др.), чтобы попылесосить там интересные данные. Поэтому используем самый быстрый и надёжный вектор VIP-fishing (aka Spear-phishing).

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

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

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

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

На мой взгляд, оптимальное решение проводить киберучения для ТОП-менеджмента. Нет, это не blue team & read team между финансовым директором и директором по стратегическому развитию. Это штабные учения или игры, основой сценария которых является моделирование возможных страхов руководства: публикация провокационной информации в СМИ, утечка данных клиентов и пр. Это поможет не только повысить осведомленность, но и вовлечь руководителей в нюансы обеспечения ИБ.

Атака на личные аккаунты

Взаимодействие хакера с объектом атаки может проходить не только через средства корпоративной коммуникации, но и по другим каналам: через СМС, мессенджеры, звонки, личные аккаунты в социальных сетях. Этот способ потребует более глубокой проработки профиля жертвы с помощью техники разведки OSINT. OSINT позволяет на основе открытых источников собрать максимальный объем информации об объекте атаки. OSINT-инструментов достаточно много, не будем подробно останавливаться на технике работы с ними. Разведка всегда приводит к очень интересным находкам: зачастую от проведения reverse photo location фотографии руководителя до обнаружения паролей от слитых аккаунтов и номеров мобильных телефонов пара шагов.

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

Очевидно, что никакие корпоративные средства защиты здесь не помогут. Хорошо, если эти базовые шаги пройдет третья сторона (пентестеры) до того, как это сделали злоумышленники:

- проведут OSINT в отношении ТОП-менеджеров (проанализируют информацию в соцсетях, базах данных утечек информации);

- проверят актуальность полученной информации;

- донесут риски до руководства.

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

Эксплуатация недостатков в групповых почтовых рассылках

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

К сожалению, культура корпоративных рассылок во многих компаниях оставляет желать лучшего: такую рассылку может создать любой пользователь, их количество переваливает за сотни, и никто уже не помнит, кто из работников или клиентов был в них включен. Особенно удобно, когда писать на групповые адреса может любой пользователь: не нужно заморачиваться веерной рассылкой, которую может заблокировать спам-фильтр: отправляем одно письмо на event@example.com, и получаем профит в сотни доставленных писем внутри компании.

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

Атаки внутри периметра (модель внутренний злоумышленник)

Получение доступа к АРМ руководителей через средства удаленного доступа

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

В комментариях мне возразят: служба ИБ и поддержки пользователей не имеет доступа к устройствам руководителей, у них свой Mac, мы к ним ногами ходим и др. Но практика удаленного подключения остаётся популярной и зачастую ничем не отличается от управления всеми остальными АРМ: рабочие станции ТОП-менеджеров находятся в общей для всех пользовательской сети с общим для всех паролем на подключение (или тем же беспаролем). Мы часто встречаем в своей практике: нестойкий пароль на подключение, хранение файлов конфигурации VNC с паролем в SYSVOL или других общедоступных папках, уязвимые версии с доступными эксплойтами, инструкции по удаленному подключению в общедоступных папках со всеми паролями.

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

Что с этим делать? Хорошая практика организация отдельного контура безопасности для рабочих мест руководства: выделение отдельного сетевого сегмента для размещения АРМ, ограничение числа лиц, имеющих права на подключение. Не забудьте запретить для машин ТОП-менеджмента возможность управления с использованием средств удаленного администрирования Windows (RDP).

Подбор учётной записи в домене

Я думаю, знакомая многим картинка:

Функционал AD позволяет исключить отдельные группы пользователей и/или компьютер от применения настроек групповой политики (Group Policy). На практике специалисты ИБ обычно используют этот функционал для отключения требований к сложности пароля для учетных записей руководства. Комментарии тут не нужны самые любимые и в большинстве своем несложные пароли подбираются быстро.

Лучшее, но не всегда доступное решение, чтобы не мучать руководителей вводом сложных паролей использовать аутентификацию на основе SMS или токенов. Если это пока невозможно реализовать, усложняем существующую парольную политику с использованием базовых фишек AD Fine-Grained Password Policies пользовательских списков запрещенных слов. Кроме превентивных мер подключаем детектирующие контроли: периодическую проверку хешей паролей пользователей в домене Windows на слабые пароли и, конечно, мониторинг.

Разведка в папках общего доступа

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

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

Однако это лишь верхушка айсберга. Именно до сетевых ресурсов у ИБ-специалистов зачастую руки доходят в последний момент. Поэтому права All Domain Users read/write довольно частая практика даже для таких папок, как Казначейство, Finance, Buh.

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

Атаки на хэш учётной записи

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

Где удобнее и быстрее всего найти заветный хэш? Например, на RD Session host служб удалённого рабочего стола (MS RDS), на серверах BI-платформ.

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

- отключение LM и NTLM,

- запрет кэширования учетных данных,

- включение в группу Protected Users,

- запрет использования сохранённых паролей,

- отключение возможности получение debug,

описаны в огромном количестве статей в сети Интернет.


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

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

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

Подробнее..

Успеть за 24 часа история переезда оборудования между ЦОДами

29.03.2021 10:21:19 | Автор: admin

Переезд сродни пожару. Накал страстей нужно умножить на 10, когда речь идет о перевозке целого ЦОДа крупного банка. Сомневаетесь, что за 24 часа можно перевести 25 стоек, которые содержали 150 единиц оборудования, включая СХД, высокопроизводительные серверы HP Superdome и целый набор разных систем от Sun, Huawei, Lenovo, Quantum и IBM? Берите попкорн, кота на колени, вязание (нужное подчеркнуть), а мы расскажем, как это было и поделимся лайфхаками, как пережить подобные проекты.

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

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

Хорошая подготовка половина успеха

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

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

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

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

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

Три. Начинаем разбирать

Закон Мёрфи гласит: Если что-то может пойти не так, оно пойдет не так. Практика такова, что чем масштабнее проект и экстремальнее сроки, тем больше вероятность возникновения сюрпризов. Когда мы прибыли на площадку, далеко не все оборудование было готово к вывозу. Отключение и вывод систем из продуктива занял больше времени, и нам пришлось ждать старта.

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

Два. Переезжаем

Отставание от графика уже перевалило 5 часов, когда оборудование было готово. Начали работать. Нужно было погрузить 25 стоек со 150 единицами оборудования. Чтобы уложить переезд в сутки, мы выставили приоритеты, разделив системы на 3 категории. Сначала перевозились наиболее критичные системы, потом средней важности и наименее приоритетные.

В числе переезжавших устройств оказались не только серверы переселялось также хранилище high-end класса Huawei Ocean Store и уникальная для России система защиты Hitachi Protection Platform. Это оборудование курировали профильные специалисты с соответствующей сертификацией. Тонкость заключалась в том, что нам нужно было подобрать по 3 инженера на каждый вид специализированного оборудования, чтобы в каждую смену кто-то знающий отвечал за соответствующие устройства.

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

Один. Собираем и запускаем

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

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

К подключению сложных устройств мы тщательно подготовились заранее и вовлекли в проект вендоров. Например, для отключения и подключения HP Superdome приехал инженер HPE. Hitachi Protection Platform мы запускали на новом месте при поддержке российского представительства. То же самое касалось и Huawei Oceanstor нам потребовалось практически непрерывно поддерживать связь с техподдержкой производителя, пока шла настройка и конфигурирование на целевой площадке.

Можно ли успеть за 24 часа?

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

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

Драгоценная мораль

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

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

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

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

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

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

  6. Нужен почасовой план с пошаговым описанием действий всех участников. Да, сражение никогда не идет по плану, но, если у вас нет плана вы точно проиграете. Поэтому очень помогает предварительно прогнать всю схему с участниками процесса в настольном режиме и заложить дополнительные резервы на случай сбоев. А еще, готовя такой план, не стоит попадать в ловушку сознания: если я пробегаю 100 метров за 10 секунд, то с марафоном за управлюсь меньше, чем за 1,5 часа. Это не так. Усталость сильно влияет на скорость работ, и это тоже нужно брать в расчет.

А вы участвовали в подобных ИТ-переездах? Какие выводы оказались самыми ценными для вас?

Автор: Нина Пушкарь, менеджер проектов Инфосистемы Джет



Подробнее..

Компьютерное зрение. Свой алгоритм или решение из коробки?

13.10.2020 12:18:27 | Автор: admin


Меня зовут Александра Царева. Я и мои коллеги работаем над проектами в сфере компьютерного зрения в Центре машинного обучения компании Инфосистемы Джет. Мне хочется поделиться нашим опытом разработки и внедрения проектов в сфере компьютерного зрения. Сегодня речь пойдет о преимуществах и недостатках кастомных и коробочных решений, и я расскажу о нашем опыте применения инструмента от IBM Maximo Visual Inspection.

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

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

Так ли совершенны кастомные решения и тривиальны готовые? Давайте попробуем разобраться.

Кастомные решения


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

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

Теперь перейдем к недостаткам кастомного решения. Как ни грустно это признавать, они тоже есть.

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

  1. Первые проблемы касаются данных. Дата-сайнтист, участвующий в проекте, сначала выступает в качестве data-психоаналитика и подробно расспрашивает о данных. Люди понимают, что у имеющихся в их распоряжении данных есть специфика и ограничения. Две стороны одной проблемы: слишком много неструктурированных данных, или слишком мало данных в принципе. На то, чтобы получить полезную информацию из таких данных, как, например, большого числа фотографий без разметки, потребуется много сил и времени. Если речь идет о специфических данных (например, требуется оценивать качество изделий из редких металлов или драгоценных камней), потребуется труд довольно дорогих экспертов. Их невозможно заменить crowd-sourcingом, к тому же нередко их опыт не поддается формализации. С другой стороны, данных может быть очень мало: их сбор может происходить медленно. Например, разрабатываемая модель должна определять, верно ли установлены детали в двигатель на видеоконтроле конвейера, а работники все достаточно квалифицированы, и ошибки у них происходят единично.
  2. Второй нюанс касается непосредственно дата-сайнтистов, которые будут работать над проектом компьютерного зрения для конкретной задачи. Во-первых, профессиональный рынок перегрет от спроса: специалистов меньше, чем компании готовы нанять. В целом, обычные для всех ИТ-профессий проблемы, помноженные на то, что постоянно появляются новые задачи, решаемые наукой о данных. Во-вторых, даже если в бизнесе уже есть дата-сайнтисты может быть, это не те дата-сайнтисты, которых вы ищете. Наметился тренд на все более сильную специализацию в рамках профессии. В-третьих, то, что сделают дата-сайнисты, нужно будет внедрять и поддерживать (и, может быть, даже развивать, если вам понравится эффект!). А если имеется относительно обширный парк устройств, на которых это надо использовать, то еще и адаптировать. Бизнес, не имеющий тяги к стартапам, на этом этапе часто решает, что ему не так уж и нужно компьютерное зрение.

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

Нейросети из коробки


У бизнеса самого по себе есть тайная сила, не (всегда) доступная специалистам в математике.

Во-первых, никто не знает задачу так хорошо, как заказчик.

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

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

С этой точки зрения IBM Maximo Visual Inspection решает множество проблем, поскольку сильно занижает порог вхождения. Можно сказать, это вариация AutoML, автоматизированного машинного обучения, теперь для работы с изображениями и видео. Самое главное, решение Maximo Visual Inspection изначально разработано для использования людьми без обширных познаний в области глубокого обучения нейросетей. Для тех, кому хочется узнать больше о приемах работы и терминах, которые используют дата-сайнтисты, когда говорят о компьютерном зрении, решение снабжено подробной документацией (документация пока только на английском, но вряд ли это станет препятствием для пытливого ума).

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

Есть три продукта в этой линейке: IBM Maximo Visual Inspection для обучения нейросетевых моделей, IBM Maximo Visual Inspection Edge для применения обученных моделей на различных устройствах с GPU или CPU, и IBM Visual Inspection Mobile (Visual Inspector) для применения обученных моделей с использованием мобильных устройств для различных инспекций. Дополнительно следует отметить, что IBM Maximo Visual Inspection сейчас включает интеграцию с продуктом IBM Maximo Asset Monitor. Таким образом Maximo Visual Inspection может автоматически отправлять результаты распознаваний в Maximo Asset Monitor для дальнейшей обработки.

Кроме того, обученные в Maximo Visual Inspection модели можно использовать в продукте IBM Video Analytics, который позволяет подключать сотни и тысячи камер любых производителей, осуществлять трекинг объектов, имеет специальный интерфейс администратора, который позволяет настраивать правила поведения или состояния объектов, которые необходимо отслеживать, генерировать мгновенные оповещения в интерфейс оператора или как сигналы другим системам, а также индексировать видеопотоки описывая все происходящее в виде. метаданных, по которым в последствии оператор может выполнять поиск интересующих объектов или событий.

Пайплайн работы решения достаточно стандартный: загружаем в необходимые видео или изображения, которые становятся новым датасетом, размечаем его с помощью удобного функционала (в том числе доступны функции аугментации данных и авторазметки), выбираем требуемый тип сети для обучения в зависимости от задачи (нужна ли нам модель поточнее или побыстрее, распознавание прямоугольниками или по контуру и т.д., сделать правильный выбор легко), после этого, в один клик, запускаем процесс обучения и наблюдаем в реальном времени за графиком с основными параметрами качества обучения. В зависимости от выбранного типа сети обучение занимает ориентировочно от 2 до 30 минут. По завершении процесса обучения создается экземпляр модели, который может быть уже связан с существующей инфраструктурой, например, использован для распознавания на каком-либо Edge устройстве с помощью второй версии продукта Maximo Visual Inspection Edge.

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

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

Царева Александра, ведущий специалист по машинному обучению Инфосистемы Джет
Подробнее..

Перевод K8s в проде и в разработке четыре мифа

11.09.2020 12:04:11 | Автор: admin

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

Не будет.

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

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

С оркестрацией контейнеров обычно та же ситуация. Например, компания The New Stack три года назад провела исследование и выяснила, что внедрение контейнеров подтолкнуло к внедрению Kubernetes, потому что компании искали мощную технологию, способную помочь им в решении сложных эксплуатационных задач. Хотя у Kubernetes есть альтернативы, однако он быстро стал синонимом оркестрации и стандартом де-факто. И может быть большая разница между запуском K8s в песочнице и в боевых условиях.

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

Миф первый: запуск Kubernetes в среде разработки или тестирования гарантирует, что ваши эксплуатационные потребности будут удовлетворены

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

Разницу между запуском в проде и запуском в одной из сред можно сравнить с разницей между гибкостью (agility) и гибкостью в сочетании с надёжностью и производительностью. И в последнем случае придётся поработать.

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

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

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

Миф второй: вы обеспечили надёжность и безопасность

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

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

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

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

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

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

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

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

Рекомендуется относиться к безопасности контейнеров как к десятиуровневой системе, охватывающей стек контейнеров (хост и реестры), а также вопросы, связанные с жизненным циклом контейнеров (например, управление API). Подробно об этих десяти уровнях и их связи с инструментами оркестрации вроде Kubernetes рассказывается в подкасте со специалистом по безопасности из Red Hat, а также в статье Ten Layers of Container Security.

Миф третий: оркестрация превращает масштабирование в пустяк

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

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

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

Продуктивные кластеры масштабировать сложнее, чем кластеры для разработки или наладки. Хотя в Kubernetes довольно просто масштабировать приложения горизонтально, но DevOps нужно помнить о некоторых нюансах, особенно когда речь идёт о поддержании работы сервисов при масштабировании инфраструктуры. Важно убедиться, что основные сервисы, а также системы оповещения об уязвимостях и нарушении безопасности, были распределены по узлам кластера и работали со stateful-томами, чтобы данные не терялись при масштабировании вниз.

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

Миф четвёртый: Kubernetes везде работает одинаково

В реальности: различия в работе в разных средах могут быть подобно тому, как различается запуск Kubernetes на ноутбуке разработчика и на боевом сервере. Многие считают, что если K8s работает локально, то он будет работать и в любой эксплуатационной среде. Хотя он обеспечивает согласованные среды, однако в зависимости от вендора могут быть серьёзные отличия.

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

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

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

Подробнее..

Чем запомнились Volga CTF 2020

07.10.2020 16:09:34 | Автор: admin
Всем привет! Меня зовут Маша, вместе с командой Jet CSIRT я помогаю крупным компаниям выстраивать защиту от злоумышленников. Помимо работы, учусь в Самарском национальном исследовательском университете им. Королева и помогаю в организации некоторых ИТ-мероприятий в своем городе. Недавно мне выдалась возможность побывать на Volga CTF одном из крупнейших соревнований в области информационной безопасности, которые ежегодно проводятся в Самаре. В этом году мероприятие проходило с 14 по 18 сентября и отмечало свой 10-летний юбилей. На протяжении нескольких дней участники соревнования сражались за первенство, а представители бизнеса, образовательных учреждений, МИД РФ и ИБ-эксперты проводили для всех желающих семинары по актуальным вопросам и проблемам в сфере кибербезопасности. Под катом вас ждут подробности с мероприятия.



В этом году в финал Volga CTF вышли 23 команды, 10 из которых из-за сложившейся эпидемиологической обстановки участвовали онлайн. Было много иностранных команд, в том числе из Австрии, Португалии, Канады, Тайваня, Туниса, Италии и Германии. Некоторые команды уже не в первый раз участвуют в этих соревнованиях и бывали в России на очном туре.



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





Илья Цатуров рассказал, как устроен язык запросов GraphQL, в чем он лучше Rest API, и как его неправильное использование в веб-приложении может создать множество ошибок и уязвимостей. Спикер перечислил варианты специфичных атак, например, Information Disclosure, Broken Access Control, DoS и Batching Attack, и способы их избежать. И если названия первых трех вариантов говорят сами за себя, то о Batching Attack лично я слышала впервые. Как оказалось, это тип атак, связанных с фичей Batching Queries, благодаря которой система может объединить в массив несколько запросов, пришедших за небольшой промежуток времени от одного пользователя, что при определенных обстоятельствах позволяет устроить своего рода брутфорс.



Николай Анисеня и Максим Костиков поделились опытом анализа защищенности банковских приложений, рассказали, как банки защищают деньги и личные данные пользователей и как злоумышленники могут эту защиту обходить. Из доклада спикеров участники мероприятия также узнали о багах аутентификации. Например, при двухфакторной аутентификации можно перебрать SMS-коды даже при ограничении количества попыток входа с одного IP-адреса, просто подменив его на стороне сервера. Были названы и некоторые логические уязвимости, в том числе неустойчивость к DoS-атакам и race condition (возможность при помощи множества запросов произвести несколько одинаковых транзакций). Спикеры также упомянули атаки на клиентскую часть мобильных приложений (к примеру, обход блокировки PIN-кодом при помощи брутфорса или отключения части интерфейса, что особенно актуально для Android-устройств) и рассказали, почему сливы банковских данных так важны.





Далее Никита Ступин в своем докладе подробно разобрал, как можно тестировать IoT-устройства, имея минимальные знания о бинарных приложениях и железе, и применять свои навыки, участвуя в программе Bug Bounty. Также он затронул тему радиохакинга, рассказав, что можно делать с интерфейсами, которые работают через Wi-Fi или Bluetooth. Например, у каждого устройства, предназначенного для продажи в Америке, есть FCC ID, с помощью которого можно узнать, на каких частотах оно работает. Спикер сосредоточился на использовании Bluetooth, так как на рассматриваемом им девайсе в качестве демона, запускавшего Wi-Fi, был опенсорсный hostapd, поиск уязвимостей в котором осложнялся существованием репозитория OSS-Fuzz.

Я уже все посмотрел вебку, беспроводные сети Остались только бинарные приложения. И я хотел пофаззить, рассказал Никита Ступин.

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

Все это привело меня к тому, что вместо техники DBI (Dynamic Binary Instrumentation) я посмотрел в сторону Radamsa и начал фаззить, как это делали в 90-е или даже раньше, то есть это был Black Box Fuzzing.


Фрагмент презентации

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



Далее слушатели вместе с Денисом Макрушиным в режиме онлайн размышляли о том, что будет, если сервисы и автоматизированные контроли безопасности окажутся уязвимыми и будут использованы для атаки. Спикер рассказал об использовании GitHub для нахождения обходных путей подключения к коммерческим ИБ-решениям (например, Checkmarx), но не забыл и об опенсорсных проектах. Денис показал, каким образом open source может менять поверхность атаки, и привел примеры уязвимостей, найденных при анализе такого софта. В качестве одного из объектов для исследования он выбрал Flower опенсорсный дашборд для менеджмента очередей в Python-скриптах. Последние могут хранить в оперативной памяти ценные данные и буферизовать их. При анализе этого инструмента докладчик нашел единственное поле, куда можно было ввести какие-либо данные, и даже оно содержало уязвимость.

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




Фрагмент презентации

Следующим в программе первого дня был Anatol Prisacaru aka shark0der. В формате онлайн спикер рассказал об уязвимостях в смарт-контрактах Ethereum, об арбитражных ботах, атаках с опережением и затронул тему флэш-кредитов.



После перерыва Иннокентий Сенновский рассказал, чем современные реализации фаззеров отличаются от ванильного AFL. Слушатели познакомились с терминами AFLFast, MOpt, Entropic и узнали, как они влияют на фаззинг, и чем воспользоваться, если придумали, как улучшить фаззинг, но переписывать AFL не очень хочется.



Завершающим выступлением был доклад Антона Кутепова и Ильяса Очкова. Спикеры рассказали (и немного показали), как с помощью open source проектов можно эффективно выявлять атаки, опираясь на данные из различных файлов логов. Используемый стек ELK, Sigma rules, Atomic Threat Coverage, Sysmon, auditd. Лично мне как оператору первой линии реагирования на инциденты это доклад был ближе всего по профессиональной тематике.





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



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

  • использование JWT (JSON Web Tokens) для сессий авторизации вместо старых добрых cookies;
  • отказ от использования адресов, целенаправленно выделенных под авторизацию;
  • использование библиотеки imagemagick без песочницы;
  • отсутствие изоляции доменов для контента пользователей;
  • старт сессий с one-time token (к примеру, приходящего на e-mail);
  • излишнее использование криптографии (например, написание своих алгоритмов);
  • использование соединений server-2-server при наличии реальных пользователей;
  • использование паролей (по словам докладчика, будущее за сервисами, которые используют одноразовые коды аутентификации, например, QR-код в WhatsApp или одноразовые ссылки, как в Medium).



Рамазан aka r0hack DeteAct рассказал о том, как выбирать программу для Bug Hunting, с чего начать ее изучение, а также описал эффективные способы нахождения багов и пару интересных кейсов.



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



После небольшого перерыва онлайн-лекцию провел профессор из Бельгии Tom Van Goethem. Он рассказал про новый тип временных атак, которые используют объединение пакетов по сетевым протоколам и одновременную обработку запросов приложениями.



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



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



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











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







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

Автор: Мария Волгина, специалист группы обработки инцидентов ИБ Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT компании Инфосистемы Джет
Подробнее..

Резервирование СУБД Oracle силами Veritas NetBackup Appliance быть или не быть?

01.12.2020 10:20:26 | Автор: admin
Наладить резервное копирование СУБД Oracle инструментами того же вендора просто. А если попытаться оптимизировать стоимость решения? Тогда возможные ИТ-инструменты стоит придирчиво рассмотреть в действии. Так и получилось: в поиске ответа на запрос заказчика обнаружилось, когда стоит женить Oracle и NBU, а когда лучше это не делать. Делимся опытом тестирования системы резервного копирования Veritas NBU для защиты данных в СУБД Oracle и интересными нюансами процесса настройки.


Один из наших клиентов ритейлер федерального масштаба озаботился резервированием данных в СУБД Oracle. По умолчанию для этого подходит Oracle Zero Data Loss Recovery Appliance (ZDLRA). Но стоит комплекс как круизный ледокол. К тому же ZDLRA не дал бы клиенту контролировать все процессы резервного копирования через единую консоль. Эти соображения заставили искать альтернативы. Одной из них стало устройство Veritas NetBackup Appliance 5240 СРК среднего уровня с хорошей производительностью в стандартных условиях. Оптимизма добавляла и технология Copilot в арсенале Veritas, предназначенная специально для работы с СУБД Oracle.

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

Плюсы Veritas NBU


Сначала мы оценили, какие уникальные технологии могут ускорить процессы резервного копирования и восстановления. Поскольку речь шла о резервном копировании СУБД Oracle, а в качестве сетевого подключения использовался 10 GbE (никаких Fiber Channel), наиболее полезными оказались следующие инструменты Veritas:

  • Media Server Deduplication Pool (MSDP) дедупликация данных на лету, которая оптимизирует репликацию резервных копий между устройствами и создает синтетические полные резервные копии за время инкрементальных;
  • NetBackup Optimized Duplication устраняет избыточность передаваемых данных за счет передачи только уникальных блоков, которые отсутствуют на принимающем устройстве;
  • NetBackup Copilot сокращает время создания резервных копий СУБД Oracle, используя мгновенные снимки файловой системы устройства NetBackup и интеграцию с менеджером резервного копирования Oracle RMAN.

Больше других надежду в контексте СУБД Oracle дарила технология NetBackup Copilot. В тестировании мы сфокусировались на проверке ее производительности в сравнении с обычными инкрементальными копиями БД.

К тестированию готовы? Да, но нет


Мы развернули тестовый стенд, который включал в себя NetBackup Master Server, NetBackup Media Server и Oracle Linux Server 6.7. NetBackup Appliance (выступал в роли NetBackup Media Server) был подключен к базе данных через два порта 10 GbE, а NetBackup Master Server развернули на виртуальной машине в среде виртуализации VMware vSphere 6.0.

В качестве источника РК использовали физический сервер с установленной ОС Oracle Linux Enterprise 6.7 и СУБД Oracle 19. Чтобы смоделировать работу системы в условиях, близких к требованиям заказчика, объем тестовой базы Oracle мы установили в размере 1 Tб в формате Bigfile. База данных находилась под нагрузкой, а объем изменений в течение 12 часов составлял 50-60% от изначального объема базы.

Итак, поехали! Мы запустили резервное копирование, но уровень производительности оказался удивительно низким 2,32,8 TB/h. По результатам привет из 90-х! В документах по работе Veritas NBU с СУБД Oracle готовых решений для сложившейся ситуации не было. Но сам факт наличия Copilot и хорошая производительность решения на стандартных задачах, как, например, резервное копирование файловых систем, наводили на мысль, что мы упускаем из виду какие-то моменты. Тогда вместе с коллегами из Veritas мы начали поиск тонких настроек NetBackup, которые повысили бы производительность.

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

  • значения Jumbo Frame (размеры фреймов Ethernet, в которых можно передавать данные);
  • политика передачи хэша (xmit_hash_policy), напрямую влияющая на скорость и эффективность резервного копирования;
  • размеры буферов (Number Disk, Size Disk) Veritas Appliance требовалось менять для резервного копирования часто меняющейся БД

Использовать ли Copilot?


Мы возлагали большие надежды на NetBackup Copilot все-таки эта технология изначально создавалась для работы с СУБД и использует Oracle incremental merge, чтобы перейти на схему резервного копирования forever incremental. При работе в режиме Copilot система взаимодействует с менеджером резервного копирования СУБД Oracle RMAN для запуска команд резервного копирования СУБД.

Если разложить процесс резервного копирования с использованием NetBackup Copilot по стадиям, он выглядит так:

  1. на устройстве NetBackup Appliance настраивается устройство хранения резервных копий, доступное серверу СУБД Oracle по протоколу NFS;
  2. после этого настраивается политика резервного копирования в консоли администрирования СРК NetBackup;
  3. сам процесс резервного копирования начинается с создания базовой копии (level-0), после чего выполняются только инкрементальные резервные копии (level-1);
  4. изменения, возникающие с момента создания базовой резервной копии level-0, применяются к образу, который актуализируется на момент создания последней резервной копии level-1;
  5. NetBackup создает мгновенные снимки образа резервной копии на NFS-хранилище устройства (используя функции интегрированного в устройство ПО InfoScale);
  6. каждая резервная копия и мгновенный снимок добавляются в каталог менеджера резервных копий Oracle RMAN и в служебную базу данных NetBackup.

Плюсов у такого решения много. Например, мгновенные снимки файловой системы NFS-хранилища устройства NetBackup Appliance могут автоматически дублироваться (перемещаться) на наиболее эффективный уровень хранения: диск, пул дедупликации, лента, облачное хранилище, или реплицироваться на устройство NetBackup на резервной площадке. Это делается за счет политик управления жизненным циклом (SLP).

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

А если на скорость?


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

В таблице даны сводные результаты создания полной резервной копии с включенной и выключенной дедупликацией на клиенте, включенной и выключенной срезкой Redo logs, в условиях, когда СУБД находится под нагрузкой и без нагрузки.

Type Job Schedule DB Load Client deduplication Redo logs Elapsed Time Speed TB/h
Backup Full Yes Enable Disable 0:14:06 4,4
Backup Full Yes Disable Disable 0:18:22 4,2
Backup Full Yes Enable Enable 0:22:36 4,1
Backup Full Yes Disable Enable 0:30:07 3,6
Backup Full No Enable Disable 0:12:16 4,7
Backup Full No Disable Disable 0:16:45 4,2
Backup Full No Enable Enable 0:16:15 4,3
Backup Full No Disable Enable 0:17:40 3,9

Система резервного копирования NBU показала хорошую скорость записи резервных копий. Очевидным узким местом в нашем тесте оказалась дисковая подсистема Veritas Appliance в модели 5240 (количество дисков в RAID-группе и скорость работы интерфейса). В тестировании использовалась минимальная конфигурация с одной дисковой полкой.

Делаем инкрементальные копии


Чтобы оценить производительность в режиме создания инкрементальных резервных копий, мы проводили копирование 2 раза в сутки в 10:00 и 22:00. СУБД находилась под нагрузкой, а дедупликация на клиенте была включена.

Type Job Schedule DB Load Client deduplication Elapsed Time Speed TB/h
Backup Incremental 10:00 Yes Enable 0:10:58 2,2
Backup Incremental 22:00 Yes Enable 0:09:58 2,2
Backup Incremental 10:00 Yes Enable 0:10:03 2,3
Backup Incremental 22:00 Yes Enable 0:09:04 2,2
Backup Incremental 10:00 Yes Enable 0:11:13 2,3
Backup Incremental 22:00 Yes Enable 0:12:01 2,2
Backup Incremental 10:00 Yes Enable 0:12:21 2,3
Backup Incremental 22:00 Yes Enable 0:10:53 2,5
Backup Incremental 10:00 Yes Enable 0:12:03 2,3
Backup Incremental 22:00 Yes Enable 0:12:04 2,2
Backup Incremental 10:00 Yes Enable 0:12:13 2,3
Backup Incremental 22:00 Yes Enable 0:12:01 2,2
Backup Incremental 10:00 Yes Enable 0:12:21 2,3
Backup Incremental 22:00 Yes Enable 0:10:53 2,5

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

Включаем режим Copilot


В режиме Copilot ситуация выглядит иначе. В нашем тесте создание резервной копии происходило каждые 12 часов, а время резервного копирования фиксировалось от момента создания снапшота Oracle до окончания момента записи резервной копии в storage pool на устройстве NBU.

Type DB Load Elapsed Time Megabytes Speed TB/h
Backup Yes 0:36:53 1 294 153 2,6
Backup Yes 0:32:14 1 126 525 2,5
Backup Yes 0:33:34 1 152 365 2,7
Backup Yes 0:31:23 1 123 620 2,6
Backup Yes 0:44:04 1 681 999 2,9

Результаты этого теста оказались средними. Однако стоит учитывать, что синтезирование резервной копии с последующей записью в storage pool происходило в NFS Share. Возможно, частично за низкую производительность отвечают дополнительные ограничения скорости чтения и записи NFS Share. К тому же для более старших моделей NetBackup Appliance существует технология Optimized Share, так что скорость работы в подобном режиме должна быть выше. Мы использовали Veritas Appliance в минимальной конфигурации с одной полкой, тогда как вендор рекомендует применять минимум две полки для режима Copilot.

Таким образом, главным преимуществом использования Copilot остается восстановление последней полной резервной копии без необходимости наката инкрементальных копий. Использование функции Instant Restore для быстрого доступа к СУБД еще в процессе восстановления также является большим плюсом.

Не больше 25% и в пределах 50 Тб


Вернемся к случаю заказчика. Тестирование на синтетической БД оказалось полезным, так как помогло клиенту увидеть все за и против первоначально симпатичного решения. Поиграв с параметрами, мы пришли к выводу, что использовать Veritas NetBackup целесообразно для СУБД размером до 50 Тб, а также при суточных изменениях в БД не более 25%. Поскольку БД розничной сети менялись каждые сутки на 50%, то Veritas NetBackup не стал подходящим решением.

Побочный эффект нашего тестирования оказался ценным. Мы нашли оптимальные режимы для работы Veritas NBU вместе с СУБД Oracle. За счет настройки параметров и выбора режима (классическая копия или Copilot) можно создать достойную и более доступную альтернативу для резервного копирования и восстановления СУБД Oracle при относительно небольшом количестве суточных изменений в БД в десятки Тб. Для тех, кто уже пользуется СРК Veritas, такой выход оптимален. Это использование более доступной по стоимости СРК и управление всем резервным копированием через одну консоль.

Автор: Артем Хмеленко, инженер систем хранения данных Инфосистемы Джет
Подробнее..

Переворот на инфраструктурном рынке ARM против Intel

19.04.2021 12:12:03 | Автор: admin

99,9 % всех серверов на рынке построены на базе Intel. Поэтому, говоря про серверное железо, мы невольно подразумеваем технику на базе Intel, как в свое время под ксероксом подразумевали копировальный аппарат от единственного производителя этих устройств.

С годами на рынке устройств печати монополия была разрушена появились сильные игроки, потеснившие Xerox. А что же с рынком серверного оборудования? До недавнего времени многие считали, что Intel продержится у руля еще 10лет, и предпосылок к переменам не было.

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

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

Темы круглого стола:

  • Почему процессоры ARM внезапно стали такими быстрыми?

  • Какой софт нужен новым процессорам, и где его взять?

  • Зачем компаниям нужна закупка подобного железа?

  • Как прошли первые тесты ARM? Как процессоры показывают себя в продуктивной эксплуатации?

Кому будет интересно?

  • руководителям направления ИТ-инфраструктуры;

  • CIO компаний различных отраслей;

  • старшему техническому составу ИТ-подразделений.

Модератор: Илья Воронин, руководитель Центра проектирования вычислительных комплексов Инфосистемы Джет

Спикеры:

  • Павел Романченко, технический директор Центра инноваций Инфосистемы Джет;

  • Александр Голуб, технический директор Т-Платформы;

  • Василий Гладышев, руководитель департаментаИТ эксплуатации QIWI.

Регистрация по ссылке

Подробнее..

Сказка про SD-WAN

27.11.2020 16:12:57 | Автор: admin
Как от перфокарт и проводков мир дошел до программно-определяемых сетей, и что теперь с этим делать.



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

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

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

Но потом какие-то негодяи придумали всякие атаки на сети. И рядом с файрволом поставили IDS/IPS. А потом пришёл очередной кризис, и все стали бедными. Под эту тему некоторые предприимчивые граждане придумали оптимизаторы трафика. Люди их купили и поставили рядом с остальной кучей железяк. Чтобы хоть как-то понимать, что теперь происходит, до кучи прикупили систему управления и мониторинга и, чтобы два раза не вставать, антивирус.

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

И все такие хором: Ох! Теперь же сетевые функции можно впихнуть на обычные серваки! Или даже на один сервак! Вместо отдельных железяк можно сделать на одном железном серваке отдельные виртуалки, попросить кого-нибудь придумать способ расстановки этих виртуалок в нужном порядке (service chain), ???, PROFIT!!!.

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

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


Тем временем стала модной тема SDN. Под неё некоторые предприимчивые граждане решили попробовать натянуть SDN на глобус WAN. Даже термин SD-WAN появился, типа тоже программно-определяемая распределенная сеть. То есть сперва придумали термин, а потом стали думать о реализации.

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

Поэтому, подумав, стартапы породили новую концепцию: SD-WAN это не просто конфигурирование железа через web-морду. Больше не конфигурим железо не барское это дело. Работать должны роботы, человек создан для творчества. Люди композиторы, пишут музыку, а оркестром рулит дирижёр. И не важно, как именно он сконфигурит эти мсвиртуальные железки, всё сделает быстро и без ошибок, человеческий фактор практически исключён, 100% гарантия следования нотам.

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

Что было дальше?


  1. В одном флаконе теперь могут жить роутер, FW, IDS/IPS, оптимизатор, антивирус, система управления и прочий DPI, который умеет рулить не просто пакетами, но приложениями. Ну или не все хором, а любая их комбинация.
  2. Вместо инженера можно отправлять в командировку монтажника или вообще тупо разбудить по телефону охранника и попросить его подключить провода и питание.
  3. Зачем вообще программировать тривиальную по сути задачу на ассемблере, когда существуют визуальные языки программирования?

Да и научить управляться в визуальной среде быстрее, проще и дешевле, чем обучить условного CCIE. Вообще лучше день потерять, зато потом за 5 минут долететь.

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

Но главная гибкость SD-WAN в эффективном использовании каналов. Железяки очень умные, поэтому постоянно следят за всевозможными характеристиками разных каналов (выделенка ли, интернет ли хоть корпоративный, хоть домашний, хоть условная Yota, хоть халявный Wi-Fi из соседнего Макдональдса). Потому что иногда VPN через интернет может быть по куче причин выгоднее, чем VPN через выделенный канал. И в зависимости от заданных корпоративных политик умеет направлять трафик от разных приложений в наиболее подходящий для него канал, причём что такое наиболее подходящий, определяется не толщиной или типом канала, а, например, задержками.

Ну или как поставщики сами решат, потому что они теперь главные. И очень, очень гибкие! А тут из зала крики, мол, так-то звучит заманчиво, а нам это надо? А и правда, кому это надо? Тем, у кого есть распределённые сети и филиалы. И чем распределённее и филиальнее, тем больше надо. Банки с кучей отделений и сетью банкоматов, сетевой ритейл, страховые компании, франшизы (типа производителей бургеров и жареной курицы), пенсионные фонды, почты России. Сюда же идут лавки, у которых есть филиалы за бугром, прям милое дело использовать SD-WAN! Но есть самые-самые потенциальные клиенты. У кого самые большие и самые распределённые сети на миллиард подключений? Операторы, конечно.

Так за чем же дело стало? Речь же не о переходе на SD-WAN, не о софте и железе, а о новой услуге. Компании ставят конфигурялко-управлялко-мониторилку у себя и продают SD-WAN как облачную услугу, сдавая клиентские устройства в аренду, например! С учётом того, что одна конфигурялка-управлялка может держать на себе 2500 устройств, причём как угодно распределённых между клиентами, и клиенты никак не пересекутся и друг о друге ничего не узнают, SD-WAN для операторов самое милое дело.

Или, скажем, решает один из офисов переехать. Ну, аренда ли перестала устраивать, мэр ли на бульдозере под покровом ночи напал пусть переезжает! Берёт SD-WAN и валит куда хочет, даже в тот самый бизнес-центр, куда не пускают всякие коррупционеры. И к какому бы оператору он на новом месте ни подключился, продавец-первопроходец копеечку за свои (СВОИ!) сервисы получит, потому что SD-WAN, как тот праздник, всегда с тобой. Воткнул в розетку, всякие VPN и прочие файрволы тут же включились и работай, касатик, ничего не бойся. А ежемесячная аналитика в разрезе каналов и приложений будет прилетать регулярно.

В настоящий момент советские операторы ещё не шибко предлагают SD-WAN как услугу, но потом прочухаются и станут предлагать его честным коммерсантам. И если бизнесмены не любят насаживаться выход есть, и он зеркальный. Не используешь облачную операторскую SD-WAN-голову, а покупаешь собственную, воспитываешь, так сказать, Бабу-ягу в своём коллективе. И всё! Полная мобильность, полная независимость и контроль над каналами и приложениями. И надежность выше, и свобода полная. Захотел к этому оператору подключился, захотел к другому, захотел вообще переехал. Но суть-то осталась! Воткнул SD-WAN в розетку, он тут же получил новые настройки, всякие VPN и прочие файрволы тут же включились и работай, касатик, ничего не бойся. Хорошо быть свободным человеком!
Подробнее..

Рыцари несправедливости. Дата-сайнтисты против смещения данных

09.03.2021 12:08:26 | Автор: admin
Рыцари справедливости. Кадр из фильмаРыцари справедливости. Кадр из фильма

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

Причины смещения данных

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

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

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

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

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

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

  • датчики, снимающие данные, могут быть заменены на аналогичные, но другой фирмы и с другой погрешностью;

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

  • датчик, всегда измерявший в сантиметрах, начинает возвращать измерения в метрах;

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

Чтобы отследить такие неполадки, существуют инструменты для мониторинга данных. Они проверяют, что новые данные не имеют критических отличий от данных из обучения модели. Если у нас начинает появляться много данных, которые лежат, например, за границами диапазонов обучения, или данные начинают быть непохожими по своим статистическим характеристикам на данные, использованные для обучения (например, где-то датчик начал часто западать и возвращать значение 300 вместо обычного значения 400-700), система мониторинга сообщает об этом специалистам, и люди уже разбираются, что же произошло, не изменился ли процесс настолько, что нам теперь нужна другая модель.

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

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

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

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

Доверяй, но проверяй

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

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

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

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

Александра Царева, специалист машинного обучения "Инфосистемы Джет"

Подробнее..

Big Data. Как повышают квалификацию сотрудники ИТ-компаний

19.02.2021 12:19:30 | Автор: admin

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

Мастерская Big Data

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

Есть план

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

Конечно, мы не ставим новые задачи по изучению конкретных технологий каждые два месяца, а, определив вектор развития, ставим контрольные точки в виде промежуточных результатов, которые приближают нас к цели. У нас есть объемные темы, допустим, Big Data, Data Lake, Hadoop и т. п., и за 2 месяца нереально все сразу изучить. Поэтому руководитель формулирует этапы.

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

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

Антон:

Я одновременно решал рабочие задачи и развивался врамках своего индивидуального плана. Бывает, когда задачи по ИПР не совсем стыкуются сзадачами по проекту: допустим, проект перенесся, задача есть, а проекта нет. Тут как-то самостоятельно не в ущерб времени, выделяемого на проект, приходится что-то осваивать.

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

Вендоры

Oracle. Изначально наш отдел, а теперь уже большой Центр, создавался на базе продуктов Oracle: мы занимались базой данных Oracle, системой отчетов Oracle BI, Apex и Data Integrator. Начиная с 2008 года мы активно изучали эти продукты.

Сергей:

С 2008 года я отвечаю за направление Oracle Data Integrator. Несколько раз проходил обучение, например, применение Data Integrator для построения хранилищ данных. До пандемии все обучение шло очно, я ездил в учебные классы Oracle, выполнял практические и теоретические задания. Это было серьезное и плотное обучение, по-моему, более основательное, чем по Zoom или Skype. Сейчас мы все это активно закрепляем на практике.

Антон:

Я проходил обучение по реляционным базам данных Oracle на различных курсах. Эти курсы всегда шли в центре обучения, уроки длились весь рабочий день, апрактические задания отрабатывали в классе на рабочих машинах с настроенными "песочницами". Обучение занимало от 3 до 5 дней с утра до вечера. Курсы имеет смысл пройти, чтобы структурировать знания и заполнить пробелы. Это нужно не для получения сертификата, а для дальнейшей работы. Я, например, сдавал экзамен по Oracle SQL, но я не проходил никакого обучения: сам готовился и сам сдавал.

Arenadata. Курс от Arenadata, который мы проходили, назывался Эксплуатация Arenadata DB. Внем был теоретический блок и практические задания, которые мы выполняли вспециально организованной "песочнице". Для этого была подготовлена платформа, каждому из нас дали доступ, и выделили свой экземпляр кластера, на котором можно проводить эксперименты по установке и запуску DB. Можно проверить софт, который идет впоставке, выполнение простейших команд, например, создание таблиц, распределение ролей и т.д.

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

Юнидата. В 2020 году Центр начал контактировать с Юнидата, и они предложили присоединиться ких вебинарам на тему MDM-систем. Обучение проходило во время карантина, когда многие ушли на удаленную работу, а курс назывался Юнидата усиливает борьбу скоронавирусом J.

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

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

Informatica. Недавно мы проходили обучение по американской платформе Informatica. Его организовывала DIS Group, представитель Informatica в России и странах СНГ. А курс назывался Интеграция данных для разработчиков. Мы рассмотрели там основные моменты по использованию информатики в power center. Обучение заняло 5 дней, на каждом занятии была вводная часть и потом практика.

Зачем все это?

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

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

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

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

Подробнее..

Наиболее полный обзор рынка внедрений CRM-систем исистем лояльности за 10 лет

24.12.2020 04:15:09 | Автор: admin

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

Поэтому мы решили впервые опубликовать собственное исследование этого рынка. В нем рассматривались более 3,4тыс. проектов внедрений CRM-систем и систем лояльности за последние 10лет в России.

Этот пост будет интересен владельцам бизнеса, аналитикам, исполнительным и ИТ-директорам ивсем, кто изучает, внедряет или использует системы CRM. Так что, велком под кат.

Чтобы избежать недопонимания, определимся с терминами:

Крупнейшие компании компании, входящие в рейтинг РАЭКС-600. Под прочими компаниями понимаются те, кто не вошел в этот рейтинг.

Топ-системами мы называем системы от следующих вендоров: SAP, Oracle, SAS, Manzana, Microsoft, ЦФТ, Salesforce, Terrasoft. Если на базе топ-систем были сделаны доработки и новые продукты, то эти внедрения идут как системы на базе топ-систем. Остальные системы относим к прочим системам.

Если внедрение проекта заявлено в 2019-2020 гг, то запись относится к актуальным проектам.

Основные выводы:

1. Общий спрос на CRM решения в 2020году был постоянным и высоким.

2. Топ-3 отрасли по внедрениям по крупнейшим компаниям это финансы, ритейл и телеком.

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

4. CRM часто внедряется как облачная услуга.

5. Лидер по внедрениям компания Terrasoft.

Общая динамика

Рассматривая проекты за период 2010-2020гг., мы можем отметить большое количество проектов в 2011году и далее два года активных внедрений CRM-систем. Кризис частично сократил число проектов в 2014 и 2015годах, однако в среднем за 2014-2019гг. происходило порядка 250внедрений в год.

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

Динамика по крупнейшим компаниям отличается от общих тенденций. В крупнейших компаниях тоже был всплеск внедрений в 2011году, но не такой большой, как в общем по компаниям. И далее можно отметить плавный рост числа проектов с 2012 по 2019годы. В текущем году число проектов не дотягивает до аналогичных показателей прошлого года и составляет 65% от прошлогодних показателей. Это касается как топ-систем, так и прочих.

Отраслевое распределение

Отраслевое распределение различается в зависимости от размера компании. Если для крупнейших компаний топ-3 отрасли это финансы, ритейл и телеком, то среди прочих компаний ритейл, ИТ и финансы.

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

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

крупнейшие компании

прочие компании

Финансовые услуги, инвестиции и аудит

Ритейл

Ритейл

Информационные технологии

Телекоммуникация и связь

Финансовые услуги, инвестиции и аудит

Металлургическая промышленность

Фармацевтика, медицина, здравоохранение

Страхование

Строительство и промышленность строительных материалов

Фармацевтика, медицина, здравоохранение

Телекоммуникация и связь

Транспорт

Индустрия развлечений, досуг, спорт

Пищевая промышленность

Логистика и дистрибуция

Нефтяная промышленность

Государственные и социальные структуры

Строительство и промышленность строительных материалов

Образование и наука

Обзор подготовила Пахтанова Ольга, аналитик Инфосистемы Джет.

Подробнее..

Все об OpenShift Egress. Часть 2

16.12.2020 10:16:09 | Автор: admin
В первой части статьи про OpenShift Egress мы рассмотрели варианты организации фиксированных исходящих IP-адресов для POD в кластере. Но что делать, если надо предоставить доступ во внешние по отношению к кластеру сегменты сети, находящиеся в определенных VLAN?


Манипуляции с IP-адресацией здесь не помогут. Единственным решением в этом случае будет организация дополнительных интерфейсов на узлах кластера, которые будут находиться в нужных VLAN, и организация доступа к дополнительным интерфейсам с нужных нам проектов внутри кластера. И помочь в этом может проект под названием Multus CNI.

Multus CNI


Как известно, по умолчанию у POD в Kubernetes есть один интерфейс, через который и происходит все взаимодействие с ним. Multus позволяет создать в POD несколько интерфейсов помимо определенного по умолчанию. Фактически Multus сам является CNI-Plugin'ом, в свою очередь управляющий вызовом других CNI-Plugin'ов. За это Multus называют CNI meta Plugin. То, что делает Multus, хорошо показано на картинке из статьи Demystifing Multus:


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

Настройка Multus CNI в OpenShift


Итак, попробуем решить задачу доступа в выделенный VLAN на нашем стенде. По умолчанию всем узлам кластера выделен один интерфейс, находящийся в VLAN OpenShift (IP: 192.168.111/24). Мы хотим организовать доступ из проекта multes-test в ресурсы сети 192.168.112/24, находящейся в VLAN Restricted. VLAN Restricted и VLAN OpenShift между собой не маршрутизируются.


Для начала добавим на ряд узлов (в нашем случае это Node1 и Node2) интерфейс из VLAN Restricted, и поставим на этих узлах метку node-role.kubernetes.io/multus-node='yes'. C узлов с меткой multus-node будут доступны ресурсы из Restricted VLAN. Создадим наш проект multus-test:

[ocp@shift-is01 macvlan]$ oc new-project multus-test

Поддержка Multus CNI давно присутствует в OpenShift, отдельно добавлять ее не надо. Управление конфигурацией Multus производится через CR в CRD networks.operator.openshift.io. Необходимо отредактировать этот ресурс, добавив конфигурацию CNI Plugin для нового интерфейса:

oc edit networks.operator.openshift.io cluster

spec:  additionalNetworks:    - name : net1      namespace: multus-test      type: Raw      rawCNIConfig: |-        { "cniVersion": "0.3.1",          "type": "ipvlan",          "mode": "l2",          "master": "ens224",          "ipam": {            "type": "static"           }        }

Этот момент требует расшифровки. Что мы определили данной конфигурацией?

  1. Для POD в проекте multus-test добавится интерфейс с названием net1
  2. Конфигурация этого интерфейса будет определяться через CNI Plugin ipvlan;
  3. CNI Plugin ipvlan сконфигурируется в L2 Mode;
  4. В качестве основного интерфейса для net1 используется физический интерфейс узла ens224;
  5. И, наконец, для управления IP-адресацией будет применяться IPAM static plugin.

Выбор CNI Plugin


Для нашего дополнительного интерфейса нужно выбрать используемый CNI Plugin. Список возможных CNI Plugin можно посмотреть на сайте www.cni.dev. В своем примере мы используем ipvlan plugin. По сути это простейший bridge, который позволяет контейнерам взаимодействовать через внешний сетевой интерфейс хоста. При этом все исходящие соединения используют свой IP-адрес, но будут иметь MAC-адрес внешнего сетевого интерфейса. Картинка с сайта hicu.be хорошо иллюстрирует работу ipvlan plugin:


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

Выбор IPAM Plugin


Помимо организации сетевого интерфейса нам необходимо определить правила выдачи IP-адреса для нового интерфейса. Этим также занимается CNI Plugin, который реализует функции IP Address Management (или IPAM). Список возможных IPAM-plugin также можно посмотреть на сайте www.cni.dev. В данном примере мы использовали простейший static IPAM plugin, который присваивает фиксированный адрес нашему POD.

Если таких POD окажется много, использовать static IPAM станет неудобно. Хорошим выбором здесь будет либо использование dhcp plugin (он назначает IP адреса POD через запрос к внешнему DHCP-серверу), либо использование whereabouts plugin.

Поддержка этих IPAM Plugin также по умолчанию есть в OpenShift, отдельно устанавливать их не надо.

Доступ в restricted VLAN


После определения нашей конфигурации Multus в кластере должен появиться ресурс под названием Network Attachment Definition, в котором отражена текущая конфигурация Multus:

Network Attachment Definition

[ocp@shift-is01 macvlan]$ oc get network-attachment-definitions --all-namespacesNAMESPACE     NAME   AGEmultus-test   net1   3m4s[ocp@shift-is01 macvlan]$ oc get network-attachment-definitions.k8s.cni.cncf.io -n multus-test net1 -o yamlapiVersion: k8s.cni.cncf.io/v1kind: NetworkAttachmentDefinitionmetadata:  creationTimestamp: "2020-11-02T16:44:46Z"  generation: 1  managedFields:  - apiVersion: k8s.cni.cncf.io/v1    fieldsType: FieldsV1    fieldsV1:      f:metadata:        f:ownerReferences:          .: {}          k:{"uid":"01a4f46a-fc3c-495f-b196-b39352421e2a"}:            .: {}            f:apiVersion: {}            f:blockOwnerDeletion: {}            f:controller: {}            f:kind: {}            f:name: {}            f:uid: {}      f:spec:        .: {}        f:config: {}    manager: cluster-network-operator    operation: Update    time: "2020-11-02T16:44:46Z"  name: net1  namespace: multus-test  ownerReferences:  - apiVersion: operator.openshift.io/v1    blockOwnerDeletion: true    controller: true    kind: Network    name: cluster    uid: 01a4f46a-fc3c-495f-b196-b39352421e2a  resourceVersion: "25898949"  selfLink: /apis/k8s.cni.cncf.io/v1/namespaces/multus-test/network-attachment-definitions/net1  uid: 7a7d718b-82c5-46fe-8f72-8fd4299508ecspec:  config: |-    { "cniVersion": "0.3.1",      "type": "ipvlan",      "mode": "l2",      "master": "ens224",      "ipam": {        "type": "static"       }    }

Создадим тестовый POD с дополнительным интерфейсом, который будет иметь доступ в наш restricted VLAN:

pod-ipvlan-static.yaml

[ocp@shift-is01 ipvlan]$ cat ./pod-ipvlan-static.yamlapiVersion: v1kind: Podmetadata:  namespace: multus-test  name: test-multus-pod  labels:    app: test-multus-pod  annotations:    k8s.v1.cni.cncf.io/networks: '[      {        "name": "net1",        "ips": ["192.168.112.250/24"]      }]'spec:  nodeSelector:    node-role.kubernetes.io/multus-node: yes  containers:  - name: test-multus-pod    image: centos/tools    command: ["/bin/bash", "-c", "sleep 9000000"]

Зайдем в созданный POD, чтобы посмотреть его сетевую конфигурацию и проверить доступность адресов в restricted VLAN (в сети 192.168.112.0/24):

ocp@shift-is01 ipvlan]$ oc rsh test-multus-podsh-4.2# ip a1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00    inet 127.0.0.1/8 scope host lo       valid_lft forever preferred_lft forever    inet6 ::1/128 scope host       valid_lft forever preferred_lft forever3: eth0@if2142: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default    link/ether 0a:58:0a:fe:04:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 0    inet 10.254.4.160/24 brd 10.254.4.255 scope global eth0       valid_lft forever preferred_lft forever    inet6 fe80::bc4b:abff:fe0b:91f8/64 scope link       valid_lft forever preferred_lft forever4: net1@if826: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default    link/ether 00:50:56:96:f3:02 brd ff:ff:ff:ff:ff:ff    inet 192.168.112.250/24 brd 192.168.112.255 scope global net1       valid_lft forever preferred_lft forever    inet6 fe80::50:5600:196:f302/64 scope link       valid_lft forever preferred_lft foreversh-4.2# ping 192.168.112.1 -c 3PING 192.168.112.1 (192.168.112.1) 56(84) bytes of data.64 bytes from 192.168.112.1: icmp_seq=1 ttl=64 time=0.179 ms64 bytes from 192.168.112.1: icmp_seq=2 ttl=64 time=0.230 ms64 bytes from 192.168.112.1: icmp_seq=3 ttl=64 time=0.223 ms--- 192.168.112.1 ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 2041msrtt min/avg/max/mdev = 0.179/0.210/0.230/0.028 ms

Как видно из вывода команды ip a, POD получил дополнительный сетевой интерфейс net1@if826 и IP-адрес, который мы указали в его манифесте. Так как дополнительный интерфейс работает через ethernet адаптер, находящийся в restricted VLAN, с этого POD мы получили доступ в нужный нам сегмент сети.

Автор: Сергей Артемов, руководитель отдела DevOps-решений Инфосистемы Джет

Присоединяйтесь к нашему каналу в Telegram @DevSecOps Talks!

Список литературы


  1. OpenShift 4 with MacVLAN and whereabouts
  2. Demystifying Multus
  3. Macvlan vs Ipvlan
Подробнее..

Категории

Последние комментарии

  • Имя: Murshin
    13.06.2024 | 14:01
    Нейросеть-это мозг вселенной.Если к ней подключиться,то можно получить все знания,накопленные Вселенной,но этому препятствуют аннуннаки.Аннуннаки нас от неё отгородили,установив в головах барьер. Подр Подробнее..
  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru