Skip to main content

Первоначальная настройка сервера Ubuntu 24.04


Пошаговая настройка свежеустановленного сервера: обновление, рабочий пользователь, файрвол, защита SSH, Caddy как реверс-прокси.

Техника безопасности. Шаги 5 и 8 могут отрезать вас от сервера при ошибке в конфиге. Всё время работы держите вторую открытую SSH-сессию и не закрывайте её, пока не убедитесь, что новая сессия открывается в третьем окне. Если доступа к консоли (IPMI, KVM, веб-консоль провайдера) нет — обеспечьте его до начала работы.

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

Каждый блок кода ниже рассчитан на копирование целиком: это либо одна команда, либо цепочка через &&, которая отработает и одной строкой.

1. Обновление системы

sudo apt update && sudo apt upgrade -y

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

[ -f /var/run/reboot-required ] && sudo reboot

Опционально — автоматические обновления безопасности. Установка:

sudo apt install -y unattended-upgrades

Интерактивная настройка (задаст один вопрос, ответить «Да»):

sudo dpkg-reconfigure -plow unattended-upgrades

2. Пользователь mrleo1nid с sudo без пароля

Создаём пользователя. Команда интерактивная: спросит пароль и несколько необязательных полей, которые можно пропустить через Enter.

sudo adduser mrleo1nid

Добавляем в группу sudo:

sudo usermod -aG sudo mrleo1nid

Sudo без пароля

Правило пишем отдельным файлом в /etc/sudoers.d/, а не правкой /etc/sudoers — так изменение легко откатить и оно переживёт обновление пакета:

echo 'mrleo1nid ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/mrleo1nid && sudo chmod 440 /etc/sudoers.d/mrleo1nid

Проверка синтаксиса — обязательна. Ошибка в sudoers ломает sudo целиком, и без root-доступа это уже не чинится:

sudo visudo -c -f /etc/sudoers.d/mrleo1nid

Ожидаемый вывод: parsed OK.

SSH-ключ

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

ssh-keygen -t ed25519

Копируем на сервер, тоже с локальной машины:

ssh-copy-id mrleo1nid@СЕРВЕР

Проверяем в отдельном окне, что вход работает:

ssh mrleo1nid@СЕРВЕР

И что sudo не спрашивает пароль (должно вывести root):

sudo whoami

Не переходите к шагу 8, пока это не заработало.

3. Переключение на iptables legacy

Ubuntu 24.04 по умолчанию использует backend nftables. Скрипт бана из шага 7 работает через классический iptables + ipset, поэтому переключаем систему в legacy-режим — тогда UFW, Docker и скрипт будут писать правила в одну таблицу, а не в две параллельные.

sudo apt install -y iptables ipset

sudo update-alternatives --set iptables /usr/sbin/iptables-legacy && sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy && sudo update-alternatives --set arptables /usr/sbin/arptables-legacy && sudo update-alternatives --set ebtables /usr/sbin/ebtables-legacy

Проверка — в выводе должно быть (legacy):

sudo iptables --version

Чтобы старые nft-правила не висели параллельно, перезагружаемся:

sudo reboot

Если на сервере установлен Docker, после переключения его нужно перезапустить — backend определяется при старте демона. Перезагрузка делает это сама.

4. Fail2ban

Банит IP после нескольких неудачных попыток входа.

sudo apt install -y fail2ban

Свои настройки пишем в jail.local — jail.conf перезаписывается при обновлении пакета:

sudo nano /etc/fail2ban/jail.local

Содержимое:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
# свои адреса, чтобы не забанить себя
ignoreip = 127.0.0.1/8 ::1 192.168.0.0/16 10.0.0.0/8

[sshd]
enabled = true
backend = systemd

backend = systemd заставляет читать журнал systemd вместо файла /var/log/auth.log — надёжнее, так как наличие этого файла зависит от того, установлен ли rsyslog.

Запускаем:

sudo systemctl enable --now fail2ban && sudo systemctl restart fail2ban

Проверяем, что jail поднялся:

sudo fail2ban-client status sshd

Разбанить адрес, если забанили себя:

sudo fail2ban-client set sshd unbanip 1.2.3.4

5. Файрвол

sudo apt install -y ufw

Сначала разрешаем SSH, потом включаем. Обратный порядок отрежет вас от сервера. Правила задаются одной цепочкой:

sudo ufw default deny incoming && sudo ufw default allow outgoing && sudo ufw allow OpenSSH && sudo ufw allow 80/tcp && sudo ufw allow 443/tcp

Только теперь включаем (команда спросит подтверждение — ответить y):

sudo ufw enable

Проверка:

sudo ufw status verbose

Порты 80 и 443 нужны Caddy: 80 — для ACME-проверки Let's Encrypt, без него сертификат не выпустится.

Docker и UFW. Если на сервере есть контейнеры с проброшенными портами (ports: в compose), Docker пишет правила напрямую в iptables в обход UFW. Запрет в ufw такие порты не закроет. Ограничивать их нужно правилами в цепочке DOCKER-USER либо биндить публикацию на конкретный интерфейс: '127.0.0.1:8080:80' вместо '8080:80'.

6. Caddy

Реверс-прокси с автоматическим получением и продлением сертификатов Let's Encrypt.

Зависимости:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl

Ключ репозитория:

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

Сам репозиторий:

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

Установка:

sudo apt update && sudo apt install -y caddy

Перед настройкой убеждаемся, что A-запись домена указывает на этот сервер:

dig +short example.com

Конфиг:

sudo nano /etc/caddy/Caddyfile

