Introductie
Het gebruik van een firewall draait net zoveel om het nemen van intelligente beleidsbeslissingen als om het leren van de syntaxis. Firewalls zoals iptables zijn ontworpen om beleidsregels af te dwingen door regels geïnterpreteerd door de beheerder. Als beheerder moet u echter weten welke soorten regels logisch zijn voor uw infrastructuur.
Terwijl andere handleidingen zich richten op de benodigde commando’s om aan de slag te gaan, zullen we in deze handleiding enkele beslissingen bespreken die u moet nemen bij het implementeren van een firewall. Deze keuzes zullen van invloed zijn op het gedrag van uw firewall, hoe afgeschermd uw server is en hoe deze zal reageren op verschillende omstandigheden die zich voordoen. We zullen iptables als een specifiek voorbeeld gebruiken, maar de meeste concepten zullen breed toepasbaar zijn.
Het kiezen van een Standaardbeleid
Bij het bouwen van een firewall is een van de belangrijkste beslissingen die moeten worden genomen, het standaardbeleid. Dit bepaalt wat er gebeurt wanneer verkeer niet overeenkomt met andere regels. Standaard kan een firewall ofwel al het verkeer dat niet overeenkomt met eerdere regels, ACCEPT, of dat verkeer DROPpen.
Standaard Drop versus Standaard Accepteren
A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.
De alternatieve optie is een standaardbeleid van DROP. Dit betekent dat elk verkeer dat niet overeenkomt met een expliciete regel niet wordt toegestaan. Elke service moet expliciet worden toegestaan, wat misschien lijkt op een aanzienlijke hoeveelheid configuratie vooraf. Dit betekent echter dat uw beleid gericht is op beveiliging en dat u precies weet wat is toegestaan om verkeer op uw server te ontvangen. Bovendien zal bijna alle voorgeconfigureerde beleidsregels deze aanpak volgen, wat betekent dat u kunt voortbouwen op bestaande standaarden.
Standaard Dropbeleid versus Laatste Dropregel
De keuze voor een standaard dropbeleid leidt tot een andere subtiele beslissing. Bij iptables en andere vergelijkbare firewalls kan het standaardbeleid worden ingesteld met behulp van de ingebouwde beleidsfunctionaliteit van de firewall, of worden geïmplementeerd door een catch-all dropregel toe te voegen aan het einde van de lijst met regels.
De onderscheiding tussen deze twee methoden komt neer op wat er gebeurt als de firewall-regels worden leeggemaakt.
Als de ingebouwde beleidsfunctie van je firewall is ingesteld op DROP en je firewall-regels ooit worden geleegd (teruggezet), of als bepaalde overeenkomende regels worden verwijderd, zullen je services onmiddellijk ontoegankelijk worden op afstand. Dit is vaak een goed idee bij het instellen van beleid voor niet-kritieke services, zodat je server niet wordt blootgesteld aan kwaadaardig verkeer als de regels worden verwijderd.
Het nadeel van deze aanpak is dat je services volledig onbeschikbaar zullen zijn voor je klanten totdat je permissieve regels opnieuw instelt. Je zou jezelf zelfs potentieel kunnen buitensluiten van de server als je geen lokale of op web gebaseerde externe toegang hebt als alternatief.
De alternatieve benadering voor het instellen van een drop-beleid met de ingebouwde beleidsfunctionaliteit is om het standaardbeleid van je firewall in te stellen op ACCEPT en vervolgens een DROP-beleid in te voeren met reguliere regels. Je kunt een normale firewall-regel toevoegen aan het einde van je keten die al het overgebleven niet-overeenkomende verkeer overeenkomt en weigert.
In dit geval zullen je services toegankelijk zijn maar onbeschermd als je firewall-regels worden geleegd. Afhankelijk van je opties voor lokale of alternatieve toegang, kan dit een noodzakelijk kwaad zijn om ervoor te zorgen dat je je server kunt betreden als de regels worden geleegd. Als je besluit deze optie te gebruiken, zorg er dan voor dat de vang-alles-regel altijd de laatste regel in je regelset blijft.
Verkeer laten vallen versus Verkeer afwijzen
Er zijn verschillende manieren om te voorkomen dat een pakket zijn beoogde bestemming bereikt. De keuze tussen deze methoden heeft invloed op hoe de client zijn verbindingspoging ervaart en hoe snel ze kunnen vaststellen dat hun verzoek niet zal worden bediend.
De eerste manier waarop pakketten kunnen worden geweigerd, is met het gebruik van DROP. Drop kan worden gebruikt als een standaardbeleid of als een doel voor overeenkomstregels. Wanneer een pakket wordt verworpen, gooit iptables het gewoon weg. Er wordt geen reactie teruggestuurd naar de client die probeert verbinding te maken en er wordt geen indicatie gegeven dat de betreffende pakketten ooit zijn ontvangen. Dit betekent dat clients (legitiem of niet) geen bevestiging ontvangen van de ontvangst van hun pakketten.
Voor TCP-verbindingspogingen (zoals verbindingen gemaakt door een webbrowser) zal de verbinding stagneren totdat de time-outlimiet is bereikt. Het ontbreken van respons voor UDP-clients is nog onduidelijker. In feite is het niet ontvangen van een UDP-pakket vaak een indicatie dat het pakket is geaccepteerd. Als de UDP-client geeft om de ontvangst van zijn pakketten, zal hij ze opnieuw moeten verzenden om te proberen vast te stellen of ze zijn geaccepteerd, verloren zijn gegaan tijdens het transport of zijn verworpen. Dit kan de hoeveelheid tijd vergroten die een kwaadwillende acteur moet besteden om informatie te verkrijgen over de status van de poorten van uw server, maar het kan ook problemen veroorzaken met legitiem verkeer.
Een alternatief voor het laten vallen van verkeer is om pakketten expliciet te weigeren die je niet toestaat. ICMP, of Internet Control Message Protocol, is een meta-protocol dat overal op internet wordt gebruikt om status-, diagnostische en foutberichten tussen hosts te verzenden als een out-of-band kanaal dat niet afhankelijk is van conventionele communicatieprotocollen zoals TCP of UDP. Wanneer je het REJECT doelwit gebruikt in plaats van het DROP doelwit, wordt het verkeer geweigerd en wordt een ICMP-pakket teruggestuurd naar de afzender om hen te informeren dat hun verkeer is ontvangen maar niet zal worden geaccepteerd. Er kan ook een statusbericht worden toegevoegd om een reden te geven.
Dit heeft een aantal gevolgen. Als wordt aangenomen dat ICMP-verkeer de client kan bereiken, worden ze direct geïnformeerd dat hun verkeer is geblokkeerd. Voor legitieme clients betekent dit dat ze contact kunnen opnemen met de beheerder of hun verbindingsmogelijkheden kunnen controleren om er zeker van te zijn dat ze contact opnemen met de juiste poort. Voor kwaadwillende gebruikers betekent dit dat ze hun scans kunnen voltooien en de open, gesloten en gefilterde poorten in een kortere tijd kunnen in kaart brengen.
Er is veel om rekening mee te houden bij het beslissen of je verkeer laat vallen of weigert. Een belangrijke overweging is dat het meeste kwaadaardige verkeer eigenlijk wordt gepleegd door geautomatiseerde scripts. Omdat deze scripts doorgaans niet worden begeleid, zal het laten vallen van onrechtmatig verkeer hen niet wezenlijk ontmoedigen, en zal het negatieve effecten hebben voor legitieme gebruikers. Meer over dit onderwerp is te vinden op de website van Peter Benie.
Drop vs Reject Response Table
De tabel hieronder toont hoe een server die beschermd wordt door een firewall zal reageren op verschillende verzoeken, afhankelijk van het beleid dat wordt toegepast op de bestemmingspoort.
| Client Packet Type | NMap Command | Port Policy | Response | Inferred Port State |
|---|---|---|---|---|
| TCP | nmap [-sT | -sS] -Pn <server> | Accept | TCP SYN/ACK | Open |
| TCP | nmap [-sT | -sS] -Pn <server> | Drop | (none) | Filtered |
| TCP | nmap [-sT | -sS] -Pn <server> | Reject | TCP RESET | Closed |
| UDP | nmap -sU -Pn <server> | Accept | (none) | Open or Filtered |
| UDP | nmap -sU -Pn <server> | Drop | (none) | Open or Filtered |
| UDP | nmap -sU -Pn <server> | Reject | ICMP Port Unreachable | Closed |
De eerste kolom geeft het pakkettype aan dat door de client wordt verzonden. De tweede kolom bevat de nmap-opdrachten die kunnen worden gebruikt om elk scenario te testen. De derde kolom geeft het poortbeleid aan dat wordt toegepast op de poort. De vierde kolom is de reactie die de server terugstuurt en de vijfde kolom is wat de client kan afleiden over de poort op basis van de respons die hij heeft ontvangen.
ICMP-beleid
Net zoals bij het beslissen of verkeer dat wordt geweigerd moet worden verwijderd of afgewezen, hebt u de mogelijkheid om ICMP-pakketten die zijn bestemd voor uw server te accepteren of af te wijzen.
ICMP is een protocol dat voor veel dingen wordt gebruikt. Zoals vermeld, wordt het vaak teruggestuurd om statusinformatie te geven over verzoeken met behulp van andere protocollen. Een van de populairste functies is het versturen en reageren op netwerk-pings om de verbinding met externe hosts te verifiëren. Er zijn veel andere toepassingen voor ICMP die niet zo bekend zijn, maar toch nuttig.
ICMP-pakketten zijn georganiseerd op basis van “type” en vervolgens verder op basis van “code”. Een type specificeert de algemene betekenis van het bericht. Bijvoorbeeld, Type 3 betekent dat de bestemming onbereikbaar was. Een code wordt vaak gebruikt om verdere informatie over een type te geven. Zo betekent ICMP Type 3 Code 3 bijvoorbeeld dat de bestemmingspoort niet beschikbaar was, terwijl ICMP Type 3 Code 0 betekent dat het doelnetwerk niet kon worden bereikt.
Sommige ICMP-types zijn verouderd, dus ze kunnen onvoorwaardelijk worden geblokkeerd. Hieronder vallen onder andere ICMP-brononderdrukking (type 4 code 0) en alternatieve host (type 6). Types 1, 2, 7 en type 15 en hoger zijn allemaal verouderd, gereserveerd voor toekomstig gebruik, of experimenteel. Veel upstream-firewalltemplates zullen dit standaard afhandelen.
Te blokkeren types afhankelijk van netwerkconfiguratie
Sommige ICMP-types zijn nuttig in bepaalde netwerkconfiguraties, maar moeten in andere worden geblokkeerd.
Bijvoorbeeld, ICMP-omleidingsberichten (type 5) kunnen nuttig zijn om slecht netwerkontwerp te verduidelijken. Een ICMP-omleiding wordt verzonden wanneer een betere route rechtstreeks beschikbaar is voor de client. Dus als een router een pakket ontvangt dat naar een andere host op hetzelfde netwerk moet worden gerouteerd, stuurt het een ICMP-omleidingsbericht om de client te vertellen de pakketten in de toekomst via de andere host te sturen.
Dit is handig als je vertrouwt op je lokale netwerk en inefficiënties in je routeringstabellen wilt opsporen tijdens de initiële configuratie. Op een onbetrouwbaar netwerk kan een kwaadwillende gebruiker mogelijk ICMP-omleidingen sturen om de routeringstabellen op hosts te manipuleren.
Andere ICMP-types die nuttig zijn in sommige netwerken en potentieel schadelijk in andere, zijn ICMP-routeradvertenties (type 9) en routersolicitaties (type 10) pakketten. Routeradvertentie- en solicitatiespakketten worden gebruikt als onderdeel van IRDP (ICMP Internet Router Discovery Protocol), een systeem dat hosts in staat stelt om beschikbare routers dynamisch te ontdekken bij het opstarten of bij het aansluiten op een netwerk.
In de meeste gevallen is het beter voor een host om statische routes geconfigureerd te hebben voor de gateways die het zal gebruiken. Deze pakketten moeten worden geaccepteerd in dezelfde situaties als de ICMP-omleidingspakketten. Sterker nog, aangezien de host de voorkeursroute niet zal weten voor verkeer van alle ontdekte routes, zijn omleidingsberichten vaak direct na ontdekking nodig. Als je geen service draait die routersolicitaties verzendt of je routes wijzigt op basis van advertentiepakketten (zoals rdisc), kun je deze pakketten veilig blokkeren.
Typen die vaak veilig zijn om toe te staan
ICMP-types die meestal veilig zijn om toe te staan, staan hieronder vermeld, maar je kunt ze uitschakelen als je extra voorzichtig wilt zijn.
- Type 8 — Echoverzoek: Dit zijn pingverzoeken gericht aan uw server. Het is meestal veilig om deze toe te staan (het weigeren van deze pakketten verbergt uw server niet, omdat er genoeg andere manieren zijn voor gebruikers om erachter te komen of uw host actief is), maar u kunt ze blokkeren of de bronadressen beperken waarop u reageert als u dat wilt.
- Type 13 — Tijdstempelverzoek: Deze pakketten kunnen door clients worden gebruikt om latentie-informatie te verzamelen. Ze kunnen worden gebruikt in sommige OS-fingerprintingtechnieken, dus u kunt ze blokkeren of het bereik van adressen beperken waarop u reageert.
De onderstaande typen kunnen meestal worden toegestaan zonder expliciete regels door uw firewall zo te configureren dat deze antwoorden op verzoeken toestaat die het heeft gemaakt (door de conntrack-module te gebruiken om ESTABLISHED– en RELATED-verkeer toe te staan).
- Type 0 — Echo-antwoorden: Dit zijn antwoorden op echoverzoeken (ping).
- Type 3 — Bestemmingsonbereikbaar: Legitieme pakketten die aangeven dat de bestemming onbereikbaar is, zijn antwoorden op verzoeken die door uw server zijn gemaakt en aangeven dat het pakket niet kon worden afgeleverd.
- Type 11 — Tijd overschreden: Dit is een diagnostische fout die wordt geretourneerd als een pakket dat door uw server is gegenereerd, voordat het de bestemming heeft bereikt, is gestopt vanwege het overschrijden van de TTL-waarde.
- Type 12 — Parameterprobleem: Dit betekent dat een uitgaand pakket vanaf uw server onjuist was gevormd.
- Type 14 — Tijdstempelreacties: Dit zijn de antwoorden op tijdstempelverzoeken die door uw server zijn gegenereerd.
Het wordt nog steeds aanbevolen door sommige beveiligingsexperts om al het inkomende ICMP-verkeer te blokkeren, maar tegenwoordig moedigen veel mensen intelligente acceptatiebeleidslijnen voor ICMP aan. Deze twee Stack Exchange threads bevatten meer informatie.
Verbindingsbeperking en Snelheidsbeperking
Voor sommige diensten en verkeerspatronen wilt u mogelijk alleen toegang toestaan zolang de client die toegang niet misbruikt. Twee manieren om het gebruik van resources te beperken, zijn verbindingsbeperking en snelheidsbeperking.
Verbindingsbeperking
Verbindingsbeperking kan worden geïmplementeerd met extensies zoals connlimit om te controleren hoeveel actieve verbindingen een client open heeft. Dit kan worden gebruikt om het aantal gelijktijdige verbindingen te beperken. Als u besluit verbindingslimieten op te leggen, moet u enkele beslissingen nemen:
- Beperkt u op basis van een specifiek adres, netwerk of op wereldwijde basis?
- Matcht en beperkt u het verkeer voor een specifieke dienst of voor de server als geheel?
Verbindingen kunnen op host-voor-hostbasis worden beperkt, of er kan een limiet worden ingesteld voor een netwerksegment door een netwerkvoorvoegsel op te geven (zoals een IP-adresbereik voor een hele organisatie). U kunt ook een wereldwijd maximum aantal verbindingen instellen voor een service of de gehele machine. Houd er rekening mee dat het mogelijk is om deze te combineren en te matchen om complexere beleidsregels te maken voor het beheersen van het aantal verbindingen.
Rate Limiting
Rate limiting stelt u in staat regels te construeren die de snelheid of frequentie bepalen waarmee verkeer door uw server wordt geaccepteerd. Er zijn verschillende firewall-extensies die kunnen worden gebruikt voor rate limiting, waaronder limit, hashlimit en recent. De keuze voor de extensie die u gebruikt, zal grotendeels afhangen van de manier waarop u het verkeer wilt beperken.
De limit-extensie zorgt ervoor dat de betreffende regel overeenkomt totdat de limiet is bereikt, waarna verdere pakketten worden verworpen. Een limiet zoals 5/sec staat toe dat 5 pakketten per seconde overeenkomen, waarna de regel niet meer overeenkomt. Dit is handig voor het instellen van een wereldwijde rate limit voor een service. U kunt ook een aanvullende service zoals Fail2ban implementeren om herhaalde verbindingspogingen te blokkeren.
De uitbreiding hashlimit is flexibeler, waardoor u enkele van de waarden kunt specificeren waarop iptables zal hashen om een overeenkomst te evalueren. Het kan bijvoorbeeld kijken naar het bronadres, bronpoort, bestemmingsadres, bestemmingspoort, of een combinatie van die vier waarden om elke vermelding te evalueren. Het kan beperken op basis van pakketten of op basis van ontvangen bytes. Dit biedt flexibele snelheidsbeperkingen per client of per service.
De extensie recent voegt dynamisch IP-adressen van clients toe aan een lijst of controleert tegen een bestaande lijst wanneer de regel overeenkomt. Dit stelt u in staat om uw beperkende logica over verschillende regels te verspreiden voor complexe patronen. Het heeft de mogelijkheid om een hit teller en een tijdsbereik te specificeren zoals de andere beperkers, maar kan ook het tijdsbereik opnieuw instellen als er extra verkeer wordt gedetecteerd, waardoor een client al het verkeer moet stoppen als ze worden beperkt.
Monolithisch versus ketengebaseerd beheer
Alle firewallbeleid van iptables en nftables is in wezen geworteld in het uitbreiden van de ingebouwde ketens. In eerste instantie betekent dit meestal het wijzigen van het standaardbeleid voor de bestaande ketens en het toevoegen van regels. Voor complexere firewalls is het vaak een goed idee om het beheerkader uit te breiden door extra ketens te creëren.
Gebruikersgemaakte ketens worden secundair genoemd en zijn inherent verbonden met hun “oproepketen” waar ze vandaan komen. Gebruikersgemaakte ketens hebben geen standaard beleid, dus als een pakket door een gebruikersgemaakte keten valt, keert het terug naar de oproepketen en gaat de evaluatie door. Met dat in gedachten zijn gebruikersgemaakte ketens voornamelijk nuttig voor organisatorische doeleinden, om de voorwaarden voor regelovereenkomsten beter onderhoudbaar te maken en de leesbaarheid te verbeteren door overeenkomstvoorwaarden te splitsen.
Als je merkt dat je bepaalde overeenkomstcriteria herhaalt voor een aanzienlijk aantal regels, kan het de moeite waard zijn om een sprongregel te maken met de gedeelde overeenkomstcriteria naar een nieuwe keten. Binnen de nieuwe keten kun je die reeks regels toevoegen met weggelaten overeenkomstcriteria.
De beslissing om al je regels in een van de ingebouwde ketens op te nemen of om aanvullende ketens te maken en te gebruiken, hangt af van hoe complex je regelset is.
Conclusie
Je zou nu een beter begrip moeten hebben van de beslissingen die je moet nemen bij het ontwerpen van firewallbeleid voor je servers. Meestal gaat de tijdsinvestering met firewalls sterk naar de initiële configuratie. Hoewel het enige tijd en experimentatie kan vergen om een beleid te bedenken dat het beste bij je behoeften past, geeft het doen ervan je meer controle over de beveiliging van je server.
Als je meer wilt weten over firewalls en specifiek iptables, bekijk dan de volgende artikelen:
De volgende handleidingen kunnen u helpen bij het implementeren van uw beleid. Kies de handleiding die overeenkomt met uw firewall om aan de slag te gaan: