ar
Feedback
Linux_BE1

Linux_BE1

الذهاب إلى القناة على Telegram

Канал по Linux, полезный и интересный контент для всех уровней. По вопросам сотрудничества @cyberJohnny

إظهار المزيد
188
المشتركون
لا توجد بيانات24 ساعات
-37 أيام
-1530 أيام
أرشيف المشاركات

📌 Задача: «Загадочный рост нагрузки в полночь» Каждую ночь, ровно в 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_be1

😂 Это вышка - один из сотрудников xAI случайно разместил (https://www.linkedin.com/posts/caturegli_yo-xai-your-devs-are-leak
😂 Это вышка - один из сотрудников xAI случайно разместил (https://www.linkedin.com/posts/caturegli_yo-xai-your-devs-are-leaking-api-keys-on-activity-7321566948020953088-6KXj) на GitHub приватный API-ключ. Два месяца подряд любой мог получить доступ к более чем 60 внутренним моделям xAI, в том числе неанонсированным версиям Grok. Ключ работал до 30 апреля. Похоже, xAI таким образом решили стать open source 😁 @linux_be1

В августе 1991-го студент Хельсинкского университета Линус Торвальдс, жонглируя Minix на своём 386-м, задумал создать «свой» свободный UNIX-подобный ядро. 25 августа он опубликовал в интернете короткое сообщение: «Я пишу свой собственный ОС-ядро — это просто хобби, и вряд ли получится что-то крупное…» Но пользователи по всему миру откликнулись — предложили идеи, патчи, драйверы. Вскоре Торвальдс сменил лицензию на GPL, и Linux превратился в настоящий народный проект. Ключевые вехи: 1991 — первая версия 0.01: лишь несколько тысяч строк кода, минимальный функционал. 1992 — переход на GPL: открыт дверной проём для свободного распространения и модификаций. 1994 — выпуск стабильного ядра 1.0: «взросление» платформы. 1996–2000 — поддержка десятков архитектур, появление популярных дистрибутивов (Red Hat, Debian). 2003–2005 — активный переход серверного рынка на Linux; начало бумов embedded-устройств. Сегодня Linux управляет миллионами серверов, смартфонами (Android!) и «умными» устройствами. Всё это — результат одного любопытного студента и огромного сообщества энтузиастов, превративших «просто хобби» в крупнейший проект в истории софта. @linux_be1

большая коллекция словарей для брутфорса, которые используют многие пентестеры в своей работе. Самое главное - весь материал абсолютно бесплатный, без ограничений и всего прочего. Ну и еще есть API для автоматизации и интеграции в собственные инструменты. Забираем отсюда: https://weakpass.com @linux_be1

Linux засунули в Excel-файл! 🖥 Очень забавный проект для сисадминов, переквалифицировавшихся в бухгалтеров. https://github.c
Linux засунули в Excel-файл! 🖥 Очень забавный проект для сисадминов, переквалифицировавшихся в бухгалтеров. https://github.com/NSG650/LinuxInExcel #Linux #Excel #IT @linux_be1

Linux засунули в Excel-файл! 🖥 Очень забавный проект для сисадминов, переквалифицировавшихся в бухгалтеров. https://github.c
Linux засунули в Excel-файл! 🖥 Очень забавный проект для сисадминов, переквалифицировавшихся в бухгалтеров. https://github.com/NSG650/LinuxInExcel #Linux #Excel #IT @linux_be1

🚨 Уязвимость в ядре Linux: повышение привилегий через VSOCK (CVE-2025-21756 (https://security-tracker.debian.org/tracker/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, немедленно примените обновления — эксплоит работает локально и не требует дополнительных разрешений. ⚫️ Эксплоит (https://github.com/hoefler02/CVE-2025-21756/blob/main/x.c) @linux_be1

🔒 Microsoft ограничила работу своего C/C++ расширения в форках VS Code Пользователи альтернативных редакторов на базе VS Cod
🔒 Microsoft ограничила работу своего C/C++ расширения в форках VS Code Пользователи альтернативных редакторов на базе VS Code столкнулись с блокировкой проприетарного расширения для C/C++ от Microsoft. После обновления до версии 1.24.5 плагин начал выдавать ошибку, сообщая о возможности работы только в официальных продуктах Microsoft — VS Code, Visual Studio и связанных сервисах. Ситуация вновь поднимает вопрос о зависимости open-source проектов от проприетарных дополнений. Пока единственное решение для тех, кому критично расширение от Microsoft — откат на старую версию и отключение автообновлений. 🔗 Ссылка - *клик* (https://github.com/VSCodium/vscodium/issues/2300) @linux_be1

🔥 Полезный совет: Мониторинг 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_be1

Удобный "справочник" по любой команде в Linux. ExplainShell (https://explainshell.com/) представляет удобный интерфейс для по
Удобный "справочник" по любой команде в Linux. ExplainShell (https://explainshell.com/) представляет удобный интерфейс для поиска справочной информации по любой команде. Просто вбиваете нужную вам команду со всеми аргументами в поисковую строку — и получаете подробное объяснение, что конкретно делает каждый аргумент. Крч, нереально годная вещь! @linux_be1

🖥 Linux Academy — топ-канал для продвинутого освоения Linux. Мы раскрываем скрытые механизмы ядра через наглядные шпаргалки
+5
🖥 Linux Academy — топ-канал для продвинутого освоения Linux. Мы раскрываем скрытые механизмы ядра через наглядные шпаргалки и яркую визуальную графику, детально разбираем малоизвестные команды и скрипты. Экспресс-гайды, которые экономят часы поиска: https://t.me/+vd77Zi1TC_9lNjgy @linux_be1

🖥 Лучшая команда для поиска ошибки в Linux ? journalctl -xe` 📌 Что делает: Показывает последние критические события (-e прыгает в конец лога). Расшифровывает коды ошибок и статусы (-x добавляет объяснения). Включает системные и пользовательские логи — не только ядро. ▪️ Когда использовать: При падении сервиса (systemctl status намекает на проблему). При неожиданных перезагрузках, зависаниях или отказах служб. При проблемах с сетью, правами доступа, драйверами. ▪️ Почему лучше других: Гораздо информативнее, чем dmesg, tail /var/log/syslog, messages. Работает на всех современных дистрибутивах с systemd. @linux_be1

💡Совет дня для Linux Используйте mkdir -p для создания нескольких вложенных каталогов за один раз! Этот однострочник $ mkdir
💡Совет дня для Linux Используйте mkdir -p для создания нескольких вложенных каталогов за один раз! Этот однострочник $ mkdir -p projects/{frontend,backend}/{src,test,docs} мгновенно создаст 6 каталогов @linux_be1

💡 Задача: Пропажа файла после echo У вас есть файл` /tmp/testfile` с важным содержимым. Вы решили добавить в него строку "`Hello, world!`" с помощью команды: ``` echo "Hello, world!" > /tmp/testfile ``` Однако после выполнения этой команды вы замечаете, что всё старое содержимое исчезло и осталась только одна строка "`Hello, world!`". Вопрос: Почему это произошло? Как правильно было добавить строку, не потеряв содержимое? ✅ Решение и объяснение: 🔍 Что делает >? Символ > в Bash — это перезапись (truncate) файла. Когда вы пишете: ``` echo "Hello, world!" > /tmp/testfile ``` Это значит: Shell открывает файл на запись с обнулением (truncate). Весь предыдущий контент удаляется, прежде чем echo записывает новую строку. Вот подвох: даже если echo кажется безобидной командой, сам процесс перенаправления (>) выполняется до запуска echo. ✅ Как сделать правильно? Чтобы добавить строку, нужно использовать >>, а не >: ``` echo "Hello, world!" >> /tmp/testfile ``` >> открывает файл в режиме append, не трогая текущее содержимое. ⚠️ Бонусный подвох (для профи) Выполните это: ``` cat /tmp/testfile > /tmp/testfile ``` После этого файл станет пустым. Почему? ➡️ Ответ: cat читает из /tmp/testfile, но перенаправление > делает truncate сразу, еще до запуска cat. То есть: Файл обнуляется, Потом cat читает его… но он уже пустой! Чтобы избежать такого поведения, можно использовать временный файл: ``` cat /tmp/testfile > /tmp/tmpfile && mv /tmp/tmpfile /tmp/testfile ``` @linux_be1

Zev 🔍 Это помощник для работы с терминалом на естественном языке. Он помогает быстро находить нужные команды и сохранять их в избранное, а его простой и понятный интерфейс делает освоение терминала доступным даже для новичков. `pip install zev` 📌 Github (https://github.com/dtnewman/zev) @linux_be1

❓ Задача: "Исчезающие процессы" На сервере с 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_be1

Исследователи обнаружили связь между хак-группами Team46 и TaxOff Специалисты Positive Technologies установили, что группиров
Исследователи обнаружили связь между хак-группами Team46 и TaxOff Специалисты Positive Technologies установили, что группировки Team46 и TaxOff тесно связаны между собой или, вероятно, являются одной хак-группой. Совпадения были найдены в их инструментах, инфраструктуре и тактиках атак, включая использование уязвимости нулевого дня. https://xakep.ru/2025/04/21/team46-and-taxoff/ @linux_be1