Настройка UFW для защиты сервера и сайта в 2026 году

Я обычно настраиваю UFW сразу после поднятия сервера, ещё до деплоя сайта. И честно говоря, это одна из тех вещей, которые занимают 15 минут, а потом годами экономят нервы, деньги и время. В 2026 году это по-прежнему актуально: атак меньше не стало, сканеры ходят круглосуточно, а открытый SSH на 22-м порту без ограничений — это плохая идея.

Если у вас VPS на Ubuntu 22.04, 24.04 или Debian 12, UFW закрывает базовый периметр очень достойно. Он не заменяет Fail2Ban, 2FA, правильный SSH и нормальный хостинг, но как первый уровень защиты работает отлично. А если нужна не только настройка, но и доработка сайта под задачу, я обычно сразу смотрю связку: сервер, CMS, логины, формы, API и права доступа. Кстати, на webfull.ru есть отдельная доработка сайта, если нужно не просто «поставить firewall», а собрать нормальную схему безопасности целиком.

Что такое UFW и зачем он нужен в 2026 году

UFW — это Uncomplicated Firewall, то есть упрощённая оболочка над iptables/nftables. На деле это удобный способ быстро описать правила доступа к серверу без плясок с длинными цепочками и сложным синтаксисом. Я часто вижу, как серверы вообще живут без firewall: открыт SSH, открыт Nginx, открыт MySQL наружу, а потом владелец удивляется, почему в логах крутятся попытки брутфорса из десятков стран.

Для сайта UFW полезен не только как защита SSH. Он позволяет ограничить доступ к панели администрирования, к базам, к Redis, к нестандартным портам приложений и к промежуточным сервисам. Особенно это заметно на проектах с Laravel, WordPress и Bitrix, где в одном VPS может жить сайт, cron, queue worker, SMTP-агент и ещё пара сервисов. На практике одна ошибка в открытом порте — и вся схема становится дырявой.

Если говорить грубо, UFW нужен для ответа на простой вопрос: «кому и откуда вообще можно стучаться на сервер». И это уже половина нормальной защиты. Особенно если у вас есть отдельный план защиты сайта от взлома, а не хаотичный набор плагинов и надежда на авось.

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

Самая частая ошибка — включить UFW на живом сервере без подготовки и отрезать себе SSH. У меня был случай: клиент на Ubuntu 24.04 решил «просто включить firewall», не добавив правило для своего IP и не проверив второй SSH-сеанс. Итог предсказуемый — потеряли доступ на 40 минут, пока шли через консоль провайдера. Ничего критичного, но нервов было много. Так делать не надо.

Сначала проверьте, какие порты реально нужны. Для типичного сайта на Nginx это обычно:

• 22/tcp — SSH, но лучше ограничить по IP;
• 80/tcp — HTTP, если нужен редирект на HTTPS;
• 443/tcp — HTTPS;
• иногда 3306/tcp — MySQL, но только локально или по VPN, а не в интернет;
• 8080/8443 — если есть панель или proxy backend, но это нужно закрывать особенно аккуратно.

Если у вас WordPress, Bitrix или Laravel, я бы ещё заранее посмотрел, как организованы очереди, CRON и админка. Для WordPress полезно свериться со статьёй защита wp-admin, а для общего сервера — с материалом настройка SSH-ключей для сервера. И да, SSH-ключи в 2026 году — это уже не рекомендация, а база.

Установка и базовая настройка UFW

На Ubuntu UFW обычно уже есть в репозитории. На Debian 12 он тоже ставится без проблем. Я обычно ставлю его так:

sudo apt update
sudo apt install ufw -y

После установки сначала смотрим статус, а не сразу рубим всё подряд. Это банально, но помогает не наделать глупостей:

sudo ufw status verbose

Если firewall выключен, начинаем с политики по умолчанию. Для сервера сайта логика простая: входящие запрещаем, исходящие оставляем разрешёнными. На деле это нормальный старт почти для любого веб-проекта.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Дальше добавляем правила. Вот минимальный безопасный набор для веб-сервера:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Если SSH нужен всем из офиса — лучше не делать так. Однозначно стоит ограничить доступ по IP. Например, если ваш внешний адрес статический:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

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

Когда правила готовы, включаем UFW:

sudo ufw enable

Потом обязательно проверяем:

sudo ufw status numbered

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

Безопасный SSH и запрет лишних портов

SSH — это первая цель для перебора. На сервере без ограничения по IP в логи можно смотреть как в сериал. Боты долбят 22-й порт, а потом ещё 2222, 22022, 8022 и любые другие варианты. UFW тут помогает, но я всегда усиливаю это связкой: ключи, смена порта при необходимости, отключение root-login, Fail2Ban и 2FA. Про 2FA для панели и сервера у меня есть отдельный материал — настройка 2FA для сервера. И это не лишнее.

Если вы не готовы менять порт SSH, не беда. Честно говоря, сам по себе перенос SSH с 22 на 2222 уже давно не даёт чудес. Он снижает шум в логах, но не является защитой. Настоящая защита — ограничение по IP и вход по ключам. UFW в этой схеме просто закрывает дверь для всех чужих адресов.

Для сервера с несколькими администраторами я обычно делаю отдельные правила по IP. Например:

sudo ufw allow from 198.51.100.24 to any port 22 proto tcp
sudo ufw allow from 198.51.100.25 to any port 22 proto tcp

Если сервер используется для staging или тестов, лучше вообще не светить SSH в интернет без необходимости. Можно пускать только через VPN или bastion host. На проектах с Laravel и контейнерами Docker это особенно удобно: наружу торчит только 80/443, а внутренняя кухня живёт в закрытом сегменте. Кстати, если у вас тестовый контур, посмотрите статью как настроить staging-сайт — там хорошо сочетаются и UFW, и ограничение доступов.

UFW для Nginx, PHP-FPM, Bitrix, WordPress и Laravel

Если у вас обычный сайт на Nginx + PHP-FPM, UFW нужен в первую очередь для внешних портов. Сам PHP-FPM вообще не должен смотреть в интернет. На моей практике это одна из частых ошибок у начинающих админов: открывают 9000 порт «для проверки», а потом забывают его закрыть. В результате локальный backend становится доступен извне, и это уже очень плохая идея.

Схема простая: Nginx слушает 80 и 443, PHP-FPM общается только по localhost или unix-socket, MySQL слушает только 127.0.0.1 или внутреннюю сеть, Redis — вообще лучше без публичного доступа. Для WordPress и Bitrix это особенно актуально, потому что многие атаки идут не в сам сайт, а в сервисы вокруг него. Если нужна серверная доработка, где надо закрыть лишнее и одновременно ничего не сломать, я обычно советую доработать под задачу через нормальный аудит, а не точечные «починим один порт».

Вот пример, как я обычно думаю о правилах для типового веб-сервера:

• 80/443 — доступны всем;
• 22 — только с IP администратора или из VPN;
• 3306 — закрыт извне;
• 6379 — закрыт извне;
• 9000, 8080, 3000, 5173 — открываются только если есть реальная необходимость, и то лучше локально или через reverse proxy.

Если сайт работает через обратный прокси, полезно почитать настройку обратного прокси Nginx. Там UFW и Nginx должны быть согласованы: если наружу нужен только 443, значит всё остальное должно быть закрыто. Иначе прокси есть, а поверхность атаки всё равно широкая.

Пример типовой конфигурации для Nginx и UFW на сервере с Laravel-проектом может выглядеть так: наружу открыт только веб-трафик, а админские сервисы доступны через внутреннюю сеть или туннель. Если у вас PHP 8.2 или 8.3, это никак не меняет логику firewall — но меняет качество стека в целом. Я часто вижу связку Ubuntu 24.04 + PHP 8.3 + MySQL 8.0, и там главное — не забыть про закрытие портов после настройки очередей, Horizon, Redis и backup-агентов.

Advanced-правила для почты, баз данных и админки

Вот здесь люди чаще всего ошибаются. Потому что UFW легко настроить для сайта, но забыть про дополнительные сервисы. У одного клиента был сервер с WordPress, MySQL 8.0 и Redis. Сайт работал быстро, PageSpeed по desktop был 92, а вот порт MySQL торчал наружу. Формально ничего не сломано, но с точки зрения безопасности это почти приглашение для проблем.

Я обычно рекомендую такую логику: база данных не должна быть доступна из интернета вообще. Исключение — очень редкие случаи, когда вы строите распределённую архитектуру с несколькими внутренними хостами. Но даже тогда доступ надо ограничивать по IP, а ещё лучше — по VPN. То же самое касается Redis, Memcached, Elasticsearch и админских панелей.

Пример: если MySQL нужен только локально, то в конфиге сервера он должен слушать loopback, а UFW выступает как дополнительный барьер. Проверить это можно и на уровне сети. А если доступ к базе нужен разработчику, лучше использовать отдельный туннель:

ssh -L 3307:127.0.0.1:3306 user@server

После этого MySQL доступен локально на вашей машине через 3307, а наружу порт вообще не торчит. На деле это гораздо безопаснее, чем открывать 3306 всему миру и потом чистить логи.

Если у вас Bitrix, обратите внимание на настройку кеширования в Битрикс и настройку Redis для сайта. Когда кеш и очередь вынесены правильно, сервер не раздувается по портам. А если у вас корпоративная почта, обязательно сверяйте доступы с материалом настройка почты для сайта. Почтовые сервисы любят приносить с собой дополнительную сетевую путаницу.

Проверка, отладка и частые ошибки

После настройки UFW я всегда делаю короткую проверку. Не доверяю ни себе, ни автоматике, пока не посмотрю, что реально открыто. Минимальный чек такой: статус firewall, список портов, вход по SSH, доступ к сайту по HTTPS и отсутствие неожиданных наружных сервисов.

Проверить открытые порты на самом сервере можно так:

sudo ss -tulpn

Если хотите увидеть только то, что разрешил UFW, смотрите:

sudo ufw status numbered
sudo ufw show added

А если сервер ведёт себя странно, я часто сначала смотрю не код сайта, а связку firewall + логи + nginx error log. Кстати, у меня есть полезная статья про логи сайта — без неё отладка на VPS превращается в угадайку. И ещё пригодится материал как исправить 502 Bad Gateway, потому что после жёсткой настройки firewall часть ошибок как раз и маскируется под 502/504.

Типовые ошибки, которые я встречаю чаще всего:

• забыли открыть 443/tcp и сайт не работает по HTTPS;
• открыли SSH, но только с одного IP и забыли, что адрес у провайдера динамический;
• открыли MySQL наружу и потом удивились странным подключениям в логах;
• включили UFW, но не проверили правила после рестарта;
• настроили firewall, но оставили доступ к панели управления CMS без ограничений.

Если что-то пошло не так, не надо паниковать. У большинства VPS-провайдеров есть web-console или rescue-mode. И да, это ещё один аргумент не заниматься настройкой в одиночку на боевом сервере, если вы не уверены в каждом шаге. Иногда настройка силами специалиста выходит дешевле, чем потом восстанавливать доступ и вылавливать последствия.

UFW и дополнительная защита сайта в 2026 году

UFW — это только слой сети. Но в 2026 году нормально защищённый сервер — это всегда набор мер. Я обычно собираю такую связку: UFW, SSH-ключи, Fail2Ban, 2FA, актуальный PHP, закрытые админки, мониторинг и резервные копии. Если убрать хотя бы один элемент, конструкция уже не выглядит надёжной.

Например, UFW отлично дополняет Fail2Ban. Firewall режет доступ на уровне сети, а Fail2Ban банит слишком активные IP по логам. Вместе они намного эффективнее, чем по отдельности. Плюс я почти всегда подключаю мониторинг: если сервер перестал отвечать, мне нужен сигнал, а не сюрприз через сутки. Тут очень к месту статья про критические уведомления и материал про uptime-мониторинг.

Ещё одна вещь, которую многие недооценивают, — резервные копии. UFW не спасает от кривого обновления, удаления базы или сбоя диска. Поэтому у меня на серверах клиентов почти всегда есть бэкапы и инкрементальные копии. Если хотите собрать более надёжную схему, посмотрите бэкапы сайта: как делать правильно и инкрементальные резервные копии. Без этого безопасность неполная.

Примеры команд и конфигурации для частых сценариев

Ниже дам несколько рабочих примеров, которые я сам использую или адаптирую под конкретный проект. Они не универсальны на 100%, но как база подходят отлично.

Сценарий 1: обычный сайт на Nginx

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Сценарий 2: сервер с Laravel и закрытым Redis

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw deny 6379/tcp
sudo ufw deny 3306/tcp
sudo ufw enable

Сценарий 3: доступ к MySQL только из внутренней сети

sudo ufw allow from 10.0.0.0/24 to any port 3306 proto tcp
sudo ufw deny 3306/tcp

Я отдельно отмечу: порядок правил важен. Если сначала разрешить слишком широкий доступ, а потом пытаться его перекрыть, легко запутаться. Поэтому я обычно начинаю с deny incoming и потом добавляю только то, что действительно нужно.

Если нужен ещё и контроль доступов на уровне сайта, то UFW — это лишь фундамент. Дальше идут ограничения по IP, логины по 2FA, защита админки, rate limiting, headers и аудит контента. В некоторых проектах я вообще сначала делаю проверку сайта, а уже потом сажусь за firewall. Это помогает увидеть реальные сервисы, не трогать лишнее и не сломать работающий проект.

Как я бы строил безопасную схему в 2026 году

Если коротко, я бы делал так: сервер на Ubuntu 24.04, SSH только по ключам, UFW с deny incoming, разрешённые 80/443, SSH только с IP администратора или через VPN, MySQL и Redis закрыты наружу, Fail2Ban включён, 2FA на панели и доступах, бэкапы есть, мониторинг тоже. И уже сверху — защита сайта, а не наоборот.

Для WordPress я бы ещё закрыл wp-login.php и ограничил wp-admin, а для Bitrix проверил бы, нет ли лишних открытых сервисов после интеграций, cron и обменов с CRM. Для Laravel я бы посмотрел очереди, Horizon, webhooks и админские endpoint’ы. На больших проектах часто всплывают неожиданные вещи — например, отдельная админка на поддомене или старый тестовый порт, который забыли удалить после разработки.

Если вы хотите не просто поставить firewall, а собрать систему защиты под конкретный проект, я бы начал с аудита. На webfull.ru для этого есть и проверка сайта, и услуги по доработке сайта, и техническая поддержка. Честно говоря, на боевом проекте это часто разумнее, чем пытаться закрыть всё вручную в 2 часа ночи.

И последнее. UFW — это не «поставил и забыл» в буквальном смысле. Раз в несколько месяцев я пересматриваю правила, потому что меняются IP, появляются новые сервисы, а старые порты надо убирать без сожалений. Без этого firewall превращается в склад старых исключений. А склад исключений — это уже не защита, а технический долг, только на сетевом уровне.