Een Diepgaande Blik op de Architectuur van Iptables en Netfilter

Firewall

Inleiding

Firewalls zijn een belangrijk hulpmiddel dat geconfigureerd kan worden om uw servers en infrastructuur te beschermen. In het Linux-ecosysteem is iptables een veelgebruikt firewall-hulpmiddel dat samenwerkt met het netfilter-pakketfilterframework van de kernel. Het maken van betrouwbare firewall-beleidsregels kan ontmoedigend zijn, vanwege de complexe syntaxis en het aantal onderling verbonden onderdelen.

In deze handleiding duiken we in de architectuur van iptables met als doel het begrijpelijker te maken voor gebruikers die hun eigen firewall-beleidsregels moeten opstellen. We zullen bespreken hoe iptables interageert met netfilter en hoe de verschillende componenten samenkomen om een uitgebreid filtersysteem te bieden.

Wat zijn IPTables en Netfilter?

Voor vele jaren werd de meest gebruikte firewall software in Linux iptables genoemd. In sommige distributies is het vervangen door een nieuw gereedschap genaamd nftables, maar de syntax van iptables wordt nog steeds vaak gebruikt als referentiepunt. De iptables firewall werkt door interactie met de pakketfilteringshooks in de netwerkstack van de Linux kernel. Deze kernelhooks staan bekend als het netfilter framework.

Elk pakket dat door de netwerklaag gaat (inkomend of uitgaand) zal deze hooks triggeren, waardoor programma’s kunnen interacteren met het verkeer op belangrijke punten. De kernelmodules die geassocieerd zijn met iptables registreren zich bij deze hooks om ervoor te zorgen dat het verkeer voldoet aan de voorwaarden die zijn vastgelegd door de firewallregels.

Netfilter Hooks

Er zijn vijf netfilter hooks waar programma’s zich bij kunnen registreren. Terwijl pakketten door de stack vorderen, zullen ze de kernelmodules triggeren die zich hebben geregistreerd bij deze hooks. Welke hooks een pakket zal triggeren, hangt af van of het pakket inkomend of uitgaand is, de bestemming van het pakket, en of het pakket op een eerder punt is verworpen of afgewezen.

De volgende hooks vertegenwoordigen deze goed gedefinieerde punten in de netwerkstack:

NF_IP_PRE_ROUTING: Deze hook wordt geactiveerd door elk binnenkomend verkeer zeer binnenkort nadat het het netwerkstack is binnengekomen. Deze hook wordt verwerkt voordat er enige routingsbeslissingen zijn genomen over waar het pakket naartoe moet.
NF_IP_LOCAL_IN: Deze hook wordt geactiveerd nadat een inkomend pakket is gerouteerd als het pakket bestemd is voor het lokale systeem.
NF_IP_FORWARD: Deze hook wordt geactiveerd nadat een inkomend pakket is gerouteerd als het pakket moet worden doorgestuurd naar een andere host.
NF_IP_LOCAL_OUT: Deze hook wordt geactiveerd door elk lokaal gecreëerd uitgaand verkeer zodra het de netwerkstack raakt.
NF_IP_POST_ROUTING: Deze hook wordt geactiveerd door elk uitgaand of doorgestuurd verkeer nadat de routing heeft plaatsgevonden en vlak voordat het de draad opgaat.

Kernelmodules die zich bij deze hooks moeten registreren, moeten ook een prioriteitsnummer opgeven om de volgorde te bepalen waarin ze worden aangeroepen wanneer de hook wordt geactiveerd. Dit biedt de mogelijkheid voor meerdere modules (of meerdere exemplaren van dezelfde module) om verbonden te worden met elk van de hooks met deterministische volgorde. Elke module wordt achtereenvolgens aangeroepen en geeft na verwerking een beslissing terug aan het netfilter-framework die aangeeft wat er met het pakket moet gebeuren.

IPTables-tabellen en -ketens

De firewall iptables gebruikt tabellen om zijn regels te organiseren. Deze tabellen classificeren regels volgens het type beslissingen dat ze worden gebruikt om te maken. Als een regel bijvoorbeeld betrekking heeft op netwerkadresvertaling, wordt deze in de nat-tabel geplaatst. Als de regel wordt gebruikt om te beslissen of het pakket naar zijn bestemming moet worden doorgestuurd, wordt deze waarschijnlijk toegevoegd aan de filter-tabel.

Binnen elke iptables-tabel worden regels verder georganiseerd in afzonderlijke “ketens”. Terwijl tabellen worden gedefinieerd door het algemene doel van de regels die ze bevatten, vertegenwoordigen de ingebouwde ketens de netfilter-haken die ze activeren. Ketens bepalen wanneer regels worden geëvalueerd.

De namen van de ingebouwde ketens weerspiegelen de namen van de netfilter-haken waarmee ze zijn geassocieerd:

PREROUTING: Geactiveerd door de NF_IP_PRE_ROUTING-haak.
INPUT: Geactiveerd door de NF_IP_LOCAL_IN-haak.
FORWARD: Geactiveerd door de NF_IP_FORWARD-haak.
OUTPUT: Geactiveerd door de NF_IP_LOCAL_OUT-haak.
POSTROUTING: Geactiveerd door de NF_IP_POST_ROUTING-haak.

Ketens stellen de beheerder in staat om te bepalen waar in het afleveringspad van een pakket een regel wordt geëvalueerd. Omdat elke tabel meerdere ketens heeft, kan de invloed van een tabel op meerdere punten in de verwerking worden uitgeoefend. Omdat bepaalde soorten beslissingen alleen zinvol zijn op bepaalde punten in de netwerkstack, zal niet elke tabel een keten hebben geregistreerd bij elke kernelhaak.

Er zijn slechts vijf netfilter kernel hooks, dus bij elk van de haken zijn ketens van meerdere tabellen geregistreerd. Bijvoorbeeld, drie tabellen hebben PREROUTING ketens. Wanneer deze ketens zich registreren bij de bijbehorende NF_IP_PRE_ROUTING hook, specificeren ze een prioriteit die bepaalt in welke volgorde elke tabel’s PREROUTING keten wordt aangeroepen. Elke regel binnen de keten met de hoogste prioriteit wordt sequentieel geëvalueerd voordat de volgende PREROUTING keten wordt doorlopen. We zullen zo meteen de specifieke volgorde van elke keten bekijken.

Welke tabellen zijn er beschikbaar?

Laten we even terugkijken en kijken naar de verschillende tabellen die iptables biedt. Deze vertegenwoordigen verschillende sets regels, georganiseerd per aandachtsgebied, voor het evalueren van pakketten.

De Filtertabel

De filtertabel is een van de meest gebruikte tabellen in iptables. De filter tabel wordt gebruikt om beslissingen te nemen over het al dan niet doorlaten van een pakket naar zijn beoogde bestemming of om het verzoek te weigeren. In firewall-taal staat dit bekend als “filteren” van pakketten. Deze tabel biedt het grootste deel van de functionaliteit waar mensen aan denken bij het bespreken van firewalls.

De NAT-tabel

De nat tabel wordt gebruikt om netwerkadresvertalingsregels te implementeren. Wanneer pakketten het netwerkstack binnenkomen, zullen regels in deze tabel bepalen of en hoe het bron- of doeladres van het pakket moet worden gewijzigd om de route van het pakket en eventueel antwoordverkeer te beïnvloeden. Dit wordt vaak gebruikt om pakketten naar netwerken te routeren wanneer directe toegang niet mogelijk is.

De Mangle-tabel

De mangle tabel wordt gebruikt om de IP-headers van het pakket op verschillende manieren te wijzigen. Bijvoorbeeld, je kunt de TTL (Time to Live) waarde van een pakket aanpassen, door het aantal geldige netwerksprongen te verlengen of te verkorten dat het pakket kan volhouden. Andere IP-headers kunnen op vergelijkbare manieren worden gewijzigd.

Deze tabel kan ook een interne kernel-“markering” op het pakket plaatsen voor verdere verwerking in andere tabellen en door andere netwerktools. Deze markering raakt het eigenlijke pakket niet, maar voegt de markering toe aan de representatie van het pakket door de kernel.

De Ruwe Tabel

