- отправлять кому угодно и что угодно

- смотреть логи, т.е. кто что и кому слал

- возможность тиражирования

И мои поиски увенчались успехом, я вычитал про мессенджер Rocket chat. Это как раз было то что надо.

Установка и начало работы с Rocket chat

Rocket chat ставится на Ubuntu (бесплатная операционная система!) сервер. Ну или на другие похожие, но мне как-то убунту ближе. Сразу скажу, что все поставить и запустить это очень прямо не просто. Может быть я конечно еще тот ламер, но у меня это почти месяц заняло. Расскажу подробнее.

1. Способ установки. Ставить Rocket chat можно разными способами. Или просто скачать пакет

или ставить его в контейнер docker. Я выбрал сначала первый способ. Причем на момент установки версия Rocket chat уже ушла вперед, а я-то этого не знал! В итоге поставил старую, которая работать у меня отказалась, пришлось все обнулять, думать, и переставлять уже на новую. Причем поначалу у меня ну никак не хотели работать уведомления. Т.е. сообщение приходило, но телефон молчал. Ни настройки андроида, ни настройки самого Rocket chat не помогали. Починить это удалось лишь после обновления Rocket chat на версию 8.8.0.

2. Дополнительное ПО. Rocket chat работает совместно с базой данных MongoDB. И не все версии Rocket chat подходят к разным версиям этой БД. А еще есть обратный прокси сервер Nginx. Он тоже нужен для Rocket chat. Причем тоже не все версии подходят. В общем, я плутал в трех соснах несколько дней, пока в итоге не нашел рабочую связку. У меня заработала отправка сообщений, фото, аудиофайлов.

3. Настройка аудио и видио звонков.

Для этого используется бесплатная программа jitsi. Это сервер видеоконференций. и Rocket chat может работать с ней совместно. Причем в Rocket chat есть такая штука "магазин приложений". Там тьма всяких допов и интеграций. Даже типа шлюза к Whatsapp и Telegramm. Так вот из этого магазина прямо в web интерфейсе Rocket chat и ставится (бесплатно) jitsi. Но тут есть один очень важный нюанс.Если эту самую джитси просто так поставить и даже все настроить, то видеозвонки как бы получаются, но работают они через официальный сервер jitsi а там есть авторизация, приходится при каждом звонке выбирать модератора, всем вводить пароли от google аккаунтов, это все долго, и в итоге это полная хрень. Но есть решение!!! Надо поставить свой jitsi сервер! А уж в моем сервере я все могу настроить как угодно. Или вообще отключить авторизацию (что опасно, т.к. сервер висит в инете, могут найтись желающие нахаляву через него пообщаться) или есть еще возможность настроить Rocket chat так чтобы он сам авторизовался уже на моем сервере jitsi, для чего и там и тут я задаю логины и пароли.

Вот тогда наступает кайф, ты звонишь пользователю Rocket chat, у него раздается звонок и и все,

начинаете разговор. Причем это все реально работает. Отдельная тема, это отправка сообщений в Rocket chat из 1С. Сделать это было точно можно, но информации в инете кот наплакал. Но в итоге, я все-таки написал в коде 1С несколько функций:

- отправка сообщения боту

- отправка сообщения пользователю в личку

- отправка web ссылки

- отправка фото

- отправка документа

Тут тоже возникала просто тьма сложностей. ИИ от гугла хотя мне сильно помог, но ответы на мои вопросы и примеры кода у него немного неправильные ВСЕГДА. Это наверное фишка такая. Всегда после ИИ приходилось все переделывать и дорабатывать. Хотя оснвные идеи он выдает годные. Вся работа идет через HTTP запросы. Для некоторых сложных случаев пришлось запускать сниффер трафика fiddler и ловить что моя 1с передает и что Rocket chat ей отвечает, чтобы понять где у меня затык. Но в итоге все более менее заработало. Также огромную сложность вызвало у меня установка Rocket chat и jitsi на один сервер. Т.к. и то и это хочет отдельный домен. В итоге заработало на разных портах. Rocket chat на 443 https порту, а jitsi на 8443. Так что оба работают уже в контейнерах docker и друг другу не мешают.

Вот что я в итоге поимел:

1. Свой личный мессенджер (по функционалу сравнимый с telegramm)

2. Его точно никто мне не отключит и не заблокирует

3. Клиенты работают где угодно (андроид, айфоны, windows)

4. Можно слать сообщения, файлы, делать видеозвонки

5. Отлично принимает сообщения (в т.ч. и конкретному пользователю) из 1С

Что именно нужно защитить

Безопасная настройка sshd_config начинается со списка тех, кому нужен SSH: владельца VPS, коллег, программы резервного копирования.

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

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

Какие настройки сервер действительно использует

В чек-лист аудита SSH внесите версии ОС и OpenSSH, исходные настройки. Их покажут команды на сервере:

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

Блоки Match задают исключения для пользователей и адресов. Параметр -C учитывает их для конкретного подключения:

Подставьте своего пользователя, IP и имя клиента. Если Match содержит условия на адрес и порт сервера, укажите их через laddr и lport. Вывод -T показывает то, что записано в файлах на диске. Уже открытые сеансы продолжают работать по прежним настройкам, поэтому проверять изменения нужно новым подключением. Слушающие порты покажет команда ss, а её вывод стоит сверить с правилами межсетевого экрана на VPS и в панели провайдера.

