Hur man installerar ModSecurity 3 & OWASP Core Rule Set med Nginx på Ubuntu 20.04

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 3 & OWASP Core Rule Set med Nginx på Ubuntu 20.04 LTS Focal Fossa.

Förutsättningar

  • Rekommenderat OS: ubuntu 20.04 eller högre
  • Användarkonto: Ett användarkonto med sudo or root-åtkomst.

Uppdatera operativsystem

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

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@ubuntu ~]$ sudo whoami
root

För att konfigurera ett befintligt eller nytt sudo-konto, besök vår handledning på Hur man lägger till en användare till Sudoers på Ubuntu.

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

su

Installera senaste Nginx på Ubuntu 20.04

Först rekommenderas det att ta bort alla befintliga installationer av Nginx och installera den senaste versionen med den anpassade PPA underhållen av Ondřej Surý, som också kommer med extra dynamiska moduler som Brotli-modulen.

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:

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

Lägg till senaste Nginx PPA

Nu när du har tagit bort din gamla Nginx-tjänst rekommenderas att installera en av de två PPA:erna nedan.

Handledningen rekommenderar alltid att du installerar huvudlinjen enligt Nginx rekommendation.

Installera en av följande PPA:er med följande kommando:

Installera senaste Nginx (STABIL):

sudo add-apt-repository ppa:ondrej/nginx-stable -y && sudo apt update

Installera senaste Nginx (MAINLINE):

sudo add-apt-repository ppa:ondrej/nginx-mainline -y && sudo apt update

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

sudo 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).

Lägg till Nginx källkod till arkivet

Som standard installeras inte källkoden när PPA installeras. Du måste aktivera detta manuellt för att ladda ner Nginx-källkoden för att kompilera Modsecurity senare i handledningen.

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

sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list

Placera nu raden som börjar med # deb-src och okommentar (#) linjen.

# deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/ focal main

Exempel på hur det ska se ut:

Hur man installerar ModSecurity 3 & OWASP Core Rule Set med Nginx på Ubuntu 20.04

Spara nu filen (CTRL+O) och gå ut (CTRL+X). Uppdatera nu förvarslistan med följande kommando:

sudo apt update

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:

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

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

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

Installera beroenden och kör nedladdning

Ladda sedan ner källkodspaketet med följande:

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

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

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+ubuntu20.04.1+deb.sury.org+1.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.orig.tar.gz' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

Detta kan säkert ignoreras.

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:

jjames@ubuntu:/usr/local/src/nginx$ ls
nginx-1.21.1
nginx_1.21.1-1+ubuntu20.04.1+deb.sury.org+1.debian.tar.xz
nginx_1.21.1-1+ubuntu20.04.1+deb.sury.org+1.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 Ubuntu-operativsystem. För att göra detta, använd följande nginx -v kommando enligt följande:

nginx -v

Du bör få samma utdataversion som källan enligt följande:

jjames@ubuntu:/usr/local/src/nginx$ nginx -v
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å Ubuntu 20.04 kan du installera detta från standardförrådet för Ubuntu 20.04. Detta rekommenderas dock inte som med de flesta LTS-versioner, och det släpar ofta efter. Istället kommer du att kompilera från den mycket mer uppdaterade källan enligt följande.

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:

sudo apt install git -y

Observera att detta installerar Ubuntu 20.04 standardversionen av arkivet. Om du vill ha den senaste uppdaterade versionen med en PPA från GIT repository-teamet, besök vår guide för att installera och uppdatera den senaste Git på Ubuntu 20.04.

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:

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:

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:

./configure

Obs, du kommer möjligen att se följande fel

fatal: No names found, cannot describe anything.

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

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.

make -j 6

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

sudo 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 libmodsäkerhet. Det är 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.

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

sudo 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:

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

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

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

Ladda och konfigurera ModSecurity-nginx Connector med Nginx

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.

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.

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

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

Exempelvis:

Hur man installerar ModSecurity med Nginx på Ubuntu 20.04

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.

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 i Ubuntu, öppna filen modsecurity.conf enligt följande:

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:

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

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.

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) att lämna.

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:

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.

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.

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

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

sudo dnf 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:

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+T).

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

sudo nginx -t

Efter att ha kört torrkörningstestet bör du 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:

sudo systemctl restart nginx

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

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

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

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, höj aldrig 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 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:

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.

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. Du kan också, med lite kunskap, 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. 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.

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 inte bara se att meddelandena är skräppost, utan också 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. Detta är dock litet då data är tillförlitlig, men ibland blir bra bots främst flaggade, så var försiktig.

Steg 1. Skapa ett konto a gratis konto.

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

Hur man installerar ModSecurity med Nginx på Ubuntu 20.04

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

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

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

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

SecHttpBlKey amhektvkkupe

Steg 6. Avkommentera sedan alla rader för att aktivera regeln. Om du vill inaktivera 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:

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:

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:

ModSecurity-loggar kan växa ganska snabbt. Eftersom du kompilerar modulen och den inte installeras via något officiellt arkiv från Ubuntu, 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.

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. Men tålamod, tid och engagemang i lärandet 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