Hur man installerar ModSecurity 2 med Apache på Debian 12 eller 11

ModSecurity 2 är en viktig webbapplikationsbrandvägg (WAF) för att säkra Apache HTTP-servrar, som erbjuder realtidsövervakning och regelbaserad filtrering. Installerat på en Debian 12 eller 11 Linux-server hjälper ModSecurity till att förhindra SQL-injektioner, cross-site scripting (XSS) och andra attacker. Digitalwave ModSecurity Repository förenklar installationen och säkerställer att du använder den senaste stabila versionen.

För att förbättra säkerheten tillhandahåller OWASP Core Rule Set (CRS) förkonfigurerade regler som riktar in sig på vanliga sårbarheter. Genom att konfigurera det kan administratörer stärka försvaret med minimal manuell konfiguration. Den här guiden visar dig hur du installerar ModSecurity 2 på Debian med hjälp av Digitalwave-förvaret och konfigurerar OWASP CRS för optimalt skydd.

Uppdatera Debians systempaket för installation av ModSecurity 2

Vårt första steg är att se till att vårt Debiansystem är uppdaterat. Att göra det håller alla befintliga paket uppdaterade, säkerställer optimal prestanda och minimerar säkerhetsrisker. Uppnå detta genom att köra följande kommando:

sudo apt update && sudo apt upgrade

När du har uppdaterat ditt system, kontrollera om Apache är installerat. Om inte, använd följande kommando för att installera det:

sudo apt install apache2

Importera ModSecurity Module PPA

Konfigurera det nödvändiga arkivet

Nästa uppgift på vår lista är att installera ModSecurity Apache-modulen. Den version som är tillgänglig i Debians standardförråd kanske inte är den senaste, och att använda den kan leda till omedelbara fel. Istället kommer vi att importera ett arkiv från tredje part för att installera den senaste ModSecurity-modulen för Apache. Detta tredjepartsförråd, som underhålls av Digitalwave, är känt för sina stabila binärer.

Börja med att installera en uppsättning nödvändiga paket:

sudo apt install apt-transport-https lsb-release ca-certificates curl -y

Vi fortsätter sedan med att importera ModSecurity 2 Module PPA-förvaret GPG-nyckel:

curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/null

När du har skaffat GPG-nyckeln lägger du till arkivet till ditt system:

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.list

Prioritering av den nya Apache-modulens PPA-förråd

Med arkivet på plats är det nu nödvändigt att justera APT-policyn för att prioritera detta arkiv för specifika paket relaterade till ModSecurity. Följande kommando åstadkommer detta:

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
EOF

Kör sedan en APT-uppdatering för att återspegla den nyligen importerade källan:

sudo apt update

För att bekräfta inställningarna kan du dessutom bekräfta denna policyändring med följande:

sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3

Installera ModSecurity 2-modulen

Nu när förvaret är klart, fortsätt med installationen av libapache2-mod-security2-modulen:

sudo apt install libapache2-mod-security2

Efter installationen måste modulen vara aktiverad. Använd följande kommando för att uppnå detta:

sudo a2enmod security2

Startar om Apache Service

Slutligen startar vi om Apache-tjänsten för att se till att alla ändringar träder i kraft och att den nyligen tillagda ModSecurity-modulen är korrekt integrerad:

sudo nano /etc/apache2/mods-enabled/security2.conf

Aktivera ModSecurity 2 Module på Apache HTTP

Åtkomst till ModSecurity-konfigurationsfilen

Konfigurationsfilen för Apache ModSecurity finns på /etc/apache2/mods-enabled/security2.conf. Få åtkomst till den här filen med nanotextredigeraren (eller din föredragna textredigerare) med följande kommando:

sudo nano /etc/apache2/mods-enabled/security2.conf

Leta efter raden som lyder:

