Облачный инстанс создан, SSH-доступ работает, и первое, что хочется сделать, это запустить приложение. Но новый сервер в этот момент уязвим: root-доступ может быть разрешён, часть пакетов требовать обновления, firewall ещё не настроен, мониторинга нет. Автоматические сканеры находят новые IP-адреса за минуты и начинают перебор паролей ещё до того, как вы откроете второй терминал.

Настройка облачных серверов перед нагрузкой – это четыре конкретных блока: сеть, пользователи и доступ, firewall, мониторинг. Каждый занимает от десяти минут до получаса. Пропустить любой – значит получить дыру в безопасности и эксплуатации.

Разберём все четыре блока по порядку на примере Ubuntu 22.04 LTS. Все команды воспроизводимы и проверены. Порядок шагов важен: каждый следующий опирается на предыдущий. Не запускайте приложение до настройки firewall: незащищённый VPS с открытым SSH быстро попадает под автоматический перебор паролей.

С чего начинается настройка облачного сервера?

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

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

Следующий шаг – проверить синхронизацию времени. Расхождение системных часов ломает TLS-рукопожатие, сбивает JWT-токены и делает логи бесполезными при сравнении событий с разных хостов. На Ubuntu 22.04 за это отвечает systemd-timesyncd. Проверьте его статус:

В строке NTP service должно стоять active. Если нет – включите вручную:

Также сразу посмотрите, что уже запущено на сервере, и сколько свободно дискового пространства. На минимальном образе Ubuntu 22.04 запущено около 25–30 системных сервисов. Если их заметно больше, образ уже преднастроен провайдером:

Если корневой раздел занят более чем на 80%, разберитесь с этим до любых дальнейших шагов: нехватка места ломает обновления пакетов, ротацию логов и запись временных файлов.

Настройка сети на облачном сервере

Начните с просмотра текущего состояния сетевых интерфейсов. Две команды дают полную картину: какие интерфейсы подняты, какие IP назначены и куда идёт маршрут по умолчанию.

В выводе ip a найдите интерфейс с публичным IP-адресом – обычно это ens3, ens4 или eth0, в зависимости от провайдера. Запомните его имя: оно понадобится в конфигурации netplan.

На Ubuntu 22.04 сетевые настройки управляются через netplan: конфигурационные файлы лежат в /etc/netplan/. Если провайдер использует cloud-init для автоматической конфигурации сети, в /etc/netplan/ уже может быть файл 50-cloud-init.yaml. Его можно редактировать, но изменения могут быть перезаписаны cloud-init при следующей перезагрузке или пересоздании конфигурации. Безопаснее создать отдельный файл с более высоким приоритетом, например 99-custom.yaml: числа в именах файлов определяют порядок применения, большее число применяется последним и переопределяет предыдущее.

Пример конфигурации со статическим IP (замените значения на реальные):

Директива addresses задаёт статический IP с маской. routes описывает маршрут по умолчанию – шлюз, через который идёт весь трафик. nameservers – DNS-серверы; при необходимости укажите серверы провайдера или вашего корпоративного резолвера.

Перед применением проверьте конфигурацию через netplan try: он применит настройки и автоматически откатит их через 120 секунд, если вы не подтвердите. Это страховка от потери соединения. Если всё в порядке – зафиксируйте:

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

Диагностика сетевых проблем

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

Если ping проходит, а dig не разрешает имена – проблема в DNS. На Ubuntu 22.04 DNS управляется через systemd-resolved. Его состояние:

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

В выводе resolvectl смотрите секцию DNS Servers для каждого интерфейса. Если серверы не отображаются или стоит 127.0.0.53, убедитесь, что в файле netplan прописан раздел nameservers, и заново примените конфигурацию.

Команда ss -tulpn полезна не только при диагностике сети: её стоит запускать после каждого шага настройки, чтобы убедиться – ничего лишнего не появилось на открытых портах.

Управление пользователями и доступом (users)

Постоянно работать от root – плохая практика. Опечатка в пути к файлу под root может уничтожить данные без возможности отмены. Любая уязвимость в запущенном от root приложении даёт атакующему полный контроль над системой. При командной работе аудит затруднён: в логах нет разграничения между разными администраторами.

Создайте пользователя для повседневной работы. В Ubuntu удобнее использовать adduser: команда создаёт домашнюю директорию, настраивает оболочку и интерактивно запрашивает пароль.

