❤️ Необычная и крайне интересная статья на Хабре: «Пустили ботов по SSH на фейковый сервер с четырьмя H100: что они там делали»!

В этой статье:
• Узнаете, как с помощью Python и Cowrie создать SSH-ловушку, имитирующую мощный сервер с четырьмя NVIDIA H100;
• Посмотрите, что делали атакующие боты после входа: меняли пароли, добавляли SSH-ключи и пытались установить майнеры;
• Разберёте результаты первых 12,5 часов эксперимента — 1 846 подключений и более 1 500 команд — и способы защиты SSH от подобных атак.

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

В Git можно переносить незавершённые изменения между проектами или рабочими деревьями без коммитов и копирования файлов вручную!

Для этого достаточно обычного патча. Git умеет сохранить изменения в текстовый файл, а затем применить их в другом каталоге.

git diff > changes.patch

Команда сохраняет изменения отслеживаемых файлов, которые ещё не добавлены в индекс. Сам файл патча можно передать коллеге или использовать в другой копии репозитория.

Перед применением полезно проверить, получится ли внести изменения:

git apply --check changes.patch

Если проверка прошла успешно, применяем:

git apply changes.patch

А если нужно перенести и изменения, уже добавленные в индекс, используйте:

git diff HEAD > changes.patch

Важно: новые неотслеживаемые файлы в такой патч автоматически не попадут.

🔥 git diff вместе с git apply — удобный способ переносить локальные правки между рабочими деревьями, тестовыми окружениями и копиями проекта без промежуточных коммитов.

🚪 Linux Ready | #совет

Почему линукс может показывать разные файлы по одному и тому же пути?

В линукс два процесса могут обращаться к /tmp, /etc или /var, но фактически видеть разные файловые системы. Причём для этого необязательно использовать docker или полноценный контейнер.

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

Проверим на практике. Сначала создадим тестовый каталог:

sudo mkdir -p /mnt/ns-test
echo "original" | sudo tee /mnt/ns-test/file

Теперь запустим отдельное пространство имён монтирования:

sudo unshare --mount --propagation private /bin/bash

Внутри новой оболочки смонтируем tmpfs поверх существующего каталога:

mount -t tmpfs tmpfs /mnt/ns-test
echo "isolated" > /mnt/ns-test/file
cat /mnt/ns-test/file

Результат:

isolated

Откроем второй терминал и выполним:

cat /mnt/ns-test/file

Здесь результат будет другим:

original

Оба процесса используют одинаковый абсолютный путь, но обращаются к разным объектам файловой системы.

Посмотреть пространства имён процессов можно через:

readlink /proc/self/ns/mnt

А для конкретного процесса:

readlink /proc/PID/ns/mnt

Если идентификаторы отличаются, процессы находятся в разных mount namespaces. Однако это ещё не означает, что их таблицы монтирования обязательно различаются.

Посмотреть реальные точки монтирования процесса:

cat /proc/PID/mountinfo

Можно также войти в существующее пространство имен другого процесса:

sudo nsenter --target PID --mount -- /bin/bash

После этого новая оболочка будет использовать его mount namespace. Именно этот механизм применяется в контейнерах и при изоляции сервисов systemd. Например, параметр PrivateTmp=yes позволяет сервису получить отдельные пространства для временных файлов в /tmp и /var/tmp.

Поэтому файл, созданный сервисом в /tmp, может быть недоступен по тому же пути из обычной пользовательской оболочки. После эксперимента выйдем из изолированной оболочки командой exit и удалим тестовый каталог:

sudo rm -rf /mnt/ns-test

🔥 Абсолютный путь в линукс не гарантирует обращение к одному и тому же файлу. При диагностике контейнеров и systemd-сервисов проверяйте не только путь, но и mount namespace процесса. Особенно если приложение видит файл, который отсутствует на хосте, или наоборот.

🚪 Linux Ready | #практика

Как диагностировать переполнение TCP listen backlog в линукс?

