Terug naar blog

De architectuur van Iptables en Netfilter

De architectuur van Iptables en Netfilter

Een firewall is een beveiligingsapparaat (hardware/software) dat het netwerk beschermt door verkeer te filteren en ongewenste/ongeautoriseerde toegang tot privégegevens te blokkeren. Het hebben van een goede firewall is belangrijk om uw servers en infrastructuur te beschermen. Het kan niet alleen ongewenst verkeer blokkeren, maar ook voorkomen dat kwaadaardige software het systeem infecteert.

In het Linux-ecosysteem is iptables een populaire firewall die communiceert met het netfilter framework op de Linux-kernel. De meeste moderne Linux-systemen worden geleverd met deze vooraf ingebouwde tools. Om het meeste uit deze systemen te halen, is het essentieel om hun architecturen te begrijpen. Anders kan het ontwikkelen van betrouwbare firewall-beleidsregels ontmoedigend zijn. Het kan leiden tot het creëren van ingewikkelde syntaxis, onderling samenhangende onderdelen in het framework, enz.

Deze gids duikt diep in de architectuur van iptables om gebruikers te helpen die hun eigen firewall-beleidsregels moeten maken. We zullen ook onderzoeken hoe iptables communiceert met netfilter en hoe de verschillende componenten in elkaar passen.

Iptables en Netfilter

In Linux is de iptables firewall de meest gebruikelijke. Deze werkt door te communiceren met de pakketfilteringshooks in de netwerkstack van de Linux-kernel. Het zijn deze kernelhooks die gezamenlijk worden aangeduid als het netfilter framework.

Elk inkomend/uitgaand pakket in het systeem zal deze hooks activeren naarmate het zich door de stack beweegt. Hierdoor kunnen de programma’s die bij deze hooks zijn geregistreerd, op cruciale punten met het verkeer communiceren. Ten slotte maken de kernelmodules die zijn gekoppeld aan iptables verbinding met deze hooks om de gespecificeerde firewall-regels af te dwingen.

Netfilter Hooks

Om programma’s verbinding te laten maken, zijn er vijf verschillende netfilter hooks. Naarmate pakketten zich door de stack bewegen, activeren de hooks de kernelmodules die erbij zijn geregistreerd. De activeringsvoorwaarde hangt af van omstandigheden zoals:  de richting van het pakket (inkomend/uitgaand), de bestemming van het pakket, of het pakket op een eerder punt is weggeworpen/geweigerd, enz.

Dit zijn de hooks die verschillende goed gedefinieerde punten in de netwerkstack vertegenwoordigen:

  • NF_IP_PRE_ROUTING: Deze hook wordt geactiveerd door elk inkomend verkeer. De activering vindt plaats voordat er een routeringsbeslissing wordt genomen over de bestemming van het pakket.

  • NF_IP_LOCAL_IN: Deze hook wordt geactiveerd na het routeren van een inkomend pakket. Het pakket moet ook bestemd zijn voor het lokale systeem.

  • NF_IP_FORWARD: Deze hook wordt ook geactiveerd na het routeren van een inkomend pakket. Deze wordt echter geactiveerd als het pakket naar een andere host moet worden gerouteerd.

  • NF_IP_LOCAL_OUT: Elk lokaal uitgaand verkeer activeert deze hook zodra het de netwerkstack bereikt.

  • NF_IP_POST_ROUTING: Deze hook wordt geactiveerd door elk uitgaand/doorgestuurd verkeer nadat de routering heeft plaatsgevonden, voordat het pakket de kabel bereikt.

Kernelmodules die zich bij deze hooks willen registreren, moeten een prioriteitsnummer opgeven. Deze waarde helpt bij het bepalen van de volgorde waarin ze worden aangeroepen zodra de hook wordt geactiveerd. Een dergelijk mechanisme maakt het mogelijk dat meerdere modules (verschillende modules of meerdere kopieën van dezelfde module) in een deterministische volgorde verbinding maken met elk van de hooks. Elke module zal een beslissing terugsturen naar het netfilter framework na het verwerken van de pakketten.

Tabellen en chains in Iptables