De firewall iptables is stateful, wat betekent dat pakketten worden geëvalueerd met betrekking tot hun relatie tot eerdere pakketten. De verbindingsvolgfuncties die zijn gebouwd op het netfilter-framework stellen iptables in staat om pakketten te bekijken als onderdeel van een lopende verbinding of sessie in plaats van als een stroom van afzonderlijke, niet-gerelateerde pakketten. De logica van verbindingsvolging wordt meestal zeer snel toegepast nadat het pakket de netwerkinterface heeft bereikt.

De raw-tabel heeft een zeer nauw omschreven functie. Het enige doel ervan is om een mechanisme te bieden om pakketten te markeren om ze uit te sluiten van verbindingsvolging.

De Beveiligingstabel

De security-tabel wordt gebruikt om interne SELinux-beveiligingscontextmarkeringen op pakketten in te stellen, die van invloed zullen zijn op hoe SELinux of andere systemen die SELinux-beveiligingscontexten kunnen interpreteren, de pakketten behandelen. Deze markeringen kunnen worden toegepast op basis van een per-pakket of per-verbinding.

Relaties tussen Ketens en Tabellen

Als drie tabellen PREROUTING-ketens hebben, in welke volgorde worden ze geëvalueerd?

De volgende tabel geeft de ketens aan die beschikbaar zijn binnen elke iptables-tabel wanneer ze van links naar rechts worden gelezen. Bijvoorbeeld, we kunnen zien dat de raw-tabel zowel de PREROUTING– als OUTPUT-ketens heeft. Wanneer van boven naar beneden gelezen, toont het ook de volgorde waarin elke keten wordt aangeroepen wanneer de bijbehorende netfilter-hook wordt geactiveerd.

A few things should be noted. In the representation below, the nat table has been split between DNAT operations (those that alter the destination address of a packet) and SNAT operations (those that alter the source address) in order to display their ordering more clearly. We have also include rows that represent points where routing decisions are made and where connection tracking is enabled in order to give a more holistic view of the processes taking place:

Tables↓/Chains→	PREROUTING	INPUT	FORWARD	OUTPUT	POSTROUTING
(routing decision)				✓
raw	✓			✓
(connection tracking enabled)	✓			✓
mangle	✓	✓	✓	✓	✓
nat (DNAT)	✓			✓
(routing decision)	✓			✓
filter		✓	✓	✓
security		✓	✓	✓
nat (SNAT)		✓			✓

Als een pakket een netfilter-hook activeert, worden de bijbehorende ketens verwerkt zoals ze worden vermeld in de bovenstaande tabel van boven naar beneden. De hooks (kolommen) die een pakket zal activeren, zijn afhankelijk van of het een inkomend of uitgaand pakket is, de routingbeslissingen die worden genomen, en of het pakket de filtercriteria doorstaat.

Bepaalde gebeurtenissen zullen ertoe leiden dat de keten van een tabel wordt overgeslagen tijdens de verwerking. Bijvoorbeeld, alleen het eerste pakket in een verbinding zal worden geëvalueerd tegen de NAT-regels. Eventuele beslissingen van nat die voor het eerste pakket zijn genomen, worden automatisch toegepast op alle volgende pakketten in de verbinding zonder aanvullende evaluatie. Reacties op genat-verbindingen zullen automatisch de omgekeerde NAT-regels hebben toegepast om correct te routeren.

Volgorde van Keten Traversal

Assuming dat de server weet hoe een pakket moet worden gerouteerd en dat de firewallregels de transmissie toestaan, vertegenwoordigen de volgende stromen de paden die worden doorlopen in verschillende situaties:

PREROUTING -> INPUT
Inkomende pakketten bestemd voor een andere host: PREROUTING -> FORWARD -> POSTROUTING
Lokaal gegenereerde pakketten: OUTPUT -> POSTROUTING

Als we de bovenstaande informatie combineren met de volgorde die is uiteengezet in de vorige tabel, kunnen we zien dat een inkomend pakket bestemd voor het lokale systeem eerst wordt geëvalueerd tegen de PREROUTING-ketens van de raw, mangle en nat tabellen. Vervolgens zal het de INPUT-ketens van de mangle, filter, security en nat tabellen doorlopen voordat het uiteindelijk wordt afgeleverd bij de lokale socket.

