Forestil dig, at din webserver bliver kompromitteret i morgen. Hvilke andre enheder kan den så nå? Svaret er med til at afgøre, om hændelsen bliver begrænset til én tjeneste eller bringer flere dele af virksomheden i fare. En rettelse beskytter mod en kendt sårbarhed. Et godt netværksdesign begrænser også de mulige følger.
Eksemplet er en fiktiv kundeportal: Brugerne logger ind, ser ordrer og henter dokumenter. Applikationen har brug for en afgrænset databaseforbindelse. Det betyder ikke, at den også skal have adgang til administrationen af NAS, backupserveren eller virtualiseringsværten. Denne forskel skal håndhæves teknisk.
En kompromitteret tjeneste bruger de tilgængelige veje
En sårbarhed kan gøre det muligt at køre fremmed kode med webapplikationens rettigheder. Hvad der derefter kan ske, afhænger blandt andet af netværksregler, tjenestekonti, gemte adgangsoplysninger og andre sårbarheder. At en tjeneste kan nås, betyder ikke, at adgang lykkes. En kompromitteret webserver overtager heller ikke automatisk hele LAN’et.
Risikoen vokser, når tilgængelige interne tjenester kombineres med for brede rettigheder. Angriberen skal så overvinde færre grænser. Denne mulige spredning til andre systemer kaldes lateral bevægelse. Derfor er det nyttigt at designe ud fra, at en applikation allerede er kompromitteret.
Netværk A: Portalen ligger i et fladt virksomhedsnetværk
I den første opbygning deler portal, database, fillager og administrationsflader ét netværk. Perimeterfirewallen begrænser indgående forbindelser. Internt er der dog brede tilladelser eller utilstrækkelig adskillelse. Webserveren kan derfor nå flere systemer, end dens opgave kræver.
En fælles administratorkonto gør situationen værre. Det samme gælder en tilsluttet backupmappe med skriverettigheder eller vidtgående adgangsoplysninger gemt i applikationsmappen. En fungerende backup hjælper kun lidt, hvis den kompromitterede tjeneste også kan ændre dens administration eller alle sikkerhedskopier.
Netværk B: Zoner og regler begrænser forbindelserne
I den anden opbygning når internettrafikken først en defineret frontend eller reverse proxy. Den må kontakte den nødvendige applikation i et separat websegment. Applikationen får kun den nødvendige forbindelse til et bestemt databasemål. Administration, backupsystemer og andre interne tjenester ligger i adskilte zoner; unødvendig adgang fra websegmentet bliver blokeret.
Et VLAN opdeler netværket logisk. Kontrollen med forbindelserne afgør, om opdelingen bliver en effektiv sikkerhedsgrænse. For åbne regler for routing mellem VLAN forbinder i vidt omfang de adskilte netværk igen. Der kan også være behov for yderligere filtrering mellem enkelte workloads inden for samme VLAN.
OPNsense eller Sophos Firewall er mulige platforme til passende regler, ligesom andre egnede produkter. Det afgørende er konkrete kilder, mål, tjenester, ansvar og en verificeret implementering. Betjening og tilgængelige funktioner varierer mellem platformene. Et produktnavn beskriver ikke i sig selv en afprøvet sikkerhedsarkitektur.
Reverse proxy og WAF er fortsat dele af beskyttelsen
En reverse proxy kan samle offentlig adgang, håndtere TLS-forbindelser og sende forespørgsler til udvalgte backends. HAProxy understøtter blandt andet HTTP- og TCP-tilstande til disse formål. Det betyder ikke en generel proxyfunktion for vilkårlige protokoller. En foranstillet web application firewall kan genkende og afvise bestemte skadelige webforespørgsler.
Disse komponenter erstatter hverken sikre applikationer, rettidige opdateringer eller begrænset backendadgang. Forkerte regler eller en anden tilgængelig indgang kan omgå beskyttelsen. I eksemplet må også en applikation, der kompromitteres bag proxyen, derfor kun nå de mål, den udtrykkeligt har brug for.
Tænk på både udgående og intern trafik
Det afgørende spørgsmål er ikke kun, hvem der må kontakte webserveren. Hvor må serveren selv oprette forbindelser til? Kan den nå NAS’ens administrationsflade? Skal den kunne kontakte vilkårlige internetmål? Hvilke interne tjenester har andre containere faktisk brug for?
Planen for udgående trafik, også kaldet egress, omfatter blandt andet navneopslag, tidssynkronisering, opdateringer og eksterne grænseflader. Nødvendige mål tillades specifikt. Kommunikation mellem interne systemer, ofte kaldet øst-vest-trafik, kræver også klare regler. IPv6 og alternative ruter skal overholde den samme tilsigtede adskillelse.
En forbindelsesplan beskriver kilde, mål, nødvendig tjeneste, formål og ansvarlig person. Derefter testes både tilladte og blokerede veje under kontrollerede forhold. Logning og overvågning skal synliggøre uventede vellykkede forbindelser såvel som mistænkelige blokerede forsøg. En regel uden verificeret virkning er endnu ikke et pålideligt bevis.
VM’er og containere har brug for passende grænser
En virtuel maskine har sit eget gæsteoperativsystem; containere deler typisk værtens kerne. Begge modeller kræver en passende opsætning af netværk og rettigheder. Proxmox VE tilbyder firewallregler til værter og gæster. Hvilke lag og funktioner der virker, afhænger også af firewallens backend og den konkrete aktivering.
I Docker kan containere på samme bridge-netværk kommunikere med hinanden. Udgående forbindelser er ikke automatisk begrænset til offentlige mål. Publicerede porte kan skabe flere indgange. I host-netværkstilstand deler containere værtens netværksnavnerum; der er derfor ingen særskilt netværksisolation.
Ekstra privilegier, unødvendige monteringer af værtsmapper og adgang til Docker-socketen kan udvide følgerne af en hændelse betydeligt. Separate applikationsnetværk, minimale rettigheder, passende firewallregler på værten og kontrollerede DNS- og egress-veje skal derfor tænkes sammen. Også her er den faktisk virksomme konfiguration afgørende.
En overskuelig begyndelse for mindre virksomheder
- Kortlæg tjenesterne: dokumentér offentlige applikationer, afhængigheder og ansvarlige personer.
- Definér zonerne: adskil offentlige workloads, data, administration og backup efter beskyttelsesbehov.
- Begrund forbindelserne: tillad kun definerede kilder, mål og tjenester; blokér resten, hvor det er driftsmæssigt hensigtsmæssigt.
- Beskyt administrationen: brug betroede adgangsveje, egnede VPN- og MFA-metoder samt separate konti.
- Inddrag driften: planlæg opdateringer, centrale logs, alarmer og uafhængigt beskyttede backups med afprøvet gendannelse.
- Dokumentér virkningen: gennemgå regler jævnligt, tidsbegræns undtagelser, og test igen efter ændringer.
Ændringer kræver forberedelse, et passende vedligeholdelsesvindue og en mulighed for at rulle tilbage. En generel blokering kan afbryde legitime applikationer eller ens egen administrative adgang. Kortlæg derfor først afhængighederne, gennemfør overgangen kontrolleret, og kontrollér forretningsfunktionerne sammen med de ansvarlige.
Én kompromitteret applikation behøver ikke trække netværket med sig
PHP2Shell-artiklerne om reaktionen på PHP-sårbarheder og kortlægning med AI-støtte er den aktuelle anledning. Den supplerende kontrol af NAS, Docker og offentlige tjenester fører til et varigt arkitekturspørgsmål: Hvilke forbindelser og rettigheder har den enkelte tjeneste virkelig brug for?
DAXS hjælper med kortlægning, kommunikationsplan, implementering og verificerbar drift. Uanset om applikationen kører lokalt, i en privat cloud eller på en offentlig cloudplatform, skal beskyttelsesgrænserne passe til det faktiske behov. Lad os tale om dit konkrete miljø.
Kilder: OPNsense: regler og tilstandsbaseret filtrering · Sophos Firewall: zoner, regler og logning · HAProxy: HTTP- og TCP-tilstande · Docker: bridge-netværk · Docker: host-netværkstilstand · Docker: dæmon, rettigheder og sikkerhedsgrænser · Proxmox VE: firewalldokumentation · NCSC: begræns spredning, og beskyt administration og backup.
