Beiträge zu “ModSecurity”

ModSecurity: Honigtöpfe mit falschen Cookies setzen

Ich bin mir zwar nicht sicher ob das was bringt aber einen Versuch ist es wert. Worum geht es?

Beim Einsatz einer Web Application Firewall (WAF) wie ModSecurity versucht man über Regeln herauszufinden ob sich ein Anwender “böse” verhält. Dabei kann es natürlich vorkommen, dass ein normaler Benutzer sich ganz normal verhält aber in das Raster einen “bösen” Anwenders passt. Ein Fehlalarm (False Positive)

Man könnte also versuchen jetzt eine Art Falle zu stellen die ein normaler Nutzer niemals “sehen” würde und die nur von “bösen” Anwendern gesehen wird. Ein böses Verhalten ist zum Beispiel das Wiederverwenden oder Manipulieren von Cookies. Wenn das passiert weiß man ganz sicher das man keinen normalen Anwender vor sich hat sondern jemanden der weiß was er tut und das ist böse.

In diesem Beitrag wird eine Möglichkeit erklärt wie man so ein Session Cookie setzen kann. Die Namen und Werte sollen den Eindruck erwecken das mit dem Cookie Administrative Zugriffe gesteuert werden. Der Autor des Eintrages ist der Meinung, dass es böse Jungs gibt die versuchen so einen Cookie zu manipulieren.

Leider bin ich mit den Beispielen in dem oben genannten Blogeintrag nicht erfolgreich gewesen. Diese etwas weniger allgemeine Version macht aber erst mal das was ich möchte. Es wird ein Cookie gesetzt:

SecRule RESPONSE_HEADERS:Set-Cookie "^(.*?)=" "id:'295',phase:3,t:none,nolog,pass,capture,setenv:honeytrap_cookie_name=admin-role, setvar:tx.fake_cookie_name_count=+1, setvar:global.fake_cookie_name_%{tx.fake_cookie_name_count}=admin-role"
Header set Set-Cookie "%{HONEYTRAP_COOKIE_NAME}e=Admin:0" env=honeytrap_cookie_name

und dieser Regel wird eine Warnung in das Logfile geschrieben wenn jemand den Cookie manipuliert hat.

SecRule REQUEST_HEADERS:Cookie "@contains admin-role" "chain,id:'296',phase:1,t:none,log,pass,msg:'HoneyTrap Alert: Fake Cookie Data Manipulation'"
    SecRule REQUEST_HEADERS:Cookie "!@contains =Admin:0"

Jetzt werde ich erst mal prüfen wie oft so was passiert und dann mache ich mir Gedanken wie man diese bösen Jungs aussperren kann.

2.11.14
Weitere Beiträge zu: ModSecurity  

Keine englischen Kommentare mehr mit modsecurity

Gestern habe ich innerhalb von 10 Stunden über 200 Spam Kommentare in meinem Blog auf Basis von Movabletype bekommen. Alle mit englischen Texten.

Jetzt ist Schluß damit. Ab sofort werden alle englischen Kommentare mit modsecurity abgewiesen.

Zuerst eine kleine Datei die gänge Wörter enthält die in den englischen Kommentar auftauchen

vi /etc/apache2/security/activated_rules/local-spamfilter.txt
your
you
Outlet
saving
You
Your
with
really

Hierbei habe ich versucht Begriffe zu wählen die in deutschen Wörtern nicht vorkommen.

Dann die Regel für modsecurity

vi modsecurity_crs_48_local_exceptions.conf
<Location "/cgi-bin/mt/mt-comments.cgi">
SecRule ARGS "@pmFromFile /etc/apache2/security/activated_rules/local-spamfilter.txt" "t:lowercase,deny,msg:'Blog spam blocked',id:'2960990',tag:'Custom Rule'"
</Location>

Und tschüss

8.2.14
Weitere Beiträge zu: ModSecurity   Movabletype  

Ein Vergleichstest von Web Application Firewalls

Ein Vergleich von verschiedenen Web Application Firewalls - unter anderem mit modsecurity. Mein Favorit schneidet ganz gut ab (wenn man sich durch die mühsame Konfiguration durchbeist)