Om zijn regels te organiseren, gebruikt de iptables-firewall tabellen. De tabellen categoriseren de regels op basis van het type beslissingen dat ze nemen. Als een regel bijvoorbeeld over NAT (network address translation) gaat, wordt de regel onder de nat-tabel geplaatst. Op dezelfde manier geldt dat als een regel beslist of een pakket naar zijn bestemming moet worden toegestaan of geweigerd, deze wordt toegevoegd aan de filter tabel.

Binnen elke tabel van iptables, worden regels verder georganiseerd in afzonderlijke “chains”. Hoewel de tabel het type regels vertegenwoordigt dat ze bevatten, beschrijven de chains de netfilter hooks die de regels activeren. Kortom, chains bepalen wanneer de regel wordt geëvalueerd.

Hier zijn de ingebouwde chains van iptables. Interessant genoeg weerspiegelen de chain-namen ook de naam van de geassocieerde netfilter-hooks:

Chain (iptables) Gebruik
PREROUTING NF_IP_PRE_ROUTING
INPUT NF_IP_LOCAL_IN
FORWARD NF_IP_FORWARD
OUTPUT NF_IP_LOCAL_OUT
POSTROUTING NF_IP_POST_ROUTING

Met behulp van de chains kunnen beheerders bepalen in welk stadium van de pakketaflevering de regel wordt geëvalueerd. Omdat elke tabel meerdere chains bevat, kan deze zijn invloed ook op meerdere punten in de verwerking uitoefenen. Bepaalde beslissingen zijn alleen logisch op bepaalde punten van de netwerkstack. Daarom zal niet elke tabel een chain hebben die is geregistreerd bij elke kernel-hook.

Het netfilter-framework biedt slechts 5 kernel-hooks. Als zodanig worden chains uit meerdere tabellen op elk punt van de hooks geregistreerd. Bijvoorbeeld, als drie chains de PREROUTING-chains hebben, dan is dit geregistreerd bij de NF_IP_PRE_ROUTING-hook. Elk daarvan moet een prioriteit opgeven die bepaalt in welke volgorde de PREROUTING-chain van elke tabel wordt aangeroepen. De PREROUTING-chain wordt als eerste geëvalueerd, die met de op één na hoogste prioriteit als tweede, enzovoort.

De iptables-tabellen

Laten we een stap terug doen en kijken naar de tabellen die iptables biedt. Zoals eerder vermeld, vertegenwoordigt elke tabel verschillende sets regels, georganiseerd per toepassingsgebied, voor pakketevaluatie.

  • filter-tabel

In iptables is de filter-tabel een van de populairste. Deze wordt gebruikt om te bepalen of een pakket al dan niet mag doorgaan naar zijn bestemming. In firewallterminologie staat dit proces bekend als het “filteren” van pakketten.

Het zijn de functies van de filter-tabel waarnaar mensen verwijzen als ze het over firewalls hebben (voor het grootste deel).

  • nat-tabel

Deze tabel implementeert regels die NAT reguleren. Wanneer pakketten de netwerkstack binnenkomen, bepalen de regels in deze tabel hoe het bron-/bestemmingsadres van het pakket moet worden gewijzigd, wat invloed heeft op de routering van het pakket en eventueel antwoordverkeer.

Vaak wordt de nat-tabel gebruikt om pakketten te routeren naar netwerken waar geen directe toegang toe is.

  • mangle-tabel

Deze tabel bevat de regels die de IP-headers van de pakketten op verschillende manieren wijzigen. Het kan bijvoorbeeld de TTL-waarde (Time to Live) van een pakket wijzigen door het aantal geldige netwerkhops dat het pakket kan verdragen te verlengen/verkorten. Daarnaast kan de mangle-tabel andere IP-headers op vergelijkbare wijze wijzigen.

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

  • raw-tabel

De iptables-firewall is stateful, wat betekent dat de pakketten worden geëvalueerd in de context van hun relatie met eerdere pakketten. De functie voor het volgen van verbindingen (connection tracking), ontwikkeld bovenop het netfilter-framework, stelt iptables in staat om pakketten te beschouwen als onderdeel van een lopende verbinding of sessie, in plaats van als een stroom van afzonderlijke, niet-gerelateerde pakketten. Over het algemeen wordt de connection tracking-logica zeer snel nadat het pakket de netwerkinterface bereikt, toegepast.

