Новае правіла 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 апускае правілы каркаса, напісаныя ўручную, таму парадак можа выглядаць інакш, чым тое, што ўжывае ядро. Параўнайце абодва, перш чым рабіць выснову, што правіла не на сваім месцы.
Затым праверце два кантролі, якія даказваюць, што правіла вузкае, а не шырокае: дазволены пункт прызначэння з таго ж кліента па-ранейшаму працуе, а другі кліент па-ранейшаму дасягае заблакаванага пункта, калі яго палітыка гэта дазваляе. Блакаванне, якое правальвае абодва тэсты, — гэта змена палітыкі, а не мэтанакіраваная.
Калі тэст скончаны, выдаліце толькі дададзенае вамі правіла, дакладна паўтарыўшы яго. Калі палітыка пастаянная, перадайце яе ўладальніку міжсеткавага экрана разам з ідэнтычнасцю кліента, уладальнікам пункта прызначэння і датай перагляду, каб перапрызначаны адрас тунеля не пакінуў састарэлае блакаванне.