Erinevus lehekülje "Modsecurity" redaktsioonide vahel
(→Kasutusnäide) |
(→Reeglite loomine) |
||
149. rida: | 149. rida: | ||
tõkestatakse ainult liiklus, mis vastab täpselt mingi tuntud ründe | tõkestatakse ainult liiklus, mis vastab täpselt mingi tuntud ründe | ||
mustrile. | 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 | ||
+ | |||
+ | |||
+ | 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" | ||
+ | |||
+ | 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. | ||
+ | |||
<source lang=apache> | <source lang=apache> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
# Simple filter | # Simple filter | ||
165. rida: | 195. rida: | ||
# Only check the body of the POST request | # Only check the body of the POST request | ||
SecFilterSelective POST_PAYLOAD 333 | SecFilterSelective POST_PAYLOAD 333 | ||
− | + | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
# Prevent OS specific keywords | # Prevent OS specific keywords | ||
SecFilter /etc/password | SecFilter /etc/password | ||
192. rida: | 215. rida: | ||
# Forbid file upload | # Forbid file upload | ||
SecFilterSelective "HTTP_CONTENT_TYPE" multipart/form-data | SecFilterSelective "HTTP_CONTENT_TYPE" multipart/form-data | ||
− | + | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
# Only allow our own test utility to send requests (or Mozilla) | # Only allow our own test utility to send requests (or Mozilla) | ||
SecFilterSelective HTTP_USER_AGENT "!(mod_security|mozilla)" | SecFilterSelective HTTP_USER_AGENT "!(mod_security|mozilla)" | ||
− | + | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Unixi tavakäskude esinemise keelamine | Unixi tavakäskude esinemise keelamine | ||
Redaktsioon: 8. mai 2012, kell 16:47
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
# 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>
deny asemel võib panna ka esialgu debugimise eesmärgil pass.
Veel oleks mõistlik lisada järgnevad asjad:
#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 ^$
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.
Reeglite uuendamiseks:
# /usr/local/modsecurity/bin/rules-updater.pl \ -rhttp://www.modsecurity.org/autoupdate/repository/ -p rules -Smodsecurity-crs
/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, keelatud on m.h. järgnev:
- teistele veebilehtedele viitamine täispika URLiga, nagu page=http://www.example.com/
- SQL käsurea esinemine, nagu: "select * from"
- UNIXi käskude esinemine, nagu: wget, uname
- PHP koodi või funktsioonide esinemine, nagu: <?php, exec, fopen
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
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"
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.
# Simple filter
SecFilter 111
# Only check the QUERY_STRING variable
SecFilterSelective QUERY_STRING 222
# Only check the body of the POST request
SecFilterSelective POST_PAYLOAD 333
# Prevent OS specific keywords
SecFilter /etc/password
# Weaker XSS protection but allows common HTML tags
SecFilter "<( |\n)*script"
# Prevent XSS atacks (HTML/Javascript injection)
SecFilter "<(.|\n)+>"
# Very crude filters to prevent SQL injection attacks
SecFilter "delete[[:space:]]+from"
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"
# Require HTTP_USER_AGENT and HTTP_HOST headers
SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"
# Forbid file upload
SecFilterSelective "HTTP_CONTENT_TYPE" multipart/form-data
# Only allow our own test utility to send requests (or Mozilla)
SecFilterSelective HTTP_USER_AGENT "!(mod_security|mozilla)"
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/)
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>
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.
Lisaks rakenduvad kõigile ülejäänud HTTP päringu päiseridadele filtrid, mis kontrollivad, et need vastaksid standarditele ja ei sisaldaks midagi lubamatut. Normaalse veebiliikluse puhul need reeglid aga probleeme ei peaks tekitama.
Viited
- http://www.modsecurity.org/documentation/
- http://www.howtoforge.com/remo_modsecurity_apache
- http://blog.supportpro.com/2009/08/mod_security-intro/
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
http://www.modsecurity.org/projects/console/index.html ametlik konsool alertide vaatamiseks ja reeglite haldamiseks