| Pakkefilter (PF) | |
|---|---|
| Type | Firewall |
| Udvikler | OpenBSD- projekt |
| Skrevet i | C [1] [2] |
| Operativ system | BSD systemer |
| Første udgave | 1. december 2001 [3] |
| nyeste version | 4.8 ( 1. november 2010 ) |
| Licens | BSD |
| Internet side | FAQ |
Packet Filter (PF) er en firewall udviklet som en del af OpenBSD- projektet . Den har høj hastighed, nem konfiguration og fantastiske funktioner, herunder understøttelse af IPv6 . Bruges i øjeblikket, udover OpenBSD, i NetBSD [4] og FreeBSD [5] , samt MirOS BSD baseret på disse tre , DesktopBSD , pfSense og andre. Siden version 10.7 PF er brugt i Mac OS X. PF blev overført til Microsoft Windows og dannede grundlaget for Core Force firewallen [6] .
PF's historie begyndte i 2000, da Darren Reid , udvikleren af IPFilter- firewall'en brugt på det tidspunkt i OpenBSD , ændrede licensen til den. Så blev ipf udelukket fra CVS -depotet, og dets plads blev overtaget af udgivelsen af OpenBSD 3.0 skrevet fra bunden PF.
OpenBSD 3.3 introducerede pfsync , en pseudo-grænseflade, der giver dig mulighed for at replikere forbindelseskontekstinformation mellem to (og senere flere) værter. Ved brug af CARP eller anden lignende teknologi tillader pfsync især at skabe fejltolerante konfigurationer fra flere fysiske firewalls: Hvis en vært fejler, vil den anden fortsætte med at behandle netværkstrafik uden at afbryde forbindelser.
I starten var PF ret lig IPFilter. En større redesign af interiørarkitekturen begyndte i 2005 [7] gennem indsatsen fra Henning Brower og Ryan McBride . Som en del af dette projekt modtog PF støtte til en ny type matchregler , en ny ordning til at tage højde for sammenhængen med forbindelser ( engelsk angiver i den oprindelige terminologi). En anden stor ændring var afvisningen af at adskille regelsæt efter type: tidligere havde PF, ligesom IPFilter, separate regelsæt for NAT og trafikfiltrering. Som en del af den overordnede udvikling af OpenBSD modtog PF også støtte til flere tabeller og routingdomæner .
PF består af to dele: selve pakkefilteret [8] og pfctl-værktøjet [9] , som giver en grænseflade til styring af firewallen. Filteret fungerer fuldt ud i sammenhæng med operativsystemkernen , interaktion med det udføres gennem ioctl -systemkaldet . [10] Derfor er pfctl strengt taget ikke en nødvendig del af PF.
PF er ikke oprindeligt designet til multi-threaded pakkebehandling. På den anden side har fraværet af låse en positiv effekt på ydeevnen.
PF er i stand til at springe unødvendige kontroller over, mens de passerer listen over regler. For eksempel, hvis to regler i træk kun refererer til TCP -protokollen , så vil en pakke af enhver anden protokol (for eksempel UDP ), efter at den ikke passer til den første regel, ikke blive kontrolleret på den anden. For at gøre dette kan pfctl først, når der kompileres et sæt regler, ved at kende den optimale rækkefølge af kontroller ændre den gensidige rækkefølge af flere på hinanden følgende regler; derefter analyseres det forberedte sæt ved indlæsning i PF, og for hver regel kompileres et overgangskort for mismatch af en eller anden parameter.
Ved optimering af regellisten kan PF også tage højde for den akkumulerede statistik over kontrolfrekvensen for reglerne og justere overgangskortet i overensstemmelse med denne statistik.
Filteret behandler netværkspakker i én (når der sendes en pakke fra den samme computer , som filteret er installeret på, til en anden computer eller omvendt) eller to (når den videresendes inde i computeren, eller når computeren med filteret fungerer som en netværksgateway ) behandlingscyklus.
Selve behandlingen af pakken sker i henhold til et sæt regler. Ved afslutningen af behandlingen bliver pakken enten kasseret eller sprunget over. Hver regel består af et sæt betingelser og et sæt instruktioner, der udføres, når sættet af betingelser er opfyldt. Der er tre typer regler:
match Hvis pakken opfylder reglens betingelser, udføres instruktionerne fra denne regel med det samme. matchregler bruges almindeligvis til NAT, trafiklogning, QoS og så videre. blok Hvis pakken ikke matcher reglens betingelser, er den markeret som blokerbar. PF giver dig mulighed for enten blot at droppe pakken eller generere en ICMP- fejlmeddelelse. passere Hvis pakken opfylder reglens betingelser, er den markeret som om den skal sendes videre.Instruktionerne skrevet for blok- og beståelsesreglerne udføres efter gennemgangen af regelsættet er fuldført. Hvis en blok- eller pass-regel er markeret i overensstemmelse hermed, så hvis pakken opfylder betingelserne i denne regel, vil passagen gennem regelsættet blive afbrudt med udførelsen af de tilsvarende instruktioner. Denne rækkefølge giver dig mulighed for at angive en række regler, der gradvist indsnævrer omfanget, hvilket ser mere naturligt ud end den omvendte rækkefølge. Hvis ingen blok- eller pass-regel matcher, er pakken bestået: dette er et mål for beskyttelse mod en utilsigtet fejl ved konfiguration af firewallen.
Reglerne kan indeholde følgende retningslinjer:
normalisering samling af fragmenterede og kassering af åbenlyst ukorrekte pakker, samt andre operationer, der forenkler yderligere behandling; udsende trafikomdirigering på lag 2 (mere subtil end konventionelle routingværktøjer kan give ) og 3 i OSI-modellen med understøttelse af NAT og destinationsadressepuljer; prioritering tvungen indstilling af pakkens servicetype, anbringelse af pakken i en eller anden kø ALTQ ; filtrering træffe den endelige beslutning om at videregive eller blokere en netværkspakke.PF kan filtrere pakker efter følgende parametre:
Den sidste mulighed giver dig mulighed for at oprette regler, der affyrer "nogle gange", hvilket hjælper med at bekæmpe (nogle gange utilsigtede) DDoS-angreb .
Tags tildeles af PF-regler. Hver pakke kan højst have ét mærke. Du kan indstille/erstatte et tag med en regel, men du kan ikke fjerne et eksisterende. Tagget beholdes af pakken i hele den tid, den passerer gennem netværksstakken.
PF giver dig også mulighed for at tilsidesætte den anvendte routingtabel, så pakker kan overføres mellem routingdomæner. Dette giver naturligvis kun mening for indgående trafik, som ruten endnu ikke er fastlagt for med standardmidler.
Du kan angive etiketter for regler . Den samme etiket kan matche flere regler. Etiketter giver dig mulighed for bedre at identificere regler fra brugerområdet, samt deaktivere indbygget regelsætoptimering for visse regler; sidstnævnte kan f.eks. være nødvendig for faktureringssystemer.
PF ved ikke kun, hvordan man filtrerer baseret på kontekst, men understøtter også tre muligheder for at arbejde i denne tilstand (terminologi fra den originale dokumentation):
holde tilstand simpel tilstand, kun korrespondancen af par af netværksadresser og porte huskes; denne tilstand gælder ikke kun for TCP, men også for UDP. modulere tilstand en mere kompleks tilstand, hvor PF uafhængigt vælger startværdierne for TCP-pakketællere; dette giver forbedret beskyttelse i tilfælde, hvor en af parterne vælger værdierne af disse tællere, der er dårlige med hensyn til sandsynligheden for at gætte. synproxy tilstand i denne tilstand etablerer PF uafhængigt en TCP-forbindelse med den anden side, og først derefter sendes de tilsvarende pakker til initiatoren; dette giver beskyttelse mod SYN-oversvømmelsesangreb, der forfalsker afsenderens adresse.Som standard tager alle pass-regler hensyn til konteksten (behold tilstand), og dem, der er relateret til TCP, kontrollerer også flagene for SYN-pakken. Dette gøres, fordi det gør det muligt at reducere mængden af regler betydeligt (både med hensyn til deres antal og med hensyn til deres beskrivelse i konfigurationsfilen) i typiske situationer. Samtidig kan du kraftigt nægte disse funktioner for en bestemt regel eller hele deres sæt. Det skal også tages i betragtning, at hvis pakken ikke falder ind under nogen pass-regel, så sker der ingen kontrol og kontekstoprettelse.
En af de mest interessante funktioner ved PF er at arbejde med adressetabeller:
For eksempel kan alle private adresser [11] [12] [13] indtastes i en tabel i en enkelt tabel, og derefter kan forbindelsesforsøg udefra fra angiveligt disse adresser blokeres med kun én regel.
Ved at bruge adresseekskluderingsflag (adresseområder) er det desuden muligt at specificere følgende konfiguration ved hjælp af kun tre indtastninger i tabellen: Tabellen inkluderer området 10.0.0.0/8, bortset fra 10.0.3.192/26, plus inkluderer også 10.0.3.211. Tilsvarende poster i tabellen kan indtastes i enhver rækkefølge, PF vil bruge dem i henhold til deres præfikser (undernetmaske).
Tredjepartsprogrammer, gennem ioctl -systemkaldet eller gennem pfctl-programkaldet, kan manipulere indholdet af tabeller. For eksempel understøtter OpenBSD DHCP-serveren dhcpd (link unreachable) op til tre PF-tabeller:
Regler kan kombineres til blokke ( ankre i den originale dokumentation). I dette tilfælde kan du indstille generelle parametre for hver blok, som vil være gyldige for alle regler i blokken.
Blokke behandles på linje med regler og kan indlejres i hinanden. Samtidig kan indholdet af blokkene ændres uafhængigt af hinanden, samt fra den generelle liste over regler. Sidstnævnte er faktisk den samme blok.
Blokke af regler er praktiske til brug i programmer, der på en eller anden måde styrer trafikstrømmene. Program eksempler:
| OpenBSD | |
|---|---|
| Operativ system |
|
| gafler |
|
| Relaterede projekter | |
| Mennesker |
|
| Organisationer og andre ressourcer |
|
| Firewalls | ||
|---|---|---|
| Ledig | ||
| Ledig |
| |
| Kommerciel |
| |
| Hardware | ||