Како проверити шта покрива нужни прекидач на компромитованом хосту

Покрените тест прекида, прочитајте резултат сваког слоја и погледајте где се нужни прекидач зауставља: блокира путеве, а не софтвер који чита податке пре шифровања.

Укључите нужни прекидач, искључите сервер тунела из мреже и посматрајте шта машина још ради. Тест вреди извести, јер одваја оно што заштитни зид заиста спроводи од онога што сте претпоставили, а резултати су ужи него што већина страница производа сугерише. Нужни прекидач управља мрежним путевима; не управља софтвером који већ ради на уређају. Ову секвенцу изводим на свакој машини чији клијент тврди да је 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 преко HTTPS разрешава упит HTTPS захтевом: упит је блокиран само толико колико је блокиран порт 443 ка тој крајњој тачки. На хосту где политика дозвољава локалну подмрежу, тај захтев ипак може да стигне до резолвера на LAN-у.

Трећи корак: одвојте мрежну изложеност од изложености крајњих тачака

Сада део до којег не допире ниједно правило заштитног зида. Нужни прекидач блокира путеве из машине; не спречава софтвер на машини да чита податке пре шифровања и не спречава тај софтвер да законито користи тунел. Келогер, злонамерно проширење, остављен откључан екран, клијент за синхронизацију са широким дозволама: све то преноси информације везом коју прекидач радо дозвољава.

Исто важи за надзорни софтвер који је послодавац намерно инсталирао. Блокирање рута га не уклања, а куповина новог VPN сервера није поправка, јер изложеност је пре тунела.

Менаџер клипингборда који отпрема на облачни налог то показује оштро. Саобраћај је шифрован, одредиште дозвољено, а нужни прекидач све време пријављује здраво стање.

Четврти корак: напишите тврдњу коју ваш тест подржава

После теста прекида можете навести конкретне чињенице: које апликације су отказале, који путеви су стали, како су се понашали DNS и IPv6 и да ли је блокирање издржало када је тунел пао. Не можете тврдити да је оперативни систем чист, нити да ће услуга на далеком крају сачувати вашу пријаву приватном.

Држите два проблема одвојено и дајте сваком сопствену контролу:

  • Нужни прекидач: дефинисани захтев за отказ, потврђен тестом прекида који понављате после сваког ажурирања клијента.
  • Поверење у уређај: подржана ажурирања, заштита крајњих тачака из поузданог извора, преглед необјашњених дозвола и захтева за аутентификацију.
  • Инцидент: при сумњи на компромитацију следите процес платформе или организације; нови сервер није корак чишћења.
  • Откривање: када тражите помоћ, не лепите приватне кључеве или целе дијагностичке архиве, јер дневници и снимци екрана носе исте тајне као веза.

Поново изведите секвенцу после следећег ажурирања, јер је нужни прекидач конфигурација која се креће са верзијама. Тест је једини доказ да је понашање на које се ослањате још увек оно које добијате.

Повезани чланци