DevOps by REBRAIN

Привет!🤘 Кратко о граблях, на которые наступают даже профи. Нужно дать скрипту права root. Кажется, что это просто:

# ⛔️ ОШИБКА, НЕ ДЕЛАЙ ТАК!
sudo chown root my_tool.sh
sudo chmod u+s my_tool.sh

Эта команда ставит SUID`-бит, который должен запускать файл с правами владельца (`root`). Но с скриптами (.sh`, .py`) это не работает — ядро Linux игнорирует `SUID для них из соображений безопасности. Хуже того, это создает ложное чувство защиты и открывает двери для атаки Path Injection. Как `root`-скрипт отдает тебе систему Представь, у тебя есть скрипт, который запускается через sudo и содержит вызов системной команды без полного пути: victim_script.sh

#!/bin/bash
# ...какой-то код...
# Вот уязвимость:
ps aux
# ...

Атакующий делает три простых шага: 1️⃣ Создает свой `ps`:

    # Этот "ps" на самом деле запускает шелл
    echo '/bin/bash' > /home/attacker/ps
    chmod +x /home/attacker/ps
    

2️⃣ Добавляет свою папку в `PATH`:

    export PATH=/home/attacker:$PATH
    

Теперь его папка в приоритете для поиска команд. 3️⃣ Запускает твой скрипт:

    sudo /path/to/victim_script.sh
    

Скрипт попытается выполнить ps, найдет вредоносный файл атакующего и запустит его с правами root. Игра окончена, система захвачена. Как делать правильно и безопасно Всего два железных правила, которые спасут твою инфраструктуру: 1️⃣ Всегда указывай полные пути к исполняемым файлам в своих скриптах: /bin/ps, /usr/bin/systemctl и т.д. 2️⃣ Используй `sudoers` для выдачи прав. Это единственный контролируемый способ. Создай файл /etc/sudoers.d/developers:

# Дать право запускать ТОЛЬКО один конкретный скрипт без пароля
developer ALL=(root) NOPASSWD: /usr/local/bin/my_awesome_tool.sh

Это безопасно, логируется и полностью под твоим контролем. --- Знание таких основ — это фундамент. Чтобы видеть все векторы атак, от sudo и SUID до эксплойтов ядра, и уметь им противостоять, нужно мыслить как атакующий. Именно этому мы учим на нашем практикуме "Повышение привилегий в Linux". Только хардкор, только практика на стендах. 🚀 Старт курса уже 26 января! Успей запрыгнуть, чтобы стать на голову выше в понимании Linux. 🤘Записаться на курс --- P.S. Мы хотим постить прямые ссылки на самые сочные материалы в сторис, но для этого Телеграм просит "бусты". Если наши посты тебе полезны, поддержи канал своим голосом! Это быстро и бесплатно. 🚀 Бустануть канал Rebrain Спасибо! 💪

❗ Открытый практикум Free Range Routing (FRR): управление статической и динамической маршрутизацией в Linux идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/330 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума Free Range Routing (FRR): управление статической и динамической маршрутизацией в Linux уже через 5 минут Встречаемся в 19:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/330 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

Открытый практикум Free Range Routing (FRR): управление статической и динамической маршрутизацией в Linux начнётся сегодня в 19:00 МСК. Практикум будет проходить на площадке Zoom.US Важно!!! Чтобы вы смогли без проблем к нам присоединиться, заранее протестируйте комнату по ссылке: https://zoom.us/test Ссылку для доступа отправим вам за 5 минут до начала. Либо заходите через личный кабинет в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

немного про greenplum от эксперта курса Никиты Целищева

🗓️ Расписание вебинаров на сегодня ⏰ 19:00 МСК - Free Range Routing (FRR): управление статической и динамической маршрутизацией в Linux 🔗 Регистрация и программа О вебинаре напомним за 5 минут до начала на этом канале. Также вы сможете зайти через личный кабинет. 🔥 Задать вопросы и обсудить детали можно в нашем чате

🔥 Сломали голову над медленными запросами? Учитесь оптимизировать Greenplum у тех, кто его создаёт. Давайте разберём одну из самых частых и болезненных проблем в распределённых базах данных: запросы внезапно начинают выполняться часами при росте данных. Частая причина — неправильная дистрибуция (распределение) таблиц в Greenplum, из-за которой система тратит львиную долю времени не на вычисления, а на пересылку данных между узлами. Суть проблемы: Допустим, у вас две таблицы — sales и products. Они распределены по разным ключам или случайно.

