Въведение във Firewalld: Динамично управление на защитната стена в Linux

Firewalld е демон за управление на защитна стена в потребителското пространство за Linux, който предоставя динамичен, базиран на зони интерфейс над бекендовете за филтриране на пакети на ниво ядро iptables и nftables. За разлика от статичните инструменти за защитна стена, които изискват пълно рестартиране на услугата за прилагане на промени в правилата, Firewalld модифицира правилата на netfilter в движение — запазвайки активните TCP сесии и елиминирайки престоя по време на актуализации на политиките.

Това ръководство обхваща всеки оперативен слой на Firewalld: неговия архитектурен модел, абстракциите на зони и услуги, богатите правила, конфигурацията по време на изпълнение спрямо постоянната конфигурация, и точните команди, необходими за сигурно управление на производствен сървър.

Защо Firewalld замени статичните работни процеси с iptables

Традиционното управление на iptables означава писане на правила в shell скриптове или плоски конфигурационни файлове, след което изчистване и презареждане на целия набор от правила при всяка необходима промяна. На натоварен сървър, този цикъл на изчистване и презареждане прекъсва текущите връзки и въвежда кратък прозорец, в който не е активно никакво филтриране.

Firewalld решава това чрез активиран от D-Bus демон (firewalld), който поддържа авторитетното състояние на правилата и комуникира промените към ядрото постепенно. Резултатът е атомарни актуализации на правилата без прекъсване на връзките — критично за всеки сървър, изпълняващ постоянни натоварвания като бази данни, VPN тунели или дълготрайни API връзки.

Когато предоставяте среда за VPS Хостинг и трябва да я защитите без рестартиране или прекъсване на услуги, Firewalld е естественият оперативен избор за дистрибуции от семейството на RHEL и много дистрибуции от семейството на Debian.

Основна архитектура: Как Firewalld взаимодейства с ядрото

Разбирането на стека под Firewalld предотвратява неправилна конфигурация и помага при отстраняване на неочаквано поведение.

User Space
┌─────────────────────────────────────────────┐
│ firewall-cmd / firewall-config / D-Bus API  │
└────────────────────┬────────────────────────┘
                     │ D-Bus
┌────────────────────▼────────────────────────┐
│              firewalld daemon               │
│  (zone engine, service definitions, rich    │
│   rule parser, direct rule passthrough)     │
└────────────────────┬────────────────────────┘
                     │ nftables / iptables backend
Kernel Space
┌────────────────────▼────────────────────────┐
│           netfilter (kernel module)         │
└─────────────────────────────────────────────┘

От RHEL 8 и Fedora 32, Firewalld използва по подразбиране бекенда nftables. На по-стари системи или изрично конфигурирани среди използва бекенда iptables. Можете да проверите или замените активния бекенд в /etc/firewalld/firewalld.conf чрез директивата FirewallBackend.

Критичен проблем: Никога не смесвайте директни команди iptables или nft с Firewalld на същия интерфейс. Firewalld притежава таблиците на netfilter, които създава; ръчно вмъкнатите правила извън демона ще бъдат мълчаливо презаписани при следващото презареждане.

Ключови концепции в Firewalld

Зони

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

Firewalld се доставя със следните предварително дефинирани зони, наредени от най-разрешителна до най-малко разрешителна:

Архитектурен нюанс: Зона може да бъде обвързана с мрежов интерфейс (напр. eth0) или с изходен CIDR (напр. 192.168.1.0/24). Обвързването по източник има предимство пред обвързването по интерфейс, което ви позволява да прилагате различни политики към трафик, пристигащ на същия физически интерфейс от различни подмрежи — модел, разпространен в многонаемни или контейнеризирани среди.

Услуги

Една услуга в Firewalld е XML дефиниционен файл, съхраняван под /usr/lib/firewalld/services/ (системни настройки по подразбиране) или /etc/firewalld/services/ (потребителски замени). Всеки файл декларира портовете, протоколите и незадължителните помощни модули, необходими за именовано приложение.

