Всем привет!

Если вы уже успели заскучать от типовых атак на торчащие наружу облачные Docker API с последующим майнингом криптовалюты, то как раз для вас подъехала отличная статья! :)

Исследователи компании Intezer обнаружили новое вредносное ПО (это backdoor), назвав его Doki. Конечно, все в итоге сводится к вышеуказанному, но атака в совокупности с Doki реализуется действительно изящно.

Тому есть 2 причины:

Во-первых, в скомпрометированной инфраструктуре запускаются легитимные образы (это alpine с установленным curl).

Выглядит это примерно так:
🍡К Docker API создаётся запрос с указанием параметра для привязки папки контейнера к рутовой директории сервера
🍡С использованием сервиса Ngrok загружаются вредоносные файлы через curl (сетевые сканеры и "плохие бинари", среди которых и был обнаружен Doki)

Во-вторых, Doki - это такой вредонос под Linux, который не смогли выявить даже 60 антивирусов VirusTotal. К тому же он использует незадокументированный метод связи со своим оператором, используя blockchain-технологию криптовалюты Dogecoin для динамической генерации его доменных имён C2 .

Но об этом вам лучше почитать в самой статье по ссылке.

P. S. И немного про Ngrok.

Всем привет! Time to robotize!

Вы знали, что типовые рутинные процессы, выполняемые человеком в информационных системах, можно типизировать, алгоритмизировать и автоматизировать?

Для этих целей существуют специальные платформы под названием Robotic Process Automation (RPA).
Решили немного рассказать про них.

Зачем нужны RPA?
По факту есть 2 большие цели:
🍪Автоматизация простых рутинных операций или даже реализации сложных бизнес-процессов
🍪Скорость и минимизация ошибок при решении различных задач вроде почтовой рассылки или аггрегации данных из разных систем (сокращение человеческого фактора)

Почему именно RPA, а не 'классическая' автоматизация?
Есть несколько причин:
🍪Возможность использования сторонних библиотек: компьютерное зрение, OCR, встраиваемые внешние модули AI
🍪Не надо переделывать бизнес-процесс, он автоматизируется as is (роботы воспроизводят действия пользователей)
🍪Общая среда управления роботами: расписание, балансировка нагрузки, запуск разных процессов из единой точки.

Где это может быть применимо на примерах?
🍪Продажи (проверка наличия товаров на складе, письма)
🍪HR (сборка заявок в HR службу)
🍪Финансы (формирование рассылок отчётов)
🍪Внутренний контроль (аналитика по финансовой отчётности)
🍪Управление информацией (проверка контрагентов)
И это ещё не все.

Какие RPA платформы можно встретить на рынке?
🍪UIPATH (наиболее известное решение)
🍪Robin (первое решение в реестре российского ПО)
🍪Blue Prism
🍪Automation Anywhere

Если интересно, расскажем в чем разница. Пишите в чатик

Всем привет!

Сегодня скажем пару слов про харденинг и полезные инструменты для него. А так же можно ли упростить этот процесс.

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

Но ведь в процессе жизненного цикла эта конфигурация может изменится!
Как понять, не произошло ли критичных с точки зрения безопасности изменений в конфигурации?
К счастью, есть решение!
Фреймворк Inspec разработанный компанией Chef, одним из лидеров в вопросах управления конфигурациями, поможет провести аудит целевых систем, не затрагивая при этом непосредственно конфигурацию. Мы не передаем и не заменяем на серверах конфигурации, но проводим проверку и получаем отчёт о конкретных изменениях в них.

Плюшки inspec:
🍩 Возможность выполнять проверки в удаленных системах посредством ssh и winrm (для Windows).
🍩 Возможность применять профили проверок из github на лету, без pull’ов.
🍩 Поддержка аудита для docker контейнеров и облачных провайдеров (AWS, Azure).
🍩 Из удаленных систем берутся только значения проверяемых параметров. Нарушить работоспособность своим сканированием нельзя.
🍩 Легко кастомизируемые профили проверок. Нет нужды проверять все параметры конфигурации систем. Проверяем только необходимое нам.
🍩 Встроенный supermarket с большим набором готовых проверок под различные системы и прикладное ПО (от Windows до Kubernetes).
Решение может быть интегрировано в конвейеры разработки, IaC системы и в целом обладает большой гибкостью применения!

Больше информации на сайте и github разработчиков.

https://inspec.io
https://github.com/inspec/inspec
Stay safe. Stay secure. 😷

Нашли картинку, которая наглядно изображает, как с помощью инструментов DevSecOps автоматизировать рабочую рутину. Машина Голдберга, которую мы все заслужили 🤓 Всем хорошей и продуктивной пятницы: https://twitter.com/memenetes/status/1287923648787931136?s=09

И снова привет!

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

