A ModSecurity 2 telepítése Apache segítségével a Debian 12 vagy 11 rendszeren

A ModSecurity 2 egy alapvető webalkalmazás-tűzfal (WAF) az Apache HTTP-kiszolgálók védelméhez, valós idejű megfigyelést és szabályalapú szűrést kínál. A Debian 12-es vagy 11-es Linux-kiszolgálóra telepített ModSecurity segít megelőzni az SQL-befecskendezést, a cross-site scripting-et (XSS) és más támadásokat. A Digitalwave ModSecurity Repository leegyszerűsíti a telepítést, és biztosítja, hogy a legújabb stabil verziót használja.

A biztonság fokozása érdekében az OWASP Core Rule Set (CRS) előre konfigurált szabályokat kínál a gyakori sebezhetőségekre. A beállítás lehetővé teszi a rendszergazdák számára, hogy minimális kézi konfigurációval erősítsék meg a védelmet. Ez az útmutató bemutatja, hogyan telepítheti a ModSecurity 2-t Debianra a Digitalwave tároló használatával, és hogyan konfigurálhatja az OWASP CRS-t az optimális védelem érdekében.

Frissítse a Debian rendszercsomagokat a ModSecurity 2 telepítéséhez

Első lépésünk a Debian rendszer frissítésének biztosítása. Ezzel minden meglévő csomagot naprakészen tart, optimális teljesítményt biztosít, és minimalizálja a biztonsági kockázatokat. Ezt a következő parancs futtatásával érheti el:

sudo apt update && sudo apt upgrade

A rendszer frissítése után ellenőrizze, hogy az Apache telepítve van-e. Ha nem, használja a következő parancsot a telepítéshez:

sudo apt install apache2

Importálja a ModSecurity Modul PPA-t

A szükséges tárhely beállítása

A listánk következő feladata a ModSecurity Apache Module telepítése. Előfordulhat, hogy a Debian alapértelmezett tárolóiban elérhető verzió nem a legújabb, és használata azonnali hibákhoz vezethet. Ehelyett egy harmadik féltől származó adattárat importálunk a legújabb ModSecurity Module for Apache telepítéséhez. Ez a Digitalwave által fenntartott, harmadik féltől származó adattár stabil binárisairól híres.

Kezdje a szükséges csomagok telepítésével:

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

Ezután folytatjuk a ModSecurity 2 Module PPA tárolójának importálását GPG kulcs:

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

A GPG kulcs beszerzése után adja hozzá a lerakat a rendszeréhez:

echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list

Az új Apache-modul PPA-tárának prioritása

Miután a tárhely a helyén van, most módosítani kell az APT-házirendet, hogy ez a lerakat prioritást élvezzen a ModSecurity-hez kapcsolódó egyes csomagok számára. Ezt a következő parancs hajtja végre:

cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF

Ezután futtasson egy APT frissítést, amely tükrözi az újonnan importált forrást:

sudo apt update

Ezenkívül a beállítások megerősítéséhez megerősítheti ezt az irányelv-módosítást a következőkkel:

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

Telepítse a ModSecurity 2 modult

Most, hogy a tároló készen áll, folytassa a libapache2-mod-security2 modul telepítésével:

sudo apt install libapache2-mod-security2

A telepítés után a modult engedélyezni kell. Ennek eléréséhez használja a következő parancsot:

sudo a2enmod security2

Az Apache szolgáltatás újraindítása

Végül újraindítjuk az Apache szolgáltatást, hogy megbizonyosodjunk arról, hogy minden változtatás érvénybe lép, és az újonnan hozzáadott ModSecurity modul megfelelően integrálva van:

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

Engedélyezze a ModSecurity 2 modult az Apache HTTP-n

A ModSecurity konfigurációs fájl elérése

Az Apache ModSecurity konfigurációs fájlja az /etc/apache2/mods-enabled/security2.conf címen található. Ezt a fájlt a nano szövegszerkesztővel (vagy a kívánt szövegszerkesztővel) érheti el a következő paranccsal:

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

