Firewall на выделенном сервере: как закрыть лишнее и сохранить доступ

MAATRIX · Выделенные серверы · Статья 44 из 48

Самый аккуратный firewall начинается с листа бумаги. На нём написано, какие службы должны быть доступны пользователям, какие — только приложению, а какие — одному администратору. Уже потом появляются правила и команды. Обратный порядок обычно заканчивается длинным набором разрешений, назначение которых никто не помнит.

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

Сначала карта дверей, потом замки

Возьмём условный сервер магазина. На нём работают обратный прокси, приложение, база, кэш и административная панель. Пользователю нужны HTTPS-запросы к сайту. Приложению нужна связь с базой и кэшем. Администратору — защищённый путь управления. Открывать все пять служб всему интернету для такого обмена не требуется.

Что считать публичным сервисом

Публичность должна быть осознанным свойством. Если сайт обслуживает браузеры через 443/TCP, это понятное назначение. Если включён HTTP/3, может потребоваться отдельная работа с UDP на соответствующем порту. Если порт базы открыт «на время настройки», у этого времени должна быть дата окончания и ответственный.

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

Проверьте, где приложение слушает соединения. Привязка к 127.0.0.1 и ко всем адресам — разные решения. IPv6 также может иметь собственный путь доступа. Не полагайтесь на название параметра в панели: посмотрите фактические сокеты и подтвердите поведение извне.

Для первоначального осмотра на Linux полезны команды чтения:

ss -lntup
ip -br address
sudo nft list ruleset

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

Что уже фильтрует провайдер

Уточните, существует ли внешняя фильтрация, как она настраивается и какие адреса или интерфейсы охватывает. Защита от DDoS, список разрешённых портов в панели и локальный firewall выполняют разные функции. Даже если сеть провайдера отсекает часть нежелательного трафика, она не обязана знать, что ваш PostgreSQL предназначен только для приложения.

Для тарифов CARTOUCHE, ANKH или NECROPOLIS сами характеристики CPU и дисков ничего не говорят о готовой политике доступа. Обозначение UNLIMITED относится к условиям трафика, а не к правилам входа. Перечень предоставляемых сетевых функций нужно подтверждать отдельно.

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

Типичная исходная идея для входящего трафика проста: разрешить необходимое, остальное не принимать. Но в «необходимое» входят не только порты приложения. Нужны служебный обмен, loopback, ответы в установленных соединениях и протоколы, обеспечивающие нормальную работу сети.

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

Сначала запасной путь

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

Разрешите рабочий административный доступ до включения запретов. Если вход разрешён только с определённого адреса, проверьте внешний адрес именно текущего соединения. Офисный NAT, VPN или сменившаяся мобильная сеть могут сделать старое разрешение бесполезным.

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

Для изменения применяйте поддерживаемый вашим инструментом способ проверки и отката. У nftables есть проверка файла без применения через nft -c -f, но корректный синтаксис не доказывает, что правила сохранят нужную связность. Проверку логики и аварийный план она не заменяет.

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

Не закрывайте служебную сеть вслепую

ICMP используется не только для привычного ping. В IPv6 служебные сообщения участвуют в обнаружении соседей и других необходимых механизмах. Запретить всё ради невидимости — способ получить странные сетевые сбои. Правила должны учитывать нужные типы сообщений, а не руководствоваться принципом «всё непонятное опасно».

Если вы ограничиваете исходящий трафик, отдельно учтите DNS, синхронизацию времени, обновления, внешние API и резервное копирование. Такая политика может быть полезна, но требует более полной карты зависимостей. Иначе приложение начнёт ошибаться в местах, которые никак не похожи на firewall: например, перестанет проверять сертификаты или отправлять уведомления.

Административный порт тоже не становится защищённым только из-за необычного номера. Сильная аутентификация, ограничение доступа, обновления и понятный порядок выдачи прав важнее самого выбора 22 или другого TCP-порта.

Контейнеры и виртуальные машины меняют маршрут пакета

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

Docker, например, создаёт собственные правила для bridge-сетей и публикации портов. Его документация отдельно описывает взаимодействие с firewall и UFW. При определённых путях обработки опубликованный контейнерный порт может оказаться доступным вопреки ожиданиям администратора, смотрящего только на UFW.

Практический вывод — проверять фактический результат и учитывать используемый backend. Инструкции для iptables нельзя автоматически переносить на nftables, особенно если в них упомянуты конкретные цепочки. Сначала выясните версию и способ работы вашей платформы.

Не отключайте управление правилами со стороны Docker без понимания последствий. Можно нарушить сеть контейнеров, исходящий доступ или изоляцию. Часто правильнее вообще не публиковать внутреннюю базу наружу: оставить обмен внутри соответствующей сети, а вход пользователей организовать через контролируемый прокси.

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

С гипервизорами картина похожа по принципу, но отличается деталями реализации. Есть правила хоста, гостя, виртуального коммутатора и, возможно, внешней сети. После переезда нескольких VPS на один CARTOUCHE или NECROPOLIS привычные границы могут измениться. Отдельные VM не должны случайно получить доступ к сетям управления друг друга.

Подробный разбор распространённой ситуации есть в статье о неожиданно открытом порте Docker. Главный урок шире самого Docker: проверяйте путь пакета целиком. Таблица правил — описание намерения, а внешний тест показывает результат.

Проверка извне и жизнь правил после настройки

После изменения подключитесь с разрешённого адреса и с отдельной внешней точки, которая не должна иметь административный доступ. Проверьте публичный сайт и внутренние сервисы, отдельно IPv4 и IPv6, если они используются. Ограниченный контроль портов своей машины допустим и полезен; случайные чужие сети для этого не нужны.

Нужно подтвердить как минимум два результата: разрешённое работает, запрещённое недоступно. Один отказ подключения ещё не объясняет причину — сервис может просто не слушать порт. Поэтому сопоставляйте внешний тест со списком сокетов и правилами, а при необходимости с журналами.

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

Журналирование полезно, пока не создаёт новую проблему. Записывать каждый отброшенный пакет без ограничения при большом потоке — способ заполнить диск и отвлечь ресурсы. Выбирайте события, которые помогут расследованию, ограничивайте частоту и настройте хранение журналов.

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

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

Если после изменения доступ пропал, не начинайте одновременно чистить все правила и перезагружать всё подряд. Через подготовленную консоль верните известную конфигурацию или исправьте конкретное правило. Порядок действий отдельно описан в статье о потере доступа после настройки firewall.

Локальный firewall не остановит поток, который уже переполнил внешнее соединение до сервера. Он также не исправит ошибку авторизации внутри приложения. Его задача — сделать сетевые границы явными и исполняемыми. Когда вы можете объяснить каждое открытое направление и проверить его снаружи, защита перестаёт быть набором магических команд. Она становится частью устройства вашего сервиса.

Все материалы о выделенных серверах