Да добавите правило за отказ и да гледате как отворено изтегляне продължава не е грешка в 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 пропуска правила на рамката, написани на ръка, така че редът може да изглежда различен от това, което ядрото налага. Сравнете двете, преди да заключите, че правило е на грешно място.

После проверете двете контроли, които доказват, че правилото е ограничено, а не широко: разрешено местоназначение от същия клиент все още работи, а втори клиент все още достига отказаното местоназначение, ако политиката му го позволява. Отказ, който чупи и двата теста, е промяна на политиката, не насочена такава.

Когато тестът приключи, премахнете само добавеното от вас правило, като го повторите точно. Ако политиката е постоянна, предайте я на собственика на защитната стена с идентичността на клиента, собственика на местоназначението и дата за преглед, за да не остави преназначен тунелен адрес остарял отказ.

Подобни статии