Используем iptables hashlimit + recent вместо fail2ban

Когда fail2ban уже не справляется или слишком медленный, пора перейти на уровень ниже — к iptables.

Сочетание --hashlimit и --recent даёт мощный инструмент контроля попыток подключения к SSH без необходимости читать логи и запускать демоны.

Защитить порт 22 от перебора и сканеров

Входящие подключения должны:
⏺быть не чаще X раз в минуту с одного IP (аналог hashlimit),
⏺блокироваться при агрессивной активности (аналог recent),
⏺не мешать своим или автоматическим задачам (допускаем trusted IP или подсети).

1️⃣Разрешаем trusted-подсеть без лимитов

iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT

2️⃣Ограничение по частоте с hashlimit

Допускаем не более 3 подключений в минуту с одного IP:

iptables -A INPUT -p tcp --dport 22 \
  -m state --state NEW \
  -m hashlimit --hashlimit 3/min \
  --hashlimit-burst 5 \
  --hashlimit-mode srcip \
  --hashlimit-name sshlimit \
  -j ACCEPT

Это не требует ни журналов, ни доп. сервисов — чисто на уровне netfilter.

3️⃣Ловим и блокируем агрессивных через recent

Если IP попытался открыть соединение >5 раз за 60 секунд — баним на 5 минут:

iptables -A INPUT -p tcp --dport 22 \
  -m state --state NEW \
  -m recent --name SSH --set

iptables -A INPUT -p tcp --dport 22 \
  -m state --state NEW \
  -m recent --name SSH --update \
  --seconds 60 --hitcount 5 -j DROP

4️⃣Остальные соединения — по умолчанию DROP или REJECT

iptables -A INPUT -p tcp --dport 22 -j DROP

Тестирование

Подключитесь к серверу с другого IP и сделайте 10 попыток:

for i in {1..10}; do nc -zv your.server.ip 22; sleep 2; done

После 5–6 попыток пакет начнёт дропаться.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: В чем разница между процессами и потоками (threads) в Linux?

✅Ответ:

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

Потоки, в отличие от процессов, выполняются внутри одного адресного пространства. Это позволяет потокам одного процесса совместно использовать память и ресурсы, что делает их легче и быстрее в создании по сравнению с процессами. Для создания потоков используются библиотеки, такие как POSIX Threads (pthread).

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое Linux PSI (Pressure Stall Information) и как его использовать для мониторинга?

✅Ответ: PSI — это механизм ядра Linux, позволяющий отслеживать давление на ресурсы: CPU, память и I/O. Он показывает, сколько времени процессы провели в ожидании этих ресурсов, что помогает выявить узкие места до того, как ситуация станет критичной (например, до вмешательства oom-killer).

PSI не измеряет загрузку напрямую — он измеряет «stall time» — сколько процессов одновременно не могли продолжить работу из-за нехватки ресурса. Это дает более реалистичную картину деградации системы.

Проверка PSI осуществляется через:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

Перехват stdout/stderr у systemd-сервиса в рантайме: без перезапуска и strace

Иногда вам нужно отладить запущенный systemd-сервис, чтобы понять, что он пишет в stdout или stderr, но:

– сервис уже работает,
– логи в journald запаздывают или отфильтрованы,
– вы не хотите/не можете использовать strace.

Что делать?

1️⃣Ищем дескрипторы вывода

Узнаём PID процесса:

systemctl show -p MainPID your-service

Идём в /proc/<PID>/fd/ — смотрим, куда пишется stdout (обычно fd 1) и stderr (обычно fd 2):

ls -l /proc/<PID>/fd/1

Может быть что-то вроде:

/proc/<PID>/fd/1 -> /dev/null
или -> socket:[12345]
или -> /run/log/journal/...

2️⃣Если это сокет — дублируем вывод

Можно аккуратно “подключиться” к этому дескриптору с помощью socat, если он всё ещё живой:

socat -u ABSTRACT-CONNECT:your-socket - | cat

Или, если это пайп или лог-файл — можно открыть его напрямую и читать в реальном времени:

tail -f /run/log/your-app.log

3️⃣Переоткрытие stdout/stderr без перезапуска

Иногда вы хотите временно направить stdout/err в другой файл (например, в отладочный лог). Если приложение не закрывает дескрипторы, можно сделать:

exec 3>/tmp/debug.log
sudo tee /proc/<PID>/fd/1 >/dev/null <&3

Это дублирует вывод в debug.log. Подходит не для всех случаев, но может сработать.

Диагностика high-load без perf и strace: ps + procfs как минимум

Когда серверу плохо, а perf, strace и eBPF недоступны (или неуместны) — остаётся old school: ps, top и чтение /proc.

И это вполне достаточно, чтобы найти:

– кто грузит CPU и память,
– где залипли процессы,
– кто блокирует I/O и тормозит остальных.

1️⃣Кто грузит CPU?
Проверяем самых голодных:

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head

Или top -H — если процесс многопоточный (например, Java или nginx), смотрим нагрузку по тредам.

2️⃣Что делают эти процессы?

Находим PID и лезем в /proc/<pid>/:

cat /proc/<pid>/status | grep -E 'State|VmRSS'

Смотрим состояние (Running, Sleeping, Zombie) и потребление памяти.

Читаем cmdline и cwd:

tr '\0' ' ' < /proc/<pid>/cmdline
ls -l /proc/<pid>/cwd

3️⃣Что с диском?

Находим процессы с активным I/O:

iotop -o    # если доступен

Или вручную:

grep -r . /proc/*/io | grep read_bytes | sort -nk2 | tail

Можно отследить, кто грузит диск даже без iotop.

4️⃣Где залипли?

Иногда процессы висят в ожидании ресурсов. Смотрим wchan:

ps -eo pid,wchan:30,cmd | grep -v -E '^\s*PID' | grep -v running

wchan показывает, где «спит» поток: например, futex_wait_queue_me (ожидание мьютекса) или unix_stream_recvmsg (чтение из сокета).

5️⃣Кто кого держит?

Смотрим locks:

cat /proc/locks

Или проверяем открытые файлы:

ls -l /proc/<pid>/fd/

Быстро даёт понять, кто блокирует файл или ждёт освобождения сокета/канала.

6️⃣А если нагрузка прыгает?

Снимаем срез каждые 5 секунд:

while true; do ps -eo pid,cmd,%cpu,%mem --sort=-%cpu | head -n 10; sleep 5; clear; done

Можно обернуть в watch или bash-циклы для простейшего мониторинга.