example.com {
    reverse_proxy 127.0.0.1:8080
}

Проверяем синтаксис и применяем:

sudo caddy validate --config /etc/caddy/Caddyfile && sudo systemctl reload caddy

Смотрим логи — должна появиться запись об успешно полученном сертификате:

sudo journalctl -u caddy -f

Если Caddy стоит вторым в цепочке прокси

Когда перед ним есть ещё один Caddy или nginx, во внутреннем блоке достаточно передать протокол:

example.com {
    reverse_proxy http://10.10.1.129:8080 {
        header_up X-Forwarded-Proto https
    }
}

Дублировать header_up для Host, X-Real-IP и X-Forwarded-For не нужно: Caddy проставляет их сам, причём X-Forwarded-For дописывает к цепочке, а ручное header_up его затирает — приложение начнёт видеть IP прокси вместо реального клиента.

7. Блокировка IP по внешнему списку (ban.sh)

Скрипт из somebody-knocked-my-ssh скачивает список IP/CIDR, заливает его в ipset и вешает одно правило DROP в INPUT — вместо сотен отдельных правил на каждый адрес.

Скачиваем и делаем исполняемым:

sudo wget "https://raw.githubusercontent.com/jahlib/somebody-knocked-my-ssh/refs/heads/main/ban.sh" -O /usr/local/sbin/ban.sh && sudo chmod +x /usr/local/sbin/ban.sh

Перед первым запуском задаём переменную URL вверху скрипта — адрес текстового файла со списком (одна запись на строку, комментарии через #). Остальные параметры (SET_NAME, REMOVE_ORPHANS, LOCK_FILE) можно оставить по умолчанию:

sudo nano /usr/local/sbin/ban.sh

Первый запуск:

sudo bash /usr/local/sbin/ban.sh

Скрипт сам поставит ipset, если его нет, создаст набор, добавит правило и выведет строку-итог вида added / skipped / invalid / removed / total.

Автообновление по cron

sudo crontab -e

Добавить в конец:

@reboot      sleep 60 && bash /usr/local/sbin/ban.sh
0 */6 * * *  bash /usr/local/sbin/ban.sh

Строка @reboot важна: ipset живёт в памяти, и после перезагрузки набор пуст, а правило iptables без него ничего не блокирует. Задержка даёт подняться сети.

Проверка

Сколько адресов в наборе:

sudo ipset list blacklist | grep "Number of entries"

Стоит ли правило в цепочке:

sudo iptables -L INPUT -n --line-numbers | grep blacklist

Замечания

  • Только IPv4. Для IPv6 скрипт ничего не делает.
  • Правило добавляется в конец INPUT, а UFW ставит свои переходы в начало цепочки. Проверьте по --line-numbers, что порядок вас устраивает: если UFW разрешает порт раньше, чем сработает DROP, блокировка для этого порта не применится.
  • В режиме зеркала (REMOVE_ORPHANS=1) пустой или битый удалённый список на очередной синхронизации разбанит всех. Следите за значением removed= в логе.
  • Список по URL стоит держать неугадываемым: скрипт не умеет авторизацию, и любой, кто найдёт адрес, увидит его содержимое.

Как удалить

sudo iptables -D INPUT -m set --match-set blacklist src -j DROP -m comment --comment "ipset-blacklist-drop" && sudo ipset destroy blacklist

8. Закрытие root-доступа

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

Отключаем вход root по SSH

В Ubuntu 24.04 в /etc/ssh/sshd_config есть директива Include /etc/ssh/sshd_config.d/*.conf, поэтому правки удобнее держать отдельным файлом:

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

Содержимое:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Проверяем синтаксис и применяем одной командой — при ошибке в конфиге sshd -t выведет её и не даст перезапустить сломанный сервис:

sudo sshd -t && sudo systemctl restart ssh

В новом окне проверяем, что вход по-прежнему работает:

ssh mrleo1nid@СЕРВЕР

И что root теперь получает отказ:

ssh root@СЕРВЕР

Про смену порта SSH. В 24.04 sshd запускается через сокет-активацию (ssh.socket), и директива Port в sshd_config игнорируется. Порт меняется через sudo systemctl edit ssh.socket с переопределением ListenStream=.

Убираем пароль root

sudo passwd -l root

-l блокирует пароль: локальный вход под root по паролю становится невозможен, sudo при этом работает как обычно.

Команда passwd -d root удаляет пароль, а не блокирует. При некоторых конфигурациях PAM пустой пароль означает вход вообще без пароля — на консоли или при физическом доступе это дыра. Используйте -l, если нет конкретной причины поступить иначе.

Проверка — во втором поле должно быть L:

sudo passwd -S root

Итоговая проверка

Backend iptables (ожидается legacy):

sudo iptables --version

Файрвол активен, открыты 22/80/443:

sudo ufw status verbose

Fail2ban работает:

sudo fail2ban-client status sshd

Чёрный список загружен:

sudo ipset list blacklist | grep "Number of entries"

Caddy запущен:

sudo systemctl status caddy

Root заблокирован:

sudo passwd -S root

Фактически применённая конфигурация SSH — полезно, когда настройки разбросаны по нескольким файлам и непонятно, какая победила:

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'

Что стоит сделать дополнительно

  • Настроить бэкапы (restic, borg) с выгрузкой на другой хост.
  • Поставить мониторинг доступности, чтобы узнавать о падении не от пользователей.
  • Через неделю работы просмотреть sudo journalctl -p err -b — там обычно всплывает то, что настроено криво, но пока не мешает.

No comments to display

Back to top