Первоначальная настройка безопасности Linux на Ubuntu — базовая защита сервера после установки

Свежий сервер Ubuntu нельзя оставлять «как установили»: сначала нужно обновить систему, закрыть лишние входы, настроить SSH, firewall, пользователей, автоматические обновления и базовый мониторинг. Этот гайд помогает привести VPS или выделенный сервер к более безопасному состоянию без сложной корпоративной инфраструктуры.

Базовая защита Ubuntu начинается до установки приложений

Первичная настройка безопасности Linux — это не установка одного «волшебного» антивируса и не набор случайных команд из интернета. Это последовательность простых решений, которые уменьшают площадь атаки сервера.

Площадь атаки — это всё, через что к серверу можно подключиться, что можно просканировать, подобрать, сломать или использовать с ошибкой администратора. На новом Ubuntu-сервере обычно уже есть SSH-доступ, пакетный менеджер, системные службы, журналы, пользователи и сетевые настройки. Этого достаточно, чтобы сервер начал попадать в автоматические сканирования почти сразу после появления в интернете.

Задача первоначальной настройки — не сделать сервер «абсолютно неуязвимым». Такой цели в реальной админской практике нет. Задача проще и полезнее: убрать очевидные слабые места, включить предсказуемые правила доступа и подготовить систему к дальнейшей эксплуатации.

В качестве примера будем рассматривать Ubuntu Server 24.04 LTS и более новые LTS-релизы. Большинство команд также подходит для Ubuntu 22.04 LTS, Debian-подобных систем и типичного VPS. Для production-сервера команды стоит выполнять внимательно, особенно если вы подключены по SSH и можете случайно закрыть себе доступ.

Обновления закрывают известные уязвимости быстрее ручного администрирования

Первый шаг после входа на сервер — обновить список пакетов и установить доступные исправления.

sudo apt update
sudo apt upgrade -y

После крупных обновлений, особенно ядра, библиотек и системных служб, серверу может потребоваться перезагрузка:

sudo reboot

Проверить, требуется ли перезагрузка, можно так:

test -f /var/run/reboot-required && cat /var/run/reboot-required

Для сервера, который будет работать постоянно, важно включить автоматическую установку обновлений безопасности. В Ubuntu для этого используется механизм unattended-upgrades. Согласно документации Ubuntu Server, автоматические security updates в Ubuntu Server включены по умолчанию, а unattended-upgrades обычно выполняется раз в день. Официальная документация также указывает, что управление периодичностью находится в /etc/apt/apt.conf.d/20auto-upgrades, а подробные логи — в /var/log/unattended-upgrades.

Проверить наличие пакета можно так:

dpkg -l | grep unattended-upgrades

Если пакет отсутствует:

sudo apt install unattended-upgrades -y

Проверка базовой конфигурации:

cat /etc/apt/apt.conf.d/20auto-upgrades

Обычно там должны быть строки такого вида:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Первая строка отвечает за регулярное обновление списков пакетов, вторая — за автоматическую установку разрешённых обновлений.

Для небольшого VPS автоматические security updates часто полезнее, чем редкое ручное обслуживание. Но есть нюанс: на сложных production-системах обновления могут перезапускать службы или требовать перезагрузки. Поэтому для критичных проектов стоит заранее продумать окно обслуживания, резервные копии и порядок проверки после обновлений.

Новый пользователь снижает риск работы от имени root

Многие VPS-провайдеры выдают первый доступ к серверу под пользователем root. Это удобно для установки, но плохо для повседневной работы. Если вы постоянно работаете от имени root, любая ошибочная команда выполняется с максимальными правами.

Создайте отдельного пользователя:

adduser adminuser

Добавьте его в группу sudo:

usermod -aG sudo adminuser

Проверьте вход под новым пользователем в отдельной SSH-сессии:

ssh adminuser@SERVER_IP

После входа проверьте sudo-доступ:

sudo whoami

Если команда вернула root, пользователь настроен корректно.

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

SSH требует ключей, запрета root-входа и аккуратной проверки конфигурации

