Hur man installerar ModSecurity med Apache på Debian 11 Bullseye

ModSecurity, ofta kallad Modsec, är en gratis brandvägg för webbapplikationer med öppen källkod (WAF). ModSecurity skapades som en modul för Apache HTTP-servern. Men sedan dess tidiga dagar har WAF vuxit och täcker nu en rad HyperText Transfer Protocol-förfrågningar och svarsfiltreringsfunktioner för olika plattformar som Microsoft IIS, Nginx och Apache.

Hur WAF fungerar, är ModSecurity-motorn utplacerad framför webbapplikationen, vilket gör att motorn kan skanna inkommande och utgående HTTP-anslutningar. ModSecurity används oftast tillsammans med OWASP Core Rule Set (CRS), en uppsättning regler med öppen källkod skrivna på ModSecuritys SecRules-språk och är högt ansedd inom säkerhetsbranschen.

OWASP-regeluppsättning med ModSecurity kan nästan omedelbart hjälpa till att skydda din server mot:

  • Dåliga användaragenter
  • DDOS
  • Skripting på flera webbplatser
  • SQL-injektion
  • Session kapning
  • Andra hot

Under handledningen kan du märka att det installerar version 2-bygget, och detta beror på att, till skillnad från Nginx, betaversionen av Apache för Apache/Modsecurity-anslutningen har övergivits och kommer inte att fungera effektivt, så det rekommenderas att stanna kvar den ursprungliga konstruktionen. Uppdateringar utförs fortfarande, så version två har inte övergetts.

I följande handledning kommer du att lära dig hur du installerar ModSecurity & OWASP Core Rule Set med Apache på Debian 11 Bullseye med exempelkonfigurationer.

OWASP har tre versioner att installera; Jag testade både 3.3.2 och 4.0.0 RC1, som arbetade.

INNEHÅLLSFÖRTECKNING

Uppdatera Debian

Uppdatera först ditt system för att säkerställa att alla befintliga paket är uppdaterade.

sudo apt update && sudo apt upgrade -y

Installera senaste Apache

Först rekommenderas det att ta bort alla befintliga installationer av Apache och installera den senaste versionen, som vi kommer att använda Ondrey Surfury PPA.

Ta bort befintlig Apache-installation

Stoppa den aktuella tjänsten om den är installerad med följande kommando.

sudo systemctl stop apache2

Ta nu bort den befintliga Apache-installationen enligt följande:

sudo apt-get purge apache2 -y && sudo apt autoremove apache2 -y

Lägg till senaste Apache PPA

Nästa steg är att importera och installera Apache-webbservern till den senaste versionen är att lägga till förvaret genom Ondřej Surý.

Lägg till förvaret med följande kommando i din terminal.

curl -sSL https://packages.sury.org/apache2/README.txt | sudo bash -x

Uppdatera ditt arkiv för att återspegla den nya ändringen:

sudo apt update

Nu när du har installerat Apache-förvaret och uppdaterade förvarslistan, installera Apache2 med följande:

sudo apt install apache2 -y

Bekräfta sedan att installationen lyckades genom att bekräfta det nya bygget:

sudo apache2 -v

Installera/aktivera ModSecurity Apache-modul

Det första steget är att installera Apache-modulen som ingår i standardförvaret för Debian 11 Bullseye med följande kommando.

sudo apt install libapache2-mod-security2

När den är installerad, aktivera modulen enligt följande.

sudo a2enmod security2

Se till att du startar om din Apache2-tjänst för att återspegla den nya modulen och ändringarna.

sudo systemctl restart apache2

Aktivera ModSecurity Module

Apache ModSecuritys konfigurationer finns i /etc/apache2/mods-enabled/security2.conf, som kommer att ha en rad som innehåller följande.

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

Kontrollera att följande rad finns och inte har en kommentar på raden.

IncludeOptional /etc/modsecurity/*.conf

Exempelvis:

Hur man installerar ModSecurity med Apache på Debian 11 Bullseye

Apache kommer att ladda alla * .conf filer från /etc/modsecurity/ katalogen, men du måste byta namn på modsecurity.conf-rekommenderas konfigurationsfilen först.

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

Använd sedan din favorittextredigerare i Debian och öppna modsecurity.conf fil enligt följande.

sudo nano /etc/modsecurity/modsecurity.conf

Som standard har ModSecurity-konfigurationen regelmotorn angiven som (Endast upptäckt), som med andra ord kör ModSecurity och upptäcker allt skadligt beteende men inte åtgärdsblockerar eller förbjuder och loggar alla HTTP-transaktioner som den flaggar. Detta bör endast användas om du har många falska positiva eller har höjt säkerhetsnivåinställningarna till en extrem nivå och testar för att se om några falska positiva resultat inträffar.

Ändra detta beteende till i konfigurationsfilen (på), hittat på rad 7.

SecRuleEngine DetectionOnly

Ändra raden till detta för att aktivera ModSecurity med följande.

SecRuleEngine On

Exempelvis:

Hur man installerar ModSecurity med Apache på Debian 11 Bullseye

Nu måste du hitta följande SecAuditLogParts, som ligger på linje 224.

# Log everything we know about a transaction.
SecAuditLogParts ABDEFHIJZ

Detta är inte korrekt och måste ändras. Ändra raden till följande:

SecAuditLogParts ABCEFHJKZ

Spara nu fil med hjälp av (CTRL+O), avsluta sedan (CTRL+X).

Starta om din Apache-tjänst med kommandot systemctl för att göra ändringarna live.

sudo systemctl restart apache2

Installera OWASP Core Rule Set för ModSecurity

ModSecurity i sig skyddar inte din webbserver, och du måste ha regler. En av de mest kända, respekterade och välkända reglerna är OWASP CRS-regeluppsättningen. Reglerna är de mest använda bland webbservrar och andra WAF:er, och de flesta andra liknande system bygger de flesta av sina regler på detta CRS. Genom att installera denna regeluppsättning kommer du automatiskt att ge dig en utmärkt källa till skydd mot de flesta nya hot på Internet genom att upptäcka illvilliga aktörer och blockera dem.

Kontrollera OWASP Release tag sida för att se vad som är det senaste, eftersom exemplet nedan kan ha ändrats i framtiden.

Skapa först katalogen som kommer att vara huvudföräldern för OWASP.

sudo mkdir /etc/apache2/modsec/

Använda wget -kommando, ladda ner OWASP CRS 3.3.2-arkiv, som från och med detta datum den senaste stabila, men kom ihåg för fyra dagar sedan, pre-release-versionen föll, så mitt råd är att kolla länken några rader ovan för att se hur utgåvorna ser ut för kärnregeluppsättningen.

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

För de som vill leva på kanten kan du ladda ner nattbygget. Använd bara den nattliga om du är beredd att fortsätta kompilera om och kontrollera CoreRuleSet Github ofta för uppdateringar och vara mer säker på att ta reda på problem. Tekniskt sett kan den nattliga vara säkrare men kan potentiellt skapa problem.

För nybörjare, använd den stabila versionen och använd inte nedanstående version.

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

Vid tidpunkten för skapandet av handledningen är v4.0.0-RC1-förhandsutgåvan också tillgänglig, som tidigare nämnts.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.0.0-rc1.zip

Jag skulle rekommendera att använda pre-release över den nuvarande 3.3.x eller nattliga versioner om du är säker nog. Processen att ladda ner och lägga till reglerna är dock väldigt enkel när du har gjort det två eller tre gånger in i framtiden.

Installera sedan Packa upp paketet om du inte har detta installerat på din server.

sudo apt install unzip -y

Packa upp arkivet.

sudo unzip v4.0.0-rc1.zip -d /etc/apache2/modsec

Kom ihåg att om du har laddat ner v4.0 eller nightly, ändra kommandona för att återspegla detta.

OWASP CRS kommer med ett exempel på en konfigurationsfil som du behöver byta namn på. Det är bäst att använda CP-kommandot och spara en säkerhetskopia för framtiden ifall du behöver starta om igen.

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

Kom ihåg att kommandot ovan endast är ett exempel, se till att ändra /coreuleset-4.0.0-rc1/ med den exakta versionen av OWASP du bestämmer dig med.

För att aktivera reglerna, öppna /etc/etc/apache2/mods-enabled/security2.conf som följer.

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

Väl inne i filen igen, lägg till följande två ytterligare rader:

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

Kom ihåg att kommandot ovan endast är ett exempel, se till att ändra /coreuleset-3.3.2/ med den exakta versionen av OWASP du bestämmer dig med.

Töm också följande rad eller ta bort den.

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

Exempelvis:

Hur man installerar ModSecurity med Apache på Debian 11 Bullseye

Spara filen (CTRL+O) och gå ut (CTRL+T).

Starta om din Apache-tjänst för att göra ändringarna live enligt följande:

sudo systemctl restart apache2

Använda och förstå OWASP Core Rule Set

OWASP CRS har ganska många alternativ, standardinställningarna kommer dock att skydda de flesta servrar direkt utan att skada dina riktiga besökare och bra SEO-bots. Nedan kommer några områden att täckas upp för att förklara. Ytterligare läsning skulle vara bäst att undersöka alla alternativ i själva konfigurationsfilerna eftersom de har en hel del textdata för att förklara vad de är.

Öppna din CRS-setup.conf fil.

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

Observera att detta är konfigurationen för utvecklarversionen med ytterligare objekt jämfört med version 3.3.

Härifrån kan du ändra de flesta av dina OWASP CRS-inställningar.

OWASP CRS Poängsättning

För att bryta ner det har ModSecurity två lägen:

Avvikelsepoängläge

# -- [[ Anomaly Scoring Mode (default) ]] --
# In CRS3, anomaly mode is the default and recommended mode, since it gives the
# most accurate log information and offers the most flexibility in setting your
# blocking policies. It is also called "collaborative detection mode".
# In this mode, each matching rule increases an 'anomaly score'.
# At the conclusion of the inbound rules, and again at the conclusion of the
# outbound rules, the anomaly score is checked, and the blocking evaluation
# rules apply a disruptive action, by default returning an error 403.

Självständigt läge

# -- [[ Self-Contained Mode ]] --
# In this mode, rules apply an action instantly. This was the CRS2 default.
# It can lower resource usage, at the cost of less flexibility in blocking policy
# and less informative audit logs (only the first detected threat is logged).
# Rules inherit the disruptive action that you specify (i.e. deny, drop, etc).
# The first rule that matches will execute this action. In most cases this will
# cause evaluation to stop after the first rule has matched, similar to how many
# IDSs function.

Avvikelsepoäng är i allmänhet, för de flesta användare, det bästa läget att använda.

Det finns fyra paranoianivåer:

  • Paranoia nivå 1 – Standardnivå och rekommenderas för de flesta användare.
  • Paranoia nivå 2 – Endast avancerade användare.
  • Paranoia nivå 3 – Endast expertanvändare.
  • Paranoia nivå 4 – Rekommenderas inte alls, förutom under exceptionella omständigheter.
# -- [[ Paranoia Level Initialization ]] ---------------------------------------
#
# The Paranoia Level (PL) setting allows you to choose the desired level
# of rule checks that will add to your anomaly scores.
#
# With each paranoia level increase, the CRS enables additional rules
# giving you a higher level of security. However, higher paranoia levels
# also increase the possibility of blocking some legitimate traffic due to
# false alarms (also named false positives or FPs). If you use higher
# paranoia levels, it is likely that you will need to add some exclusion
# rules for certain requests and applications receiving complex input.
#
# - A paranoia level of 1 is default. In this level, most core rules
#   are enabled. PL1 is advised for beginners, installations
#   covering many different sites and applications, and for setups
#   with standard security requirements.
#   At PL1 you should face FPs rarely. If you encounter FPs, please
#   open an issue on the CRS GitHub site and don't forget to attach your
#   complete Audit Log record for the request with the issue.
# - Paranoia level 2 includes many extra rules, for instance enabling
#   many regexp-based SQL and XSS injection protections, and adding
#   extra keywords checked for code injections. PL2 is advised
#   for moderate to experienced users desiring more complete coverage
#   and for installations with elevated security requirements.
#   PL2 comes with some FPs which you need to handle.
# - Paranoia level 3 enables more rules and keyword lists, and tweaks
#   limits on special characters used. PL3 is aimed at users experienced
#   at the handling of FPs and at installations with a high security
#   requirement.
# - Paranoia level 4 further restricts special characters.
#   The highest level is advised for experienced users protecting
#   installations with very high security requirements. Running PL4 will
#   likely produce a very high number of FPs which have to be
#   treated before the site can go productive.
#
# All rules will log their PL to the audit log;
# example: [tag "paranoia-level/2"]. This allows you to deduct from the
# audit log how the WAF behavior is affected by paranoia level.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.

Testa OWASP CRS på din server

För att testa om OWASP CRS fungerar på din server, öppna din webbläsare och använd följande:

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

Du bör få en 403 förbjudet fel. Om inte, har ett steg missats.

Exempelvis:

Hur man installerar ModSecurity med Apache på Debian 11 Bullseye

Det vanligaste problemet saknas för att ändra Endast upptäckt till On, som beskrivits tidigare i handledningen.

Hantera falska positiva och uteslutningar av anpassade regler

En av de ofta oändliga uppgifterna är att hantera falska positiva, ModSecurity och OWASP CRS gör ett bra jobb tillsammans, men det kommer på bekostnad av din tid, men med tanke på det skydd du får är det värt det. Till att börja med, att aldrig höja paranoianivån till att börja med är den gyllene regeln.

En bra tumregel är att köra regeluppsättningen i några veckor till månader med knappt några falska positiva resultat, sedan öka till exempel paranoianivå 1 till paranoianivå 2, så att du inte översvämmas med ett ton samtidigt.

Exklusive falska positiva kända applikationer

Modsecurity kan som standard vitlista vardagliga handlingar som leder till falska positiva resultat enligt nedan:

#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 möjliggöra t.ex. WordPress, phpBB och phpMyAdmin när du använder alla tre, avkommentera raderna och lämna (1) numret intakt, ändra de andra tjänster du inte använder, till exempel Xenforo till (0) eftersom du inte vill vitlista dessa regler.

Exempel nedan:

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_cpanel=0,\
  setvar:tx.crs_exclusions_dokuwiki=0,\
  setvar:tx.crs_exclusions_drupal=0,\
  setvar:tx.crs_exclusions_nextcloud=0,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1,\
  setvar:tx.crs_exclusions_xenforo=0"

Du kan också ändra syntaxen, vilket skulle vara renare. Till exempel:

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"

Som du kan se, tas bort alternativen som inte behövs och har lagts till (") i slutet av WordPress för korrekt syntax.

Exklusive regler före CRS

För att hantera anpassade uteslutningar måste du först ändra namnet från REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf fil med cp-kommando enligt följande:

sudo cp /etc/apache2/modsec/coreruleset-3.3.2/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.2/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

En punkt att komma ihåg när du skapar undantagsregler måste var och en ha id: och vara unik, annars får du ett felmeddelande när du testar din Apache2-tjänst.

Exempelvis "id:1544,phase:1,log,allow,ctl:ruleEngine=off", id 1544 kan inte användas för en andra regel.

Till exempel kommer vissa REQUEST_URI att ge falska positiva resultat. Exemplet nedan är två med Google pagespeed beacon och WMUDEV-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"

Som du kan se kommer alla webbadresser som börjar med sökvägen att tillåtas automatiskt.

Ett annat alternativ är att vitlista IP-adresser; några sätt du kan gå tillväga för detta:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
## or ###
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"

Du har nu möjlighet @ipMatch kan användas mer omfattande för subnät. Om du vill neka en ändring av subnät eller IP-adress, tillåt att neka. Med lite know-how kan du även skapa svarta listor och vitlistor och konfigurera detta med fail2ban. Möjligheterna kan ofta vara oändliga.

Ett sista exempel är att endast inaktivera regler som utlöser falska positiva resultat, inte vitlistning av hela sökvägen, som du såg med det första REQUEST_URI-exemplet. Detta kräver dock mer tid och testning.

Till exempel om du vill ta bort regler 941000 och 942999 från din /administration/ område eftersom det fortsätter att utlösa falska förbud och blockeringar för ditt lag, hitta regel-ID:t i dina modsäkerhetsloggar och inaktivera sedan endast det ID:t med RemoveByID som exemplet nedan:

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

Exempel finns på ModSecurity GIT wiki sida.

WordPress WPRS-regeluppsättning för ModSecurity

Ett annat alternativ för Wordpress användare ska installera och köra tillsammans med din OWASP CRS-regeluppsättning, ett välkänt projekt med titeln WPRS-regeluppsättning. Eftersom detta är valfritt och inte är för alla, kommer handledningen inte att täcka det i det här avsnittet.

Men om du vill installera detta för extra skydd om du använder WordPress på din server, besök vår handledning om Installera WordPress ModSecurity Rule Set (WPRS).

Skapa ModSecurity LogRotate-fil.

ModSecurity-loggar kan växa över, så du måste ställa in loggrotering eftersom detta inte görs åt dig.

Skapa och öppna först din ModSecurity-rotationsfil modsec.

sudo nano /etc/logrotate.d/modsec

Lägg till följande kod:

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

Detta kommer att spara loggar i 31 dagar. Om du föredrar att ha mindre, ändra 31 till 7 dagar, motsvarande en veckas loggar. Du bör rotera dagligen för ModSecurity. Om du behöver granska loggfilerna kommer det att vara en katastrof att sålla igenom att ha en veckofil, med tanke på hur stor den kommer att vara.

Kommentarer och slutsats

Generellt sett kommer att distribuera ModSecurity på din server att ge omedelbart skydd. Men tålamod, tid och engagemang för att lära sig kommer att vara en så bra funktion. Det sista du vill är att blockera SEO-bots eller, ännu viktigare, riktiga användare som kan vara potentiella kunder.


Inte vad du letade efter? Försök att söka efter ytterligare tutorials.

Lämna en kommentar