Базовая безопасность Linux-сервера: SSH, firewall, обновления и hardening

Безопасность Linux-сервера часто страдает не из-за сложных атак, а из-за банальной неаккуратности: root по паролю открыт в интернет, firewall не настроен, пакеты не обновлялись месяцами, резервного копирования нет, а секреты лежат в текстовом файле рядом с приложением. Хорошая новость в том, что базовый hardening даёт очень заметный эффект и не требует редкой магии.

1. Начните с SSH: это главная дверь

Если сервер доступен по SSH из интернета, он почти наверняка будет постоянно получать шумовые попытки перебора. Поэтому первый слой защиты — аккуратно настроить сам вход.

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers deploy admin

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

sshd -t
systemctl reload sshd

Отдельно полезно продумать, кто вообще должен иметь SSH-доступ. Чем меньше список пользователей и IP-источников, тем лучше.

2. Firewall: правило по умолчанию должно быть строгим

Базовый принцип простой: разрешать только то, что действительно нужно. Всё остальное — закрыто. Конкретный инструмент может быть любым: ufw, nftables, iptables. Важно не название, а ясность набора правил.

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Если порт нужен только из внутренней сети или через VPN, не стоит публиковать его наружу. Очень много проблем исчезает просто потому, что сервис перестаёт быть виден всему интернету.

3. Обновления: «потом» обычно означает «слишком поздно»

Не каждая уязвимость критична, но привычка регулярно обновлять систему и базовые пакеты — это минимальная гигиена. Особенно для серверов с публичным доступом.

apt update
apt upgrade
apt list --upgradable

# для RHEL-подобных
dnf check-update
dnf upgrade

Важно, чтобы обновления были не только «вроде установлены», но и сопровождались контролем сервисов после применения: не упали ли unit-ы, не изменился ли формат конфигурации, не требует ли что-то ручного вмешательства.

4. Права и учётные записи

Чем дольше сервер живёт, тем больше на нём случайных пользователей, устаревших ключей и непонятных sudo-прав. Это надо ревизовать.

getent passwd
awk -F: '$3 >= 1000 {print $1}' /etc/passwd
sudo -l -U deploy
find /home -name authorized_keys -type f -print
lastlog | head

В продакшене полезно иметь понятную политику:

• кто получает SSH-доступ;
• кто имеет sudo и на какие команды;
• как удаляются ключи после ухода сотрудника или подрядчика;
• где хранится список аварийных доступов.

5. Fail2ban и защита от грубого перебора

Fail2ban не решает всю безопасность, но отлично уменьшает шум на публичных сервисах, особенно на SSH и в некоторых сценариях веб-периметра.

apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
maxretry = 5
findtime = 10m
bantime = 1h

Главное — не считать Fail2ban заменой ключевой авторизации и firewall. Это именно дополнительный слой, а не основа безопасности.

6. Секреты, конфиги и журналы

Секреты в открытом виде — один из самых частых источников риска. Пароли и токены не должны лежать в Git-репозитории, world-readable файлах или внутри образов без контроля.

chmod 600 /etc/myapp/secrets.env
chown root:root /etc/myapp/secrets.env

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

7. Бэкапы: без них hardening неполон

Безопасность — это не только защита от входа, но и способность восстановиться после ошибки, сбоя или компрометации. Поэтому резервные копии — обязательный элемент.

• проверяйте, что backup действительно создаётся;
• периодически тестируйте восстановление;
• храните копии отдельно от основного хоста;
• защищайте доступ к backup-репозиторию.

«Бэкап есть» без теста восстановления — это просто красивая гипотеза.

8. Минимальный аудит публичного Linux-сервера

# какие порты слушают
ss -tulpn

# какие правила на firewall
ufw status verbose

# кто может логиниться
grep -E 'PermitRootLogin|PasswordAuthentication|AllowUsers' /etc/ssh/sshd_config

# какие сервисы активны
systemctl list-units --type=service --state=running

# что с журналом ошибок
journalctl -p err -b

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

9. Частые анти-паттерны

1. Открытый root-доступ по паролю.
2. Все сервисы опубликованы в интернет, даже внутренние.
3. Деплой выполняется вручную под root.
4. Никто не знает, где лежат резервные копии и как их восстановить.
5. Патчи откладываются бесконечно, потому что «сейчас страшно обновлять».

Эти проблемы не решаются одной утилитой. Они решаются инженерным режимом работы: понятные доступы, регулярная ревизия, automation-friendly конфиги и внятный контроль изменений.

Базовая безопасность — это не «параноидальный режим», а нормальное состояние публичного сервера.

Итог

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