Как настроить фаервол UFW на Ubuntu без потери доступа по SSH 

Базовая настройка UFW на удаленном Ubuntu-сервере выглядит так:

sudo ufw allow OpenSSH

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw enable

sudo ufw status verbose

После включения firewall не закрывайте текущую SSH-сессию сразу — сначала проверьте новое подключение во втором терминале.

Дальше UFW можно использовать для точечных задач:

• Разрешать доступ к порту только с определенного IP;
• Блокировать отдельные адреса;
• Удалять правила через ufw status numbered;
• Включать логирование;
• Контролировать IPv6.

Если сервер использует Docker, одного ufw status недостаточно: опубликованные контейнерные порты нужно дополнительно проверять через docker ps и ss.

Если после включения UFW перестал работать SSH или сайт, сначала проверяйте само правило и listening port, а ufw disable используйте только как временный диагностический шаг.

Что такое UFW и зачем он нужен

Добро пожаловать!

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

Речь про UFW — Uncomplicated Firewall, то есть упрощенный интерфейс для управления firewall в Ubuntu.

Само слово firewall часто звучит так, будто сейчас придется лезть в какие-то запутанные сетевые таблицы, цепочки, приоритеты и километровые правила. Но на практике UFW как раз и появился для того, чтобы администратору не приходилось каждый раз вручную работать с более низкоуровневыми механизмами Linux.

Смысл firewall довольно простой: он решает, какой сетевой трафик разрешить, а какой заблокировать.

Например, у нас есть обычный VPS, на котором работают:

• SSH для администрирования;
• Nginx на 80 и 443;
• Возможно, PostgreSQL;
• Какие-то внутренние сервисы;
• Docker-контейнеры.

Без firewall сервер может слушать больше портов, чем мы вообще планировали показывать наружу.

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

UFW позволяет заранее задать понятные правила:

1. SSH — разрешить
2. HTTP — разрешить
3. HTTPS — разрешить
4. PostgreSQL — не открывать наружу
5. Все остальное — блокировать

Именно с такой логикой мы и будем работать дальше.

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

Особенно легко это сделать на удаленном VPS, где единственный способ управления сервером — SSH.

Поэтому в этой статье главным будет не просто набор команд, а порядок действий.

Как UFW связан с firewall в Ubuntu

UFW сам по себе не является каким-то отдельным сетевым экраном, который живет поверх Linux независимо от системы.

Скорее это удобный интерфейс управления правилами фильтрации сетевого трафика.

В современных Ubuntu под капотом могут использоваться механизмы netfilter и соответствующая инфраструктура iptables/nftables, а UFW позволяет работать с ними через более простые команды.

Вместо условно сложных низкоуровневых правил мы можем написать: sudo ufw allow 22/tcp и получить понятное правило: разрешить входящие TCP-подключения на порт 22.

Или: sudo ufw deny 3306/tcp, то есть: запретить входящие подключения к MySQL сервису на этом порту.

Конечно, в реальной системе лучше не просто раскидывать allow и deny хаотично.

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

UFW как раз очень хорошо подходит для такого подхода.

Например, базовая политика может быть:

sudo ufw default deny incoming

sudo ufw default allow outgoing

Первая команда запрещает входящие соединения, если для них нет отдельного разрешающего правила.

Вторая разрешает исходящие соединения с сервера.

Это довольно распространенная схема для VPS.

Серверу обычно нужно самому ходить наружу:

• Скачивать пакеты через apt;
• Обращаться к API;
• Делать DNS-запросы;
• Получать сертификаты;
• Подключаться к внешним сервисам.

В идеальной инфраструктуре внешние подключения сервера тоже ограничиваются по белым спискам, но на базовом уровне default outgoing ставить в allow является допустимым. 

А вот входящие подключения мы хотим контролировать иначе. Более строже.

Поэтому можно представить UFW как охранника у входа в здание.

Он не обязан знать, что происходит внутри приложения, базы или Nginx.

Его задача проще: «На какой порт пришли? Откуда? Есть ли правило, которое это разрешает?»

Если правила нет — трафик блокируется.

Главное правило: сначала разрешаем SSH, потом включаем firewall

Вот теперь самая важная часть всей статьи.

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

Это не формальность и не перестраховка, и чтобы примета "удалённая настройка файрвола - к дальней дороге" не стала реальностью, нужно подготовиться.

Представим ситуацию.

Вы подключены к серверу: ssh ubuntu@203.0.113.10

Затем выполняете:

sudo ufw default deny incoming

sudo ufw enable

Но правило для SSH не добавили.

Текущая SSH-сессия иногда может еще какое-то время жить, потому что соединение уже установлено.

А вот новая попытка подключения может закончиться тем, что сервер просто перестанет пускать вас на порт 22.

И тогда получается довольно комичная, но неприятная ситуация: firewall работает прекрасно. Настолько прекрасно, что защищает сервер даже от администратора.

Если у провайдера есть web-console, VNC или rescue mode, ситуацию обычно можно исправить.

Если нет — придется обращаться в поддержку или восстанавливать доступ другим способом.

Поэтому нормальный порядок всегда такой:

1. Уточняем, как можно будет подключится к серверу, если сами себя заблокируем;
2. Проверяем, на каком порту работает SSH.
3. Разрешаем этот порт в UFW.
4. Только потом включаем firewall.
5. Не закрываем текущую SSH-сессию сразу.
6. Открываем второе подключение и проверяем, что SSH действительно работает.

Для стандартного SSH на порту 22 можно разрешить готовый профиль: sudo ufw allow OpenSSH

Или явно: sudo ufw allow 22/tcp

Оба варианта решают одну задачу.

Проверить правило можно еще до включения firewall: sudo ufw status

Если UFW пока выключен, увидим что-то вроде: Status: inactive

Но сами правила уже могут быть добавлены.

Если SSH работает не на стандартном 22, а, например, на 2222, то разрешить нужно именно его: sudo ufw allow 2222/tcp

Узнать текущий слушающий порт можно, например, так: sudo ss -lntp | grep ssh или посмотреть конфигурацию SSH: sudo grep -i "^Port" /etc/ssh/sshd_config

Если строка Port не задана явно, обычно используется стандартный 22.

Есть еще один полезный практический прием: не закрывайте текущую SSH-сессию сразу после ufw enable.

Лучше открыть второй терминал и попробовать подключиться заново.

Например: ssh ubuntu@203.0.113.10

Если второе соединение проходит, значит правило SSH работает.

Если нет — первая сессия все еще открыта, и у нас есть шанс исправить firewall без приключений.

Проверяем UFW и текущие настройки

С принципом работы разобрались. Теперь можно перейти к самому серверу.

Перед тем как добавлять правила, полезно сначала понять две вещи:

• Установлен ли UFW вообще;
• В каком состоянии он сейчас находится.

Заодно сразу проверим IPv6, потому что закрыть только IPv4 и забыть про второй стек — не самая удачная идея.

Устанавливаем UFW при необходимости

На Ubuntu UFW часто уже установлен, но лучше всё равно расскажу как перепроверить этот момент.

Проверим: ufw --version

Если команда отрабатывает и показывает версию — всё в порядке.

Если получаем что-то вроде: command not found, то устанавливаем пакет:

sudo apt update

sudo apt install -y ufw

После этого снова проверяем: ufw --version

Теперь посмотрим текущий статус: sudo ufw status

На свежем сервере вполне нормально увидеть: Status: inactive

Это означает, что UFW установлен, но фильтрация через него пока не активирована.

Важно: inactive — не ошибка.

На этом этапе мы как раз и не должны спешить с ufw enable, потому что SSH-правило еще нужно проверить и настроить аккуратно.

Если UFW уже активен, увидим что-то вроде: Status: active

А ниже — существующие правила.

Например:

В таком случае не стоит сразу добавлять дубликаты.

Сначала лучше посмотреть конфигурацию целиком: sudo ufw status verbose

Эта команда дополнительно покажет политики по умолчанию и логирование.

Например: Default: deny (incoming), allow (outgoing), disabled (routed)

Для обычного VPS это вполне логичная модель: любой входящий трафик закрыт, а нужные сервисы открываются отдельными правилами.

Проверяем статус и поддержку IPv6

Теперь разберемся с IPv6.

UFW умеет создавать правила сразу и для IPv4, и для IPv6, если соответствующая поддержка включена.

Проверим файл: sudo nano /etc/default/ufw

Нас интересует строка: IPV6=yes

Если указано: IPV6=yes