This document contains the results of a comparative penetration test conducted by a team of security specialists at Zero Science Lab against three ‘leading’ web application firewall solutions. Our goal was to bypass security controls in place, in any way we can, circumventing whatever filters they have. This report also outlines the setup and configuration process, as well as a detailed security assessment.

201303-waf-test.png
 

27.3.13
Weitere Beiträge zu: ModSecurity  

Modsecurity: Hash Tokens gegen URL Manipulationen

In dem Buch "The Web Application Defener's Cookbook: Battling Hackers and Protecting Users" wird im "Recipe 1-2" eine Methode zum Einsatz von Hash Tokens beschrieben. Das ganze hört sich ganz nett an ist aber in dieser Form nicht ready for prime time.

Zum einen sind die Informationen im Buch und auch in den bereitgestellten Downloads nicht korrekt. Die Paramenter sind inzwischen geändert worden und somit sind die dargestellten Beispiele nicht richtig. Das man das Buch nicht mehr ändern kann verstehe ich. Warum die Downloads nicht korrigiert werden finde ich nicht angemessen.

Hier die korrekten Beispiele.

SecContentInjection On
SecStreamOutBodyInspection On
SecHashEngine On
SecHashKey rand keyOnly
SecHashParam rv_token
SecHashMethodrx "HashHref" "[a-zA-Z0-9]"
SecRule REQUEST_URI "@validateHash [a-zA-Z0-9]" "phase:2,id:1000,t:none,block,msg:'Request Validation Violation.',ctl:HashEnforcement=On"

Generell ist zu sagen das der hier vorgestellte Ansatz die URLs mittels dieses einfachen regulären Ausdrucks zu erkennen so nicht ausreichend ist. Damit das Ganze auch bei komplexeren URLs oder Eingabefeldern funktioniert muss man die Webanwendungen deutlich genauer analysieren.

So jeden Fall ist das nicht zu gebrauche und verdient den nahmen "Rezept" auf keinen Fall.

11.2.13
Weitere Beiträge zu: ModSecurity  

ModSecurity: No action id present within the rule

Beim Update auf Modsecurity 2.7.1 bekam ich bei meinen eigenen Regeln die folgende Fehlermeldung

Syntax error on line xx of /etc/apache2/security/activated_rules/modsecurity_crs_99_customrules.conf:
ModSecurity: No action id present within the rule

Wenn man den eigenen Regeln

SecRule REQUEST_FILENAME ".(?:jpe?g|gif|png|js|css|ttf)$" "phase:1,allow,nolog"

eine neue ID verpasst

SecRule REQUEST_FILENAME ".(?:jpe?g|gif|png|js|css|ttf)$" "phase:1,allow,nolog,id:'2960901',tag:'Custom Rule'"

ist Ruhe im Karton.

21.12.12
Weitere Beiträge zu: ModSecurity  

Spambotabwehr mit Modsecurity

Auf Basis dieser schönen Erklärung habe ich versucht meine bisheriges Captcha Modul abzuschalten und die Spambot Bekämpfung mittels einer Regel für Modsecurity zu implementieren. Zwar habe ich bisher mit dem Captcha Modul keine schlechten Erfahrungen gemacht aber es ist sehr rechenintensiv und auch nicht immer gut zu lesen.

Die Idee ist simple. Spambots füllen alle Felder aus die sich Ihnen in einem Kommentarformular bieten. Also führen wir ein Feld ein das wir mittels CSS Anweisungen verstecken. Normale Benutzer sehen dieses Feld nicht und füllen es auch nicht aus. Spambots "sehen" das Feld und füllen es aus. Dann müssen wir nur noch eine Regel einfügen das alle Kommentare die dieses Feld ausgefüllt haben abgewiesen werden.

Die Resultate sind ermutigend. Ungefähr 20 Kommentare in etwas über einer Woche in drei Schüben. Alle mit demselben Autorennamen. Wenn der noch öfters kommt bekommt der eine eigene Regel. Im Schnitt wurden in zehn Tagen ungefähr 6 Kommentare pro Tag abgewiesen. An einem Tag wurden als Ausreißer 140 Kommentare abgewiesen.

