AnyConnect-advarsel om ikke-betroet server: accepter eller importer?

Du indsætter gateway-værtsnavnet i AnyConnect, vinduet bliver rødt eller hvidt, og en dialog spørger, om du vil stole på en server, hvis certifikat klienten ikke kan verificere. Den naturlige bevægelse er at klikke igennem og gå i gang, og det er netop den forkerte refleks. Svaret skrives ind i klientens indstillinger på den maskine og gælder for senere forbindelser, så dialogen er en konfigurationsbeslutning i kostume af en engangsadvarsel. Her er den rute, jeg tager, i den rækkefølge klienten viser den.

Start med den advarsel, du faktisk ser

Rød og hvid er ikke kosmetiske varianter. Den røde advarsel betyder, at profilen eller indstillingen er sat til at blokere ikke-betroede servere, så klienten nægter at fortsætte, indtil den indstilling ændres; den hvide advarsel betyder, at den lader dig fortsætte, når du først svarer udtrykkeligt. Et tredje tilfælde ser ens ud og opfører sig anderledes: et udløbet certifikat, som klienten slet ikke vil tilbyde at importere, fordi import ikke ville gøre det gyldigt. At skelne de tre tager et sekund og afgør alt det følgende.

Bag dem alle står en kort liste af årsager: et selvsigneret gateway-certifikat, en privat CA, som endpointet ikke stoler på, eller et værtsnavn, der mangler i certifikatets subject alternative names. Enhver af de tre giver samme dialog og kræver en anden rettelse.

Læs certifikatet, før du svarer på dialogen

Åbn certifikatdetaljerne fra advarslen, og se på tre felter, før du rører en knap. Subject og SAN skal navngive den gateway, du faktisk ville nå, udstederen skal være den CA, din organisation driver, og gyldighedsdatoerne skal dække i dag. Sammenlign derefter SHA-256-fingeraftrykket med en kopi, du har fået et andet sted end gennem denne forbindelse, en intern dokumentationsside eller en sag, for et fingeraftryk læst fra samme dialog beviser intet som helst. Kan du ikke finde en uafhængig kopi, har du intet grundlag for at acceptere undtagelsen.

Det er trinnet, der skiller et laboratorium fra en produktionsgateway. På en testmaskine med et selvsigneret certifikat, du genererede i går, er det rimeligt at klikke igennem. På en virksomhedsgateway, hvor brugerne derefter skriver legitimationsoplysninger, er et certifikat, du ikke kan verificere, et sandsynligt aflytningsarrangement, og klienten er den eneste komponent, der stadig stiller spørgsmålet.

Vid, hvad hvert svar skriver til tillidslageret

Svarer du ja til importspørgsmålet, føjes gatewayens certifikat til klientens betroede lager på den maskine. Det er ikke en undtagelse pr. session: senere forbindelser kan gennemføres uden samme prompt, hvilket er pointen og også risikoen, fordi intet på skærmen minder nogen om, at undtagelsen findes. Svarer du nej, fortsætter login kun for denne session. Begge veje får dig forbundet, og kun én af dem ændrer maskinen.

Er du på den røde vej, er det første forsøg slet ikke et login. Den dokumenterede inputsekvens er en connect-linje efterfulgt af to bekræftelser, som ændrer indstillingen og afslutter; et script, der betragter det som succes, har gemt en indstilling og aldrig godkendt nogen. Spørgsmålet om certifikatimport vises først ved næste forsøg, og derfor konkluderer folk, at prompten er periodisk.

Den rækkefølge betyder noget for automatisering, ikke kun for fingre. Et scriptet svar, der altid siger ja, bliver ved med at virke, efter gatewayen skifter, og bliver ved med at stole på hvilket som helst certifikat, der dukker op.

Skriv svarene i den rækkefølge, klienten spørger

Når klienten advarer men tillader forbindelsen, kommer svarene i en fast rækkefølge: connect, ja for at fortsætte, derefter importspørgsmålet, derefter gruppen, brugernavnet og adgangskoden. Skriv dem som separate linjer i inputfilen i stedet for at gætte på promptens timing. At afvise importen er en enkelt tegnændring i samme fil, og det er den sikrere standard for alt, der kører uden opsyn.

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

Foretræk at distribuere organisationens CA til endepunkterne frem for at lære hvert script at acceptere et løvcertifikat. Et korrekt udstedt certifikat med det rigtige SAN fjerner prompten for alle, holder valideringen meningsfuld og afhænger ikke af én endepunkts hukommelse om en beslutning. Installation af en rod-CA er en tungere ændring end import af et løvcertifikat, så behandl det som en styret udrulning frem for en genvej fra supporten.

Fjern de undtagelser, der lever længere end deres gateway

AnyConnect gemmer disse indstillinger pr. maskine, så gamle svar hober sig op på bærbare computere, der har flyttet mellem kontorer. Gennemgå de gemte indstillinger og de importerede certifikater på administrerede endepunkter, og kontroller, om en undtagelse stadig nævner et værtsnavn, der har skiftet ejer. En indstilling, der accepterer enhver ikke-betroet server, er bredere end det certifikat, den blev oprettet til.

Det mønster, der er værd at bevare, er smalt: et betroet certifikat til normal brug, en dokumenteret fingeraftrykskontrol uden for båndet til en midlertidig undtagelse og en navngivet ejer, der fjerner den, når migreringen slutter. Finder du en indstilling, der accepterer enhver server, på en maskine, du administrerer, skal du behandle det som et fund, ikke som en bekvemmelighed.