Первичная защита сервера

Первичная защита чистого Linux-сервера до установки iEXExchanger

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

Проверка исходного состояния

Подключитесь по SSH, сверив отпечаток сервера с первым доверенным подключением. Проверьте имя узла, ОС, диски, память, время и слушающие порты:

hostnamectl
timedatectl
lsblk
free -h
ss -lntup

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

Обновления и время

Установите штатные обновления безопасности для выбранной ОС и повторно загрузите сервер только тогда, когда пакет или ядро действительно требуют этого. До перезагрузки убедитесь, что доступ через консоль провайдера работает.

Временная зона журнала должна быть известна, а системное время синхронизировано. Неверное время нарушает TLS, подписи callback, сроки заявок и сопоставление журналов.

Учётные записи и SSH

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

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

Сетевой экран

На этапе установки достаточно:

Порт	Доступ
SSH	Только доверенные административные адреса
HTTP и HTTPS	После настройки сайта; затем через Cloudflare и подтверждённые интеграции

Не публикуйте PostgreSQL, Redis, внутренний порт SSR и внутренний канал реального времени. Если сервер уже работает с FASTPANEL, её административный порт разрешайте только доверенным адресам или VPN. Сначала измените правило в новой сессии, затем проверьте существующую и новую SSH-сессию. Не закрывайте текущий терминал до подтверждения входа.

Системные и прикладные пользователи

Не запускайте приложение, планировщик, очереди и Node.js-процесс от root. Чистый установщик создаёт отдельного прикладного пользователя и настраивает службы с ограниченными правами. Не заменяйте его на root и не меняйте владельцев каталогов без проверки действующей схемы.

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

Секреты и журналирование

Файл окружения, приватные ключи, токены, пароли базы и резервного хранилища доступны только владельцу серверной части и необходимому процессу. Не включайте секреты в историю shell, cloud-init, снимок экрана или обращение в поддержку.

Включите журнал входов, событий панели и операций провайдера. Определите срок хранения и внешний канал оповещения, который продолжит работать при недоступности сервера.

Проверка

1. Войдите отдельным ключом в новой сессии.
2. Убедитесь, что неизвестные публичные порты отсутствуют.
3. Проверьте синхронизацию времени и свободное место.
4. Проверьте сетевые правила у провайдера и в ОС.
5. Создайте снимок исходной защищённой системы.
6. Зафиксируйте способ аварийного входа и возврата сетевых правил.