Je VPN-gateway is gecompromitteerd: wat er werkelijk ligt blootgesteld

Een VPN-gateway staat aan het einde van de tunnel die hij beschermt, wat betekent dat hij die versleuteling beëindigt in plaats van door te geven. Als een aanvaller de host bestuurt, ziet de tunnel er van buiten nog steeds gezond uit terwijl de machine in het midden niet langer betrouwbaar is. De nuttige vraag is niet of alles wordt ontsleuteld. Het is wat die host kon zien, waar hij kon komen en welke geheimen er werkelijk op waren opgeslagen. Die drie antwoorden verschillen sterk, en de reactie verschilt ermee.

De gateway beëindigt de tunnel, dus hij kijkt erin

Versleuteling in een VPN gaat hop voor hop, en de gateway is de hop. Hij stript de buitenste laag, past beleid toe en stuurt het binnenste pakket door, zodat elk vervoerd pakket op een gegeven moment leesbaar in het geheugen van die host staat. Dat is het ontwerp en geen fout. Daarom is compromittering van de gateway een andere gebeurtenis dan compromittering van de cryptografie van de tunnel.

Wat de aanvaller eerst wint, is positie: het vermogen om vervoerd verkeer te observeren, doorsturen te wijzigen of in plaats van een backend te antwoorden. Wat hij daarna wint, hangt van de host af, en hier overschatten mensen. Toegang tot de gateway alleen levert geen TLS-sessiesleutels van een browser op, want die stonden nooit op de gateway.

Drie blootstellingen die niet even groot zijn

Splits de vraag in vervoerd verkeer, bereikbare systemen en opgeslagen geheimen, en beantwoord elk afzonderlijk.

De middelste rij is degene die wordt overgeslagen. Een gateway heeft meestal een route naar privénetwerken en een bronadres dat de backends al vertrouwen, dus de interessante vraag is wat die backends vanaf dat adres toestaan. Een smal clienttoegangsbeleid is een goede controle, maar een aanvaller op de host is niet beperkt tot de interface die een normale client zou gebruiken.

De onderste rij bepaalt hoe lang het incident duurt. Een serversleutel en een CA-sleutel hebben volledig verschillende invloedsradii, en dat geldt ook voor een lokaal beheerdersaccount en een alleen-lezen monitoringtoken.

HTTPS in de tunnel blijft HTTPS

TLS van de toepassing eindigt in de toepassing, niet bij de VPN-gateway, dus een gecompromitteerde gateway ziet voor die stromen alleen cijfertekst. Dat is een echte grens aan wat de aanvaller krijgt, en het is de moeite waard dat duidelijk te zeggen, omdat de tegenovergestelde bewering paniek en slechte beslissingen verspreidt. Twee voorwaarden doorbreken het. Als er een inspectiecomponent met een vertrouwd certificaat in het pad zit, kan de gateway by design platte tekst zien. Als het eindpunt van de toepassing zelf is gecompromitteerd, is de tunnel irrelevant.

Het antwoord op wat ze zagen is dus voorwaardelijk, en het moet als voorwaarden worden opgeschreven in plaats van als een vonnis te worden aangekondigd.

Wat moet veranderen voordat je hem weer vertrouwt

De host opnieuw opbouwen is noodzakelijk en zelden voldoende. Een aanvaller die nog een beheerdersaccount, een implementatie-identiteit of een ondertekeningssleutel heeft, kan de host terugzetten zoals hij wil. Herstel moet beginnen bij een beheerpad dat niet van de gecompromitteerde machine afhangt.

Inventariseer wat erop stond voordat je beslist wat er moet rouleren. Sleutels, serviceaccounts, API-tokens, lokale gebruikers, geplande taken, vertrouwensrelaties en de implementatiepijplijn zijn allemaal kandidaten, en elk heeft een eigenaar die dat zou moeten bevestigen.

ss -lntup
getent passwd
crontab -l
ip route show table all

Die lijst is de snelste manier om te zien wat de host bood en waar hij kon komen. Bewaar eerst het bewijs, volgens het proces van de eigenaar van de respons, want een herbouw vernietigt precies wat een onderzoek nodig heeft. NIST SP 800-61 Revisie 3 behandelt voorbereiding, detectie, respons en herstel als delen van één risicoproces en niet als een herstartinstructie.

Grenzen die de volgende goedkoper maken

Vier grenzen zijn de moeite waard om te bouwen voordat je ze nodig hebt. Houd een onafhankelijk herstelpad dat niet via de gateway authenticeert. Houd de ondertekeningsbevoegdheid gescheiden van de host die verkeer bedient. Beperk waar de gateway kan komen, zodat een gecompromitteerde gateway niet automatisch een gecompromitteerd beheernetwerk is. En leg vast wie eigenaar is van elke inloggegevens, zodat rotatie een telefoontje is in plaats van een archeologieproject.

Niets hiervan voorkomt compromittering. Het begrenst die, en het maakt het verschil tussen een slechte week en een slecht kwartaal.