Кому принадлежат учётные записи и ключи

Составьте список всех учётных записей, которые могут войти и выполнять команды. Отдельно отметьте тех, кто может выполнять команды от имени администратора через sudo. В authorized_keys хранятся разрешённые открытые ключи. У каждого должен быть известен владелец, потому что подпись рядом с ключом ещё не подтверждает его личность. Отключение входа по паролю SSH лучше делать только после того, как этот список собран.

Личные аккаунты помогают различать администраторов в журнале. Программе резервного копирования выделите отдельный ключ. Параметр command= в authorized_keys ограничивает его заданной командой, а restrict отключает дополнительные возможности, включая туннели. После настройки по справке OpenSSH убедитесь, что копирование работает.

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

Как отключить вход по паролю и не потерять доступ?

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

Какие способы входа оставить

Следующий пример разрешает вход только по ключам. Вместо admin укажите имя пользователя, под которым вы уже проверили вход и sudo:

В AllowUsers включите всех нужных пользователей и служебные аккаунты. Если удобнее управлять группой, вместо списка имён можно использовать AllowGroups. MFA и allowlist для SSH работают вместе: список ограничивает круг пользователей, второй фактор защищает от украденного ключа.

Параметр PermitRootLogin со значением no запрещает прямой вход под root. Значение prohibit-password сохраняет вход root по ключу.

Для ключа и одноразового кода через PAM, систему аутентификации Linux, нужны другие значения. Прежние значения замените следующими, а UsePAM добавьте, если его ещё нет:

Такая многофакторная аутентификация (MFA) работает лишь с заранее настроенным PAM-модулем. Сам keyboard-interactive может запрашивать обычный пароль. Поэтому одного PasswordAuthentication no недостаточно для запрета всех способов парольного входа.Как применить изменения и вернуться назад

До правок проверьте вход по ключу в новом соединении. На своём компьютере выполните команду со своим логином и адресом VPS:

Команда создаёт новое соединение и допускает только вход по ключу. Для MFA через PAM укажите в PreferredAuthentications publickey,keyboard-interactive. В новом сеансе проверьте sudo. Старый оставьте открытым.

В этом примере меняется только новый файл /etc/ssh/sshd_config.d/00-local-access.conf. Это имя и имя с окончанием .disabled должны быть свободны. Сохраните вывод -T до правок. После них убедитесь, что нужные значения действуют для каждого условия Match.

Сначала выясните, как запущен SSH. Команда systemctl is-enabled ssh.socket покажет, включена ли активация через сокет. В Ubuntu она включена по умолчанию с версии 22.10. sshd не работает постоянно, а поднимается на каждое входящее соединение и читает конфигурацию заново, поэтому reload не нужен, достаточно открыть новый сеанс. Если сокет отключён и работает постоянная служба, изменения применяет reload:

Проверка -t при успехе ничего не печатает. При ошибке команда после && не выполнится. Запрет root login и остальные ограничения проверяют попытками входа: повторите вход по ключу, проверку sudo и попытки запрещённого входа.

Для отката в старом сеансе или консоли переименуйте файл, после этого он не попадает под маску *.conf.

Этот откат относится только к новому файлу. PAM, межсетевой экран и порт меняйте отдельно, с собственными командами возврата. Старый сеанс закройте лишь после всех проверок.

Что делать с туннелями и алгоритмами

Безопасность SSH на VPS зависит и от возможностей после входа. Например, SSH-туннель передаёт трафик другой программы через зашифрованное соединение.

AllowTcpForwarding управляет TCP-туннелями. X11Forwarding разрешает вывод окон серверных программ на компьютер пользователя. AllowAgentForwarding даёт доступ через сервер к агенту с ключами на компьютере пользователя. Ненужные возможности стоит отключить. При этом пользователь с командной оболочкой может обойти запрет туннелей собственной программой пересылки трафика.

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

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

Достаточно ли Fail2ban и нестандартного порта?

Нет, этих мер мало.

1.  На другом порту обычно меньше автоматических попыток входа, но сканирование всё равно его найдёт.

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

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

Как ограничить сеть и сохранить события входа

Межсетевой экран может принимать SSH только с адресов администраторов. Проверьте вход из разрешённой и посторонней сети, включая IPv6, если он используется.

Fail2ban временно блокирует адреса после серии неудачных входов. После установки убедитесь, что он читает журнал SSH и применяет блокировки. Тестовые попытки входа тоже могут привести к блокировке вашего IP.

Журнал должен содержать успешные входы, отказы и административные действия через sudo. Недавние записи в Ubuntu можно посмотреть так:

Злоумышленник с правами root может изменить локальный журнал. Копия на отдельном сервере поможет восстановить события. Убедитесь, что записи действительно туда попадают, время на обеих машинах синхронизировано по NTP, а журналы хранятся столько, сколько требует ваш аудит. Администраторам VPS не нужны права удаления этой копии.

Как подтвердить результат проверки

Отчёт содержит версии ОС и OpenSSH, список подключённых файлов, перечень пользователей и ключей, настройки до и после правок. К сравнению файлов до и после правок (diff) добавьте причины изменений. Приватные ключи и секреты второго фактора в отчёт входить не должны. Собранные файлы и результаты тестов и есть audit evidence, которое запросит аудитор.

В таблице ниже указаны ожидаемые результаты. Каждый сценарий нужно проверить на своём сервере:

• Администратор из AllowUsers с верным ключом: вход и работа sudo

• Тот же пользователь только с паролем: отказ во входе

• Root с верным ключом: отказ во входе

• Пользователь вне AllowUsers с верным ключом: отказ во входе

• Подключение из запрещённой сети при настроенном межсетевом экране: блокировка межсетевым экраном

• Возврат прежней конфигурации: новый вход по прежним правилам

Для проверки парольного входа выполните на своём компьютере:

Этот тест отключает ключи. Пользователя вне AllowUsers проверяйте с верным ключом, иначе причина отказа останется неясной. При MFA нужны попытки с верным, неверным и пропущенным кодом.

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

Хороший результат выглядит просто: разрешённый пользователь входит, запрещённые сценарии получают отказ, а откат проверен заранее и не зависит от того, работает ли SSH. Чек-лист харденинга SSH храните вместе с инструкцией восстановления доступа. У каждого исключения должны быть причина, владелец и дата пересмотра. Так следующий администратор сможет отличить рабочую необходимость от забытой временной настройки.

Настройка VPS начинается со сверки: тот ли сервер выдали и кто, кроме вас, может на него войти. После первого входа нужно сверить параметры заказа, подтвердить SSH-отпечаток, создать отдельного администратора, ограничить входящие соединения и сохранить базовые метрики. Установка VPS по этой схеме рассчитана на образ Ubuntu 24.04 LTS с одним администратором. Панель или cloud-init могут менять эти шаги, поэтому некоторые пункты стоит проверять.

Что сделать сразу после получения доступа к VPS?

Для начала сверьте IP, регион, образ и ресурсы с заказом, затем найдите аварийную консоль и проверьте SSH-отпечаток. После входа создайте отдельного пользователя с sudo, подтвердите доступ по ключу во втором сеансе и только потом включайте firewall и запрещайте парольный вход. Для панели или готового образа сначала посмотрите уже открытые порты.

Что приходит после заказа VPS и что проверить до входа

В личном кабинете или письме указаны IPv4, логин, начальный пароль либо открытый ключ, а также IPv6, если он выдан. Сверьте с заказом регион, образ ОС, vCPU, RAM и диск. После загрузки проверьте их командами nproc, free -h, lsblk и cat /etc/os-release. С ошибкой в регионе или тарифе обратитесь в поддержку до размещения своих данных на сервер.

До первого SSH-входа найдите VNC или другую аварийную консоль, а также порядок запуска rescue mode. Это может понадобится, если ошибка в sshd_config или firewall закроет сетевой доступ. Инструкция Aéza по аварийному режиму показывает, где включается среда восстановления. Конечно, сама она не заменит резервную копию.

Пароль из письма нельзя считать постоянным секретом, так как он прошёл через почту и мог попасть в журнал уведомлений. Если после установки VPS доступен парольный вход, используйте его только для перехода на собственный ключ. Когда образ уже принимает заданный при заказе ключ, не включайте пароль ради удобства. Для нестандартного ISO также проверьте контрольную сумму или подпись.

Как подключиться к VPS и проверить отпечаток ключа

В Linux, macOS и Windows Terminal SSH-клиент вызывается одинаково. В примере данные замените на те, что в карточке сервера:

При первом соединении OpenSSH показывает тип ключа хоста и SHA256-отпечаток.

The authenticity of host '203.0.113.42' can't be established.
ED25519 key fingerprint is SHA256:Wq6...K3A.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Не подтверждайте yes, пока не получите отпечаток другим путём. Откройте аварийную консоль и выполните ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub, затем сравните строку целиком.

После переустановки ключ хоста меняется. Если сервер не переустанавливали, предупреждение REMOTE HOST IDENTIFICATION HAS CHANGED требует остановки и проверки через консоль или поддержку. Команду ssh-keygen -R IP запускают только после подтверждения причины. На Windows запись хранится в %USERPROFILE%\.ssh\known_hosts, в Linux и macOS – в ~/.ssh/known_hosts.

Отдельный пользователь, sudo и вход по ключу

Сначала создайте учётную запись и каталог для ключа. Текущий сеанс пока не закрывайте:

На рабочем компьютере создайте ключ ssh-keygen -t ed25519 -a 100, если его ещё нет. В Linux перенесите открытую часть командой ssh-copy-id operator@IP. В macOS и Windows Terminal при отсутствии ssh-copy-id добавьте содержимое .pub в /home/operator/.ssh/authorized_keys через открытый сеанс, затем задайте владельца operator и права 600. Приватный ключ на сервер копировать не нужно. Войдите как operator во втором терминале и выполните sudo -v. После проверки можно продолжать настройку VPS сервера.

Как безопасно перейти с пароля на SSH-ключи?

Добавьте открытый ключ отдельному пользователю, войдите им во втором сеансе и проверьте sudo. Затем создайте конфигурационный фрагмент, который читается раньше остальных, выполните sshd -t и загрузите новую конфигурацию службы. Исходный сеанс держите открытым до повторного входа, а при ошибке исправьте настройки через аварийную консоль.

В Ubuntu файлы из sshd_config.d читаются раньше основного sshd_config, а для большинства директив действует первое найденное значение. Имя 00-local-hardening.conf помещает локальный фрагмент в начало порядка чтения.

После sshd -t выполните reload и, не закрывая текущую сессию, откройте вторую новым пользователем. Проверка вторым сеансом важнее самой команды: на Ubuntu 24.04 с сокет-активацией reload может вернуть ошибку, если ssh.service не запущен. Если вход не работает, исправьте фрагмент через VNC и повторите sshd -t.

Запретить входящие и открыть только нужные порты

UFW в стандартном Ubuntu изначально выключен, а в облачном образе пакет и вовсе может отсутствовать. Проверьте его, задайте политики и откройте SSH-порт. Если sshd слушает не 22-й порт, возьмите значение из sudo ss -utlnp.

Перед ufw enable оставьте SSH-сеанс открытым. Второй терминал понадобится, чтобы проверить, как подключиться к VPS при действующих правилах. ufw status показывает эти правила, а ss -utlnp – слушающие сокеты и связанные процессы. Сетевой экран не останавливает сами службы.

Порты 80 и 443 добавляют после запуска веб-сервера. Базу данных, Redis и административную панель не нужно открывать всему интернету только потому, что приложение к ним подключается. Смена SSH-порта уменьшает шум от сканеров в журнале, но не заменяет ключи и запрет входа по паролю. В руководстве Ubuntu по UFW описаны простые правила, однако сетевой экран в панели провайдера остаётся отдельным уровнем.

Docker направляет трафик к опубликованным портам в обход обычных правил UFW. Сервис за обратным прокси привязывайте к 127.0.0.1. Для iptables правила пишите в цепочку DOCKER-USER: она документирована и не перезаписывается при перезапуске Docker. При другом бэкенде фильтруйте трафик в панели провайдера.

Обновления, время, локаль и swap без лишнего тюнинга

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

В стандартной установке Ubuntu 24.04 пакет unattended-upgrades ежедневно применяет обновления безопасности. Сторонние репозитории без отдельного правила он не охватывает, а автоматическая перезагрузка по умолчанию выключена. Ответственного за окно обновлений и перезагрузку лучше всё равно назначить, а результат контролировать по /var/log/unattended-upgrades/.

Для серверных журналов удобно оставить UTC: sudo timedatectl set-timezone UTC. Локаль C.UTF-8 уменьшает расхождения в выводе скриптов, если приложение не требует другой: sudo localectl set-locale LANG=C.UTF-8. Менять локаль ради отдельной команды не нужно, достаточно запускать её с LC_ALL=C.

Swap даёт ядру запас при резком пике памяти. При нехватке RAM этот механизм может вызвать длительные задержки при обращении к диску. Сначала проверьте текущий swap и профиль приложения. Для базы данных или сервиса, чувствительного к задержке, размер и vm.swappiness выбирают после замеров. Если в vmstat постоянно растут столбцы si/so, пересмотрите лимиты или тариф до увеличения swap.

Как доказать, что VPS работает после настройки

Сразу после настройки сервер пустой, и это лучший момент снять базовую линию. Через месяц, когда появится жалоба на медленную работу, сравнивать будет не с чем. Зафиксируйте дату, исполнителя, ОС, ядро, vCPU, RAM, диск и версии утилит. Для CPU сохраните минутный лог mpstat, для диска используйте временный файл, а iperf3 запускайте до своего узла в целевом регионе.

Как проверить безопасность и базовую производительность VPS?

1. Сохраните эффективные параметры sshd -T, правила ufw status numbered и список слушающих сокетов ss -utlnp.

2. Сохраните минутный лог mpstat, запустите fio на две минуты и запишите p50/p95/p99, затем выполните прямой и обратный прогоны iperf3.

3. Приложите конфигурацию, версии и сырой вывод, затем повторите замеры в другое время. Один максимум не считается базовой линией.

date -Is; uname -r; lscpu | sed -n '1,16p'; free -h; lsblk
fio --version; iperf3 --version; mpstat -V
LC_ALL=C mpstat -P ALL 1 60 | tee mpstat.log
fio --name=baseline --filename=/var/tmp/fio.bin --size=1G --direct=1 \
--rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --iodepth=1 \
--runtime=120 --time_based --group_reporting --percentile_list=50:95:99 \
--output-format=json --output=fio.json
rm -f /var/tmp/fio.bin
: "${IPERF_HOST:?Укажите адрес сервера iperf3}"
iperf3 -c "$IPERF_HOST" -P 4 -t 30 -O 5 --json > iperf3-send.json
iperf3 -c "$IPERF_HOST" -P 4 -t 30 -O 5 -R --json > iperf3-recv.json

fio нагружает диск, поэтому запускайте его в согласованное окно: на основном сервере и на соседних VM нагрузка будет заметна. iodepth=1 показывает задержку одиночной очереди, а не максимальные IOPS при глубине 32. Файл должен помещаться на диске с запасом. В документации fio JSON содержит IOPS и completion latency percentiles, включая заданные p50, p95 и p99.

На собственном контрольном узле запустите iperf3 -s, задайте его адрес в IPERF_HOST и выполните прямой и обратный прогоны с одинаковыми параметрами. Публичный узел не служит эталоном. По официальной документации iperf3 для теста нужны клиент и сервер. Между прогонами не меняйте конечные узлы и их конфигурацию. Сохраните JSON и повторите замер трижды. Оценивайте %steal вместе с загрузкой vCPU: одиночный всплеск не доказывает проблему хоста.

Привязать домен и не ждать TTL вслепую

