Leking med modsecurity

Leking med modsecurity

Mon 04 August 2014

I denne posten skriver jeg kort om hva mod_security er og hvordan du installerer det på din Centos server. Jeg vil også vise noen enkle regelsett du kan bruke for å komme igang, samt noen referanser til videre lesestoff og videoer.

Hva er modsecurity?

Det finnes bøker og dokumentasjon som tar for seg dette bedre en det jeg kan gjøre her, men jeg vil gi en veldig kort introduksjon (i stikkordsform) som forhåpentligvis gjør at du vurderer å teste ut modsecurity.

Modsecurity er en webapplikasjonsbrannmur (eng: Web Application Firewall, WAF). Det vil si at den ligger foran webtjenesten din og ser etter ulumskheter.

Modsecurity er gratis, åpen kildekode, og har vært utviklet siden 2002.

Modsecurity er regelstyrt, det vil si at all trafikken som skal igjennom modsecurity må testes mot en eller flere regler. En regel kan avslå eller godta trafikk.

En regel er satt sammen av 4 deler:

  • variabler (eng: variables)
  • operatorer (eng: operators)
  • transformasjoner (eng: transformations)
  • hendelser (eng: actions)

Trafikken som skal evalueres går igjennom 5 faser:

  • phase 1: request headers
  • phase 2: request body
  • phase 3: response headers
  • phase 4: response body
  • phaase 5: logging

Hver regel definerer hvilken av de 5 fasene den operer på.

Les mer om fasene her: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Processing_Phases

Vi kan spesifisere hvilken deler av trafikken vi vil jobbe med (variables), f.eks:

  • REMOTE_ADDR
  • ARGS
  • FILES
  • REQUEST_BODY, REQUEST_COOKIES, REQUEST_METHOD RESPONSE_BODY, RESPONSE_HEADER, RESPONSE_STATUS

Se liste over alle variables her: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Variables

Vi kan spesifisere hvordan vi vil analysere trafikken (operators), f.eks:

  • string matching (@beginsWith, @rsub, @rx)
  • numerical (@eq, @ge, @gt)
  • validation (@validateByteRange, @validateSchema, @validateUrlEncoding) miscellaneous (@geoLookup, @verifyCC, @ipMatch)

Se liste over alle operators her: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Operators

Vi kan modifisere trafikken (transformations), f.eks:

  • base64decode, base64encode length
  • lowercase
  • sha1, md5

Se liste over alle transformations her: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Transformation_functions

Vi kan gjøre noe med trafikken basert på om regelen matcher eller ikke (actions), f.eks:

  • are disruptive (allow, block, deny, drop, proxy, pass, redirect) affect rule flow (chain, skip, skipAfter)
  • affect metadata (id, phase, msg, rev, severity tag)
  • affect variables (capture, deprecatevar, setvar, setuid)

Se liste over alle actions her: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Actions

Du kan også koble sammen flere regler (eng: chaining), bygge opp treff for så å blokkere på en gitt treshold (eng: assign score) og mye mer.

Dette er avanserte temaer som du kan finne mer informasjon om ved å kikke på "Referanser / Lenker / Ressurser" på slutten av denne artikkelen.

Når du om litt får se eksempel på en regel vil du forhåpentligvis kjenne igjen oppbygningen som jeg har skissert over, og dermed burde det hele være litt mindre skummelt.

Når vi installerer modsecurity vil vi også installere det som kalles "core-rule-set, crs", som er en samling av regler som man kan ta utgangspunkt i. Dette betyr at du slipper å bygge regler fra grunnen av.

CRS samlingen vedlikeholdes av OWASP prosjektet, og gir deg et sett av regler som detekterer de mest vanlige angrepsvektorene.

Installer modsecurity

1: Legg til EPEL repository.


# wget http://dl.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.2.noarch.rpm
# rpm -ivh epel-release-7-0.2.noarch.rpm

2: Installer alle tilgjengelige modsecurity pakker.



# yum install mod_security


# yum install mod_security_crs

Dette gir deg følgende to pakker:

- mod_security.i686 : Security module for the Apache HTTP Server
- mod_security_crs.noarch : ModSecurity Rules

3: Vi får nå en ny mappe i /etc/httpd/modsecurity.d.



# ls /etc/httpd/modsecurity.d/
activated_rules  modsecurity_crs_10_config.conf

4: Kikk i filen "modsecurity_crs_10_config.conf". Den er godt dokumentert og gir en pekepinn på hvilken muligher vi har.



# cat /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf

Geolokaliser besøkene dine

Vi ønsker å kunne vite hvor ipadresser kommer fra. Dette vil gi oss mulighet til å blokkere tilkoblinger som kommer fra land som f.eks er kjent for å ha store botnett.

Installer GeoIP databasen:



# mkdir -p /opt/modsecurity/lib/


# cd /opt/modsecurity/lib/


# wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz


# gunzip GeoLiteCity.dat.gz

Oppdater konfigurasjon til å bruke GeoIP databasen:

Rediger filen modsecurity_crs_10_config.conf, og avkommenter følgende linje for å aktivere GeoIP databasen din.



155 #
156 # -- [[ GeoIP Database ]] -----------------------------------------------------------------
157 #
158 # There are some rulesets that need to inspect the GEO data of the REMOTE_ADDR data.
159 #
160 # You must first download the MaxMind GeoIP Lite City DB -
161 #
162 #       http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
163 #
164 # You then need to define the proper path for the SecGeoLookupDb directive
165 #
166 # Ref: http://blog.spiderlabs.com/2010/10/detecting-malice-with-modsecurity-geolocation-data.html
167 # Ref: http://blog.spiderlabs.com/2010/11/detecting-malice-with-modsecurity-ip-forensics.html
168 #
169 #SecGeoLookupDb /opt/modsecurity/lib/GeoLiteCity.dat
170
171 #

Restart apache for å laste inn den nye modsecurity konfigurasjonen.



# apachectl restart

Konfigurasjonsregel som blokkerer basert på geolokasjon:

Nå som vi har geolokalisering ønsker vi å blokkere basert på dette. Vi ønsker kun å tillate trafikk fra norske IP-adresser:

  • Lag din egen regelfil i /etc/http/modsecurity.d/activated_rules



vi /etc/httpd/modsecurity.d/activated_rules/modsecurity_custom_70_geoblock.conf

  • Lim inn følgende innhold:


SecRule REMOTE_ADDR "@geoLookup" "id:5,phase:1,t:none,pass,nolog"
 SecRule GEO:COUNTRY_CODE3 "!@streq NOR" "id:6,phase:1,t:none,log,deny,msg:'Client IP not from Norway'"

  • Vi blokkerer nå all trafikk som ikke kommer fra Norge.

Detekter HTTP fingerprinting

Vi ønsker å detektere HTTP fingerprinting, samt endre strengen angriperen får tilbake. Dette gjør at vi kan lure angriperen til å tro at webserveren vår er noe annet en det den faktisk er.

  • Lag en ny fil i /etc/http/modsecurity.d/activated_rules



# vi /etc/http/modsecurity.d/activated_rules/modsecurity_custom_70_http_fingerprinting.conf

  • Lim inn følgende innhold


#
# Defeat HTTP fingerprinting
#

# Change server signature
SecServerSignature "Microsoft-IIS/6.0"

# Deny requests without a host header
SecRule &REQUEST_HEADERS:Host "@eq 0" "id:1,phase:1,deny"

# Deny requests without an accept header
SecRule &REQUEST_HEADERS:Accept "@eq 0" "id:2,phase:1,deny"

# Deny request that don't use GET, HEAD or POST
SecRule REQUEST_METHOD !^(get|head|post)$ "id:3,phase:1,t:lowerCase,deny"

# Only allow HTTP version 1.0 and 1.1
SecRule REQUEST_PROTOCOL !^http/1.(0|1)$ "id:4,phase:1,t:lowercase,deny"

# Add X-Powered-By header to mimic IIS
Header set X-Powered-By "ASP.NET 2.0"

# Remove the ETag header
Header unset ETag

Restart apache for å laste inn den nye modsecurity konfigurasjonen.



# apachectl restart

  • Merk at vi bruker en unik ID på reglene våre i eksempelet over. Du har forskjellige navnerom som er reservert til forskjellig bruk.
  • Liste over tilgjengelige og reserverte ider finner du her: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-id

Logging av modsecurity

En av styrkene til modsecurity er muligheten til å logge alt som skjer. Vi kan logge til webserveren sin error.log, modsecurity_audit, eller begge deler. Default for de fleste regler er å logge til begge loggfilene.

Personlig liker jeg å skille modsec beskjeder ut i en egen loggfil fordi det potensielt kan bli mye data i denne loggen.



# tail -f /var/log/httpd/modsec_audit.log

Om du trenger enda med data om hva som foregår kan du skru på debug logging:

  • vi /etc/httpd/conf.d/mod_security.conf


    SecDebugLog /var/log/httpd/modsec_debug.log
    SecDebugLogLevel 3

Annet

Dette avsnittet fikk jeg behov for siden puppet fjernet vitale deler av modsecurity konfigurasjonen min.

  • Om ikke modulen laster må du legge inn følgende i /etc/httpd/conf.d/modsecurity.load


LoadModule security2_module modules/mod_security2.so

<IfModule !mod_unique_id.c>
    LoadModule unique_id_module modules/mod_unique_id.so
</IfModule>

  • Vi trenger også følgende i /etc/httpd/conf.d/modsecurity.conf



<IfModule mod_security2.c>
    # ModSecurity Core Rules Set configuration
    IncludeOptional modsecurity.d/*.conf
    IncludeOptional modsecurity.d/activated_rules/*.conf

    # Default recommended configuration
    SecRuleEngine On
    SecRequestBodyAccess On
    SecRule REQUEST_HEADERS:Content-Type "text/xml" \
         "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
    SecRequestBodyLimit 13107200
    SecRequestBodyNoFilesLimit 131072
    SecRequestBodyInMemoryLimit 131072
    SecRequestBodyLimitAction Reject
    SecRule REQBODY_ERROR "!@eq 0" \
    "id:'200001', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
    SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
    "id:'200002',phase:2,t:none,log,deny,status:44,msg:'Multipart request body \
    failed strict validation: \
    PE %{REQBODY_PROCESSOR_ERROR}, \
    BQ %{MULTIPART_BOUNDARY_QUOTED}, \
    BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
    DB %{MULTIPART_DATA_BEFORE}, \
    DA %{MULTIPART_DATA_AFTER}, \
    HF %{MULTIPART_HEADER_FOLDING}, \
    LF %{MULTIPART_LF_LINE}, \
    SM %{MULTIPART_MISSING_SEMICOLON}, \
    IQ %{MULTIPART_INVALID_QUOTING}, \
    IP %{MULTIPART_INVALID_PART}, \
    IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
    FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

    SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
    "id:'200003',phase:2,t:none,log,deny,status:44,msg:'Multipart parser detected a possible unmatched boundary.'"

    SecPcreMatchLimit 1000
    SecPcreMatchLimitRecursion 1000

    SecRule TX:/^MSC_/ "!@streq 0" \
            "id:'200004',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"

    SecResponseBodyAccess Off
    SecDebugLog /var/log/httpd/modsec_debug.log
    SecDebugLogLevel 0
    SecAuditEngine RelevantOnly
    SecAuditLogRelevantStatus "^(?:5|4(?!04))"
    SecAuditLogParts ABIJDEFHZ
    SecAuditLogType Serial
    SecAuditLog /var/log/httpd/modsec_audit.log
    SecArgumentSeparator &
    SecCookieFormat 0
    SecTmpDir /var/lib/mod_security
    SecDataDir /var/lib/mod_security
</IfModule>

Referanser / Lenker / Ressurser

Owasp5023 - WAF MODSECURITY, with Ivan Ristic. (ca 45 minutter, fordelt på 6 videosnutter).

Modsecurity Reference Manual

Modsecurity Commercial and Community Support/Services

Open Web Application Security Project (OWASP)

Tagged as : sikkerhet brannmur apache centos owasp