Quick Reply

[Kalashnikov]

mod_security este un modul Apache care se comporta ca un filtru/firewall pentru web. Il putem invata cum ne-ar ataca cineva si ce am putea face ca sa ne aparam. De exemplu, se stie ca aplicatiile scrise in C pot fi vulnerabile la nullbyte attack. O solutie ar fi sa reparam aplicatia, dar daca e o aplicatie comerciala si nu avem acces la sursa nu avem ce-i face. Sau, chiar daca am avea acces la sursa, nu ar fi mai bine sa ne facem imuni la nullbyte attack decat sa stam cu frica-n spate ca poate cineva gaseste undeva o vulnerabilitate?

Ca sa rezolvam aceasta problema, trebuie sa instalam mod_security si apoi sa adaugam in httpd.conf urmatoarele linii:

Code:

<ifmodule mod_security.c>
    SecFilterEngine On
    SecFilterForceByteRange 1 255
 </ifmodule>

Instalarea mod_security se poate face simplu ca in cazul oricarui alt modul Apache folosind comanda apxs:

Code:

[root@localhost ~]# wget http://www.modsecurity.org/download/mod_security-1.7.4.tar.gz
 [root@localhost ~]# tar zxvf mod_security-1.7.4.tar.gz
 [root@localhost apache2]# cd mod_security-1.7.4/apache2
 [root@localhost apache2]# /usr/local/apache/bin/apxs -cia mod_security.c

Dupa instalare restartam serverul Apache si modulul devine functional. Acum, cand cineva incearca sa injecteze un nullbyte va primi un mesaj de eroare 406.

Dupa cum v-ati dat seama, in httpd.conf trebuie sa pornim filtrul pentru ca apoi sa putem seta diferite reguli. Asta se face folosind directiva “SecFilterEngine On“. Mai jos putem incepe sa adaugam reguli care sa ne protejeze. SecFilterForceByteRange e una din regulile folosite.

Mergand putin mai departe, ajungem la doua tipuri de atac care se bazeaza pe includerea de fisiere: RFI si LFI. De fapt e vorba de o singura vulnerabilitate in script care permite unei persoane rau intentionate sa includa un fisier, dar daca serverul e slab securizat acea vulnerabilitate poate permite includerea de fisiere remote – aici e diferenta intre RFI si LFI. Probabil va intrebati ce poate face mod_security cand vine vorba de RFI sau LFI. Ei bine, intotdeauna cand se gaseste o vulnerabilitate se doreste inserarea intr-o pagina a unui fisier care nu ar trebui sa fie vizibil. De exemplu, in cazul LFI, cineva ar vrea sa includa intr-un fisier public continutul fisierului.htpasswd. Ca sa ne protejam de astfel de specimene vom adauga urmatoarea regula:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "\.htpasswd"
 </ifmodule>

Din nou am pornit motorul filtrului iar apoi am creat un filtru care atunci cand gaseste in cerere sirul “.htpasswd” va genera o eroare si va bloca accesul. Astfel, daca cineva incearca ceva de genul asta:

Code:

http://www.exemplu.ro/fisier.php?variabila=.htpasswd

mod_security va detecta cererea ca atac si ii va bloca accesul. In cazul RFI putem face acelasi lucru, dar sa facem un filtru pentru http. De exemplu:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "=http://"
 </ifmodule>

Astfel cand cineva incearca sa seteze o variabila cu o valoare care incepe cu http://, mod_security va sesiza din nou pericolul si va bloca accesul.

Bineinteles, mod_security poate face mai mult. Ne poate proteja, de exemplu, de atacuri de tip XSS. Se stie ca in XSS se incearca includerea unor scripturi ca informatii valide. De exemplu un atacator va incerca sa ofere ca si cale catre o imagine un cod JavaScript care sa fure cookieurile. Pentru a ne proteja de atacurile XSS transmise prin URL putem adauga urmatoarele coduri:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "javascript\://"
 SecFilter "img src=javascript"
 SecFilter "< [[:space:]]*script"
 SecFilter "<(.|\n)+>"
 </ifmodule>

La fel se poate adauga cate o regula pentru fiecare metoda de atac XSS prin URL care il detectati. Aici imi permit sa va indemn sa cautati alte metode de a injecta cod JavaScript. Cele 4 reguli sunt doar exemplificative. Posibilitatile sunt mai multe. Cautati si vedeti ce ati mai putea adauga ca sa va protejati.

Cum mod_security e mult mai destept decat pare ne poate proteja chiar si de SQL Injection. Adica, daca stim cum arata un atac de tip SQL Injection il putem bloca creand niste reguli de forma:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilter "insert[[:space:]]+into"
 SecFilter "select.+from"
 </ifmodule>

Cum stim din experienta atacatorilor ca de obicei se folosesc instructiunile delete, insert, union etc. le putem bloca cand sunt trimise prin URL. Astfel, chiar daca siteul in sine ar fi vulnerabil la SQL Injection din cauza codului, noi suntem protejati pentru ca mod_security are grija sa nu ni se intample nimic rau.

Ma opresc aici cu exemplificarile pentru ca trebuie sa va las si pe voi sa va puneti mintea la contributie si sa gasiti noi atacuri si metode de a bloca acele atacuri. Chiar mi-ar place sa vad ce puteti adauga la regulile de mai sus. As vedea asa ca ati inteles cum functioneaza.

Mai departe sa vedem ce picanterii putem adauga. O idee ar fi actiunea care e luata atunci cand cineva ne ataca. In mod implicit se tranteste un mesaj de eroare cu cod 406 si userul e blocat. Totusi, daca avem o aplicatie buggy e posibil ca o cerere valida sa fie interpretata ca fiind un atac. E urat ca vizitatorul sa vada ca e tratat ca un atacator. Ar fi bine sa il redirectam spre o pagina de eroare. De exemplu, putem face asa:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilterDefaultAction "redirect:/eroare.html"
 </ifmodule>

stfel oricand apare o problema, vizitatorul/atacatorul va fi redirectat catre eroare.html unde poate primi un mesaj frumos, aranjat, in care e anuntat ca a incercat sa faca ceva ce serverul considera ca nu e bine. Pentru siguranta pagina respectiva poate fi de fapt un script care preia toate datele vizitatorului (IP, proxy, OS,browser etc) si le trimite, in mod transparent, pe mail sau le salveaza intr-o baza de date pentru a urmari mai tarziu statisticile si posibilele cai de atac.

Cred ca a ajuns informatia. E mai mult decat o mica introducere. Daca aveti nelamuriri puteti apela cu incredere la documentatia oficiala care o gasiti la adresa: modsecurity.org/documentation/index.html

Ca un mic sfat, daca sunteti webmaster sau administrator de server, nu lasati mod_security si mod_rewrite sa treaca pe langa voi. Impreuna pot forma un firewall la nivel de aplicatie extraordinar.

Articol preluat de la http://www.lamp.ro

[Status:]

mod_security este un modul Apache care se comporta ca un filtru/firewall pentru web. Il putem invata cum ne-ar ataca cineva si ce am putea face ca sa ne aparam. De exemplu, se stie ca aplicatiile scrise in C pot fi vulnerabile la nullbyte attack. O solutie ar fi sa reparam aplicatia, dar daca e o aplicatie comerciala si nu avem acces la sursa nu avem ce-i face. Sau, chiar daca am avea acces la sursa, nu ar fi mai bine sa ne facem imuni la nullbyte attack decat sa stam cu frica-n spate ca poate cineva gaseste undeva o vulnerabilitate?

Ca sa rezolvam aceasta problema, trebuie sa instalam mod_security si apoi sa adaugam in httpd.conf urmatoarele linii:

Code:

<ifmodule mod_security.c>
    SecFilterEngine On
    SecFilterForceByteRange 1 255
 </ifmodule>

Instalarea mod_security se poate face simplu ca in cazul oricarui alt modul Apache folosind comanda apxs:

Code:

[root@localhost ~]# wget http://www.modsecurity.org/download/mod_security-1.7.4.tar.gz
 [root@localhost ~]# tar zxvf mod_security-1.7.4.tar.gz
 [root@localhost apache2]# cd mod_security-1.7.4/apache2
 [root@localhost apache2]# /usr/local/apache/bin/apxs -cia mod_security.c

Dupa instalare restartam serverul Apache si modulul devine functional. Acum, cand cineva incearca sa injecteze un nullbyte va primi un mesaj de eroare 406.

Dupa cum v-ati dat seama, in httpd.conf trebuie sa pornim filtrul pentru ca apoi sa putem seta diferite reguli. Asta se face folosind directiva “SecFilterEngine On“. Mai jos putem incepe sa adaugam reguli care sa ne protejeze. SecFilterForceByteRange e una din regulile folosite.

Mergand putin mai departe, ajungem la doua tipuri de atac care se bazeaza pe includerea de fisiere: RFI si LFI. De fapt e vorba de o singura vulnerabilitate in script care permite unei persoane rau intentionate sa includa un fisier, dar daca serverul e slab securizat acea vulnerabilitate poate permite includerea de fisiere remote – aici e diferenta intre RFI si LFI. Probabil va intrebati ce poate face mod_security cand vine vorba de RFI sau LFI. Ei bine, intotdeauna cand se gaseste o vulnerabilitate se doreste inserarea intr-o pagina a unui fisier care nu ar trebui sa fie vizibil. De exemplu, in cazul LFI, cineva ar vrea sa includa intr-un fisier public continutul fisierului.htpasswd. Ca sa ne protejam de astfel de specimene vom adauga urmatoarea regula:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "\.htpasswd"
 </ifmodule>

Din nou am pornit motorul filtrului iar apoi am creat un filtru care atunci cand gaseste in cerere sirul “.htpasswd” va genera o eroare si va bloca accesul. Astfel, daca cineva incearca ceva de genul asta:

Code:

http://www.exemplu.ro/fisier.php?variabila=.htpasswd

mod_security va detecta cererea ca atac si ii va bloca accesul. In cazul RFI putem face acelasi lucru, dar sa facem un filtru pentru http. De exemplu:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "=http://"
 </ifmodule>

Astfel cand cineva incearca sa seteze o variabila cu o valoare care incepe cu http://, mod_security va sesiza din nou pericolul si va bloca accesul.

Bineinteles, mod_security poate face mai mult. Ne poate proteja, de exemplu, de atacuri de tip XSS. Se stie ca in XSS se incearca includerea unor scripturi ca informatii valide. De exemplu un atacator va incerca sa ofere ca si cale catre o imagine un cod JavaScript care sa fure cookieurile. Pentru a ne proteja de atacurile XSS transmise prin URL putem adauga urmatoarele coduri:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "javascript\://"
 SecFilter "img src=javascript"
 SecFilter "< [[:space:]]*script"
 SecFilter "<(.|\n)+>"
 </ifmodule>

La fel se poate adauga cate o regula pentru fiecare metoda de atac XSS prin URL care il detectati. Aici imi permit sa va indemn sa cautati alte metode de a injecta cod JavaScript. Cele 4 reguli sunt doar exemplificative. Posibilitatile sunt mai multe. Cautati si vedeti ce ati mai putea adauga ca sa va protejati.

Cum mod_security e mult mai destept decat pare ne poate proteja chiar si de SQL Injection. Adica, daca stim cum arata un atac de tip SQL Injection il putem bloca creand niste reguli de forma:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilter "insert[[:space:]]+into"
 SecFilter "select.+from"
 </ifmodule>

Cum stim din experienta atacatorilor ca de obicei se folosesc instructiunile delete, insert, union etc. le putem bloca cand sunt trimise prin URL. Astfel, chiar daca siteul in sine ar fi vulnerabil la SQL Injection din cauza codului, noi suntem protejati pentru ca mod_security are grija sa nu ni se intample nimic rau.

Ma opresc aici cu exemplificarile pentru ca trebuie sa va las si pe voi sa va puneti mintea la contributie si sa gasiti noi atacuri si metode de a bloca acele atacuri. Chiar mi-ar place sa vad ce puteti adauga la regulile de mai sus. As vedea asa ca ati inteles cum functioneaza.

Mai departe sa vedem ce picanterii putem adauga. O idee ar fi actiunea care e luata atunci cand cineva ne ataca. In mod implicit se tranteste un mesaj de eroare cu cod 406 si userul e blocat. Totusi, daca avem o aplicatie buggy e posibil ca o cerere valida sa fie interpretata ca fiind un atac. E urat ca vizitatorul sa vada ca e tratat ca un atacator. Ar fi bine sa il redirectam spre o pagina de eroare. De exemplu, putem face asa:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilterDefaultAction "redirect:/eroare.html"
 </ifmodule>

stfel oricand apare o problema, vizitatorul/atacatorul va fi redirectat catre eroare.html unde poate primi un mesaj frumos, aranjat, in care e anuntat ca a incercat sa faca ceva ce serverul considera ca nu e bine. Pentru siguranta pagina respectiva poate fi de fapt un script care preia toate datele vizitatorului (IP, proxy, OS,browser etc) si le trimite, in mod transparent, pe mail sau le salveaza intr-o baza de date pentru a urmari mai tarziu statisticile si posibilele cai de atac.

Cred ca a ajuns informatia. E mai mult decat o mica introducere. Daca aveti nelamuriri puteti apela cu incredere la documentatia oficiala care o gasiti la adresa: modsecurity.org/documentation/index.html

Ca un mic sfat, daca sunteti webmaster sau administrator de server, nu lasati mod_security si mod_rewrite sa treaca pe langa voi. Impreuna pot forma un firewall la nivel de aplicatie extraordinar.

Articol preluat de la http://www.lamp.ro

[Posts:]

mod_security este un modul Apache care se comporta ca un filtru/firewall pentru web. Il putem invata cum ne-ar ataca cineva si ce am putea face ca sa ne aparam. De exemplu, se stie ca aplicatiile scrise in C pot fi vulnerabile la nullbyte attack. O solutie ar fi sa reparam aplicatia, dar daca e o aplicatie comerciala si nu avem acces la sursa nu avem ce-i face. Sau, chiar daca am avea acces la sursa, nu ar fi mai bine sa ne facem imuni la nullbyte attack decat sa stam cu frica-n spate ca poate cineva gaseste undeva o vulnerabilitate?

Ca sa rezolvam aceasta problema, trebuie sa instalam mod_security si apoi sa adaugam in httpd.conf urmatoarele linii:

Code:

<ifmodule mod_security.c>
    SecFilterEngine On
    SecFilterForceByteRange 1 255
 </ifmodule>

Instalarea mod_security se poate face simplu ca in cazul oricarui alt modul Apache folosind comanda apxs:

Code:

[root@localhost ~]# wget http://www.modsecurity.org/download/mod_security-1.7.4.tar.gz
 [root@localhost ~]# tar zxvf mod_security-1.7.4.tar.gz
 [root@localhost apache2]# cd mod_security-1.7.4/apache2
 [root@localhost apache2]# /usr/local/apache/bin/apxs -cia mod_security.c

Dupa instalare restartam serverul Apache si modulul devine functional. Acum, cand cineva incearca sa injecteze un nullbyte va primi un mesaj de eroare 406.

Dupa cum v-ati dat seama, in httpd.conf trebuie sa pornim filtrul pentru ca apoi sa putem seta diferite reguli. Asta se face folosind directiva “SecFilterEngine On“. Mai jos putem incepe sa adaugam reguli care sa ne protejeze. SecFilterForceByteRange e una din regulile folosite.

Mergand putin mai departe, ajungem la doua tipuri de atac care se bazeaza pe includerea de fisiere: RFI si LFI. De fapt e vorba de o singura vulnerabilitate in script care permite unei persoane rau intentionate sa includa un fisier, dar daca serverul e slab securizat acea vulnerabilitate poate permite includerea de fisiere remote – aici e diferenta intre RFI si LFI. Probabil va intrebati ce poate face mod_security cand vine vorba de RFI sau LFI. Ei bine, intotdeauna cand se gaseste o vulnerabilitate se doreste inserarea intr-o pagina a unui fisier care nu ar trebui sa fie vizibil. De exemplu, in cazul LFI, cineva ar vrea sa includa intr-un fisier public continutul fisierului.htpasswd. Ca sa ne protejam de astfel de specimene vom adauga urmatoarea regula:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "\.htpasswd"
 </ifmodule>

Din nou am pornit motorul filtrului iar apoi am creat un filtru care atunci cand gaseste in cerere sirul “.htpasswd” va genera o eroare si va bloca accesul. Astfel, daca cineva incearca ceva de genul asta:

Code:

http://www.exemplu.ro/fisier.php?variabila=.htpasswd

mod_security va detecta cererea ca atac si ii va bloca accesul. In cazul RFI putem face acelasi lucru, dar sa facem un filtru pentru http. De exemplu:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "=http://"
 </ifmodule>

Astfel cand cineva incearca sa seteze o variabila cu o valoare care incepe cu http://, mod_security va sesiza din nou pericolul si va bloca accesul.

Bineinteles, mod_security poate face mai mult. Ne poate proteja, de exemplu, de atacuri de tip XSS. Se stie ca in XSS se incearca includerea unor scripturi ca informatii valide. De exemplu un atacator va incerca sa ofere ca si cale catre o imagine un cod JavaScript care sa fure cookieurile. Pentru a ne proteja de atacurile XSS transmise prin URL putem adauga urmatoarele coduri:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "javascript\://"
 SecFilter "img src=javascript"
 SecFilter "< [[:space:]]*script"
 SecFilter "<(.|\n)+>"
 </ifmodule>

La fel se poate adauga cate o regula pentru fiecare metoda de atac XSS prin URL care il detectati. Aici imi permit sa va indemn sa cautati alte metode de a injecta cod JavaScript. Cele 4 reguli sunt doar exemplificative. Posibilitatile sunt mai multe. Cautati si vedeti ce ati mai putea adauga ca sa va protejati.

