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

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