Cyber Security

# Disseminatie van cyberdreigingsinformatie Dit onderwerp gaat over de methoden en protocollen voor het effectief verspreiden van voltooide cyberdreigingsinformatie naar de juiste ontvangers. ### 1.1 Belang van disseminatie De effectiviteit van cyberdreigingsinformatie (CTI) hangt sterk af van de juiste disseminatie. Het gaat erom dat de informatie de juiste persoon bereikt op het juiste moment, zodat deze actie kan ondernemen. CTI wordt doorgaans verspreid op verschillende niveaus: * **Strategisch niveau:** Informatie voor het hogere management, gericht op langetermijnrisico's en beleidsbeslissingen. * **Operationeel niveau:** Informatie voor managers en teamleiders, gericht op het plannen van beveiligingsmaatregelen en incidentrespons. * **Tactisch niveau:** Informatie voor beveiligingsanalisten en -ingenieurs, gericht op directe bedreigingen en technische mitigaties. * **Technisch niveau:** Zeer gedetailleerde informatie voor beveiligingsexperts, gericht op de implementatie van specifieke controles. Bij het verspreiden van informatie is het cruciaal om te bepalen of de informatie ook met externe partijen gedeeld mag worden. ### 1.2 Protocollen voor informatie delen Er zijn specifieke protocollen en regels opgesteld om de veilige en effectieve uitwisseling van cyberdreigingsinformatie te faciliteren. #### 1.2.1 Chatham House Rules De Chatham House Rules zijn bedoeld om de openheid van discussies te vergroten. Volgens deze regel is iedereen die deelneemt aan een bijeenkomst vrij om informatie uit de discussie te gebruiken, maar mag niet onthullen wie een specifieke opmerking heeft gemaakt. Het doel is om anonimiteit te garanderen aan de sprekers om betere internationale relaties te bevorderen. #### 1.2.2 Traffic Light Protocol (TLP) Het Traffic Light Protocol (TLP) is een set regels die bepaalt hoe gevoelige informatie mag worden gedeeld. Het kent de volgende niveaus: * **TLP: RED:** Informatie mag niet worden gedeeld buiten de directe deelnemers van de communicatie en mag niet worden opgeslagen. Deze informatie blijft strikt vertrouwelijk binnen de deelnemende partijen. * **TLP: GREEN:** Informatie is vrij te delen binnen de gemeenschap. Het is echter niet toegestaan om deze informatie publiekelijk op het internet te publiceren. * **TLP: AMBER & TLP: AMBER+STRICT:** * **AMBER:** De informatie is deelbaar binnen een organisatie en met haar klanten. * **AMBER+STRICT:** De informatie is beperkt tot de organisatie zelf. Aanvullende beperkingen kunnen worden toegevoegd. * **TLP: CLEAR:** Informatie mag ongelimiteerd worden gedeeld met iedereen. Hierbij moeten echter wel de wetten rond auteursrecht en non-disclosure agreements (NDA's) worden gerespecteerd. #### 1.2.3 Permissible Actions Protocol (PAP) Het Permissible Actions Protocol (PAP) specificeert welke acties ontvangers mogen ondernemen met de ontvangen informatie. Dit protocol is met name relevant voor het delen van informatie over kwetsbaarheden en actieve exploits. * **PAP: RED:** Alleen niet-detecteerbare passieve acties zijn toegestaan. Ontvangers mogen de informatie niet op het netwerk gebruiken voor actieve operaties, maar mogen wel passieve acties uitvoeren op logs die van buitenaf niet detecteerbaar zijn. * **PAP: GREEN:** Actieve acties zijn toegestaan. Ontvangers mogen de informatie gebruiken om bijvoorbeeld de doelwitten te pingen, inkomend/uitgaand verkeer te blokkeren, of honeypots specifiek te configureren om met het doelwit te interageren. * **PAP: AMBER:** Passieve cross-checks zijn toegestaan. Ontvangers mogen de informatie gebruiken voor online checks, zoals VirusTotal, of voor het monitoren van een honeypot. * **PAP: WHITE:** Er zijn geen beperkingen in het gebruik van deze informatie. ### 1.3 Feedback loop en verbetering Het is essentieel om een feedback loop te hebben in het CTI-proces. Dit betekent dat er mechanismen moeten zijn om feedback te verzamelen over de bruikbaarheid en effectiviteit van de verstrekte informatie. #### 1.3.1 Belang van feedback Feedback helpt bij het verfijnen van het gehele CTI-levenscyclus: * **Planning & Direction:** Feedback kan de prioriteiten en focus van de informatieverzameling bijsturen. * **Collection:** Ontvangers kunnen aangeven welke soorten informatie ontbreken of onvoldoende zijn. * **Analysis:** Feedback kan de interpretatie van data verbeteren en de nauwkeurigheid van analyses verhogen. * **Reporting:** De manier van rapporteren kan worden aangepast aan de behoeften van de ontvangers. * **Dissemination:** De methoden en kanalen voor verspreiding kunnen worden geoptimaliseerd. #### 1.3.2 Typische feedbackbronnen Feedback kan afkomstig zijn van: * Beveiligingsteams die de informatie gebruiken voor incidentrespons. * Management die de informatie gebruikt voor strategische besluitvorming. * Samenwerkende organisaties en partners. #### 1.3.3 Hoe feedback het CTI-proces verfijnt Door feedback te integreren, kan CTI relevanter, nauwkeuriger en directer toepasbaar worden. Dit leidt tot een proactievere en effectievere beveiligingshouding. --- ### 1.4 Vulnerability Intelligence in Disseminatie Hoewel dit specifiek gaat over de verspreiding van *voltooide* CTI, is het belangrijk te erkennen dat vulnerability intelligence hierbij een cruciale rol speelt. Kwetsbaarheidsinformatie (vulnerability intelligence) richt zich op specifieke technische tekortkomingen die door aanvallers kunnen worden uitgebuit. * **Context:** Er worden jaarlijks tienduizenden nieuwe CVE's (Common Vulnerabilities and Exposures) gepubliceerd. Het is onmogelijk om alle kwetsbaarheden te patchen. Prioritering is dus essentieel. * **Voorbeeld:** De gemiddelde tijd om een kwetsbaarheid te exploiteren is ongeveer 16.5 dagen, terwijl de tijd om deze te herstellen gemiddeld 39 dagen is. Dit onderstreept de noodzaak voor snelle en gerichte mitigatie. * **Frameworks:** Frameworks zoals CVSS (Common Vulnerability Scoring System), EPSS (Exploit Prediction Scoring System) en de CISA KEV (Known Exploited Vulnerabilities) lijst helpen bij het prioriteren van kwetsbaarheden op basis van ernst, waarschijnlijkheid van exploitatie en actieve uitbuiting. Wanneer vulnerability intelligence is verrijkt en geanalyseerd, wordt het onderdeel van de CTI-output die gedissemineerd moet worden. De disseminatie van deze informatie kan dan plaatsvinden met behulp van de hierboven beschreven protocollen (zoals TLP en PAP), afhankelijk van de gevoeligheid en het beoogde gebruik van de informatie. > **Tip:** Combineer verschillende bronnen en methoden voor het delen van informatie, zoals TLP voor gevoeligheidsniveaus en PAP voor toegestane acties, om een robuust en flexibel disseminatieproces te creëren. --- # Kwetsbaarheidsintelligentie en prioritering Hier is de studiehandleiding voor "Kwetsbaarheidsintelligentie en prioritering". ## 2. Kwetsbaarheidsintelligentie en prioritering Dit onderwerp verkent de noodzaak om kwetsbaarheden te prioriteren op basis van gegevens zoals tijd tot exploitatie en herstelduur, en bespreekt verschillende frameworks en systemen voor het beoordelen en beheren van kwetsbaarheden. ### 2.1 Het belang van kwetsbaarheidsintelligentie De digitale wereld produceert continu nieuwe kwetsbaarheden, met meer dan 40.000 nieuwe CVE's (Common Vulnerabilities and Exposures) alleen al in 2024. De tijd die nodig is om een kwetsbaarheid te 'wapeniseren' (klaar te maken voor exploitatie) is gemiddeld 16,5 dagen, terwijl het oplossen ervan gemiddeld 39 dagen duurt. Gezien de enorme hoeveelheid kwetsbaarheden is het onmogelijk om alles tegelijk te patchen; daarom is effectieve prioritering essentieel. Studies tonen aan dat 88,2% van de kwetsbaarheden wordt aangepakt met behulp van geprioriteerde benaderingen. #### 2.1.1 Wat zijn veelvoorkomende kwetsbaarheden? * **Softwarefouten:** Zwakheden in code die aanvallers kunnen misbruiken. * **Hardwarefouten:** Fysieke componenten met kwetsbaarheden die geëxploiteerd kunnen worden. * **Configuratieproblemen:** Fouten in de configuratie die risico's creëren. * **Zero-days:** Kwetsbaarheden waarvoor nog geen patch beschikbaar is. * **Proof-of-concept exploits (PoC):** Demonstraties die aantonen dat een kwetsbaarheid geëxploiteerd kan worden. #### 2.1.2 Waarom is kwetsbaarheidsintelligentie belangrijk? Kwetsbaarheidsintelligentie is gericht op de specifieke gebreken die aanvallers kunnen exploiteren. In combinatie met bredere bedreigingsintelligentie (die inzichten biedt in aanvallers, hun methoden en motivaties) vormt het een compleet risicoprofiel voor het ontwikkelen van effectieve mitigerende strategieën. > **Tip:** Kwetsbaarheidsintelligentie en bedreigingsintelligentie vullen elkaar aan om een holistisch beeld te geven van de potentiële risico's. ### 2.2 De rol van CVE's en hun verrijking Een CVE (Common Vulnerabilities and Exposures) is een unieke identifier voor een publiek bekende cyberbeveiligingskwetsbaarheid. CVE's zijn cruciaal voor het volgen en beheren van kwetsbaarheden. #### 2.2.1 Integratie in de intelligentiecyclus Het integreren van CVE's in de CTI-levenscyclus omvat verschillende stappen: * **Planning & Richting:** Identificeren van prioritaire technologieën, risico's en hiaten. * **Verzameling:** Monitoren van adviezen, de CISA KEV-lijst, openbare bronnen (OSINT), leveranciersbulletins en het dark web. * **Verwerking:** Normaliseren en dedupliceren van CVE-gegevens, en het verrijken ervan met informatie zoals EPSS (Exploit Prediction Scoring System) en links naar bedreigingsactoren. #### 2.2.2 Voorbeelden van CVE's en hun context * CVE-2025-10035 (GoAnywhere MFT) * CVE-2021-44228 (Apache Log4j / Log4Shell) * CVE-2020-5902 (F5 BIG-IP TMUI RCE) * CVE-2014-6271 (Bash / Shellshock) * CVE-2016-9335 (Red Lion Sixnet Industrial Switches) * CVE-2019-11061 (ASUS HG100 IoT Authentication Bypass) ### 2.3 Frameworks voor het beoordelen en prioriteren van kwetsbaarheden Verschillende frameworks helpen organisaties om de ernst en waarschijnlijkheid van exploitatie van kwetsbaarheden te beoordelen en te prioriteren. #### 2.3.1 CVSS (Common Vulnerability Scoring System) CVSS is een gestandaardiseerd systeem voor het toekennen van scores aan de ernst van softwarekwetsbaarheden. * **Base Metrics:** Beschrijven de inherente kenmerken van een kwetsbaarheid, zoals aanvalsvector, complexiteit en impact. * **Temporal Metrics:** Evalueren de veranderende aard van een kwetsbaarheid over tijd. * **Exploit Code Maturity:** De beschikbaarheid en volwassenheid van exploitcode. Een hogere score betekent een groter risico. * **Remediation Level:** De beschikbaarheid van patches of workarounds. Een lagere score duidt op een verminderd risico. * **Report Confidence:** Hoe goed een kwetsbaarheid is gevalideerd. Hogere zekerheid leidt tot een hogere score. * **Environmental Metrics:** Stellen organisaties in staat om de Base CVSS-score aan te passen op basis van hun specifieke beveiligingsvereisten en bestaande mitigerende maatregelen. * **Security Requirements:** De kritikaliteit van het getroffen systeem (bv. databases met klantgegevens krijgen hogere scores dan werkstations van niet-geprivilegieerde gebruikers). * **Modified Base Metrics:** Organisaties kunnen Base Metrics aanpassen op basis van bestaande mitigaties, zoals 'air-gapping' van systemen, wat de aanvalsvector verlaagt. > **Tip:** Door zowel Temporal als Environmental Metrics te overwegen, kan een meer nauwkeurige beoordeling van het werkelijke risico voor een specifieke omgeving worden verkregen. #### 2.3.2 EPSS (Exploit Prediction Scoring System) EPSS voorspelt de waarschijnlijkheid dat een kwetsbaarheid binnen 30 dagen wordt geëxploiteerd. Het maakt gebruik van een machine learning-model. * **Input:** CVSS-scores, exploitcode, telemetrie, adviezen, PoC-beschikbaarheid. * **Output:** Een waarschijnlijkheidsscore van 0 tot 1. * **Voorbeeld:** Voor Log4Shell (CVE-2021-44228) was de EPSS-score ongeveer 0,975, wat wijst op een 97,5% kans op exploitatie. * **Voordelen:** Voorspellend, met realtime updates. * **Nadelen:** Een wereldwijd gemiddelde, mist lokale context. > **Example:** Een kwetsbaarheid met een hoge CVSS-score (ernst) en een hoge EPSS-score (waarschijnlijkheid van exploitatie) zou een zeer hoge prioriteit moeten krijgen voor mitigatie. #### 2.3.3 CPE (Common Platform Enumeration) CPE is een gestructureerd naamgevingsschema om hardware, besturingssystemen en applicaties te identificeren. Het wordt gebruikt om kwetsbaarheden (CVE's) te koppelen aan specifieke producten. Dit is essentieel voor asset-kwetsbaarheidscorrelatie en geautomatiseerd kwetsbaarheidsbeheer. * **Voorbeeld:** `cpe:2.3:a:microsoft:edge:129.0.0:*:*:*:*:*:*` #### 2.3.4 CWE (Common Weakness Enumeration) CWE is een classificatie van software-zwakheden die kan leiden tot kwetsbaarheden. Het helpt bij het identificeren van de onderliggende oorzaken van beveiligingsproblemen. #### 2.3.5 SSVC (Stakeholder-Specific Vulnerability Categorization) SSVC biedt een beslissingsboom voor contextgestuurde prioritering, gebaseerd op verschillende beslisfactoren. Het helpt organisaties te bepalen of onmiddellijke actie vereist is. #### 2.3.6 CISA KEV (Known Exploited Vulnerabilities) De CISA KEV-lijst bevat kwetsbaarheden die actief worden geëxploiteerd. Deze lijst wordt regelmatig bijgewerkt door de U.S. Cybersecurity and Infrastructure Security Agency en is een kritieke prioriteit voor snelle mitigatie om tegen lopende aanvallen te beschermen. #### 2.3.7 Vulnerability Enrichment en Integratie Verschillende frameworks voegen lagen van context toe aan kwetsbaarheidsgegevens: * **Ontdekking:** CVSS (technische ernst) * **Context:** SSVC (missierelevantie voor de organisatie) * **Identificatie:** CPE (welk product is kwetsbaar) * **Voorspelling:** EPSS (waarschijnlijkheid van exploitatie) * **Bevestiging:** KEV (wordt het nu geëxploiteerd?) * **Reflectie:** LEV (was het eerder geëxploiteerd?) Een aanbevolen integratie voor risicogebaseerde prioritering is: `CVSS (Ernst) × EPSS (Waarschijnlijkheid) × KEV (Bewijs) → Verfijnen met SSVC (Context) → Valideren met CPE (Blootstelling)` ### 2.4 De kwetsbaarheidsintelligentie levenscyclus Deze cyclus beschrijft het proces van het omzetten van data naar actie: 1. **Planning:** Vaststellen van doelen en objectieven. 2. **Verzameling:** Data verzamelen over kwetsbaarheden en hun impact. 3. **Analyse:** Risico's beoordelen en acties prioriteren. 4. **Rapportage:** Inzichten delen voor gecoördineerde actie. 5. **Feedback:** Voortgang volgen en het proces verfijnen. #### 2.4.1 Sleutelvragen voor organisaties * **Prioritering:** Welke kwetsbaarheden vormen de grootste risico's? Hoe sturen CVSS- en EPSS-scores onze patchinspanningen? * **Bedrijfsbegrip:** Wat zijn de meest geëxploiteerde kwetsbaarheden op de CISA KEV-lijst? Welke leveranciers en producten komen consistent voor in rapporten? * **Actiegerichte inzichten:** Hoe beïnvloedt de waarschijnlijkheid van exploitatie onze patchprioriteiten? Wat zijn de herstelacties voor de meest relevante kwetsbaarheden? * **Bedrijfsimplicaties:** Wat is de potentiële impact van niet-aangepakte kwetsbaarheden op het bedrijf? Hoe prioriteren we kwetsbaarheden op basis van hun locatie (internetgericht versus intern)? * **Gegevensbronnen:** Gebruiken we CISA KEV, EPSS en andere geverifieerde databases effectief? Hoe kunnen deze bronnen onze risicogebaseerde kwetsbaarheidsbeheer aanpak verbeteren? ### 2.5 Betrouwbare bronnen voor kwetsbaarheidsintelligentie * **CISA Known Exploited Vulnerabilities (KEV):** CISA.gov - Een lijst van actief geëxploiteerde kwetsbaarheden. * **EPSS (Exploit Prediction Scoring System):** First.org - Een probabilistisch scoringsmodel voor de waarschijnlijkheid van exploitatie. * **CISA Top Exploited Vulnerabilities Reports:** Jaarlijkse rapporten, mede-auteurs van wereldwijde cybersecurity-agentschappen. * **NVD (National Vulnerability Database):** nvd.nist.gov - Een uitgebreide database met CVE-details. * **Vendor Security Advisories:** Websites van grote leveranciers (bv. Microsoft, VMware, Atlassian). * **Threat Intelligence Platforms:** Tools zoals Metasploit of exploit-db voor aanvullende inzichten. > **Tip:** Combineer meerdere bronnen voor een alomvattend begrip van het dreigingslandschap. --- # Geavanceerde persistente dreigingsgroepen (APT's) Dit onderwerp identificeert en beschrijft verschillende geavanceerde persistente dreigingsgroepen (APT's) die worden geassocieerd met specifieke landen, hun affiliaties, doelwitten, tactieken en opmerkelijke incidenten, evenals conventies voor het benoemen van deze actoren. ## 3. Geavanceerde persistente dreigingsgroepen (APT's) Geavanceerde persistente dreigingsgroepen (APT's) zijn georganiseerde entiteiten, vaak staatsgesteund, die zich richten op het verkrijgen van langdurige toegang tot specifieke netwerken om gevoelige informatie te stelen of systemen te ontwrichten. Ze onderscheiden zich door hun geavanceerde technieken, stealth, volharding en gerichte aard. ### 3.1 Russische APT's Rusland is geassocieerd met verschillende prominente APT's, die opereren onder verschillende affiliaties en met uiteenlopende doelwitten. #### 3.1.1 APT28 / Fancy Bear * **Affiliatie:** Russische GRU (militaire inlichtingendienst). * **Doelwitten:** Overheden, militaire organisaties, NAVO, media en politieke organisaties. * **Tactieken:** Spear-phishing, diefstal van inloggegevens, zero-days en supply-chain aanvallen. * **Opmerkelijk incident:** In de periode 2021-2024 schreef de Franse cybersecurity-agentschap ANSSI een reeks cyberaanvallen toe aan APT28, gericht op Franse ministeries, lokale overheden, de luchtvaart- en financiële sectoren en organisaties die betrokken waren bij de planning van de Olympische Spelen van 2024. De campagne omvatte infiltratiepogingen voor inlichtingenvergaring en operaties met de kenmerken van verkiezingsbemoeienis, gekoppeld aan Russische belangen. #### 3.1.2 APT29 / Cozy Bear * **Affiliatie:** SVR (Russische buitenlandse inlichtingendienst). * **Doelwitten:** Overheden, diplomatieke instanties, technologie- en onderzoeksinstellingen. * **Tactieken:** "Living-off-the-land" technieken (gebruik van legitieme tools), supply-chain aanvallen en stealthy persistentie. * **Opmerkelijk incident:** De supply-chain compromis van SolarWinds (SUNBURST backdoor) in 2020. Ongeveer 18.000 klanten van het Orion-platform installeerden de kwaadaardige update. Hoogwaardige slachtoffers, waaronder Amerikaanse overheidsinstanties, werden later geselecteerd voor volledige toegang. APT29 injecteerde een backdoor in een legitieme update, vestigde heimelijk persistente toegang en verplaatste zich naar doelnetwerken. #### 3.1.3 Turla / Snake / Uroburos * **Affiliatie:** FSB (Federale Veiligheidsdienst). * **Doelwitten:** Overheden, defensie, energie en ambassades in Europa en het Midden-Oosten. * **Tactieken:** Custom implants, modulaire backdoors en het kapen van satellietverbindingen. * **Opmerkelijk incident:** In 2016 compromitteerde Turla de Zwitserse defensieaannemer RUAG, waarbij gevoelige informatie werd geëxfiltreerd, waaronder de identiteiten van leden van een elite Zwitserse eenheid. Turla infiltreerde ook Tsjechische overheidsnetwerken in 2016-2017. De groep gebruikte zijn "Snake" malware en kaapte satelliet- en cybercriminele infrastructuur voor heimelijke spionagecampagnes. #### 3.1.4 Sandworm / BlackEnergy Group * **Affiliatie:** GRU Unit 74455. * **Doelwitten:** Kritieke infrastructuur, energiesector en militaire sectoren. * **Tactieken:** Destructieve malware (zoals Industroyer en NotPetya), wipers en verstoring van Industriële Controle Systemen (ICS). * **Opmerkelijk incident:** Op 23 december 2015 orkestreerde Sandworm een aanval op het Oekraïense elektriciteitsnet, waarbij de BlackEnergy3 malware en de KillDisk wiper werden gebruikt om onderstations in twee westelijke oblasten te ontregelen, waardoor ongeveer 225.000 klanten zonder stroom kwamen te zitten. Deze campagne was de eerste publiekelijk erkende succesvolle cyberaanval op een nationaal elektriciteitsnet. Latere aanvallen in 2016/2022 maakten gebruik van Industroyer2, CaddyWiper, en andere tools. ### 3.2 Noord-Koreaanse APT's Noord-Korea is geassocieerd met APT's die zich richten op financiële winst en technologische ontwikkeling. #### 3.2.1 APT38 / Lazarus Group * **Affiliatie:** Door de staat gesponsorde cyberunits van de Democratische Volksrepubliek Korea (DPRK). * **Doelwitten:** Financiële instellingen, cryptocurrency, defensie en media. * **Tactieken:** Social engineering, ransomware en crypto-diefstalmalware. * **Opmerkelijk incident:** In juni 2022 stalen door Noord-Korea gelieerde actoren (APT38) ongeveer $100 miljoen aan cryptocurrency van de Horizons-brug. De groep gebruikte cryptografische layering en laundering via het Railgun-systeem om de gestolen fondsen te verplaatsen. ### 3.3 Chinese APT's China is geassocieerd met APT's die opereren onder de paraplu van staatsinlichtingen. #### 3.3.1 APT10 / Cloud Hopper * **Affiliatie:** Ministerie van Staatsveiligheid (MSS). * **Doelwitten:** Managed Service Providers (MSPs), telecombedrijven, luchtvaart, productie en R&D. * **Tactieken:** Supply-chain compromis, backdoors en diefstal van inloggegevens. * **Opmerkelijk incident:** Van ongeveer 2014 tot 2018 compromitteerde Operatie Cloud Hopper wereldwijd grote Managed Service Providers (MSPs) om toegang te krijgen tot klantnetwerken, wat werd toegeschreven aan APT10. De aanvallers maakten gebruik van gecompromitteerde MSP-inloggegevens, laterale bewegingen via het MSP-klant-ecosysteem en bereikten honderden bedrijfs- en overheidsdoelen in veel landen. ### 3.4 Iraanse APT's Iran heeft APT's die zich richten op strategische sectoren en politieke tegenstanders. #### 3.4.1 APT33 / Elfin * **Affiliatie:** Islamitische Revolutionaire Garde Corps (IRGC). * **Doelwitten:** Luchtvaart, energie, overheid en industriële controlesystemen. * **Tactieken:** Spear-phishing, diefstal van inloggegevens en destructieve malware (zoals Shamoon-varianten). * **Opmerkelijk incident:** APT33 richtte zich op luchtvaart- en petroleumbedrijven via spear-phishing, valse vacatures en HTA-malware tussen ongeveer 2016-2017. De groep is waargenomen bij het voorbereiden van disruptieve ICS-operaties en heeft zich gericht op de Iraanse petrochemische/luchtvaart strategische sectoren. ### 3.5 Pakistaanse APT's Pakistan is geassocieerd met APT's die zich richten op specifieke geopolitieke rivalen. #### 3.5.1 APT36 / Transparent Tribe * **Affiliatie:** Pakistanse militaire inlichtingendienst. * **Doelwitten:** Indiase overheid, militair en onderwijsinstellingen. * **Tactieken:** Spear-phishing, remote-access trojans (Crimson RAT) en Android spyware. * **Opmerkelijk incident:** APT36 maakte gebruik van spear-phishing campagnes (Operatie Transparent Tribe) gericht op Indiase militaire personeel en overheidsfunctionarissen vanaf ongeveer 2016. Meer recentelijk, in 2022, gebruikte de groep de nieuwe "Limepad" malware gericht op Indiase overheidsmedewerkers. Campagnes omvatten Android spyware (CapraRAT) en phishing via getrojaniseerde apps (MeetsApp / MeetUp) gericht op Indiase overheids- en defensiesectoren. ### 3.6 Amerikaanse APT's De Verenigde Staten zijn, via hun inlichtingendiensten, ook betrokken bij geavanceerde cyberoperaties. #### 3.6.1 Equation Group * **Affiliatie:** Tailored Access Operations (TAO) van de NSA. * **Doelwitten:** Wereldwijde telecommunicatie, overheden en technologieaanbieders. * **Tactieken:** Firmware-implants, custom malware frameworks en netwerkexploitatie tools. * **Opmerkelijk incident:** In 2016 lekte de groep bekend als Shadow Brokers hacktools en exploits die naar verluidt toebehoorden aan Equation Group (gelieerd aan de NSA). Kaspersky bevestigde code-overeenkomsten met de malware van Equation. De lekken omvatten firewall exploits, scripts en tools daterend uit 2010, wat leidde tot de publieke verspreiding van wapengebruikte cybertools (zoals die hergebruikt in WannaCry) en een verhoogd bewustzijn van offensieve cybercapaciteiten. ### 3.7 Conventies voor naamgeving van APT's Verschillende cybersecuritybedrijven hanteren hun eigen conventies voor het benoemen van bedreigingsactoren, vaak gebaseerd op hun motivatie, landaffiliatie of tactieken. #### 3.7.1 Microsoft Actor Naming Conventions Microsoft hanteert vijf hoofdcategorieën, gebaseerd op motivatie: * **Nation-state actors:** Geassocieerd met statelijke actoren. * **Financially motivated actors (Tempest):** Gericht op financieel gewin. * **Private sector offensive actors (Tsunami):** Particuliere entiteiten die offensieve cybercapaciteiten aanbieden. * **Influence operations (Flood):** Gerelateerd aan desinformatie en beïnvloedingscampagnes. * **Groups in development (Storm):** Opkomende groepen. Voorbeelden: Volt Typhoon, Storm-0288, Midnight Blizzard. Voorheen gebruikte Microsoft element-gebaseerde namen zoals "NOBELIUM". #### 3.7.2 Crowdstrike Actor Naming Conventions Crowdstrike deelt bedreigingsactoren in drie categorieën in: * **Nation-state actors performing espionage:** Benoemd naar het nationale dier van het betreffende land. * **Financially motivated (Spider):** Gerelateerd aan financieel gewin. * **Hacktivists (Jackal):** Hackers die politieke of sociale doelen nastreven. Voorbeelden: Scattered Spiders, Mustang Panda. #### 3.7.3 Recorded Future Actor Naming Conventions Recorded Future gebruikt verschillende methoden: * **State-Sponsored APTs:** Benoemd met een kleur of kleurmengsel van de nationale vlag van het toegewezen land, of een uniek codewoord uit het NAVO-fonetische alfabet (bv. "RedDelta"). * **Threat activity groups:** Aangeduid met "TAG-" gevolgd door een nummer (bv. "TAG-22"), waarbij TAG's landaffiliatie-agnostisch zijn. * **Advanced Cybercriminal Gangs:** Groepen zonder namen krijgen een "Gray" + kardinaal getal (bv. "Grey2"), terwijl groepen die zichzelf benoemen hun eigen namen behouden (bv. "Conti Ransomware Gang"). * **Hacktivists:** Zelfbenoemde groepen (bv. "KillNet"). #### 3.7.4 Palo Alto's Unit 42 Actor Naming Conventions Unit 42 hanteert een naam bestaande uit twee delen: de naam van een sterrenbeeld en een modificerend woord. De vijf categorieën zijn: Cybercrime (General), Business Email Compromise, Ransomware, Hacktivism, en Nation-State focused on Espionage. Voorbeelden: Pensive Ursa (Turla), Howling Scorpius (Akira) en Ignoble Scorpius (BlackSuit). #### 3.7.5 Mandiant (GTI) Actor Naming Conventions Mandiant categoriseert groepen als volgt: * **APT##:** Staatsgesponsorde dreigingsgroepen met langdurige, persistente operaties. * **FIN##:** Financieel gemotiveerde groepen geïdentificeerd door Mandiant. * **TEMP.:** Tijdelijke cluster-designators gebruikt wanneer Mandiant een activiteitcluster ziet, maar het nog niet zelfverzekerd kan toewijzen aan een bestaande groep of een nieuwe APT/FIN-groep kan creëren. * **UNC (Unknown/Unclassified):** Gebruikt wanneer Mandiant een distinct activiteitcluster heeft geïdentificeerd, maar het nog niet kan toewijzen aan een bekende APT/FIN-groep, bevestigen dat het een coherente groep is (in plaats van overlappende operators), of voldoen aan de bewijsdrempel voor formele promotie. Voorbeelden: APT41, FIN7, TEMP. Armageddon, UNC484. #### 3.7.6 MITRE Actor Naming Conventions MITRE gebruikt een prefix "G" gevolgd door een sequentieel nummer (bv. G0016). Dit is niet-semantisch en er is één ID per MITRE-gedefinieerde groep. Aliassen worden apart behandeld en er zijn geen gereserveerde bereiken. Voorbeelden: G0016 (APT29), G0032 (FIN7), G0096 (Lazarus Group). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | Cyberdreigingsinlichtingen (CTI) | Het proces van het verzamelen, verwerken en analyseren van informatie over cyberdreigingen om een beter begrip te krijgen van de bedreigingen, hun motivaties, capaciteiten en intenties, met als doel proactieve verdedigingen en reacties te verbeteren. | | Strategisch niveau | Inlichtingen die bedoeld zijn voor leiderschap en besluitvormers op hoog niveau, gericht op langetermijnrisico's, trends en de algemene cyberbeveiligingshouding van een organisatie. | | Operationeel niveau | Inlichtingen die gericht zijn op managers en beveiligingsteams, met details over de tactieken, technieken en procedures (TTP's) van bedreigingsactoren en hun lopende campagnes. | | Tactisch niveau | Inlichtingen die gedetailleerde technische informatie bevatten over specifieke bedreigingen, zoals malware-indicatoren, IP-adressen en domeinnamen, bedoeld voor directe beveiligingsmaatregelen. | | Chatham House Rules | Een regel die van toepassing is op discussies waarbij deelnemers informatie uit de discussie vrij mogen gebruiken, maar de identiteit van de sprekers niet mogen onthullen, om openheid en eerlijkheid te bevorderen. | | Traffic Light Protocol (TLP) | Een protocol dat wordt gebruikt om de verspreiding van gevoelige informatie te reguleren, met verschillende kleurbenamingen (RED, AMBER, GREEN, CLEAR) die aangeven aan wie de informatie mag worden gedeeld. | | Kwetsbaarheidsintelligentie | Een specifiek type cyberdreigingsinlichtingen dat zich richt op het identificeren en analyseren van zwakheden (kwetsbaarheden) in software, hardware of configuraties die door aanvallers kunnen worden uitgebuit. | | CVE (Common Vulnerabilities and Exposures) | Een gestandaardiseerde lijst van publiekelijk bekende informatiebeveiligingskwetsbaarheden en -blootstellingen, die een unieke identificatiecode bevat voor elke geregistreerde kwetsbaarheid. | | CVSS (Common Vulnerability Scoring System) | Een open industriestandaard voor het beoordelen van de ernst van beveiligingskwetsbaarheden, die numerieke scores toekent op basis van verschillende metrische groepen om de potentiële impact te kwantificeren. | | EPSS (Exploit Prediction Scoring System) | Een systeem dat de waarschijnlijkheid voorspelt dat een kwetsbaarheid binnen 30 dagen zal worden geëxploiteerd, gebruikmakend van machine learning op basis van diverse databronnen. | | KEV (Known Exploited Vulnerabilities) | Een lijst van kwetsbaarheden die actief door bedreigingsactoren worden uitgebuit, samengesteld en bijgehouden door CISA (Cybersecurity and Infrastructure Security Agency) om de focus op de meest urgente bedreigingen te vergemakkelijken. | | APT (Advanced Persistent Threat) | Een geavanceerde, aanhoudende dreiging, meestal een groep die door een staat wordt gesteund of gefinancierd, die zich richt op specifieke organisaties of landen met als doel langdurige infiltratie, spionage of verstoring. | | TTP's (Tactics, Techniques, and Procedures) | De methoden en werkwijzen die door bedreigingsactoren worden gebruikt om hun doelen te bereiken, zoals gedefinieerd door frameworks zoals MITRE ATT&CK. | | Zero-day | Een kwetsbaarheid die nog niet publiekelijk bekend is of waarvoor nog geen patch beschikbaar is, waardoor deze zeer waardevol is voor aanvallers. | | Proof-of-Concept (PoC) | Een demonstratie of code die de exploitatie van een kwetsbaarheid aantoont, vaak gebruikt om de ernst van de kwetsbaarheid te bewijzen of om een aanval te reproduceren. | | MITRE ATT&CK | Een wereldwijd toegankelijke kennisbasis van de tactieken en technieken van vijanden, gebaseerd op echte observaties, die dient als een gemeenschappelijke taal voor cyberbeveiligingskaders. | | CPE (Common Platform Enumeration) | Een gestandaardiseerd naamgevingsschema voor het identificeren van hardware-, besturingssysteem- en softwareproducten, gebruikt om kwetsbaarheden te correleren met specifieke activa. | | CWE (Common Weakness Enumeration) | Een lijst met veelvoorkomende software- en hardwarezwakheden die kunnen leiden tot kwetsbaarheden, nuttig voor het identificeren en aanpakken van programmeerfouten. | | SSVC (Stakeholder-Specific Vulnerability Categorization) | Een beslissingsboomkader dat contextafhankelijke prioritering van kwetsbaarheden mogelijk maakt op basis van gedefinieerde beslissingsfactoren en de missie van een organisatie. | | Indicatoren van Compromis (IoC's) | Digitale artefacten die wijzen op een mogelijke inbraak op een netwerk, zoals verdachte IP-adressen, domeinnamen, bestands-hashes en afwijkende netwerkactiviteit. |

