📨 Единый вход: как подружить 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 = [email protected]
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!

👉 Программа
👉Ссылка, если готов сразу купить

Привет, инженеры! 🤘

Сегодня без долгих предисловий — разберем вечную головную боль. Кто-то что-то настроил в 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`).

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

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

✅ Конфигурация: "Автоматический аудит 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"

🧐 Что с этим делать и как использовать?

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" мы такие вещи разбираем на атомы, учимся не только находить, но и эксплуатировать их, чтобы ты мог мыслить как атакующий и строить непробиваемую защиту. Залетай

немного про greenplum от эксперта курса Никиты Целищева, архитектора Data Platform Yandex Cloud

Привет, инженеры!

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

Вы часто спрашиваете: «А что там нового?». Скажу прямо: индустрия летит вперед, и мы вместе с ней. Более 80% контента мы либо обновили с нуля, либо жестко перетряхнули.

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

🔥 Абсолютно новые модули
Смотрите, это не просто теория, а ответы на то, что сейчас болит у бизнеса и девопсов:

🔹Безопасность веб-приложений (OWASP Top 10): Чтобы спать спокойно и не быть тем самым инженером, через которого слили базу.
🔹Прикладной LLM: Хайп хайпом, а понимание, как встроить нейронки в реальный пайплайн — это уже мастхэв.
🔹Kube-prometheus-stack: Весь мониторинг в кубе как на ладони. Настраиваем грамотно.
🔹GitLab CI: Классика, но теперь в самом свежем и правильном виде. Пайплайны, раннеры — всё как надо.
🔹ArgoCD: GitOps победил. Если вы еще не деплоите через Argo, вы либо мазохисты, либо просто еще не видели этот модуль.
🔹EFK (Elasticsearch, Fluentd, Kibana): Логи — это жизнь. Учимся их собирать и читать так, чтобы решать инциденты за минуты.
🔹Teamlead: Софт-скиллы для тех, кто устал быть просто крутым инженером и хочет вести команду за собой.
🔹Starvault: Секреты должны оставаться секретами. Глубокое погружение.

🛠 Глобальные рефакторинги
Мы взяли проверенные временем темы и пересобрали их под современные реалии. Убрали "воду", добавили "мяса":

🔸Ceph: Распределенное хранилище без боли (ну, почти).
🔸 Kafka Admin: Чтобы брокеры летали, а не падали.
🔸RabbitMQ: Очереди для тех, кто понимает толк в асинхронности.
🔸HAProxy: Балансировка на максималках.
🔸Grafana: Красивые дашборды — это половина успеха в инцидент-менеджменте.
🔸Terraform: IaC наше всё. Актуализировали под свежие версии провайдеров.

---

В чем суть?
Мы не заставляем зубрить конфиги. Мы даем понимание *архитектуры*. Как это работает под капотом и зачем это вообще нужно твоему проекту. Теория сразу закрепляется практикой — заходите, ломаете, чините.

Если чувствуешь, что в твоем стеке пробел по этим технологиям — велкам к нашим менеджерам. Они подскажут, с чего лучше начать.

🤝 Чтобы вход был приятнее, сделали скидки (действуют до 27 января включительно):

💰 Одна технология — скидка 3 000 ₽
💰💰 Две технологии — скидка 7 000 ₽
💰💰💰 Три технологии — скидка 15 000 ₽

Не стой на месте. Инженерия — это постоянное движение.

👉 Пиши менеджерам в лс: @rebrain_manager