Основи UFW або як налаштувати брандмауер у Linux

На жаль, налаштування брандмауера - це одна з тих речей, про які або згадують занадто пізно, або взагалі відкладають на потім. Дуже часто бізнес орієнтований виключно на те, щоб якнайшвидше запустити свій продукт, сервіс або сайт. Тому процес налаштування нового сервера виглядає приблизно так: підняли VPS, розгорнули свій сервіс, перевірили, що сайт відкривається, і пішли далі. На цьому етапі багатьом здається, що питаннями безпеки можна зайнятися потім, коли з'явиться час. Яка ж це помилка!

Проблема в тому, що кожен сервер з публічною IP-адресою починає скануватися практично відразу після появи в мережі. Тисячі ботів перебирають логіни та паролі від SSH, шукають відкриті порти, доступні бази даних, перевіряють вразливі сервіси та модулі. Причому це не є цільовою атакою саме на вас або ваш бізнес - це просто "нормальний" фоновий шум інтернету. І якщо ваш сервер відкритий у зовнішній інтернет трохи більше, ніж це потрібно для його нормальної роботи, то він рано чи пізно буде скомпрометований або зламаний.

Здавалося б, ще зовсім недавно налаштування брандмауера в Linux було завданням "зі зірочкою", адже робота безпосередньо з iptables вимагала твердого та впевненого розуміння принципів роботи ланцюжків правил, таблиць і станів мережевих з'єднань. У той же час помилка, допущена всього в якомусь одному правилі, могла або повністю відкрити сервер для зловмисників, або, навпаки, відрізати до нього доступ усім, включаючи вас самих. Саме тому багато адміністраторів або відкладали налаштування брандмауера на потім, "щоб потім, коли буде вільний час, сісти і гарненько розібратися", або банально копіювали чужі конфігурації, не до кінця розуміючи, що саме вони роблять і як працюють.

Але з появою UFW ситуація почала змінюватися на краще. По суті, утиліта UFW - це надбудова над утилітою iptables (або nftables), яка, у свою чергу, є надбудовою для конфігурації модуля ядра Netfilter, вбудованого системного брандмауера. Це просто інструмент спрощення, який дозволяє замість десятків правил і ланцюжків ввести всього кілька зрозумілих команд.

Одного разу ми вже писали короткий гайд по UFW. Ну а в цій статті ми хотіли б детальніше ознайомитися з цим інструментом, розібратися в тому, як встановити UFW і налаштувати за його допомогою брандмауер для захисту вашого сервера від проникнень зловмисників. Правда, завжди варто пам'ятати, що налаштування брандмауера - це лише невелика частина цілого комплексу заходів, які слід вживати для забезпечення максимальної безпеки вашої інфраструктури.

Чому брандмауер потрібно налаштовувати на кожному сервері

Повернемося до того, як зазвичай виглядає завдання з налаштування нового сервера, а саме: запустили VPS, встановили потрібні пакети, налаштували Nginx або backend, відкрили SSH для управління сервером і, здавалося б, завдання виконано. Здається, що сервер повністю готовий до роботи, адже сервіс відповідає, сайт доступний, значить можна перейти до наступних завдань або піти випити чаю з колегами та обговорити вчорашній футбольний матч.

Але є нюанс, який не очевидний навіть багатьом досвідченим адміністраторам. Справа в тому, що ваш сервер за замовчуванням набагато "балакучіший", ніж вам може здатися. І навіть якщо ви спеціально не відкривали ніяких додаткових портів, то все одно назовні можуть бути доступні різні точки входу, про які ви можете навіть не здогадуватися.

Найбанальніші приклади можуть виглядати приблизно так:

• SSH на стандартному порту, доступний усьому інтернету;
• веб-сервер, який слухає всі інтерфейси;
• база даних, випадково залишена відкритою після тестів;
• контейнери Docker з прокинутими портами;
• тимчасові сервіси, які банально забули закрити.

О! Це ж просто рай для хакерів, це цілий набір потенційних точок входу, які автоматично перевіряються тисячами ботів, після чого перевіряються більш складними інструментами.