Сегмент 1: sales {A, C, E}, products {A, D}
Сегмент 2: sales {B, D, F}, products {B, C}

➡️ При join по product_id системе придётся "гонять" почти все строки между серверами (reshuffle). Это и есть главный тормоз. Как это выглядит в коде (проблемный вариант):

-- Таблицы созданы без общей стратегии дистрибуции
CREATE TABLE sales (sale_id bigint, product_id int, amount decimal)
DISTRIBUTED RANDOMLY; -- или DISTRIBUTED BY (sale_id)

CREATE TABLE products (product_id int, name text)
DISTRIBUTED BY (product_id);

💡Решение — контроль дистрибуции от создателей технологии: Эксперты Yandex Cloud покажут, как проектировать схему с самого начала, чтобы соединения работали локально.

-- Правильная дистрибуция по общему ключу соединения
CREATE TABLE sales_opt (sale_id bigint, product_id int, amount decimal)
DISTRIBUTED BY (product_id); -- Теперь product_id совпадает с products!

CREATE TABLE products (product_id int, name text)
DISTRIBUTED BY (product_id);

Результат: Данные с одинаковым product_id лежат на одном сегменте. Join выполняется локально, ускоряясь в десятки раз. 🎯 Где вы научитесь такому подходу? Только на курсе, разработанном и проводимом командой Yandex Cloud. Это не просто теория. Это официальная программа от Yandex Cloud, где: 🔹 Все практические работы выполняются на реальных инструментах Yandex Cloud — в сервисе Yandex MPP Analytics for PostgreSQL. 🔹Вы учитесь на кейсах и best practices, которые используют разработчики этой облачной платформы. 🔹Формат этой когорты — гибридный для максимального результата: 🔹Гибкий график: Теорию и задачи проходите в удобное время. 🔹Синхронные вебинары с экспертом Yandex Cloud: Онлайн-встречи привязаны к программе, чтобы разбирать сложные моменты и давать обратную связь. Держите ритм, чтобы не отстать! Вебинары проведёт Никита Целищев — эксперт по Big Data из команды Yandex Cloud, который ежедневно работает с сервисом Yandex MPP Analytics и знает все тонкости оптимизации изнутри. 🚀 Хотите не просто использовать Greenplum, а понимать его архитектуру и выжимать максимум производительности? Записывайтесь на курс "Greenplum в Yandex MPP Analytics for PostgreSQL" от создателей и главных экспертов по облачной платформе. 👉 Подробнее о курсе и программе: https://rebrainme.com/courses/greenplum 💳 Оплатить по специальной цене: 55000 38 500 руб. (до 22 января включительно)

📊DataLens On-Premises: Настройка как у Яндекс Облака. Прямой перевод опыта команды-разработчика Внедряете или администрируете корпоративный DataLens? Команда Yandex Cloud систематизировала свой опыт и создала единственный на рынке курс по промышленному администрированию On-Premises-версии. Почему это эталонный подход? 1️⃣ В основе курса — реальные инструменты, инфраструктура и методологии Yandex Cloud. Вы не изучаете абстрактные кейсы, а работаете в среде, на которой построен сам сервис. Это гарантирует, что вы учитесь на актуальных и проверенных практиках. 2️⃣ Разберём на примере. Одна из ключевых задач — настройка централизованного сбора логов Usage Tracking во внешний ClickHouse для аудита и анализа поведения пользователей. Как это решается в инфраструктуре Yandex Cloud (упрощённо): 1️⃣Подготовка Managed ClickHouse в облаке или на выделенных хостах. 2️⃣Конфигурация DataLens через Helm-чарт с указанием внешнего кластера:

# Фрагмент values.yaml, основанный на практике YC
usageTracking:
  enabled: true
  exporter: clickhouse
  clickhouse:
    hosts:
      - rc1a-xxxxxx.mdb.yandexcloud.net:9440
    database: datalens_logs
    table: usage_events
    user: tracker
    tls_mode: REQUIRE

3️⃣Верификация потока данных: логи из подов DataLens начинают поступать в ваше управляемое хранилище, где их можно анализировать с помощью SQL. Архитектурная схема решения: DataLens Pods (K8s) → [Secure TLS Channel] → Yandex Managed ClickHouse → Ваши SQL-отчёты 💡Где научиться всему циклу работ от первоисточника? Приглашаем на практический курс «Администрирование DataLens On‑Premises», который полностью разработан и проводится экспертами Yandex Cloud. Ваши главные преимущества: 🔹Курс от создателей: Программа создана командой Yandex Cloud и отражает внутренние стандарты развёртывания и настройки. 🔹Инструменты от первого лица: Все практические работы вы выполняете в инфраструктуре Yandex Cloud, используя те же сервисы и подходы. 🔹Эксперт-наставник из Яндекс Облака: Онлайн-вебинары ведёт Глеб Белов, Senior Solutions Architect в Yandex Cloud, который непосредственно помогает крупным клиентам внедрять DataLens Enterprise. Формат: Гибридный. Теорию и задачи в LMS проходите в удобном темпе, а на вебинарах с Глебом разбираете сложные моменты и перенимаете экспертный опыт. 🚀 Специальное предложение до 22 января: 💳 Оплатить со скидкой 30% (38 500 руб. вместо 55 000 руб.) Научитесь администрировать DataLens у команды, которая его создаёт и развивает.

🧐 Что с этим делать и как использовать? 1. Сохрани скрипт: Назови его audit_scheduler.sh, дай права на выполнение (`chmod +x`). 2. Запускай от `root`: Для полноценного анализа нужны права. Скрипт соберет инфу из системных и пользовательских crontab, а также из systemd. 3. Интегрируй в автоматизацию: * Ansible/Salt/Chef: Добавь запуск этого скрипта в плейбук регулярного аудита. * CI/CD: Прогоняй скрипт на "золотых" образах (AMI, Docker-образах), чтобы не допустить дыры в продакшен. * В самом Cron: Да, можно и так, но с умом. Настрой запуск раз в неделю и отправку отчета в почту или мессенджер. 4. Анализируй отчет: Скрипт не панацея, он ищет потенциальные проблемы. Твоя задача — посмотреть на CRITICAL и HIGH и понять, реальная ли это угроза в твоем контексте. 5. Исправляй: * chmod 755 /path/to/script.sh и chown root:root /path/to/script.sh. * Перепиши команды в кроне, чтобы избежать wildcard: tar cf /backup/$(date +%F).tar /data/www вместо tar cf /backup/my.tar *. * Наведи порядок в правах на systemd юниты. Хватит работать вслепую. Автоматизируй защиту так же, как и деплой. Это и есть DevOps-подход. 🚀 На нашем курсе "Повышение привилегий в Linux" мы такие вещи разбираем на атомы, учимся не только находить, но и эксплуатировать их, чтобы ты мог мыслить как атакующий и строить непробиваемую защиту. Залетай

✅ Конфигурация: "Автоматический аудит cron и systemd"

#!/bin/bash
# audit_scheduler.sh - Улучшенный скрипт для аудита cron и systemd

REPORT_FILE="/var/log/security_audit_$(hostname)_$(date +%F).log"
# Чистим старый лог или начинаем новый
> "$REPORT_FILE"

log_finding() {
    local level="$1"
    local message="$2"
    echo "[${level}] - $(date +'%Y-%m-%d %T') - ${message}" | tee -a "$REPORT_FILE"
}

log_finding "INFO" "Начало аудита безопасности на хосте $(hostname)"

# --- ПРОВЕРКА CRON ---

log_finding "INFO" "Анализ cron-задач..."

# Объединяем все известные места с cron-задачами в один список для анализа
ALL_CRONS=$(mktemp)
(cat /etc/crontab; find /etc/cron.* -type f -exec cat {} +; for user in $(cut -d: -f1 /etc/passwd); do crontab -u "$user" -l 2>/dev/null; done) | grep -v '^\s*#' | grep -v '^\s*$' > "$ALL_CRONS"

# Проверка 1: Скрипты, доступные на запись ВСЕМ (World-writable)
log_finding "INFO" "Поиск скриптов, доступных на запись для всех (world-writable)..."
# Извлекаем путь к исполняемому файлу (более надежный способ)
cut -d ' ' -f 6- "$ALL_CRONS" | tr ' ' '\n' | grep '^/' | sort -u | while read -r cmd_path; do
    [ ! -f "$cmd_path" ] && continue
    # Находим файлы, у которых есть право на запись для 'other'
    if stat -c "%a" "$cmd_path" | grep -qE '.[0-7][2367]$'; then
        log_finding "CRITICAL" "Cron-скрипт '$cmd_path' доступен для записи всем! Права: $(stat -c '%a' "$cmd_path")"
    fi
done

