Apache webszerver edzési és biztonsági útmutató

Gyakorlati útmutató az Apache HTTP Server biztonságához és megszilárdításához.


A webszerver a webes alkalmazások kritikus része. Az Apache Web Server gyakran a hálózat szélén helyezkedik el, így az egyik legsebezhetőbb szolgáltatás lesz a támadás.

Az alapértelmezett konfigurációval sok érzékeny információ található, amely segíthet a hackereknek az alkalmazások támadására való felkészülésben. A webes alkalmazások támadásainak többsége XSS, Info Leakage, Session Management és SQL Injection támadásokon alapul, amelyek a gyenge programozási kód és a webalkalmazás-infrastruktúra fertőtlenítésének hiányából származnak..

Érdekes kutatás Pozitív technológiák kiderült, hogy a beolvasott alkalmazás 52% -ában volt magas sebezhetőség.

Ebben a cikkben az Apache HTTP szerver Linux platformon történő biztosításának bevált gyakorlatairól szólok.

Az alábbiakat az Apache 2.4.x verzióján teszteltük.

  • Ez feltételezi, hogy telepítette az Apache-t a UNIX platformon. Ha nem, akkor olvassa el a Telepítési útmutatót.
  • Az útmutató teljes részében az Apache telepítési könyvtárat / opt / apache-t $ Web_Server-nek hívom.
  • Javasoljuk, hogy bármilyen módosítás előtt készítsen biztonsági másolatot a meglévő konfigurációs fájlról.

Közönség

Ezt a Middleware rendszergazdát, az alkalmazástámogatást, a rendszerelemzőt, és mindenkit szeretnék használni, aki szívesen tanul megkeményedést & Biztonsági irányelvek.

Az Apache Web Server valós ismerete & A UNIX parancs kötelező.

Megjegyzések

Szüksége van valamilyen eszközre a HTTP fejlécek vizsgálatához a végrehajtás ellenőrzéséhez. Ennek két módja van.

  1. A böngészőbe beépített fejlesztőeszközök segítségével ellenőrizze a HTTP-fejléceket. Általában a Hálózat lapon található
  2. Használja az online HTTP válaszfejléc-ellenőrző eszközt

Távolítsa el a Szerver verzió szalaghirdetését

Azt mondanám, hogy ez az egyik első szempont, amelyet figyelembe kell venni, mivel nem akarja feltárni, hogy milyen webszerver verziót használ. A verzió feltárása azt jelenti, hogy segít a hackereknek a felderítési folyamat felgyorsításában.

Az alapértelmezett konfiguráció az alábbiak szerint feltárja az Apache verziót és az operációs rendszer típusát.

  • Lépjen a $ Web_Server / conf mappába
  • Módosítsa a httpd.conf fájlt a vi szerkesztő használatával
  • Adja hozzá a következő irányelvet, és mentse a httpd.conf fájlt

ServerTokens Prod
Kiszolgáló aláírás ki

  • Indítsa újra az apache-t

A ServerSignature eltávolítja a verzióinformációkat az Apache által generált oldalról.

A ServerTokens fejlécet csak termelésre, azaz Apache-ra változtat

Mint látható alább, verzió & Az operációs rendszerrel kapcsolatos információk eltűntek.

Tiltsa le a könyvtár böngésző listáját

Letiltja a könyvtár felsorolását egy böngészőben, így a látogató nem látja az összes fájlt és mappát, amelyek a gyökér vagy alkönyvtár alatt vannak.

Vizsgáljuk meg, hogy néz ki ez az alapértelmezett beállításokban.

  • Lépjen a $ Web_Server / htdocs könyvtárba
  • Hozzon létre egy mappát és néhány fájlt benne

# mkdir teszt
# touch hi
# Érintse hello

Most próbáljuk meg elérni az Apache-t http: // localhost / teszt

Mint látta, kiderül, hogy mi az összes fájlja / mappája, és biztos vagyok benne, hogy nem akarja, hogy ezt feltárja.

  • Lépjen a $ Web_Server / conf könyvtárba
  •  Nyissa meg a httpd.conf fájlt a vi használatával
  •  Keresse meg a Directoryt, és változtassa meg az Opciók irányelvet Nincs vagy –Index értékre

Opciók -Indexek

(vagy)

Opciók Nincs

  • Indítsa újra az Apache alkalmazást

Megjegyzés: Ha a környezetben több Directory irányelv van, akkor fontolóra kell vennie, hogy ugyanazt tegye mindenki számára.

Most próbáljuk meg elérni az Apache-t http: // localhost / teszt

