Как установить firewall на сервер

Обновлено: 06.07.2024

Основной брандмауэр в операционных системах Linux - это iptables. Но команды iptables сложны, и многим пользователям тяжело запомнить все опции и случаи, в которых их надо использовать. Поэтому разработчики дистрибутивов создают свои надстройки над iptables, которые помогают упростить управление фаерволом. У CentOS надстройка для управления iptables называется Firewalld.

У Firewalld есть несколько важных отличий, по сравнению с iptables. Здесь управление доступом к сети выполняется на уровне зон и сервисов, а не цепочек и правил. А также правила обновляются динамически, не прерывая запущенных сессий. В этой статье будет рассмотрена настройка Firewall CentOS 7 на примере Firewalld.

Основы использования Firewalld

Как я уже сказал выше, Firewalld работает не с цепочками правил, а с зонами. Каждому сетевому интерфейсу может быть присвоена определенная зона. Зона представляет из себя набор правил, ограничений и разрешений, которые применяются к этому сетевому интерфейсу. Для одного интерфейса может быть выбрана только одна зона. Разработчики создали несколько предустановленных зон:

Таким образом, чтобы разрешить или запретить какой-либо сервис, вам достаточно добавить или удалить его из текущей зоны или сменить зону интерфейса на ту, где он разрешён. Можно провести аналогию с политикой действий по умолчанию для пакетов в iptables. Зона trusted имеет политику ACCEPT и разрешает все подключения, зона block имеет политику DENY, которая запрещает все подключения, а все остальные зоны можно считать наследниками зоны block, плюс в них уже предопределены правила разрешения сетевых подключений для некоторых сервисов.

Также у Firewalld есть два вида конфигурации:

runtime - действительна только до перезагрузки, все изменения, в которых явно не указано другое, применяются к этой конфигурации;
permanent - постоянные настройки, которые будут работать и после перезагрузки.

Теперь вы знаете всё необходимое, поэтому перейдём к утилите firewalld-cmd.

Синтаксис и опции firewall-cmd

Управлять настройками Firewalld можно как с помощью консольной утилиты firewall-cmd, так и в графическом интерфейсе. CentOS чаще всего используется на серверах, поэтому вам придётся работать в терминале. Давайте рассмотрим синтаксис утилиты:

firewall-cmd опции

Для управления зонами используется такой синтаксис:

firewall-cmd --конфигурация --zone=зона опции

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

--state - вывести состояние брандмауэра;
--reload - перезагрузить правила из постоянной конфигурации;
--complete-reload - жёсткая перезагрузка правил с разрывом всех соединений;
--runtime-to-permanent - перенести настройки конфигурации runtime в постоянную конфигурацию;
--permanent - использовать постоянную конфигурацию;
--get-default-zone - отобразить зону, используемую по умолчанию;
--set-default-zone - установить зону по умолчанию;
--get-active-zones - отобразить активные зоны;
--get-zones - отобразить все доступные зоны;
--get-services - вывести предопределенные сервисы;
--list-all-zones - вывести конфигурацию всех зон;
--new-zone - создать новую зону;
--delete-zone - удалить зону;
--list-all - вывести всё, что добавлено, из выбранной зоны;
--list-services - вывести все сервисы, добавленные к зоне;
--add-service - добавить сервис к зоне;
--remove-service - удалить сервис из зоны;
--list-ports - отобразить порты, добавленные к зоне;
--add-port - добавить порт к зоне;
--remove-port - удалить порт из зоны;
--query-port - показать, добавлен ли порт к зоне;
--list-protocols - вывести протоколы, добавленные к зоне;
--add-protocol - добавить протокол к зоне;
--remove-protocol - удалить протокол из зоны;
--list-source-ports - вывести порты источника, добавленные к зоне;
--add-source-port - добавить порт-источник к зоне;
--remove-source-port - удалить порт-источник из зоны;
--list-icmp-blocks - вывести список блокировок icmp;
--add-icmp-block - добавить блокировку icmp;
--add-icmp-block - удалить блокировку icmp;
--add-forward-port - добавить порт для перенаправления в NAT;
--remove-forward-port - удалить порт для перенаправления в NAT;
--add-masquerade - включить NAT;
--remove-masquerade - удалить NAT.

Это далеко не все опции утилиты, но для этой статьи нам будет их достаточно.

Настройка Firewall в CentOS 7

1. Статус брандмауэра

Первым делом необходимо посмотреть состояние брандмауэра. Для этого выполните:

sudo systemctl status firewalld

Если служба Firewalld отключена, то необходимо её включить:

sudo systemctl start firewalld
sudo systemctl enable firewalld

Теперь нужно посмотреть, запущен ли Firewalld, с помощью команды firewall-cmd:

sudo firewall-cmd --state

2. Управление зонами

Как вы уже поняли, зоны - это основной инструмент для управления сетевыми подключениями. Чтобы посмотреть зону по умолчанию, выполните:

sudo firewall-cmd --get-default-zone

В моем случае это зона public. Вы можете изменить текущую зону с помощью опции --set-default-zone:

sudo firewall-cmd --set-default-zone=public

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

sudo firewall-cmd --get-active-zones

В списке будут выведены зоны и интерфейсы, для которых они присвоены. Такой командой можно посмотреть конфигурацию для определённой зоны. Например, для зоны public:

sudo firewall-cmd --zone=public --list-all

