Как настроить брандмауэр с firewalld на centos 7

Введение

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

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

Для проверки, попробуем подключиться из сети Интернет через telnet на публичный IP адрес сервера gw-server на порт 80:

Результатом будет ответ веб сервера web-server01 из нашей внутренней сети:

HTTP/1.1 400 Bad Request
Server: nginx/1.14.2
Date: Wed, 31 Jul 2019 10:21:21 GMT
Content-Type: text/html
Content-Length: 173
Connection: close

Аналогично можно настроить доступ из интернета на свою рабочую станцию по RDP. Так как доступ по RDP будет нужен ограниченному количеству человек, безопасней будет использовать при подключении нестандартный порт, например 13389, а уже с него перенаправлять на порт 3389 сервера внутренней сети (либо изменить номер RDP порта на Windows компьютере). Измененный порт назначения указывается через двоеточие после IP адреса:

Для проверки, попробуем подключиться из сети Интернет через telnet (или командлет PowerShell Test-NetConnection) на публичный IP адрес сервера gw-server на порт 13389:

В ответ получим пустой экран и курсор, это говорит о том, что соединение работает.

Открытие порта или сервиса

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

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

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

/usr/lib/firewalld/services/http.xml

Чтобы разрешить входящий HTTP-трафик (порт 80) для интерфейсов в публичной зоне, только для текущего сеанса (конфигурация времени выполнения), введите:

Если вы зону по умолчанию, вы можете не параметр .

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

Если вы хотите оставить порт 80 открытым после перезагрузки, вам нужно будет ввести ту же команду еще раз, но на этот раз с параметром :

Используйте вместе с параметром чтобы проверить свои изменения:

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

Приведенная выше команда удаляет службу http из постоянной конфигурации публичной зоны.

Что делать, если вы запускаете такое приложение, как Plex Media Server, для которого нет подходящей службы?

В подобных ситуациях у вас есть два варианта. Вы можете либо открыть соответствующие порты, либо определить новую службу FirewallD.

Например, Plex Server прослушивает порт 32400 и использует TCP, чтобы открыть порт в публичной зоне для текущего сеанса, используйте параметр :

Протоколы могут быть или .

Чтобы убедиться, что порт был добавлен успешно, используйте параметр :

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

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

Создание новой службы FirewallD

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

Например, чтобы создать определение службы для Plex Media Server, мы можем использовать служебный файл SSH:

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

В следующем примере мы открываем порты UDP и TCP.

/etc/firewalld/services/plexmediaserver.xml

Сохраните файл и перезагрузите сервис FirewallD:

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

Настройка Source NAT: доступ из локальной сети в Интернет

При source NAT для серверов внешней сети, запросы от наших клиентов из внутренней сети будут выглядеть так, как будто с ними общается напрямую сервер шлюз — gw-server01.

В прошлой статье “Базовая настройка файервола Linux с помощью iptables” мы рассмотрели азы использования iptables. В этот раз, работать в iptables будем не только с таблицей filter, но и с таблицей nat. Таблицы для фильтрации трафика filter, таблица nat содержит следующие chains(цепочки):

PREROUTING — в этой цепочке обрабатываются входящие IP пакеты, до их разделения на предназначенные для самого сервера или для передачи другому, т.е. до принятия решения о выборе маршрута для IP пакета;
OUTPUT – цепочка предназначена для обработки IP пакетов, которые сгенерированы локально приложением на сервере. Локально сгенерированные IP пакеты не проходят цепочку PREROUTING;
POSTROUTING — в этой цепочке обрабатываются все исходящие IP пакеты, уже после принятия решения о маршруте для IP пакета.

Отличаются и действия, выполняемые для IP пакетов, в этой таблице:

MASQUERADE и SNAT— производит подмену IP адреса источника для исходящих пакетов. Отличием этих действий является то, что SNAT дает возможность задать конкретный IP адрес нового источника, а в случае MASQUERADE это происходит динамически;
DNAT — производит подмену IP адреса назначения для входящих пакетов.

Важно: действие MASQUERADE и SNAT задается только для цепочки POSTROUTING, а действие DNAT только для цепочек PREROUTING или OUTPUT.

На рисунке 2 изображены этапы обработки IP пакета из внутренней сети на шлюзе gw-server01 при SNAT на iptables. IP адрес и порт назначения при этом остаются неизменными.

Рисунок 2

IP пакет поступил на внутренний интерфейс eth1 сервера gw-server01. Так как IP назначения не принадлежит серверу gw-server01, IP пакет переходит к обработке цепочкой FORWARD.
После прохождения цепочки FORWARD, для IP пакета определяется исходящий сетевой интерфейс, с которого он должен быть отправлен, это отмечено желтым цветом
В конце IP пакет проходит цепочку POSTROUTING, в которой происходит подмена IP адреса источника, на IP адрес внешнего интерфейса eth0 сервера gw-server01

Приступим к настройке. Сначала нужно установить параметр ядра, который позволяет передавать пакеты между интерфейсами сервера. Для этого в файл /etc/sysctl.conf добавим переменную:

Чтобы применить изменения, выполним команду

здесь sysctl это команда, которая позволяет управлять параметрами ядра, ключ -p означает, что нужно считать параметры из файла.

Синтаксис команд

В отличии от iptables, тут довольно все просто:

# firewall-cmd -- --zone= options

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

Следующие опции могут быть использованы для манипуляций с зонами:

—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.

Пример: разрешаем ssh на нестандартном порте

Давайте разрешим доступ к серверу по ssh на порте 2234/tcp, а не на 22/tcp, как по-умолчанию. Попутно чуть-чуть коснемся selinux.

Сначала посмотрим, что вообще разрешено постоянно на нашем сервере:

# firewall-cmd —permanent —list-all public (default) interfaces: sources: services: ssh dhcpv6-client masquerade: no forward-ports: icmp-blocks: rich rules:

Я не использую пока ipv6, поэтому сразу уберу соотв. правило из firewalld:

# firewall-cmd —permanent —zone=public —remove-service=dhcpv6-client

Разрешим на постоянной основе (чтобы после перезагрузки не потерлось) соединение на порт 2234/tcp (на него повесим sshd):

# firewall-cmd —permanent —zone=public —add-port=2234/tcp

# firewall-cmd —zone=public —list-ports 2234/tcp

Ок, порт открыт. Редактируем конфиг sshd:

# nano /etc/ssh/sshd_config . port 2234 .

# systemctl restart sshd.service

Но SELinux, которую вы, надеюсь, не отключали, не даст подключиться к ssh на нестандартном порте (порт 2234/tcp для sshd — нестандартный). Вы можете этот шаг пропустить и проверить, как сработатет защита SELinux, а можете сразу все настроить:

# yum provides semanage # yum install policycoreutils-python # semanage port -a -t ssh_port_t -p tcp 2234

Вот теперь все ок. Проверяем подключение по ssh на новом порте. Если все ок, закрываем доступ к порту 22:

# firewall-cmd —permanent —zone=public —remove-service=ssh # firewall-cmd —reload

Смотрим, что получилось:

# firewall-cmd —list-all public (default, active) interfaces: sources: services: ports: 2234/tcp masquerade: no forward-ports: icmp-blocks: rich rules:

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

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

drop — блокировать все входящие пакеты, разрешить только исходящие
block — в отличие от предыдущего варианта отправителю пакета будет отправлено сообщение по блокировке его пакета;
public — поддерживаются входящие соединения только для ssh и dhclient;
external — поддерживает NAT для скрытия внутренней сети;
internal — разрешены сервисы ssh, samba, mdns и dhcp;
dmz — используется для изолированных сервров, у которых нет доступа к сети. Разрешено только подключение по SSH;
work — разрешенны сервисы ssh и dhcp;
home — аналогично internal;
trusted — всё разрешено.

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

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

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

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

Шаг 5 — Настройка разрешений SELinux для виртуальных хостов (рекомендуется)

SELinux настраивается для работы с конфигурацией Apache по умолчанию. Поскольку вы настроили пользовательскую директорию журналов в файле конфигурации виртуальных хостов, вы получите ошибку при попытке запуска службы Apache. Для устранения данной проблемы вам нужно обновить политики SELinux, чтобы разрешить Apache записывать данные в нужные файлы. SELinux обеспечивает повышенную безопасность для вашей среды CentOS 7, поэтому мы не рекомендуем полностью отключать модуль ядра.

Существуют различные способы настройки политики с учетом потребностей вашей среды, поскольку SELinux позволяет вам настраивать уровень безопасности. На этом шаге мы обсудим два метода внесения изменений в политики Apache: универсально и в конкретной директории. Изменение политики в директориях является более безопасным, поэтому мы рекомендуем использовать этот подход.

Универсальное изменение политик Apache

Универсальная настройка политики Apache позволит SELinux одинаковым образом использовать все процессы Apache, используя для этого булеву переменную

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

Запустите следующую команду для установки универсальной политики Apache:

Команда меняет значения булевых значений SELinux. Флаг будет обновлять значение времени начальной загрузки, а обновленное значение сохраняется между перезагрузками. — это булево значение, которое позволит SELinux рассматривать все процессы Apache как один тип, поэтому вы активировали его со значением .

Изменение политик Apache для директории

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

Вначале проверьте тип контекста, который SELinux указал для директории :

Эта команда формирует список и выводит контекст SELinux из директории. Вы увидите примерно следующий результат:

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

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

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

Вы можете вывести список контекста еще раз, чтобы посмотреть изменения:

Результат отражает обновленный тип контекста:

Теперь, когда директория использует тип , вы готовы протестировать вашу конфигурацию виртуального хоста.

Создание пользовательских зон

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

Например, создадим зону publicweb для веб-сервера. Для нее потребуется настроить дополнительную зону для DNS-сервиса, которая предоставляется в частной сети, назовем ее privateDNS.

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

sudo firewall-cmd --permanent --new-zone=publicweb
sudo firewall-cmd --permanent --new-zone=privateDNS

Проверим, что они присутствуют в постоянных правилах:

firewall-cmd --get-zones

Ответ:

block dmz drop external home internal public trusted work

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

sudo firewall-cmd --reload
firewall-cmd --get-zones

Ответ:

block dmz drop external home internal privateDNS public publicweb trusted work

Теперь можно присвоить новым зонам нужные сервисы и порты. Рекомендуется внести изменения в активный экземпляр и протестировать, а затем перенести их в постоянные правила. Например, в зону publicweb можно добавить SSH, HTTP и HTTPS.

sudo firewall-cmd --zone=publicweb --add-service=ssh
sudo firewall-cmd --zone=publicweb --add-service=http
sudo firewall-cmd --zone=publicweb --add-service=https
sudo firewall-cmd --zone=publicweb --list-all

Ответ:

publicweb
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: ssh http https
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

Аналогично добавим DNS-сервис к зоне privateDNS:

sudo firewall-cmd --zone=privateDNS --add-service=dns
sudo firewall-cmd --zone=privateDNS --list-all

Ответ:

privateDNS
  interfaces: 
  sources: 
  services: dns
  ports: 
  masquerade: no
  forward-ports: 
  icmp-blocks: 
  rich rules:

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

sudo firewall-cmd --zone=publicweb --change-interface=eth0
sudo firewall-cmd --zone=privateDNS --change-interface=eth1

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

sudo firewall-cmd --zone=publicweb --permanent --add-service=ssh
sudo firewall-cmd --zone=publicweb --permanent --add-service=http
sudo firewall-cmd --zone=publicweb --permanent --add-service=https
sudo firewall-cmd --zone=privateDNS --permanent --add-service=dns

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

sudo systemctl restart network
sudo systemctl reload firewalld

Убедитесь, что зоны были присвоены правильно:

firewall-cmd --get-active-zones

Ответ:

privateDNS
  interfaces: eth1
publicweb
  interfaces: eth0

И проверьте, что в обеих зонах работают нужные сервисы:

sudo firewall-cmd --zone=publicweb --list-services

Ответ:

http https ssh

sudo firewall-cmd --zone=privateDNS --list-services

Ответ:

dns

Пользовательские зоны созданы! Если вы хотите сделать одну из этих зон зоной по умолчанию для других интерфейсов, используйте параметр :

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

Как проверить открытые порты в Linux с соответствующим сервисом-процессом?

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

1. Проверка открытых портов в Linux с помощью команды NETSTAT

В основной форме команда NetStat выводит на экран или печатает информацию о сетевых подключениях и таблицу маршрутизации и т.д. Однако та же команда вместе с параметром ниже может быть использована для проверки открытых портов в Linux.

Команда:

Вывод:

Вот команда выше отображает все выходные TCP, а также порты UDP. В случае, если вы хотите отфильтровать его дальше, допустим, вы хотите узнать, процесс или услугу, используемую по порту 80, следуют использовать команду ниже.

В приведенной выше командной порт используется HTTPd службы с PID 1086.

Утилита lsof в основном отображает список открытых файлов. Однако с некоторыми настройками параметров мы можем в состоянии также проверить открытые порты в Linux. По умолчанию она не установлена в системе, пожалуйста, следуйте ниже набором команд для установки в соответствии с дистрибутивом Linux.

Переназначить интерфейс в другую зону

Выберите интерфейс и выполните

firewall-cmd —permanent —zone=public —remove-interface=enp0s10

The interface is under control of NetworkManager and already bound to the default zone
The interface is under control of NetworkManager, setting zone to default.
success

Интерфейс enp0s8 будет добавлен в зону internal, enp0s10 в external

firewall-cmd —permanent —zone=internal —add-interface=enp0s8

The interface is under control of NetworkManager, setting zone to ‘internal’.
success

firewall-cmd —permanent —zone=external —add-interface=enp0s10

The interface is under control of NetworkManager, setting zone to ‘external’.
success

Осталось перезагрузить firewalld и проверить результат

systemctl restart firewalld

firewall-cmd —get-active-zones

internal
interfaces: enp0s8
external
interfaces: enp0s10
public
interfaces: enp0s9

Можно задать зону по умолчанию. В данном примере дефолтной зоной назначена external

firewall-cmd —set-default-zone=external

success

firewall-cmd —get-default-zone

external

Каждую зону можно изучить отдельно

firewall-cmd —list-all —zone=external

external (active)
target: default
icmp-block-inversion: no
interfaces: enp0s10
sources:
services: ssh
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:

Установка TigerVNC

Теперь давайте разберемся, как мы можем установить и настроить TigerVNC в CentOS. Первое, что нужно сделать, это установить программу TigerVNC Server, открыв сеанс терминала и введя следующую команду с правами root:

Сразу после этого вам необходимо создать отдельного пользователя VNC, с которого и будет осуществляться подключение (с выделенным паролем). Для этого введите следующее:

Важно: никогда не делайте этого от имени root-пользователя — это создаст серьезную угрозу безопасности вашей системы. Лучшим решением будет оставить пользователя root без доступа к VNC и настроить выделенную учетную запись с ограниченными правами

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

(первая строка может быть опущена, если мы уже вошли под пользователем vncuser заранее).

Следующее, что нужно сделать, это создать файл конфигурации VNC для vncuser. Самый быстрый способ сделать это — скопировать файл общего шаблона VNC, расположенный в папке /lib/systemd/system/, — и затем изменить его:

Цифра «1», которую мы добавили в новое имя файла, — это номер дисплея, который будет использоваться для этого конкретного экземпляра службы

Это важно знать, потому что он также определит порт TCP, который будет использоваться нашим VNC-сервером, равным 5900 + номер дисплея. Первый будет 5901, затем 5902 и так далее

Сразу после копирования вам нужно отредактировать новый файл с помощью Vi, Nano или другого текстового редактора, и заменить на имя пользователя, созданного недавно (в нашем случае vncuser). Вот как файл должен выглядеть после обновления (за исключением длинной закомментированной части в начале):

Как только вы это сделаете, можете перезагрузить демон VNC и запустить vncserver@1 с помощью следующих команд:

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

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

Еще одна проверка, которую вы можете выполнить, прежде чем пытаться подключиться к серверу, — это посмотреть на активные сетевые сокеты с помощью команды ss: если все работает правильно, вы должны увидеть, что VNC-сервер работает и использует порт TCP 5901. Выполните команду:

Результат должен быть следующим:

Если вы видите это, значит все настроено правильно.

Настройка шлюза по-умолчанию в CentOS 8

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

netstat -nr

Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.253.2 0.0.0.0 UG 0 0 0 ens36
192.168.31.0 0.0.0.0 255.255.255.0 U 0 0 0 ens33
192.168.253.0 0.0.0.0 255.255.255.0 U 0 0 0 ens36