Под нагрузкой TCP-сервис может терять новые подключения или увеличивать время их установления, хотя CPU не перегружен, а существующие соединения работают стабильно. Одна из возможных причин — переполнение accept queue, в которой завершённые TCP-подключения ожидают обработки через accept().

Размер очереди определяется аргументом backlog при вызове listen() и ограничивается net.core.somaxconn. Проверим listening socket на порту 443:

ss -lnt '( sport = :443 )'

Для TCP-сокета в состоянии LISTEN поле Recv-Q показывает количество соединений, ожидающих accept(), а Send-Q — максимальную длину очереди. Следующий результат указывает на её заполнение в момент измерения:

State   Recv-Q Send-Q Local Address:Port
LISTEN  128    128    0.0.0.0:443

Заполненная очередь ещё не доказывает потери подключений. Проверим системный лимит и счётчики переполнений TCP-стека:

sysctl net.core.somaxconn

nstat -az | grep -E \
  'TcpExtListenOverflows|TcpExtListenDrops'

ListenOverflows учитывает события переполнения, а ListenDrops — более широкий набор отказов при обработке подключений. Счётчики относятся ко всему network namespace и не отражают точное количество уникальных потерянных соединений.

Для оценки динамики измерим прирост счётчиков за 30 секунд, используя два снимка статистики ядра.

nstat -az > /tmp/tcp-before.nstat
sleep 30
nstat -az > /tmp/tcp-after.nstat

awk '
NR == FNR { before[$1] = $2; next }
/^TcpExtListen(Overflows|Drops)[[:space:]]/ {
    printf "%s: +%.0f\n", $1, $2 - before[$1]
}
' /tmp/tcp-before.nstat /tmp/tcp-after.nstat

Если ListenOverflows растёт одновременно с заполнением Recv-Q, необходимо проверить интенсивность обработки соединений приложением. Через bpftrace подсчитаем успешные вызовы accept4() процесса с PID 2451:

sudo bpftrace -e '
tracepoint:syscalls:sys_exit_accept4
/pid == 2451 && args->ret >= 0/
{
    @accepted = count();
}

interval:s:1
{
    print(@accepted);
    clear(@accepted);
}'

Измерение приблизительное: оно не учитывает обычный accept() и другие процессы, а вывод и очистка счётчика не атомарны. Для многопроцессных серверов требуется учитывать всех обработчиков соединений.

От accept queue необходимо отличать SYN queue, которая используется при незавершённых TCP-handshake. Проверим параметры и статистику её переполнения:

sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.ipv4.tcp_syncookies

nstat -az | grep -E \
  'TcpExtSyncookiesSent|TcpExtTCPReqQFull'

Рост SyncookiesSent может указывать на давление на SYN queue, но не обязательно свидетельствует о SYN flood. Фактическое поведение зависит от конфигурации сокета и реализации TCP в ядре.

При переполнении accept queue параметр tcp_abort_on_overflow влияет на возможность сброса подключений через RST:

sysctl net.ipv4.tcp_abort_on_overflow

При значении 0 ядро обычно допускает повторную обработку подключения, что может увеличивать задержки. Значение 1 позволяет отправлять RST, но не устраняет причину перегрузки.

Если используется SO_REUSEPORT, несколько listening sockets могут обслуживать один порт с независимыми accept queues. Проверять их необходимо отдельно:

sudo ss -lntpe '( sport = :443 )'

🔥 Переполнение TCP listen backlog диагностируется по совокупности показателей: заполненности Recv-Q, динамике ListenOverflows и ListenDrops, интенсивности accept() и состоянию SYN queue. При подтверждённой перегрузке следует исследовать обработчики соединений, блокировки event loop и распределение нагрузки до изменения системных лимитов.

🚪 Linux Ready | #практика

Gemini Pro на 24 месяца за 800₽!

Вместо 39.000₽ — всего 800₽ ($9.9) за 2 года. По акции сейчас это 33₽ в месяц, в 48 раз выгоднее!