# Inleiding tot MISP Dit gedeelte introduceert het Malware Information Sharing Platform (MISP) als een open-source platform voor het beheren en uitwisselen van cyberdreigingsinformatie. ## 1. Inleiding tot MISP Het Malware Information Sharing Platform (MISP) is een open-source platform dat is ontworpen voor het beheren en uitwisselen van Cyber Threat Intelligence (CTI). Het platform is oorspronkelijk ontwikkeld door Christophe Vandeplas bij Belgian Defence en wordt momenteel verder ontwikkeld en onderhouden door CIRCL (Computer Incident Response Center Luxembourg). Het primaire doel van MISP is om organisaties te helpen bij het verzamelen, opslaan, analyseren en delen van Indicators of Compromise (IOCs). Het wordt veelvuldig gebruikt door Computer Emergency Response Teams (CERTs), Security Operations Centers (SOCs), Information Sharing and Analysis Centers (ISACs), militaire organisaties en private ondernemingen. ### 1.1 Kernconcepten binnen MISP MISP organiseert threat intelligence informatie rond verschillende kernconcepten die samen een gestructureerd en bruikbaar ecosysteem vormen voor het delen van dreigingsinformatie. #### 1.1.1 Events Een MISP-event fungeert als een container voor gerelateerde threat intelligence informatie. Het groepeert diverse indicatoren, objecten en attributen binnen een specifieke context, zoals bijvoorbeeld een phishingcampagne of een specifieke malware-uitbraak. Elk event wordt geïdentificeerd door een unieke Event ID en beschikt over metadata, waaronder de maker, de datum van creatie, toegepaste tags en het distributieniveau. Events zijn essentieel voor het organiseren en delen van informatie over specifieke incidenten of dreigingsscenario's. #### 1.1.2 Attributes Attributen zijn de meest elementaire eenheden van informatie binnen MISP en vertegenwoordigen een enkelvoudig gegevensobject gerelateerd aan een dreiging. Voorbeelden van attributen zijn een IP-adres, een domeinnaam of een e-mailadres. Elk attribuut heeft een gedefinieerd type (bijvoorbeeld `ip-src` voor bron-IP-adres, `url` voor een webadres, of `hash` voor een bestandshash), een categorie (zoals 'Network activity' of 'Malware analysis') en de feitelijke waarde. Daarnaast kunnen attributen contextuele informatie bevatten, zoals Intrusion Detection System (IDS) vlaggen of specifieke commentaren. Attributen zijn de atomische indicatoren die gebruikt worden voor detectie, correlatie en analyse over verschillende events heen. #### 1.1.3 Objects Een MISP-object is een gestructureerde verzameling van gerelateerde attributen. Objecten modelleren real-world entiteiten of technische artefacten, zoals een bestand, een combinatie van domein en IP-adres, of een specifieke kwetsbaarheid. Elk object maakt gebruik van een vooraf gedefinieerd sjabloon (template) dat de toegestane attributen en de relaties daartussen specificeert. Het gebruik van objecten verbetert de organisatie van data en zorgt voor semantische consistentie binnen threat intelligence datasets. #### 1.1.4 Event reports Event reports zijn menselijk leesbare samenvattingen of analyses die aan een specifiek event worden gekoppeld. Ze bieden narrative context, resultaten van onderzoeken, of tijdlijnen van incidenten. Deze rapporten worden typisch geschreven in Markdown voor gestructureerde en leesbare presentatie, en vullen de technische data aan met analytische inzichten. #### 1.1.5 Galaxies Galaxies zijn gestructureerde kennisbanken die gerelateerde dreigingsentiteiten groeperen, zoals threat actors, malware families, of tactieken, technieken en procedures (TTPs) zoals gedefinieerd door frameworks als MITRE ATT&CK. Elke galaxy bevat clusters met metadata en gedefinieerde relaties. Galaxies worden gebruikt om events te verrijken met high-level intelligence context en faciliteren classificatie en threat correlatie tussen verschillende MISP-instanties. Ze kunnen worden toegepast op zowel events als individuele attributen. #### 1.1.6 Correlations Correlations in MISP verwijzen naar automatische koppelingen tussen events en attributen die overeenkomen of gerelateerde data bevatten. Dit helpt bij het identificeren van gemeenschappelijke indicatoren, infrastructuur of threat actors. Deze correlaties worden vaak gevisualiseerd door middel van correlatiegrafieken of relatiekaarten, wat bijdraagt aan een verbeterd situationeel bewustzijn en effectievere threat tracking. #### 1.1.7 Proposals Proposals zijn voorgestelde wijzigingen aan attributen of objecten die zijn gemaakt door externe bijdragers. Dit mechanisme is met name nuttig wanneer gebruikers beperkte bewerkingsrechten hebben op gedeelde data. Eigenaren van events kunnen deze voorgestelde modificaties beoordelen, accepteren of afwijzen, wat bijdraagt aan het handhaven van de data-integriteit terwijl collaboratieve intelligence sharing mogelijk wordt gemaakt. #### 1.1.8 Warning lists Warning lists zijn collecties van bekende 'benigne' of 'false positive' indicatoren, zoals publieke DNS-servers of de meest populaire domeinen volgens lijsten zoals Alexa Top 1M. Deze lijsten worden automatisch vergeleken met eventdata om potentiële valse positieven te signaleren. Dit helpt analisten om zich te concentreren op de werkelijk relevante indicatoren. Deze lijsten moeten regelmatig worden bijgewerkt om hun accuraatheid te behouden. #### 1.1.9 Feeds Feeds maken het mogelijk om externe databronnen automatisch te importeren in MISP. Dit biedt toegang tot threat intelligence van publieke, commerciële of interne bronnen. Feeds zijn configureerbaar voor periodieke synchronisatie en maken continue verrijking en correlatie van dreigingsdata mogelijk. ### 1.2 Tags en Taxonomies Tags en Taxonomies spelen een cruciale rol in de categorisatie, filtering en toegangscontrole binnen MISP. #### 1.2.1 Tags Tags zijn labels die worden toegepast op events of attributen om deze te categoriseren. Ze maken snelle filtering, zoeken en handhaving van toegangsbeheer mogelijk. Tags kunnen door gebruikers zelf worden gedefinieerd of worden afgeleid van taxonomies en galaxies. Ze ondersteunen automatisering en de afdwinging van sharing policies. #### 1.2.2 Taxonomies Taxonomies zijn vooraf gedefinieerde sets van gestandaardiseerde tags, zoals de Traffic Light Protocol (TLP) classificaties of het Admiralty System. Ze zorgen voor consistente classificatie over verschillende organisaties heen. Elke taxonomie definieert een vocabulaire van betekenisvolle termen en verbetert de interoperabiliteit en de uitwisseling van gestructureerde data. ### 1.3 Admiralty System (NATO Intelligence Rating System) Het Admiralty System is een tweeledig beoordelingssysteem dat afzonderlijk de betrouwbaarheid van de bron (Source Reliability) en de geloofwaardigheid van de informatie (Information Credibility) evalueert. * **Bron Betrouwbaarheid:** Geclassificeerd van A tot F, waarbij A de meest betrouwbare bron aanduidt en F de minst betrouwbare. * **Informatie Geloofwaardigheid:** Geclassificeerd van 1 tot 6, waarbij 1 de meest geloofwaardige informatie aangeeft en 6 de minst geloofwaardige. Dit systeem erkent dat een betrouwbare bron slechte informatie kan leveren, en een onbetrouwbare bron accurate informatie kan verschaffen. De gecombineerde beoordelingen, zoals A1 (zeer betrouwbare bron, zeer geloofwaardige informatie) of C3 (gemiddeld betrouwbare bron, gemiddeld geloofwaardige informatie), maken consistente interpretatie mogelijk. De ratings zijn niet-normatief, wat betekent dat ze de beoordeelde betrouwbaarheid/geloofwaardigheid op het moment van rapportage beschrijven en geen voorspelling doen van toekomstige prestaties. Het systeem is ontworpen voor de 'fusion' en vergelijking van informatie, waardoor meerdere rapporten systematisch kunnen worden gewogen. Het is vendor- en domein-neutraal en kan worden gebruikt in diverse militaire, inlichtingen- en cybersecuritycontexten. ### 1.4 Distributieniveaus (Distribution Levels) MISP biedt een fijnmazig controlesysteem voor het bepalen hoe threat intelligence informatie wordt gedeeld. De distributieniveaus bepalen welke organisaties of gemeenschappen toegang krijgen tot specifieke events. * **Your organisation only:** Alleen zichtbaar binnen de eigen organisatie. * **This community only:** Zichtbaar binnen de eigen MISP community. * **The server on which you’re on:** Zichtbaar voor alle gebruikers van de specifieke MISP-server. * **Connected communities:** Zichtbaar voor communities die direct verbonden zijn met de eigen community. * **This community + any connected servers; but not further:** Zichtbaar voor de eigen community en verbonden servers, maar niet verder verspreid. * **All communities:** Geen restrictie op propagatie, zolang er een connectie bestaat. * **Distribution lists / Sharing groups:** Specifieke lijsten of groepen gebruikers kunnen worden aangewezen. * **Inherit event:** Het event neemt het distributieniveau over van de creator of een parent event. > **Tip:** Het correct instellen van distributieniveaus is cruciaal voor het waarborgen van de vertrouwelijkheid en het effectief delen van threat intelligence, om te voorkomen dat gevoelige informatie onbedoeld wordt verspreid. ### 1.5 Toepassingsvoorbeelden en Oefeningen MISP wordt in de praktijk gebruikt om actuele dreigingsinformatie te delen en te analyseren. De documentatie bevat links naar demonstraties en oefeningen die de functionaliteit van MISP illustreren. > **Voorbeeld:** Een demonstatie kan een scenario tonen waarbij een nieuw malware-exemplaar wordt geanalyseerd, de bijbehorende IOCs (IP-adressen, hashes, domeinen) worden geëxtraheerd en als een MISP-event worden gedeeld met andere organisaties. Oefeningen tonen hoe MISP kan worden gebruikt om te reageren op specifieke dreigingen, zoals het analyseren van APT-groepen (Advanced Persistent Threats) of het identificeren van botnet-activiteiten. --- # Kernconcepten van MISP Dit deel van de studiehandleiding behandelt de fundamentele bouwstenen van MISP (Malware Information Sharing Platform & Threat Sharing) en hun rol in het beheer en de uitwisseling van cyberdreigingsinformatie. ### 2.1 Wat is MISP? MISP is een open-source platform dat is ontworpen om organisaties te helpen bij het verzamelen, opslaan, analyseren en delen van Indicators of Compromise (IOC's) en andere cyberdreigingsinformatie (CTI). Het platform is ontwikkeld om incidentresponsteams (CERTs), Security Operations Centers (SOCs), ISACs, militaire instanties en particuliere bedrijven te ondersteunen bij het gestructureerd omgaan met dreigingsinformatie. ### 2.2 Essentiële Componenten van MISP De kernfunctionaliteit van MISP wordt gevormd door een reeks onderling verbonden concepten: #### 2.2.1 Events Een MISP-event fungeert als een container voor gerelateerde dreigingsinformatie. Het groepeert verschillende indicatoren, objecten en attributen die verband houden met een specifieke incident, dreiging of campagne. Elk event wordt geïdentificeerd door een unieke Event ID en bevat metadata zoals de maker, aanmaakdatum, distributieniveau en tags. Events zijn cruciaal voor het organiseren en delen van contextuele informatie over specifieke dreigingsscenario's. #### 2.2.2 Attributes Attributen vertegenwoordigen de meest atomische stukjes dreigingsinformatie binnen MISP. Dit kunnen specifieke gegevenspunten zijn zoals een IP-adres, een domeinnaam, een e-mailadres of een hashwaarde. Elk attribuut heeft een specifiek type (bijvoorbeeld `ip-src`, `url`, `hash`) en behoort tot een bepaalde categorie (bijvoorbeeld "Network activity"). Attributen kunnen aanvullende contextuele informatie bevatten, zoals IDS-vlaggen of commentaren. Ze zijn de bouwstenen voor detectie en correlatie over verschillende events heen. #### 2.2.3 Objects Een MISP-object is een gestructureerde verzameling van gerelateerde attributen. Objecten zijn ontworpen om reële entiteiten of technische artefacten te modelleren, zoals een bestand, een domein-IP-paar, of een kwetsbaarheid. Elk object maakt gebruik van een vooraf gedefinieerd sjabloon dat specificeert welke attributen toegestaan zijn en hoe deze zich tot elkaar verhouden. Dit bevordert de organisatie van data en zorgt voor semantische consistentie binnen dreigingsinformatiedatabases. > **Tip:** Objecten bieden een krachtige manier om complexe dreigingsinformatie op een georganiseerde en semantisch rijke manier weer te geven, wat de analyse aanzienlijk verbetert. #### 2.2.4 Event Reports Event reports zijn menselijk leesbare samenvattingen of analyses die aan een specifiek event worden gekoppeld. Ze bieden narratieve context, onderzoeksresultaten of tijdlijnen van incidenten. Deze rapporten worden doorgaans geschreven in Markdown om gestructureerde en leesbare inhoud te garanderen, en complementeren de technische data met analytische inzichten. #### 2.2.5 Galaxies Galaxies zijn gestructureerde kennisbanken die gerelateerde dreigingsentiteiten groeperen, zoals threat actors, malware families of MITRE ATT&CK technieken. Elke galaxy bevat "clusters" met metadata en relaties. Ze worden gebruikt om events te verrijken met hogere-level intelligentie en faciliteren de classificatie en correlatie van dreigingen over verschillende MISP-instances heen. Galaxies kunnen worden toegepast op zowel events als attributen. #### 2.2.6 Admiralty System Het Admiralty System, ook bekend als het NATO Intelligence Rating System, is een tweeledig beoordelingssysteem voor bronbetrouwbaarheid en informatiegeloofwaardigheid. Het evalueert onafhankelijk de betrouwbaarheid van de bron (geschaald van A tot F) en de geloofwaardigheid van de informatie (geschaald van 1 tot 6). Dit systeem erkent dat een betrouwbare bron soms minder accurate informatie kan leveren, en vice versa. De gecombineerde beoordelingen, bijvoorbeeld A1 of C3, maken consistente interpretatie mogelijk. Het systeem is ontworpen voor fusie en vergelijking, en is vendor- en domein-neutraal. * **Bronbetrouwbaarheid (A-F):** Geeft aan hoe betrouwbaar de bron historisch is gebleken. * **Informatiegeloofwaardigheid (1-6):** Geeft aan hoe waarschijnlijk de informatie zelf is, gebaseerd op de beoordeling op het moment van rapportering. #### 2.2.7 Tags Tags zijn labels die aan events of attributen worden toegekend voor categorisatie en filtering. Ze maken snelle zoekopdrachten, filtering en toegangscontrole mogelijk. Tags kunnen door gebruikers worden gedefinieerd of afgeleid worden van Taxonomies en Galaxies. Ze ondersteunen automatisering en het afdwingen van deelbeleid. #### 2.2.8 Taxonomies Taxonomies zijn vooraf gedefinieerde sets van gestandaardiseerde tags die zorgen voor consistente classificatie over verschillende organisaties heen. Elke taxonomy definieert een vocabulaire van betekenisvolle termen, wat de interoperabiliteit en het gestructureerd delen van data verbetert. Voorbeelden hiervan zijn TLP (Traffic Light Protocol) en het Admiralty System. #### 2.2.9 Correlations Correlations in MISP zijn automatische koppelingen tussen events en attributen die overeenkomende of gerelateerde data bevatten. Dit helpt bij het identificeren van gemeenschappelijke indicatoren, infrastructuur of threat actors. Correlaties worden vaak gevisualiseerd via correlatiegrafieken of relatiekaarten, wat de situationele bewustzijn en het volgen van dreigingen verbetert. #### 2.2.10 Proposals Proposals zijn voorgestelde wijzigingen aan attributen of objecten die door externe bijdragers zijn aangemaakt. Dit mechanisme wordt gebruikt wanneer gebruikers beperkte bewerkingsrechten hebben op gedeelde data. Event-eigenaren kunnen deze voorgestelde wijzigingen beoordelen, accepteren of afwijzen, wat bijdraagt aan de integriteit van de data en tegelijkertijd samenwerkende dreigingsinformatiedeling mogelijk maakt. #### 2.2.11 Warning Lists Warning Lists zijn verzamelingen van bekende goedaardige of false-positive indicatoren, zoals publieke DNS-servers of de Top 1 miljoen domeinen van Alexa. Deze lijsten worden automatisch vergeleken met de data in events om potentiële valse positieven te signaleren. Dit helpt analisten om zich te concentreren op de meest relevante indicatoren. Warning lists moeten regelmatig worden bijgewerkt om hun nauwkeurigheid te behouden. #### 2.2.12 Feeds Feeds zijn externe databronnen die automatisch worden geïmporteerd in MISP. Ze leveren dreigingsinformatie van publieke, commerciële of interne bronnen. Feeds kunnen worden geconfigureerd voor periodieke synchronisatie, wat zorgt voor een continue verrijking en correlatie van dreigingsdata. ### 2.3 Distributieniveaus MISP hanteert verschillende distributieniveaus om te bepalen hoe dreigingsinformatie wordt gedeeld. Deze niveaus bepalen de reikwijdte van de zichtbaarheid en de mogelijke propagatie van data: * **Your organisation only:** De informatie is alleen zichtbaar binnen de eigen organisatie. * **This community only:** De informatie is alleen zichtbaar binnen de direct verbonden gemeenschap (community). * **The server on which you're on:** De informatie is alleen zichtbaar op de MISP-server waar deze is gecreëerd. * **Connected communities:** De informatie is zichtbaar voor alle direct en indirect verbonden gemeenschappen. * **This community + any connected servers; but not further:** De informatie is zichtbaar voor de huidige gemeenschap en servers die direct aan deze gemeenschap gekoppeld zijn, maar niet verder. * **All communities:** De informatie heeft geen beperkingen op propagatie zolang er een verbinding bestaat. Daarnaast zijn er mogelijkheden voor `Distribution lists / Sharing groups` en kan het distributieniveau van een event worden `Inherited`. --- # Distributieniveaus en Demonstraties Dit gedeelte beschrijft de verschillende distributieniveaus binnen MISP voor het delen van informatie, met verwijzingen naar demo's en oefeningen. ### 3.1 Distributieniveaus binnen MISP MISP biedt gedetailleerde controle over hoe informatie wordt gedeeld en verspreid. Deze distributieniveaus bepalen de reikwijdte van de zichtbaarheid en toegankelijkheid van gebeurtenissen en gerelateerde data. #### 3.1.1 Beschikbare distributieniveaus De volgende distributieniveaus zijn beschikbaar binnen MISP, van meest restrictief tot minst restrictief: * **Alleen uw organisatie**: Informatie is uitsluitend zichtbaar binnen de eigen organisatie. * **Alleen deze community**: Informatie wordt gedeeld met de specifieke community waarbinnen MISP is geïnstalleerd of geconfigureerd. * **De server waarop u zich bevindt**: Informatie is zichtbaar op de MISP-instantie waar de gebruiker toegang toe heeft. Dit kan overeenkomen met "Alleen deze community" afhankelijk van de configuratie. * **Verbonden communities**: Informatie wordt gedeeld met andere communities die expliciet verbonden zijn met de huidige MISP-instantie. * **Deze community + alle verbonden servers; maar niet verder**: Informatie wordt gedeeld met de eigen community en alle direct verbonden communities, maar deelt deze niet verder met andere, indirect verbonden communities. * **Alle communities**: Er is geen restrictie op de verspreiding zolang er een verbinding bestaat tussen de MISP-instanties. Dit is het meest open niveau van delen. #### 3.1.2 Sharing groups en distributielijsten Naast de algemene distributieniveaus, kunnen gebruikers ook specifieke "sharing groups" of distributielijsten creëren. Deze fungeren als groepen van organisaties of communities waaraan informatie specifiek kan worden gedeeld. Gebeurtenissen kunnen deze distributieniveaus erven, waardoor ze standaard de ingestelde distributie van de gebeurtenis overnemen. ### 3.2 Demonstraties en oefeningen Om de functionaliteiten van MISP te illustreren en gebruikers praktisch te laten oefenen, worden demonstraties en oefeningen aangeboden. Deze kunnen variëren van specifieke scenario's tot het analyseren van werkelijke dreigingsinformatie. #### 3.2.1 Voorbeelden van demo's en oefeningen Hieronder volgen enkele voorbeelden van demonstraties en oefeningen die relevant zijn voor MISP: * **Demo Scenario 1**: Een demonstratie die de functionaliteit van MISP demonstreert, mogelijk met betrekking tot de "AppSuite OneStart Deception" technologie. * Een mogelijke link voor deze demonstratie is: `https://www.gdatasoftware.com/blog/2025/09/38262-appsuite-onestart-deception`. * Een interne referentie naar een gebeurtenis voor deze demo kan zijn: `https://localhost/events/view/d58aa25d-4c4a-5d02-92bd-ca841850aa59`. * **Oefening Scenario 1**: Een praktische oefening gericht op het analyseren van dreigingsinformatie, bijvoorbeeld gerelateerd aan APT24 en hun aanvalspatronen. * Een mogelijke bron voor deze oefening is de analyse van APT24's strategie: `https://cloud.google.com/blog/topics/threat-intelligence/apt24-pivot-to-multi-vector-attacks`. * Een interne referentie naar een gebeurtenis voor deze oefening kan zijn: `https://localhost/events/view/f8727d06-1bac-4624-982b-7324439e6c53`. * **Oefening Scenario 2**: Een oefening die zich richt op het identificeren en analyseren van een specifieke dreiging, zoals de "ShadowBot" DDoS-botnet. * Een mogelijke bron voor deze oefening is een analyse van ShadowBot: `https://www.darktrace.com/blog/shadowv2-an-emerging-ddos-for-hire-botnet`. * Een interne referentie naar een gebeurtenis voor deze oefening kan zijn: `https://localhost/events/view/44a65216-3609-47d6-94c4-ceea4175e2a6`. > **Tip:** Door deze demo's en oefeningen te doorlopen, kan men een dieper inzicht krijgen in hoe MISP wordt gebruikt voor het beheren en delen van cyber dreigingsinformatie in realistische scenario's. Het bestuderen van de gebeurtenis-ID's kan helpen bij het navigeren binnen een MISP-instantie om de corresponderende data te bekijken. --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | MISP (Malware Information Sharing Platform & Threat Sharing) | Een open-source platform ontworpen voor het beheren, opslaan, analyseren en delen van cyberdreigingsinformatie, met name Indicatoren van Compromittering (IOCs). | | Cyberdreigingsinformatie (CTI) | Informatie die wordt verzameld, verwerkt en geanalyseerd om inzicht te krijgen in potentiële of bestaande bedreigingen en aanvallen op computersystemen en netwerken. | | Indicatoren van Compromittering (IOC) | Bewijs van een beveiligingsincident, zoals de aanwezigheid van kwaadaardige IP-adressen, domeinnamen, bestands-hashes of registervermeldingen die duiden op een compromis. | | Event (in MISP) | Een container binnen MISP die gerelateerde dreigingsinformatie, zoals indicatoren, objecten en attributen, groepeert in een enkele context, bijvoorbeeld een specifieke phishingcampagne of een beveiligingsincident. | | Attribute (in MISP) | Een enkelvoudig gegevenselement binnen een MISP-event dat een specifiek stuk dreigingsinformatie vertegenwoordigt, zoals een IP-adres, domeinnaam of e-mailadres, met een gedefinieerd type en categorie. | | Object (in MISP) | Een gestructureerde verzameling van gerelateerde attributen binnen MISP, die reële entiteiten of technische artefacten modelleert, zoals een bestand, een domein-IP-relatie of een kwetsbaarheid, met behulp van vooraf gedefinieerde templates. | | Event Report | Een menselijk leesbare samenvatting of analyse die aan een MISP-event is gekoppeld en narratieve context, onderzoeksresultaten of incidenttijdlijnen biedt, vaak geschreven in Markdown. | | Tags | Labels die worden toegepast op MISP-events of attributen voor categorisatie, wat snelle filtering, zoeken en toegangscontrole mogelijk maakt en de ondersteuning van automatisering en het delen van beleid vergemakkelijkt. | | Taxonomieën | Vooraf gedefinieerde sets van gestandaardiseerde tags, zoals TLP (Traffic Light Protocol) of de Admiralty Scale, die zorgen voor consistente classificatie en de interoperabiliteit tussen organisaties verbeteren. | | Admiralty System | Een beoordelingssysteem (ook bekend als NATO Intelligence Rating System) dat de betrouwbaarheid van de bron (A-F) en de geloofwaardigheid van de informatie (1-6) scheidt om de kwaliteit van inlichtingen systematisch te evalueren en te vergelijken. | | Galaxies | Gestructureerde kennisbases binnen MISP die gerelateerde dreigingsentiteiten, zoals aanvallers of malwarefamilies, groeperen, metadata en relaties bevatten om events te verrijken met context en correlatie over verschillende MISP-instanties heen te faciliteren. | | Correlaties | Automatische koppelingen tussen MISP-events en attributen die gebaseerd zijn op overeenkomende of gerelateerde gegevens, helpen bij het identificeren van gemeenschappelijke indicatoren, infrastructuur of aanvallers. | | Voorstellen (Proposals) | Voorgestelde wijzigingen aan attributen of objecten die door externe bijdragers worden gemaakt en die door de eigenaren van het event kunnen worden beoordeeld, geaccepteerd of afgewezen, wat bijdraagt aan gegevensintegriteit en samenwerking. | | Waarschuwingslijsten (Warning Lists) | Verzamelingen van bekende onschuldige of valse-positieve indicatoren die automatisch worden vergeleken met eventgegevens om potentiële valse positieven te markeren, waardoor analisten zich kunnen richten op relevante informatie. | | Feeds | Externe gegevensbronnen die automatisch in MISP worden geïmporteerd, wat zorgt voor continue verrijking en correlatie van dreigingsgegevens uit openbare, commerciële of interne bronnen. | | Distributieniveaus | Verschillende niveaus die de reikwijdte van het delen van informatie binnen MISP bepalen, variërend van strikt privé tot volledig openbaar, afhankelijk van de vertrouwelijkheid van de dreigingsinformatie. |

# YARA en regelconstructie Dit onderwerp introduceert YARA, een krachtig instrument voor het identificeren van bestanden en netwerkverkeer op basis van gedefinieerde patronen, en behandelt de fundamentele opbouw en best practices voor het creëren van effectieve YARA-regels. ### 1.1 Overzicht van YARA YARA is een tool die in 2007 is geïntroduceerd en gebruikt wordt voor het identificeren van bestanden en netwerkverkeer op basis van specifieke patronen. Het acroniem YARA staat voor "Yet Another Recursive Acronym". Het kan worden beschouwd als een geavanceerde versie van `grep` voor signature-gebaseerde detectie, een techniek die al langer bekend is binnen de antiviruswereld. Een YARA-regel bestaat uit een set van gedefinieerde *strings* en *condities* die de detectielogica bepalen. De drie kerncomponenten van een YARA-regel zijn: * **Meta-informatie**: Beschrijvende informatie over de regel. * **Strings**: De patronen die gezocht moeten worden. * **Condities**: De logische regels die bepalen wanneer de regel matcht. ### 1.2 YARA - Regelnaamgeving en Meta-informatie Effectieve regelnaamgeving en gestructureerde meta-informatie zijn cruciaal voor het beheer en onderhoud van YARA-regels. #### 1.2.1 Best Practices voor Meta-informatie De `meta`-sectie van een YARA-regel moet zo veel mogelijk context bieden. Aanbevolen velden zijn: * **Author**: Naam, e-mailadres of Twitter-handle van de maker. * **CreationDate**: Datum waarop de regel is aangemaakt. * **ModifyDate**: Datum waarop de regel voor het laatst is bijgewerkt. * **Version**: Het versienummer van de YARA-regel om wijzigingen te kunnen volgen. * **Reference**: Een link naar een artikel, download van een sample, of andere relevante informatie over het malware-sample waarvoor de regel is ontworpen. * **Description**: Een korte beschrijving van het doel van de regel en de malware die het beoogt te detecteren. * **Hash**: Een lijst van de hashes van de samples die gebruikt zijn bij het creëren van de regel. * **TlpCode**: Specificeert de toegestane deelmodaliteit van de regel (bv. TLP:WHITE). ### 1.3 YARA - Strings Strings zijn de fundamentele bouwstenen voor het identificeren van patronen binnen bestanden of netwerkverkeer. #### 1.3.1 Definitie en Modifiers Strings worden gedefinieerd met een naam gevolgd door de string zelf. Modifiers kunnen worden toegevoegd om de zoekopties te verfijnen: * `fullword`: Vereist een exacte woordmatch. * `wide`: Zoekt naar zowel ASCII- als Unicode-varianten, inclusief null-bytes. * `wide_ascii`: Zoekt naar zowel Unicode- als ASCII-varianten. * `nocase`: Negeert hoofdlettergevoeligheid tijdens de match. > **Tip:** Gebruik `nocase` spaarzaam. Als functies bijvoorbeeld "CamelCase" of "PascalCase" gebruiken, is `nocase` vaak onnodig en kan het de prestaties beïnvloeden. Optimaliseer de code waar mogelijk. #### 1.3.2 Best Practices voor Strings Strings zijn uitstekende identificatieobjecten. Overweeg de volgende elementen voor opname: * **Mutexes**: Uniek voor specifieke malware-families. Controleert of een apparaat al is geïnfecteerd door de aanwezigheid van een mutex te controleren. * **Zeldzame en ongebruikelijke user agents**: Kan duiden op kwaadaardige communicatie. * **C2-communicatie**: Patronen gerelateerd aan Command and Control servers. * **Registry keys**: Specifieke registersleutels die door malware worden gebruikt. * **Persistence mechanismen**: Patronen die duiden op methoden om persistentie te verkrijgen. * **PDB paths**: Padnamen die gebruikt worden tijdens het debuggen, vaak te vinden in malware. * **Debugging informatie**: Algemene debugging gerelateerde strings. * **Encrypted config strings**: Bevatten vaak nuttige Indicators of Compromise (IOCs) zoals IP-adressen en domeinen. * **Specifieke commentaren, variabelen, typografische fouten of grammaticale fouten**: Kunnen unieke identificatiemogelijkheden bieden. De "Pyramid of Pain" kan hierbij als leidraad dienen, waarbij lager gelegen indicatoren (zoals hashes) makkelijker te wijzigen zijn dan hoger gelegen indicatoren (zoals tactieken, technieken en procedures). #### 1.3.3 Hex Strings Naast tekstuele strings, ondersteunt YARA ook hexadecimale strings. Deze zijn nuttig voor het detecteren van binaire patronen. * **Basis Hex String**: Een reeks hexadecimale waarden. * Voorbeeld: `$a = {74 6f 70 20 73 65 63 72 65 74}` (komt overeen met "top secret" in ASCII). * **Wildcards**: Vraagtekens (`?`) kunnen worden gebruikt als wildcards voor individuele bytes. * Voorbeeld: `$a = { 74 ?? ?? 20 73 65 63 72 65 74 }` detecteert een patroon met twee willekeurige bytes ertussen. * **Byte Ranges**: Vierkante haken `[min-max]` specificeren een bereik van willekeurige bytes. * Voorbeeld: `$a = { 74 [2-10] 6f 70 20 73 65 63 72 65 74 }` zoekt naar de byte '74', gevolgd door 2 tot 10 willekeurige bytes, en dan de rest van de string. * **Alternatieven**: Gebruik de pipe `|` om alternatieve reeksen bytes aan te geven. * Voorbeeld: `$a = { 74 (01 02 | 03 04) 6f 70 20 73 65 63 72 65 74 }` matcht wanneer na de '74' OF de sequentie '01 02' OF de sequentie '03 04' volgt, waarna de rest van de string wordt gezocht. Dit resulteert in twee mogelijke matches: * `74 01 02 6f 70 20 73 65 63 72 65 74` * `74 03 04 6f 70 20 73 65 63 72 65 74` ### 1.4 YARA - Condities Condities definiëren de logica die bepaalt of een regel matcht. Ze kwantificeren de voorwaarden waaraan voldaan moet worden. #### 1.4.1 Algemene Conditie Constructies * **Counting**: Specificeert het aantal benodigde matches uit een set strings. * `3 of ($a, $b, $c, $d)`: Ten minste 3 van de gedefinieerde strings ($a, $b, $c, $d) moeten matchen. * `3 of ($a*)`: Ten minste 3 van alle strings die beginnen met "a" (bv. $a1, $a2) moeten matchen. * **Boolean Logic**: Gebruikt `and`, `or`, `not` om condities te combineren. * `$a and not $b`: String $a moet matchen en string $b mag niet matchen. #### 1.4.2 Voorbeelden van Condities Condities kunnen ook gebruik maken van ingebouwde functies en specifieke offsets: * **Bestandsheaders**: Controleer de magic bytes van bestanden. * `uint16(0) == 0x5A4D`: Controleert of de eerste 16 bits van het bestand overeenkomen met de MZ-header, wat duidt op een Windows EXE-bestand. * `uint32(0) == 0x464c457f) or (uint32(0) == 0xfeedfacf) or (uint32(0) == 0xcffaedfe) or (uint32(0) == 0xfeedface) or (uint32(0) == 0xcefaedfe)`: Controleert verschillende magic bytes die kunnen duiden op Linux-binaries (ELF-headers). * `uint16be(0x00) == 0xFFD8`: Controleert de Big-Endian 16-bit header die duidt op een JPEG-bestand. * **Reguliere expressies**: Gebruik reguliere expressies voor complexe patroonherkenning. * `$vbe = /#@~\^.+\^#~@/`: Definieert een regex-string genaamd `$vbe` die een VBE-bestand binnen een byte-sequentie detecteert. * **String Count**: Controleert het aantal keren dat een string voorkomt. * `#a == 6`: Controleert of de string `$a` exact 6 keer voorkomt in het bestand. > **Tip:** De juiste combinatie van strings en condities is cruciaal voor het creëren van YARA-regels die zowel efficiënt als nauwkeurig zijn. Test regels grondig met diverse samples. --- # Cyberdreigingsinformatieplatforms en -tools Dit gedeelte behandelt de diverse online platforms en tools die gebruikt worden voor het verzamelen, analyseren en delen van cyberdreigingsinformatie, inclusief scanners, zoekmachines voor internetdekking, IP-databases, analyseplatforms voor malware en URL's, en tools voor het monitoren van ransomware en spam. ## 2. Cyberdreigingsinformatieplatforms en -tools Cyberdreigingsinformatieplatforms en -tools vormen de ruggengraat van moderne cyberbeveiligingsoperaties. Ze bieden beveiligingsanalisten, incident response teams en threat hunters de nodige middelen om bedreigingen te detecteren, te analyseren en erop te reageren. Deze tools variëren van signature-gebaseerde detectiesystemen tot uitgebreide internetbrede scan- en analyseplatforms. ### 2.1 YARA YARA is een krachtig en flexibel hulpmiddel dat wordt gebruikt voor het identificeren van bestanden en netwerkverkeer op basis van tekstuele of binaire patronen. Het werd geïntroduceerd in 2007 en staat voor "Yet Another Recursive Acronym". YARA wordt vaak beschreven als "grep on steroids", wat de kracht ervan benadrukt in het zoeken naar specifieke patronen binnen grote hoeveelheden data. #### 2.1.1 YARA-regels Een YARA-regel is de kerncomponent van de tool. Deze bestaat uit een set *strings* (patronen) en *condities* die de logica van de regel bepalen. Een regel definieert wanneer een bestand of stuk data als malafide moet worden beschouwd. #### 2.1.2 Componenten van een YARA-regel * **Meta-informatie:** Biedt context en beschrijvende informatie over de regel. Goede meta-informatie is cruciaal voor het begrijpen en onderhouden van regels. Best practices omvatten: * `Author`: Naam, e-mailadres, Twitter-handle van de auteur. * `CreationDate`: Datum waarop de regel is aangemaakt. * `ModifyDate`: Datum waarop de regel is bijgewerkt. * `Version`: Versienummer van de YARA-regel voor het bijhouden van wijzigingen. * `Reference`: Een link naar een artikel of download van het malwaresample waarop de regel is gebaseerd. * `Description`: Een korte beschrijving van het doel van de regel en de malware die het beoogt te detecteren. * `Hash`: Een lijst van sample hashes die zijn gebruikt om de YARA-regel te creëren. * `TlpCode`: Specificeert de deelmogelijkheden van de regel (bijvoorbeeld TLP:WHITE, TLP:AMBER). * **Strings:** Dit zijn de daadwerkelijke patronen die YARA zoekt. Ze kunnen tekstueel of hexadecimaal zijn en verschillende modifiers hebben om de zoekopties te verfijnen. * **Modifiers:** * `fullword`: Zoekt naar het exacte woord. * `wide`: Inclusief Unicode-bytes met null bytes. * `wide ascii`: Inclusief Unicode- en ASCII-bytes. * `nocase`: Zoekt ongeacht hoofdlettergebruik. * **Best Practices voor Strings:** Strings zijn krachtige identificatie-objecten. Nuttige elementen om naar te zoeken zijn: * Mutexes: Vaak uniek voor malwarefamilies, geven aan of een systeem al geïnfecteerd is. * Zeldzame of ongebruikelijke user agents: Gebruikt in C2-communicatie. * Registry keys: Indicatoren voor persistentie. * PDB-paden: Debugging-informatie. * Geëncrypteerde configuratiestrings: Kunnen nuttige IOC's bevatten zoals IP-adressen en domeinen. * Specifieke commentaren, typografische of grammaticale fouten: Kunnen uniek zijn voor bepaalde malware. * **Hex Strings:** YARA ondersteunt ook hexadecimale strings, wat essentieel is voor het matchen van binaire patronen. * Voorbeeld: `$a = {74 6f 70 20 73 65 63 72 65 74}` ( komt overeen met "top secret" in hex) * **Wildcards:** Vraagtekens (`?`) kunnen worden gebruikt als wildcards voor individuele bytes. * **Bytebereiken:** Vierkante haken `[]` kunnen worden gebruikt om een bereik van bytes aan te geven, bijvoorbeeld `$a = { 74 [2-10] 6f 70 20 73 65 63 72 65 74 }` (zoek naar '74', gevolgd door 2 tot 10 willekeurige bytes, gevolgd door "op secret"). * **Alternatieven:** Verticale lijnen `|` kunnen worden gebruikt om alternatieve byte-sequenties aan te geven, bijvoorbeeld `$a = { 74 (01 02 | 03 04) 6f 70 20 73 65 63 72 65 74 }`. * **Condities:** Dit deel specificeert de logica die bepaalt of een regel triggert. Het kwantificeert welke strings moeten overeenkomen en onder welke omstandigheden. * Voorbeelden van condities: * `3 of ($a,$b,$c,$d)`: Minstens 3 van de genoemde strings moeten voorkomen. * `3 of ($a*)`: Minstens 3 strings met het prefix `$a` moeten voorkomen. * `$a and not $b`: String `$a` moet voorkomen en string `$b` mag niet voorkomen. * **Voorbeelden van YARA-condities:** * `uint16(0) == 0x5A4D`: Controleert de eerste twee bytes van een bestand om te zien of het de MZ-specificatie van een Windows EXE bevat. * `uint32(0) == 0x464c457f) or (uint32(0) == 0xfeedfacf)`: Controleert de magische bytes van een bestand om te bepalen of het een Linux-binair is. * `uint16be(0x00) == 0xFFD8`: Controleert de magische bytes van een JPEG-bestand. * `$vbe = /#@~\^.+\^#~@/`: Gebruikt een reguliere expressie om een VBE-bestand binnen een byte-reeks te detecteren. * `($a == 6)`: Controleert of het aantal voorkomens van string `$a` gelijk is aan 6. ### 2.2 Internetbrede Scan- en Zoekmachines Deze tools bieden inzicht in de externe attack surface van organisaties en het internet als geheel. Ze scannen poorten, identificeren services, ontdekken certificaten en indexeren apparaten en diensten wereldwijd. * **Urlscan.io:** Een online scanner voor URL's en websites. Het analyseert de fetch-activiteit, DOM, netwerkverzoeken en redirects om malafide indicatoren en phishinggedrag te identificeren. Het biedt ook visuele weergaven, metadata en dreigingsscores, wat nuttig is voor SOC-, IR- en phishing-triagedoeleinden. * **Censys.io:** Een internetbrede scan- en zoekmachine voor hosts, services en certificaten. Het brengt continu de IPv4-ruimte, het TLS-ecosysteem en cloud-infrastructuren in kaart. Het stelt gebruikers in staat open poorten, protocollen, softwareversies en misconfiguraties te ontdekken en ondersteunt threat hunting en vulnerability assessment. * **Shodan.io:** Een zoekmachine voor internetverbonden apparaten en diensten. Het indexeert banners van poorten, protocollen, IoT-apparaten, ICS en cloudservices, en onthult blootstellingen, misconfiguraties, kwetsbaarheden en open services. Het is een waardevolle tool voor threat hunting, asset discovery en externe attack-surface mapping. * **Hunter.how:** Een gespecialiseerde, webgebaseerde zoekmachine voor het in kaart brengen, fingerprinten en analyseren van de externe attack surface van een organisatie. Het scant en indexeert de wereldwijde IPv4- en IPv6-ruimte om informatie te verzamelen over internetverbonden apparaten en diensten. Het identificeert specifieke technologieën, producten en versies die op poorten draaien. * **FOFA (Footprint Finder):** Een op China gebaseerde cyberspace zoekmachine die door beveiligingsonderzoekers wordt gebruikt om internet-facing apparaten en digitale assets wereldwijd actief te scannen, in kaart te brengen en informatie te verzamelen. Vergelijkbaar met Shodan en Hunter.how, focust FOFA op fingerprinting van software, hardware, besturingssystemen en versies. Het biedt een krachtige query-taal voor gedetailleerde zoekopdrachten. * **Driftnet.io:** Een internetbrede attack-surface & exposure intelligence platform dat hosts, services, poorten, TLS-certificaten en internetverbonden assets wereldwijd scant. Het aggregeert service- en poortgegevens om blootgestelde of verkeerd geconfigureerde services te ontdekken. Het biedt een web-UI en API voor asset discovery, exposure monitoring en externe attack-surface analyse. ### 2.3 Malware Analyse Platforms Deze platforms bieden geavanceerde methoden om verdachte bestanden en URLs te analyseren en hun gedrag in een gecontroleerde omgeving te bestuderen. * **Virustotal:** Een multi-engine malware analyseplatform voor bestanden, URL's, IP's en domeinen. Het aggregeert resultaten van antivirusengines, sandboxes, reputatiesystemen en threat-intel feeds. Het biedt statische en dynamische analyse, gedragslogboeken, metadata en grafische weergaven van relaties, en wordt gebruikt voor malware triage, incident response en threat-intel verrijking. * **Tria.ge:** Een cloudgebaseerd malware-analyse- en sandboxplatform. Het voert samples (bestanden, URL's, payloads) uit in geïsoleerde omgevingen om hun gedrag te observeren en gedetailleerde rapporten te genereren over procesactiviteit, netwerkverkeer, injecties, persistentie en IOC's. Het ondersteunt diverse besturingssystemen en mobiele omgevingen. ### 2.4 IP- en Netwerkinlichtingenplatforms Deze tools richten zich op het verzamelen en analyseren van gegevens over IP-adressen, netwerkactiviteit en de bredere internetinfrastructuur. * **GreyNoise:** Een internetbrede ruisinlichtingenplatform dat massascans en achtergrondverkeer bijhoudt. Het classificeert IP-adressen op basis van hun gedrag en intentie om onderscheid te maken tussen legitieme scanners en daadwerkelijke bedreigingen. Het vermindert alertmoeheid door commodity-ruis te filteren en biedt IP-reputatie, tagging en context. * **AbuseIPDB:** Een community-gedreven IP-dreigingsdatabase die informatie deelt over malafide IP-adressen. Het verzamelt rapporten over spam, hacking, DDoS, brute-force-aanvallen, malwareverspreiding en ander misbruik. Gebruikers kunnen IP-reputatie en historische misbruiksactiviteit opzoeken en de data integreren via een API voor geautomatiseerde blokkering en monitoring. * **SPUR:** Een high-fidelity IP-intelligentie- en data-feedplatform dat grootschalige, up-to-date gegevens levert over IP-adressen, proxies, VPN's en geanonimiseerd/residentieel verkeer. Het volgt miljoenen actieve anonieme IP's en honderden VPN/proxy-services, en biedt gedetailleerde attributen per IP, inclusief geolocation, ASN, proxy/VPN-status en verbindingsinformatie. * **Mnemonic PDNS (Passive DNS):** Een dienst die historische en real-time DNS-gegevens verzamelt en analyseert om threat hunting en incident response te ondersteunen. Het verzamelt passief DNS-queries en -responsen, en archiveert deze data. Dit maakt het mogelijk om de levenscyclus van een domein te volgen, infrastructuurwisselingen te identificeren en domeinen te correleren die dezelfde C2-IP delen. ### 2.5 Ransomware en Spam Monitoring Tools Deze tools zijn specifiek ontworpen om de activiteiten van ransomware-groepen en de verspreiding van ongewenste e-mails te volgen. * **Ransomware.live:** Een open-source, real-time threat intelligence platform dat wereldwijde ransomware-activiteiten volgt. Het monitort continu Dark Web data leak sites (DLS) van dreigingsactoren. Het onderhoudt een zoekbare repository van slachtoffers en ransomwaregroepen, en aggregeert data over ransomclaims, ontdekkingsdatums en aanvalsdata. * **Ransomlook.io:** Een threat intelligence resource die zich richt op het monitoren van de gevolgen van ransomware-aanvallen, voornamelijk via het Telegram-platform. Het monitort DLS van ransomwaregroepen om nieuwe slachtoffers en activiteiten te volgen. Het biedt gedetailleerde profielen van ransomwaregroepen en heeft een API voor integratie met beveiligingstools. * **The Spamhaus Project:** Een internationale, non-profit organisatie die zich richt op het bestrijden van e-mailspam en gerelateerde cyberdreigingen. Het is een van de meest gebruikte bronnen van anti-spam-intelligentie wereldwijd. Spamhaus compileert en distribueert meerdere real-time DNS-gebaseerde Blocklists (DNSBLs) om ongewenste en malafide e-mails te filteren. * **Abuse.ch:** Een non-profit organisatie die malware en botnets bestrijdt door gratis, community-gedreven cyberdreigingsinformatie te verstrekken. Het beheert een reeks platforms zoals URLhaus (malicieuze URL's), MalwareBazaar (malware samples) en ThreatFox (Indicators of Compromise/IOC's). ### 2.6 URL- en DNS-analyse Tools Deze tools helpen bij het analyseren van verdachte URL's en het controleren van DNS-gerelateerde informatie. * **URLhaus:** Een project van abuse.ch dat zich toelegt op het delen van informatie over malafide URL's die actief worden gebruikt voor de verspreiding van malware. Het verzamelt en volgt URL's die malware payloads hosten. De verzamelde data wordt gedeeld met beveiligingsproducten en diensten zoals Google Safe Browsing. * **DNS Checker:** Een online hulpprogramma dat gratis, real-time DNS-lookup en propagatiecontroles uitvoert vanuit meerdere geografische locaties wereldwijd. Het controleert DNS-records (A, CNAME, MX, TXT, NS, etc.) voor een gespecificeerd domein en is essentieel voor het controleren van DNS-wijzigingen. * **DNSTwister:** Een open-source tool die malafide domeinen ontdekt die legitieme websites imiteren door middel van typfouten of visuele gelijkenissen. Het genereert een lijst met lookalike domeinvariaties en controleert of deze geregistreerd zijn en actieve DNS-records hebben. ### 2.7 Certificaat- en Domeinmonitoring Tools Deze tools bieden inzicht in de uitgifte en het gebruik van SSL/TLS-certificaten, wat cruciaal is voor het detecteren van phishing en andere vormen van misleiding. * **Certstream:** Een real-time intelligentie-feed die nieuw uitgegeven SSL/TLS-certificaten van het Certificate Transparency (CT) log-netwerk aggregeert en streamt. Het stelt beveiligingsteams in staat om proactief nieuwe bedreigingen te detecteren, zoals verdachte domeinen die worden gebruikt voor phishing. * **Phishing catcher:** Een Proof of Concept (PoC)-script dat potentiële phishing-domeinen in bijna real-time identificeert door de CertStream-feed te monitoren op nieuw uitgegeven TLS/SSL-certificaten. Het gebruikt een scoringssysteem op basis van trefwoorden en TLD's in de domeinnaam. * **crt.sh:** Een gratis, doorzoekbare webinterface en database die gegevens aggregeert uit het Certificate Transparency (CT) log-netwerk. Het stelt gebruikers in staat de uitgifte van SSL/TLS-certificaten wereldwijd te bevragen en te auditen, wat essentieel is voor externe attack-surface management (EASM) en phishingdetectie. ### 2.8 Overige Belangrijke Tools en Diensten * **Cyberchef:** Vaak de "Cyber Swiss Army Knife" genoemd, is dit een krachtige, webgebaseerde tool voor datamanipulatie en -analyse. Het biedt een uitgebreide bibliotheek van meer dan 300 operaties voor codering, decodering, encryptie, hashing, compressie en diverse dataformaatconversies. Het is onmisbaar voor het de-obfusceren van kwaadaardige code en het extraheren van IOC's. * **Malpedia:** Een collaboratieve, open-access platform dat dient als een uitgebreide kennisbank en gecureerde corpus voor malware-analyse en -onderzoek. Het biedt gedetailleerde profielen van duizenden malwarefamilies en bijbehorende dreigingsactoren, inclusief technische beschrijvingen en historische tijdlijnen. * **Hashlookup:** Een gratis, open-source project dat wordt gebruikt in digital forensics en incident response (DFIR) om bekende bestanden efficiënt te identificeren door hun cryptografische hashes te controleren tegen enorme openbare databases, zoals de NIST National Software Reference Library (NSRL). * **Wayback Machine:** Een digitaal archief van het World Wide Web gemaakt door de Internet Archive. Het bewaart de geschiedenis van het internet door periodieke snapshots van websites te maken, waardoor gebruikers websites kunnen bekijken zoals ze in het verleden verschenen. Dit is nuttig voor cybersecurity forensics om malafide pagina's te bekijken nadat ze zijn verwijderd. * **Browserling:** Een cloudgebaseerde service voor cross-browser compatibiliteitstesten. Het stelt gebruikers in staat hun website in verschillende browsers en besturingssystemen te testen, wat kan worden gebruikt om verdachte links veilig te bezoeken, aangezien de browsesessies geïsoleerd zijn in hun sandbox. * **DNS over HTTPS (DoH):** Een protocol dat DNS-resolutie uitvoert over HTTPS, waardoor DNS-queries en -responsen worden versleuteld. Dit voorkomt afluisteren, manipulatie en tracking van DNS-verzoeken, wat de privacy verhoogt en DNS-spoofing tegengaat. * **Cloudflare RADAR:** Een real-time internetverkeersinzichten en threat intelligence platform van Cloudflare. Het volgt wereldwijde internettrends, verkeerspatronen en beveiligingsevents, en monitort DDoS-aanvallen, botactiviteit en opkomende bedreigingen. * **Tranco List:** Een onderzoeksgerichte, gerangschikte lijst van de meest populaire websites op internet. Het biedt een stabiel en reproduceerbaar alternatief voor commerciële site-ranglijsten voor academisch en beveiligingsonderzoek. * **Lookyloo:** Een open-source cybersecurity tool voor het onderzoeken en ontleden van websites. Het legt een webpagina vast, simuleert een gebruikersbezoek en visualiseert de boom van domeinen die met elkaar interageren tijdens het capture-proces. Het is nuttig voor het identificeren van malafide activiteit. * **BGPranking - CIRCL:** Een open-source beveiligingsinlichtingenproject dat een beveiligingsrisicoscore berekent voor Autonomous System Numbers (ASNs) op basis van de malafide activiteit die ze huisvesten. Het verzamelt data van diverse blocklists om "slechte buurten" van netwerken te identificeren. * **Silent Push:** Een proactief cyberdreigingsinformatieplatform dat zich richt op het identificeren en volgen van malafide infrastructuur voordat deze wordt gebruikt in een aanval. Het modelleert hoe dreigingsactoren hun infrastructuur opbouwen om aanvalspatronen te detecteren vóórdat ze worden ingezet. Deze platforms en tools vormen samen een cruciaal ecosysteem voor het begrijpen en bestrijden van moderne cyberdreigingen. Door hun gecombineerde functionaliteiten kunnen beveiligingsprofessionals een proactieve en geïnformeerde houding aannemen tegenover de steeds evoluerende dreigingslandschap. --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | YARA | YARA is een tool die wordt gebruikt om bestanden en netwerkverkeer te identificeren op basis van tekstuele of binaire patronen. Het maakt gebruik van signaturen, vergelijkbaar met oudere antivirusprogramma's, en wordt omschreven als 'grep op steroïden'. | | Regel (YARA) | Een YARA-regel bestaat uit een set strings en condities die de logica van de detectie bepalen. Deze regels helpen bij het identificeren van specifieke patronen die wijzen op de aanwezigheid van malware of andere verdachte activiteiten. | | Meta (YARA) | Het meta-gedeelte van een YARA-regel bevat contextuele informatie zoals de auteur, aanmaakdatum, versie, referentie naar samples, een beschrijving van het doel van de regel en eventuele deelrestricties (TLPCode). | | Strings (YARA) | Dit zijn de detecteerbare patronen binnen een YARA-regel, die zowel tekstueel als hexadecimaal kunnen zijn. Modifiers zoals Fullword, Wide, Nocase en Wide ascii kunnen worden gebruikt om de zoekopties te verfijnen. | | Conditie (YARA) | Het conditiegedeelte definieert de logische voorwaarden waaraan voldaan moet worden om een match te genereren. Dit kan variëren van het aantal voorkomende strings tot specifieke bytepatronen en file headers. | | Mutexes | Een uniek identificatieobject dat vaak door malwarefamilies wordt gebruikt. Het controleren op de aanwezigheid van een mutex kan aangeven of een apparaat al is geïnfecteerd. | | Gebruikersagenten | Rare en ongebruikelijke gebruikersagenten in netwerkverkeer kunnen indicaties geven van Command and Control (C2) communicatie van malware. | | Register Sleutels | Register sleutels kunnen worden gebruikt als persistentie-mechanismen door malware, waardoor deze na een herstart van het systeem opnieuw kan worden uitgevoerd. | | PDB Pad | PDB (Program Database) paden kunnen debugging-informatie bevatten die achterblijft in gecompileerde bestanden en nuttig kan zijn voor analyse. | | Hex Strings | Hexadecimale weergave van binaire data. In YARA kunnen hex strings wildcards (??) en specificaties voor bereiken van bytes gebruiken om flexibeler te zoeken. | | Urlscan.io | Een online scanner voor URL's en websites die analyses uitvoert op fetches, DOM, netwerkverkeer en redirects om malafide indicatoren en phishinggedrag te identificeren. | | Censys.io | Een internet-brede scan- en zoekmachine voor hosts, services en certificaten die open poorten, protocollen, softwareversies en misconfiguraties blootlegt. | | Shodan.io | Een zoekmachine voor internet-verbonden apparaten en services die banners indexeert om blootstellingen, misconfiguraties, kwetsbaarheden en open services te onthullen. | | Hunter.how | Een gespecialiseerde, webgebaseerde zoekmachine voor het in kaart brengen, fingerprinten en analyseren van de externe aanvalsoppervlakte van een organisatie voor beveiligingsdoeleinden. | | FOFA | FOFA (Footprint Finder) is een cyberspace-zoekmachine die actief internet-facing apparaten en digitale activa wereldwijd scant, in kaart brengt en verzamelt voor beveiligingsonderzoekers. | | Virustotal | Een multi-engine malware-analyseplatform voor bestanden, URL's, IP's en domeinen dat resultaten aggregeert van antivirus engines, sandboxes, reputatiesystemen en threat-intel feeds. | | Tria.ge | Een cloudgebaseerd platform voor malware-analyse en sandboxing dat samples uitvoert in geïsoleerde omgevingen om gedrag te observeren en gedetailleerde rapporten te produceren. | | Greynoise | Een internet-breed ruis-intelligentieplatform dat massale scans en achtergrondverkeer volgt en IP-adressen classificeert op basis van gedrag en intentie. | | AbuseIPDB | Een gemeenschapsgestuurde IP-dreigingsdatabase die informatie bijhoudt en deelt over malafide IP-adressen die worden gerapporteerd voor spam, hacking, DDoS en andere misbruiken. | | DNS-over-HTTPS (DoH) | Een protocol dat DNS-resolutie uitvoert via HTTPS, waardoor DNS-query's en -antwoorden worden versleuteld om luisteren, manipulatie en ISP-tracking te voorkomen. | | Cloudflare RADAR | Een real-time internetverkeerinzichten en threat intelligence platform van Cloudflare dat wereldwijde internettrends, verkeerspatronen en beveiligingsevenementen volgt. | | Tranco List | Een onderzoeksgerichte, gerangschikte lijst van de meest populaire websites op het internet, bedoeld als een stabiel en reproduceerbaar alternatief voor commerciële site-ranglijsten. | | SPUR | Een high-fidelity IP-intelligentie- en data-feedsplatform dat grootschalige, up-to-date gegevens levert over IP-adressen, proxies, VPN's en geanonimiseerd/residentieel verkeer. | | Lookyloo | Een open-source cybersecuritytool voor het onderzoeken en ontleden van websites door een webpage vast te leggen en de onderlinge domeinrelaties te visualiseren. | | Cyberchef | Een krachtige, webgebaseerde tool, ook wel de 'Cyber Swiss Army Knife' genoemd, voor data-manipulatie en -analyse met meer dan 300 operaties voor codering, decodering, encryptie en hashing. | | Ransomware.live | Een open-source, real-time threat intelligence platform dat wereldwijde ransomware-activiteiten volgt door informatie te schrapen van dreigingsactoren, met name hun dark web dataleksites. | | Ransomlook.io | Een specifieke threat intelligence bron die zich richt op het monitoren van de nasleep van ransomware-aanvallen, met name door het volgen van dark web leak sites. | | Spamhaus | Een internationale, non-profit organisatie die zich toelegt op het bestrijden van e-mailspam en gerelateerde cyberdreigingen door middel van real-time blocklists (DNSBL's). | | Abuse.ch | Een non-profit organisatie die zich toelegt op het bestrijden van malware en botnets door het verstrekken van gratis, gemeenschapsgestuurde cyberdreigingsinformatie via een ecosysteem van platforms. | | Threatfox | Een gespecialiseerd, open-source platform van abuse.ch dat zich toelegt op het in realtime delen van Indicators of Compromise (IOC's) met betrekking tot malware en botnets. | | URLhaus | Een project van abuse.ch dat zich toelegt op het delen van intelligentie over malafide URL's die actief worden gebruikt voor de distributie van malware. | | MalwareBazaar | Een gratis, gemeenschapsgestuurd platform van abuse.ch dat is toegewijd aan de uitwisseling en verrijking van geverifieerde malware-samples. | | YARAify | Het dedicated YARA-regel scan- en jachtplatform van het abuse.ch project, gericht op het helpen van de beveiligingsgemeenschap bij het classificeren en volgen van malware. | | Hunting.Abuse.ch | De gecentraliseerde zoekinterface voor de diverse, onderling verbonden threat intelligence platforms die door het abuse.ch project worden beheerd, gericht op het bestrijden van malware en botnets. | | Hashlookup | Een gratis, open-source project en service die voornamelijk wordt gebruikt in digital forensics en incident response (DFIR) om bekende bestanden efficiënt te identificeren door hun cryptografische hashes te vergelijken met enorme publieke databases. | | Waybackmachine | Een digitaal archief van het World Wide Web, gemaakt door de Internet Archive, dat periodieke snapshots van websites bewaart om de geschiedenis van het internet te bewaren. | | Browserling | Een cloudgebaseerde service ontworpen om webontwikkelaars en kwaliteitsborgingsprofessionals te helpen bij het efficiënt en betaalbaar uitvoeren van cross-browser compatibiliteitstests. | | DNS checker | Een populaire online utility die gratis, real-time DNS-lookup- en propagatiecontroles biedt vanaf meerdere geografische locaties wereldwijd. | | DNSTwister | Een geavanceerd, open-source hulpprogramma ontworpen om proactief malafide domeinen te ontdekken die legitieme websites imiteren, voornamelijk door typfouten of visuele gelijkenissen uit te buiten. | | Mnemonic - PDNS | Mnemonic PDNS (Passive DNS) is een service die historische en real-time DNS-gegevens verzamelt en analyseert om te helpen bij threat hunting en incident response. | | CERTSTREAM | Een real-time intelligentie-feed die nieuw uitgegeven SSL/TLS-certificaten aggregeert en streamt van het Certificate Transparency (CT) lognetwerk om beveiligingsteams in staat te stellen nieuwe dreigingen proactief te detecteren. | | Phishing catcher | Een tool gebouwd voor real-time beveiligingsmonitoring door gebruik te maken van publiek beschikbare certificaatgegevens om potentiële phishing-domeinen te identificeren. | | Crt.sh | Een gratis, publiekelijk doorzoekbare webinterface en database die gegevens aggregeert uit het Certificate Transparency (CT) lognetwerk, waardoor gebruikers de uitgifte van SSL/TLS-certificaten wereldwijd kunnen bevragen en auditen. | | BGPranking - CIRCL | Een open-source beveiligingsintelligentieproject ontwikkeld door CIRCL dat een beveiligingsrisicoscore voor Autonomous System Numbers (ASN's) berekent op basis van de malafide activiteit die zij hosten. | | Malpedia | Een collaboratief, open-toegangsplatform dat fungeert als een uitgebreide kennisbank en gecureerde corpus voor malware-analyse en -onderzoek, met gedetailleerde profielen van malwarefamilies en bedreigingsactoren. | | Silent push | Een proactief cyberdreigingsintelligentieplatform dat zich richt op het proactief identificeren en volgen van malafide infrastructuur voordat deze in een aanval wordt gebruikt, met behulp van 'Indicators of Future Attack' (IOFA™). |

