Защита Linux-сервера: Часть 1 — Межсетевой экран UFW

Межсетевой экран — первое, что настраивают на новом сервере, ещё до Fail2ban, CrowdSec и аудита. Его задача простая: пропустить только тот трафик, который нужен работающим службам, и отбросить всё остальное. Чем меньше открытых портов, тем меньше точек, через которые сервер можно атаковать.

В Debian и Ubuntu для этого обычно используют UFW (Uncomplicated Firewall). Это не отдельный межсетевой экран, а утилита, которая превращает короткие команды в правила ядра Linux. UFW вызывает iptables, а в современных Debian и Ubuntu iptables работает поверх nftables, поэтому правила в итоге попадают в nftables.

Политика по умолчанию

Правильная отправная точка — запретить все входящие подключения и разрешить исходящие:

sudo ufw default deny incoming
sudo ufw default allow outgoing

После этого открывают только нужные порты. Всё, что не разрешено явно, будет отброшено.

Сначала SSH, потом включение

Самая частая ошибка — включить UFW на удалённом сервере, не разрешив SSH. Соединение оборвётся, и зайти на сервер можно будет только через консоль провайдера. Документация UFW прямо рекомендует добавить правило для SSH до включения: правила можно добавлять, пока межсетевой экран выключен.

sudo ufw allow 22/tcp          # или ваш нестандартный порт SSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Если SSH слушает другой порт, откройте именно его. Если к серверу подключаются только из офиса, лучше ограничить доступ адресом:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Ограничение частоты подключений

Команда limit разрешает подключения, но отклоняет адрес, который пытается открыть 6 и более соединений за 30 секунд. Для SSH это простая защита от быстрого перебора паролей:

sudo ufw limit 22/tcp

limit не заменяет Fail2ban: он не читает журналы и не знает, успешным был вход или нет. Это грубый, но полезный первый фильтр.

Порядок правил

UFW проверяет правила сверху вниз, и срабатывает первое подходящее. Если сначала стоит allow 22, а ниже — deny from 198.51.100.0/24, запрет для этой сети на SSH не сработает. Посмотреть порядок и вставить правило в нужное место:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 3

IPv6

По умолчанию UFW создаёт правила и для IPv4, и для IPv6 — за это отвечает параметр IPV6=yes в /etc/default/ufw. Если у сервера есть IPv6-адрес, а поддержку отключили, службы на IPv6 могут оказаться открыты без всякой фильтрации. Проверьте, что в выводе ufw status есть строки с пометкой (v6).

Профили приложений

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

sudo ufw app list
sudo ufw allow "OpenSSH"
sudo ufw allow "Nginx Full"

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

Docker обходит UFW

Главная ловушка на серверах с контейнерами. Документация Docker прямо говорит: при публикации порта контейнера трафик к нему перенаправляется раньше, чем его увидят правила UFW, и Docker с UFW несовместимы в этом смысле. Строка -p 5432:5432 в docker run или ports: - "5432:5432" в Compose делает базу данных доступной из интернета, даже если в UFW порт закрыт.

Что с этим делать:

• публиковать служебные порты только на локальном адресе: -p 127.0.0.1:5432:5432, а наружу отдавать сервис через обратный прокси;
• для связи контейнеров между собой использовать общую сеть Docker, а порт не публиковать вовсе;
• если порт всё же нужно открыть наружу с ограничениями, добавлять правила в цепочку DOCKER-USER, которую Docker проверяет раньше своих правил;
• после развёртывания проверять открытые порты снаружи, например с другого сервера командой nmap.

Журнал

Чтобы видеть отброшенные подключения, включите журналирование:

sudo ufw logging on

Записи попадают в системный журнал с пометкой [UFW BLOCK]. На открытом в интернет сервере их будет много — это фон постоянного сканирования, а не атака на вас лично.

Когда UFW недостаточно

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

Типичные ошибки

• UFW включён без правила для SSH — доступ к серверу потерян.
• Правило запрета стоит ниже разрешающего и не срабатывает.
• IPv6 отключён в UFW, а службы слушают IPv6-адрес.
• Порты контейнеров опубликованы на всех интерфейсах и открыты в интернет в обход UFW.
• Открыт порт «на время отладки» и забыт.

Межсетевой экран — только первый слой. Что ещё сделать с новым сервером, собрано в чек-листе «Купил VPS — что дальше?» и в статье «Новый сервер — это не чистый лист».