Linux Kali

🧨 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

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

💥 В даркнете появилась база с данными 89 млн аккаунтов Steam — возможная утечка из Twilio На одной из даркнет-площадок выставлен на продажу файл, содержащий якобы 89 миллионов записей пользователей Steam — это около двух третей всех аккаунтов на платформе. Продавец с ником Machine1337 запросил $5000 за доступ к базе и опубликовал примерку из 3000 строк в качестве доказательства. Содержимое файла включает: - SMS-сообщения с одноразовыми кодами Steam Guard - номера телефонов, на которые были отправлены эти коды По оценкам экспертов, утечка вряд ли произошла со стороны Valve — куда более вероятной выглядит компрометация облачного провайдера Twilio, который занимается отправкой SMS для двухфакторной аутентификации. 📌 Если у вас включён Steam Guard через мобильное приложение, серьёзных причин для беспокойства нет — коды, отправленные по SMS, считаются менее защищённым методом. @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

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

🫡 Без обид, Линус Торвальдс… но этот человек — величайший гик современности. 📟 В 1971 году, в 28 лет, он создал UNIX — систему, на которой построен весь современный интернет. 🦫 В 2009 году, уже в 66 лет, он стал соавтором языка Go — одного из самых популярных языков в мире DevOps и микросервисов. 💥 Но это только начало: ▪ Он разработал язык B, который стал основой для языка C ▪ Создал UTF-8 — кодировку, благодаря которой мы видим текст на любом языке в интернете ▪ Придумал grep — команду, без которой не обходится ни один разработчик ▪ Работал над Multics, Plan 9, Inferno — это четыре операционные системы, созданные одним человеком 🧠 Большинство людей в жизни не используют и двух ОС. А он — создал четыре. И при этом... О нём почти никто не знает. Запомни имя: Кен Томпсон. 🛠 Один из тех, кто буквально построил цифровой мир, в котором мы живём. 🏛 Рим не за один день строился... а вот grep — почти что за одну ночь 😎 История создания grep — действительно захватывающая. Один из создателей операционной системы UNIX, Кен Томпсон, разработал grep буквально «за ночь». На самом деле, у него уже был личный инструмент для поиска текста в файлах. Однажды его начальник, Дуг МакИлрой, подошёл и сказал: «Знаешь, было бы здорово — уметь искать нужное в файлах». Томпсон ответил: «Хорошо, подумаю об этом ночью.» Он пришёл домой, доработал свой старый код, пофиксил баги — и всё это заняло не больше часа. На следующий день он показал результат МакИлрою. Тот воскликнул: «Это именно то, что мне было нужно!» А дальше — это уже история. 🤔 Если ты задаёшься вопросом, почему инструмент называется grep, а не просто search — на это есть вполне логичное объяснение 👇 ❤️ Ставьте лайк и я напишу пост про историю названия Grep. https://www.youtube.com/shorts/tfzw9HOu4xc @linuxkalii

🐧 Задача-ловушка: Почему служба не видит обновлённый файл? Условие: Вы обновили конфигурационный файл для популярного сервиса (например, `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 прощается с эпохой 486-х процессоров: мэйнтейнеры ядра Linux готовятся к историческому изменению — полному удалению поддержки данной линейки из кодовой базы. Инициатива исходит от самого Линуса Торвальдса, который считает, что поддержка 30-летних чипов давно стала обузой для разработчиков. Удаление 14 тысяч строк кода упростит архитектуру ядра и снизит нагрузку на сопровождающих. Интересно, что встраиваемые системы на базе Quark не пострадают — они используют модернизированные 486-совместимые ядра с поддержкой современных инструкций. 🔗 Ссылка - *клик* @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

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