Mint láthatta, egy tiltott hibát jelenít meg a tesztmappák felsorolása helyett.

ETAG

Ez lehetővé teszi a távoli támadók számára, hogy érzékeny információkat szerezzenek, például az inode számot, a többrészes MIME határt és a gyermek folyamatot az Etag fejlécen keresztül..

A sebezhetőség elkerülése érdekében hajtsa végre az alábbiak szerint. Ez szükséges a PCI-megfelelés javításához.

  • Lépjen a $ Web_Server / conf könyvtárba
  • Adja hozzá a következő irányelvet, és mentse a httpd.conf fájlt

FileETag Nincs

  • Indítsa újra az apache-t

Futtassa az Apache-t nem privilegizált fiókból

Az alapértelmezett telepítés senki vagy démonként fut. Jó, ha külön nem kiváltságos felhasználót használ az Apache számára.

Az ötlet az, hogy bármilyen biztonsági rés esetén megvédje a többi szolgáltatást.

  • Hozzon létre egy apache nevű felhasználót és csoportot

# groupadd apache
# useradd –G apache apache

  • Az apache telepítési könyvtárának tulajdonjogát változtassa meg egy újonnan létrehozott nem jogosult felhasználóval

# chown –R apache: apache / opt / apache

  •  Lépjen a $ Web_Server / conf oldalra
  •  Módosítsa a httpd.conf fájlt a vi használatával
  •  Felhasználó keresése & Csoportos irányelv és változás nem privilegizált fiókcímként

Felhasználói apache
Csoportos apache

  •  Mentse a httpd.conf fájlt
  •  Indítsa újra az Apache alkalmazást

grep a http folyamat futtatásához, és győződjön meg arról, hogy az apache felhasználóval fut

# ps –ef | grep http

Látnia kell, hogy az egyik folyamat root felhasználóval fut. Ennek oka az, hogy az Apache a 80-as porton hallgat, és azt a root segítségével kell elindítani.

Védje a bináris és a konfigurációs könyvtár engedélyét

Alapértelmezés szerint a bináris és a konfigurációs engedély 755, azaz a szerver bármely felhasználója megtekintheti a konfigurációt. Megengedheti, hogy egy másik felhasználó belépjen a conf és bin mappába.

  • Lépjen a $ Web_Server könyvtárba
  • A bin és conf mappa engedélyének megváltoztatása

# chmod –R 750 bin conf

Rendszerbeállítások védelme

Alapértelmezett telepítés esetén a felhasználók felülbírálhatják az apache-konfigurációt a .htaccess használatával. Ha meg akarja akadályozni, hogy a felhasználók megváltoztassák az apache-kiszolgáló beállításait, hozzáadhatja az AllowOverride értéket a Nincs értékhez az alább látható módon.

Ezt a gyökér szintjén kell megtenni.

  • Lépjen a $ Web_Server / conf könyvtárba
  •  Nyissa meg a httpd.conf fájlt a vi használatával
  •  Keressen egy könyvtárat gyökér szinten

Opciók -Indexek
AllowOverride Nincs

  •  Mentse a httpd.conf fájlt
  •  Indítsa újra az Apache alkalmazást

HTTP kérési módszerek

A HTTP 1.1 protokoll támogatja számos kérési módszert, amelyek esetleg nem szükségesek, és néhányuk potenciális kockázatot jelent.

Általában szüksége lehet GET, HEAD, POST kérési módszerekre egy webalkalmazásban, amelyet a vonatkozó Directory irányelvben konfigurálhatnak..

Alapértelmezett konfigurációs támogatás OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT módszer a HTTP 1.1 protokollban.

  •  Lépjen a $ Web_Server / conf könyvtárba
  •  Nyissa meg a httpd.conf fájlt a vi használatával
  • Keresse meg a Directoryt, és adja hozzá a következőt

mindenki tagadja

  • Indítsa újra az Apache alkalmazást

Tiltsa le a HTTP nyomkövetési kérelem nyomon követését

Alapértelmezés szerint a Trace módszer engedélyezve van az Apache webkiszolgálón.

Ennek engedélyezése lehetővé teszi a Cross Site Tracing támadást, és lehetőséget adhat a hackerek számára a cookie-k ellopására. Lássuk, hogy néz ki az alapértelmezett konfiguráció.

  •  Végezzen telnet web szerver IP-t hallgatóporttal
  •  Végezzen TRACE kérést az alább látható módon

#telnet localhost 80
Próbálom a 127.0.0.1-et…
Csatlakoztatva a localhost-hoz.
A menekülési karakter ‘^]’.
TRACE / HTTP / 1.1 Host: teszt
HTTP / 1.1 200 OK
Dátum: 2013. augusztus 31., szombat, 02:13:24 GMT
Szerver: Apache
Transzfer-kódolás: csonkítva
Tartalom típusa: üzenet / http 20
TRACE / HTTP / 1.1
Gazda: teszt
0
A kapcsolatot külföldi házigazda zárta.
#

Amint a fenti TRACE-kérésből láthatta, az válaszolt a kérdésemre. Letiltjuk és teszteljük.

  •  Lépjen a $ Web_Server / conf könyvtárba
  • Adja hozzá a következő irányelvet, és mentse a httpd.conf fájlt

TraceEnable ki

  •  Indítsa újra az apache-t

Végezzen telnet webkiszolgáló IP-t figyelő porttal, és tegyen TRACE kérést az alábbiak szerint

#telnet localhost 80
Próbálom a 127.0.0.1-et…
Csatlakoztatva a localhost-hoz.
A menekülési karakter ‘^]’.
TRACE / HTTP / 1.1 Host: teszt
HTTP / 1.1 405 módszer nem engedélyezett
Dátum: 2013. augusztus 31., szombat, 02:18:27 GMT
Szerver: Apache Engedélyezés: Tartalom-Hossz: 223Tartalom-típus: szöveg / html; charset = ISO-8859-1
405 A módszer nem engedélyezett

Nem megengedett módszer

A kért TRACE módszer nem engedélyezett az URL /.

A kapcsolatot külföldi házigazda zárta.
#

Amint a fenti TRACE-kérésből láthatta, blokkolta a kérésomat a HTTP 405 módszer használata nem engedélyezett funkcióval.

Ez a webszerver nem engedélyezi a TRACE kérést és segítséget a webhelyek közötti nyomon követés támadásának megakadályozásában.

Állítsa be a cookie-kat a HttpOnly és a Secure zászlóval

A HttpOnly és a Secure zászló használatával a cookie-kban enyhítheti a gyakori webhelyek közötti parancsfájlok támadását. A HttpOnly és a Biztonság nélkül el lehet lopni vagy manipulálni a webes alkalmazások munkamenetét és a sütiket, és ez veszélyes.

  •  Győződjön meg arról, hogy a mod_headers.so engedélyezve van a httpd.conf fájlban
  •  Lépjen a $ Web_Server / conf könyvtárba
  •  Adja hozzá a következő irányelvet, és mentse a httpd.conf fájlt

Fejléc szerkesztése Set-Cookie ^ (. *) $ $ 1; HttpOnly; Biztonságos

  •  Indítsa újra az apache-t

Clickjacking Attack

A clickjacking egy ismert webes alkalmazás biztonsági rése.

  •  Győződjön meg arról, hogy a mod_headers.so engedélyezve van a httpd.conf fájlban
  •  Lépjen a $ Web_Server / conf könyvtárba
  •  Adja hozzá a következő irányelvet, és mentse a httpd.conf fájlt

A fejléc mindig csatolja az X-Frame-Options SAMEORIGIN elemet

  •  Indítsa újra az apache-t

Az X-Frame-Options támogatja még két további lehetőséget is, amelyeket itt magyaráztam.

Szerveroldalt is tartalmaz

A Server Side Include (SSI) kockázatával növeli a szerver terhelését. Ha megosztotta a környezetet és a nagy forgalmú webes alkalmazásokat, akkor fontolja meg az SSI letiltását az Include in Options irányelv hozzáadásával.

Az SSI támadás lehetővé teszi egy webes alkalmazás kihasználását szkriptek HTML-oldalakba történő beillesztésével vagy kódok távoli végrehajtásával.

  • Lépjen a $ Web_Server / conf könyvtárba
  •  Nyissa meg a httpd.conf fájlt a vi használatával
  •  Keresse meg a Directoryt, és adjon hozzá Beletartozások az Opciók irányelvbe

Opciók –Indexek –Beépíti
Rendelés engedélyezése, denyAllow mindenkinek

  • Indítsa újra az Apache alkalmazást

Megjegyzés: Ha a környezetben több Directory irányelv van, akkor fontolóra kell vennie, hogy ugyanazt tegye mindenki számára.

X-XSS védelem

Az XSS (Cross Site Scripting) védelmet sok böngészőben megkerülhetik. Ezt a védelmet egy webes alkalmazásra alkalmazhatja, ha a felhasználó letiltotta. Ezt olyan óriási webcégek többsége használja, mint a Facebook, a Twitter, a Google stb.

  • Lépjen a $ Web_Server / conf könyvtárba
  • Nyissa meg a httpd.conf fájlt a vi használatával, és adja hozzá a következő fejlécet tartalmazó irányelvet

