Hoe om te toets wat 'n noodstop op 'n gekompromitteerde gasheer dek

Voer die onderbrekingstoets uit, lees elke laag se resultaat en sien waar 'n noodstop stop: dit blokkeer roetes, nie sagteware wat data voor enkripsie lees nie.

Skakel die noodstop aan, trek die tonnelbediener vanlyn en kyk wat die masjien steeds doen. Daardie toets is die moeite werd om te hardloop, want dit skei wat die firewall afdwing van wat jy vermoed het dit afdwing, en die resultate is smaller as wat die meeste produkbladsye voorstel. 'n Noodstop beheer netwerkroetes; dit beheer nie sagteware wat reeds op die toestel loop nie. Ek hardloop hierdie reeks op enige masjien waar die kliënt beweer dat dit fail-closed is, en dit neem omtrent tien minute.

Begin by die kliënt, nie by die bediener nie

Die afdwingpunt is die gasheer waar jy sit: die bedryfstelsel se firewall, 'n hulpdienste of die VPN-kliënt se eie drywer. Dit maak saak, want alles wat die skakelaar kan doen, word begrens deur wat daardie laag kan sien. As die kliënt die blok met 'n roetereël plus 'n merkie implementeer, kan enigiets met genoeg voorregte sy eie reël byvoeg; as dit 'n kern-firewalltabel gebruik, kan dieselfde voorregte die tabel wysig. Die sterkte van die syfer kom nooit in hierdie vraag ter sprake nie.

Die eerste ding om vas te stel is dus wie die beleid op hierdie toestel besit en wat dit mag oorheers. Op 'n bestuurde werksmasjien is die antwoord gewoonlik die organisasie se eindpunt-agent, en 'n persoonlike VPN verwyder nie daardie vermoëns nie, hoe die tonnel ook ingestel is.

Stap een: bevestig die blok op die roetes wat jy dink dit dek

Neem die tonnel aan die verre kant af eerder as by die kliënt, sodat die kliënt steeds glo dit behoort verbind te wees. Probeer dan dit wat 'n mens werklik sou probeer:

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

Jy wil 'n kliënt hê wat vinnig en skoon misluk, nie een wat hang tot 'n blaaier se tydsperk nie. 'n Hang beteken gewoonlik dat pakkette stil deur 'n reël sonder verwerping laat val word, wat aanvaarbaar is, maar dit kan ook beteken dat die kliënt 'n verouderde standaardroete na 'n dooie koppelvlak gelos het. Lees die roetetabel terwyl die tonnel af is: 'n standaardroete wat steeds na die tonneltoestel wys en 'n firewallreël wat net nuwe uitgaande verbindings blokkeer, is twee verskillende toestande, en net een van hulle is fail-closed.

Herhaal dieselfde opdragte met die kliënt se allow-LAN-opsie aan en af. Daardie skakelaar is waar die meeste verrassings woon, want dit heropen 'n roete wat die res van die beleid geskryf is om te sluit.

Stap twee: ondersoek DNS en IPv6 as aparte roetes

Naamresolusie is die gap wat die meeste implementasies oorleef, want die navraag kan deur iets anders as die stelsel se resolver vertrek. Vra met 'n gereedskap wat jou resolver-konfigurasie ignoreer, en kyk terselfdertyd na die v6-kant:

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

Leë antwoorde vir albei naamnavrae met die tonnel af is die resultaat wat jy wil hê. As die tweede navraag antwoord, is 'n hardgekodeerde resolver-adres bereikbaar en die tonnel is nie die enigste pad van die masjien af nie. As net die v6-versoek slaag, dek die beleid IPv4 en ignoreer IPv6, wat dieselfde lek in 'n ander adresfamilie is.

Blaaiers maak dit moeiliker om van buite te lees, want een wat vir DNS oor HTTPS ingestel is, los die navraag deur 'n HTTPS-versoek op: die navraag is net so geblokkeer soos poort 443 na daardie eindpunt. Op 'n gasheer waar die beleid die plaaslike subnet toelaat, kan daardie versoek steeds 'n resolver op die LAN bereik.

Stap drie: skei netwerkblootstelling van eindpuntblootstelling

Nou die deel wat geen firewallreël bereik nie. 'n Noodstop blokkeer roetes van die masjien af; dit stop nie sagteware op die masjien om data te lees voordat dit geënkripteer is nie, en dit stop nie daardie sagteware om die tonnel wettig te gebruik nie. 'n Sleutelvaslegger, 'n kwaadwillige uitbreiding, 'n skerm wat oopgelaat is, 'n sinchroniseerkliënt met breë toestemmings: al hierdie dinge beweeg inligting oor 'n verbinding wat die skakelaar graag toelaat.

Dieselfde geld vir moniteringsagteware wat 'n werkgewer doelbewus geïnstalleer het. Die blokkering van roetes verwyder dit nie, en die koop van 'n nuwe VPN-bediener is nie die herstel nie, want die blootstelling sit stroomop van die tonnel.

'n Knipbordbestuurder wat na 'n wolkrekening oplaai, maak die punt skerp. Die verkeer is geënkripteer, die bestemming is toegelaat, en die noodstop rapporteer die hele tyd 'n gesonde toestand.

Stap vier: skryf die bewering wat jou toets ondersteun

Na die onderbrekingstoets kan jy spesifieke feite noem: watter programme gefaal het, watter roetes gestop het, of DNS en IPv6 hulle behoorlik gedra het, en of die blok gehou het toe die tonnel geval het. Jy kan nie sê dat die bedryfstelsel skoon is nie, en jy kan nie sê dat 'n diens aan die verre kant jou aanmelming privaat sal hou nie.

Hou die twee probleme apart en gee elkeen sy eie beheer:

  • Noodstop: die gedefinieerde foutvereiste, geverifieer deur 'n onderbrekingstoets wat jy ná elke kliëntopgradering herhaal.
  • Toestelvertroue: ondersteunde opdaterings, eindpuntbeskerming van 'n betroubare bron, hersiening van onverklaarde toestemmings en aanmeldingsversoeke.
  • Voorval: volg die platform- of organisasieproses wanneer daar vermoede van kompromittering is; 'n nuwe bediener is nie 'n opruimstap nie.
  • Openbaarmaking: wanneer jy om hulp vra, moenie private sleutels of volledige diagnostiese argiewe plak nie, want logs en skermskote dra dieselfde geheime as die verbinding.

Voer die reeks weer ná die volgende opdatering uit, want 'n noodstop is konfigurasie wat saam met weergawes beweeg. Die toets is die enigste bewyse wat jy het dat die gedrag waarop jy staatmaak steeds die gedrag is wat jy kry.

Verwante artikels