Момент, когда вы наконец поднимаете новый VPS, — еще не повод расслабляться. Автоматические боты начинают сканировать сервер раньше, чем вы допьёте свой кофе, перебирая все известные эксплойты. Большинство таких попыток провалится, если только вы не забудете об элементарных вещах.
Безопасность сервера — это не задача «на потом». Это руководство проводит вас по первым шагам усиления нового удалённого сервера (будь то VPS или выделенный хостинг) с помощью универсальных приёмов в командной строке. Мы заменим слабые настройки по умолчанию, закроем очевидные лазейки для атак и заложим чистую базу, которую можно повторить на любом другом сервере.
Безопасность сервера — это контроль над машиной, который принадлежит только вам и никому больше. Это всё, что защищает систему от несанкционированного доступа, злоупотреблений и банальной человеческой глупости.
В нее входят:
Проще говоря, безопасность сервера — это дисциплина, которая делает вашу инфраструктуру защищённой, предсказуемой и надёжной — даже когда весь остальной интернет ведёт себя наоборот.
Самые первые шаги при подключении к новому серверу (в нашем случае — VPS) определяют, насколько безопасным он будет дальше. В этом разделе: как правильно подключиться к серверу и сразу установить все необходимые обновления системы, чтобы закрыть известные уязвимости.
Первое, что нужно сделать после получения VPS, — подключиться к нему по SSH (Secure Shell). Это основной и безопасный способ связи с машиной. SSH шифрует всё соединение, не позволяя никому перехватить логин или передаваемые данные.
Чтобы защититься максимально надёжно:
Так сервер будет впускать только те подключения, которые подтверждаются вашим приватным ключом — своего рода «замок и ключ», который автоматические боты не смогут взломать перебором.
Ваш новый VPS поставляется с IP-адресом, именем пользователя root и паролем. Чтобы подключиться, используйте SSH со своего компьютера.
Введите команду (замените your-server-ip на IP-адрес, выданный провайдером):
ssh root@your-server-ip
Например:
ssh root@37.1.112.112
При первом подключении SSH предупредит о «fingerprint» сервера — уникальном отпечатке ключа. Введите yes, чтобы продолжить, затем — пароль root. Если всё прошло успешно, вы увидите приглашение командной строки:
root@vps-321306:~#
Внутри нового VPS часто может оказаться устаревшее ПО — иногда на недели или месяцы. Хакеры это знают и активно сканируют сеть в поисках серверов со старыми ядрами и сервисами. Поэтому самое первое, что вы должны сделать после входа, — обновить всё, прежде чем ставить приложения или менять конфигурации.
Для Ubuntu/Debian выполните:
sudo apt update && sudo apt upgrade -y
Эта команда обновит списки пакетов, установит последние версии и уже на этом этапе устранит множество известных уязвимостей. Если среди обновлений было новое ядро Linux, изменения вступят в силу только после перезагрузки.
Лучшее решение на этом этапе — перезагрузить сервер:
sudo reboot
Сделайте это сейчас, а не когда-нибудь потом. Каждый час промедления — это ещё один бот, проверяющий ваш “старый” сервер на уязвимости.
После перезапуска проверьте текущую версию ядра:
uname -sr
Поддержание сервера в актуальном состоянии — самый важный шаг к его безопасности. Большинство атак происходит не из-за «нулевых уязвимостей», а потому что кто-то просто забыл нажать apt upgrade.
Управление пользователями и способами их аутентификации — краеугольный камень безопасности сервера. По умолчанию большинство серверов разрешают прямой вход под root по паролю, а это крайне небезопасно.
В этом разделе: как создать менее привилегированного пользователя для повседневных задач, настроить SSH для безопасной авторизации по ключам и отключить рискованный вход под root.
Выполнять всё под root — всё равно что оставить ключи от дома где-то на крыльце. Конечно, вы всегда можете попробовать. Вместо этого создайте обычного пользователя, который при необходимости будет поднимать привилегии через sudo.
После входа под root выполните команды:
adduser alex
usermod -aG sudo alex
Теперь вы можете входить под alex и повышать права только тогда, когда это действительно нужно. Если кто-то компрометирует эту учётку, ему всё равно придётся получать sudo, чтобы нанести серьёзный вред.
Если вы по-прежнему все делаете как root, это азартная игра со временем безотказной работы.
Когда вы убедились, что новый пользователь работает, пора закрыть одну из крупнейших брешей на свежем сервере — прямой SSH-вход под root.
Многие VPS-провайдеры по умолчанию позволяют заходить под root с мастер-паролем. Конечно, это удобно — пока какой-нибудь бот не подберёт пароль быстрее, чем вы успеете поставить ПО.
Root имеет неограниченную власть: подобрали пароль и машина уже не ваша. Лучший подход — заставить всех сначала входить как обычный пользователь и только при необходимости повышать права через sudo.
Откройте конфигурацию SSH:
sudo nano /etc/ssh/sshd_config
Найдите строку (если она закомментирована — раскомментируйте) и измените на:
PermitRootLogin no
Сохраните и выйдите (Ctrl+O, Enter, Ctrl+X).
Перезапустите службу SSH, чтобы изменения вступили в силу:
sudo systemctl restart sshd
С этого момента прямой вход под root по SSH невозможен. Подключайтесь под обычным пользователем и используйте sudo для администрационных задач. Один простой шаг и вы захлопываете огромную дверь, в которую боты так любят стучать.
Надёжные пароли — это хорошо, но их по-прежнему можно угадать, украсть или подобрать перебором — боты не спят.
SSH-ключи куда надёжнее: они опираются на криптографию, а не на человеческие секреты, и их практически невозможно взломать перебором. После настройки ключей вы вообще перестанете вводить пароль при входе.
На локальной машине (не на сервере) выполните:
ssh-keygen -t ed25519 -C you@example.com
При запросе нажмите Enter, чтобы сохранить ключ в файле по умолчанию (~/.ssh/id_ed25519). Для дополнительной безопасности можно задать passphrase — тогда даже при краже приватного ключа злоумышленник не сможет им воспользоваться без этой фразы.
Отправьте публичную часть ключа на сервер (замените alex на свое имя и your-server-ip на актуальный IP сервера):
ssh-copy-id alex@your-server-ip
Команда создаст ключи (если их ещё нет) и скопирует ваш публичный ключ на сервер.
На сервере проверьте, что ключ записан:
cat /home/alex/.ssh/authorized_keys
Вы должны увидеть там вашу строку с публичным ключом. Отныне при подключении по SSH сервер будет аутентифицировать вас по приватному ключу — без паролей.
Поздравляем — вы сделали вход практически невзламываемым. Разве что, если вы назовёте приватный ключ id_ed25519_final_FINAL_really_last.pem и умудритесь его потерять.
SSH — это излюбленная цель атакующих. В этом разделе рассказываем, как укрепить его конфигурацию: сменить порт по умолчанию, включить более строгую аутентификацию и подключить инструмент, который сам блокирует ботов, пытающихся подобрать пароль.
Большинство автоматических атак нацелено на порт 22 (стандартный для SSH). Смена порта не сделает сервер неуязвимым, но заметно уменьшит шум в логах.
Откройте конфигурацию SSH:
sudo nano /etc/ssh/sshd_config
Измените строку на:
Port 2222
Сохраните файл, обновите правила файрвола, чтобы разрешить новый порт, и обязательно протестируйте подключение, не разрывая текущую сессию:
ssh -p 2222 alex@your-server-ip
Если вы всегда подключаетесь с одного статического IP (например, из офиса), можно разрешить SSH-доступ только с этого адреса. Для UFW:
sudo ufw allow from 203.0.113.5 to any port 2222 proto tcp
Замените 203.0.113.5 на свой IP.
Чтобы SSH принимал подключения только по ключам, отредактируйте /etc/ssh/sshd_config:
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
Так вы исключите любую возможность взлома перебором пароля.
Fail2Ban следит за логами и блокирует IP-адреса, которые слишком активно пытаются войти в систему.
Установите и настройте его командами:
sudo apt install fail2ban -y
sudo nano /etc/fail2ban/jail.local
Добавьте секцию для SSH (если вы меняли порт, например на 2222, — укажите тот же):
[sshd]
enabled = true
port = 2222
bantime = 3600
maxretry = 5
Перезапустите Fail2Ban и проверьте статус:
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
С этого момента любой бот или человек, который продолжит долбиться в SSH, будет заблокирован автоматически. Это уменьшит шум в логах, охладит пыл атакующих и даст вам заниматься делом, а не смотреть, как по экрану бегут строки с ошибками входа.
Представьте файрвол как вышибалу у двери вашего сервера. Без него любой случайный запрос проходит внутрь. С ним — только разрешённые порты.
Есть три основных способа настроить файрвол в Linux:
Для большинства случаев оптимальный выбор — UFW. Он прост, надёжен и справляется со своей задачей без лишней возни.
Если вы используете CentOS/RHEL, просто замените команды UFW на firewall-cmd.
Начните с политики по умолчанию: запретить всё входящее, разрешить всё исходящее. Затем откройте только нужные порты.
sudo ufw default deny incoming
sudo ufw default allow outgoing
Теперь разрешите SSH (на вашем порту, например 2222):
sudo ufw allow 2222/tcp
Если на сервере запущен сайт, откройте также HTTP и HTTPS:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
И наконец, включите файрвол (UFW):
sudo ufw enable
Простое правило: если порт не используется — он должен быть закрыт.
sudo ufw delete allow 8080/tcp
Чтобы просмотреть активные правила файрвола в любой момент:
sudo ufw status verbose
Укрепление системы по самому простому сценарию можно свести к правилу: закрываете всё лишнее и оставляете только то, что действительно нужно.
Серверы часто поставляются с фоновыми службами, которые вам не нужны. А каждая лишняя служба — потенциальная уязвимость.
Посмотрите, что запущено:
systemctl list-unit-files --type=service | grep enabled
Если видите что-то вроде avahi-daemon или cups, и вы это не используете — смело отключайте:
sudo systemctl stop avahi-daemon
sudo systemctl disable avahi-daemon
Хакеры обожают ленивых админов — не доставляйте им такого удовольствия. Настройте автоматическую установку обновлений безопасности.
Для Ubuntu/Debian:
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades
Проверьте конфигурацию:
cat /etc/apt/apt.conf.d/20auto-upgrades
Теперь система будет регулярно подтягивать и устанавливать критические обновления — даже если вы забудете это сделать вручную.
Дополнительную защиту можно включить на уровне ядра с помощью sysctl.
Создайте новый файл конфигурации:
sudo nano /etc/sysctl.d/99-hardening.conf
Добавьте туда правила:
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.tcp_syncookies = 1
kernel.randomize_va_space = 2
Примените изменения:
sudo sysctl --system
Эти параметры включают защиту от подмены маршрутов, усиливают работу TCP и включают рандомизацию адресного пространства — мелочи, которые могут предотвратить большие неприятности.
Безопасность — это не только закрыть двери, но и знать, что происходит внутри. Мониторинг VPS позволяет видеть как нормальное поведение системы, так и подозрительные активности.
Ваш сервер уже ведёт обширные журналы событий — нужно лишь научиться их читать.
Просмотреть системные логи можно командой:
journalctl -xe
Или открыть классические записи syslog:
cat /var/log/syslog
Журналы — это первый источник правды о том, что действительно происходит на сервере.
Читать сырые логи каждый день — сомнительное удовольствие. Logwatch делает это за вас: собирает события и выдаёт краткие отчёты в удобном для чтения виде
sudo apt install logwatch -y
sudo logwatch --detail High --service All --range today --output stdout
Logrotate, который уже предустановлен почти везде, предотвращает разрастание логов до размеров, способных заполнить весь диск.
Для настройки частоты ротации можно отредактировать файл:
/etc/logrotate.conf
Если кто-то проник на сервер и изменил файлы — вам нужно узнать об этом сразу. Для этого нужны системы обнаружения вторжений.
Установите AIDE (Advanced Intrusion Detection Environment):
sudo apt install aide -y
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo aide --check
AIDE создаёт базу «эталонных» хэшей файлов и предупреждает, если что-то в системе изменилось без вашего ведома.
Для более продвинутых сценариев можно использовать OSSEC — он умеет присылать уведомления в реальном времени и анализировать логи на предмет корреляции событий.
Куда же без бэкапов и плана аварийного восстановления. Вы надеетесь, что они не пригодятся, но если вдруг — лучше, чтобы всё сработало безупречно.
Самый простой способ — использовать rsync. Вот короткий скрипт для резервного копирования вашего веб-каталога:
#!/bin/bash
SRC="/var/www/"
DEST="backup@backup-server:/backups/$(hostname -s)/"
rsync -avz --delete $SRC $DEST
Сохраните этот скрипт как /usr/local/bin/backup.sh и сделайте его исполняемым:
chmod +x /usr/local/bin/backup.sh
Теперь добавьте задачу в cron, чтобы она выполнялась автоматически:
crontab -e
0 2 * * * /usr/local/bin/backup.sh
Этот бэкап будет выполняться каждую ночь в 2:00.
У вас нет бэкапа, пока вы не проверили его восстановление. Желательно до сбоя в пятницу вечером...
Выберите тестовую директорию и выполните восстановление:
rsync -avz backup@backup-server:/backups/$(hostname -s)/ /tmp/restore-test/
Проверьте, что всё на месте:
ls -la /tmp/restore-test/
Надёжные бэкапы не должны храниться на том же сервере, который они защищают. Если этот сервер выйдет из строя или будет скомпрометирован, вы потеряете и данные, и копии.
Лучший вариант — выгружать резервные копии вне сервера, например, в облако с помощью rclone, который поддерживает AWS S3, Google Cloud, Backblaze B2 и другие хранилища.
Для дополнительной безопасности можно зашифровать файлы с помощью gpg или встроенного механизма rclone crypt. Даже если кто-то перехватит ваши архивы, расшифровать их без ключей он не сможет.
Также стоит продумать географическую изоляцию: храните бэкапы в разных дата-центрах или регионах. Если один из них выйдет из строя из-за сбоя или катастрофы, у вас останутся чистые копии в другом месте.
Следуйте правилу 3-2-1:
Когда сам сервер уже защищён, пора пойти дальше — укрепить безопасность приложений, которые на нём работают.
Веб-серверы и базы данных требуют особого внимания.
Первое правило для Nginx и Apache — никогда не запускать их от root. Используйте ограниченный системный аккаунт вроде www-data или создайте отдельного пользователя с минимальными правами.
Так, даже если веб-сервер будет скомпрометирован, злоумышленник не получит полный доступ к системе.
Также стоит:
Для баз данных (MySQL, Postgres) действуют те же принципы минимизации рисков. Привяжите их к 127.0.0.1, чтобы они принимали соединения только с локального хоста, если удалённый доступ не нужен:
# Example for MySQL to listen only locally
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address = 127.0.0.1
Обязательно используйте уникальные и сложные пароли для всех учётных записей и придерживайтесь принципа наименьших привилегий — каждый пользователь получает только те права, которые ему реально нужны.
Убедитесь, что веб-файлы не доступны для записи всем подряд. Пример команд для типичного каталога сайта:
sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 750 {} \;
sudo find /var/www/example.com -type f -exec chmod 640 {} \;
Такая настройка исключает случайное (или злонамеренное) изменение файлов приложений и конфигурации.
Шифрование трафика уже давно не опция, а обязательное условие безопасности и доверия. С Let’s Encrypt добавить HTTPS можно за несколько минут.
Установите Certbot:
sudo apt install snapd -y
sudo snap install core; sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
Запросите и установите сертификат для Nginx:
sudo certbot --nginx -d example.com -d www.example.com
Проверьте автообновление сертификатов:
sudo certbot renew --dry-run
Теперь ваш чистый VPS уже не похож на открытую дверь — скорее на крепость с оврагом по периметру. Ниже короткая «предполетная» проверка перед тем, как начинать работу на проектами на сервере.
Прогоняйте этот список каждый раз, когда поднимаете новый сервер. Пропустите шаг — и вскоре узнаете, зачем вообще нужен был этот список.
С этим чек-листом вам не нужно предугадывать, что и когда настривать для безопасности сервера. Сделайте один раз вручную, автоматизируйте во второй и спите спокойно, вместо того чтобы по ночам наблюдать за странными логами.