➡Argon 4.0 + Claude Opus 5.5 — для кода
➡Nano Banana 2 Pro — для картинок
➡Генерация видео — ролики и анимации
➡AntiGravity + 5 ТБ облака
➡Opus 5.5 и Sonnet 5.5
➡Youtube Premium

Акция ограничена по времени, дальше будет официальная цена 480$!

Приобрести можно в Магазине с 20.000+ покупок и 2000+ отзывов (есть возвраты и замены).

Как ограничить linux-сервису запись в файловую систему через systemd?

По умолчанию systemd-сервис имеет доступ к файловой системе в пределах прав своего пользователя. Однако иногда требуется запретить изменение системных каталогов, разрешив запись только в определённую директорию.

Для этого используются ProtectSystem=strict и ReadWritePaths. Они ограничивают запись через отдельное пространство монтирования (mount namespace), не изменяя глобальные права файлов.

Практика рассчитана на обычную линукс систему с systemd и поддержкой mount namespaces. В контейнерах с ограниченными привилегиями поведение может отличаться. Создадим каталог для данных приложения:

sudo mkdir -p /var/lib/test-app

Создадим тестовый сервис, который попытается записать файлы в разрешённый каталог и в защищённый /etc:

sudo tee /etc/systemd/system/test-app.service >/dev/null <<'EOF'
[Unit]
Description=Filesystem isolation test

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'touch /var/lib/test-app/ok && touch /etc/test-app-file'
ProtectSystem=strict
ReadWritePaths=/var/lib/test-app
EOF

Сервис намеренно запускается от root (без User=), чтобы продемонстрировать именно ограничения systemd, а не обычные права доступа к файлам. ProtectSystem=strict делает почти всю файловую иерархию доступной только для чтения внутри mount namespace сервиса, за исключением отдельных API-файловых систем.

ReadWritePaths исключает /var/lib/test-app из ограничения read-only, но не отменяет обычные права доступа и не позволяет записывать данные на файловую систему, изначально смонтированную только для чтения.

Убедимся, что тестовый файл в /etc отсутствует:

if [ -e /etc/test-app-file ] || [ -L /etc/test-app-file ]; then
  echo "Ошибка: /etc/test-app-file уже существует"
else
  sudo systemctl daemon-reload
  sudo systemctl start test-app.service
fi

На типичной системе запуск завершится ошибкой: первая операция touch выполнится успешно, а вторая получит EROFS (Read-only file system). Поскольку используется Type=oneshot, юнит перейдёт в состояние failed.

Проверим результат и журнал сервиса:

test -f /var/lib/test-app/ok && echo "OK: запись разрешена"

if [ ! -e /etc/test-app-file ] && [ ! -L /etc/test-app-file ]; then
  echo "OK: файл в /etc не создан"
fi

journalctl -u test-app.service -n 20 --no-pager

Первый файл должен существовать, второй — отсутствовать, а журнал должен содержать ошибку записи в /etc. Совокупность этих результатов подтверждает ожидаемое поведение изоляции. Если первый файл не создан, необходимо проверить журнал и причину сбоя.

Проверим загруженные параметры изоляции и оценим конфигурацию безопасности:

systemctl show test-app.service \
  -p ProtectSystem \
  -p ReadWritePaths

systemd-analyze security test-app.service

systemd-analyze security оценивает защитные настройки юнита, но не проверяет фактические права записи.

При этом ProtectSystem не изолирует сеть и процессы. Сервис с достаточными привилегиями, в частности с CAP_SYS_ADMIN, потенциально способен изменять ограничения монтирования. После проверки удалим тестовое окружение:

sudo systemctl stop test-app.service
sudo rm -f /etc/systemd/system/test-app.service
sudo rm -rf /var/lib/test-app
sudo systemctl daemon-reload
sudo systemctl reset-failed test-app.service