# Concept en typen firewalls Een firewall fungeert als een digitale verdedigingslinie die inkomend en uitgaand netwerkverkeer reguleert op basis van vooraf gedefinieerde beveiligingsregels. ## 1. Concept en typen firewalls ### 1.1 Wat is een firewall? Een firewall is een netwerkbeveiligingssysteem dat is ontworpen om inkomend en uitgaand netwerkverkeer te monitoren en te controleren op basis van vooraf bepaalde beveiligingsregels. Het functioneert als een barrière tussen een vertrouwd intern netwerk en een onbetrouwbaar extern netwerk, zoals het internet. De oorspronkelijke betekenis van het woord "firewall" verwees naar een muur die was bedoeld om een brand in een gebouw te beperken [3](#page=3). ### 1.2 Firewalling op verschillende lagen Firewalls kunnen opereren op verschillende lagen van het OSI-model: * **Lagen 1-7:** Het OSI-model bestaat uit zeven lagen: Fysiek, Datalink, Netwerk, Transport, Sessie, Presentatie en Applicatie [5](#page=5). * **Netwerkfirewalls:** Deze opereren typisch op de netwerklaag (laag 3) en/of de transportlaag (laag 4) [5](#page=5). * **Applicatiefirewalls:** Deze opereren op de applicatielaag (laag 7) [5](#page=5). ### 1.3 Typen firewalls Firewalls kunnen worden geclassificeerd op basis van hun locatie (netwerk- of hostgebaseerd) en de lagen waarop ze opereren (netwerk- of applicatiefirewalls). #### 1.3.1 Netwerkgebaseerde firewalls Netwerkgebaseerde firewalls bevinden zich op gateways die meerdere hosts bedienen. Ze inspecteren pakketten die moeten worden doorgestuurd. Deze kunnen worden geïmplementeerd als dedicated hardware of als software op algemene hardware [7](#page=7). * **Voorbeelden:** * **Dedicated hardware:** Cisco, Netgate [7](#page=7). * **Software:** netfilter/iptables, pfSense [7](#page=7). #### 1.3.2 Hostgebaseerde firewalls Hostgebaseerde firewalls worden op een enkele computer geïnstalleerd. Ze inspecteren zowel inkomende als uitgaande pakketten. Ze functioneren vaak als een daemon of service op het besturingssysteem [7](#page=7). * **Voorbeelden:** * netfilter/iptables, Windows Defender Firewall [7](#page=7). #### 1.3.3 Applicatiefirewalls Applicatiefirewalls, ook wel bekend als next-generation firewalls (NGFW), zijn specifiek ontworpen om verkeer op applicatieniveau te inspecteren. Ze kunnen diepgaande inhoudsinspectie uitvoeren, zoals het controleren op virussen of exploits [6](#page=6). * **Netwerkgebaseerde applicatiefirewalls:** * Bevinden zich op gateways voor meerdere hosts, vaak als (reverse) proxy [6](#page=6). * Specifiek voor bepaalde applicatieprotocollen en voeren inhoudsinspectie uit [6](#page=6). * **Voorbeelden:** Web Application Firewall (WAF), ModSecurity (Modsec), Cloudflare’s Cloud WAF [6](#page=6). * **Hostgebaseerde applicatiefirewalls:** * Bevinden zich op een enkele host [6](#page=6). * Bieden sandboxing voor meerdere applicaties [6](#page=6). * Nieuwere generaties maken vaak gebruik van Mandatory Access Control (MAC) [6](#page=6). * **Voorbeelden:** AppArmor, SELinux [6](#page=6). ### 1.4 Samenwerking van firewalls Een applicatiefirewall werkt complementair aan een netwerkfirewall. De netwerkfirewall dient vaak als de eerste verdedigingslinie. Veel netwerkfirewalls zijn al ingebouwd in het besturingssysteem [8](#page=8). --- # Netfilter, iptables en nftables Dit deel van de cursus behandelt de ingebouwde netwerkfirewalls van Linux, Netfilter, en de gebruikersapplicaties iptables en het modernere nftables [9](#page=9). ### 2.1 Netfilter: de kernel-subsystemen Netfilter is de firewall-subsystemen in de Linux-kernel dat pakketfiltering, NAT en andere pakketmanipulaties mogelijk maakt. Het is sinds kernelversie 2.4 aanwezig in Linux en werd destijds geïnitieerd door Paul “Rusty” Russell [10](#page=10) [11](#page=11) [12](#page=12). Netfilter werkt met tabellen, chains en regels [13](#page=13): * **Tabellen**: Groeperen gerelateerde functionaliteiten. * **Chains**: Sequenties van regels binnen een tabel. * **Regels**: De fundamentele configuratie-items die criteria bevatten om verkeer te matchen en acties uit te voeren op het gematchte verkeer [13](#page=13). #### 2.1.1 Packet filtering hooks en chains Netfilter heeft vijf packet filtering "hooks" in de netwerkstack van de Linux-kernel, die corresponderen met vijf iptables chains [14](#page=14): 1. **PREROUTING**: Verwerkt pakketten zodra ze binnenkomen [14](#page=14). 2. **INPUT**: Verwerkt pakketten die bestemd zijn voor lokale sockets [14](#page=14). 3. **FORWARD**: Verwerkt pakketten die via het systeem worden gerouteerd [14](#page=14). 4. **OUTPUT**: Verwerkt pakketten die lokaal worden gegenereerd [14](#page=14). 5. **POSTROUTING**: Verwerkt pakketten vlak voordat ze het systeem verlaten [14](#page=14). Deze chains zijn visueel weergegeven in een vereenvoudigd schema [15](#page=15). #### 2.1.2 Netfilter tabellen Er zijn vijf hoofdtabellen in Netfilter [16](#page=16): 1. **filter**: De standaardtabel voor packet filtering [16](#page=16). 2. **nat**: Wordt geraadpleegd wanneer een pakket een nieuwe verbinding creëert, voornamelijk voor Network Address Translation [16](#page=16). 3. **mangle**: Een speciale tabel voor packet-aanpassingen [16](#page=16). 4. **raw**: Heeft de hoogste prioriteit en wordt gebruikt voor uitzonderingen in connection tracking [16](#page=16). 5. **security**: Gebruikt voor mandatory access control netwerkregels, zoals SECMARK en CONNSECMARK targets, voor SELinux en andere beveiligingsmodules [16](#page=16). Het is belangrijk om onderscheid te maken tussen tabel- en chainnamen; tabelnamen zijn doorgaans in kleine letters (bv. `filter`), terwijl chainnamen in hoofdletters staan (bv. `INPUT`). Een gedetailleerd overzicht van het packet-flow door deze componenten is beschikbaar [18](#page=18) [19](#page=19). ### 2.2 iptables: de klassieke gebruikerstool `iptables` is de traditionele command-line tool voor het beheren van de Netfilter-firewall [22](#page=22). #### 2.2.1 Huidige regels bekijken Men kan de huidige regels van specifieke tabellen of de standaard `filter` tabel bekijken met de volgende commando's [23](#page=23): * `iptables -t -L`: Toon alle regels van een specifieke tabel [23](#page=23). * `iptables -L`: Toon alle regels van de standaard `filter` tabel [23](#page=23). #### 2.2.2 Default policies De `policy` van een chain bepaalt de actie die wordt uitgevoerd op pakketten die niet door een regel in die chain worden gematcht. Standaard is deze vaak ingesteld op `ACCEPT`. Het wijzigen van de default policy, bijvoorbeeld naar `DROP` voor de `FORWARD` chain, is een veelvoorkomende beveiligingsmaatregel [24](#page=24). #### 2.2.3 Firewall regels toevoegen Regels kunnen worden toegevoegd aan chains [25](#page=25): * **Append (`-A`)**: Voegt een regel toe aan het einde van een chain [25](#page=25). * **Insert (`-I`)**: Voegt een regel in op een specifieke positie in een chain [25](#page=25). #### 2.2.4 Targets Targets definiëren de actie die wordt uitgevoerd op een gematcht pakket [26](#page=26): * **LOG**: Logt het pakket [26](#page=26). * **ACCEPT**: Staat het pakket toe [26](#page=26). * **REJECT**: Wijst het pakket af en stuurt een foutmelding terug [26](#page=26). * **DROP**: Negeert het pakket zonder melding terug te sturen [26](#page=26). #### 2.2.5 Regel criteria Regels kunnen specifieke criteria bevatten om pakketten te matchen [27](#page=27): * **Source (`-s` of `--source`)**: Bronadres [27](#page=27). * **Destination (`-d` of `--destination`)**: Bestemmingsadres [27](#page=27). * **Protocol (`-p` of `--protocol`)**: Protocol (bv. `icmp`, `tcp`) [27](#page=27). * **Module opties**: Extra criteria kunnen worden toegevoegd met behulp van modules (zie `man iptables-extensions`) [27](#page=27). Een voorbeeld van een regel die ICMP ping requests met een lengte tussen 200 en 1500 bytes dropt, is: `iptables -A INPUT -s 192.168.111.100 -p icmp -m length --length 200:1500 -j DROP` [27](#page=27). #### 2.2.6 Firewall regels verwijderen Regels kunnen op verschillende manieren worden verwijderd [28](#page=28): * **Regelnummer tonen**: `iptables -L --line-numbers` [28](#page=28). * **Specifieke regel verwijderen**: `iptables -D ` [28](#page=28). * **Alle regels in een chain verwijderen**: `iptables -F ` [28](#page=28). * **Alle regels in alle chains van de filtertabel verwijderen**: `iptables -F` [28](#page=28). > **Tip:** Wees uiterst voorzichtig bij het configureren van `iptables` regels, vooral via SSH. Een verkeerd commando kan leiden tot permanente uitsluiting totdat het fysiek wordt opgelost [29](#page=29). ### 2.3 nftables: de modernere opvolger `nftables` is een nieuwe kernel-subsystem (`nf_tables`) die de Netfilter-infrastructuur hergebruikt, maar een nieuwe gebruikersruimte tool (`nft`) en syntaxis introduceert. Het is geïntegreerd in de Linux-kernel sinds versie 3.13 [31](#page=31). #### 2.3.1 Vergelijking met iptables `nftables` biedt diverse voordelen ten opzichte van `iptables` [33](#page=33): * **Efficiëntie**: Snellere packet classificatie [33](#page=33). * **Flexibiliteit**: Betere ondersteuning voor dynamische ruleset updates [33](#page=33). * **Uniformiteit**: Eén tool voor alle address families (IPv4, IPv6, ARP) [33](#page=33). * **Vereenvoudiging**: Vervangt meerdere tools (`iptables`, `ip6tables`, `arptables`, `ebtables`) [33](#page=33). * **Nieuwe features**: Zoals de `inet` familie voor dual-stack IPv4/IPv6 beheer [33](#page=33). #### 2.3.2 ‘iptables’ op moderne distributies Op recentere distributies, zoals RHEL 8 en Debian 11, gebruikt de `iptables` command-line tool vaak al de `nf_tables` backend. Op Debian wordt de `nft` command standaard gebruikt in plaats van `iptables` [34](#page=34) [35](#page=35). #### 2.3.3 nftables: tabellen In `nftables` specificeer je voor een tabel de address family [36](#page=36): * `ip`: Correspondeert met `iptables` (IPv4) [36](#page=36). * `ip6`: Correspondeert met `ip6tables` (IPv6) [36](#page=36). * `inet`: Combineert IPv4 en IPv6, waarvoor men voorheen zowel `iptables` als `ip6tables` moest gebruiken [36](#page=36). * `arp`: Correspondeert met `arptables` [36](#page=36). * `bridge`: Correspondeert met `ebtables` [36](#page=36). * `netdev`: Gebruikt de nieuwe `ingress` hook [36](#page=36). `nftables` maakt het mogelijk om willekeurig veel custom tabellen te definiëren, in tegenstelling tot de 5 vooraf gedefinieerde tabellen in `xtables`. Een voorbeeld commando is: `nft add table inet mytable` [36](#page=36). #### 2.3.4 nftables: chains Chains in `nftables` kunnen twee types hebben [37](#page=37): * **Base chain**: Haakt in op de netwerkstack en vereist `type`, `hook` en `priority` parameters [37](#page=37) [44](#page=44). * **Regular chain**: Voor betere organisatie van regels [37](#page=37). Het `type` van een chain bepaalt de functionaliteit [38](#page=38): * **filter**: Standaard packet filtering [38](#page=38). * **nat**: Voor Network Address Translation [38](#page=38). * **route**: Voor nieuwe route lookups als pakketten zijn gewijzigd [38](#page=38). De `hook` specificeert het stadium in de packetverwerking waar de chain ingrijpt [39](#page=39): * `ingress`: Nieuw, voor zeer vroege filtering [39](#page=39) [40](#page=40) [41](#page=41). * `prerouting`: Vlak na binnenkomst [39](#page=39). * `input`: Voor lokaal bestemde pakketten [39](#page=39). * `forward`: Voor gerouteerde pakketten [39](#page=39). * `output`: Voor lokaal gegenereerde pakketten [39](#page=39). * `postrouting`: Vlak voor het verlaten van het systeem [39](#page=39). De `priority` parameter bepaalt de volgorde waarin chains met dezelfde hook worden doorlopen, waarbij lagere waarden voorrang hebben. Standaard prioriteitsnamen zijn beschikbaar die overeenkomen met de volgorde van de `xtables` tabellen: "raw" < "mangle" < "dstnat" < "filter" < "security" < "srcnat" [42](#page=42). #### 2.3.5 nftables: regels Regels in `nftables` bestaan uit uitdrukkingen (expressions) en statements [43](#page=43): * **Expressions**: Bepalen wat gematcht moet worden [43](#page=43). * **Statements**: Definiëren de uit te voeren actie [43](#page=43). Een voorbeeld van een regel die echo-request ICMP pakketten dropt: `nft add rule inet mytable mychain icmp type echo-request drop` [43](#page=43) [46](#page=46). #### 2.3.6 nftables syntaxis De `nft` tool biedt commando's voor het beheren van tabellen, chains en regels [44](#page=44): * **Tabellen**: * `nft list tables []` * `nft list table [] [-n [-a]` * `nft (add | delete | flush) table [] ` [44](#page=44). * **Chains**: * `nft (add | create) chain [] [ { type hook priority \; [policy \;] } ]` * `nft (delete | list | flush) chain [] ` [44](#page=44). * **Regels**: * `nft add rule [] ` * `nft insert rule [] [position ] ` * `nft replace rule [] [handle ] ` * `nft delete rule [] [handle ]` [44](#page=44). #### 2.3.7 nftables configuratie en service Regelsets kunnen automatisch worden geladen via een `nftables.service` systemd unit. De configuratie wordt meestal opgeslagen in een `nftables.conf` bestand, respectievelijk in `/etc/nftables.conf` op Debian en `/etc/sysconfig/nftables.conf` op RHEL [45](#page=45). Een demonstratie van `nft` commando's op Debian is gegeven [46](#page=46). --- # Beheerhulpmiddelen en geavanceerde configuratie Dit onderwerp verkent verschillende methoden en tools voor het beheren van Linux-firewalls, van hogere abstracties zoals firewalld en TCP wrappers tot systemd IP-toegangslijsten. ### 3.1 Netfilter management tools Linux-gebaseerde distributies beschikken doorgaans over een `iptables`/`nftables` pakket. Daarnaast kunnen er specifieke tools zijn voor het configureren van de regels, zoals `firewall-cmd` op RHEL of `ufw` op Ubuntu [48](#page=48). #### 3.1.1 Firewalld Firewalld is een dynamische firewall daemon met een gebruikersinterface. Het maakt gebruik van het concept van 'zones' om vertrouwensniveaus per interface of verbinding te definiëren [49](#page=49). * **Daemon/service:** `firewalld` [49](#page=49). * **Gebruiker CLI tool:** `firewall-cmd` [49](#page=49). * **Gebruiker GUI tool:** `firewall-config` [49](#page=49). **Concept van zones:** Een zone vertegenwoordigt een vertrouwensniveau en kan worden toegepast per interface of verbinding [49](#page=49). * **Voorbeeld:** Alle verbindingen op de interface `ens33` kunnen tot de 'public' zone behoren, terwijl verbindingen vanaf `192.168.11.1` tot de 'internal' zone kunnen behoren [49](#page=49). **Veelgebruikte `firewall-cmd` commando's:** * `firewall-cmd --get-active-zones`: Geeft de actieve zones weer [50](#page=50). * `firewall-cmd --list-all-zones`: Toont alle gedefinieerde zones en hun configuratie [50](#page=50). * `firewall-cmd --info-zone=public`: Toont gedetailleerde informatie over een specifieke zone, zoals 'public' [50](#page=50). * `firewall-cmd --info-service=ssh`: Toont informatie over een specifieke service, zoals SSH [50](#page=50). * `firewall-cmd --permanent --zone=public --add-service=ssh`: Voegt de SSH-service permanent toe aan de 'public' zone [50](#page=50). * `firewall-cmd --permanent --zone=public --remove-service=ssh`: Verwijdert de SSH-service permanent uit de 'public' zone [50](#page=50). * `firewall-cmd --reload`: Herlaadt de firewall-regels na permanente wijzigingen [50](#page=50). ##### 3.1.1.1 Firewalld en extra `nft` regels In RHEL kunnen basis `nft` regels worden gevonden in bestanden zoals `main.nft`, `router.nft`, en `nat.nft` binnen `/etc/nftables/`. Deze kunnen worden ingeschakeld en aangepast bovenop de `firewalld` regelset, en worden uitgevoerd na de `firewalld` regels via een prioriteitsinstelling [51](#page=51). > **Tip:** Het is mogelijk om netfilter te configureren via `iptables`, `nftables`, of `firewalld` [53](#page=53). ### 3.2 TCP wrappers TCP wrappers zijn een methode voor het monitoren en controleren van netwerkactiviteit van daemons die gelinkt zijn aan `libwrap.so` of deze statisch geïmplementeerd hebben. Dit is een host-gebaseerde firewalling op applicatielaag [55](#page=55). * **Verificatie:** U kunt controleren of een daemon gebruikmaakt van `libwrap.so` met het `ldd` commando [55](#page=55). * **Voordeel:** Runtime herconfiguratie van toegangscontrole, waardoor daemons niet opnieuw geladen hoeven te worden [55](#page=55). * **Configuratiebestanden:** TCP wrappers gebruiken de bestanden `/etc/hosts.allow` en `/etc/hosts.deny` [55](#page=55). * **Status:** TCP wrappers worden niet meer onderhouden en worden als verouderd beschouwd [55](#page=55). #### 3.2.1 `hosts.allow` en `hosts.deny` Als een bestand niet bestaat, wordt het als leeg beschouwd. De toegangscontrole software raadpleegt beide bestanden; de zoekactie stopt bij de eerste overeenkomst [57](#page=57): 1. Toegang wordt verleend als een `(daemon:client)` paar overeenkomt met een vermelding in `/etc/hosts.allow` [57](#page=57). 2. Anders wordt toegang geweigerd als een `(daemon:client)` paar overeenkomt met een vermelding in `/etc/hosts.deny` [57](#page=57). 3. Anders wordt toegang verleend [57](#page=57). * `/etc/hosts.allow`: Specificeert expliciet welke hosts mogen netwerken met een bepaalde daemon [57](#page=57). * `/etc/hosts.deny`: Specificeert expliciet welke hosts niet mogen netwerken met een bepaalde daemon [57](#page=57). * Raadpleeg `man hosts_access` voor meer details [57](#page=57). #### 3.2.2 `iptables` versus `hosts.deny` * `iptables` werkt op kernelniveau en filtert op basis van pakketheaders [58](#page=58). * `hosts.deny` opereert op applicatie/procesniveau [58](#page=58). * **Verschil:** `iptables` kan bijvoorbeeld op poort 22 blokkeren, terwijl `hosts.deny` blokkeert op basis van de daemon `sshd` [58](#page=58). * Als `sshd` een andere poort gebruikt, is de `iptables` configuratie belangrijk [58](#page=58). * `iptables` blokkeert pakketten echter veel eerder in het proces [58](#page=58). #### 3.2.3 Log-gebaseerde intrusion detection systems (IDS) * **DenyHosts:** Analyseert SSH-logs en voegt hosts toe aan `/etc/hosts.deny` [59](#page=59). * **Fail2ban:** Is niet beperkt tot SSH-logs. Het kan hosts toevoegen aan `/etc/hosts.deny` en ook `iptables` of `pfSense`/`OPNsense` regels wijzigen [59](#page=59). ### 3.3 Systemd IP-toegangslijsten Als een daemon wordt gedefinieerd binnen een `systemd` service unit configuratiebestand, is het mogelijk om IP-toegangslijsten direct in dat configuratiebestand te definiëren [61](#page=61). **Configuratie:** Deze lijsten worden ingesteld met de directives `IPAddressAllow` en `IPAddressDeny` binnen het `[Service]` sectie van een `systemd` unit-bestand [61](#page=61). * **Voorbeeld uit een service-bestand:** ```ini [Unit Description=Exciting webapp [Service WorkingDirectory=/opt/exciting-webapp ExecStart=/usr/bin/python3 -m http.server Restart=always IPAddressAllow=192.168.11.0/24 IPAddressDeny=any [Install WantedBy=multi-user.target ``` Dit voorbeeld staat verkeer toe van het `192.168.11.0/24` netwerk en weigert al het andere verkeer ("any") [61](#page=61). #### 3.3.1 `IPAddressDeny` & `IPAddressAllow` De beslissingslogica voor toegangscontrole is als volgt [62](#page=62): 1. Toegang wordt verleend als een adres overeenkomt met een vermelding in `IPAddressAllow` [62](#page=62). 2. Anders wordt toegang geweigerd als een adres overeenkomt met een vermelding in `IPAddressDeny` [62](#page=62). 3. Anders wordt toegang verleend [62](#page=62). * Het sleutelwoord 'any' kan worden gebruikt in plaats van de `*` wildcard [62](#page=62). * `IPAddressDeny`: Al het verkeer van en naar dit IP-adres/netwerk wordt geweigerd voor de processen van de service [62](#page=62). * `IPAddressAllow`: Al het verkeer dat overeenkomt met dit IP-adres/netwerk wordt toegestaan [62](#page=62). * Verdere details zijn te vinden in `man systemd.resource-control` [62](#page=62). #### 3.3.2 Overzicht van daemon configuratiebestanden Verschillende methoden voor daemon configuratie en netwerkbeheer kunnen naast elkaar bestaan en interageren: * **Daemons:** `sshd`, `httpd`, etc. [56](#page=56) [63](#page=63). * **TCP Wrappers:** Gebruikt `/etc/hosts.allow` en `/etc/hosts.deny` [56](#page=56) [63](#page=63). * **Netfilter:** Geconfigureerd via `/etc/nftables.conf` (of `iptables` equivalenten) [56](#page=56) [63](#page=63). * **Systemd:** Maakt gebruik van service unit bestanden in `/etc/systemd/system/*.service` en `/lib/systemd/system/*.service` voor IP-toegangslijsten [63](#page=63). * **Applicaties:** Zoals `cockpit` en netwerk services [56](#page=56) [63](#page=63). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

Glossary

| Term | Definition | |------|------------| | Firewall | Een netwerkbeveiligingssysteem dat inkomend en uitgaand netwerkverkeer monitort en controleert op basis van vooraf bepaalde beveiligingsregels, fungerend als een barrière tussen een vertrouwd intern netwerk en een onvertrouwd extern netwerk zoals het internet. | | OSI-model | Een conceptueel model dat de communicatiefuncties van een telecommunicatie- of computersysteem beschrijft, verdeeld in zeven abstractielagen: Fysiek, Datalink, Netwerk, Transport, Sessie, Presentatie en Applicatie. | | Netwerkfirewall | Een firewall die het verkeer tussen twee of meer netwerken inspecteert en controleert, meestal geïmplementeerd op gateways tussen netwerken of op individuele hosts om inkomende en uitgaande pakketten te inspecteren. | | Applicatiefirewall | Een firewall die specifieke applicatieprotocollen inspecteert en controleert, vaak door middel van inhoudinspectie (zoals virus- of exploitdetectie), en kan op netwerkgateways of op individuele hosts worden geplaatst. | | Netfilter | De kerncomponent van de Linux-firewall die packet filtering, netwerkadresvertaling (NAT) en packet manipulatie mogelijk maakt door middel van hooks in de netwerkstack van de kernel. | | iptables | Een gebruikerstoepassing die communiceert met Netfilter om firewallregels te configureren en te beheren, bestaande uit tabellen, ketens en individuele regels die verkeer matchen en acties uitvoeren. | | nftables | Een modernere, flexibelere en krachtigere opvolger van iptables, die een nieuwe syntaxis introduceert en de verschillende packet filtering tools (iptables, ip6tables, arptables, ebtables) consolideert onder één enkele backend genaamd nf_tables. | | Tabellen (iptables/nftables) | Verzamelingen van regels in de Netfilter-architectuur die specifiek zijn ontworpen voor bepaalde functies, zoals het filteren van pakketten (`filter`), netwerkadresvertaling (`nat`), of pakketmanipulatie (`mangle`). | | Ketens (iptables/nftables) | Geordende lijsten van regels binnen een specifieke tabel die de paden definiëren waarlangs pakketten worden verwerkt, met standaardketens zoals `INPUT`, `OUTPUT`, `FORWARD`, `PREROUTING`, en `POSTROUTING`. | | Regels (iptables/nftables) | De fundamentele configuratie-items in Netfilter die criteria bevatten om specifiek netwerkverkeer te matchen en een bijbehorende actie (target) uit te voeren, zoals `ACCEPT`, `DROP`, `REJECT` of `LOG`. | | Targets (iptables/nftables) | De acties die worden uitgevoerd op verkeer dat overeenkomt met een firewallregel, zoals het toestaan (`ACCEPT`), weggooien (`DROP`), afwijzen (`REJECT`) of loggen (`LOG`) van het pakket. | | Hooks (Netfilter) | Specifieke punten in de netwerkstack van de Linux-kernel waar Netfilter packet filtering kan toepassen; deze hooks komen overeen met de verschillende ketens die worden gebruikt in `iptables` en `nftables`. | | Statefull packet filtering | Een methode van firewalling die rekening houdt met de status van netwerkverbindingen om beslissingen te nemen over het toestaan of weigeren van verkeer, waardoor alleen de verkeersstroom die deel uitmaakt van een actieve, legitieme verbinding wordt toegestaan. | | firewalld | Een dynamisch firewallbeheerhulpprogramma voor Linux dat zones gebruikt om verschillende vertrouwensniveaus toe te wijzen aan netwerkinterfaces en verbindingen, waardoor een flexibele en gebruiksvriendelijke configuratie van firewallregels mogelijk is. | | Zones (firewalld) | Concepten binnen firewalld die een vertrouwensniveau vertegenwoordigen dat wordt toegewezen aan netwerkinterfaces of verbindingen, waarbij verschillende regels van toepassing kunnen zijn afhankelijk van de zone waartoe een verkeerspakket behoort. | | TCP wrappers | Een verouderde methode voor hostgebaseerde toegangscontrole die het verkeer naar netwerkservices regelt door middel van de bestanden `/etc/hosts.allow` en `/etc/hosts.deny`, gebaseerd op de daemon en het client IP-adres. | | systemd IP access lists | Een mechanisme binnen systemd service-eenheden waarmee IP-adressen of netwerken expliciet kunnen worden toegestaan (`IPAddressAllow`) of geweigerd (`IPAddressDeny`) voor de processen die door die specifieke service worden beheerd. |

注册阅读 了解更多

Cover

LSS - Lecture IV - Linux firewalling.pdf

词汇表摘要

Summary

