Gatewayen til fjernadgang er det udstyr, der står med den ene fod på internettet og den anden i jeres net. En penetrationstest af den afprøver tre ting: om udstyret er opdateret, om det er sat op til kun at vise og tillade det nødvendige, og om login holder for alle brugergrupper. Fundene lander hos driften, fordi det er driften, der opdaterer, konfigurerer og administrerer brugerne. Prioriteringen behøver ikke være svær. Gatewayen er et af de steder, hvor selv middelalvorlige fund bør rettes hurtigt.
Hvad køberen skal beslutte om fjernadgang i bestillingen, er beskrevet på penetrationtest.dk. Her går vi et lag dybere ned i det, IT-afdelingen faktisk skal arbejde med.
Hvorfor gatewayen er et særligt testområde
Gatewayen skal kunne nås fra hele verden, ellers virker den ikke for medarbejdere på farten. Den skal genkende brugere, før den lukker dem ind, og den placerer dem bagefter et sted i jeres net. Det gør den til et af de mest udsatte stykker udstyr, I har.
Producenterne af fjernadgangsudstyr udsender jævnligt rettelser, og kendte sårbarheder registreres med et CVE-nummer. Flere af dem har været udnyttet aktivt. Den amerikanske myndighed CISA fører et katalog over sårbarheder, der vides at være udnyttet, og anbefaler at bruge det som input til prioritering. For gatewayens vedkommende er det en god målestok: står jeres udstyr der, er det ikke en opgave til næste måned.
Opdatering: det første, testen ser
Testen vil typisk konstatere, hvilken udgave af udstyret der kører, og om den har kendte sårbarheder. Det er et fund, I selv kunne have set, og testeren kan sige det på den måde. Et fund om en manglende opdatering på gatewayen siger mindst lige så meget om opdateringsprocessen som om selve udstyret.
Stil derfor to spørgsmål, når fundet kommer. Hvorfor blev opdateringen ikke installeret? Og hvordan hører I om nye opdateringer til udstyret? Svaret kan være, at udstyret ligger uden for den almindelige opdateringsrutine, fordi det administreres af en leverandør, eller fordi en opdatering kræver nedetid, som ingen har planlagt. → Opdateringsstatus
Når producenten advarer om en kritisk sårbarhed, er opdateringen det første skridt. En test bagefter giver først mening, når opdateringen er på plads. → Leverandøren advarer om en kritisk sårbarhed
Opsætning: det, der vises udadtil
Ud over opdatering ser testen på, hvordan gatewayen præsenterer sig. Typiske fund handler om, at den viser mere end nødvendigt:
- Oplysninger om udgave og produkt · gør det lettere for andre at vurdere, om udstyret er sårbart. → Versionsoplysninger i rapporten
- Administration på samme adresse · styringen af gatewayen kan nås fra internettet sammen med brugerportalen.
- Gamle protokoller og svag kryptering · bevaret for at gamle klienter kan forbinde.
- Flere portaler end nødvendigt · en gammel portal fra en tidligere løsning svarer stadig.
Rettelsen er på begrebsniveau at fjerne det, der ikke bruges, og flytte administrationen væk fra internettet. Gamle protokoller fjernes i takt med, at de sidste klienter opdateres. Det kan kræve en plan, fordi en enkelt gammel klient hos en leverandør kan holde en svag indstilling i live.
Find ud af, hvem den klient tilhører, og hvad det vil kræve at opdatere den. Måske kan leverandøren skifte til en nyere forbindelse, når nogen beder om det. Sæt en dato i samarbejde med leverandøren, og meld datoen ud i god tid, så den gamle indstilling kan fjernes uden overraskelser for nogen af parterne.
Login: alle brugergrupper, ikke kun de almindelige
Login er det, gatewayen skal kunne. Testen afprøver, om login er beskyttet for alle, der kan bruge det. Når de almindelige medarbejdere har tofaktor, ligger fundene andre steder. De ligger ved undtagelserne.
- Servicekonti og fælles konti · konti, der logger ind uden person bag, og som derfor er undtaget fra tofaktor.
- Leverandørkonti · oprettet af leverandøren selv og ikke altid gennemgået.
- Gamle konti · tidligere medarbejdere, der stadig kan logge ind, fordi kontoen findes i et lokalt register på gatewayen.
- Alternative loginmetoder · en ældre metode, der blev bevaret ved siden af den nye.
Fund i denne gruppe peger på, at tofaktor er indført, men ikke for alle. Lav en liste over hver undtagelse med begrundelse og ejer, og fjern dem, der ikke kan begrundes. → Tofaktor med undtagelser
Det, driften skal have klar før testen
Gatewayen er en tjeneste, mange afhænger af. Testen skal kunne afprøve login uden at stoppe hverdagen. Det kræver forberedelse.
- Testkonti · til de brugergrupper, testen skal se på, med samme loginform som rigtige brugere.
- Låsepolitik · hvad sker der, hvis testen udløser låsning af rigtige konti? → Låste konti under testen
- Leverandørens accept · hvis gatewayen drives af en leverandør eller er en tjeneste i cloud.
- Udgave og opsætning · noter, hvilken udgave og hvilke indstillinger der kører, så resultatet kan læses mod det.
- Overvågning · beslut, om alarmer fra gatewayen skal håndteres som normalt i testperioden.
Hvis testen også skal se på, hvad brugerne når efter login, skal netværkets opdeling beskrives. Det er en anden del af opgaven og hører tættere ved den interne test. → Segmentering i dybden
Det skal I lade være med
- At lade gatewayen stå uden for opdateringsrutinen · den skal have sin egen faste plads i den.
- At kun teste den almindelige brugers login · undtagelserne er der, hvor fundene ligger.
- At bevare gamle protokoller uden plan · find de klienter, der kræver dem, og sæt en dato.
- At lade den gamle portal køre ved siden af den nye · luk den, når overgangen er sket.
- At tro, at tofaktor dækker alle · servicekonti og leverandører kan være undtaget.
- At glemme lokale konti på selve gatewayen · de følger ikke med, når medarbejdere stopper.
Hvad kan og ikke kan konkluderes
En test af gatewayen viser, hvordan udstyret præsenterede sig og opførte sig udefra i testperioden, og om login holdt for de brugergrupper, der indgik. Den kan påvise manglende opdatering, overflødige oplysninger og undtagelser i login.
Den kan ikke sige, at gatewayen er sikker, når producenten næste gang offentliggør en sårbarhed. Den siger heller ikke, hvad en bruger kan nå efter login, medmindre den del var med. Og den viser ikke, om en medarbejders bærbare, der forbinder, er beskyttet. Den løbende sikkerhed i gatewayen afhænger af opdatering og vedligeholdelse, som testen kun kan vise et øjebliksbillede af.
Tjekliste til gatewayen
- ☐ Har gatewayen en fast plads i opdateringsrutinen?
- ☐ Ved I, hvordan I hører om producentens sikkerhedsrettelser?
- ☐ Er administration flyttet væk fra internettet?
- ☐ Er gamle portaler og protokoller fjernet eller planlagt fjernet?
- ☐ Er alle undtagelser fra tofaktor listet med ejer og begrundelse?
- ☐ Er lokale konti og leverandørkonti gennemgået?
- ☐ Er testkonti, låsepolitik og leverandørens accept på plads før testen?
Kilder
- CISA: Known Exploited Vulnerabilities Catalog: katalog over sårbarheder, der vides at være udnyttet, anbefalet som input til prioritering.
- CVE: registrering af kendte sårbarheder med et fælles nummer.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Opdateringsstatus · Ekstern penetrationstest i praksis
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