UFW будет применять правила и к IPv6-трафику.

Если же стоит: IPV6=no

фильтрация через UFW для IPv6 отключена.

Почему это важно?

Допустим, сервер имеет сразу два публичных адреса:

• IPv4 → 203.0.113.10
• IPv6 → 2001:db8::10

Вы настроили UFW только для IPv4 и уверены, что закрыли лишний порт.

Но если сервис слушает еще и IPv6, к нему потенциально можно обратиться по второму адресу.

Поэтому если VPS реально использует IPv6, лучше не оставлять его вне правил firewall.

После изменения /etc/default/ufw конфигурацию UFW нужно будет перезагрузить.

Но на этом этапе мы пока ничего менять не обязаны — достаточно проверить текущее значение.

Дополнительно посмотрим, есть ли у сервера IPv6-адреса: ip -6 addr

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

Если же есть глобальный адрес, его уже стоит учитывать при настройке firewall.

Можно также посмотреть текущие правила более подробно: sudo ufw status verbose

Если UFW активен и IPv6 включен, правила часто отображаются в двух вариантах:

Это хороший признак: одно правило обслуживает сразу оба IP-стека.

Идём дальше.

Настраиваем базовые правила без потери SSH

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

Теперь можно переходить к самому важному этапу — добавить базовые правила и включить firewall так, чтобы не потерять доступ к серверу.

Здесь порядок действий критичен.

Сначала разрешаем SSH. Затем открываем веб-порты. И только после этого активируем UFW.

Разрешаем SSH

Если SSH работает на стандартном порту 22, самый простой вариант: sudo ufw allow OpenSSH

UFW использует профиль приложения OpenSSH, который обычно соответствует TCP-порту 22.

Проверить доступные профили можно так: sudo ufw app list

Ожидаем что-то вроде:

Available applications: OpenSSH

Можно открыть SSH и напрямую по номеру порта: sudo ufw allow 22/tcp

По смыслу результат тот же.

Если SSH настроен на нестандартный порт, например 2222, разрешать нужно именно его: sudo ufw allow 2222/tcp

Перед включением UFW полезно проверить добавленное правило: sudo ufw status

Если firewall пока не активен, статус все еще может показывать:

Status: inactive

Это нормально. Правило уже сохранено и начнет применяться после включения UFW.

Самое главное — не выполнять ufw enable, пока SSH не разрешен.

Открываем HTTP и HTTPS

Теперь добавим порты, которые понадобятся обычному веб-серверу.

HTTP использует TCP-порт 80: sudo ufw allow 80/tcp

HTTPS — TCP-порт 443: sudo ufw allow 443/tcp

Можно также использовать готовый профиль Nginx, если он установлен.

Посмотрим: sudo ufw app list

Там могут быть:

Nginx Full

Nginx HTTP

Nginx HTTPS

Например: sudo ufw allow "Nginx Full" обычно открывает сразу 80 и 443.

Но для учебной настройки явные правила:

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

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

При этом не нужно открывать вообще все сервисы, которые существуют на сервере.

Например, если PostgreSQL работает только локально, порт 5432 наружу ему не нужен.

То же самое касается локальных портов приложений вроде:

8000

3000

8080

Если сервис стоит за Nginx и слушает только 127.0.0.1, открывать соответствующий порт в UFW нет смысла.

Для типичного VPS базовый набор правил может выглядеть так:

sudo ufw allow OpenSSH

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

Перед активацией еще раз проверим: sudo ufw status

Включаем UFW и проверяем результат

Теперь SSH уже разрешен, HTTP и HTTPS тоже подготовлены.

Можно активировать firewall: sudo ufw enable

UFW предупредит, что включение firewall может повлиять на существующие SSH-подключения.

Если правило SSH добавлено правильно, подтверждаем: y

После этого проверим: sudo ufw status verbose

Ожидаем примерно такую картину:

Если вместо 22/tcp использовали профиль OpenSSH, в таблице может отображаться его имя.

Но проверка на этом не заканчивается.

Не закрывайте текущую SSH-сессию.

Откройте второе окно терминала и попробуйте подключиться к VPS заново: ssh ubuntu@203.0.113.10

Если новое соединение устанавливается, значит SSH действительно не заблокирован.

После этого можно проверить веб-порты.

Например: curl -I http://203.0.113.10 или, если домен уже подключен: curl -I https://example.com

