- Что такое firewall и зачем он нужен
- Уровни защиты сети: сервер и облачная инфраструктура
- Основные принципы работы firewall
- Типичные ошибки при настройке firewall
- Практические рекомендации по безопасности серверов
- Итоги
Утечки данных и DDoS‑атаки могут нанести бизнесу не только финансовый, но и репутационный ущерб. Один из самых эффективных способов снизить эти риски – грамотно настроить firewall на всех уровнях инфраструктуры.
Что такое firewall и зачем он нужен
Firewall – это система фильтрации сетевого трафика. Он проверяет подключения по заданным правилам и решает, пропускать их, блокировать или отклонять. В правилах можно учитывать IP-адрес, порт, протокол и направление трафика.
Firewall нужен, чтобы ограничить доступ к серверу и оставить открытыми только необходимые сервисы. Например, для сайта обычно доступны порты 80/tcp и 443/tcp, а SSH-подключение лучше разрешать только с доверенных IP или через VPN.
С помощью firewall можно:
- закрыть ненужные порты;
- защитить административные интерфейсы;
- ограничить доступ к базам данных и внутренним сервисам;
- снизить количество автоматических атак и сканирований;
- разделить публичные и приватные зоны инфраструктуры.
Firewall не заменяет обновления, безопасные пароли, SSH-ключи и мониторинг, но помогает уменьшить площадь атаки.
Уровни защиты сети: сервер и облачная инфраструктура
Чтобы трафик фильтровался до попадания на машину и дополнительно контролировался внутри операционной системы, нужно настроить его на уровне облака и самого сервера.
Облачный firewall работает на стороне провайдера. Правила применяются до того, как трафик попадет на сервер. Он подойдет для грубой фильтрации, когда нужно разрешить HTTP/HTTPS, ограничить SSH, закрыть доступ к базе данных или настроить правила для группы серверов.
Серверный firewall работает внутри операционной системы. В Linux для этого используются iptables, nftables, firewalld, ufw и другие инструменты. Он позволяет точнее управлять правилами, учитывать локальные интерфейсы, контейнеры, VPN, Docker-сети и внутренние сервисы.
Лучше использовать оба уровня. Облачный firewall уменьшает количество лишнего трафика на входе, а серверный остается дополнительной защитой на случай ошибки в облачных правилах или изменения инфраструктуры.
Основные принципы работы firewall
Firewall проверяет сетевой трафик по заданным правилам и решает, что с ним делать: разрешить, заблокировать, отклонить или записать событие в журнал. Правила могут учитывать IP-адрес, порт, протокол, сетевой интерфейс и состояние соединения.
Главный принцип настройки – разрешать только необходимое. Например, для веб-сервера обычно открывают порты 80 и 443, а SSH-доступ ограничивают по IP или VPN. Все остальное лучше блокировать политикой по умолчанию.
Firewall работает с разными типами трафика:
| Тип трафика | Что означает |
| Входящий | Подключения к серверу извне |
| Исходящий | Подключения с сервера к внешним ресурсам |
| Транзитный | Трафик, который проходит через сервер дальше |
Важен и порядок правил: firewall обрабатывает их последовательно или по приоритету. Поэтому сначала задают точные разрешения, а затем общее ограничение для всего лишнего трафика.
На практике безопасная схема выглядит так: открыть только нужные сервисы, ограничить административный доступ, учитывать IPv4 и IPv6, а все неиспользуемые порты держать закрытыми.
iptables и nftables в Linux
В Linux долгое время основным инструментом фильтрации был iptables. Он до сих пор используется во многих системах, инструкциях и готовых скриптах. С его помощью можно управлять цепочками правил, фильтровать трафик по портам, IP-адресам, протоколам и состоянию соединения.
Пример правила iptables для разрешения SSH:
Более современная альтернатива – nftables. Он пришел на замену iptables и предлагает единый синтаксис, лучшую производительность и удобную работу с наборами адресов, таблицами и цепочками.
Пример правила nftables:
В новых версиях Linux часто предпочтительнее nftables, но iptables все еще очень часто встречается.
Настройка firewall на уровне сервера
Firewall на уровне сервера настраивается внутри операционной системы и контролирует трафик, который уже дошел до машины. В Linux для этого чаще используют iptables, nftables, ufw или firewalld.
Перед настройкой проверьте, какие порты действительно нужны. Например, веб-серверу обычно достаточно открыть HTTP/HTTPS, а SSH лучше разрешить только с доверенного IP.
Базовый вариант настройки через ufw:
ufw default allow outgoing
ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
В этом примере входящие подключения по умолчанию запрещены, исходящие разрешены, SSH открыт только для IP 203.0.113.10, а порты 80 и 443 доступны для сайта.
После настройки проверьте активные правила:
Также посмотрите, какие сервисы слушают порты:
Не открывайте порты «на всякий случай». Доступ к базам данных, административным панелям, Redis, Elasticsearch и другим внутренним сервисам ограничьте приватной сетью, VPN или списком доверенных IP.
Firewall в облачной инфраструктуре
Firewall в облачной инфраструктуре настраивается на стороне провайдера и фильтрует трафик еще до того, как он попадет на сервер. В разных облаках он может называться Cloud Firewall, Security Groups, Network Firewall или правилами доступа.
Обычно облачный firewall используют, чтобы быстро ограничить доступ к виртуальным машинам, базам данных, балансировщикам и внутренним сервисам. Например, можно открыть HTTP и HTTPS для всех пользователей, а SSH разрешить только с доверенного IP.
Типовой набор правил для веб-сервера:
- разрешить TCP 80 для всех;
- разрешить TCP 443 для всех;
- разрешить TCP 22 только с IP администратора;
- запретить доступ к портам баз данных из интернета;
- разрешить внутренний трафик только между нужными серверами.
Используйте разные группы правил для разных ролей серверов. Для фронтенд-серверов можно открыть публичный веб-трафик, бэкэнд-серверы лучше оставить доступными только из внутренней сети, а базы данных – только для бэкэнд-уровня.
Проверьте, чтобы правила в облачном firewall не конфликтовали с настройками на самом сервере. Оптимально использовать оба уровня защиты: облачный firewall отсекает лишний трафик до сервера, а серверный дополнительно контролирует доступ внутри операционной системы.
В отличие от обычного хостинга, VDS дает больше свободы в настройке безопасности. Арендуя виртуальный сервер в Spaceweb, вы получите доступ к системе и сможете самостоятельно управлять сетевыми правилами: закрывать лишние порты, ограничивать SSH по IP, настраивать firewall внутри ОС и выстраивать защиту под конкретный проект.
Ограничение доступа к портам
Открытый порт означает, что к сервису можно подключиться извне или из определенной сети. Поэтому перед настройкой firewall проверьте, какие службы действительно должны быть доступны пользователям, администраторам или другим серверам.
Для обычного веб-сервера чаще всего оставляют открытыми только базовые порты: 80/tcp для HTTP и 443/tcp для HTTPS. SSH-порт 22/tcp лучше не открывать для всех – ограничьте доступ доверенными IP-адресами или подключением через VPN.
Порты баз данных и внутренних сервисов не стоит публиковать в интернете. Например, MySQL/MariaDB использует 3306/tcp, PostgreSQL – 5432/tcp, Redis – 6379/tcp, MongoDB – 27017/tcp, Elasticsearch – 9200/tcp. Такие сервисы лучше оставлять доступными только из приватной сети, с бэкэнд-серверов или по списку разрешенных адресов.
Проверьте, какие порты слушает сервер:
Для внешней проверки используйте сканирование с другой машины:
После проверки закройте все лишнее. Оставьте доступ только для нужных сценариев: публичный веб-трафик, администрирование через VPN или доверенный IP и внутренние подключения между серверами.
Защита серверов от несанкционированных подключений
Firewall не заменяет полноценную настройку безопасности, но значительно усложняет несанкционированный доступ. Особенно это важно для SSH, панелей администрирования, API, баз данных и систем мониторинга.
Для SSH рекомендуется:
- запретить вход по паролю и использовать ключи;
- ограничить доступ по IP;
- отключить вход под root;
- использовать fail2ban или аналогичный инструмент;
- не открывать SSH для всего интернета без необходимости.
Пример ограничения SSH в ufw:
Для административных панелей лучше использовать VPN, private network или allowlist по IP. Кроме того, стоит закрывать публичный доступ к панелям управления, phpMyAdmin, Grafana, Kibana, Portainer и подобным инструментам.
Дополнительно можно ограничивать исходящие соединения. Это помогает при компрометации сервера: вредоносному процессу будет сложнее подключаться к внешним адресам, отправлять данные или загружать дополнительные компоненты.
Типичные ошибки при настройке firewall
Правильно выбранный firewall не гарантирует защиту, если правила настроены хаотично или не проверяются после изменений. Чаще всего проблемы возникают не из-за сложных атак, а из-за простых ошибок: лишний открытый порт, забытый IPv6, слишком широкое правило или несохраненная конфигурация.
| Ошибка | Чем опасна | Как исправить |
| Открыты все входящие подключения | Сервер становится доступен для сканирования, перебора паролей и атак на уязвимые сервисы | Использовать политику по умолчанию deny/drop для входящего трафика и разрешать только нужные порты |
| SSH доступен для всех IP | На сервер постоянно идут попытки brute-force и автоматические подключения | Ограничить SSH по IP, использовать VPN, отключить вход по паролю и запретить root-login |
| Публично открыты порты баз данных | MySQL, PostgreSQL, Redis, MongoDB и другие сервисы могут стать целью атак или утечки данных | Разрешать доступ к БД только из внутренней сети, с бэкэнд-серверов или через VPN |
| Не учтен IPv6 | IPv4 может быть закрыт, а IPv6 остается открытым для внешних подключений | Проверить правила для IPv6 и отключить его, если он не используется |
| Правила не сохранены после настройки | После перезагрузки сервер возвращается к прежнему состоянию, иногда вообще без фильтрации | Настроить автозагрузку правил через iptables-persistent, nftables, ufw или firewalld |
| Слишком широкие разрешения | Правило вроде «разрешить все из подсети» может открыть доступ большему числу серверов, чем нужно | Ограничивать доступ по конкретным IP, портам и ролям серверов |
| Нет резервного доступа к серверу | Ошибка в правилах может закрыть SSH и оставить администратора без доступа | Перед изменениями проверить наличие консоли в панели провайдера, VNC или rescue-режима |
| Firewall настроен только на сервере | Лишний трафик все равно доходит до виртуальной машины и нагружает ее | Использовать два уровня защиты: облачный firewall и firewall внутри ОС |
| Не проверяются открытые порты | Можно не заметить случайно опубликованный сервис или тестовую панель | Проверять сервер командами ss -tulpen, nmap, а также через внешние сканеры |
| Нет документации по правилам | Через несколько месяцев становится непонятно, зачем было добавлено то или иное разрешение | Описывать назначение правил: какой сервис, какой порт, кому разрешен доступ и почему |
Особенно опасны временные правила, которые забыли удалить после тестирования. Например, администратор может открыть порт базы данных «на пять минут» для проверки подключения, а затем оставить его доступным из интернета. Поэтому после любых работ с firewall стоит повторно проверить список открытых портов и убедиться, что наружу смотрят только действительно необходимые сервисы.
Практические рекомендации по безопасности серверов
Начинать лучше с инвентаризации сервисов. Нужно понять, какие процессы слушают порты, кому они должны быть доступны и с каких адресов.
Что вы можете сделать:
- публично открывать только необходимые порты;
- административные подключения ограничивать по IP или VPN;
- базы данных размещать во внутренней сети;
- закрывать неиспользуемые сервисы;
- учитывать IPv4 и IPv6;
- сохранять правила после перезагрузки;
- проверять firewall после обновлений и миграций;
- вести журналирование важных блокировок;
- документировать правила и их назначение.
Также важно разделять окружения. Для production, staging и test-серверов не стоит использовать одинаково широкие правила. Тестовые сервисы часто менее защищены, поэтому их лучше скрывать за VPN или allowlist.
В облаке желательно использовать группы правил по ролям: отдельно для веб-серверов, баз данных, балансировщиков, VPN-шлюзов и административных машин. Это упрощает сопровождение и снижает вероятность случайно открыть лишний порт.
Итоги
Firewall нужен не столько для закрытия портов, сколько для управления сетевым доступом к серверу и инфраструктуре. Надежная схема строится на двух уровнях: облачный firewall фильтрует трафик до сервера, а серверный firewall контролирует доступ внутри операционной системы.
Важно разрешать только то, что действительно нужно. Для веб-сервера обычно достаточно открыть 80 и 443, а SSH ограничить доверенными IP. Базы данных, кеши, панели управления и внутренние API не должны быть доступны из интернета без необходимости.
Грамотно настроенный firewall снижает количество атак, защищает административные интерфейсы и помогает удерживать инфраструктуру в предсказуемом состоянии. Он не заменяет обновления, безопасную конфигурацию сервисов и мониторинг, но остается обязательной частью базовой защиты сервера.