macOS pf-brannmuren: hva den kan gjøre, og hvorfor den ikke kan være din app-brannmur

Hver Mac leveres med to ting folk kaller "brannmuren". Den ene er applikasjonsbrannmuren i systeminnstillinger, en veksling per app for innkommende tilkoblinger. Den andre, roligere er pf, BSD-pakkefilteret som macOS arvet fra FreeBSD/OpenBSD-linjen og som Apple selv bruker under panseret for internettdeling, VPN og NAT. Avanserte brukere og administratorer kan snakke med den direkte med pfctl, og mange guider viser en pf.conf-snutt og kaller det en dag. Det disse guidene sjelden forklarer er hvor pf slutter å være nyttig for det folk flest faktisk vil ha: å se og kontrollere hva deres egne apper sender ut. Dette er et laboratorium, ikke en forelesning – vi vil slå pf på, skrive en regel, lese tilstanden den beholder, og så se på nøyaktig hvorfor den tilstanden er feil form for en app-brannmur.

Hva pf egentlig er

pf er et pakkefilter på kjernenivå: det inspiserer pakker når de krysser nettverksgrensesnitt og bestemmer regel for regel om de skal sendes eller blokkeres. Den har ikke noe begrep om "apper" - den fungerer utelukkende på pakkehoder: kilde- og destinasjonsadresse, port, protokoll, grensesnitt, retning. Det er ikke en begrensning noen glemte å fikse; det er designet. pf ble bygget for å filtrere trafikk på nettverkslaget, det samme laget rutere og gatewayer opererer på, og den er veldig god på den jobben.

Du snakker med den med pfctl, kontrollverktøyet. Dens man-side er eksplisitt om splittelsen mellom de to tingene den gjør: den laster inn regelsett fra en konfigurasjonsfil, og den rapporterer om tilstanden kjernen har. To flagg betyr mest for å aktivere og deaktivere filteret, med man-sidens egne ord: -e ("Aktiver pakkefilteret.") og -d ("Deaktiver pakkefilteret."). Ingenting annet om pf er på eller av - hele regelsettet beveger seg sammen.

Slår den på og leser statusen

En rask lab, på en Mac hvor du er komfortabel med å bruke sudo. Kontroller først om filteret allerede er aktivert og se tellerne:

$ sudo pfctl -s info
# example output, trimmed — the real thing includes per-rule and per-source-tracking stats with -v
Status: Enabled for 0 days 02:14:07		Debug: err
State Table                          Total             Rate
  current entries                       42
  searches                           88213             9.7/s
  inserts                              611             0.1/s
  removals                             569             0.1/s

List deretter reglene som kjernen har for øyeblikket. pfctl -s rules gjør akkurat dette; man-siden bemerker at med -v skriver den også ut tellinger per regel, pakker og byte:

$ sudo pfctl -s rules
# example output, trimmed
scrub-anchor "com.apple/*" all fragment reassemble
anchor "com.apple/*" all
block drop in log quick from <blocklist> to any

Den com.apple/*-linjen er ikke dekorasjon. Apple laster inn sine egne regler i navngitte ankere - pfs betegnelse for et selvstendig underregelsett som kan byttes inn og ut uten å laste inn alt annet. pfctls -a-flagg retter seg mot et spesifikt anker, og, i henhold til man-siden, muliggjør bruk av det med et jokertegn rekursiv utskrift av nestede ankere, som er hvordan du ser hva Apple selv har lastet sammen med alt du legger til:

$ sudo pfctl -a '*' -s rules
# example output, trimmed to the anchors that exist on a stock Mac

Skrive og laste inn en testregel

En minimal ankerfil som blokkerer én utgående IP-adresse, lagret som /etc/pf.anchors/test-block:

block drop out quick on en0 proto tcp to 203.0.113.10 port 443

For å laste en enkelt ankerfil, leser pfctl -f regler fra en fil, i henhold til man-siden, som beskriver filen som inneholdende makroer, tabeller, alternativer og filtreringsregler:

$ sudo pfctl -f /etc/pf.anchors/test-block
$ sudo pfctl -s rules
block drop out quick on en0 proto tcp from any to 203.0.113.10 port = 443

Hvorfor pf ikke kan være din app-brannmur

Ingenting av det som følger er en feil. Det er det som skjer når du peker et nettverkslagspakkefilter mot en jobb som krever å vite hvilken prosess som sendte pakken.

Den aner ikke hvilken app som sendte pakken

pf-regler samsvarer med IP, port, protokoll, grensesnitt og retning. Det er ikke noe felt for "prosessnavn", "buntidentifikator" eller "kodesignatur", fordi pf sitter på laget der pakker finnes, men prosesser ikke. To helt forskjellige apper som åpner TCP-tilkoblinger til samme IP og port kan ikke skilles fra pf. Hvis du vil la Slack nå en vert mens du blokkerer alle andre apper fra å nå den samme verten, kan ikke pf alene uttrykke den regelen.

En regel for et vertsnavn er en regel for hvilken IP-adresse det vertsnavnet hadde ved innlastingstid

pf.conf-filer refererer ofte til et vertsnavn for lesbarhet - block from evil.example.com. Det som faktisk blir lastet er ikke det navnet; det er uansett hvilken adresse det er løst til. OpenBSD pf.conf man-siden sier dette tydelig: "Vertsnavnoppløsning og grensesnitt for adresseoversettelse gjøres ved regelsett lastetid." Det er ingen kjøretids DNS-oppslag når trafikken flyter – erstatningen skjer én gang når du kjører pfctl -f, og regelen fortsetter å matche den ene adressen til du laster den inn på nytt. Det er greit for en server med en statisk IP. Den faller fra hverandre i det øyeblikket navnet bak den er en CDN, en skylastbalanserer, eller en hvilken som helst tjeneste som roterer eller lastbalanserer på tvers av mange adresser – som beskriver det meste av internett i 2026. En regel som er ment å blokkere «denne tjenesten», begrenser seg stille til «den av den tjenestens IP-er som tilfeldigvis svarte da jeg lastet inn alle andre adresser til samme vertsnavn».

Ingen forespørsler, ingen samtale - bare et statisk regelsett

pf har ingen interaksjonsmodell. Den kan ikke sette en tilkobling på pause og spørre "Mail ønsker å nå 51.x.x.x på port 993 for første gang — tillate det?" Den samsvarer enten med en regel du allerede har skrevet, eller så faller den gjennom standarden. Hver beslutning må forutses og skrives ned på forhånd, i IP-og-port-termer, før trafikken skjer. Det er ingen ekvivalent med en forespørsel om første tilkobling, fordi forespørsel krever å vite hvilken app som spør, og pf har ikke den informasjonen til å begynne med.

Din håndskrevne konfigurasjon overlever ikke en oppdatering

Apple behandler /etc/pf.conf og ankrene den laster inn som systemadministrert konfigurasjon knyttet til macOS internals – internettdeling, VPN, applikasjonsbrannmurens egne ankere er avhengig av det. macOS-oppdateringer er gratis å omskrive eller erstatte den filen. Hvis du har håndredigert den for å legge til dine egne regler, er det ingen garanti for at de overlever neste oppdatering; du finner ut på den harde måten, i ettertid, at regelen din i det stille sluttet å gjelde. En konfigurasjonsfil som en person vedlikeholder for hånd og som operativsystemet med jevne mellomrom overskriver, er et dårlig sted å oppbevare den ene tingen du faktisk brydde deg om - "snakket Mac-en min til den adressen igjen."

Ingen loggvisning, ingen historikk, ingen kart

pf kan logge matchede pakker til et pseudo-grensesnitt, pflog0, hvis en regel inkluderer log nøkkelordet — synlig ovenfor i blokkeringslisteregelen fra den tidligere -s rules-utgangen. Men den loggen er en pakkefangststrøm, lesbar med tcpdump -i pflog0, ikke en søkbar historie. Det er ingen innebygd visningsprogram, ingen per-app-liste over hva som ble blokkert og når, ingen land eller organisasjon knyttet til en adresse, ingenting du ville vise noen å svare på "hva prøvde denne Macen å nå forrige uke." Du får råpakker, og resten får du bygge selv.

Laget Apple faktisk bygget for denne jobben

Apples eget svar på "Jeg vil filtrere Mac-trafikken per app" er ikke pf - det er Network Extension-rammeverket, spesielt innholdsfilterleverandørene. Apples utviklerdokumentasjon beskriver modellen direkte: "Et nettverksinnholdsfilter på enheten undersøker brukernettverksinnhold når det passerer gjennom nettverksstabelen og bestemmer om det skal blokkere det innholdet eller tillate det å sende videre til det endelige målet," og en filterdataleverandør - en NEFilterDataProvider - ​​"mottar brukernettverksinnhold og undersøker innholdet for å bestemme om det skal blokkeres eller tillate det." Strømmer er representert som NEFilterFlow objekter (med NEFilterBrowserFlow og NEFilterSocketFlow som konkrete tilfeller), som er den manglende brikken pf aldri hadde: et flytobjekt som en filtreringsapp kan inspisere og knytte tilbake til prosessen som åpnet den, før den bestemmer seg for pass eller blokkering.

Dette er også grunnen til at den innebygde applikasjonsbrannmuren (bryteren i systeminnstillinger) er et annet dyr enn pf, ikke en frontend for det. Apples egen guide beskriver det bare i inngående termer: den "kan beskytte Mac-en din mot uønsket kontakt initiert av andre datamaskiner," og den fungerer ved å la deg "velge apper og tjenester, og spesifisere om de kan ha tilgang gjennom brannmuren." Per app, ja - men bare for tilkoblinger som kommer inn, og bare gjennom den spesifikke mekanismen Apple bygde for den ene jobben. Den svarer på et annet spørsmål enn "hva sender appen min ut."

Ingenting av dette gjør pf ubrukelig. Hvis du kjører en Mac som en lettvektsruter, trenger å avvise en kjent-dårlig rekkevidde på kjernenivå uavhengig av hvilken prosess du spør om, eller ønsker å forstå hva Apples egne internettdelings- og VPN-funksjoner gjør under panseret, er pf det riktige og eneste verktøyet for den jobben, og pfctl -s rules / -s info er den rette måten å se det på. Det den aldri kom til å gjøre er å svare på spørsmålet folk flest faktisk har: hvilke av appene mine snakker til hvem, akkurat nå, og kan jeg bli spurt før en ny kommer til.

Hvor FireAI og HisnLabs kommer inn

pf and the built-in Application Firewall are both worth using — FireAI does not replace either; it fills the specific gap neither one can, by tying outbound decisions to the app’s code signature and asking before an unknown one gets a first connection.

FireAI er HisnLabs’ eget produkt: en KI-brannmur som kjører direkte på Macen. Den viser hver tilkobling appene dine gjør, i klart språk, og lar deg bestemme hva som forlater Macen din — KI-en kjører lokalt, så trafikken din sendes aldri til oss eller noen andre. HisnLabs’ sikkerhetsforskningsteam er de som holder disse vurderingene pålitelige: de katalogiserer hvilke domener som er vanlig telemetri og hvilke som er en ekte tjeneste, sporer landet og nettverket bak en tilkobling, og trener den lokale modellen (Autopilot-funksjonen) på ekte trafikkmønstre — uten at noe av det forlater Macen din.

Du kan lese om de tekniske valgene bak, eller prøve FireAI i 17 dager, på FireAI, fra HisnLabs.