UFW на практике: быстрые правила для веб‑сервера, SSH и rate‑limit

Если у вас Ubuntu‑сервер и нужно «навести порядок» в сетевом доступе за 10–15 минут, UFW (Uncomplicated Firewall) — та самая практичная обёртка над подсистемой фильтрации пакетов, которая закрывает 90% задач без лишней боли. На виртуальном хостинге файрволл на уровне ОС обычно уже управляется провайдером; UFW актуален для собственных серверов и VDS. В этой статье разберём минимально достаточную, но безопасную схему для веб‑сервера: базовые политики, SSH c ограничением частоты попыток, порты 80/443, профили приложений и аккуратную проверку, чтобы не выпилить себе доступ. Всё с упором на реальные шаги и типовые ситуации админов, девопсов и веб‑мастеров.

Базовая модель: «закрыто всё, кроме нужного»

Золотое правило firewall на публичном сервере — по умолчанию запрещаем входящий трафик, а разрешаем только необходимые сервисы. Исходящий трафик обычно оставляем открытым (обновления, внешние API и прочее). В UFW это выражается двумя настройками по умолчанию (default deny incoming и default allow outgoing) и дальнейшим добавлением точечных allow.

Прежде чем включать UFW на удалённом сервере, обязательно добавьте правило для SSH. И держите активное SSH‑соединение не закрытым, пока не убедитесь, что новый доступ работает.

Подготовка: IPv6, профили приложений, текущее состояние

На современных серверах всё чаще используется IPv6. Если ваш хостинг выдаёт IPv6, проверьте, чтобы UFW фильтровал и его. Для этого убедитесь, что UFW включит поддержку IPv6 до старта. Также полезно посмотреть доступные «профили приложений», чтобы одним правилом открыть сразу пару портов (например, HTTP+HTTPS для Nginx или Apache).

sudo nano /etc/default/ufw   # параметр IPV6=yes, если у вас есть IPv6
sudo ufw status verbose      # состояние и политики по умолчанию
sudo ufw app list            # профили приложений: Nginx Full, Apache Full и т.п.

Если IPV6 был выключен, включите, сохраните файл и перезапустите UFW после основной настройки. Иначе UFW начнёт фильтровать только IPv4, оставив IPv6 «дырявым».

Стартовая безопасная последовательность

Сделаем минимальный набор шагов, который подходит почти для всех веб‑серверов:

# 1) Разрешаем SSH заранее (подставьте свой порт, если он нестандартный)
sudo ufw allow OpenSSH comment "SSH"
# или так, если у вас, например, порт 2222
sudo ufw allow 2222/tcp comment "SSH on 2222"

# 2) Политики по умолчанию: закрываем входящий, разрешаем исходящий
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 3) HTTP/HTTPS для веб‑сервера
# Если используете Nginx или Apache — удобнее профилем:
sudo ufw allow "Nginx Full"
# или
sudo ufw allow "Apache Full"

# 4) Включаем firewall
sudo ufw enable

# 5) Проверяем
sudo ufw status verbose

На этом этапе у вас уже работающая и достаточно безопасная база: снаружи видны только SSH и веб‑порт(ы). Далее — доводим до практического совершенства.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

SSH: ограничение частоты (rate limit) и ограничение по IP

На публичном SSH всегда идёт «фоновый шум» из ботов. В UFW есть простое средство приглушить брутфорс — режим limit. Он разрешает доступ, но ограничивает частоту новых соединений с одного источника. Если попыток слишком много за короткий промежуток (ориентировочно несколько попыток в 30 секунд), источник временно подавляется.

# Включить ограничение частоты для SSH (по стандартному порту):
sudo ufw limit OpenSSH comment "Rate limit SSH"

# Для нестандартного порта, например 2222:
sudo ufw limit 2222/tcp comment "Rate limit SSH on 2222"

Режим limit особенно полезен, когда у вас нет статического «админского» IP. Если статический IP есть, лучше разрешить доступ только с него, а остальным — отказать:

# Разрешаем SSH только с вашего IP/подсети (пример — документационная подсеть)
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp comment "SSH allow from office"

# Дополнительно можно явным правилом запретить SSH всем остальным (при default deny это не обязательно)
sudo ufw deny 22/tcp comment "SSH deny others"

Если доступ нужен из нескольких сетей (офис, VPN), добавьте несколько allow from .... Для нестандартного порта правила выглядят так же, просто меняйте 22 на свой порт.

Режим limit в UFW ограничивает новые соединения. Уже установленным сеансам он не мешает. Для лучшей защиты совмещайте его с ключевой аутентификацией SSH и отключением паролей.

Веб‑сервер: открываем ровно то, что нужно

Для веб‑сервера обычно достаточно открыть порты 80/tcp и 443/tcp. Самый простой способ — использовать профиль приложения, который уже содержит оба порта:

sudo ufw app list
sudo ufw allow "Nginx Full"
# или, если вы на Apache:
sudo ufw allow "Apache Full"

Если профилей нет или вы слушаете специфичный порт, откройте его явно:

# Классика вручную
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Пример для бэкенда на 8080 (если он должен быть доступен извне)
sudo ufw allow 8080/tcp comment "Public app port"

Не применяйте ufw limit к 80/443. Веб‑трафик бывает «всплесками», и ограничение на уровне UFW может привести к ложным блокировкам. Rate limit для HTTP/HTTPS делайте на уровне веб‑сервера (например, средствами Nginx) или с помощью специализированных решений.

Чтобы 443/tcp имел смысл, установите валидные SSL-сертификаты и включите редиректы на HTTPS. Дополнительно укрепите фронтенд политиками заголовков — смотрите наш гайд по HTTP Security Headers для Nginx и Apache.

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

Профили хранятся в /etc/ufw/applications.d/ и позволяют одной командой открывать набор портов. Посмотрите детали профиля, чтобы понимать, какие порты он включает:

sudo ufw app info "Nginx Full"

Если в вашем стеке есть сервис с собственными портами (например, панель администрирования), имеет смысл создать кастомный профиль или просто явно прописать allow для нужных портов и подсетей.

Сужаем доступ к админке и бэкендам

Частая ошибка — публиковать в Интернет всё подряд: phpMyAdmin, админки CMS, внутренние панели или бэкенд на 3000/8080. На уровне firewall старайтесь отрезать лишнее сразу:

• Если сервис слушает только 127.0.0.1, он и так недоступен снаружи — это лучший вариант для внутренних бэкендов за обратным прокси.
• Если сервис обязан быть доступен извне, ограничьте подсетями: офис, VPN, конкретные адреса.
• К админкам применяйте allow from ... и дополнительно ограничивайте паролями/2FA на уровне приложения.

# Пример: доступ к панели на 8443 только из офиса и VPN
sudo ufw allow from 203.0.113.0/24 to any port 8443 proto tcp comment "Admin from office"
sudo ufw allow from 198.51.100.10 to any port 8443 proto tcp comment "Admin from VPN"
# Остальным доступ закрыт политикой deny incoming

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

UFW применяет правила сверху вниз. Команда status numbered показывает нумерованный список, а delete позволяет удалять по номеру. Это удобно, когда вы экспериментируете и хотите быстро откатить неудачное правило.

sudo ufw status numbered
sudo ufw delete 5
sudo ufw delete allow 8080/tcp

Посмотреть, что было добавлено пользователем (в отличие от автоматически сгенерированных правил), можно так:

sudo ufw show added

Логи и аудит

Для разбора инцидентов включайте логирование. В UFW есть уровни off, low, medium, high, full. Начните с low или medium, чтобы не утонуть в сообщениях.

sudo ufw logging medium
sudo ufw status verbose

Логи обычно доступны в /var/log/ufw.log и в системном журнале. Ищите отбрасываемые подключения, всплески по SSH и странные попытки на незадокументированные порты.

Проверка снаружи: что по факту открыто

Проверьте с другого хоста, какие порты видны. Используйте знакомые инструменты для TCP‑сканирования конкретных портов. На самом сервере проверьте, кто слушает сокеты, и сверьте с правилами:

ss -ltnp | grep -E ":(22|80|443|8080)"

