👾 Новые атаки Spectre-v2: Training Solo обходит защиту Intel. Исследователи из Амстердамского свободного университета обнаружили серию уязвимостей в процессорах Intel, связанных с атаками Spectre-v2. Метод, получивший название Training Solo, позволяет обходить механизмы изоляции памяти, такие как IBPB и eIBRS, и извлекать данные из ядра или гипервизора со скоростью до 17 КБ/с**.

В отличие от классических атак Spectre, Training Solo использует не подконтрольный злоумышленнику код, а уже существующие фрагменты в привилегированных областях. Эксплуатация возможна благодаря аппаратным уязвимостям CVE-2024-28956 и CVE-2025-24495, затрагивающим процессоры Intel от Coffee Lake до Lunar Lake.

Intel уже выпустила обновление микрокода с новой инструкцией IBHF, а в Linux добавлены патчи для блокировки атак через cBPF. AMD и ARM заявили, что их современные процессоры не подвержены угрозе.

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

@linuxkalii

Читать полностью…

🕵️‍♂️ API-s-for-OSINT — каталог API для разведки по открытым источникам

Если ты занимаешься OSINT, кибербезопасностью или просто хочешь автоматизировать сбор данных — этот репозиторий станет для тебя настоящей сокровищницей.

📦 Что внутри:
Каталог разбит по тематикам, в каждой — список полезных API с описанием и ссылками. Вот лишь малая часть:

• Поиск устройств и IP: Shodan, Censys, Netlas
• Проверка email и доменов: WhoisXML, Kickbox
• Телефонные API: Numverify, Twilio
• Геолокация: Google Geocoding, Zipcodebase
• Даркнет и утечки: Onion Lookup, Darksearch
• Социальные сети, блокчейн, хэши, Wi-Fi и многое другое

🧠 Как использовать:
• Автоматизация с Python, Bash, Telegram-ботами
• Проверка подозрительных email и IP
• Интеграция в OSINT-дашборды или Google Sheets
• Быстрый доступ к API через curl или Postman

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

🔗 Ссылка

@linuxkalii

Читать полностью…

🫡 Без обид, Линус Торвальдс… но этот человек — величайший гик современности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@linuxkalii

Читать полностью…

🚀 Linux прощается с эпохой 486-х процессоров: мэйнтейнеры ядра Linux готовятся к историческому изменению — полному удалению поддержки данной линейки из кодовой базы. Инициатива исходит от самого Линуса Торвальдса, который считает, что поддержка 30-летних чипов давно стала обузой для разработчиков.

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

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

@linuxkalii

Читать полностью…

🧩 Задача для 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 от временных файлов.

Читать полностью…

# 🔐 Современный алгоритм шифрования: 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 его можно легко интегрировать в свои проекты.

Читать полностью…

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

Каждую ночь, ровно в 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

Читать полностью…

🚨 Уязвимость в ядре 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

Читать полностью…

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


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

---

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

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

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

sudo apt install htop
htop

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

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

sudo apt install iotop
sudo iotop

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

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

sudo apt install iftop
sudo iftop

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

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

sudo apt install glances
glances

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

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

sudo apt install dstat
dstat

---

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

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

---

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

---

Читать полностью…

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

🧩 Условие:

Перед вами скрипт 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

Читать полностью…

🖥 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

Читать полностью…

🤖 Исследователи обнаружили тревожный тренд: ИИ-ассистенты вроде ChatGPT и Gemini всё чаще предлагают код с несуществующими зависимостями. Злоумышленники быстро адаптировались — они регистрируют эти галлюцинированные названия в PyPI и NPM, наполняя их вредоносным кодом.

Под особой угрозой разработчики, практикующие vibe-coding — бездумное копирование ИИ-подсказок. Некоторые фейковые пакеты выглядят убедительно: имеют документацию, GitHub-репозитории и даже блоги-однодневки.

‼️ Фонд Python называет эту тактику «слопсквоттинг» (от *slop* — «мусорный вывод ИИ») и усиливает защиту репозиториев. Пока главная рекомендация — вручную проверять каждую зависимость, даже если её рекомендует ИИ.

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

@linuxkalii

Читать полностью…

🌐 Tor Browser 14.5 — крупное обновление для мобильных и десктоп-платформ. После полугода разработки выпущена новая версия любимого всеми анонимного браузера на базе Firefox 128 ESR.

Особенность релиза — усиленная защита от цифрового фингерпринтинга. Браузер не просто блокирует трекеры, но и камуфлирует системные параметры, нейтрализуя 15+ Web-API. При этом улучшена диагностика подключений — теперь лог операций обновляется в реальном времени без перезагрузки интерфейса.

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

@linuxkalii

Читать полностью…

🛡️ CVE обретает стабильность: возобновление финансирования и создание независимого фонда