Also in dem Template für die Kommentare wird folgendes Elemente eingefügt. (Geht alles noch natürlich noch "schöner")

 <style type="text/css">
             div .Check456 {display:none;}
</style>

  <div class="Check456">
      <input name="Check456" type="text">
</div>

Damit wird ein neues Feld eingefügt welches aber nicht sichtbar ist. Bots sehen das Feld und füllen es aus. Jetzt die custom rule in  Modsecurity
 

SecRule ARGS:Check456 "(\S+)" "auditlog,deny,log,msg:'Denied user creation by a bot'"


Dann passiert folgendes (manuel getestet mit einem sichtbaren Feld):

--15fd2321-A--
[10/Aug/2012:22:34:53 +0200] UCVwbT5LiwwAAHWcWUQAAAAE 127.0.0.1 3622 62.75.139.12 80
--15fd2321-B--
POST /cgi-bin/mt/mt-comments.cgi HTTP/1.1
Host: www.hagen-bauer.de
......
--15fd2321-C--
static=1&entry_id=916&__lang=de&parent_id=&armor=8b5a52fcb91lkjlj668348267b92b7dd&preview=&sid=&Check456=ksjflksafasfd&author=Hagen+Bauer&email=Hagen.Bauer%40caserio.de&url=&text=ljfdljsafdaslfd&token=98pWeJoiJuLLBCWRbeEfOptc1Yb2cFG601iiPp8U&captcha_code=
--15fd2321-F--
HTTP/1.1 403 Forbidden
Content-Length: 228
Keep-Alive: timeout=7, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

--15fd2321-E--
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /cgi-bin/mt/mt-comments.cgi
on this server.</p>
</body></html>

 

26.8.12
Weitere Beiträge zu: ModSecurity   Movabletype  

Google+ kann teilweise von modsecurity blockiert werden

Veröffentlicht man auf Google+ einen Link auf eine Website so versucht Google+ die ersten Sätze und ein Thumbnail des ersten Bildes als Vorschau darzustellen. So weit so gut.

Verwendet man die Webapplikation Firewall modsecurity so wird je nach verwendetem Regelwerk dieses Bild nicht dargestellt. Im Logfile findet man etwas wie

[/assets_c/2011/08/201108-koenig-kunde-thumb-500x316-981.jpg][2] Warning. Operator GE matched 5 at TX:anomaly_score. [file ".......conf"] [line "41"] [msg "Transactional Anomaly Score (score 5): Request Missing an Accept Header"]

Kann durch eine eigene Regel natürlich freigeschaltet werden.

2.8.11
Weitere Beiträge zu: Google+   ModSecurity  

Skipfish: ein Security Scanner von Google

201009-skipfish.pngSkipfish ist ein voll automatischer Sicherheitsscanner für Web Anwendungen. Er wird von Google als OpenSource bereitgestellt. Wenn ich die diversen Reviews richtig verstehe sollte er als eins von mehreren Sicherheitswerkzeugen angesehen werden. Also keine eierlegende Wollmichsau aber auf jeden Fall sinnvoll es laufen zu lassen.

Installation ist einfach (hier auf Debian)

apt-get install libidn11-dev libssl-dev
mkdir skipfish
cd skipfish/
wget http://skipfish.googlecode.com/files/skipfish-1.64b.tgz
tar xzvf skipfish-1.64b.tgz
cd skipfish-1.64b
make

In den meisten Anleitungen steht, daß man mit der grossen Wortliste beginnt. Aber Achtung: Skipfish erzeugt richtig viel Last. Den ersten Versuch mit der grossen Wortliste habe ich auf meinem schwachbrüstigen Doppel Pentium3 Entwicklungsrechner nach 3 Tagen abgebrochen.

Ich würde auf jeden Fall erstmal mit einer leeren Wortliste starten. Da kommt schon genug Last zusammen.