# Проверка 2: Директории в $PATH, доступные на запись (Path Hijacking)
log_finding "INFO" "Поиск директорий в $PATH, доступных для записи..."
echo "$PATH" | tr ':' '\n' | while read -r dir; do
    [ ! -d "$dir" ] && continue
    if stat -c "%a" "$dir" | grep -qE '.[0-7][2367]$'; then
        log_finding "HIGH" "Директория '$dir' из \$PATH доступна для записи всем. Возможна атака Path Hijacking."
    fi
done


# Проверка 3: Wildcard Injection в популярных командах (tar, rsync, chown)
log_finding "INFO" "Поиск потенциально уязвимых wildcard'ов..."
if grep -E '(tar|rsync|chown).*\s+\*' "$ALL_CRONS"; then
    log_finding "WARNING" "Найдено использование wildcard (*) в cron. Проверьте вручную на уязвимость Wildcard Injection:"
    grep -nE '(tar|rsync|chown).*\s+\*' "$ALL_CRONS" | sed 's/^/  Line /' | tee -a "$REPORT_FILE"
fi

rm "$ALL_CRONS"

# --- ПРОВЕРКА SYSTEMD ---

log_finding "INFO" "Анализ systemd-юнитов..."
find /etc/systemd/system /usr/lib/systemd/system -name "*.service" -type f | while read -r unit_file; do
    # Проверяем, что сам .service файл доступен на запись кому-то кроме root
    if [ "$(stat -c '%U' "$unit_file")" != "root" ] || stat -c "%a" "$unit_file" | grep -qE '.[0-7][2367]$'; then
         log_finding "CRITICAL" "Systemd unit '$unit_file' имеет слабые права доступа: $(stat -c '%a (%U:%G)' "$unit_file")"
    fi
    # Ищем путь к исполняемому файлу и проверяем его права
    exec_start=$(grep -oP 'ExecStart=\K.*' "$unit_file" | awk '{print $1}')
    if [[ -n "$exec_start" && -f "$exec_start" ]]; then
       if stat -c "%a" "$exec_start" | grep -qE '.[0-7][2367]$'; then
            log_finding "HIGH" "Бинарник '$exec_start' из юнита '$unit_file' доступен на запись всем!"
       fi
    fi
done


log_finding "INFO" "Аудит завершен. Отчет сохранен в $REPORT_FILE"
echo "---"
echo "Аудит завершен. Найденные проблемы уровня CRITICAL/HIGH:"
grep -E '\[CRITICAL\]|\[HIGH\]' "$REPORT_FILE"

Привет, инженеры! 🤘 Сегодня без долгих предисловий — разберем вечную головную боль. Кто-то что-то настроил в cron или systemd на сервере, а ты теперь думай — не завезли ли нам бэкдор? Руками проверять 100500 серверов — гиблое дело. Давайте автоматизируем! Сделаем скрипт для аудита, который будет искать за нас дыры в планировщиках. Но не спеши просто копипастить. Сначала разберем, как НЕ надо делать. Вот пример логики из "быстрого решения", которое можно найти в сети:

# ⛔️ ПЛОХОЙ ПРИМЕР, НЕ ИСПОЛЬЗОВАТЬ! ⛔️

# Ищем скрипты
cmd_list=$(cat /etc/crontab | awk '{print $6}')

# Проверяем, доступны ли они на запись
for script in $cmd_list; do
  if [ -w "$script" ]; then
    echo "УЯЗВИМОСТЬ: $script доступен на запись!"
  fi
done

🔥 Разбор полетов: почему это не работает? 1. Хрупкий парсинг: awk '{print $6}' сработает только для идеально отформатированного crontab из 6 полей. Забыли переменную? MAILTO=... — и всё, парсер поехал. @reboot? Тоже мимо. Команда из нескольких слов? Возьмется только первое. 2. Неверная проверка прав: if [ -w "$script" ], запущенный от root, всегда скажет true для файлов, принадлежащих root. Скрипт будет кричать об уязвимости почти на каждый системный файл, создавая тонны шума. Проверять нужно права для *других* пользователей (`group` и `other`). 3. Поверхностный поиск: Скрипт не проверяет права на *директорию*, где лежит скрипт (атака Path Hijacking), не ищет уязвимости с wildcard (*) и полностью игнорирует пользовательские кронтабы (`crontab -e`). Итог: такой аудит бесполезен. Он либо ничего не найдет, либо утопит тебя в ложных срабатываниях. А теперь, как надо. Собираем более надежный и умный скрипт, который учитывает эти нюансы.

