Hur man installerar ModSecurity 3 & OWASP Core Rule Set med Nginx 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 naturligtvis 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 bland 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

I följande handledning kommer du att lära dig hur man installerar ModSecurity med Nginx på Debian 11 Bullseye skrivbord eller server.

INNEHÅLLSFÖRTECKNING

Annons

Förutsättningar

  • Rekommenderat OS: Debian 11 Bullseye.
  • Användarkonto: Ett användarkonto med sudo- eller root-åtkomst.
  • Nödvändiga paket: listas i hela handledningen

Uppdatera operativsystem

Uppdatera din Debian operativsystem för att se till att alla befintliga paket är uppdaterade:

Annons
sudo apt update && sudo apt upgrade -y

Handledningen kommer att använda sudo kommando och förutsatt att du har sudo-status.

Så här verifierar du sudo-status på ditt konto:

sudo whoami

Exempel på utdata som visar sudo-status:

[joshua@debian~]$ sudo whoami
root

För att konfigurera ett befintligt eller nytt sudo-konto, besök vår handledning på Lägga till en användare till Sudoers på Debian.

Annons

Att använda root-konto, använd följande kommando med root-lösenordet för att logga in.

su

Installera CURL & UNZIP-paketet

Handledningen använder sig av kommandot curl och unzip under vissa delar. För att säkerställa att detta är installerat, kör följande kommando i din terminal:

Annons
sudo apt install curl unzip -y

Installera senaste Nginx

Först måste du installera Nginx, och det rekommenderas att göra detta med den senaste stabila eller mainline Nginx-versionen. Innan du fortsätter rekommenderas det att ta bort befintliga installationer av Nginx och installera den senaste Nginx stabil eller mainline version.

Ta bort befintlig Nginx-installation

Stoppa den nuvarande Nginx-tjänsten:

sudo systemctl stop nginx

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

Annons
apt-get purge nginx -y && sudo apt autoremove nginx -y

Importera senaste Nginx Repository & Installera

För att använda den senaste versionen av antingen nginx mainline eller stabil, måste du först importera arkivet.

Så här importerar du ett huvudlager:

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

Så här importerar du ett stabilt arkiv:

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

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

apt update

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

Annons
apt install nginx-core nginx-common nginx nginx-full

Observera att du kan bli ombedd att behålla eller ersätta din befintliga / etc / nginx /nginx.conf konfigurationsfilen under installationen. Det rekommenderas att behålla din nuvarande konfigurationsfil genom att trycka på (N). En kopia kommer att göras oavsett underhållarens version, och du kan även kontrollera detta i framtiden.

Lägg till Nginx källkod till arkivet

Endast binären installeras när du installerar den senaste versionen av Nginx mainline eller stabil som standard. Du behöver dock källan för att kompilera Modsecurity vidare i handledningen.

Öppna först konfigurationsfilen i /etc/apt/sources.list.d med nano enligt nedan:

Huvudlinje:

Annons
nano /etc/apt/sources.list.d/nginx-mainline.list

Stabil:

Annons
nano /etc/apt/sources.list.d/nginx.list

I både mainline och stabil, när du öppnar filen, kommer du bara att se en enda rad enligt följande:

#Mainline File#
deb-src https://packages.sury.org/nginx-mainline/ bullseye main
#Stable File#
deb-src https://packages.sury.org/nginx/ bullseye main

Lägg till följande rad under den ursprungliga raden:

Huvudlinje:

deb-src https://packages.sury.org/nginx-mainline/ bullseye main

Stabil:

deb-src https://packages.sury.org/nginx-mainline/ bullseye main

Exempel på hur det ska se ut (endast huvudexempel):

Annons
Annons
Hur man installerar och ställer in ModSecurity med Nginx på Debian 11

Ladda ner Nginx Source

Du måste ladda ner Nginx-källkoden för att kompilera ModSecurity dynamisk modul. För att göra detta måste du ladda ner och lagra källpaketet på katalogplatsen /etc/local/src/nginx.

Skapa och konfigurera kataloger

Skapa platsen enligt följande:

mkdir /usr/local/src/nginx && cd /usr/local/src/nginx

Valfritt – Tilldela behörighet till katalogen om det behövs enligt nedan:

chown username:username /usr/local/src/ -R 

Installera beroenden och kör nedladdning

Ladda sedan ner källkodspaketet med följande:

apt install dpkg-dev -y && sudo apt source nginx

Observera att du kommer att se följande felmeddelande enligt nedan:

Annons
dpkg-source: info: extracting nginx in nginx-1.21.1
dpkg-source: info: unpacking nginx_1.21.1.orig.tar.gz
dpkg-source: info: unpacking nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Make-sure-signature-stays-the-same-in-all-nginx-buil.patch
dpkg-source: info: applying 0002-define_gnu_source-on-other-glibc-based-platforms.patch
W: Download is performed unsandboxed as root as file 'nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

Detta kan säkert ignoreras.

Annons

Verifiera källversionen

Lista sedan katalogfilerna med ls kommando enligt följande:

ls

Du bör se följande utdata i din /usr/src/local/nginx katalogen:

nginx-1.21.1
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc
nginx_1.21.1.orig.tar.gz
nginx_1.21.1.orig.tar.gz.asc

Bekräfta sedan att källpaketet är detsamma som din Nginx-version installerad på ditt Debian-operativsystem. För att göra detta, använd följande nginx -v kommando enligt följande:

sudo nginx -v

Källan du laddade ner bör matcha den binära versionen som är installerad på ditt system.

Annons

Exempelvis:

nginx version: nginx/1.21.1

Installera libmodsecurity3 för ModSecurity

Paketet libmodsecurity3 är den faktiska delen av WAF som gör HTTP-filtrering för dina webbapplikationer. På Debian 11 kan du installera detta från Debian 11s standardförråd. Detta rekommenderas dock inte som med de flesta stabila versioner, och det släpar ofta efter. Istället kommer du att kompilera från den mycket mer uppdaterade källan enligt följande.

Annons

Clone ModSecurity Repsoitory från Github

Det första steget är klonen från Github, och om du inte har git installerat måste du köra följande kommando:

apt install git -y

Klona sedan libmodsecurity3 GIT-förvaret enligt följande:

git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/

När du har klonat måste du göra det CD till katalogen:

Annons
cd /usr/local/src/ModSecurity/

Installera libmodsecurity3 beroenden

För att kompilera måste du installera följande beroenden enligt följande:

sudo apt install gcc make build-essential autoconf automake libtool libcurl4-openssl-dev liblua5.3-dev libfuzzy-dev ssdeep gettext pkg-config libpcre3 libpcre3-dev libxml2 libxml2-dev libcurl4 libgeoip-dev libyajl-dev doxygen -y

Nu för att avsluta, installera följande GIT-undermoduler enligt följande:

git submodule init

Uppdatera sedan undermodulerna:

Annons
git submodule update

Bygga ModSecurity-miljön

Nästa steg är nu faktiskt att först bygga miljön. Använd följande kommando:

./build.sh

Kör sedan kommandot configure:

Annons
./configure

Observera att du eventuellt kommer att se följande fel:

fatal: No names found, cannot describe anything.

Du kan lugnt ignorera detta och gå vidare till nästa steg.

Se även  Hur man installerar Brave Browser på Fedora 37/36/35

Kompilera ModSecurity-källkoden

Nu när du har byggt och konfigurerat miljön för libmodsecurity3 är det dags att kompilera den med kommandot göra.

make

Ett praktiskt knep är att specificera -j eftersom detta kan öka kompileringshastigheten avsevärt om du har en kraftfull server. Till exempel LinuxCapable servern har 6 processorer, och jag kan använda alla 6 eller åtminstone använda 4 till 5 för att öka hastigheten.

