Когда система кажется неприступной и администратор «залочил» вас в белом списке оболочек, не спешите сдаваться. Если среди разрешённых утилит есть 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👍15❤6
В арсенале любого опытного 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.log1️⃣4️⃣ lsblk
📋 Что делает: показывает блочные устройства (диски, разделы, LVM) в древовидном формате.
💡 Пример:
lsblk -f1️⃣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 username1️⃣7️⃣ column
📋 Что делает: форматирует текстовый ввод в аккуратные колонки.
💡 Пример:
mount | column -t1️⃣8️⃣ dig (Domain Information Groper)
📋 Что делает: мощный DNS‑клиент для гибких запросов к DNS‑серверам.
💡 Пример:
dig google.com MX +short
dig @8.8.8.8 example.org A1️⃣9️⃣ dpkg -L / rpm -ql📋 Что делает: показывает файлы, установленные пакетом (Debian/Ubuntu или RHEL/CentOS).
💡 Пример:
dpkg -L nginx-core
rpm -ql httpd2️⃣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🔥25❤6🎉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
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
👍9❤3🔥3
🧩 Условие:
Перед вами скрипт
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
👍49❤12🔥7👎2
⚠️ Критическая уязвимость в NPM-пакете xrpl.js: бэкдор для кражи криптоключей.
Официальная библиотека для работы с криптовалютой XRP оказалась скомпрометирована — злоумышленники внедрили вредоносный код в версии 2.14.2 и 4.2.1-4.2.4. Под видом функции проверки ключей
Атака длилась менее суток (21-22 апреля), но за это время уязвимые версии успели скачать 165 тысяч раз. Подозревается компрометация аккаунта мейнтейнера через фишинг. Разработчики XRP Ledger оперативно выпустили патч в версиях 4.2.5 и 2.14.3.
🔗 Ссылка - *клик*
@linuxkalii
Официальная библиотека для работы с криптовалютой 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🔥5❤4
Если система начинает тормозить или странно себя вести, быстрое выявление проблем (нагрузка на 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🔥13❤11👎1😁1
🔒 Microsoft ограничила работу своего C/C++ расширения в форках VS Code
Пользователи альтернативных редакторов на базе VS Code столкнулись с блокировкой проприетарного расширения для C/C++ от Microsoft. После обновления до версии 1.24.5 плагин начал выдавать ошибку, сообщая о возможности работы только в официальных продуктах Microsoft — VS Code, Visual Studio и связанных сервисах.
Ситуация вновь поднимает вопрос о зависимости open-source проектов от проприетарных дополнений. Пока единственное решение для тех, кому критично расширение от Microsoft — откат на старую версию и отключение автообновлений.
🔗 Ссылка - *клик*
@linuxkalii
Пользователи альтернативных редакторов на базе VS Code столкнулись с блокировкой проприетарного расширения для C/C++ от Microsoft. После обновления до версии 1.24.5 плагин начал выдавать ошибку, сообщая о возможности работы только в официальных продуктах Microsoft — VS Code, Visual Studio и связанных сервисах.
Ситуация вновь поднимает вопрос о зависимости open-source проектов от проприетарных дополнений. Пока единственное решение для тех, кому критично расширение от Microsoft — откат на старую версию и отключение автообновлений.
🔗 Ссылка - *клик*
@linuxkalii
😁28👍12😢5❤3🔥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
Что случилось?
Обнаружена уязвимость «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👍23❤8😱2
Два месяца подряд любой мог получить доступ к более чем 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👍18❤6🔥3
📌 Задача: «Загадочный рост нагрузки в полночь»
Каждую ночь, ровно в 00:00, сервер на Linux (Ubuntu 22.04 LTS) начинает внезапно потреблять повышенное количество ресурсов (CPU и RAM).
Через 5-10 минут нагрузка сама возвращается в норму, не оставляя очевидных следов. В течение дня ситуация стабильная и не проявляется.
📌 Администратору поступила задача:
- Определить причину еженощного кратковременного всплеска нагрузки.
- Выявить конкретный процесс или задачи, которые запускаются.
- Предложить решение для оптимизации или полного устранения проблемы.
🧩 Ограничения и подсказки:
Логи системного планировщика (cron) почему-то пусты или очищаются.
На сервере включена система мониторинга systemd.
Возможны скрытые задачи в системных директориях (/etc/cron.*, /var/spool/cron).
Используются контейнеры Docker (возможно, что-то происходит в контейнерах).
Пользовательские процессы не явно обозначают себя в списке ps aux.
🛠️ Какие команды и подходы следует использовать?
Шаг 1: Анализ нагрузки
Шаг 2: Поиск подозрительных процессов
Шаг 3: Исследование задач по времени запуска
Шаг 4: Проверка Docker-контейнеров
Шаг 5: Анализ сетевой активности и дисковой активности
✅ Решение и итог:
Определить процесс или скрытую задачу.
Установить, кто или что запускает этот процесс.
Удалить, оптимизировать или перенастроить планировщик (cron, systemd timer) или Docker-контейнер, чтобы устранить кратковременные скачки нагрузки.
Такая задача заставляет администратора комплексно проверить сервер и выявить скрытые или нетипичные источники нагрузки, проявить внимательность к деталям и глубокие знания инструментов анализа Linux.
@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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍106🔥12❤7😱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
В новом релизе Libreboot добавлена поддержка плат Acer Q45T-AM/G43T-AM3, обновлены инструменты сборки (Debian 12.10, GCC 15) и компоненты. Canoeboot, как более строгая версия, исключает все бинарные вставки, сохраняя совместимость лишь с ограниченным набором устройств — от старых ThinkPad до PlayStation 1.
🔗 Ссылка - *клик*
@linuxkalii
👍31🔥9❤5
# 🔐 Современный алгоритм шифрования: 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:
✅ Обратите внимание:
key — секретный ключ (должен храниться в секрете).
iv (инициализационный вектор) — нужен для дешифрования, его можно передавать открытым текстом.
Используется padding, чтобы текст был кратен размеру блока.
🔍 Почему AES?
Безопасен — нет известных практических атак.
Быстрее DES и 3DES.
Широко поддерживается во всех современных протоколах (TLS, SSH, VPN, ZIP, WhatsApp).
⚠️ Важные рекомендации
Никогда не используйте один и тот же ключ и IV для нескольких сообщений.
Храните ключи в защищённом хранилище.
При передаче данных используйте безопасные протоколы.
➡️ AES — это золотой стандарт симметричного шифрования. Его применяют везде: от HTTPS и VPN до мессенджеров.
С помощью Python и библиотеки PyCryptodome его можно легко интегрировать в свои проекты.
В современном мире данных шифрование — это не роскошь, а необходимость. От защиты банковских транзакций до хранения паролей — всё держится на надёжных алгоритмах.
Один из самых популярных и надёжных стандартов сегодня — 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 для нескольких сообщений.
Храните ключи в защищённом хранилище.
При передаче данных используйте безопасные протоколы.
С помощью Python и библиотеки PyCryptodome его можно легко интегрировать в свои проекты.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍40❤31🔥8😁2
@linuxkalii
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20🔥10👎7👍5
🧩 Задача для Linux-администраторов: "Исчезающий процесс"
📖 Описание задачи
В системе неожиданно появилась служба, которая запускается автоматически через 10 минут после удаления её бинарного файла и убийства процесса.
Особенности:
- Бинарный файл процесса каждый раз появляется в разной директории внутри
- Имя процесса каждый раз разное (например,
- При запуске процесс слушает TCP-порт на случайном высоком порту (>=1024).
- Порт каждый раз динамически выбирается и кодируется в base64, чтобы затруднить прямую идентификацию.
- Бинарный файл зашифрован и расшифровывается процессом в оперативной памяти перед запуском.
- После удаления файла и убийства процесса через 10 минут процесс появляется снова.
📝 Ваша задача:
1. Определить источник "реинкарнации" процесса.
2. Найти механизм автозапуска и зашифрованного хранения бинарника.
3. Остановить автоматический запуск навсегда без перезагрузки системы.
4. Задокументировать шаги поиска и устранения проблемы.
🕵️ Решение (разбор шаг за шагом)
1️⃣ Найти процесс и порт
Поскольку порт зашифрован (base64), стандартный
Запоминаем PID и порт. Чтобы проверить порт в base64:
(найденный зашифрованный порт в коде процесса может совпадать)
2️⃣ Посмотреть открытые файлы и дескрипторы
Чтобы понять, где запускается исполняемый файл:
Смотрим дескрипторы
Если исполняемый файл удалён, но процесс его держит открытым, можно восстановить его через
3️⃣ Отследить родителя процесса
Проверим родительский процесс:
➡️ Нужно понять, кто создаёт зашифрованный бинарник и запускает процесс.
4️⃣ Отследить создание файла в /tmp
Используем
или
Когда файл создастся → смотрим, какой процесс его записал:
5️⃣ Проверить автозагрузку
Проверяем cron:
Проверяем systemd:
Проверяем init.d, rc.local, profile.d:
6️⃣ Проанализировать процесс запуска
Раз шифрование происходит в памяти:
- Проверяем аргументы запуска процесса через
- Используем
- Проверяем, не использует ли процесс
📝 Возможное объяснение
- Основной процесс шифрует бинарник и хранит его (например, в `/etc/.hidden/enc.bin`).
- Через cron job или systemd timer каждые 10 минут запускается дешифровщик, который:
- Расшифровывает бинарник в
- Запускает процесс
- Запущенный процесс открывает порт, шифрует его номер (base64) и выводит только в своих аргументах/переменных окружения.
- Процесс удаляет бинарник сразу после запуска, оставляя только дескриптор в памяти.
✅ Как остановить навсегда (без перезагрузки):
1. Найти и остановить родительский процесс (watchdog/дешифровщик):
2. Удалить механизм автозапуска:
- Удалить запись из cron.
-
- Удалить файлы-инициаторы из
3. Найти и удалить зашифрованный бинарник:
или поиск по дате изменения:
4. Очистить /tmp, /dev/shm, /run от временных файлов.
📖 Описание задачи
В системе неожиданно появилась служба, которая запускается автоматически через 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🔥22❤16
🚀 Linux прощается с эпохой 486-х процессоров: мэйнтейнеры ядра Linux готовятся к историческому изменению — полному удалению поддержки данной линейки из кодовой базы. Инициатива исходит от самого Линуса Торвальдса, который считает, что поддержка 30-летних чипов давно стала обузой для разработчиков.
Удаление 14 тысяч строк кода упростит архитектуру ядра и снизит нагрузку на сопровождающих. Интересно, что встраиваемые системы на базе Quark не пострадают — они используют модернизированные 486-совместимые ядра с поддержкой современных инструкций.
🔗 Ссылка - *клик*
@linuxkalii
Удаление 14 тысяч строк кода упростит архитектуру ядра и снизит нагрузку на сопровождающих. Интересно, что встраиваемые системы на базе Quark не пострадают — они используют модернизированные 486-совместимые ядра с поддержкой современных инструкций.
🔗 Ссылка - *клик*
@linuxkalii
🤔37👍25🔥5🥰4😢3👎2
🐧 Задача-ловушка: Почему служба не видит обновлённый файл?
Условие:
Вы обновили конфигурационный файл для популярного сервиса (например, `nginx`), изменив несколько параметров. Затем вы перезапустили сервис:
Однако после рестарта сервис всё ещё использует старые параметры из старого конфига, хотя проверка:
показывает, что файл точно обновлён.
Вы проверили права, синтаксис конфига (`nginx -t` выдаёт OK), SELinux, AppArmor — всё в норме.
❓ Вопрос:
Что могло пойти не так? Почему сервис использует старый конфиг, хотя файл обновлён и процесс был перезапущен?
---
🔍 Подсказка:
Недавно на сервере был проведён атомарный деплой конфига с помощью такой команды:
---
✅ Разбор:
💥 Ловушка:
На первый взгляд всё выглядит правильно, но вот ключевой момент:
Linux (и systemd) работают с inodes, а не с именами файлов напрямую.
Когда вы делаете:
```bash
mv /tmp/new_nginx.conf /etc/nginx/nginx.conf
```
это не заменяет содержимое файла. Это заменяет inode файла по данному имени, то есть создаётся новый файл с новым inode, а старый файл с тем же именем удаляется.
Если ваш сервис (например, `nginx`) запущен под присмотром systemd с включённым ProtectSystem или иными security-механизмами (или даже через старый init-скрипт), при перезапуске сервис может запускаться с открытым файловым дескриптором старого файла или в chroot-окружении, где старый inode остаётся привязанным.
В результате:
- показывает новый файл (новый inode по тому же имени).
- Сервис по факту читает старый файл, который всё ещё «жив» для процессов ядра через старый дескриптор.
---
🔧 Как проверить:
1️⃣ Посмотреть inode текущего файла:
```bash
ls -li /etc/nginx/nginx.conf
```
2️⃣ Посмотреть, какой inode был открыт сервисом:
```bash
lsof -p $(pidof nginx) | grep nginx.conf
```
Вы увидите, что процесс всё ещё держит старый inode.
---
🛠 Как исправить:
• После замены файла через рекомендуется не просто перезапустить сервис, а полностью остановить и запустить заново:
```bash
systemctl stop nginx
systemctl start nginx
```
или использовать , если поддерживается:
```bash
nginx -s reload
```
Это гарантирует, что дескрипторы будут закрыты и процесс откроет новый файл с новым inode.
---
✅ Вывод:
• В Linux имя файла — это просто ссылка на inode.
• Замена файла через не заменяет содержимое «на лету» для уже работающих процессов.
• Даже после systemd или скрипты могут не освободить старый дескриптор, если используются специфические модули, overlayfs или другие хитрости.
💡 Бонус-вопрос:
Почему
@linuxkalii
Условие:
Вы обновили конфигурационный файл для популярного сервиса (например, `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- Сервис по факту читает старый файл, который всё ещё «жив» для процессов ядра через старый дескриптор.
---
🔧 Как проверить:
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💡 Бонус-вопрос:
Почему
tail -f /etc/nginx/nginx.conf после mv может перестать работать корректно, и как сделать так, чтобы отслеживание файла продолжалось после замены?@linuxkalii
👍46🔥17❤7😁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
📟 В 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