Любой локальный пользователь без привилегий прямо сейчас может прочитать твои приватные SSH-ключи и хеши паролей из /etc/shadow. Давай закроем брешь CVE-2026-46333 на уровне ядра строго по рекомендациям Red Hat.

Ошибка кроется в функции __ptrace_may_access(). Во время завершения процесса ядро освобождает память до закрытия файловых дескрипторов. Возникает состояние гонки. Успешная эксплуатация опирается на использование вызова pidfd_getfd(2). Под ударом RHEL 8, 9, 10 и зависимые продукты (RHEL CoreOS, OpenShift, OpenStack, Red Hat Virtualization).

Официальный бюллетень Red Hat не предоставляет готовых bash-скриптов, но описывает два варианта изоляции угрозы:

1. Option 1: Admin-only scope (Безопасный режим)
Необходимо установить ptrace_scope в значение 2. Это ограничит ptrace только для процессов с правами CAP_SYS_PTRACE и заблокирует известные векторы атак.
Важно: это не позволит обычным пользователям использовать отладчики (gdb, strace -p) для своих собственных процессов.

2. Option 2: Most restrictive scope (Радикальный режим)
Необходимо установить ptrace_scope в значение 3. Это полностью отключит любые операции ptrace для всех, включая root.
Важно: сломаются любые инструменты мониторинга, опирающиеся на ptrace. Требуется жесткое тестирование.

Для отката любого из этих вариантов (Mitigation removal) вендор дает следующую прямую инструкцию:

delete /etc/sysctl.d/ptrace-restrict.conf and run sysctl --system

Помни, что изменения ptrace блокируют только известные эксплойты. Полностью уязвимость закроет только официальный патч ядра.

Устал парсить бесконечные логи и ждать завершения долгого деплоя? Есть легальный способ выдохнуть, не сворачивая любимую консоль. Держи шпаргалку по 10 олдскульным играм, которые запускаются прямо в терминале.

1. Знаменитая головоломка 2048.

$ 2048

2. Классический сапёр (mines)

$ nbmines
$ freesweep


3. Текстовое приключение (adventure).

$ adventure


4. Лунный багги (moon-buggy).

$ moon-buggy


5. Классическая ролевая игра (angband).

$ angband


6. Подземелья Мории (moria).

$ moria


7. Симулятор авиадиспетчера (atc).

$ atc


8. Легендарный рогалик (nethack).

$ nethack-console


9. Нарды в консоли (backgammon).

$ backgammon


10. Космические захватчики (ninvaders).

$ ninvaders

Сохрани этот пост, чтобы быстро переключиться и дать мозгу отдохнуть, пока шеф думает, что ты упорно дебажишь ядро.

Не успели мы выдохнуть после патчей для Dirty Frag, как исследователь William Bowling из команды V12 выкатил продолжение — уязвимость «Fragnesia» (CVE-2026-46300). Давай разберем механику угрозы и посмотрим на официальные методы защиты.

Новый баг — это непреднамеренный побочный эффект от патчей, которыми ранее закрывали прошлую дыру Dirty Frag. Проблема находится в подсистеме ядра XFRM, отвечающей за обработку ESP-in-TCP (поддержка IPsec).

Опасность Fragnesia кроется в трех факторах:
- Логическая ошибка позволяет произвольно записывать байты в кэш страниц ядра (page cache) для файлов, доступных только для чтения.
- Опубликованный эксплойт успешно модифицирует бинарник /usr/bin/su прямо в оперативной памяти, открывая root-оболочку без изменения файла на диске.
- Эксплойт абсолютно предсказуем. В отличие от старых багов вроде Dirty COW, он вообще не полагается на состояния гонки (Race Conditions), что делает его сверхнадежным.

Такие вендоры, как Ubuntu, RHEL, Debian, SUSE и Amazon Linux, уже оценивают масштабы проблемы по всем поддерживаемым версиям ядер. Microsoft предупреждает: эксплойт позволяет модифицировать любой читаемый юзером файл, включая /etc/passwd

Что делать прямо сейчас? Инженеры уже подготовили патч из двух строк для файла skbuff.c, но пока он едет в стабильные ветки дистрибутивов (Ubuntu, Debian, RHEL, SUSE и др.), разработчики AlmaLinux выпустили официальную рекомендацию по защите:

«Если твой сервер не использует IPsec/ESP, жесткое отключение этих модулей ядра поможет срезать вектор атаки до установки финального патча. Следи за пакетным менеджером и обновляйся.»

Масштабная автоматизированная supply-chain атака Megalodon всего за шесть часов поразила более 5500 репозиториев на GitHub. Злоумышленники внедряют вредоносные рабочие процессы в CI/CD и сливают критичные секреты инфраструктуры. Разберем механику взлома и официальные шаги по защите.

Аналитики Hudson Rock подтвердили: источником заражения стали обычные инфостилеры на рабочих компьютерах разработчиков. Украденные учетные данные позволили хакерам получить доступ к репозиториям.

Как действует эксплойт:
- Атакующие используют поддельные имена авторов, маскируясь под легитимных ботов (build-bot, auto-ci, ci-bot, pipeline-bot).
- В GitHub Actions внедряется вредоносный workflow с полезной нагрузкой на bash в кодировке Base64.
- Скрипт собирает переменные окружения, ключи AWS, SSH, токены Kubernetes, Docker, Vault и Terraform, после чего отправляет их на C2-сервер атакующих.

Опасность в том, что атака активируется автоматически при каждом пуше (вариант SysDiag) или ждет ручного запуска через workflow_dispatch (вариант Optimize-Build), гарантируя хакерам максимальный охват.

Поскольку проблема кроется в утечке доступов, готовых bash-скриптов для очистки нет — зараженные пайплайны нужно вычищать вручную. Платформа npm уже начала принудительно аннулировать скомпрометированные ключи и выпустила официальную инструкцию по сдерживанию угрозы:


Официальные меры по защите от атаки в экосистеме npm
1. Немедленно аннулировать гранулярные токены доступа с правами на запись, которые обходят двухфакторную аутентификацию (2FA).
2. Перевести публикацию пакетов на механизм Trusted Publishing, чтобы снизить зависимость от статических токенов.

Машина разработчика с трояном — это прямой бэкдор в твой продакшен. Проверь историю коммитов на предмет странных ботов и отзови старые токены прямо сегодня.

Скрипт отработал с ошибкой, но не остановился и удалил половину нужных файлов? Или CI/CD пайплайн споткнулся о пустую переменную? Я отжал воду из огромных справочников и оставил ровно 50 самых хардкорных и важных конструкций Bash, которые жизненно необходимы.

1. Безопасность и запуск (Strict Mode)
Эти настройки — стандарт де-факто для любых production-скриптов. Они отлавливают ошибки на раннем этапе.

# Указать интерпретатор (лучшая практика переносимости)
#!/usr/bin/env bash

# Сделать скрипт исполняемым
chmod +x script.sh

# "Strict Mode" (выход при ошибке, ошибке переменной или в пайплайне)
set -euo pipefail

# Выйти немедленно при ошибке
set -e

# Режим отладки (выводить команды перед выполнением)
set -x


2. Продвинутая работа с переменными
Защита от пустых значений, которые могут сломать автоматизацию.

# Присвоить значение (строго без пробелов вокруг =)
VAR=value

# Безопасное чтение с кавычками (предотвращает word splitting)
"$VAR"

# Использовать по умолчанию, если переменная не задана (важно для Docker)
${VAR:-default}

# Назначить значение по умолчанию, если VAR не задана
${VAR:=default}

# Выйти с ошибкой, если переменная не задана (failsafe для деплоя)
${VAR:?error msg}

# Сделать переменную доступной только для чтения (константа)
readonly VAR

# Экспортировать переменную для дочерних процессов
export VAR


3. Системные переменные
Идентификаторы процессов и аргументы функций.

# Имя скрипта
$0

# Позиционные параметры (аргументы 1-9)
$1..$9

# Количество переданных аргументов
$#

# Все аргументы безопасно как отдельные слова
$@

# Статус выхода последней команды (0 - успех, иное - ошибка)
$?

# PID текущего процесса shell
$$