Annons
make -j 6

Efter att ha kompilerat källkoden, kör nu installationskommandot i din terminal:

Annons
make install

Observera att installationen görs i /usr/local/modsecurity/, som du kommer att referera till senare i guiden.

Installera ModSecurity-nginx Connector

Du har nu möjlighet ModSecurity-nginx-kontakt är kopplingspunkten mellan nginx och libmodsecurity. I grund och botten är det komponenten som kommunicerar mellan Nginx och ModSecurity (libmodsecurity3).

Klona ModSecurity-nginx Repsoitory från Github

I likhet med föregående steg när du klona libmodsecurity3-förvaret, måste du klona anslutningsförvaret igen med följande kommando:

sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/

Installera ModSecurity-nginx Dependencies

Därefter, CD-katalogen till Nginx-källkatalogen enligt följande:

cd /usr/local/src/nginx/nginx-1.21.1

Observera, ersätt versionen av guiden med den aktuella Nginx-versionen i ditt system.

Annons
Annons

Kör nu kommandot i din Debianterminal för att installera de beroenden som krävs:

apt build-dep nginx && sudo apt install uuid-dev -y

Därefter kommer du att kompilera ModSecurity-nginx Connector modul endast med -med-compat flagga enligt följande:

./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx

Nu göra (skapa) de dynamiska modulerna med följande kommando:

make modules

Därefter, medan du är i Nginx källkatalog, använd följande kommando för att flytta den dynamiska modulen du just skapade som sparades på platsen objs/ngx_http_modsecurity_module.so och kopiera den till /usr/share/nginx/modules katalog.

sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/

Du kan lagra den dynamiska modulen var som helst, så länge du anger hela sökvägen när du laddar.

Annons

Ladda och konfigurera ModSecurity-nginx Connector med Nginx Web Server

Nu när du har kompilerat den dynamiska modulen och lokaliserat den därefter, måste du redigera din /etc/nginx/nginx.conf konfigurationsfil för att få ModSecurity att fungera med din Nginx-webbserver.

Annons

Aktivera ModSecurity i nginx.conf

Först måste du specificera ladda_modul och sökvägen till din modsäkerhetsmodul.

Öppna nginx.conf med valfri textredigerare. För handledningen kommer nano att användas:

sudo nano /etc/nginx/nginx.conf

Lägg sedan till följande rad i filen nära toppen:

load_module modules/ngx_http_modsecurity_module.so;

Om du har hittat modulen någon annanstans, se till att inkludera hela sökvägen.

Annons

Lägg nu till följande kod under HTTP {} avsnitt enligt följande:

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsec-config.conf;

ENDAST exempel:

Annons
Hur man installerar och ställer in ModSecurity med Nginx på Debian 11

Om du har hittat modulen någon annanstans, se till att inkludera hela sökvägen.

Spara nginx.conf fil (CTRL+O), avsluta sedan (CTRL+X).

Skapa och konfigurera katalog och filer för ModSecurity

Du måste skapa en katalog för att lagra konfigurationsfilerna och framtida regler, OWASP CRS för handledningen.

Annons

Använd följande kommando för att skapa /etc/nginx/modsec katalog enligt följande:

sudo mkdir /etc/nginx/modsec/

Nu måste du kopiera provet ModSecurity-konfigurationsfilen tillbaka från vår klonade GIT-katalog:

sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

Använd din favorittextredigerare och öppna filen modsecurity.conf enligt följande:

Annons
sudo nano /etc/nginx/modsec/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.

För att ändra detta beteende till (på), hitta följande på linje 7:

Annons
SecRuleEngine DetectionOnly

Ändra raden till detta för att aktivera ModSecurity:

SecRuleEngine On

Nu måste du hitta följande, som finns på linje 224:

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

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

SecAuditLogParts ABCEFHJKZ

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

Annons