После недели неопределённости Министерство внутренней безопасности США продлило контракт с MITRE на поддержку базы CVE — фундаментальной системы идентификации уязвимостей, используемой всеми от Apache до Google. Но главная новость — анонс CVE Foundation, некоммерческой организации, которая возьмёт на себя долгосрочное управление проектом, устранив зависимость от государственного финансирования.

Этот шаг стал результатом годовой работы коалиции членов CVE Board (включая представителей Linux Foundation, Google и Red Hat), обеспокоенных глобальной зависимостью инфраструктуры кибербезопасности от единственного источника. Фонд сохранит существующую систему с 453 CNA-участниками, но добавит прозрачности в процесс управления.

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

@linuxkalii

Читать полностью…

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

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

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

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

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

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

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

Вопрос:

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

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

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

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

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

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

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

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

Решение:

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

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

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

Читать полностью…

💥 В даркнете появилась база с данными 89 млн аккаунтов Steam — возможная утечка из Twilio

На одной из даркнет-площадок выставлен на продажу файл, содержащий якобы 89 миллионов записей пользователей Steam — это около двух третей всех аккаунтов на платформе.

Продавец с ником Machine1337 запросил $5000 за доступ к базе и опубликовал примерку из 3000 строк в качестве доказательства.

Содержимое файла включает:

- SMS-сообщения с одноразовыми кодами Steam Guard

- номера телефонов, на которые были отправлены эти коды

По оценкам экспертов, утечка вряд ли произошла со стороны Valve — куда более вероятной выглядит компрометация облачного провайдера Twilio, который занимается отправкой SMS для двухфакторной аутентификации.

📌 Если у вас включён Steam Guard через мобильное приложение, серьёзных причин для беспокойства нет — коды, отправленные по SMS, считаются менее защищённым методом.

@linuxkalii

Читать полностью…

🧠 Задача для продвинутых Linux-администраторов: “Служба-зомби и ловушка systemd”

📘 Условие

У тебя есть systemd unit-файл /etc/systemd/system/fake-backup.service:

[Unit]
Description=Fake Backup Daemon
After=network.target

[Service]
ExecStart=/usr/local/bin/fake-backup.sh
Type=forking
PIDFile=/var/run/fake-backup.pid
Restart=always

[Install]
WantedBy=multi-user.target

А вот скрипт fake-backup.sh:

#!/bin/bash
echo $$ > /var/run/fake-backup.pid
sleep 300

Ты выполняешь команды:

systemctl daemon-reload
systemctl enable fake-backup
systemctl start fake-backup

И через несколько секунд команда:

systemctl status fake-backup

показывает:

• active (exited)
• или в логах: Main PID exited, but service still running.
• или PID не соответствует реальному процессу

❓ Вопрос

1) Почему systemd считает службу завершённой?
2) Что не так с этим скриптом и unit-файлом?
3) Как исправить поведение, чтобы служба отслеживалась корректно и перезапускалась?

✅ Разбор и подвох

💣 Проблема №1: Type=forking требует форка

Type=forking говорит systemd:
> «Я ожидаю, что процесс ExecStart форкнется, и его родитель завершится. Я буду отслеживать дочерний PID.»

Но в нашем случае fake-backup.sh не форкается, а просто пишет свой PID и спит.

Что происходит:
• systemd запускает скрипт
• скрипт не форкается → родитель завершился → systemd считает службу завершённой

💥 Проблема №2: PIDFile не спасает

Даже если ты пишешь PIDFile, systemd не может точно отследить процесс, если:

• PID-файл создаётся слишком поздно
• процесс не демонится правильно
• нет настоящего двойного fork и setsid

✅ Правильные варианты

🔧 Вариант 1: изменить тип службы

Самый простой путь:

```ini
[Service]
Type=simple
ExecStart=/usr/local/bin/fake-backup.sh
Restart=always
```

Тогда systemd просто будет держать скрипт открытым и считать его работающим.

🔧 Вариант 2: сделать реальный daemon

Переделай скрипт, чтобы он демонизировался корректно, например:

```bash
#!/bin/bash
(
echo $$ > /var/run/fake-backup.pid
exec sleep 300
) &
```

Или используй `daemon`, `start-stop-daemon`, или пиши на C с двойным fork.

🎯 Проверка

```bash
systemctl status fake-backup
ps aux | grep fake-backup
```

Если `systemd` отслеживает PID правильно — всё работает.
Если служба переходит в `exited`, то systemd считает, что она завершилась.

⚠️ Подвох

Многие считают, что `Type=forking` — это просто "для фонового режима".
Но на самом деле он требует **корректного поведения демона**, иначе systemd не будет понимать, что с ним происходит.

Поэтому:

• не используй `forking` без настоящего демонизирования
• simple — безопасный тип для большинства скриптов

