Защита SSH и mysql innodb: devops чек-лист по безопасности сервера

[admin]

Введение в архитектуру безопасности SSH

Протокол SSH (Secure Shell) является стандартным интерфейсом для удаленного администрирования UNIX-подобных систем. В стандартной конфигурации "из коробки" SSH часто остается уязвимым для широкого спектра атак: от тривиального подбора паролей (brute-force) до использования уязвимостей в устаревших методах шифрования. Для обеспечения промышленного уровня безопасности необходимо реализовать эшелонированную защиту, включающую криптографическую идентификацию, минимизацию привилегий и динамическое ограничение доступа на сетевом уровне. Данная статья описывает практические шаги по усилению защиты SSH-сервера на базе OpenSSH.

Асимметричная криптография: переход на SSH-ключи

Парольная аутентификация — самое слабое звено в цепочке доступа. Человеческий фактор приводит к использованию предсказуемых паролей, которые легко компрометируются через словари или утечки. Использование SSH-ключей переводит безопасность на уровень владения уникальным секретом длиной в сотни байт.

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

Генерация ключа на стороне клиента:

Код: Выделить всё

ssh-keygen -t ed25519 -a 100 -C "admin@infrastructure"

Параметр -a 100 увеличивает количество итераций хеширования парольной фразы для защиты приватного ключа. После генерации необходимо передать публичный ключ на сервер:

Код: Выделить всё

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-server

После проверки успешного входа по ключу необходимо полностью деактивировать парольную аутентификацию в конфигурационном файле /etc/ssh/sshd_config:

Код: Выделить всё

PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes

Ограничение привилегированного доступа и отключение root-login

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

Правильная архитектура доступа подразумевает вход под ограниченным пользователем с последующим повышением привилегий через sudo. Для настройки необходимо отредактировать следующие параметры в /etc/ssh/sshd_config:

Код: Выделить всё

PermitRootLogin no

Дополнительно рекомендуется явно ограничить список пользователей, которым разрешено инициировать SSH-сессию. Это реализуется через директиву AllowUsers:

Код: Выделить всё

AllowUsers sysadmin deploy-user

Этот белый список блокирует доступ для всех остальных учетных записей, включая системные (bin, daemon, mail), даже если у них настроены ключи.

Динамическая защита с помощью Fail2Ban

Даже если парольный вход отключен, SSH-порт постоянно подвергается сканированию. Это создает паразитную нагрузку на CPU и забивает системные логи (/var/log/auth.log или journalctl). Fail2Ban — это инструмент, который анализирует логи в реальном времени и при обнаружении признаков атаки (множественные попытки входа, использование несуществующих пользователей) вносит IP-адрес атакующего в правила брандмауэра (iptables или nftables) на определенное время.

Установка и базовая настройка в дистрибутивах на базе Debian/Ubuntu:

Код: Выделить всё

apt update && apt install fail2ban

Не редактируйте основной файл jail.conf, создайте локальную копию /etc/fail2ban/jail.local для переопределения параметров:

Код: Выделить всё

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 3600

В данной конфигурации IP-адрес будет заблокирован на один час (bantime), если с него зафиксировано 3 неудачных попытки входа в течение 10 минут. После внесения изменений перезапустите службу:

Код: Выделить всё

systemctl restart fail2ban

Дополнительное ужесточение конфигурации (Hardening)

Для достижения максимального уровня защиты архитектура SSH должна учитывать временные параметры сессий и сетевые нюансы:

• Изменение стандартного порта. Перенос SSH с 22 на произвольный порт (например, 2244) не является защитой в строгом смысле (security by obscurity), но позволяет отсечь до 95% "шумового" трафика от примитивных ботов.
• Тайм-ауты сессий. Для предотвращения зависших соединений и защиты от несанкционированного доступа к открытому терминалу настройте автоматическое завершение:

  Код: Выделить всё

  ClientAliveInterval 300
  ClientAliveCountMax 0
  

• Отключение X11 Forwarding и Agent Forwarding. Если вы не используете проброс графического интерфейса или ключей, эти функции лучше отключить для минимизации векторов атак:

  Код: Выделить всё

  X11Forwarding no
  AllowAgentForwarding no
  

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

Мониторинг и аудит

Безопасность — это не состояние, а процесс. Регулярно проверяйте список активных соединений и историю входов. Для этого используйте системные утилиты:

• last — просмотр последних успешных входов в систему.
• fail2ban-client status sshd — просмотр статистики заблокированных IP-адресов.
• journalctl -u ssh — анализ системных сообщений демона SSH.

Согласно рекомендациям CIS Benchmarks, также следует ограничить права доступа к самому конфигурационному файлу sshd_config и директориям [.ssh], установив права 600 для ключей и 700 для папок, чтобы исключить чтение секретов другими пользователями системы. Применение описанного комплекса мер позволяет нейтрализовать большинство угроз, связанных с удаленным доступом, и обеспечить стабильную работу критической инфраструктуры.