Чек-лист защиты сервера: 25 шагов от взлома до полной безопасности

Новый сервер в интернете — мишень с первых минут. Буквально. Автоматические сканеры находят открытые порты за секунды, боты начинают перебирать пароли, а непропатченные уязвимости эксплуатируются ещё до того, как вы допьёте кофе. На Хабре один администратор поделился неожиданным решением: он кормит вредоносных ботов zip-бомбами — отдаёт 1-мегабайтный файл, который разворачивается в 10 ГБ и кладёт бота на лопатки. Пост собрал 368 комментариев — люди спорили жарко. Мы прочитали всё это, выгребли самое полезное и собрали чек-лист защиты сервера: от азов до таких вот нестандартных трюков.

Зачем нужен чек-лист и кому он поможет?

Чек-лист — не замена политике безопасности. Это рабочий инструмент «взял и сделал». Он нужен:

• Системным администраторам — при развёртывании нового сервера (Linux или Windows Server)
• DevOps-инженерам — чтобы безопасность попала в CI/CD пайплайн, а не осталась на потом
• Малому бизнесу — когда выделенного ИБ-специалиста нет, а серверы уже стоят и работают
• При аудите — как отправная точка для проверки того, что реально настроено в инфраструктуре

К каждому пункту — конкретные команды и ссылки. Никаких догадок: берёшь и делаешь.

Часть 1: Базовая защита (первые 30 минут)

1. Обновите систему до актуального состояния

Первое, что мы делаем на любом новом сервере, — обновляем всё подряд. Старые пакеты с известными CVE — любимая еда ботнетов, они сканируют именно их, целенаправленно.

# Debian/Ubuntu
sudo apt update && sudo apt upgrade -y

# CentOS/RHEL
sudo dnf update -y

# Windows Server (PowerShell)
Install-Module PSWindowsUpdate -Force
Get-WindowsUpdate -Install -AcceptAll -AutoReboot

2. Настройте автоматические обновления безопасности

# Debian/Ubuntu — unattended-upgrades
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

# Проверка конфигурации
cat /etc/apt/apt.conf.d/20auto-upgrades

3. Создайте непривилегированного пользователя

Работа под root — классика жанра и главная ошибка. Видели это сотни раз. Заведите отдельного пользователя с sudo и забудьте про root для повседневных задач:

adduser admin
usermod -aG sudo admin  # Debian/Ubuntu
usermod -aG wheel admin # CentOS/RHEL

4. Настройте SSH: ключи, порт, root

Подробно расписали в статье Настройка безопасности SSH на Linux. Здесь — минимум, который нужен прямо сейчас:

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

5. Включите файрвол

# UFW (Debian/Ubuntu)
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 54322/tcp  # SSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

# Проверка
sudo ufw status verbose

Про построение правил подробнее — в статье iptables: настройка фаервола в Linux.

Часть 2: Активная защита от атак

6. Установите Fail2Ban

Fail2Ban блокирует IP после нескольких неудачных попыток входа. В том самом обсуждении на Хабре участники были единодушны: это «минимум, который должен стоять на любом публичном сервере». Трудно не согласиться — настраивается за 10 минут, а головной боли снимает много.

sudo apt install fail2ban -y

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 54322
maxretry = 3
bantime = 3600
findtime = 600

[nginx-botsearch]
enabled = true
filter = nginx-botsearch
logpath = /var/log/nginx/access.log
maxretry = 2
bantime = 86400

7. Настройте rate limiting на веб-сервере

# nginx.conf — ограничение запросов
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        limit_conn conn 10;
    }
}

8. Zip-бомбы для вредоносных ботов

Тот самый метод, из-за которого разгорелся весь сыр-бор. Суть проста: отдаёшь боту сжатый файл, который при распаковке съедает гигабайты памяти. Красиво — но комментаторы сразу указали на подводные камни:

# Создание gzip-бомбы (10 ГБ в сжатом виде ~10 МБ)
dd if=/dev/zero bs=1G count=10 | gzip -c > /var/www/bomb/10GB.gz

# PHP-обработчик
if (is_malicious_bot($ua, $ip)) {
    header("Content-Encoding: gzip");
    header("Content-Length: " . filesize("/var/www/bomb/10GB.gz"));
    readfile("/var/www/bomb/10GB.gz");
    exit;
}

Пользователь ihouser предложил альтернативу попроще: капча вместо бомб. Пользователь MkIV007 посоветовал прописать ограничения в robots.txt и Terms of Service — хотя бы чтобы закрыть юридический вопрос.

9. Tarpit: замедление атакующих

Более мягкий подход, чем zip-бомбы — без риска зацепить лишних. Tarpit просто тормозит ответы подозрительным клиентам, тратя их ресурсы:

# nginx — замедление подозрительных IP
map $remote_addr $slow_response {
    default 0;
    ~^192\.168\.100\. 5;  # медленный ответ для диапазона
}

server {
    location / {
        if ($slow_response) {
            # Используем lua или модуль delay
            access_by_lua_block {
                ngx.sleep(tonumber(ngx.var.slow_response))
            }
        }
    }
}

10. GeoIP-фильтрация

Если ваш сервер работает только на Россию и СНГ, остальной мир можно просто закрыть. Зачем держать дверь открытой для тех, кто к вам всё равно не придёт:

# iptables + xtables-addons
sudo apt install xtables-addons-common libtext-csv-xs-perl -y

# Блокировка конкретных стран
sudo iptables -A INPUT -m geoip ! --src-cc RU,BY,KZ,UA -j DROP

Часть 3: Мониторинг и аудит

11. Настройте логирование

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

# rsyslog — централизованные логи
# /etc/rsyslog.conf
*.* @logserver.internal:514

# journald — сохранение логов на диск
# /etc/systemd/journald.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
MaxRetentionSec=90day

12. Мониторинг целостности файлов (AIDE/Tripwire)

# Установка AIDE
sudo apt install aide -y

# Инициализация базы
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Проверка изменений (добавьте в cron)
sudo aide --check

13. Аудит открытых портов

# Что слушает сервер прямо сейчас?
sudo ss -tlnp

# Сканирование снаружи (с другого сервера)
nmap -sS -sV -p- server.example.com

# Автоматическая проверка раз в сутки
echo "0 6 * * * root ss -tlnp | mail -s 'Ports audit' admin@company.ru" >> /etc/crontab

14. Настройте уведомления

# Telegram-бот для алертов (простой скрипт)
#!/bin/bash
BOT_TOKEN="your_token"
CHAT_ID="your_chat_id"
MSG="$1"
curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
  -d chat_id="${CHAT_ID}" -d text="${MSG}" > /dev/null

15. Регулярные бэкапы с проверкой

# Ежедневный бэкап с ротацией
#!/bin/bash
BACKUP_DIR="/backup/$(date +%Y%m%d)"
mkdir -p "$BACKUP_DIR"

# Бэкап конфигурации
tar czf "$BACKUP_DIR/etc.tar.gz" /etc/
# Бэкап баз данных
pg_dumpall | gzip > "$BACKUP_DIR/postgres.sql.gz"

# Удаление старых бэкапов (> 30 дней)
find /backup -maxdepth 1 -mtime +30 -exec rm -rf {} \;

# ВАЖНО: проверка целостности
gunzip -t "$BACKUP_DIR/etc.tar.gz" && echo "Backup OK" || echo "Backup CORRUPTED!"

Часть 4: Защита веб-приложений

16. HTTP-заголовки безопасности

# nginx — добавляем заголовки
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' fonts.googleapis.com; font-src fonts.gstatic.com;" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;

17. SSL/TLS: правильная конфигурация

# Генерация сертификата Let's Encrypt
sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d server.example.com

# nginx ssl_params.conf
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_stapling on;
ssl_stapling_verify on;

18. WAF (Web Application Firewall)

# ModSecurity с nginx
sudo apt install libmodsecurity3 libmodsecurity-dev -y

# Включение OWASP Core Rule Set
git clone https://github.com/coreruleset/coreruleset /etc/nginx/modsec/crs
cp /etc/nginx/modsec/crs/crs-setup.conf.example /etc/nginx/modsec/crs/crs-setup.conf

19. Защита от DDoS на уровне приложения

# nginx — ограничения по размеру и таймауту
client_max_body_size 10m;
client_body_timeout 12;
client_header_timeout 12;
send_timeout 10;
keepalive_timeout 15;

# Ограничение количества соединений с одного IP
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;

Часть 5: Продвинутые техники

20. Port knocking

SSH-порт «не существует», пока не постучишь в нужные порты в правильной последовательности. Звучит как магия — работает как надёжный фильтр:

# Установка knockd
sudo apt install knockd -y

# /etc/knockd.conf
[openSSH]
    sequence = 7000,8000,9000
    seq_timeout = 5
    command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 54322 -j ACCEPT
    tcpflags = syn

[closeSSH]
    sequence = 9000,8000,7000
    seq_timeout = 5
    command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 54322 -j ACCEPT
    tcpflags = syn

21. Двухфакторная аутентификация SSH

# Google Authenticator для SSH
sudo apt install libpam-google-authenticator -y

# Настройка для пользователя
google-authenticator -t -d -f -r 3 -R 30 -w 3

# /etc/pam.d/sshd — добавить строку
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

22. Контейнерная изоляция сервисов

Каждый сервис — в отдельном контейнере. Если один скомпрометируют, до остальных атакующий не доберётся:

# docker-compose.yml — пример изоляции
version: '3.8'
services:
  web:
    image: nginx:alpine
    read_only: true
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp
    networks:
      - frontend
  app:
    image: myapp:latest
    read_only: true
    networks:
      - frontend
      - backend
  db:
    image: postgres:16-alpine
    networks:
      - backend
    volumes:
      - pgdata:/var/lib/postgresql/data

networks:
  frontend:
  backend:
    internal: true  # база недоступна снаружи

23. Аудит с помощью Lynis

# Установка
sudo apt install lynis -y

# Полный аудит системы
sudo lynis audit system

# Результат — оценка hardening index и список рекомендаций
# Пример вывода:
# Hardening index : 72 [##############      ]
# Tests performed : 256
# Warnings        : 3
# Suggestions     : 12

24. Honeypot: ловушка для атакующих

Один из участников дискуссии верно заметил: honeypot лучше держать на отдельном сервере, иначе рискуете подставить основную инфраструктуру. Из проверенных вариантов:

• Cowrie — эмулирует SSH/Telnet, записывает каждое действие атакующего — иногда читаешь логи как детектив
• Dionaea — ловит эксплойты для SMB, HTTP, FTP
• T-Pot — комплексная платформа, под капотом 20+ honeypot сразу

# Быстрый запуск Cowrie в Docker
docker run -d --name cowrie \
  -p 2222:2222 \
  -v cowrie-logs:/cowrie/var/log \
  cowrie/cowrie:latest

25. Документируйте всё

Последний пункт — и, пожалуй, самый недооценённый. Ведите журнал:

• Какие меры внедрены и когда именно
• Результаты каждого аудита
• Инциденты и выводы из них
• Конфигурации и почему выбраны именно такие решения
• Контакты ответственных за каждую систему

Сводная таблица: приоритеты защиты

Времени в обрез? Начните с самого критичного — вот очерёдность из нашей практики:

• Критично (день 1): обновления, SSH-ключи, файрвол, отключение root
• Высокий (неделя 1): Fail2Ban, логирование, бэкапы, SSL
• Средний (месяц 1): WAF, rate limiting, мониторинг целостности, 2FA
• Продвинутый: port knocking, honeypot, GeoIP, контейнерная изоляция

Часто задаваемые вопросы (FAQ)