touch empty-wordlist
./skipfish -u -o outputdirectory -W empty-wordlist http://your-server.addr.ess

Nach 1,5 Tagen war der Test dann durch. Man bekommt die Ergebnisse als HTML Seite.

201009-skipfish-screen.png

8.9.10
Weitere Beiträge zu: skipfish   Security   ModSecurity   Google  

ModSecurity Logs mit Jarvinen in MySQL speichern

Jarvinen stellt ein einfaches webbasierendes Monitoring Werkzeug für Modsecurity bereit. Es besteht aus 2 Teilen. Zum einen ein Shell Script welches die Logfiles durchgeht und die einzelnen Einträge in eine Mysql Datenbank schreibt. Der andere Teil ist eine PHP Web Anwendung mit der man sich die Dinge auch ansehen kann. Den Download gibt es hier

In der Datei jarvinen_python_v1.tgz gibt es vier Dateien:

  • eine SQL Datei welche die Datenbanken erstellt.
  • eine Konfigurationsdatei mit den Datenbank Parametern wie user / password
  • das eigentliche Programm in Python geschrieben das die Logfiles durchsucht
  • ein Script welches das ganze automatisiert aufruft.

Je nach Linux Distribution muss man vielleicht noch andere Komponenten installieren die bei mir schon da waren (z.b. python-mysqldb)

1. Installation des Import Scripts

Meine Installationschritte sind von hier

wget http://jarvinen.googlecode.com/files/jarvinen_python_v1.tgz
tar xzvf jarvinen_python_v1.tgz
rm jarvinen_python_v1.tgz
cd jarvinen/

Datenbank anlegen und Datenbankstrukturen importieren

# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 192033

mysql> create database msaudit;
Query OK, 1 row affected (0.02 sec)

mysql> CREATE USER 'modsecuser'@'localhost' IDENTIFIED BY 'geheim';
Query OK, 0 rows affected (0.15 sec)

mysql> GRANT ALL ON msaudit.* TO 'modsecuser'@'localhost';
Query OK, 0 rows affected (0.00 sec)

mysql>quit

#mysql -u modsecuser -pgeheim < Create_Database.sql

2. Importroutine konfigurieren

Die Datenbankinformation anpassen in der Konfigurationsdatei eingetragen werden

vi jarvinen.conf

