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

На сервере с 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.

@linux_education

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

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

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

🔗 Ссылка - *клик* (https://cve.mitre.org/news/archives/index.html)

@linux_education

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

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

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

🔗 Ссылка - *клик* (https://cabforum.org/)

@linux_education

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

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

@linux_education

‍🖥 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"

✔️ Подробнее (https://uproger.com/20-luchshih-maloizvestnyh-i-poleznyh-komand-linux/)

@linux_education

⚠️ В 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.

🔗 Ссылка - *клик* (https://www.aikido.dev/blog/xrp-supplychain-attack-official-npm-package-infected-with-crypto-stealing-backdoor)

@linux_education

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

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

---

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

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

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

```bash
sudo apt install htop
htop
```

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

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

```bash
sudo apt install iotop
sudo iotop
```

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

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

```bash
sudo apt install iftop
sudo iftop
```

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

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

```bash
sudo apt install glances
glances
```

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

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

```bash
sudo apt install dstat
dstat
```

---

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

@linux_education

🚨 Найдена уязвимость в ядре Linux: повышение привилегий через VSOCK (CVE-2025-21756 (https://security-tracker.debian.org/tracker/CVE-2025-21756))

Что произошло?
В ядре Linux выявлена ошибка «use-after-free» в реализации AF_VSOCK (виртуальных сокетов), которая позволяет локальному злоумышленнику получить права 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, немедленно примените обновления — эксплоит работает локально и не требует дополнительных прав.

⚫️ Эксплоит доступен по ссылке (https://github.com/hoefler02/CVE-2025-21756/blob/main/x.c)

@linux_education

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

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

@linux_education

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

🔗 Ссылка - *клик* (https://libreboot.org/news/libreboot2504.html)

@linux_education

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

```python
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 его легко внедрить в свои проекты.

@linux_education

🧩 Задача для 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

Обратить внимание на дескрипторы в /tmp/, /dev/shm/, /proc/self/fd/.

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

cp /proc//exe ./restored_binary

3️⃣ Отследить родительский процесс

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

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

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

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

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

lsof -p | grep memfd

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

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

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

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

kill -9

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_education

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

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

▪ Основные функции
• Поиск аккаунтов по заданному username на большом количестве популярных платформ
• Рекурсивное выявление альтернативных никнеймов и связанных аккаунтов
• Проверка email на утечки через базу данных HudsonRock’s Cybercrime Intelligence или 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
• --show-summary — показывает сводку после завершения сканирования
• --concise — выводит краткую информацию
• --check-breach — проверяет email через базу HudsonRock (отмечает «(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

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

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

🔗 GitHub (https://github.com/JackJuly/linkook)

@linux_education

🐧 Задача-ловушка: Почему служба не видит обновлённый файл?

Условие:

Вы изменили конфигурационный файл для популярного сервиса (например, `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) работают с inode, а не напрямую с именами файлов.

Когда вы выполняете:

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

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

Если сервис (например, `nginx`) запущен под контролем systemd с включёнными параметрами ProtectSystem или другими механизмами безопасности (или даже через старый 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 или init-скрипты могут не закрыть старые дескрипторы, особенно при использовании специальных модулей, overlayfs и других особенностей.

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

@linux_education

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

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

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

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

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

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

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

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

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

История создания grep — действительно увлекательная.

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

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

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

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

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

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

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

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

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

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

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

@linux_education