Если сервер слушает порт, но он не должен быть доступен извне, убедитесь, что UFW его не открывает, и при необходимости ограничьте доступ по IP.

Rate limit шире SSH: когда уместно

Ограничение частоты в UFW можно применять не только для SSH. Это полезно для сервисов, где редкие входы — норма (SMTP submission на 587/tcp, административные панели, RDP/VNC в частных сценариях). Смысл тот же: не ставить «бетонную стену», а приглушить всплески и брутфорс.

# Пример: ограничить частоту подключений к почтовой отправке
sudo ufw limit 587/tcp comment "Rate limit submission"

# Пример: ограничить панель администрирования
sudo ufw limit 8443/tcp comment "Rate limit admin"

Повторимся: для HTTP/HTTPS это неподходящий механизм — у веб‑трафика совсем другой профиль нагрузки.

Docker и UFW: что важно знать

Если вы используете контейнеры, имейте в виду, что публикация портов в контейнере может обойти ваши ожидания относительно UFW: правила Docker изменяют таблицы фильтрации. В результате некоторые порты оказываются доступны, хотя вы их не открывали в UFW. Решения есть (настройка политики FORWARD, использование цепочки DOCKER‑USER, аккуратные route-правила UFW), но это уже отдельная тема. Главное — проверяйте фактическую доступность снаружи и сверяйте её с задуманной моделью.

Сохранность правил и перезагрузки

UFW применяет persistent‑конфигурацию — после ребута ваши правила сохраняются. Если меняете поддержку IPv6, правите /etc/default/ufw или «ломаете» набор правил экспериментами, можно сделать «мягкий» откат:

# Полный сброс к дефолтам (используйте осторожно)
sudo ufw reset
# Повторно задать политики и нужные allow/limit

Перед любыми кардинальными изменениями зафиксируйте текущее состояние для справки:

sudo ufw status numbered
sudo ufw show added
sudo cp /etc/ufw/user.rules ~/user.rules.backup
sudo cp /etc/ufw/user6.rules ~/user6.rules.backup

Готовые «пресеты» правил для типовых задач

Минимальный веб‑сервер (SSH + HTTP/HTTPS)

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH comment "SSH"
sudo ufw limit OpenSSH comment "Rate limit SSH"
sudo ufw allow "Nginx Full"
sudo ufw enable
sudo ufw status verbose

Веб‑сервер с админкой по IP‑листу

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw limit OpenSSH
sudo ufw allow "Nginx Full"
# Админка только из офиса и VPN
sudo ufw allow from 203.0.113.0/24 to any port 8443 proto tcp comment "Admin office"
sudo ufw allow from 198.51.100.10 to any port 8443 proto tcp comment "Admin VPN"
sudo ufw enable

Bastion/удалённый доступ только по SSH

sudo ufw default deny incoming
sudo ufw default allow outgoing
# Ограничиваем SSH сетью офиса и резервным IP
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
sudo ufw allow from 198.51.100.10 to any port 22 proto tcp
sudo ufw limit OpenSSH
sudo ufw enable

Чек‑лист перед включением UFW на проде

• Понимаете, откуда будете заходить по SSH (статический IP, VPN, динамика)? Добавили нужные allow или limit.
• Проверили IPV6=yes, если у сервера есть IPv6.
• Открыли только 80/tcp и 443/tcp для публичного веб‑сайта; внутренние бэкенды — на 127.0.0.1 или ограничены по IP.
• Включили логирование на уровне low/medium и посмотрели первые записи.
• Проверили фактическую доступность снаружи и список слушающих сокетов.

Итог

UFW в Ubuntu — оптимальный способ быстро закрыть поверхность атаки: строгие политики по умолчанию, точечные разрешения для SSH и веб‑сервера, простое rate limit против брутфорса, понятные логи и управление правилами. Начните с минимальной схемы «deny incoming, allow outgoing», добавьте профили Nginx Full/Apache Full, включите limit для SSH — и у вас уже адекватный базовый уровень безопасности. Для полноценной защиты дополняйте это настройкой HTTPS через SSL-сертификаты и политиками безопасности на веб‑уровне.