Саме тут добре проявляється ключова роль брандмауера. Він не посилює безпеку якось абстрактно, це ж не чарівна кнопка "зроби так, щоб все було безпечно". Натомість він робить цілком конкретну річ, а саме - він зводить зовнішній доступ до сервера до строго необхідного мінімуму, відкриваючи лише ті сервіси, які мають бути видимими, і то лише тим, кому це дозволено.

Що таке UFW і як він влаштований

Як ми вже згадували у вступі, UFW не є самостійним механізмом фільтрації пакетів, а є лише надбудовою над існуючими низькорівневими інструментами. Під капотом він використовує iptables або nftables, а його основне завдання полягає у спрощенні взаємодії з ними, не змушуючи вас щоразу розбиратися в ланцюжках правил, таблицях і станах з'єднань.

Якщо говорити простіше, то UFW - це високорівневий інтерфейс до брандмауера. Ви описуєте правила у вигляді простих і зрозумілих команд, а система вже сама перетворює їх на коректні низькорівневі правила, які застосовуються на рівні ядра Linux. Тобто вся реальна фільтрація відбувається там же, де і при ручному налаштуванні iptables, а різниця лише в тому, як ви цим керуєте.

І тут важливо розвіяти одну поширену помилку. Через свою простоту UFW іноді сприймається як спрощений або навіть навчальний інструмент. Але на практиці це не так. Він не обмежує можливості брандмауера, а лише приховує надмірну складність. Звичайно, якщо ви працюєте над складним інфраструктурним проєктом, що вимагає застосування складних схем фільтрації, тоді ви завжди можете писати правила безпосередньо в iptables. Але для переважної більшості завдань можливостей UFW більш ніж достатньо.

Більше того, використання UFW часто робить конфігурацію більш передбачуваною та підтримуваною. Коли правила написані у простому, зрозумілому для людини форматі типу "дозволити це" і "заборонити те", їх простіше перевіряти, документувати та передавати іншим адміністраторам. На відміну від довгих ланцюжків правил у iptables, де без контексту іноді складно зрозуміти, що саме відбувається.

Встановлення та перший запуск

На Ubuntu UFW зазвичай вже встановлений у системі, на Debian - його може не бути. У будь-якому разі встановлення займає пару секунд і не складає труднощів:

sudo apt update

sudo apt install ufw

ВАЖЛИВО! Найпоширеніша помилка, яку допускають недосвідчені адміністратори, полягає в тому, що якщо ви підключені до сервера через SSH і увімкнете UFW, не дозволивши до цього SSH, то ви закриєте з'єднання для себе.

Тому відразу після встановлення, ПЕРЕД УВІМКНЕННЯМ, насамперед потрібно відкрити SSH-порт:

sudo ufw allow OpenSSH

Ця команда додає правило, що дозволяє доступ через SSH (зазвичай це порт 22, якщо використовується стандартна конфігурація).

Якщо у вас використовується нестандартний порт (що, до речі, часто роблять для зменшення шуму від брутфорсу), його потрібно вказати явно:

sudo ufw allow 5522/tcp

,де 5522 - це ваш реальний порт SSH. Без цього кроку при увімкненні UFW ви просто втратите доступ до сервера.

Тільки після цього ви можете сміливо вмикати UFW:

sudo ufw enable

Перевірити його статус можна командою:

sudo ufw status verbose

Якщо ви все зробили правильно, то вже на цьому етапі ви отримали базовий захист свого сервера і не втратили доступ до сервера, а це вже досягнення :)

Базова логіка - спочатку все заборонити, потім дозволити потрібне

Коли мова заходить про налаштування брандмауера, важливо не стільки запам'ятати команди, скільки зрозуміти сам підхід до захисту. UFW будується на дуже простій і зрозумілій моделі, коли ваш сервер за замовчуванням не повинен приймати жодних вхідних з'єднань, якщо ви явно цього не дозволили.

Це саме той принцип, який варто використовувати у своїй інфраструктурі: не "закриваємо зайве", а "дозволяємо тільки необхідне". І нехай різниця здається невеликою, але з практичної точки зору це два абсолютно різних рівні контролю.

У UFW ця логіка задається буквально двома командами:

sudo ufw default deny incoming

