Erinevus lehekülje "Modsecurity" redaktsioonide vahel

Allikas: Kuutõrvaja
(Uus lehekülg: 'ModSecurity On Apache jaoks kirutatud omalaadne tulemüür ja IDS/IPS lahendus mis võimaldab päringuid reeglite alusel filtreerida ning ebasoovitavate ja eelnevalt defineeritud m...')
 
(Viited)
 
(ei näidata sama kasutaja 77 vahepealset redaktsiooni)
1. rida: 1. rida:
ModSecurity
+
{{Täienda}}
  
On Apache jaoks kirutatud omalaadne tulemüür ja IDS/IPS lahendus mis võimaldab päringuid
+
===Sissejuhatus===
reeglite alusel filtreerida ning ebasoovitavate ja eelnevalt defineeritud mustrite esimise korral blokeerida
 
*http://en.wikipedia.org/wiki/ModSecurity
 
  
'''Install ja seadistus'''
+
ModSecurity, on nn veebiteenuse tulemüür
 +
(Web Application Firewall - WAF) ja IDS/IPS lahendus. Tegemist on tarkvaraga, mis
 +
filtreerib veebilehtedele tehtavaid päringuid ja üritab tõkestada
 +
nii rünnakuid serverile kui ka lehe näotustamise katseid.
  
TODO
+
===Install ja seadistus===
  
conf
+
FreeBSDs asub moodul portsude www/mod_security harus
 +
Gentoo ...
  
cat modsecurity.conf  
+
httpd.conf
  #LoadModule security_module    modules/mod_security.so
+
 
  #AddModule mod_security.c
+
Siin on tarvilik laadida moodul ja seejärel konfiguratsioonifail
 +
 
 +
  LoadModule security_module    modules/mod_security.so
 +
 
 +
või
 +
 
 +
  LoadModule security_module /usr/libexec/apache/mod_security.so
 +
 
 +
Ja
 +
 
 +
Include /etc/apache2/modsecurity.conf
 +
 
 +
modsecurity.conf sisu
 +
 
 +
<source lang=apache>
 
  <IfModule mod_security.c>
 
  <IfModule mod_security.c>
+
    # Enable ModSecurity
    # Enable ModSecurity
+
    SecFilterEngine On
    SecFilterEngine On
 
 
    # Reject requests with status 403
 
    SecFilterDefaultAction "deny,log,status:403"
 
 
    
 
    
    # Some sane defaults
+
    # Vaikimisi mittesobiv liiklus blokeeritakse, logitakse ja väljastatakse veakood.
    SecFilterScanPOST On
+
    # Tõkestatud liikluse tunnuseks on veakood 403 ja veebilehe asemel
    SecFilterCheckURLEncoding On
+
    # ekraanil näidatav kiri pealkirjaga "Forbidden".
    SecFilterCheckUnicodeEncoding Off
+
    SecFilterDefaultAction "deny,log,status:403"
 +
 
 +
    #Turn Audit on
 +
    SecAuditEngine On
 +
 
 +
    SecAuditLog logs/modsec_audit.log
 +
 
 +
    # Some sane defaults
 +
    SecFilterScanPOST On
 +
    SecFilterCheckURLEncoding On
 +
    SecFilterCheckUnicodeEncoding Off
 
   
 
   
 +
    # buffrite ületäitumise vastu nt SecFilterByteRange 32 126
 
     # Accept almost all byte values
 
     # Accept almost all byte values
 
     SecFilterForceByteRange 1 255
 
     SecFilterForceByteRange 1 255
 
   
 
   
     # Server masking is optional
+
     # ei säilita uploaditud faile analüüsiks
    # SecServerSignature "Microsoft-IIS/5.0"
 
 
    # Designate a directory for temporary files
 
    # storage. It is a good idea to change the
 
    # value below to a private directory, just as
 
    # an additional measure against race conditions
 
 
     SecUploadDir /tmp
 
     SecUploadDir /tmp
 
     SecUploadKeepFiles Off
 
     SecUploadKeepFiles Off
44. rida: 61. rida:
 
     # Uncomment below to record responses with unusual statuses
 
     # Uncomment below to record responses with unusual statuses
 
     # SecAuditLogRelevantStatus ^5
 
     # SecAuditLogRelevantStatus ^5
 +
   
 +
    # modsecurity peamine logifail
 
     SecAuditLog /var/log/apache2/modsec_audit.log
 
     SecAuditLog /var/log/apache2/modsec_audit.log
 
   
 
   
 
     # You normally won't need debug logging
 
     # You normally won't need debug logging
 
     SecFilterDebugLevel 0
 
     SecFilterDebugLevel 0
 +
    # modsecurity debug logi
 
     SecFilterDebugLog /var/log/apache2/modsec_debug.log
 
     SecFilterDebugLog /var/log/apache2/modsec_debug.log
 
   
 
   
     # lokaalne exclude list
+
     # lokaalne exclude list, ehk siis tühistame mõningad liiga karmid reeglid (süntaks toodud allpool)
 
     Include /etc/apache2/modsecurity/exclude.conf
 
     Include /etc/apache2/modsecurity/exclude.conf
 +
</IfModule>
 +
</source>
 +
 +
deny asemel võib panna ka esialgu debugimise eesmärgil pass.
 +
 +
Veel oleks mõistlik lisada vaikeseadistusele HTTP päringute päiseridadele filtrid,
 +
mis kontrollivad, et need vastaksid standarditele ja ei sisaldaks midagi lubamatut. Normaalse veebiliikluse puhul ei peaks need reeglid probleeme tekitama.
 +
 +
<source lang=apache>
 +
#Accept only valid protocol versions, helps fight HTTP fingerprinting
 +
SecFilterSelective SERVER_PROTOCOL !^HTTP/(0\.9|1\.0|1\.1)$
 +
#Allow supported request methods only
 +
SecFilterSelective REQUEST_METHOD !^(GET|HEAD|POST)$
 +
#Require HTTP_USER_AGENT and  HTTP_HOST, no telnet use.
 +
SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"
 +
#require Content-Length to be provided with every POST request.
 +
SecFilterSelective REQUEST_METHOD ^POST$ chain
 +
SecFilterSelective HTTP_Content-Length ^$
 +
</source>
 +
 +
/var/log/httpd/modsec_audit.log failist saab jälgida, kelle ta ära
 +
blokib. Tundub, et üsna hoogsalt üritatakse spämmi edastada. Kui keegi kurdab, et tal asjad ei tööta, siis tuleks auditi logist
 +
uurida ja vajadusel /etc/apache/modsecurity/exclude.conf-is sealsete
 +
näidete alusel vastavad ID-d välja lülitada (per LocationMatch või
 +
Directory vms).
 +
 +
modsecurity/exclude.conf
 +
 +
<source lang=apache>
 +
<Directory /www/html>
 +
SecFilterRemove 300018
 +
</Directory>
 
   
 
   
    # Gotroot.com'i reeglid
+
<Directory /lasteaed/www/html>
 +
SecFilterRemove 300018
 +
</Directory>
 
   
 
   
 +
<Directory /muistne/www/html/>
 +
SecFilterRemove 300018
 +
</Directory>
 +
</source>
 +
 +
Reegleid saab mõne veebi piires keelata ka näiteks .htaccess fail sisuga
 +
 +
  SecFilterEngine Off
 +
  SecFilterScanPOST Off
 +
 +
===Reeglite loomine===
 +
 +
Enamus filtreid rakenduvad HTTP GET päringutele
 +
 +
* teistele veebilehtedele viitamine täispika URLiga, nagu page=http://www.example.com/
 +
 +
SQL käsurea esinemine, nagu: "select * from"
 +
 +
    SecFilter "delete[[:space:]]+from"
 +
    SecFilter "insert[[:space:]]+into"
 +
    SecFilter "select.+from"
 +
 +
UNIXi käskude esinemine, nagu: wget, uname
 +
 +
SecFilterSelective THE_REQUEST "/bin/ps"
 +