Fejléckészlet X-XSS-Protection "1; mode = block"

  •  Indítsa újra az Apache alkalmazást

Mint láthatja, az XSS-védelem a válasz fejlécébe kerül.

Tiltsa le a HTTP 1.0 protokollt

Amikor a biztonságról beszélünk, mindent meg kell védenünk. Miért használjuk a protokoll régebbi HTTP-verzióját, tiltsa le őket is?

A HTTP 1.0 biztonsági rése van a munkamenet eltérítésével kapcsolatban. Ezt letilthatjuk a mod_rewrite modul használatával.

  • Töltse be a mod_rewrite modult a httpd.conf fájlba
  •  Engedélyezze a RewriteEngine irányelvet az alábbiak szerint, és adja hozzá a Rewrite feltételt, hogy csak a HTTP 1.1 engedélyezhető legyen

RewriteEngine be
RewriteCond% {THE_REQUEST}! HTTP / 1.1 $
RewriteRule. * – [F]

Időtúllépés-konfiguráció

Alapértelmezés szerint az Apache időtúllépési értéke 300 másodperc, amely a Slow Loris támadás és a DoS áldozata lehet. Ennek enyhítése érdekében csökkentheti az időtúllépés értékét 60 másodpercre.

  • Lépjen a $ Web_Server / conf könyvtárba
  • Nyissa meg a httpd.conf fájlt a vi használatával
  •  Adja hozzá a következőt a httpd.conf fájlhoz

Időtúllépés 60

SSL

Az SSL használata egy további biztonsági réteg, amelyet hozzáad a webes alkalmazáshoz. Az alapértelmezett SSL-konfiguráció azonban bizonyos sebezhetőségeket eredményez, és érdemes megfontolnia ezen konfigurációk módosítását.

SSL kulcs

Az SSL-kulcs megsértése nehéz, de nem lehetetlen. Ez csak a számítási teljesítmény és az idő kérdése.

Mint talán tudod, egy 2009-es korszak PC-jével kb. 73 napig eltörhet fordított mérnök egy 512 bites kulcsot.

Tehát minél nagyobb a kulcs hossza, annál bonyolultabbá válik az SSL-kulcs törése. Az óriási webcégek többsége 2048 bites kulcsot használ, az alábbiak szerint, miért nem mi??

  •  Outlook.com
  •  Microsoft.com
  •   Live.com
  •  Skype.com
  •  Apple.com
  •  Yahoo.com
  •  Bing.com
  •  Hotmail.com
  •  Twitter.com

Az OpenSSL segítségével az alábbiak szerint készíthet 2048 bites CSR-t.

openssl req -out geekflare.csr -newkey rsa: 2048 -csomópontok -keyout geekflare.key

Létrehoz egy CSR-t, amelyet el kell küldenie a tanúsító hatóság hogy aláírja. Miután megkapta az aláírt tanúsítványfájlt, felveheti őket a httpd-ssl.conf fájlba

SSLCertificateFile #Azonosító által aláírt tanúsítvány
SSLCertificateChainFile #Azonosító által a hatóság által megadott aláíró
SSLCertificateKeyFile #Key fájl, amelyet fent generált

  • Indítsa újra az Apache webszervert, és próbálja meg elérni az URL-t a https segítségével

SSL titkosító

Az SSL Cipher egy titkosítási algoritmus, amelyet kulcsként használnak két számítógép között az interneten keresztül. Az adattitkosítás az egyszerű szöveget titkos kódolt kódokká alakítja.

A webkiszolgáló SSL titkosítójának konfigurációján alapul, és az adatok titkosítására kerül sor. Ezért fontos az SSL titkosító konfigurálása, amely erősebb és nem sebezhető.

  • Lépjen a $ Web_Server / conf / extra mappába
  •  Módosítsa az SSLCipherSuite irányelvet a httpd-ssl.conf fájlban az alábbiak szerint, hogy csak magasabb titkosítási algoritmusokat fogadjon el.

SSLCipherSuite HIGH:! KÖZPONTI:! SZÖVEG:! MD5:! RC4

  •  Mentse a konfigurációs fájlt, és indítsa újra az apache szervert

Megjegyzés: Ha sok gyenge rejtjele van az SSL naplózási jelentésben, akkor gyorsan elutasíthatja azok hozzáadását! az elején.

Az SSL v2 letiltása & v3

SSL v2 & A v3-nak számos biztonsági hibája van, és ha a behatolási teszten vagy a PCI-megfelelésen dolgozik, akkor várhatóan bezárja a biztonsági megállapítást az SSL v2 / v3 letiltásához..

Az SSL v2 / v3 kommunikáció sebezhető lehet a közép-támadás során, amely lehetővé teheti az adatok megsértését vagy közzétételét..

Vigyük be az apache webszervert, hogy csak a legújabb TLS-t fogadja el, és elutasítsa az SSL v2 / v3 csatlakozási kérelmet.

  • Lépjen a $ Web_Server / conf / extra mappába
  • Módosítsa az SSLProtocol irányelvet a httpd-ssl.conf fájlban az alábbiak szerint, hogy csak a TLS 1.2-et fogadja el+

SSLProtocol –ALL + TLSv1.2

Miután elvégezte az SSL konfigurálását, érdemes kipróbálni a webes alkalmazást az online SSL / TLS tanúsítvány eszköz segítségével, hogy megtalálja a konfigurációs hibákat..

Mod biztonság

A Mod Security egy nyílt forráskódú webalkalmazás-tűzfal, amelyet az Apache-vel használhat.

Modulként jön létre, amelyet le kell fordítania és telepítenie. Ha nem engedheti meg magának a kereskedelmi webes alkalmazások tűzfalát, akkor ez kiváló választás.

Az általános webes alkalmazások védelme érdekében az alapszabályok a következő technikákat használják:

  • HTTP védelem – a HTTP protokoll és a helyileg meghatározott használati házirend megsértésének észlelése
  • Valós idejű feketelisták keresése – a harmadik fél IP hírnevét használja fel
  • Web alapú rosszindulatú programok észlelése – a rosszindulatú webtartalmakat azonosítja a Google Biztonságos Böngészés API segítségével.
  • A szolgáltatásmegtagadás HTTP védelme – védelem a HTTP árvíz és a lassú HTTP DoS támadások ellen.
  • Közös webes támadások védelme – a webes alkalmazások általános biztonsági támadásának észlelése
  • Automatizálás észlelése – Robotok, bejárók, szkennerek és egy másik rosszindulatú felszíni tevékenység észlelése
  • Integráció a fájlfeltöltések AV-szkennelésével – azonosítja a webes alkalmazáson keresztül feltöltött rosszindulatú fájlokat.
  • Érzékeny adatok követése – A hitelkártya felhasználásának nyomon követése és a szivárgások megakadályozása.
  • Trójai védelem – A trójai lovakhoz való hozzáférés észlelése.
  • Alkalmazási hibák azonosítása – figyelmeztetések az alkalmazás hibás konfigurációjáról.
  • Hibakeresés és elrejtés – a szerver által elküldött hibaüzenetek álcázása.

Letöltés & Telepítés

A következő előfeltételeket telepíteni kell arra a kiszolgálóra, amelyen a Mod Security szolgáltatást az Apache használatával kívánja használni. Ha ezek közül egyik sem létezik, akkor a Mod Security összeállítása sikertelen lesz. Ezeket a csomagokat a yum install Linuxon vagy a Centoson használhatja.

  • apache 2.x vagy újabb
  • libpcre csomag
  •  libxml2 csomag
  • liblua csomag
  • libcurl csomag
  •  libapr és libapr-util csomag
  •  mod_unique_id modul az Apache webszerverrel csomagolva

Töltse le most a Mod Security 2.7.5 legújabb stabil verzióját a itt

  • A letöltött fájl átvitele az / opt / apache mappába
  • Kivonat a modsecurity-apache_2.7.5.tar.gz fájlból

# gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –

  • Ugrás a kibontott mappához, a modsecurity-apache_2.7.5

# cd modsecurity-apache_2.7.5

  • Futtassa a konfigurációs szkriptet, beleértve az apxs elérési útját a létező Apache-hez

# ./configure –with-apxs = / opt / apache / bin / apxs

  • Compile & telepítés a make parancsfájllal

# make
# telepítse

  • A telepítés befejezése után a mod_security2.so üzenet jelenik meg a modulok mappájában az / opt / apache alatt

Ez most arra a következtetésre jut, hogy telepítette a Mod Security modult a meglévő Apache webszerverre.

Configuration

Ahhoz, hogy a Mod biztonsági szolgáltatást Apache-vel használhassuk, be kell töltenünk a mod biztonsági modult a httpd.conf fájlba. A mod_unique_id modul előfeltétele a Mod Biztonságnak.