De raw-tabel heeft een zeer nauw gedefinieerde functie. Het enige doel van deze tabel is het bieden van een mechanisme om pakketten te markeren om zo uit te sluiten van connection tracking.

  • security-tabel

De security tabel plaatst interne SELinux-beveiligingscontextmarkeringen op pakketten. Dit heeft op zijn beurt invloed op hoe SELinux (of een andere app die SELinux-beveiligingscontexten interpreteert) de pakketten zal verwerken.

De SELinux-markeringen kunnen per pakket of per verbinding worden toegepast.

Chains geïmplementeerd in elke tabel

Tot nu toe hebben we tabellen en chains afzonderlijk besproken. Tijd om te bekijken welke chains beschikbaar zijn bij elke tabel. Dit onderwerp is een uitbreiding op de discussie over de evaluation order of chains die bij dezelfde hook zijn geregistreerd. Wat gebeurt er bijvoorbeeld als drie tabellen PREROUTING-chains hebben? Wat is hun evaluatievolgorde?

Kijk vervolgens naar de volgende tabel. Deze geeft de chains aan die beschikbaar zijn binnen elke iptables tabel.

  PREROUTING INPUT FORWARD OUTPUT POSTROUTING

(routeringsbeslissing)

raw

(verbindingstracking ingeschakeld)

mangle

nat (DNAT)

(routeringsbeslissing)

filter

security

nat (SNAT)

Van links naar rechts gelezen beschrijft het welke tabellen welke chains bevatten. Bijvoorbeeld, de raw tabel heeft zowel PREROUTING en OUTPUT chains. Van boven naar beneden gelezen beschrijft het in welke volgorde elke chain wordt aangeroepen wanneer de bijbehorende netfilter hook wordt geactiveerd.

Merk op dat de nat tabel is opgesplitst tussen DNAT bewerkingen (het wijzigen van de bestemming van een pakket) en SNAT bewerkingen (het wijzigen van de bron van een pakket) om hun volgorde duidelijker aan te geven. De tabel bevat ook representatiepunten waar routeringsbeslissingen worden genomen en waar verbindingstracking is ingeschakeld.

De hooks (kolommen) die een pakket zal activeren zijn gebaseerd op de aard van het pakket (inkomend/uitgaand), de routeringsbeslissingen die worden genomen, en of een pakket voldoet aan de filtercriteria.

Bepaalde gebeurtenissen kunnen de chain van een tabel overslaan tijdens de verwerking. Bijvoorbeeld, alleen het eerste pakket in een verbinding wordt geëvalueerd tegen de NAT-regels zoals beschreven door de nat tabel. Elk volgend pakket in dezelfde verbinding krijgt dezelfde nat beslissingen toegepast zonder aanvullende evaluatie. Reacties op de NAT-verbindingen krijgen automatisch de omgekeerde NAT-regels toegepast voor een correcte routering.

Volgorde van chain-doorloop

Ervan uitgaande dat de server de routeringsregels voor pakketten kent en de firewallregels de overdracht toestaan, vertegenwoordigen de volgende stromen hoe de verschillende paden worden doorlopen:

  • Inkomende pakketten bestemd voor het lokale systeem: PREROUTING >> INPUT

  • Inkomende pakketten bestemd voor een andere host: PREROUTING >> FORWARD >> POSTROUTING

  • Lokaal gegenereerde pakketten: OUTPUT >> POSTROUTING

Kortom, als we alle informatie die we tot nu toe hebben besproken combineren, zien we dat elk inkomend pakket bestemd voor het lokale systeem zal worden geëvalueerd tegen de PREROUTING chains van de raw, mangle, en nat tabellen. Vervolgens passeert het de INPUT chains van de mangle, filter, security, en nat tabellen voordat het uiteindelijk de lokale socket bereikt.

Iptables-regels

De iptables firewallregels worden binnen een specifieke chain van een specifieke tabel geplaatst. Wanneer een chain wordt aangeroepen, wordt het betreffende pakket geëvalueerd tegen elke regel in de chain. Elke regel heeft twee componenten: een match-component en een actie-component.

  • Matching

Het matching-gedeelte van een regel specificeert de voorwaarden waaraan een pakket moet voldoen voordat de opgegeven actie (of “target”) wordt uitgevoerd.

Het matching-systeem biedt een ongelooflijke flexibiliteit. De functionaliteit kan ook worden uitgebreid met behulp van iptables extensies. Regels kunnen worden beschreven om pakketten te matchen op protocoltype, bron-/bestemmingsadres, bron-/bestemmingspoort, bron-/bestemmingsnetwerk, invoer-/uitvoerinterface, headers, verbindingsstatus en andere criteria. Een regel kan ook een combinatie van deze voorwaarden bevaten, wat resulteert in complexe regelsets om onderscheid te maken tussen verschillende soorten verkeer.

  • Targets

Een target is de actie die wordt ondernomen wanneer een pakket voldoet aan de matching-criteria van een regel. Over het algemeen worden targets in twee groepen verdeeld:

    • Beëindigende targets: Het beëindigt het evaluatieproces binnen de chain en geeft de controle terug aan de netfilter hook. Op basis van de retourwaarde zal de hook het pakket toestaan zijn weg te vervolgen of het weggooien.

    • Niet-beëindigende targets: Het target voert een actie uit en de evaluatie in de chain gaat door. Hoewel elke chain een definitieve beëindigende beslissing moet doorlopen, kan vooraf een willekeurig aantal niet-beëindigende targets plaatsvinden.

De beschikbaarheid van elk doel binnen regels is afhankelijk van de context. De chain en het tabeltype kunnen bijvoorbeeld invloed hebben op de beschikbaarheid van doelen. Andere mogelijke factoren zijn geactiveerde extensies in de regel en de overeenkomende clausules.

Door de gebruiker gedefinieerde chains

Er is ook een speciale klasse van niet-beëindigende doelen: het jump-doel. Jump-doelen zijn acties die worden uitgevoerd wanneer de evaluatie van de ene chain naar de andere overgaat voor extra verwerking. Tot nu toe hebben we het gehad over ingebouwde chains die nauw verbonden zijn met de netfilter hooks die deze aanroepen. Echter, iptables stelt beheerders ook in staat om hun eigen chains te maken.

Regels in door de gebruiker gedefinieerde chains zijn ook vergelijkbaar met die in ingebouwde chains. Het belangrijkste verschil is dat door de gebruiker gedefinieerde chains alleen bereikbaar zijn door er vanaf een regel naar te “springen”. Dit komt omdat door de gebruiker gedefinieerde chains niet gekoppeld zijn aan netfilter hooks.

Je kunt door de gebruiker gedefinieerde chains zien als uitbreidingen van de chain die ze oorspronkelijk heeft aangeroepen. Bijvoorbeeld, in een door de gebruiker gedefinieerde chain zal de evaluatie terugkeren naar de aanroepende chain als het einde van de regellijst wordt bereikt of als een overeenkomende regel een RETURN-doel uitvoert. Interessant is dat een door de gebruiker gedefinieerde chain de evaluatie ook kan laten “springen” naar een andere door de gebruiker gedefinieerde chain.

Deze functie legt de basis voor een betere organisatie en het noodzakelijke raamwerk voor robuuste vertakkingen.

Connection tracking

Bij het bespreken van de raw-tabel en de criteria voor het matchen van de verbindingsstatus, hebben we het connection tracking-systeem besproken dat is geïmplementeerd bovenop het netfilter-framework. Deze functie stelt iptables  in staat om pakketten te bekijken in de context van een lopende verbinding. Het connection tracking-systeem voorziet iptables ook van de nodige functionaliteit die nodig is om “stateful” bewerkingen uit te voeren.

Direct nadat een pakket de netwerkstack binnenkomt, wordt connection tracking toegepast. De raw-tabel chains en enkele basiscontroles zijn de enige logica die wordt gebruikt om pakketten aan een verbinding te koppelen.

Het systeem controleert elk pakket aan de hand van een reeks bestaande verbindingen. Indien nodig zal het systeem de status van de bestaande verbindingen bijwerken of nieuwe maken. Pakketten die in een van de raw-tabel chains zijn gemarkeerd met het NOTRACK-doel, zullen verdere connection tracking-routines omzeilen.

  • Beschikbare statussen

Verbindingen die door het connection tracking-systeem worden gevolgd, krijgen een van de volgende statussen toegewezen:

    • NEW : Bij aankomst van een pakket dat niet is gekoppeld aan een bestaande verbinding, maar niet ongeldig is als eerste pakket, wordt een nieuwe verbinding aan het systeem toegevoegd met dit label. Dit gebeurt voor zowel verbindingsgerichte protocollen (bijvoorbeeld TCP) als verbindingsloze protocollen (bijvoorbeeld UDP).

    • ESTABLISHED: De status van een verbinding wordt bijgewerkt van NEW  naar ESTABLISHED wanneer het een geldige reactie uit de tegenovergestelde richting ontvangt. Voor TCP-verbindingen betekent dit een SYN/ACK. Voor UDP- en ICMP-verkeer betekent dit een reactie waarbij de bron en bestemming van het oorspronkelijke pakket zijn omgewisseld.

    • RELATED: Pakketten die geen deel uitmaken van een verbinding maar wel gerelateerd zijn aan een tot stand gebrachte verbinding, worden gelabeld als RELATED . Dit kan een hulpverbinding betekenen (bijvoorbeeld bij een FTP-gegevensoverdrachtsverbinding), of ICMP-reacties op verbindingspogingen door andere protocollen.

    • INVALID: Pakketten die geen deel uitmaken van een tot stand gebrachte verbinding, als ongeschikt worden beschouwd voor het openen van een nieuwe verbinding, niet kunnen worden geïdentificeerd, niet routeerbaar zijn enz., worden gelabeld als INVALID.

    • UNTRACKED: Een pakket kan worden gelabeld als UNTRACKED als deze het doelwit was in een raw-tabel chain om tracking te omzeilen.

    • SNAT: Het geeft een virtuele status aan die wordt ingesteld wanneer het bronadres wordt gewijzigd door een NAT-bewerking. Dit wordt afgehandeld door het connection tracking-systeem, zodat de bronadressen in antwoordpakketten worden vertaald.

    • DNAT: Vergelijkbaar met SNAT, geeft dit een virtuele status aan wanneer het bestemmingsadres wordt gewijzigd door een NAT-bewerking. Het verbindingsvolgsysteem handelt dit zo af dat het weet dat het bestemmingsadres moet worden terugvertaald bij het routeren van antwoordpakketten.

Deze statussen die door het verbindingsvolgsysteem worden bijgehouden, stellen beheerders in staat om specifieke regels op te stellen die gericht zijn op specifieke momenten in de levensduur van een verbinding. Het biedt de nodige functionaliteit voor grondigere en veiligere regels.

Tot slot

In Linux vormen het netfilter-framework en de iptables-firewall de basis voor de meeste firewalls. De netfilter-hooks bevinden zich dicht genoeg bij de netwerkstack om krachtige controle mogelijk te maken over pakketten die door het systeem worden verwerkt. Door gebruik te maken van deze mogelijkheden biedt de iptables-firewall een flexibele manier om beleidsvereisten aan de kernel te communiceren.

Deze gids gaat dieper in op de interne structuur van het netfilter-framework en de iptables-firewall. Daarnaast wordt het verbindingsvolgsysteem besproken. Door te begrijpen hoe deze onderdelen in elkaar passen, kunt u ze beter gebruiken om robuustere en veiligere serveromgevingen te creëren.

Tot slot, hoewel deze gids de interne werking behandelt, kunt u deze gids bekijken over het configureren van iptables om ze in de praktijk toe te passen. Daarnaast kunt u zien hoe de UFW-firewall zorgt voor een verdere vereenvoudiging van iptables. Daarnaast is het handig om te leren hoe u iptables-firewallregels kunt weergeven en verwijderen.

Veel computerplezier!

author

Preslav Dobrev

Auteur · CloudSigma

Preslav Dobrev is een creatief ontwerper bij CloudSigma, met de nadruk op een consistente bedrijfsidentiteit door middel van traditionele en innovatieve marketingkanalen. Hij is bedreven in het samenvoegen van artistieke visie met strategische marketing om impactvolle merkverhalen te creëren.

Reacties

Nog geen reacties. Wees de eerste.