ModSecurity 2 er en essentiel webapplikationsfirewall (WAF) til sikring af Apache HTTP-servere, der tilbyder overvågning i realtid og regelbaseret filtrering. Installeret på en Debian 12 eller 11 Linux-server hjælper ModSecurity med at forhindre SQL-injektioner, cross-site scripting (XSS) og andre angreb. Digitalwave ModSecurity Repository forenkler installationen og sikrer, at du bruger den seneste stabile version.
For at øge sikkerheden giver OWASP Core Rule Set (CRS) forudkonfigurerede regler rettet mod almindelige sårbarheder. Opsætning af det giver administratorer mulighed for at styrke forsvaret med minimal manuel konfiguration. Denne guide viser dig, hvordan du installerer ModSecurity 2 på Debian ved hjælp af Digitalwave-depotet og konfigurerer OWASP CRS for optimal beskyttelse.
Opdater Debian-systempakker til installation af ModSecurity 2
Vores første skridt er at sikre, at vores Debian-system er opdateret. Dette holder alle eksisterende pakker opdaterede, sikrer optimal ydeevne og minimerer sikkerhedsrisici. Opnå dette ved at køre følgende kommando:
sudo apt update && sudo apt upgradeEfter opdatering af dit system skal du kontrollere, om Apache er installeret. Hvis ikke, brug følgende kommando til at installere det:
sudo apt install apache2Importer ModSecurity Module PPA
Opsætning af det påkrævede lager
Den næste opgave på vores liste er at installere ModSecurity Apache-modulet. Den version, der er tilgængelig i Debians standardlagre, er muligvis ikke den nyeste, og brugen af den kan føre til øjeblikkelige fejl. I stedet importerer vi et tredjepartslager for at installere det seneste ModSecurity-modul til Apache. Dette tredjepartsdepot, vedligeholdt af Digitalwave, er kendt for sine stabile binære filer.
Begynd med at installere et sæt nødvendige pakker:
sudo apt install apt-transport-https lsb-release ca-certificates curl -yVi fortsætter derefter med at importere ModSecurity 2 Module PPA-lageret GPG nøgle:
curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/nullNår du har erhvervet GPG-nøglen, skal du tilføje lageret til dit 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.listPrioritering af det nye Apache Module PPA Repository
Med lageret på plads er det nu nødvendigt at justere APT-politikken for at prioritere dette lager for specifikke pakker relateret til ModSecurity. Følgende kommando udfører dette:
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
EOFKør derefter en APT-opdatering for at afspejle den nyligt importerede kilde:
sudo apt updateDerudover kan du bekræfte denne politikændring med følgende for at bekræfte præferencerne:
sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3
Installer ModSecurity 2-modulet
Nu hvor depotet er klar, fortsæt med installationen af libapache2-mod-security2-modulet:
sudo apt install libapache2-mod-security2Efter installationen skal modulet være aktiveret. Brug følgende kommando for at opnå dette:
sudo a2enmod security2Genstarter Apache Service
Til sidst genstarter vi Apache-tjenesten for at sikre, at alle ændringer træder i kraft, og at det nyligt tilføjede ModSecurity-modul er korrekt integreret:
sudo nano /etc/apache2/mods-enabled/security2.confAktiver ModSecurity 2 Module på Apache HTTP
Adgang til ModSecurity-konfigurationsfilen
Konfigurationsfilen for Apache ModSecurity kan findes på /etc/apache2/mods-enabled/security2.conf. Få adgang til denne fil ved hjælp af nano-teksteditoren (eller din foretrukne teksteditor) med følgende kommando:
sudo nano /etc/apache2/mods-enabled/security2.confSe efter linjen, der lyder:
IncludeOptional /etc/modsecurity/*.confSørg for, at denne linje ikke er kommenteret, da den indeholder andre nødvendige konfigurationsfiler fra mappen /etc/modsecurity. Den skal som standard være ukommenteret.
Ændring af ModSecurity 2-konfigurationen
Vi skal omdøbe den modsecurity.conf-recommended konfigurationsfil til modsecurity.conf for at gøre den aktiv. Dette kan gøres med følgende kommando:
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.confLad os nu åbne denne nyligt navngivne konfigurationsfil:
sudo nano /etc/modsecurity/modsecurity.confModSecurity-regelmotoren er som standard indstillet til DetectionOnly i denne fil. Det betyder, at den vil identificere og logge potentielt ondsindet adfærd uden at blokere den. For at ændre dette og aktivere ModSecuritys blokeringsfunktioner skal du finde SecRuleEngine-linjen (omkring linje 7) og erstatte DetectionOnly med On.
Fra:
SecRuleEngine DetectionOnlyTil:
SecRuleEngine On
Justering af logindstillinger for Apache
Længere nede i konfigurationsfilen finder du SecAuditLogParts-linjen (omkring linje 224). Standardindstillingen for denne linje er ikke helt korrekt; det skal justeres for at logge alle transaktionsoplysninger nøjagtigt.
Forandring:
SecAuditLogParts ABDEFHIJZTil:
SecAuditLogParts ABCEFHJKZMed disse ændringer på plads, gem dine ændringer og forlad editoren.
Genstarter Apache for at anvende ændringer
Vores sidste trin i denne proces er at genstarte Apache-tjenesten, så vores ændringer af ModSecurity-konfigurationen træder i kraft. Dette opnås ved hjælp af følgende kommando:
sudo systemctl restart apache2Installer OWASP Core Rule Set for ModSecurity2
ModSecurity alene beskytter ikke din webserver. Det kræver et regelsæt til at identificere potentielle trusler og blokere ondsindet aktivitet. OWASP (Open Web Application Security Project) Core Rule Set (CRS) er et højt anset regelsæt, der bruges af forskellige webservere og Web Application Firewalls (WAF'er). Implementering af dette regelsæt giver din server robust beskyttelse mod en række trusler, der dukker op på internettet.
Før vi fortsætter, er det vigtigt at bekræfte, at du har den seneste version af OWASP CRS ved at besøge OWASP Frigiv tag-side. Dette trin sikrer, at du downloader og installerer de mest opdaterede sikkerhedsforanstaltninger til din server.
Oprettelse af det overordnede bibliotek for OWASP CRS
Lad os først oprette den førende overordnede mappe til OWASP ved hjælp af mkdir-kommandoen:
sudo mkdir /etc/apache2/modsec/Download OWASP CRS-arkiv på Debian
Dernæst bruger vi wget-kommandoen til at hente OWASP CRS 3.3.4-arkivet, som er den stabile version i skrivende stund. Husk, at du skal verificere versionen ved at bruge det tidligere nævnte link.
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zipDen natlige build kan tilbyde mere opdaterede sikkerhedsforanstaltninger, men kan forårsage problemer på grund af dens udviklingsstatus. For nye brugere er det tilrådeligt at bruge den stabile version for at undgå potentielle komplikationer.
Bemærk: Du bør konstant tjekke for opdateringer; staldreglerne ændres ikke ugentligt, men hvert kvartal eller medmindre en akut opdatering er påkrævet.
Udpakning af arkivet
Med arkivet downloadet, kan vi udtrække det i den mappe, vi oprettede tidligere:
sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsecHusk at ændre kommandoerne baseret på den OWASP CRS-version, du downloadede.
Konfiguration af regelsættet
OWASP CRS har en eksempelkonfigurationsfil, som du skal omdøbe, mens du beholder originalen som en sikkerhedskopi. Du kan gøre dette ved at bruge 'cp-kommandoen':
sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.confBemærk: Husk at erstatte /coreruleset-3.3.4/ med den nøjagtige version af den OWASP CRS du valgte.
Aktivering af reglerne
For at aktivere reglerne skal du åbne filen /etc/apache2/mods-enabled/security2.conf:
sudo apt install unzip -yIndsæt derefter følgende to linjer:
Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.confBemærk: Sørg igen for, at du erstatter /coreuleset-3.3.4/ med den nøjagtige version af OWASP CRS, du har valgt, da det coreruleset, du vil downloade, højst sandsynligt vil være nyere end vejledningens eksempel.
Derudover skal du kommentere eller fjerne følgende linje:
IncludeOptional /usr/share/modsecurity-crs/*.loadNår du er færdig, gem og afslut filen:
Genstarter Apache for at anvende ændringer
Det sidste trin er at genstarte din Apache-tjeneste for at sikre, at ændringerne træder i kraft:
sudo systemctl restart apache2Kom godt i gang med OWASP Core Rule Set og ModSecurity 2
OWASP Core Rule Set (CRS) er et omfattende værktøj med adskillige tilpasningsmuligheder. Dens standardkonfiguration giver øjeblikkelige sikkerhedsforbedringer for de fleste servere uden at påvirke ægte besøgende eller søgemaskineoptimering (SEO) bots. Vi vil diskutere et par væsentlige aspekter af CRS i dette afsnit, men det er altid en fordel at udforske konfigurationsfilerne for at få en fuldstændig forståelse af alle tilgængelige muligheder.
Justering af CRS-konfigurationen
Vi starter ved at åbne filen crs-setup.conf, hvor de fleste af CRS-indstillingerne kan ændres:
sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.confForståelse af CRS Scoring System
ModSecurity fungerer i to forskellige tilstande:
- Anomali-scoringstilstand: Anbefalet til de fleste brugere, denne tilstand tildeler en 'anomali-score', hver gang en regel matcher. Efter behandling af både indgående og udgående regler kontrolleres anomali-scoren, og en forstyrrende handling udløses om nødvendigt. Denne handling har ofte form af en 403-fejl. Denne tilstand giver nøjagtige logoplysninger og giver større fleksibilitet ved indstilling af blokeringspolitikker.
- Selvstændig tilstand: I denne tilstand anvendes en handling øjeblikkeligt, når en regel matches. Selvom det kan reducere ressourceforbruget, giver det mindre fleksibilitet og giver mindre informative revisionslogfiler. Regelmatchningsprocessen stopper, når den første regel er opfyldt, og den angivne handling udføres.
Forståelse af paranoianiveauer
OWASP CRS definerer fire paranoianiveauer:
- Paranoia niveau 1: Standardniveauet er velegnet til de fleste brugere.
- Paranoia niveau 2: For avancerede brugere.
- Paranoia niveau 3: For ekspertbrugere.
- Paranoia niveau 4: Kun tilrådeligt under ekstraordinære omstændigheder.
Højere paranoianiveauer muliggør yderligere regler, øger sikkerheden og øger sandsynligheden for at blokere lovlig trafik på grund af falske positiver. Det er vigtigt at vælge et paranoia-niveau, der stemmer overens med din ekspertise og sikkerhedsbehov.
Test af OWASP CRS på din server
For at sikre, at OWASP CRS fungerer korrekt på din server, skal du bruge din internetbrowser til at få adgang til følgende URL. Husk at erstatte "ditdomæne.com" med dit faktiske domæne:
https://www.yourdomain.com/index.html?exec=/bin/bashHvis du modtager en 403 Forbidden fejl, vil OWASP CRS fungere som forventet. Hvis ikke, kan der være et fejltrin i opsætningsprocessen, som kræver din opmærksomhed; det mest almindelige problem kan være at glemme at ændre DetectionOnly til On eller noget lignende.
Håndter falske positiver og tilpassede ekskluderingsregler
Håndtering af falske positiver med ModSecurity og OWASP Core Rule Set (CRS) kan være en løbende opgave. Det robuste forsvar disse systemer tilbyder mod en bred vifte af trusler gør imidlertid denne indsats afgørende. For at minimere falske positive indledningsvis, er det tilrådeligt at indstille et lavt paranoianiveau.
Ved at køre regelsættet på et lavere paranoia-niveau i flere uger eller endda måneder, kan du reducere sandsynligheden for et overvældende antal falske positive. Denne tilgang giver dig tid til at sætte dig ind i advarslerne og de passende svar, før du gradvist øger paranoia-niveauet for mere stringent sikkerhed.
Håndtering af falske positiver i kendte applikationer på Debian med OWASP, ModSecurity 2
ModSecurity inkluderer muligheden for at hvidliste visse handlinger, der utilsigtet kan udløse falske positiver. For eksempel:
#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"
For at indføre whitelisting for applikationer som WordPress, phpBB og phpMyAdmin skal du fjerne kommentarer til de respektive linjer og bevare værdien (1). For at forhindre hvidlisten af tjenester, der ikke er i brug, skal du justere værdien til (0).
Den opdaterede konfiguration kunne se ud som følger:
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 dette tilfælde er uvedkommende indstillinger blevet fjernet, hvilket efterlader den korrekte syntaks for de konfigurationer, du har brug for.
Oprettelse af regeludelukkelser før implementering af CRS
For at oprette tilpassede ekskluderinger skal du begynde med at omdøbe filen "REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf" ved hjælp af følgende 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.confHusk, at hver udelukkelsesregel skal have et unikt 'idnummer' for at undgå fejl under Apache2-servicetest.
For eksempel kan nogle "REQUEST_URI'er" forårsage falske positiver. Følgende eksempel illustrerer to sådanne tilfælde, der involverer Google PageSpeed-beacon og WPMU DEV-plugin til 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"Disse regler tillader automatisk enhver URL, der begynder med den angivne sti.
Du kan også hvidliste specifikke 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ørste regel er en enkelt IP-adresse hvidlistet, mens den anden regel bruger '@ipMatch'-direktivet til bredere undernetmatchning. For at blokere et undernet eller en IP-adresse skal du blot erstatte 'allow' med 'deny'. Denne fleksibilitet giver dig mulighed for at oprette detaljerede sortlister og hvidlister, som kan integreres med Fail2Ban for en forbedret sikkerhedsstrategi.
Deaktivering af specifikke regler på Debian med OWASP, ModSecurity 2
I stedet for at hvidliste en hel sti, er en anden tilgang at deaktivere specifikke regler, der forårsager vedvarende falske positiver. Selvom denne metode kræver flere tests, giver den langsigtede fordele.
For eksempel, hvis regler 941000 og 942999 i "/admin/"-området udløser falske positiver for dit team, kan du finde regel-id'et i dine ModSecurity-logfiler og kun deaktivere de specifikke id'er ved hjælp af kommandoen "RemoveByID":
SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"Overvågning af logs og identifikation af mønstre
Kontinuerlig logovervågning er afgørende, når du håndterer falske positiver med Apache, ModSecurity og OWASP. Det hjælper med at identificere mønstre, der udløser falske positiver, så du kan oprette tilpassede regler for at adressere dem.
For eksempel, hvis specifikke regler konsekvent forårsager falske positiver, kan du lave en ekskluderingsregel til at håndtere disse specifikke tilfælde. Denne skræddersyede tilgang sikrer en mere effektiv håndtering af falske positiver.
Ved regelmæssigt at gennemgå dine logfiler og justere dine regler kan du opretholde et mere sikkert og effektivt miljø for dine applikationer.
Log Rotation for ModSecurity 2
På grund af webtransaktioners dynamiske natur kan ModSecurity-logfiler vokse hurtigt, hvilket gør effektiv logstyring afgørende. Logrotation er et nyttigt værktøj til at administrere disse logfiler, selvom det ikke er konfigureret som standard i ModSecurity. Dette afsnit vil guide dig gennem opsætning af logrotation specifikt for ModSecurity.
Oprettelse af en ModSecurity-rotationsfil
Først skal du oprette en dedikeret fil til ModSecurity-logrotation. For at gøre dette skal du bruge følgende kommando til at oprette og åbne en ny fil med navnet modsec:
sudo nano /etc/logrotate.d/modsecKonfiguration af rotationsfilen
Tilføj følgende i den nyoprettede ModSecurity (modsec)-konfigurationsfil:
/var/log/modsec_audit.log
{
rotate 31
daily
missingok
compress
delaycompress
notifempty
}Denne konfiguration gemmer logfiler i 31 dage, men du kan ændre nummeret, så det passer til dine behov. Hvis du f.eks. ændrer den til 'rotér 7', vil du i stedet beholde en uges logfiler.
Direktivet 'dagligt' sikrer, at logfiler roteres hver dag, mens 'komprimering' sparer plads ved at komprimere gamle logfiler. Indstillingen 'delaycompress' forsinker komprimeringen indtil den anden rotationscyklus, og 'missingok' forhindrer fejl, hvis logfilen er fraværende. Derudover sikrer 'notifempty', at tomme logfiler ikke roteres.
Tip: Daglig logrotation er tilrådelig for at undgå at håndtere alt for store logfiler, hvilket kan gøre analysen mere tidskrævende.
Konklusion
Du har nu installeret ModSecurity 2 på din Debian 12- eller 11-server ved hjælp af Digitalwave-lageret og konfigureret OWASP Core Rule Set. Med disse værktøjer på plads er din server udstyret til at blokere mange almindelige webapplikationstrusler.
Husk at opdatere CRS regelmæssigt og overvåg for eventuelle falske positiver eller mistede sårbarheder. Konsekvente test og justeringer er nøglen til at opretholde en robust sikkerhedsopsætning.