A-запись содержит IPv4 сервера, AAAA-запись содержит IPv6. Перед добавлением AAAA проверьте маршрут, сетевой экран и прослушивание сервиса по IPv6. Первоначальная настройка VPS также требует проверить, проксирует ли DNS-провайдер веб-трафик и какой IP увидит пользователь.

TTL определяет, как долго резолвер может хранить ответ в кеше. После изменения запросите авторитетный сервер зоны, а потом несколько рекурсивных резолверов. До истечения прежнего TTL часть из них может возвращать старый ответ.

Если ответы расходятся, сравните их TTL с ответом авторитетного сервера. Очистка локального кеша не изменит запись у внешнего резолвера. Для HTTPS дополнительно проверьте сертификат и имя виртуального хоста, поскольку правильный A/AAAA ещё не подтверждает готовность приложения.

Для исходящей почты нужен PTR, который настраивает владелец IP-диапазона. Имя из PTR должно прямым запросом возвращаться к тому же адресу. Требования Gmail для всех отправителей включают согласованные прямую и обратную DNS-записи, а также SPF или DKIM. При отправке более 5000 писем в сутки на адреса Gmail нужны оба механизма и DMARC. Если сервер не отправляет почту напрямую, веб-сайту PTR не нужен.

Что добавить после первого часа: бэкап, мониторинг и сервис

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

Бэкапы храните вне VPS и регулярно восстанавливайте тестовую копию. Не стоит путать со снапшотами: они фиксируют состояние на момент создания, но не заменяют независимую копию и журнал восстановления. Частоту выбирают по RPO, а время восстановления по RTO. Для базы данных нужна согласованная копия средствами СУБД или остановка записи на время снимка.

В мониторинг включите доступность сервиса, свободное место, память, срок TLS-сертификата, обновления и дату последнего успешного бэкапа. Пороги задавайте после сохранения базовой линии. Секреты храните отдельно от истории команд, compose-файла и репозитория. Для каждого секрета укажите ответственного и период ротации.

Docker, панели и бэкапы требуют отдельных инструкций: у них разные сетевые правила, каталоги данных и процедуры обновления. Одного администратора и UFW недостаточно для командной работы, персональных данных, публичной БД или требований регулятора. В этих случаях нужны журналирование действий, раздельные роли, MFA, проверенное восстановление и контролируемый процесс выпуска изменений.

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

Через сутки после первого запуска повторите контрольные проверки. Убедитесь, что обновления завершились, место на диске не заканчивается, сервис отвечает, а задание бэкапа выполнилось успешно. Считайте, что настройка VPS закончена, когда текущее состояние можно проверить, а порядок восстановления понятен тому, кто будет сопровождать сервер.

Вы арендовали VPS, получили IP и пароль от root. Между этим моментом и рабочим сервисом в продакшене лежит десяток шагов, которые важно пройти в правильном порядке. Пропустить один из них означает оставить сервер уязвимым или потратить часы на отладку в самый неподходящий момент. И здесь встаёт вопрос: как подготовить свой VPS к реальной работе?

Этот материал проведёт вас от первого SSH-подключения до полноценного окружения с безопасным доступом, настроенным firewall и рабочим стеком приложений. Руководство написано для Ubuntu 22.04 LTS: проверенного LTS-релиза, который часто используют для серверов и небольших проектов. В конце вас ждёт чек-лист, который удобно держать под рукой при каждой новой установке.

Что понадобится до начала установки VPS

Перед тем как приступить к установке VPS и первичной настройке, убедитесь, что у вас есть всё необходимое.

Во-первых, данные для подключения: IP-адрес сервера, имя пользователя (обычно root) и пароль или SSH-ключ. Всё это провайдер высылает на email сразу после создания машины. Если провайдер вместо пароля сразу добавил публичный ключ, убедитесь, что соответствующий приватный ключ есть у вас локально.

Во-вторых, терминал на локальной машине. На macOS и Linux SSH встроен по умолчанию. На Windows удобно использовать PowerShell со встроенным OpenSSH-клиентом.

Заранее найдите в панели провайдера KVM/VNC-консоль, она понадобится в случае потери SSH-доступа после изменений в конфигурации сети или firewall.

Первое подключение к серверу по SSH

Подключитесь к серверу из терминала. Замените YOUR_IP на IP-адрес сервера:

При первом подключении терминал покажет предупреждение с отпечатком (fingerprint) сервера (уникальным идентификатором хоста) и предложит добавить его в список доверенных. Перед подтверждением сверьте fingerprint с данными в панели провайдера или документации к инстансу. Если он совпадает, введите yes. SSH сохранит ключ хоста в ~/.ssh/known_hosts. Если отпечаток изменится при повторном подключении, это может указывать на атаку посредника или на переустановку сервера.

Если провайдер настроил аутентификацию по SSH-ключу, а не по паролю, укажите путь к приватному ключу:

Возможные ошибки при первом подключении:

• Connection refused: SSH-сервис не запущен или порт закрыт. Проверьте состояние сервера через панель провайдера, иногда образ ещё инициализируется.

• Permission denied (publickey): ключ не добавлен на сервер или указан неверный путь к файлу ключа.

• Connection timed out: IP указан неверно или сервер ещё загружается. Подождите минуту и повторите.

Для удобства при частых подключениях настройте алиас в файле ~/.ssh/config на локальной машине:

После этого достаточно набрать ssh myserver. При необходимости подключаться под другим пользователем добавьте второй блок Host с другим значением User.

