Блог компании 3v-Hosting
13 мин.
К сожалению настройка файервола - это одна из тех вещей, о которых либо вспоминают слишком поздно либо вообще откладывают на потом. Очень часто бизнес ориентирован исключительно на то, чтобы поскорее запустить свой продукт, сервис или сайт. Поэтому процесс настройки нового сервера выглядит как-то так: подняли VPS, развернули свой сервис, проверили, что сайт открывается и пошли дальше. На этом этапе многим кажется, что вопросами безопасности можно заняться потом, когда появится время. Какая-же это ошибка!
Проблема в том, что каждый сервер с публичным IP начинает сканироваться практически сразу после появления в сети. Тысячи ботов перебирают логины и пароли от SSH, ищут открытые порты, доступные базы данных, проверяют уязвимые сервисы и модули. Причем это не является целевой атакой именно на вас или ваш бизнес - это просто "нормальный" фоновый шум интернета. И если ваш сервер открыт во внешний интернет чуть больше, чем это требуется для его нормальной работы, то он рано или поздно будет скомпрометирован или взломан.
Казалось бы, ещё совсем недавно настройка файервола в Linux была задачей "со звёздочкой", ведь работа напрямую с iptables требовала твёрдого и уверенного понимания принципов работы цепочек правил, таблиц и состояний сетевых соединений. В то-же время ошибка, допущенная всего в каком-то одном правиле могла либо полностью открыть сервер для злоумышленников, либо, наоборот, отрезать к нему доступ всем, включая вас самих. Именно поэтому многие администраторы либо откладывали настройку файервола на потом, "чтобы потом, когда будет свободное время, сесть и хорошенько разобраться", либо банально копировали чужие конфиги, не до конца понимая, что именно они делают и как работают.
Но с появлением UFW ситуация начала меняться в лучшею сторону. По сути, утилита UFW это надстройка над утилитой iptables (или nftables), которая в свою очередь является надстройкой для конфигурирования модуля ядра Netfilter, встроенного системного файервола. Это просто инструмент упрощения, который позволяет вместо десятков правил и цепочек ввести всего несколько понятных команд.
Однажды мы уже писали краткий гайд по UFW. Ну а в этой статье мы хотели бы подробнее познакомиться с этим инструментом, разобраться в том, как установить UFW и настроить с его помощью файервол для защиты вашего сервера от проникновений злоумышленников. Правда всегда стоит помнить, что настройка файервола - это лишь малая часть из целого комплекса мер, которые должны предприниматься, для обеспечения максимальной безопасности вашей инфраструктуры.
Вернёмся к тому, как обычно выглядит задача по настройке нового сервера, а именно подняли VPS, установили нужные пакеты, настроили Nginx или backend, открыли SSH для управления сервером и вроде бы задача закрыта. Кажется, что сервер полностью готов к работе, ведь сервис отвечает, сайт доступен, значит можно переключаться на следующие задачи или пойти попить с коллегами чаю и обсудить вчерашний футбольный матч.
Но есть нюанс, который не очевиден даже многим опытным администраторам. Дело в том, что ваш сервер по умолчанию гораздо более "разговорчивый", чем вам может показаться. И даже если вы не открывали специально никаких дополнительных портов, то всё равно наружу могут быть доступны разные точки входа о которых вы можете даже не догадываться.
Самые банальные примеры могут выглядеть как-то так:
О! Это-же просто рай для взломщиков, это целый набор потенциальных точек входа, которые автоматически проверяются тысячами ботов, после чего проверяются более сложными инструментами.
Именно здесь хорошо проявляется ключевая роль файервола. Он не усиливает безопасность как-то абстрактно, это же не волшебная кнопка "сделай чтоб всё было безопасно". Вместо этого он делает вполне конкретную вещь, а именно - он сводит внешний доступ к серверу к строго необходимому минимуму, открывая только те сервисы, которые должны быть видны и то, только тем, кому это разрешено.
Как мы уже упоминали во введении, UFW не является самостоятельным механизмом фильтрации пакетов, а является всего лишь надстройкой над существующими низкоуровневыми инструментами. Под капотом он использует iptables или nftables, а его основная задача состоит в упрощении взаимодействия с ними, не заставляя вас каждый раз разбираться в цепочках правил, в таблицах и состояниях соединений.
Если говорить проще, то UFW - это высокоуровневый интерфейс к брандмауэру. Вы описываете правила в виде простых и понятных команд, а система уже сама переводит их в корректные низкоуровневые правила, которые применяются на уровне ядра Linux. То есть вся реальная фильтрация происходит там же, где и при ручной настройке iptables, а разница только в том, как вы этим управляете.
И здесь важно развеять одно распространённое заблуждение. Из-за своей простоты UFW иногда воспринимается как облегчённый или даже учебный инструмент. Но на практике это не так. Он не урезает возможности брандмауэра, а лишь скрывает избыточную сложность. Конечно, если вы работаете над сложным инфраструктурным проектом, требующим применения сложных схем фильтрации, тогда вы всегда можете писать правила напрямую в iptables. Но для подавляющего большинства задач возможностей UFW более чем достаточно.
Более того, использование UFW часто делает конфигурацию более предсказуемой и поддерживаемой. Когда правила написаны в простом человекочитаемом формате типа "разрешить это" и "запретить то", то их проще проверять, документировать и передавать другим администраторам. В отличие от длинных цепочек правил в iptables, где без контекста иногда сложно понять, что именно происходит.
На Ubuntu UFW обычно уже установлен в системе, на Debian - его может не быть. В любом случае установка занимает пару секунд и не составляет труда:
sudo apt update sudo apt install ufw
ВАЖНО! Самая частая ошибка, которую допускают неопытные администраторы, заключается в том, что если вы подключены к серверу по SSH и включите UFW, не разрешив до этого SSH, то вы закроете соединение сами для себя.
Поэтому сразу после установки, ДО ВКЛЮЧЕНИЯ, первым делом нужно открыть SSH-порт:
sudo ufw allow OpenSSH
Эта команда добавляет правило, разрешающее доступ по SSH (обычно это порт 22, если используется стандартная конфигурация).
Если у вас используется нестандартный порт (что, кстати, часто делают для снижения шума от брутфорса), его нужно указать явно:
sudo ufw allow 5522/tcp
,где 5522 - это ваш реальный порт SSH. Без этого шага при включении UFW вы просто потеряете доступ к серверу.
Только после этого вы можете смело включать UFW:
sudo ufw enable
Проверить его статус можно командой:
sudo ufw status verbose
Если вы всё сделали правильно, то уже на этом этапе вы получили базовую защиту своего сервера и не потеряли доступ к серверу, а это уже достижение:)
Когда речь заходит о настройке файервола, важно не столько запомнить команды, сколько понять сам подход к защите. UFW строится на очень простой и понятной модели, когда ваш сервер по умолчанию не должен принимать никакие входящие соединения, если вы явно этого не разрешили.
Это ровно тот принцип, который стоит использовать в своей инфраструктуре: не "закрываем лишнее", а "разрешаем только необходимое". И пусть разница кажется небольшой, но с практической точки зрения это два совершенно разных уровня контроля.
В UFW эта логика задаётся буквально двумя командами:
sudo ufw default deny incoming sudo ufw default allow outgoing
Этими командами мы запретили все входящие соединения и разрешили все исходящие, поэтому любое входящее соединение будет отклонено, если вы не добавили для него явное правило. При этом исходящие подключения остаются открытыми, чтобы система могла нормально работать, получать обновления, обращаться к сторонним API, скачивать пакеты и т.д.
Дальше вы уже начинаете осознанно открывать только те сервисы, которые действительно должны быть доступны извне.
Например, базовый набор для веб-сервера, это http и https порты:
sudo ufw allow 80/tcp sudo ufw allow 443/tcp
В примерах выше мы просто открывали нужные нам порты, но в реальной практике простое открытие порта - это лишь половина дела. Правильным подходом является не просто открытие порта, а ограничение доступа к нему.
Например, SSH редко должен быть доступен всему интернету и обычно доступ нужен только с вашего IP. В таком случае мы должны разрешить доступ только для вашего IP:
sudo ufw allow from 192.168.1.100 to any port 22
Также дело обстоит и с базами данных, ведь PostgreSQL или MySQL не должны слушать внешний мир. Их клиент, обычно, это backend или API - вот для них и БД и должна быть доступна.
sudo ufw allow from 10.0.0.5 to any port 5432
Снаружи порт вроде бы и виден, но доступ к нему строго ограничен одним или несколькими IP-адресами. Поэтому для случайных сканеров он фактически оказывается закрытым.
На старте конфигурация файервола зачастую выглядит предельно аккуратно, всего пара правил, всё понятно и прозрачно. Но проходит время, постепенно в систему добавляются новые сервисы, настраиваются какие-то временные доступы, прописываются тестовые настройки, в результате чего список правил начинает разрастаться. В какой-то момент совокупный набор правил перестает быть очевидным, а необходимость внести любые новые изменения вызывают сомнение, не сломается ли что либо из старых правил.
Поэтому, чтобы не доводить дело до состояния, когда файервол становится чёрным ящиком, за ним нужно периодически следить и ухаживать:) UFW даёт для этого отличный простой инструмент - просмотр правил с нумерацией:
sudo ufw status numbered
Вы получите список примерно такого вида:
[ 1] 22/tcp ALLOW IN Anywhere [ 2] 80/tcp ALLOW IN Anywhere
А нумерация здесь не просто для удобства - она напрямую может использоваться для управления правилами, например их удаления. Если правило вам больше не нужно, то его можно легко удалить по номеру:
sudo ufw delete 1
Это кажется банальным, но простая дисциплина вида "добавил правило, проверил, убрал лишнее" - позволяет держать конфигурацию в контролируемом состоянии. А если этим пренебрегать, то уже через несколько месяцев файервол превращается в набор случайных разрешений, где уже сложно понять, что и зачем открыто.
В реальной работе с сервером часто возникает ощущение, что если сервис не отвечает, значит проблема обязательно в коде, конфиге веб-сервера или конкретном контейнере. Вы проверяете Nginx, перезапускаете backend, смотрите логи приложения и всё, вроде-бы выглядит нормально, но соединения по-прежнему не проходят.
И вот здесь часто всплывает простой, но не всегда очевидный факт, что трафик может блокироваться на уровне файервола. Причём без каких-либо явных ошибок в самом приложении.
Поэтому ещё одним шикарным инструментом, который сильно облегчает жизнь системным администраторам является встроенное логирование. Оно позволяет увидеть, какие соединения были отклонены и откуда они приходили. Включается это одной командой:
sudo ufw logging on
После этого все события записываются в стандартный лог:
/var/log/ufw.log
Внутри вы увидите записи о заблокированных пакетах с указанием их IP-адресов, номеров портов и направлением трафика. Это очень сильно облегчает процесс локализации проблем в системе и позволяет быстро обнаружить и устранить проблему.
Особенно это помогает при настройке взаимодействия между несколькими сервисами или микросервисами, работе с Docker или Kubernetes, где часть сетевой логики скрыта, а также при отыскании и устранении "плавающих" сетевых проблем, которые трудно воспроизвести.
На первый взгляд UFW создаёт ощущение полной управляемости, ведь вы задали правила и уверены, что именно они определяют, что доступно снаружи, а что нет. Но в реальной инфраструктуре иногда всё чуть сложнее.
Существует целый класс сервисов, которые работают с файерволом напрямую, минуя UFW. Самые распространённые примеры - это Docker или гипервизоры типа Proxmox. Они управляют iptables самостоятельно, добавляя свои правила для сетей, NAT и проброса портов.
В результате может возникнуть неочевидная на первый взгляд ситуация, когда вы смотрите на UFW правила и видите, что порт закрыт, но по факту сервис всё равно доступен извне. С точки зрения UFW всё запрещено, но на уровне iptables уже есть правило, которое этот доступ разрешает.
Это не является ни ошибкой ни багом - это просто архитектурная особенность. Поэтому, чтобы избежать таких ситуаций, при настройке сервера будет полезным, во первых, понимать, какие из компонентов будущей системы могут управлять файерволом напрямую, а во-вторых, в идеале, проверять работающие правила напрямую на более низких уровнях, например в самом iptables.
Можно ли использовать UFW в продакшене? Да, это нормальный инструмент для большинства VPS и небольших проектов. Если он настроен правильно, то он обеспечивает достаточный уровень безопасности.
Нужно ли закрывать исходящие соединения? Обычно нет, но в высокобезопасных средах это делают, чтобы ограничить утечки данных и нежелательные исходящие соединения, как например Reverse shell.
Выбрать UFW или управлять iptables напрямую? Если вам не нужны сложные сценарии, то работа с UFW быстрее и удобнее. А вот iptables имеет смысл, когда требуется тонкая кастомизация.
Почему порт закрыт, но сервис работает? Скорее всего в вашей системе есть какой-то другой инструмент, который обходит UFW и управляет правилами файервола напрямую. Примерами таких сервисов могут быть Docker, ProxMox и другие.
Как понять, что именно блокирует соединение? В случае, если вы не можете понять, что именно блокирует соединение, рекомендуем включить и посмотреть логи UFW, в которых будет видно, какие пакеты были отклонены и все их параметры.
Нужно ли открывать порт базы данных наружу? Почти никогда этого не стоит делать. Лучше ограничить доступ только внутренними IP или VPN, что нужно учитывать ещё на этапе проектирования системы.
Итак, мы с вами выяснили, что UFW (Uncomplicated Firewall) не является в прямом смысле каким-то упрощенным файерволом, а просто является удобной надстройкой над встроенным файерволом, который в Linux и так уже работает на уровне ядра.
Также мы обсудили главную философию, присущую, правда, не только UFW, что нужно сначала запретить все входящие соединения, а затем разрешить только те, которые необходимы и только для тех IP, которым это доверено.
При этом важно помнить, что UFW может оказаться не единственным элементом системы, имеющим доступ к встроенному файерволу и, например, Docker, Proxmox и другие инструменты могут напрямую работать с iptables, добавляя свои правила и обходя вашу конфигурацию, что может внести неопределенность в работу сервера. Правда если это происходит, значит ваша система уже имеет достаточный уровень сложности и в таком случае вам стоит проверять реальные действующие в системе правила на более низком уровне, например напрямую в iptables.
Важной отличительной способностью UWF является простота поддержки и прозрачность, благодаря простому и интуитивно понятному синтаксису.
В итоге UFW закрывает ключевую задачу, а именно, даёт вам быстрый и понятный контроль над тем, какие сервисы доступны извне, обеспечивая достойный уровень безопасности при минимальных усилиях.
Компания 3v-Hosting получила признание Research.com как лучшее программное обеспечение для резервного копирования благодаря своей проверенной надежности, надежн...
При постоянной работе с линукс серверами очень часто возникает необходимость передать файлы или папки с одного сервера на другой и самым простым способом для эт...
Выбор вида веб хостинга - это ключевая задача для любого, кто собирается создать свой сайт или приложение. Ведь правильный выбор вида вебхостинга и выбор провай...
Что означает ошибка HTTP 500, почему она возникает и как её быстро диагностировать. Практические шаги, примеры и советы для серверов, CMS и приложений.
Как понять, что сайт тормозит из-за CPU, RAM или диска, а не из-за кода? Разбираем признаки, диагностику и реальные кейсы, чтобы быстро найти узкое место и прин...
Proxy и VPN часто путают, но это разные инструменты. Разбираем, как они работают, в чём разница, когда использовать каждый и как правильно применять их в реальн...
