Нове правило UFW, старе з'єднання: перемагає встановлений стан

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

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

Вирішує порядок, а не існування правила

UFW — це інтерфейс, який записує правила netfilter поетапно: секція каркаса, що виконується до правил користувача, потім самі правила користувача, потім секція, що виконується після них. Стандартні попередні правила приймають трафік встановлених і пов'язаних з'єднань, і ці правила оцінюються раніше за все, що ви додасте звичайним allow або deny. Довідник команд UFW документує синтаксис вставки й нумерований перегляд стану, від яких залежить ця зміна.

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

Для цієї роботи використовуйте правила route, бо пакет пересилається через шлюз, а не адресується його власним службам. Правило вводу фільтрувало б не той трафік і виглядало б так, ніби нічого не робить.

Вставте вище широкого дозволу

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

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Якщо попередній перегляд показує рівно одне правило в очікуваній позиції, застосуйте ту саму команду без прапорця dry-run. Позиція 1 ставить його вище за ширші дозволи користувача, а не вище за розглянуті раніше правила каркаса. Переконайтеся, що назва інтерфейсу відповідає тунельному пристрою на цьому шлюзі, бо правило, прив'язане до інтерфейсу, якого більше немає, стоятиме в списку й виглядатиме правильним, ні з чим не збігаючись. Перейменуйте посилання на пристрій до застосування, а не після невдалого тесту.

У цьому правилі немає порту призначення, тож воно забороняє всі порти TCP на цій адресі, а не лише HTTPS. Якщо мета — одна служба, назвіть порт; правило, ширше за політику, — це майбутній інцидент, що чекає на свого першого читача.

Обмежте джерело однією адресою лише якщо ця адреса прив'язана до потрібної особи. Пул VPN з динамічним розподілом може завтра видати ту саму адресу іншому клієнту, і заборона йтиме за адресою, а не за людиною.

Встановлені потоки переживають нове правило

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

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

Пам'ятайте й про межі. Це правило нічого не каже про ICMP, UDP або IPv6, тож успішний ping не доводить, що заборона не спрацювала. Одна адреса IPv4 — теж не вебсайт: ім'я може розв'язуватися в кілька адрес, і покрито лише ту, яку ви назвали.

Перевірте новим потоком

Прочитайте нумеровані правила користувача й чинний сирий вигляд, потім відкрийте нове з'єднання з вибраного клієнта:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

Сирий вигляд важливий, бо status пропускає правила каркаса, написані вручну, тож порядок може виглядати інакше, ніж той, який застосовує ядро. Порівняйте обидва, перш ніж дійти висновку, що правило стоїть не на місці.

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

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

Схожі статті