Прямое сетевое соединение из Bash без сетевых утилит!

В bash есть возможность открывать TCP/UDP-соединения через путь /dev/tcp/host/port. Это не реальный файл, а спец-путь, который интерпретируется самим bash (сетевые редиректы).

Открываем сокет к серверу и получаем файловый дескриптор:

exec 3<>/dev/tcp/example.com/80

Теперь можно отправлять данные напрямую, как в обычный файл:

printf "GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" >&3

И читать ответ сервера без curl, nc и telnet (чтение завершится, когда сервер закроет соединение):

cat <&3

Работает именно в bash (не в sh/dash/busybox ash) и при включённой поддержке сетевых редиректов.

🔥 Это удобно на урезанных системах, контейнерах и rescue-окружениях, где нет сетевых утилит, но есть bash.

➡️ DevOps Ready | #совет

📂 Напоминалка по 8 популярным сетевым протоколам!

Например, HTTP работает по request-response, TCP через SYN-ACK handshake, а UDP — без подтверждений, идеально для видео.

На картинке — таблица с принципами работы (handshake, шифрование, каналы) и примерами: веб-сёрфинг (HTTP/HTTPS), чаты (WebSocket), файлы (FTP), почта (SMTP).
Сохрани, чтобы не забыть!

➡️ DevOps Ready | #ресурс

Использование магических ссылок /proc для восстановления удаленных файлов в Linux!

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

Это фундаментальный принцип Linux «все есть файл», позволяющий вернуть данные через файловую систему процессов /proc.

Для начала создадим файл, запустим процесс, который его читает, и имитируем удаление данных злоумышленником:

echo "секретные данные" > secret.log
tail -f secret.log > /dev/null &
# Запоминаем PID последнего процесса и удаляем файл
PID=$!; rm secret.log

Файл исчез из списка ls, но данные все еще доступны через дескрипторы активного процесса.

Теперь ищем дескриптор удаленного файла в директории fd процесса:

ls -l /proc/$PID/fd | grep "deleted"

В выводе вы увидите номер (например, 3), указывающий на призрачную ссылку удаленного файла.

Чтобы вернуть данные, достаточно скопировать содержимое этой магической ссылки обратно в обычный файл:

cp /proc/$PID/fd/3 restored_secret.log

Файл успешно восстановлен в текущую директорию из оперативной памяти.

Проверка работоспособности:

cat restored_secret.log && ls -l restored_secret.log

Ожидаемый вывод: секретные данные (и информация о новом файле).

🔥 При анализе взломанных систем всегда проверяйте /proc перед перезагрузкой — это ваш лучший шанс найти удаленные улики.

➡️ DevOps Ready | #практика

😎 Linux Insides — подробное руководство по внутреннему устройству ядра!

Это перевод известной книги Linux Insides, где шаг за шагом разбирается, как работает ядро: процесс загрузки системы, переход в защищённый режим, управление памятью, прерывания, драйверы, планировщик и другие низкоуровневые механизмы.

Оставляю ссылочку: GitHub 📱

➡️ DevOps Ready | #репозиторий

Параллельный запуск обычных команд без GNU Parallel!

Многие задачи в Linux можно ускорить в разы, задействовав несколько ядер CPU.

Ключ — опция -P у xargs, которая запускает несколько процессов одновременно (это именно многопроцессность, не потоки).

Например, выполнить задачи параллельно:

P=$(nproc)
seq "$P" | xargs -P"$P" -I{} ./task.sh {}

Здесь одновременно работают до P копий скрипта (обычно по числу доступных CPU).

Отлично подходит для тяжёлых операций над файлами:

find . -maxdepth 1 -name "*.log" -print0 | xargs -0 -P4 -I{} gzip "{}"

Файлы сжимаются параллельно, а не по одному. Использование -print0 / -0 безопасно для имён с пробелами и спецсимволами.

Можно комбинировать с find для массовой обработки каталогов:

find . -name "*.jpg" -print0 | xargs -0 -P6 -I{} convert "{}" -resize 50% "resized/{}"

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

🔥 Это простой способ распараллелить многие CPU-интенсивные задачи, но итоговая скорость может упираться в диск или другие ресурсы.

➡️ DevOps Ready | #совет

☕️ Kubernetes Goat — интерактивная обучающая среда по безопасности!

Здесь можно отрабатывать сценарии взлома контейнеров, обход прав доступа, атаки на кластер, утечки данных и другие типичные проблемы облачной инфраструктуры. Проект подходит как для специалистов по безопасности, так и для разработчиков и DevOps-инженеров, чтобы понимать, как защищать систему на практике.

📌 Оставляю ссылочку: madhuakula.com

➡️ DevOps Ready | #сайт

Диагностируем процессы в Linux через strace!

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

Запускаем программу под трассировкой:

strace ls /tmp

Сразу видно, какие файлы открываются, какие библиотеки грузятся, где возникают ошибки.

Можно прицепиться к уже работающему процессу — удобно, если сервис завис:

sudo strace -p <PID>

Обычно быстро становится понятно, где он застрял: futex (блокировка), ожидание I/O (poll/epoll_wait), connect, чтение/запись и т.п.

Если программа создаёт дочерние процессы, без этого ключа часть событий не попадёт в вывод:

strace -f <command>

Проблемы с файлами, конфигами и правами:

strace -e trace=%file <command>

Покажет open/stat/access и другие файловые операции — удобно понять, какие пути реально проверяются.

Частый кейс — программа ищет файл, которого нет:

strace -e trace=%file <command> 2>&1 | grep ENOENT

Сразу видно, какой путь оказался отсутствующим.

Для сетевых проблем:

strace -e trace=%network <command>

Видно создание сокетов, попытки подключения и ошибки.

Если нужно сохранить вывод:

strace -o trace.log <command>

С дочерними процессами лучше так:

strace -ff -o trace.log <command>

Будут отдельные файлы по PID.

Иногда вывод обрезает длинные строки — увеличиваем лимит:

strace -s 200 <command>

Посмотреть, где именно тратится время:

strace -T <command>

Короткая сводка по системным вызовам:

strace -c <command>

🔥 strace незаменим при анализе поведения непрозрачных бинарников и в случаях, когда нет доступа к исходному коду. Он показывает, на каких системных вызовах процесс блокируется и какие операции фактически выполняет в пространстве ядра.

➡️ DevOps Ready | #практика

📂 Напоминалка по архитектуре Linux!

Например, ядро управляет процессами, памятью, устройствами, сетью и файловыми системами — именно эти подсистемы обеспечивают работу всей операционной системы.

На картинке — 5 основных компонентов ядра, которые важно понимать разработчикам, DevOps-инженерам и системным администраторам.

Сохрани, чтобы держать базовую архитектуру Linux под рукой!

➡️ DevOps Ready | #ресурс

✍️ Ryan’s Tutorials — системное руководство по командной строке Linux!

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

📌 Оставляю ссылочку: ryanstutorials.net

➡️ DevOps Ready | #сайт

Знали, что Linux умеет реагировать на события файловой системы в реальном времени?

Ядро через inotify сообщает, когда файл изменился, создан или заменён.

Команда блокируется и просыпается только при событии, поэтому почти не расходует CPU:

inotifywait -e close_write config.yaml

Можно отслеживать целую директорию (важно, если редактор сохраняет через temp-файл + rename) и автоматизировать любые действия - перезапуск сервисов, сборку проекта или бэкап:

inotifywait -m -e create,delete,modify,moved_to ./src

Очень удобно для авто-reload без Docker, IDE и сторонних инструментов:

while inotifywait -e close_write app.py; do
  pkill -f "python app.py"; python app.py &
done

🔥 Такой прием пригодится для CI-скриптов, авторазвертывания, hot-reload и администрирования.

🚪 Linux Ready | #совет

✍️ Awesome DevSecOps Russia — полезная русскоязычная подборок по DevSecOps и безопасной разработке!

В репозитории собраны статьи, доклады, инструменты, стандарты, курсы и реальные практики внедрения безопасности в процесс разработки, от анализа кода до защиты контейнеров и облаков. Здесь можно найти материалы по SAST/DAST, безопасности Docker и Kubernetes, IaC-сканированию, compliance-подходам и другим важным аспектам современной инфраструктуры.

Оставляю ссылочку: GitHub 📱

➡️ DevOps Ready | #репозиторий

📂 Топ инструментов кибербезопасности!

Это подборка must-have инструментов с краткими описаниями. Охватывает сканирование, анализ, эксплуатацию, мониторинг и защиту — от сетей до malware.

Идеально для пентестера или админа, чтобы быстро выбрать инструмент под задачу.

➡️ DevOps Ready | #ресурс

Переменные окружения в Linux: управление поведением процессов!

Переменные окружения (environment variables) задают контекст выполнения программ. Через них настраиваются shell, компиляторы, интерпретаторы, библиотеки и большинство CLI-утилит. Это базовый механизм конфигурации в Unix-подобных системах.

Посмотреть все переменные окружения текущего процесса (shell):

printenv

или:

env

Обе команды выводят окружение текущего процесса (экспортированные переменные). env также часто используют для запуска команды с заданными переменными.

Посмотреть значение конкретной переменной:

echo "$PATH"

Кавычки важны при подстановке переменных: они предотвращают нежелательное разбиение на слова и обработку спецсимволов (особенно если значение содержит пробелы или символы glob).

Временная переменная для одного запуска программы:

DEBUG=true ./app

Переменная будет доступна только процессу ./app и его дочерним процессам. В текущем shell она не сохранится.

Экспорт переменной в текущей сессии shell:

export NODE_ENV=production

После export переменная становится частью окружения текущего shell и наследуется всеми дочерними процессами, но не влияет на другие терминалы и будущие входы в систему.

Удаление переменной:

unset NODE_ENV

Удаляет переменную из текущего shell и его окружения.

Постоянные переменные пользователя - задаются в конфигурационных файлах shell и применяются при старте сессии. Для Bash обычно используют: ~/.bashrc — интерактивные shell; ~/.profile или ~/.bash_profile — login-shell

Конкретный файл зависит от способа запуска shell в системе.

Пример:

export EDITOR=vim
export PATH="$HOME/bin:$PATH"

После изменения применить настройки можно:

source ~/.bashrc

или просто открыть новый терминал.

Глобальные переменные для всех пользователей - можно задать в файле:

/etc/environment

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

Пример:

JAVA_HOME=/usr/lib/jvm/java-17

Посмотреть окружение конкретного запущенного процесса:

cat /proc/<PID>/environ | tr '\0' '\n'

Переменные хранятся в памяти процесса как строки, разделённые нулевым байтом. Обычно доступно только для своих процессов или с правами root (может ограничиваться настройками безопасности).

Порядок PATH критичен - поиск исполняемых файлов идёт слева направо:

echo "$PATH"

Будет запущена первая найденная программа с совпадающим именем.

🔥 Переменные окружения передаются процессам через механизм fork/exec, существуют только в памяти процесса и наследуются его потомками. Они не изменяют систему глобально сами по себе и являются стандартным способом управления поведением программ в Linux.

🚪 Linux Ready | #практика

💡 How To Secure A Linux Server — пошаговое руководство по защите Linux-сервера!

Репозиторий представляет собой подробный чек-лист по хардненингу системы: настройка безопасного SSH-доступа, файрвола, ограничение прав пользователей, аудит действий, антивирусная защита и другие меры повышения безопасности. Материал ориентирован на реальные сценарии эксплуатации серверов и может применяться как для домашних, так и для облачных систем.

Оставляю ссылочку: GitHub 📱

➡️ DevOps Ready | #репозиторий