@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 показывает новый файл (новый 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

Читать полностью…

🔍 Linkook — инструмент OSINT для поиска связанных аккаунтов

Linkook — это мощный инструмент для автоматического поиска связанных аккаунтов в соцсетях и связанных email по одному username. Полезен для OSINT-расследований, аудита и мониторинга цифрового следа.

▪ Основные возможности
• Поиск аккаунтов по заданному username на множестве популярных платформ
• Рекурсивное обнаружение альтернативных никнеймов и связанных аккаунтов
• Проверка email на утечки через HudsonRock’s Cybercrime Intelligence Database или API Have I Been Pwned
• Экспорт данных в JSON (совместим с Neo4j для визуализации графа связей)

▪ Установка

# Быстрая установка через pipx
pipx install linkook

# Или установка из исходников
git clone https://github.com/JackJuly/linkook
cd linkook
python setup.py install

▪ Быстрый старт и ключевые опции

linkook <username>
• --show-summary — вывод сводки после завершения сканирования
• --concise — компактный вывод
• --check-breach — проверка email через HudsonRock DB (отмечает «(breach detected)»)
• --hibp — проверка через Have I Been Pwned (API-ключ обязателен)
• --neo4j — экспорт в neo4j_export.json для Neo4j
• Другие: --silent, --scan-all, --print-all, --no-color, --browse, --debug, --output, --local, --version, --update

▪ Чем отличается от Sherlock?
В отличие от Sherlock, который ищет аккаунты только по идентичному username, Linkook:
• Автоматически ищет связанные аккаунты даже при смене никнеймов
• Собирает взаимосвязи между аккаунтами и email
• Поддерживает экспорт в Neo4j для построения графов связей и глубокого анализа

▪ Техническая информация
• Язык: Python (100%)
• Лицензия: MIT
• Актуальная версия: v1.1.2 (5 марта 2025)
• GitHub: ★ 693 Forks 69

🔗 GitHub

Читать полностью…

🥷 OnionGPT — бесплатный ИИ на основе Llama в сети Tor и без цензуры!

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

@linuxkalii

Читать полностью…

👾 Опубликованы новые релизы свободных загрузочных прошивок 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

Читать полностью…

😂 Это вышка - один из сотрудников xAI случайно разместил на GitHub приватный API-ключ.

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

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

@linuxkalii

Читать полностью…

🔒 Microsoft ограничила работу своего C/C++ расширения в форках VS Code

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

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

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

@linuxkalii

Читать полностью…

⚠️ Критическая уязвимость в 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

Читать полностью…

⚡️Легкий способ получать свежие обновления и следить за трендами в разработке на вашем языке. Находите свой стек и подписывайтесь:

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
Разработка игр: /channel/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: /channel/addlist/2Ls-snqEeytkMDgy
Папка FRONTEND: /channel/addlist/mzMMG3RPZhY2M2Iy

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

🎓954ГБ ОПЕНСОРС КУРСОВ: @courses
📕Ит-книги бесплатно: /channel/addlist/BkskQciUW_FhNjEy

Читать полностью…

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

Когда система кажется неприступной и администратор «залочил» вас в белом списке оболочек, не спешите сдаваться. Если среди разрешённых утилит есть 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

Читать полностью…

🎫 Не пропусти крупнейший международный киберфестиваль Positive Hack Days!

PHDays Fest пройдет 22–24 мая в «Лужниках». Здесь раскрывают секреты технологий и их роль в повседневной жизни каждого из нас.

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

🤟 В программе — 270 докладов, 26 треков и выступления более 500 спикеров — от начинающих специалистов до именитых экспертов со всего мира, CIO и CISO крупных IT-компаний. А также кибербитва Standoff.

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

😏 Приобрести билет

Читать полностью…

🔐 TLS-сертификаты станут скоропортящимися: введение новых правил CA/Browser Forum.

Крупнейшие игроки интернет-индустрии договорились о радикальном сокращении срока жизни TLS-сертификатов — с нынешних 13 месяцев до всего 47 дней к 2029 году.

Это решение, поддержанное 29 участниками ассоциации, направлено на борьбу с последствиями утечек и ускорение перехода на новые криптостандарты. Особое внимание уделено SAN-сертификатам: их валидация теперь будет действительна лишь 10 дней.

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

@linuxkalii

Читать полностью…

Получи грант на обучение в Центральном университете

Центральный университет выдает гранты на 4 года обучения в бакалавриате.

Грант покрывает до 100% стоимости обучения. Участвуй в отборе, чтобы получить грант.

Получи доступ к уникальным активностям для абитуриентов. Для выпускников 10-х, 11-х классов и колледжей.

Узнать больше

#реклама
apply.centraluniversity.ru
О рекламодателе

Читать полностью…

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

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

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

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

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

Читать полностью…