Hoe't jo teste wat in needskakelaar op in kompromittearre host dekt

Rin de útfaltest, lês it resultaat fan elke laach en sjoch wêr't in needskakelaar stopt: hy blokkearret paden, net software dy't gegevens lêst foar fersifering.

Sette de needskakelaar oan, helje de tunnelserver offline en sjoch wat de masine noch docht. De test is de muoite wurdich, want hy skiedt wat de firewall hanthavent fan wat jo oannamen, en de resultaten binne smeller as de measte produktsiden suggerearje. In needskakelaar regelet netwurkpaden; hy regelet gjin software dy't al op it apparaat rint. Ik rin dizze sekwinsje op elke masine dêr't de klant beweart fail-closed te wêzen, en it duorret sawat tsien minuten.

Begjin by de klant, net by de server

It hanthaveningspunt is de host dêr't jo sitte: de firewall fan it bestjoeringssysteem, in helpstsjinst of de eigen driver fan 'e VPN-klant. Dat makket út, want alles wat de skakelaar dwaan kin, wurdt beheind troch wat dy laach sjocht. As de klant de blokkade útfiert mei in routeringsregel plus in mark, kin alles mei genôch privileezjes in eigen regel tafoegje; as er in kern-firewalltabel brûkt, kin itselde privileezje de tabel bewurkje. De sterkte fan 'e sifer komt nea yn dizze fraach.

Dat is dus it earste dat fêststeld wurde moat: wa't it belied op dit apparaat besit en wat it oerskriuwe mei. Op in beheard wurkmasine is it antwurd meastentiids de einpuntagent fan 'e organisaasje, en in persoanlike VPN ferwideret dy mooglikheden net, hoe't de tunnel ek konfigurearre is.

Stap ien: befêstigje de blokkade op 'e paden dy't jo tinke dat er dekt

Helje de tunnel del oan 'e fiere kant, net by de klant, sadat de klant noch leaut dat er ferbûn wêze moat. Probearje dan wat in persoan echt probearje soe:

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

Jo wolle in klant dy't fluch en skjin mislearret, net ien dy't hinget oant de browser-timeout. Hingje betsjut meast dat pakketten stilwei troch in regel sûnder ôfwizing falle litten wurde, wat akseptabel is, mar it kin ek betsjutte dat de klant in ferâldere standertrûte nei in deade interface efterlitten hat. Lês de routeringstabel wylst de tunnel del is: in standertrûte dy't noch nei it tunnelapparaat wiist en in firewallregel dy't allinnich nije útgeande ferbiningen blokkearret binne twa ferskillende tastannen, en mar ien fan beide is fail-closed.

Werhelje deselde kommando's mei de allow-LAN-opsje fan 'e klant oan en út. Dy skeakel is wêr't de measte ferrassings libje, want hy iepenet wer in paad dat de rest fan it belied skreaun wie om te sluten.

Stap twa: kontrolearje DNS en IPv6 as aparte paden

Nammeneigening is de kleau dy't de measte ymplemintaasjes oerlibbet, want de fraach kin troch wat oars as de systeemresolver nei bûten gean. Freegje mei in helpmiddel dat jo resolverkonfiguraasje negearret, en kontrolearje tagelyk de 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

Lege antwurden op beide namme-fragen mei de tunnel del binne it resultaat dat jo wolle. As de twadde fraach antwurdet, is in hurdkoade resolveradres berikber en is de tunnel net it iennichste paad fan 'e masine ôf. As allinnich it v6-fersyk slagget, dekt it belied IPv4 en negearret IPv6, wat deselde lek is yn in oare adresfamylje.

Browsers meitsje dit fan bûten ôf dreger te lêzen, want in browser dy't foar DNS oer HTTPS konfigurearre is, lost de fraach op fia in HTTPS-fersyk: de fraach is mar safier blokkearre as port 443 nei dat einpunt. Op in host dêr't it belied it lokale subnet tastiet, kin dat fersyk noch in resolver op it LAN berikke.

Stap trije: skied netwurkbleatstelling fan einpuntbleatstelling

No it diel dêr't gjin firewallregel by komt. In needskakelaar blokkearret paden fan 'e masine ôf; hy stopet software op 'e masine net by it lêzen fan gegevens foar't dy fersifere binne, en hy stopet dy software net by it wetlik brûken fan 'e tunnel. In keylogger, in kweade útwreiding, in skerm dat ûntsletten litten is, in syngronisaasjeklant mei brede rjochten: se ferpleatse allegear ynformaasje oer in ferbining dy't de skakelaar graach tastiet.

Itselde jildt foar tafersjochsoftware dy't in wurkjouwer mei opsetsin ynstallearre hat. Rûtes blokkearje ferwidert it net, en in nije VPN-server keapje is net de reparaasje, want de bleatstelling sit boppe de tunnel.

In klamboerdbehearder dy't nei in cloudaccount uploadt, lit dat skerp sjen. It ferkear is fersifere, de bestemming is tastien, en de needskakelaar rapportearret de hiele tiid in sûne tastân.

Stap fjouwer: skriuw de bewearing dy't jo test stipet

Nei de útfaltest kinne jo konkrete feiten neame: hokker applikaasjes mislearren, hokker paden stoppen, hoe't DNS en IPv6 har hâlden en oft de blokkade stie doe't de tunnel foel. Jo kinne net sizze dat it bestjoeringssysteem skjin is, en ek net dat in tsjinst oan 'e fiere kant jo oanmelding privee hâldt.

Hâld de twa problemen skieden en jou elk syn eigen kontrôle:

  • Needskakelaar: de fêstleine falôf eask, ferifiearre troch in útfaltest dy't jo nei elke klantfernijing werhelje.
  • Apparaatbetrouwen: stipe fernijings, einpuntbeskerming fan in betroubere boarne, kontrôle fan ûnferklearre rjochten en autentikaasjefersiken.
  • Ynsidint: folgje it proses fan it platfoarm of de organisaasje as kompromis fermoede wurdt; in nije server is gjin oprommestap.
  • Iepenbiering: as jo om help freegje, plak dan gjin privee kaaien of hiele diagnostyske argiven, want logs en skermôfbyldings drage deselde geheimen as de ferbining.

Rin de sekwinsje wer nei de folgjende fernijing, want in needskakelaar is konfiguraasje dy't mei ferzjes mei beweecht. De test is it iennichste bewiis dat it gedrach dêr't jo op fertrouwe noch it gedrach is dat jo krije.

Relatearre artikelen