UFW е измислен, за да се настройва защитната стена с три команди, и с това се справя. Проблемът е другаде: ufw status показва намеренията, а не резултата. Едно правило може да стои в списъка и същевременно да не затваря абсолютно нищо — по три различни причини, и трите се срещат редовно на реални сървъри.

Начало, при което не се заключвате сами

Редът на командите има значение. Първо разрешете SSH, после включвайте:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

ufw enable преди разрешаването на SSH прекъсва собствената ви сесия и после остава само конзолата на доставчика. Ако сървърът вече е настроен и не сте сигурни, дръжте отворена втора връзка, тя ще преживее неуспешна промяна.

Гледа се подробното състояние, краткото скрива политиката по подразбиране:

sudo ufw status verbose

Първа грешка: правилото го има, но портът е отворен за целия свят

Най-честият ред в чужди конфигурации:

sudo ufw allow 3306

Така отварят MySQL „за да може да се свързва от вкъщи“ — и го отварят за целия интернет. Правилните варианти са два и двата са по-добри:

sudo ufw allow from 203.0.113.25 to any port 3306

или, което е по-надеждно, услугата изобщо да не се пуска навън: bind-address = 127.0.0.1 в конфигурацията на MySQL, а достъпът отвън — през SSH тунел. Защитната стена е втората линия; първата е услугата да не слуша на публичен адрес. Правило в UFW може да се изтрие по невнимание, а bind-address сам няма да се промени.

Втора грешка: IPv6

Правило от вида ufw allow from 203.0.113.25 се отнася само за IPv4. Ако сървърът има IPv6 адрес — а повечето VPS имат и той е включен — услугата остава достъпна по него. Доставчикът е дал адреса, вие не си спомняте за него, скенерът знае.

Проверете дали филтрирането на v6 изобщо е включено (IPV6=yes в /etc/default/ufw) и дали услугата не слуша на :: без нужда:

ss -tulpn | grep ':::'

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

Трета грешка: Docker

Най-неприятната. Docker публикува портове, като дописва собствени правила във веригите на iptables преди тези, в които пише UFW. В резултат контейнер, стартиран като -p 5432:5432, е достъпен от интернет, дори когато UFW показва Status: active и политика deny incoming. Защитната стена при това не е счупена — просто до нея не се стига.

Това не се лекува в UFW, а в начина, по който се публикува портът:

ports:
  - "127.0.0.1:5432:5432"

Привързването към локалния адрес е най-простото и най-надеждното решение. Навън трябва да гледа само това, което наистина обслужва посетителите: обикновено портове 80 и 443 на обратен прокси.

Редът на правилата

UFW прилага първото подходящо правило и спира дотам. Затова забрана, добавена след разрешение, няма да сработи: до нея не се стига. Гледаме номерацията и вмъкваме на нужното място:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 7

Правилата се изтриват по номер, но номерата се изместват след всяко изтриване — изтривайте по едно и препрочитайте списъка.

Проверка отвън

Локалните команди показват какво е настроено. Какво се е получило в действителност, се вижда само от друга машина:

nmap -Pn -p- 203.0.113.25
nc -zv 203.0.113.25 3306

Достатъчен е всеки друг сървър или домашен компютър. Това е единствената проверка, която не лъже, и си струва да се прави след всяко забележимо пренастройване — особено след инсталиране на нещо, което „само си настройва мрежата“: Docker, контролни панели, VPN.

Журнали

По подразбиране UFW почти нищо не записва. Включва се така:

sudo ufw logging low

Записите отиват в /var/log/ufw.log — но само ако в системата има rsyslog. На Debian 12 и Ubuntu 24.04 може да го няма и тогава всичко отива в журнала на systemd:

sudo journalctl -k | grep -i '\[UFW'

Празен /var/log/ufw.log сам по себе си не означава нищо — първо погледнете в журнала.

Какво да се очаква от защитната стена

UFW затваря това, което не бива да е достъпно. Тя не разглежда съдържанието на заявките към отвореното: порт 443 е отворен за всички и всичко, което дойде на сайта, ще дойде безпрепятствено. Това е работа на други инструменти — WAF на ниво приложение, IDS на ниво трафик. Задачата на защитната стена е по-скромна и по-важна: списъкът на отворените портове да съвпада с това, което мислите за него. Как изглежда този списък заедно с активните правила на една страница, показва демонстрацията по-долу.