# Introductie tot firewalls en hun functionaliteit Dit gedeelte introduceert het concept van een firewall, de oorsprong van de term en de functie ervan in netwerkbeveiliging, en legt de basis voor de latere discussie over specifieke firewalltechnologieën en hun plaats in het OSI-model [3](#page=3). ### 1.1 Wat is een firewall? Een firewall is een netwerkbeveiligingssysteem dat inkomend en uitgaand netwerkverkeer controleert en regelt op basis van vooraf bepaalde beveiligingsregels. De term "firewall" vindt zijn oorsprong in een muur die oorspronkelijk bedoeld was om een brand in aangrenzende gebouwen te beperken. In netwerkbeveiliging functioneert een firewall als een barrière tussen een vertrouwd intern netwerk en een onvertrouwd extern netwerk, zoals het internet [3](#page=3). ### 1.2 Firewalling op verschillende lagen van het OSI-model Firewalls kunnen opereren op verschillende lagen van het Open Systems Interconnection (OSI) model. Het OSI-model bestaat uit zeven lagen: Fysiek (Layer 1), Datalink (Layer 2), Netwerk (Layer 3), Transport (Layer 4), Sessie (Layer 5), Presentatie (Layer 6) en Applicatie (Layer 7) [5](#page=5). #### 1.2.1 Netwerkfirewalls Netwerkfirewalls opereren voornamelijk op de netwerk- en transportlagen van het OSI-model. Ze inspecteren netwerkpakketten op basis van informatie zoals IP-adressen en poortnummers [5](#page=5) [7](#page=7). * **Netwerkgebaseerde netwerkfirewalls** bevinden zich op gateways voor meerdere hosts en inspecteren de pakketten die zij moeten doorsturen. Ze kunnen bestaan uit speciale hardware of software op algemene hardware. Voorbeelden hiervan zijn Cisco, Netgate, netfilter/iptables, pfSense [7](#page=7). * **Hostgebaseerde netwerkfirewalls** bevinden zich op een enkele host en inspecteren zowel inkomende als uitgaande pakketten. Ze draaien vaak als een daemon of service. Voorbeelden zijn netfilter/iptables en Windows Defender Firewall [7](#page=7). #### 1.2.2 Applicatiefirewalls Applicatiefirewalls, ook wel bekend als next-generation firewalls (NGFW), opereren op hogere lagen van het OSI-model, met name de applicatielaag. Ze voeren inspectie uit van de inhoud van de data, voorbij de basispakketinformatie die netwerkfirewalls gebruiken [5](#page=5) [6](#page=6). * **Netwerkgebaseerde applicatiefirewalls** bevinden zich op gateways voor meerdere hosts en fungeren vaak als een (reverse) proxy. Ze zijn specifiek voor bepaalde applicatieprotocollen en voeren contentinspectie uit, bijvoorbeeld op virussen of exploits. Voorbeelden zijn Web Application Firewalls (WAF), ModSecurity (Modsec) en Cloudflare's Cloud WAF [6](#page=6). * **Hostgebaseerde applicatiefirewalls** draaien op een enkele host en bieden sandboxing voor meerdere applicaties. Next-generation firewalls maken hierbij vaak gebruik van Mandatory Access Control (MAC). Voorbeelden zijn AppArmor en SELinux [6](#page=6). ### 1.3 Samenwerking tussen firewalls Een applicatiefirewall werkt complementair aan een netwerkfirewall. De netwerkfirewall wordt vaak beschouwd als de eerste verdedigingslinie en is vaak ingebouwd in het besturingssysteem. Dit gelaagde beveiligingsmodel biedt een meer robuuste bescherming door verschillende aspecten van het netwerkverkeer op verschillende niveaus te inspecteren en te controleren [8](#page=8). --- # Netfilter en iptables in Linux Dit deel van de studiehandleiding behandelt Netfilter, de ingebouwde netwerkfirewall van Linux, en de bijbehorende gebruikersruimte-tool iptables. We duiken dieper in de architectuur van Netfilter, inclusief tabellen, chains en hooks, en demonstreren hoe iptables wordt gebruikt voor het configureren van regels [9](#page=9). ### 2.1 Introductie tot Netfilter Netfilter is een stateful packet-filtering firewall die sinds kernelversie 2.4 deel uitmaakt van de Linux kernel. Het werd ontwikkeld door Paul “Rusty” Russell en is een fundamenteel onderdeel van de netwerkbeveiliging in Linux. De oorspronkelijke documentatie beschrijft de ontwikkeling als een "grote strijd en heldhaftige daden" met als doel "de derde leeftijd van Linux firewalling" in te luiden [12](#page=12). Netfilter is meer dan alleen iptables; het is een framework dat op verschillende niveaus kan worden benaderd. Naast iptables zijn er ook andere gebruikersruimte-tools zoals `nft / nftables`, `xtables`, en oudere tools zoals `ip6tables`, `arptables`, en `ebtables` die specifiek waren voor IPv6, ARP en Ethernet-frames [10](#page=10). > **Tip:** Onthoud dat Netfilter een kernelcomponent is, terwijl iptables een gebruikersruimte-tool is om deze te configureren. ### 2.2 Architectuur van Netfilter De kern van Netfilter bestaat uit tabellen, chains en regels [13](#page=13). #### 2.2.1 Tabellen Netfilter organiseert zijn functionaliteit in verschillende tabellen, elk met een specifiek doel: * **filter**: Dit is de standaardtabel en wordt gebruikt voor algemene pakketfiltering [16](#page=16). * **nat**: Deze tabel wordt geraadpleegd wanneer een pakket wordt aangetroffen dat een nieuwe verbinding creëert, en wordt gebruikt voor Netwerkadresvertaling (NAT) [16](#page=16). * **mangle**: Een speciale tabel die kan worden gebruikt voor het aanpassen van pakketten [16](#page=16). * **raw**: Dit is de tabel met de hoogste prioriteit en wordt aangeroepen vóór alle andere tabellen. Het wordt voornamelijk gebruikt voor uitzonderingen in connection tracking [16](#page=16). * **security**: Deze tabel wordt gebruikt voor verplichte toegangscontrole netwerkregels (Mandatory Access Control), zoals die ingeschakeld door `SECMARK` en `CONNSECMARK` targets [16](#page=16). Tabelnamen worden in kleine letters geschreven [18](#page=18). #### 2.2.2 Chains Binnen elke tabel bevinden zich chains, die fungeren als logische groepen van regels. Netfilter heeft vijf belangrijke "hooks" in de netwerkstack van de Linux kernel, die corresponderen met vijf iptables chains [14](#page=14): 1. **PREROUTING**: Voor pakketten zodra ze binnenkomen in het netwerkapparaat [14](#page=14). 2. **INPUT**: Voor pakketten die bestemd zijn voor lokale sockets op de machine zelf [14](#page=14). 3. **FORWARD**: Voor pakketten die via de machine worden gerouteerd naar een andere bestemming [14](#page=14). 4. **OUTPUT**: Voor pakketten die lokaal worden gegenereerd door processen op de machine [14](#page=14). 5. **POSTROUTING**: Voor pakketten vlak voordat ze het systeem verlaten, na routingbeslissingen [14](#page=14). Chains worden in hoofdletters geschreven [18](#page=18). > **Tip:** De `PREROUTING` en `POSTROUTING` chains worden gebruikt voor pakketten die door de machine worden gerouteerd (niet bestemd voor de machine zelf), terwijl `INPUT` en `OUTPUT` worden gebruikt voor verkeer dat de lokale machine betreft. De `FORWARD` chain is specifiek voor pakketten die worden doorgestuurd [15](#page=15). #### 2.2.3 Hooks en Packet Flow De packet filtering "hooks" zijn de punten in de Linux kernel netwerkstack waar Netfilter pakketten kan inspecteren en manipuleren. Een gedetailleerd overzicht van de packet flow toont hoe pakketten door de verschillende tabellen en chains gaan, afhankelijk van hun oorsprong en bestemming [14](#page=14) [19](#page=19). > **Example:** Een inkomend pakket dat bestemd is voor de lokale machine zal de `PREROUTING` hook passeren, vervolgens de `filter` tabel doorlopen (indien van toepassing) en uiteindelijk de `INPUT` chain bereiken. Een pakket dat lokaal wordt gegenereerd, doorloopt de `OUTPUT` chain en kan daarna de `POSTROUTING` chain passeren voordat het het netwerk verlaat [19](#page=19). ### 2.3 De iptables Tool `iptables` is de gebruikersruimte-applicatie die wordt gebruikt om de regels in de Netfilter kernelmodules te configureren [10](#page=10). #### 2.3.1 Huidige regels bekijken Om de momenteel geconfigureerde regels te bekijken, gebruikt men de `iptables -L` commando. Optioneel kan men met de `-t` vlag een specifieke tabel specificeren, bijvoorbeeld `iptables -t raw -L` om de regels in de `raw` tabel te tonen. Standaard toont `iptables -L` de regels van de `filter` tabel [23](#page=23). > **Example:** > ```bash > sudo iptables -L > ``` > Dit commando toont de chains `INPUT`, `FORWARD` en `OUTPUT` met hun standaard policies en eventuele regels [23](#page=23). #### 2.3.2 Standaard Policies (Default Policy) Elke chain heeft een standaard policy die bepaalt wat er met pakketten gebeurt die niet door een specifieke regel worden gematcht. Veelvoorkomende policies zijn `ACCEPT` (doorgelaten) en `DROP` (stilletjes genegeerd) [24](#page=24). > **Tip:** Het is een goede beveiligingspraktijk om de default policy van de `FORWARD` en `INPUT` chains in te stellen op `DROP` en alleen expliciet benodigde verkeer toe te staan [24](#page=24). > **Example:** > ```bash > sudo iptables -P FORWARD DROP > ``` > Dit commando stelt de standaard policy van de `FORWARD` chain in op `DROP`, wat betekent dat al het verkeer dat bedoeld is om te worden doorgestuurd, standaard wordt geweigerd [24](#page=24). #### 2.3.3 Firewallregels toevoegen Regels kunnen worden toegevoegd aan chains met de `-A` (append) of `-I` (insert) opties [25](#page=25). * **Append (`-A`)**: Voegt een regel toe aan het einde van een chain [25](#page=25). > **Example:** `iptables -A FORWARD -j LOG` voegt een regel toe aan het einde van de `FORWARD` chain die al het verkeer logt [25](#page=25). * **Insert (`-I`)**: Voegt een regel in op een specifieke positie binnen een chain [25](#page=25). > **Example:** `iptables -I FORWARD 3 -j LOG` voegt een regel toe als de derde regel in de `FORWARD` chain [25](#page=25). #### 2.3.4 Targets Een target bepaalt de actie die wordt uitgevoerd op een pakket dat aan de regels voldoet. Veelgebruikte targets zijn [26](#page=26): * **ACCEPT**: Sta het pakket toe [26](#page=26). * **DROP**: Negeer het pakket stilzwijgend [26](#page=26). * **REJECT**: Sta het pakket niet toe en stuur een foutmelding terug naar de afzender [26](#page=26). * **LOG**: Log het pakket voor analyse, maar laat het daarna doorgaan naar het volgende target [26](#page=26). #### 2.3.5 Regelcriteria Regels specificeren criteria waaraan een pakket moet voldoen om gematcht te worden. Belangrijke criteria zijn [27](#page=27): * `-s` of `--source`: Bronadres of netwerk [27](#page=27). * `-d` of `--destination`: Bestemmingsadres of netwerk [27](#page=27). * `-p` of `--protocol`: Het protocol (bv. `tcp`, `udp`, `icmp`) [27](#page=27). Daarnaast kunnen modules worden gebruikt voor meer gedetailleerde matching. Raadpleeg `man iptables` en `man iptables-extensions` voor een volledig overzicht [27](#page=27). > **Example:** > ```bash > iptables -A INPUT -s 192.168.1.0/24 -p icmp -j ACCEPT > ``` > Deze regel staat ICMP-verkeer toe vanaf het netwerk `192.168.1.0/24` naar de `INPUT` chain [27](#page=27). > **Example met module:** > ```bash > iptables -A INPUT -s 192.168.111.100 -p icmp -m length --length 200:1500 -j DROP > ``` > Deze regel dropt ICMP-pakketten van het adres `192.168.111.100` met een lengte tussen 200 en 1500 bytes, die de `INPUT` chain bereiken [27](#page=27). #### 2.3.6 Firewallregels verwijderen Het verwijderen van regels is een kritiek onderdeel van het beheer van de firewall [28](#page=28). * **Regelnummers weergeven**: Gebruik `iptables -L --line-numbers` om regels met hun nummers te zien [28](#page=28). * **Specifieke regel verwijderen**: Gebruik de `-D` (delete) optie met het chain- en regelnummer [28](#page=28). > **Example:** `iptables -D FORWARD 3` verwijdert de derde regel uit de `FORWARD` chain [28](#page=28). * **Alle regels in een chain verwijderen**: Gebruik de `-F` (flush) optie [28](#page=28). > **Example:** `iptables -F FORWARD` verwijdert alle regels uit de `FORWARD` chain [28](#page=28). * **Alle regels in alle chains van een tabel verwijderen**: Gebruik de `-F` optie zonder chain specificatie voor de standaard (filter) tabel [28](#page=28). > **Example:** `iptables -F` verwijdert alle regels uit alle chains van de `filter` tabel [28](#page=28). #### 2.3.7 Waarschuwingen Wees extreem voorzichtig bij het configureren van iptables, vooral via SSH. Een verkeerde commando kan ervoor zorgen dat u permanent buitengesloten wordt totdat de machine fysiek wordt benaderd [29](#page=29). > **Warning:** Configureer altijd eerst de regels die toegang verlenen tot de server (bijvoorbeeld SSH-toegang) voordat u andere regels instelt die mogelijk de toegang kunnen blokkeren. Test wijzigingen grondig en houd een fallback-methode beschikbaar [29](#page=29). --- # Nieuwere firewalltechnologie: nftables Dit gedeelte introduceert nftables als de opvolger van iptables, met een focus op de nieuwe kernel-backend (nf_tables) en de bijbehorende gebruikersruimte-tool nft, waarbij de voordelen, verschillen en syntax worden besproken [30](#page=30). ### 3.1 Introductie tot nftables Nftables is de moderne opvolger van iptables en maakt gebruik van de nieuwe kernel-backend `nf_tables`, wat staat voor Netfilter. Het hergebruikt de bestaande hook-infrastructuur van Netfilter, de zogenaamde "chains". Nftables is beschikbaar in de Linux kernel vanaf versie 3.13 en wordt beheerd door de `nft` gebruikersruimte-tool. Een significant verschil is de introductie van een nieuwe, meer compacte syntax. Hoewel de nieuwe syntax de voorkeur heeft, kan de oude iptables-syntax nog steeds worden gebruikt en wordt deze vertaald naar de `nf_tables` backend [31](#page=31). ### 3.2 Voordelen van nftables ten opzichte van iptables Nftables biedt verschillende verbeteringen ten opzichte van iptables: * **Verbeterde prestaties**: Sneller pakketclassificatie wordt mogelijk gemaakt [33](#page=33). * **Betere ondersteuning voor dynamische regelaanpassingen**: Het bijwerken van regelsets is efficiënter [33](#page=33). * **Uniforme syntax**: Adres, protocol en extensiespecifieke inconsistenties van iptables worden aangepakt, wat leidt tot een nettere en compactere syntax [33](#page=33). * **Universele tool**: Met `nft` kunnen alle adresfamilies (IPv4, IPv6, ARP, etc.) worden beheerd, wat de afzonderlijke tools zoals `iptables`, `ip6tables` en `arptables` vervangt [33](#page=33). * **Vereenvoudigd dual-stack beheer**: De nieuwe `inet` familie maakt het beheer van zowel IPv4 als IPv6 gemakkelijker [33](#page=33). ### 3.3 Nftables in distributies Vanaf Red Hat Enterprise Linux (RHEL) 8 gebruikt het `iptables`-commando de `nf_tables` backend, wat betekent dat de oude iptables-syntax wordt vertaald naar de nieuwe nftables-backend. Dit is te controleren met commando's als `which iptables` en `realpath USD(which iptables)` [34](#page=34). In Debian 11 is het `iptables`-commando niet langer standaard geïnstalleerd. De `nft`-commando is de voorgeschreven methode voor firewallbeheer [35](#page=35). > **Tip:** Controleer welke firewall-backend uw systeem gebruikt, vooral bij het migreren van oudere configuraties. Op moderne systemen is de kans groot dat `iptables` een alias is voor de `nftables` backend. ### 3.4 Nftables syntax: tabellen, chains en regels De configuratie in nftables is gestructureerd rond tabellen, chains en regels. #### 3.4.1 Tabellen (tables) Een tabel specificeert de adresfamilie waarvoor de regels gelden. De veelvoorkomende families zijn [36](#page=36): * `ip`: voor IPv4. Komt overeen met het oude `iptables` [36](#page=36). * `ip6`: voor IPv6. Komt overeen met het oude `ip6tables` [36](#page=36). * `inet`: voor zowel IPv4 als IPv6. Dit is een nieuwe familie die het beheer van dual-stack vereenvoudigt [33](#page=33) [36](#page=36). * `arp`: voor ARP-pakketten. Komt overeen met het oude `arptables` [36](#page=36). * `bridge`: voor bridge-filtering. Komt overeen met `ebtables` [36](#page=36). * `netdev`: maakt gebruik van de nieuwe `ingress`-hook [36](#page=36). Als er geen familie wordt gespecificeerd, is de standaardfamilie `ip` [36](#page=36). **Voorbeeld:** Een tabel aanmaken met de `inet` familie: `nft add table inet mytable` [36](#page=36). #### 3.4.2 Chains Chains zijn collecties van regels. Er zijn twee types [37](#page=37): * **Base chain**: Deze wordt gekoppeld aan de netwerkstack via hooks en heeft parameters als `type`, `hook` en `priority` [37](#page=37). * **Regular chain**: Deze worden voornamelijk gebruikt voor een betere organisatie van regels [37](#page=37). **Parameters van Base Chains:** * **Type**: Definieert het doel van de chain. Veelvoorkomende types zijn `filter` (standaard packet filtering), `nat` (voor Network Address Translation) en `route` (voor route lookup) [38](#page=38). * `filter`: Kan gebruikt worden met alle families en hooks [38](#page=38). * `nat`: Kan gebruikt worden met `ip`, `ip6` en `inet` families voor specifieke hooks [38](#page=38). * `route`: Kan gebruikt worden met `ip` en `ip6` families voor de `output` hook [38](#page=38). * **Hook**: Specificeert in welke fase van de pakketverwerking de chain actief wordt. De hooks zijn [39](#page=39): * `ingress`: Een nieuwe hook die beschikbaar is sinds kernel 4.2 via `nf_tables`, waarmee pakketten al zeer vroeg in de netwerkstack kunnen worden gefilterd. Dit biedt een vroeg detectiepunt voor verkeer [40](#page=40). * `prerouting`: Verwerking voor de routeringsbeslissing [39](#page=39). * `input`: Pakketten bestemd voor de lokale machine [39](#page=39). * `forward`: Pakketten die door de machine heen gerouteerd worden [39](#page=39). * `output`: Pakketten die door de machine zelf worden gegenereerd [39](#page=39). * `postrouting`: Verwerking na de routeringsbeslissing [39](#page=39). > **Tip:** De `ingress`-hook is krachtig omdat het alle verkeer voor een NIC ziet, zonder aannames over L2/L3 protocollen, wat zeer vroege filtering mogelijk maakt [40](#page=40). * **Priority**: Een integerwaarde die de volgorde van chains op dezelfde hook bepaalt. Lagere prioriteitswaarden hebben voorrang. Standaard prioriteitsnamen, die de volgorde aangeven, zijn: `raw` < `mangle` < `dstnat` < `filter` < `security` < `srcnat` [42](#page=42). **Voorbeeld:** Een base chain aanmaken: `nft add chain inet mytable mychain { type filter hook input priority filter \; policy accept \; }` [37](#page=37). #### 3.4.3 Regels (rules) Regels worden opgebouwd uit twee componenten: expressies en statements [43](#page=43). * **Expressies**: Bepalen wat er gematcht moet worden [43](#page=43). * **Statements**: Definiëren de actie die ondernomen moet worden bij een match [43](#page=43). **Voorbeeld van een regel:** `nft add rule inet mytable mychain tcp dport {80, 443} ct state new,established counter accept`. Deze regel accepteert TCP-verkeer naar poorten 80 en 443, telt het verkeer mee (`counter`) en markeert het als nieuw of gevestigd (`ct state new,established`) [43](#page=43). ### 3.5 Commando's en beheer De `nft` tool biedt een reeks commando's voor het beheren van tabellen, chains en regels [44](#page=44). * **Tabellen:** * `nft list tables []`: Toon tabellen [44](#page=44). * `nft list table [] [-n [-a]`: Toon specifieke tabel [44](#page=44). * `nft (add | delete | flush) table [] `: Voeg toe, verwijder of wis een tabel [44](#page=44). * **Chains:** * `nft (add | create) chain []

[ { type hook priority \; [policy \;] } ]`: Voeg een chain toe met specificaties [44](#page=44). * `nft (delete | list | flush) chain [] `: Verwijder, toon of wis een chain [44](#page=44). * **Regels:** * `nft add rule [] `: Voeg een regel toe [44](#page=44). * `nft insert rule [] [position ] `: Voeg een regel in op een specifieke positie [44](#page=44). * `nft replace rule [] [handle ] `: Vervang een regel [44](#page=44). * `nft delete rule [] [handle ]`: Verwijder een regel [44](#page=44). > **Tip:** Raadpleeg `man nft` voor een gedetailleerd overzicht van alle expressies en statements voor verschillende protocollen [43](#page=43) [44](#page=44). ### 3.6 Opslaan en laden van regels De regels kunnen automatisch worden geladen via een `nftables.service` systemd unit. De regels worden opgeslagen in een configuratiebestand [45](#page=45): * Debian: `/etc/nftables.conf` [45](#page=45). * RHEL: `/etc/sysconfig/nftables.conf` [45](#page=45). ### 3.7 Demo met nft commando's Hieronder volgt een reeks commando's om de functionaliteit van `nft` te demonstreren op een Debian-achtig systeem [46](#page=46): 1. Een tabel aanmaken: `sudo nft add table inet demo` [46](#page=46). 2. Alle tabellen tonen: `sudo nft list tables` [46](#page=46). 3. De specifieke tabel tonen: `sudo nft list table inet demo` [46](#page=46). 4. Een chain aanmaken binnen de tabel: `sudo nft add chain inet demo test { type filter hook input priority filter \; policy accept \; }` [46](#page=46). 5. Een regel toevoegen om ICMP echo-request pakketten te droppen: `sudo nft add rule inet demo test icmp type echo-request drop` [46](#page=46). 6. De chain leegmaken: `sudo nft flush chain inet demo test` [46](#page=46). 7. De chain verwijderen: `sudo nft delete chain inet demo test` [46](#page=46). 8. De tabel verwijderen: `sudo nft delete table inet demo` [46](#page=46). --- # Hogere-niveau firewallbeheertools en beveiligingsmechanismen Dit gedeelte behandelt geavanceerde tools en mechanismen voor firewallbeheer, waaronder command-line utilities, zone-concepten, oudere beveiligingsmethoden zoals TCP wrappers, en modernere, log-gebaseerde systemen voor inbraakdetectie. ### 4.1 Firewall-beheertools bovenop iptables/nftables Veel Linux-distributies bieden naast `iptables` of `nftables` ook eigen, meer gebruiksvriendelijke tools voor het configureren van firewallregels. Voorbeelden hiervan zijn `firewall-cmd` op Red Hat Enterprise Linux (RHEL) en `ufw` (Uncomplicated Firewall) op Ubuntu [48](#page=48). #### 4.1.1 firewalld `firewalld` is een dynamisch firewallbeheersysteem dat werkt met het concept van 'zones' [49](#page=49). * **Daemon/service:** `firewalld` [49](#page=49). * **Gebruikers CLI tool:** `firewall-cmd` [49](#page=49). * **Gebruikers GUI tool:** `firewall-config` [49](#page=49). **Zones** Zones vertegenwoordigen een vertrouwensniveau en kunnen worden toegewezen aan specifieke netwerkinterfaces of verbindingen. Bijvoorbeeld, alle verkeer via de `ens33` interface kan tot de `public` zone behoren, terwijl verkeer van `192.168.11.1` tot de `internal` zone kan worden gerekend [49](#page=49). **Veelgebruikte `firewall-cmd` commando's:** * `firewall-cmd --get-active-zones`: Toont de zones die momenteel actief zijn [50](#page=50). * `firewall-cmd --list-all-zones`: Geeft een overzicht van alle geconfigureerde zones en hun instellingen [50](#page=50). * `firewall-cmd --info-zone=public`: Toont gedetailleerde informatie over een specifieke zone (hier: `public`) [50](#page=50). * `firewall-cmd --info-service=ssh`: Geeft informatie over een vooraf gedefinieerde service (hier: SSH) [50](#page=50). * `firewall-cmd --permanent --zone=public --add-service=ssh`: Voegt permanent de SSH-service toe aan de `public` zone [50](#page=50). * `firewall-cmd --permanent --zone=public --remove-service=ssh`: Verwijdert permanent de SSH-service uit de `public` zone [50](#page=50). * `firewall-cmd --reload`: Herlaadt de firewallconfiguratie om permanente wijzigingen actief te maken zonder de dienst te herstarten [50](#page=50). **Integratie met `nftables`** In RHEL-gebaseerde systemen kunnen basis `nftables` regels, zoals gedefinieerd in bestanden als `main.nft`, `router.nft`, en `nat.nft` in de `/etc/nftables/` map, worden gebruikt bovenop `firewalld` regels. Deze `nftables` regels worden, door middel van een prioriteitsverschuiving, uitgevoerd ná de `firewalld` regels [51](#page=51). > **Tip:** Het is belangrijk om te weten wanneer je `firewalld` of `nftables` direct moet configureren, afhankelijk van de complexiteit en specifieke eisen van de netwerkbeveiliging [52](#page=52). #### 4.1.2 ufw Hoewel `ufw` niet gedetailleerd wordt behandeld in de verstrekte documentatie, is het de standaard firewall-configuratietool voor Ubuntu en dient het een vergelijkbaar doel als `firewall-cmd`: het vereenvoudigen van het beheer van `netfilter` regels [48](#page=48). ### 4.2 TCP wrappers TCP wrappers zijn een oudere methode voor host-gebaseerde applicatielaag firewalling, ontworpen om de netwerkactiviteit van daemons die gekoppeld zijn aan `libwrap.so` te monitoren en te controleren [55](#page=55). * Je kunt controleren of een daemon `libwrap` gebruikt met het `ldd` commando [55](#page=55). * Het voordeel van TCP wrappers is de mogelijkheid om toegangscontrole tijdens runtime aan te passen, zonder dat daemon services opnieuw geladen hoeven te worden [55](#page=55). * TCP wrappers maken gebruik van de bestanden `/etc/hosts.allow` en `/etc/hosts.deny` [55](#page=55). * **Status:** TCP wrappers worden niet langer onderhouden en worden als verouderd beschouwd [55](#page=55). **Werking van `/etc/hosts.allow` en `/etc/hosts.deny`** De toegang wordt gecontroleerd door beide bestanden te raadplegen; de zoektocht stopt bij de eerste overeenkomst [57](#page=57). 1. Toegang wordt verleend als een `(daemon:client)` paar overeenkomt met een vermelding in `/etc/hosts.allow` [57](#page=57). 2. Anders wordt toegang geweigerd als een `(daemon:client)` paar overeenkomt met een vermelding in `/etc/hosts.deny` [57](#page=57). 3. Als er geen overeenkomst is in beide bestanden, wordt toegang verleend [57](#page=57). * `/etc/hosts.allow`: Specificeert expliciet welke hosts mogen netwerken met een bepaalde daemon [57](#page=57). * `/etc/hosts.deny`: Specificeert expliciet welke hosts niet mogen netwerken met een bepaalde daemon [57](#page=57). **Verschil met `iptables`** `iptables` werkt op kernelniveau en filtert pakketten op basis van packet headers. TCP wrappers daarentegen opereren op applicatie/proces niveau. Bijvoorbeeld, `iptables` kan poort 22 blokkeren, terwijl `hosts.deny` specifiek de `sshd` daemon kan blokkeren. Als `sshd` echter een andere poort gebruikt, moet de `iptables` configuratie hierop aangepast worden, hoewel `iptables` het pakket wel eerder blokkeert [58](#page=58). ### 4.3 Log-gebaseerde intrusion detection systemen (IDS) Systemen zoals DenyHosts en Fail2ban analyseren logbestanden om kwaadwillend gedrag te detecteren en vervolgens actie te ondernemen [59](#page=59). * **DenyHosts:** Analyseert SSH-logs en voegt de geïdentificeerde hosts toe aan `/etc/hosts.deny` [59](#page=59). * **Fail2ban:** Is niet beperkt tot SSH-logs en kan hosts toevoegen aan `/etc/hosts.deny`. Daarnaast kan het ook `iptables` regels of regels in andere firewallproducten zoals pfSense/OPNsense aanpassen [59](#page=59). ### 4.4 Systeemgebaseerde IP-toegangslijsten in systemd-service-units Voor daemons die binnen een `systemd` service unit configuratiebestand worden beheerd, is het mogelijk om IP-toegangslijsten direct in dat configuratiebestand te definiëren. Dit biedt een geïntegreerde manier om de toegang voor specifieke services te beheren [61](#page=61). **Configuratie in `systemd` unit files:** Binnen een `.service` bestand kunnen de volgende directieven worden gebruikt: * `IPAddressAllow`: Specificeert welke IP-adressen of netwerken toegang wordt verleend [62](#page=62). * `IPAddressDeny`: Specificeert welke IP-adressen of netwerken toegang wordt geweigerd [62](#page=62). **Beslissingsproces voor toegang:** 1. Toegang wordt verleend als een IP-adres overeenkomt met een vermelding in `IPAddressAllow` [62](#page=62). 2. Anders wordt toegang geweigerd als een IP-adres overeenkomt met een vermelding in `IPAddressDeny` [62](#page=62). 3. Als er geen overeenkomst is in beide lijsten, wordt toegang verleend [62](#page=62). > **Tip:** Het sleutelwoord `any` kan worden gebruikt om alle adressen te specificeren, in plaats van de wildcard `*` [62](#page=62). **Voorbeeld van een `systemd` service unit met IP-toegangslijsten:** ``` # /lib/systemd/system/exciting.service [Unit Description=Exciting webapp [Service WorkingDirectory=/opt/exciting-webapp ExecStart=/usr/bin/python3 -m http.server Restart=always IPAddressAllow=192.168.11.0/24 IPAddressDeny=any [Install WantedBy=multi-user.target ``` In dit voorbeeld wordt al het verkeer van het `192.168.11.0/24` netwerk toegestaan, terwijl al het andere verkeer wordt geweigerd [61](#page=61). De `systemd` service unit configuratiebestanden bevinden zich doorgaans in `/etc/systemd/system/` of `/lib/systemd/system/`. Dit mechanisme biedt een alternatief voor of aanvulling op de `TCP wrappers` en `nftables` configuratie voor specifieke daemons [63](#page=63). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

Glossary

| Term | Definition | |------|------------| | Firewall | Een netwerkbeveiligingssysteem dat inkomend en uitgaand netwerkverkeer monitort en controleert op basis van vooraf bepaalde beveiligingsregels, fungerend als een barrière tussen een betrouwbaar intern netwerk en een onbetrouwbaar extern netwerk zoals het internet. | | OSI-model | Een conceptueel referentiemodel dat de functies van een telecommunicatie- of informaticasysteem beschrijft in termen van abstractielagen. Het model definieert zeven lagen, die elk specifieke netwerkfuncties afhandelen, van fysieke verbindingen tot applicatiesoftware. | | Netfilter | Een framework binnen de Linux-kernel dat stateful packet filtering mogelijk maakt. Het biedt hooks in de netwerkstack waar firewallregels kunnen worden toegepast om verkeer te inspecteren en te manipuleren. | | iptables | Een gebruikersruimte-tool voor Linux die wordt gebruikt om regels te configureren voor het Netfilter-framework. Het stelt beheerders in staat om netwerkverkeer te filteren, te natten en te manipuleren door middel van tabellen, chains en regels. | | Nftables | Een moderne netwerkpakketfilteringsframework voor Linux dat is ontworpen als opvolger van iptables. Het biedt een flexibeler en efficiënter systeem voor het definiëren en beheren van firewallregels met een nieuwere syntax en ondersteuning voor meerdere adresfamilies. | | Tabel (firewall) | In Netfilter en nftables een verzameling van chains die betrekking hebben op specifieke functionaliteit, zoals het filteren van pakketten (filter), netwerkadresvertaling (nat) of het wijzigen van pakketten (mangle). | | Chain (firewall) | Een gesequenceerde lijst van regels binnen een firewalltabel. Pakketten worden geëvalueerd tegen de regels in een chain in de gedefinieerde volgorde. | | Hook (netfilter) | Specifieke punten in de netwerkstack van de Linux-kernel waar Netfilter-pakketverwerking kan ingrijpen. Voorbeelden zijn PREROUTING, INPUT, FORWARD, OUTPUT en POSTROUTING. | | NAT (Network Address Translation) | Een techniek die wordt gebruikt om IP-adressen te herschrijven wanneer pakketten tussen netwerken worden gerouteerd. Dit wordt vaak gebruikt om meerdere interne IP-adressen te mappen naar een enkel publiek IP-adres. | | Daemon | Een computerprogramma dat op de achtergrond draait en vaak wordt gebruikt om services te leveren aan andere programma"s of gebruikers. Veel daemons, zoals SSH of webservers, zijn doelwitten van firewallregels. | | TCP wrappers | Een ouder mechanisme voor toegangscontrole op hostniveau in Linux-systemen dat wordt gebruikt om te bepalen welke hosts verbinding mogen maken met specifieke netwerkdiensten (daemons) die gelinkt zijn aan de libwrap.so-bibliotheek. Het maakt gebruik van de bestanden /etc/hosts.allow en /etc/hosts.deny. | | systemd service unit | Configuratiebestanden voor systemd, het init-systeem dat in veel moderne Linux-distributies wordt gebruikt. Deze bestanden definiëren hoe services moeten worden beheerd, inclusief het instellen van IP-toegangslijsten (IPAddressAllow en IPAddressDeny) voor specifieke services. | | Intrusion Detection System (IDS) | Een beveiligingssysteem dat netwerkverkeer of systeemactiviteiten monitort op verdachte patronen die kunnen duiden op kwaadwillige activiteiten of beleidsbreuken. Loggebaseerde IDS"en analyseren logbestanden om dergelijke patronen te detecteren. |

注册阅读 了解更多

Cover

LSS - Lecture VIIIa - Linux logging.pdf

词汇表摘要

Summary

