Як праверыць, што перакрывае аварыйны выключальнік на кампраметаваным хасце

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

Уключыце аварыйны выключальнік, адключыце сервер тунеля і паназірайце, што машына ўсё яшчэ робіць. Гэты тэст варта праводзіць, бо ён аддзяляе тое, што ажыццяўляе міжсеткавы экран, ад таго, што вы меркавалі, што ён ажыццяўляе, і вынікі вузейшыя, чым прапануюць большасць старонак прадуктаў. Аварыйны выключальнік кіруе сеткавымі шляхамі; ён не кіруе праграмамі, якія ўжо працуюць на прыладзе. Я праводжу гэтую паслядоўнасць на любой машыне, дзе кліент сцвярджае, што працуе ў рэжыме fail-closed, і гэта займае каля дзесяці хвілін.

Пачніце з кліента, а не з сервера

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

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

Крок першы: пацвердзіце блок на шляхах, якія, на вашу думку, ён пакрывае

Адключыце тунель на далёкім канцы, а не на кліенце, каб кліент усё яшчэ верыў, што павінен быць падключаным. Затым паспрабуйце тое, што паспрабаваў бы чалавек:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Вам патрэбен кліент, які хутка і чыста выходзіць з ладу, а не той, што вісіць да тайм-аўту браўзера. Завісанне звычайна азначае, што пакеты ціха скідаюцца правілам без адмовы, і гэта дапушчальна, але яно таксама можа азначаць, што кліент пакінуў састарэлы маршрут па змаўчанні, накіраваны на мёртвы інтэрфейс. Чытайце табліцу маршрутызацыі, пакуль тунель адключаны: маршрут па змаўчанні, які ўсё яшчэ паказвае на прыладу тунеля, і правіла міжсеткавага экрана, якое блакуе толькі новыя зыходныя злучэнні, — гэта два розныя станы, і толькі адзін з іх fail-closed.

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

Крок другі: праверце DNS і IPv6 як асобныя шляхі

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

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

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

Браўзеры робяць гэта цяжэйшым для чытання звонку, бо браўзер, наладжаны на DNS over HTTPS, развязвае запыт праз HTTPS-запыт: запыт блакуецца настолькі, наколькі блакуецца порт 443 да гэтай канчатковай кропкі. На хасце, дзе палітыка дазваляе лакальную падсетку, гэты запыт усё яшчэ можа дасягнуць рэзалутара ў LAN.

Крок трэці: аддзяліце сеткавую схільнасць ад схільнасці канчатковых кропак

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

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

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

Крок чацвёрты: сфармулюйце сцвярджэнне, якое падтрымлівае ваш тэст

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

Трымайце дзве праблемы асобна і дайце кожнай свой кантроль:

  • Аварыйны выключальнік: вызначанае патрабаванне да адмовы, пацверджанае тэстам адключэння, які вы паўтараеце пасля кожнага абнаўлення кліента.
  • Давер да прылады: падтрымоўваныя абнаўленні, абарона канчатковых кропак з надзейнай крыніцы, разгляд неабгрунтаваных дазволаў і запытаў аўтэнтыфікацыі.
  • Інцыдэнт: прытрымлівайцеся працэсу платформы або арганізацыі пры падазрэнні на кампраміс; новы сервер — не крок ачысткі.
  • Раскрыццё: просячы дапамогі, не ўстаўляйце прыватныя ключы або цэлыя дыягнастычныя архівы, бо журналы і здымкі экрана нясуць тыя ж сакрэты, што і злучэнне.

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

Падобныя артыкулы