Например, дефиницията на услугата https отваря TCP порт 443 и не зарежда допълнителни помощници на ядрото. Услугата ftp отваря TCP порт 21 и зарежда помощника nf_conntrack_ftp за обработка на динамичното договаряне на портове на FTP канала за данни.

Използването на имена на услуги вместо необработени номера на портове прави вашата политика на защитна стена самодокументираща се и намалява риска от печатни грешки, които оставят порт непреднамерено отворен или затворен.

За да изброите всички налични дефиниции на услуги на вашата система:

firewall-cmd --get-services

За да прегледате XML дефиницията на конкретна услуга:

cat /usr/lib/firewalld/services/https.xml

Богати правила

Богатите правила разширяват модела на зони с условна логика, която простата абстракция услуга/порт не може да изрази. Те поддържат съпоставяне по адреси на източници и дестинации, диапазони от портове, протоколи, времеви прозорци и състояние на връзката, и могат да задействат действия включително accept, drop, reject, log и audit.

Синтаксисът на богатите правила следва структурирана граматика:

rule [family="ipv4|ipv6"]
  [source address="addr[/mask]" [invert="true"]]
  [destination address="addr[/mask]" [invert="true"]]
  [service name="service-name"] | [port port="port" protocol="tcp|udp"]
  [log [prefix="prefix"] [level="level"] [limit value="rate/duration"]]
  [audit]
  [accept|drop|reject [type="reject-type"]]

Практически пример — ограничаване на скоростта на опитите за влизане в SSH до 3 в минута от всеки единичен IPv4 източник, след което регистриране и изпускане на излишъка:

firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  log prefix="SSH_RATELIMIT " level="warning" limit value="3/m"
  accept' --permanent

firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  drop' --permanent

Краен случай: Редът на богатите правила има значение. Firewalld оценява богатите правила в реда, в който са добавени в рамките на зона. Ако добавите широко правило drop преди конкретно правило accept, правилото accept никога няма да бъде достигнато. Винаги добавяйте първо по-конкретните правила.

Конфигурация по време на изпълнение спрямо постоянна конфигурация

Това е най-важното оперативно разграничение в Firewalld и източникът на най-честите производствени грешки.

Работен процес с най-добри практики за производствени промени:

1. Приложете правилото само по време на изпълнение (без флага --permanent) и проверете дали се държи според очакванията.
2. Ако е правилно, приложете същото правило с --permanent, за да го запишете на диска.
3. Изпълнете firewall-cmd --reload, за да синхронизирате постоянната конфигурация в състоянието по време на изпълнение и потвърдете паритета.

Този работен процес предотвратява класическия сценарий, при който администратор добавя правило --permanent, презарежда и открива, че се е заключил от SSH — защото тестът по време на изпълнение би разкрил проблема, преди да стане постоянен.

Инсталиране и активиране на Firewalld

Firewalld е инсталиран по подразбиране на RHEL, CentOS Stream, Fedora, AlmaLinux и Rocky Linux. На Debian и Ubuntu трябва да бъде инсталиран изрично.

RHEL / CentOS Stream / AlmaLinux / Rocky Linux:

sudo dnf install firewalld

Debian / Ubuntu:

sudo apt-get update && sudo apt-get install firewalld

Забележка за потребителите на Ubuntu: Ако ufw е активен, деактивирайте го преди активиране на Firewalld, за да избегнете конфликтни правила на netfilter:

sudo ufw disable
sudo systemctl disable ufw

Стартирайте и активирайте демона:

sudo systemctl start firewalld
sudo systemctl enable firewalld

Проверете дали демонът работи и бекендът на ядрото е активен:

sudo firewall-cmd --state
sudo firewall-cmd --info-zone=public

Основни команди на Firewalld

Проверка на текущото състояние

Проверка на статуса на демона:

sudo firewall-cmd --state

