Привет! 👋
Сегодня поговорим про классику жанра, на которой обжигаются даже опытные админы. Тема — безопасность в Linux, а точнее — Sudo Rights Abuse.
Мы часто привыкли думать, что sudo — это волшебная палочка, которая просто дает права. Ну, прописал джуну в /etc/sudoers доступ к одной команде, чтобы он мог логи почитать или конфиг поправить, и спишь спокойно. Пароль от рута же не дал, верно?
А вот и нет. 🙅♂️ Чаще всего это равносильно тому, что ты просто отдал ключи от квартиры, где деньги лежат.
💡 В чем соль?
Существует огромный класс бинарников, которые ведут себя вполне легитимно, но если запустить их через sudo, они позволяют «сбежать» из своего контекста и запустить системную оболочку (/bin/sh или /bin/bash). А так как родительский процесс был запущен от рута, то и шелл ты получаешь рутовый.
Эта концепция называется🔥 GTFOBins (Get The F*ck Out Binaries).
Давайте к практике. Сразу предупреждаю: тестируем только на своих виртуалках!
Пример 1️⃣: "Безобидный" Vim
Представь, ты дал разработчику право редактировать конфиг Nginx через sudo vim.
Разработчик заходит на сервер и делает так:
Всё. Он в системе под root.
Почему так работает? Vim умеет выполнять системные команды прямо из редактора. Если Vim запущен от рута, то и команда :!/bin/sh стартует от рута.
Пример 2️⃣: Утилита Find
Казалось бы, find — просто поиск файлов. Часто дают права на sudo find, чтобы искать логи или бэкапы по всей системе.
Смотрим трюк:
Флаг -exec позволяет выполнить любую команду для найденного файла. Мы просто просим выполнить шелл. И снова — привет, root. 👑
Как защититься?
1. Понимать инструмент: Прежде чем давать sudo на бинарник, загляни на [GTFOBins](https://gtfobins.github.io/) и проверь, есть ли он в списке " Shell Escape".
2. Ограничивать аргументы: В sudoers можно прописывать не просто путь к бинарнику, а конкретные аргументы, чтобы нельзя было вписать лишнее.
3. Использовать `NOEXEC`: В новых версиях sudo есть опция noexec, которая мешает запускать дочерние процессы, но она работает не со всеми программами.
---
Это — лишь верхушка айсберга. Повышение привилегий (Privilege Escalation) — это целое искусство. Нужно не просто знать трюки, а понимать, как ядро работает с памятью, как устроены права доступа, SUID биты, Capabilities и как все это можно повернуть в свою пользу (или защитить).
Мы собрали мощный курс "Повышение привилегий в Linux", где разбираем всё: от сбора информации и эксплойтов ядра до закрепления в системе. Без воды, только хардкор и практика.
Программу курса можно посмотреть тут👈
Если хочешь перестать бояться терминала и начать понимать Linux на уровне бога — тебе сюда 🤑купить курс 🤑 до 25 января самая выгодная цена 22 000 рублей.
Залетай, будем делать из тебя инженера! 🚀
Сегодня поговорим про классику жанра, на которой обжигаются даже опытные админы. Тема — безопасность в Linux, а точнее — Sudo Rights Abuse.
Мы часто привыкли думать, что sudo — это волшебная палочка, которая просто дает права. Ну, прописал джуну в /etc/sudoers доступ к одной команде, чтобы он мог логи почитать или конфиг поправить, и спишь спокойно. Пароль от рута же не дал, верно?
А вот и нет. 🙅♂️ Чаще всего это равносильно тому, что ты просто отдал ключи от квартиры, где деньги лежат.
Существует огромный класс бинарников, которые ведут себя вполне легитимно, но если запустить их через sudo, они позволяют «сбежать» из своего контекста и запустить системную оболочку (/bin/sh или /bin/bash). А так как родительский процесс был запущен от рута, то и шелл ты получаешь рутовый.
Эта концепция называется
Давайте к практике. Сразу предупреждаю: тестируем только на своих виртуалках!
Пример 1️⃣: "Безобидный" Vim
Представь, ты дал разработчику право редактировать конфиг Nginx через sudo vim.
Разработчик заходит на сервер и делает так:
sudo vim -c ':!/bin/sh'
Всё. Он в системе под root.
Почему так работает? Vim умеет выполнять системные команды прямо из редактора. Если Vim запущен от рута, то и команда :!/bin/sh стартует от рута.
Пример 2️⃣: Утилита Find
Казалось бы, find — просто поиск файлов. Часто дают права на sudo find, чтобы искать логи или бэкапы по всей системе.
Смотрим трюк:
sudo find . -exec /bin/sh \; -quit
Флаг -exec позволяет выполнить любую команду для найденного файла. Мы просто просим выполнить шелл. И снова — привет, root. 👑
Как защититься?
1. Понимать инструмент: Прежде чем давать sudo на бинарник, загляни на [GTFOBins](https://gtfobins.github.io/) и проверь, есть ли он в списке " Shell Escape".
2. Ограничивать аргументы: В sudoers можно прописывать не просто путь к бинарнику, а конкретные аргументы, чтобы нельзя было вписать лишнее.
3. Использовать `NOEXEC`: В новых версиях sudo есть опция noexec, которая мешает запускать дочерние процессы, но она работает не со всеми программами.
---
Это — лишь верхушка айсберга. Повышение привилегий (Privilege Escalation) — это целое искусство. Нужно не просто знать трюки, а понимать, как ядро работает с памятью, как устроены права доступа, SUID биты, Capabilities и как все это можно повернуть в свою пользу (или защитить).
Мы собрали мощный курс "Повышение привилегий в Linux", где разбираем всё: от сбора информации и эксплойтов ядра до закрепления в системе. Без воды, только хардкор и практика.
Программу курса можно посмотреть тут👈
Если хочешь перестать бояться терминала и начать понимать Linux на уровне бога — тебе сюда 🤑купить курс 🤑 до 25 января самая выгодная цена 22 000 рублей.
Залетай, будем делать из тебя инженера! 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22❤7👍5
This media is not supported in your browser
VIEW IN TELEGRAM
🔥26👍15❤6💯3
Привет! 👋
Продолжаем препарировать почтовые системы. Сегодня поговорим про классическую боль, с которой приходят ребята, когда их проект перерастает стадию «три калеки и админ».
Проблема: «Сервер ложится при рассылках» или High Load на ровном месте.
Сценарий до боли знакомый: у вас связка Postfix + Dovecot. Вроде всё работает, письма ходят. Но стоит прилететь спам-атаке или корпоративной рассылке на 500+ адресов, как Load Average улетает в космос, память заканчивается, а сервер встает колом.
Вы смотрите top и видите сотни процессов dovecot-lda.
В чем ошибка?
Скорее всего, у вас настроена доставка через LDA (Local Delivery Agent) методом pipe в Postfix. Это старый дедовский способ.
Как это выглядит в конфиге Postfix (`/etc/postfix/master.cf`):
Почему это плохо:
На каждое входящее письмо Postfix порождает новый процесс dovecot-lda.
Пришло 10 писем — ок. Пришло 100 писем в секунду — OS форкает 100 процессов, каждый грузит конфиги, открывает соединения к БД/LDAP, пишет на диск и умирает. Это адский оверхед на CPU и I/O.
🔥Решение: Переходим на LMTP (Local Mail Transfer Protocol)
Dovecot (как и Nginx с PHP-FPM) умеет работать как постоянный сервис. Мы поднимаем LMTP-сервер внутри Dovecot. Это демон, он уже запущен, он держит кэши и соединения с базой открытыми. Postfix просто стучится к нему в сокет.
Разница в производительности — колоссальная.
💡 Как переехать за 5 минут
Шаг 1️⃣. Настраиваем Dovecot
Открываем /etc/dovecot/conf.d/10-master.conf. Нам нужно включить сервис lmtp и дать права Postfix писать в его сокет.
Шаг 2️⃣. Настраиваем логику LMTP
В файле /etc/dovecot/conf.d/20-lmtp.conf:
Не забываем systemctl restart dovecot (и проверяем логи, чтобы сервис поднялся!).
Шаг 3️⃣. Учим Postfix ходить в сокет
Идем в /etc/postfix/main.cf и меняем транспорт. Закомментируйте старое и добавьте:
*Важно: путь private/dovecot-lmtp — относительный от queue_directory постфикса (обычно `/var/spool/postfix`).*
Делаем systemctl reload postfix.
Итог:
Вместо запуска тысяч бинарников, Postfix теперь просто "льет" данные в открытый сокет.
1️⃣ Нагрузка на CPU падает в разы.
2️⃣ Пропадают проблемы с правами доступа (permission denied), так как LMTP работает от имени пользователя Dovecot.
3️⃣ Ошибки (например, "ящик переполнен") отдаются Postfix'у прямо во время сессии, и он корректно шлет отлуп отправителю, а не создает bounce-письма, засоряя очередь.
Внедряйте, проверяйте нагрузку) Если нужны системные знания и отработать их на правктике - приходи на наш новый курс "Dovecot", подробная программа тут.
26 января старт курса, до 25 числа включительно самая выгодная цена 22 000 рублей, купить можно по ссылке.
Продолжаем препарировать почтовые системы. Сегодня поговорим про классическую боль, с которой приходят ребята, когда их проект перерастает стадию «три калеки и админ».
Проблема: «Сервер ложится при рассылках» или High Load на ровном месте.
Сценарий до боли знакомый: у вас связка Postfix + Dovecot. Вроде всё работает, письма ходят. Но стоит прилететь спам-атаке или корпоративной рассылке на 500+ адресов, как Load Average улетает в космос, память заканчивается, а сервер встает колом.
Вы смотрите top и видите сотни процессов dovecot-lda.
В чем ошибка?
Скорее всего, у вас настроена доставка через LDA (Local Delivery Agent) методом pipe в Postfix. Это старый дедовский способ.
Как это выглядит в конфиге Postfix (`/etc/postfix/master.cf`):
# ТАК ДЕЛАТЬ НЕ НАДО при нагрузках
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -d ${recipient}
Почему это плохо:
На каждое входящее письмо Postfix порождает новый процесс dovecot-lda.
Пришло 10 писем — ок. Пришло 100 писем в секунду — OS форкает 100 процессов, каждый грузит конфиги, открывает соединения к БД/LDAP, пишет на диск и умирает. Это адский оверхед на CPU и I/O.
🔥Решение: Переходим на LMTP (Local Mail Transfer Protocol)
Dovecot (как и Nginx с PHP-FPM) умеет работать как постоянный сервис. Мы поднимаем LMTP-сервер внутри Dovecot. Это демон, он уже запущен, он держит кэши и соединения с базой открытыми. Postfix просто стучится к нему в сокет.
Разница в производительности — колоссальная.
Шаг 1️⃣. Настраиваем Dovecot
Открываем /etc/dovecot/conf.d/10-master.conf. Нам нужно включить сервис lmtp и дать права Postfix писать в его сокет.
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
# Важно: сокет должен быть доступен Postfix'у.
# Обычно это user=postfix group=postfix и mode=0600
group = postfix
mode = 0600
user = postfix
}
}
# Не забудьте включить сам протокол в 10-master.conf или dovecot.conf
# protocols = imap pop3 lmtp
Шаг 2️⃣. Настраиваем логику LMTP
В файле /etc/dovecot/conf.d/20-lmtp.conf:
protocol lmtp {
postmaster_address = postmaster@yoursite.com
mail_plugins = $mail_plugins sieve # Если нужны фильтры/автоответы
}
Не забываем systemctl restart dovecot (и проверяем логи, чтобы сервис поднялся!).
Шаг 3️⃣. Учим Postfix ходить в сокет
Идем в /etc/postfix/main.cf и меняем транспорт. Закомментируйте старое и добавьте:
# Было (скорее всего)
# virtual_transport = dovecot
# Стало
virtual_transport = lmtp:unix:private/dovecot-lmtp
*Важно: путь private/dovecot-lmtp — относительный от queue_directory постфикса (обычно `/var/spool/postfix`).*
Делаем systemctl reload postfix.
Итог:
Вместо запуска тысяч бинарников, Postfix теперь просто "льет" данные в открытый сокет.
1️⃣ Нагрузка на CPU падает в разы.
2️⃣ Пропадают проблемы с правами доступа (permission denied), так как LMTP работает от имени пользователя Dovecot.
3️⃣ Ошибки (например, "ящик переполнен") отдаются Postfix'у прямо во время сессии, и он корректно шлет отлуп отправителю, а не создает bounce-письма, засоряя очередь.
Внедряйте, проверяйте нагрузку) Если нужны системные знания и отработать их на правктике - приходи на наш новый курс "Dovecot", подробная программа тут.
26 января старт курса, до 25 числа включительно самая выгодная цена 22 000 рублей, купить можно по ссылке.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍29🔥16❤3
1️⃣ Free Range Routing (FRR): управление статической и динамической маршрутизацией в Linux
Время проведения:
20 января 2026, вторник, 19:00 по МСК
Программа практикума:
Кто ведёт?
Андрей Шабалин — Тренер Cisco / Huawei, инструктор академии Eltex и Астра-Университета
---------------------------------------------------------------------------------------
2️⃣ Обратный прокси на базе Angie/Nginx
Время проведения:
21 января 2026, среда, 20:00 по МСК
Программа практикума:
Кто ведёт?
Николай Лавлинский — Технический директор в ООО “Метод Лаб”. Веб-разработчик более 15 лет. Спикер конференций HighLoad++, РИТ++
---------------------------------------------------------------------------------------
3️⃣ Kubernetes: Ingress vs Gateway API
Время проведения:
22 января 2026, четверг, 19:00 по МСК
Программа практикума:
Кто ведёт?
Василий Озеров — co-Founder REBRAIN, IT-инженер с 2012 года, провёл 100+ вебинаров по DevOps и инфраструктуре.
Please open Telegram to view this post
VIEW IN TELEGRAM
Free Range Routing (FRR): управление статической и динамической маршрутизацией в Linux
Вебинары by REBRAIN
🔥16❤1
📨 Единый вход: как подружить Dovecot и базу данных приложения
Знакомая боль: есть веб-проект (SaaS, админка, корпоративный портал) с базой пользователей в PostgreSQL. Задача — дать им почту.
Плохой путь: Создавать системных юзеров в Linux или писать скрипты, которые по крону синхронизируют табличку пользователей с файлом паролей. Это костыли, рассинхрон и дыры в безопасности.
Правильный путь: Научить Dovecot ходить прямо в базу вашего приложения.
Это дает Single Source of Truth: сменил пароль в вебе — он тут же сменился в почте. Забанили юзера в админке — почта тоже отвалилась.
Ниже — рабочая конфигурация, которую можно адаптировать под любой проект. Погнали настраивать.
1️⃣ Готовим базу данных
Предполагаем, что таблица юзеров app_users уже есть. Добавим поля для почты. В идеале лучше сделать VIEW, чтобы не мусорить в основной таблице, но для примера добавим колонки напрямую:
2️⃣ Создаем системного "почтальона"
Dovecot не должен работать от root. Ему нужен один технический юзер, который будет владеть всеми файлами писем.
3️⃣ Настраиваем Dovecot
Идем в /etc/dovecot/conf.d/.
Файл 10-auth.conf
Отключаем системных юзеров и включаем SQL:
Файл auth-sql.conf.ext
Говорим Dovecot, где искать правила:
Файл dovecot-sql.conf.ext (Самое мясо)
Здесь мы мапим данные из SQL в переменные Dovecot.
В чем подвох?
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!
👉 Программа
👉Ссылка, если готов сразу купить
Знакомая боль: есть веб-проект (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!
👉 Программа
👉Ссылка, если готов сразу купить
🔥7❤5
Привет, инженеры! 🤘
Сегодня без долгих предисловий — разберем вечную головную боль. Кто-то что-то настроил в cron или systemd на сервере, а ты теперь думай — не завезли ли нам бэкдор? Руками проверять 100500 серверов — гиблое дело.
Давайте автоматизируем! Сделаем скрипт для аудита, который будет искать за нас дыры в планировщиках. Но не спеши просто копипастить. Сначала разберем, как НЕ надо делать.
Вот пример логики из "быстрого решения", которое можно найти в сети:
🔥 Разбор полетов: почему это не работает?
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 на сервере, а ты теперь думай — не завезли ли нам бэкдор? Руками проверять 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`).
Итог: такой аудит бесполезен. Он либо ничего не найдет, либо утопит тебя в ложных срабатываниях.
А теперь, как надо. Собираем более надежный и умный скрипт, который учитывает эти нюансы.
❤14👍4🔥2
✅ Конфигурация: "Автоматический аудит 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"
👍17❤15
🧐 Что с этим делать и как использовать?
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" мы такие вещи разбираем на атомы, учимся не только находить, но и эксплуатировать их, чтобы ты мог мыслить как атакующий и строить непробиваемую защиту. Залетай
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" мы такие вещи разбираем на атомы, учимся не только находить, но и эксплуатировать их, чтобы ты мог мыслить как атакующий и строить непробиваемую защиту. Залетай
👍38🔥1
Внедряете или администрируете корпоративный DataLens? Команда Yandex Cloud систематизировала свой опыт и создала единственный на рынке курс по промышленному администрированию On-Premises-версии.
Почему это эталонный подход?
1️⃣ В основе курса — реальные инструменты, инфраструктура и методологии Yandex Cloud. Вы не изучаете абстрактные кейсы, а работаете в среде, на которой построен сам сервис. Это гарантирует, что вы учитесь на актуальных и проверенных практиках.
2️⃣ Разберём на примере. Одна из ключевых задач — настройка централизованного сбора логов Usage Tracking во внешний ClickHouse для аудита и анализа поведения пользователей.
Как это решается в инфраструктуре Yandex Cloud (упрощённо):
# Фрагмент 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
Архитектурная схема решения:
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 у команды, которая его создаёт и развивает.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤1
🔥 Сломали голову над медленными запросами?
Учитесь оптимизировать Greenplum у тех, кто его создаёт.
Давайте разберём одну из самых частых и болезненных проблем в распределённых базах данных: запросы внезапно начинают выполняться часами при росте данных. Частая причина — неправильная дистрибуция (распределение) таблиц в Greenplum, из-за которой система тратит львиную долю времени не на вычисления, а на пересылку данных между узлами.
Суть проблемы:
Допустим, у вас две таблицы — sales и products. Они распределены по разным ключам или случайно.
➡️ При join по product_id системе придётся "гонять" почти все строки между серверами (reshuffle). Это и есть главный тормоз.
Как это выглядит в коде (проблемный вариант):
💡 Решение — контроль дистрибуции от создателей технологии:
Эксперты Yandex Cloud покажут, как проектировать схему с самого начала, чтобы соединения работали локально.
Результат: Данные с одинаковым 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 января включительно)
Учитесь оптимизировать 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
💳 Оплатить по специальной цене:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👎2
немного про greenplum от эксперта курса Никиты Целищева, архитектора Data Platform Yandex Cloud
Привет!🤘
Кратко о граблях, на которые наступают даже профи. Нужно дать скрипту права root. Кажется, что это просто:
Эта команда ставит SUID`-бит, который должен запускать файл с правами владельца (`root`). Но с скриптами (.sh`, .py`) это не работает — ядро Linux игнорирует `SUID для них из соображений безопасности.
Хуже того, это создает ложное чувство защиты и открывает двери для атаки Path Injection.
Как `root`-скрипт отдает тебе систему
Представь, у тебя есть скрипт, который запускается через sudo и содержит вызов системной команды без полного пути:
victim_script.sh
Атакующий делает три простых шага:
1️⃣ Создает свой `ps`:
2️⃣ Добавляет свою папку в `PATH`:
Теперь его папка в приоритете для поиска команд.
3️⃣ Запускает твой скрипт:
Скрипт попытается выполнить ps, найдет вредоносный файл атакующего и запустит его с правами root. Игра окончена, система захвачена.
Как делать правильно и безопасно
Всего два железных правила, которые спасут твою инфраструктуру:
1️⃣ Всегда указывай полные пути к исполняемым файлам в своих скриптах: /bin/ps, /usr/bin/systemctl и т.д.
2️⃣ Используй `sudoers` для выдачи прав. Это единственный контролируемый способ.
Создай файл /etc/sudoers.d/developers:
Это безопасно, логируется и полностью под твоим контролем.
---
Знание таких основ — это фундамент. Чтобы видеть все векторы атак, от sudo и SUID до эксплойтов ядра, и уметь им противостоять, нужно мыслить как атакующий.
Именно этому мы учим на нашем практикуме "Повышение привилегий в Linux". Только хардкор, только практика на стендах.
🚀 Старт курса уже 26 января! Успей запрыгнуть, чтобы стать на голову выше в понимании Linux.
🤘Записаться на курс
---
P.S. Мы хотим постить прямые ссылки на самые сочные материалы в сторис, но для этого Телеграм просит "бусты". Если наши посты тебе полезны, поддержи канал своим голосом! Это быстро и бесплатно.
🚀 Бустануть канал 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. Игра окончена, система захвачена.
Как делать правильно и безопасно
Всего два железных правила, которые спасут твою инфраструктуру:
Создай файл /etc/sudoers.d/developers:
# Дать право запускать ТОЛЬКО один конкретный скрипт без пароля
developer ALL=(root) NOPASSWD: /usr/local/bin/my_awesome_tool.sh
Это безопасно, логируется и полностью под твоим контролем.
---
Знание таких основ — это фундамент. Чтобы видеть все векторы атак, от sudo и SUID до эксплойтов ядра, и уметь им противостоять, нужно мыслить как атакующий.
Именно этому мы учим на нашем практикуме "Повышение привилегий в Linux". Только хардкор, только практика на стендах.
🚀 Старт курса уже 26 января! Успей запрыгнуть, чтобы стать на голову выше в понимании Linux.
🤘Записаться на курс
---
P.S. Мы хотим постить прямые ссылки на самые сочные материалы в сторис, но для этого Телеграм просит "бусты". Если наши посты тебе полезны, поддержи канал своим голосом! Это быстро и бесплатно.
🚀 Бустануть канал Rebrain
Спасибо! 💪
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
DevOps by REBRAIN
Проголосуйте за канал, чтобы он получил больше возможностей.
👍19🔥19❤14👎1
🗓️ Расписание вебинаров на сегодня
⏰ 20:00 МСК - Обратный прокси на базе Angie/Nginx
🔗 Регистрация и программа
О вебинаре напомним за 5 минут до начала на этом канале.
Также вы сможете зайти через личный кабинет.
🔥 Задать вопросы и обсудить детали можно в нашем чате
⏰ 20:00 МСК - Обратный прокси на базе Angie/Nginx
🔗 Регистрация и программа
О вебинаре напомним за 5 минут до начала на этом канале.
Также вы сможете зайти через личный кабинет.
🔥 Задать вопросы и обсудить детали можно в нашем чате
🔥2
Открытый практикум Обратный прокси на базе Angie/Nginx начнётся сегодня в 20:00 МСК. Практикум будет проходить на площадке Zoom.US
Важно!!! Чтобы вы смогли без проблем к нам присоединиться, заранее протестируйте комнату по ссылке: https://zoom.us/test
Ссылку для доступа отправим вам за 5 минут до начала. Либо заходите через личный кабинет в разделе «Вебинары».
🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате
Важно!!! Чтобы вы смогли без проблем к нам присоединиться, заранее протестируйте комнату по ссылке: https://zoom.us/test
Ссылку для доступа отправим вам за 5 минут до начала. Либо заходите через личный кабинет в разделе «Вебинары».
🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате