Jeg har i markedet opplevd at det finnes en del misforståelser mellom reverse DNS og URL. Har også opplevd manglende viten, forståelse og kompetanse på URL’er og bruk av dette i regelsett vs IP adresser. Det er veldig viktig å forstå URL’er og mulighetene man har i Palo Alto Networks.
Dette er ment som en enkel oversikt, med det mål å synliggjøre forskjellene her i forhold til bruk av de forskjellige elementene i et brannmurregelsett når man har en moderne brannmur som kan ta avgjørelser bl.a basert på IP, FQDN og URL. Det er viktig å vite forskjellen fordi dette gjør stor forskjell på mulighetene.
- IP er helt fint i interne systemer som ikke er store og komplekse.
- Noen ganger gir det mening å bruke FQDN, men da må man være klar over fordeler, risikoer, kompleksitet og avhengighet av DNS.
- Noen ganger er URL den ultimate løsningen for en god policy, et unntak, fleksibilitet og mulighet. URL funksjonaliteten er nok en skjult skatt for mange
Vil derfor gjøre en kortfattet gjennomgang av forskjellene her, samt vise en rask demovideo.
Internet Protocol (IP)
IP er IP. Det er avsender-IP, og det er mottager-IP. Det er IP på PC’er, mobiltelefoner, servere, TV’er, kjøleskap, industrisystemer, i skyen, spillkonsoll, overvåkingskamera, medisinsk utstyr, bilen din, og mye mye mer.
Når ting skal snakke sammen, skjer dette basert på IP og protokoll, gjerne med portnummer. I gamle gamle dager ville man initiere en forbindelse ved å bruke IP. Alt var mindre. Alt var enklere. Man husket IP-adresser. Husker jeg brukte IP for å lese VG.
Husker fortsatt at OKDN, Oslo Kommunes Digitale Nettverk, hadde 100 nettet. 100.201.x.y var bydel 1.
- 100 var OKDN
- 201 var etaten eller bydelen
- (100.7.x.x var SDS, Statens Data Sentral, med Takos 100.7.1.1)
- x var lokasjon i bydelen
- y var host. .250 var default gateway i alle nettverk i hele kommunen
Det var naturligvis struktur. Dette hjalp på oversikt, kontroll og feilsøking.
I Palo Alto Networks brannmurer brukes dette i adresseobjekter samt source og destination i regelsett.
Fully Qualified Domain Name (FQDN)
https://en.wikipedia.org/wiki/Fully_qualified_domain_name
Dette er betegnelsen på oppbyggingen av et navn.
www.dataequipment.no
- www -> Hostname
- dataequipment.no -> Domain
- no -> Top Level Domain (TLD)
I Palo Alto Networks brannmurer brukes dette i adresseobjekter samt source og destination i regelsett.
Domain Name System (DNS)
https://en.wikipedia.org/wiki/Domain_Name_System
Ettersom nettverk ble større, både internt og internett, kom DNS. Det var gjerne enklere å huske navn, og det var enklere å holde struktur og orden. FQDN og DNS henger naturligvis sammen.
Hensikten med DNS er å være telefonkatalogen på nettet.
- Man har gjerne interne DNS-tjenere for interne nettverk og interne tjenester.
- Man har DNS-tjenere for sine internettdomener for tjenester tilgjengelig fra internett, som websider og e-postservere.
- dataequipment.no internt er forskjellig fra dataequipment.no eksternt
Alt dette er typisk Forward DNS, der man gjør om et navn til en IP.
I Palo Alto Networks brannmurer må en DNS server konfigureres for at navneoppslag skal fungere, for interne brannmurtjenester, for å kunne kommunisere med oppdateringsservere, kjøre reverse DNS lookup, sende e-post og mer.
Reverse DNS
https://en.wikipedia.org/wiki/Reverse_DNS_lookup
Viser dette i videoen.
Reverse DNS er IKKE URL. Dette er litt av hovedgrunnen til at jeg skrev denne artikkelen.
Mens Forward DNS gjør om fra navn til IP, gjør Reverse DNS det motsatte. Om du har en IP, i en logg eller en hendelse, og lurer på hva dette er, kan du kjøre en Reverse DNS Lookup.
- nslookup 100.200.10.20
Det vil typisk gi deg et navn tilbake. Men ikke alltid. Og navnet har som regel ikke noe med tjenesten å gjøre.
Om du gjør «nslookup www.domene.no» (som er forward DNS lookup) og får IP 123.234.4.200, kan «nslookup 123.234.4.200» (som er reverse DNS lookup) gjerne gi svaret server1.domene.no.
Reverse DNS må konfigureres, og eksisterer ikke alltid. Gjør du reverse DNS lookup er det ikke alltid at du får en navn tilbake. Det er ikke nødvendigvis feil.
I Palo Alto Networks brannmurer ser man dette i loggene.
Passiv DNS
Om du har en IP, kan du gjøre Reverse DNS lookup. Som vist over kan svaret gi deg navnet på serveren. Men du lurer kanskje på hva som gjorde at noe eller noen i utgangspunktet satte opp en forbindelse med denne IP-adressen. Hva slags FQDN ble benyttet? Da er det en funksjon som heter Passive DNS. Dette er en database du kan spørre inn i, for å finne hvilke navn som har gitt denne IP-adressen. Veldig fint for feilsøking.
- Reverse DNS lookup av 123.234.4.200 gir server1.domene.no
- Passiv DNS lookup av 123.234.4.200 kan gi mange FQDNs om dette er en webserver for mange websider, eller kun et navn. Dette kan være www.domene.no
I Palo Alto Networks brannmurer får man dette med AutoFocus.
Uniform Resource Locator (URL)
Du har FQDN. Du har URL. Du har URI. Det tar alt for lang tid å forklare alt her, så anbefaler å sjekke denne Wikipedia-linken. Når du skriver zerotrust.no i internettleseren din, er det både et FQDN og domene. Fordi internett og internettleseren har blitt som det har blitt (for det var ikke slik før, da man måtte skrive www.zerotrust.no), havner man på websidene til Data Equipment. Da har man kommunisert https://zerotrust.no, som blir URL’en. Når man besøker denne siden henter man mange objekter, inkludert objekter fra andre lokasjoner og domener, som f.eks. https://location1.cdn.com/images/picture123.png.
Om man ikke har SSL dekryptering i Palo Alto Networks brannmuren vil man se dette i URL loggen:
- zerotrust.no/
- location1.cdn.com/
Om man har SSL dekryptering i Palo Alto Networks brannmuren ser man alt, inkludert at alle sikkerhetsprofiler får full verdi:
- zerotrust.no/
- location1.cdn.com/images/picture123.png
Dette betyr at mulighetene med brannmuren utvides.
URL-muligheter i Palo Alto Networks
I regelsettet kan man matche på source sone og IP/FQDN, man kan matche på destination sone og IP/FQDN, man kan matche på bruker (User-ID), man kan matche på applikasjon (App-ID), og man kan matche på URL. Og det er den siste her som ofte er en skjult skatt. Ikke så rart, da Palo Alto Networks har valgt å skjule denne kolonnen i regelsettet, slik at du manuelt må velge å legge den til. Dette viser jeg i videoen.
Se alle mulighetene med URL her:
URL som match kriterium i regelsettet vs i URL Profile
Om du skal lage en regel som tillater kommunikasjon, fra internett mot din webtjeneste, eller fra en server mot internett, bygger du gjerne opp regelen slik:
Internett mot web tjeneste
- Source zone: Internett
- Destination zone: DMZ
- Destination: IP eller FQDN
- Application: ssl (om man ikke dekrypterer), web-browsing (om man dekrypterer)
- Service: application-default (som håndterer dekryptering og web-browsing med port 443)
- URL: Custom URL category med «zerotrust.no»
- Profiles: Alle, basert på BPAT, for beskyttelse, men også for logging av URL’er
Servere mot internett
Viser dette i videoen.
I tråd med god cyber hygiene er det viktig å hviteliste hva en server kan gjøre mot internett. Dette bl.a. for å være robust mot moderne angrep som avhenger av callback/phone home/command & control.
Starter man med en liberal regel, som tillater det meste, vil man i traffic log og URL log se hvilke applikasjoner og URL’er serveren har kommunisert med. Dette benytter man deretter for å bygge opp det hvitelistede regelsettet. Det kan være fornuftig med minst to regler per server/servergruppe. En regel som inneholder applikasjoner som ikke benytter URL, og en som benytter applikasjoner OG URL. Et eksempel på det siste er en Windows server som liker å snakke hjem til microsoft.com. Det er umulig å gjøre dette basert på IP, derfor kommer URL inn i bildet. Du kan lage en regel som dette:
- source zone: domain controllers
- Source: domain controllers IPs or FQDNs
- Destination zone: internet
- Application: web-browsing
- URL category: Custom URL category inneholdene *.microsoft.com/
- Profiles: alle profiler for beskyttelse og logging
Dette gjør at domene kontrollerne ikke kan kjøre ldap eller rmi mot internett som en start på callback i forbindelse med Log4J sårbarheten CVE-2021-44228.
SSL dekryptering og URL
Når man skal dekryptere, vil unntak være en naturlig del av konfigurasjonen. Disse gjør jeg kun basert på URL, aldri IP.
EDL - External Dynamic List
https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/policy/use-an-external-dynamic-list-in-policy/external-dynamic-list.html
Med Palo Alto Networks brannmurer kan man laste ned lister med informasjon for bruk i regelsett. Dette kalles EDL. Disse kan laste ned IP, for bruk i tilgangskontroll og mer, domain, for bruk i Anti Spyware DNS policy og URL for bruk i tilgangskontroll eller URL profiles.
Husk at EDL kan laste ned lister fra f.eks. Github.
URL profile
Denne legges på allow regler. Den har to funksjoner. Sperring og logging av URL’er i kategorier du har valgt å ikke tillate, samt logging av all tillatt URL trafikk. Det er viktig å aldri bruke allow som action i en profile, da det ikke logger. Alert tillater og logger.
Ikke bruk profiles i en policy for å tillate en spesifikk URL, da det er komplisert og sårbart.
Bruk heller ikke URL category som match kriterie når du ønsker å sperre en URL, da det vil forhindre logging av URL.
- Sperring av URL’er gjøres i profiles på allow regler
- Tillatelse av URL’er gjøres i match kriterie i en regel