Изброяване на всички активни зони с техните присвоени интерфейси и източници:

sudo firewall-cmd --get-active-zones

Показване на пълния набор от правила за конкретна зона:

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

Показване на пълния набор от правила за всички зони едновременно:

sudo firewall-cmd --list-all-zones

Управление на зоната по подразбиране

Зоната по подразбиране се прилага към всеки интерфейс, който не е изрично присвоен към друга зона:

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

Присвояване на интерфейс към зона

sudo firewall-cmd --zone=internal --change-interface=eth1 --permanent
sudo firewall-cmd --reload

Проблем: На системи, използващи NetworkManager, присвояванията интерфейс-към-зона, направени чрез firewall-cmd, могат да бъдат заменени от профила на връзката на NetworkManager при повторно свързване. Задайте зоната постоянно в профила на връзката на NetworkManager:

nmcli connection modify "Wired connection 1" connection.zone internal

Добавяне и премахване на услуги

Разрешаване на HTTP в публичната зона по време на изпълнение:

sudo firewall-cmd --zone=public --add-service=http

Направете го постоянно:

sudo firewall-cmd --zone=public --add-service=http --permanent

Премахване на услуга:

sudo firewall-cmd --zone=public --remove-service=http --permanent

Отваряне и затваряне на конкретни портове

Отваряне на TCP порт 8080 по време на изпълнение:

sudo firewall-cmd --zone=public --add-port=8080/tcp

Постоянно отваряне на диапазон от UDP портове:

sudo firewall-cmd --zone=public --add-port=60000-61000/udp --permanent

Премахване на порт:

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

Разрешаване и блокиране на IP адреси

Разрешаване на целия трафик от доверена подмрежа за управление:

sudo firewall-cmd --zone=trusted --add-source=10.0.0.0/24 --permanent

Блокиране на целия трафик от конкретен IP (изпускане по източник):

sudo firewall-cmd --zone=drop --add-source=203.0.113.45/32 --permanent

Пренасочване на портове

Пренасочване на външен TCP порт 2222 към вътрешен SSH порт 22 (полезно за скриване на SSH порта по подразбиране без промяна на sshd_config):

sudo firewall-cmd --zone=public --add-forward-port=port=2222:proto=tcp:toport=22 --permanent
sudo firewall-cmd --reload

IP маскиране (NAT)

Активиране на маскиране на външната зона, за да позволи на VPS, действащ като шлюз, да извършва NAT на трафик от частна подмрежа:

sudo firewall-cmd --zone=external --add-masquerade --permanent
sudo firewall-cmd --reload

Презареждане и синхронизиране на конфигурацията

Прилагане на всички постоянни промени към работещото състояние без прекъсване на връзките:

sudo firewall-cmd --reload

Извършване на пълно рестартиране (прекъсва всички връзки — използвайте само при извънредни ситуации):

sudo systemctl restart firewalld

Създаване на персонализирани зони и дефиниции на услуги

Персонализирана зона

sudo firewall-cmd --new-zone=management --permanent
sudo firewall-cmd --zone=management --add-source=10.10.0.0/16 --permanent
sudo firewall-cmd --zone=management --add-service=ssh --permanent
sudo firewall-cmd --zone=management --add-service=cockpit --permanent
sudo firewall-cmd --reload

Дефиниция на персонализирана услуга

Създаване на файл за услуга за персонализирано приложение, слушащо на TCP 9200 (напр. Elasticsearch):

sudo nano /etc/firewalld/services/elasticsearch.xml

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Elasticsearch</short>
  <description>Elasticsearch HTTP API and transport port</description>
  <port protocol="tcp" port="9200"/>
  <port protocol="tcp" port="9300"/>
</service>

sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --add-service=elasticsearch --permanent
sudo firewall-cmd --reload

Firewalld срещу алтернативи: Избор на правилния инструмент