Ez a modul környezeti változót nyújt egyedi azonosítóval minden kéréshez, amelyet nyomon követ és használ a Mod Security.

  • Adjon hozzá egy sort, ha a Mod Security modult tölti be a httpd.conf fájlba, és mentse a konfigurációs fájlt

LoadModule egyedi_id_modul modulok / mod_unique_id.so
LoadModule security2_module modules / mod_security2.so

  •  Indítsa újra az apache webszervert

A Mod Security most telepítve van!

A következő lépés, hogy telepítenie kell a Mod Security alapszabályt, hogy teljes mértékben kihasználhassa annak funkcióját.

A legfrissebb Core Rule letölthető egy ingyenes linkre kattintva. https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

  • Másolja a letöltött alapszabály zip fájlt az / opt / apache / conf mappába
  • Csomagolja ki az alapvető fájl
  • Érdemes átnevezni a mappát rövidre és könnyen megjegyezhetőre. Ebben a példában átnevezzük crs-re.
  • Ugrás a crs mappába, és nevezze át a modsecurity_crs10_setup.conf.example címet a modsecurity_crs10_setup.conf fájlra.

Most engedjük engedélyezni ezeket a szabályokat, hogy az Apache webszerverrel működjön.

  •  Adja hozzá a következőt a httpd.conf fájlhoz

Tartalmazza a conf / crs / modsecurity_crs_10_setup.confInclude conf / crs / base_rules / * fájlt.

A fenti konfigurációban a Mod Security fő konfigurációs fájlt, a modsecurity_crs_10_setup.conf fájlt és az alapszabályokat base_rules / *. Conf töltjük be, amelyeket a Mod Security Core Rule nyújt a webes alkalmazások védelme érdekében..

  •  Indítsa újra az apache webszervert

Sikeresen konfigurálta a Mod Security szolgáltatást az Apache segítségével!

Szép munka. Az Apache webszervert most a Mod Security webes alkalmazás tűzfala védi.

Elkezdeni

Kezdjük el a Mod Security néhány kritikus konfigurációjával, hogy megszilárduljon & biztonságos webes alkalmazások.

Ebben a szakaszban az összes konfigurációs módosítást elvégezzük a /opt/apache/conf/crs/modsecurity_crs_10_setup.conf fájlban..

Ebben a szakaszban az /opt/apache/conf/crs/modsecurity_crs_10_setup.conf fájlként setup.conf néven hivatkozunk, például.

Fontos megérteni, melyek az OWASP szabályai ingyenesen. Az OWASP kétféle szabályt nyújt.

Alapszabályok – ezeket a szabályokat erősen tesztelték, és valószínűleg a hamis riasztás aránya is alacsonyabb.

Kísérleti szabályok – ezek a szabályok kísérleti célokat szolgálnak, és előfordulhat, hogy nagy téves riasztása van. Fontos, hogy konfiguráljuk, teszteljük és megvalósítsuk az UAT-ban, mielőtt ezeket termelési környezetben használnánk.

Választható szabályok – ezek az opcionális szabályok nem alkalmasak az egész környezetre. Igényei alapján használhatja őket.

Ha CSRF, felhasználói követés, munkamenet-eltérítés stb. Védelmet keres, akkor fontolhatja meg az opcionális szabályok használatát. Megvan az alap, az opcionális és a kísérleti szabályok, miután kibontottuk a letöltött crs zip fájlt az OWASP letöltési oldaláról.

Ezek a szabályok konfigurációs fájlja a crs / base_rules, crs / fakultatív_rules és a crs / kísérleti_rules mappában érhető el. Ismerkedjünk meg néhány alapszabálydal.

  • modsecurity_crs_20_protocol_violations.conf: Ez a szabály védi a protokoll sérülékenységeitől, például a válaszok felosztását, az embercsempészet kérését, a nem engedélyezett protokoll használatát (HTTP 1.0)..
  • modsecurity_crs_21_protocol_anomalies.conf: Ez egy olyan kérés elleni védelem érdekében szolgál, amely hiányzik a fejlécben található Host, Accept, User-Agent parancsokkal..
  • modsecurity_crs_23_request_limits.conf: Ez a szabály függ az alkalmazás-specifikusktól, például a kérés méretétől, a feltöltési mérettől, egy paraméter hosszától stb..
  • modsecurity_crs_30_http_policy.conf: Ennek célja az engedélyezett vagy tiltott módszerek, például CSATLAKOZTATÁS, TRACE, PUT, DELETE stb. konfigurálása és védelme..
  • modsecurity_crs_35_bad_robots.conf: Rosszindulatú robotok észlelése
  • modsecurity_crs_40_generic_attacks.conf: Ez az OS parancsok befecskendezése, a távoli fájlok beillesztése stb..
  • modsecurity_crs_41_sql_injection_attacks.conf: Ez az szabály az SQL és a vak SQL befecskendezés kérésének védelmére.
  • modsecurity_crs_41_xss_attacks.conf: Védelem a webhelyek közötti parancsfájlok kérése ellen.
  • modsecurity_crs_42_tight_security.conf: A könyvtár átjárásának észlelése és védelme.
  • modsecurity_crs_45_trojans.conf: Ez a szabály az általános fájlkezelő kimenetek észlelésére, a HTTP hátsó ajtólap feltöltésére, ismert aláírásra.
  • modsecurity_crs_47_common_exmissions.conf: Ez kivételes mechanizmusként szolgál az általános hamis pozitív üzenetek eltávolításához, amelyek az Apache belső dummy kapcsolata, SSL pinger stb..