🔥 ProtectSystem=strict совместно с ReadWritePaths позволяет ограничить запись сервиса без изменения глобальных прав файловой системы. В продакшене эти настройки рекомендуется дополнять User, NoNewPrivileges и CapabilityBoundingSet, а для управления каталогами данных использовать StateDirectory.

🚪 Linux Ready | #практика

📂 Шпаргалка по архитектуре Ansible!

Ansible позволяет автоматизировать настройку серверов, развертывание приложений и управление инфраструктурой без установки агентов на управляемые узлы.

На картинке — схема архитектуры Ansible: взаимодействие управляющего узла с серверами по SSH, а также основные компоненты — Inventory, ansible.cfg и Playbook.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

❤️ Практика администрирования Linux — большой учебный проект по настройке и автоматизации серверной инфраструктуры!

В репозитории собраны пошаговые задания по безопасности системы, настройке сетей, RAID и файловых хранилищ, резервному копированию, журналированию и автоматизации с помощью Bash и Ansible. Особенно полезно, что есть готовые скрипты, конфигурации, инструкции на русском языке и автоматические проверки выполнения заданий.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Знали, что можно заставить многие Linux-программы создавать временные файлы в отдельном каталоге, не меняя их исходный код?

Обычно приложения используют /tmp, из-за чего бывает сложно понять, какие временные файлы создала конкретная программа.

Но многие утилиты и библиотеки учитывают переменную окружения TMPDIR:

tmp=$(mktemp -d)
TMPDIR="$tmp" ./myapp

Теперь программа, если она поддерживает TMPDIR, будет использовать указанный каталог для временных файлов.

После выполнения можно посмотреть, что осталось:

find "$tmp" -maxdepth 2 -type f

Это полезно при отладке сборок, генераторов, компиляторов и скриптов, которые создают промежуточные файлы.

Для автоматической очистки в Bash можно использовать обработчик завершения:

tmp=$(mktemp -d)
trap 'rm -rf -- "$tmp"' EXIT

TMPDIR="$tmp" ./myapp

Важно: TMPDIR — не механизм изоляции. Программы с жёстко заданными путями могут продолжать писать в /tmp или другие каталоги.

🔥 TMPDIR позволяет быстро выделить программе собственное пространство для временных файлов, упростить диагностику и контролировать очистку без контейнеров и изменений в коде.

🚪 Linux Ready | #совет

Сервис не видит изменения в файле после его замены?

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

В линукс файловый дескриптор ссылается на открытый файловый объект, а не на строковый путь. Если файл заменили через rename(), процесс с уже открытым дескриптором продолжит работать со старым inode.

Проверим это на практике. Создадим файл:

echo "version=1" > /tmp/app.conf

Запустим питон-процесс, который откроет файл один раз и будет перечитывать его через тот же дескриптор:

python3 - <<'PY'
import time

with open("/tmp/app.conf") as f:
    while True:
        f.seek(0)
        print(f.read().strip(), flush=True)
        time.sleep(2)
PY

В другом терминале подготовим новую версию и атомарно заменим файл:

echo "version=2" > /tmp/app.conf.new
mv /tmp/app.conf.new /tmp/app.conf

Несмотря на замену, питон продолжит выводить:

version=1

Посмотрим inode текущего файла:

stat -c '%i %n' /tmp/app.conf

Теперь найдём PID питон-процесса и проверим его дескрипторы:

sudo ls -l /proc/<PID>/fd/

Среди них можно обнаружить:

3 -> /tmp/app.conf (deleted)

Пометка (deleted) означает, что inode больше не имеет прежнего имени в файловой системе, но продолжает существовать благодаря открытым ссылкам.

Сравним inode открытого дескриптора и файла по пути:

sudo stat -Lc '%i %n' /proc/<PID>/fd/3
stat -c '%i %n' /tmp/app.conf

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

Найти открытые удалённые файлы можно через:

sudo lsof +L1

Команда показывает открытые файлы с количеством жёстких ссылок меньше единицы. Это также полезно при поиске удалённых логов, которые продолжают занимать место на диске.