Если Nginx работает, должны получить ожидаемый HTTP-ответ.

Можно дополнительно посмотреть, какие процессы вообще слушают сетевые порты: sudo ss -lntp

Это полезная проверка, потому что UFW сам по себе не запускает сервисы.

Например, правило: sudo ufw allow 443/tcp лишь разрешает трафик.

Если Nginx на 443 не слушает, сайт по HTTPS от этого автоматически не появится.

И наоборот: если приложение слушает какой-то порт, это еще не означает, что его обязательно нужно открывать наружу.

Теперь базовая защита готова: входящие соединения контролируются UFW, административный доступ сохранен, а наружу разрешены только нужные веб-порты.

Дальше перейдем к более точечным правилам — например, разрешим доступ к определенному порту только с конкретного IP-адреса и посмотрим, как блокировать отдельные источники.

Ограничиваем доступ по IP

Разрешаем порт только для конкретного адреса

Допустим, нужно разрешить SSH только с: 198.51.100.25

Тогда правило выглядит так:

    
        
    sudo ufw allow from 198.51.100.25 to any port 22 proto tcp

Здесь мы одновременно указываем:

• Источник — 198.51.100.25;
• Порт — 22;
• Протокол — TCP.

Проверим: sudo ufw status

Увидим правило примерно такого вида:

Но здесь есть важный нюанс.

Если раньше мы уже выполнили: sudo ufw allow OpenSSH или: sudo ufw allow 22/tcp

SSH все еще разрешен для всех.

То есть наличие более узкого правила не отменяет широкое.

Если цель действительно состоит в том, чтобы пускать на SSH только один IP, старое правило нужно удалить.

Перед этим обязательно убедитесь, что ваш адрес действительно постоянный.

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

Поэтому ограничение SSH по одному IP удобно только там, где источник предсказуем.

То же самое можно сделать и для других портов.

Например, разрешить PostgreSQL только внешнему серверу:

    
        
    sudo ufw allow from 198.51.100.25 to any port 5432 proto tcp

Или служебный интерфейс:

    
        
    sudo ufw allow from 198.51.100.25 to any port 8080 proto tcp

Но открывать такие сервисы наружу стоит только тогда, когда это действительно необходимо.

Блокируем отдельный IP

Работает и обратная логика.

Если нужно заблокировать весь входящий трафик с конкретного адреса: sudo ufw deny from 198.51.100.50

Для одного конкретного порта:

    
        
    sudo ufw deny from 198.51.100.50 to any port 22 proto tcp

Это может пригодиться, если какой-то источник постоянно стучится в определенный сервис.

Но не стоит превращать UFW в бесконечный список случайных IP-адресов из логов.

Интернет-сканирование серверов — обычное явление, а адреса злоумышленников легко меняются.

Куда лучше сначала правильно настроить базовую политику: deny incoming, а затем разрешать только действительно необходимые сервисы.

Управляем правилами UFW

Через некоторое время firewall редко остается таким же аккуратным, как в день первой настройки.

Добавили тестовый порт, поменяли SSH, временно разрешили IP, потом забыли удалить правило.

Поэтому важно уметь не только добавлять правила, но и нормально ими управлять.

Смотрим правила с номерами

Обычный просмотр: sudo ufw status

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

Выполним: sudo ufw status numbered

Например:

Теперь можно обращаться к конкретному правилу по номеру.

Это особенно удобно, когда есть несколько похожих записей.

Удаляем ненужные правила

Допустим, тестовый порт 8080 больше не нужен.

Удаляем правило номер 4: sudo ufw delete 4

UFW попросит подтверждение.

После удаления снова проверяем: sudo ufw status numbered

Есть и второй вариант — удалить правило тем же способом, которым оно добавлялось.

Например: sudo ufw delete allow 443/tcp или sudo ufw delete deny from 198.51.100.50

Но numbered-вариант обычно нагляднее.

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

Поэтому если собираетесь удалить несколько правил подряд, лучше каждый раз заново выполнять: sudo ufw status numbered, а не полагаться на старую нумерацию.

Включаем логирование

Когда firewall уже работает, иногда хочется понять, что именно он блокирует.

Для этого включим логирование: sudo ufw logging on

Проверить состояние можно через: sudo ufw status verbose

Там появится информация о logging.