Cum mod_security e mult mai destept decat pare ne poate proteja chiar si de SQL Injection. Adica, daca stim cum arata un atac de tip SQL Injection il putem bloca creand niste reguli de forma:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilter "insert[[:space:]]+into"
 SecFilter "select.+from"
 </ifmodule>

Cum stim din experienta atacatorilor ca de obicei se folosesc instructiunile delete, insert, union etc. le putem bloca cand sunt trimise prin URL. Astfel, chiar daca siteul in sine ar fi vulnerabil la SQL Injection din cauza codului, noi suntem protejati pentru ca mod_security are grija sa nu ni se intample nimic rau.

Ma opresc aici cu exemplificarile pentru ca trebuie sa va las si pe voi sa va puneti mintea la contributie si sa gasiti noi atacuri si metode de a bloca acele atacuri. Chiar mi-ar place sa vad ce puteti adauga la regulile de mai sus. As vedea asa ca ati inteles cum functioneaza.

Mai departe sa vedem ce picanterii putem adauga. O idee ar fi actiunea care e luata atunci cand cineva ne ataca. In mod implicit se tranteste un mesaj de eroare cu cod 406 si userul e blocat. Totusi, daca avem o aplicatie buggy e posibil ca o cerere valida sa fie interpretata ca fiind un atac. E urat ca vizitatorul sa vada ca e tratat ca un atacator. Ar fi bine sa il redirectam spre o pagina de eroare. De exemplu, putem face asa:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilterDefaultAction "redirect:/eroare.html"
 </ifmodule>

stfel oricand apare o problema, vizitatorul/atacatorul va fi redirectat catre eroare.html unde poate primi un mesaj frumos, aranjat, in care e anuntat ca a incercat sa faca ceva ce serverul considera ca nu e bine. Pentru siguranta pagina respectiva poate fi de fapt un script care preia toate datele vizitatorului (IP, proxy, OS,browser etc) si le trimite, in mod transparent, pe mail sau le salveaza intr-o baza de date pentru a urmari mai tarziu statisticile si posibilele cai de atac.

Cred ca a ajuns informatia. E mai mult decat o mica introducere. Daca aveti nelamuriri puteti apela cu incredere la documentatia oficiala care o gasiti la adresa: modsecurity.org/documentation/index.html

Ca un mic sfat, daca sunteti webmaster sau administrator de server, nu lasati mod_security si mod_rewrite sa treaca pe langa voi. Impreuna pot forma un firewall la nivel de aplicatie extraordinar.

Articol preluat de la http://www.lamp.ro

[User:]

mod_security este un modul Apache care se comporta ca un filtru/firewall pentru web. Il putem invata cum ne-ar ataca cineva si ce am putea face ca sa ne aparam. De exemplu, se stie ca aplicatiile scrise in C pot fi vulnerabile la nullbyte attack. O solutie ar fi sa reparam aplicatia, dar daca e o aplicatie comerciala si nu avem acces la sursa nu avem ce-i face. Sau, chiar daca am avea acces la sursa, nu ar fi mai bine sa ne facem imuni la nullbyte attack decat sa stam cu frica-n spate ca poate cineva gaseste undeva o vulnerabilitate?

Ca sa rezolvam aceasta problema, trebuie sa instalam mod_security si apoi sa adaugam in httpd.conf urmatoarele linii:

Code:

<ifmodule mod_security.c>
    SecFilterEngine On
    SecFilterForceByteRange 1 255
 </ifmodule>

Instalarea mod_security se poate face simplu ca in cazul oricarui alt modul Apache folosind comanda apxs:

Code:

[root@localhost ~]# wget http://www.modsecurity.org/download/mod_security-1.7.4.tar.gz
 [root@localhost ~]# tar zxvf mod_security-1.7.4.tar.gz
 [root@localhost apache2]# cd mod_security-1.7.4/apache2
 [root@localhost apache2]# /usr/local/apache/bin/apxs -cia mod_security.c

Dupa instalare restartam serverul Apache si modulul devine functional. Acum, cand cineva incearca sa injecteze un nullbyte va primi un mesaj de eroare 406.

Dupa cum v-ati dat seama, in httpd.conf trebuie sa pornim filtrul pentru ca apoi sa putem seta diferite reguli. Asta se face folosind directiva “SecFilterEngine On“. Mai jos putem incepe sa adaugam reguli care sa ne protejeze. SecFilterForceByteRange e una din regulile folosite.

Mergand putin mai departe, ajungem la doua tipuri de atac care se bazeaza pe includerea de fisiere: RFI si LFI. De fapt e vorba de o singura vulnerabilitate in script care permite unei persoane rau intentionate sa includa un fisier, dar daca serverul e slab securizat acea vulnerabilitate poate permite includerea de fisiere remote – aici e diferenta intre RFI si LFI. Probabil va intrebati ce poate face mod_security cand vine vorba de RFI sau LFI. Ei bine, intotdeauna cand se gaseste o vulnerabilitate se doreste inserarea intr-o pagina a unui fisier care nu ar trebui sa fie vizibil. De exemplu, in cazul LFI, cineva ar vrea sa includa intr-un fisier public continutul fisierului.htpasswd. Ca sa ne protejam de astfel de specimene vom adauga urmatoarea regula:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "\.htpasswd"
 </ifmodule>

Din nou am pornit motorul filtrului iar apoi am creat un filtru care atunci cand gaseste in cerere sirul “.htpasswd” va genera o eroare si va bloca accesul. Astfel, daca cineva incearca ceva de genul asta:

Code:

http://www.exemplu.ro/fisier.php?variabila=.htpasswd

mod_security va detecta cererea ca atac si ii va bloca accesul. In cazul RFI putem face acelasi lucru, dar sa facem un filtru pentru http. De exemplu:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "=http://"
 </ifmodule>

Astfel cand cineva incearca sa seteze o variabila cu o valoare care incepe cu http://, mod_security va sesiza din nou pericolul si va bloca accesul.