sudo ufw default allow outgoing

Цими командами ми заборонили всі вхідні з'єднання і дозволили всі вихідні, тому будь-яке вхідне з'єднання буде відхилено, якщо ви не додали для нього явне правило. При цьому вихідні з'єднання залишаються відкритими, щоб система могла нормально працювати, отримувати оновлення, звертатися до сторонніх API, завантажувати пакети тощо.

Далі ви вже починаєте свідомо відкривати тільки ті сервіси, які дійсно повинні бути доступні ззовні.

Наприклад, базовий набір для веб-сервера - це http- та https-порти:

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

Тонке налаштування правил

У прикладах вище ми просто відкривали потрібні нам порти, але в реальній практиці просте відкриття порту - це лише половина справи. Правильним підходом є не просто відкриття порту, а обмеження доступу до нього.

Наприклад, SSH рідко повинен бути доступний усьому Інтернету, і зазвичай доступ потрібен лише з вашої IP-адреси. У такому випадку ми повинні дозволити доступ лише для вашої IP-адреси:

sudo ufw allow from 192.168.1.100 to any port 22

Так само справа йде і з базами даних, адже PostgreSQL або MySQL не повинні слухати зовнішній світ. Їх клієнт, зазвичай, це backend або API - ось для них і БД і повинна бути доступна.

sudo ufw allow from 10.0.0.5 to any port 5432

Ззовні порт начебто й видно, але доступ до нього суворо обмежений однією або кількома IP-адресами. Тому для випадкових сканерів він фактично виявляється закритим.

Управління правилами

На початку конфігурація брандмауера часто виглядає дуже акуратно, всього пара правил, все зрозуміло і прозоро. Але минає час, поступово в систему додаються нові сервіси, налаштовуються якісь тимчасові доступи, прописуються тестові налаштування, в результаті чого список правил починає розростатися. У якийсь момент сукупний набір правил перестає бути очевидним, а необхідність внести будь-які нові зміни викликає сумнів, чи не зламається щось із старих правил.

Тому, щоб не доводити справу до стану, коли брандмауер стає чорною скринькою, за ним потрібно періодично стежити і доглядати :) UFW надає для цього чудовий простий інструмент - перегляд правил з нумерацією:

sudo ufw status numbered

Ви отримаєте список приблизно такого вигляду:

[ 1] 22/tcp ALLOW IN Anywhere

[ 2] 80/tcp ALLOW IN Anywhere

А нумерація тут не просто для зручності - вона безпосередньо може використовуватися для управління правилами, наприклад, їх видалення. Якщо правило вам більше не потрібне, то його можна легко видалити за номером:

sudo ufw delete 1

Це здається банальним, але проста дисципліна на кшталт "додав правило, перевірив, прибрав зайве" - дозволяє тримати конфігурацію під контролем. А якщо цим нехтувати, то вже через кілька місяців брандмауер перетворюється на набір випадкових дозволів, де вже складно зрозуміти, що і навіщо відкрито.

Вбудоване логування

У реальній роботі з сервером часто виникає відчуття, що якщо сервіс не відповідає, значить проблема обов'язково в коді, конфігурації веб-сервера або конкретному контейнері. Ви перевіряєте Nginx, перезапускаєте backend, дивитеся логи додатка і все, начебто виглядає нормально, але з'єднання, як і раніше, не проходять.

І ось тут часто спливає простий, але не завжди очевидний факт, що трафік може блокуватися на рівні брандмауера. Причому без будь-яких явних помилок у самому додатку.

Тому ще одним чудовим інструментом, який значно полегшує життя системним адміністраторам, є вбудоване логування. Воно дозволяє побачити, які з'єднання були відхилені і звідки вони надходили. Вмикається це однією командою:

sudo ufw logging on

Після цього всі події записуються в стандартний лог:

/var/log/ufw.log

У ньому ви побачите записи про заблоковані пакети із зазначенням їхніх IP-адрес, номерів портів та напрямку трафіку. Це дуже полегшує процес локалізації проблем у системі та дозволяє швидко виявити й усунути проблему.

