Erinevus lehekülje "Modsecurity" redaktsioonide vahel

Allikas: Kuutõrvaja
59. rida: 59. rida:
 
     Include /etc/apache2/modsecurity/rootkits.conf
 
     Include /etc/apache2/modsecurity/rootkits.conf
 
  </IfModule>
 
  </IfModule>
 +
 +
põhireeglid rules.conf ilmselt kõige mõistlikum. Hetkel küljes ka
 +
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.
 +
 +
/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
 
modsecurity/exclude.conf
73. rida: 86. rida:
 
  SecFilterRemove 300018
 
  SecFilterRemove 300018
 
  </Directory>
 
  </Directory>
 +
 +
Reegleid saab mõne veebi piires keelata ka näiteks .htaccess fail sisuga
 +
 +
  SecFilterEngine Off
 +
  SecFilterScanPOST Off
  
 
'''Märkmeid kasutamisest'''
 
'''Märkmeid kasutamisest'''
  
rakendamisel viskas praeguse (normaalse) koormuse juures loadi 20-le.
+
rakendamisel default reeglitega tõstis normaalse koormuse juures loadi tunduvalt.
 
Siis kommenteerisin välja suure hulga reegleid, mis spämmisaatmise vastu
 
Siis kommenteerisin välja suure hulga reegleid, mis spämmisaatmise vastu
 
võitlevad (regexpi kontrollid) ja load jäi 1 ja 1.5 kanti.
 
võitlevad (regexpi kontrollid) ja load jäi 1 ja 1.5 kanti.
  
Ilmselt on mõistlik
+
Apache 1.3 puhul tasub mod_security kompileerida libpcre abil ja panin apache libpcre sisse
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
 
blokib. Tundub, et üsna hoogsalt üritatakse mingit spämmi vms edastada.
 
 
 
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
 
laadima - nii ei kasutata enam apache 1.3 seesmist regexi mootorit mis
 
on pcre-st kordades aeglasem.
 
on pcre-st kordades aeglasem.
 
Ühtlasi jätsin alles reeglid: rules.conf ja rootkits.conf (badips oli
 
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
 
niimoodi.
 
 
PS. 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).
 
 
Reegleid saab mõne veebi piires keelata ka näiteks .htaccess fail sisuga
 
 
  SecFilterEngine Off
 
  SecFilterScanPOST Off
 

Redaktsioon: 30. september 2010, kell 12:01

ModSecurity

On Apache jaoks kirutatud IDS/IPS lahendus mis võimaldab päringuid reeglite alusel filtreerida ning ebasoovitavate ja eelnevalt defineeritud mustrite esimise korral blokeerida

Install ja seadistus

TODO

modsecurity.conf

#LoadModule security_module    modules/mod_security.so
#AddModule mod_security.c
<IfModule mod_security.c>

    # Enable ModSecurity
    SecFilterEngine On

    # Reject requests with status 403
    SecFilterDefaultAction "deny,log,status:403"
 
    # Some sane defaults
    SecFilterScanPOST On
    SecFilterCheckURLEncoding On
    SecFilterCheckUnicodeEncoding Off

   # Accept almost all byte values
   SecFilterForceByteRange 1 255

   # Server masking is optional
   # 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
   SecUploadKeepFiles Off

   # Only record the interesting stuff
   SecAuditEngine RelevantOnly
   # Uncomment below to record responses with unusual statuses
   # SecAuditLogRelevantStatus ^5
   SecAuditLog /var/log/apache2/modsec_audit.log

   # You normally won't need debug logging
   SecFilterDebugLevel 0
   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

   # Gotroot.com'i http://www.gotroot.com/ reeglid
   # exclude list
   Include /etc/apache2/modsecurity/gotroot_exclude.conf
   # application protection
   Include /etc/apache2/modsecurity/rules.conf
   #rootkits
   Include /etc/apache2/modsecurity/rootkits.conf
</IfModule>

põhireeglid rules.conf ilmselt kõige mõistlikum. Hetkel küljes ka 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.

/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

Märkmeid kasutamisest

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.