[[Mysql]
HostName=localhost
DbName=msaudit
DbUser=modsecuser
DbPassword=geheim
Socket=/var/lib/mysql.sock
[WhiteList]
SrcIp=127.0.0.1
[Log]
LogPath=/var/log/modsec_audit.log

3. Programm ausführbar machen und starten

chmod +x jarvinen.py
./jarvinen.py -c jarvinen.conf -l mod-sec-audit-20100610.log

4. PHP Anwendung einrichten

Die Anwendung muss auf dem Server entpackt und in das WebServer verzeichniss kopieren werden.

wget http://jarvinen.googlecode.com/files/jarvinen_web_v1.2.tgz
tar xzvf jarvinen_web_v1.2.tgz

mv jarvinen1.2/ /var/www/localhost/htdocs/jarvinen
cd /var/www/localhost/htdocs/
chown apache jarvinen -R

Einchecken in mein lokales SVN (optional aber empfohlen siehe hier  )

cd /var/svn/
svnadmin create jarvinen
cd /var/www/localhost/htdocs/jarvinen/
svn co file:///var/svn/jarvinen/ .
Checked out revision 0.
mail jarvinen # svn add *
A         ParameterControl.php
[.....]
A         web.css

svn ci -m "initial checkin of jarvinen"
Adding         ParameterControl.php
[....]
Adding         web.css
Transmitting file data ................
Committed revision 1.

Wir müssen noch unsere eigenen Datenbankeinträge in dem PHP code anpassen

vi functions.php
$connectStr = array("localhost", "modsecuser","geheim","msaudit") ;

Das war es. Dann aufrufen und

201006-jarvinen_v1_1.gif201006-jarvinen_v1_2.gif

20.6.10
Weitere Beiträge zu: ModSecurity   Jarvinen  

ModSecurity: Rule execution error - PCRE limits exceeded

Seit dem updaten auf modsecurity 2.5.12 finden sich haufenweise Fehlermeldungen wie diese in meinem Logfile

Rule execution error - PCRE limits exceeded (-8): (null).

So wie ich das verstanden habe ist die Ursache hierfür ein reduzierten Default Wert seit 2.5.12 changlog

Reduced default PCRE match limits reducing impact of REDoS on poorly written regex rules.  Reported by Sogeti/ESEC R&D.

Sollte man mit den default werten nicht klarkommen kann man die so anpassen (siehe hier )

vi modsecurity_crs_10_global_config.conf

SecPcreMatchLimit 150000
SecPcreMatchLimitRecursion 150000

und dann so nach unten schrauben bis man die mit dem Ergebniss leben kann.

17.6.10
Weitere Beiträge zu: ModSecurity  

ModSecurity mit Nagios check_http kombinieren

Nagios checked ja ob mein WebServer läuft. Modsecurity verhindert durch definierbare Regeln das "unerwünschte" Anfragen auf den WebServer durchkommen. Beide Programme kennen sich nicht. Eine der Regeln die man bei ModSecurity standardmässig meistens verwendet ist "Die Anfrage muss sagen welche Dateitypen sie als Antwort erwartet". Das Nagios Plugin check_http macht das aber standardmässig nicht ;-(

Deswegen sagt Modsecurity: "Das darfst du nicht" und Nagios wirft eine Warnung.

201005-nagios-modsec-warning.gif

Bisher bin ich diesem Problem recht brutal aus dem Weg gegangen in dem ich dem User-Agent check_http relativ freie Rechte gegeben haben. Nach einem Nagios Update musste ich mir das aber wieder ansehen, da sich der User-Agent geändert hatte. (Hintergründe zu User-Agents und Broswer  findest du hier)Jetzt wollte ich das Problem "richtig" lösen. Am Ende bin ich hier auf die richtige Spur gekommen. Ich richte das Nagios Plugin einfach so ein das es diesen Anfrage einfach mitschickt. Der Parameter lautet

-k "Accept: text/html"

und in die Nagios Definition von check_http eingebaut

define command{
        command_name    check_http
        command_line    /usr/lib/nagios/plugins/check_http -H $HOSTADDRESS$ -k "Accept: text/html"
        }

Dann ist auch wieder Ruhe und die Warnung verschwindet.

201005-nagios-modsec-ok.png

29.5.10
Weitere Beiträge zu: ModSecurity   Nagios  

ModSecurity und xtcmodified

ModSecurity ist ja eine Anwendung welche auf Basis von Regeln den Zugriff auf den Apache Server einschränkt. Manchmal kommt es dann natürlich dazu das eine Regel anschlägt ohne das was passiert ist. Innerhalb von xtcModified kann das zum Beispiel auch passieren wenn man eine Produktbeschreibung erstellt.

Auf Basis dieses Beitrages bin ich auf folgende Kombination gekommen.

1. Den Admin Bereich zusätzlich einschränken und einen weiteren Adminacccout festlegen

2. Den dort definierten Namen in die ModSecurity Regeln aufnehmen.

Step 1: Password Authentifizierung auf den administrativen Bereich

cd /var/www/web1x/html/admin

vi .htaccess

     AuthUserFile /var/www/web1x/.htpasswd
     AuthGroupFile /dev/null
     AuthName shopadmin
     AuthType Basic
     require user shopadmin

cd /var/www/web1x
htpasswd2 –c htpasswd shopadmin

Jetzt muss man sich nicht nur mit dem normalen Shop Administrator anmelden sondern auch noch den obigen Namen. Wenn man paranoid ist dann nimmt man einen anderen als den User der in der Shopdatenbank steht.

Step 2: ModSecurity  anpassen

Jetzt brauchen wir wir noch den Freifahrtschein für modsecurity

vi modsecurity_crs_15_customrules.conf 

# shopadmin user darf alles
SecRule REMOTE_USER "shopadmin" allow
13.3.10
Weitere Beiträge zu: ModSecurity   xtcmodified  

MovableType: ModSecurity blockiert RSS Reader NetNewswire

Einer meiner Leser hat sich beklagt das er keinerlei Änderungen mehr in seinem RSS Reader NetNewsWire mehr bekommen würde. Es stellte Sich heraus das ModSecurity hier einen sogenannten FalsePositive (Fehlarlarm) erzeugt.

Im Log von ModSecurity findet man dann

.... 'Request Missing an Accept Header'  ...

Durch folgende Regel in der modsecurity_crs_15_customrules.conf kann man diese Regel für einen bestimmten Bereich ausschalten

<Location "/blog/atom.xml">
   SecRuleRemoveByID 960015
</Location>

2.3.10
Weitere Beiträge zu: Movabletype   ModSecurity  

Mehr Sicherheit für Apache-Webserver mit ModSecurity (für Dummies)

ModSecurity ist eine Komponente die man in einem Apache Webserver installieren kann. Die Zielsetzung ist es die reinkommenden Anfragen zu kontrollieren und zu überwachen. Es sind nämlich nicht nur nette Menchen unterwegs die einfach nur Webseiten lesen wollen - neiin. Es gibt auch die sehr unfreundlichen Menschen die nicht mit einem Browser arbeiten so wie Du und ich sondern mit Programmen die einen normalen Benutzer simulieren. Und die versuchen über diesen Weg Spam in Foren oder Gästebüchern zu hinterlassen oder noch schlimmer in einen Server einzubrechen.

201002-ModSecuriity.JPG

Das Bild sieht dann ungefähr so aus. Die Anfrage

/

kommt an und wir von modsecurity gelesen und nach definierten Regeln geprüft. Wenn keine Regel zutrifft ist es ok und geht an den Webserver. Wenn eine Regel zutrifft wird es direkt zurückgewiesen. Es kommt also auf die Regeln an. Da gibt es einige freie oder aber auch kommerzielle Regeln die die typischen Angriffsmuster prüfen. z.b. bei

 

//etc/password

möchte vielleicht jemand versuchen meine Passwortdatei zu bekommen. (stimmt  nicht ganz aber es soll das Schema erklärt werden). Dafür gibts ne Regel und modsecurity sagt: "kriegste nicht" auch wenn der Webserver dahinter es vielleicht erlauben würden.  Wie gesagt: Sehr "high level" Erklärung.

Es sind also die Regeln wichtig. Und wie bei allen Regel gibt es auch Fälle wo die Regel zutrifft obwohl garnichts schlimmes passiert ist. So prüfen einige Regeln den Inhalt. Es ist bei uns z.B. vorgekommen das wir für eine Seite einen Namen vergeben haben und weil "zu viele Bindesstriche" im Namen vorkamen konnte man die Seite nicht aufrufen.

Insgesamt ist zu sagen das eine Installation von modsecurity nichts ist was man mal so eben auf einen Server wirft und gut ist. Man sollte darauf eingestellt sein das man die Installation erst eine Weile überwachen muss. Es kann ja Fälle geben wo eine Anwendung nicht mehr funktioniert weil eine Regel fälschlicherweise anschlägt. Dann muss man regelmässig Logfiles überwachen. Man sollte auch wissen was "reguläre Ausdrücke" sind. Das ist nämlich das Verfahren mit denen die Regeln erstellt werden.

Es gibt noch tausend andere Dinge zu erklären. Ich werde meine Erfahrungen mit diesem Werkzeug und einigen Anwendungen dokumentieren und da wollte ich zumindestens mal einen kurze Einführung gegeben haben.

Vielleicht ist ja jemand neugierig geworden und möchte es mal versuchen. Es lohnt sich auf jeden Fall.

13.2.10
Weitere Beiträge zu: ModSecurity  

Dies ist ein privater Blog von Hagen Bauer- berufstätiger Vater, Ehemann, Naturliebhaber, Läufer, Zelter, technikverliebt.


Creative Commons License
This blog is licensed under a Creative Commons License