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

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

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

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

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

@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

🧠 Задача для продвинутых 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

🕵️‍♂️ 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

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

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

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

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

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

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

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

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

@linuxkalii

👾 Новые атаки 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

🧨 BitTorrent: изобретение, которое спасло интернет (и разозлило весь Голливуд)

В начале 2000-х интернет был... медленным.
Очень медленным.

📼 Один фильм — сутки загрузки.
💿 Один сервер — сотни пользователей, и он падал.
📉 Чем больше людей хотели скачать — тем медленнее всё работало.

В эпоху mp3 и AVI это была настоящая проблема.
И никто не знал, как её решить.

👨‍💻 Один человек. Один протокол.

Его зовут Брэм Коэн.
Он интроверт. Он страдает от хронической усталости.
Работает по несколько часов в день. Но думает — как гений.

В 2001 году, в одиночку, он пишет то, что в будущем станет
одним из главных изобретений интернета — BitTorrent.

---

## 🔁 Как это работает?

Вместо того чтобы тянуть файл с одного сервера,
BitTorrent разбивает его на сотни маленьких частей.

Пользователь скачивает один кусок —
и тут же раздаёт его другим.

Каждый становится одновременно клиентом и сервером.
📈 Чем больше людей качают — тем быстрее работает система.

🚫 Центров нет. Контроля нет.

Это был анти-интернет в мире централизованного интернета.
BitTorrent не зависел от Google, Amazon или дата-центров.
Он жил в миллионах домашних компьютеров.

🎬 Голливуд в панике

Появляется The Pirate Bay. Торренты заполняют форумы.
Фильмы, сериалы, музыка — всё разлетается по миру.

Американские студии лоббируют новые законы.
Закрывают Napster, LimeWire, **MegaUpload**…

Но BitTorrent невозможно закрыть.
Он не размещается на сервере. Он — протокол.
Он вшит в само тело интернета.

🤯 Самое интересное?

Брэм Коэн не стал миллиардером.
Он не создал корпорацию. Не уехал в Кремниевую долину.
Он просто дал миру инструмент — и отошёл в сторону.

Позже он начал разрабатывать криптовалюту Chia.
Но главную революцию он совершил, будучи один.

💡 BitTorrent — это не про пиратство

Это был протест. Это была децентрализация.
Это был предок Web3 и peer-to-peer культуры.

Сегодня вы обновляете Ubuntu через торрент.
Качаете дистрибутивы. Распространяете крупные архивы.

Всё это — благодаря одному человеку, который
когда-то сказал:

> _"Я просто хочу, чтобы интернет работал быстрее."_

📌 Запомните это имя: Брэм Коэн
Человек, который ускорил весь интернет — и остался в тени.

@linuxkalii