Ваш VPN-шлюз скомпраметаваны: што насамрэч аказалася раскрытым

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

Шлюз завяршае тунель, таму бачыць яго знутры

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

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

Тры выкрыцці рознага памеру

Раздзяліце пытанне на перанесены трафік, дасяжныя сістэмы і захаваныя сакрэты, потым адкажыце на кожнае асобна.

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

Ніжні радок вызначае, колькі доўжыцца інцыдэнт. Ключ сервера і ключ CA маюць цалкам розныя радыусы паражэння, як і лакальны адмін-акаўнт і токен маніторынгу толькі для чытання.

HTTPS унутры тунеля застаецца HTTPS

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

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

Што павінна змяніцца, перш чым зноў давяраць яму

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

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

ss -lntup
getent passwd
crontab -l
ip route show table all

Гэты спіс — самы хуткі спосаб убачыць, што хост прапаноўваў і куды мог дабрацца. Спачатку захавайце доказы, паводле працэсу ўласніка рэакцыі, бо перабудова знішчае менавіта тое, што патрэбна расследаванню. NIST SP 800-61 Рэвізія 3 разглядае падрыхтоўку, выяўленне, рэакцыю і аднаўленне як часткі аднаго працэсу рызык, а не як інструкцыю перазапуску.

Межы, якія робяць наступны выпадак таннейшым

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

Нічога з гэтага не прадухіляе ўзлом. Яно абмяжоўвае яго і робіць розніцу паміж дрэнным тыднем і дрэнным кварталам.