| Paketfilter (PF) | |
|---|---|
| Sorts | Brandvägg |
| Utvecklaren | OpenBSD- projekt |
| Skrivet i | C [1] [2] |
| Operativ system | BSD- system |
| Första upplagan | 1 december 2001 [3] |
| senaste versionen | 4.8 ( 1 november 2010 ) |
| Licens | BSD |
| Hemsida | FAQ |
Packet Filter (PF) är en brandvägg utvecklad som en del av OpenBSD- projektet . Den har hög hastighet, enkel konfiguration och fantastiska funktioner, inklusive stöd för IPv6 . Används för närvarande, förutom OpenBSD, i NetBSD [4] och FreeBSD [5] , samt MirOS BSD baserat på dessa tre , DesktopBSD , pfSense och andra. Eftersom version 10.7 PF används i Mac OS X. PF portades till Microsoft Windows och utgjorde grunden för Core Force -brandväggen [6] .
PF:s historia började år 2000, när Darren Reid , utvecklaren av IPFilter- brandväggen som användes vid den tiden i OpenBSD , ändrade licensen för den. Sedan exkluderades ipf från CVS -förrådet, och dess plats togs av releasen av OpenBSD 3.0 skriven från början PF.
OpenBSD 3.3 introducerade pfsync , ett pseudogränssnitt som låter dig replikera anslutningskontextinformation mellan två (och senare fler) värdar. När man använder CARP eller annan liknande teknik, tillåter pfsync, särskilt, att skapa feltoleranta konfigurationer från flera fysiska brandväggar: om en värd misslyckas, kommer den andra att fortsätta att bearbeta nätverkstrafik utan att bryta anslutningar.
Från början var PF ganska lik IPFilter. En stor omdesign av interiörarkitekturen började 2005 [7] genom ansträngningar av Henning Brower och Ryan McBride . Som en del av detta projekt fick PF stöd för en ny typ av matchningsregler , ett nytt schema för redovisning av sammanhanget för anslutningar ( engelska anger i den ursprungliga terminologin). En annan stor förändring var vägran att separera regeluppsättningar efter typ: tidigare hade PF, liksom IPFilter, separata regeluppsättningar för NAT och trafikfiltrering. Dessutom, som en del av den övergripande utvecklingen av OpenBSD, fick PF stöd för flera tabeller och routingdomäner .
PF består av två delar: själva paketfiltret [8] och pfctl-verktyget [9] som tillhandahåller ett gränssnitt för att hantera brandväggen. Filtret fungerar fullt ut i sammanhanget med operativsystemets kärna , interaktion med det utförs genom systemanropet ioctl . [10] Därför är pfctl strängt taget inte en nödvändig del av PF.
PF är inte ursprungligen utformad för flertrådad paketbehandling. Å andra sidan har frånvaron av lås en positiv effekt på prestandan.
PF kan hoppa över onödiga kontroller samtidigt som den klarar listan med regler. Till exempel, om två regler i rad endast hänvisar till TCP- protokollet kommer ett paket av något annat protokoll (till exempel UDP ), efter att det inte passar den första regeln, inte att kontrolleras på den andra. För att göra detta, först, när man sammanställer en uppsättning regler, kan pfctl, som känner till den optimala ordningen för kontroller, ändra den ömsesidiga ordningen för flera på varandra följande regler; sedan analyseras den förberedda uppsättningen vid laddning i PF och för varje regel sammanställs en övergångskarta för att en eller annan parameter inte matchar.
Vid optimering av listan med regler kan PF också ta hänsyn till den ackumulerade statistiken över frekvensen av kontroller för reglerna och justera övergångskartan i enlighet med denna statistik.
Filtret bearbetar nätverkspaket i ett (när ett paket skickas från samma dator som filtret är installerat på till en annan dator, eller vice versa) eller två (när det vidarebefordras inuti datorn eller när datorn med filtret fungerar som en nätverksgateway ) bearbetningscykel.
Själva behandlingen av paketet sker enligt en uppsättning regler. I slutet av bearbetningen kasseras eller hoppas paketet över. Varje regel består av en uppsättning villkor och en uppsättning instruktioner som exekveras när uppsättningen villkor är uppfyllda. Det finns tre typer av regler:
match Om paketet uppfyller villkoren för regeln, exekveras instruktionerna från denna regel omedelbart. matchningsregler används vanligtvis för NAT, trafikloggning, QoS och så vidare. blockera Om paketet inte matchar regelns villkor markeras det som blockerbart. PF låter dig antingen helt enkelt släppa paketet eller generera ett ICMP- felmeddelande. passera Om paketet uppfyller villkoren för regeln, markeras det som att det ska skickas vidare.Instruktionerna som skrivs för block- och passreglerna exekveras efter att genomgången av regeluppsättningen är klar. Om en block- eller pass-regel är märkt i enlighet därmed, om paketet uppfyller villkoren i denna regel, kommer passagen genom regeluppsättningen att avbrytas med utförandet av motsvarande instruktioner. Denna ordning låter dig ställa in en serie regler som gradvis begränsar räckvidden, vilket ser mer naturligt ut än den omvända ordningen. Om ingen block- eller pass-regel matchar, skickas paketet: detta är ett mått på skydd mot ett oavsiktligt fel vid konfigurering av brandväggen.
Reglerna kan innehålla följande riktlinjer:
normalisering sammansättning av fragmenterade och kassering av uppenbart felaktiga paket, såväl som andra operationer som förenklar vidare bearbetning; utsända trafikomdirigering vid lager 2 (mer subtila än vad konventionella routingverktyg kan tillhandahålla ) och 3 av OSI-modellen , med stöd för NAT och destinationsadresspooler; prioritering tvingad inställning av paketets tjänsttyp, placera paketet i en eller annan kö ALTQ ; filtrering fatta det slutliga beslutet att skicka eller blockera ett nätverkspaket.PF kan filtrera paket med följande parametrar:
Det sista alternativet låter dig skapa regler som avfyrar "ibland", vilket hjälper till att bekämpa (ibland oavsiktliga) DDoS-attacker .
Taggar tilldelas av PF-regler. Varje paket kan ha högst en tagg. Du kan ställa in/ersätta en tagg med en regel, men du kan inte ta bort en befintlig. Taggen behålls av paketet under hela tiden det passerar genom nätverksstacken.
PF låter dig också åsidosätta den routingtabell som används, så att paket kan överföras mellan routingdomäner. Naturligtvis är detta bara meningsfullt för inkommande trafik, för vilken rutten ännu inte har fastställts med standardmedel.
Du kan ange etiketter för regler . Samma etikett kan matcha flera regler. Etiketter låter dig bättre identifiera regler från användarutrymmet, samt inaktivera inbyggd regeluppsättningsoptimering för vissa regler; det senare kan behövas till exempel för faktureringssystem.
PF vet inte bara hur man filtrerar baserat på sammanhang, utan stöder också tre alternativ för att arbeta i det här läget (terminologi från originaldokumentationen):
behålla staten enkelt läge, endast korrespondensen mellan par av nätverksadresser och portar kommer ihåg; detta läge gäller inte bara för TCP utan även för UDP. modulera tillstånd ett mer komplext läge där PF självständigt väljer de initiala värdena för TCP-paketräknare; detta ger ett förbättrat skydd i de fall en av parterna väljer värdena på dessa räknare som är dåliga när det gäller sannolikheten att gissa. synproxytillstånd i detta läge upprättar PF oberoende en TCP-förbindelse med den andra sidan, och först efter det skickas motsvarande paket till initiatorn; detta ger skydd mot SYN-översvämningsattacker som förfalskar avsändarens adress.Som standard tar alla pass-regler hänsyn till sammanhanget (behåll tillstånd), och de som är relaterade till TCP kontrollerar också flaggorna för SYN-paketet. Detta görs eftersom det gör det möjligt att avsevärt minska volymen av regler (både vad gäller deras antal och vad gäller deras beskrivning i konfigurationsfilen) i typiska situationer. Samtidigt kan du med kraft vägra dessa funktioner för en specifik regel eller hela deras uppsättning. Det bör också beaktas att om paketet inte faller under någon pass-regel så sker inga kontroller och kontextskapande.
En av de mest intressanta funktionerna i PF är att arbeta med adresstabeller:
Till exempel kan alla privata adresser [11] [12] [13] matas in i en tabell i en enda tabell och sedan kan anslutningsförsök utifrån från antagligen dessa adresser blockeras med bara en regel.
Dessutom, genom att använda flaggorna för adressuteslutning (adressintervall), är det möjligt att specificera följande konfiguration med bara tre poster i tabellen: tabellen inkluderar intervallet 10.0.0.0/8, förutom 10.0.3.192/26, plus inkluderar också 10.0.3.211. Motsvarande poster i tabellen kan matas in i valfri ordning, PF kommer att använda dem enligt deras prefix (subnätmask).
Tredjepartsprogram, genom systemanropet ioctl eller genom programanropet pfctl, kan manipulera innehållet i tabeller. Till exempel stöder OpenBSD DHCP-servern dhcpd (länk unreachable) upp till tre PF-tabeller:
Regler kan kombineras till block ( ankare i originaldokumentationen). I det här fallet kan du ställa in allmänna parametrar för varje block, som kommer att gälla för alla regler i blocket.
Block bearbetas i linje med regler och kan kapslas in i varandra. Samtidigt kan innehållet i blocken ändras oberoende av varandra, såväl som från den allmänna listan över regler. Det senare är faktiskt samma block.
Regelblock är praktiska att använda i program som på något sätt styr trafikflöden. Programexempel:
| OpenBSD | |
|---|---|
| Operativ system |
|
| gafflar |
|
| Relaterade Projekt | |
| människor |
|
| Organisationer och andra resurser |
|
| Brandväggar | ||
|---|---|---|
| Fri | ||
| Fri |
| |
| Kommersiell |
| |
| Hårdvara | ||