Ubuntu 24.04: настройка фаервола с нуля

MAATRIX

Свежий сервер в интернете за первые часы получает сотни попыток подключиться к его портам. Настройка фаервола на Ubuntu 24.04 с нуля — это первый рубеж обороны: вы решаете, какие двери в систему открыты, а какие наглухо закрыты. В Ubuntu для этого есть UFW — удобная надстройка над мощным, но громоздким iptables. Разберём по шагам, как задать безопасные правила по умолчанию, открыть только нужные порты и прикрыть SSH от автоматического перебора.

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

UFW (Uncomplicated Firewall) — это упрощённый интерфейс к межсетевому экрану ядра Linux. Под капотом всё равно работает netfilter/iptables, но вместо длинных и неочевидных команд вы пишете короткие и читаемые: «разрешить порт», «запретить порт». Для администратора без глубокого опыта это огромная экономия времени и защита от ошибок, которые в «сыром» iptables допустить очень легко.

Зачем вообще фаервол, если можно просто не запускать лишние службы? Затем, что вы не всегда знаете, что именно слушает порты. Пакеты приносят с собой сервисы, которые могут открыться наружу без вашего ведома. Фаервол ставит жёсткую границу: даже если служба запустилась и слушает порт, снаружи к ней не пробьются, пока вы явно не разрешите. Это и есть принцип минимальной поверхности атаки — открыто только то, что осознанно нужно.

Полезно заранее понимать разницу между входящим и исходящим трафиком, потому что путаница здесь — источник большинства ошибок новичков. Входящие соединения инициирует кто-то снаружи, стучась в порты вашего сервера, — именно их мы жёстко ограничиваем. Исходящие инициирует сам сервер, когда идёт за обновлениями, скачивает пакеты или обращается к API, — их мы обычно оставляем открытыми, иначе сервер не сможет нормально работать. Поэтому базовая политика асимметрична: входящее по умолчанию запрещаем, исходящее разрешаем. Держа это различие в голове, вы не запутаетесь, какое правило под какую ситуацию писать, и не отрежете серверу выход в сеть по ошибке.

Проверяем исходное состояние

Прежде чем менять правила, посмотрите, включён ли UFW сейчас:

sudo ufw status verbose

На свежем сервере он обычно неактивен (inactive). Это значит, что все порты открыты и защиты нет — именно это мы и исправим. Важно не спешить с командой включения: если сначала включить фаервол с политикой «запретить всё», не разрешив предварительно SSH, вы мгновенно потеряете доступ к серверу. Поэтому порядок шагов критичен, и мы соблюдаем его строго: сначала правила, потом включение.

Задаём политику по умолчанию

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

sudo ufw default deny incoming
sudo ufw default allow outgoing

Эти две команды задают фундамент всей политики. «Запрещено входящее» означает, что любое новое подключение снаружи по умолчанию отбрасывается. Дальше мы точечно проделываем нужные «окна». Такой подход надёжнее обратного, где вы открываете всё и пытаетесь запретить лишнее: перечислить всё опасное невозможно, а вот перечислить немногое нужное — легко.

Открываем нужные порты

Первым делом разрешите SSH, иначе следующий шаг отрежет вам доступ:

sudo ufw allow OpenSSH

OpenSSH — это готовый профиль приложения, который открывает стандартный порт 22. Если вы перенесли SSH на нестандартный порт, откройте его явно, например sudo ufw allow 2222/tcp. Для веб-сервера добавьте порты HTTP и HTTPS:

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

Посмотреть список готовых профилей приложений можно командой sudo ufw app list — там будут Nginx, Apache, OpenSSH и другие установленные сервисы. Использовать профили удобнее, чем помнить номера портов: sudo ufw allow 'Nginx Full' откроет и 80, и 443 разом. Открывайте только то, что реально используете прямо сейчас.

Отдельного упоминания заслуживает открытие портов только для доверенных адресов. Если, например, база данных должна быть доступна лишь с одного вашего офисного IP, не открывайте её порт всему миру — ограничьте правилом с указанием источника: sudo ufw allow from 203.0.113.10 to any port 3306. Тогда к базе сможет подключиться только этот адрес, а для всех остальных порт останется закрытым. Это гораздо безопаснее, чем открывать служебные порты (базы данных, панелей администрирования, отладочных интерфейсов) наружу целиком. Общее правило простое: чем уже область действия разрешения, тем меньше риск. Публично открытыми стоит держать только те порты, которые действительно должны принимать соединения от кого угодно, — обычно это лишь веб и SSH.

Защищаем SSH от перебора

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

sudo ufw limit OpenSSH

Эта команда заменяет обычное разрешение для SSH на «разрешить с ограничением частоты». Она резко снижает эффективность перебора, не мешая вам самим заходить на сервер. Для более серьёзной защиты дополните её пакетом fail2ban, который банит адреса после нескольких неудачных попыток входа — но ufw limit уже даёт заметный эффект малой кровью и включается одной строкой.

Включаем фаервол и проверяем

Когда правила заданы, включайте фаервол:

sudo ufw enable

Система предупредит, что операция может разорвать текущие SSH-соединения, — но раз вы уже разрешили SSH, соединение сохранится. Сразу после включения проверьте итоговую картину:

sudo ufw status verbose

В списке должны быть только осознанно открытые порты. Всё остальное закрыто. Если видите лишнее правило, удалите его командой sudo ufw delete allow <порт>. Полезно также убедиться, что фаервол поднимается автоматически после перезагрузки — UFW делает это по умолчанию, но проверить не помешает командой systemctl status ufw.

Логи и обслуживание правил

Чтобы видеть попытки достучаться до закрытых портов, включите логирование:

sudo ufw logging on

Логи пишутся в /var/log/ufw.log, и по ним видно, кто и куда стучался. Не увлекайтесь уровнем high на нагруженном сервере — он раздувает логи. Со временем правила стоит пересматривать: закрыли проект — уберите его порт, добавили сервис — откройте только его. Хорошая привычка — раз в пару месяцев смотреть ufw status и спрашивать себя, нужен ли ещё каждый открытый порт. Фаервол, за которым следят, остаётся тонкой и предсказуемой границей, а не свалкой забытых разрешений.

Частые вопросы