MAATRIX / Блог / Ubuntu 24.04: первичная настройка и безопасность с нуля

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

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

MAATRIX

Вы только что получили чистый VPS, зашли под root по паролю — и на этом обычно останавливаются, а зря. Сервер, оставленный в заводском состоянии, за первые же сутки ловит тысячи попыток перебора пароля. Эта пошаговая первичная настройка и безопасность Ubuntu 24.04 с нуля проведёт вас от первого входа до защищённого рабочего сервера: заведём пользователя, настроим вход по ключу, поднимем фаервол и автообновления. Ничего лишнего — только то, что реально нужно на старте.

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →

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

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

ssh root@ВАШ_IP

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

apt update && apt upgrade -y

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

hostnamectl set-hostname my-server

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

timedatectl set-timezone Europe/Moscow

Создаём отдельного пользователя с sudo

Работать под root постоянно опасно: любая ошибка или взломанный процесс получает полный контроль над машиной. Заведите обычного пользователя и дайте ему права администратора через sudo. Замените deploy на любое удобное имя:

adduser deploy
usermod -aG sudo deploy

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

su - deploy
sudo whoami

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

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

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.

Арендовать VPS на Ubuntu 24.04

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

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

ssh-keygen -t ed25519 -C "deploy@my-server"

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

ssh-copy-id deploy@ВАШ_IP

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

Ужесточаем настройки SSH

Откройте конфигурацию демона SSH:

sudo nano /etc/ssh/sshd_config

Найдите и приведите к такому виду три ключевых параметра: запретите вход root напрямую, отключите вход по паролю и явно разрешите ключи:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Сохраните файл и перезапустите службу, чтобы изменения вступили в силу:

sudo systemctl restart ssh

Важно: не закрывайте текущую сессию, пока в новом окне терминала не убедитесь, что вход под пользователем по ключу по-прежнему работает. Это страховка от опечатки в конфиге. При желании смените стандартный порт 22 на нестандартный (например, 2222) параметром Port — это резко сокращает шум в логах от ботов, хотя и не заменяет остальную защиту.

Поднимаем фаервол UFW

В Ubuntu 24.04 из коробки есть удобная обёртка над iptables — UFW. По умолчанию логика простая: запретить всё входящее, разрешить всё исходящее, а затем точечно открыть нужные порты. Сначала разрешите SSH, иначе после включения фаервола вы отрежете себе доступ:

sudo ufw allow OpenSSH

Если вы меняли порт SSH, откройте его явно, например sudo ufw allow 2222/tcp. Если планируете веб-сервер, добавьте порты 80 и 443:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Теперь включите фаервол и проверьте статус:

sudo ufw enable
sudo ufw status verbose

Список должен показывать только те порты, что вы открыли осознанно. Всё остальное закрыто, и это правильное состояние для сервера.

Принцип «по умолчанию запрещено всё» стоит объяснить отдельно, потому что он противоречит интуиции новичка. Кажется логичным открыть побольше портов «на всякий случай», чтобы потом ничего не донастраивать. На деле каждый открытый порт — это дверь, за которой сидит какая-то служба, и если завтра в ней найдут уязвимость, атакующий войдёт именно через неё. Поэтому правильная логика обратная: закрыто всё, а открывается ровно то, что вы прямо сейчас используете и понимаете зачем. Понадобился новый сервис — открыли его порт одной строкой. Перестал быть нужен — закрыли командой sudo ufw delete allow. Такой подход резко сокращает поверхность атаки и делает поведение сервера предсказуемым: вы всегда знаете, какие двери в него ведут.

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

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

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

В диалоге выберите «Yes». После этого система будет автоматически подтягивать патчи безопасности. Проверить, что механизм работает, можно командой sudo unattended-upgrade --dry-run. Это одна из самых окупаемых мер: она закрывает целый класс проблем без вашего участия.

Финальная проверка и защита от перебора

Осталось поставить fail2ban — он блокирует IP, которые перебирают пароли или ключи, на время бана:

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

По умолчанию fail2ban уже следит за SSH. Проверьте, что защита активна:

sudo fail2ban-client status sshd

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

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.

Арендовать VPS на Ubuntu 24.04

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →

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

Обязательно ли отключать вход по паролю?

Да, это резко снижает риск: ключ подобрать перебором практически невозможно, а пароль — вполне. Только сначала убедитесь, что вход по ключу точно работает.

Что делать, если я потерял доступ после смены настроек SSH?

Зайдите через веб-консоль (VNC) в панели управления сервером — она не зависит от SSH — и откатите изменения в /etc/ssh/sshd_config.

Нужен ли fail2ban, если уже отключён вход по паролю?

Он всё равно полезен: снижает нагрузку от ботов и логовый шум, а также защищает другие сервисы, которые вы позже откроете наружу.

Как оплатить сервер на Ubuntu 24.04 из России?

У MAATRIX доступна оплата картой российского банка, по СБП, криптовалютой и токеном MAAT — иностранная карта не требуется.

Нужны сами нейросети для контента?

Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.