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

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

Вклучете го итниот прекинувач, исклучете го серверот на тунелот од мрежата и гледајте што машината сѐ уште прави. Тестот вреди да се изведе, бидејќи го дели она што огнениот ѕид навистина го спроведува од она што сте претпоставиле, а резултатите се потесни отколку што сугерираат повеќето страници на производи. Итниот прекинувач управува со мрежни патеки; тој не управува со софтвер што веќе работи на уредот. Оваа секвенца ја изведувам на секоја машина каде клиентот тврди дека е 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 и дали блокирањето издржа кога тунелот падна. Не можете да тврдите дека оперативниот систем е чист, ниту дека служба на далечниот крај ќе ја задржи вашата најава приватна.

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

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

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

Поврзани статии