Правілы брандмаўэра толькі для NEW не закрываюць усе шляхі WAN

Адхіленне новых зыходных злучэнняў на WAN выглядае як палітыка зачыненага адказу, але гэта больш вузкае абяцанне, чым здаецца. Пакеты, якія належаць ужо існым патокам, не падпадаюць пад яе, як і многія адказы. Гэтую прагалку лёгка не заўважыць, бо правіла чытаецца так, нібы яно ахоплівае інтэрфейс, а не адзін стан злучэння на ім. А чытанне супадзення стану як выраку і стварае ілжывае адчуванне закрытасці.

Стан — гэта ўмова супадзення, а не вырак

Адсочванне злучэнняў класіфікуе пакеты па тым, што брандмаўэр ужо бачыў, а не па тым, што лічыць праграма. Паток, бачны ў абодвух кірунках, лічыцца ўсталяваным, і яго наступныя пакеты застаюцца ўсталяванымі, нават калі маршрут пад ім змяняецца з тунэля на звычайнае зыходнае злучэнне. Адказ на ўваходнае злучэнне таксама можа быць усталяваным трафікам. Гэтыя пакеты ніколі зноў не становяцца новымі.

Вось чаму правіла, абмежаванае новымі злучэннямі, не можа даказаць, што кожны абаронены пакет блакуецца. Яно пакідае іншыя станы на тое, што з імі робіць набор правілаў, а гэта можа быць дазвол, змешчаны раней у ланцугу.

Чытайце правіла ў яго акружэнні

Шырокі дазвол для ўсталяванага і злучанага трафіку, змешчаны перад блокам, прапускае пакет раней, чым блок наогул ацэньваецца. Выдаленне ўмовы стану з наступнага правіла гэтага не зменіць, бо ацэнка да яго не даходзіць. Парадак вызначае вынік, а супадзенне стану вызначае, якія пакеты даходзяць да гэтага парадку.

Правярайце фактычны набор правілаў, а не файл, які вы рэдагавалі, уключаючы пераходы ў іншыя ланцугі і ўсё, што стварае платформа. На маршрутызатары пад кіраваннем iptables пералік ланцуга паказвае азначэнні правілаў, і ланцугі, на якія ён спасылаецца, таксама трэба прасачыць. Натыўнай сістэме nftables патрэбна праверка ўласнага набору правілаў і прыярытэтаў прычэпак, бо прашыўка рэдка стварае аднолькавыя ланцугі.

Лічыльнікі паказваюць, якое правіла фактычна супала, і звычайна яны больш інфарматыўныя, чым захоп пакетаў, зроблены пасля рашэння. Правіла з нулявым лічыльнікам не дасягнута, што б ні казала яго пазіцыя.

Выказвайце забарону незалежна ад стану

Калі група кліентаў ніколі не павінна выходзіць у інтэрнэт па-за тунэлем, скажыце гэта проста, а не набліжайце адным станам. Правіла павінна выбіраць па крыніцы, выхадзе і прызначэнні, не залежачы ад стану злучэння, і стаяць там, дзе ніякі ранейшы дазвол не можа яго абысці. Тады кіраванне доступам і выключэнні для лакальнай сеткі атрымліваюць свае ўласныя яўныя правілы, і намера бачная ў палітыцы.

Выбар reject замест drop змяняе тое, як збойваецца супаўны трафік, і не павялічвае набор пакетаў, якія выбірае правіла. Адмоўленае злучэнне і ціхае чаканне — розныя сімптомы, што ўказваюць на адзін і той жа выбар.

Палітыка, якая наўмысна дазваляе адказы на ініцыяваны звонку доступ праз WAN, мае права на існаванне. Проста апісвайце яе менавіта так, а не падавайце як поўную ізаляцыю толькі праз тунэль.

Праверце, хто насамрэч у групе

Прыклад ахоплівае перанакіраваны трафік IPv4 з аднаго прэфікса праз адзін інтэрфейс. Ён нічога не кажа пра IPv6, другі зыходны канал або трафік, які стварае сам маршрутызатар. Маршрутызатар у ролі DNS-рэзалвера шле свае ўласныя запыты ўверх, і яны наогул не праходзяць праз ланцуг forward.

Пераканайцеся, што абароненыя кліенты па-ранейшаму маюць адрасы ўнутры выбранага прэфікса, бо прылада, якая выйшла за яго, трапляе напрамую выпадкова, а не па палітыцы. Пашырэнне блока на ўсю LAN без перагляду дызайну выключэнняў таксама схільна забіраць ваш уласны адміністрацыйны шлях.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Затым праверце стары паток побач з новым. Свежая спроба злучэння і ўжо актыўная двухбаковая перадача паводзяць сябе па-рознаму пад гэтым правілам, і толькі праверка абодвух паказвае, якая палітыка ў вас насамрэч.