IPTables-regels

Regels worden geplaatst binnen een specifieke keten van een specifieke tabel. Als elke keten wordt aangeroepen, wordt het betreffende pakket gecontroleerd tegen elke regel binnen de keten in volgorde. Elke regel heeft een overeenkomstig component en een actiecomponent.

Overeenkomst

De overeenkomende sectie van een regel specificeert de criteria waaraan een pakket moet voldoen om de bijbehorende actie (of “doel”) te laten uitvoeren.

Het overeenkomstsysteem is zeer flexibel en kan aanzienlijk worden uitgebreid met aanvullende iptables-uitbreidingen. Regels kunnen worden geconstrueerd om overeen te komen op basis van het protocoltype, bestemming of bronadres, bestemming of bronpoort, bestemming of bronnetwerk, invoer- of uitvoerinterface, headers of verbindingsstatus, onder andere criteria. Deze kunnen worden gecombineerd om complexe regelsets te creëren om onderscheid te maken tussen verschillende verkeerstypen.

Doelen

A “target” refers to the actions that are triggered when a packet meets the matching criteria of a rule. Targets are generally divided into two categories:

Beëindigende doelen: Beëindigende doelen voeren een actie uit die de evaluatie binnen de keten beëindigt en de controle teruggeeft aan de netfilter-haak. Afhankelijk van de geleverde retourwaarde kan de haak het pakket laten vallen of toestaan dat het pakket doorgaat naar de volgende verwerkingsfase.
Niet-beëindigende doelen: Niet-beëindigende doelen voeren een actie uit en gaan door met de evaluatie binnen de keten. Hoewel elke keten uiteindelijk een definitieve beëindigingsbeslissing moet teruggeven, kunnen er vóór die tijd een willekeurig aantal niet-beëindigende doelen worden uitgevoerd.

De beschikbaarheid van elk doel in regels is afhankelijk van de context. Bijvoorbeeld, het tabel- en ketentype kan de beschikbare doelen dicteren. De geactiveerde uitbreidingen in de regel en de overeenkomende clausules kunnen ook de beschikbaarheid van doelen beïnvloeden.

Springen naar Door Gebruiker Gedefinieerde Ketens

Er is ook een speciale klasse van niet-aflopend doel: het springdoel. Springdoelen zijn acties die resulteren in evaluatie die naar een andere keten wordt verplaatst voor aanvullende verwerking. We hebben de ingebouwde ketens behandeld die zijn gekoppeld aan de netfilter-haken die ze aanroepen. Iptables staat echter ook toe dat beheerders hun eigen ketens maken voor organisatorische doeleinden.

Regels kunnen worden geplaatst in door de gebruiker gedefinieerde ketens op dezelfde manier als ze kunnen worden geplaatst in ingebouwde ketens. Het verschil is dat door de gebruiker gedefinieerde ketens alleen kunnen worden bereikt door “naar ze te springen” vanuit een regel (ze zijn niet zelf geregistreerd met een netfilter-haak).

Door de gebruiker gedefinieerde ketens fungeren als uitbreidingen van de keten die ze hebben aangeroepen. Bijvoorbeeld, in een door de gebruiker gedefinieerde keten zal de evaluatie terugkeren naar de oproepketen als het einde van de regellijst is bereikt of als een RETURN-doel wordt geactiveerd door een overeenkomende regel. Evaluatie kan ook springen naar aanvullende door de gebruiker gedefinieerde ketens.

Deze constructie maakt een grotere organisatie mogelijk en biedt het noodzakelijke kader voor een robuustere vertakking.

IPTables en Verbindingsvolging

We hebben het verbindingstrackingssysteem geïntroduceerd dat bovenop het netfilter-framework is geïmplementeerd toen we de raw-tabel en de criteria voor het matchen van verbindingsstatus bespraken. Verbindingstracking stelt iptables in staat beslissingen te nemen over pakketten die worden bekeken in de context van een lopende verbinding. Het verbindingstrackingssysteem voorziet iptables van de functionaliteit die het nodig heeft om “stateful” bewerkingen uit te voeren.