🍭 Code review
🍭 Chat and Chat Ops
🍭 Chaos Engineering (куда уж без этих 🙈)
🍭 Secret Management
🍭 Monitoring
🍭 И многое другое :) Позиций и правда больно много, чтобы все перечислять

В дополнение, помимо технологий, есть ссылки на полезные ресурсы (книги, конференции) и... DevOps Roadmap - прямо путь самурая путь DevOps'era с указанием компетенций, которые ему надо развить - хоть на стену вешай!!!
Кстати, а согласны ли вы с таким развитием специалиста? Ждем вас в чате для обсуждения!

Ссылка на Awesome DevOps: тут! Всем отличного дня!

GitHub
wmariuss/awesome-devops
A curated list of awesome DevOps tools, platforms and resources - wmariuss/awesome-devops

Что делать, если хочется Infrastructure as a Code, а вся инфраструктура уже развернута? Встречайте Terraformer - CLI для анализа существующей инфраструктуры и автоматической генерации tf и tfstate, aka reverse Terraform.

Помимо крупнейших облаков умеет работать с Yandex.Cloud, OpenStack, Kubernetes и много чем ещё. VMware не умеет :( есть issue, но без движения с апреля.

Вот тут можно посмотреть пример работы.
“Infrastructure to Code: Terraformer” by Amet Umerov https://link.medium.com/VHHyplG1D8

Привет!

Решили познакомиться с новыми CI/CD инструментами (не Jenkins’om единым!) и наткнулся на интересную статью про … Docker!!! А именно – antipatterns и как можно их избежать.

У автора интересная подача, которая начинается с простого – «Не путайте виртуальные машины и контейнеры. Контейнеры – не виртуальные машины!». Не с точки зрения техники, скорее с точки зрения восприятия. Это важно, потому как это подводит к таким советам, как:

🍭 Образ контейнера – новая «единица обмена» информацией. Dev больше не дает код/приложение Ops и не просит его «развернуть». Он дает Dockerfile!

🍭Образы должны быть максимально простыми. И даже образы контейнеров можно «дробить» (есть интересный подход через multistage build, где результирующий Dockerfile не содержит «лишней» информации, что делает его легче, менее многослойным)

🍭 Не «вшивайте» конфигурационную информацию ИТ-окружения в Dockerfile – это подводит нас к тому, что Dockerfile в Dev, Test, QA, Cert, Pre-prod и Prod – это один и тот же образ!

🍭 А как тогда передать конфигурацию?.. В run-time, например, в качестве переменных окружения - в статье есть отличные примеры и инструменты, которые позволяют это делать!

И это далеко не все (согласно рекомендациям, статья занимает 19 минут)!

Всем привет!

Снова возвращаемся к теме управления секретами.
Хардкодить пароли в конфигах и образах плохо? Выносить их в переменные окружения лучше, но тоже плохо? Что же тогда делать?
Использовать систему управления секретами!
В этот раз расскажем немного о CyberArk Conjur.
Conjur - это open source версия коммерческого продукта Cyberark DAP (Dynamic Access Provider). Он разворачивается в среде контейнеризации, например, и реализует функции работы с секретами.

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

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

Чем может помочь Conjur :
🍩 Пароли хранятся за пределами приложений и контейнеров
🍩 Система гарантирует что секрет будет выдан только по валидным запросам
🍩 Система ведет аудит всех действий над секретами (внесение, обновление, выдача)
🍩 В enterprise варианте возможно создание отказоустойчивого кластера
🍩 Легкая интеграция с CI/CD системами и оркестраторами
🍩 Централизованное управление секретами
И многое другое.

Подробнее - на портале вендора.
https://www.conjur.org/

Привет! Ещё одна вундервафля от Red Hat: на этот раз глобальный балансировщик на несколько кластеров OpenShift. Интегрируется с ACM, но поддерживает пока только ExternalDNS и Амазон, а значит не очень практически применима. Но концепт интересный, плюс пойдет в виде ликбеза и лучших практик.

https://www.openshift.com/blog/global-load-balancer-for-openshift-clusters-an-operator-based-approach

Всем привет! Если у вас приложение развёрнуто в RedHat OpenShift и ему требуется доступ к системам и СУБД вне кластера, то вы наверняка задумывались о том, как выпустить нужный тип трафика наружу, причём так, чтобы не открывать доступ со всех узлов кластера.

Чтобы решить эту задачу, можно использовать несколько способов. По сути каждый из них сводится к тому, чтобы выделить приложению конкретный адрес сети хоста, который затем указать на корпоративных СЗИ типа NGFW, proxy и пр. Тем не менее, каждый способ имеет свои особенности.

🍡Способ 1. Назначить egress IP (адрес из подсети узлов кластера) на ноды, затем присвоить этот адрес конкретному проекту (namespace). Это делается в 2 команды на уровне oc. Затем OpenShift сам поднимает дополнительный интерфейс и перекидывает egress IP в случае падения ноды.

После настройки трафик из подов проекта к внешним системам будет идти не с "обычного" IP хоста, а с выделенного egress IP. Этот адрес затем можно использовать на "типовых" средствах защиты в качестве source-адреса. Кроме этого можно на уровне самой платформы настроить EgressNetworkPolicy, которая позволит ограничить то, куда приложение может ходить. Но у неё, увы, есть ряд серьёзных ограничений. Для версии 4.5 это актуальный способ и по факту является заменой egress router (об этом ниже). Более подробная информация тут.

🍡Способ 2. Поднять в поде дополнительный интерфейс (отдельная сеть). Этот относительно новый подход, который может использоваться не только для контроля внешнего трафика (скорее, так просто можно делать), но и для разделения потоков трафика приложения. Реализуется эта возможность с помощью "мета" CNI-плагина, который называется multus. Multus - это open source проект, который умеет 'дёргать' другие плагины. Он и обеспечивает 'attach' дополнительного интерфейса в под. У RedHat OpenShift есть следующие плагины, которые можно дёргать multus-ом: bridge, host-device, macvlan, ipvlan, SR-IOV. Более подробно можно почитать тут и тут.

🍡Способ 3. В более старых версиях RedHat OpenShift, например, 3.11, можно еще развернуть egress router (под+сервис). Egress router разворачивается на конкретной ноде, ему тоже требуется выделенный IP. Egress router может работать в 3-х режимах (DNS proxy, HTTP/S proxy, redirect), выбор которого зависит от типа передаваемого приложением трафика. В конфигах настраивается source, destination, gateway. В этом случае надо сделать так, чтобы приложение подключалась к сервису egress router для доступа к внешним ресурсам. Этот вариант исчез из документации в 4.5. Для 3.11 описан тут.

Привет!

17 августа CNCF провела несколько онлайн сессий в рамках KubeCon: ServiceMeshCon, Serverless Practitioners Summit и Cloud Native Security Day.

Буквально вчера на youtube стали доступны записи докладов!!! Посмотреть их можно по ссылке. А чтобы получить первое представление о том, что можно посмотреть приводим несколько примеров:

ServiceMeshCon:

🍭 Service Mesh Is Still Hard. The Things we all Did Wrong & Tales of Woe
🍭 Service Mesh Architectures Explained - Sidecar and Beyond

Serverless Practitioners Summit

🍭 Chaos Engineering in a Serverless World 🙈🙈🙈
🍭 3factor app: An Accessible Design Pattern for Serverless

Cloud Native Security Day

🍭 Kubernetes Attack and Defense
🍭 Pod Security as an Afterthought

Что может быть лучше, чем залезть под одеяло в такую погоду и смотреть множество интересных видео?
А какой доклад понравился вам больше всего? Ждем в чате! Кстати, там даже есть доклад от Сбербанка 😃

Привет!

Читая большое количество статей про Kubernetes и контейнеры может сложиться впечатление, что это просто silver bullet, который позволяет без особых усилий переносить приложения всеми возможными способами (из Dev в Prod, из on-prem в Cloud, из Cloud в on-pem и вообще везде-везде-везде).

Но, все знают, что silver bullet не существует, но продолжают его искать. Такой вот парадокс. Чтобы показать, что реальность может несколько отличаться от ожиданий мы перевели отличную статью Kevin Casey, в которой рассматриваются потенциальные трудности (или задачи! зависит от вашей точки зрения), с которыми можно столкнуться при миграции Dev -> Prod!

А вы сталкивались с чем-нибудь подобным или все прошло «как по маслу»? Ждем вас в чате!

https://habr.com/ru/company/jetinfosystems/blog/518694/

Всем привет!

К вопросу о сетевых плагинах к Kubernetes. Нашли отличную статью про актуальные плагины для кубера, в которой приведено сравнение по производительности для разных вариантов. На наш взгляд, весьма ценная информация, которая позволяет сориентироваться в существующем многообразии CNI. Помимо тестов на performance, авторы так же дают рекомендации по настройке MTU, и рассматривают вопрос функционирования при включении шифрования трафика. Рекомендуем к прочтению!

https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-updated-august-2020-6e1b757b9e49

Привет!

По ссылке пост из блога компании Palo Alto Networks, который описывает, казалось бы, достаточно очевидные вещи, такие как значимость комплексного подхода для защиты контейнеров.

Суть заключается не только в анализе образов, но и в защите runtime. Такой подход позволит стать ближе к реализации концепции Zero Trust в Cloud Native мире. А сами примеры того, на что стоит обращать внимание приведены в статье! ) Приятного чтения!