3. Настройка сервисов

Вы можете посмотреть все предопределенные сервисы командой:

sudo firewall-cmd --get-services

А чтобы удалить этот сервис, выполните:

В обоих случаях мы использовали опцию --permanent, чтобы конфигурация сохранялась после перезагрузки. После изменений нужно обновить правила:

sudo firewall-cmd --reload

Затем, если вы посмотрите конфигурацию зоны, то там появится добавленный сервис:

sudo firewall-cmd --zone=public --list-all

4. Как открыть порт в Firewalld

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

sudo firewall-cmd --zone=public --add-port=8083/tcp --permanent

Чтобы удалить этот порт из зоны, выполните:

sudo firewall-cmd --zone=public --remove-port=8083/tcp --permanent

Аналогично сервисам, чтобы открыть порт в firewall centos 7 надо перезагрузить брандмауэр.

sudo firewall-cmd --reload

5. Проброс портов Firewalld

sudo firewall-cmd --zone=public --add-forward-port=port=2223:proto=tcp:toport=22

Здесь перенаправление выполняется только на текущей машине. Если вы хотите настроить сеть NAT и пробрасывать порт на другую машину, то вам нужно сначала включить поддержку masquerade:

sudo firewall-cmd --zone=public --add-masquerade

Затем уже можно добавить порт:

sudo firewall-cmd --zone=publiс --add-forward-port=port=2223:proto=tcp:toport=22:toaddr=192.168.56.4

6. Расширенные правила

Если функциональности зон вам недостаточно, вы можете использовать расширенные правила. Общий синтаксис расширенных правил такой:

rule family = "семейтво" source значение destination значение log audit действие

Вот значение основных параметров:

Давайте рассмотрим несколько примеров. Нам необходимо заблокировать доступ к серверу для пользователя с IP 135.152.53.5:

sudo firewall-cmd --zone=public --add-rich-rule 'rule family="ipv4" source address=135.152.53.5 reject'

Или нам нужно запретить для этого же пользователя только доступ к порту 22:

sudo firewall-cmd --zone=public --add-rich-rule 'rule family="ipv4" source address=135.152.53.5 port port=22 protocol=tcp reject'

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

sudo firewall-cmd --list-rich-rules

Выводы

В этой статье мы разобрали, как выполняется настройка firewall в CentOS 7 и какие задачи можно с помощью него выполнить. Программой намного проще пользоваться, чем iptables, но по моему мнению надстройка фаервола от Ubuntu - ufw ещё проще в использовании.

firewalld — программное обеспечение для управления брандмауэрами, поддерживаемое многими дистрибутивами Linux. Выступает в качестве клиентского интерфейса для встроенных в ядро Linux систем фильтрации пакетов nftables и iptables.

В этом обучающем руководстве мы покажем, как настраивать брандмауэр firewalld для сервера CentOS 8 и расскажем об основах управления брандмауэром с помощью административного инструмента firewall-cmd .

Предварительные требования

Для прохождения этого обучающего руководства нам потребуется сервер под управлением CentOS 8. Мы будем считать, что вы выполнили вход на этот сервер в качестве пользователя non-root user с привилегиями sudo . Чтобы выполнить настройку сервера, воспользуйтесь нашим руководством по начальной настройке сервера CentOS 8.

Основные концепции в firewalld

Прежде чем обсуждать фактическое использование утилиты firewall-cmd для управления конфигурацией брандмауэра, мы должны познакомиться с несколькими концепциями, которые вводит этот инструмент.

Демон firewalld управляет группами правил, используя элементы, называемые зонами. Зоны представляют собой набор правил, который определяет разрешенный трафик в зависимости от уровня доверия в сети. Зоне назначаются сетевые интерфейсы, определяющие поведение, которое должен разрешать брандмауэр.

Такая гибкость позволяет легко изменять правила в зависимости от среды, особенно в случае с компьютерами, которые часто перемещаются между сетями (например, с ноутбуками). Вы можете использовать более строгие правила, например, запретить большую часть трафика в публичных сетях WiFi и ввести менее строгие ограничения для домашней сети. Для сервера эти зоны не так важны, поскольку его сетевая среда редко изменяется, если это вообще происходит.

Вне зависимости от того, насколько динамична ваша сетевая среда, вам будет полезно познакомиться с общей идеей, лежащей в основе заданных зон firewalld . Заданные зоны в firewalld упорядочены от наименее доверенных к наиболее доверенным:

Для использования брандмауэра можно создавать правила и изменять свойства зон, а также назначать сетевые интерфейсы в наиболее подходящие зоны.

Постоянство правил

В firewalld правила можно применять к текущему набору правил времени исполнения или использовать как постоянные. При добавлении или изменении правила по умолчанию изменяется только работающий брандмауэр. После перезагрузки системы или службы firewalld сохраняются только постоянные правила.

Большинство операций firewall-cmd могут принимать флаг --permanent , указывающий на необходимость применения изменений к постоянной конфигурации. Кроме того, текущую конфигурацию брандмауэра можно сохранить в постоянной конфигурации с помощью команды firewall-cmd --runtime-to-permanent .

Такое разделение конфигурации времени исполнения и постоянной конфигурации позволяет безопасно тестировать правила на активном брандмауэре и просто перезагружать его в случае возникновения проблем.

Установка и активация firewalld

Брандмауэр firewalld установлен по умолчанию в некоторых дистрибутивах Linux, в том числе во многих образах CentOS 8. Однако вам может потребоваться установить firewalld самостоятельно:

После установки firewalld вы можете активировать службу и перезагрузить сервер. Помните, что в случае активации службы firewalld она будет запускаться при загрузке системы. Прежде чем настраивать такое поведение, лучше создать правила брандмауэра и воспользоваться возможностью протестировать их во избежание потенциальных проблем.

После перезагрузки сервера брандмауэр запускается, сетевые интерфейсы помещаются в настроенные зоны (или возвращаются в заданные по умолчанию зоны), и все правила зон применяются к соответствующим интерфейсам.

Чтобы проверить работу и доступность службы, можно использовать следующую команду:

Это показывает, что наш брандмауэр запущен и работает с конфигурацией по умолчанию.

Знакомство с текущими правилами брандмауэра

Прежде чем мы начнем вносить изменения, мы познакомимся со средой и правилами firewalld, используемыми по умолчанию.

Изучение параметров по умолчанию

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

Поскольку мы не отправили firewalld никаких команд для отклонения от основной зоны и никакие наши интерфейсы не настроены на привязку к другой зоне, эта зона будет единственной активной зоной (зоной, контролирующей трафик для наших интерфейсов). Это можно проверить с помощью следующей команды:

Здесь мы видим, что на нашем сервере брандмауэр контролирует два сетевых интерфейса ( eth0 и eth1 ). Управление обоими интерфейсами осуществляется в соответствии с правилами, заданными для зоны public.

Как же узнать, какие правила заданы для зоны public? Конфигурацию зоны по умолчанию можно распечатать с помощью следующей команды:

Из выводимых результатов мы видим, что эта зона активна и используется по умолчанию и что с ней связаны интерфейсы eth0 и eth1 (все это мы уже знали из предыдущих запросов). Также мы видим, что эта зона разрешает трафик клиента DHCP (для назначения IP-адресов), SSH (для удаленного администрирования) и Cockpit (веб-консоль).

Изучение альтернативных зон

Мы получили представление о конфигурации зоны по умолчанию и активной зоны. Также мы можем получить информацию о других зонах.

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

Чтобы посмотреть конкретную конфигурацию, относящуюся к зоне, необходимо добавить параметр --zone= к команде --list-all :

Вы можете вывести все определения зон, используя опцию --list-all-zones . Возможно вы захотите вывести результаты на пейджер для удобства просмотра:

Далее мы узнаем о назначении зон сетевым интерфейсам.

Выбор зон для интерфейсов

Если вы не настроили сетевые интерфейсы иным образом, каждый интерфейс будет помещен в зону по умолчанию при запуске брандмауэра.

Изменение зоны интерфейса

Для перемещения интерфейса между зонами во время сеанса следует использовать параметр --zone= в сочетании с параметром --change-interface= . Как и для всех остальных команд, изменяющих брандмауэр, вам потребуется использовать sudo .

Например, интерфейс eth0 можно переместить в зону home с помощью следующей команды:

Примечание. При перемещении интерфейса в новую зону следует помнить, что это может повлиять на работоспособность служб. Например, в данном случае мы перемещаемся в зону home, в которой поддерживается SSH. Это означает, что наше соединение не должно быть отброшено. В некоторых других зонах SSH по умолчанию не поддерживается, при переходе в такую зону ваше соединение будет разорвано, и вы не сможете снова войти на сервер.

Чтобы убедиться в успешности операции мы можем снова запросить активные зоны:

Изменение зоны по умолчанию

Если все интерфейсы могут быть хорошо обработаны в одной зоне, проще всего определить наиболее подходящую зону как зону по умолчанию, а затем использовать эту зону для конфигурации.

Вы можете изменить зону по умолчанию с помощью параметра --set-default-zone= . При этом немедленно изменятся все интерфейсы, использующие зону по умолчанию:

Установка правил для приложений

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

Добавление службы к зонам

Самый простой метод заключается в том, чтобы добавлять необходимые службы или порты в используемые зоны. Список доступных определений служб можно получить с помощью опции --get-services :

Примечание. Вы можете получить более подробную информацию о каждой из этих служб, посмотрев соответствующий файл .xml в директории /usr/lib/firewalld/services . Например, служба SSH определяется следующим образом:

Вы можете активировать службу для зоны с помощью параметра --add-service= . Данная операция будет нацелена на зону по умолчанию или на другую зону, заданную параметром --zone= . По умолчанию изменения применяются только к текущему сеансу брандмауэра. Для изменения постоянной конфигурации брандмауэра следует использовать флаг --permanent .

Вы можете опустить флаг --zone= , если хотите внести изменения в зону по умолчанию. Для проверки успешного выполнения операции можно использовать команду --list-all или --list-services :

После подтверждения надлежащей работы всех систем вы можете изменить постоянные правила брандмауэра, чтобы служба была доступна после перезагрузки системы. Чтобы сделать предыдущие изменения постоянными, нужно ввести их повторно и добавить флаг --permanent :

Также можно использовать флаг --runtime-to-permanent для сохранения текущей конфигурации брандмауэра в постоянной конфигурации:

Будьте осторожны, поскольку при этом все изменения в текущей конфигурации брандмауэра сохраняются в постоянной конфигурации.

Если вы хотите убедиться. что изменения успешно сохранены в постоянной конфигурации, добавьте флаг --permanent к команде --list-services . Вам потребуются привилегии sudo для выполнения любых операций с флагом --permanent :

Что делать, если подходящая служба отсутствует?

В базовом комплекте firewalld представлены многие распространенные приложения, к которым вы можете захотеть предоставить доступ. Однако возможны ситуации, когда эти службы не будут соответствовать вашим требованиям.

В этой ситуации у вас будет два варианта.

Открытие порта для зон

Проще всего добавить поддержку определенного приложения можно посредством открытия используемых им портов в соответствующих зонах. Для этого нужно указать порт или диапазон портов, а также протокол (TCP или UDP), связанный с портами.

Например, если наше приложение работает на порту 5000 и использует TCP, мы можем временно добавить его в зону public с помощью параметра --add-port= . Протоколы могут назначаться как tcp или udp :

Мы можем проверить успешность назначения с помощью операции --list-ports :

Также можно указать последовательный диапазон портов, разделив начальный и конечный порты диапазона дефисом. Например, если наше приложение используйте порты UDP с 4990 по 4999, мы можем открыть их на public с помощью следующей команды:

После тестирования мы вероятно захотим добавить это правило в брандмауэр на постоянной основе. Используйте для этого sudo firewall-cmd --runtime-to-permanent или запустите команды снова с флагом --permanent :

Определение службы

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

Службы представляют собой наборы портов с именем и описанием. Использование служб упрощает администрирование портов, но требует некоторой предварительной подготовки. Проще всего начать с копирования существующего скрипта (из директории /usr/lib/firewalld/services ) в директорию /etc/firewalld/services , где брандмауэр ищет нестандартные определения.

Например, мы можем скопировать определение службы SSH и использовать его для определения службы example. Имя файла без суффикса .xml определяет имя службы в списке служб брандмауэра:

Теперь можно изменить определение в скопированном вами файле. Вначале откройте его в предпочитаемом текстовом редакторе. Здесь мы используем vi :

Вначале файл будет содержать только что скопированное вами определение SSH:

Основная часть этого определения представляет собой метаданные. Вы можете изменить короткое имя службы, заключенное в тегах <short> . Это имя службы, предназначенное для чтения людьми. Также следует добавить описание на случай, если вам потребуется дополнительная информация при проведении аудита службы. Единственное изменение конфигурации, которое вам потребуется, и которое повлияет на функциональность службы, будет заключаться в определении портов, где вы идентифицируете номер порта и протокол, который хотите открыть. Можно указать несколько тегов <port/> .

Представьте, что для нашей службы example нам необходимо открыть порт 7777 для TCP и 8888 для UDP. Мы можем изменить существующее определение примерно так:

Сохраните и закройте файл.

Перезагрузите брандмауэр, чтобы получить доступ к новой службе:

Теперь вы увидите ее в списке доступных служб:

Теперь вы можете использовать эту службу в зонах, как и обычно.

Создание собственных зон

Хотя большинству пользователей будет достаточно заданных зон, иногда может быть полезно определить собственные зоны с названиями, соответствующими их функции.

Например, вы можете захотеть создать для своего веб-сервера зону с именем publicweb. При этом вы можете также захотеть использовать другую зону для службы DNS в вашей частной сети. Эту зону вы можете назвать privateDNS.

При добавлении зоны вы должны добавить ее в постоянную конфигурацию брандмауэра. Затем вы можете произвести перезагрузку для активации конфигурации для текущего сеанса. Например, мы можем создать две описанные выше зоны, введя следующие команды:

Вы можете проверить их наличие в постоянной конфигурации с помощью следующей команды:

Как указывалось ранее, пока они будут недоступны в работающем брандмауэре:

Перезагрузите брандмауэр, чтобы добавить эти зоны в активную конфигурацию:

Для зоны privateDNS можно добавить службу DNS:

Затем мы можем изменить интерфейсы на новые зоны, чтобы протестировать их:

Сейчас вы можете протестировать свою конфигурацию. Если эти значения будут работать, эти правила можно будет добавить в постоянную конфигурацию. Для этого можно снова запустить все команды с флагом --permanent , но в этом случае мы используем флаг --runtime-to-permanent для полного сохранения активной конфигурации как постоянной:

Сохранив правила в постоянной конфигурации, перезагрузите брандмауэр, чтобы проверить сохранение изменений:

Проверьте правильность назначения зон:

Убедитесь, что в обеих зонах доступны соответствующие службы:

Вы успешно настроили собственные зоны! Если вы захотите задать одну из этих зон по умолчанию для других интерфейсов, используйте для настройки параметр --set-default-zone= :

Заключение

Теперь вы должны неплохо понимать принципы администрирования службы firewalld в системе CentOS на каждодневной основе.

Служба firewalld позволяет настраивать администрируемые правила и наборы правил, учитывающие условия вашей сетевой среды. Она позволяет легко переключаться между разными политиками брандмауэра посредством использования зон и дает администраторам возможность абстрагировать управление портами в более удобную систему определения служб. Умение работать с этой системой позволит вам воспользоваться преимуществами гибкости и функциональности данного инструмента.

Дополнительную информацию о firewalld можно найти в официальной документации по firewalld.

Файрвол, как и многое другое в RouterOS, пришел из Linux и представляет собой доработанный iptables. Поэтому многие мануалы по настройке iptables легко можно сконвертировать в формат RouterOS. Файрвол состоит из следующих таблиц:

Filter — занимается фильтрацией трафика — определяет, пропустить пакет в сеть или отбросить его. Мы будем рассматривать работу только этой таблицы;
NAT — Network Address Translation. Изменяет проходящие пакеты. Поменять адрес источника или порт назначения — дело именно этой таблицы. В основном она используется для обеспечения доступа в интернет из локалки и обратно. Иногда без NAT невозможно работать в плохо спроектированных сетях, а еще его, бывает, используют в качестве «костыля»;
Mangle — классифицирует и маркирует трафик и может менять некоторые поля в заголовке (TTL, ToS, DF). Применяется для построения сложных путей трафика (например, когда подключено два провайдера или нужны разные пути трафика для RDP и VoIP);
Raw — обрабатывает пакеты до их попадания в Connection Tracking. Пригодится для защиты от DoS или при работе с большими объемами трафика.

Таблицы состоят из цепочек. Цепочки в разных таблицах могут отличаться. Чуть позже станет ясно почему. В нашей таблице Filter три цепочки:

input — трафик к самому роутеру. Обязательное условие попадания в input — адресом назначения пакета должен быть один из адресов роутера, широковещательный адрес сети или широковещательный адрес работающей на роутере службы. Сюда попадает WinBox, SSH, WebFig, ping, VPN и другой трафик, предназначенный роутеру. Полный список можешь посмотреть в вики. В этой цепочке мы должны защищать сам роутер;
output — трафик от роутера. Ответы на прилетевшее в input или новые пакеты от роутера (пинг, VPN, SSH-сессия с самого роутера). Эта цепочка редко используется, так как часто роутер считается доверенным звеном и пакеты, генерируемые им, по умолчанию легитимны. Но, как показывает история взломов, контроль исходящего трафика может выявить заражение на начальных этапах;
forward — трафик, проходящий через роутер (когда пакет прилетел в один интерфейс и вылетел с другого или того же самого). Трафик из локалки в интернет, из интернета в локалку, из одного VLAN локалки в другой;
user chains — пользовательские цепочки. Админ может создавать цепочки правил по своему усмотрению. Это бывает полезно для декомпозиции больших конфигураций. К примеру, можно весь трафик на порты 80 и 443 завернуть в отдельную цепочку WEB и в ней уже делать десятки правил для фильтрации — это визуально упростит настройку, хотя качественно на прохождение трафика не повлияет.

Два важных момента, о которых нужно помнить.

Момент первый. У трафика в forward всегда есть входящий и исходящий интерфейсы — трафик влетел в input, обработался процессом маршрутизации и должен вылететь в output. У входного трафика не может быть исходящего интерфейса — он обработается внутри роутера и никуда дальше не полетит. Также у выходного трафика не может быть входящего интерфейса — этот трафик генерируется самим роутером (это либо новый трафик, либо созданный роутером ответ на трафик, пришедший в input).

Момент второй. У трафика не существует «внешнего» или «внутреннего» интерфейсов. Роутеру плевать, что ты считаешь внешним, — для него есть интерфейс, в который трафик вошел, и интерфейс, с которого трафик уйдет.

Правила образуют цепочки. У каждого правила может быть только одна цепочка. По умолчанию политика у всех цепочек — все разрешено. Правила срабатывают в таблицах в зависимости от их порядка: сначала пакет обработается первым правилом, затем вторым и так далее. Хорошим тоном считается упорядочивать правила внутри таблиц по цепочкам: сначала — пачка правил input, затем — forward, в конце — output.

Трафик будет проходить по правилам только в пределах своей цепочки. И если сначала идет input, потом forward, затем снова input, то трафик input все равно никогда не попадет в forward, то есть такое расположение правил не повлияет на прохождение трафика, а только запутает админа. В пределах одной таблицы пакет не перепрыгнет из одной цепочки в другую, пока админ это явно не укажет.

table_chain_rule

Connection Tracking

Еще одна важная вещь для понимания работы файрвола — механизм определения состояния соединений — Connection Tracking (или просто ConnTrack). У RouterOS есть специальная таблица, в которой хранятся данные о состоянии соединений. Благодаря ей работает NAT и многие другие части файрвола.

Механизмы ConnTrack проверяют, принадлежит ли пришедший на роутер пакет какому-либо из потоков, чтобы применить к нему политики всего потока или как-то упорядочить пакеты в пределах одного или нескольких потоков (например, для нарезки скорости).

Для ConnTrack существуют четыре состояния пакетов:

new — новый пакет, не принадлежащий ни одному из известных потоков. Это может быть первый пакет для коннекта к серверу RDP, или первый пакет в потоке WinBox, или запрос к DNS. Система запоминает Source IP, Source Port, Destination IP, Destination Port и некоторые другие параметры и записывает эти данные в таблицу. Следующий пакет с такими же данными будет относиться к записанному потоку;
established — пакет, принадлежащий существующему потоку. То есть пакет, у которого Source IP, Source Port, Destination IP, Destination Port подходят под одну из записей таблицы ConnTrack (или обратный пакет);
related — пакет, порожденный другим потоком. Некоторые протоколы, такие как FTP, SIP, PPTP, используют для работы несколько потоков. Например, управляющие команды FTP ходят по порту TCP 21, но данные передаются с порта TCP 20. При попытке получения или отправки данных на FTP в потоке на порт 21 сервер сообщает: «А сейчас я открою 20-й порт, и ты забирай данные с него», после этого клиент посылает пакет на 20-й порт сервера. Этот пакет будет считаться related, так как он порожден потоком 21-го порта;
invalid — все, что не относится к перечисленным выше состояниям. Пример: сессия корректно закрылась, но из-за ошибок маршрутизации часть пакетов из середины сессии улетела другим путем. Когда они пришли, их сессия уже закрыта и роутер о них ничего не знает. Они не new и не относятся к существующим соединениям, поэтому считаем их invalid.

Состояние потока не связано с флагами TCP: SYN, ACK, FIN. Для UDP и других stateless-протоколов в таблице ConnTrack тоже содержатся все возможные состояния.

Работа ConnTrack требует ресурсов процессора и при больших объемах трафика может существенно нагрузить CPU. Но ConnTrack нужен не везде, и его можно отключить. Например, у провайдеров на стыке с вышестоящим провайдером стоят роутеры, которые молотят десятки гигабит трафика. На этих роутерах, как правило, нет NAT (прямая маршрутизация), а трафик фильтруется уровнем ниже, чтобы не перегружать и без того нагруженный бордер. То есть в этом случае ни к чему проверять каждый пакет на принадлежность какому-либо потоку.

Нажав кнопку Tracking, можно отключить механизм ConnTrack или подкрутить таймеры. В большинстве случаев тебе не понадобится заходить в эти настройки, но знать о них нужно. Режима ConnTrack три: что такое yes и no , думаю, понятно, а в режиме auto ConnTrack выключен до тех пор, пока хотя бы один пакет не попадет в существующие правила таблицы NAT или Filter.

WARNING

Выключенный ConnTrack ломает NAT и фичи файрвола, основанные на трекинге потоков: connection-bytes, connection-mark, connection-type, connection-state, connection-limit, connection-rate, layer7-protocol, new-connection-mark, tarpit.

Траблшутинг

Когда файрвол не работает или работает не так, как подразумевалось при настройке, виноват админ. Магии не бывает. Первое, на что стоит обратить внимание при траблшутинге, — счетчики пакетов. Если счетчик не увеличивается, значит, трафик в него не попадает. А если трафик не попадает, значит, либо этого трафика просто нет, либо он был обработан стоящим выше правилом.

Ты же помнишь, что правила файрвола работают по принципу «кто первый встал — того и тапки»? Если пакет попал под действие правила, то дальше он уже не пойдет. Значит, нужно искать проблему выше. Просто копируем наше правило, action ставим accept (для траблшутинга не делай дроп — так при проверке можно сломать себе доступ или нарушить работу сети) и постепенно двигаем его наверх до первого увеличения счетчиков в этом правиле. Если через это правило уже проходил трафик, то счетчики будут ненулевые и можно пропустить нужные нам пакеты, — просто сбрось счетчики в этом правиле или во всех кнопками Reset Counters.

Reset Counters

Предположим, мы нашли правило, в которое попадает наш трафик, а попадать не должен. Нужно понять, почему так происходит. В этом нам поможет опция Log. Во вкладке Action ставим галочку Log (можно написать префикс для правила, чтобы было проще отлавливать его в логах) и смотрим логи, где написаны все характеристики пакетов, попадающих под правило. Среди характеристик: цепочка, входящий и исходящий интерфейсы, адреса и порты источника и получателя, протокол, флаги, размер пакета, действия NAT.

Если даже в самом верху в правиле не будут увеличиваться счетчики, убирай правила из условия по одному. Начинай с интерфейсов — админы часто путаются в своих представлениях о том, откуда или куда должен идти трафик (например, при коннекте к провайдеру через PPPoE или в туннелях между филиалами или сложном роутинге). Счетчики пошли? Включаем лог и смотрим интерфейсы и другие параметры.

Если и это не помогает — пришло время тяжелой артиллерии. Идем в Tools → Torch и изучаем трафик на роутере. Может, ожидаемого трафика вовсе нет. Еще один крутой инструмент — аналог tcpdump — Tools → Packet Sniffer. Разбор работы этих инструментов тянет на отдельную статью (если она тебе интересна — сообщи об этом в комментариях к статье).

Чтобы упростить траблшутинг, можно использовать функцию комментирования. Если из-за комментов окно становится слишком большим и это мешает смотреть на правила, воспользуйся инлайновыми комментариями (Inline Comments). Так комменты встанут с правилом в одну строку и в окно будет умещаться больше правил.

Inline Comments

Также рекомендую распределять правила по порядку, следуя какой-то определенной логике. И старайся ее поддерживать на всех роутерах.

Итоги

В этой статье приведены только основы настройки файрвола и главные методы диагностики. Кроме RouterOS, эти принципы применимы и для Linux. В следующей статье разберем более сложные правила, которые позволяют защититься от не самых простых атак, и разберем цепочку Forward, а также создадим свои цепочки.

Установка хорошего фаервола – это обязательная мера, которую нужно принять для защиты любой современной операционной системы. Большинство дистрибутивов Linux поставляются с разными утилитами, которые можно использовать для настройки фаервола. В данном руководстве будет использоваться утилита под названием iptables.

Iptables – это стандартная фаервол-утилита, которая по умолчанию входит в состав большинства дистрибутивов Linux. Необходимо отметить, что iptables – это утилита командной строки для управления Netfilter, брандмауэром, встроенным в ядро Linux. Он позволяет управлять фильтрацией и перенаправлением пакетов – администраторы создают правила, согласно которым происходит обработка пакетов.

В данном руководстве будет рассказано, как создать базовые правила для Ubuntu 14.04.

Обратите внимание, что в статье пойдет речь только о безопасности IPv4. Защита IPv6 настраивается по-другому.

Требования

Вам понадобится пользователь с административными правами для выполнения команд sudo.

Основные команды iptables

Рассмотрим основные команды, которые используются для установки различных правил и для работы с iptables в целом.

Во-первых, все команды iptables должен использовать только пользователь с административными (root) правами. В этом руководстве будет использоваться пользователь с sudo-правами, так как это предпочтительный вариант при работе на ОС Ubuntu 14.04. Однако при желании вы можете использовать и суперпользователя.

Для начала необходимо вывести список всех прав, которые сейчас установлены для iptables. Для этого используйте ключ –L:

Вы получите примерно такой вывод на экране:

По умолчанию существует три цепочки правил – INPUT (входящие пакеты), FORWARD (транзитные пакеты) и OUTPUT (исходящие пакеты). У всех по умолчанию проставлено действие ACCEPT (пропуск пакета). Также можно увидеть заголовки колонок, но самих правил нет, т.к. Ubuntu не поставляется с каким-то пакетом правил по умолчанию.

Для того, чтобы посмотреть вывод в формате, отражающем команды, необходимые для включения каждого правила и действия, используйте ключ – S:

Вывод будет следующим:

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

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

При этом важно помнить, что даже если вы удалите все правила из своих цепочек, это никак не повлияет на порядок действий, политику (policy). Поэтому, если вы работаете удаленно, перед удалением правил убедитесь, что политика по умолчанию на входящие и исходящие пакеты (INPUT и OUTPUT) – это пропуск (ACCEPT). Сделать это можно следующей командой:

Ключ –P устанавливает политику для стандартной цепочки.

Создание первого правила

Перейдем к настройке фаервола. Мы будем работать с цепочкой INPUT, так как именно она отвечает за входящие пакеты. Для начала нужно поработать с SSH-соединением, а именно создать правило, разрешающее это соединение.

Полностью оно выглядит следующим образом:

Разберем составляющие этой команды:

-A INPUT: ключ –A говорит о том, что правило будет добавлено в конец написанной цепочки. То есть эта часть команды означает, что мы хотим добавить новое правило, оно будет добавлено в конец цепочки и действует для INPUT.
-m conntrack: conntrack отвечает за отслеживание состояния соединения и классификацию пакетов, а ключ –m используется при добавлении новых условий для того, чтобы загрузить нужное для этих условий расширение.

Таким образом, в этой части команды речь идет о том, что нам нужно получить доступ к функционалу, за который отвечает модуль conntrack.

--ctstate: ввод этой команды возможен при отсылке к модулю conntrack. Эта команда позволяет задать список возможных состояний соединений.

В данном случае мы задаем параметр ESTABLISHED для того, чтобы разрешить те пакеты, которые относятся к уже установленным соединениям. Следующее соединение – RELATED – указывает пакеты, которые логически связаны с уже установленными соединениями. Оба этих условия подходят под нашу SSH-сессию.

-j ACCEPT: в этой части указывается цель подходящих пакетов. В данном случае сообщается, что пакеты, подходящие под уже заявленные до этого критерии, будут приняты и пропущены.

Итак, мы ставим это правило первым, так как важно убедиться, что все соединения, которые вы уже используете, подходят под критерии, принимаются и выходят из цепочки до того, как они достигают каких-то других правил (в частности, правил блокировки – DROP).

Теперь можно проверить внесенные изменения:

Вывод будет примерно такой:

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

Допуск других важных соединений

Мы уже задали, что iptables должен держать открытыми все соединения, которые уже установлены, и допускать новые соединения, которые как-то связаны с предыдущими. Тем не менее необходимо создать еще несколько правил для того, чтобы были установлены другие новые соединения, которые не подходят под предыдущие критерии.

В частности, необходимо, чтобы были всегда открыты два порта: SSH-порт (по умолчанию это обычно порт 22) и порт веб-сервера, который стандартно имеет 80 порт.

Поэтому нужно добавить следующие правила:

Эти правила похожи на первое правило, но выглядят более простыми. Новые опции, которые мы используем:

-p tcp: данная часть помечает все пакеты, если использованный протокол TCP. Соединение через этот протокол используется большинством приложений.
--dport: поставить эту опцию можно только в том случае, если вы указали часть команды выше. Она указывает порт: первое правило показывает, что оно работает для TCP-пакетов для порта 22, а второе – для TCP-пакетов для порта 80.

Если еще одно правило, которое нужно добавить для того, чтобы сервер функционировал корректно. Сервисы компьютера могут взаимодействовать между собой, посылая сетевые пакеты друг другу. Они делают это, используя loopback-интерфейс, который перенаправляет трафик обратно к себе, а не на другие компьютеры.

Поэтому если один сервис взаимодействует с другим сервисом, то пакеты, используя loopback, пересылаются через порт 4555. Важно, чтобы такое взаимодействие было разрешено, так как оно необходимо для работы многих программ.

Правило, которое нужно добавить, выглядит так:

Расшифровка его частей такая:

-I INPUT 1: эта часть говорит iptables вставить правило. В отличие от ключа –A, который отправляет правило в конец цепочки, ключ –I вставляет правило в то место цепочки, куда вы хотите его поместить. В данном случае правило будет самым первым правилом в цепочке INPUT, а остальные правила будут идти уже после него. Это необходимо сделать, так как это базовое правило и оно не должно зависеть от остальных правил.
-i lo: эта часть правила проверяет, соответствует ли интерфейс пакета loopback-интерфейсу.

Для того, чтобы посмотреть текущие правила, используйте команду с флагом –S. Можно также использовать ключ –L, но при его использовании отображается не вся информация, в частности, интерфейс, к которому относится это правило, поэтому в данном случае используйте такую команду:

Вывод будет выглядеть следующим образом:

Создание правила блокировки

На данный момент уже создано несколько правил, но все они направлены на пропуск пакетов, а не на блокировку.

После того, как пакет проходит всю цепочку INPUT и не попадает ни под одно из четырех правил, с ним будет выполнено действие по умолчанию – пропуск пакета – и необходимо это изменить.

Есть два способа сделать это, и они имеют важные различия между собой.

Первый способ, как можно это сделать, это просто поменять стандартную политику цепочки INPUT при помощи следующей команды:

В этом случае все пакеты, которые пройдут цепочку INPUT, будут заблокированы. Важно не забывать, что эта политика блокировки пакетов останется даже в том случае, если вы удалите все правила.

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

Однако такое решение может также иметь неприятные последствия, если у вас нет других способов получить доступ к серверу.

Альтернативный способ – это оставить стандартную политику без изменений, но при этом добавить новое правило, согласно которому будет блокироваться любой дошедший до конца цепочки пакет.

Если вы уже поменяли стандартную политику, то вернуть ее в первоначальное состояние можно вот такой командой:

Теперь вы можете в конец цепочки добавить правило, согласно которому пакет, дошедший до конца цепочки, будет заблокирован:

В обычных условиях это правило будет работать точно так же, как если бы вы поставили блокировку пакетов согласно политике по умолчанию: любой пакет, который дойдет до конца цепочки, будет заблокирован. И в результате получается, что пакет никогда не будет проходить эту цепочку полностью и не будет достигать стандартной политики.

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

Но это также означает и то, что любое дополнительное правило должно быть добавлено перед правилом блокировки пакетов. Сделать это можно либо временно удалив правило блокировки:

Либо можно вставить новое правило, указав номер строки, на которой оно будет расположено. Например, для вставки правила на 4 строчку, нужно использовать команду:

Если вы не помните, на каких строчках располагаются какие правила, вам поможет следующая команда:

Вывод будет примерно таким:

Это поможет вам добавить новое правило на нужную строчку.

Сохранение настроек iptables

По умолчанию все правила, которые вы добавляете в iptables, временные, то есть когда вы перезагрузите сервер, все правила будут удалены.

С одной стороны, это хорошая возможность, так как этим можно воспользоваться в ситуациях, когда правила были настроены неправильно, из-за чего был потерян доступ к серверу. С другой стороны, прописывать каждый раз заново все правила не очень удобно, поэтому лучше сохранить все правила и автоматически загружать их после того, как начал работать сервер.

Есть несколько способов сделать это, однако наиболее простой – это использовать пакет iptables-persistent. Его можно загрузить из репозитория Ubuntu:

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

После того, как установка будет завершена, у вас появится новый сервис iptables-persistent, который по умолчанию запускается при запуске сервера. Он будет загружать сохраненные правила и принять их всякий раз, когда сервер будет запускаться.

Сохранение изменений

Если вы обновляете свой фаервол и не хотите, чтобы ваши изменения не потерялись, то вам нужно сохранить правила iptables. Сделать это можно следующей командой:

Заключение

Теперь у вас есть базовые знания относительно того, как можно настроить фаервол, который будет отвечать вашим требованиям. Существует множество других утилит-брандмауэров, но iptables – это один из лучших инструментов, потому что он относится к Netfilter, а также используется на огромном количестве систем.

Читайте также:

Как установить firewall на сервер

Основы использования Firewalld

Синтаксис и опции firewall-cmd

Настройка Firewall в CentOS 7

1. Статус брандмауэра

2. Управление зонами

3. Настройка сервисов

4. Как открыть порт в Firewalld

5. Проброс портов Firewalld

6. Расширенные правила

Выводы

Предварительные требования

Основные концепции в firewalld

Постоянство правил

Установка и активация firewalld

Знакомство с текущими правилами брандмауэра

Изучение параметров по умолчанию

Изучение альтернативных зон

Выбор зон для интерфейсов

Изменение зоны интерфейса

Изменение зоны по умолчанию

Установка правил для приложений

Добавление службы к зонам

Что делать, если подходящая служба отсутствует?

Открытие порта для зон

Определение службы

Создание собственных зон

Заключение

Connection Tracking

WARNING

Рекомендации по настройке

Траблшутинг

Итоги

Требования

Основные команды iptables

Создание первого правила

Допуск других важных соединений

Создание правила блокировки

Сохранение настроек iptables

Сохранение изменений

Заключение