VG testen er enkel, det er bare å åpne en browser på en server for å besøke en webside. Å adressere den krever litt mer. «Konsekvensen» av å adressere den kan være litt knot, om man ikke gjør de riktige grepene.
Min erfaring
Etter å ha adressert VG testen suksessfullt hos flere kunder, med generiske regler på toppen, deretter spesifikke server regler, og så default deny i bunnen, kommer utfordringen når nye behov oppstår.
I tillegg tar jeg her også hensyn til inngående regelsett som er basert på Least Privilege for å enkelt kunne identifisere elementer som eventuelt ikke skulle fungere.
Når nye tjenester trengs
Når VG testen er adressert, alt fungerer, og etablering av C2 (Command & Control) er umulig (ingenting er 100%, men dette er veldig nærme), så tenker man at alt er ferdig. Og det er det helt til en ny applikasjon på eksisterende server skal opp og kjøre, for da trenger man bl.a URL logger. URL logger eksisterer ikke for default deny regelen da den stopper kommunikasjon før URL inspeksjon.
Skal man sette opp en ny server vil man lage en ny regel for den IP adressen og på den måten kunne identifiserer URL’er der, så det er ikke noe problem. Problemet er når nye funksjoner skal etableres på en eksisterende server.
Løsningen
Lag en regel over default deny regel som ser slik ut:
- Source: Alle soner med servere. Ikke kjør «Any» fordi det skaper mye støy
- Destination: Internett
- Application: ssl
- Action: allow
- Security Profile Groups: default med URL block Any
Intrazone
For inngående regelsett kan det være ett unntak (kommer an på oppsett), Internett til Internett. Dette er en intrazone kategori, som gjerne har en deny regel i bunn. Da lager jeg denne regelen over denne deny regelen:
Ekstra verdi:
Etter etablering av dette oppsettet finner man legitim trafikk som tidligere ikke er adressert og gjør deretter justeringer av etablerte regler.
Det skal ikke være mye trafikk som treffer denne regelen da den har til hensikt å identifisere elementer som ikke allerede er adressert.
Leave a Reply