Як відновити доступ після зламаних правил ufw

Повернення доступу

Якщо ufw заблокував доступ до вашого VPS, повернутися можна через консоль провайдера або rescue mode, оскільки після активації правила блокування виправити ситуацію через SSH неможливо. Ядро відкидає ваш пакет ще до того, як його побачить sshd, тому підключитися для виправлення через мережу неможливо. Відкрийте консоль у панелі керування провайдера, увійдіть у неї та виконайте одну команду.

sudo ufw disable

Ви маєте побачити Firewall stopped and disabled on system startup. Нові SSH-з’єднання знову запрацюють через одну-дві секунди. Налаштування не буде втрачено: disable вивантажує правила з ядра та записує ENABLED=no у /etc/ufw/ufw.conf, а ваші правила залишаються на диску в /etc/ufw/user.rules і чекають наступного ufw enable.

Не перезавантажуйте сервер у надії, що це допоможе. ufw запускається під час завантаження системи, тому ENABLED=yes означає, що той самий набір правил завантажиться знову ще до запуску мережі. Перезавантаження нічого не змінює, якщо ufw заблокував доступ.

Консолі потрібен пароль, якого у вас може не бути

Вебконсоль (VNC або serial) — це клавіатура, підключена до машини. Вона не використовує мережевий шлях, тому жодне правило firewall не може її заблокувати. Водночас для неї потрібен локальний вхід. Саме тут виникають проблеми в конфігураціях, де дозволено лише автентифікацію за ключем: якщо ви ніколи не встановлювали пароль для свого sudo-користувача, а вхід root заблокований, консоль показує запит, на який ви не можете відповісти. Встановіть цей пароль зараз, поки у вас ще є SSH: sudo passwd yourname. Більшість панелей також дають змогу скинути пароль root, що зазвичай примусово запускає перезавантаження.

Якщо консоль непридатна для використання, завантажте rescue system провайдера. Вона запускає окрему операційну систему, а ваш диск залишається відмонтованим. Тому ви можете вимкнути ufw із зовнішнього середовища.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Спочатку виконайте lsblk, оскільки root partition не завжди є /dev/vda1. Перезавантажтеся у звичайну систему. ufw залишатиметься вимкненим, доки ви не ввімкнете його вручну.

Мінімальна послідовність відновлення

Виконуйте дії в цьому порядку. Перші чотири кроки безпечні. Наступний — ні.

1. sudo ufw disable, щоб вивантажити правила й відновити доступ.
2. sudo ufw show added, щоб вивести додані правила у вигляді команд, які їх додали. Це працює, коли ufw неактивний, на відміну від ufw status.
3. sudo sshd -T | grep -i '^port', щоб перевірити порт, на якому справді очікує підключень sshd. Команда виводить port 22, якщо ви його не змінювали.
4. sudo ufw allow 22/tcp, використовуючи фактичний порт, щоб наступне увімкнення не спричинило повторного блокування доступу.
5. sudo ufw enable, попередньо запланувавши відкат. Це описано нижче на цій сторінці.

Що насправді робить скидання ufw

ufw reset — це крайній захід, а не перший крок. Команда вимикає firewall, створює резервні копії всіх файлів правил і повертає типові політики: забороняти вхідні з’єднання та дозволяти вихідні. Вона виводить окремий рядок резервної копії для кожного файлу:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

Після скидання дозволених правил немає взагалі. Тому запускайте команду з консолі, а не через SSH, і додайте правило для SSH до повторного ввімкнення firewall. Резервні копії зберігаються як звичайний текст. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 показує, якими були попередні правила. Так можна відновити набір правил, який ви не планували видаляти.

Де ufw зберігає свої правила

Читання файлів надійніше за спроби відновити все з пам’яті. У п’яти шляхах зберігається весь стан:

• /etc/ufw/user.rules і /etc/ufw/user6.rules: правила, які ви додали, у порядку їх перевірки.
• /etc/ufw/before.rules і /etc/ufw/after.rules, а також варіанти 6: каркас ufw навколо ваших правил, зокрема правило приймання для встановлених з’єднань і правила для loopback.
• /etc/default/ufw: політики за замовчуванням і перемикач IPV6.
• /etc/ufw/ufw.conf: ENABLED і рівень журналювання.
• /var/log/ufw.log: заблокований трафік, якщо журналювання ввімкнено.

Перед перезаписуванням файлу ufw створює його копію з часовою міткою, тому ls /etc/ufw/ заповнюється іменами на кшталт user.rules.20260813_101500. Це історія скасування змін. Перед відновленням попередніх налаштувань її варто переглянути.

Щоб переглянути правила, завантажені в kernel, а не правила на диску, використовуйте sudo ufw show raw або sudo iptables -S і sudo ip6tables -S. В Ubuntu 22.04 і 24.04 ці команди працюють на основі nft, тому sudo nft list ruleset виводить ті самі правила в новішому синтаксисі.

Чому після ввімкнення ufw було розірвано мій сеанс SSH?

Політика за замовчуванням для вхідних підключень — deny. Якщо ввімкнути ufw без правила для порту SSH, усі нові підключення буде заблоковано. ufw попереджає про це: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Відповідь на y без налаштованого правила allow для SSH є найпоширенішою причиною всіх проблем, описаних на цій сторінці.

Проблема полягає в затримці. /etc/ufw/before.rules приймає пакети зі станом ESTABLISHED,RELATED до застосування ваших правил, тому сеанс, у якому ви виконали команду, продовжує працювати у штатному режимі. Блокування проявляється лише під час наступного підключення. Воно може відбутися через кілька годин, і на той момент зміна налаштувань firewall уже не здаватиметься пов’язаною з проблемою. Завжди відкривайте другий сеанс SSH і перевіряйте, що він працює, перш ніж закривати перший.

Чому після зміни політики перестали працювати apt і DNS?

sudo ufw default deny outgoing блокує вихідні DNS-запити (система доменних імен) і вихідний HTTP-трафік, тому розпізнавання імен не працює, а оновлення пакетів припиняються. apt update повідомляє про Temporary failure resolving 'archive.ubuntu.com'. Вхідний SSH і далі працює, оскільки відповіді на нього мають стан ESTABLISHED і проходять правила framework. Через це здається, що firewall не є причиною, хоча саме він спричиняє проблему.

Якщо потрібно заборонити вихідний трафік за замовчуванням, відкрийте те, що фактично потрібно машині:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Без останнього правила системний годинник відстає, а неправильний час порушує перевірку сертифікатів TLS (безпека транспортного рівня), тому curl починає повідомляти про помилки дат, а не портів. Цей симптом з’являється через кілька днів після зміни. Тому політика заборони вихідного трафіку підходить для машин, які ви моніторите, а не для сервера, який налаштовують один раз.

Чому моє правило ufw ніколи не спрацьовує?

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

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp виводить правила, які було б записано, але нічого не змінює. Це безпечний спосіб перевірити правило до його застосування.

Ще одна проблема пов’язана з профілями застосунків. sudo ufw allow OpenSSH використовує профіль із /etc/ufw/applications.d/openssh-server, а цей профіль означає порт 22. Якщо sshd прослуховує порт 2222, правило відкриває порт, який ніхто не використовує, і ви втратите доступ до сервера, хоча набір правил виглядатиме правильним. Після зміни порту використовуйте номер порту. Інший синтаксис описано в основах ufw firewall для VPS.

Чому правила IPv4 не пояснюють побачену поведінку?