4. Парсинг строк (без вызова awk/sed)
Молниеносные встроенные манипуляции с путями и текстом.

# Удалить самое короткое совпадение паттерна с начала
${VAR#pattern}

# Удалить самое короткое совпадение с конца (удобно для расширений файлов)
${VAR%pattern}

# Заменить все вхождения подстроки
${VAR//old/new}

# Перевести все символы в нижний регистр
${VAR,,}


5. Условия и мощные проверки
Используй `[[ ]]` вместо старого `[ ]` — это безопаснее и поддерживает регулярные выражения.

# Проверить существование файла и вывести результат
if [[ -f "file.txt" ]]; then echo "exists"; fi

# Проверка по регулярному выражению
=~

# Конструкция case (идеально для стартовых скриптов systemd)
case "$1" in start) echo "Starting";; stop) echo "Stopping";; *) echo "Usage: $0 {start|stop}";; esac

# Файл существует и является обычным
-f file

# Файл существует и является директорией
-d file

# Строка пустая
-z string

# Строка не пустая
-n string

# Строковое равенство и неравенство
==
!=

# Числовое равенство и неравенство
-eq
-ne


6. Массивы и словари
Незаменимо для перебора IP-адресов, списков серверов и портов.

# Объявить индексированный массив
arr=(a b c)

# Получить все элементы массива
${arr[@]}

# Узнать количество элементов в массиве
${#arr[@]}

# Объявить ассоциативный массив (словарь)
declare -A map

# Добавить значение по ключу
map[key]="value"


7. Математика, Ввод/Вывод и Сигналы
Форматирование вывода для дашбордов и правильная очистка мусора за скриптом.

# Арифметика: сложение
$((a + b))

# Арифметическое присваивание
let "a += 5"

# Прочитать строку в массив
read -r -a items <<< "a b c"

# Форматированный вывод (надежнее чем echo)
printf "Name: %s, Age: %d\n" "$name" "$age"

# Многострочный ввод (Here document) для генерации конфигов
cat <<EOF
Lines of text go here.
Variables like $HOME are expanded.
$ EOF

# Завершить скрипт с кодом успеха
exit 0

# Завершить скрипт с кодом ошибки
exit 1

# Выполнить очистку (например, удалить лок-файл) при любом выходе
trap ' rm -f /tmp/mylock' EXIT

Теперь твой код готов к нагрузкам. Сохраняй шпаргалку, чтобы не плодить костыли, и применяй правильный синтаксис!

Обычный SSH-туннель или прокси падает при малейшем сбое сети, оставляя тебя без связи. Утилита autossh решает эту проблему: она оборачивает SSH-соединение, мониторит его состояние и автоматически перезапускает при обрыве.

Ниже подробная шпаргалка, как поднять вечные туннели для любых задач.

1. Поднимаем постоянный локальный SSH-туннель (Local port forward)
Пробрасываем удаленный порт 80 на локальный 8080 с портом мониторинга 20000
autossh -M 20000 -N -L 8080:localhost:80 user@remote

2. Туннель без отдельного порта мониторинга
Полезно, если порты мониторинга закрыты (полагается на ServerAliveInterval)
autossh -M 0 -N -L 8080:localhost:80 user@remote

3. Поднимаем вечный обратный туннель (Reverse port forward)
Пробрасываем наш локальный порт 80 на удаленный порт 8080
autossh -M 20000 -N -R 8080:localhost:80 user@remote

4. Запуск в фоновом режиме
Ключ -f уводит процесс в фон сразу после аутентификации
autossh -f -M 20000 -N -L 8080:localhost:80 user@remote

5. Создаем неразрывный SOCKS-прокси
autossh -M 20000 -N -D 8080 user@remote

6. Управление через переменные окружения
Включаем отладку и задаем задержку перед первой проверкой (по умолчанию 30 сек)
AUTOSSH_DEBUG=1 AUTOSSH_GATETIME=10 autossh -M 20000 -N -D 8080 user@remote

Настрой это один раз, и твои пробросы портов больше никогда не умрут от смены IP или перезагрузки роутера. Проверь свои туннели прямо сейчас.