Команда usermod -aG sudo <name> добавляет пользователя в группу sudo. На Ubuntu эта группа по умолчанию имеет право выполнять любые команды через sudo без изменения файла /etc/sudoers. Проверьте, что всё работает не закрывая текущую сессию root:

Для входа по SSH без пароля сгенерируйте ключ на локальной машине и скопируйте публичную часть на сервер. Тип ed25519 предпочтительнее rsa:

Если нужно добавить публичный ключ вручную – создайте структуру директорий самостоятельно. Разрешения важны: 700 на директорию, 600 на файл:

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

Безопасные настройки SSH

Настройка SSH на сервере сводится к нескольким директивам в /etc/ssh/sshd_config. Ключевой принцип: ограничить поверхность атаки. Откройте файл:

Перед отключением парольного входа не закрывайте текущую root-сессию и убедитесь, что вход по SSH-ключу работает в новом терминале. Если в конфиге или ключах есть ошибка, SSH-доступ можно потерять, и восстанавливать его придётся через консоль провайдера, VNC/KVM или rescue mode.

Внесите следующие изменения:

PermitRootLogin no закрывает наиболее атакуемый вектор: большинство автоматических сканеров перебирают именно root. PasswordAuthentication no убирает парольный вход полностью после этого единственным способом войти остаются SSH-ключи. AllowUsers deploy добавляет дополнительный слой: даже если на сервере появятся другие пользователи, по SSH они войти не смогут.

Директива AllowUsers особенно полезна при командной работе: она задаёт явный белый список тех, кто может войти по SSH. Новый пользователь, не включённый в список, не получит доступ даже с корректным ключом.

Перед перезапуском проверьте синтаксис конфига, ошибка в директиве заблокирует вас при работающем соединении:

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

Дополнительно: смена стандартного порта 22 на нестандартный снижает количество автоматических сканирований и шум в логах. Если решите сменить, сначала откройте новый порт в UFW, затем измените Port в конфиге и перезапустите sshd, не наоборот.

Настройка firewall: UFW и iptables

UFW – стандартный инструмент управления firewall на Ubuntu. Он даёт простой интерфейс для настройки правил, а конкретный backend зависит от версии Ubuntu и конфигурации системы: это может быть iptables-совместимый слой или nftables. На новом сервере UFW установлен, но часто не активирован.

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

Если SSH настроен на нестандартный порт, замените 22 на него. Правило ufw status verbose покажет активные разрешения и политику по умолчанию – полезно сверить сразу после включения.

Для отладки сначала используйте вывод UFW:

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

или:

На Ubuntu 22.04 UFW может работать через iptables-совместимый backend или nftables. Поэтому не стоит ориентироваться только на одну цепочку INPUT: фактическое расположение правил зависит от backend и конфигурации системы.

Для автоматической блокировки IP-адресов после нескольких неудачных попыток входа установите fail2ban:

Создайте файл пользовательских настроек /etc/fail2ban/jail.local. Редактировать jail.conf напрямую не стоит – он перезаписывается при обновлении пакета:

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

В выводе Currently banned покажет количество активных блокировок. Разбанить конкретный IP можно командой fail2ban-client set sshd unbanip <IP>. Кроме SSH, fail2ban поддерживает джейлы для nginx, apache2 и postfix. Они конфигурируются аналогично, добавлением отдельных секций в jail.local.

Мониторинг облачного сервера

Мониторинг сервера Linux без агентов начинается со встроенных инструментов. Для быстрой диагностики их вполне хватает:

Для постоянного мониторинга с метриками и алертами нужен агент. Выбор зависит от контекста: если в инфраструктуре уже есть Prometheus, оптимален node_exporter – он экспортирует более 800 метрик ОС с минимальным потреблением ресурсов (около 20–50 MB RAM):

Агент слушает на порту 9100 и отдаёт метрики в формате Prometheus по адресу http://<IP>:9100/metrics. Добавьте этот адрес как scrape target в конфигурацию Prometheus, и метрики появятся в Grafana. Не открывайте порт 9100 наружу: ограничьте доступ через security group, UFW или приватную сеть Prometheus.

Если Prometheus ещё нет – Netdata даёт готовый интерактивный дашборд из коробки, без дополнительной инфраструктуры:

Netdata слушает на порту 19999. Настройте SSH-туннель для разового просмотра или nginx с basic auth для постоянного доступа. Netdata потребляет от 100 MB RAM, на VPS с 1 GB это существенная разница по сравнению с node_exporter.

Алерты настраиваются поверх метрик. Для node_exporter используйте Prometheus Alertmanager: правила на PromQL, уведомления в Slack, email или PagerDuty. Для Netdata встроена собственная система уведомлений – настройте её в /etc/netdata/health_alarm_notify.conf. На практике для старта хватает трёх порогов: CPU load выше числа vCPU, диск выше 85%, список упавших сервисов непуст.

Что мониторить в первую очередь

На только что настроенном сервере важны шесть базовых показателей:

CPU load average – если значение устойчиво превышает количество vCPU в течение 5–10 минут, сервер перегружен. htop или uptime показывают три скользящих средних: за 1, 5 и 15 минут.

Память – при использовании свыше 85% система начинает активно использовать swap, что резко увеличивает latency. Для веб-серверов и баз данных это ощутимо. Контролируется через free -h.

Диск – заполненность свыше 80% блокирует запись логов, временных файлов и данных приложений. Дополнительно следите за iostat (из пакета sysstat) – высокий await при умеренной нагрузке указывает на проблемы с хранилищем.

Failed services – systemctl --failed выводит список упавших юнитов. Перед выводом в продакшен этот список должен быть пустым.

Auth log – journalctl -u ssh --since "1 hour ago" покажет активность после настройки fail2ban. Строки Failed password могут продолжать появляться до бана или с других IP-адресов. Важнее проверить, что fail2ban видит попытки входа и добавляет нарушителей в jail; строки Accepted publickey должны соответствовать вашим успешным входам.

Открытые порты – ss -tulpn один раз после каждого изменения конфигурации. Всё, что слушает наружу, должно быть в явном белом списке UFW.

Чек-лист финальной проверки

Пройдитесь по списку перед открытием сервера под рабочий трафик:

•  Непривилегированный пользователь создан, добавлен в sudo

• Перед отключением парольного входа проверен вход по SSH-ключу в новом терминале

• PasswordAuthentication no и PermitRootLogin no прописаны в sshd_config

• UFW включён: ufw status verbose показывает только нужные порты

• fail2ban запущен: fail2ban-client status sshd показывает активный jail

• Пакеты обновлены: apt upgrade -y выполнен, при обновлении ядра – перезагрузка

• NTP активен: timedatectl показывает NTP service: active

• Мониторинг-агент запущен и метрики доступны

• Бэкапы настроены через панель провайдера или отдельный инструмент

• systemctl --failed возвращает пустой список

• Имя хоста и /etc/hosts настроены корректно

Четыре блока: сеть, пользователи, firewall, мониторинг – это минимальная конфигурация, без которой облачный сервер не готов к продакшену. Пропуск любого из этих шагов рано или поздно даёт о себе знать: либо взломом, либо аварией без видимой причины, либо часами поиска проблемы в логах.

Сохраните этот гайд и пройдитесь по нему при следующем деплое нового инстанса. В блоге Aeza регулярно выходят материалы по администрированию и безопасности серверов – подпишитесь, чтобы не пропускать NETTOWN5 обновления.

Прошу прощения и поехали.

В правой панели WinCSP открываем папку /root. На пустом месте правой панели жмём правую кнопку мыши, выбираем New -> File. В появившемся окошке вместо “New file” пишем “ipt-set” (без кавычек) и жмём ОК. Будет создан файл с именем ipt-set и откроется окно для его редактирования. Вписываем следующее содержимое:

#!/bin/sh

IF_EXT="venet0"

IF_OVPN="tun0"

OVPN_PORT="443"

SQUID_PORT="8080"

IPT="/sbin/iptables"

IPT6="/sbin/ip6tables"

# flush

$IPT --flush

$IPT -t nat --flush

$IPT -t mangle --flush

$IPT -X

$IPT6 --flush

# loopback

$IPT -A INPUT -i lo -j ACCEPT

$IPT -A OUTPUT -o lo -j ACCEPT

# default

$IPT -P INPUT DROP

$IPT -P OUTPUT DROP

$IPT -P FORWARD DROP

$IPT6 -P INPUT DROP

$IPT6 -P OUTPUT DROP

$IPT6 -P FORWARD DROP

# allow forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

# NAT

# #########################################

# SNAT - local users to out internet

$IPT -t nat -A POSTROUTING -o $IF_EXT -j MASQUERADE

# INPUT chain

# #########################################

$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# ssh

$IPT -A INPUT -i $IF_EXT -p tcp --dport 22 -j ACCEPT

# VPN

$IPT -A INPUT -i $IF_OVPN -p icmp -s 10.8.0.0/24 -j ACCEPT

# DNS

$IPT -A INPUT -i $IF_OVPN -p udp --dport 53 -s 10.8.0.0/24 -j ACCEPT

# openvpn

$IPT -A INPUT -i $IF_EXT -p udp --dport $OVPN_PORT -j ACCEPT

# squid

$IPT -A INPUT -i $IF_OVPN -p tcp --dport $SQUID_PORT -j ACCEPT

$IPT -A INPUT -i $IF_OVPN -p udp --dport $SQUID_PORT -j ACCEPT

# FORWARD chain

# #########################################

$IPT -A FORWARD -i $IF_OVPN -o $IF_EXT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPT -A FORWARD -i $IF_EXT -o $IF_OVPN -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A FORWARD -s 10.8.0.0/24 -d 10.8.0.0/24 -j ACCEPT

# OUTPUT chain

# #########################################

$IPT -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Нужно обратить внимание на следующие моменты:

- сетевой интерфейс называется venet0. Это особенность сборки операционной системы конкретного хостера. Возможно у вас он называется eth0. Узнать, как же правильно в вашем случае можно введя в консоли команду

ip a

В получившемся выводе команды будет список сетевых интерфейсов. Один из них носит название lo , это локальная петля. А вот второй, тот, что вам нужен.

- OVPN_PORT="443" это порт используется для нашего VPN сервера. Почему именно 443? Мы же настроим VPN и для домашнего компьютера/ноутбука, и для смартфона и, возможно, для рабочего компьютера/ноутбука. Вполне возможно, что ваше устройства окажется в сети (например, корпоративный Wi-Fi), где все порты кроме самых базовых запрещены. 443 точно будет разрешен, а VPN серверу без разницы на каком порту «висеть». Да и активность на этом порту не будет подозрительной.

- SQUID_PORT="8080"

$IPT -A INPUT -i $IF_OVPN -p tcp --dport $SQUID_PORT -j ACCEPT

$IPT -A INPUT -i $IF_OVPN -p udp --dport $SQUID_PORT -j ACCEPT

подключения к прокси-серверу мы будем принимать на порт 8080 и только от тех, кто уже подключился к VPN, мамкины кулхацкеры идут лесом.

- $IPT -A FORWARD -s 10.8.0.0/24 -d 10.8.0.0/24 -j ACCEPT

клиенты VPN будут видеть друг друга. Т.е. ваш смартфон будет видеть ваш компьютер если оба они подключились к VPN. Это удобно для расшаривания контента.

Сохраняем получившийся файл. Кликаем на нём правой кнопкой мыши, выбираем Properties и отмечаем галочками все квадратики с буквой X (третий столбик квадратиков). Обратите внимание, в поле Octal получится число 0755. Можно задать свойства файла введя сразу нужное чиасло в это поле, а не выбирая свойства галочками. В дальнейшем мы так и бедуем делать. Я просто буду писать число, которое вам нужно будет вписать в это поле.

Жмём ОК. В консоли PuTTY выполняем команду:

/root/ipt-set

а затем команду:

iptables -L -n

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

Добавим правила в автозапуск. В правой панели WinCSP переходим к папке /etc/systemd/system/ и создаем файл с именем ipt-settings.service со следующим содержимым:

[Unit]

Description=Iptables Settings Service

After=network.target

[Service]

Type=oneshot

User=root

ExecStart=/root/ipt-set

[Install]

WantedBy=multi-user.target

В свойствах файла (см. выше) указываем права 0644.

Теперь в консоли вводим команду

systemctl enable ipt-settings

В ответ получим:

Created symlink from /etc/systemd/system/multi-user.target.wants/ipt-settings.service to /etc/systemd/system/ipt-settings.service.

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

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

iptables -L -n

Должны получить то, что было на последнем скриншоте (см. выше).