IncludeOptional /etc/modsecurity/*.conf

Se till att den här raden inte är kommenterad, eftersom den innehåller andra nödvändiga konfigurationsfiler från katalogen /etc/modsecurity. Den ska vara okommenterad som standard.

Ändra ModSecurity 2-konfigurationen

Vi måste byta namn på den modsecurity.conf-recommended konfigurationsfilen till modsecurity.conf för att göra den aktiv. Detta kan göras med följande kommando:

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Nu, låt oss öppna denna nyligen namngivna konfigurationsfil:

sudo nano /etc/modsecurity/modsecurity.conf

ModSecurity-regelmotorn är inställd på DetectionOnly som standard i den här filen. Det betyder att den kommer att identifiera och logga potentiellt skadligt beteende utan att blockera det. För att ändra detta och aktivera ModSecuritys blockeringsmöjligheter, lokalisera SecRuleEngine-linjen (cirka linje 7) och ersätt DetectionOnly med On.

Från:

SecRuleEngine DetectionOnly

Till:

SecRuleEngine On

Justera logginställningar för Apache

Längre ner i konfigurationsfilen hittar du SecAuditLogParts-raden (runt rad 224). Standardinställningen för den här raden är inte helt korrekt; den måste justeras för att logga all transaktionsinformation korrekt.

Ändra:

SecAuditLogParts ABDEFHIJZ

Till:

SecAuditLogParts ABCEFHJKZ

Med dessa ändringar på plats, spara dina ändringar och avsluta redigeraren.

Startar om Apache för att tillämpa ändringar

Vårt sista steg i denna process är att starta om Apache-tjänsten så att våra ändringar av ModSecurity-konfigurationen träder i kraft. Detta görs med följande kommando:

sudo systemctl restart apache2

Installera OWASP Core Rule Set för ModSecurity2

ModSecurity ensamt skyddar inte din webbserver. Det kräver en regeluppsättning för att identifiera potentiella hot och blockera skadlig aktivitet. OWASP (Open Web Application Security Project) Core Rule Set (CRS) är en högt ansedd regeluppsättning som används av olika webbservrar och webbapplikationsbrandväggar (WAF). Genom att distribuera den här regeluppsättningen förses din server med ett robust skydd mot en rad hot som dyker upp på internet.

Innan vi fortsätter är det viktigt att verifiera att du har den senaste versionen av OWASP CRS genom att besöka OWASP Release tag sida. Detta steg säkerställer att du laddar ner och installerar de senaste säkerhetsåtgärderna för din server.

Skapa den överordnade katalogen för OWASP CRS

Låt oss först skapa den ledande överordnade katalogen för OWASP med hjälp av kommandot mkdir:

sudo mkdir /etc/apache2/modsec/

Ladda ner OWASP CRS Archive på Debian

Därefter använder vi kommandot wget för att hämta OWASP CRS 3.3.4-arkivet, som är den stabila versionen i skrivande stund. Kom ihåg att du bör verifiera versionen med hjälp av länken som nämndes tidigare.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zip

Den nattliga byggnaden kan erbjuda mer uppdaterade säkerhetsåtgärder men kan orsaka problem på grund av dess utvecklingsstatus. För nya användare är det tillrådligt att använda den stabila versionen för att undvika potentiella komplikationer.

Obs: Du bör ständigt söka efter uppdateringar; stallreglerna ändras inte varje vecka utan varje kvartal eller om inte en brådskande uppdatering krävs.

Extrahera arkivet

Med arkivet nedladdat kan vi extrahera det i katalogen vi skapade tidigare:

sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsec

Kom ihåg att ändra kommandona baserat på OWASP CRS-versionen du laddade ner.

Konfigurera regeluppsättningen

OWASP CRS har ett exempel på en konfigurationsfil som du bör byta namn på samtidigt som du behåller originalet som en säkerhetskopia. Du kan göra detta med "cp-kommandot":

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Obs: Kom ihåg att ersätta /coreruleset-3.3.4/ med den exakta versionen av OWASP CRS du valde.

Aktivering av reglerna

För att aktivera reglerna, öppna filen /etc/apache2/mods-enabled/security2.conf:

sudo apt install unzip -y

Infoga sedan följande två rader:

Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.conf

Notera: Återigen, se till att du ersätter /coreruleset-3.3.4/ med den exakta versionen av OWASP CRS du har valt, eftersom den coreruleset du kommer att ladda ner troligen kommer att vara nyare än guidens exempel.

Dessutom, kommentera eller ta bort följande rad:

IncludeOptional /usr/share/modsecurity-crs/*.load

När du är klar, spara och avsluta filen:

Startar om Apache för att tillämpa ändringar

Det sista steget är att starta om din Apache-tjänst för att säkerställa att ändringarna träder i kraft:

sudo systemctl restart apache2

Komma igång med OWASP Core Rule Set och ModSecurity 2

OWASP Core Rule Set (CRS) är ett omfattande verktyg med många anpassningsbara alternativ. Dess standardkonfiguration ger omedelbara säkerhetsförbättringar för de flesta servrar utan att det påverkar verkliga besökare eller sökmotoroptimeringsrobotar (SEO). Vi kommer att diskutera några viktiga aspekter av CRS i det här avsnittet, men att utforska konfigurationsfilerna för en fullständig förståelse av alla tillgängliga alternativ är alltid fördelaktigt.

Justera CRS-konfigurationen

Vi inleder genom att öppna filen crs-setup.conf där de flesta av CRS-inställningarna kan ändras:

sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Förstå CRS-poängsystemet

ModSecurity fungerar i två distinkta lägen:

• Avvikelsepoängläge: Rekommenderas för de flesta användare, det här läget tilldelar en "avvikelsepoäng" varje gång en regel matchar. Efter att ha bearbetat både inkommande och utgående regler kontrolleras anomalipoängen och en störande åtgärd utlöses vid behov. Denna åtgärd tar ofta formen av ett 403-fel. Det här läget ger korrekt logginformation och erbjuder större flexibilitet vid inställning av blockeringspolicyer.
• Självständigt läge: I det här läget tillämpas en åtgärd omedelbart när en regel matchas. Även om det kan minska resursanvändningen, erbjuder det mindre flexibilitet och ger mindre informativa granskningsloggar. Regelmatchningsprocessen stoppas när den första regeln uppfylls och den angivna åtgärden utförs.

Förstå paranoianivåer

OWASP CRS definierar fyra paranoianivåer:

• Paranoia nivå 1: Standardnivån är lämplig för de flesta användare.
• Paranoia nivå 2: För avancerade användare.
• Paranoia nivå 3: För expertanvändare.
• Paranoia nivå 4: Endast tillrådligt under extraordinära omständigheter.

Högre paranoianivåer möjliggör ytterligare regler, ökar säkerheten och ökar sannolikheten för att blockera legitim trafik på grund av falska positiva resultat. Att välja en paranoianivå som överensstämmer med din expertis och säkerhetsbehov är viktigt.

Testar OWASP CRS på din server

För att säkerställa att OWASP CRS fungerar korrekt på din server, använd din webbläsare för att komma åt följande URL. Kom ihåg att ersätta "dindomän.com" med din faktiska domän:

https://www.yourdomain.com/index.html?exec=/bin/bash

Om du får ett 403 Förbjudet fel kommer OWASP CRS att fungera som förväntat. Om inte, kan det finnas ett felsteg i installationsprocessen som kräver din uppmärksamhet; det vanligaste problemet kan vara att glömma att ändra DetectionOnly till On eller något liknande.

Adressera falska positiva och anpassade uteslutningsregler

Att hantera falska positiva resultat med ModSecurity och OWASP Core Rule Set (CRS) kan vara en pågående uppgift. Men det robusta försvaret som dessa system erbjuder mot ett brett spektrum av hot gör denna ansträngning väsentlig. För att minimera falska positiva inledningsvis är det tillrådligt att sätta en låg paranoianivå.

Genom att köra regeluppsättningen på en lägre paranoianivå i flera veckor eller till och med månader kan du minska sannolikheten för ett överväldigande antal falska positiva. Detta tillvägagångssätt ger dig tid att bekanta dig med varningarna och lämpliga svar innan du gradvis ökar paranoianivån för strängare säkerhet.

Hantera False Positives i kända applikationer på Debian med OWASP, ModSecurity 2

ModSecurity inkluderar möjligheten att vitlista vissa åtgärder som oavsiktligt kan utlösa falska positiva resultat. Till exempel:

#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"

För att införa vitlistning för applikationer som WordPress, phpBB och phpMyAdmin, avkommentera respektive rad och bibehåll värdet (1). För att förhindra vitlistning av tjänster som inte används, justera värdet till (0).

Den uppdaterade konfigurationen kan se ut så här:

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"

I det här fallet har ovidkommande alternativ tagits bort, vilket lämnar rätt syntax för de konfigurationer du behöver.

Skapa regelundantag innan CRS-implementering

För att skapa anpassade undantag, börja med att byta namn på filen "REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf" med följande kommando:

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.conf

Kom ihåg att varje uteslutningsregel måste ha ett unikt "idnummer" för att undvika fel under Apache2-tjänsttestning.

Till exempel kan vissa "REQUEST_URIs" orsaka falska positiva resultat. Följande exempel illustrerar två sådana fall som involverar Google PageSpeed ​​beacon och WPMU DEV-plugin för 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"

Dessa regler tillåter automatiskt alla webbadresser som börjar med den angivna sökvägen.

Du kan också vitlista specifika IP-adresser:

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"

I den första regeln är en enda IP-adress vitlistad, medan den andra regeln använder "@ipMatch"-direktivet för bredare undernätsmatchning. För att blockera ett subnät eller IP-adress, ersätt helt enkelt "tillåt" med "neka". Denna flexibilitet låter dig skapa detaljerade svarta listor och vitlistor, som kan integreras med Fail2Ban för en förbättrad säkerhetsstrategi.

Inaktivera specifika regler på Debian med OWASP, ModSecurity 2

Istället för att vitlista en hel sökväg är ett annat tillvägagångssätt att inaktivera specifika regler som orsakar ihållande falska positiva resultat. Även om denna metod kräver mer testning, erbjuder den långsiktiga fördelar.

Till exempel, om reglerna 941000 och 942999 i "/admin/"-området utlöser falska positiva resultat för ditt team, kan du hitta regel-ID:t i dina ModSecurity-loggar och inaktivera endast dessa specifika ID:n med kommandot "RemoveByID":

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

Övervaka loggar och identifiera mönster

Kontinuerlig loggövervakning är viktig när du hanterar falska positiva med Apache, ModSecurity och OWASP. Det hjälper till att identifiera mönster som utlöser falska positiva resultat, vilket gör att du kan skapa anpassade regler för att hantera dem.

Till exempel, om specifika regler konsekvent orsakar falska positiva resultat, kan du skapa en uteslutningsregel för att hantera dessa specifika instanser. Detta skräddarsydda tillvägagångssätt säkerställer en effektivare hantering av falska positiva resultat.

Genom att regelbundet granska dina loggar och justera dina regler kan du upprätthålla en säkrare och effektivare miljö för dina applikationer.

Loggrotation för ModSecurity 2

På grund av webbtransaktionernas dynamiska natur kan ModSecurity-loggar växa snabbt, vilket gör effektiv logghantering avgörande. Loggrotation är ett användbart verktyg för att hantera dessa loggar, även om det inte är konfigurerat som standard i ModSecurity. Det här avsnittet guidar dig genom att ställa in loggrotation specifikt för ModSecurity.

Skapa en ModSecurity-rotationsfil

Först måste du skapa en dedikerad fil för ModSecurity-loggrotation. För att göra detta, använd följande kommando för att skapa och öppna en ny fil med namnet modsec:

sudo nano /etc/logrotate.d/modsec

Konfigurera rotationsfilen

Lägg till följande i den nyskapade ModSecurity (modsec) konfigurationsfilen:

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

Den här konfigurationen sparar loggar i 31 dagar, men du kan ändra numret så att det passar dina behov. Om du till exempel ändrar den till 'rotera 7' kommer det att behålla en veckas loggar istället.

Direktivet "dagliga" säkerställer att loggar roteras varje dag, medan "komprimera" sparar utrymme genom att komprimera gamla stockar. Alternativet 'delaycompress' fördröjer komprimeringen tills den andra rotationscykeln, och 'missingok' förhindrar fel om loggfilen saknas. Dessutom säkerställer 'notifempty' att tomma loggfiler inte roteras.

Tips: Daglig loggrotation är att rekommendera för att undvika att hantera alltför stora loggfiler, vilket kan göra analysen mer tidskrävande.

Slutsats

Du har nu installerat ModSecurity 2 på din Debian 12- eller 11-server med hjälp av Digitalwave-förvaret och konfigurerat OWASP Core Rule Set. Med dessa verktyg på plats är din server utrustad för att blockera många vanliga webbapplikationshot.

Kom ihåg att regelbundet uppdatera CRS och övervaka eventuella falska positiva eller missade sårbarheter. Konsekventa tester och justeringar är nyckeln till att upprätthålla en robust säkerhetsinställning.