За екипи, управляващи Dedicated Servers в мащаб, D-Bus API на Firewalld позволява програмно управление на правила от инструменти за управление на конфигурации като Ansible (модул ansible.posix.firewalld) или Puppet, което е значително оперативно предимство пред поддържането на необработени скриптове iptables.

Практически модели за укрепване на сигурността

Защита на уеб сървър

Типична конфигурация за сървър, изпълняващ HTTPS с SSH, ограничен до IP за управление:

# Set the default zone
sudo firewall-cmd --set-default-zone=public --permanent

# Allow HTTPS globally
sudo firewall-cmd --zone=public --add-service=https --permanent

# Allow HTTP only to redirect to HTTPS (optional)
sudo firewall-cmd --zone=public --add-service=http --permanent

# Restrict SSH to a specific management IP only
sudo firewall-cmd --zone=public --remove-service=ssh --permanent
sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  source address="198.51.100.10/32"
  accept' --permanent

sudo firewall-cmd --reload

Ако изпълнявате уеб сървър заедно с внедряване на SSL Сертификати, осигуряването на отворен порт 443 в правилната зона преди издаване на сертификата (особено за ACME HTTP-01 или TLS-ALPN-01 предизвикателства) е предварително условие, което често се пренебрегва.

Защита на пощенски сървър

За сървъри, изпълняващи стекове за Имейл Хостинг (Postfix, Dovecot), необходимият набор от услуги е:

sudo firewall-cmd --zone=public --add-service=smtp --permanent
sudo firewall-cmd --zone=public --add-service=smtps --permanent
sudo firewall-cmd --zone=public --add-service=imap --permanent
sudo firewall-cmd --zone=public --add-service=imaps --permanent
sudo firewall-cmd --zone=public --add-service=pop3s --permanent
sudo firewall-cmd --reload

Регистриране на изпуснати пакети за криминалистика

sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  log prefix="DROPPED_PUBLIC " level="warning" limit value="10/m"
  drop' --permanent
sudo firewall-cmd --reload

Регистрационните записи се появяват в /var/log/messages или в журнала на systemd (journalctl -k -g DROPPED_PUBLIC). Ограничете скоростта на регистриране (както е показано по-горе), за да предотвратите наводняване на регистрационните файлове при DDoS сценарий.

Firewalld на VPS, управляван от cPanel

Ако използвате VPS с cPanel, имайте предвид, че cPanel инсталира и управлява собствен слой на защитна стена (по подразбиране CSF/LFD). Изпълнението на Firewalld заедно с CSF без изрична координация ще доведе до конфликтни правила на netfilter. Препоръчителният подход е да изберете един слой за управление на защитна стена на сървър и да деактивирате другия, или да използвате интерфейса за директно предаване на правила на Firewalld за интегриране с изискванията на cPanel.

Отстраняване на често срещани проблеми с Firewalld

Проблем: Правило, добавено с --permanent, не е в сила.

Причина: Постоянните правила изискват презареждане, за да влязат в работното състояние.

Решение:

sudo firewall-cmd --reload

Проблем: SSH връзката е прекъсната след промяна на защитната стена.

Причина: Услугата SSH е премахната от активната зона, или богато правило drop е добавено преди правилото accept.

Решение: Достъпете сървъра чрез извънлентова конзола (VNC/KVM конзолата на вашия хостинг доставчик), след което възстановете SSH услугата:

sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --reload

Проблем: firewall-cmd връща FirewallD is not running.

Причина: Демонът е срещнал грешка или никога не е бил стартиран.

Решение:

sudo systemctl start firewalld
sudo journalctl -u firewalld -n 50

Проблем: Правилата изглеждат правилни, но трафикът все още е блокиран.

Причина: Съществува конфликтно правило iptables или nft извън управляваните таблици на Firewalld, или SELinux/AppArmor блокира връзката на слоя на приложението.

Решение: Проверете за ръчни правила и откази на SELinux:

sudo iptables -L -n -v
sudo ausearch -m avc -ts recent

Проблем: Интерфейсът не е присвоен към очакваната зона след рестартиране.

Причина: Профилът на връзката на NetworkManager заменя присвояването на интерфейс от Firewalld.

Решение: Задайте зоната в профила на NetworkManager, както е описано в раздела за присвояване на интерфейс по-горе.

Матрица за вземане на решения и техническа контролна листа

Използвайте тази контролна листа преди внедряване на Firewalld на производствен сървър:

• Потвърдете активния бекенд на защитната стена (FirewallBackend в /etc/firewalld/firewalld.conf) съответства на поддръжката на nftables/iptables на вашето ядро.
• Проверете дали няма конфликтни инструменти за защитна стена (UFW, CSF, директни скриптове iptables), активни на същите интерфейси.
• Присвоете изрично всеки мрежов интерфейс към зона — никога не разчитайте единствено на зоната по подразбиране за сървъри с множество домашни адреси.
• Прилагайте всички промени първо по време на изпълнение, проверявайте свързаността, след което ги потвърждавайте с --permanent и --reload.
• Ограничете SSH достъпа до конкретни изходни IP адреси чрез богати правила, преди да премахнете SSH услугата от публичната зона.
• Добавете богати правила за ограничаване на скоростта за всички публично изложени услуги за удостоверяване (SSH, SMTP, HTTPS крайни точки за влизане).
• Активирайте регистриране за зоната drop с ограничение на скоростта, за да улавяте разузнавателна информация за заплахи без наводняване на хранилището.
• За сървъри, управлявани чрез VPS Контролни панели, потвърдете, че необходимите портове на контролния панел са в белия списък, преди да приложите ограничителна политика по подразбиране.
• Тествайте постоянната конфигурация, като изпълните firewall-cmd --reload и незабавно проверите дали всички критични услуги остават достъпни.
• Документирайте всяка персонализирана зона, богато правило и дефиниция на услуга в система за контрол на версиите заедно с вашата инфраструктура като код.

ЧЗВ

Каква е разликата между --reload и sudo systemctl restart firewalld?

--reload прилага постоянни промени в конфигурацията към работещия демон без прекъсване на установените връзки. systemctl restart напълно рестартира процеса на демона, което изчиства всички правила на netfilter и кратко прекъсва активните връзки. Винаги предпочитайте --reload на производствени системи.

Могат ли Firewalld и iptables да съществуват едновременно на същия сървър?

Не безопасно на същия интерфейс. Firewalld управлява собствените си вериги на netfilter; директните команди iptables, които модифицират същите вериги, ще бъдат презаписани при следващото презареждане на Firewalld. Ако трябва да вмъкнете персонализирани правила, използвайте интерфейса --direct на Firewalld или богати правила вместо това.

Как да направя постоянно правило по време на изпълнение без да го въвеждам отново?

Няма вградена команда за промотиране на всички правила по време на изпълнение към постоянни в една стъпка. Правилният работен процес е да приложите всяко правило два пъти — веднъж без --permanent за тестване, след това с --permanent за постоянство — последвано от --reload. Алтернативно, използвайте firewall-cmd --runtime-to-permanent (налично в Firewalld 0.9+), за да направите снимка на текущото работно състояние на диска.

Защо присвояването на зона се нулира след повторно свързване на NetworkManager?

NetworkManager съхранява присвояванията на зони в собствените си профили на връзки. Присвояването firewall-cmd --change-interface е временно заместване по време на изпълнение, което NetworkManager може да презапише. Запазете присвояването постоянно с nmcli connection modify <profile-name> connection.zone <zone>.

Поддържа ли Firewalld IPv6?

Да. Firewalld управлява едновременно правилата на netfilter за IPv4 и IPv6. Богатите правила изискват атрибута family="ipv6" за специфично насочване към IPv6 трафик. Правилата за зони и услуги се прилагат към двете адресни семейства по подразбиране, освен ако дефиницията на услугата или богатото правило не ограничава обхвата.