Тому що половина трафіку не є IPv4. Ubuntu постачає IPV6=yes у /etc/default/ufw, а ufw підтримує паралельний набір правил IPv6 у /etc/ufw/user6.rules. Правило, записане з адресою IPv4, наприклад ufw allow from 203.0.113.10 to any port 22, взагалі не створює правила IPv6. Якщо для вашого VPS налаштовано запис AAAA, клієнт надає перевагу IPv6, а підключення завершується тайм-аутом, хоча ufw status показує правило, яке виглядає правильним. Перевірте різницю за допомогою ssh -4 user@host і ssh -6 user@host. Якщо перша команда працює, а друга — ні, проблема полягає в наборі правил IPv6.

Зворотний випадок небезпечніший. За умови IPV6=no ufw взагалі не керує ip6tables, тому політика IPv6 залишається зі значенням ACCEPT за замовчуванням у ядрі. Порт, який ви вважаєте закритим, відповідає за своєю IPv6-адресою, і жодна команда ufw не покаже його. Перевірте це за допомогою sudo ip6tables -S і ss -tlnp, а для повної картини прочитайте як ufw обробляє порти IPv6.

Чому порт Docker відкритий, якщо ufw забороняє доступ?

Docker публікує порт, записуючи правила DNAT (трансляції мережевих адрес призначення) у таблицю nat і додаючи власний ланцюжок у FORWARD. Правила ufw розташовані в шляху INPUT. Трафік до контейнера переспрямовується, а не доставляється на хост, тому він не доходить до ланцюжка, у якому розташоване правило заборони. docker run -p 5432:5432 доступний з інтернету, навіть якщо ufw активний і забороняє весь трафік.

sudo iptables -t nat -S DOCKER

Найпростіше рішення — опублікувати порт на loopback: -p 127.0.0.1:5432:5432 прив’язує сторону хоста до 127.0.0.1, тому зовнішні підключення до нього неможливі незалежно від налаштувань ufw. У матеріалі Як Docker публікує порти в обхід ufw розглянуто випадки, коли сервіс має бути публічно доступним.

Заплануйте відкат перед застосуванням правила

Це звичка, яка робить роботу з firewall безпечною. Перед будь-якою ризикованою зміною заплануйте її скасування. Якщо зміна заблокує вам доступ, машина автоматично відновить попередній стан через п’ять хвилин, і вам не доведеться відкривати консоль.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd виводить Running timer as unit: ufw-rollback.timer. Тепер внесіть зміну. Якщо після цього ви все ще можете відкрити новий SSH-сеанс, скасуйте відкат:

sudo systemctl stop ufw-rollback.timer

Якщо відкрити цей сеанс не вдається, зачекайте. ufw самостійно зупиниться, і наступна спроба підключення буде успішною. Класичний прийом shutdown -r +5 не допомагає з ufw, оскільки під час завантаження ufw знову завантажує той самий набір правил.

Залиште другий спосіб доступу

• Увійдіть до консолі провайдера один раз заздалегідь і переконайтеся, що пароль працює. Консоль, яку ви ніколи не перевіряли, не є резервним способом доступу.
• Створіть другого користувача з правами sudo і власним ключем, щоб один пошкоджений файл authorized_keys не позбавив вас доступу.
• Перевірте, чи використовує ваш провайдер мережевий firewall у панелі керування окремо від ufw. Він блокує ті самі порти, а ufw status ніколи його не покаже.
• Не робіть ufw allow from <your home address> єдиним правилом SSH, якщо ця адреса динамічна. Провайдер змінить її вночі, і ви втратите доступ.

Найдешевше виконати все це на новому сервері разом з іншими початковими налаштуваннями, описаними в розділі перші десять хвилин на новому VPS.

Відмова або перевищення часу очікування показують, на якому рівні сталася помилка

Connection refused означає, що пакет досяг сервера, а у відповідь щось надіслало TCP reset. Мережевий шлях працює, тому sshd зупинений або прослуховує інший порт. Firewall рідко є причиною, оскільки ufw за замовчуванням відкидає пакети, а не відхиляє їх.