Bineinteles, mod_security poate face mai mult. Ne poate proteja, de exemplu, de atacuri de tip XSS. Se stie ca in XSS se incearca includerea unor scripturi ca informatii valide. De exemplu un atacator va incerca sa ofere ca si cale catre o imagine un cod JavaScript care sa fure cookieurile. Pentru a ne proteja de atacurile XSS transmise prin URL putem adauga urmatoarele coduri:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "javascript\://"
 SecFilter "img src=javascript"
 SecFilter "< [[:space:]]*script"
 SecFilter "<(.|\n)+>"
 </ifmodule>

La fel se poate adauga cate o regula pentru fiecare metoda de atac XSS prin URL care il detectati. Aici imi permit sa va indemn sa cautati alte metode de a injecta cod JavaScript. Cele 4 reguli sunt doar exemplificative. Posibilitatile sunt mai multe. Cautati si vedeti ce ati mai putea adauga ca sa va protejati.

Cum mod_security e mult mai destept decat pare ne poate proteja chiar si de SQL Injection. Adica, daca stim cum arata un atac de tip SQL Injection il putem bloca creand niste reguli de forma:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilter "insert[[:space:]]+into"
 SecFilter "select.+from"
 </ifmodule>

Cum stim din experienta atacatorilor ca de obicei se folosesc instructiunile delete, insert, union etc. le putem bloca cand sunt trimise prin URL. Astfel, chiar daca siteul in sine ar fi vulnerabil la SQL Injection din cauza codului, noi suntem protejati pentru ca mod_security are grija sa nu ni se intample nimic rau.

Ma opresc aici cu exemplificarile pentru ca trebuie sa va las si pe voi sa va puneti mintea la contributie si sa gasiti noi atacuri si metode de a bloca acele atacuri. Chiar mi-ar place sa vad ce puteti adauga la regulile de mai sus. As vedea asa ca ati inteles cum functioneaza.

Mai departe sa vedem ce picanterii putem adauga. O idee ar fi actiunea care e luata atunci cand cineva ne ataca. In mod implicit se tranteste un mesaj de eroare cu cod 406 si userul e blocat. Totusi, daca avem o aplicatie buggy e posibil ca o cerere valida sa fie interpretata ca fiind un atac. E urat ca vizitatorul sa vada ca e tratat ca un atacator. Ar fi bine sa il redirectam spre o pagina de eroare. De exemplu, putem face asa:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilterDefaultAction "redirect:/eroare.html"
 </ifmodule>

stfel oricand apare o problema, vizitatorul/atacatorul va fi redirectat catre eroare.html unde poate primi un mesaj frumos, aranjat, in care e anuntat ca a incercat sa faca ceva ce serverul considera ca nu e bine. Pentru siguranta pagina respectiva poate fi de fapt un script care preia toate datele vizitatorului (IP, proxy, OS,browser etc) si le trimite, in mod transparent, pe mail sau le salveaza intr-o baza de date pentru a urmari mai tarziu statisticile si posibilele cai de atac.

Cred ca a ajuns informatia. E mai mult decat o mica introducere. Daca aveti nelamuriri puteti apela cu incredere la documentatia oficiala care o gasiti la adresa: modsecurity.org/documentation/index.html

Ca un mic sfat, daca sunteti webmaster sau administrator de server, nu lasati mod_security si mod_rewrite sa treaca pe langa voi. Impreuna pot forma un firewall la nivel de aplicatie extraordinar.

Articol preluat de la http://www.lamp.ro

[Location:]

mod_security este un modul Apache care se comporta ca un filtru/firewall pentru web. Il putem invata cum ne-ar ataca cineva si ce am putea face ca sa ne aparam. De exemplu, se stie ca aplicatiile scrise in C pot fi vulnerabile la nullbyte attack. O solutie ar fi sa reparam aplicatia, dar daca e o aplicatie comerciala si nu avem acces la sursa nu avem ce-i face. Sau, chiar daca am avea acces la sursa, nu ar fi mai bine sa ne facem imuni la nullbyte attack decat sa stam cu frica-n spate ca poate cineva gaseste undeva o vulnerabilitate?

Ca sa rezolvam aceasta problema, trebuie sa instalam mod_security si apoi sa adaugam in httpd.conf urmatoarele linii:

Code:

<ifmodule mod_security.c>
    SecFilterEngine On
    SecFilterForceByteRange 1 255
 </ifmodule>

Instalarea mod_security se poate face simplu ca in cazul oricarui alt modul Apache folosind comanda apxs:

Code:

[root@localhost ~]# wget http://www.modsecurity.org/download/mod_security-1.7.4.tar.gz
 [root@localhost ~]# tar zxvf mod_security-1.7.4.tar.gz
 [root@localhost apache2]# cd mod_security-1.7.4/apache2
 [root@localhost apache2]# /usr/local/apache/bin/apxs -cia mod_security.c

Dupa instalare restartam serverul Apache si modulul devine functional. Acum, cand cineva incearca sa injecteze un nullbyte va primi un mesaj de eroare 406.

Dupa cum v-ati dat seama, in httpd.conf trebuie sa pornim filtrul pentru ca apoi sa putem seta diferite reguli. Asta se face folosind directiva “SecFilterEngine On“. Mai jos putem incepe sa adaugam reguli care sa ne protejeze. SecFilterForceByteRange e una din regulile folosite.

Mergand putin mai departe, ajungem la doua tipuri de atac care se bazeaza pe includerea de fisiere: RFI si LFI. De fapt e vorba de o singura vulnerabilitate in script care permite unei persoane rau intentionate sa includa un fisier, dar daca serverul e slab securizat acea vulnerabilitate poate permite includerea de fisiere remote – aici e diferenta intre RFI si LFI. Probabil va intrebati ce poate face mod_security cand vine vorba de RFI sau LFI. Ei bine, intotdeauna cand se gaseste o vulnerabilitate se doreste inserarea intr-o pagina a unui fisier care nu ar trebui sa fie vizibil. De exemplu, in cazul LFI, cineva ar vrea sa includa intr-un fisier public continutul fisierului.htpasswd. Ca sa ne protejam de astfel de specimene vom adauga urmatoarea regula:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "\.htpasswd"
 </ifmodule>

Din nou am pornit motorul filtrului iar apoi am creat un filtru care atunci cand gaseste in cerere sirul “.htpasswd” va genera o eroare si va bloca accesul. Astfel, daca cineva incearca ceva de genul asta:

Code:

http://www.exemplu.ro/fisier.php?variabila=.htpasswd

mod_security va detecta cererea ca atac si ii va bloca accesul. In cazul RFI putem face acelasi lucru, dar sa facem un filtru pentru http. De exemplu:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "=http://"
 </ifmodule>

Astfel cand cineva incearca sa seteze o variabila cu o valoare care incepe cu http://, mod_security va sesiza din nou pericolul si va bloca accesul.

Bineinteles, mod_security poate face mai mult. Ne poate proteja, de exemplu, de atacuri de tip XSS. Se stie ca in XSS se incearca includerea unor scripturi ca informatii valide. De exemplu un atacator va incerca sa ofere ca si cale catre o imagine un cod JavaScript care sa fure cookieurile. Pentru a ne proteja de atacurile XSS transmise prin URL putem adauga urmatoarele coduri:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "javascript\://"
 SecFilter "img src=javascript"
 SecFilter "< [[:space:]]*script"
 SecFilter "<(.|\n)+>"
 </ifmodule>

La fel se poate adauga cate o regula pentru fiecare metoda de atac XSS prin URL care il detectati. Aici imi permit sa va indemn sa cautati alte metode de a injecta cod JavaScript. Cele 4 reguli sunt doar exemplificative. Posibilitatile sunt mai multe. Cautati si vedeti ce ati mai putea adauga ca sa va protejati.

Cum mod_security e mult mai destept decat pare ne poate proteja chiar si de SQL Injection. Adica, daca stim cum arata un atac de tip SQL Injection il putem bloca creand niste reguli de forma:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilter "insert[[:space:]]+into"
 SecFilter "select.+from"
 </ifmodule>

Cum stim din experienta atacatorilor ca de obicei se folosesc instructiunile delete, insert, union etc. le putem bloca cand sunt trimise prin URL. Astfel, chiar daca siteul in sine ar fi vulnerabil la SQL Injection din cauza codului, noi suntem protejati pentru ca mod_security are grija sa nu ni se intample nimic rau.

Ma opresc aici cu exemplificarile pentru ca trebuie sa va las si pe voi sa va puneti mintea la contributie si sa gasiti noi atacuri si metode de a bloca acele atacuri. Chiar mi-ar place sa vad ce puteti adauga la regulile de mai sus. As vedea asa ca ati inteles cum functioneaza.

Mai departe sa vedem ce picanterii putem adauga. O idee ar fi actiunea care e luata atunci cand cineva ne ataca. In mod implicit se tranteste un mesaj de eroare cu cod 406 si userul e blocat. Totusi, daca avem o aplicatie buggy e posibil ca o cerere valida sa fie interpretata ca fiind un atac. E urat ca vizitatorul sa vada ca e tratat ca un atacator. Ar fi bine sa il redirectam spre o pagina de eroare. De exemplu, putem face asa:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilterDefaultAction "redirect:/eroare.html"
 </ifmodule>

stfel oricand apare o problema, vizitatorul/atacatorul va fi redirectat catre eroare.html unde poate primi un mesaj frumos, aranjat, in care e anuntat ca a incercat sa faca ceva ce serverul considera ca nu e bine. Pentru siguranta pagina respectiva poate fi de fapt un script care preia toate datele vizitatorului (IP, proxy, OS,browser etc) si le trimite, in mod transparent, pe mail sau le salveaza intr-o baza de date pentru a urmari mai tarziu statisticile si posibilele cai de atac.

Cred ca a ajuns informatia. E mai mult decat o mica introducere. Daca aveti nelamuriri puteti apela cu incredere la documentatia oficiala care o gasiti la adresa: modsecurity.org/documentation/index.html

Ca un mic sfat, daca sunteti webmaster sau administrator de server, nu lasati mod_security si mod_rewrite sa treaca pe langa voi. Impreuna pot forma un firewall la nivel de aplicatie extraordinar.

Articol preluat de la http://www.lamp.ro

[Website]

mod_security este un modul Apache care se comporta ca un filtru/firewall pentru web. Il putem invata cum ne-ar ataca cineva si ce am putea face ca sa ne aparam. De exemplu, se stie ca aplicatiile scrise in C pot fi vulnerabile la nullbyte attack. O solutie ar fi sa reparam aplicatia, dar daca e o aplicatie comerciala si nu avem acces la sursa nu avem ce-i face. Sau, chiar daca am avea acces la sursa, nu ar fi mai bine sa ne facem imuni la nullbyte attack decat sa stam cu frica-n spate ca poate cineva gaseste undeva o vulnerabilitate?

Ca sa rezolvam aceasta problema, trebuie sa instalam mod_security si apoi sa adaugam in httpd.conf urmatoarele linii:

Code:

<ifmodule mod_security.c>
    SecFilterEngine On
    SecFilterForceByteRange 1 255
 </ifmodule>

Instalarea mod_security se poate face simplu ca in cazul oricarui alt modul Apache folosind comanda apxs:

Code:

[root@localhost ~]# wget http://www.modsecurity.org/download/mod_security-1.7.4.tar.gz
 [root@localhost ~]# tar zxvf mod_security-1.7.4.tar.gz
 [root@localhost apache2]# cd mod_security-1.7.4/apache2
 [root@localhost apache2]# /usr/local/apache/bin/apxs -cia mod_security.c

Dupa instalare restartam serverul Apache si modulul devine functional. Acum, cand cineva incearca sa injecteze un nullbyte va primi un mesaj de eroare 406.

Dupa cum v-ati dat seama, in httpd.conf trebuie sa pornim filtrul pentru ca apoi sa putem seta diferite reguli. Asta se face folosind directiva “SecFilterEngine On“. Mai jos putem incepe sa adaugam reguli care sa ne protejeze. SecFilterForceByteRange e una din regulile folosite.

Mergand putin mai departe, ajungem la doua tipuri de atac care se bazeaza pe includerea de fisiere: RFI si LFI. De fapt e vorba de o singura vulnerabilitate in script care permite unei persoane rau intentionate sa includa un fisier, dar daca serverul e slab securizat acea vulnerabilitate poate permite includerea de fisiere remote – aici e diferenta intre RFI si LFI. Probabil va intrebati ce poate face mod_security cand vine vorba de RFI sau LFI. Ei bine, intotdeauna cand se gaseste o vulnerabilitate se doreste inserarea intr-o pagina a unui fisier care nu ar trebui sa fie vizibil. De exemplu, in cazul LFI, cineva ar vrea sa includa intr-un fisier public continutul fisierului.htpasswd. Ca sa ne protejam de astfel de specimene vom adauga urmatoarea regula:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "\.htpasswd"
 </ifmodule>

Din nou am pornit motorul filtrului iar apoi am creat un filtru care atunci cand gaseste in cerere sirul “.htpasswd” va genera o eroare si va bloca accesul. Astfel, daca cineva incearca ceva de genul asta:

Code:

http://www.exemplu.ro/fisier.php?variabila=.htpasswd

mod_security va detecta cererea ca atac si ii va bloca accesul. In cazul RFI putem face acelasi lucru, dar sa facem un filtru pentru http. De exemplu:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "=http://"
 </ifmodule>

Astfel cand cineva incearca sa seteze o variabila cu o valoare care incepe cu http://, mod_security va sesiza din nou pericolul si va bloca accesul.

Bineinteles, mod_security poate face mai mult. Ne poate proteja, de exemplu, de atacuri de tip XSS. Se stie ca in XSS se incearca includerea unor scripturi ca informatii valide. De exemplu un atacator va incerca sa ofere ca si cale catre o imagine un cod JavaScript care sa fure cookieurile. Pentru a ne proteja de atacurile XSS transmise prin URL putem adauga urmatoarele coduri:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "javascript\://"
 SecFilter "img src=javascript"
 SecFilter "< [[:space:]]*script"
 SecFilter "<(.|\n)+>"
 </ifmodule>

La fel se poate adauga cate o regula pentru fiecare metoda de atac XSS prin URL care il detectati. Aici imi permit sa va indemn sa cautati alte metode de a injecta cod JavaScript. Cele 4 reguli sunt doar exemplificative. Posibilitatile sunt mai multe. Cautati si vedeti ce ati mai putea adauga ca sa va protejati.

Cum mod_security e mult mai destept decat pare ne poate proteja chiar si de SQL Injection. Adica, daca stim cum arata un atac de tip SQL Injection il putem bloca creand niste reguli de forma:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilter "insert[[:space:]]+into"
 SecFilter "select.+from"
 </ifmodule>

Cum stim din experienta atacatorilor ca de obicei se folosesc instructiunile delete, insert, union etc. le putem bloca cand sunt trimise prin URL. Astfel, chiar daca siteul in sine ar fi vulnerabil la SQL Injection din cauza codului, noi suntem protejati pentru ca mod_security are grija sa nu ni se intample nimic rau.

Ma opresc aici cu exemplificarile pentru ca trebuie sa va las si pe voi sa va puneti mintea la contributie si sa gasiti noi atacuri si metode de a bloca acele atacuri. Chiar mi-ar place sa vad ce puteti adauga la regulile de mai sus. As vedea asa ca ati inteles cum functioneaza.

Mai departe sa vedem ce picanterii putem adauga. O idee ar fi actiunea care e luata atunci cand cineva ne ataca. In mod implicit se tranteste un mesaj de eroare cu cod 406 si userul e blocat. Totusi, daca avem o aplicatie buggy e posibil ca o cerere valida sa fie interpretata ca fiind un atac. E urat ca vizitatorul sa vada ca e tratat ca un atacator. Ar fi bine sa il redirectam spre o pagina de eroare. De exemplu, putem face asa:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilterDefaultAction "redirect:/eroare.html"
 </ifmodule>

stfel oricand apare o problema, vizitatorul/atacatorul va fi redirectat catre eroare.html unde poate primi un mesaj frumos, aranjat, in care e anuntat ca a incercat sa faca ceva ce serverul considera ca nu e bine. Pentru siguranta pagina respectiva poate fi de fapt un script care preia toate datele vizitatorului (IP, proxy, OS,browser etc) si le trimite, in mod transparent, pe mail sau le salveaza intr-o baza de date pentru a urmari mai tarziu statisticile si posibilele cai de atac.

Cred ca a ajuns informatia. E mai mult decat o mica introducere. Daca aveti nelamuriri puteti apela cu incredere la documentatia oficiala care o gasiti la adresa: modsecurity.org/documentation/index.html

Ca un mic sfat, daca sunteti webmaster sau administrator de server, nu lasati mod_security si mod_rewrite sa treaca pe langa voi. Impreuna pot forma un firewall la nivel de aplicatie extraordinar.

Articol preluat de la http://www.lamp.ro

mod_security este un modul Apache care se comporta ca un filtru/firewall pentru web. Il putem invata cum ne-ar ataca cineva si ce am putea face ca sa ne aparam. De exemplu, se stie ca aplicatiile scrise in C pot fi vulnerabile la nullbyte attack. O solutie ar fi sa reparam aplicatia, dar daca e o aplicatie comerciala si nu avem acces la sursa nu avem ce-i face. Sau, chiar daca am avea acces la sursa, nu ar fi mai bine sa ne facem imuni la nullbyte attack decat sa stam cu frica-n spate ca poate cineva gaseste undeva o vulnerabilitate?

Ca sa rezolvam aceasta problema, trebuie sa instalam mod_security si apoi sa adaugam in httpd.conf urmatoarele linii:

Code:

<ifmodule mod_security.c>
    SecFilterEngine On
    SecFilterForceByteRange 1 255
 </ifmodule>

Instalarea mod_security se poate face simplu ca in cazul oricarui alt modul Apache folosind comanda apxs:

Code:

[root@localhost ~]# wget http://www.modsecurity.org/download/mod_security-1.7.4.tar.gz
 [root@localhost ~]# tar zxvf mod_security-1.7.4.tar.gz
 [root@localhost apache2]# cd mod_security-1.7.4/apache2
 [root@localhost apache2]# /usr/local/apache/bin/apxs -cia mod_security.c

Dupa instalare restartam serverul Apache si modulul devine functional. Acum, cand cineva incearca sa injecteze un nullbyte va primi un mesaj de eroare 406.

Dupa cum v-ati dat seama, in httpd.conf trebuie sa pornim filtrul pentru ca apoi sa putem seta diferite reguli. Asta se face folosind directiva “SecFilterEngine On“. Mai jos putem incepe sa adaugam reguli care sa ne protejeze. SecFilterForceByteRange e una din regulile folosite.

Mergand putin mai departe, ajungem la doua tipuri de atac care se bazeaza pe includerea de fisiere: RFI si LFI. De fapt e vorba de o singura vulnerabilitate in script care permite unei persoane rau intentionate sa includa un fisier, dar daca serverul e slab securizat acea vulnerabilitate poate permite includerea de fisiere remote – aici e diferenta intre RFI si LFI. Probabil va intrebati ce poate face mod_security cand vine vorba de RFI sau LFI. Ei bine, intotdeauna cand se gaseste o vulnerabilitate se doreste inserarea intr-o pagina a unui fisier care nu ar trebui sa fie vizibil. De exemplu, in cazul LFI, cineva ar vrea sa includa intr-un fisier public continutul fisierului.htpasswd. Ca sa ne protejam de astfel de specimene vom adauga urmatoarea regula:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "\.htpasswd"
 </ifmodule>

Din nou am pornit motorul filtrului iar apoi am creat un filtru care atunci cand gaseste in cerere sirul “.htpasswd” va genera o eroare si va bloca accesul. Astfel, daca cineva incearca ceva de genul asta:

Code:

http://www.exemplu.ro/fisier.php?variabila=.htpasswd

mod_security va detecta cererea ca atac si ii va bloca accesul. In cazul RFI putem face acelasi lucru, dar sa facem un filtru pentru http. De exemplu:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilterSelective THE_REQUEST "=http://"
 </ifmodule>

Astfel cand cineva incearca sa seteze o variabila cu o valoare care incepe cu http://, mod_security va sesiza din nou pericolul si va bloca accesul.

Bineinteles, mod_security poate face mai mult. Ne poate proteja, de exemplu, de atacuri de tip XSS. Se stie ca in XSS se incearca includerea unor scripturi ca informatii valide. De exemplu un atacator va incerca sa ofere ca si cale catre o imagine un cod JavaScript care sa fure cookieurile. Pentru a ne proteja de atacurile XSS transmise prin URL putem adauga urmatoarele coduri:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "javascript\://"
 SecFilter "img src=javascript"
 SecFilter "< [[:space:]]*script"
 SecFilter "<(.|\n)+>"
 </ifmodule>

La fel se poate adauga cate o regula pentru fiecare metoda de atac XSS prin URL care il detectati. Aici imi permit sa va indemn sa cautati alte metode de a injecta cod JavaScript. Cele 4 reguli sunt doar exemplificative. Posibilitatile sunt mai multe. Cautati si vedeti ce ati mai putea adauga ca sa va protejati.

Cum mod_security e mult mai destept decat pare ne poate proteja chiar si de SQL Injection. Adica, daca stim cum arata un atac de tip SQL Injection il putem bloca creand niste reguli de forma:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilter "insert[[:space:]]+into"
 SecFilter "select.+from"
 </ifmodule>

Cum stim din experienta atacatorilor ca de obicei se folosesc instructiunile delete, insert, union etc. le putem bloca cand sunt trimise prin URL. Astfel, chiar daca siteul in sine ar fi vulnerabil la SQL Injection din cauza codului, noi suntem protejati pentru ca mod_security are grija sa nu ni se intample nimic rau.

Ma opresc aici cu exemplificarile pentru ca trebuie sa va las si pe voi sa va puneti mintea la contributie si sa gasiti noi atacuri si metode de a bloca acele atacuri. Chiar mi-ar place sa vad ce puteti adauga la regulile de mai sus. As vedea asa ca ati inteles cum functioneaza.

Mai departe sa vedem ce picanterii putem adauga. O idee ar fi actiunea care e luata atunci cand cineva ne ataca. In mod implicit se tranteste un mesaj de eroare cu cod 406 si userul e blocat. Totusi, daca avem o aplicatie buggy e posibil ca o cerere valida sa fie interpretata ca fiind un atac. E urat ca vizitatorul sa vada ca e tratat ca un atacator. Ar fi bine sa il redirectam spre o pagina de eroare. De exemplu, putem face asa:

Code:

<ifmodule mod_security.c>
 SecFilterEngine On
 SecFilter "delete[[:space:]]+from"
 SecFilterDefaultAction "redirect:/eroare.html"
 </ifmodule>

stfel oricand apare o problema, vizitatorul/atacatorul va fi redirectat catre eroare.html unde poate primi un mesaj frumos, aranjat, in care e anuntat ca a incercat sa faca ceva ce serverul considera ca nu e bine. Pentru siguranta pagina respectiva poate fi de fapt un script care preia toate datele vizitatorului (IP, proxy, OS,browser etc) si le trimite, in mod transparent, pe mail sau le salveaza intr-o baza de date pentru a urmari mai tarziu statisticile si posibilele cai de atac.

Cred ca a ajuns informatia. E mai mult decat o mica introducere. Daca aveti nelamuriri puteti apela cu incredere la documentatia oficiala care o gasiti la adresa: modsecurity.org/documentation/index.html

Ca un mic sfat, daca sunteti webmaster sau administrator de server, nu lasati mod_security si mod_rewrite sa treaca pe langa voi. Impreuna pot forma un firewall la nivel de aplicatie extraordinar.

Articol preluat de la http://www.lamp.ro