Keresse meg a következő sort:

IncludeOptional /etc/modsecurity/*.conf

Győződjön meg arról, hogy ez a sor nincs megjegyzés nélkül, mivel más szükséges konfigurációs fájlokat is tartalmaz az /etc/modsecurity könyvtárból. Alapértelmezés szerint nem kell kommentálni.

A ModSecurity 2 konfigurációjának módosítása

Át kell neveznünk a modsecurity.conf-recommended konfigurációs fájlt modsecurity.conf-ra, hogy aktív legyen. Ezt a következő paranccsal lehet megtenni:

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

Most nyissuk meg ezt az újonnan elnevezett konfigurációs fájlt:

sudo nano /etc/modsecurity/modsecurity.conf

A ModSecurity szabálymotor alapértelmezés szerint DetectionOnly értékre van állítva ebben a fájlban. Ez azt jelenti, hogy azonosítja és naplózza a potenciálisan rosszindulatú viselkedést anélkül, hogy blokkolná azt. Ennek megváltoztatásához és a ModSecurity blokkoló képességeinek engedélyezéséhez keresse meg a SecRuleEngine sort (a 7. sor körül), és cserélje ki a DetectionOnly szót On értékre.

Tól:

SecRuleEngine DetectionOnly

Címzett:

SecRuleEngine On

Az Apache naplóbeállításainak módosítása

A konfigurációs fájlban lejjebb találja a SecAuditLogParts sort (a 224-es sor körül). Ennek a sornak az alapértelmezett beállítása nem egészen megfelelő; módosítani kell az összes tranzakciós információ pontos naplózásához.

Változás:

SecAuditLogParts ABDEFHIJZ

Címzett:

SecAuditLogParts ABCEFHJKZ

Ha ezek a módosítások érvényben vannak, mentse el a változtatásokat, és lépjen ki a szerkesztőből.

Az Apache újraindítása a változtatások alkalmazásához

A folyamat utolsó lépése az Apache szolgáltatás újraindítása, hogy a ModSecurity konfigurációban végrehajtott módosításaink érvénybe lépjenek. Ez a következő paranccsal érhető el:

sudo systemctl restart apache2

Telepítse az OWASP Core Rule Set for ModSecurity2-t

A ModSecurity önmagában nem védi meg webszerverét. A lehetséges fenyegetések azonosításához és a rosszindulatú tevékenységek blokkolásához szabálykészletre van szükség. Az OWASP (Open Web Application Security Project) Core Rule Set (CRS) egy nagy tekintélyű szabálykészlet, amelyet különféle webszerverek és webalkalmazási tűzfalak (WAF) használnak. Ennek a szabálykészletnek a telepítése robusztus védelmet nyújt a szervernek az interneten megjelenő számos fenyegetés ellen.

Mielőtt továbblépnénk, feltétlenül ellenőrizze, hogy az OWASP CRS legújabb verziójával rendelkezik-e a következő oldalon OWASP kiadási címke oldal. Ez a lépés biztosítja, hogy letöltse és telepítse a legfrissebb biztonsági intézkedéseket a kiszolgálóhoz.

Az OWASP CRS szülőkönyvtárának létrehozása

Először is hozzuk létre az OWASP vezető szülőkönyvtárát az mkdir paranccsal:

sudo mkdir /etc/apache2/modsec/

Töltse le az OWASP CRS archívumot a Debianon

Ezután a wget paranccsal lekérjük az OWASP CRS 3.3.4 archívumot, amely a cikk írásakor stabil verzió volt. Ne feledje, hogy ellenőriznie kell a verziót a korábban említett hivatkozás segítségével.

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

Az éjszakai összeállítás naprakészebb biztonsági intézkedéseket kínálhat, de fejlesztési állapota miatt problémákat okozhat. Új felhasználók számára a lehetséges komplikációk elkerülése érdekében célszerű a stabil verziót használni.

Megjegyzés: Folyamatosan ellenőriznie kell a frissítéseket; a stabil szabályok nem hetente változnak, hanem negyedévente vagy hacsak nincs szükség sürgős frissítésre.

Az archívum kibontása

A letöltött archívumot kibonthatjuk a korábban létrehozott könyvtárba:

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

Ne felejtse el módosítani a parancsokat a letöltött OWASP CRS-verzió alapján.

A szabálykészlet konfigurálása

Az OWASP CRS-nek van egy minta konfigurációs fájlja, amelyet át kell nevezni, miközben megőrzi az eredetit biztonsági másolatként. Ezt a „cp parancs” segítségével teheti meg:

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

Megjegyzés: Ne felejtse el lecserélni a /coreruleset-3.3.4/ fájlt az OWASP CRS pontos verziójára, amelyet választott.

A szabályok engedélyezése

A szabályok aktiválásához nyissa meg az /etc/apache2/mods-enabled/security2.conf fájlt:

sudo apt install unzip -y

Ezután illessze be a következő két sort:

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

Megjegyzés: Ismét ügyeljen arra, hogy a /coreruleset-3.3.4/ fájlt az OWASP CRS pontos verziójára cserélje ki, mivel a letöltendő magkészlet valószínűleg újabb lesz, mint az útmutató példája.

Ezenkívül írja be vagy távolítsa el a következő sort:

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

Ha elkészült, mentse el és lépjen ki a fájlból:

Az Apache újraindítása a változtatások alkalmazásához

Az utolsó lépés az Apache szolgáltatás újraindítása, hogy a változtatások érvénybe lépjenek:

sudo systemctl restart apache2

Az OWASP Core Rule Set és a ModSecurity 2 első lépései

Az OWASP Core Rule Set (CRS) egy átfogó eszköz számos testreszabható opcióval. Alapértelmezett konfigurációja azonnali biztonsági fejlesztéseket tesz lehetővé a legtöbb szerveren anélkül, hogy hatással lenne a valódi látogatókra vagy a keresőoptimalizálási (SEO) robotokra. Ebben a részben a CRS néhány fontos vonatkozását tárgyaljuk, de a konfigurációs fájlok feltárása az összes elérhető opció teljes megértése érdekében mindig hasznos.

A CRS konfiguráció beállítása

Kezdeményezzük a crs-setup.conf fájl megnyitásával, ahol a legtöbb CRS-beállítás módosítható:

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

A CRS pontozási rendszer megértése

A ModSecurity két különböző módban működik:

• Anomália pontozási mód: A legtöbb felhasználó számára ajánlott, ez a mód „rendellenes pontszámot” rendel minden alkalommal, amikor egy szabály egyezik. A bejövő és kimenő szabályok feldolgozása után a rendszer ellenőrzi az anomália pontszámát, és szükség esetén megzavaró műveletet hajt végre. Ez a művelet gyakran 403-as hiba formájában történik. Ez a mód pontos naplóinformációkat biztosít, és nagyobb rugalmasságot biztosít a blokkolási irányelvek beállításában.
• Önálló mód: Ebben a módban a művelet azonnal végrehajtódik, amikor egy szabály egyezik. Bár csökkentheti az erőforrás-felhasználást, kevesebb rugalmasságot kínál, és kevésbé informatív ellenőrzési naplókat ad. A szabályegyeztetési folyamat leáll, amikor az első szabály teljesül, és a megadott művelet végrehajtásra kerül.

A paranoia szintek megértése

Az OWASP CRS négy paranoia szintet határoz meg:

• Paranoia 1. szint: Az alapértelmezett szint a legtöbb felhasználó számára megfelelő.
• Paranoia 2. szint: Haladó felhasználóknak.
• Paranoia 3. szint: Szakértő felhasználóknak.
• Paranoia 4. szint: Csak rendkívüli körülmények között javasolt.

A magasabb paranoia-szint további szabályokat tesz lehetővé, növeli a biztonságot, és növeli annak valószínűségét, hogy hamis pozitív eredmények miatt blokkolják a jogos forgalmat. Alapvető fontosságú, hogy olyan paranoia szintet válassz, amely megfelel szakértelmének és biztonsági igényeinek.

Az OWASP CRS tesztelése a szerveren

Annak érdekében, hogy az OWASP CRS megfelelően működjön a szerverén, használja az internetböngészőt a következő URL eléréséhez. Ne felejtse el a „sajatdomain.com” kifejezést a tényleges domainjére cserélni:

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

Ha 403-as tiltott hibaüzenetet kap, az OWASP CRS a várt módon fog működni. Ha nem, akkor előfordulhat, hogy a beállítási folyamat félrelépést igényel, amely figyelmet igényel; A leggyakoribb probléma az lehet, hogy elfelejti beállítani a DetectionOnly funkciót On értékre vagy valami hasonlóra.

Adja meg a hamis pozitív üzeneteket és az egyéni kizárási szabályokat

A téves pozitívumok kezelése a ModSecurity és az OWASP Core Rule Set (CRS) segítségével folyamatos feladat lehet. Azonban a rendszerek által kínált robusztus védelem számos fenyegetés ellen elengedhetetlenné teszi ezt az erőfeszítést. A hamis pozitív eredmények kezdetben történő minimalizálása érdekében ajánlatos alacsony paranoiaszintet beállítani.

Ha a szabálykészletet néhány hétig vagy akár hónapig alacsonyabb paranoia szinten futtatja, csökkentheti annak a valószínűségét, hogy túlnyomó számú téves pozitív eredményt kapjon. Ez a megközelítés időt ad arra, hogy megismerkedjen a riasztásokkal és a megfelelő válaszokkal, mielőtt fokozatosan növelné a paranoia szintjét a szigorúbb biztonság érdekében.

Hamis pozitívumok kezelése ismert Debian alkalmazásokban az OWASP, ModSecurity 2 segítségével

A ModSecurity magában foglalja azt a képességet, hogy engedélyezőlistára helyezzen bizonyos műveleteket, amelyek véletlenül hamis pozitív eredményeket válthatnak ki. Például:

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

A WordPress, phpBB és phpMyAdmin alkalmazások engedélyezőlistájának engedélyezéséhez törölje a megjegyzéseket a megfelelő sorokból, és tartsa meg az (1) értéket. A nem használt szolgáltatások engedélyezőlistára való felvételének megakadályozásához állítsa az értéket (0) értékre.

A frissített konfiguráció a következőképpen nézhet ki:

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"

Ebben az esetben a felesleges beállításokat eltávolítottuk, így meghagytuk a megfelelő szintaxist a szükséges konfigurációkhoz.

Szabálykizárások létrehozása a CRS bevezetése előtt

Egyéni kizárások létrehozásához először nevezze át a „REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf” fájlt a következő paranccsal:

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

Ne feledje, hogy minden kizárási szabálynak egyedi „azonosítószámmal” kell rendelkeznie, hogy elkerülje a hibákat az Apache2 szolgáltatástesztelése során.

Például néhány „REQUEST_URI” téves pozitív eredményt okozhat. A következő példa két ilyen esetet szemléltet a Google PageSpeed ​​beacon és a WordPress WPMU DEV beépülő moduljával kapcsolatban:

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"

Ezek a szabályok automatikusan engedélyezik a megadott elérési úttal kezdődő bármely URL-t.

Adott IP-címeket is engedélyezőlistára helyezhet:

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"

Az első szabályban egyetlen IP-cím szerepel az engedélyezési listán, míg a második szabály az „@ipMatch” direktívát használja a szélesebb alhálózati egyeztetéshez. Egy alhálózat vagy IP-cím blokkolásához egyszerűen cserélje ki az „allow” szót „megtagadás”-ra. Ez a rugalmasság lehetővé teszi részletes fekete- és fehérlisták létrehozását, amelyek integrálhatók a Fail2Ban szolgáltatással a fokozott biztonsági stratégia érdekében.

Speciális szabályok letiltása a Debianon OWASP, ModSecurity 2 segítségével

Ahelyett, hogy egy teljes útvonalat engedélyezőlistára helyezne, egy másik megközelítés az, hogy letiltja a tartós hamis pozitív eredményeket okozó bizonyos szabályokat. Bár ez a módszer több tesztelést igényel, hosszú távú előnyöket kínál.

Például, ha a 941000 és 942999 szabályok az „/admin/” területen hamis pozitív eredményt váltanak ki a csapatnál, akkor megkeresheti a szabályazonosítót a ModSecurity naplóiban, és csak az adott azonosítókat tilthatja le a „RemoveByID” paranccsal:

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

Naplók figyelése és minták azonosítása

A folyamatos naplófigyelés elengedhetetlen az Apache, ModSecurity és OWASP téves pozitív üzenetek kezelésekor. Segít azonosítani azokat a mintákat, amelyek hamis pozitív eredményeket váltanak ki, lehetővé téve egyéni szabályok létrehozását ezek kezelésére.

Például, ha bizonyos szabályok következetesen hamis pozitív eredményeket okoznak, létrehozhat egy kizárási szabályt ezeknek a konkrét eseteknek a kezelésére. Ez a személyre szabott megközelítés biztosítja a hamis pozitív eredmények hatékonyabb kezelését.

A naplók rendszeres felülvizsgálatával és a szabályok módosításával biztonságosabb és hatékonyabb környezetet tarthat fenn alkalmazásai számára.

A ModSecurity 2 naplózása

A webes tranzakciók dinamikus jellege miatt a ModSecurity naplók gyorsan növekedhetnek, így a hatékony naplókezelés kulcsfontosságú. A naplóforgatás hasznos eszköz ezeknek a naplóknak a kezelésére, bár alapértelmezés szerint nincs beállítva a ModSecurityben. Ez a rész végigvezeti Önt a naplóforgatás beállításán, kifejezetten a ModSecurity számára.

ModSecurity rotációs fájl létrehozása

Először is létre kell hoznia egy dedikált fájlt a ModSecurity naplóforgatásához. Ehhez használja a következő parancsot egy új modsec nevű fájl létrehozásához és megnyitásához:

sudo nano /etc/logrotate.d/modsec

A forgatási fájl konfigurálása

Az újonnan létrehozott ModSecurity (modsec) konfigurációs fájlban adja hozzá a következőket:

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

Ez a konfiguráció 31 napig megőrzi a naplókat, de a számot az igényeinek megfelelően módosíthatja. Például, ha a „7-es forgatás” értékre változtatja, akkor helyette egy hét naplója marad meg.

A „napi” direktíva biztosítja, hogy a naplók minden nap forogjanak, míg a „tömörítés” a régi naplók tömörítésével helyet takarít meg. A 'delaycompress' opció késlelteti a tömörítést a második forgatási ciklusig, a 'missingok' pedig megakadályozza a hibákat, ha a naplófájl hiányzik. Ezenkívül a „notifempty” biztosítja, hogy az üres naplófájlokat ne forgatják el.

Tipp: Javasoljuk a napi naplóforgatást, hogy elkerülje a túl nagy naplófájlok kezelését, ami időigényesebbé teheti az elemzést.

Következtetés

Most már telepítette a ModSecurity 2-t a Debian 12 vagy 11 szerverére a Digitalwave tároló segítségével, és beállította az OWASP Core Rule Set-et. Ezekkel az eszközökkel a kiszolgáló fel van szerelve számos általános webalkalmazás-fenyegetés blokkolására.

Ne felejtse el rendszeresen frissíteni a CRS-t, és figyelje a hamis pozitív eredményeket vagy a kihagyott sebezhetőségeket. A következetes tesztelés és beállítás kulcsfontosságú a robusztus biztonsági beállítás fenntartásához.