# Authenticatie- en sessielogbestanden Dit gedeelte behandelt de verschillende logbestanden die worden gebruikt voor het bijhouden van authenticatieactiviteiten van gebruikers, inclusief inlogpogingen, succesvolle en mislukte sessies, en de commando's om deze logboeken te benaderen [2](#page=2). ### 1.1 Authenticatie logbestanden Authenticatielogbestanden registreren de inlogactiviteiten van gebruikers. De locatie en het beheer van deze logboeken kunnen per distributie verschillen [3](#page=3). #### 1.1.1 Locaties van authenticatielogbestanden * **Debian & afgeleiden:** * `/var/log/auth.log`: Dit bestand werd gebruikt in oudere versies van Debian. Sinds Debian 12 wordt dit vervangen door `systemd-journald`. Het kan echter nog steeds aanwezig zijn als `rsyslog` is geïnstalleerd [3](#page=3). * **RHEL & afgeleiden:** * `/var/log/secure`: Dit bestand bevat authenticatiegerelateerde gebeurtenissen [3](#page=3). #### 1.1.2 Gebruiksscenario's voor authenticatielogboeken ##### 1.1.2.1 Logs van `sudo` authenticatie De `sudo` opdracht maakt gebruik van het `pam_unix` module in de authenticatiestack van zijn PAM configuratiebestand [14](#page=14). * **Verkeerd sudo wachtwoord:** Dit wordt gelogd en kan worden teruggevonden in de betreffende logbestanden [14](#page=14). * **Correct sudo wachtwoord:** Succesvolle authenticatie via `sudo` wordt ook geregistreerd [14](#page=14). * **Niet in `sudoers` bestand of `sudo`/`wheel` groep:** Wanneer een gebruiker probeert `sudo` te gebruiken zonder de juiste permissies, wordt dit gelogd met de melding "This incident will be reported". Deze gebeurtenissen worden geregistreerd in `systemd-journald` en/of `/var/log/secure` [16](#page=16). ##### 1.1.2.2 Logs van `su` authenticatie Het gebruik van de `su` opdracht om supergebruiker te worden, wordt vergelijkbaar met `sudo` gelogd. De `pam_unix` module wordt gebruikt in de sessiestack voor `su` [17](#page=17). * **Correct `su` gebruik:** Succesvolle overgang naar de root-sessie wordt gelogd. In tegenstelling tot `sudo`, wordt er nog geen "session closed" melding geregistreerd omdat de sessie als root actief blijft [17](#page=17). ##### 1.1.2.3 Logs van `ssh` authenticatie SSH-authenticatiepogingen, zowel mislukt als succesvol, worden geregistreerd [18](#page=18) [19](#page=19). * **Verkeerd SSH wachtwoord:** Mislukte SSH-inlogpogingen worden gelogd en bevatten vaak informatie over de externe host (IP-adres). De `pam_unix` module in de authenticatiestack voor `sshd` is hierbij betrokken [18](#page=18). * **Succesvolle SSH login/logout:** Succesvolle SSH-logins en -logouts worden ook gelogd, inclusief tijdstempels die sessietracering mogelijk maken. Tools zoals `last` en `lastb` kunnen worden gebruikt om deze informatie te analyseren [19](#page=19). ### 1.2 Login/sessielogbestanden Naast authenticatiegerelateerde gebeurtenissen, registreren login- en sessielogbestanden informatie over de aanmeldingen en sessies van gebruikers op het systeem [20](#page=20). #### 1.2.1 `/var/log/lastlog` * Dit logbestand bevat de meest recente inloggegevens van gebruikers [21](#page=21). * Het is standaard ingeschakeld op de meeste distributies [21](#page=21). * Het logboek is opgeslagen in een binair formaat [21](#page=21). * Om dit logboek te lezen, kunnen de commando's `lastlog` of `lslogins` worden gebruikt [21](#page=21). * **Opmerking:** De standaarduitvoer toont alleen gebruikers die in `/etc/passwd` staan. Verwijderde gebruikers en niet-lokale gebruikers (bijvoorbeeld via SSSD) worden niet standaard weergegeven, maar kunnen wel specifiek worden opgevraagd [21](#page=21). #### 1.2.2 `/var/log/btmp` * Dit logbestand houdt de laatste mislukte inlogpogingen bij [23](#page=23). * Het is standaard ingeschakeld op de meeste distributies [23](#page=23). * Het logboek is opgeslagen in een binair formaat [23](#page=23). * Om dit logboek te lezen, kunnen de commando's `lastb` of `lslogins --failed` worden gebruikt [23](#page=23). * **Opmerking:** Vergelijkbaar met `lastlog`, toont de standaarduitvoer alleen gebruikers uit `/etc/passwd`. Verwijderde en niet-lokale gebruikers worden niet standaard weergegeven [23](#page=23). * Voor forensisch onderzoek op een niet-live systeem kan het commando `lastb -f ` worden gebruikt [24](#page=24). #### 1.2.3 Y2K38 bug * Het `btmp` logbestand, net als andere binaire logbestanden, kan last hebben van de Y2K38 bug, die problemen kan veroorzaken met tijdstempels na het jaar 2038 [25](#page=25). #### 1.2.4 `/var/log/faillog` * Dit logbestand registreert de pogingen die worden beheerd door `pam_faillock.so` [26](#page=26). * De `pam_faillock` module houdt een lijst bij van mislukte authenticatiepogingen per gebruiker gedurende een gespecificeerd interval en vergrendelt het account als er meer dan een gedefinieerd aantal ("deny") opeenvolgende mislukte authenticaties plaatsvinden [26](#page=26). * Deze functie is niet standaard ingeschakeld op Debian/RHEL [26](#page=26). * Het logboek is opgeslagen in een binair formaat [26](#page=26). * Om dit logboek te lezen, kan het commando `faillog` worden gebruikt [26](#page=26). #### 1.2.5 `/var/log/wtmp` * Dit logbestand bevat informatie over alle succesvolle logins, logouts en systeemreboots [27](#page=27). * Het is standaard ingeschakeld op de meeste distributies [27](#page=27). * Het logboek is opgeslagen in een binair formaat [27](#page=27). * Om dit logboek te lezen, kan het commando `last` worden gebruikt [27](#page=27). * **Opmerking:** In tegenstelling tot `lastlog` en `lastb`, worden hier ook verwijderde en niet-lokale gebruikers weergegeven [27](#page=27). * Voor forensisch onderzoek op een niet-live systeem kan het commando `last -f ` worden gebruikt [28](#page=28). #### 1.2.6 `/run/utmp` * Dit bestand bevat informatie over gebruikers die momenteel zijn ingelogd op het systeem [29](#page=29). * Het is standaard ingeschakeld op de meeste distributies [29](#page=29). * Het logboek is opgeslagen in een binair formaat [29](#page=29). * Om dit logboek te lezen, kunnen de commando's `who` of `w` worden gebruikt. Het `w` commando biedt aanvullende informatie ten opzichte van `who`, zoals de huidige processen en CPU-tijd die door de gebruiker worden gebruikt [29](#page=29). ### 1.3 Samenvatting van login/sessie commando's * `who`: Toont wie er is ingelogd [31](#page=31). * `w`: Toont wie er is ingelogd en wat ze aan het doen zijn [31](#page=31). * `last`: Rapporteert de meest recente logins en boot tijden [31](#page=31). * `lastb` / `lslogins --failed`: Toont een lijst van de laatste mislukte logins [31](#page=31). * `lastlog` / `lslogins`: Toont een lijst van de laatste inlogtijd van gebruikers [31](#page=31). * `faillog`: Toont een lijst van het aantal mislukte logins van gebruikers vóór een lockout (indien ingeschakeld) [31](#page=31). --- # De systemd-journal De systemd-journal biedt een beveiligd en gestructureerd alternatief voor traditionele tekstgebaseerde logboeksystemen door middel van cryptografische hashing en verbeterde permissiebeheer [5](#page=5) [9](#page=9). ### 2.1 Structuur en opslagformaat De systemd-journal slaat logboekvermeldingen op in binaire bestanden, die doorgaans te vinden zijn in de submap `/var/log/journal/`. De kern van de beveiligingsvoordelen ligt in de manier waarop deze logboeken worden opgeslagen. Geïnspireerd door systemen zoals Git, worden alle logboekvermeldingen cryptografisch gehasht, waarbij elke vermelding de hash van de voorgaande vermelding bevat. Dit creëert een keten van vermeldingen, waardoor elke vermelding alle voorgaande authenticeert. Door de meest recente hash veilig op te slaan, bijvoorbeeld op een write-once locatie, kan de integriteit van de gehele logboekketen worden gewaarborgd, waardoor manipulaties door aanvallers gemakkelijk detecteerbaar zijn [5](#page=5) [7](#page=7) [8](#page=8). #### 2.1.1 Bestandseigenschappen en permissies De logboekbestanden in `/var/log/journal/` zijn eigendom van root, maar de groep `systemd-journal` heeft speciale permissies [9](#page=9). * **SetGID permissie (`drwxr-sr-x+`):** Deze permissie zorgt ervoor dat alle bestanden die in deze map worden aangemaakt, automatisch de groep `systemd-journal` krijgen. Dit betekent dat leden van de `systemd-journal` groep volledige toegang hebben tot de logbestanden zonder dat ze sudo-permissies nodig hebben [9](#page=9). * **Extended Attributes (ACLs):** Naast de standaard UNIX-permissies kunnen er ook extended attributes (xattr) aanwezig zijn in de `system` namespace. Deze worden gebruikt voor Access Control Lists (ACLs) wat verder verfijnt wie toegang heeft tot de logbestanden [10](#page=10) [11](#page=11). > **Tip:** De SetGID-permissie op de journal-map is een belangrijke beveiligingsfunctie die geautoriseerde gebruikers toegang geeft tot loggegevens zonder de noodzaak van verhoogde privileges [9](#page=9). ### 2.2 Configuratie en distributiespecifieke verschillen De systemd-journal wordt beheerd door de `systemd-journald` service, geconfigureerd via `journald.conf` (meestal in `/etc/systemd/`). Er zijn enkele verschillen in hoe de journal wordt gebruikt en geconfigureerd tussen verschillende Linux-distributies [6](#page=6). #### 2.2.1 RHEL (Red Hat Enterprise Linux) In RHEL, dat ook systemd gebruikt, bevat de systemd-journal de beveiligingsberichten en andere gebeurtenissen die men normaal zou vinden in `/var/log/secure` [12](#page=12). * **Persistentie:** Een belangrijk verschil is dat de systemd-journal in RHEL standaard *niet persistent* is en de logboeken worden opgeslagen in `/run/log/journal/`. Dit kan echter worden aangepast via het `journald.conf` bestand om de journal persistent te maken [12](#page=12). * **Permissies en ACLs:** Leden van de `wheel` groep hebben in RHEL ook leesrechten tot alle journalbestanden, wat betekent dat ze zonder sudo-permissies alle logboekvermeldingen kunnen bekijken. Verder kunnen journalbestanden extended attributes bevatten voor ACLs en SELinux-contexten [13](#page=13). #### 2.2.2 Debian en vergelijkbare distributies In distributies zoals Debian worden de journalbestanden doorgaans opgeslagen in `/var/log/journal/` en zijn ze standaard persistent. De permissiebeheer via de `systemd-journal` groep is ook hier van toepassing [7](#page=7) [9](#page=9). > **Tip:** Het is cruciaal om de distributiespecifieke configuratie van `journald.conf` te controleren, vooral met betrekking tot de persistentie van logboeken in omgevingen zoals RHEL [12](#page=12). ### 2.3 Beveiligingsvoordelen ten opzichte van traditionele tekstlogboeken De systemd-journal biedt aanzienlijke beveiligingsvoordelen ten opzichte van traditionele platte tekstlogboeken die via syslog worden beheerd [5](#page=5). * **Integriteit:** De cryptografische hashing-keten zorgt ervoor dat de integriteit van logboeken gegarandeerd kan worden. Elke poging tot het wijzigen van een logboekvermelding zou de hash van dat item en alle volgende items ongeldig maken, wat de manipulatie direct zichtbaar maakt [5](#page=5). * **Authenticatie:** De hash-keten fungeert als een vorm van authenticatie, waardoor logboekvermeldingen kunnen worden geverifieerd als authentiek en ongewijzigd [5](#page=5). * **Verbeterd permissiebeheer:** De speciale groep `systemd-journal` en de ondersteuning voor ACLs maken een fijnmaziger controle van toegang tot loggegevens mogelijk, wat kan helpen bij het beperken van onbevoegde toegang [10](#page=10) [9](#page=9). > **Voorbeeld:** Stel dat een aanvaller probeert om zijn toegang tot een systeem te verbergen door logboeken te wissen of te wijzigen. Met traditionele tekstbestanden kan dit relatief onopgemerkt gebeuren. Met de systemd-journal zal een dergelijke wijziging de cryptografische keten verbreken, waardoor het systeembeheerder dit direct kan detecteren [5](#page=5). --- # Systeemeen kernellogboeken This section details system-wide logging mechanisms, focusing on general system logs like syslog and messages, and the kernel ring buffer used for capturing boot-time information [32](#page=32) [35](#page=35). ### 3.1 System logs System logs provide a centralized location for recording events and messages generated by the operating system and its services. These logs are crucial for monitoring system health, diagnosing issues, and auditing activities [33](#page=33). #### 3.1.1 Log file locations The specific location of system log files can vary between Linux distributions. * **Debian and derivatives:** Historically, logs were found in `/var/log/syslog`. However, since Debian 12, the `systemd-journald` service has largely replaced this with its own logging system, which can be accessed using `journalctl`. It's important not to confuse the `syslog` log file with the `(r)syslog` daemon itself [33](#page=33). * **RHEL and derivatives:** In Red Hat Enterprise Linux and its derivatives, the primary system log file is located at `/var/log/messages` [33](#page=33) [34](#page=34). #### 3.1.2 Accessing system logs While specific log files are important, the `journalctl` command is a modern and powerful tool for accessing logs, especially on systems using `systemd` [33](#page=33). ### 3.2 Kernel ring buffer The kernel ring buffer is a dedicated mechanism for capturing messages generated during the system's boot process and by the kernel itself [36](#page=36). #### 3.2.1 Purpose and function During system startup, a significant amount of information is displayed on the console, detailing hardware events, driver initialization, boot processes, and other low-level system occurrences. To prevent the loss of these critical early messages, the kernel employs a ring buffer [36](#page=36). * **Message Storage:** This buffer stores all messages, including boot-time messages, that are generated by the `printk()` function within the kernel code [36](#page=36). * **"Ring" Concept:** The term "ring" refers to the buffer's nature as a cyclic data structure with a fixed, hard-coded size within the kernel. When the buffer becomes full, new incoming data overwrites the oldest data, ensuring that the most recent information is always available [36](#page=36). #### 3.2.2 Accessing the kernel ring buffer The kernel ring buffer's contents can be accessed through several methods: * **Character Device:** It is available as the character device `/dev/kmsg` [37](#page=37) [39](#page=39). * **Legacy Files:** Older distributions might have stored kernel messages in files like `/var/log/dmesg` or `/var/log/kern.log` [37](#page=37). * **Tools:** * `dmesg` (diagnostic message): This command is a common utility to display messages from the kernel ring buffer [37](#page=37) [38](#page=38). * `journalctl -k`: This command, part of the `systemd` journal system, specifically displays kernel messages [37](#page=37). * `journalctl --dmesg`: An alternative `journalctl` command to view messages equivalent to `dmesg` [37](#page=37). > **Tip:** The kernel ring buffer is essential for understanding the very first moments of your system's operation, making it invaluable for debugging boot failures or hardware initialization problems. --- # Applicatie- en logbeheer Dit gedeelte behandelt de mechanismen voor het beheren van applicatielogs, inclusief protocollen zoals syslog, implementaties zoals rsyslog, en logrotatie met logrotate en journald. ### 4.1 Applicatielogs Applicaties genereren diverse logbestanden die cruciaal zijn voor monitoring en troubleshooting. Standaard worden deze logs vaak opgeslagen in de `/var/log/` directory [40](#page=40) [41](#page=41). #### 4.1.1 Locaties van applicatielogs Verschillende applicaties hebben hun eigen specifieke loglocaties: * **Apache2 webserver:** * RHEL-gebaseerde systemen: `/var/log/httpd/*` [41](#page=41). * Debian-gebaseerde systemen: `/var/log/apache2/*` [41](#page=41). * **NGINX webserver:** `/var/log/nginx/*` [41](#page=41). * **Fail2Ban:** `/var/log/fail2ban.log` [41](#page=41). * **ufw (Uncomplicated Firewall):** `/var/log/ufw.log` [41](#page=41). * **Apache Tomcat:** `/opt/tomcat/logs/*` (voor Java-applicatieservers) [43](#page=43). Voorbeelden van de inhoud van deze logs zijn te vinden in bestanden zoals `/var/log/httpd/access.log` [42](#page=42). #### 4.1.2 Andere logmechanismen Naast het opslaan in platte tekstbestanden, kunnen applicaties ook gebruik maken van `systemd-journald` voor hun logging. Een voorbeeld hiervan is de OpenSSH server, waarvan de logs bevraagd kunnen worden met `journalctl -u sshd` [43](#page=43). ### 4.2 Logbeheer: rsyslog Rsyslog is een implementatie van het syslog-protocol dat wordt gebruikt voor het verzamelen en routeren van logberichten van verschillende bronnen [45](#page=45). #### 4.2.1 Syslog protocol Het syslog-protocol (nu gestandaardiseerd in RFC 5424) scheidt logberichten van de software die ze genereert en de software die ze analyseert. Door de jaren heen zijn er verschillende implementaties geweest [45](#page=45): * **Syslog (jaren '80):** Geïntroduceerd in UNIX-systemen om berichten van de kernel en applicaties te loggen [45](#page=45). * **Syslog-ng:** Breidde syslog uit met functies zoals filtering en aangepaste opmaak [45](#page=45). * **Rsyslog:** Voegde functies toe zoals hoge prestaties en database-integratie. De 'r' staat voor 'rocket fast' en 'remote log shipping' [45](#page=45). #### 4.2.2 Rsyslog in moderne distributies * **Debian:** Sinds Debian 12 wordt rsyslog niet standaard geïnstalleerd. Basis lokale logging wordt afgehandeld door `systemd-journald`, waardoor rsyslog voor deze taak overbodig werd. Het is echter nog steeds beschikbaar in de repositories en kan worden geïnstalleerd voor externe syslog-behoeften of software die het nog vereist [46](#page=46). * **RHEL (Red Hat Enterprise Linux):** Rsyslog is standaard beschikbaar [46](#page=46). Het rsyslog-daemon is verantwoordelijk voor het verwerken van logberichten. De configuratie van rsyslog vindt plaats in het bestand `/etc/rsyslog.conf` [47](#page=47) [48](#page=48). #### 4.2.3 Facility codes en severity levels Rsyslog gebruikt "facility codes" en "severity levels" om logberichten te categoriseren en prioriteren [49](#page=49). * **Facility:** Specificeert de bron van het logbericht (bv. kernel, mail, auth) [49](#page=49). * **Severity:** Geeft het belang van het logbericht aan (bv. debug, info, warning, error) [49](#page=49). Deze codes en levels worden gebruikt voor het filteren, routeren en beheren van logs [49](#page=49). > **Tip:** Het begrijpen van facility codes en severity levels is essentieel voor het effectief filteren en analyseren van logbestanden [49](#page=49) [50](#page=50). ### 4.3 Logbeheer: logrotate Logrotate is een tool die wordt gebruikt om de groei van logbestanden te beheren door ze periodiek te roteren. Het werkt met platte tekstlogbestanden en niet met de `systemd-journald` logs [52](#page=52). #### 4.3.1 Functies van logrotate Logrotate voert de volgende taken uit: * **Rollen:** Start een nieuw logbestand na een bepaalde periode (roteren) [52](#page=52). * **Compressie:** Optioneel kan het geroteerde logbestanden comprimeren [52](#page=52). * **Verwijderen:** Verwijdert oude logs op basis van ingestelde retentieperiodes [52](#page=52). Logrotate wordt typisch dagelijks uitgevoerd, vaak getriggerd door `cron` of een `systemd timer` [52](#page=52). #### 4.3.2 Configuratie van logrotate De configuratie van logrotate is onderverdeeld in twee locaties: * **/etc/logrotate.conf:** Definieert de standaardinstellingen, zoals wekelijkse rotatie en een retentieperiode van vier weken. Een voorbeeld hiervan is het beheer van `/var/log/secure` op RHEL-systemen [52](#page=52) [55](#page=55). * **/etc/logrotate.d/:** Bevat specifieke configuratiebestanden voor individuele logbestanden. Dit wordt gebruikt om specifieke instellingen te definiëren voor bepaalde logs, zoals de `/var/log/btmp` bestanden die worden gebruikt door commando's als `lastb` [52](#page=52) [56](#page=56). > **Example:** Een configuratie in `/etc/logrotate.d/apache2` kan specificeren dat het access log dagelijks geroteerd moet worden, gecomprimeerd na rotatie, en dat er 7 dagen aan logs bewaard moeten blijven [54](#page=54). ### 4.4 Logbeheer: systemd-journald `systemd-journald` is een logboekbeheerservice die deel uitmaakt van `systemd`. Het beheert logs op een andere manier dan traditionele syslog-implementaties, doorgaans niet in platte tekstbestanden [58](#page=58). #### 4.4.1 Configuratie van journald De instellingen voor het roteren van de journallogs worden beheerd in het configuratiebestand `/etc/systemd/journald.conf` [58](#page=58). #### 4.4.2 Logrotatie bij tijdswijzigingen Logrotatie kan ook worden getriggerd door abrupte (backward) tijdswijzigingen. Dit is bijvoorbeeld relevant bij het starten van virtuele machines waarbij de systeemtijd mogelijk niet correct is gesynchroniseerd met het hostsysteem. Door de logs in een apart bestand te bewaren, worden problemen door uit-de-orde-geplaatste logboekvermeldingen voorkomen, wat de logintegriteit en de tijdlijn van gebeurtenissen verbetert [59](#page=59). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

Glossary

| Term | Definition | |------|------------| | Authenticatie logboeken | Logbestanden die informatie bevatten over de inlogactiviteiten van gebruikers, zoals pogingen tot inloggen en de resultaten daarvan. Dit helpt bij het volgen van wie, wanneer en hoe toegang heeft verkregen tot het systeem. | | systemd-journald | Een systeemcomponent die verantwoordelijk is voor het verzamelen, opslaan en doorsturen van logberichten in een gestructureerd binair formaat, wat zorgt voor betere integriteit en efficiëntie vergeleken met traditionele platte tekstlogboeken. | | journalctl | Een commando-regelprogramma dat wordt gebruikt om logboeken uit de systemd-journal uit te lezen en te manipuleren. Het biedt krachtige filter- en sorteeropties. | | cryptografisch gehasht | Een proces waarbij data wordt omgezet in een unieke, vaste-lengte string (hash) met behulp van cryptografische algoritmen. Dit wordt gebruikt om de integriteit van gegevens te waarborgen, aangezien elke wijziging in de originele data resulteert in een andere hash. | | setgid (set group ID) | Een speciale bestandspermissie in Unix-achtige systemen die ervoor zorgt dat een uitgevoerd programma de groepseigendom van de uitvoerder overneemt, in plaats van het groepseigendom van de eigenaar van het uitvoerbare bestand. In de context van logbestanden kan dit gebruikers toegang verlenen zonder directe sudo-rechten. | | Access Control List (ACL) | Een uitbreiding op de traditionele Unix-bestandspermissies die gedetailleerdere controle biedt over wie toegang heeft tot bestanden en mappen, en welke acties ze mogen uitvoeren. ACL's worden opgeslagen in 'extended attributes'. | | Extended attributes (xattr) | Metagegevens die gekoppeld zijn aan bestanden en directories, bovenop de standaard Unix-permissies. Deze kunnen onder andere ACL's, SELinux-contexten of andere specifieke informatie bevatten. | | Kernel ring buffer | Een cyclische datastructuur met een vaste grootte die berichten opslaat die door de kernel worden gegenereerd tijdens het opstarten en tijdens de normale werking van het systeem. Nieuwe berichten overschrijven de oudste wanneer de buffer vol is. | | dmesg | Een commando dat wordt gebruikt om de kernelringbuffer uit te lezen. Het toont diagnostische berichten van de kernel, die nuttig zijn voor het oplossen van problemen met hardware en stuurprogramma's. | | syslog | Een gestandaardiseerd netwerkprotocol voor het verzenden van logberichten van verschillende bronnen naar een centrale logserver. Het definieert logboekberichten op basis van 'facility' (bron) en 'severity' (ernst). | | rsyslog | Een verbeterde implementatie van het syslog-protocol, bekend om zijn hoge prestaties en ondersteuning voor functies zoals database-integratie en remote log shipping. | | facility code | Een indicator in een logbericht die de bron of categorie van het bericht aangeeft, zoals de kernel, gebruikersprocessen of specifieke daemons. | | severity level | Een indicator in een logbericht die de ernst van het gebeuren beschrijft, variërend van debug-informatie tot kritieke fouten en noodsituaties. | | logrotate | Een hulpprogramma dat wordt gebruikt om logbestanden automatisch te beheren door ze te roteren (nieuwe bestanden aanmaken), te comprimeren en oude logboeken te verwijderen volgens gedefinieerde regels, om schijfruimte te besparen en logbestanden hanteerbaar te houden. | | log retention policy | Een beleid dat bepaalt hoe lang logbestanden worden bewaard voordat ze worden verwijderd of gearchiveerd. Dit is cruciaal voor compliance, beveiligingsaudits en het beheren van schijfruimte. | | /var/log/lastlog | Een binair logbestand dat de meest recente login-informatie voor elke gebruiker op het systeem opslaat. Het wordt gelezen met het commando 'lastlog'. | | /var/log/btmp | Een binair logbestand dat mislukte login-pogingen bijhoudt. Het wordt gelezen met het commando 'lastb'. | | /var/log/wtmp | Een binair logbestand dat alle succesvolle logins en logouts, evenals systeemherstarts, registreert. Het wordt gelezen met het commando 'last'. | | /run/utmp | Een binair logbestand dat informatie bevat over gebruikers die momenteel op het systeem zijn ingelogd. Het wordt gelezen met de commando's 'who' of 'w'. | | Y2K38 bug | Een probleem dat vergelijkbaar is met de Y2K-bug, waarbij tijdstempels die worden opgeslagen met een 32-bit 'signed integer' de waarde van het jaar 2038 zullen overschrijden, wat kan leiden tot onverwacht gedrag in software die deze tijdstempels gebruikt. | | PAM (Pluggable Authentication Modules) | Een flexibel framework dat applicaties in staat stelt om authenticatie- en autorisatiemechanismen te gebruiken die configureerbaar zijn zonder de applicatie zelf te hoeven wijzigen. |

注册阅读 了解更多

Cover

LSS - Lecture VIIIb - Linux Auditing.pdf

词汇表摘要

Summary

# auditd voor gedetailleerde logging Auditd is een gedetailleerd en fraudebestendig logmechanisme voor het identificeren van specifieke acties op een Linux-systeem, essentieel voor forensische analyse na een beveiligingsincident [3](#page=3). ### 1.1 Implementatie en componenten De implementatie van auditd omvat de `auditd` daemon zelf, een `systemd` service genaamd `auditd.service`, en gebruikershulpprogramma's zoals `auditctl`. De logbestanden worden opgeslagen in `/var/log/audit/audit.log` en de configuratie wordt beheerd via `/etc/audit/auditd.conf` [4](#page=4). #### 1.1.1 Systeemdienst en configuratie De `auditd.service` is een `systemd` unit die verantwoordelijk is voor het beheer van de auditd daemon. De configuratie in `/etc/audit/auditd.conf` regelt diverse aspecten, waaronder de locatie van het logbestand, logrotatie, monitoring van schijfruimte, foutafhandeling en remote logging [5](#page=5) [6](#page=6). > **Tip:** Op Debian-systemen is auditd niet standaard geïnstalleerd, terwijl het op RHEL-gebaseerde systemen wel standaard geïnstalleerd en actief is [4](#page=4). ### 1.2 Auditregels Auditregels bepalen welke systeemactiviteiten worden gelogd. Deze regels kunnen worden weergegeven met `auditctl -l` [7](#page=7). #### 1.2.1 Het aanmaken van auditregels Regels worden aangemaakt met het `auditctl` commando. Een voorbeeld is het monitoren van schrijf- en attribuutwijzigingen voor het bestand `/etc/passwd` [8](#page=8). De syntaxis van `auditctl` omvat verschillende opties: * `-a always,exit`: Voegt een regel toe die systeemoproepen bij afsluiting monitort [8](#page=8). * `-F`: Specificeert filters. * `path=/etc/passwd`: Monitort een specifiek bestand [8](#page=8). * `arch=b64`: Beperkt de regel tot 64-bit systeemoproepen [8](#page=8). * `perm=wa`: Filtert op schrijf- (`w`) en attribuutwijzigingen (`a`) [8](#page=8). * `-k `: Een sleutel (key) om gebeurtenissen in het auditlog te taggen en te filteren. Deze sleutels zijn niet vooraf gedefinieerd en moeten zelf worden bedacht [8](#page=8). * `-S`: Filtert op het type systeemoproep (alle systeemoproepen indien niet gespecificeerd) [8](#page=8). Meer voorbeelden zijn te vinden in de `man` pagina van `auditctl` en in `/usr/share/audit/sample-rules/` [9](#page=9). > **Tip:** Zorg ervoor dat de key-namen descriptief zijn om het later zoeken te vergemakkelijken [8](#page=8). #### 1.2.2 Persistentie van auditregels Om auditregels persistent te maken, moeten ze worden opgeslagen in `.rules` bestanden in de map `/etc/audit/rules.d/`. De `augenrules` binary genereert automatisch een `/etc/audit/audit.rules` bestand wanneer de `auditd` service opnieuw wordt geladen, gebaseerd op de regels in deze map [14](#page=14). > **Tip:** Het `augenrules` script is te vinden in `/usr/lib/systemd/system/auditd.service` [14](#page=14). ### 1.3 Audit gebeurtenissen en analyse De gegenereerde audit gebeurtenissen worden opgeslagen in het `/var/log/audit/audit.log` bestand. Om deze gebeurtenissen te parsen en te doorzoeken, kan het hulpprogramma `ausearch` worden gebruikt [10](#page=10). #### 1.3.1 Zoeken naar audit gebeurtenissen Met `ausearch` kan gezocht worden op de zelf gedefinieerde sleutels (keys), bijvoorbeeld: * `ausearch -k passwd_monitoring` [10](#page=10). * De optie `-i` kan worden gebruikt voor interpretatie, zoals het omzetten van epoch-tijden naar timestamps en UID's naar gebruikersnamen: `ausearch -k passwd_monitoring -i` [10](#page=10). `ausearch` leest de informatie uit `/var/log/audit/audit.conf` (waarschijnlijk bedoeld als `/var/log/audit/audit.log` of configuratie die ernaar verwijst). Audit logbestanden bevatten informatie zoals de epoch tijd (seconden sinds 1 januari 1970) en de audit gebeurtenis-ID [12](#page=12). > **Voorbeeld:** Het toevoegen van een nieuwe gebruiker met `adduser john` kan meerdere audit gebeurtenissen genereren voor `/etc/passwd`, zoals het aanmaken van een nieuw bestand, het verwijderen van het oude bestand en het updaten van de directory-invoer [13](#page=13). ### 1.4 Meer dan alleen auditregels Er worden meer gebeurtenissen gelogd dan expliciet in de `audit.rules` bestanden zijn gedefinieerd. Voorbeelden hiervan zijn [16](#page=16): * SELinux/AppArmor denials [16](#page=16). * Gebruikerslogins [16](#page=16). * Kernelberichten [16](#page=16). Het `aureport` commando kan reeds enkele van deze gebeurtenissen samenvatten [16](#page=16). #### 1.4.1 SELinux integratie SELinux in permissieve modus (die geen acties blokkeert maar deze wel logt) genereert logs die via auditd worden verwerkt [17](#page=17). * SELnx permissieve logs kunnen worden gezocht met: * `grep permissive /var/log/audit/audit.log` [17](#page=17). * `aureport --avc` [17](#page=17). * `ausearch -m avc` [17](#page=17). * Hulpprogramma's zoals `audit2why` en `audit2allow` kunnen helpen bij het analyseren van SELinux-gerelateerde audit logs om problemen te diagnosticeren of nieuwe regels te genereren [17](#page=17). ### 1.5 Aanvullende hulpprogramma's Naast `auditctl` en `ausearch` zijn er andere hulpprogramma's die informatie uit de audit logs halen. #### 1.5.1 aulast Het `aulast (--bad)` commando toont een lijst van de laatst ingelogde gebruikers of mislukte logins, vergelijkbaar met `last` en `lastb`, maar haalt de informatie uit `/var/log/audit/audit.log` in plaats van `/var/log/wtmp` of `/var/log/btmp` [18](#page=18). #### 1.5.2 aulastlog `aulastlog` toont de laatste login voor alle gebruikers op de lokale machine. Dit is vergelijkbaar met `lastlog`, maar gebruikt `/var/log/audit/audit.log` als bron in plaats van `/var/log/lastlog` [19](#page=19). > **Tip:** Deze tools zijn nuttig voor het snel verkrijgen van inzichten in gebruikersactiviteit die via auditd worden gelogd [18](#page=18) [19](#page=19). --- # Auditregels en hun configuratie Dit gedeelte beschrijft hoe auditregels gecreëerd, geladen, opgeslagen en persistent gemaakt kunnen worden, met de nadruk op het monitoren van specifieke systeemanalyse. ### 2.1 Auditregels creëren en laden Auditregels worden gecreëerd en geladen met behulp van de `auditctl` tool. Deze regels specificeren welke systeemactiviteiten gemonitord moeten worden [7](#page=7). #### 2.1.1 Lijsten van actieve auditregels Om een lijst te bekijken van alle momenteel geladen auditregels, kan het commando `auditctl -l` worden gebruikt [7](#page=7). #### 2.1.2 Een nieuwe auditregel aanmaken Het aanmaken van een nieuwe auditregel gebeurt met specifieke parameters aan het `auditctl` commando. Een voorbeeld hiervan is het monitoren van schrijf- en attributiewijzigingen op het `/etc/passwd` bestand [8](#page=8). Het commando om dit te realiseren is: `auditctl -a always,exit -F path=/etc/passwd -F arch=b64 -F perm=wa -k passwd_monitoring` [8](#page=8). Hierbij betekenen de parameters: * `-a always,exit`: Voegt een regel toe die systeemcalls bij het afsluiten monitort [8](#page=8). * `-F`: Wordt gebruikt om filters te specificeren [8](#page=8). * `path=/etc/passwd`: Specificeert het bestand dat gemonitord moet worden [8](#page=8). * `arch=b64`: Zorgt ervoor dat de regel alleen van toepassing is op 64-bit systeemcalls [8](#page=8). * `perm=wa`: Filtert op schrijfacties (`w`) en attributiewijzigingen (`a`) [8](#page=8). * `-k passwd_monitoring`: Dit is een door de gebruiker te definiëren sleutel (key) voor het taggen en filteren van gebeurtenissen in het auditlogboek. Er zijn geen vooraf gedefinieerde sleutels [8](#page=8). * `-S`: Hiermee kan gefilterd worden op het type systeemcall. Indien niet gespecificeerd, worden alle systeemcalls gemonitord [8](#page=8). > **Tip:** Meer gedetailleerde voorbeelden zijn te vinden in de man-pagina van `auditctl` en in de directory `/usr/share/audit/sample-rules/` [9](#page=9). ### 2.2 Auditgebeurtenissen en logging Wanneer auditregels worden geactiveerd, worden de bijbehorende gebeurtenissen gelogd in het bestand `/var/log/audit/audit.log` [10](#page=10). #### 2.2.1 Auditlogboeken doorzoeken met `ausearch` Om de gelogde auditgebeurtenissen te parsen en te doorzoeken, wordt de tool `ausearch` gebruikt. Dit maakt het mogelijk om te zoeken naar gebeurtenissen die overeenkomen met de gedefinieerde auditregels [10](#page=10). Je kunt zoeken op de door jou gespecificeerde sleutels, bijvoorbeeld: `ausearch -k passwd_monitoring` [10](#page=10). Voor een meer interpreteerbare output, waarbij onder andere epoch-tijden naar timestamps en UID's naar gebruikersnamen worden omgezet, kan de `-i` optie worden gebruikt: `ausearch -k passwd_monitoring -i` [10](#page=10). #### 2.2.2 Voorbeelden van `ausearch` output Wanneer een regel wordt aangemaakt, wordt dit eerst gelogd. De output van `ausearch` toont onder andere de epoch-tijd (seconden sinds 1 januari 1970), de audit event ID en andere relevante details van de gebeurtenis [11](#page=11) [12](#page=12). **Voorbeeld: Het aanmaken van een gebruiker** Het toevoegen van een nieuwe gebruiker, bijvoorbeeld via `adduser john`, kan meerdere auditgebeurtenissen genereren die betrekking hebben op het `/etc/passwd` bestand. Dit kan het aanmaken van een nieuw bestand, het verwijderen van het oude bestand, en het bijwerken van de directory-invoer omvatten. Het doorzoeken met `ausearch -k passwd_monitoring` na het aanmaken van de gebruiker zal deze gebeurtenissen tonen [13](#page=13). ### 2.3 Auditregels persistent maken Om ervoor te zorgen dat auditregels ook na een herstart van het systeem actief blijven, moeten ze persistent gemaakt worden [14](#page=14). #### 2.3.1 Opslaglocatie voor persistente regels Persistente auditregels moeten worden opgeslagen in een bestand met de extensie `.rules` in de directory `/etc/audit/rules.d/` [14](#page=14). #### 2.3.2 Automatische generatie van `audit.rules` Wanneer de `auditd` service opnieuw wordt geladen, wordt er automatisch een bestand `/etc/audit/audit.rules` gegenereerd door het `augenrules` binary. Dit bestand wordt samengesteld op basis van de regels die zich in de `.rules` bestanden binnen `/etc/audit/rules.d/` bevinden [14](#page=14). > **Tip:** Raadpleeg `man augenrules` voor meer informatie over dit proces en bekijk de service definitie in `/usr/lib/systemd/system/auditd.service` [14](#page=14). --- # Geavanceerde auditd functionaliteit en rapportage Deze sectie behandelt auditd-functionaliteiten die verder gaan dan de expliciet gedefinieerde auditregels, met een focus op het monitoren van SELinux-afwijzingen en kernelberichten, en introduceert hulpmiddelen voor analyse en interpretatie [16](#page=16). ### 3.1 Monitoren van gebeurtenissen buiten expliciete auditregels Auditd registreert meer dan alleen de gebeurtenissen die expliciet in het `audit.rules` bestand zijn gedefinieerd. Dit omvat onder andere [16](#page=16): * SELinux/AppArmor denials [16](#page=16). * Gebruikersaanmeldingen [16](#page=16). * Kernelberichten [16](#page=16). * Andere systeemgebeurtenissen [16](#page=16). Het hulpprogramma `aureport` kan al aanwijzingen geven over deze niet-gedefinieerde gebeurtenissen [16](#page=16). ### 3.2 Analyse van SELinux-gebeurtenissen SELinux (Security-Enhanced Linux) speelt een cruciale rol in de beveiliging van Linux-systemen door middel van Mandatory Access Control (MAC). Wanneer SELinux in de "permissive mode" draait, worden beleidsafwijzingen gelogd door `auditd` in plaats van direct te worden geblokkeerd. Dit is nuttig voor het testen en ontwikkelen van SELinux-beleid [17](#page=17). * **SELinux Permissive Mode:** Dit fungeert als een "what if"-scenario waarbij acties die normaal gesproken geblokkeerd zouden worden, worden gelogd door `auditd` [17](#page=17). * **AVC (Access Vector Cache):** Dit is gerelateerd aan de logging van SELinux-beleidsafwijzingen [17](#page=17). **Tools voor SELinux-analyse:** * **Grep op `audit.log`:** Men kan direct zoeken naar SELinux-gerelateerde berichten in het auditlogbestand: ```bash grep permissive /var/log/audit/audit.log ``` * **`aureport --avc`:** Dit commando genereert een rapportage specifiek voor SELinux Access Vector Cache (AVC) gebeurtenissen [17](#page=17). * **`ausearch -m avc`:** Dit commando zoekt naar auditberichten met het type "AVC" [17](#page=17). * **`audit2why`:** Dit hulpprogramma analyseert de auditlogregels en geeft een leesbare uitleg van SELinux-afwijzingen [17](#page=17). ```bash cat /var/log/audit/audit.log | audit2why ``` * **`audit2allow`:** Dit hulpprogramma wordt gebruikt om SELinux-beleidsregels te genereren op basis van auditlogmeldingen. Het helpt bij het ontwikkelen van SELinux-beleid door configuratiefouten te identificeren en oplossingen voor te stellen [17](#page=17). ```bash cat /var/log/audit/audit.log | audit2allow ``` > **Tip:** Het combineren van `audit2why` en `audit2allow` is een krachtige methode voor het debuggen en verfijnen van SELinux-beleid. `audit2why` geeft inzicht in het probleem, terwijl `audit2allow` concrete beleidsvoorstellen kan genereren. ### 3.3 Hulpprogramma's voor gebruikersaanmeldingen en laatste logins Naast SELinux biedt `auditd` ook functionaliteiten voor het monitoren van gebruikersactiviteit, waaronder aanmeldingspogingen. * **`aulast (--bad)`:** Dit commando toont een lijst van de laatst geregistreerde gebruikersaanmeldingen of mislukte aanmeldingspogingen. Het is vergelijkbaar met de commando's `last` en `lastb`, maar haalt de informatie uit `/var/log/audit/audit.log` in plaats van de traditionele logbestanden zoals `/var/log/wtmp` of `/var/log/btmp` [18](#page=18). * **`aulastlog`:** Dit commando geeft de laatste aanmelding voor alle gebruikers op de lokale machine weer. Het is vergelijkbaar met het commando `lastlog`, maar haalt de informatie uit `/var/log/audit/audit.log` in plaats van het bestand `/var/log/lastlog` [19](#page=19). > **Voorbeeld:** Om snel te zien welke gebruikers recentelijk succesvol zijn ingelogd op het systeem, kunt u `aulast` gebruiken. Als u specifieke mislukte aanmeldingspogingen wilt onderzoeken, kunt u `aulast --bad` raadplegen. `aulastlog` biedt een overzicht van de laatste login per gebruiker, wat nuttig kan zijn voor het controleren van gebruikersactiviteit [18](#page=18) [19](#page=19). --- # Sysmon voor Linux: systeemmonitoring Dit onderwerp introduceert Sysmon voor Linux, een krachtige systeemmonitor die gedetailleerde inzichten biedt in systeemactiviteiten zoals procescreaties en netwerkverbindingen [21](#page=21). ### 4.1 Introductie en Oorsprong Sysmon voor Linux is een port van 'Sysmon for Windows' en biedt vergelijkbare functionaliteit voor het monitoren van systeemgebeurtenissen. Het is gebaseerd op Microsoft Sysinternals en maakt gebruik van Extended Berkeley Packet Filter (eBPF) om aangepaste programma-executie in de kernel mogelijk te maken. De configuratie van Sysmon voor Linux is identiek aan die voor Windows en maakt gebruik van XML-bestanden [21](#page=21). ### 4.2 Installatie De installatie van Sysmon voor Linux omvat het toevoegen van de Microsoft-repository en vervolgens het installeren van het pakket via `apt` of `dnf`. Na de installatie wordt het commando `sysmon -i` gebruikt om Sysmon te initialiseren. Dit proces creëert een configuratiebestand en een systemd-service [22](#page=22). ### 4.3 Configuratie De configuratie van Sysmon voor Linux gebeurt via een XML-bestand, dat standaard te vinden is op `/opt/sysmon/config.xml`. Dit XML-schemavolgt de structuur die definieert welke gebeurtenissen gelogd moeten worden. Gedetailleerde informatie over de configuratie-opties is beschikbaar via het commando `sysmon -? config` [23](#page=23) [24](#page=24). > **Tip:** Zorg ervoor dat u de `config.xml` aanpast om alleen de gebeurtenissen te loggen die relevant zijn voor uw monitoringdoeleinden, om logoverload te voorkomen. ### 4.4 Gebeurtenislogs De door Sysmon voor Linux gegenereerde gebeurtenissen worden opgeslagen in de systeemlogbestanden. Op Debian-gebaseerde systemen is dit doorgaans `/var/log/syslog`, terwijl op RHEL-gebaseerde systemen dit `/var/log/messages` is. De logbestanden zijn in XML-formaat, wat het parsen en analyseren vergemakkelijkt [25](#page=25). ### 4.5 Loganalyse Voor het parsen van de Sysmon-logbestanden kan de gebruikerslevel tool `sysmonLogView` worden gebruikt. Een veelgebruikte methode om live gebeurtenissen te bekijken is door de output van het logbestand te combineren met `tail -f` en `sysmonLogView`, bijvoorbeeld: `sudo tail -f /var/log/syslog | sudo /opt/sysmon/sysmonLogView` [26](#page=26). > **Voorbeeld:** Het volgen van de logbestanden in realtime kan helpen bij het direct identificeren van verdachte activiteiten, zoals ongeautoriseerde procescreaties of netwerkverbindingen. --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

Glossary

| Term | Definition | |------|------------| | auditd | Een daemon die zorgt voor gedetailleerde en fraudebestendige logging van systeemactiviteiten, voornamelijk via systeemoproepen, om te registreren wat, wie, wanneer en vanwaar er acties zijn uitgevoerd op een Linux-systeem. | | Systeemoproep (System Call) | Een interface waarmee een computerprogramma een dienst kan aanvragen van de kernel van het besturingssysteem waarop het draait; auditd richt zich voornamelijk op het loggen van deze systeemoproepen. | | Forensische analyse | Een methode om bewijsmateriaal te verzamelen en te onderzoeken na een beveiligingsincident om de oorzaak, de omvang en de daders van het incident te achterhalen. | | auditctl | Een command-line tool die wordt gebruikt om auditregels te manipuleren, zoals het laden, weergeven of verwijderen van regels die specifieke systeemgebeurtenissen monitoren. | | auditd.conf | Het configuratiebestand voor de auditd daemon, waarin instellingen zoals de locatie van logbestanden, logrotatie, schijfruimtebewaking en foutafhandeling worden gedefinieerd. | | Auditregels | Instructies die worden ingesteld om specifieke systeemgebeurtenissen te monitoren; ze bepalen welke systeemoproepen, bestanden of processen aandacht verdienen en gelogd moeten worden. | | ausearch | Een command-line tool die wordt gebruikt om logbestanden gegenereerd door auditd te doorzoeken en te filteren op specifieke criteria, zoals sleutelwoorden of tijdstempels. | | Persistente regels | Auditregels die na een herstart van het systeem behouden blijven; deze worden doorgaans opgeslagen in speciale `.rules` bestanden in de configuratiemap van auditd. | | SELinux | Security-Enhanced Linux, een beveiligingsmechanisme voor Linux dat een discretionair toegangscontrolebeleid afdwingt; SELinux-afwijzingen kunnen via auditd worden gelogd. | | Sysmon | Een systeemmonitor, oorspronkelijk voor Windows en nu ook beschikbaar voor Linux, die gedetailleerde informatie genereert over procescreaties, netwerkverbindingen en andere systeemgebeurtenissen. | | eBPF (extended Berkeley Packet Filter) | Een technologie die het mogelijk maakt om veilige, efficiënte en programmeerbare code binnen de Linux-kernel uit te voeren, gebruikt door Sysmon voor Linux om diepgaande systeemmonitoring te realiseren. | | XML (Extensible Markup Language) | Een markup-taal die wordt gebruikt voor het definiëren van regels en configuraties voor Sysmon voor Linux, waardoor een gestructureerde manier ontstaat om te specificeren welke gebeurtenissen gelogd moeten worden. |

注册阅读 了解更多

Cover

LSS - Lecture VIIIb - Linux Auditing.pdf

词汇表摘要

Summary

# auditd voor gedetailleerde logging Auditd is een daemon die zorgt voor gedetailleerde en manipulatief bestendige logging van systeemactiviteiten op Linux-systemen, voornamelijk gericht op het monitoren van systeemoproepen. Dit is van cruciaal belang voor forensische analyse na een beveiligingsincident, mits de logging voorafgaand aan het incident was ingeschakeld [3](#page=3). ### 1.1 Implementatie en componenten De implementatie van auditd omvat verschillende componenten [4](#page=4): * **Daemon:** `auditd` zelf is de achtergrondservice die verantwoordelijk is voor het vastleggen van gebeurtenissen. * **Systemd service:** `auditd.service` is de systemd-unit die het beheer van de daemon regelt [5](#page=5). * **Gebruikershulpprogramma's:** `auditctl` en andere tools worden gebruikt om interactie te hebben met het auditsysteem [4](#page=4). * **Logbestand:** De auditgebeurtenissen worden opgeslagen in `/var/log/audit/audit.log` [4](#page=4). * **Configuratiebestand:** De hoofdconfiguratie voor de `auditd` daemon bevindt zich in `/etc/audit/auditd.conf` [4](#page=4). Op Debian-gebaseerde systemen is `auditd` niet standaard geïnstalleerd, terwijl het op RHEL-gebaseerde systemen standaard geïnstalleerd en actief is [4](#page=4). ### 1.2 Configuratie van auditd Het configuratiebestand `/etc/audit/auditd.conf` bevat diverse instellingen die het gedrag van de auditdaemon bepalen. Belangrijke configuratieopties zijn onder meer [6](#page=6): * Locatie van het logbestand. * Rotatie van logbestanden. * Monitoring van schijfruimte. * Foutafhandeling. * Externe logging. * En meer [6](#page=6). ### 1.3 Auditregels #### 1.3.1 Toon huidige regels De momenteel geladen auditregels kunnen worden weergegeven met het commando `auditctl -l` [7](#page=7). #### 1.3.2 Creëren van auditregels Auditregels specificeren welke systeemactiviteiten moeten worden gelogd. Ze worden doorgaans aangemaakt met het `auditctl` commando. **Voorbeeld:** Om schrijf- en attribuutwijzigingen voor het bestand `/etc/passwd` te monitoren, kan de volgende regel worden gebruikt [8](#page=8): `auditctl -a always,exit -F path=/etc/passwd -F arch=b64 -F perm=wa -k passwd_monitoring` Uitleg van de componenten van deze regel: * `-a always,exit`: Voegt een regel toe die systeemoproepen monitort bij het verlaten (exit) van de oproep [8](#page=8). * `-F`: Wordt gebruikt voor filters. * `path=/etc/passwd`: Specificeert het te monitoren bestand [8](#page=8). * `arch=b64`: Zorgt ervoor dat de regel alleen van toepassing is op 64-bit systeemoproepen [8](#page=8). * `perm=wa`: Filtert specifiek op schrijf (`w`) en attribuutwijzigingen (`a`) [8](#page=8). * `-k passwd_monitoring`: Dit is een sleutel (key) die zelf gedefinieerd moet worden om gebeurtenissen in het auditlogboek te taggen en te filteren. Er zijn geen vooraf gedefinieerde sleutels [8](#page=8). * `-S`: Hiermee kan gefilterd worden op het type systeemoproep. Als dit niet gespecificeerd is, worden alle systeemoproepen meegenomen [8](#page=8). Meer voorbeelden van auditregels zijn te vinden in de man-pagina van `auditctl` en in de directory `/usr/share/audit/sample-rules/` [9](#page=9). #### 1.3.3 Persistentie van auditregels Om auditregels persistent te maken zodat ze na een herstart van de systeembehoud, moeten ze worden opgeslagen in een `.rules` bestand in de directory `/etc/audit/rules.d/`. Het bestand `/etc/audit/audit.rules` wordt automatisch gegenereerd (door het `augenrules` binary) wanneer de `auditd` service herladen wordt, gebaseerd op de regels in de `.rules` bestanden [14](#page=14). #### 1.3.4 Welke regels te gebruiken? Er zijn best practices en aanbevolen configuraties beschikbaar. Een GIT-repository van Florian Roth biedt een basisconfiguratie die uit-de-doos werkt op de meeste grote Linux-distributies, geschikt is voor de meeste gebruiksscenario's, een redelijke hoeveelheid loggegevens produceert, beveiligingsrelevante activiteiten dekt en gemakkelijk te lezen is. Het voorbeeld wordt gegeven op: `https://github.com/Neo23x0/auditd/blob/master/audit.rules` [15](#page=15). ### 1.4 Auditgebeurtenissen De vastgelegde gebeurtenissen worden opgeslagen in het bestand `/var/log/audit/audit.log`. Om deze gebeurtenissen te parsen en te doorzoeken op basis van ingestelde auditregels, wordt het hulpprogramma `ausearch` gebruikt [10](#page=10). **Voorbeelden van `ausearch` gebruik:** * Zoeken op zelf gedefinieerde 'sleutels': `ausearch -k passwd_monitoring` [10](#page=10). * Met enige interpretatie (zoals omzetten van epoch-tijd naar timestamps, uid naar gebruikersnaam, etc.): `ausearch -k passwd_monitoring -i` [10](#page=10). `ausearch` leest zijn configuratie uit `/var/log/audit/audit.conf`. De output van `ausearch` kan informatie bevatten zoals epoch-tijd, audit gebeurtenis-ID, etc. [12](#page=12). **Voorbeeld van `ausearch` na het aanmaken van een gebruiker:** Het toevoegen van een nieuwe gebruiker kan meerdere auditgebeurtenissen genereren voor `/etc/passwd`, zoals het aanmaken van een nieuw bestand, het verwijderen van het oude bestand, en het updaten van de directory-invoer [13](#page=13). > **Tip:** De creatie van de auditregel zelf wordt ook gelogd [11](#page=11). ### 1.5 Meer dan expliciet gedefinieerde regels Het is belangrijk te beseffen dat er meer wordt geaudit dan alleen wat expliciet is gedefinieerd in het `audit.rules` bestand. Dit omvat bijvoorbeeld [16](#page=16): * SELinux / AppArmor denials. * Gebruikersaanmeldingen. * Kernelberichten. * En meer [16](#page=16). Het hulpprogramma `aureport` kan reeds enkele van deze gebeurtenissen aan het licht brengen [16](#page=16). #### 1.5.1 Voorbeeld: SELinux Wanneer SELinux in permissieve modus staat, worden gebeurtenissen die normaal geblokkeerd zouden worden, gelogd via `auditd`. Dit betreft vaak Access Vector Cache (AVC) meldingen [17](#page=17). * Zoeken naar permissieve modus logs: `grep permissive /var/log/audit/audit.log` [17](#page=17). * Samenvatting van AVC-meldingen met `aureport`: `aureport --avc` [17](#page=17). * Zoeken naar specifieke AVC-meldingen met `ausearch`: `ausearch -m avc` [17](#page=17). Er zijn ook tools die de ontwikkeling van SELinux-beleid versnellen met behulp van auditlogs: * `cat /var/log/audit/audit.log | audit2why` [17](#page=17). * `cat /var/log/audit/audit.log | audit2allow` [17](#page=17). ### 1.6 Hulpprogramma's voor loganalyse Naast `auditctl` en `ausearch` zijn er nog andere nuttige hulpprogramma's voor het analyseren van auditlogs: #### 1.6.1 `aulast` Het `aulast` commando (met de optie `--bad`) toont een lijst van de laatst ingelogde gebruikers of mislukte logins. Dit is vergelijkbaar met de commando's `last` en `lastb` uit de module 'Logging', maar haalt zijn informatie uit `/var/log/audit/audit.log` in plaats van `/var/log/wtmp` of `/var/log/btmp` [18](#page=18). #### 1.6.2 `aulastlog` Het `aulastlog` commando toont de laatste login voor alle gebruikers van de lokale machine. Dit is vergelijkbaar met het commando `lastlog`, maar haalt de informatie uit `/var/log/audit/audit.log` in plaats van `/var/log/lastlog` [19](#page=19). --- # Sysmon voor Linux Sysmon voor Linux is een systeemmonitor die, gebaseerd op de Windows-versie, gedetailleerde informatie verschaft over procescreaties en netwerkverbindingen, gebruikmakend van eBPF-technologie [21](#page=21). ### 2.1 Introductie en functionaliteit Sysmon is oorspronkelijk ontwikkeld als een tool voor Windows door Microsoft Sysinternals. De Linux-versie is hiernaar geporteerd en biedt vergelijkbare functionaliteit. Het primaire doel is het gedetailleerd loggen van systeemactiviteiten, zoals procescreaties en netwerkverbindingen. De configuratie is gelijk aan die van Windows en maakt gebruik van XML-bestanden. De technologie achter Sysmon voor Linux maakt gebruik van Extended Berkeley Packet Filter (eBPF) voor het uitvoeren van aangepaste programma's binnen de kernel. Dit maakt het mogelijk om diepgaande inzichten te verkrijgen in systeemgebeurtenissen [21](#page=21). ### 2.2 Installatie De installatie van Sysmon voor Linux verloopt doorgaans door het toevoegen van de Microsoft-repository en vervolgens het installeren via de package manager (apt of dnf). Na het downloaden van de benodigde bestanden, wordt de installatie gestart met het commando `sysmon -i`. Dit commando creëert automatisch een configuratiebestand en start een systemd-service. Gedetailleerde installatie-instructies zijn te vinden op GitHub [22](#page=22). > **Tip:** Zorg ervoor dat je de officiële documentatie op GitHub volgt voor de meest actuele installatieprocedures [22](#page=22). ### 2.3 Configuratie De configuratie van Sysmon voor Linux wordt beheerd via een XML-bestand, doorgaans te vinden op `/opt/sysmon/config.xml`. Dit bestand definieert de schema's voor welke gebeurtenissen gelogd moeten worden. Gebruikers kunnen de beschikbare configuratieopties bekijken met het commando `sysmon -? config` [23](#page=23) [24](#page=24). ### 2.4 Gebeurtenislogs De gelogde gebeurtenissen worden opgeslagen in de systeemlogbestanden. Op Debian-gebaseerde systemen is dit doorgaans `/var/log/syslog`, terwijl op RHEL-gebaseerde systemen `/var/log/messages` wordt gebruikt. De logbestanden zijn opgemaakt in XML, wat verdere parsing en analyse vergemakkelijkt [25](#page=25). > **Voorbeeld:** Een procescreatiegebeurtenis kan gedetailleerde informatie bevatten zoals de naam van het proces, de parent-ID, de command line argumenten en de gebruikerscontext waarin het proces is gestart. ### 2.5 Tools voor analyse Voor het eenvoudig bekijken en parsen van de gegenereerde logbestanden is er de gebruikerslevel tool `sysmonLogView`. Deze tool kan, in combinatie met commando's zoals `tail -f` en `sudo`, real-time de logbestanden doorzoeken [26](#page=26). > **Voorbeeld:** Het volgende commando toont de meest recente logregels van `/var/log/syslog` en pipe deze door naar `sysmonLogView` voor een overzichtelijke weergave: > `sudo tail -f /var/log/syslog | sudo /opt/sysmon/sysmonLogView` [26](#page=26). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

Glossary

| Term | Definition | |------|------------| | auditd | Een daemon die een gedetailleerd en manipulatief bestendig loggingmechanisme biedt voor het identificeren van specifieke acties op een Linux-systeem, met focus op systeemoproepen om bij te houden wat, wie, wanneer en van waar acties zijn uitgevoerd. | | Auditregels | Instructies die worden ingesteld met tools zoals `auditctl` om de `auditd` daemon te instrueren welke systeemoproepen of bestandspaden gemonitord moeten worden, inclusief filters voor architectuur en permissies, en sleutelwoorden voor latere filtering. | | ausearch | Een command-line tool die wordt gebruikt om auditgebeurtenissen te parsen en te doorzoeken in het `/var/log/audit/audit.log` bestand, met de mogelijkheid om te filteren op specifieke sleutelwoorden, systeemaanroepen en tijdperken. | | auditctl | Een gebruikersniveau-tool die wordt gebruikt om auditregels te laden, te inspecteren en te verwijderen in de auditd-daemon, essentieel voor het configureren van de monitoring van systeemactiviteiten. | | Sysmon for Linux | Een systeemmonitor die gedetailleerde informatie biedt over procescreaties, netwerkverbindingen en andere systeemactiviteiten op Linux, gebaseerd op Microsoft Sysinternals en gebruikmakend van eBPF, met configuratie in XML-formaat. | | eBPF (Extended Berkeley Packet Filter) | Een technologie die aangepaste programma's in de kernel van Linux laat uitvoeren, gebruikt door Sysmon for Linux om gedetailleerde informatie te verzamelen over systeemgebeurtenissen op een efficiënte manier. | | XML (Extensible Markup Language) | Een markup-taal die wordt gebruikt voor het structureren en transporteren van gegevens, toegepast door Sysmon for Linux voor zijn configuratiebestanden en voor het formatteren van gelogde gebeurtenissen. | | Systeemoproep (System Call) | Een interface waarmee een computerprogramma een dienst kan aanvragen bij de kernel van het besturingssysteem, wat de basis vormt voor veel auditmechanismen zoals `auditd`. | | SELinux (Security-Enhanced Linux) | Een beveiligingsmechanisme dat toegangscontroles afdwingt op basis van beleidsregels, waarbij ontkenningen gelogd kunnen worden door `auditd` en geanalyseerd met tools zoals `audit2why` en `audit2allow`. | | Logbestand | Een bestand waarin gebeurtenissen en informatie worden opgeslagen door software of het besturingssysteem, zoals `/var/log/audit/audit.log` voor `auditd` en `/var/log/syslog` of `/var/log/messages` voor Sysmon. |

注册阅读 了解更多

Cover

LSS - Lecture VII - LUKS encryption.pdf

词汇表摘要

Summary

# Introductie tot LUKS-encryptie LUKS (Linux Unified Key Setup) is de standaard voor volledige schijf- of partitie-encryptie in Linux, aangedreven door de dm-crypt kernelmodule [2](#page=2). ### 1.1 Wat is LUKS? LUKS staat voor Linux Unified Key Setup. Het is een gestandaardiseerde manier om data op een blokapparaat (zoals een harde schijf of partitie) te versleutelen. LUKS werkt bovenop dm-crypt, een kernelmodule die zorgt voor de daadwerkelijke encryptie en decryptie van data. De 'dm' in dm-crypt staat voor Device-mapper, wat een generieke methode is om virtuele lagen van blokapparaten te creëren. LUKS is compatibel met diverse tools en wordt breed ondersteund in verschillende Linux-distributies [2](#page=2). ### 1.2 Voordelen van LUKS De voordelen van het gebruik van LUKS omvatten: * **Gebruiksvriendelijk sleutelbeheer:** LUKS biedt een eenvoudige manier om encryptiesleutels te beheren [3](#page=3). * **Ondersteuning voor meerdere sleutels:** Het is mogelijk om meerdere sleutels of passphrases te koppelen aan één versleutelde partitie, wat flexibiliteit biedt [3](#page=3) [5](#page=5). * **Brede ondersteuning:** LUKS wordt erkend en ondersteund door de meeste gangbare Linux-distributies [3](#page=3). * **Betrouwbare technologie:** Het is een bewezen en betrouwbare technologie voor databeveiliging [3](#page=3). * **Anti-forensische functies:** LUKS bevat technieken die het berekeningsintensief maken om brute-force aanvallen uit te voeren, wat de veiligheid verhoogt [3](#page=3). ### 1.3 Hoe LUKS werkt LUKS werkt door een speciale LUKS-header toe te voegen aan het begin van het versleutelde apparaat. Deze header bevat metadata over de encryptieconfiguratie [5](#page=5). Het kerncomponent is dm-crypt, dat de daadwerkelijke encryptie van de data verzorgt. dm-crypt kan ook direct worden gebruikt zonder een LUKS-header, wat nuttig kan zijn voor steganografische toepassingen en het creëren van plausibele ontkenning [5](#page=5). Het sleutelbeheer binnen LUKS is hiërarchisch opgebouwd. Er is een 'volume key' die de data op het schijfblokniveau versleutelt. Om deze volume key te beveiligen, worden passphrases of sleutelbestanden gebruikt om de volume key zelf te versleutelen. Dit multi-laagse benadering maakt het mogelijk om bijvoorbeeld een passphrase te wijzigen zonder de volledige partitie of schijf opnieuw te hoeven versleutelen [5](#page=5). > **Tip:** Het multi-laagse sleutelbeheer is een cruciaal voordeel van LUKS. Het betekent dat als u uw wachtwoord wilt veranderen, u niet de hele inhoud van uw versleutelde schijf hoeft te hercoderen. U hoeft alleen de verbinding tussen uw nieuwe wachtwoord en de volume key te herstellen [5](#page=5). --- # Het correcte proces voor partitie-encryptie met LUKS Dit onderwerp beschrijft de essentiële volgorde voor het correct instellen van partitie-encryptie met LUKS, inclusief de interactie tussen het encryptie- en bestandssysteem [4](#page=4). ### 2.1 De juiste volgorde voor partitioneren, initialiseren en formatteren Het correct toepassen van LUKS-encryptie vereist een specifieke volgorde van handelingen om de integriteit en functionaliteit te waarborgen [4](#page=4). #### 2.1.1 Partitioneringsfase Allereerst dient de schijf te worden gepartitioneerd. Het is cruciaal om deze stap vóór de encryptie uit te voeren. Indien de schijf eerst zou worden versleuteld alvorens partities aan te maken, zou de partitietabel zelf gedecodeerd moeten worden om partities te creëren en beheren. Dit ondermijnt het doel van encryptie. Bovendien zouden partities niet onafhankelijk van elkaar versleuteld kunnen worden, wat het beheer ervan bemoeilijkt [4](#page=4). > **Tip:** Partitioner eerst de schijf; dit zorgt ervoor dat de partitietabel en de partities zelf afzonderlijk beheerd en versleuteld kunnen worden. #### 2.1.2 Initialisatie met LUKS Na het partitioneren wordt de encryptie geïnitialiseerd met LUKS op de betreffende partitie. Dit proces schrijft essentiële metadata voor de encryptie en de sleutels naar de partitie. De daadwerkelijke encryptie vindt pas plaats wanneer er data naar de partitie wordt geschreven. De resulterende entiteit wordt een 'LUKS-container' genoemd [4](#page=4). #### 2.1.3 Formatteren van de LUKS-container Tot slot wordt de geopende LUKS-container geformatteerd met een bestandssysteem. Het is belangrijk om te begrijpen dat LUKS geen kennis heeft van het bestandssysteem. LUKS opereert op het niveau van blokapparaten en verzorgt de encryptie van ruwe data die naar de schijf wordt geschreven of ervan wordt gelezen. Omgekeerd is het bestandssysteem zich niet bewust van de onderliggende encryptie; het functioneert alsof het met een regulier, onversleuteld blokapparaat werkt [4](#page=4). > **Voorbeeld:** Een gebruiker formatteert een LUKS-container met `mkfs.ext4 /dev/mapper/` en mount deze vervolgens naar `/mnt`, waarna bestanden normaal kunnen worden gelezen en geschreven. ### 2.2 Interactie tussen LUKS en het bestandssysteem De relatie tussen LUKS en het bestandssysteem is hiërarchisch en transparant voor de gebruiker [11](#page=11) [4](#page=4). #### 2.2.1 Het ontgrendelde blokapparaat Na het succesvol ontgrendelen van een LUKS-partitie, wordt deze beschikbaar gemaakt via een symbolische link in `/dev/mapper/`. Dit virtuele blokapparaat kan vervolgens op dezelfde manier worden behandeld als elk ander normaal partitieblokapparaat [11](#page=11). #### 2.2.2 Data-encryptie en -decryptie on-the-fly Wanneer een bestandssysteem op dit gemapte apparaat is geformatteerd en gemount, communiceert het met het onderliggende blokapparaat. dm-crypt (de module achter LUKS) versleutelt en ontsleutelt data op de achtergrond ('on-the-fly') tijdens schrijf- en leesbewerkingen van de gebruiker. Dit proces is transparant; de gebruiker interacteert met een standaard bestandssysteem [11](#page=11) [4](#page=4). > **Belangrijk:** Ongebruikte ruimte op de LUKS-container blijft onversleuteld totdat er data naar wordt geschreven [11](#page=11). #### 2.2.3 Beveiligen van de mapping Om de LUKS-mapping veilig te sluiten en de data weer te beveiligen, wordt de `cryptsetup close ` commando gebruikt [11](#page=11). ### 2.3 Prestatie en beveiligingsaspecten De scheiding tussen LUKS en het bestandssysteem biedt significante voordelen op het gebied van prestaties en beveiliging [13](#page=13). #### 2.3.1 Bestandsysteemagnostisch LUKS-encryptie werkt onafhankelijk van het gekozen bestandssysteem. Dit betekent dat de keuze van het bestandssysteem geen invloed heeft op de prestaties of het gedrag van de encryptie. Elk bestandssysteem, inclusief swap-partities, kan worden versleuteld met LUKS. Dit staat in contrast met systemen zoals BitLocker op Windows, dat geïntegreerd is met specifieke bestandssystemen zoals NTFS/FAT/ex-FAT [13](#page=13). #### 2.3.2 Beveiligingsborging Omdat het bestandssysteem bovenop de LUKS-laag opereert, worden alle data, inclusief de metadata van het bestandssysteem (zoals superblokken en inodes), versleuteld. Dit zorgt voor een algehele databeveiliging op partitieniveau [13](#page=13). --- # Gebruik van cryptsetup voor LUKS-beheer Dit onderwerp behandelt de essentiële commando's en processen voor het beheren van LUKS-partities met behulp van het `cryptsetup`-pakket, inclusief initialisatie, toegang, gebruik en sluiting van versleutelde volumes, evenals beheer van de LUKS-header en sleutels [9](#page=9). ### 3.1 Initialiseren van een LUKS-partitie Het initialiseren van een partitie voor LUKS-versleuteling creëert de benodigde structuur voor de beveiliging van de gegevens [9](#page=9). #### 3.1.1 Het `luksFormat` commando Het `cryptsetup luksFormat` commando wordt gebruikt om een LUKS-header, een volume-sleutel en de eerste wachtwoordzin-sleutel aan te maken op een gespecificeerde partitie [9](#page=9). * **Commando:** `cryptsetup luksFormat /dev/sdXY` * **Voorbeeld:** `cryptsetup luksFormat /dev/sdb1` [9](#page=9). ### 3.2 Openen van een LUKS-partitie Nadat een partitie is geïnitialiseerd met LUKS, kan deze worden geopend om toegang te krijgen tot de versleutelde gegevens [10](#page=10). #### 3.2.1 Het `open` commando Het `cryptsetup open` commando ontgrendelt de LUKS-partitie met behulp van een correcte wachtwoordzin of sleutel. Dit proces ontsluit de volume-sleutel die nodig is voor de decryptie [10](#page=10). * **Commando:** `cryptsetup open /dev/sdXY ` * **Resultaat:** Na succesvolle authenticatie wordt er een virtueel block device aangemaakt onder de naam `/dev/dm-*`, met een vriendelijkere symlink genaamd `/dev/mapper/` [10](#page=10). ### 3.3 Gebruik van de LUKS-partitie Na het openen van de LUKS-partitie kan het resulterende mapper-device worden behandeld als een standaard blokapparaat voor de opslag van bestanden en systemen [11](#page=11). * **Formatteren:** Als de partitie voor het eerst wordt gebruikt, kan deze worden geformatteerd met een bestandssysteem, bijvoorbeeld: `mkfs.ext4 /dev/mapper/` [11](#page=11). * **Mounten:** Het gemapte device kan worden gemount op een mount point, zoals elk ander bestandssysteem: `mount /dev/mapper/ /mnt` [11](#page=11). * **Bestandsoperaties:** Gebruikers kunnen bestanden lezen en schrijven naar het gemounte deel als een normaal bestandssysteem [11](#page=11). * **On-the-fly encryptie/decryptie:** dm-crypt zorgt voor de encryptie en decryptie van data op de achtergrond tijdens lees- en schrijfoperaties [11](#page=11). * **Niet-gebruikte ruimte:** Ruimte die nog niet is beschreven, blijft onversleuteld totdat er gegevens naar worden geschreven [11](#page=11). #### 3.3.1 Het sluiten van een LUKS-partitie Om een LUKS-mapping veilig te verwijderen en het volume weer te vergrendelen, wordt het `cryptsetup close` commando gebruikt [11](#page=11). * **Commando:** `cryptsetup close ` [11](#page=11). ### 3.4 Beheer van de LUKS-header De LUKS-header is een cruciaal onderdeel dat aan het begin van de versleutelde partitie staat [12](#page=12). * **Inhoud:** De header bevat metadata zoals het gebruikte encryptie-algoritme (bijvoorbeeld AES), cipher mode (zoals XTS), hashing-algoritme voor wachtwoordvalidatie, en informatie over de sleutel-slots [12](#page=12). * Het standaard cipher dat voor LUKS wordt gebruikt, is `aes-xts-plain64` [12](#page=12). * De standaard sleutelgrootte voor LUKS is 512 bits [12](#page=12). * **Sleutel-slots:** Deze slots koppelen gebruikerswachtwoorden aan de volume-sleutel [12](#page=12). * LUKS1 kent 8 sleutel-slots [12](#page=12). * LUKS2 kent 32 sleutel-slots [12](#page=12). * **Belangrijk:** Verlies van de LUKS-header leidt tot onherstelbaar dataverlies, omdat decryptie onmogelijk wordt [12](#page=12). * **Back-up en Inspectie:** * Het wordt sterk aanbevolen om de LUKS-header te back-uppen met `cryptsetup luksHeaderBackup` [12](#page=12). * De inhoud van de LUKS-header kan worden geanalyseerd met `cryptsetup luksDump` [12](#page=12). ### 3.5 Sleutelbeheer in LUKS LUKS-devices ondersteunen meerdere sleutel-slots, wat de mogelijkheid biedt om back-upsleutels of alternatieve wachtwoordzinnen toe te voegen [14](#page=14). * **LUKS1:** Ondersteunt maximaal 8 sleutels [14](#page=14). * **LUKS2:** Ondersteunt maximaal 32 sleutels [14](#page=14). #### 3.5.1 Toevoegen en verwijderen van sleutels * **Een nieuwe sleutel toevoegen:** * **Commando:** `cryptsetup luksAddKey /dev/sdXY` [14](#page=14). * **Een sleutel verwijderen:** * **Commando:** `cryptsetup luksRemoveKey /dev/sdXY` [14](#page=14). > **Tip:** Het toevoegen van meerdere wachtwoordzinnen of sleutels aan een LUKS-volume is een effectieve methode om verlies van toegang tot uw versleutelde gegevens te voorkomen, mocht u een van de wachtwoordzinnen vergeten. Zorg altijd voor een veilige opslag van back-up sleutels [14](#page=14). --- # Geavanceerde concepten en beperkingen van LUKS Dit onderwerp behandelt de integratie van LVM bovenop LUKS, de prestatie-isolatie, beveiligingsgaranties en de inherente beperkingen van LUKS, evenals alternatieve versleutelingsoplossingen. ### 4.1 LVM op LUKS Tijdens de installatie van een Linux-besturingssysteem wordt LVM (Logical Volume Management) doorgaans aangeboden bovenop LUKS (Linux Unified Key Setup). Dit betekent dat de versleutelde partitie, beheerd door LUKS, fungeert als de onderliggende opslag voor de logische volumes die door LVM worden gecreëerd [15](#page=15) [16](#page=16). ### 4.2 Beperkingen van LUKS Ondanks de sterke beveiligingsvoordelen van LUKS, zijn er diverse beperkingen waarmee rekening gehouden moet worden: * **Bescherming bij uitgeschakeld systeem:** LUKS en vergelijkbare schijfversleutelingsoplossingen beschermen de gegevens uitsluitend wanneer het systeem is uitgeschakeld. Zodra het systeem draait en LUKS de schijf heeft ontsleuteld, kunnen bestanden gelezen worden door iedereen met fysieke toegang tot het systeem [17](#page=17). * **Sleutelbeheer:** Het correct beheren van de versleutelingssleutels is cruciaal. Het vereist een sterk wachtwoord [17](#page=17). * **Fysieke schade:** LUKS biedt geen bescherming tegen fysieke schade aan de opslagmedia [17](#page=17). * **Aantal sleutels:** Het aantal verschillende toegangssleutels dat voor een LUKS-container kan worden ingesteld, is beperkt tot een maximum van 32 [17](#page=17). * **Directory-/bestandsniveau-encryptie:** LUKS biedt geen functionaliteit voor het versleutelen van individuele directories of bestanden per gebruiker [17](#page=17). > **Tip:** Vanwege de beperking op het aantal sleutels en het ontbreken van bestandsniveau-encryptie, is LUKS voornamelijk geschikt voor het versleutelen van volledige opslagapparaten of partities, en minder voor gedetailleerde toegangscontrole op gebruikersniveau binnen een gedeelde omgeving. ### 4.3 Alternatieven voor LUKS Voor scenario's die specifieke vereisten hebben die LUKS niet kan vervullen, zijn er alternatieve oplossingen beschikbaar, zowel op Linux als op andere platforms: * **Directory-level encryptie op Linux:** * Voor bestandssystemen zoals ext4 en f2fs kan `fscrypt` worden gebruikt [18](#page=18). * ZFS biedt een ingebouwde native encryptiefunctie [18](#page=18). * **Andere platforms dan Linux:** * **VeraCrypt:** Een multi-platform oplossing die compatibel is met verschillende besturingssystemen [18](#page=18). * **BitLocker:** De ingebouwde encryptieoplossing voor Windows [18](#page=18). > **Example:** Een gebruiker die een volledige schijfversleuteling wenst voor zijn laptop, kan LUKS gebruiken. Als dezelfde gebruiker echter specifieke gevoelige documenten binnen zijn thuismap wil versleutelen met een aparte sleutel, onafhankelijk van de systeemsleutel, en met de mogelijkheid om dit per gebruiker te doen, dan zijn oplossingen zoals `fscrypt` of VeraCrypt meer geschikt. --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

Glossary

| Term | Definition | |------|------------| | LUKS | Linux Unified Key Setup, een standaard voor volledige schijf- of partitie-encryptie in Linux die gebruikmaakt van dm-crypt. Het biedt gebruiksvriendelijk sleutelbeheer en multi-sleutelondersteuning. | | dm-crypt | Een kernelmodule in Linux die cryptografische operaties uitvoert op block devices. Het vormt de basis voor schijfencryptie en kan met of zonder de LUKS-header worden gebruikt. | | Device-mapper (dm) | Een generieke framework in de Linux-kernel dat virtuele lagen van block devices creëert, waardoor complexe opslagconfiguraties zoals encryptie mogelijk worden. | | LUKS-container | Een partitie of schijf die is geïnitialiseerd met LUKS. Het bevat een LUKS-header met metadata voor encryptie en sleutels, en dient als een beveiligde laag waarover een bestandssysteem kan worden gecreëerd. | | LUKS-header | Een niet-versleuteld gedeelte aan het begin van een LUKS-container dat essentiële metadata bevat, zoals het gebruikte encryptie-algoritme, cipher-modus, hash-functie en sleutel-slots voor het opslaan van versleutelde volume-sleutels. | | Volume-sleutel | Een willekeurige sleutel die wordt gebruikt om de daadwerkelijke gegevens op een schijf of partitie te versleutelen. Deze volume-sleutel wordt zelf versleuteld met behulp van wachtwoorden of sleutelbestanden die in de LUKS-header zijn opgeslagen. | | Sleutel-slot | Een locatie binnen de LUKS-header die een versleutelde versie van de volume-sleutel bevat, beschermd door een gebruikerswachtwoord of sleutelbestand. LUKS1 ondersteunt maximaal 8 sleutel-slots, LUKS2 tot 32. | | cryptsetup | Een command-line tool in Linux voor het beheren van LUKS-versleutelde volumes. Het wordt gebruikt voor het initialiseren, openen, sluiten en aanpassen van LUKS-partities en sleutels. | | LVM | Logical Volume Manager, een flexibel opslagsysteem in Linux dat gebruikmaakt van virtuele opslagvolumes. LVM wordt vaak bovenop LUKS geplaatst tijdens Linux-installaties voor geavanceerd schijfbeheer. | | fscrypt | Een methode voor directory-level encryptie op Linux-bestandssystemen zoals ext4 en f2fs. Het biedt versleuteling per directory, wat granulariteit en gebruikersspecifieke beveiliging mogelijk maakt. | | VeraCrypt | Een open-source, multi-platform hulpprogramma voor encryptie dat wordt gebruikt voor het versleutelen van opslagapparaten of het creëren van versleutelde volumes, als alternatief voor platform-specifieke oplossingen. |

注册阅读 了解更多

Cover

LSS - Lecture V - NSS and PAM.pdf

词汇表摘要

Summary

# Name Service Switch (NSS) The Name Service Switch (NSS) in Linux is a mechanism that allows administrators to configure the sources from which the system obtains various types of naming and identity information. It defines which services are consulted and in what order for name lookups [4](#page=4). ### 1.1 Configuration of NSS The primary configuration file for NSS is located at `/etc/nsswitch.conf`. This file dictates how the system resolves names for users, groups, hosts, and other network information. The `man nsswitch.conf` and `man nss` commands provide detailed information on its usage [4](#page=4). ### 1.2 Functionality of NSS NSS determines which sources are used to obtain naming service information and the order in which these services are contacted. For instance, it specifies whether user credential information should be retrieved from local files or across a network. It is crucial to note that the program or service that relies on NSS must be specifically programmed to utilize it; this is the responsibility of the program's developer [4](#page=4). ### 1.3 The `/etc/nsswitch.conf` file structure The `/etc/nsswitch.conf` file is organized into sections that define the databases to be queried and the sources to be used for each database [7](#page=7) [8](#page=8). #### 1.3.1 Databases Databases are categories of information that the system needs to look up. Common databases include: * `passwd`: User account information. * `group`: Group information. * `hosts`: Hostname-to-address mappings. * `services`: Network service names and their port numbers. * `networks`: Network names and numbers. * `protocols`: Protocol names and numbers. #### 1.3.2 Sources Sources are the actual locations or mechanisms from which the system can retrieve information for a given database. The NSS configuration specifies the order in which these sources are queried. Common sources include [8](#page=8): * `files`: Information is retrieved from local configuration files (e.g., `/etc/passwd`, `/etc/group`, `/etc/hosts`) [9](#page=9). * `dns`: Information is retrieved using the Domain Name System [10](#page=10). * `nis`: Information is retrieved from Network Information Service (formerly Yellow Pages). * `nisplus`: Information is retrieved from Network Information Service Plus. * `compat`: A compatibility mode that allows older applications to work with NSS [9](#page=9). * `local`: Similar to `files`, but often refers to system-specific local sources. #### 1.3.3 Specifying the order of sources The order in which sources are listed for a database is significant. The system queries them sequentially until the requested information is found or all configured sources have been exhausted. > **Tip:** The `compat` source can be useful for ensuring backward compatibility, but it's generally recommended to use explicit sources like `files` and `dns` for clarity and better control [9](#page=9). ### 1.4 Example: Host name lookup A typical scenario involves looking up a hostname, such as resolving `www.example.com` to its IP address. The `/etc/nsswitch.conf` file would specify the order of services to consult for host lookups [10](#page=10) [5](#page=5). For example, a configuration line might look like this: ``` hosts: files dns ``` This line indicates that when the system needs to look up a hostname: 1. It will first consult the local `files` (typically `/etc/hosts`) [10](#page=10). 2. If the hostname is not found in the local files, it will then query the `dns` [10](#page=10). > **Example:** If `/etc/hosts` contains `192.168.1.10 www.example.com`, and a lookup for `www.example.com` is performed, the system will return `192.168.1.10` directly from the files without querying DNS. If `www.example.com` is not in `/etc/hosts`, then DNS will be queried [10](#page=10). --- # Pluggable Authentication Module (PAM) Pluggable Authentication Modules (PAM) bieden een flexibel en modulair systeem voor authenticatie in Linux, waardoor systeembeheerders de manier waarop gebruikers worden geverifieerd kunnen aanpassen zonder applicaties te hoeven wijzigen [14](#page=14). ### 2.1 PAM-concept en doel PAM staat voor Pluggable Authentication Module en is ontworpen om authenticatiefuncties modulair te maken. Dit stelt systeembeheerders in staat om de authenticatieprocedure voor specifieke situaties aan te passen en zelf te kiezen hoe individuele service-aanbiedende applicaties gebruikers authenticeren. Een belangrijke eigenschap is dat het lokale authenticatiesysteem volledig kan worden geüpgraded zonder de applicaties of services zelf aan te raken. Applicaties moeten specifiek zijn geschreven en gecompileerd om PAM te gebruiken, wat betekent dat ze gelinkt moeten zijn tegen `libpam.so` of deze functionaliteit statisch hebben geïmplementeerd. PAM definieert de authenticatie voor alle services die iets met authenticatie te maken hebben, niet alleen voor de loginprocedure. Voorbeelden hiervan zijn `su`, `chsh`, `sshd`, en meer. Elk systeem waarvoor een PAM-module bestaat, kan voor authenticatie worden gebruikt, zoals smartcards, vingerafdrukken of tweefactorauthenticatie. Het gebruik van PAM kan voor specifieke services worden ingeschakeld of uitgeschakeld in het configuratiebestand van die service, bijvoorbeeld in `/etc/ssh/sshd_config` voor SSH [14](#page=14) [15](#page=15) [16](#page=16). ### 2.2 PAM-modules PAM-modules zijn dynamisch laadbare objectbestanden met de extensie `.so` (shared object). Ontwikkelaars kunnen meerdere dynamische bibliotheken in hun C-code laden. Deze modules worden opgeslagen in specifieke "library" mappen, zoals `/usr/lib64/security/` op RHEL of `/usr/lib/x86_64-linux-gnu/security/` op Debian. Elk PAM-module heeft zijn eigen man-pagina, bijvoorbeeld `man pam_unix` of `man pam_deny` [18](#page=18). #### 2.2.1 Voorbeelden van PAM-modules Er zijn diverse PAM-modules beschikbaar met verschillende functionaliteiten [19](#page=19): * `pam_unix`: Traditionele wachtwoordauthenticatie [19](#page=19). * `pam_deny`: Een module die altijd faalt [19](#page=19). * `pam_permit`: Een module die altijd slaagt [19](#page=19). * `pam_time`: Controleert toegang op basis van tijdstip van de dag [19](#page=19). * `pam_pwquality`: Handhaaft de sterkte van wachtwoorden [19](#page=19). * `pam_rootok`: Controleert of de echte gebruikers-ID nul (root) is [19](#page=19). * `pam_nologin`: Voorkomt dat niet-root gebruikers inloggen als `/etc/nologin` bestaat [19](#page=19). #### 2.2.2 Functionaliteitstypes van PAM-modules PAM-modules kunnen vier verschillende soorten functies bieden [20](#page=20): * **auth (authenticatie)**: Verifieert of de gebruiker is wie hij zegt te zijn [20](#page=20). * **account (account)**: Controleert de status van het gebruikersaccount en of de gebruiker geautoriseerd is om iets te doen [20](#page=20). * **session (sessie)**: Voert acties uit die specifiek zijn voor de huidige sessie van de gebruiker, zoals het weergeven van een bericht van de dag (`/etc/motd`) [20](#page=20). * **password (wachtwoord)**: Wijzigt het wachtwoord of andere inloggegevens van een gebruiker [20](#page=20). Een module kan meerdere functies combineren. Bijvoorbeeld, `pam_unix.so` biedt functies voor `auth`, `account`, `session` en `password`, terwijl `pam_securetty.so` alleen de `auth` functie biedt [21](#page=21). > **Tip:** Controleer de sectie "MODULE TYPES PROVIDED" in de man-pagina van een PAM-module voor een overzicht van de aangeboden functies [21](#page=21). ### 2.3 PAM-configuratiebestanden PAM-configuratiebestanden definiëren de koppeling tussen applicaties (services) en de PAM-modules die de daadwerkelijke authenticatietaken uitvoeren. Deze bestanden worden opgeslagen in de map `/etc/pam.d` of, op oudere systemen, in een enkel bestand `/etc/pam.conf`. Als `/etc/pam.d` bestaat, wordt `/etc/pam.conf` genegeerd. De naam van het configuratiebestand verwijst naar de applicatie waarvoor PAM is geconfigureerd, bijvoorbeeld `/etc/pam.d/login`, `/etc/pam.d/sshd`, etc.. Als een applicatie geen eigen bestand heeft in `/etc/pam.d`, wordt `/etc/pam.d/other` gebruikt [22](#page=22). #### 2.3.1 Gedeelde configuratie Veel services maken gebruik van gemeenschappelijke configuratie die in aparte bestanden wordt geplaatst en vervolgens door andere configuratiebestanden wordt geïncludeerd. Op RHEL is dit vaak `/etc/pam.d/system-auth`. Op Debian zijn de gemeenschappelijke configuratiebestanden `common-auth`, `common-password`, `common-session` en `common-account` [23](#page=23). #### 2.3.2 Structuur van configuratiebestanden Een configuratiebestand in `/etc/pam.d` bestaat uit meerdere regels met een vergelijkbare structuur. Deze regels specificeren de functionaliteitstypes (`auth`, `account`, `password`, `session`) en de PAM-modules die gebruikt moeten worden, samen met de bijbehorende control flags [25](#page=25). De structuur van een regel is: `moduletype control_flag module_path [module_arguments]` [28](#page=28). * `moduletype`: Geeft het type functie aan dat de module uitvoert (bv. `auth`, `account`, `password`, `session`) [25](#page=25). * `control_flag`: Bepaalt hoe het succes of falen van de module de authenticatie beïnvloedt [27](#page=27). * `module_path`: Het pad naar het PAM-modulebestand [28](#page=28). * `module_arguments`: Optionele argumenten die aan de module worden meegegeven [28](#page=28). Het configuratiebestand bepaalt dus welke PAM-functies van welke PAM-modules worden gebruikt en in welke volgorde. Hierdoor worden vier "stacks" gevormd: `auth`, `account`, `password` en `session`, die doorlopen moeten worden [26](#page=26). #### 2.3.3 Control flags Elke PAM-module in een stack retourneert `SUCCESS` of `FAILURE`. De uiteindelijke uitkomst van de stack wordt bepaald door de control flags. Er zijn vier verschillende control flags [27](#page=27) [29](#page=29): * **`required`**: Een `required` module moet slagen voor de authenticatie om te slagen. Als een `required` module faalt, zal de stack uiteindelijk falen, maar de uitvoering van de overige modules in de stack wordt voortgezet [29](#page=29) [32](#page=32). * **`requisite`**: Als een `requisite` module faalt, faalt de authenticatie onmiddellijk. De resterende modules in de stack worden niet uitgevoerd [29](#page=29) [31](#page=31). * **`sufficient`**: Als een `sufficient` module slaagt, slaagt de authenticatie onmiddellijk, mits er geen `required` modules vóór de `sufficient` module hebben gefaald. Als een `sufficient` module faalt, heeft dit geen invloed op de uitkomst; de volgende modules worden geëvalueerd [29](#page=29) [30](#page=30). * **`optional`**: Het succes of falen van een `optional` module heeft geen directe invloed op de uitkomst van de authenticatie. Het resultaat wordt meegenomen in de uiteindelijke beslissing, maar is niet doorslaggevend [29](#page=29) [33](#page=33). > **Voorbeeld:** In `/etc/pam.d/chsh` [34](#page=34): > ``` > auth sufficient pam_rootok.so > auth requisite pam_shells.so > auth sufficient pam_unix.so > auth required pam_deny.so > ``` > De `pam_rootok.so` module wordt als eerste gecontroleerd. Als deze slaagt, is de authenticatie succesvol (`sufficient`). Als `pam_shells.so` faalt, faalt de authenticatie onmiddellijk (`requisite`). Als `pam_unix.so` slaagt, is de authenticatie succesvol (`sufficient`). Ten slotte controleert `pam_deny.so` of de authenticatie moet falen (`required`). #### 2.3.4 Module-specifieke configuratiebestanden Naast de configuratiebestanden in `/etc/pam.d`, die bepalen *welke* PAM-modules te gebruiken, in welke volgorde en met welke gevolgen, zijn er ook configuratiebestanden voor de PAM-modules zelf. Deze worden meestal opgeslagen in `/etc/security` [40](#page=40). * `/etc/security/time.conf`: Configuratie voor de `pam_time.so` module om toegang op specifieke tijden van de dag te beperken [40](#page=40). * `/etc/securetty`: Kan worden aangemaakt voor de `pam_securetty.so` module om een lijst van TTY's op te geven waarvandaan root kan inloggen. Let op: dit is niet meer beschikbaar sinds Debian 11 [40](#page=40). --- # PAM configuratiebestanden en controlemechanismen PAM configuratiebestanden in `/etc/pam.d` bepalen welke PAM-modules worden gebruikt voor specifieke applicaties (services), in welke volgorde, en met welke consequenties, waarbij controlemechanismen (flags) de uitkomst van authenticatie sturen [25](#page=25) [26](#page=26). ### 3.1 Structuur van PAM configuratiebestanden PAM configuratiebestanden, doorgaans gevestigd in de `/etc/pam.d/` directory, bevatten regels die de functionaliteit van PAM voor een specifieke applicatie of service definiëren. Elke regel heeft doorgaans de volgende structuur: `moduletype control_flag module_path [module_arguments...]` [25](#page=25) [26](#page=26) [28](#page=28). * **Moduletype:** Dit geeft aan voor welk doel de module wordt gebruikt. De vier hoofdtypes zijn: * `auth`: Voor authenticatie (verifiëren van de identiteit van de gebruiker) [26](#page=26). * `account`: Voor accountbeheer (controleren of het account geldig is, niet verlopen, etc.) [26](#page=26). * `password`: Voor het beheren van wachtwoorden (wijzigen, updaten) [26](#page=26). * `session`: Voor sessiebeheer (handelingen die aan het begin en einde van een gebruikerssessie moeten worden uitgevoerd, zoals het mounten van home directories of het loggen van sessie-informatie) [26](#page=26). * **Control flag (controlemechanisme):** Dit bepaalt hoe het succes of falen van een specifieke module de algehele uitkomst van de stap in de PAM-stack beïnvloedt. Er zijn vier verschillende controlemechanismen [27](#page=27) [29](#page=29): * `required`: Een `required` module moet slagen voor de hele authenticatie-stap om te slagen. Als een `required` module faalt, faalt de gehele stack uiteindelijk, maar de uitvoering van de stack wordt voortgezet om alle modules te kunnen uitvoeren [29](#page=29) [32](#page=32). * `requisite`: Als een `requisite` module faalt, faalt de authenticatie-stap onmiddellijk. De uitvoering van de stack stopt [29](#page=29) [31](#page=31). * `sufficient`: Als een `sufficient` module succesvol is, slaagt de authenticatie-stap onmiddellijk, *tenzij* er voorgaande `required` modules zijn gefaald. Als er geen voorgaande `required` modules zijn die gefaald zijn, en de `sufficient` module slaagt, wordt de rest van de modules in de stack voor dit moduletype genegeerd [29](#page=29) [30](#page=30). * `optional`: Het succes of falen van een `optional` module heeft geen invloed op de algehele uitkomst van de authenticatie-stap. Deze modules worden vaak gebruikt voor logging of andere informele taken [29](#page=29) [33](#page=33). * **Module Path:** Het pad naar de PAM-module die moet worden geladen (bijvoorbeeld `pam_unix.so`) [28](#page=28). * **Module Arguments:** Optionele argumenten die specifieke gedragingen van de module kunnen beïnvloeden [28](#page=28). Elk van de vier moduletypes (`auth`, `account`, `password`, `session`) vormt een "stack" van modules die in de gedefinieerde volgorde moeten worden doorlopen [26](#page=26). #### 3.1.1 De rol van controlemechanismen bij het bepalen van de uitkomst De controlemechanismen zijn cruciaal voor het bepalen van het uiteindelijke resultaat van een PAM-stap. De interactie tussen deze flags en de resultaten van de individuele modules bepaalt of een gebruiker succesvol wordt geauthenticeerd, of dat de toegang wordt geweigerd [27](#page=27). > **Tip:** Het begrijpen van de interactie tussen `required` en `sufficient` flags is essentieel. Een `sufficient` module kan een succesvolle stap garanderen, tenzij een eerdere `required` module al heeft gefaald. Dit zorgt voor flexibiliteit en robuustheid in het authenticatieproces. ### 3.2 Voorbeeld: `/etc/pam.d/chsh` configuratie Een vereenvoudigd voorbeeld van een PAM-configuratiebestand, specifiek voor de `chsh` (change shell) commando, illustreert de toepassing van deze concepten [34](#page=34) [35](#page=35) [36](#page=36) [37](#page=37) [38](#page=38) [39](#page=39): ``` auth sufficient pam_rootok.so auth requisite pam_shells.so auth sufficient pam_unix.so auth required pam_deny.so ``` Laten we dit voorbeeld analyseren: 1. `auth sufficient pam_rootok.so`: Als `pam_rootok.so` succesvol is (wat betekent dat de gebruiker root is), dan slaagt de `auth`-stap onmiddellijk [35](#page=35) [36](#page=36). 2. `auth requisite pam_shells.so`: Als de gebruiker geen root is, wordt deze regel geëvalueerd. `pam_shells.so` controleert of de gewenste shell van de gebruiker in de lijst van toegestane shells staat. Als deze module faalt (de shell is niet toegestaan), faalt de authenticatie onmiddellijk [37](#page=37). 3. `auth sufficient pam_unix.so`: Als de `pam_shells.so` module succesvol was (en de gebruiker dus root is óf de shell toegestaan is), dan controleert `pam_unix.so` de gebruikersnaam en het wachtwoord tegen de `/etc/shadow` database. Als dit succesvol is, slaagt de `auth`-stap onmiddellijk (omdat het een `sufficient` module is en de vorige `required` modules (of in dit geval `requisite`) succesvol waren) [38](#page=38). 4. `auth required pam_deny.so`: Deze regel wordt alleen bereikt als de voorgaande `sufficient` modules niet tot een onmiddellijk succes hebben geleid. `pam_deny.so` faalt altijd, wat impliceert dat als de vorige stappen het niet al tot succes hebben gebracht, deze regel de authenticatie definitief zal laten falen [39](#page=39). > **Voorbeeld:** Stel, een gebruiker probeert `chsh` te gebruiken. > * Als de gebruiker `root` is: `pam_rootok.so` slaagt (sufficient), dus de `auth`-stap is succesvol [35](#page=35). > * Als de gebruiker geen `root` is maar de gewenste shell is toegestaan: `pam_rootok.so` faalt (en wordt genegeerd omdat het `sufficient` is). `pam_shells.so` slaagt (requisite). Vervolgens slaagt `pam_unix.so` (sufficient) na correcte wachtwoordinvoer, dus de `auth`-stap is succesvol [37](#page=37) [38](#page=38). > * Als de gebruiker geen `root` is en de gewenste shell NIET is toegestaan: `pam_rootok.so` faalt. `pam_shells.so` faalt (requisite), dus de `auth`-stap faalt onmiddellijk [37](#page=37). > * Als om een andere reden de eerdere modules falen, maar de stappen nog niet definitief zijn afgesloten, zal `pam_deny.so` (required) de `auth`-stap laten falen [39](#page=39). ### 3.3 Module-specifieke configuratiebestanden Naast de algemene PAM-configuratiebestanden in `/etc/pam.d`, kunnen individuele PAM-modules hun eigen configuratiebestanden hebben om specifieke instellingen te beheren. Deze bestanden bevinden zich vaak in de `/etc/security/` directory [40](#page=40). * **Voorbeeld:** `/etc/security/time.conf` wordt gebruikt door de `pam_time.so` module om toegang te beperken tot specifieke tijden van de dag [40](#page=40). * **Voorbeeld:** `/etc/securetty` kan worden aangemaakt voor de `pam_securetty.so` module om een lijst van TTY's te specificeren van waaruit `root` mag inloggen (hoewel dit mechanisme sinds Debian 11 niet meer beschikbaar is) [40](#page=40). --- # Praktische toepassing en bronnen Deze sectie behandelt de praktische implementatie van tweefactorauthenticatie (2FA) met Time-based One-Time Passwords (TOTP) en biedt een lijst met nuttige bronnen voor verdere studie. ### 4.1 Implementatie van tweefactorauthenticatie (2FA) met TOTP De implementatie van tweefactorauthenticatie (2FA) maakt gebruik van Time-based One-Time Passwords (TOTP). Dit kan worden gerealiseerd door het gebruik van applicaties op mobiele telefoons, zoals de Google Authenticator app. Daarnaast is de integratie met Pluggable Authentication Modules (PAM) een gebruikelijke methode binnen Linux-omgevingen [41](#page=41). > **Tip:** TOTP-mechanismen genereren codes die slechts een beperkte tijd geldig zijn, wat de veiligheid aanzienlijk verhoogt door het risico op hergebruik van credentials te verminderen. ### 4.2 Bronnen voor verdere studie Voor diepgaandere kennis over Linux en gerelateerde onderwerpen, waaronder PAM, zijn de volgende bronnen aanbevolen: * **Boeken:** * "How Linux works 3rd edition" [42](#page=42). * "Practical Linux Topics" [42](#page=42). * "Beginning the Linux Command Line" [42](#page=42). * **Online documentatie (Linux-PAM):** * De officiële Linux-PAM website biedt uitgebreide documentatie, waaronder: * System Administrator Guide (SAG): http://www.linux-pam.org/Linux-PAM-html//Linux-PAM_SAG.html [42](#page=42). * Application Developer Guide (ADG): http://www.linux-pam.org/Linux-PAM-html//Linux-PAM_ADG.html [42](#page=42). * Module Writer's Guide (MWG): http://www.linux-pam.org/Linux-PAM-html//Linux-PAM_MWG.html [42](#page=42). > **Tip:** De documentatie van Linux-PAM is essentieel voor systeembeheerders en ontwikkelaars die de authenticatiemechanismen van hun systemen willen begrijpen en configureren. --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

Glossary

| Term | Definition | |------|------------| | Name Service Switch (NSS) | Een mechanisme in Linux dat definieert waar en in welke volgorde naamgevingsinformatie, zoals gebruikersgegevens en hostnamen, wordt opgehaald. Het wordt geconfigureerd in het bestand `/etc/nsswitch.conf`. | | Pluggable Authentication Module (PAM) | Een flexibel framework in Linux dat het mogelijk maakt om authenticatiemechanismen modulair te beheren. Het scheidt de authenticatielogica van de applicaties zelf, waardoor systeembeheerders authenticatiemethoden kunnen aanpassen zonder applicaties te hoeven wijzigen. | | `/etc/nsswitch.conf` | Het configuratiebestand dat de Name Service Switch (NSS) beheert. Het specificeert de bronnen (zoals lokale bestanden, DNS, LDAP) die gebruikt moeten worden voor het opzoeken van diverse soorten informatie en de volgorde waarin deze bronnen worden geraadpleegd. | | `libpam.so` | Een gedeelde bibliotheek (shared object) die de functionaliteit van Pluggable Authentication Modules (PAM) bevat. Applicaties die PAM ondersteunen, worden hiertegen gelinkt om de PAM-authenticatie te kunnen gebruiken. | | Authenticatie | Het proces waarbij de identiteit van een gebruiker of entiteit wordt geverifieerd, meestal door middel van een wachtwoord, biometrische gegevens of een ander bewijs van identiteit. | | Account | Verwijst naar de status en rechten van een gebruiker in een systeem, inclusief zaken als vervaldatum, toegestane inlogtijden en toegangsrechten. | | Sessie | De context waarin een gebruiker interactie heeft met het systeem nadat authenticatie is geslaagd. Dit kan bijvoorbeeld het uitvoeren van opdrachten of het weergeven van berichten omvatten. | | Wachtwoord | Een geheime reeks tekens die wordt gebruikt om de identiteit van een gebruiker te verifiëren tijdens het authenticatieproces. PAM kan regels afdwingen voor wachtwoordsterkte en -wijzigingen. | | Dynamisch laadbare objectbestanden | Bestanden die tijdens de uitvoering van een programma in het geheugen kunnen worden geladen. PAM-modules zijn vaak van dit type, wat zorgt voor flexibiliteit en efficiëntie. | | Gedeelde objecten (`.so` bestanden) | Bestanden die code en gegevens bevatten die door meerdere programma"s tegelijk kunnen worden gebruikt. PAM-modules zijn typisch gedeelde objecten die specifieke authenticatietaken uitvoeren. | | Control flags | Parameters in PAM configuratiebestanden die bepalen hoe de uitkomst (succes of falen) van een specifieke PAM-module de algehele authenticatie voor de betreffende taak (auth, account, session, password) beïnvloedt. | | `required` (control flag) | Een controlemechanisme in PAM. Als een `required` module faalt, zal de hele authenticatiestack uiteindelijk falen, maar de uitvoering van de resterende modules in de stack wordt voortgezet. | | `requisite` (control flag) | Een controlemechanisme in PAM. Als een `requisite` module faalt, faalt de hele authenticatiestack onmiddellijk. De uitvoering van verdere modules wordt gestopt. | | `sufficient` (control flag) | Een controlemechanisme in PAM. Als een `sufficient` module slaagt, wordt de authenticatiestack als succesvol beschouwd, zelfs als andere modules falen. De uitvoering van verdere modules wordt gestopt. | | `optional` (control flag) | Een controlemechanisme in PAM. Het succes of falen van een `optional` module heeft geen directe invloed op de algehele uitkomst van de authenticatiestack. | | Tweefactorauthenticatie (2FA) | Een beveiligingsmethode die vereist dat een gebruiker twee verschillende vormen van identificatie levert om toegang te krijgen, wat de beveiliging aanzienlijk verhoogt vergeleken met een enkele authenticatiefactor. | | TOTP (Time-based One-Time Password) | Een algoritme dat een eenmalig wachtwoord genereert dat geldig is voor een beperkte tijd, gebaseerd op een gedeeld geheim en de huidige tijd. Dit is een veelgebruikte methode voor tweefactorauthenticatie. |

注册阅读 了解更多