Как настроить лёгкий файрвол (UFW) на облачном сервере

Свежий Linux VPS с публичным IP попадает в поле зрения сканеров почти сразу после установки. Мы наблюдали Ubuntu 22.04 сразу после загрузки: меньше чем за четыре часа в /var/log/auth.log накопилось более тысячи попыток SSH brute force со всего мира. Security group облачного провайдера отсекает часть трафика, но файрвол на уровне ОС — вторая линия обороны, которой вы действительно управляете.

На серверах Ubuntu / Debian UFW (Uncomplicated Firewall) — почти стандарт по умолчанию: простой синтаксис, бесшовная работа с iptables, хорошая документация. В этой статье не разбираем десятки цепочек iptables, а собираем в чеклист проверенный в продакшене workflow UFW — от установки и открытия SSH до веб-портов, сосуществования с Docker, согласования с облачными security group и главного: как настроить файрвол, не заперев себя снаружи.

Предпосылка: вы вошли по SSH или через облачную консоль (VNC) и имеете sudo. Если SSH уже не подключается, сначала прочитайте наш гайд по устранению отказа SSH на Linux-сервере, разберитесь — сеть или файрвол — и возвращайтесь сюда.

Зачем на облачном сервере нужен файрвол?

Многие думают: «У меня есть security group, в системе ничего делать не надо». На деле уровни разные: облачная security group фильтрует снаружи виртуальной сетевой карты, управляется из веб-консоли; UFW фильтрует на уровне netfilter ядра, управляется из командной строки. Одного слоя мало — как запереть входную дверь, оставив спальню открытой: lateral movement, случайно открытые сервисы, reverse shell после взлома требуют правил на уровне ОС.

UFW, как описано в официальной документации Ubuntu UFW, — фронтенд к iptables: ufw allow 22 превращается в соответствующие правила ACCEPT. Синтаксис близок к естественному языку, ufw status numbered показывает политику с первого взгляда, правила менять проще.

Шаг 1: установка и проверка UFW

Ubuntu Desktop и большинство серверных образов уже содержат UFW; минимальные образы — не всегда. Сначала проверьте:

sudo apt update
                sudo apt install ufw -y

                # Текущий статус (inactive = ещё не включён)
                sudo ufw status verbose

                # Автозапуск (правила настроить до enable)
                sudo systemctl enable ufw

Если вывод показывает Status: inactive, правила можно безопасно добавлять по одному — они пока не действуют. Это лучшее окно для настройки. Никогда не выполняйте ufw enable, пока не открыт SSH — иначе сразу потеряете удалённый доступ.

Шаг 2: разрешить SSH (самое важное правило)

SSH — канал администрирования, его открывают первым. Если sshd слушает нестандартный порт (например 2222), порт в правиле должен совпадать с sshd_config, и security group тоже нужно обновить.

# Стандартный порт 22
                sudo ufw allow 22/tcp comment 'SSH'

                # Пользовательский порт
                sudo ufw allow 2222/tcp comment 'SSH custom'

                # Только IP выхода офиса (рекомендуется в проде)
                sudo ufw allow from 203.0.113.50 to any port 22 proto tcp

                # По имени сервиса (если есть в /etc/services)
                sudo ufw allow OpenSSH

Проверьте, что sshd действительно слушает: sudo ss -tlnp | grep ssh. 0.0.0.0:22 или [::]:22 — сервис в порядке. Если ListenAddress равен 127.0.0.1, UFW не поможет — это настройка sshd, не файрвола.

Как согласовать порт SSH и security group, см. наш FAQ по минимальной поверхности атаки и файрволу на Linux cloud-хосте — там матрица SSH/HTTPS для долгосрочного планирования.

Шаг 3: политика по умолчанию

Рекомендуемая базовая линия UFW: запретить весь входящий трафик, разрешить весь исходящий. Исходящий открыт — сервер тянет пакеты apt, ходит в API, резолвит DNS; входящий сжат до явно нужных портов.

sudo ufw default deny incoming
                sudo ufw default allow outgoing

                # Правила с номерами (для удаления)
                sudo ufw status numbered

При требованиях compliance можно ужесточить исходящий: ufw default deny outgoing, затем точечно allow out для DNS (53), HTTPS (443) и т.д. Для большинства web/API-серверов «исходящий открыт, входящий по необходимости» — лучший баланс усилий и безопасности.

Шаг 4: открыть порты сервисов

Добавляйте правила под реальные сервисы. Типичные комбинации:

# HTTP / HTTPS (Nginx, Caddy, Apache)
                sudo ufw allow 80/tcp
                sudo ufw allow 443/tcp

                # Или краткая форма по имени сервиса
                sudo ufw allow 'Nginx Full'

                # Dev: временно Node или другой порт
                sudo ufw allow 3000/tcp comment 'dev API'

                # Панель админки только с указанного IP
                sudo ufw allow from 198.51.100.0/24 to any port 8080 proto tcp