📨 Единый вход: как подружить Dovecot и базу данных приложения Знакомая боль: есть веб-проект (SaaS, админка, корпоративный портал) с базой пользователей в PostgreSQL. Задача — дать им почту. Плохой путь: Создавать системных юзеров в Linux или писать скрипты, которые по крону синхронизируют табличку пользователей с файлом паролей. Это костыли, рассинхрон и дыры в безопасности. Правильный путь: Научить Dovecot ходить прямо в базу вашего приложения. Это дает Single Source of Truth: сменил пароль в вебе — он тут же сменился в почте. Забанили юзера в админке — почта тоже отвалилась. Ниже — рабочая конфигурация, которую можно адаптировать под любой проект. Погнали настраивать. 1️⃣ Готовим базу данных Предполагаем, что таблица юзеров app_users уже есть. Добавим поля для почты. В идеале лучше сделать VIEW, чтобы не мусорить в основной таблице, но для примера добавим колонки напрямую:

ALTER TABLE app_users
ADD COLUMN IF NOT EXISTS email_enabled BOOLEAN DEFAULT TRUE,
ADD COLUMN IF NOT EXISTS quota_mb BIGINT DEFAULT 1024; -- Квота 1Гб

-- Важно: Пароль должен лежать не текстом, а хэшем (например, ARGON2ID или SHA512-CRYPT), который понимает Dovecot.

2️⃣ Создаем системного "почтальона" Dovecot не должен работать от root. Ему нужен один технический юзер, который будет владеть всеми файлами писем.

# Создаем группу и юзера vmail с uid/gid 5000
groupadd -g 5000 vmail
useradd -g vmail -u 5000 -d /var/vmail -m -s /usr/sbin/nologin vmail

3️⃣ Настраиваем Dovecot Идем в /etc/dovecot/conf.d/. Файл `10-auth.conf` Отключаем системных юзеров и включаем SQL:

# !include auth-system.conf.ext  <-- Комментируем это!
!include auth-sql.conf.ext       <-- Раскомментируем это

Файл `auth-sql.conf.ext` Говорим Dovecot, где искать правила:

passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}

Файл `dovecot-sql.conf.ext` (Самое мясо) Здесь мы мапим данные из SQL в переменные Dovecot.

driver = pgsql
# Создайте отдельного юзера в БД с правами ТОЛЬКО на SELECT!
connect = host=127.0.0.1 dbname=mydb user=dovecot_user password=secure_pass

# Схема паролей по умолчанию
default_pass_scheme = ARGON2ID

# Запрос для проверки пароля (PassDB).
# %u = user@domain.com
password_query = \
  SELECT username as user, password \
  FROM app_users WHERE username = '%u' AND email_enabled = 't'

# Запрос данных пользователя (UserDB).
# Возвращаем UID/GID нашего юзера vmail (5000) и путь к ящику.
# home - где лежат индексы, mail - где лежат письма
user_query = \
  SELECT '/var/vmail/%d/%n' as home, \
         'maildir:/var/vmail/%d/%n' as mail, \
         5000 as uid, 5000 as gid, \
         concat('*:storage=', quota_mb, 'M') as quota_rule \
  FROM app_users WHERE username = '%u' AND email_enabled = 't'

В чем подвох? 1. Нагрузка: Каждый логин (даже проверка почты телефоном в фоне) — это запрос в БД. Если у вас 10k юзеров, базе может стать плохо. Решение: кэширование в Dovecot или пулеры соединений. 2. Безопасность: Если вашу базу "уведут", утекут и почтовые креды. Ограничивайте права SQL-юзера Dovecot’а. --- 💡 Это — база. Но почтовый сервер — это не только userdb. Это еще TLS, антиспам, Sieve-фильтры, LMTP-доставка и бэкапы, которые реально восстанавливаются. Хочешь разобраться, как построить production-grade почтовую систему, а не просто скопипастить конфиг? Залетай. 🔥 Курс «Dovecot: настройка и эксплуатация почтовых систем» Что внутри: * Полная архитектура (MTA, MDA, LMTP). * Интеграция не только с SQL, но и с LDAP/AD. * Безопасность (SSL/TLS, защита от брутфорса). * Траблшутинг (doveadm, логи, дебаг). 🗓 Старт: 26 января 💰 Цена: 22 000 руб. (до 25 января), потом — 25 000 руб. Не копи технический долг, учись строить системы правильно с Rebrain! 👉 Программа 👉Ссылка, если готов сразу купить

❗ Открытый практикум Legacy в 2026 году. Как жить, мигрировать и не сойти с ума идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/329 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума Legacy в 2026 году. Как жить, мигрировать и не сойти с ума уже через 5 минут Встречаемся в 19:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/329 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате