Порты — это «двери» сервера: через 22-й заходят по SSH, через 80-й и 443-й открывается сайт, через 3306-й общается база данных. По умолчанию лишние двери должны быть закрыты, а нужные — открыты. В Ubuntu этим управляет файрвол ufw (Uncomplicated Firewall) — «несложный файрвол», и он правда несложный: весь гайд сводится к пяти командам.
Что понадобится
- Сервер с Ubuntu — подойдёт любой VPS из каталога, ufw предустановлен во всех современных версиях;
- Доступ по SSH с правами root или sudo;
- 5 минут времени.
Шаг 1. Проверяем состояние файрвола
sudo ufw status verbose
Три возможных ответа: Status: active — файрвол работает, ниже список правил; Status: inactive — выключен (все порты фактически открыты настежь); command not found — редкий случай, ставится командой sudo apt install ufw.
Шаг 2. ⚠️ Сначала разрешаем SSH — потом всё остальное
Главная ошибка новичка: включить файрвол, не разрешив SSH — и мгновенно потерять доступ к серверу. Поэтому первое правило всегда такое:
sudo ufw allow 22/tcp
Если меняли стандартный порт SSH — укажите свой. Только после этого можно включать файрвол:
sudo ufw enable
Система переспросит про разрыв соединений — отвечайте y: правило для SSH уже есть, сессия не оборвётся.
Шаг 3. Открываем нужные порты
Синтаксис одинаковый: sudo ufw allow НОМЕР/протокол. Типовой набор:
sudo ufw allow 80/tcpиsudo ufw allow 443/tcp— сайт по HTTP и HTTPS (443-й нужен и Telegram-боту на вебхуках);sudo ufw allow 8080/tcp— тестовое веб-приложение;sudo ufw allow from 203.0.113.5 to any port 3306— доступ к MySQL только с конкретного IP. Базы данных наружу целиком не открывают — это правило-исключение вместо «двери нараспашку».
После каждой команды ufw отвечает Rule added — правило работает сразу, перезагрузка не нужна.
Шаг 4. Закрываем лишнее
Посмотрите правила с номерами и удалите ненужное:
sudo ufw status numberedsudo ufw delete 3
Или по имени правила: sudo ufw deny 8080/tcp — порт закрыт.
Как проверить, что порт реально открыт
Изнутри сервера: ss -tlnp — покажет, какие порты слушают программы. Важный нюанс: ufw открывает дверь, но за ней должен кто-то стоять — если на порту 8080 ничего не запущено, снаружи он всё равно будет выглядеть закрытым. Снаружи проверяют так: nc -zv IP_сервера 8080 с домашнего компьютера.
Частые ошибки
Включил ufw и потерял SSH-доступ. Подключитесь через консоль VNC/KVM в панели провайдера (она работает «мимо» сети) и выполните sudo ufw allow 22/tcp. На будущее — правило SSH всегда первое.
Порт открыт, но сервис недоступен. Проверьте, что приложение слушает не только localhost: в выводе ss -tlnp должно быть 0.0.0.0:8080, а не 127.0.0.1:8080. Это настройка самого приложения, не файрвола.
Правила «не работают» на VPS. У части провайдеров есть внешний файрвол в панели управления — правила нужно продублировать и там. Если берёте недорогой VPS, уточните в карточке, есть ли внешний файрвол.
Готовые наборы правил под типовые сценарии
Веб-сервер (сайт + SSH):
sudo ufw allow 22/tcp && sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw enable
Сервер только для себя (бот, парсер, VPN): достаточно одного SSH — всё входящее закрыто, исходящие соединения бота работают как обычно, для них входящие порты не нужны. Это частая путаница: чтобы скрипт ходил в интернет, открывать ничего не надо.
Приложение + база на двух серверах: на сервере базы открываем 3306 только для IP приложения: sudo ufw allow from 10.0.0.2 to any port 3306 — и никакого MySQL наружу.
Логи: смотрим, кто стучится в закрытые двери
Включите журнал: sudo ufw logging on — заблокированные попытки начнут писаться в /var/log/ufw.log. Посмотреть последние: sudo tail -20 /var/log/ufw.log. В каждой строке: [UFW BLOCK], SRC= (кто стучался) и DPT= (в какой порт). Не пугайтесь количества — боты сканируют весь интернет круглосуточно, сотни блокировок в день это норма и признак того, что файрвол работает. Если один и тот же IP долбит SSH — забаньте его совсем: sudo ufw deny from 203.0.113.66, а лучше поставьте fail2ban, который делает это автоматически.
Docker и ufw: почему контейнер игнорирует файрвол
Неприятный сюрприз, о котором молчат базовые гайды: Docker пишет свои правила напрямую в iptables в обход ufw. Запустили контейнер с -p 8080:80 — порт 8080 открыт всему интернету, даже если ufw его «запрещает». Что делать: пробрасывать порты только на локальный адрес — docker run -p 127.0.0.1:8080:80, а наружу отдавать через nginx; либо для внутренних сервисов использовать docker-сети без публикации портов вообще. Проверить, что торчит наружу после Docker: ss -tlnp — смотрите, какие порты слушают 0.0.0.0.
Профили приложений и диапазоны портов
У ufw есть готовые профили — их регистрируют устанавливаемые пакеты. Посмотреть список: sudo ufw app list. Вместо номеров можно писать по-человечески:
sudo ufw allow 'Nginx Full' — откроет сразу 80 и 443;sudo ufw allow 'OpenSSH' — 22-й порт.
Диапазон портов открывается через двоеточие с обязательным протоколом: sudo ufw allow 60000:61000/udp — так, например, работает mosh (SSH для нестабильного интернета). А посмотреть текущие правила «как есть» в формате конфига можно в файлах /etc/ufw/user.rules — иногда быстрее, чем разбирать вывод status.
Сброс и откат: если запутались в правилах
Команда sudo ufw reset стирает все правила и выключает файрвол — чистый лист. После неё обязательно начните заново с разрешения SSH. Точечный откат удобнее делать по номерам: sudo ufw status numbered → sudo ufw delete N. И помните: правила ufw переживают перезагрузку сервера — «само сбросится» не сработает ни в плохую, ни в хорошую сторону.
Частые вопросы
Чем ufw отличается от iptables?
ufw — дружелюбная обёртка над iptables/nftables: те же правила, но человеческим языком. Для 95% задач ufw достаточно; iptables напрямую нужен для сложной маршрутизации.
Какие порты должны быть открыты на веб-сервере?
Минимум: 22 (SSH), 80 (HTTP), 443 (HTTPS). Всё остальное — по потребности и лучше с ограничением по IP.
Опасно ли держать порты открытыми?
Опасен не открытый порт, а уязвимый сервис за ним. Правило простое: открыто только то, что используется, софт обновлён, пароли сложные. От сетевого флуда защищает DDoS-фильтрация провайдера.
Как разрешить ping до сервера?
ICMP-запросы ufw по умолчанию пропускает, так что ping работает из коробки. Если сервер не пингуется — смотрите внешний файрвол в панели провайдера или настройки ядра, а не ufw. Кстати, «не пингуется» ещё не значит «не работает»: часть провайдеров сознательно режет ICMP для защиты от сканирования.
ufw или облачный файрвол провайдера — что использовать?
Оба сразу — это два рубежа обороны. Внешний файрвол отсекает трафик ещё до сервера (экономит ресурсы и спасает при атаках), ufw страхует, если правило в панели забыли или настроили неточно. Главное — держите правила синхронными, иначе будете долго искать, «кто из двоих» блокирует нужный порт.
Может ли открытый порт «съедать» ресурсы?
Сам по себе — нет: порт это просто разрешение принимать соединения. Ресурсы ест сервис за портом и попытки перебора. Поэтому смысл минимализма не в экономии, а в сокращении поверхности атаки: чем меньше открытых дверей, тем меньше нужно защищать.
Шпаргалка: все команды из гайда
| Действие | Команда |
|---|---|
| Статус и правила | sudo ufw status verbose |
| Разрешить порт | sudo ufw allow 443/tcp |
| Разрешить только с IP | sudo ufw allow from 1.2.3.4 to any port 3306 |
| Запретить порт | sudo ufw deny 8080/tcp |
| Забанить IP | sudo ufw deny from 1.2.3.4 |
| Удалить правило | sudo ufw status numbered → sudo ufw delete N |
| Включить / выключить | sudo ufw enable / sudo ufw disable |
| Сбросить всё | sudo ufw reset |
| Кто слушает порты | ss -tlnp |
| Логи блокировок | sudo tail -f /var/log/ufw.log |
Финальная проверка: посмотрите на сервер глазами атакующего
Настроили правила — проверьте результат снаружи, как это сделал бы сканер. С домашнего компьютера (не с самого сервера!):
nmap -F IP_сервера
Утилита переберёт сотню типовых портов и покажет три состояния: open — порт открыт и за ним живёт сервис, closed — файрвол пропускает, но никто не слушает, filtered — файрвол молча отбрасывает пакеты (это и есть работа ufw). В идеальной картине open — только у портов из вашего списка, всё остальное filtered. Увидели неожиданный open — вернитесь к ss -tlnp на сервере и выясните, что за программа его заняла: часто это забытая тестовая служба или тот самый Docker-контейнер. Такой аудит стоит повторять после установки любого нового софта — многие пакеты открывают порты «услужливо» и молча.
Итог
Вся практика: ufw allow 22/tcp → ufw enable → ufw allow для нужных портов → ufw status для контроля. Если сервера ещё нет — выбирайте в рейтинге VPS: на любом тарифе с Ubuntu этот гайд отработает без изменений.
