👽 Проведи выходные с пользой, Игры которые прокачают знание команд в терминале весело и эффективно:

Terminus
Текстовая RPG от MIT: вы — новобранец Академии Магии, и каждое заклинание здесь — это команда Linux. Пройдите обучение, разгадайте тайны подземелий и отточите навык работы в консоли.

GameShell
Минималистичная головоломка прямо в терминале от Университета Савойи (Savoie Mont Blanc). Управляйте героем, применяя команды для решения задачек и прокладывая путь к победе.

Bashcrawl
Консольный рогалик: исследуйте процедурно генерируемые подземелья, сражайтесь с монстрами-мимиками и осваивайте базовые и продвинутые команды Bash, чтобы выжить и выбраться на поверхность.

Попробуйте всё — и изучение терминала превратится в настоящее приключение!

@linuxkalii

❓ Задача: "Исчезающие процессы"

На сервере с Linux (Ubuntu 22.04) установлен некий демон (например, mydaemon), который запускается через systemd unit и, согласно логам, должен работать постоянно.

❓ Но вот странность:

systemctl status mydaemon показывает, что сервис активен.

Однако при выполнении ps aux | grep mydaemon — процесса в списке нет.

top, htop, pgrep, pidof — тоже ничего не показывают.

Но при перезапуске systemd-сервиса (systemctl restart mydaemon) — в логах появляется запись о запуске, ошибок нет, а поведение не меняется.

Вопрос:

что происходит и как найти реальный процесс?

Подсказки:
Попробуйте посмотреть, какой тип сервиса указан в systemd unit-файле.

Изучите, куда уходит stdout/stderr.

Подумайте, может ли ExecStart запускать shell-обёртку, а не сам процесс.

Что покажет systemctl show -p MainPID mydaemon?

Подвох и решение:
Часто в unit-файле могут писать:

```ini
Type=simple
ExecStart=/bin/bash -c 'sleep 9999'```

Systemd считает, что bash — это основной процесс (MainPID), но он сразу завершается, передав выполнение sleep. Однако поскольку Type=simple, systemd не отслеживает дочерние процессы, и MainPID исчезает — ps и pgrep по имени mydaemon ничего не покажут, а дочерний процесс (sleep 9999) работает, но под другим именем.

Решение:

Либо указать Type=forking и использовать PIDFile.

Либо не использовать bash -c, а запускать нужный бинарь напрямую.

Либо использовать Type=exec (в systemd >240) или Type=notify с proper daemon tools.

✔️ Эскейп в «клетке» ограниченной оболочки: два классических приёма

Когда система кажется неприступной и администратор «залочил» вас в белом списке оболочек, не спешите сдаваться. Если среди разрешённых утилит есть vi/vim или less, они могут стать вашим ключом к свободе.

✨ 1. Волшебная интерактивная оболочка через Vim
Представьте, что у вас есть доступ к бинарям с SUID/GUID — и что в списке одобренных приложений значится сам Vim. Запустите его так:

vim -c ':!/bin/sh'

или

vim --cmd ':set shell=/bin/sh|:shell'

И вот, вы уже держите в руках полноценную интерактивную $-оболочку. Гуляйте по файловой системе, исследуйте /root и другие запретные зоны — всё это будет доступно, пока Vim остаётся в вашем распоряжении. 🥳

🌟 2. Плавный выход через Less
Укажем недостатков меньше, чем возможностей у less. Откройте любой файл, например:


less /etc/passwd

Затем просто наберите в самом less:

diff

!sh

После этого — вуаля! — перед вами окажется полноценная sh-оболочка. Этот трюк срабатывает везде, где допускается вызов less.

📌 Бонус: Python-эскейп
Если же в окружении есть Python, и вы мечтаете о ещё одном пути к свободе, выполните:

python -c 'import pty; pty.spawn("/bin/sh")'

Или, чтобы обойтись без интерактивного ввода:

python - <<<'import os; os.system("/bin/sh")'

Эти приёмы давно и прочно обосновались в арсенале пентестеров.

Сохраняйте их, добавляйте в свои бэклоги и применяйте на тестовых стендах!

@linuxkalii

🖥 20 полезных команд Linux

В арсенале любого опытного Linux‑администратора есть набор проверенных временем утилит: ls, cd, grep, find, ps, top и другие. Однако за пределами этой стандартной десятки скрываются настоящие «скрытые жемчужины» — мощные, но менее известные инструменты, способные упростить диагностику, автоматизацию и управление системой.

1️⃣ mtr (My Traceroute)

📋 Что делает: объединяет ping и traceroute, постоянно опрашивая каждый хоп и показывая статистику потерь и времени отклика.
💡 Пример:

mtr example.com

2️⃣ ss (Socket Statistics)

📋 Что делает: современная замена netstat. Быстро показывает TCP/UDP/RAW/UNIX‑сокеты и их состояние.
💡 Пример:

ss -tulnp

3️⃣ iotop

📋 Что делает: мониторинг дискового I/O в реальном времени, показывает процессы, активно читающие или пишущие на диск.
💡 Пример:

sudo iotop -o

4️⃣ nethogs

📋 Что делает: группирует сетевой трафик по процессам, позволяет быстро найти «трафик‑хищников».
💡 Пример:

sudo nethogs eth0

5️⃣ lsof (List Open Files)

📋 Что делает: показывает, какие файлы (включая сокеты и устройства) открыты процессами.
💡 Пример:

sudo lsof -i :80
sudo lsof /var/log/syslog

6️⃣ pgrep / pkill

📋 Что делает: ищет или убивает процессы по именам/атрибутам без парсинга ps | grep.
💡 Пример:

pgrep -u nginx
pkill -f "python my_script.py"

7️⃣ pstree

📋 Что делает: отображает дерево процессов с PID и связями «родитель → дочерний».
💡 Пример:

pstree -p

8️⃣ dstat

📋 Что делает: универсальный генератор статистики CPU, диска, сети, памяти, I/O в реальном времени.
💡 Пример:

dstat -tcdmn

9️⃣ atop

📋 Что делает: продвинутый мониторинг производительности с возможностью записи истории метрик.
💡 Пример:

atop
atop -r /var/log/atop/atop_20250418

🔟 multitail

📋 Что делает: позволяет «tail -f» сразу несколько лог‑файлов в одном терминале с разделёнными панелями.
💡 Пример:

multitail /var/log/nginx/access.log /var/log/nginx/error.log

1️⃣1️⃣ parallel (GNU Parallel)

📋 Что делает: выполняет команды параллельно, альтернатива xargs для многоядерных систем.
💡 Пример:

find . -name "*.jpg" | parallel convert {} {.}.png

1️⃣2️⃣ watch

📋 Что делает: периодически запускает команду и обновляет её вывод в реальном времени.
💡 Пример:

watch -n 1 'ss -an | grep ESTABLISHED | wc -l'

1️⃣3️⃣ script / scriptreplay

📋 Что делает: записывает терминальную сессию (ввод/вывод) в файл; scriptreplay воспроизводит её.
💡 Пример:

script my_session.log
exit
scriptreplay my_session.log

1️⃣4️⃣ lsblk

📋 Что делает: показывает блочные устройства (диски, разделы, LVM) в древовидном формате.
💡 Пример:

lsblk -f

1️⃣5️⃣ getent

📋 Что делает: получает записи из NSS‑источников (passwd, group, hosts и т.д.), включая LDAP/NIS.
💡 Пример:

getent passwd username
getent hosts google.com

1️⃣6️⃣ chage

📋 Что делает: управляет политиками устаревания паролей пользователей.
💡 Пример:

sudo chage -l username
sudo chage -M 90 username

1️⃣7️⃣ column

📋 Что делает: форматирует текстовый ввод в аккуратные колонки.
💡 Пример:

mount | column -t

1️⃣8️⃣ dig (Domain Information Groper)

📋 Что делает: мощный DNS‑клиент для гибких запросов к DNS‑серверам.
💡 Пример:

dig google.com MX +short
dig @8.8.8.8 example.org A

1️⃣9️⃣ dpkg -L / rpm -ql

📋 Что делает: показывает файлы, установленные пакетом (Debian/Ubuntu или RHEL/CentOS).
💡 Пример:

dpkg -L nginx-core
rpm -ql httpd

2️⃣0️⃣ journalctl

📋 Что делает: запрашивает логи из systemd‑журнала с гибкими фильтрами по юнитам, времени и приоритетам.
💡 Пример:

journalctl -u nginx.service -f
journalctl --since "1 hour ago"

✔️ Подробнее

@linuxkalii

✔️ Задача: "Найди ошибку в скрипте запуска сервиса на Linux"

🧩 Условие:

Перед вами скрипт start_server.sh, который должен запускать серверное приложение в фоне и писать логи.
Вот его код:

#!/bin/bash

APP_PATH="/opt/myapp/server"
LOG_PATH="/var/log/myapp/server.log"

nohup $APP_PATH > $LOG_PATH 2>&1 &
echo $! > /var/run/myapp.pid

Однако:

- Иногда сервер не стартует.
- Иногда сервер стартует, но процесс через несколько секунд исчезает.
- Иногда лог-файл пустой или обрывается посередине.

Требуется:

- Найти все ошибки в этом скрипте.
- Объяснить, почему они происходят.
- Предложить исправленную версию скрипта.

---

▪️ Подсказки:

- Обратите внимание на работу nohup, выводы в лог, управление путями, записи PID, обработку ошибок.
- Помните про особенности запуска фоновых процессов в Bash.
- Подумайте о правах доступа к папкам /var/log и /var/run.

---

🔜 Что оценивается:

- Глубокое понимание системных процессов Linux.
- Умение выявлять скрытые ошибки запуска фоновых сервисов.
- Правильное использование команд оболочки для стабильного старта приложений.
- Практическое мышление в реальных DevOps-ситуациях.

---

✅ Разбор ошибок:

▪️ Ошибка 1: Неверное использование $APP_PATH

- Просто указывая путь, мы не проверяем, существует ли файл, исполняемый ли он.
- Если $APP_PATH не существует или не имеет права на исполнение, nohup запустится, но процесс быстро "умрет".

▪️ Ошибка 2: Отсутствие проверки успешности запуска

- Скрипт сразу пишет $! в PID-файл, не проверяя, действительно ли процесс стартовал корректно.

▪️ Ошибка 3: Проблемы с nohup

- Если директория /var/log/myapp не существует или нет прав на запись, то перенаправление в $LOG_PATH вызовет мгновенный крах nohup.

▪️ Ошибка 4: PID-файл создается без проверки

- Если директория /var/run/myapp не существует, команда echo $! > /var/run/myapp.pid провалится молча, PID будет потерян.

▪️ Ошибка 5: Нехватка "обезопасивания" путей

- Прямое использование переменных в Bash без кавычек (`"$APP_PATH"`, `"$LOG_PATH"`) может вызвать ошибки, если в пути есть пробелы.

---

▪️ Исправленная версия скрипта:

#!/bin/bash

APP_PATH="/opt/myapp/server"
LOG_DIR="/var/log/myapp"
RUN_DIR="/var/run/myapp"
LOG_PATH="$LOG_DIR/server.log"
PID_FILE="$RUN_DIR/myapp.pid"

# Проверяем наличие исполняемого файла
if [ ! -x "$APP_PATH" ]; then
  echo "Ошибка: приложение $APP_PATH не найдено или не имеет права на исполнение."
  exit 1
fi

# Создаём каталоги при необходимости
mkdir -p "$LOG_DIR" "$RUN_DIR"

# Запускаем приложение
nohup "$APP_PATH" >> "$LOG_PATH" 2>&1 &

APP_PID=$!

# Небольшая пауза для стабильного старта
sleep 1

# Проверяем, жив ли процесс
if ps -p $APP_PID > /dev/null; then
  echo $APP_PID > "$PID_FILE"
  echo "Сервер успешно запущен с PID $APP_PID."
else
  echo "Ошибка: процесс не запустился корректно. См. лог $LOG_PATH."
  exit 1
fi

🔖 Ключевые улучшения:

- Проверка наличия исполняемого файла.
- Безопасное создание директорий перед записью логов и PID-файла.
- Проверка успешного старта процесса перед записью PID.
- Кавычки вокруг переменных для защиты от ошибок в путях.
- Вывод информативных ошибок.

📌 Дополнительные вопросы на собеседовании:

- Почему лучше использовать exec в скриптах демонизации?
- Чем отличается nohup от запуска через systemd?
- Как улучшить управление процессом, чтобы обрабатывать перезапуски и сбои?

@linuxkalii

🔥 Полезный совет: Мониторинг Linux в реальном времени — не жди, пока будет поздно!


🔜 Почему важно?
Если система начинает тормозить или странно себя вести, быстрое выявление проблем (нагрузка на CPU, память, диск, сеть) может спасти сервер или рабочую машину от падения.

---

**Топ-5 инструментов для реального мониторинга в Linux:**

▪️ htop — улучшенная версия top

- Красивое цветное отображение процессов.
- Быстрая сортировка по нагрузке на CPU, память.
- Можно убивать или приостанавливать процессы прямо из интерфейса.

sudo apt install htop
htop

▪️ iotop — мониторинг ввода-вывода дисков

- Показывает, какие процессы нагружают диск.
- Полезно при тормозах связанных с дисковыми операциями.

sudo apt install iotop
sudo iotop

▪️ iftop — сетевой мониторинг в реальном времени

- Отображает, кто сколько трафика потребляет.
- Идеально для поиска сетевых утечек или подозрительной активности.

sudo apt install iftop
sudo iftop

▪️ glances — комплексный мониторинг системы

- Объединяет CPU, память, диск, сеть в одном удобном окне.
- Адаптивный интерфейс, много деталей.