SecFilterSelective THE_REQUEST "/bin/sh"
 +
SecFilterSelective THE_REQUEST "/tmp/sh"
 +
SecFilterSelective THE_REQUEST "/usr/bin/id"
 +
SecFilterSelective THE_REQUEST "/bin/kill"
 +
SecFilterSelective THE_REQUEST "/usr/bin/gcc"
 +
SecFilterSelective THE_REQUEST "/usr/bin/cc"
 +
SecFilterSelective THE_REQUEST "/usr/bin/g\+\+"
 +
SecFilterSelective THE_REQUEST "/bin/mail"
 +
SecFilterSelective THE_REQUEST "/bin/ls"
 +
 +
Unixi tavakäskude esinemise keelamine
 +
 +
SecFilter (uname|id|ls|cat|rm|kill|mail|su)
 +
 +
Kaustapuus tagasipöördumise keelamiseks, stiilis (../../).
 +
 +
SecFilter "\.\./"
 +
 +
Keelame unixi failisüsteemi kataloogide kasutamise.
 +
 +
SecFilter (/home/|/var/|/boot/|/etc/|/bin/|/usr/|/tmp/)
 +
 +
PHP koodi või funktsioonide, nagu: <?php, exec, fopen esinemine argumentides.
 +
 +
SecFilterSelective "THE_REQUEST|ARG_VALUES" "(system|exec|passthru|cmd|fopen|exit|fwrite)" deny,log
 +
 +
SecFilterSelective POST_PAYLOAD|REQUEST_URI "<\?php  (chr|fwrite|fopen|echr|passthru|popen|shell_exec|exec|proc_nice|proc_terminate|proc_g et_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posi x_setsid|posix_setuid|phpinfo)\(.*\)\;" "id:330002,rev:1,severity:2,msg:'Generic PHP exploit pattern denied'"
 +
 +
 +
 +
HTTP POST meetodiga saab edastada pikemaid tekste ja faile, mille puhul
 +
on raske kindlaks teha, kas tegemist on rünnakuga või näiteks Linuxi
 +
installeerimisjuhendiga, mistõttu selle meetodi päringute puhul
 +
tõkestatakse ainult liiklus, mis vastab täpselt mingi tuntud ründe
 +
mustrile.
 +
 +
Some of the other worms I've seen attempt to use wget to download scripts which they can then execute - so you can block those with:
 +
 +
SecFilter cd\x20/tmp
 +
SecFilter wget\x20
 +
 +
Although we've defined the general action to take against matched rules we can customize the actions on a per-rule basis. For example if we wish we can cause a redirect with the following:
 +
 +
SecFilter /etc/passwd redirect:http://www.foo.com/bad/request.html
 +
 +
Or if we wish we can execute a command to log the request:
 +
 +
SecFilter /bin/rm execute:/usr/local/bin/mail-admin.pl
 +
 +
SecFilter yyy log,exec:/home/ivanr/apache/bin/report-attack.pl
 +
 +
Here is an example rule –
 +
 +
 +
SecRule SCRIPT_USERNAME "!^apache$"
 +
 +
In this case, ModSecurity would only allow a script to execute if the owner of the script was the “apache” user.  So, in your scenario, “apache” would not be the owner of perl or sh so this should prevent execution.  You would need to test this with your exact scenario however to see if it works as expected.
 +
 
 +
    # Weaker XSS protection but allows common HTML tags
 +
    SecFilter "<( |\n)*script"
 +
 +
    # Prevent XSS atacks (HTML/Javascript injection)
 +
    SecFilter "<(.|\n)+>"
 +
 +
    # Require HTTP_USER_AGENT and HTTP_HOST headers
 +
    SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"
 +
 +
    # Only allow our own test utility to send requests (or Mozilla)
 +
    SecFilterSelective HTTP_USER_AGENT "!(mod_security|mozilla)"
 +
 +
===Kasutusnäide===
 +
 +
Meil on veeb, mis koosneb failidest.
 +
 +
*/user_view.php
 +
*/user_add.php
 +
 +
Tegemist lihtsa veebiga, mis näitab kasutajate nimekirja, lubab sinna kasutajaid
 +
lisada ning laadida ka kasutajatest pilte. Kahjuks pole aga veebi kood kuigi hea ja see on kirjutatud üsnagi hulk aega tagasi. Kuidas seda kaitsta pahade kavatsustega inimeste eest?
 +
 +
Võtame ülal viidetud vaikekonfi ja tekitame veebi kaitsmiseks sinna lisaks järgnevad reeglid:
 +
 +
<source lang=apache>
 +
<Location /user_view.php>
 +
    # This script only accepts GET
 +
    SecFilterSelective REQUEST_METHOD !^GET$
 +
    # Accept only one parameter: id
 +
    SecFilterSelective ARGS_NAMES !^id$
 +
    # Parameter id is mandatory, and it must be
 +
    # a number, 4-14 digits long
 +
    SecFilterSelective ARG_id !^[[:digit:]]{4,14}$
 +
</Location>
 +
</source>
 +
 +
<source lang=apache>
 +
<Location /user_add.php>
 +
      # This script only accepts POST
 +
    SecFilterSelective REQUEST_METHOD !^POST$
 +
      # Accept three parameters: firstname, lastname, and email
 +
    SecFilterSelective ARGS_NAMES !^(firstname|lastname|email)$
 +
      # Parameter firstname is mandatory, and it must
 +
      # contain text 1-64 characters long
 +
    SecFilterSelective ARG_firstname !^[[:alnum:][:space:]]{1,64}$
 +
    # Parameter lastname is mandatory, and it must
 +
    # contain text 1-64 characters long
 +
    SecFilterSelective ARG_lastname !^[ [:alnum:][:space:]]{1,64}$
 +
    # Parameter email is optional, but if it is present
 +
    # it must consist only of characters that are
 +
    # allowed in an email address
 +
    SecFilterSelective ARG_email !(^$|^[[:alnum:].@]{1,64}$)
 +
    # uploadida võib vaid teatud laiendiga faile
 +
    SecFilterSelective POST_PAYLOAD "!image/(jpeg|bmp|gif)"
 +
</Location>
 +
</source>
 +
 +
===Välised gotroot reeglikogumikud===
 +
 +
Gotroot.com'i http://www.gotroot.com/ reeglid http://www.gotroot.com/mod_security+rules
 +
 
     # exclude list
 
     # exclude list
 
     Include /etc/apache2/modsecurity/gotroot_exclude.conf
 
     Include /etc/apache2/modsecurity/gotroot_exclude.conf
 
 
     # application protection
 
     # application protection
 
     Include /etc/apache2/modsecurity/rules.conf
 
     Include /etc/apache2/modsecurity/rules.conf
 
 
     #rootkits
 
     #rootkits
 
     Include /etc/apache2/modsecurity/rootkits.conf
 
     Include /etc/apache2/modsecurity/rootkits.conf
</IfModule>
 
  
modsecurity/exclude.conf
+
põhireeglid rules.conf failis on ilmselt kõige mõistlikumad. Lisaks tasub includeda
 +
rootkits.conf, mis peaks tõkestama kõiksugu failide includemised jmt.
 +
 
 +
badips on 7000~ rida IP numbreid, mida võiks põhimõtteliselt tulemüüri või kuhugi
 +
toppida ja ei pea apache regexides kasutama). Ilmselt on mõistlik badips.conf fail küljes hoida juhul
 +
kui soov vähendada DDoSi võimalust, kahjuks kõiki maailma halbu aadresse blokeerida ei jõua.
 +
 
 +
===Veel mõned tähelepanekud===
  
</Directory>
+
Modsecurity rakendamisel default reeglitega tõstis normaalse koormuse juures loadi tunduvalt.
 +
Siis kommenteerisin välja suure hulga reegleid, mis spämmisaatmise vastu
 +
võitlevad (regexpi kontrollid) ja load jäi 1 ja 1.5 kanti.
  
<Directory /www/html>
+
Apache 1.3 puhul tasub mod_security kompileerida libpcre abil ja panin apache libpcre sisse
SecFilterRemove 300018
+
laadima - nii ei kasutata enam apache 1.3 seesmist regexi mootorit mis
</Directory>
+
on pcre-st kordades aeglasem.
  
<Directory /lasteaed/www/html>
+
===Viited===
SecFilterRemove 300018
 
</Directory>
 
  
<Directory /muistne/www/html/>
+
* http://www.modsecurity.org/documentation/
SecFilterRemove 300018
+
* http://www.howtoforge.com/remo_modsecurity_apache
</Directory>
+
* http://blog.supportpro.com/2009/08/mod_security-intro/
 +
http://www.thebitsource.com/infrastructure-operations/web-application/securing-apache-web-servers-modsecurity/
  
'''Märkmeid kasutamisest'''
+
http://www.askapache.com/htaccess/mod_security-htaccess-tricks.html
  
rakendamisel viskas praeguse (normaalse) koormuse juures loadi 20-le.
+
http://www.modsecurity.org/documentation/modsecurity-apache/1.9.3/html-multipage/05-actions.html
Siis kommenteerisin välja suure hulga reegleid, mis spämmisaatmise vastu
 
võitlevad (regexpi kontrollid) ja load jäi 1 ja 1.5 kanti.
 
  
Ilmselt on mõistlik
+
http://atomicplayboy.net/blog/2005/01/30/an-introduction-to-mod-security/
badips.conf fail küljes hoida, et vähendada DDoSi võimalust pisutki,
 
põhireeglid rules.conf kah ilmselt mõistlik. Hetkel küljes ka
 
rootkits.conf, mis peaks tõkestama kõiksugu failide includemised jmt.
 
  
/var/log/httpd/modsec_audit.log failist saab jälgida, kelle ta ära
+
http://penguinsecurity.net/wiki/index.php?title=Web_Security_Appliance_With_Apache_and_mod_security
blokib. Tundub, et üsna hoogsalt üritatakse mingit spämmi vms edastada.
 
  
Apache 1.3 puhul tasub
+
http://www.g-loaded.eu/2006/08/24/modsecurity-overview/
mod_security kompileerida libpcre abil ja panin apache libpcre sisse
 
laadima - nii ei kasutata enam apache 1.3 seesmist regexi mootorit mis
 
on pcre-st kordades aeglasem.
 
  
Ühtlasi jätsin alles reeglid: rules.conf ja rootkits.conf (badips oli
+
Abivahendid
7000 rida IP numbreid, mida võiks põhimõtteliselt tulemüüri või kuhugi
 
toppida ja ei pea apache regexides kasutama).
 
  
Seejärel on masina load 0.4 - 0.8 kandis püsinud. Ehk võib siis käima jätta
+
http://www.netnea.com/cms/?q=remo ruulide loomise vahend
niimoodi.
 
  
PS. Kui keegi kurdab, et tal asjad ei tööta, siis tuleks auditi logist
+
http://www.owasp.org/index.php/Category:OWASP_WeBekci_Project haldusvahend
uurida ja vajadusel /etc/apache/modsecurity/exclude.conf-is sealsete
 
näidete alusel vastavad ID-d välja lülitada (per LocationMatch või
 
Directory vms).
 
  
Reegleid saab mõne veebi piires keelata ka näiteks .htaccess fail sisuga
+
https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_security-with-apache-on-debian-ubuntu kuidas filtreerida post formist välja spämmi.
  
  SecFilterEngine Off
+
[[Kategooria:veeb]]
  SecFilterScanPOST Off
+
[[Kategooria:turvalisus]]

Viimane redaktsioon: 28. juuli 2015, kell 21:37

                                        Roheline.jpg Toores. Ehk seda pala võib täiendada.

Sissejuhatus

ModSecurity, on nn veebiteenuse tulemüür (Web Application Firewall - WAF) ja IDS/IPS lahendus. Tegemist on tarkvaraga, mis filtreerib veebilehtedele tehtavaid päringuid ja üritab tõkestada nii rünnakuid serverile kui ka lehe näotustamise katseid.

Install ja seadistus

FreeBSDs asub moodul portsude www/mod_security harus Gentoo ...

httpd.conf

Siin on tarvilik laadida moodul ja seejärel konfiguratsioonifail

LoadModule security_module    modules/mod_security.so

või

LoadModule security_module /usr/libexec/apache/mod_security.so

Ja

Include /etc/apache2/modsecurity.conf

modsecurity.conf sisu

 <IfModule mod_security.c>
    # Enable ModSecurity
    SecFilterEngine On
  
    # Vaikimisi mittesobiv liiklus blokeeritakse, logitakse ja väljastatakse veakood.
    # Tõkestatud liikluse tunnuseks on veakood 403 ja veebilehe asemel
    # ekraanil näidatav kiri pealkirjaga "Forbidden".
    SecFilterDefaultAction "deny,log,status:403"

    #Turn Audit on
    SecAuditEngine On

    SecAuditLog logs/modsec_audit.log 
   
    # Some sane defaults
    SecFilterScanPOST On
    SecFilterCheckURLEncoding On
    SecFilterCheckUnicodeEncoding Off
 
    # buffrite ületäitumise vastu nt SecFilterByteRange 32 126
    # Accept almost all byte values
    SecFilterForceByteRange 1 255
 
    # ei säilita uploaditud faile analüüsiks 
    SecUploadDir /tmp
    SecUploadKeepFiles Off
 
    # Only record the interesting stuff
    SecAuditEngine RelevantOnly
    # Uncomment below to record responses with unusual statuses
    # SecAuditLogRelevantStatus ^5
    
    # modsecurity peamine logifail
    SecAuditLog /var/log/apache2/modsec_audit.log
 
    # You normally won't need debug logging
    SecFilterDebugLevel 0
    # modsecurity debug logi
    SecFilterDebugLog /var/log/apache2/modsec_debug.log
 
    # lokaalne exclude list, ehk siis tühistame mõningad liiga karmid reeglid (süntaks toodud allpool)
    Include /etc/apache2/modsecurity/exclude.conf
 </IfModule>

deny asemel võib panna ka esialgu debugimise eesmärgil pass.

Veel oleks mõistlik lisada vaikeseadistusele HTTP päringute päiseridadele filtrid, mis kontrollivad, et need vastaksid standarditele ja ei sisaldaks midagi lubamatut. Normaalse veebiliikluse puhul ei peaks need reeglid probleeme tekitama.

 #Accept only valid protocol versions, helps fight HTTP fingerprinting
 SecFilterSelective SERVER_PROTOCOL !^HTTP/(0\.9|1\.0|1\.1)$
 #Allow supported request methods only
 SecFilterSelective REQUEST_METHOD !^(GET|HEAD|POST)$
 #Require HTTP_USER_AGENT and  HTTP_HOST, no telnet use.
 SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"
 #require Content-Length to be provided with every POST request.
 SecFilterSelective REQUEST_METHOD ^POST$ chain
 SecFilterSelective HTTP_Content-Length ^$

/var/log/httpd/modsec_audit.log failist saab jälgida, kelle ta ära blokib. Tundub, et üsna hoogsalt üritatakse spämmi edastada. Kui keegi kurdab, et tal asjad ei tööta, siis tuleks auditi logist uurida ja vajadusel /etc/apache/modsecurity/exclude.conf-is sealsete näidete alusel vastavad ID-d välja lülitada (per LocationMatch või Directory vms).

modsecurity/exclude.conf

 <Directory /www/html>
 SecFilterRemove 300018
 </Directory>
 
 <Directory /lasteaed/www/html>
 SecFilterRemove 300018
 </Directory>
 
 <Directory /muistne/www/html/>
 SecFilterRemove 300018
 </Directory>

Reegleid saab mõne veebi piires keelata ka näiteks .htaccess fail sisuga

  SecFilterEngine Off
  SecFilterScanPOST Off

Reeglite loomine

Enamus filtreid rakenduvad HTTP GET päringutele

SQL käsurea esinemine, nagu: "select * from"

   SecFilter "deletespace:+from"
   SecFilter "insertspace:+into"
   SecFilter "select.+from"

UNIXi käskude esinemine, nagu: wget, uname

SecFilterSelective THE_REQUEST "/bin/ps"
SecFilterSelective THE_REQUEST "/bin/sh"
SecFilterSelective THE_REQUEST "/tmp/sh"
SecFilterSelective THE_REQUEST "/usr/bin/id"
SecFilterSelective THE_REQUEST "/bin/kill"
SecFilterSelective THE_REQUEST "/usr/bin/gcc"
SecFilterSelective THE_REQUEST "/usr/bin/cc"
SecFilterSelective THE_REQUEST "/usr/bin/g\+\+"
SecFilterSelective THE_REQUEST "/bin/mail"
SecFilterSelective THE_REQUEST "/bin/ls"

Unixi tavakäskude esinemise keelamine

SecFilter (uname|id|ls|cat|rm|kill|mail|su)

Kaustapuus tagasipöördumise keelamiseks, stiilis (../../).

SecFilter "\.\./"

Keelame unixi failisüsteemi kataloogide kasutamise.

SecFilter (/home/|/var/|/boot/|/etc/|/bin/|/usr/|/tmp/)

PHP koodi või funktsioonide, nagu: <?php, exec, fopen esinemine argumentides.

SecFilterSelective "THE_REQUEST|ARG_VALUES" "(system|exec|passthru|cmd|fopen|exit|fwrite)" deny,log
SecFilterSelective POST_PAYLOAD|REQUEST_URI "<\?php  (chr|fwrite|fopen|echr|passthru|popen|shell_exec|exec|proc_nice|proc_terminate|proc_g et_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posi x_setsid|posix_setuid|phpinfo)\(.*\)\;" "id:330002,rev:1,severity:2,msg:'Generic PHP exploit pattern denied'"


HTTP POST meetodiga saab edastada pikemaid tekste ja faile, mille puhul on raske kindlaks teha, kas tegemist on rünnakuga või näiteks Linuxi installeerimisjuhendiga, mistõttu selle meetodi päringute puhul tõkestatakse ainult liiklus, mis vastab täpselt mingi tuntud ründe mustrile.

Some of the other worms I've seen attempt to use wget to download scripts which they can then execute - so you can block those with:

SecFilter cd\x20/tmp
SecFilter wget\x20

Although we've defined the general action to take against matched rules we can customize the actions on a per-rule basis. For example if we wish we can cause a redirect with the following:

SecFilter /etc/passwd redirect:http://www.foo.com/bad/request.html

Or if we wish we can execute a command to log the request:

SecFilter /bin/rm execute:/usr/local/bin/mail-admin.pl
SecFilter yyy log,exec:/home/ivanr/apache/bin/report-attack.pl

Here is an example rule –


SecRule SCRIPT_USERNAME "!^apache$"

In this case, ModSecurity would only allow a script to execute if the owner of the script was the “apache” user. So, in your scenario, “apache” would not be the owner of perl or sh so this should prevent execution. You would need to test this with your exact scenario however to see if it works as expected.

   # Weaker XSS protection but allows common HTML tags
   SecFilter "<( |\n)*script"

   # Prevent XSS atacks (HTML/Javascript injection)
   SecFilter "<(.|\n)+>"

   # Require HTTP_USER_AGENT and HTTP_HOST headers
   SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"
   # Only allow our own test utility to send requests (or Mozilla)
   SecFilterSelective HTTP_USER_AGENT "!(mod_security|mozilla)"

Kasutusnäide

Meil on veeb, mis koosneb failidest.

  • /user_view.php
  • /user_add.php

Tegemist lihtsa veebiga, mis näitab kasutajate nimekirja, lubab sinna kasutajaid lisada ning laadida ka kasutajatest pilte. Kahjuks pole aga veebi kood kuigi hea ja see on kirjutatud üsnagi hulk aega tagasi. Kuidas seda kaitsta pahade kavatsustega inimeste eest?

Võtame ülal viidetud vaikekonfi ja tekitame veebi kaitsmiseks sinna lisaks järgnevad reeglid:

 <Location /user_view.php>
     # This script only accepts GET
     SecFilterSelective REQUEST_METHOD !^GET$
     # Accept only one parameter: id
     SecFilterSelective ARGS_NAMES !^id$
     # Parameter id is mandatory, and it must be
     # a number, 4-14 digits long
     SecFilterSelective ARG_id !^[[:digit:]]{4,14}$
 </Location>
 <Location /user_add.php>
      # This script only accepts POST
     SecFilterSelective REQUEST_METHOD !^POST$
      # Accept three parameters: firstname, lastname, and email
     SecFilterSelective ARGS_NAMES !^(firstname|lastname|email)$
      # Parameter firstname is mandatory, and it must
      # contain text 1-64 characters long
    SecFilterSelective ARG_firstname !^[[:alnum:][:space:]]{1,64}$
     # Parameter lastname is mandatory, and it must
     # contain text 1-64 characters long
    SecFilterSelective ARG_lastname !^[ [:alnum:][:space:]]{1,64}$
     # Parameter email is optional, but if it is present
     # it must consist only of characters that are
     # allowed in an email address 
    SecFilterSelective ARG_email !(^$|^[[:alnum:].@]{1,64}$)
     # uploadida võib vaid teatud laiendiga faile
    SecFilterSelective POST_PAYLOAD "!image/(jpeg|bmp|gif)"
 </Location>

Välised gotroot reeglikogumikud

Gotroot.com'i http://www.gotroot.com/ reeglid http://www.gotroot.com/mod_security+rules

   # exclude list
   Include /etc/apache2/modsecurity/gotroot_exclude.conf
   # application protection
   Include /etc/apache2/modsecurity/rules.conf
   #rootkits
   Include /etc/apache2/modsecurity/rootkits.conf

põhireeglid rules.conf failis on ilmselt kõige mõistlikumad. Lisaks tasub includeda rootkits.conf, mis peaks tõkestama kõiksugu failide includemised jmt.

badips on 7000~ rida IP numbreid, mida võiks põhimõtteliselt tulemüüri või kuhugi toppida ja ei pea apache regexides kasutama). Ilmselt on mõistlik badips.conf fail küljes hoida juhul kui soov vähendada DDoSi võimalust, kahjuks kõiki maailma halbu aadresse blokeerida ei jõua.

Veel mõned tähelepanekud

Modsecurity rakendamisel default reeglitega tõstis normaalse koormuse juures loadi tunduvalt. Siis kommenteerisin välja suure hulga reegleid, mis spämmisaatmise vastu võitlevad (regexpi kontrollid) ja load jäi 1 ja 1.5 kanti.

Apache 1.3 puhul tasub mod_security kompileerida libpcre abil ja panin apache libpcre sisse laadima - nii ei kasutata enam apache 1.3 seesmist regexi mootorit mis on pcre-st kordades aeglasem.

Viited

http://www.thebitsource.com/infrastructure-operations/web-application/securing-apache-web-servers-modsecurity/

http://www.askapache.com/htaccess/mod_security-htaccess-tricks.html

http://www.modsecurity.org/documentation/modsecurity-apache/1.9.3/html-multipage/05-actions.html

http://atomicplayboy.net/blog/2005/01/30/an-introduction-to-mod-security/

http://penguinsecurity.net/wiki/index.php?title=Web_Security_Appliance_With_Apache_and_mod_security

http://www.g-loaded.eu/2006/08/24/modsecurity-overview/

Abivahendid

http://www.netnea.com/cms/?q=remo ruulide loomise vahend

http://www.owasp.org/index.php/Category:OWASP_WeBekci_Project haldusvahend

https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_security-with-apache-on-debian-ubuntu kuidas filtreerida post formist välja spämmi.