Nästa del är att skapa följande fil modsec-config.conf. Här lägger du till modsecurity.conf fil med och senare på andra regler som t.ex OWASP CRS, och om du använder WordPress, WPRS CRS regeluppsättning.

Annons

Använd följande kommando för att skapa filen och öppna den:

sudo nano /etc/nginx/modsec/modsec-config.conf

Väl inne i filen lägger du till följande rad:

Include /etc/nginx/modsec/modsecurity.conf

Spara modsec-config.conf fil med (CTRL+O) sedan (CTRL+X) utgång.

Slutligen, kopiera ModSecurity's unicode.mapping fil med CP kommando enligt följande:

sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/

Nu innan du går vidare bör du ge din Nginx-tjänst en torrkörning med följande terminalkommando:

Annons
Annons
sudo nginx -t

Om du har ställt in allt korrekt bör du få följande utdata:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

För att göra ändringarna live, starta om din Nginx-tjänst med kommandot systemctl:

sudo systemctl restart nginx

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.

Se även  Hur man installerar Nvidia-drivrutiner på Debian 11/10

Använda wget kommando, ladda ner OWASP CRS 3.3.2-arkiv enligt följande:

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.

Annons

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

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

installera Packa upp paketet om du inte har detta installerat på din server:

sudo apt install unzip -y

Nu packa de master.zip arkiv enligt följande:

sudo unzip v3.3.2.zip -d /etc/nginx/modsec

Som förr, liksom modsecurity.conf exempelkonfiguration, OWASP CRS kommer med ett exempel på en konfigurationsfil som du behöver byta namn på. Det är bäst att använda CP kommando och spara en säkerhetskopia för framtiden ifall du behöver starta om igen.

sudo cp /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf

För att aktivera reglerna, öppna /etc/nginx/modsec/modsec-config.conf använda valfri textredigerare igen:

Annons
sudo nano /etc/nginx/modsec/modsec-config.conf

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