Обновление системы и базовые пакеты

Сразу после входа обновите список пакетов и сами пакеты.

После обновления установите базовый набор инструментов:

Назначение каждого пакета:

•  curl и wget: загрузка файлов и скриптов из сети;

•  htop: интерактивный мониторинг процессов и потребления ресурсов;

• ufw: управление правилами firewall поверх iptables;

• fail2ban: автоматическая блокировка IP при многократных неудачных попытках входа.

Если после обновления терминал выводит System restart required, было обновлено ядро. Выполните reboot, дождитесь восстановления SSH-соединения (обычно 30–60 секунд) и продолжайте.

Создание пользователя и настройка безопасного доступа

Безопасная работа на своём VPS начинается с отказа от постоянной работы под root. Любая ошибка в команде или скомпрометированный пакет, запущенный с правами root, получает неограниченный доступ к системе. Создайте отдельного пользователя с правами sudo.

Если у вас ещё нет SSH-ключа, сгенерируйте его на локальной машине. Алгоритм ed25519 предпочтительнее RSA:

Публичный ключ находится в ~/.ssh/id_ed25519.pub. Его нужно добавить на сервере в файл ~/.ssh/authorized_keys того пользователя, под которым вы будете подключаться по SSH.

Создание пользователя и добавление в группу sudo:

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

Важно: откройте вторую сессию и убедитесь, что вход под admin работает, прежде чем вносить следующие изменения. Потеря доступа на этом этапе потребует входа через KVM/VNC-консоль провайдера.

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

Найдите и задайте параметры:

Перезагрузите конфигурацию через reload, а не restart: активные сессии при этом не прервутся.

Опционально: смена стандартного порта SSH с 22 на нестандартный снижает объём шума от автоматических сканеров в логах. Если решите изменить порт, сначала разрешите новый порт в UFW, затем внесите изменения в sshd_config и только после этого перезагрузите SSH.

Настройка брандмауэра и базовой защиты

Свежий сервер без firewall попадает под сканирование портов в первые минуты после выдачи публичного IP. UFW (Uncomplicated Firewall) снижает этот риск без необходимости работать с iptables напрямую. По умолчанию UFW блокирует весь входящий трафик и разрешает исходящий трафик.

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

Разрешите нужные порты:

Если используете нестандартный порт SSH, добавьте его вместо или дополнительно к 22 на период перехода. Включите firewall и проверьте статус:

Вывод Status: active и список разрешённых портов подтверждают корректную работу. Все остальные входящие соединения будут отклоняться.

Настройка fail2ban. На Ubuntu 22.04 SSH-события пишутся в systemd journal, поэтому создайте файл /etc/fail2ban/jail.local с указанием backend:

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

В выводе строки Currently banned и Currently failed покажут число заблокированных адресов и количество неудачных попыток за текущий период. Снять блокировку вручную можно командой fail2ban-client set sshd unbanip IP. Если fail2ban не видит попыток входа при реальных ошибках, проверьте значение backend = systemd в конфиге.

Установка рабочей среды: веб-сервер, БД, язык

Состав стека целиком зависит от задач проекта. Для большинства веб-приложений достаточно трёх компонентов: веб-сервер, база данных и runtime языка. Устанавливайте только то, что действительно нужно: каждый лишний запущенный сервис потребляет ресурсы сервера.

Nginx в роли веб-сервера и reverse proxy – стандартный выбор для большинства проектов:

Node.js. Версия в стандартном репозитории Ubuntu 22.04 может быть старее актуальной LTS-версии. Для установки свежей LTS-версии можно использовать NodeSource, предварительно сверив номер версии на nodejs.org:

Python 3 уже предустановлен в Ubuntu 22.04. Для работы с виртуальными окружениями добавьте:

Docker как универсальный вариант

Если проект допускает контейнеризацию, Docker избавляет от ручного управления зависимостями: приложение с окружением упаковывается в образ и запускается одинаково на любом хосте. Для продакшен-среды предпочтительнее установка через официальный apt-репозиторий Docker: так проще контролировать источник пакетов и обновления. Официальный скрипт тоже добавляет репозиторий Docker Engine и ставит актуальную версию, но его лучше использовать для быстрого старта или тестового окружения:

Добавьте пользователя в группу docker, чтобы команды выполнялись без sudo:

Изменения применятся при следующем входе в сессию. Docker Compose v2 устанавливается как плагин и вызывается без дефиса:

Пример минимального docker-compose.yml для сервиса с автоперезапуском:

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

Домен, SSL и автозапуск сервисов

Привязка домена. В DNS-настройках у регистратора добавьте A-запись, указав IP сервера:

Обновление DNS-записей занимает от нескольких минут до 24 часов. Проверить это можно командой dig yourdomain.com или через онлайн-сервисы вроде dnschecker.org. Не запускайте certbot до того, как запись распространится: это приведёт к ошибке валидации.

HTTPS через Let's Encrypt. Установите Certbot с плагином для Nginx:

Получите сертификат:

Certbot изменит конфигурацию Nginx, добавит HTTPS-блок с путями к сертификату и предложит настроить редирект с HTTP на HTTPS. Обновление сертификата происходит через cron или systemd timer без вашего участия. Сертификат Let's Encrypt действует 90 дней. Проверьте, что продление пройдёт без ошибок:

Автозапуск сервисов. Пакеты, установленные через apt, как правило, включаются в автозапуск автоматически. Для собственного приложения создайте unit-файл:

Чек-лист: что проверить перед запуском в прод

Каждая установка VPS проходит по схожему маршруту. Сохраните этот список и проходитесь по пунктам при каждой новой настройке.

1. Система обновлена: apt update && apt upgrade выполнены

2. Создан непривилегированный пользователь с правами sudo

3. Root-вход отключён: PermitRootLogin no в /etc/ssh/sshd_config

4. Аутентификация только по SSH-ключу: PasswordAuthentication no

5. UFW активен: ufw status показывает Status: active с нужными правилами

6. fail2ban работает: fail2ban-client status sshd показывает активный jail

7. HTTPS настроен: certbot renew --dry-run выполняется без ошибок

8. Сервисы добавлены в автозапуск: проверьте systemctl is-enabled nginx и другие

9. Настроены бэкапы или снапшоты через панель провайдера

10. Запланированы регулярные обновления безопасности: настройте unattended-upgrades для security-обновлений или другой контролируемый процесс обновления.

От первого ssh root до продакшен-среды вполне можно дойти за один рабочий день. Настройка VPS-сервера с нуля требует внимания прежде всего на этапе безопасности: шаги, пропущенные здесь, могут позже дать о себе знать. Не жалейте времени на проверку каждого пункта чек-листа до открытия сервиса пользователям.

VPS с открытым SSH-портом быстро замечается ботами. На сервере счётчик неудачных входов набирает сотни попыток в сутки, а на давно засвеченных адресах – тысячи. Боты работают автоматически и не делают перерывов. Настройка VPS без базовой защиты от перебора – прямое приглашение для таких сканеров.

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

Fail2Ban не заменяет SSH-ключи, отключение входа по паролю и аккуратный firewall, но хорошо снимает самый частый шум от bruteforce: видит повторяющиеся ошибки входа и отправляет подозрительные IP в бан. Ниже – рабочая настройка для Ubuntu 22.04/24.04, Debian 11/12, AlmaLinux 9 и CentOS Stream 9: установка, jail.local, защита SSH и проверка результата.

Что такое Fail2Ban и как он работает?

Fail2Ban работает довольно просто. Этот инструмент на Python читает лог-файлы или systemd journal и ищет строки, похожие на неудачную аутентификацию. Совпало регулярное выражение – счётчик для IP увеличился. Набралось maxretry ошибок за findtime – адрес уходит в firewall на время bantime. Когда срок заканчивается, блокировка снимается автоматически.

Отдельный сервис поднимать не нужно, Fail2Ban использует системный firewall: iptables, nftables или firewalld. Вся защита от bruteforce держится на понятной связке: лог, фильтр, порог срабатывания и действие блокировки.

В конфигурации чаще всего встречаются два термина:

Jail – правило для конкретного сервиса: какие события читать, какие строки считать нарушением и что делать после превышения лимита.

Filter – набор failregex, то есть регулярных выражений для поиска нужных строк в логе. Для SSH, nginx, postfix и других популярных сервисов такие фильтры уже лежат в пакете.

Подготовка VPS перед установкой

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

Обновите систему:

Проверьте, что на сервере есть пользователь с sudo. Работать от root не рекомендуется: ошибка в конфиге или случайная команда могут повлиять на весь сервер.

Чек-лист перед установкой

•  SSH-доступ работает; запасная сессия открыта или есть KVM/VNC-консоль в панели провайдера

•  Внешний IP известен: curl -4 https://api.ipify.org

•  На сервере есть пользователь с sudo

•  Если используется UFW на Ubuntu/Debian, проверен его статус: sudo ufw status

• На AlmaLinux 9 / CentOS Stream 9 проверен firewalld: sudo systemctl status firewalld

Установка Fail2Ban на Ubuntu/Debian и AlmaLinux/CentOS

На Ubuntu и Debian пакет есть в стандартном репозитории:

/var/log/auth.log может отсутствовать при использовании systemd-journald вместо rsyslog. Если auth.log отсутствует или jail [sshd] не считает попытки входа, задайте backend = systemd. При использовании backend = systemd может потребоваться пакет python3-systemd. На минимальных образах он не всегда установлен:

Проблема с backend может выглядеть так: сервис запущен, jail [sshd] активен, но Currently failed остаётся 0 даже после заведомо ошибочных SSH-входов. В таком случае явно укажите backend = systemd и перезапустите инструмент.

В AlmaLinux 9 и CentOS Stream 9 Fail2Ban обычно ставят через EPEL. Для связки с firewalld понадобится дополнительный пакет fail2ban-firewalld:

На современных системах Fail2Ban также может работать через nftables без fail2ban-firewalld, в зависимости от выбранного banaction.

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

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

В статусе нужен Active: active (running). Если сервис упал, первым делом посмотрите последние сообщения unit:

Базовая конфигурация: jail.local без магии

/etc/fail2ban/jail.conf приходит вместе с пакетом и может измениться после обновления. Свои правила лучше держать в /etc/fail2ban/jail.local: он читается поверх jail.conf и обычно не перезаписывается при обновлениях.

Создаём файл:

Секция [DEFAULT] задаёт глобальные параметры для всех jail:

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

bantime определяет срок бана. Десять минут часто слишком мало: бот успевает вернуться с тем же или соседним адресом. Для рабочей SSH-защиты обычно начинают с 1h, а затем повышают до 24h, если ложных срабатываний нет.

findtime и maxretry всегда смотрят вместе. При findtime = 10m и maxretry = 5 адрес блокируется после пяти ошибок за десять минут. Для SSH это нормальный старт: пользователь с опечаткой не страдает, а простой перебор быстро отсекается.

backend = auto автоматически выбирает способ чтения логов в зависимости от окружения. В большинстве случаев этого достаточно, но если SSH-события не обнаруживаются, необходимо указать backend = systemd в нужном jail.

Защита SSH: минимально рабочая конфигурация

Добавьте в jail.local секцию [sshd] для защиты входа по SSH. Обычная настройка fail2ban ssh выглядит так:

Если SSH-события в Ubuntu 24.04 читаются через journal, добавьте в [sshd]:

Для AlmaLinux 9 и CentOS Stream 9 задайте действие блокировки через firewalld в [DEFAULT] или [sshd]:

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

Дополнительные jail: nginx, postfix, панели управления

Фильтры для nginx, postfix, dovecot и других сервисов лежат в /etc/fail2ban/filter.d/. Например, для basic auth в nginx можно завести отдельный jail:

Для ISPmanager, cPanel, Plesk и других панелей универсального фильтра обычно нет. Правила лучше брать из документации панели или репозитория Fail2Ban, а затем прогонять у себя.

Проверка работы и мониторинг

Общий статус всех активных jail:

Статус jail [sshd] показывает, сколько раз правило сработало и какие IP сейчас в бане:

Если sshd не появился в списке jail, чаще всего проблема в jail.local. Проверить конфиг можно без перезапуска:

Разбанить конкретный IP:

Основной лог – /var/log/fail2ban.log. По строкам Ban и Unban видно, кого заблокировали и когда блокировка закончилась:

Если при реальных атаках строк Ban нет, а Currently failed держится на 0, Fail2Ban смотрит не туда. На системах, где SSH пишет в /var/log/auth.log, фильтр можно проверить так:

Типичные ошибки и как их избежать

Самоблокировка при настройке. Две-три ошибки в пароле – и ваш IP уже в бане. Перед тестами держите открытой запасную сессию. Если доступ пропал, зайдите через KVM/VNC в панели провайдера и снимите блокировку:

Неверный backend при использовании systemd journal. Если auth.log отсутствует, а backend оставлен auto, jail может не видеть SSH-события. Итог: Currently failed остаётся 0 при реальных неудачных входах. Обычно помогает backend = systemd в [sshd]; на минимальных образах проверьте python3-systemd.

Конфликт с firewalld на AlmaLinux и CentOS. Без fail2ban-firewalld и banaction блокировки через firewalld баны могут появляться в fail2ban.log, но не попадать в реальные правила firewall. Проверьте rich rules:

Конфликт с UFW на Ubuntu. Если Fail2Ban использует способ блокировки, который не совпадает с активным firewall, правила могут применяться некорректно. Проверьте выбранный banaction и используйте вариант, соответствующий вашему окружению: UFW, iptables, nftables или firewalld.

Слишком низкий maxretry. Значение 1–2 ловит не только ботов, но и людей с одной опечаткой при вводе пароля. Для SSH начинайте с 3–5 попыток; для веб-сервисов с живыми пользователями ставьте порог выше.

Ложные срабатывания. Если под бан попал легитимный пользователь или сервис, чаще всего виноваты слишком строгий maxretry или неподходящий failregex. На системах с /var/log/auth.log проверьте совпадения фильтра:

Если auth.log нет, смотрите SSH-события через journalctl и используйте backend = systemd. Адреса с постоянным административным доступом добавляйте в ignoreip.

Нет ignoreip для офисных адресов. При смене сети или работе из нескольких локаций риск заблокировать себя выше. Если у офиса статический IP, внесите в ignoreip всю офисную подсеть.

Итоговый чек-лист внедрения

1. Сервис стартует вместе с системой, а systemctl status fail2ban показывает active (running)

2. Пользовательские правила лежат в /etc/fail2ban/jail.local, минимум с секциями [DEFAULT] и [sshd]

3. В ignoreip внесены личный IP и административные подсети

4. bantime задан минимум на 1 час

5. Для систем с SSH-логами в systemd journal в [sshd] указан backend = systemd, а python3-systemd установлен или уже пришёл зависимостью

6. Для AlmaLinux 9 / CentOS Stream 9 установлен fail2ban-firewalld, а banaction работает через firewallcmd-rich-rules

7. fail2ban-client status sshd показывает активный jail и реальные счётчики при неудачных входах

Базовая настройка Fail2Ban обычно занимает 15–20 минут. После этого достаточно изредка проверять логи и whitelist, особенно при смене firewall, офиса или сети. Правильная настройка VPS сервера начинается с таких базовых вещей – ещё до деплоя приложения. Боты не ждут, пока вы закончите.

Облачный инстанс создан, 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 обновления.

ports:

- "127.0.0.1:5432:5432"

Docker будет слушать только на loopback, и порт останется доступным только с хоста.

Почему сканеры не помогут

Паттерн "5432:5432" без явного 127.0.0.1: - это слепое пятно для Trivy, Checkov, Semgrep и Snyk. Ни один из них не флагует такой биндинг как эксплойт, потому что это мисконфиг а не уязвимость. Рассчитывать на CI-сканеры в этом случае нельзя - проверять нужно глазами или кастомным правилом.