Debian 12: первичная настройка и безопасность с нуля

MAATRIX

Debian 12 (bookworm) ценят за стабильность и минимализм: свежий образ содержит почти голую систему без лишнего. Но эта же аскетичность значит, что первичную настройку и безопасность Debian 12 с нуля придётся сделать самому — по умолчанию сервер отвечает под root по паролю и открыт всем ветрам. Пройдём путь от первого входа до защищённой машины: доустановим sudo, заведём рабочего пользователя, перейдём на SSH-ключи, поднимем фаервол и включим автообновления.

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

Подключитесь к серверу по SSH под root, используя выданные IP и пароль:

ssh root@ВАШ_IP

Первым делом обновите систему — за время хранения образа вышли исправления безопасности:

apt update && apt upgrade -y

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

hostnamectl set-hostname my-server
timedatectl set-timezone Europe/Moscow

В отличие от многих готовых образов, минимальный Debian часто идёт вообще без части привычных утилит — это нормально для дистрибутива, который принципиально не тянет ничего лишнего. Нужные пакеты мы доустановим по ходу.

Доустанавливаем sudo

Важная особенность Debian: в минимальной установке пакет sudo может отсутствовать, а работа идёт напрямую под root. Первым делом это стоит исправить, потому что вся дальнейшая практика безопасности строится вокруг обычного пользователя с правами через sudo. Установите пакет под root:

apt install -y sudo

sudo — это механизм, который позволяет обычному пользователю выполнять отдельные команды с правами администратора, каждый раз подтверждая действие паролем. Такой подход безопаснее постоянной работы под root: случайная опасная команда потребует явного повышения прав, а не выполнится молча. После установки sudo мы заведём пользователя и включим его в нужную группу — это фундамент всей настройки.

Почему это важнее, чем кажется на первый взгляд. Root — всемогущий пользователь: он способен стереть систему одной опечаткой и не задаёт лишних вопросов. Обычный пользователь с sudo, наоборот, каждый раз явно подтверждает административное действие вводом пароля, и это маленькое трение не раз спасало серверы от случайного удаления не в той директории. Кроме того, автоматические атаки почти всегда ломятся именно в учётную запись root, потому что она есть на каждой Linux-машине и её имя известно заранее. Ваш пользователь называется как угодно, и подобрать сразу и имя, и ключ практически нереально. Поэтому связка «отдельный пользователь плюс запрет входа root» — не бюрократия ради галочки, а фундамент, на который ложится всё остальное. В минималистичном Debian, где вы настраиваете всё сами, заложить этот фундамент правильно особенно важно.

Создаём рабочего пользователя

Заведите обычного пользователя и дайте ему административные права, добавив в группу sudo. Замените deploy на удобное имя:

adduser deploy
usermod -aG sudo deploy

Команда adduser в Debian интерактивна: она спросит пароль и несколько необязательных полей, которые можно пропустить клавишей Enter. Группа sudo в Debian — это та самая группа, членам которой разрешено повышать права. Проверьте, что всё работает: войдите под новым пользователем командой su - deploy и выполните sudo whoami — ответ root подтвердит, что права выданы верно. Дальше всю настройку ведите из-под этого пользователя, а прямой вход root мы вскоре закроем. Работа под отдельной учёткой — не формальность: именно в root целятся автоматические атаки, ведь эта учётная запись есть на каждом сервере.

Настраиваем вход по SSH-ключу

Пароль перебираем, ключ — практически нет. На своём домашнем компьютере (не на сервере) создайте пару ключей, если её ещё нет:

ssh-keygen -t ed25519

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

ssh-copy-id deploy@ВАШ_IP

Проверьте вход по ключу: отключитесь и подключитесь заново командой ssh deploy@ВАШ_IP. Если сервер пустил без запроса пароля пользователя — ключ работает. Этот шаг обязателен перед отключением паролей: сначала убеждаемся, что ключ пускает, и только потом закрываем парольный вход, иначе рискуем запереть себя снаружи. Держите открытой одну рабочую сессию до конца настройки как страховку.

Ужесточаем SSH и включаем фаервол

Откройте конфиг демона SSH командой sudo nano /etc/ssh/sshd_config и приведите три параметра к виду: PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes. Затем перезапустите службу:

sudo systemctl restart ssh

Не закрывая текущую сессию, в новом окне проверьте, что вход по ключу по-прежнему работает — это страховка от опечатки в конфиге. Теперь поставьте и настройте фаервол UFW, который в Debian ставится отдельно:

sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw enable

Первым делом мы разрешаем SSH и лишь затем включаем фаервол — порядок критичен, иначе можно отрезать себе доступ. По умолчанию UFW запрещает все входящие соединения и разрешает исходящие, так что после включения открытыми останутся только осознанно разрешённые порты. Для веб-сервера позже добавьте порты 80 и 443.

Автообновления и защита от перебора

Большинство взломов идёт через давно закрытые уязвимости на необновлённых серверах. Debian умеет ставить обновления безопасности сам:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Выберите в диалоге «Yes», и система начнёт автоматически подтягивать критические патчи. Дополнительно поставьте fail2ban, который банит адреса, перебирающие вход:

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

Из коробки fail2ban следит за SSH и блокирует назойливых ботов, проверить его работу можно командой sudo fail2ban-client status sshd. Пройдитесь по финальному чек-листу: система обновлена, установлен sudo, заведён пользователь, вход root и пароли отключены, работает вход по ключу, фаервол включён, автообновления и fail2ban активны. Этот набор превращает голый Debian в защищённый рабочий сервер, готовый принять веб-сервер, базы или приложения.

Стоит понимать, что безопасность сервера — это не разовая настройка, а состояние, которое нужно поддерживать. Мы заложили прочную основу, но она требует минимального внимания: раз в месяц полезно заглядывать в логи через sudo journalctl -p err, проверять список открытых портов командой sudo ss -tulpn и убеждаться, что автообновления действительно ставят патчи. Отдельно отметьте для себя запасной путь на случай потери доступа: в панели управления VPS есть веб-консоль, которая подключается к серверу напрямую, минуя SSH и сеть. Через неё вы войдёте по паролю пользователя и почините сломанный конфиг, поэтому пароль стоит хранить в менеджере даже после перехода на ключи. Зная про этот запасной вход, вы можете смело ужесточать настройки, не боясь запереть себя снаружи.

Частые вопросы