Include /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-3.3.2/rules/*.conf

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

Annons

Som tidigare måste du testa alla nya tillägg till din Nginx-tjänst innan du gör den live:

sudo nginx -t

Du bör få följande utdata vilket betyder att allt fungerar korrekt:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

Annons
sudo systemctl restart nginx

Använda och förstå OWASP CRS

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 arkivera enligt följande:

nano /etc/nginx/modsec/coreruleset-3.4-dev/crs-setup.conf

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

Annons

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:

Annons

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 generellt för de flesta användare det bästa läget att använda.

Det finns fyra paranoianivåer:

Annons
  • 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:

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

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

Det vanligaste problemet saknas för att ändra Endast upptäckt till På, 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 resultat, ModSecurity och OWASP CRS gör ett bra jobb tillsammans, men det kommer på bekostnad av din tid, men med tanke på skyddet får du att det är 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.

Se även  Hur man installerar VSCodium på Ubuntu 22.10/22.04/20.04

Exklusive falska positiva kända applikationer

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

Annons
Annons
#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 har alternativen inte tagits bort och lagts till (") i slutet av WordPress för korrekt syntax.

Exkluderar regler i Before 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:

Annons
sudo cp /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/nginx/modsec/coreruleset-3.4-dev/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 Nginx-tjänst. Exempel "id:1544,phase:1,log,allow,ctl:ruleEngine=off", id 1544 kan inte användas för en andra regel.

Annons

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:

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 förneka a undernät or IP-adress ändra, tillåta att förneka. Med lite know-how kan du även skapa svartlistor och vitlistor och konfigurera detta med fail2ban. Möjligheterna kan ofta vara oändliga.

Annons

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. Du vill till exempel ta bort regler 941000 och 942999 från ditt /admin/-område eftersom det fortsätter att utlösa falska förbud och blockeringar för ditt team, 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; LinuxCapable kommer i framtiden att skapa en handledning om denna del då det finns ganska mycket att ta upp.

Annons

Valfritt – Inkludera Project Honeypot

Projekt Honey Pot är det första och enda distribuerade systemet för att identifiera spammare och de spambots de använder för att skrapa adresser från din webbplats. Med hjälp av Project Honey Pot-systemet kan du installera anpassade taggade adresser till tiden och IP-adressen för en besökare på din webbplats. Om en av dessa adresser börjar ta emot e-post kan vi se att meddelandena är skräppost, det exakta ögonblicket då adressen samlades in och IP-adressen som samlade in den.

ModSecurity kan ha möjlighet att integrera Project Honeypot, som kommer att fråga databasen och blockera alla adresser som finns på HoneyPot-svartlistan. Observera att användning av detta kan leda till falska positiva resultat, men överlag anses det vara mycket tillförlitligt jämfört med liknande alternativ.

Steg 1. Skapa ett konto a gratis konto.

Annons

Steg 2. När du har registrerat dig och loggat in, på instrumentpanelen, hitta raden (Din http:BL API-nyckel) och klicka få en.

Steg 3. Gå tillbaka till filen CRS-setup.conf genom att öppna den med en textredigerare:

sudo nano /etc/nginx/modsec/coreruleset-3.3.3/crs-setup.conf

Steg 4. Hitta raden som börjar med #SecHttpBlKey, som finns på linje 629.

Annons
#SecHttpBlKey XXXXXXXXXXXXXXXXX
#SecAction "id:900500,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.block_search_ip=1,\
#  setvar:tx.block_suspicious_ip=1,\
#  setvar:tx.block_harvester_ip=1,\
#  setvar:tx.block_spammer_ip=1"

Steg 5. Ändra SecHttpBlKey XXXXXXXXXXXXXXXXX med din nyckel från Project HoneyPot.

Exempelvis:

Annons
SecHttpBlKey amhektvkkupe

Steg 6. Avkommentera sedan alla rader för att aktivera regeln. För att avaktivera en regel, istället för (1), sätta (0) istället om du vill ha någon av reglerna inaktiverad. Som standard är block_search_ip=0 för sökmotorrobotar, aktivera inte detta om du inte vill att Bing, Google och andra bra bots ska komma till din webbplats.

SecHttpBlKey amhektvkkupe
SecAction "id:900500,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.block_search_ip=0,\
  setvar:tx.block_suspicious_ip=1,\
  setvar:tx.block_harvester_ip=1,\
  setvar:tx.block_spammer_ip=1"

Obs, använd inte amhektvkkupe. Använda sig av din nyckel istället!

Steg 7. Testa Nginx för att se till att inga fel har inträffat med följande:

sudo nginx -t

Exempel på utdata om allt är korrekt:

Annons
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Starta nu om din Nginx-tjänst:

Annons
sudo systemctl restart nginx

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

Med tanke på hur många rader och information den kan logga, kommer ModSecurity att växa ganska snabbt. Eftersom du kompilerar modulen och den inte installeras via något officiellt arkiv från Debian, måste du skapa din egen loggrotationsfil.

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 hålla loggar för 31 dagar. Om du föredrar att ha mindre, byt 31 att säga 7 dagar lika med en veckas stockar. 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.

Annons
Annons

Kommentarer och slutsats

I handledningen har du ett grepp om att installera Nginx-källan, kompilera ModSecurity och ställa in OWASP-reglerna bland de översta delarna. Generellt sett kommer att distribuera ModSecurity på din server att ge omedelbart skydd.

Tålamod, tid och engagemang i lärandet kommer dock att vara en sådan fantastisk egenskap. 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.

2 tankar om "Hur man installerar ModSecurity 3 & OWASP Core Rule Set med Nginx på Debian 11 Bullseye"

  1. Hej,

    I stegen "Bygga ModSecurity Environment" har jag många fel vid tillverkningssteget som:

    make[2]: Går in i katalogen '/usr/local/src/ModSecurity/src'
    make[3]: Går in i katalogen '/usr/local/src/ModSecurity/src'
    make[3]: Lämnar katalogen '/usr/local/src/ModSecurity/src'
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/src'
    make[1]: Lämnar katalogen '/usr/local/src/ModSecurity/src'
    Gör allt i doc
    make[1]: Gå in i katalogen '/usr/local/src/ModSecurity/doc'
    make[1]: Inget att göra för "alla".
    make[1]: Lämnar katalogen '/usr/local/src/ModSecurity/doc'
    Tillverkar allt i verktyg
    make[1]: Går in i katalogen '/usr/local/src/ModSecurity/tools'
    Att kontrollera alla regler
    make[2]: Gå in i katalogen '/usr/local/src/ModSecurity/tools/rules-check'
    make[2]: Inget att göra för "alla".
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/tools/rules-check'
    make[2]: Går in i katalogen '/usr/local/src/ModSecurity/tools'
    make[2]: Inget att göra för 'all-am'.
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/tools'
    make[1]: Lämnar katalogen '/usr/local/src/ModSecurity/tools'
    Gör allt i exempel
    make[1]: Gå in i katalogen '/usr/local/src/ModSecurity/examples'
    Gör allt i multiprocess_c
    make[2]: Gå in i katalogen '/usr/local/src/ModSecurity/examples/multiprocess_c'
    make[2]: Inget att göra för "alla".
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/examples/multiprocess_c'
    Gör allt i läsloggar_med_offset
    make[2]: Gå in i katalogen '/usr/local/src/ModSecurity/examples/reading_logs_with_offset'
    make[2]: Inget att göra för "alla".
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/examples/reading_logs_with_offset'
    Gör allt i read_logs_via_rule_message
    make[2]: Gå in i katalogen '/usr/local/src/ModSecurity/examples/reading_logs_via_rule_message'
    make[2]: Inget att göra för "alla".
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/examples/reading_logs_via_rule_message'
    Gör allt i simple_example_using_c
    make[2]: Gå in i katalogen '/usr/local/src/ModSecurity/examples/simple_example_using_c'
    make[2]: Inget att göra för "alla".
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/examples/simple_example_using_c'
    Gör allt i using_bodies_in_chunks
    make[2]: Gå in i katalogen '/usr/local/src/ModSecurity/examples/using_bodies_in_chunks'
    make[2]: Inget att göra för "alla".
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/examples/using_bodies_in_chunks'
    make[2]: Gå in i katalogen '/usr/local/src/ModSecurity/examples'
    make[2]: Inget att göra för 'all-am'.
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/examples'
    make[1]: Lämnar katalogen '/usr/local/src/ModSecurity/examples'
    Gör allt i test
    make[1]: Går in i katalogen '/usr/local/src/ModSecurity/test'
    Att göra allt i benchmark
    make[2]: Gå in i katalogen '/usr/local/src/ModSecurity/test/benchmark'
    make[2]: Inget att göra för "alla".
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/test/benchmark'
    make[2]: Går in i katalogen '/usr/local/src/ModSecurity/test'
    make[2]: Inget att göra för 'all-am'.
    make[2]: Lämnar katalogen '/usr/local/src/ModSecurity/test'
    make[1]: Lämnar katalogen '/usr/local/src/ModSecurity/test'
    make[1]: Gå in i katalogen '/usr/local/src/ModSecurity'
    make[1]: Inget att göra för 'all-am'.
    make[1]: Lämnar katalogen '/usr/local/src/ModSecurity'

    Svara
    • Hej,

      Var det allt som trycktes?

      Fick inte en lång utgång? Det är normalt för testerna, exempel på att ingenting ska göras men om det var den enda utgången låt mig veta.

      Jag körde bara om detta snabbt kompilerade, laddade fint på min sida. Jag kan se några förbättringar. Jag kan rensa upp handledningen för att göra den enklare, men det är morgondagens jobb.

      Kunde du bygga den dynamiska modulen?

      Låt mig veta hur du går.

      Tack.

      Svara

Lämna en kommentar