По умолчанию UFW пишет события через системный журнал, а в Ubuntu также часто используется файл: /var/log/ufw.log

Посмотреть последние записи можно так: sudo tail -n 50 /var/log/ufw.log

А наблюдать в реальном времени: sudo tail -f /var/log/ufw.log

В логах можно увидеть:

• Заблокированный пакет;
• IP источника;
• IP назначения;
• Порт;
• Протокол;
• Интерфейс.

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

Тогда можно проверить: запрос вообще не доходит до сервиса или его режет UFW.

Если логов становится слишком много, уровень можно настроить: sudo ufw logging low

Доступны уровни вроде:

off

low

medium

high

full

Для обычного VPS чаще всего достаточно low.

Чем выше уровень, тем больше записей будет появляться, а значит, тем быстрее могут расти логи.

Теперь UFW уже умеет не только пропускать нужные сервисы, но и ограничивать доступ по источнику, удалять устаревшие правила и помогать с диагностикой через логи.

Осталось отдельно разобрать два момента, о которых легко забыть: IPv6 и Docker.

IPv6 и UFW

Проверяем, что IPv6 тоже фильтруется

Начнем с конфигурации UFW: sudo grep "^IPV6=" /etc/default/ufw

Ожидаем: IPV6=yes

Если так и есть, UFW будет создавать правила не только для IPv4, но и для IPv6.

Проверить наличие IPv6-адресов на сервере можно так: ip -6 addr

Если сервер действительно использует глобальный IPv6-адрес, это особенно важно.

Теперь посмотрим правила: sudo ufw status

При включенной поддержке IPv6 можно увидеть пары вроде:

Это означает, что правила применяются сразу к обоим стекам.

Если же IPV6=no, а сервер реально использует IPv6, лучше сначала изменить: IPV6=yes, а затем применить настройки UFW.

После изменений: sudo ufw reload

Если конфигурация менялась на уже работающем сервере, после перезагрузки firewall еще раз проверяем: sudo ufw status verbose

Смысл здесь простой: если сервис доступен по IPv6, firewall тоже должен учитывать IPv6.

Иначе можно получить странную картину, когда по IPv4 порт закрыт, а по IPv6 — все еще доступен.

UFW и Docker: важный нюанс

Вот здесь начинается одна из самых известных ловушек UFW.

Допустим, мы уверены, что разрешили наружу только:

• 22
• 80
• 443

А потом запускаем контейнер: docker run -p 8080:80 nginx

Логично ожидать, что UFW заблокирует внешний доступ к 8080, ведь такого allow мы не добавляли.

Но Docker работает с сетевыми правилами немного особым образом.

Почему опубликованные Docker-порты могут обходить ожидаемые правила UFW

Docker сам добавляет правила в netfilter/iptables для NAT и пересылки трафика.

Из-за этого опубликованные контейнерные порты могут обрабатываться еще до того, как трафик пройдет через те цепочки UFW, на которые администратор рассчитывает.

Поэтому ситуация может выглядеть так: sudo ufw status показывает только:

но Docker-контейнер, опубликованный через: -p 8080:80 все равно оказывается доступен снаружи.

По итогу просто Docker сам вмешивается в сетевую обработку трафика и создает свои правила.

Это особенно важно понимать, если вы используете Docker на публичном VPS и считаете UFW единственным фильтром.

Проверить опубликованные порты контейнеров можно так: docker ps

Например: 0.0.0.0:8080->80/tcp

Здесь ключевое: 0.0.0.0:8080

Это означает, что Docker слушает порт на всех IPv4-интерфейсах сервера.

Если контейнер должен быть доступен только локально, безопаснее привязать его к loopback: docker run -p 127.0.0.1:8080:80 nginx

Тогда сервис будет доступен только самому VPS.

Такой вариант особенно удобен для контейнера, который стоит за Nginx: Nginx → 127.0.0.1:8080 → Docker-контейнер

И внешний порт 8080 вообще не нужно публиковать наружу.

Как безопаснее работать с UFW и Docker

Главное правило здесь — не полагаться только на список ufw status, если на сервере работает Docker.

Всегда дополнительно проверяйте, какие порты реально опубликованы: docker ps и что слушает система: sudo ss -lntp

Особенно внимательно смотрите на адрес привязки.

Например: 0.0.0.0:8080 означает доступ со всех IPv4-интерфейсов. А: 127.0.0.1:8080 — только локально.

Для большинства приложений за reverse proxy второй вариант безопаснее.

Если контейнер действительно должен быть доступен из интернета напрямую, правила доступа лучше продумывать отдельно, учитывая Docker networking и цепочку DOCKER-USER.

Но для обычного VPS часто достаточно более простого подхода:

• Не публиковать лишние контейнерные порты наружу;
• Привязывать внутренние сервисы к 127.0.0.1;
• Наружу оставлять только Nginx на 80 и 443;
• Отдельно проверять реальные listening ports через ss и docker ps.

Именно здесь особенно полезно помнить: firewall — это не только то, что написано в ufw status.

Если на сервере есть Docker, фактическая сетевая картина может быть шире, чем кажется по одному UFW.

Если после включения UFW что-то перестало работать

Даже при аккуратной настройке firewall иногда что-то идет не по плану.

Главное в такой ситуации — не начинать хаотично удалять все правила подряд. Гораздо полезнее сначала понять, что именно перестало работать и на каком уровне.

Если SSH не подключается, смотрим правила доступа к административному порту.

Если сайт пропал — проверяем 80 и 443, а заодно убеждаемся, что сам Nginx вообще слушает эти порты.

И только если нужно срочно вернуть доступ к серверу, временно отключаем UFW.

SSH больше не подключается

Если после включения UFW новая SSH-сессия не открывается, первым делом проверяем, разрешен ли нужный порт.

Если старая SSH-сессия еще жива, выполняем: sudo ufw status numbered

Для стандартного SSH должны увидеть правило примерно такого вида: 22/tcp    ALLOW IN    Anywhere или OpenSSH   ALLOW IN    Anywhere

Если используется нестандартный порт, например: 2222, проверяем именно его: sudo ss -lntp | grep ssh

Если SSH слушает 2222, а в UFW открыт только 22, причина уже найдена.

Добавляем правильное правило: sudo ufw allow 2222/tcp и снова пробуем подключиться из второго терминала.

Если SSH ограничен конкретным IP:

    
        
    sudo ufw allow from 198.51.100.25 to any port 22 proto tcp

нужно проверить еще и свой текущий внешний адрес.

Если он изменился, UFW будет совершенно правильно блокировать новое подключение.

Именно поэтому ограничение SSH по IP удобно только при стабильном источнике.

Если же текущая сессия уже потеряна, остается использовать альтернативный доступ от провайдера:

• Web-console;
• VNC;
• Serial console;
• Rescue mode.

Через него можно исправить правило и вернуть SSH.

Сайт недоступен по HTTP или HTTPS

Если после настройки UFW перестал открываться сайт, сначала проверим разрешенные веб-порты: sudo ufw status

Должны быть разрешены:

80/tcp

443/tcp

Если правила отсутствуют:

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

После этого: sudo ufw reload

Но тут важно не перепутать firewall с самим веб-сервером.

UFW может разрешать 443, но если Nginx не запущен или вообще не слушает этот порт, HTTPS все равно не заработает.

Проверяем: sudo ss -lntp | grep -E ':80|:443' и sudo systemctl status nginx --no-pager

Если 80 или 443 отсутствуют в ss, проблема уже не в UFW.

Для HTTP можно дополнительно проверить локально: curl -I http://127.0.0.1

Если локально сайт отвечает, а извне нет, firewall становится одним из первых подозреваемых.

Если не отвечает даже локально — ищем проблему в Nginx или самом приложении.

Когда можно временно отключить UFW

Иногда нужно быстро проверить гипотезу: действительно ли соединение блокирует UFW?

В таком случае firewall можно временно отключить: sudo ufw disable

После этого сразу повторяем проблемное подключение.

Если сервис внезапно заработал, значит причина действительно была в правилах UFW.

Но оставлять firewall выключенным просто потому, что так «всё работает», не стоит.

Лучше найти конкретное правило, которое мешает.

После исправления снова включаем UFW: sudo ufw enable и проверяем: sudo ufw status verbose

То есть ufw disable — это скорее диагностический инструмент или аварийный временный шаг.

Если что-то перестало работать после включения firewall, лучше идти по списку наводящих вопросов:

• Сервис запущен?
• Нужный порт слушается?
• UFW разрешает его?
• Правило не ограничено неправильным IP?
• Docker не меняет ожидаемое поведение сети?

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

Заключение

UFW — один из тех инструментов, которые выглядят простыми ровно до тех пор, пока не включишь firewall раньше времени и не отрежешь себе SSH.

Поэтому главное в его настройке — не количество команд, а правильный порядок действий.

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

Дальше уже можно точечно ограничивать доступ по IP, удалять лишние правила, включать логирование и учитывать IPv6.

Отдельного внимания заслуживает Docker или другое ПО, которое "вмешивается" в трафик и делает свои правила. Опубликованные контейнерные порты могут вести себя не так, как ожидается по одному только ufw status, поэтому на Docker-хостах всегда полезно дополнительно проверять реальные listening ports и привязку контейнеров.

В итоге нормальная логика для обычного VPS выглядит довольно просто: наружу открываем только то, что действительно нужно, все остальное оставляем закрытым и периодически проверяем, не появился ли новый сервис, про который firewall еще ничего не знает.

FAQ

Нужно ли открывать SSH для всех IP-адресов?

Не обязательно.

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

    
        
    sudo ufw allow from 198.51.100.25 to any port 22 proto tcp

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

Что лучше: ufw allow OpenSSH или ufw allow 22/tcp?

Оба варианта подходят для стандартного SSH на порту 22.

Команда: sudo ufw allow OpenSSH использует готовый application profile UFW.

А: sudo ufw allow 22/tcp указывает порт напрямую.

Если SSH перенесен, например, на 2222, готовый профиль уже не подойдет без изменения его конфигурации — проще явно разрешить нужный порт.

Нужно ли открывать PostgreSQL, Redis или внутренний порт приложения в UFW?

Только если к сервису действительно должны подключаться извне.

Если PostgreSQL, Redis, Gunicorn или Node.js-приложение работают на том же VPS и доступны через 127.0.0.1, открывать их порты в UFW не требуется.

Чем меньше сервисов выставлено наружу, тем проще контролировать поверхность атаки.

Почему порт закрыт в UFW, но Docker-контейнер все равно доступен?

Потому что Docker сам создает сетевые правила для опубликованных портов.

Например: docker run -p 8080:80 nginx может опубликовать 8080 наружу независимо от того, как администратор ожидает работу обычных правил UFW.

Поэтому на Docker-хостах нужно дополнительно проверять:

docker ps

sudo ss -lntp

А внутренние контейнерные сервисы за reverse proxy удобнее привязывать к 127.0.0.1.

Что произойдет с текущей SSH-сессией после ufw enable?

Уже установленное соединение может продолжить работать, но полагаться на это нельзя.

Именно поэтому после включения UFW лучше не закрывать текущий терминал, а открыть вторую SSH-сессию и проверить новое подключение.

Если новая сессия проходит, доступ настроен правильно.

Можно ли полностью сбросить UFW?

Да: sudo ufw reset

Команда отключит UFW и удалит пользовательские правила.

Использовать ее лучше осторожно: после сброса придется заново настраивать SSH и остальные разрешения.

На удаленном VPS особенно важно не потерять доступ во время повторной настройки.

Нужно ли включать IPv6 в UFW, если я им не пользуюсь?

Если на VPS нет публичного IPv6 и стек фактически не используется, практической разницы может не быть.

Но если сервер получил глобальный IPv6-адрес, правила firewall должны учитывать и его. Иначе сервис может оказаться закрыт по IPv4, но доступен по IPv6.

Проверить можно командами:

ip -6 addr

sudo ufw status

Достаточно ли одного UFW для защиты VPS?

Нет. UFW — это только один уровень защиты.

Он помогает ограничить сетевой доступ, но не заменяет:

• Обновления системы;
• Безопасную настройку SSH;
• Сильные ключи и пароли;
• Права пользователей;
• Настройку приложений;
• Резервные копии;
• Контроль Docker-портов;
• Мониторинг и логи.

Firewall уменьшает поверхность атаки, но не исправляет уязвимый сервис, если тот уже открыт наружу.

Список источников

1. Ubuntu Server Documentation — Firewall / UFW
2. Ubuntu Community Help Wiki — UFW
3. Docker Documentation — Packet filtering and firewalls
4. UFW Manual — Ubuntu Manpages