Как настроить UFW на Ubuntu
Первое включение UFW на Ubuntu VPS с сохранением SSH-доступа: правила портов, таймер отката, внешняя проверка и частые ошибки.

В серии о первом VPS в Timeweb Cloud этот шаг выполняется после SSH-подключения и создания пользователя с sudo.
UFW позволяет настроить сетевой экран Ubuntu понятными командами: разрешить SSH, HTTP и HTTPS, а остальные новые входящие соединения блокировать. Но неправильный порядок действий может закрыть и ваше собственное подключение. Поэтому сначала выясним действующий SSH-порт, добавим разрешения и только затем включим firewall.
Инструкция рассчитана на первое включение UFW на обычном VPS с Ubuntu 24.04 LTS. На учебном сервере уже работает Nginx с HTTPS. Мы проверяем не только список правил, но и новое SSH-соединение, ответ сайта и блокировку отдельного тестового HTTP-порта снаружи.
Если VPS ещё не настроен, начните с подключения по SSH и создания пользователя с sudo. Для практической части используем уже работающий VPS с Ubuntu 24.04 LTS — это позволяет сократить расходы на подготовку уроков.
Какие порты оставить открытыми
Для простого веб-сервера в нашем примере нужны три входящих TCP-порта:
| Порт | Назначение | Когда нужен |
|---|---|---|
22/tcp |
SSH | Если SSH действительно работает на стандартном порту. При другом порте разрешайте его фактическое значение. |
80/tcp |
HTTP | Обычный HTTP, перенаправление на HTTPS и проверка Let's Encrypt HTTP-01. |
443/tcp |
HTTPS | Зашифрованный доступ к сайту. |
Порты базы данных, Redis и служебных панелей не открывают всему интернету только потому, что соответствующее приложение установлено. Сначала определите, кто должен к нему подключаться: процесс на той же машине, соседний сервер в приватной сети или внешний клиент.
Эти три разрешения не подходят автоматически для почтового сервера, VPN, игрового сервера или другой инфраструктуры. Составьте список необходимых служб до включения ограничений. UFW управляет правилами самой ОС; отдельный firewall провайдера и правила контейнерной сети проверяются дополнительно.
Шаг 1. Проверяем текущую конфигурацию
В административной сессии выполните:
sudo ufw status verbose
sudo ss -lntup
printf '%s\n' "$SSH_CONNECTION"
В переменной SSH_CONNECTION обычно четыре поля: адрес клиента, его порт, адрес сервера и серверный порт SSH. Последнее поле помогает проверить порт текущего соединения. Сопоставьте его с слушающими сокетами; при использовании NAT, нестандартного перенаправления или bastion учитывайте и сетевую схему провайдера.
Для первого включения ожидается Status: inactive. Если firewall уже активен, не сбрасывайте его через ufw reset и не копируйте процедуру заново целиком. Сначала сохраните существующие правила, узнайте назначение ограничений и добавляйте только нужные изменения.
Если команда не найдена, пакет устанавливается из репозитория Ubuntu:
sudo apt update
sudo apt install ufw
Список ss показывает программы, которые слушают порты, а не полный ответ на вопрос о внешней доступности. Сервис может слушать 127.0.0.1, быть закрыт firewall или находиться за сетевым экраном провайдера.
Шаг 2. Готовим страховку от потери соединения
Не закрывайте исходный терминал. Убедитесь, что в панели провайдера доступна консоль восстановления. При первом включении из состояния inactive можно также запланировать автоматическое отключение UFW через пять минут:
sudo systemd-run --unit=ufw-rollback --on-active=5m /usr/sbin/ufw disable
sudo systemctl status ufw-rollback.timer --no-pager
Это временный таймер: если вы потеряете доступ, UFW отключится после его срабатывания. Если всё работает, таймер нужно остановить до истечения пяти минут. Для уже настроенного активного firewall такая страховка не подходит: она снимет существующую защиту. В том случае нужен план восстановления именно прежней конфигурации.
Если имя ufw-rollback уже занято, сначала выясните назначение существующей службы и таймера. Не останавливайте незнакомую задачу только ради копирования команды.
Шаг 3. Сначала разрешаем SSH и веб-трафик
В нашем примере SSH слушает порт 22. Подготовьте базовые политики и разрешения:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw show added
deny incoming задаёт политику для входящих соединений, не разрешённых отдельными правилами. allow outgoing сохраняет исходящие обращения сервера: например, загрузку обновлений, DNS-запросы и запросы Certbot к центру сертификации.
Если SSH работает на 2222, замените разрешение 22/tcp на 2222/tcp. Не меняйте сам порт SSH одновременно с первым включением firewall — так проще понять причину возможной ошибки.
Вместо номеров можно использовать существующие профили приложений:
sudo ufw app list
sudo ufw app info OpenSSH
sudo ufw app info 'Nginx Full'
Профиль — набор портов, а не автоматическое определение настроек работающей программы. Например, профиль OpenSSH нельзя слепо использовать для SSH на изменённом порту. Числовые правила в основном примере явно показывают, какой доступ разрешён.
Шаг 4. Включаем UFW
Когда фактический порт SSH и нужные веб-порты уже разрешены:
sudo ufw enable
sudo ufw status verbose
Подтвердите действие в интерактивном запросе. При автоматизации есть вариант ufw --force enable, но он пропускает подтверждение и не исправляет ошибочные правила. Не используйте его до проверки разрешений.
Ожидаемый результат — Status: active, политика deny (incoming) и разрешения необходимых портов. Если IPv6 включён в UFW, будут показаны соответствующие строки (v6). Наличие правил IPv4 не означает, что IPv6 тоже настроен правильно: учитывайте оба стека, если сервер имеет публичные адреса обоих семейств.
Снимок показывает конкретные правила учебного VPS. На вашем сервере их список должен соответствовать его приложениям и фактическому SSH-порту.
Шаг 5. Проверяем новый вход и работу сайта
Откройте второе соединение с компьютера:
ssh deploy@203.0.113.10
Замените IP и имя пользователя своими. При нестандартном порте укажите -p, а если ключ не выбран автоматически — -i. Успешно работающий старый терминал не заменяет эту проверку: уже установленное соединение может сохраниться, хотя новые подключения окажутся заблокированы.
Проверьте сайт со своего компьютера, а не только из самого VPS:
curl -I http://example.com/
curl -I https://example.com/
Здесь example.com нужно заменить своим доменом. Для настроенного перенаправления ожидается ответ 301 или 308 на HTTP и успешный ответ страницы на HTTPS. На нашем стенде после включения UFW сохранились HTTP-перенаправление и HTTPS 200, а новое SSH-соединение прошло успешно.
Дополнительно на учебном VPS проверили отдельный слушающий HTTP-сервис: до включения UFW он отвечал снаружи, а после — перестал отдавать ответ через неразрешённый порт. Это позволяет отличить работающую фильтрацию от ситуации, когда в закрытом порту просто нет программы. Такой тест выполняют на собственном сервере с временной тестовой страницей без чувствительных данных; открывать для него служебные панели или реальные базы данных не нужно.
Когда новый вход и сайт проверены, отмените страховочный таймер:
sudo systemctl stop ufw-rollback.timer
sudo systemctl is-active ufw-rollback.timer
sudo ufw status verbose
Для таймера ожидается inactive, для firewall — active. Если таймер уже успел отключить UFW, проверьте причину потери доступа, вновь подготовьте разрешения и повторите включение с новой страховкой.
Как менять и удалять правила
Просмотреть правила с номерами:
sudo ufw status numbered
Удалять правило по номеру удобно, но после удаления нумерация сдвигается. Перед каждым следующим удалением проверяйте список заново. Никогда не удаляйте последнее рабочее разрешение SSH из единственной административной сессии.
Удалить конкретное ненужное разрешение, например для тестового TCP-порта, можно так:
sudo ufw delete allow 8080/tcp
Команда относится к соответствующему простому правилу. Для более сложного правила с ограничением адреса источника укажите те же параметры либо выберите его по номеру. Если исходное разрешение отсутствует, удалять ничего не нужно.
При смене SSH-порта сначала разрешите новый порт, настройте службу и подтвердите новое соединение. Старое разрешение удаляют только после этого. Для баз данных предпочтительнее локальное или приватное соединение; публичный доступ ограничивают конкретными доверенными адресами.
Почему порт может быть доступен вопреки ожиданиям
Проверьте, что запрос попадает на нужный IP и адресное семейство, а не на другой сервер, CDN или прокси. Посмотрите более ранние разрешающие правила, область их действия и публикацию портов контейнеров.
Docker создаёт собственные правила сети. Опубликованный контейнерный порт при типичной bridge-сети может обходить ожидаемую фильтрацию UFW. Поэтому настройку Docker проверяют отдельно по его документации, а базы и внутренние интерфейсы не публикуют в интернет без необходимости. Не отключайте управление сетевыми правилами Docker наугад: это может нарушить связь контейнеров.
Для Nginx, установленного непосредственно в ОС, используйте обычные правила UFW и проверяйте ответ извне. Установка и конфигурация такого сервера показаны в уроке по Nginx.
Частые ошибки
| Ситуация | Что делать |
|---|---|
| После включения пропал SSH | Дождаться заранее настроенного отката либо использовать консоль провайдера. Проверить фактический порт и правило разрешения. |
| HTTPS работает, а продление сертификата HTTP-01 не проходит | Проверить доступ к порту 80 и ACME-пути. HTTP-01 не выполняется через произвольно выбранный альтернативный порт. |
curl с VPS работает, а с компьютера — нет |
Проверить внешние правила, DNS, firewall провайдера и адрес прослушивания службы. |
| Правило есть, но сервис не открывается | Firewall не запускает программу. Проверить состояние службы и ss -lntup. |
| IPv4 закрыт, а через IPv6 сайт доступен иначе | Проверить публичный IPv6, правила (v6), настройки UFW и правила провайдера для обоих семейств. |
| Порт контейнера доступен несмотря на UFW | Проверить способ публикации и сетевые правила Docker. |
Проверка результата
Настройка закончена, когда UFW активен, новый SSH-вход проходит, необходимые страницы доступны извне, а лишние входящие подключения действительно ограничены. Проверьте, что страховочный таймер остановлен и вы не оставили временный тестовый сервис.
Firewall дополняет обновления, права пользователей, SSH-ключи и резервные копии. Далее можно подключить сертификат и проверить его продление или настроить ежедневное резервное копирование.
Если планируете использовать Docker
При публикации портов Docker создаёт собственные сетевые правила. В уроке по установке Docker и запуску Compose показано, как привязать учебное приложение к 127.0.0.1, проверить доступ и сохранить данные в отдельном томе.
Первоисточники
Сообщите адрес статьи и фрагмент через контакты редакции.