В продакшене: что можно отдать на reverse proxy по 443, не выставляйте напрямую на 3000/8080. В UFW откройте только 22 + 80 + 443, приложение на 127.0.0.1, TLS-терминация через Nginx или Caddy — поверхность атаки сразу уменьшается.

Шаг 5: включить и проверить

После добавления правил включите UFW:

sudo ufw enable
                # Предупреждает о возможном обрыве SSH — подтвердить y

                sudo ufw status verbose
                sudo ufw status numbered

С другой машины проверьте: nc -zv your.server.ip 22 должен вернуть open; неразрешённый порт (например 3306) — timeout или refused. SSH оборвался? Сразу через облачную консоль/VNC: sudo ufw disable, найдите недостающее правило, начните снова.

Продвинутое: лимиты, удаление, порядок правил

UFW умеет больше, чем allow — частые сценарии:

# Лимит: anti brute force SSH (6 попыток/30 сек)
                sudo ufw limit 22/tcp

                # Удалить по номеру (сначала status numbered)
                sudo ufw delete 3

                # Запретить конкретный IP
                sudo ufw deny from 192.0.2.100

                # Сбросить все правила (осторожно)
                sudo ufw reset

ufw limit использует модуль iptables recent для частоты соединений — эффективно для SSH, но не заменяет вход по ключу и отключение пароля. Правила применяются в порядке добавления; более конкретные должны быть выше. allow не срабатывает? Проверьте, не перекрывает ли его более поздний deny.

UFW вместе с Docker / Kubernetes

Сценарий, где UFW «настроен, но как будто нет». Docker по умолчанию вставляет свои цепочки iptables и может обходить правила UFW — вы думаете, 3306 закрыт, а порт контейнера всё ещё виден из интернета.

Решения (по убыванию предпочтения):

• Контейнер только на 127.0.0.1 — -p 127.0.0.1:3000:3000, наружу через reverse proxy на хосте
• Без ports в docker-compose — внутренняя сеть + reverse proxy
• Docker "iptables": false (правила форвардинга вести самим — для продвинутых)
• Облачная security group как последняя сетка, если Docker обходит UFW

На узлах K8s добавляются NetworkPolicy Calico/Cilium; UFW дополняет на уровне узла. Для одиночного VPS с Docker Compose обычно хватает первого пункта (привязка к loopback).

Согласование security group и UFW

Настраивайте оба уровня — политика должна совпадать: security group разрешает 22, UFW тоже allow 22; security group не пускает 3306, allow в UFW с интернета не поможет — но скомпрометированные машины во внутренней сети могут сканировать, поэтому UFW всё равно deny.

Рекомендуемое разделение:

• Security group: грубо, только 22/80/443, источник IP — офис или CDN
• UFW: тонко, комментарии к сервисам, limit SSH, блокировка вредоносных IP
• fail2ban: динамический слой, читает логи

После изменений проверьте снаружи: nmap -p 22,80,443,3306 your.server.ip (только свои машины!). 3306 open без намеренной экспозиции БД? Сразу проверьте binding Docker или адрес прослушивания приложения.

Устранение неполадок: сервис недоступен после UFW

В таком порядке — большинство случаев за десять минут:

• sudo ufw status verbose — правила активны? Верны порт и протокол (tcp/udp)?
• sudo ss -tlnp — приложение слушает 0.0.0.0, а не только 127.0.0.1?
• Входящие правила security group синхронизированы?
• Docker обходит UFW?
• Временно sudo ufw disable для сравнения (потом снова enable)

Не подключается только один источник IP? Ищите deny from или бан fail2ban. Логи UFW по умолчанию скудные; при необходимости LOGLEVEL=medium в /etc/ufw/ufw.conf, sudo ufw reload, отклонённые пакеты в /var/log/ufw.log.

Чеклист перед продакшеном (можно копировать)

Новая машина или переустановка — выполните по порядку:

sudo apt install ufw -y
                sudo ufw default deny incoming
                sudo ufw default allow outgoing
                sudo ufw allow 22/tcp comment 'SSH'      # или ваш порт
                sudo ufw allow 80/tcp
                sudo ufw allow 443/tcp
                sudo ufw limit 22/tcp                    # опционально: лимит SSH
                sudo ufw enable
                sudo ufw status verbose

Не забудьте усиление системы: SSH-ключи, отключение root по паролю, регулярные обновления через unattended-upgrades. Файрвол — граница, не панацея, но отсекает большую часть автоматического сканирования, пока вы углубляете защиту.