❤️ Крутая статья для тех, кто хочет руками собрать безопасный Linux VPS и не оставить его открытым для брута и сканеров.

В этой статье:
• Показывают, как сразу после поднятия сервера отключить root‑логин, перейти на SSH‑ключи и закрыть лишние точки входа.

• Разбирают базовый hardening: UFW, fail2ban, автообновления и минимальный набор правил, который реально снижает риск взлома.

• Объясняют, как проверить результат через логи и быстрый аудит, чтобы понять, не остались ли у сервера очевидные дыры.

🔊 Продолжай читать статью

➡️ Hacking Ready | #статья

📂 Напоминалка по NAT и работе сетевого роутера!

Например, NAT позволяет нескольким устройствам внутри локальной сети использовать один публичный IP-адрес для выхода в интернет, а обратный NAT возвращает ответы именно тому устройству, которое отправило запрос.

На картинке — наглядная схема того, как работает трансляция адресов: как роутер меняет private IP на public IP, зачем нужны порты и тд.

Сохрани, чтобы не потерять!

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

👍 Linux Audit — полезные материалы по Linux и безопасности!

На сайте собраны статьи и гайды по Linux, системному администрированию, hardening и безопасности серверов. Здесь можно найти разбор команд, настройку сервисов, аудит системы, советы по защите инфраструктуры и практические рекомендации для админов и backend-разработчиков.

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

➡️ Hacking Ready | #сайт

Создаём временную RAM-директорию — быстрые файлы без лишней записи на SSD/HDD!

Иногда нужно быстрое временное хранилище: сборка проекта, кэш, распаковка архивов, временные логи или обработка больших файлов. В Linux для этого можно использовать tmpfs — файловую систему в памяти (RAM, при необходимости — с использованием swap).

Создаём директорию:

sudo mkdir -p /mnt/ramdisk

Монтируем tmpfs:

sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk

Что происходит: tmpfs создаёт файловую систему в памяти; size=2G — максимальный лимит, а не сразу занятая RAM; память выделяется по мере записи файлов; /mnt/ramdisk — директория монтирования.

Теперь всё, что записывается в /mnt/ramdisk, хранится в памяти и обычно значительно снижает количество записей на SSD/HDD.

Например:

cd /mnt/ramdisk

И работаешь как с обычной директорией:

cp big-archive.tar.gz /mnt/ramdisk
tar -xf big-archive.tar.gz

Практический пример: временная сборка большого frontend/backend-проекта или работа с временными файлами:

TMPDIR=/mnt/ramdisk npm run build

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

Для pip можно отдельно вынести кэш и временные файлы в RAM:

TMPDIR=/mnt/ramdisk \
PIP_CACHE_DIR=/mnt/ramdisk/pip-cache \
pip install -r requirements.txt

Проверить, что tmpfs смонтирован:

df -h

Пример:

tmpfs   2.0G   120M  1.9G   6% /mnt/ramdisk

Когда работа закончена — отмонтировать:

sudo umount /mnt/ramdisk

А также важно помнить: данные исчезают после reboot; tmpfs использует RAM и при необходимости может использовать swap; не стоит хранить там что-то важное; размер можно менять через size=; после umount директория останется, но данные tmpfs исчезнут.

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

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

✍️ Gizmo AI — нейросеть для обучения и запоминания информации!

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

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

➡️ Hacking Ready | #сайт

Знали, что можно добавлять timestamp к любому выводу terminal pipeline без изменения приложения и логгера?

Во многих CLI-утилитах, shell-скриптах и legacy-сервисах отсутствуют временные метки, из-за чего сложно анализировать задержки, интервалы выполнения и последовательность событий.

Утилита ts из пакета moreutils добавляет timestamp к каждой строке stdin в реальном времени:

$ tail -f app.log | ts '%Y-%m-%d %H:%M:%S'

Теперь каждая строка получает точное время:

2026-05-22 18:41:03 request started
2026-05-22 18:41:07 request finished

Это особенно полезно при отладке конвейеров команд, shell-автоматизации, CI-логов, docker-контейнеров и long-running процессов, где нельзя быстро изменить сам источник логов.

Можно использовать свой формат времени:

$ tail -f app.log | ts '[%H:%M:%S]'

Или измерять интервалы между событиями:

$ ping 1.1.1.1 | ts -i

Иногда программы буферизуют вывод — тогда поможет:

$ stdbuf -oL -eL some-command | ts

🔥 Приём кажется небольшим, но на практике сильно упрощает анализ поведения систем и CLI-инструментов без внедрения полноценного логгирования.

🚪 Linux Ready | #совет

📂 Напоминалка по подготовке запросов перед автоматическим сканированием!

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

Сохрани, чтобы не потерять!

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

☕️ DevOps Interview — интерактивная платформа для подготовки к собеседованиям!

Это ресурс, где собраны вопросы и практические сценарии по DevOps, разбитые по ключевым темам: Docker, Kubernetes, CI/CD, облака, безопасность, мониторинг и др. Формат построен как тренажёр, можно проходить вопросы по категориям. Отдельно выделяются реальные сценарии, где разбираются проблемы и их решения.

📌 Оставляю ссылочку: interview.devopscommunity.in

➡️ Hacking Ready | #сайт

Слышали, что Bash умеет выводить set -x не в терминал, а в отдельный log-файл?

Обычно при debugging shell-скриптов используют set -x, но весь trace смешивается с обычным stdout/stderr и быстро делает вывод неудобным для чтения.

В Bash существует специальная переменная BASH_XTRACEFD, которая перенаправляет xtrace в отдельный файловый дескриптор:

$ exec {FD}>>debug.log
$ export BASH_XTRACEFD=$FD

Теперь debugging не ломает основной вывод программы:

$ bash -x ./deploy.sh

Все trace-команды уходят только в debug.log, а stdout/stderr продолжают работать как обычно.

Это особенно полезно в автоматизации, CI/CD, deploy-скриптах, где важно сохранить чистый вывод программы, но при этом иметь полную трассировку выполнения для отладки.

После завершения debugging дескриптор корректно закрывается:

$ set +x
$ exec {FD}>&-

🔥 Механизм работает внутри Bash и использует обычные файловые дескрипторы оболочки без внешних утилит.

🚪 Linux Ready | #совет

📂 Напоминалка по перенаправлениям ввода/вывода!

Например, > перенаправляет вывод команды в файл, 2> — ошибки, а 2>&1 объединяет STDOUT и STDERR.

На картинке — основные файловые дескрипторы (STDIN, STDOUT, STDERR), примеры перенаправлений и другое.

Сохрани, чтобы не потерять!

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

Настройка coredump в Linux — диагностика падений процессов!

Когда Linux-процесс аварийно завершается (например, SIGSEGV / Segmentation fault, SIGABRT и др.), система может сохранить снимок памяти процесса — core dump.

Без dump-файла обычно остаётся только сам факт падения и запись в логах. Core dump позволяет открыть состояние процесса в gdb, получить stack trace, посмотреть память, регистры, потоки и локализовать причину уже после завершения процесса.

Проверка текущего лимита на создание dump:

ulimit -c

Если вывод 0 — сохранение core dump отключено для текущей shell/session.

Временное включение:

ulimit -c unlimited

Это работает только для процессов, запущенных из текущей shell-сессии. После logout или reboot настройка пропадёт.

Для systemd-сервисов одного ulimit недостаточно — лимит нужно задавать в unit-файле:

[Service]
LimitCORE=infinity

После изменения unit-файла:

sudo systemctl daemon-reload
sudo systemctl restart app.service

Теперь проверяем, как именно система сохраняет dump-файлы:

cat /proc/sys/kernel/core_pattern

Параметр core_pattern определяет обработчик и путь сохранения dump. Если значение начинается с |, dump передаётся внешнему обработчику, например systemd-coredump.

Пример прямого сохранения dump в файл:

/core.%e.%p.%t

Где: %e — имя процесса; %p — PID процесса; %t — UNIX timestamp

Создадим каталог для dump-файлов и настроим сохранение:

sudo mkdir -p /var/crash
sudo chmod 1777 /var/crash
sudo sysctl -w kernel.core_pattern=/var/crash/core.%e.%p.%t

1777 используется как простой демо вариант для тестов и локальной диагностики. В продакшен обычно делают более жёсткие права доступа и отдельно контролируют доступ к dump-файлам, поскольку они могут содержать чувствительные данные процесса.

Чтобы настройка сохранилась после reboot:

sudo nano /etc/sysctl.d/99-coredump.conf

Добавляем:

kernel.core_pattern=/var/crash/core.%e.%p.%t

Применяем конфигурацию:

sudo sysctl --system

Пример аварийного завершения процесса:

./app
Segmentation fault (core dumped)

После падения появится dump-файл:

/var/crash/core.app.18422.1715962012

Теперь можно открыть dump через gdb:

gdb ./app /var/crash/core.app.18422.1715962012

Посмотреть стек вызовов:

(gdb) bt

Для полноценного анализа бинарь желательно собирать с debug symbols (-g) без stripping.

На большинстве современных systemd-дистрибутивов dump часто обрабатывается через systemd-coredump, а не сохраняется напрямую через core_pattern.

Посмотреть список crash:

coredumpctl list

Получить информацию по dump:

coredumpctl info PID

Открыть dump сразу в gdb:

coredumpctl debug PID

Вместо PID можно использовать имя процесса, путь к бинарю и другие фильтры coredumpctl. Также важно помнить, что systemd-coredump отдельно управляет хранением dump-файлов через coredump.conf: Storage, ProcessSizeMax, ExternalSizeMax, MaxUse, KeepFree.

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

🔥 Core dump — один из базовых механизмов low-level диагностики Linux-приложений, backend-сервисов и анализа падений в продакшен.

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

📂 Напоминалка по SSH — как устанавливается защищённое соединение!

Например, SSH сначала согласовывает версии и алгоритмы шифрования, затем выполняет обмен ключами и только после этого открывает безопасную сессию для передачи команд и данных.

На картинке — полный цикл работы SSH: от TCP-подключения до шифрования команд и проверки ключей клиента.

Сохрани, чтобы не потерять!

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

❤️ На Habr вышел сильный практический разбор ошибок атакующих глазами SOC.

В этой статье:
• Разбирается, как red team палится ещё до цели — по шумным сканерам, VPN, User-Agent и другим мелким, но очень заметным следам;
• Показано, на какие артефакты обращает внимание защита: Sysmon, метаданные файлов, командные строки и нестандартные пути запуска;
• Разобраны реальные ошибки атакующих, из которых полезно учиться не только пентестеру, но и тем, кто строит детект и реагирование.

🔊 Продолжай читать на Habr!

➡️ Hacking Ready | #статья