С чего начать защиту сервера
У вас новый сервер. Или старый, но вы понимаете, что безопасность — не его сильная сторона. С чего начать? Что делать в первую очередь, а что можно отложить? Сколько это займёт времени?
Хорошая новость: базовую защиту сервера можно настроить за один день. Существует проверенный порядок действий: сначала закрыть самое критичное, потом постепенно усиливать. В этой статье — пошаговый план из 10 шагов, которые защитят сервер от большинства атак. Если нужно настроить защиту сервера — поможем.
Почему это важно
Сервер без защиты взламывают быстро. По статистике, сервер с открытым SSH и слабым паролем взламывают в течение 24–48 часов после запуска.
Боты сканируют всё
Автоматические сканеры обходят весь интернет. Ваш сервер найдут быстро.
Уязвимости есть всегда
Даже в свежих версиях ПО находят уязвимости. Нужны обновления и защита.
DDoS и атаки
Сервер может быть использован для атак на других, даже если вас не интересуют.
Репутация
Взломанный сервер попадает в чёрные списки. Письма не доходят, пользователи не заходят.
Приоритеты
Не всё можно сделать сразу. Есть критичные шаги, которые нужно выполнить в первую очередь, и есть те, что можно отложить.
| Приоритет | Что делать | Сколько времени |
|---|---|---|
| Критично (день 1) | Обновления, SSH-ключи, файрвол | 2–3 часа |
| Важно (неделя 1) | Fail2ban, пользователи, бэкапы | 1–2 дня |
| Планово (месяц 1) | Мониторинг, логирование, аудит | 2–3 дня |
| Постоянно | Документация, ротация, обучение | Регулярно |
💡 Важно
Начните с критичных шагов. Даже если сделаете только их — уже защитите сервер от 90% типовых атак. Остальное можно добавлять постепенно.
Шаг 1. Обновления
Первое, что нужно сделать на новом или старом сервере — установить все обновления.
Что делать
- Ubuntu / Debian: apt update && apt upgrade -y;
- CentOS / AlmaLinux: dnf update -y;
- Автообновления: unattended-upgrades для Ubuntu;
- Ядро: не забудьте перезагрузиться, если обновилось ядро.
Почему это критично
Большинство атак используют известные уязвимости. Если ПО обновлено — атака не сработает. Обновления — самый простой и самый эффективный шаг в защите.
Автоматизация
- Ubuntu: apt install unattended-upgrades && dpkg-reconfigure -plow unattended-upgrades;
- CentOS: dnf-automatic — установка и настройка;
- Проверка: регулярно смотреть логи обновлений.
Шаг 2. SSH-ключи
SSH — главная цель атакующих. Защитить его — критично.
Что делать
- Сгенерировать ключ: ssh-keygen -t ed25519;
- Скопировать на сервер: ssh-copy-id user@server;
- Проверить вход по ключу: ssh user@server;
- Отключить пароли: PasswordAuthentication no в /etc/ssh/sshd_config;
- Отключить root: PermitRootLogin no;
- Сменить порт: Port 22022 (опционально);
- Перезапустить SSH: systemctl restart sshd.
Подробнее — в статье SSH-ключи и 2FA.
💡 Важно
Перед отключением паролей убедитесь, что вход по ключу работает. Проверяйте в отдельной сессии, не закрывайте текущую.
Шаг 3. Файрвол
Файрвол закрывает все порты, кроме нужных. Это вторая линия защиты после SSH.
Что делать
- Выбрать инструмент: ufw (простой) или nftables (современный);
- Разрешить SSH: обязательное правило;
- Разрешить веб: 80, 443 для веб-сервера;
- Запретить всё остальное: default deny incoming;
- Сохранить правила: чтобы не сбрасывались при перезагрузке;
- Включить: применить изменения.
Пример ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 80/tcp
ufw allow 443/tcp
ufw enableПодробнее — в статье Файрвол на сервере.
Шаг 4. Fail2ban
Fail2ban анализирует логи и блокирует IP-адреса, с которых идут атаки.
Что делать
- Установить: apt install fail2ban;
- Скопировать конфиг: cp jail.conf jail.local;
- Настроить sshd: включить jail для SSH;
- Настроить bantime, findtime, maxretry;
- Добавить ignoreip: свой IP не блокировать;
- Перезапустить и проверить: fail2ban-client status sshd.
Подробнее — в статье Fail2ban: защита от брутфорса.
Шаг 5. Пользователи и права
Убедитесь, что пользователи и права настроены правильно.
Что делать
- Список пользователей: удалить ненужных, заблокировать дефолтных;
- Root: вход под root запрещён, использовать sudo;
- Sudo: только у тех, кому нужно;
- Пароли: сложные, менять при уходе сотрудников;
- Права на файлы: 644 для файлов, 755 для папок;
- Ownership: файлы сайта не должны принадлежать root;
- Скрытые пользователи: проверить /etc/passwd.
Что проверить
- UID 0: только root должен иметь UID 0;
- Пустые пароли: нет пользователей без пароля;
- Sudoers: минимальный список;
- SSH-доступ: только у тех, кому нужно.
Шаг 6. Бэкапы
Бэкапы — страховка от потери данных. Без них любая ошибка или атака может стать фатальной.
Что делать
- Выбрать стратегию: правило 3-2-1;
- Настроить автоматизацию: ежедневные бэкапы через cron;
- Хранить вне сервера: S3, другой сервер, внешний диск;
- Зашифровать: данные в бэкапах не должны быть доступны;
- Тестировать: раз в месяц восстанавливать;
- Документировать: как восстановить, где лежит.
💡 Важно
Бэкап на том же сервере — не бэкап. Если сервер упадёт или его зашифрует вирус — данные потеряются вместе с бэкапом.
Шаг 7. Мониторинг
Мониторинг помогает узнавать о проблемах раньше пользователей.
Что мониторить
- CPU, RAM, диски: базовые ресурсы;
- Сервисы: nginx, БД, PHP-FPM — работают ли;
- Доступность: сайт открывается извне;
- Аномалии: резкий рост нагрузки, ошибки;
- Безопасность: попытки входа, подозрительные запросы.
Инструменты
- Uptime-мониторинг: UptimeRobot, Pingdom;
- Метрики: Prometheus + Grafana;
- Zabbix: классика для серверов;
- Алерты: Telegram, email.
Шаг 8. Логирование
Логи — это «черный ящик» сервера. Они показывают, что происходило.
Что логировать
- Входы: SSH, админки;
- Ошибки: приложения, веб-сервера, БД;
- Аномалии: подозрительные запросы, попытки взлома;
- Изменения: кто что менял.
Что важно
- Ротация: logrotate для старых логов;
- Централизация: ELK, Graylog — сбор со всех серверов;
- Хранение: минимум 30 дней, лучше год;
- Доступ: логи не должны быть доступны всем.
Шаг 9. Аудит
Аудит — регулярная проверка безопасности. Проводится раз в 6–12 месяцев.
Что делать
- Lynis: автоматический аудит конфигураций;
- Nmap: сканирование портов извне;
- OpenVAS: сканирование уязвимостей;
- testssl.sh: проверка SSL;
- Проверка логов: подозрительная активность.
Подробнее — в статье Аудит безопасности.
Шаг 10. Документация
Документация — скучный, но важный шаг. Без неё все знания у одного человека.
Что документировать
- Схему инфраструктуры: какие серверы, что на них;
- Настройки безопасности: что настроено, где;
- Доступы: кто имеет доступ, к чему;
- Пароли и ключи: где хранятся (в менеджере паролей);
- Регламенты: как реагировать на инциденты;
- Контакты: кто ответственный, к кому обращаться.
Где хранить
- Wiki: Confluence, Notion, локальная wiki;
- Менеджер паролей: Bitwarden, 1Password, KeePass;
- Git: для конфигов и скриптов;
- Защита: документация тоже должна быть защищена.
Наши рекомендации
Что вы получаете, заказывая базовую защиту у нас
- Обновления — установка и настройка автообновлений
- SSH-ключи — вместо паролей
- Файрвол — закрытие лишних портов
- Fail2ban — защита от брутфорса
- Бэкапы — настройка резервного копирования
- Мониторинг — базовые метрики и алерты
📌 Итоговый вывод
Защита сервера — это последовательность шагов, а не разовое действие.
Что нужно знать:
- Приоритеты — критично, важно, планово, постоянно
- Шаг 1 — обновления
- Шаг 2 — SSH-ключи
- Шаг 3 — файрвол
- Шаг 4 — Fail2ban
- Шаг 5 — пользователи и права
- Шаг 6 — бэкапы
- Шаг 7 — мониторинг
- Шаг 8 — логирование
- Шаг 9 — аудит
- Шаг 10 — документация
Также рекомендуем: 152-ФЗ для серверов, аудит безопасности, Fail2ban, файрвол на сервере, SSH-ключи и 2FA, настройка безопасности.