sudo apt install glances
glances

▪️ dstat — мониторинг ресурсов по категориям

- Универсальный инструмент для анализа CPU, сети, ввода-вывода, использования памяти и т.д.

sudo apt install dstat
dstat

---

Бонус:
Если хочешь красивый мониторинг в браузере → попробуй netdata:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

---

Вывод:
Настоящий мастер Linux постоянно мониторит систему, а не ищет проблему только после падения.

---

🚨 Уязвимость в ядре Linux: повышение привилегий через VSOCK (CVE-2025-21756)

Что случилось?
Обнаружена уязвимость «use-after-free» в реализации AF_VSOCK (виртуальных сокетов) ядра Linux, которая позволяет локальному злоумышленнику получить права root.


🔜 Ключевые факты

- Идентификатор: CVE-2025-21756
- Тип уязвимости: Use-After-Free в функции удаления сокета VSOCK
- Влияние: выполнение произвольного кода с правами root на уязвимых системах
- Рабочий эксплоит: доказан на ядре 6.6.75 (для других версий требуется правка кода эксплоита)

Затронутые версии

- Все ядра Linux до 6.14 (включительно)
- Стабильные ветки 6.12.16, 6.6.79, 6.1.131 и ранее
- Корпоративные сборки: RHEL, SUSE/openSUSE, Ubuntu, Debian 12 (уже исправлены)
- Debian 11 — до сих пор уязвим

Механизм уязвимости

1. При переназначении транспорта для AF_VSOCK вызывается vsock_remove_sock().
2. Далее vsock_remove_bound() неправильно уменьшает счётчик ссылок на объект сокета.
3. Счётчик становится равным нулю, ядро освобождает память, хотя объект ещё используется.
4. Локальный пользователь получает доступ к освобождённой памяти и может выполнить произвольный код с привилегиями ядра.

👽 Как защититься

1. Обновите ядро до версии 6.14 или выше.
2. Установите последние февральские/мартовские патчи для веток 6.12.16, 6.6.79 и 6.1.131.
3. На дистрибутивах RHEL, SUSE/openSUSE, Ubuntu и Debian 12 убедитесь, что установлены свежие пакеты ядра.
4. В Debian 11 — либо обновитесь до Debian 12, либо вручную соберите патченный пакет ядра.

❗ **Важно:** если на системе используются контейнеры или виртуальные машины с VSOCK, немедленно примените обновления — эксплоит работает локально и не требует дополнительных разрешений.

⚫️ Эксплоит

@linuxkalii

📌 Задача: «Загадочный рост нагрузки в полночь»

Каждую ночь, ровно в 00:00, сервер на Linux (Ubuntu 22.04 LTS) начинает внезапно потреблять повышенное количество ресурсов (CPU и RAM).

Через 5-10 минут нагрузка сама возвращается в норму, не оставляя очевидных следов. В течение дня ситуация стабильная и не проявляется.

📌 Администратору поступила задача:

- Определить причину еженощного кратковременного всплеска нагрузки.

- Выявить конкретный процесс или задачи, которые запускаются.

- Предложить решение для оптимизации или полного устранения проблемы.

🧩 Ограничения и подсказки:
Логи системного планировщика (cron) почему-то пусты или очищаются.

На сервере включена система мониторинга systemd.

Возможны скрытые задачи в системных директориях (/etc/cron.*, /var/spool/cron).

Используются контейнеры Docker (возможно, что-то происходит в контейнерах).

Пользовательские процессы не явно обозначают себя в списке ps aux.

🛠️ Какие команды и подходы следует использовать?

Шаг 1: Анализ нагрузки

htop
vmstat 1
sar -q

Шаг 2: Поиск подозрительных процессов

ps aux --sort=-%cpu | head -n 20
ps aux --sort=-%mem | head -n 20
pidstat -u 1 10

Шаг 3: Исследование задач по времени запуска

journalctl --since "23:59" --until "00:10"
systemctl list-timers
grep -rnw '/etc/' -e '00:00'

Шаг 4: Проверка Docker-контейнеров

docker stats
docker ps -a --format "{{.ID}} {{.Image}} {{.Command}} {{.RunningFor}}"
docker inspect $(docker ps -q) --format '{{ .Id }}: {{ .State.StartedAt }}'

Шаг 5: Анализ сетевой активности и дисковой активности

iftop -nNP
iotop -oPa

✅ Решение и итог:

Определить процесс или скрытую задачу.

Установить, кто или что запускает этот процесс.

Удалить, оптимизировать или перенастроить планировщик (cron, systemd timer) или Docker-контейнер, чтобы устранить кратковременные скачки нагрузки.

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

@linuxkalii