Connection timed out означає, що у відповідь не надійшло нічого. Це характерна ознака відкидання пакета: ufw, мережевий firewall провайдера або неправильна адреса. Правильне трактування цих двох помилок заощаджує годину безплідного пошуку, а різниця між відмовою в підключенні та перевищенням часу очікування допомагає розібрати решту випадків.

Увімкніть журналювання перед наступною зміною

sudo ufw logging on
sudo tail -f /var/log/ufw.log

Заблокований пакет має такий вигляд:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 із вашою власною адресою в SRC= доводить, що блокування виконує ufw, а не мережа й не sshd. У мінімальному образі без rsyslog файлу /var/log/ufw.log немає, і ті самі рядки надходять із sudo journalctl -k | grep UFW. ufw обмежує частоту власних правил журналювання, тому відсутність рядка не доводить, що пакет було дозволено.

Якщо ви виявили правила, яких не додавали

Ruleset, який змінився сам по собі, не є проблемою firewall. Його змінив хтось із доступом до root. Виконайте sudo grep ufw /var/log/auth.log, щоб переглянути виконані команди sudo і обліковий запис, від імені якого їх виконували, а потім last, щоб перевірити входи в систему приблизно в цей час. Якщо облікові записи не належать нікому з відомих вам користувачів, припиніть налагодження firewall і пройдіть контрольний список для скомпрометованого VPS. Повторне ввімкнення firewall на сервері, який контролює інша особа, лише приховає проблему.

Зберіть конфігурацію знову

Коли причина відома, знову увімкніть ufw так, щоб блокування не повторилося. Дозвольте фактичний порт SSH, заплануйте відкат, увімкніть ufw, потім відкрийте новий сеанс SSH з іншого термінала й переконайтеся, що підключення працює. Закривайте поточний сеанс лише після встановлення нового сеансу. Залиште журналювання увімкненим на один день, оскільки журнал набагато швидше покаже, яке правило ви забули дозволити, ніж читання user.rules.

FAQ

Чи ufw disable видаляє мої правила?

Ні. disable вивантажує набір правил із ядра та записує ENABLED=no у /etc/ufw/ufw.conf. Ваші правила залишаються у /etc/ufw/user.rules і /etc/ufw/user6.rules, а sudo ufw show added показує їх, коли firewall неактивний. ufw reset — це команда, яка очищає їх. Спочатку вона створює резервну копію кожного файла та виводить рядок на кшталт Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

Чи скасує перезавантаження мого VPS блокування через ufw?

Ні. ufw запускається під час завантаження з ENABLED=yes у /etc/ufw/ufw.conf, тому ті самі правила завантажуються ще до запуску мережі, і доступ знову буде заблоковано. Перезавантаження допоможе лише після вимкнення ufw або після редагування цього файла в rescue mode із підключеним диском. Скористайтеся консоллю провайдера та виконайте там sudo ufw disable.

Чому мій Docker container доступний, коли ufw забороняє порт?

Docker створює власні правила DNAT і FORWARD для кожного опублікованого порту. Цей трафік переспрямовується до container, а не доставляється на host, тому він не проходить через ланцюжок INPUT, де діє правило ufw deny. Якщо порт потрібен лише для host, опублікуйте його на loopback за допомогою -p 127.0.0.1:5432:5432. Перевірте правила, встановлені Docker, за допомогою sudo iptables -t nat -S DOCKER.

У мене немає пароля для консолі та rescue mode. Які є варіанти?

Доступні варіанти залежать від вашого провайдера: скидання пароля з control panel, яке зазвичай перезавантажує server, або підключення диска до іншого instance, щоб відредагувати /etc/ufw/ufw.conf. Перш ніж перевстановлювати server, зверніться до support, оскільки перевстановлення знищує дані на ньому. Після відновлення доступу виконайте sudo passwd yourname і один раз перевірте вхід через консоль, щоб наступне блокування не коштувало вам більше двох хвилин.