Для устранения проблемы приложение должно закрыть старый дескриптор и повторно открыть файл по пути. В зависимости от реализации это может происходить при reload или только при полном перезапуске.

🔥 Атомарная замена через rename() гарантирует переключение имени файла, но не обновляет уже открытые файловые дескрипторы. При диагностике конфигураций, логов и файлов данных полезно сравнивать inode через stat и проверять /proc/<PID>/fd, прежде чем искать проблему в кэшировании.

🚪 Linux Ready | #практика

⚡️ Онлайн-митап IT_ONE: Между кодом и продом
 
Три прикладных доклада для тех, кто отвечает за стабильность инфраструктуры. Обсудим на встрече защиту Helm-чартов
от некорректных данных, научим писать надежные проверки
на helm-unittest и разберем развертывание собственной LLM-модели для всей команды.

Приглашаем разработчиков, DevOps-, QA- и SRE-инженеров, тимлидов и архитекторов.

12 ноября
18:00 (мск), онлайн
Регистрация: по ссылке
 
В программе митапа — три выступления:

1️⃣ Персональный ИИ своими руками.
Руслан Кашафутдинов расскажет, как развернуть свою ИИ-модель и работать без квот облачных сервисов.
2️⃣ Helm-чарты: когда они действительно нужны.
Виталий Перваков разберет защиту от некорректных данных и сравнит инструменты проверки конфигураций.
3️⃣ Стабильные unit-тесты для Helm-чартов.
Андрей Слатимов покажет, как с помощью helm-unittest находить ошибки шаблонизации и проверять обратную совместимость.

 
Приходи со своими рабочими вопросами — можно будет обсудить их с экспертами. Авторы лучших вопросов получат мерч IT_ONE: футболку, стикеры и плед.

📎 Всем зарегистрированным участникам после митапа отправим презентации спикеров и другие полезные материалы.

Регистрируйся до 11 ноября, 23:59 (мск)

Запускаем временные команды в Linux под управлением systemd!

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

В Linux есть полезный инструмент systemd-run, позволяющий запускать процессы в отдельных временных units без создания service-файлов.

Например, запустим dev-сервер:

systemd-run --user --scope \
  --unit=dev-server npm run dev

Команда создаёт отдельный scope в пользовательском systemd. Но есть нюанс: --scope сам по себе не гарантирует завершение процесса при закрытии терминала.

Для временных задач удобнее использовать transient service с ограничением времени:

systemd-run --user \
  --unit=temp-build \
  --working-directory="$PWD" \
  -p RuntimeMaxSec=10min \
  npm run build

Сборка запускается как отдельный сервис и по умолчанию выполняется асинхронно. Если она не завершится за 10 минут, systemd инициирует остановку сервиса.

Проверить состояние задачи можно без поиска PID:

systemctl --user status temp-build.service

А если процесс завис или больше не нужен, достаточно остановить unit. По умолчанию systemd завершит процессы в его cgroup согласно настройкам сервиса.

systemctl --user stop temp-build.service

Ещё одна полезная возможность — ограничение потребления памяти:

systemd-run --user \
  --unit=limited-build \
  --working-directory="$PWD" \
  -p MemoryMax=1G \
  npm run build

Лимит применяется ко всей cgroup сервиса, включая дочерние процессы. При превышении ограничения возможен OOM-kill. Для работы необходим доступный контроллер памяти cgroups.

Посмотреть логи задачи можно через journalctl:

journalctl --user -u limited-build.service -f

Команды предполагают работающий пользовательский systemd. Окружение transient service отличается от текущего shell: например, npm, установленный через nvm, может быть недоступен. Также имена units должны быть свободны при запуске.

🔥 Это удобно для сборок, тестов и временных фоновых задач: не нужно вручную управлять PID, перенаправлять вывод в файлы или писать отдельные service-файлы.

🚪 Linux Ready | #практика