Web Application Firewall cu Mod Security & reverse proxy

[DarkyAngel]

Una din cele mai mari probleme întâlnite online este costul unei securit??i pentru web applications.

Este comun în UK de exemplu, s? pl?te?ti o tax? zilnic? de ~£1000 pentru ca site-ul t?u s? fie testat de un consultant în securitatea aplica?iilor. Firewallurile pentru Web Applications pot fi la fel de rele. Furnizorii foarte r?spândi?i cere în jur de 15.000$ pentru un "software virtual appliance" ?i 20.000$ pentru o versiune hardware cu support pentru 12 luni.

Cu toate astea, costurile WAF au fost recent t?iate , odat? cu introducerea serviciilor de firewall bazate pe cloud. Ideea din spatele acestui tip de produs este c? firewallul poate acoperi mai mult decât un server de aplica?ie.

Acest tutorial va discuta utilizarea unui firewall open source pentru web applications ?i furnizarea conceptului ideii de a crea un 'appliance' cu acesta.

În timp ce o discu?ie în profunzime despre securitatea web applica?iilor este dincolo de scopul acestui articol, cred c? sunt 3 c?i diferite prin care po?i securiza aplica?ia ta web:

Secure Development Life Cycle (SDLC)

Web Application Testing

Web Application Firewall (WAF)

Developerii ar trebui s? încoroporeze fiecare concept în creerea aplica?iei lui web, dar noi ne vom concentra pe WAF.

Mod Security

Mod Security este un firewall gratuit open source pentru web applications care a fost recent achizi?ionat de Trustwave ca parte din diviziunea lor de research SpiderLabs. Asta le permite s? developeze complet?ri rapide ?i s? le pun? în comunitate pentru a fi testate. Mod Security este unul dintre cele mai des folosite ?i între?inute WAF-uri disponibile. Ca atare, este nevoie de mult reseach ?i multe proiecte adi?ionale au fost construite pe asta, ?i toate pot fi g?site pe Website-ul Mod Security

Acest web application firewall a fost creat pentru a securiza un webserver Apache. Exist? un num?r mare de port?ri care sunt curent f?cute disponibile. Ele pot fi g?site pe website, dar sunt înc? în developare.

Metoda discutat? în acest articol intercepteaz? toate requesturile ?i trimite requesturile acceptate / parsate c?tre web serverul relevant însemnând c? nu va securiza doar un server Apache, ci toate serverele disponibile.

Preg?tirea

Ca s? demonstrez ce vrem s? discut?m, vom folosi dou? ma?ini virtuale. Acest exemplu va folosi Ubuntu Minimal 10.04 pentru c? este cel mai rapid install pe care l-am g?sit ?i pentru c? nu va ajunge un live server, a?a c? nu conteaz? ce folosesc. V? pute?i prepara ma?inile virtuale în acela?i fel dac? dori?i s? urm?ri?i tutorialul cu ce fac, ?i nu doar s? îl citi?i.

Imaginea de mai jos arat? set?rile care le aleg la stagiul de selectare a software-urilor a instal?rii. Aceasta din nou m? ajut? s? gr?besc procesul ?i voi pute?i decide s? instala?i Apache, PHP ?i MySQL, etc, manual. De asemenea am instalat OpenSSH ca s? pot avea acces SSH din pc-ul meu ?i s? nu trebuiasc? s? intru în VM când este pornit.

Am creat dou? VM-uri cu acelea?i configura?ii, în afara hostname-ului. Asta pentru a putea emula un server ca fiind WAF, iar cel?lalt ca fiind serverul aplica?ie. Fi?i siguri c? connexiunile sunt 'bridged' pe local network pentru ca VM-urile s? comunice.

Urm?toarele dou? sec?iuni sunt dedicate set?rii unui PoC ( proof of concept ) func?ional despre ce vreau s? discut?m. V? rog s? re?ine?i c? acesta nu este un ghid exhaustiv, sau calea pe care a? urma-o în realitate. Dac? decizi s? faci asta, ar trebui s? cite?te mai detaliat despre securitatea folosind un reverse proxy ?i configurarea mod security

Setarea clientului

Ca s? test?m c? WAF merge odat? ce l-am setat, avem nevoie s? creem o vulnerabilitate în client. Cea mai simpl? cale s? test?m asta ar fi s? creem o vulnerabilitate "lfi ( local file inclusion )" pe server. Din moment ce am instalat serverul LAMP putem folosi PHP s? creem asta f?când urm?toarele:

cd /var/www/
nano include.php

în fi?ierul include.php ad?ug?m

<? $i = $_GET['i'];
include ($i); ?>

Acest script preia simplu parametrul i din requestul GET ?i îl include în include.php. Acum , introducând pagina http://ADRESA-IP/include.php?i=/etc/passwd putem vedea:

Deci ce facem noi aici este s? includem fi?ierul passwd din folderul /etc. Acesta este o metod? comun? în raporturile pentesting la site-urile care au LFI, deoarece arat? un fi?ier care nu este accesibil din aplica?ia web.

Acum c? clientul e preg?tit, putem configura WAF-ul.

Setarea WAF-ului

Sunt multe c?i diferite de a instala mod security: surs?, installere sau managere de package-uri. Ultima versiune a mod security la timpul scrierii acestui tutorial este 2.6.0 ?i poate fi g?sit AICI. Din nou, ca mai sus, o s? fac ni?te o s? "tai unele col?uri" ?i s? instalez o versiune mai veche a tutorialului din package manager, deoarece am nevoie s? ar?t doar protec?ia cross server. Din fericire de ajuns, acest sistem de operare are un install foarte u?or la mod security care l-am g?sit AICI. Dac? sunt probleme cu accesul sau nu ai destule permisiuni folse?te SUDO.

sudo apt-get install libapache2-mod-security
a2enmod mod-security
nano /etc/apache2/conf.d/mod-security

Aici introduce?i:

<IfModule security2_module>
Include modsecurity-rules/*.conf
Include modsecurity-rules/base_rules/*.conf
</IfModule>

apoi continua?i:

mkdir /etc/apache2/modsecurity-rules
cd /etc/apache2/modsecurity-rules
wget tar -xvf modsecurity-apache_2.5.12.tar.gz
rm -rf CHANGELOG LICENSE READ util
sudo service apache2 restart

Asta e tot! Din nou, dac? ai probleme cu întregul proces, folose?te SUDO ex. sudo su. Acum c? e instalat, este timpul s? connect?m cele 2 servere ?i s? protej?m pagina vulnerabil? cu acest WAF.

Reverse Proxy

Abilitatea WAF-ului s? acopere mai multe servere este posibil? folosind ceea ce este cunoscut ca "reverse proxy". Un "reverse proxy" func?ioneaz? ca un gateway pentru servere ?i permite unui server web s? furnizeze informa?ii pentru al?ii într-o manier? transparent?. Poate fi folosit pentru stocarea în cache a informa?iilor de la client ?i ca atare s? creasc? performan?a ?i ( în acest caz ) s? securizeze. Este recomandat ca, dac? decizi s? faci asta, s? faci cercet?ri în vulnerabilit??ile cauzate de folosirea 'reverse proxy' ?i c?i de securizare împotriva atacurilor r?u-inten?ionate.

Configura?ia proxy este f?cut? în totalitate pe serverul WAF - serverul client nu are nevoie de nici-o configura?ie. În acest caz, vom schimba fi?ierul default /etc/apache2/sites-enabled/000-default . Acest fi?ier este "apelat" de fi?ierul httpd.conf ( sau în acest caz, apache2.conf ) ?i inclus la sfâr?it. Ca s? începem avem nevoie s? pornim modului proxy ?i asta poate fi f?cut simplu ad?ugând urm?toarele 2 linii la începutul fi?ierului.

sudo /etc/apache2/sites-enabled/000-default

LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so

Acum avem nevoie ca proxy-ul s? fac? request c?tre webserverul client. Din nou, se face simplu ad?ugând câteva linii în containerul hostului virtual.

ProxyRequests off
ProxyPass / http://ADRESA-IP/
ProxyPassReverse / http://ip-address/

... ?i ASTA E ! Ai acum un WAF care acoper? un server complet separat. Acum, când chemi IP-ul firewallului, acesta preia requestul, îl parseaz? ?i se asigur? c? e un request genuine verificându-l prin mod security. Apoi îl trimite c?tre serverul client , iar acesta trimite înapoi r?spunsul. Lua?i o privire la pagina vulnerabil? acum.

Mod security ?tie c? /etc/passwd nu e un request normal, ?i nu e normal s? se întâmple într-o aplica?ie web, a?a c? arat? eroarea.

Acesta este un exemplu ufoarte simplu despre cum putem folosi mod security s? acoperim un server separat de cel pe care st?. Este un exemplu bun a ceea ce un 'reverse proxy' poate face, ?i cum folose?ti numai modific?ri Apache ( mod security ) ?i acoperi servere Java based / IIS based / etc.

Cloud-ul

Ce este interesant cu setarea pe care am creat-o este c? face referin?? la un IP care e pe re?eaua local?. Ce s-ar întâmpla dac? am face referin?? la ceva din afara re?elei locale? Ei bine, la fel se întâmpl? , de exemplu c?tre blogul "http://tmacuk.co.uk" .

Po?i vedea din adresa IP din c?su?a URL c? facem request la WAF-ul local, dar pentru regulile prezente în fi?ierul 000-default vedem con?inutul blogului respectiv. S? ne uit?m pu?in mai departe.

Când folosim Tamper Data cu requestul respectiv, observ?m c? facem request GET pentru adresa IP 192.168.0.10 ( în acest caz ). Aici e un scurt delay, dup? care returneaz? un status code 200 ?i r?spunsul de la serverul aplica?ie. Aici sunt dou? requesturi :

17:09:55.386[0ms][total 0ms] Status: pending[]
GET http://192.168.0.10/ Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Content Size[unknown] Mime Type[unknown]


17:10:03.618[957ms][total 9214ms] Status: 200[OK]
GET http://192.168.0.10/ Load Flags[LOAD_DOCUMENT_URI LOAD_REPLACE LOAD_INITIAL_DOCUMENT_URI ] Content Size[-1] Mime     Type

Diferen?a e în flagurile LOAD.

Ni?te set?ri bune DNS trebuie s? fie incluse dac? aceasta era pentru o configura?ie real? de webserver. Numele domeniului trebuie s? fie asociat cu WAF-ul în loc de webserver, altfel URL-ul va sta ca adresa IP. Asta atunci, arat? ca o problem? pentru servere multiple folosite de WAF. Calea s? faci asta, ar fi s? creezi containere de host virtuale pentru fiecare hostname. În fiecare container faci regulile ProxyPass pentru a forwarda traficul c?tre serverul relevant aplica?iei respective.

Concluzie

Costul securiz?rii aplica?iei tale web ?i a serverului poate fi mare. Folosind alternative open source ca WAF ?i SLDC poate ajuta foarte mult ?i asta e ceea ce discut?m aici. Poti crea u?or un firewall care acoper? mai multe servere f?r? s? oferi prea multe informa?ii. În acest fel, cititorul nu poate vedea lucrurile ca set?rile ?i addons-urile diferite pe care mod security le are, sau nu, instalate.

Translated from HERE