VPN-gatewayen din er kompromittert: hva som faktisk er eksponert
En hacket VPN-gateway ser inn i sin egen tunnel, men det er ikke det samme som å eie hver økt. Skill trafikk, rekkevidde og lagrede hemmeligheter før gjenoppretting.
En VPN-gateway står ved enden av tunnelen den beskytter, noe som betyr at den avslutter krypteringen i stedet for å slippe den gjennom. Hvis en angriper kontrollerer verten, ser tunnelen fortsatt sunn ut utenfra mens maskinen i midten ikke lenger er til å stole på. Det nyttige spørsmålet er ikke om alt dekrypteres. Det er hva den verten kunne se, hvor den kunne nå, og hvilke hemmeligheter som faktisk var lagret på den. De tre svarene er svært forskjellige, og responsen er forskjellig med dem.
Gatewayen avslutter tunnelen, så den ser inn i den
Kryptering i en VPN går hopp for hopp, og gatewayen er hoppet. Den fjerner det ytre laget, anvender policy og videresender den indre pakken, så hver transportert pakke finnes på et tidspunkt i lesbar form i minnet til den verten. Det er designet, ikke en feil. Det er også grunnen til at kompromittering av gatewayen er en annen hendelse enn kompromittering av tunnelens kryptografi.
Det angriperen først vinner er posisjon: evnen til å observere transportert trafikk, endre videresending eller svare i stedet for en backend. Hva de vinner deretter avhenger av verten, og det er her folk overvurderer. Tilgang til gatewayen alene utleverer ikke nettleserens TLS-øktnøkler, fordi de aldri var på gatewayen.
Tre eksponeringer som ikke er like store
Del spørsmålet i transportert trafikk, tilgjengelige systemer og lagrede hemmeligheter, og svar deretter på hver for seg.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
Den midterste raden er den som hoppes over. En gateway har vanligvis en rute inn i private nettverk og en kildeadresse som backendene allerede stoler på, så det interessante spørsmålet er hva disse backendene tillater fra den adressen. En smal klienttilgangspolicy er god kontroll, men en angriper på verten er ikke begrenset til grensesnittet en vanlig klient ville brukt.
Den nederste raden avgjør hvor lenge hendelsen varer. En servernøkkel og en CA-nøkkel har helt forskjellige virkningsradier, og det samme har en lokal administratorkonto og et skrivebeskyttet overvåkningstoken.
HTTPS inne i tunnelen er fortsatt HTTPS
Applikasjons-TLS avsluttes i applikasjonen, ikke på VPN-gatewayen, så en kompromittert gateway observerer bare chiffertekst for disse strømmene. Det er en reell grense for hva angriperen får, og det er verdt å si klart, fordi den motsatte påstanden sprer panikk og dårlige beslutninger. To betingelser bryter det. Hvis en inspeksjonskomponent med et klarert sertifikat sitter i veien, kan gatewayen se klartekst ved design. Hvis selve applikasjonens endepunkt er kompromittert, er tunnelen irrelevant.
Så svaret på hva de så er betinget, og det bør skrives ned som betingelser i stedet for å annonseres som en dom.
Hva som må endres før du stoler på den igjen
Å bygge opp verten på nytt er nødvendig og sjelden tilstrekkelig. En angriper som fortsatt har en administrasjonskonto, en utrullingslegitimasjon eller en signeringsnøkkel kan sette verten tilbake som de vil. Gjenoppretting må starte fra en administrasjonsvei som ikke avhenger av den kompromitterte maskinen.
Kartlegg hva som var på den før du bestemmer hva som skal roteres. Nøkler, tjenestekontoer, API-tokens, lokale brukere, planlagte jobber, tillitsforhold og utrullingspipeline er alle kandidater, og hver har en eier som bør bekrefte det.
ss -lntup
getent passwd
crontab -l
ip route show table allDen listen er den raskeste måten å se hva verten tilbød og hvor den kunne nå. Bevar bevisene først, etter prosessen til eieren av responsen, fordi en gjenoppbygging ødelegger nøyaktig det en undersøkelse trenger. NIST SP 800-61 Revisjon 3 behandler forberedelse, deteksjon, respons og gjenoppretting som deler av én risikoprosess i stedet for som en omstartinstruks.
Grenser som gjør den neste billigere
Fire grenser er verdt å bygge før du trenger dem. Hold en uavhengig gjenopprettingsvei som ikke autentiserer gjennom gatewayen. Hold signeringsmyndighet adskilt fra verten som betjener trafikk. Begrens hva gatewayen kan nå, slik at en kompromittert gateway ikke automatisk er et kompromittert administrasjonsnettverk. Og registrer hvem som eier hver legitimasjon, slik at rotasjon er en telefonsamtale i stedet for et arkeologiprosjekt.
Ingen av disse forhindrer kompromittering. De avgrenser den, og de gjør forskjellen mellom en dårlig uke og et dårlig kvartal.