ModSecurity 2 is een essentiële webapplicatiefirewall (WAF) voor het beveiligen van Apache HTTP-servers, met realtime monitoring en op regels gebaseerde filtering. Geïnstalleerd op een Debian 12 of 11 Linux-server, helpt ModSecurity SQL-injecties, cross-site scripting (XSS) en andere aanvallen te voorkomen. De Digitalwave ModSecurity Repository vereenvoudigt de installatie en zorgt ervoor dat u de nieuwste stabiele versie gebruikt.
Om de beveiliging te verbeteren, biedt de OWASP Core Rule Set (CRS) vooraf geconfigureerde regels die gericht zijn op veelvoorkomende kwetsbaarheden. Door het in te stellen, kunnen beheerders de verdediging versterken met minimale handmatige configuratie. Deze gids laat zien hoe u ModSecurity 2 op Debian installeert met behulp van de Digitalwave-repository en OWASP CRS configureert voor optimale bescherming.
Update Debian System-pakketten voor ModSecurity 2-installatie
Onze eerste stap is om ervoor te zorgen dat ons Debian-systeem wordt bijgewerkt. Hierdoor blijven alle bestaande pakketten up-to-date, worden optimale prestaties gegarandeerd en worden beveiligingsrisico's geminimaliseerd. U bereikt dit door de volgende opdracht uit te voeren:
sudo apt update && sudo apt upgradeControleer na het updaten van uw systeem of Apache is geïnstalleerd. Als dat niet het geval is, gebruikt u de volgende opdracht om het te installeren:
sudo apt install apache2ModSecurity-module PPA importeren
De vereiste repository instellen
De volgende taak op onze lijst is het installeren van de ModSecurity Apache Module. De versie die beschikbaar is in de standaard repositories van Debian is mogelijk niet de nieuwste en het gebruik ervan kan leiden tot onmiddellijke fouten. In plaats daarvan importeren we een third-party repository om de nieuwste ModSecurity Module voor Apache te installeren. Deze third-party repository, onderhouden door Digitalwave, staat bekend om zijn stabiele binaries.
Begin met het installeren van een set benodigde pakketten:
sudo apt install apt-transport-https lsb-release ca-certificates curl -yVervolgens importeren we de ModSecurity 2 Module PPA-repository GPG-sleutel:
curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/nullNadat u de GPG-sleutel hebt verkregen, voegt u de repository toe aan uw systeem:
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.listPrioriteit geven aan de nieuwe Apache Module PPA-repository
Nu de repository op zijn plaats is, is het nodig om het APT-beleid aan te passen om deze repository te prioriteren voor specifieke pakketten gerelateerd aan ModSecurity. De volgende opdracht bereikt dit:
cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOFVoer vervolgens een APT-update uit om de nieuw geïmporteerde bron te weerspiegelen:
sudo apt updateOm uw voorkeuren te bevestigen, kunt u deze beleidswijziging als volgt bevestigen:
sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3
ModSecurity 2-module installeren
Nu de repository gereed is, kunt u doorgaan met de installatie van de module libapache2-mod-security2:
sudo apt install libapache2-mod-security2Na de installatie moet de module worden ingeschakeld. Gebruik hiervoor de volgende opdracht:
sudo a2enmod security2Apache-service opnieuw opstarten
Ten slotte starten we de Apache-service opnieuw op om er zeker van te zijn dat alle wijzigingen zijn doorgevoerd en dat de nieuw toegevoegde ModSecurity-module correct is geïntegreerd:
sudo nano /etc/apache2/mods-enabled/security2.confModSecurity 2-module inschakelen op Apache HTTP
Toegang tot het ModSecurity-configuratiebestand
Het configuratiebestand voor Apache ModSecurity is te vinden op /etc/apache2/mods-enabled/security2.conf. Open dit bestand met de nano-teksteditor (of uw favoriete teksteditor) met de volgende opdracht:
sudo nano /etc/apache2/mods-enabled/security2.confZoek naar de regel die luidt:
IncludeOptional /etc/modsecurity/*.confZorg ervoor dat deze regel niet is gecommentarieerd, aangezien het andere benodigde configuratiebestanden uit de directory /etc/modsecurity bevat. Standaard zou het niet gecommentarieerd moeten zijn.
De ModSecurity 2-configuratie wijzigen
We moeten het modsecurity.conf-recommended configuratiebestand hernoemen naar modsecurity.conf om het actief te maken. Dit kan met de volgende opdracht:
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.confLaten we nu het nieuwe configuratiebestand openen:
sudo nano /etc/modsecurity/modsecurity.confDe ModSecurity-regelengine is standaard ingesteld op DetectionOnly in dit bestand. Dit betekent dat het potentieel kwaadaardig gedrag identificeert en registreert zonder het te blokkeren. Om dit te wijzigen en de blokkeringsmogelijkheden van ModSecurity in te schakelen, zoekt u de regel SecRuleEngine (rond regel 7) en vervangt u DetectionOnly door On.
Van:
SecRuleEngine DetectionOnlyNaar:
SecRuleEngine On
Logboekinstellingen voor Apache aanpassen
Verderop in het configuratiebestand vindt u de regel SecAuditLogParts (rond regel 224). De standaardinstelling voor deze regel is niet helemaal correct; deze moet worden aangepast om alle transactiegegevens nauwkeurig te loggen.
Wijziging:
SecAuditLogParts ABDEFHIJZNaar:
SecAuditLogParts ABCEFHJKZNadat u deze wijzigingen hebt doorgevoerd, slaat u uw wijzigingen op en sluit u de editor.
Apache opnieuw opstarten om wijzigingen toe te passen
Onze laatste stap in dit proces is het opnieuw opstarten van de Apache-service, zodat onze wijzigingen in de ModSecurity-configuratie van kracht worden. Dit wordt bereikt met de volgende opdracht:
sudo systemctl restart apache2Installeer OWASP Core Rule Set voor ModSecurity2
ModSecurity alleen beschermt uw webserver niet. Het vereist een regelset om potentiële bedreigingen te identificeren en schadelijke activiteiten te blokkeren. De OWASP (Open Web Application Security Project) Core Rule Set (CRS) is een zeer gerespecteerde regelset die wordt gebruikt door verschillende webservers en Web Application Firewalls (WAF's). Door deze regelset te implementeren, wordt uw server voorzien van robuuste bescherming tegen een reeks bedreigingen die opduiken op internet.
Voordat we verdergaan, is het essentieel om te controleren of u de nieuwste versie van OWASP CRS hebt door de volgende website te bezoeken: OWASP Release-tagpaginaMet deze stap zorgt u ervoor dat u de meest recente beveiligingsmaatregelen voor uw server downloadt en installeert.
De bovenliggende map voor OWASP CRS maken
Laten we eerst de leidende bovenliggende map voor OWASP maken met behulp van de opdracht mkdir:
sudo mkdir /etc/apache2/modsec/Download OWASP CRS-archief op Debian
Vervolgens gebruiken we de wget-opdracht om het OWASP CRS 3.3.4-archief op te halen, wat de stabiele versie is op het moment van schrijven. Vergeet niet dat u de versie moet verifiëren met behulp van de eerder genoemde link.
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zipDe nightly build biedt mogelijk meer up-to-date beveiligingsmaatregelen, maar kan problemen veroorzaken vanwege de ontwikkelingsstatus. Voor nieuwe gebruikers is het raadzaam om de stabiele versie te gebruiken om mogelijke complicaties te voorkomen.
Let op: Controleer voortdurend of er updates zijn. De stabiele regels worden niet wekelijks gewijzigd, maar elk kwartaal, tenzij er een dringende update nodig is.
Het archief extraheren
Nadat we het archief hebben gedownload, kunnen we het uitpakken in de map die we eerder hebben gemaakt:
sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsecVergeet niet de opdrachten aan te passen op basis van de OWASP CRS-versie die u hebt gedownload.
De regelset configureren
De OWASP CRS heeft een voorbeeldconfiguratiebestand dat u moet hernoemen terwijl u het origineel als back-up behoudt. U kunt dit doen met de 'cp-opdracht':
sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.confLet op: Vergeet niet om /coreruleset-3.3.4/ te vervangen door de exacte versie van de OWASP CRS die u hebt gekozen.
De regels inschakelen
Om de regels te activeren, opent u het bestand /etc/apache2/mods-enabled/security2.conf:
sudo apt install unzip -yVoeg vervolgens de volgende twee regels in:
Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.confLet op: zorg ervoor dat u /coreruleset-3.3.4/ vervangt door de exacte versie van OWASP CRS die u hebt geselecteerd, aangezien de coreruleset die u downloadt waarschijnlijk nieuwer is dan het voorbeeld in de gids.
U kunt bovendien de volgende regel uitcommentariëren of verwijderen:
IncludeOptional /usr/share/modsecurity-crs/*.loadZodra u klaar bent, slaat u het bestand op en sluit u het af:
Apache opnieuw opstarten om wijzigingen toe te passen
De laatste stap is het opnieuw opstarten van uw Apache-service om ervoor te zorgen dat de wijzigingen van kracht worden:
sudo systemctl restart apache2Aan de slag met OWASP Core Rule Set en ModSecurity 2
De OWASP Core Rule Set (CRS) is een uitgebreide tool met talloze aanpasbare opties. De standaardconfiguratie biedt onmiddellijke beveiligingsverbeteringen voor de meeste servers zonder echte bezoekers of Search Engine Optimization (SEO) bots te beïnvloeden. We zullen in deze sectie een paar belangrijke aspecten van de CRS bespreken, maar het verkennen van de configuratiebestanden voor een volledig begrip van alle beschikbare opties is altijd nuttig.
De CRS-configuratie aanpassen
We starten door het bestand crs-setup.conf te openen, waarin de meeste CRS-instellingen kunnen worden gewijzigd:
sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.confHet CRS-scoresysteem begrijpen
ModSecurity werkt in twee verschillende modi:
- Anomaly Scoring Mode: Aanbevolen voor de meeste gebruikers, deze modus kent een 'anomaliescore' toe telkens wanneer een regel overeenkomt. Na het verwerken van zowel inkomende als uitgaande regels, wordt de anomaliescore gecontroleerd en wordt indien nodig een verstorende actie geactiveerd. Deze actie neemt vaak de vorm aan van een 403-fout. Deze modus biedt nauwkeurige loginformatie en biedt meer flexibiliteit bij het instellen van blokkeringsbeleid.
- Self-Contained Mode: In deze modus wordt een actie direct toegepast wanneer een regel wordt gematcht. Hoewel het resourcegebruik kan verminderen, biedt het minder flexibiliteit en levert het minder informatieve auditlogs op. Het regelmatchingproces stopt wanneer aan de eerste regel wordt voldaan en de opgegeven actie wordt uitgevoerd.
Begrijpen van paranoia-niveaus
De OWASP CRS definieert vier niveaus van paranoia:
- Paranoia niveau 1: Het standaardniveau is geschikt voor de meeste gebruikers.
- Paranoia niveau 2: voor gevorderde gebruikers.
- Paranoia niveau 3: voor ervaren gebruikers.
- Paranoia niveau 4: Alleen aan te raden onder buitengewone omstandigheden.
Hogere paranoia-niveaus maken extra regels mogelijk, verhogen de beveiliging en vergroten de kans op het blokkeren van legitiem verkeer vanwege valse positieven. Het kiezen van een paranoia-niveau dat aansluit bij uw expertise en beveiligingsbehoeften is essentieel.
OWASP CRS testen op uw server
Om er zeker van te zijn dat de OWASP CRS correct werkt op uw server, gebruikt u uw internetbrowser om toegang te krijgen tot de volgende URL. Vergeet niet om “uwdomein.com” te vervangen door uw werkelijke domein:
https://www.yourdomain.com/index.html?exec=/bin/bashAls u een 403 Forbidden-fout ontvangt, functioneert OWASP CRS zoals verwacht. Als dat niet het geval is, is er mogelijk een misstap in het installatieproces die uw aandacht vereist; het meest voorkomende probleem kan zijn dat u vergeet DetectionOnly op On te zetten of iets dergelijks.
Valse positieven aanpakken en aangepaste uitsluitingsregels
Het beheren van false positives met ModSecurity en de OWASP Core Rule Set (CRS) kan een doorlopende taak zijn. De robuuste verdediging die deze systemen bieden tegen een breed scala aan bedreigingen maakt deze inspanning echter essentieel. Om false positives in eerste instantie te minimaliseren, is het raadzaam om een laag paranoianiveau in te stellen.
Door de regelset op een lager paranoianiveau te laten draaien gedurende meerdere weken of zelfs maanden, kunt u de kans op een overweldigend aantal vals-positieve resultaten verkleinen. Deze aanpak geeft u de tijd om uzelf vertrouwd te maken met de waarschuwingen en de juiste reacties voordat u het paranoianiveau geleidelijk verhoogt voor strengere beveiliging.
Het beheren van valse positieven in bekende applicaties op Debian met OWASP, ModSecurity 2
ModSecurity bevat de mogelijkheid om bepaalde acties die onbedoeld false positives kunnen triggeren, op de whitelist te zetten. Bijvoorbeeld:
#SecAction \
# "id:900130,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:tx.crs_exclusions_cpanel=1,\
# setvar:tx.crs_exclusions_dokuwiki=1,\
# setvar:tx.crs_exclusions_drupal=1,\
# setvar:tx.crs_exclusions_nextcloud=1,\
# setvar:tx.crs_exclusions_phpbb=1,\
# setvar:tx.crs_exclusions_phpmyadmin=1,\
# setvar:tx.crs_exclusions_wordpress=1,\
# setvar:tx.crs_exclusions_xenforo=1"
Om whitelisting in te schakelen voor applicaties zoals WordPress, phpBB en phpMyAdmin, verwijdert u de commentaartekens van de betreffende regels en behoudt u de waarde (1). Om te voorkomen dat services die niet in gebruik zijn op de whitelist worden gezet, past u de waarde aan naar (0).
De bijgewerkte configuratie kan er als volgt uitzien:
SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_phpbb=1,\
setvar:tx.crs_exclusions_phpmyadmin=1,\
setvar:tx.crs_exclusions_wordpress=1"In dit geval zijn overbodige opties verwijderd, zodat de juiste syntaxis voor de gewenste configuraties behouden blijft.
Regeluitsluitingen maken vóór de CRS-implementatie
Om aangepaste uitsluitingen te maken, begint u met het hernoemen van het bestand “REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf” met behulp van de volgende opdracht:
sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.confHoud er rekening mee dat elke uitsluitingsregel een uniek 'id-nummer' moet hebben om fouten tijdens het testen van de Apache2-service te voorkomen.
Sommige “REQUEST_URI’s” kunnen bijvoorbeeld valse positieven veroorzaken. Het volgende voorbeeld illustreert twee van dergelijke gevallen met betrekking tot Google PageSpeed beacon en de WPMU DEV plugin voor WordPress:
SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"
SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"Deze regels staan automatisch alle URL's toe die beginnen met het opgegeven pad.
U kunt ook specifieke IP-adressen op de witte lijst zetten:
SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"In de eerste regel wordt één IP-adres op de whitelist gezet, terwijl de tweede regel de '@ipMatch'-richtlijn gebruikt voor bredere subnetmatching. Om een subnet of IP-adres te blokkeren, vervangt u 'allow' eenvoudigweg door 'deny'. Deze flexibiliteit stelt u in staat om gedetailleerde blacklists en whitelists te maken, die kunnen worden geïntegreerd met Fail2Ban voor een verbeterde beveiligingsstrategie.
Specifieke regels op Debian uitschakelen met OWASP, ModSecurity 2
In plaats van een heel pad op de whitelist te zetten, is een andere aanpak om specifieke regels uit te schakelen die aanhoudende false positives veroorzaken. Hoewel deze methode meer testen vereist, biedt het voordelen op de lange termijn.
Als bijvoorbeeld de regels 941000 en 942999 in het gebied “/admin/” valse positieven voor uw team veroorzaken, kunt u de regel-ID in uw ModSecurity-logboeken vinden en alleen die specifieke ID's uitschakelen met de opdracht “RemoveByID”:
SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"Monitoringlogboeken en identificatiepatronen
Continue logbewaking is essentieel bij het verwerken van false positives met Apache, ModSecurity en OWASP. Het helpt patronen te identificeren die false positives triggeren, zodat u aangepaste regels kunt maken om deze aan te pakken.
Als specifieke regels bijvoorbeeld consequent valse positieven veroorzaken, kunt u een uitsluitingsregel opstellen om deze specifieke gevallen te behandelen. Deze op maat gemaakte aanpak zorgt voor effectiever beheer van valse positieven.
Door uw logboeken regelmatig te controleren en uw regels aan te passen, kunt u een veiligere en efficiëntere omgeving voor uw toepassingen creëren.
Logrotatie voor ModSecurity 2
Vanwege de dynamische aard van webtransacties kunnen ModSecurity-logs snel groeien, waardoor effectief logbeheer cruciaal is. Logrotatie is een handig hulpmiddel voor het beheren van deze logs, hoewel het niet standaard is geconfigureerd in ModSecurity. Deze sectie begeleidt u bij het instellen van logrotatie specifiek voor ModSecurity.
Een ModSecurity-rotatiebestand maken
Eerst moet u een speciaal bestand maken voor ModSecurity logrotatie. Gebruik hiervoor de volgende opdracht om een nieuw bestand met de naam modsec te maken en te openen:
sudo nano /etc/logrotate.d/modsecHet rotatiebestand configureren
Voeg het volgende toe in het nieuw gemaakte ModSecurity (modsec) configuratiebestand:
/var/log/modsec_audit.log
{
rotate 31
daily
missingok
compress
delaycompress
notifempty
}Deze configuratie bewaart logs gedurende 31 dagen, maar u kunt het aantal aanpassen aan uw behoeften. Als u het bijvoorbeeld verandert in 'rotate 7', worden logs van een week bewaard.
De richtlijn 'daily' zorgt ervoor dat logs elke dag worden geroteerd, terwijl 'compress' ruimte bespaart door oude logs te comprimeren. De optie 'delaycompress' stelt compressie uit tot de tweede rotatiecyclus en 'missingok' voorkomt fouten als het logbestand ontbreekt. Bovendien zorgt 'notifempty' ervoor dat lege logbestanden niet worden geroteerd.
Tip: Het is raadzaam om het logboek dagelijks te roteren. Zo voorkomt u dat u te maken krijgt met te grote logbestanden, omdat de analyse hierdoor meer tijd kan kosten.
Conclusie
U hebt ModSecurity 2 nu geïnstalleerd op uw Debian 12 of 11 server met behulp van de Digitalwave repository en de OWASP Core Rule Set geconfigureerd. Met deze tools is uw server uitgerust om veelvoorkomende webapplicatiebedreigingen te blokkeren.
Vergeet niet om de CRS regelmatig bij te werken en te controleren op eventuele false positives of gemiste kwetsbaarheden. Consistente tests en aanpassingen zijn essentieel voor het onderhouden van een robuuste beveiligingsopstelling.
