Инструменты для поиска проблем в докере 💻

На каждом собеседовании заходит речь про докеры. "Что это?", "Как их использовать?", "Зачем нужны?" и самое главное, — "Как из них выходить?". Есть множество способов, которые можно найти на hacktricks, но сегодня разговор зайдет про инструментарий.

Мне, как нынешнему DevSecOps-у удалось потыкать несколько видов развёртывания инструментов в нем. Я сейчас строю процесс на Gitlab Ci\Cd и у его раннера есть возможность работать как в обычном докере, так и в его "улучшенной" версии.

💻 Docker
Возможен запуск с привилегиями (обычно от этого и отталкиваемся)

💻 Docker in docker
Всегда запущен с привилегиями

💻 Kaniko (dind от Google), buildah, umoci, img
Всегда запущен с привилегиями

🔵 Инструменты Automatic Enumeration/Escape

🌐 deepce — Docker Enumeration, Escalation of Privileges and Container Escapes (DEEPCE);
🌐 CDK — инструментарий для проникновения в контейнеры с открытым исходным кодом, предназначенный для обеспечения стабильной эксплуатации в различных тонких контейнерах без зависимости от ОС;
🌐 grype — cканер уязвимостей для образов контейнеров и файловых систем;
🌐 LinPEAS — да, у него есть замечательная функция работы с контейнерами;
🌐 dive — инструмент для изучения образа docker, содержимого слоев и поиска способов уменьшения размера образа Docker/OCI.

#opensource #devsecops #blueteam #redteam

🖼️ Distroless Контейнеры или минимализм ради безопасности и эффективности

В эпоху, когда любой проект зависит от модулей (да-да, log4j тому яркий пример), концепция distroless контейнеров от Google выступает как маяк безопасности. Эти контейнеры, лишенные балласта в виде стандартных инструментов и библиотек операционных систем, представляют собой идеальное сочетание минимализма и функциональности. Но что делает их такими особенными, и почему они становятся неотъемлемой частью современной разработки и кибербезопасности?

🤨 Что это такое

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

🤨 Как это работает

Ключ к созданию distroless контейнера лежит в использовании минимального базового образа, который включает в себя только необходимые библиотеки и зависимости для запуска конкретного приложения. Google предоставляет несколько таких базовых образов через свой проект google/distroless на 💻 GitHub, которые поддерживают языки программирования, такие как Java, Python (применяется в проекте), Go (применяется в проекте), Node.js и другие.

Спасибо @szybnev за рекомендацию

🤨 Что в них такого особенного

🔵 Углубленная Безопасность

Отсутствие shell и лишних утилит сокращает векторы атак, затрудняя эксплуатацию уязвимостей злоумышленниками.

🔵 Эффективность и Производительность

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

🤨 За пределами очевидного

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

🔵 Упрощение CI/CD — Включение в процессы непрерывной интеграции и доставки становится более стройной и эффективной, благодаря сокращению времени сборки и развертывания, что способствует более быстрому циклу разработки.

Разберём на примере 💻 Gitlab CI/CD и 💻 Kubernetes

FROM golang:1.21.4 AS build

WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /bin/app

FROM gcr.io/distroless/base-debian10
COPY --from=build /bin/app /

CMD ["/app"]

❕ Пример использования в gitlab-ci.yml

stages:
  - build
  - deploy

variables:
  # Указываем ваш registry
  DOCKER_IMAGE_NAME: $CI_REGISTRY

build:
  stage: build
  image: docker:19.03.12
  services:
    - docker:19.03.12-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $DOCKER_IMAGE_NAME:$CI_COMMIT_SHA .
    - docker push $DOCKER_IMAGE_NAME:$CI_COMMIT_SHA

deploy:
  stage: deploy
  image: alpine:latest
  script:
    - apk add --no-cache kubectl
    - kubectl config set-cluster default --server=$KUBE_SERVER --certificate-authority=/etc/deploy/ca.pem
    - kubectl config set-credentials default --token=$KUBE_TOKEN
    - kubectl config set-context default --cluster=default --user=default
    - kubectl config use-context default
    # Указываем использование нашего Distroless контейнера
    - kubectl set image deployment/my-deployment my-container=$DOCKER_IMAGE_NAME:$CI_COMMIT_SHA --namespace=my-namespace
  only:
    - main

😜 Заключение

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

#devsecops

💻 Falco и то как его правильно настроить (Часть 2)

Продолжаем тему защиты кубика. Не люблю так оставлять недоделанные посты, но бывает (я помню про вторую часть SBOM-ов, не нужно меня пинать 😬).

На чем мы там остановились? Точно! На конфигурации сервера API.

Как показано ниже, нам нужно создать конфигурационный файл webhook для передачи событий аудита на веб-сервер Falco. На этот файл будет сделана ссылка в конфигурации сервера API. Обязательно замените IP-адрес на кластерный IP-адрес службы Falco в вашей конфигурации. Вы можете получить этот IP-адрес, выполнив команду kubectl get svc -n falco.

apiVersion: v1
kind: Config
clusters:
- name: falco
  cluster:
    server: http://10.110.100.245:9765/k8s-audit
contexts:
- context:
    cluster: falco
    user: ""
  name: default-context
current-context: default-context
preferences: {}
users: []

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

yaml 
- --audit-policy-file=/etc/kubernetes/audit/policy.yaml
- --audit-webhook-config-file=/etc/kubernetes/audit/webhook.yaml
- --audit-log-format=json
volumeMounts:
- mountPath: /etc/kubernetes/audit
  name: audit
volumes:
- hostPath:
    path: /etc/kubernetes/audit
    type: DirectoryOrCreate
  name: audit

⚙️ Добавление правил Falco для Kubernetes

Переходим к самому интересному и важному - к кастомным правилам и как с ними работать.

Каждое правило Falco описывается в YAML-формате и включает в себя несколько ключевых компонентов:

- rule: Имя правила.
- desc: Описание того, что делает правило.
- condition: Условие, при котором срабатывает правило. Это выражение, которое обычно анализирует системные вызовы и их аргументы.
- output: Сообщение, которое будет выведено, когда правило сработает. Может включать переменные из условия.
- priority: Уровень важности (INFO, WARNING, ERROR).

Чтобы Falco использовал кастомные правила, вам нужно указать путь к файлу правил в конфигурационном файле Falco (falco.yaml) или передать его напрямую при запуске Falco через аргумент командной строки.

🔵 Изменение конфигурационного файла

Откройте falco.yaml и найдите раздел rules_file. Добавьте путь к вашему файлу с кастомными правилами:

rules_file:   - /etc/falco/falco_rules.yaml   - /etc/falco/falco_rules.local.yaml   - /etc/falco/custom_rules.yaml  # Путь к вашему файлу с кастомными правилами

🔵 Использование аргумента командной строки:

Вы также можете указать файл правил напрямую при запуске Falco, используя аргумент командной строки -r:

falco -r /path/to/your/custom_rules.yaml

Не забудьте перезапустить Falco после добавления правил 😜

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

#devsecops

🤨 Почему Nuclei можно и нужно использовать как фаззер

Ха, попались, это кликбейт... Хотел бы написать я, но у меня есть действительно интересная тема для дискуссии.

📕 А что мы вообще сейчас хотим видеть от фаззеров?

Если подойти к вопросу максимально просто, то скорость и оптимизация, а ну и чтобы не вылетало. Вот и всё? Однозначно нет, нам нужно покрытие, возобновление работы после прерывания или случайного "нажатия не туда", кастомизация и простота использования (сюда можно было бы добавить AI, но сейчас оно из каждого утюга, вскоре и чебупели мне будет AI подогревать🤗).

А что из этого мы можем получить, используя тот же движок от Burp 😈? Всё, кроме AI и оптимизации (говорим про большие проекты). А ещё он же платный, даже если мы говорим про его "free" dastardly

⚠️ Да начнется холивар

😱 Nuclei — лучший и самый удобный фаззер. Да, но почему это так ? Кластеризация темплейтов, многопоточность 💻, возобновляемые прерывания, интеграция со всеми продуктами ProjectDiscovery (странно было бы если такого не было). Даже открыв исходники Нукли мы можем увидеть то, с чем он может работать:

/pkg/fuzz/component/body.go
/pkg/fuzz/component/cookie.go
/pkg/fuzz/component/headers.go
/pkg/fuzz/component/path.go
/pkg/fuzz/component/query.go
/pkg/fuzz/component/value.go

Мало? Можете дописать сами или закинуть в "хотелки", разрабы помогут и подскажут.

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

❌ Но всё ли так хорошо ?

🙃🥹😘👍

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

katana -u example.com -f qurl -o fuzz_list.txt -hl -nos -jc -jsl

Всё что касается HEADLESS - нужно отдельно настраивать
`-jsl` очень сильно нагружает ОП
В данном примере RATE-LIMIT я не трогал, но он очень хорошо масштабируется

Либо можно использовать немого другой инструмент, но смысл остаётся — ТЫК
Буквально:

git clone https://github.com/0xKayala/NucleiFuzzer.git
cd NucleiFuzzer
sudo chmod +x install.sh
./install.sh
nf -h

Вот у нас есть эндпоинты, сам фаззер, но нет результатов. Что же нам теперь делать? Правильно, устанавливаем темплейты для фаззинга (пора бы свои тоже писать начать. ЭТО ВСЕХ КАСАЕТСЯ!), а также смотрим, как это чудо запускать:

nuclei -t custom-fuzzing-templates -list fuzz_list.txt -dast -im list -irr -je best_fuzzer_result.json

`-fuzz` устарел, поэтому мы используем `-dast`
`-irr` нужен, чтобы мы сохраняли req/res в самом отчете
Во флаге `-im` мы можем указать следующие значения `list`, `burp`, `jsonl`, `yaml`, `openapi`, `swagger`

Нет, я не перехваливаю его, есть же Ffuf — ТЫК, а если его использовать в связке с ffufPostprocessing — ТЫК, то он раскрывается очень хорошо.

После написания поста, нашел улучшенную версию ffufPostprocessing. Самое удивительное, что я даже знаю этого человека reewardius/ffufPostprocessing — ТЫК

❔ Заключение

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

😜 UPD: Обязательно заходите в комментарии к записи, там больше материала ❤️❤️

#redteam #devsecops

💬 Ищем XSS с помощью автоматизации и пропущенного мной инструмента

"Инструменты не способны охватить все точки входа, но мы можем попробовать уменьшить количество уязвимостей или увеличить False positive, кто уж теперь разберётся" — Я 🥺

❔ Немного предыстории

Я разрабатываю инструмент для DAST буквально с 0️⃣. И у меня возникает огромное желание сделать свою версию оркестратора инструментов с корреляцией и фаззерами. Вот и наступил момент, когда могу сказать - "Ну и залез же я в ...пу". И почему же? Сейчас есть огромное количество SCA, SAST-а, а вот с DAST-ом возникают проблемы. У нас есть ZAP, nuclei, и подобные продукты от owasp и project discovery. Но что есть ещё?

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

💻 Dalfox — ТЫК

Да, можете считать, что я "открыл Америку", но мне никто не скидывал его или я где-то его встречал в обиходе (пару постов видел, но в них не было того, как лично мне использовать этот инструмент)

⚙️ Возможности

Искать 🥸😋😋. на этом можно было бы и закончить, но мы такого не допустим. Инструмент написан на 💻, так что пришло время нам покопаться в коде и его способе применения.

ТЫК — вот мы и нашли что можно ему давать на вход 🖥.

Интересующие меня:

go 
type Options struct {
  Data              string  `json:"data"` //rawdata из Burp/ZAP
  UseHeadless       bool    `json:"use-headless"`
  UseDeepDXSS       bool    `json:"use-deepdxss"`
  RemotePayloads    string
  RemoteWordlists   string
  PoCType           string   `json:"poc-type"`
  WAFEvasion        bool     `json:"waf-evasion"`
  HarWriter         *[har]   `json:"har-file-path"`
}             

Эти параметры мы можем использовать для тонкой настройки его движка. Очень заинтересовал модуль WAFEvasion, через какое-то время вернусь к Вам с результатами 🤗

Не реклама, но как пример простого использования подойдет:
shadow_group_tg — ТЫК
shadow_group_tg — ТЫК

🔅Использование в CI/CD

Странно, но даже в их wiki отсутствует запуск в Gitlab CI/CD, исправим, но для начала разберёмся в его режимах работы. "А что тут говорить? Просто пишем `dalfox url https://test.test/` и всё он за нас сделает." — скажет мне любой, кто краем уха слышал про этот инструмент. Но нет, мы используем API и развернем его как сервер dalfox server.🧑‍💻

А вот теперь можно и делайть пайплайн для CI/CD:

image: curlimages/curl:latest

stages:
  - for_test

test_run_dalfox:
  stage: for_test
  script:
    - |
      curl -X POST "$URL_TO_DALFOX" \
      -H "accept: application/json" \
      -H "Content-Type: application/json" \
      -d "{\"url\": \"$URL_TO_SCAN\", \"options\":{\"cookie\": \"$COOKIE_TO_USE\", \"worker\":1}}"
  
 variables:
  URL_TO_DALFOX: "http://localhost:6664/scan" # Замените на нужный URL нашего раннера с dalfox
    URL_TO_SCAN: "https://example.com"  # Замените на нужный URL для скана
    COOKIE_TO_USE: "session=your_session_cookie"  # Замените на нужную cookie

🤨 А что ещё можно искать

Вполне вероятно, что можно и больше, но вот основные пункты:

Storage xss
Reflected xss
Blind xss
DOM xss

В режиме BAV (Basic Another Vulnerability):

SQL Injection
SSTI
Open Redirect
CRLF Injection

✏️ Заключение

Инструмент не нов, но он поддерживается. Написан на Go, кастомизируется и имеет возможность удобно использовать в CI/CD. От себя, однозначно, рекомендую.

#devsecops #redteam

⚠️ Про переоценённую безопасность кластеров или как вы сами даёте новые вектора атак

Подготовка к PHDays, работа, проекты, личная жизнь, Hades 2 забирают у меня почти всё время. Я начал замечать, что перестал пить воду, потому что забываю. Думаю, к лету будет проще дарить вам не только смех с мемов, но также продолжить заставлять ваш мозг работать.

🤨 Про что сегодня поговорим

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

❕ Сначала про eBPF

eBPF (extended Berkeley Packet Filter) — это технология в ядре Linux, которая позволяет выполнять безопасный, изолированный код внутри ядра, не изменяя его исходники или загружая модули. eBPF изначально был разработан для фильтрации пакетов, но его возможности значительно расширились со временем и теперь он умеет в:

➖ Сетевой мониторинг и фильтрацию;
➖ Трассировку и отладку системы;
➖ Мониторинг приложений;
➖ Предотвращение атак.

eBPF позволяет писать программы, которые могут перехватывать и анализировать события в ядре Linux, что делает его идеальным инструментом для задач безопасности и мониторинга (либо слежки, но про это мы тут не говорим🥺). Некая грань между стандартными безопасниками и соковцами (может пора их начать записывать в отдельную категорию? 👮‍♂️)

Знакомьтесь, ваш новый папа — Tetragon

💻 Ссылка — ТЫК

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

Да, не зря упоминал про eBPF 🤗

😜 Основные возможности Tetragon

Всё то, что и так все знают, но немного больше.

💩 Мониторинг событий в реальном времени

💩 Политики безопасности
"Ага, поверил... Ну и бредятина!" — Шрек понимает меня. А теперь о том, как его использовать так, чтобы было интересно.

✅ Блокируем легитимные вызовы

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

apiVersion: cilium.io/v2
kind: TetragonPolicy
metadata:
  name: block-kaspersky
spec:
  policyName: "Block Kaspersky Processes"
  policy: |
    trace:
      - syscalls:
          matchArgs:
            - name: "execve"
              args:
                - index: 0
                  value: "/opt/kaspersky/kesl/bin/kesl"
          action: "deny"
      - syscalls:
          matchArgs:
            - name: "execve"
              args:
                - index: 0
                  value: "/opt/kaspersky/kesl/bin/kesl-supervisor"
          action: "deny"

😑 А что ещё можем?
Места в посте нет, но вы держитесь. Я могу отдельно написать и выложить правила.

➖ Обход существующих политик безопасности (политика позволяющая обойти политики)
➖ Саботаж системных процессов (может кто-то помнит мультик "Валиант" — теперь мы та самая мышь)
➖ Кража учетных данных (ssh делает бррррр)

💬 Итоги поста

Ну вот, вы только что узнали о Tetragon — инструменте, который, вероятно, знает о вашем кластере больше, чем вы сами (а может и не только о кластере, но и о вас 😈). Да, потому что мониторинг в реальном времени, отслеживание системных вызовов и контроль сетевых соединений — это, конечно, то, о чем вы всегда мечтали. Забудьте о спокойных ночах и расслабленных выходных, теперь вы будете наслаждаться бесконечными отчетами и политиками безопасности. Впрочем, что ещё делать людям из SOC-а.

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

Думайте, прежде чем ставить)
#devsecops #blueteam #redteam #бредниавтора

Ну что, готовы к крутой лекции по безопасности k8s от отца контейнеров @aleksey0xffd? OWASP k8s TOP 10, RBAC, security context для pod и контейнеров в нем, аутентификация и авторизация, безопасная конфигурация workloads, секреты, сегментация сети внутри кубера и многое другое.

В общем, вся база всего за час, а не за 10, как у практически всех площадок онлайн-образования. Смотрим, впитываем, образовываемся – ютуб и рутуб.

#BaseSecurity #DevSecOps

🧠 Твой Пакет Знаний

Харденинг

Есть такая область безопасности и ДевОпса под названием харденинг. Если коротко, то с помощью этого подхода можно обеспечить дополнительную безопасность чего-угодно (сервера, сети, БД, ОС) за счет уменьшения поверхности атаки = заколачивания окон досками.

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

⚙ Целый сборник харденинг-годноты – раз и два
⚙ Чеклисты по харденингу всего и вся – ссылка

#BaseSecurity #DevSecOps #Network

🧠 Твой Пакет Знаний | 🛍 Другие каналы

Настало время уязвимостей

Что-то модно (как уязвимости Next.js и GraphQL), что-то вышло из моды (как уязвимости для Adobe Flash Player), а что-то вечно (привет, Битрикс).

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

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

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

Ну а вот и эти платформы-агрегаторы 👇

📂 CVE Crowd – один из самых популярных сервисов

📂 CVE Shield – один из самых старых агрегаторов

📂 Vulmon Vulnerability Trends – хороший агрегатор с историей за прошлые дни

📂 CVE Trends – топ10 обсуждаемых в интернетах уязвимостей за сутки

📂 Vulners – целый портал кибербезопасных инфоповодов, включая эксплойты, безопасность AI, BugBounty и прочее

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

#BaseSecurity #AppSec #DevSecOps #Pentest

🧠 Твой Пакет Знаний | 🛍 Другие каналы

🛠IngressNightmare или как снова что-то нашли

Всем привет, и да, я снова тут с постом, который никто особо не ждал, ведь выше есть пост, но пройти мимо такой темы я не смог. Сегодня расскажу более подробно про свежий и крайне неприятный инцидент в Kubernetes-мире.

❓Что стряслось и почему все в панике

Короче, ребята из Wiz недавно нашли серию критических уязвимостей в контроллере Ingress-NGINX для Kubernetes. Назвали это всё красиво и драматично – IngressNightmare. И поверьте, название выбрали неспроста: если коротко, то это пять CVE, из-за которых атакующий может спокойно выполнить код на ingress-контроллере и буквально угнать весь кластер со всеми секретами. И самое весёлое, что атакующему даже не нужны учётные записи или пароли, хватит одного кривого HTTP-запроса.

🔍 Технические подробности для тех, кто любит копаться в кишках

Суть этих уязвимостей кроется в недостаточной проверке входящих данных, которые разработчики Ingress-NGINX радостно вставляли напрямую в конфиги NGINX. Из-за этого через безобидные, казалось бы, аннотации (auth-url, auth-tls-match-cn, mirror-target) можно было внедрить произвольные директивы. Ну, например, какую-нибудь такую прелесть:

ssl_engine /tmp/malicious.so;

Именно это использовали исследователи Wiz в своём PoC. Ты просто отправляешь HTTP-запрос с большим телом, NGINX сохраняет это тело как временный файл, а потом через специальный AdmissionReview-запрос (без аутентификации!) загружает твою вредоносную .so библиотеку. И всё, поздравляю, теперь ты внутри контейнера с контроллером. Дальше читаешь секреты, токены и вообще делаешь, что хочешь.

‼️ Кто в опасности и как проверить себя любимого

Если ваша версия Ingress-NGINX ниже v1.12.1 (а ещё 1.11.5 и 1.10.7), то у вас серьёзные проблемы:
🔵 Узнать текущую версию можно через:

kubectl -n ingress-nginx get deploy ingress-nginx-controller -o=jsonpath='{.spec.template.spec.containers[0].image}'

🔵 Или через GitLab, найдя в манифестах YAML или Helm-чартах строку:

image: ingress-nginx/controller:v1.12.0

❔ Как с этим жить дальше

Что делать, если вы попали в этот клуб неудачников с уязвимой версией:

1. Срочно обновляйтесь до v1.12.1;

2. Пока не обновились, отключите admission-контроллер (controller.admissionWebhooks.enabled=false);

3. Ограничьте доступ к admission webhook с помощью Network Policy. Только API-сервер должен туда стучаться;

4. Просмотрите audit-логи Kubernetes и ищите подозрительные Ingress’ы с странными аннотациями.

Если вы не можете обновиться сразу (а кто из нас может?), хотя бы проверьте, что webhook не светит в интернет. В Wiz уже подсчитали, что около 6500 кластеров с открытым admission webhook доступны снаружи. Возможно, среди них есть и ваш.

👀 Личное мнение и мораль сей басни

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

Спасибо, что дочитали мой очередной маленький монолог. Обещаю, скоро вернусь с чем-нибудь менее трагичным.

#devsecops #appsec

Сегодня у нас чтиво о защите периметра сети - Архитектура защищённости сетей.

В данной книге разбираются такие типы СЗИ как NGFW, Email Security, WAF и Sandbox. Список самих обозреваемых решений довольно большой, начиная от циски и майкрософта, заканчивая нашими решениями от PT, Usergate и т.д.

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

#AppSec #DevSecOps #SecArch

🧠 Пакет Знаний | 👨‍🏫 Менторство
📂 Другие каналы

Делимся большой картой с сертификатами в ИБ.

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

Сами сертификаты можно фильтровать по стоимости, вендорам и специальностям. И ещё тут есть фича сравнения сертификатов по ключевым параметрам.

Цель на жизнь поставлена, можно начинать собирать.

#AppSec #Pentest #DevSecOps #SecArch #SOC

🧠 Пакет Знаний | 👨‍🏫 Менторство
📂 Другие каналы