Ссылка: https://blog.paloaltonetworks.com/2020/09/cloud-native-zero-trust/

И это снова мы!

В предыдущем посте мы написали про значимость комплексного подхода по защите контейнеров: на «уровне» образов и runtime. А так ли это важно на самом деле?

Ответ – да. Из показательных примеров можно привести недавно обнаруженную уязвимость CVE-2020-14386, которая позволяет повысить привилегии до root и совершить escape на node.

Специалисты из Sysdig написали потрясающую статью, которая описывает способы обнаружения и устранения указанной уязвимости с использованием их продуктов:

🍭 Falco (runtime защита) – создание правила, которое позволит идентифицировать создание новых socket в контейнер
🍭 Sysdig Secure – использование функционала по анализу workloads с целью идентификации тех, что подвержены рассматриваемой CVE

Для устранения уязвимостей рекомендуется следующее:

🍭 Обновить операционную систему
🍭 Отключить CAP_NET_RAW
🍭 Использовать PodSecurityPolicy

Для последнего отлично подойдет Sysdig Secure PSP Advisor, который позволяет «эмулировать» применение политики для идентификации workloads, которые будут подвержены изменениям, что позволяет минимизировать нежелательный эффект (например, нарушение доступности) при применении политик!

Подробности и примеры можно найти по ссылке: https://sysdig.com/blog/cve-2020-14386-falco/

Всем привет! 22 сентября вышла новая версия Prisma Cloud Compute Edition компании Palo Alto Networks. Версия 20.09.345.

Перечень основных изменений:
🍡 Появилась поддержка VMware Tanzu TAS
🍡 Сканирование git-репозиториев на наличие уязвимых компонентов
🍡 Возможность настройки правил для конкретных кластеров (а не только образов, хостов и пр)
🍡 Добавление новых методов аутентификации (OAuth 2.0 and OpenID Connect)
🍡 Расширение функциональности Web Application Firewall (теперь модуль CNAF называется WAAS)

С полным перечнем изменений можно ознакомиться тут.

Всем привет!

Решили у вас спросить, какие посты вы хотели бы видеть в нашем канале DevSecOps Talks, поэтому составили короткий опрос. Собираем ваши мнения 😊

Привет!

Спасибо всем, кто принял участие в нашем опросе. Мы точно будем писать больше про безопасность и про наш практический опыт внедрений, продолжим писать про инструменты DevSecOps. А ещё мы придумали две новых рубрики:

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

📍Во второй поделимся "грабельками", которые мы встречали, и тем, какие выводы мы сделали по итогам.

⁉️Кстати, если у вас есть вопросы, то вы всегда можете их задавать в нашем чатике!

Всем привет!

Отличная новость для пятницы. Совсем скоро, а именно, 12 ноября состоится бесплатная онлайн-конференция ADDO - All Day DevOps. Мероприятие продлится 24 часа и на нем выступят 180 спикеров из разных стран. Перечень тематических блоков и конкретных докладов можно просмотреть на сайте.

Вот примеры того, о чем будут рассказывать:
🍡DevSecOps. Our Secret Management Journey from Code to Vault
🍡DevSecOps. Automated Governance - Building a Compliant by Default Environment
🍡DevSecOps. Embedding Security in your Terraform and Cloudformation Code
🍡Cultural Transformation. Oups already Agile! DevOps Remains
🍡Modern Infrastructure. DevCovidOps - Two Sprints to Production
🍡CI/CD Continuous Everything. Get up to Speed with DevOps using Modern Development Practices
🍡DevSecOps. Kubernetes from an Attacker's Perspective

И это еще не все! Присоединяйтесь, будет интересно!

Всем привет!

По ссылке можно найти результат internship молодого специалиста в компании Appsecco (только у нас ассоциации про смесь Application Security и Prosecco? 🤔), в котором шаг за шагом решаются такие задачи как:

🍭 Создание pipeline для генерации security report для DVNA (дада, еще один damn vulnerable 😂) – использование SAST/DAST, CI/CD – Jenkins
🍭 Создание bill of materials для анализируемого приложения
🍭 «Перенос» наработок с локальной рабочей станции на AWS, отдельное внимание уделяется корректному хранению необходимых секретов
🍭 Использование полученного опыта для анализа следующего приложения – SuiteCRM

Отчет отлично структурирован, в нем есть большое количество строк кода, ссылок на статьи, наработками которых пользовался автор и даже немного верхнеуровневого сравнения open source инструментов!!!

ИТОГО: на наш взгляд это must have для любого специалиста, который хочет углубиться в практики выстраивания secured pipeline – все лаконично, просто и по делу! А вы что думаете?

P.S. Отдельно задумались над вопросом – «А почему у нас по результатам испытательного срока/internship не делают чего то подобного? Это же просто потрясающе!»

P.P.S. У ссылки на отчет не отображается preview, поэтому дублируем еще раз: https://devsecops-pipelines.ayushpriya.tech/