Fakitermelés

A naplózás a konfigurálás egyik első dolga, így naplókat hozhat létre a Mod Security tevékenységeihez. Kétféle naplózási lehetőség áll rendelkezésre; Debug & Ellenőrzési napló.

Hiba napló: az Apache hiba, figyelmeztető és figyelmeztető üzenetek másolása a hibanaplóból.

Ellenőrzési napló: Így írja meg a Mod biztonsági szabályokkal megjelölt tranzakciós naplókat. A Mod Security lehetőséget ad az Audit, Debug vagy mindkét naplózás konfigurálására..

Alapértelmezés szerint a konfiguráció mindkét naplót írja. Azonban megváltoztathatja a követelményei alapján. A naplót a SecDefaultAction irányelv vezérli. Nézzük meg az alapértelmezett naplózási konfigurációt a setup.conf fájlban

SecDefaultAction „fázis: 1, tagadás, napló”

Hibakeresés, naplózás naplója – használja a „naplót”. Csak naplózás naplózása – használja a „nolog, auditlog”. Csak a hibakeresési napló naplózása – a „napló, noauditlog” használata irányelv.

Írjuk be az ellenőrzési naplót a /opt/apache/logs/modsec_audit.log oldalba az alábbiak szerint történő hozzáadásával.

  • Adja hozzá a SecAuditLog irányelvet a setup.conf fájlhoz, és indítsa újra az Apache Web Server alkalmazást

SecAuditLog /opt/apache/logs/modsec_audit.log

  • Az újraindítás után látnia kell, hogy a modsec_audit.log előálljon

A Rule Engine engedélyezése

Alapértelmezés szerint a Motor Rule ki van kapcsolva, azaz ha nem engedélyezi a Rule Engine alkalmazását, akkor nem használja ki a Mod Security összes előnyeit.

A Rule Engine engedélyezését vagy letiltását a SecRuleEngine irányelv szabályozza.

  • Adja hozzá a SecRuleEngine irányelvet a setup.conf fájlhoz, és indítsa újra az Apache Web Server alkalmazást

SecRuleEngine be

A SecRuleEngine számára három érték van:

  • Be – a Rule Engine engedélyezéséhez
  • Ki – a Rule Engine letiltásához
  • DetectionOnly – engedélyezze a Rule Engine-t, de soha ne hajtson végre olyan műveleteket, mint a blokkolás, megtagadás, eldobás, engedélyezés, proxy vagy átirányítás

Amint a Rule Engine be van kapcsolva – a Mod Security készen áll a védelemre a leggyakoribb támadások típusaival.

Közös támadás típusú védelem

Most a webszerver készen áll a védelemre olyan általános támadástípusokkal, mint az XSS, az SQL befecskendezés, a protokoll megsértése stb., Mivel telepítettük a Core Rulet és bekapcsoltuk a Rule Engine-t. Vizsgáljuk meg néhányat közülük.

XSS Attack

  •  Nyissa meg a Firefox szoftvert, és férjen hozzá az alkalmazásához, és tegye a címkét a végére, vagy az URL-t
  •  Figyelemmel kíséri a modsec_audit.log fájlt az apache / naplók mappában

Észre fogja venni a Mod Security blokkolja a kérést, mivel tartalmaz címkét, amely az XSS támadás gyökere.

Directory Traversal Attack: – A könyvtári átjárási támadások sok kárt okozhatnak, ha kihasználják ezt a sebezhetőséget és a hozzáférési rendszerhez kapcsolódó fájlt. Ex – / etc / passwd, .htaccess stb.

  •  Nyissa meg a Firefox-ot, és az alkalmazáshoz hozzáférjen a könyvtár átjárásával
  •  Figyelemmel kíséri a modsec_audit.log fájlt az apache / naplók mappában

