Каждый день тысячи серверов по всему миру взламываются не потому что у злоумышленников сложные инструменты, а потому что администраторы не сделали базовую настройку. Стандартный Ubuntu или CentOS после установки — это открытая дверь: root-доступ по SSH, дефолтный порт 22, никакого файрволла.
Этот чеклист — не теория. Каждый пункт можно сделать руками за вечер.
Сначала — обновления
Первое, что нужно сделать на свежем сервере, ещё до любых настроек:
apt update && apt upgrade -y
Звучит банально, но уязвимости в ядре и системных пакетах — это реальная история. Heartbleed, Shellshock, Dirty COW — все эти громкие CVE эксплуатировались именно на серверах, которые просто давно не обновлялись.
Настройте автоматические обновления безопасности:
apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades
Проверьте /etc/apt/apt.conf.d/50unattended-upgrades — там можно настроить автоперезагрузку и уведомления на почту.
SSH — главная точка входа
По умолчанию SSH слушает порт 22. Боты сканируют весь интернет и ломятся именно туда. Посмотрите логи на любом свежем сервере:
grep 'Failed password' /var/log/auth.log | wc -l
Через несколько часов после запуска там будут сотни попыток.
Смена порта
Откройте /etc/ssh/sshd_config и измените:
Port 2222
Порт не должен быть занят. Проверьте: ss -tlnp | grep 2222. После смены не забудьте открыть новый порт в файрволле и только потом перезапускать SSH — иначе рискуете потерять доступ.
Отключение root-входа
PermitRootLogin no
Создайте отдельного пользователя с sudo-правами:
adduser deploy
usermod -aG sudo deploy
Теперь для выполнения привилегированных команд нужно сначала зайти под обычным пользователем, а потом использовать sudo. Это добавляет дополнительный барьер.
Только ключи, никаких паролей
Парольная аутентификация — слабое место. Ключи несравнимо надёжнее. Сгенерируйте пару на своей машине:
ssh-keygen -t ed25519 -C "deploy@myserver"
Публичный ключ скопируйте на сервер:
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@your-server
После того как убедились, что вход по ключу работает, отключите парольную аутентификацию:
PasswordAuthentication no
PubkeyAuthentication yes
Дополнительные параметры sshd_config
X11Forwarding no
AllowTcpForwarding no
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2
Последние два параметра отключат зависшие сессии через 10 минут бездействия.
Файрволл
UFW (Uncomplicated Firewall) — самый простой способ настроить правила на Ubuntu:
apt install ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp # ваш SSH-порт
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
Проверьте статус: ufw status verbose.
Если используете iptables напрямую — базовые правила выглядят так:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -P INPUT DROP
Сохраните правила: iptables-save > /etc/iptables/rules.v4.
Fail2ban — защита от брутфорса
Даже с ключами и нестандартным портом боты продолжат стучаться. Fail2ban банит IP-адреса после нескольких неудачных попыток:
apt install fail2ban
Создайте /etc/fail2ban/jail.local:
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
[sshd]
enabled = true
port = 2222
logpath = /var/log/auth.log
Перезапустите: systemctl restart fail2ban.
Посмотреть заблокированные IP: fail2ban-client status sshd.
Fail2ban работает не только с SSH — его можно настроить под Nginx, Apache, Postfix и другие сервисы.
Минимизация поверхности атаки
Правило простое: чем меньше сервисов запущено, тем меньше потенциальных уязвимостей.
Посмотрите, что сейчас слушает сеть:
ss -tlnp
Если видите незнакомые порты — разберитесь, что там висит, и отключите лишнее.
Проверьте автозапуск сервисов:
systemctl list-unit-files --state=enabled
Отключите то, что не нужно:
systemctl disable bluetooth
systemctl disable cups
Конкретный список зависит от задачи сервера. На VPS под веб-приложение точно не нужны Bluetooth, принтеры и avahi-daemon.
Права доступа к файлам
Несколько быстрых проверок:
# Файлы с SUID-битом (выполняются с правами владельца)
find / -perm -4000 -type f 2>/dev/null
# Файлы с широкими правами записи
find /etc -perm -002 -type f 2>/dev/null
# Файлы без владельца
find / -nouser -o -nogroup 2>/dev/null
SUID-файлы — частая цель для privilege escalation. Их должно быть немного: passwd, sudo, ping. Всё остальное — повод разобраться.
Критичные файлы конфигурации должны быть доступны только root:
chmod 600 /etc/shadow
chmod 644 /etc/passwd
chmod 640 /etc/sudoers
Sudo — аккуратно с правами
Посмотрите текущие sudo-права:
cat /etc/sudoers
ls /etc/sudoers.d/
Никогда не давайте NOPASSWD: ALL без крайней необходимости. Если нужно, чтобы скрипт мог перезапускать конкретный сервис без пароля — пропишите только его:
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx
Проверяйте, кто состоит в группе sudo:
getent group sudo
Шифрование и сертификаты
HTTPS сегодня — не опция, а обязательное требование. Let's Encrypt решает этот вопрос бесплатно:
apt install certbot python3-certbot-nginx
certbot --nginx -d yourdomain.com
Проверьте настройки TLS в Nginx или Apache. Отключите старые протоколы:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
ssl_prefer_server_ciphers off;
Проверить конфигурацию можно через SSL Labs (ssllabs.com/ssltest/) — он покажет оценку и конкретные проблемы.
Автообновление сертификата:
crontab -e
# Добавьте:
0 3 * * * certbot renew --quiet
Логи и мониторинг
Логи бесполезны, если их никто не читает. Настройте централизованный сбор хотя бы на уровне одного сервера.
Полезные файлы:
/var/log/auth.log — авторизации, sudo, SSH/var/log/syslog — системные события/var/log/nginx/access.log и error.log — веб-трафик
Для мониторинга подозрительной активности — logwatch:
apt install logwatch
logwatch --detail High --mailto admin@yourdomain.com --range today
Аuditd позволяет отслеживать конкретные файлы и системные вызовы:
apt install auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
auditctl -w /etc/sudoers -p wa -k sudoers_changes
Смотреть события: ausearch -k passwd_changes.
Проверка целостности системы
AIDE (Advanced Intrusion Detection Environment) создаёт базу хэшей файлов и сигнализирует об изменениях:
apt install aide
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
Проверка:
aide --check
Добавьте в cron ежедневную проверку с отправкой отчёта. Если кто-то подменил бинарник или изменил конфиг — вы узнаете об этом утром.
Ограничение ресурсов
Лимиты на уровне системы защищают от fork bomb и других атак типа resource exhaustion. Отредактируйте /etc/security/limits.conf:
* soft nproc 1024
* hard nproc 2048
* soft nofile 65536
* hard nofile 65536
Для systemd-сервисов задавайте лимиты в unit-файле:
[Service]
LimitNOFILE=65536
LimitNPROC=512
MemoryMax=512M
CPUQuota=50%
Разделение сетевых зон
Если на сервере крутится база данных — она не должна быть доступна извне. Только с localhost или из приватной сети:
# В /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address = 127.0.0.1
То же самое для Redis, Memcached и других хранилищ данных. Открытый Redis без пароля на публичном IP — это классика, которая стоила многим компаниям утечки данных.
Чеклист одним списком
Для удобства — всё вышесказанное в виде списка:
- Обновить систему и включить автообновления безопасности
- Сменить порт SSH
- Отключить root-вход по SSH
- Настроить аутентификацию по ключу, отключить пароли
- Настроить файрволл (UFW или iptables), закрыть всё лишнее
- Установить fail2ban
- Отключить неиспользуемые сервисы
- Проверить файлы с SUID-битом
- Настроить права на критичные конфигурационные файлы
- Проверить sudo-права, убрать NOPASSWD там где не нужно
- Включить HTTPS, настроить TLS 1.2+
- Настроить сбор и мониторинг логов
- Развернуть AIDE для контроля целостности
- Закрыть базы данных от публичного доступа
- Настроить лимиты ресурсов
Это не разовая задача
Hardening — не то, что делается один раз и забывается. Новые уязвимости появляются постоянно. Подписывайтесь на рассылки безопасности: Ubuntu Security Notices, CERT/CC, CVE Details.
Раз в квартал прогоняйте сервер через lynis — это бесплатный аудитор безопасности:
apt install lynis
lynis audit system
Он выдаст оценку и конкретный список рекомендаций с приоритетами.
Если у вас несколько серверов или нет времени разбираться в деталях — можно доверить настройку и поддержку специалистам. Команда REEXY (r3xy.ru) занимается в том числе поддержкой и администрированием: поддержка сайта от 10 000 ₽/мес включает мониторинг, обновления и базовое обеспечение безопасности.
Но даже если вы всё делаете сами — этот чеклист закроет 90% типичных векторов атак на небольшой VPS. Остальные 10% — это уже история про пентесты, WAF и более серьёзную инфраструктуру.