Verbindingstracking wordt zeer snel toegepast nadat pakketten de netwerkstack binnenkomen. De ketens van de raw-tabel en enkele sanity checks zijn de enige logica die wordt uitgevoerd op pakketten voordat de pakketten worden geassocieerd met een verbinding.

Het systeem controleert elk pakket tegen een reeks bestaande verbindingen. Het zal de status van de verbinding in zijn opslag bijwerken indien nodig en zal nieuwe verbindingen aan het systeem toevoegen wanneer dat nodig is. Pakketten die gemarkeerd zijn met het NOTRACK-doel in een van de raw-ketens zullen de routines voor verbindingstracking omzeilen.

Beschikbare statussen

Verbindingen die worden bijgehouden door het verbindingstrackingssysteem bevinden zich in een van de volgende statussen:

NEW: Wanneer een pakket arriveert dat niet is geassocieerd met een bestaande verbinding, maar niet ongeldig is als eerste pakket, wordt een nieuwe verbinding met dit label aan het systeem toegevoegd. Dit gebeurt zowel voor verbindingbewuste protocollen zoals TCP als voor verbindingloze protocollen zoals UDP.
ESTABLISHED: Een verbinding wordt van NEW naar ESTABLISHED veranderd wanneer het een geldige respons in de tegenovergestelde richting ontvangt. Voor TCP-verbindingen betekent dit een SYN/ACK, en voor UDP- en ICMP-verkeer betekent dit een respons waarbij de bron- en bestemmingsadressen van het oorspronkelijke pakket zijn omgewisseld.
RELATED: Pakketten die geen deel uitmaken van een bestaande verbinding, maar wel geassocieerd zijn met een verbinding die al in het systeem bestaat, worden gelabeld als RELATED. Dit kan een hulpverbinding betekenen, zoals bij FTP-gegevensoverdrachtverbindingen, of het kunnen ICMP-responsen zijn op verbindingspogingen door andere protocollen.
INVALID: Pakketten kunnen als INVALID worden gemarkeerd als ze niet zijn geassocieerd met een bestaande verbinding en niet geschikt zijn om een nieuwe verbinding te openen, als ze niet kunnen worden geïdentificeerd, of als ze om andere redenen niet routeerbaar zijn.
UNTRACKED: Pakketten kunnen als UNTRACKED worden gemarkeerd als ze zijn gericht in een raw-tabelketen om tracking te omzeilen.
SNAT: Dit is een virtuele status die wordt ingesteld wanneer het bronadres is gewijzigd door NAT-operaties. Dit wordt door het verbindingstrackingssysteem gebruikt zodat het weet dat het de bronadressen moet wijzigen in antwoordpakketten.
DNAT: Dit is een virtuele status die wordt ingesteld wanneer het bestemmingsadres is gewijzigd door NAT-operaties. Dit wordt door het verbindingstrackingssysteem gebruikt zodat het weet dat het het bestemmingsadres moet wijzigen bij het routeren van antwoordpakketten.

De staten die worden bijgehouden in het verbindingsvolgsysteem stellen beheerders in staat om regels te maken die zich richten op specifieke punten in het leven van een verbinding. Dit biedt de functionaliteit die nodig is voor meer grondige en veilige regels.

Conclusie

Het netfilter-pakketfilteringsframework en de iptables-firewall vormen de basis voor de meeste firewalloplossingen op Linux-servers. De netfilter-kernelhaken liggen dicht genoeg bij de netwerkstack om krachtige controle over pakketten te bieden terwijl ze door het systeem worden verwerkt. De iptables-firewall maakt gebruik van deze mogelijkheden om een flexibele, uitbreidbare methode te bieden om beleidsvereisten aan de kernel door te geven. Door te leren hoe deze stukken in elkaar passen, kunt u ze beter gebruiken om uw serveromgevingen te beheren en te beveiligen.

Als u meer wilt weten over het kiezen van effectieve iptables-beleidsregels, bekijk dan deze gids.

Deze gidsen kunnen u helpen bij het implementeren van uw iptables-firewallregels:

Source:
https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture