✅ Конфигурация: "Автоматический аудит 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"
👍21❤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/noscript.sh и chown root:root /path/to/noscript.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/noscript.sh и chown root:root /path/to/noscript.sh.
* Перепиши команды в кроне, чтобы избежать wildcard: tar cf /backup/$(date +%F).tar /data/www вместо tar cf /backup/my.tar *.
* Наведи порядок в правах на systemd юниты.
Хватит работать вслепую. Автоматизируй защиту так же, как и деплой. Это и есть DevOps-подход.
🚀 На нашем курсе "Повышение привилегий в Linux" мы такие вещи разбираем на атомы, учимся не только находить, но и эксплуатировать их, чтобы ты мог мыслить как атакующий и строить непробиваемую защиту. Залетай
👍39🔥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
👍6❤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
❤11👎2
немного про greenplum от эксперта курса Никиты Целищева, архитектора Data Platform Yandex Cloud
Привет!🤘
Кратко о граблях, на которые наступают даже профи. Нужно дать скрипту права root. Кажется, что это просто:
Эта команда ставит SUID`-бит, который должен запускать файл с правами владельца (`root`). Но с скриптами (.sh`, .py`) это не работает — ядро Linux игнорирует `SUID для них из соображений безопасности.
Хуже того, это создает ложное чувство защиты и открывает двери для атаки Path Injection.
Как `root`-скрипт отдает тебе систему
Представь, у тебя есть скрипт, который запускается через sudo и содержит вызов системной команды без полного пути:
victim_noscript.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_noscript.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_noscript.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
Проголосуйте за канал, чтобы он получил больше возможностей.
👍33🔥23❤20👎1
Привет, инженеры!
Слушайте, мы тут оглянулись на четвертый квартал и сами офигели. Работа проделана колоссальная. Мы не просто пилили контент, мы реально прокачали платформу.
Вы часто спрашиваете: «А что там нового?». Скажу прямо: индустрия летит вперед, и мы вместе с ней. Более 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
Слушайте, мы тут оглянулись на четвертый квартал и сами офигели. Работа проделана колоссальная. Мы не просто пилили контент, мы реально прокачали платформу.
Вы часто спрашиваете: «А что там нового?». Скажу прямо: индустрия летит вперед, и мы вместе с ней. Более 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
👍17🔥7❤6👎1💯1
1️⃣ Keycloak: часть 3
Время проведения:
27 января 2026, вторник, 19:00 по МСК
Программа практикума:
Кто ведёт?
Василий Озеров — co-Founder REBRAIN, IT-инженер с 2012 года, провёл 100+ вебинаров по DevOps и инфраструктуре.
---------------------------------------------------------------------------------------
2️⃣ Linux From Scratch: 01
Время проведения:
28 января 2026, среда, 20:00 по МСК
Программа практикума:
Кто ведёт?
Андрей Буранов — системный администратор в департаменте VK Play, 10+ лет опыта работы с ОС Linux, 8+ лет опыта преподавания. Входит в топ 3 лучших преподавателей образовательных порталов
---------------------------------------------------------------------------------------
3️⃣ HTTPS в Angie и Nginx
Время проведения:
29 января 2026, четверг, 19:00 по МСК
Программа практикума:
Кто ведёт?
Николай Лавлинский — Технический директор в ООО “Метод Лаб”. Веб-разработчик более 15 лет. Спикер конференций HighLoad++, РИТ++
Please open Telegram to view this post
VIEW IN TELEGRAM
Rebrain
Ошибка 404
DevOps, Kubernetes, Docker, Linux, HighLoad, обучение онлайн, онлайн-практикумы, вебинары, обучение DevOps, обучение Linux, обучение HighLoad, обучение Docker, корпоративное обучение DevOps, обучение Kubernetes, корпоративное обучение Docker, корпоративное…
👍9🔥6💯2
Привет! 🤙
Мы с вами уже говорили про sudo и скрытые угрозы типа Capabilities. Но сегодня я хочу затронуть слона в посудной лавке — Docker🐳
Все мы любим Докер. Но часто ради удобства (или лени) мы прокидываем доступ к Docker сокету внутрь контейнеров или даем пользователям группу docker.
⚠️ В чем проблема?
Если у пользователя есть доступ к /var/run/docker.sock или он входит в группу docker, это эквивалентно правам root на хост-системе. Без паролей, без регистрации и смс.
🔫 Сценарий атаки:
Злоумышленник (или кривой скрипт) получает доступ к сокету и запускает привилегированный контейнер, монтируя корень хостовой системы (`/`) внутрь контейнера. Всё, он владеет сервером.
🛡️ Решение: Docker Socket Proxy (Harden Configuration)
Не прокидывайте сырой сокет! Используйте проксирующий контейнер, который фильтрует запросы к Docker API. Это "флоппинет" (firewall) для вашего докера.
Ниже готовый docker-compose.yml для Tecnativa Docker Socket Proxy. Он разрешает только чтение (GET запросы) и запрещает запуск новых контейнеров. Идеально для мониторинга (Portainer, Traefik, Prometheus и др.).
📂 Конфигурация (docker-compose.yml)
🛠️ Как это работает в продакшене:
1️⃣ Изоляция: Сервисы (мониторинг, Traefik и т.д.) больше не получают /var/run/docker.sock.
2️⃣ Доступ: Они общаются с docker-proxy:2375 внутри внутренней сети proxy-net.
3️⃣ Фильтр: Если взломанный сервис попробует сделать POST /containers/create (создать новый контейнер для побега), прокси ответит 403 Forbidden.
Совет: Если у вас Jenkins или GitLab Runner требует сокет для сборки — используйте Docker-in-Docker (dind) или выделенные ноды. Не давайте CI/CD системам прямой доступ к сокету продакшн-хоста. Это самоубийство.
---
Хочешь реально понимать, где в Linux живут уязвимости и как их закрывать, а не просто копировать конфиги с StackOverflow?
Жду тебя на курсе "Повышение привилегий в Linux".
Разберем всё: от SUID и ядра до NFS и токенов.
🗓 Старт: 26 января
👉 Записывайся тут, Стоимость всего 22 000 рублей ⛔️сегодня последний день скидки на модуль⛔️
Мы с вами уже говорили про sudo и скрытые угрозы типа Capabilities. Но сегодня я хочу затронуть слона в посудной лавке — Docker
Все мы любим Докер. Но часто ради удобства (или лени) мы прокидываем доступ к Docker сокету внутрь контейнеров или даем пользователям группу docker.
Если у пользователя есть доступ к /var/run/docker.sock или он входит в группу docker, это эквивалентно правам root на хост-системе. Без паролей, без регистрации и смс.
Злоумышленник (или кривой скрипт) получает доступ к сокету и запускает привилегированный контейнер, монтируя корень хостовой системы (`/`) внутрь контейнера. Всё, он владеет сервером.
Не прокидывайте сырой сокет! Используйте проксирующий контейнер, который фильтрует запросы к Docker API. Это "флоппинет" (firewall) для вашего докера.
Ниже готовый docker-compose.yml для Tecnativa Docker Socket Proxy. Он разрешает только чтение (GET запросы) и запрещает запуск новых контейнеров. Идеально для мониторинга (Portainer, Traefik, Prometheus и др.).
📂 Конфигурация (docker-compose.yml)
version: '3.8'
services:
docker-proxy:
image: tecnativa/docker-socket-proxy
container_name: docker-proxy
privileged: true # Нужно для доступа к реальному сокету
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro # Монтируем оригинал в RO
environment:
# --- Политика безопасности ---
# Разрешаем только безопасные операции
CONTAINERS: 1 # List containers
IMAGES: 1 # List images
NETWORKS: 1 # List networks
VOLUMES: 1 # List volumes
INFO: 1 # System info
# Запрещаем всё, что может менять состояние
POST: 0 # Запрет на создание (POST)
DELETE: 0 # Запрет на удаление
AUTH: 0 # Запрет auth
SECRETS: 0 # Не палить секреты
# Остальное по умолчанию запрещено образом
ports:
- "127.0.0.1:2375:2375" # Слушаем только на localhost!
restart: unless-stopped
networks:
- proxy-net
# Пример сервиса, которому нужен доступ к докеру (например, мониторинг)
monitoring-agent:
image: alpine:latest
command: ["curl", "http://docker-proxy:2375/containers/json"]
depends_on:
- docker-proxy
networks:
- proxy-net
networks:
proxy-net:
internal: true # Изолированная сеть
🛠️ Как это работает в продакшене:
1️⃣ Изоляция: Сервисы (мониторинг, Traefik и т.д.) больше не получают /var/run/docker.sock.
2️⃣ Доступ: Они общаются с docker-proxy:2375 внутри внутренней сети proxy-net.
3️⃣ Фильтр: Если взломанный сервис попробует сделать POST /containers/create (создать новый контейнер для побега), прокси ответит 403 Forbidden.
Совет: Если у вас Jenkins или GitLab Runner требует сокет для сборки — используйте Docker-in-Docker (dind) или выделенные ноды. Не давайте CI/CD системам прямой доступ к сокету продакшн-хоста. Это самоубийство.
---
Хочешь реально понимать, где в Linux живут уязвимости и как их закрывать, а не просто копировать конфиги с StackOverflow?
Жду тебя на курсе "Повышение привилегий в Linux".
Разберем всё: от SUID и ядра до NFS и токенов.
🗓 Старт: 26 января
👉 Записывайся тут, Стоимость всего 22 000 рублей ⛔️сегодня последний день скидки на модуль⛔️
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥27👍11❤7
Всем привет, небольшой апдейт по вебинару Keycloak: часть 3 👋
Мы отменяем вебинар по этой теме: спикер приболел, а также выяснилось, что все ключевые моменты Вася Озеров уже подробно разобрал в предыдущих вебинарах.
Увидимся с Васей 5 февраля на вебинаре Kubernetes: Service Mesh на базе Linkerd 🚀
Спасибо за понимание и до встречи!
Мы отменяем вебинар по этой теме: спикер приболел, а также выяснилось, что все ключевые моменты Вася Озеров уже подробно разобрал в предыдущих вебинарах.
Увидимся с Васей 5 февраля на вебинаре Kubernetes: Service Mesh на базе Linkerd 🚀
Спасибо за понимание и до встречи!
❤19🔥8💯5
Знакомая боль: пользователь ищет письмо за 2018 год, Thunderbird висит, а сервер выжирает диск в полку. Почему? Dovecot по умолчанию ищет "в лоб", перебирая файлы.
Решение — Full Text Search (FTS) на движке Lucene. Он быстрый, легкий, не требует Java (как Solr) и хранит индексы прямо рядом с письмами.
🛠 Настройка за 5 минут
plugin {
fts = lucene
# Лайфхак: @. в whitespace_chars позволяет искать по email целиком
fts_lucene = whitespace_chars=@. no_index=mime
# Индексируем входящие сразу. Для HighLoad лучше 'no' + cron
fts_autoindex = yes
# Стемминг для русского и английского
fts_languages = en ru
}
protocol imap {
mail_plugins = $mail_plugins fts fts_lucene
}
# То же самое добавляем в protocol lda и lmtp!
После рестарта (`systemctl restart dovecot`) новые письма индексируются сами.
⚡ Как ускорить старые письма?
Их нужно прогнать через индексатор вручную. Осторожно, нагрузка на CPU!
# Для одного страдающего пользователя
doveadm fts rescan -u user@domain.com && doveadm index -u user@domain.com INBOX
# Для всех сразу (запускать в screen/tmux)
doveadm fts rescan -A
✅ Итог:
* Скорость: Поиск занимает миллисекунды.
* Ресурс: Диски перестают "хрустеть" I/O операциями при поиске.
* Цена: Индексы съедят ~10-20% доп. места на диске.
---
🔥 Почта — это сложная экосистема. Хочешь понимать, как тюнить производительность, интегрировать SQL/LDAP, настраивать Sieve и безопасность?
Приходи на новый курс Dovecot, материалы уже на платформе. Разбираем архитектуру, а не просто копипастим конфиги.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16❤8👍5
Как приручить хаос: Импорт ресурсов и рефакторинг без даунтайма
Знакомая ситуация? Ты приходишь на новый проект, а там — классический ClickOps. Половина инфраструктуры натыкана руками в консоли облака, другая половина — в потерянных bash-скриптах. Или другой сценарий: ты решил навести порядок в коде, переименовать ресурсы, разложить всё по модулям, запускаешь plan, а Terraform радостно сообщает:
У тебя холодный пот. Удалять прод нельзя. Оставлять как есть — значит плодить технический долг.
Многие в этот момент сдаются и оставляют "как есть". Но сильный инженер знает: Terraform state — это не скрижаль, которую нельзя трогать. Это база данных, которой можно и нужно управлять.
Проблема1️⃣ : "Это было создано руками"
Допустим, у тебя уже есть виртуалка в Yandex Cloud (`ID: fhm...`), созданная через UI. Тебе нужно загнать её под IaC.
Неправильно: Писать код и надеяться, что Terraform "подхватит" существующий айдишник. Он попытается создать новую ВМ и упадет с ошибкой конфликта.
Как делает профи: Использует terraform import.
1️⃣ Описываем ресурс в коде (пока можно даже пустой):
2️⃣ Импортируем реальное состояние в наш стейт:
3️⃣ Теперь самое интересное. Выполняем `terraform plan`. Terraform скажет, что хочет *изменить* ресурс, чтобы привести его к пустому конфигу. Твоя задача — дописать HCL код так, чтобы plan показал: No changes.
Проблема2️⃣ : "Хочу переименовать, но боюсь пересоздания"
Ты назвал ресурс resource "yandex_vpc_network" "net" {}, но по стайл-гайду нужно vpc-main. Если просто поменяешь имя в коде — Terraform удалит старую сеть (и всё, что в ней!) и создаст новую.
💡 Решение: Манипуляции со стейтом (`terraform state mv`).
Мы объясняем Terraform, что объект в базе данных переехал по новому адресу:
После этой команды меняешь имя в .tf файле, запускаешь plan — и видишь заветный зеленый свет без разрушений.
🚀 Terraform 2.0: Глобальная перезагрузка
Умение работать со стейтом, писать чистые модули, внедрять CI/CD и понимать, *как* это работает под капотом — это база. И именно эту базу мы полностью пересобрали.
Рады сообщить, что мы обновили курс по Terraform на 90%. Это не просто косметика, это полный рефакторинг программы.
🔗 Смотреть подробную программу (PDF)
🔗 Купить обновленный курс. Мы сделали знания доступнее. Теперь модуль стоит 30 000 ₽ (вместо 50 000 ₽).
🛑 Важно для "старичков": Если ты уже покупал этот курс ранее — тебе не нужно платить снова. Пиши в поддержку, и тебе откроют доступ к новой версии бесплатно (без сохранения прогресса старой, так как программа новая).
Перестань бояться terraform apply. Становись архитектором своей инфраструктуры.
Знакомая ситуация? Ты приходишь на новый проект, а там — классический ClickOps. Половина инфраструктуры натыкана руками в консоли облака, другая половина — в потерянных bash-скриптах. Или другой сценарий: ты решил навести порядок в коде, переименовать ресурсы, разложить всё по модулям, запускаешь plan, а Terraform радостно сообщает:
Plan: 10 to add, 10 to destroy.
У тебя холодный пот. Удалять прод нельзя. Оставлять как есть — значит плодить технический долг.
Многие в этот момент сдаются и оставляют "как есть". Но сильный инженер знает: Terraform state — это не скрижаль, которую нельзя трогать. Это база данных, которой можно и нужно управлять.
Проблема
Допустим, у тебя уже есть виртуалка в Yandex Cloud (`ID: fhm...`), созданная через UI. Тебе нужно загнать её под IaC.
Неправильно: Писать код и надеяться, что Terraform "подхватит" существующий айдишник. Он попытается создать новую ВМ и упадет с ошибкой конфликта.
Как делает профи: Использует terraform import.
1️⃣ Описываем ресурс в коде (пока можно даже пустой):
resource "yandex_compute_instance" "legacy_vm" {
# Пока пусто, заполним после импорта, глядя в state
}
2️⃣ Импортируем реальное состояние в наш стейт:
terraform import yandex_compute_instance.legacy_vm fhm1234567890abcdef
3️⃣ Теперь самое интересное. Выполняем `terraform plan`. Terraform скажет, что хочет *изменить* ресурс, чтобы привести его к пустому конфигу. Твоя задача — дописать HCL код так, чтобы plan показал: No changes.
Проблема
Ты назвал ресурс resource "yandex_vpc_network" "net" {}, но по стайл-гайду нужно vpc-main. Если просто поменяешь имя в коде — Terraform удалит старую сеть (и всё, что в ней!) и создаст новую.
Мы объясняем Terraform, что объект в базе данных переехал по новому адресу:
terraform state mv yandex_vpc_network.net yandex_vpc_network.vpc-main
После этой команды меняешь имя в .tf файле, запускаешь plan — и видишь заветный зеленый свет без разрушений.
🚀 Terraform 2.0: Глобальная перезагрузка
Умение работать со стейтом, писать чистые модули, внедрять CI/CD и понимать, *как* это работает под капотом — это база. И именно эту базу мы полностью пересобрали.
Рады сообщить, что мы обновили курс по Terraform на 90%. Это не просто косметика, это полный рефакторинг программы.
🔗 Смотреть подробную программу (PDF)
🔗 Купить обновленный курс. Мы сделали знания доступнее. Теперь модуль стоит 30 000 ₽ (вместо 50 000 ₽).
🛑 Важно для "старичков": Если ты уже покупал этот курс ранее — тебе не нужно платить снова. Пиши в поддержку, и тебе откроют доступ к новой версии бесплатно (без сохранения прогресса старой, так как программа новая).
Перестань бояться terraform apply. Становись архитектором своей инфраструктуры.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14❤10👍5
1️⃣ EIGRP. Протокол динамической маршрутизации
Время проведения:
3 февраля 2026, вторник, 19:00 по МСК
Программа практикума:
Кто ведёт?
Андрей Шабалин — Тренер Cisco / Huawei, инструктор академии Eltex и Астра-Университета
---------------------------------------------------------------------------------------
2️⃣ Linux From Scratch - 02
Время проведения:
4 февраля 2026, среда, 20:00 по МСК
Программа практикума:
Кто ведёт?
Андрей Буранов — системный администратор в департаменте VK Play, 10+ лет опыта работы с ОС Linux, 8+ лет опыта преподавания. Входит в топ 3 лучших преподавателей образовательных порталов
---------------------------------------------------------------------------------------
3️⃣ Kubernetes: Service Mesh на базе Linkerd
Время проведения:
5 февраоя 2026, четверг, 19:00 по МСК
Программа практикума:
Кто ведёт?
Василий Озеров — co-Founder REBRAIN, IT-инженер с 2012 года, провёл 100+ вебинаров по DevOps и инфраструктуре.
Please open Telegram to view this post
VIEW IN TELEGRAM
Rebrain
Ошибка 404
DevOps, Kubernetes, Docker, Linux, HighLoad, обучение онлайн, онлайн-практикумы, вебинары, обучение DevOps, обучение Linux, обучение HighLoad, обучение Docker, корпоративное обучение DevOps, обучение Kubernetes, корпоративное обучение Docker, корпоративное…
🔥9❤4👍1👎1