Особливо це допомагає при налаштуванні взаємодії між декількома сервісами або мікросервісами, роботі з Docker або Kubernetes, де частина мережевої логіки прихована, а також при пошуку та усуненні "плаваючих" мережевих проблем, які важко відтворити.

Конфлікти UFW і сторонніх сервісів

На перший погляд UFW створює відчуття повної керованості, адже ви задали правила і впевнені, що саме вони визначають, що доступно ззовні, а що ні. Але в реальній інфраструктурі іноді все трохи складніше.

Існує цілий клас сервісів, які працюють з брандмауером безпосередньо, минаючи UFW. Найпоширеніші приклади - це Docker або гіпервізори типу Proxmox. Вони керують iptables самостійно, додаючи свої правила для мереж, NAT і прокидання портів.

У результаті може виникнути неочевидна на перший погляд ситуація, коли ви дивитеся на правила UFW і бачите, що порт закритий, але фактично сервіс все одно доступний ззовні. З точки зору UFW все заборонено, але на рівні iptables вже є правило, яке цей доступ дозволяє.

Це не є ні помилкою, ні багом - це просто архітектурна особливість. Тому, щоб уникнути таких ситуацій, під час налаштування сервера буде корисно, по-перше, розуміти, які з компонентів майбутньої системи можуть керувати брандмауером безпосередньо, а по-друге, в ідеалі, перевіряти діючі правила безпосередньо на нижчих рівнях, наприклад у самому iptables.

FAQ

Чи можна використовувати UFW у виробничому середовищі? Так, це нормальний інструмент для більшості VPS та невеликих проєктів. Якщо він налаштований правильно, то забезпечує достатній рівень безпеки.

Чи потрібно закривати вихідні з'єднання? Зазвичай ні, але у високозахищених середовищах це роблять, щоб обмежити витік даних і небажані вихідні з'єднання, як-от Reverse shell.

Вибрати UFW чи керувати iptables безпосередньо? Якщо вам не потрібні складні сценарії, то робота з UFW швидша та зручніша. А ось iptables має сенс, коли потрібна тонка кастомізація.

Чому порт закритий, але сервіс працює? Швидше за все, у вашій системі є якийсь інший інструмент, який обходить UFW і керує правилами брандмауера безпосередньо. Прикладами таких сервісів можуть бути Docker, ProxMox та інші.

Як зрозуміти, що саме блокує з'єднання? У разі, якщо ви не можете зрозуміти, що саме блокує з'єднання, рекомендуємо увімкнути та переглянути логи UFW, у яких буде видно, які пакети були відхилені та всі їхні параметри.

Чи потрібно відкривати порт бази даних назовні? Майже ніколи цього не варто робити. Краще обмежити доступ лише внутрішніми IP або VPN, що потрібно враховувати ще на етапі проектування системи.

Висновок

Отже, ми з вами з'ясували, що UFW (Uncomplicated Firewall) не є в прямому сенсі якимось спрощеним брандмауером, а просто є зручною надбудовою над вбудованим брандмауером, який у Linux і так вже працює на рівні ядра.

Також ми обговорили головну філософію, притаманну, щоправда, не тільки UFW, що потрібно спочатку заборонити всі вхідні з'єднання, а потім дозволити лише ті, які необхідні, і лише для тих IP-адрес, яким це довірено.

При цьому важливо пам'ятати, що UFW може виявитися не єдиним елементом системи, що має доступ до вбудованого брандмауера, і, наприклад, Docker, Proxmox та інші інструменти можуть безпосередньо працювати з iptables, додаючи свої правила та обходячи вашу конфігурацію, що може внести невизначеність у роботу сервера. Щоправда, якщо це відбувається, значить ваша система вже має достатній рівень складності і в такому випадку вам варто перевіряти реальні діючі в системі правила на нижчому рівні, наприклад безпосередньо в iptables.

Важливою відмінною рисою UFW є простота підтримки та прозорість, завдяки простому та інтуїтивно зрозумілому синтаксису.

У підсумку UFW вирішує ключове завдання, а саме, надає вам швидкий та зрозумілий контроль над тим, які сервіси доступні ззовні, забезпечуючи гідний рівень безпеки при мінімальних зусиллях.