SSH — главный вход на сервер. Если он настроен небрежно, сервер может месяцами получать попытки перебора паролей. Базовая цель — перейти на вход по SSH-ключу, отключить парольную авторизацию и запретить прямой вход root.

SSH-ключ безопаснее обычного пароля

На локальном компьютере создайте ключ, если его ещё нет:

ssh-keygen -t ed25519 -C "admin@example"

Скопируйте публичный ключ на сервер:

ssh-copy-id adminuser@SERVER_IP

Если ssh-copy-id недоступен, можно добавить содержимое публичного ключа вручную в файл:

~/.ssh/authorized_keys

На сервере права должны быть строгими:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Проверьте, что вход по ключу работает:

ssh adminuser@SERVER_IP

Только после успешной проверки можно переходить к отключению парольного входа.

Конфигурацию SSH лучше менять через отдельный файл

В современных Ubuntu настройки OpenSSH могут подключаться не только из /etc/ssh/sshd_config, но и из каталога /etc/ssh/sshd_config.d/. Поэтому удобно создать отдельный файл с локальными правилами:

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

Добавьте базовые параметры:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3

Смысл параметров:

PermitRootLogin no запрещает прямой вход root по SSH;
PasswordAuthentication no отключает вход по паролю;
KbdInteractiveAuthentication no отключает keyboard-interactive авторизацию, которую иногда забывают закрыть вместе с паролями;
PubkeyAuthentication yes оставляет вход по SSH-ключу;
X11Forwarding no отключает ненужную для большинства серверов пересылку графических приложений;
MaxAuthTries 3 уменьшает число попыток авторизации в рамках одного соединения.

В официальной документации OpenSSH параметр PermitRootLogin описан как настройка, определяющая, разрешён ли вход root через SSH. Значение no полностью запрещает такой вход, а значение prohibit-password запрещает root-вход по паролю и keyboard-interactive, но может оставлять доступ по ключу.

Перед перезапуском SSH обязательно проверьте конфигурацию:

sudo sshd -t

Если ошибок нет, перезапустите службу:

sudo systemctl restart ssh

И снова проверьте вход в новой сессии:

ssh adminuser@SERVER_IP

Не закрывайте старую сессию до проверки новой.

Firewall разрешает только нужные входящие подключения

Firewall на сервере нужен не для красоты. Он задаёт понятные правила: какие входящие подключения разрешены, а какие должны быть отброшены. В Ubuntu стандартным удобным инструментом для базовой настройки является UFW — Uncomplicated Firewall. В документации Ubuntu указано, что UFW является стандартным инструментом настройки firewall в Ubuntu Server и по умолчанию изначально отключён.

Проверить статус:

sudo ufw status verbose

Базовая безопасная логика для типичного веб-сервера:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Перед включением firewall нужно разрешить SSH, иначе можно потерять доступ:

sudo ufw allow OpenSSH

Если 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 status numbered

Пример ожидаемой логики:

22/tcp     ALLOW IN    Anywhere
80/tcp     ALLOW IN    Anywhere
443/tcp    ALLOW IN    Anywhere

Если сервер используется только для API за reverse proxy, базы данных или внутреннего сервиса, открывать 80/443 может быть не нужно. Главное правило: открывайте только те порты, которые действительно используются.

Минимальный набор служб упрощает защиту сервера

Чем больше служб слушает сеть, тем сложнее понимать, что реально доступно извне. После установки сервера полезно посмотреть открытые порты:

sudo ss -tulpn

Команда покажет TCP/UDP-порты и процессы, которые их слушают. Для свежего сервера обычно ожидаем SSH. Для веб-сервера позже появятся Nginx или Apache на 80/443.

Посмотреть активные systemd-службы:

systemctl --type=service --state=running

Если вы видите службу, которую точно не используете, не спешите удалять её вслепую. Сначала проверьте назначение:

systemctl status SERVICE_NAME
apt show PACKAGE_NAME

Отключение лишней службы:

sudo systemctl disable --now SERVICE_NAME

Удаление пакета:

sudo apt remove PACKAGE_NAME

Для начинающего администратора безопаснее двигаться осторожно: сначала отключить, проверить работу сервера, потом удалять. На production-сервере перед такими действиями должны быть резервные копии и план отката.

Fail2ban помогает снизить шум от перебора паролей

Fail2ban не заменяет правильную настройку SSH и firewall. Его задача — читать журналы, находить повторяющиеся неудачные попытки входа и временно блокировать источник.

Установка:

sudo apt install fail2ban -y

Создайте локальный конфигурационный файл:

sudo nano /etc/fail2ban/jail.local

Минимальный пример для SSH:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
maxretry = 5
findtime = 10m
bantime = 1h

Запуск и включение автозагрузки:

sudo systemctl enable --now fail2ban

Проверка статуса:

sudo fail2ban-client status
sudo fail2ban-client status sshd

Fail2ban особенно полезен, если парольная авторизация ещё не отключена или если сервер постоянно сканируют. Но при входе только по ключам, запрете root-входа и закрытом firewall он становится дополнительным слоем, а не главным средством защиты.

Права sudo должны быть выданы только тем, кто администрирует сервер

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

Посмотреть пользователей с sudo-доступом можно так:

getent group sudo

Удалить пользователя из группы sudo:

sudo deluser username sudo

Создать пользователя без административных прав:

sudo adduser appuser

Такой пользователь может использоваться для отдельного приложения, если оно не должно работать от root. Например, веб-приложение, скрипт обработки задач или сервисный процесс.

Важный принцип: приложению не нужны права root, если оно не управляет системой. Чем меньше прав у процесса, тем меньше ущерб при его компрометации.

Журналы позволяют увидеть проблемы до аварии

Без журналов администрирование превращается в угадывание. В Ubuntu основные события можно смотреть через journalctl.

Ошибки текущей загрузки:

sudo journalctl -p warning..alert -b

Журнал SSH-службы:

sudo journalctl -u ssh

Последние записи в режиме наблюдения:

sudo journalctl -f

Попытки входа можно проверять через auth.log, если файл используется в вашей версии и конфигурации системы:

sudo grep "Failed password" /var/log/auth.log

Для Ubuntu на systemd-системах часто удобнее использовать journalctl, потому что часть событий централизованно попадает в systemd journal.

Полезно также проверять место на диске:

df -h

И размер каталогов журналов:

sudo du -sh /var/log/*

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

Резервные копии защищают лучше любой красивой настройки

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

Минимальный подход:

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

Для простого сайта на Ubuntu обычно нужны:

/etc/nginx или /etc/apache2
/etc/ssh
/etc/ufw
/home или /var/www
дампы баз данных
.env и другие конфигурации приложения

Пример ручного дампа MySQL/MariaDB:

mysqldump -u USER -p DATABASE_NAME > backup.sql

Пример архива каталога сайта:

tar -czf site-files.tar.gz /var/www/example.com

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

Базовая защита веб-сервера строится вокруг минимальных прав и HTTPS

Если на сервере будет сайт, API или панель управления, после системной настройки нужно аккуратно подойти к веб-слою.

Для Nginx или Apache базовые принципы одинаковые:

включить HTTPS;
не размещать секреты в публичном каталоге;
запретить выполнение лишних файлов там, где это не требуется;
не давать веб-пользователю права на системные каталоги;
разделять владельца кода и пользователя веб-сервера;
не открывать наружу базу данных, Redis, панели администрирования и внутренние сервисы.

Для Ubuntu-сервера с Nginx публичный каталог сайта часто находится в /var/www/.... Файл .env, конфигурации приложения, дампы базы данных, архивы и логи не должны быть доступны по прямой ссылке из браузера.

Плохой пример:

/var/www/site/public/backup.sql
/var/www/site/public/.env
/var/www/site/public/storage/logs/laravel.log

Хороший подход:

/var/www/site/
├── app
├── storage
├── .env
└── public

Веб-сервер должен смотреть только в public, а не в корень проекта.

Типичные ошибки делают сервер уязвимым даже после установки firewall

Начинающие администраторы часто выполняют отдельные правильные действия, но оставляют рядом грубые слабые места.

Открытый SSH по паролю сохраняет риск перебора

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

Firewall включён, но разрешены лишние порты

Команда sudo ufw enable сама по себе не делает сервер безопасным. Важны правила. Если открыты 3306, 6379, 9200, 8080 или панель администрирования без необходимости, firewall настроен плохо.

Root-вход запрещён только на бумаге

В новых версиях OpenSSH часть настроек может переопределяться файлами из sshd_config.d. Поэтому после изменения SSH нужно проверять итоговое поведение, а не просто считать, что строка в одном файле всё решила.

Проверка конфигурации перед перезапуском:

sudo sshd -t

Проверка входа root:

ssh root@SERVER_IP

Ожидаемый результат — отказ во входе.

Обновления включены, но перезагрузки никто не контролирует

Security updates могут установить важные пакеты, но часть исправлений начинает работать только после перезагрузки службы или сервера. Поэтому нужно проверять /var/run/reboot-required, планировать окна обслуживания и не копить месяцами обновления ядра без перезапуска.

Резервные копии существуют, но восстановление не проверялось

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

Практический чек-лист помогает не пропустить важные шаги

Ниже — последовательность, которую можно использовать после установки Ubuntu на VPS.

Первый вход и обновление

sudo apt update
sudo apt upgrade -y
test -f /var/run/reboot-required && sudo reboot

Пользователь для администрирования

adduser adminuser
usermod -aG sudo adminuser

Проверить вход новым пользователем и sudo-доступ:

ssh adminuser@SERVER_IP
sudo whoami

SSH-ключи и запрет паролей

На локальном компьютере:

ssh-keygen -t ed25519 -C "admin@example"
ssh-copy-id adminuser@SERVER_IP

На сервере:

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

Содержимое:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3

Проверка и перезапуск:

sudo sshd -t
sudo systemctl restart ssh

Firewall

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status numbered

Если это не веб-сервер, правила 80/443 не нужны.

Автоматические обновления безопасности

sudo apt install unattended-upgrades -y
cat /etc/apt/apt.conf.d/20auto-upgrades

Проверка логов:

sudo ls -la /var/log/unattended-upgrades/

Fail2ban

sudo apt install fail2ban -y
sudo nano /etc/fail2ban/jail.local

Содержимое:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
maxretry = 5
findtime = 10m
bantime = 1h

Запуск:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Проверка открытых портов и служб

sudo ss -tulpn
systemctl --type=service --state=running

Контроль журналов

sudo journalctl -p warning..alert -b
sudo journalctl -u ssh
df -h

Первичная настройка не заменяет дальнейшее сопровождение

После выполнения базовых шагов сервер становится заметно аккуратнее: вход по ключам, root закрыт, firewall ограничивает порты, обновления безопасности устанавливаются автоматически, а подозрительные попытки входа могут блокироваться Fail2ban.

Но это только первый слой. Дальше безопасность зависит от того, что именно будет работать на сервере: WordPress, Laravel, Docker, база данных, Telegram-бот, API, почтовый сервис или панель управления. У каждого сценария будут свои настройки, права, обновления, секреты и риски.

Хороший следующий шаг — описать для себя простую карту сервера:

Какие домены ведут на сервер
Какие порты открыты наружу
Какие приложения установлены
Где лежат конфигурации
Где хранятся секреты
Как создаются резервные копии
Как понять, что сервер сломан или атакован

Такой документ кажется скучным, но именно он помогает быстро восстановить контроль, когда что-то пошло не так.

Безопасный сервер начинается с дисциплины

Первоначальная настройка безопасности Ubuntu — это фундамент, который нужно выполнить до установки сайта, панели, базы данных и дополнительных сервисов. Обновления закрывают известные уязвимости, SSH-ключи защищают вход, UFW ограничивает сеть, отдельный пользователь снижает риск ошибок, Fail2ban уменьшает шум от автоматических атак, а журналы и бэкапы помогают не потерять контроль.

Для небольшого VPS этого уже достаточно, чтобы уйти от состояния «сервер открыт как попало» к нормальной базовой защите. Дальше нужно усиливать безопасность под конкретную задачу: веб-сервер, CMS, Docker, базу данных, CI/CD или внутренние сервисы.