Как да конфигурирате правила за защитна стена: Пълно техническо ръководство

Правило на защитна стена е политически запис, който инструктира двигателя на защитната стена да разрешава, отказва или регистрира мрежовия трафик въз основа на дефинирани критерии като IP адрес на източника/дестинацията, номер на порта, транспортен протокол и посока на трафика. Правилно конфигурираните правила на защитната стена формират основния слой на прилагане между вашата инфраструктура и публичния интернет, което ги прави единственият най-важен контрол за сигурност на всеки сървър или мрежово устройство.

Това ръководство обхваща архитектурата на правилата на защитната стена, UFW на Linux, firewalld, Windows Defender Firewall, nftables и оперативните практики, които разграничават защитената среда от неправилно конфигурираната.

Какво всъщност контролират правилата на защитната стена

Всяко правило в набора от правила на защитната стена се оценява спрямо пет основни атрибута на пакета, обикновено наричани 5-кортеж:

• IP адрес на източника — оригиниращият хост или подмрежа (напр., 192.168.1.0/24)
• IP адрес на дестинацията — целевият хост или диапазон
• Порт на източника — ефемерният порт от страната на инициатора
• Порт на дестинацията — портът на услугата от страната на получателя (напр., 443 за HTTPS, 22 за SSH)
• Протокол — TCP, UDP, ICMP или номер на протокол

Освен 5-кортежа, защитните стени с проследяване на състоянието също проследяват състоянието на връзката (NEW, ESTABLISHED, RELATED, INVALID), което им позволява да разрешават обратния трафик за изходящи връзки, без да пишат изрични входящи правила за всеки отговор.

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

За практически всички сървърни внедрявания — включително VPS Хостинг и Dedicated сървъри — защитната стена на хоста с проследяване на състоянието е правилният избор по подразбиране.

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

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

• Широко правило ALLOW, поставено над конкретно правило DENY, ще го замени безшумно.

DENY ALL в началото на верига блокира всичко, независимо от това, което следва.
Дублирани или засенчени правила губят цикли на обработка и създават объркване при одит.

Най-добра практика: Винаги поставяйте конкретни правила преди общите. Поставяйте изрични правила DENY за известни злонамерени източници в горната част, последвани от конкретни правила ALLOW за доверени услуги, и завършвайте всяка верига с политика DENY по подразбиране.
Конфигуриране на правила на защитната стена на Linux с UFW
UFW (Uncomplicated Firewall) е интерфейс за iptables и nftables на системи, базирани на Debian/Ubuntu. Той абстрахира синтаксиса на веригите на ниско ниво в четими от човека команди, като същевременно запазва пълен контрол върху филтрирането по порт, протокол, IP и интерфейс.
Стъпка 1: Инсталиране и активиране на UFW
UFW е предварително инсталиран на Ubuntu. Проверете статуса му преди активиране:
sudo ufw status verbose
Ако е неактивен, активирайте го:
sudo ufw enable
Критично предупреждение: Ако сте свързани чрез SSH и все още не сте разрешили порт 22, активирането на UFW ще ви изключи. Винаги разрешавайте SSH преди активиране на защитната стена на отдалечен сървър.
Стъпка 2: Задаване на политики по подразбиране
Политиките по подразбиране определят какво се случва с трафика, който не съответства на нито едно изрично правило. Сигурната базова линия е:
sudo ufw default deny incoming
sudo ufw default allow outgoing
Това блокира всички нежелани входящи връзки, като същевременно разрешава целия изходящ трафик. Ако вашата политика за сигурност изисква филтриране на изходящия трафик (напр., предотвратяване на ексфилтрация на данни или C2 обратни извиквания), променете изходящото поведение по подразбиране:
sudo ufw default deny outgoing
След това изрично разрешете само изходящите дестинации, от които се нуждае вашето приложение.
Стъпка 3: Разрешаване на конкретни услуги и портове
UFW поддържа имена на услуги от /etc/services или изрични номера на портове:
# Allow SSH by service name
sudo ufw allow ssh

# Allow HTTP and HTTPS
sudo ufw allow http
sudo ufw allow https

# Allow a custom application port
sudo ufw allow 8080/tcp

# Allow a UDP service (e.g., DNS resolver)
sudo ufw allow 53/udp
За разрешаване на диапазон от портове (напр., пасивен FTP):
sudo ufw allow 49152:65535/tcp
Стъпка 4: Ограничаване на достъпа до конкретни IP адреси на източници
Излагането на административни портове на 0.0.0.0/0 е водеща причина за компрометиране чрез груба сила. Заключете SSH към известен IP за управление:
sudo ufw allow from 203.0.113.50 to any port 22 proto tcp
За разрешаване на цяла подмрежа за управление:
sudo ufw allow from 10.0.0.0/8 to any port 22 proto tcp
Стъпка 5: Отказване на трафик от конкретни IP адреси или подмрежи
Блокиране на известен злонамерен IP:
sudo ufw deny from 198.51.100.77
Блокиране на цяла подмрежа (напр., географски блок или диапазон на злоупотребяващ ASN):
sudo ufw deny from 198.51.100.0/24
Граничен случай: Правилата deny на UFW изпращат TCP RST или ICMP port-unreachable отговор, което потвърждава съществуването на хоста. Използвайте reject за безшумно отхвърляне на пакети вместо това:
sudo ufw reject from 198.51.100.0/24
Стъпка 6: Преглед на активните правила
sudo ufw status numbered
Флагът numbered присвоява индекс на всяко правило, което е необходимо за целенасочено изтриване:
[ 1] 22/tcp                     ALLOW IN    203.0.113.50
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere
За пълен подробен изход, включващ политиките по подразбиране и свързванията на интерфейсите:
sudo ufw status verbose
Стъпка 7: Изтриване на правила
Изтриване по номер на правило (предпочитано — избягва двусмислие):
sudo ufw delete 3
Изтриване по спецификация на правило:
sudo ufw delete allow 8080/tcp
Стъпка 8: Презареждане и запазване на правилата
Правилата на UFW се запазват автоматично при рестартиране. След масови промени, презаредете без прекъсване на съществуващите връзки:
sudo ufw reload
За пълно нулиране на всички правила и започване от нулата:
sudo ufw reset
Разширен UFW: Профили на приложения
UFW поддържа именувани профили на приложения, съхранявани в /etc/ufw/applications.d/. Това ви позволява да дефинирате правила за множество портове под едно единствено име:
sudo ufw app list
sudo ufw allow 'Nginx Full'
sudo ufw app info 'Nginx Full'
Създаване на персонализиран профил за Node.js API:
[NodeAPI]
title=Node.js API Server
description=Custom Node.js application
ports=3000,3001/tcp
След това го приложете:
sudo ufw allow NodeAPI
Конфигуриране на правила на защитната стена с firewalld (RHEL/CentOS/Fedora)
firewalld използва модел, базиран на зони, а не плосък набор от правила. Всеки мрежов интерфейс се присвоява към зона (напр., public, internal, dmz), и правилата се прилагат за всяка зона. Това е архитектурно по-гъвкаво за сървъри с множество мрежови интерфейси.
Основни операции с firewalld
# Check status
sudo firewall-cmd --state

# List all active zones and their interfaces
sudo firewall-cmd --get-active-zones

# List rules in the public zone
sudo firewall-cmd --zone=public --list-all
Разрешаване и премахване на услуги
# Allow HTTPS permanently
sudo firewall-cmd --zone=public --add-service=https --permanent

# Allow a custom port
sudo firewall-cmd --zone=public --add-port=8443/tcp --permanent

# Remove a service
sudo firewall-cmd --zone=public --remove-service=http --permanent

# Reload to apply permanent changes
sudo firewall-cmd --reload
Богати правила за политики, специфични за IP
Богатите правила firewalld осигуряват детайлността на iptables с по-четим синтаксис:
# Allow SSH only from a specific IP
sudo firewall-cmd --zone=public 
  --add-rich-rule='rule family="ipv4" source address="203.0.113.50" service name="ssh" accept' 
  --permanent

# Block all traffic from a subnet
sudo firewall-cmd --zone=public 
  --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" drop' 
  --permanent

sudo firewall-cmd --reload
Конфигуриране на правила на защитната стена с nftables
nftables е съвременната замяна на iptables, предлагаща унифицирана рамка за IPv4, IPv6, ARP и мостово филтриране със значително по-добра производителност и атомарна замяна на правила.
Основен набор от правила на nftables
# Flush existing ruleset
sudo nft flush ruleset

# Create a basic filtering table
sudo nft add table inet filter

# Add input, forward, and output chains
sudo nft add chain inet filter input { type filter hook input priority 0 ; policy drop ; }
sudo nft add chain inet filter forward { type filter hook forward priority 0 ; policy drop ; }
sudo nft add chain inet filter output { type filter hook output priority 0 ; policy accept ; }

# Allow established and related connections
sudo nft add rule inet filter input ct state established,related accept

# Allow loopback
sudo nft add rule inet filter input iif lo accept

# Allow SSH from a specific IP
sudo nft add rule inet filter input ip saddr 203.0.113.50 tcp dport 22 accept

# Allow HTTP and HTTPS from anywhere
sudo nft add rule inet filter input tcp dport { 80, 443 } accept
За да направите набора от правила постоянен, запазете го в конфигурационния файл по подразбиране:
sudo nft list ruleset > /etc/nftables.conf
sudo systemctl enable nftables
Конфигуриране на правила на защитната стена на Windows
Windows Defender Firewall с разширена защита предоставя интерфейси както за GUI, така и за командния ред (netsh, PowerShell) за управление на правила.
Използване на GUI

Отворете Windows Defender Firewall с разширена защита чрез wf.msc.
Изберете Входящи правила или Изходящи правила в левия панел.
Кликнете върху Ново правило в десния панел.
Изберете типа на правилото:


Порт — филтриране по номер на TCP/UDP порт
Програма — филтриране по път на изпълнимия файл
Предварително дефинирано — използване на вградена дефиниция на Windows услуга
Персонализирано — пълен контрол върху всички параметри


Посочете порта или програмата, изберете Разрешаване или Блокиране, изберете приложимите профили (Домейн, Частен, Публичен) и наименувайте правилото.

Използване на PowerShell (препоръчително за автоматизация)
# Allow inbound HTTPS
New-NetFirewallRule -DisplayName "Allow HTTPS Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

# Allow inbound SSH (Windows OpenSSH)
New-NetFirewallRule -DisplayName "Allow SSH Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow `
  -RemoteAddress 203.0.113.50

# Block inbound traffic from a specific IP
New-NetFirewallRule -DisplayName "Block Malicious IP" `
  -Direction Inbound -RemoteAddress 198.51.100.77 -Action Block

# View all inbound rules
Get-NetFirewallRule -Direction Inbound | Select-Object DisplayName, Enabled, Action

# Remove a rule by name
Remove-NetFirewallRule -DisplayName "Allow HTTPS Inbound"
Използване на netsh (наследен, но широко поддържан)
:: Allow inbound port 443
netsh advfirewall firewall add rule name="Allow HTTPS" protocol=TCP dir=in localport=443 action=allow

:: Block a specific IP
netsh advfirewall firewall add rule name="Block IP" dir=in remoteip=198.51.100.77 action=block

:: Delete a rule
netsh advfirewall firewall delete rule name="Allow HTTPS"
Критични клопки и гранични случаи при правилата на защитната стена
Имплицитното разрешение за ESTABLISHED трафик
При защитни стени с проследяване на състоянието, неуспехът да се разрешат изрично ESTABLISHED и RELATED връзки в входящата верига ще прекъсне всички сесии, инициирани от изходящия трафик (напр., apt update, curl, DNS заявки), дори когато изходящата верига е зададена на ACCEPT. Това е най-честата неправилна конфигурация при необработени настройки на iptables или nftables.
# This rule MUST appear before any DROP rules in the input chain
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Паритет на IPv6
Много администратори конфигурират внимателно правилата за IPv4 и напълно забравят IPv6. Ако вашият сървър има IPv6 адрес и поддръжката на IPv6 в UFW не е активирана, атакуващият може да заобиколи всички IPv4 правила, като се свърже чрез ::. Проверете дали /etc/default/ufw съдържа:
IPV6=yes
Интерфейс за обратна връзка
Винаги изрично разрешавайте трафика на интерфейса за обратна връзка (lo). Много локални услуги (бази данни, опашки за съобщения, вътрешни API) комуникират чрез 127.0.0.1 или ::1. Блокирането на обратната връзка прекъсва комуникацията между процесите безшумно.
sudo ufw allow in on lo
sudo ufw allow out on lo
Ограничаване на скоростта за предотвратяване на груба сила
UFW поддържа ограничаване на скоростта на връзките по естествен начин, което е от съществено значение за SSH и други услуги за удостоверяване:
sudo ufw limit ssh
Това позволява максимум 6 опита за връзка на 30 секунди от един IP преди задействане на автоматично временно блокиране — лека алтернатива на fail2ban за основни внедрявания.
ICMP и диагностичен трафик
Блокирането на целия ICMP е честа, но контрапродуктивна практика. Тя прекъсва ping, traceroute, MTU path discovery и някои протоколи за маршрутизиране. Правилният подход е да се разрешат конкретни типове ICMP:

Тип 0 (Echo Reply) и Тип 8 (Echo Request) — за ping

Блокирайте Тип 17 (Address Mask Request) и Тип 18 (Address Mask Reply), които нямат легитимна съвременна употреба.

Правила на защитната стена и хостинг среди

Правилната стратегия за защитна стена зависи в голяма степен от вашия инфраструктурен слой.

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

При VPS с cPanel, cPanel/WHM включва ConfigServer Security & Firewall (CSF), който обвива iptables с интерфейс на високо ниво, автоматично откриване на груба сила и поддръжка на port knocking. CSF е стандартното решение за защитна стена за cPanel среди и трябва да се използва за предпочитане пред необработения UFW на тези системи.

При неуправляван VPS Хостинг или Dedicated сървъри, имате пълен контрол върху защитната стена на ядрото. Тук UFW, firewalld и nftables са подходящите инструменти. Базовата линия за защита трябва да включва:

• Политика за отказване по подразбиране на входящия трафик
• SSH ограничен до известни IP адреси за управление или VPN шлюз
• Всички несъществени портове затворени
• Ограничаване на скоростта на портовете за удостоверяване
• Регистрирането активирано за отказан трафик

Ако изпълнявате GPU натоварвания или ML услуги за извод на GPU Хостинг, обърнете особено внимание на портовете, изложени от Jupyter notebooks, TensorBoard и API за обслужване на модели — те са честа цел на ботове за криптомайнинг, които сканират за отворени портове с високи номера.

Контролен списък за одит и поддръжка на правила на защитната стена

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

Задачи за одит, които трябва да се извършват тримесечно:

• Изпълнете sudo ufw status numbered или еквивалент и прегледайте всяко правило спрямо текущия инвентар на услугите
• Премахнете правила за извадени от употреба услуги, стари IP адреси и временни изключения, които никога не са почистени
• Проверете дали политиките по подразбиране все още са deny incoming
• Проверете дали правилата за IPv6 отразяват правилата за IPv4
• Потвърдете, че регистрирането е активирано и че регистрационните файлове за отказан трафик се поглъщат от вашия SIEM или агрегатор на регистрационни файлове
• Тествайте правилата с nmap от външен хост, за да проверите дали повърхността за атака съответства на намерението ви

# Scan your own server from an external host to verify exposed ports
nmap -sS -sV -p 1-65535 --open YOUR_SERVER_IP

• Проверете дали правилата ESTABLISHED/RELATED са налице и правилно наредени
• Прегледайте правилата за ограничаване на скоростта и коригирайте праговете въз основа на наблюдаваните модели на трафик

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

Практически ключови изводи

• Задайте отказване по подразбиране на входящия трафик преди писане на каквито и да е правила за разрешаване. Това гарантира, че всяко правило, което забравите да напишете, води до блокирана връзка, а не до отворена.
• Никога не излагайте SSH на 0.0.0.0/0 на производствен сървър. Ограничете го до IP за управление, VPN подмрежа или използвайте port knocking.
• Пишете правила за разрешаване възможно най-конкретно. Предпочитайте from 203.0.113.50 to any port 22 proto tcp пред allow 22.
• Отразявайте правилата за IPv4 в IPv6. Защитна стена, която филтрира само IPv4, е половин защитна стена.
• Активирайте ограничаване на скоростта на връзките на всички портове за удостоверяване като базова мярка за смекчаване на груба сила.
• Регистрирайте отказания трафик. Безшумните отхвърляния без регистриране правят реагирането при инциденти почти невъзможно.
• Одитирайте правилата по график. Остарелите правила са отговорност, а не предпазна мрежа.
• Тествайте отвън. Използвайте nmap или външен скенер на портове след всяка значителна промяна на правилата, за да потвърдите ефективната повърхност за атака.
• Използвайте ufw reload вместо ufw disable && ufw enable, за да избегнете прекъсване на активните връзки по време на актуализации на правилата.
• При nftables и iptables, винаги поставяйте правилото за приемане ESTABLISHED/RELATED в началото на входящата верига, за да избегнете прекъсване на сесиите, инициирани от изходящия трафик.

Често задавани въпроси

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

Групата за сигурност (AWS, GCP, Azure) е управляван от облака филтър за пакети с проследяване на състоянието, приложен на ниво хипервайзор преди трафикът да достигне вашата VM. Правило на защитна стена, базирана на хост (UFW, firewalld), работи вътре в ядрото на операционната система. И двете трябва да се използват едновременно за защита в дълбочина — облачната група за сигурност като външен периметър и хост защитната стена като вътрешен слой за прилагане.

Защо UFW показва правило като активно, но трафикът все още е блокиран?

Най-честата причина е наредбата на правилата. Правило DENY по-рано в веригата съответства преди вашето правило ALLOW. Изпълнете sudo ufw status numbered и проверете наредбата. Също така проверете дали съществуват правила за IPv6, ако клиентът се свързва чрез IPv6, и потвърдете, че правилният интерфейс е насочен, ако сървърът е с множество мрежови интерфейси.

Трябва ли да блокирам ICMP изцяло за сигурност?

Не. Блокирането на целия ICMP прекъсва path MTU discovery, което причинява зависване на TCP сесиите в мрежи с нестандартни MTU. Също така прекъсва traceroute и прави мрежовата диагностика значително по-трудна. Блокирайте само типовете ICMP без легитимна оперативна употреба (типове 17 и 18). Разрешете echo request/reply, destination unreachable и time exceeded.

Какво се случва с активните SSH връзки, когато презаредя UFW?

sudo ufw reload презарежда набора от правила без изчистване на съществуващите записи за conntrack състояние. Активните SSH сесии остават свързани, защото таблицата за проследяване на връзките на ядрото все още съдържа тяхното ESTABLISHED състояние. Само sudo ufw disable, последвано от sudo ufw enable, би изчистило състоянието и потенциално би прекъснало активните връзки.

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

UFW запазва правилата автоматично при рестартиране чрез конфигурационни файлове /etc/ufw/. За firewalld, използвайте флага --permanent за всяко правило и изпълнете sudo firewall-cmd --reload. За необработен nftables, запазете набора от правила с sudo nft list ruleset > /etc/nftables.conf и се уверете, че systemd услугата nftables е активирана. За iptables, използвайте iptables-save > /etc/iptables/rules.v4 и инсталирайте пакета iptables-persistent.