http: // localhost /? ../…/boot

  • Észre fogja venni a Mod Security blokkolja a kérelmet, mivel az tartalmazza a könyvtár átjárását.

Szerver szalaghirdetés módosítása

Korábban ebben az útmutatóban megtanulta, hogyan lehet eltávolítani az Apache és az operációs rendszer típusát, a ServerTokens irányelv verziószámú súgóját.

Menjünk egy lépéssel előre, mi lenne a szerver nevének megőrzése, amit csak akarsz? Ez a Mod Security SecServerSignature irányelvjével lehetséges. Látja, hogy érdekes.

Megjegyzés: A Mod Security használatával a fejlécből történő kiszolgálói szalaghirdetés manipulálásához be kell állítania a ServerTokesn teljes értékét az Apache webszerver httpd.conf fájljában..

  • Adja hozzá a SecServerSignature irányelvet a kívánt szerver nevével a setup.conf fájlban, és indítsa újra az Apache Web Server alkalmazást

SecServerSignature YourServerName

Volt:

[/ opt / apache / conf / crs] #grep SecServer modsecurity_crs_10_setup.conf
SecServerSignature geekflare.com
[/ opt / apache / conf / crs] #

Általános konfiguráció

Nézzük meg az általános konfigurációk néhány legjobb gyakorlatát.

Konfigurálja a Figyelés lehetőséget

Ha több felülettel és IP-vel rendelkezik egy kiszolgálón, akkor ajánlott, hogy a Listen irányelvet abszolút IP- és portszámmal állítsa be..

Ha hagyja az apache konfigurációt arra, hogy meghallgassa az összes IP-t valamilyen portszámmal, akkor ez problémát okozhat a HTTP kérés továbbításában más webszerverre. Ez meglehetősen általános a megosztott környezetben.

  • Konfigurálja a figyelési irányelvet a httpd.conf fájlban az abszolút IP-vel és a porttal, az alább látható példa szerint

Hallgassa meg 10.10.10.1:80

Hozzáférés naplózáshoz

Alapvető fontosságú a hozzáférési napló megfelelő konfigurálása a webkiszolgálón. A naplóban rögzítendő néhány fontos paraméter a kérés kiszolgálásához szükséges idő, a SESSION ID.

Alapértelmezés szerint az Apache nincs konfigurálva ezen adatok rögzítésére. Kézzel kell konfigurálnia őket az alábbiak szerint.

  • A kérés és a SESSION ID kiszolgálásához szükséges idő rögzítése a hozzáférési naplóban
  •  Adjon hozzá% T-t & % sessionID a httpd.conf fájlban a LogFormat irányelv alapján

LogFormat "% h% l% u% t "% {SessionID} C" "% r" %>s% b% T" gyakori

Tudod hivatkozni http://httpd.apache.org/docs/2.2/mod/mod_log_config.html az Apache Web Server LogFormat irányelvben támogatott paraméterek teljes listájáért.

Tiltsa le a nem kívánt modulok betöltését

Ha az összes modult lefordította és telepítette, akkor nagy a valószínűsége annak, hogy sok modult tölt be az Apache-ba, ami nem feltétlenül szükséges.

A legjobb gyakorlat az Apache konfigurálása a szükséges modulokkal a webes alkalmazásokban. A következő modulok biztonsági problémákat vet fel, és érdemes lehet az Apache Web Server httpd.conf fájljában való letiltás.

WebDAV (Web-alapú elosztott autorálás és verziózás) Ez a modul lehetővé teszi a távoli kliensek számára, hogy a kiszolgálón lévő fájlokkal manipuláljanak, és különböző szolgáltatásmegtagadási támadásoknak tegyék alá őket. A megjegyzés letiltása a httpd.conf fájlban

#LoadModule dav_module modulok / mod_dav.so
#LoadModule dav_fs_module modules / mod_dav_fs.so
#Include conf / extra / httpd-dav.conf

Információs modul A mod_info modul érzékeny információkat szivároghat a .htaccess használatával, miután a modul betöltődött. A megjegyzés letiltása a httpd.conf fájlban

#LoadModule info_module modulok / mod_info.so

Hivatkozás: Ez nem lenne lehetséges a következő link útmutatása nélkül:

Tehát ez volt az egyik legjobb gyakorlat, amelyet az Apache webszerver biztonságához használhat.

Ha még nem ismeri az Apache HTTP-t, akkor azt javasolnám az Apache HTTP adminisztrációs tanfolyam.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map