News

BsidesHH - Nginx as leichtgewichtige WebApplicationFirewall

2014.12.18

Am 28.12. wird Markus Manzke einen Talk zum Thema Nginx as leichtgewichtige WebApplicationFirewall halten und die Features von Naxsi, LuaWAF und Spike vorstellen.

Aus dem Intro:

"Nginx is a fast and lightweight Webserver and Reverse-Proxy, and Nr 1 among Alexa's Top 10k - Websites.

Extendable through 3rd-Party-Modules Nginx can be used as a fast WebApplicationFirewall: Naxsi is a module that extends Nginx with classical WAF-Features, namely Rules to detect malicious behavior and classical attacks like SQLInjections, XSS, Path Traversal and Remote File Inclusion. Another approach is LuWAF, a Lua based WAF that connects the power of Nginx with the possibility to use scripting and logic. LuWAF (to be released as Open Source during BsidesHH) allows to use IPReputation, detects non-browsers and is able to prevent Layer-7-DDoS - attacks. Combined with a set of Honeypots, LuWAF might even block access from malicious IPs.

The Talk gives a short Intro into Naxsi and LuWAF, explains where and against which attacks and exploits it might help (and where and why not). I'll explain how modern WAFs could help, via Hotpatching, against Exploits like ShellShock. On a sidenote i'll show how to use Spike!, a Naxsi-Rules-Builder, and how it helps to keep WAF-Installations up-to-date with current rules. "

Zusätzlich wird es einen Hacking Naxsi Workshop geben, der das Ziel hat, Naxsi-Schwachstellen zu identifzieren und zu beseitigen.

Referenzen




8ack.de - SSL-Webserver-Scan

2014.06.10

Unter 8ack.de steht ein Service bereit, mitdem sich SSL-Server auf aktuelle OpenSSL-Sicherheitslücken überprüfen lassen. Neben Heartbleed lässt sich auch auf die aktuelle CCS-Lücke (CVE-2014-0224) testen, weitere Tests werden bereitgestellt, sofern neue Infos zu Sicherheitslücken verfügbar sind.

Ein ähnlicher Online-Test wird von der NCCGroup angeboten: ccsbug.exposed/

sslscan @ 8ack.de


sslscan @ 8ack.de




Fachgespräch: Headers, Websockets + more; Webserver- / Webapp-Sicherheit im Jahre > 2014

2014.05.26

ThemaFachgespräch: Headers, Websockets & more;
Webserver- / Webapp-Sicherheit im Jahre > 2014
Datum 17.06., 10:00 - 12:00 Uh
Ort Werftbahnstr 8
Anfahrt Google-Maps
Infoswww.mare-system.de/news/mare/1401104952/
Anmeldung roadshow@mare-system.de

wut?

Im Nachtrag zur Secure Linux Administrators Conference (SLAC, 12.- 14.05. Berlin) findet am 17.06. ein Fachgespräch zum Thema "Headers, Websockets + More; Webserver und Webapp-Sicherheit im Jahre 2014" statt, bestehend aus einem leicht gestrafften Vortrag und anschließendem Gespräch zu den Themen Web/Server/Sicherheit. Wir möchten unsere Kunden und alle DiWiSH-Mitglieder zu diesem Fachgespräch einladen; insbesondere richtet sich die Veranstaltung an Admins, RZ-Leiter und Entwickler. Aufgrund der begrenzten Anzahl der Plätze ist eine Anmeldung per Email erforderlich.

Inhalt

Mit dem Siegeszug von HTML5, CDNs und modernen Applicationserver-Technologien wie Rails, Node.js, Django/Flask, Websockets oder Java-basierten Appservern wie JBOSS und Tomcat hat sich die Webserver-Landschaft massiv verändert. Der Vortrag beleuchtet, inwieweit der Einsatz dieser Technologien die Informationsgewinnung aus Angreifersicht erleichtert, und mit welchen Maßnahmen sich die serverseitige Sicherheit erhöhen läßt. Live-Beispiele und ein fast-Live-Einbruch, der via Header-Analyse vorbereitet wurde, sollen das trockene Thema etwas anschaulicher gestalten.

Als nächsten Schwerpunkt werden Websockets erklärt, demonstriert und aufgezeigt, welche sicherheitskritischen Fragen unweigerlich aufkommen, wenn auf diese Technik gesetzt wird.

Im Zuge von HTML5 und dem weit verbreiteten Einsatz von CDNs ist der Inhalt einer Webapplikation häufig aus unterschiedlichen Quellen zusammengesetzt. In Zusammenhang mit diesen Techniken haben sich einiger Header durchgesetzt, die vornehmlich dem Userschutz dienen und Schadcode im Browser an der Ausführung hindern oder Session-Hijacking unterbinden sollen. Der Vortrag erläutert den Einsatz von CORS (Cross Object Resource Sharing) CSP (Content Security Policy) und weiterer Header, die genau für diese Zwecke als Standards definiert wurden, anhand von Livebeispielen.

Ein kurzer Abriß der momentan verfügbaren WebApplicationFirewalls im Open-Source-Umfeld gibt einen kurzen Vergleich der Features und möglicher Einsatzszenarien und ein paar Beispiele von Live-Einsätzen. So noch Zeit bleibt wird auf den momentanen Stand von SSL/TLS eingegangen.




Vortrag SLAC: Headers, Websockets + More: Webserver und Webapp-Sicherheit im Jahre 2014

2014.05.05

Vortrag auf der Secure Linux Administrators Conference / SLAC (13./14. 05., Berlin) zum Thema
Headers, Websockets & More: Webserver und Webapp-Sicherheit im Jahre 2014; die Vortragsfolien gibt es hier zum Download.

slac 2014

Mit dem Siegeszug von HTML5, CDNs und modernen Applicationserver-Technologien wie Rails, Node.js, Django/Flask, Websockets oder Java-basierten Appservern wie JBOSS und Tomcat hat sich die Webserver-Landschaft massiv verändert. Der Vortrag beleuchtet, inwieweit der Einsatz dieser Technologien die Informationsgewinnung aus Angreifersicht erleichtert, und mit welchen Maßnahmen sich die serverseitige Sicherheit erhöhen läßt. Live-Beispiele und ein fast-Live-Einbruch, der via Header-Analyse vorbereitet wurde, sollen das trockene Thema etwas anschaulicher gestalten.

Als nächsten Schwerpunkt werden Websockets erklärt, demonstriert und aufgezeigt, welche sicherheitskritischen Fragen unweigerlich aufkommen, wenn auf diese Technik gesetzt wird.

Im Zuge von HTML5 und dem weit verbreiteten Einsatz von CDNs ist der Inhalt einer Webapplikation häufig aus unterschiedlichen Quellen zusammengesetzt. In Zusammenhang mit diesen Techniken haben sich einiger Header durchgesetzt, die vornehmlich dem Userschutz dienen und Schadcode im Browser an der Ausführung hindern oder Session-Hijacking unterbinden sollen. Der Vortrag erläutert den Einsatz von CORS (Cross Object Resource Sharing) CSP (Content Security Policy) und weiterer Header, die genau für diese Zwecke als Standards definiert wurden, anhand von Livebeispielen.

Ein kurzer Abriß der momentan verfügbaren WebApplicationFirewalls im Open-Source-Umfeld gibt einen kurzen Vergleich der Features und möglicher Einsatzszenarien und ein paar Beispiele von Live-Einsätzen. So noch Zeit bleibt wird auf den momentanen Stand von SSL/TLS eingegangen.

Referenzen




Nginx überholt Apache bei den Top 1000 Websites

2014.04.29

Nginx hat den Webserver Apache im Ranking der Top 1000 Websites im April 2014 das erste Mal überholt und lag mit 38.2% knapp vor Apache mit 34.2% [1].

Insgesamt hat sich die Verbreitung von Nginx in den letzten 2 Jahren verdoppelt; seit 2010 beträgt der Zuwachs mehr als das 5fache.

Webserver-Ranking 2014
nginx-usage 2014

Webserver-Ranking 2013
nginx-usage 2013

historische Daten, alle Sites
webserver-usage

alle Daten/Grafiken mit freundlicher Genehmigung & (c) Copyright 2013,2014 W3Techs

omg!

Referenzen

  1. Usage of web servers broken down by ranking / w3techs



Nginx 1.6.0 und 1.7.0 veröffentlicht

2014.04.28

Am 24.04. wurde Nginx-1.6.0 stable veröffentlicht; dieser Zweig beinhaltet jetzt die Änderungen des 1.5.x - Branches, u.a (die komplette Liste der neuen Features befindet sich weiter unten) [2,3,4]

Des weiteren wurde der Mainline 1.5er-Branch in den 1.7er Branch umbenannt, in dem die weitere Entwicklung neuer Module und Features vorangetrieben wird; Ein Blogpost auf nginx.com erläutert die Unterschiede der beiden Branches [1]

nginx-branches

(Bild mit Genehmigung von nginx.com)

Komplette Liste der neuen Features aus dem Changelog [4]

Referenzen

  1. NGINX 1.6 and 1.7 released / nginx.com
  2. [nginx-announce] nginx-1.6.0
  3. [nginx-announce] nginx-1.7.0
  4. Changelog 1.6



CxO - taugliches XKCD zu Heartbleed

2014.04.12

xkcd zu heartbleed




kostenloser Zertifikatstausch auf allen SSL-Servern

2014.04.11

Im Zuge des Heartbleed-Bugs tauschen wir auf allen von MARE system betreuten SSL-Servern die Keys und Zertifikate; dieser Service geht auf's Haus.

Wir haben einen Heartbleed - Test eingerichtet, über den Kunden Ihre Systeme auf die Lücke testen können.

Die weiteren Auswirkung dieses Bugs sind gravierend, neben Updates und neuen Keys/Zertifikaten auf der Serverseite wird Benutzen empfohlen, alle Passwörter zu allen Webdiensten (Google, Xing, Web.de, GMX, Facebook, Hetzner, Basecamp, Github, Amazon, Yahoo .... ) umgehend zu ändern; gute Passwörter können mit den Passwortgeneratoren von KeyPass oder über unseren Online-Service makepw.com generiert werden; die lokale Version ist dabei immer zu bevorzugen.

Gut verständliche Beschreibungen vor allem der Auswirkungen des Bugs auf Unternehmen und User finden sich in den Artikeln

Bei Fragen zum Thema "Heartbleed" stehen wir Ihnen unter herzlich@mare-system.de zur Verfügung.




Heartbleeding - Test

2014.04.08

Unter www.mare-system.de/heartbleeding/ stell MARE system ein Tool bereit, mitdem Online Server auf den Heartbleed - Bug überprüft werden können.

Der Check basiert auf einem Script von Jared Stafford (jspenguin@jspenguin.org), mitdem sich Server von der Kommandozeile aus überprüfen lassen.

[ me@host :~] >  ./heartbleed.py www.mare-system.de
Connecting...
Sending Client Hello...
Waiting for Server Hello...
 ... received message: type = 22, ver = 0302, length = 66
 ... received message: type = 22, ver = 0302, length = 3495
 ... received message: type = 22, ver = 0302, length = 331
 ... received message: type = 22, ver = 0302, length = 4
Sending heartbeat request...
Unexpected EOF receiving record header - server closed connection
No heartbeat response received, server likely not vulnerable
[ me@host :~] > ./heartbleed.py www.bleeding-server.com
Connecting...
Sending Client Hello...
Waiting for Server Hello...
 ... received message: type = 22, ver = 0302, length = 66
 ... received message: type = 22, ver = 0302, length = 3548
 ... received message: type = 22, ver = 0302, length = 331
 ... received message: type = 22, ver = 0302, length = 4

Sending heartbeat request...
 ... received message: type = 24, ver = 0302, length = 16384
Received heartbeat response:
  0000: 02 40 00 D8 03 02 53 43 5B 90 9D 9B 72 0B BC 0C  .@....SC[...r...
  0010: BC 2B 92 A8 48 97 CF BD 39 04 CC 16 0A 85 03 90  .+..H...9.......
  0020: 9F 77 04 33 D4 DE 00 00 66 C0 14 C0 0A C0 22 C0  .w.3....f.....".
  0030: 21 00 39 00 38 00 88 00 87 C0 0F C0 05 00 35 00  !.9.8.........5.
  0040: 84 C0 12 C0 08 C0 1C C0 1B 00 16 00 13 C0 0D C0  ................
  0050: 03 00 0A C0 13 C0 09 C0 1F C0 1E 00 33 00 32 00  ............3.2.
  ...

WARNING: server returned more data than it should - server is vulnerable!



30 critical Java / Oracle -Cloud - Vulns published by Adam Gowdiak (Naxsi Ruleset-Update)

2014.04.03

Adam Gowdiak published 30+ critical vulns and pocs against oracle's java-cloud and weblogic-server; see SE-2013-01 Press Info (2) @ security-explorations.com

CAUTION: these rules are untested, since we dont run any weblogic-server or oracle-cloud-services and might break stuff. please test carefully before deploying

after short skimming through the exploit-codes i came up with some Naxsi-rules to possibly detect malicious access-attempts (updates have been pushed to doxi-rulesets already;

[+] new sigs:
  42000346 :: app_server.rules     :: Possible Java-Beans-Injection
  42000347 :: web_apps.rules       :: Possible Wordpress-Plugin-Backdoor detected
  42000348 :: app_server.rules     :: Possible Java.Lang - Injection (URL-Args & POST-Body)
  42000349 :: app_server.rules     :: Possible JAR-File Upload
  42000350 :: app_server.rules     :: Possible WAR - File Upload
  42000351 :: app_server.rules     :: Possible JSP - File Upload
  42000352 :: app_server.rules     :: Properties-File Access / Upload
  42000353 :: app_server.rules     :: Content-Type x-java-serialized-object
  42000354 :: app_server.rules     :: WebLogicServer wls_deployment_internal - Access
  42000355 :: app_server.rules     :: WebLogicServer wls_internal - Access



#
# sid: 42000355 | date: 2014-04-03 - 23:00 
#
# http://www.security-explorations.com/en/SE-2013-01-press2.html
#
MainRule "str:wls_internal/" "msg:WebLogicServer wls_internal - Access" "mz:URL" "s:$UWA:8" id:42000355  ;


#
# sid: 42000354 | date: 2014-04-03 - 22:59 
#
# http://www.security-explorations.com/en/SE-2013-01-press2.html
#
MainRule "str:wls_deployment_internal/" "msg:WebLogicServer wls_deployment_internal - Access" "mz:URL" "s:$UWA:8" id:42000354  ;


#
# sid: 42000353 | date: 2014-04-03 - 22:58 
#
# http://www.security-explorations.com/en/SE-2013-01-press2.html
#
MainRule "str:x-java-serialized-object" "msg:Content-Type x-java-serialized-object" "mz:$HEADERS_VAR:Content-Type " "s:$UWA:8" id:42000353  ;


#
# sid: 42000352 | date: 2014-04-03 - 22:54 
#
# http://www.security-explorations.com/en/SE-2013-01-press2.html
#
MainRule "str:.properties" "msg:Properties-File Access / Upload" "mz:URL|FILE_EXT" "s:$UWA:8" id:42000352  ;


#
# sid: 42000351 | date: 2014-04-03 - 22:51 
#
# http://www.security-explorations.com/en/SE-2013-01-press2.html
#
MainRule "str:.jsp" "msg:Possible JSP - File Upload" "mz:FILE_EXT" "s:$UWA:8" id:42000351  ;


#
# sid: 42000350 | date: 2014-04-03 - 22:41 
#
# 
#
MainRule "str:.war" "msg:Possible WAR - File Upload" "mz:FILE_EXT" "s:$UWA:8" id:42000350  ;


#
# sid: 42000349 | date: 2014-04-03 - 22:42 
#
# 
#
MainRule "str:.jar" "msg:Possible JAR-File Upload" "mz:FILE_EXT" "s:$UWA:8" id:42000349  ;


#
# sid: 42000348 | date: 2014-04-03 - 21:57 
#
# phew! http://www.security-explorations.com/en/SE-2013-01-press2.html
#
MainRule "str:java.lang." "msg:Possible Java.Lang - Injection (URL-Args & POST-Body)" "mz:BODY|ARGS" "s:$UWA:8" id:42000348  ;


#
# sid: 42000346 | date: 2014-03-20 - 19:44 
#
# http://blog.diniscruz.com/2013/12/xstream-remote-code-execution-exploit.html
# ref - sid: 42000286
#
MainRule "str:java.beans.eventhandler" "msg:Possible Java-Beans-Injection" "mz:BODY|ARGS" "s:$UWA:8" id:42000346  ;

References




Apache stellt nativen PHP-Support ein

2014.04.01

Wie die Apache-Foundation bekanntgab, wird die Version 3.0 des populären Webservers "Apache" komplett neu designed und auf das nicht-blockierende, eventbasierte Modell aufbauen, das schon Nginx schnell, performant und ressourcenschonend macht.

Als wichtigste Auswirkung dieser Änderung wird ab der kommenden Version kein nativer PHP-Support mehr möglich sein; User werden gebeten, langfristig auf Microsofts IIS zu migrieren, da dort sowohl Support, Sicherheit als auch Performance wesentlich besser seien.




Full-Disclosure is back / Re: So long and thanx for all the Bugs

2014.03.26

FD is back

Eine Woche nach der Schließung von Full-Disclosure hat Fyodor, bekannt aus Funk und Fern [4], verkündet, die Mailingliste mit einem Team Freiwilliger weiterzuführen [5,7].

Welcome back, FD

Administrivia: A Fresh Start

From: Fyodor <fyodor () nmap org>
Date: Tue, 25 Mar 2014 18:07:20 -0700

It hasn't even been a week since John quit running the Full-Disclosure list
and I already miss it!  He did a great job managing the list for almost 12
years and more than 91,500 posts.  We certainly owe him our thanks and
appreciation.

When I mailed John recently asking how I could help, he said he was through
with the list but "if you want to start a replacement, go for it."  So here
we are.  I already deal with (or ignore) many legal threats and removal
demands since I've long run the most popular Full Disclosure web archive (
http://seclists.org/fulldisclosure/), and I already run mail servers and
Mailman software for my other lists (like Nmap dev and Nmap announce).  I
love the Full Disclosure philosophy and movement, so I've started a new
list!  Here is the announcement and mailman page:

http://insecure.org/news/fulldisclosure/
http://nmap.org/mailman/listinfo/fulldisclosure

While this is a successor list in spirit, it is also a fresh start in that
the old userbase won't carry over.  Anyone who wants to continue with the
list needs to resubscribe at one of the URLs above.

If I can do this for as long as John did, and with anywhere near his skill,
I will consider it a success.  I'll recruit a team of volunteer moderators
from the active list members because this needs to be run by and for the
community!

Cheers,
Fyodor

Im Kommentar "The Death and Re-birth of the Full-Disclosure Mail List" werden einige Hintergründe der ursprünglichen Schließung genannt, u.a. wird aus einer Mail zitiert, die u.a. Anlass der Schließung gewesen sein soll. [6]

... währenddessen ...

fd first troll post

So long and Thanx for all the Bugs

Am 19.3. gab John Cartwright , Betreiber der Full Disclosure Mailingliste, das Ende der selbigen bekannt. [1]

Einen wunderbaren Nachruf hat jericho in seinem Artikel "Missing Perspective on the Closure of the Full-Disclosure Mail List" geschrieben, dem von unserer Seite nichts mehr hinzuzufügen ist; [2] der besten Kommentar zur Schließung: So long and thanx for all the Bugs

R.I.P., FD


Referenzen

  1. Administrivia: The End
  2. Missing Perspective on the Closure of the Full-Disclosure Mail List
  3. reddit:Full Disclosure mailing list closes
  4. Nmap In The Movies
  5. Full Disclosure Mailing List: A Fresh Start
  6. The Death and Re-birth of the Full-Disclosure Mail List
  7. Administrivia: A Fresh Start
  8. reddit: Full Disclosure Mailing List: A Fresh Start - Fyodor of Nmap and Seclists.org is rebooting fulldisclosure
  9. reddit-Spekulation über mögliche Gründe des FD-Schließung



Ebury/CDork - Rootkiterkennung mit check_psinfo

2014.03.19

Das Nagios-Plugin "check_psinfo" kann jetzt erkennen ob möglicherweise eine Infektion mit den Rootkits Ebury/CDork vorliegt.

Weitere Infos im Artikel: Ebury/CDork - Rootkiterkennung mit check_psinfo




Game Over! Angriffe auf Steam, Origin/EA und Leage-of-Legends - Server via NTP-Amplification-Attacks

2014.01.08

Zwischen Weihnachten und Anfang Januar kam es zu einer Reihe von DDoS-Angriffen auf die Infrastruktur von Spieleanbietern, u.a. war das Login für Steam, Origin/EA und League-of-Legends teilweise nicht mehr möglich.

Einer der MARE system - Zeitserver war aufgrund einer veralteten Version und Fehlkonfiguration Teil dieses Angriffs; eine detaillierte Analyse findet sich im Dogtown-Blog

ntp-attacks




BOFH-Excuse of the Day

2013.10.17

Due to Federal Budget problems we have been forced to cut back on the number of users able to access the system at one time.
(namely none allowed....)

BOFH - Excuse of the Day




Mozilla veröffentlicht Howto zum SSL/TLS - Server - Setup

2013.10.15

Die Mozilla-Stiftung hat einen Guide veröffentlicht, der als Empfehlung für den Serverbetrieb der Mozilla-Server dient und die Themen Cipher-Suiten, Forward Secrecy (PFS), OCSP-Stapling und Serverconfigs für Apache, Nginx, HAProxy, ELB u.a. enthält.

The goal of this document is to help operational teams with the configuration of TLS on servers.All Mozilla sites and deployment should follow the recommendations below.

The Operations Security (OpSec) team maintains this document as a reference guide to navigate the TLS landscape. It contains information on TLS protocols, known issues and vulnerabilities, configuration examples and testing tools. Changes > are reviewed and merged by the OpSec team, and broadcasted to the various Operational teams.

Link: wiki.mozilla.org/Security/Server_Side_TLS




OpenSSL Cookbook v1.1 veröffentlicht

2013.10.09

Ivan Ristic hat das OpenSSL Cookbook in Version 1.1 zum freien Download veröffentlicht[1], dass auf 56 Seiten die wichtigsten Features und Befehle vorstellt; zusätzlich findet sich das "SSL/TLS Deployment Best Practices" - Manual im Anhang.

Das Cookbook kann via Feisty Duck nach Registration frei heruntergeladen werden; zum Download via feistyduck.com

Inhaltsverzeichnis




SSLLabs veröffentlicht SSL-Browser-Test

2013.10.02

SSLLabs.com, bekannt aus Funk und Fern für den umfassenden SSL-Server Test, hat vor kurzem eine erste, experimentelle Testsuite für Browser und andere Clients veröffentlicht: SSL Client Test.

Momentan werden die folgenden Parameter untersucht:


Beispiel - Screenshot von www.ssllabs.com/ssltest/viewMyClient.html

ssllabs client test




Guide to Nginx + SSL + SPDY

2013.09.16

Umfangereiche Dokumentation zum sicheren Setup von SSL-Verschlüsselung. Die Doku enthält jede Menge Config-Snippets und beschäftigt sich, teils ausführlich, mit folgenden Themen:

Der Guide ist auf englisch erschienen und unter folgendem Link verfügbar:

MARE system: Guide to Nginx + SSL + SPDY




Nagios-Plugin check_nginx_status neu im Bitbucket-Repo

2013.09.04

Das Plugin liest die Parameter der nginx - Status-Seite aus und stellt verschiedene Tests dazu zur Verfügung, die jeweils mit -w/-c überwacht werden können. Alle unter -t auswählbaren Parameter (requests per second, active connections etc) liefern Performance-Werte.

Downloads via Bitbucket-Repo


check_nginx_status

check_nginx_status


Usage

usage: check_nginx_status -h

-----------------------------------------------------


check_nginx_status is a Nagios-Plugin 
to monitor nginx status and alerts on various values to test for

   Usage:

   check_nginx_status [-H|--HOST] [-p|--port] [-u|--url] [-a|--auth] [-s|--ssl]
                      [-t|--test] [-w|--warning] [-c|--critical]
                      [-o|--output] [-r|--resultfile]
                      [-h|--help] [-v|--version] [-d|--debug]


   Options:
          --help|-h)
            print check_nginx_status help

          --HOST|-H)
            Sets nginx host
            Default: localhost

          --port|-p)
            Sets connection-port 
            Default: 80/http, 443/https

          --ssl|-s)
            Turns on SSL
            Default: off

          --url|-u)
            Sets nginx status url path. 
            Default: /nginx_status

          --auth|-a)
            Sets nginx status BasicAuth user:password. 
            Default: off
            ***

          --test|-t)
            Sets the test(check)_value for w/c
            if used, -w/-c is mandatory
            Default: checktime
            possible Values:

                active_conns    -> active connections
                accepts_err     -> difference between accepted and 
                                   handled requests (should be 0)
                requests        -> check for requests/connection
                reading         -> actual value for reading headers
                writing         -> value for active requests
                waiting         -> actual keep-alive-connections
                checktime       -> checks if this check need more than
                                   given -w/-c milliseconds 

            --calculated checks ---------------
                rps             -> requests per seconds
                cps             -> connections per second
                dreq            -> delta requests to the previous one
                dcon            -> delta connections to the previous one

                these checks are calculated at runtime with a timeframe 
                between the latest and the current check; time is 
                extracted from the timestamp of the result_file

                to disable this option (no files ar written) use -n
                see -r - option for an alternate filepath

          --warning|-w)
            Sets a warning level for selected test(check)
            Default: off

          --critical|-c)
            Sets a critical level for selected test(check)
            Default: off

          --debug|-d)
            turn on debugging - messages (use this for manual testing, 
            never via nagios-checks; beware of the messy output
            Default: off 

          --version|-v)
            display version and exit

          --output|-o)
            output only values from selected tests in perfdata; if used w/out -t
            the check returns the value for active connections

          --resultfile|-r)
            /path/to/check_nginx.results{.csv}
            please note, beside the values from the actual check 
            (eg.g check_nginx.results) a second
            file is created, if not existent, and written on each plugin-run
            (check_nginx.results.csv), containign a historic view on all 
            extracted values
            default: /tmp/check_nginx.results{.csv}

          --noresult|-n)
            never write a results-file; CANNOT be used with calculated checks 
            -t [rps|cps|dreq|dcon] 
            default: off 

        *** ) -> please dont use this option, not implemented or not functional

    Examples:
            just get all perfdata, url is default (/nginx_status)
            ./check_nginx_status --HOST www.example.com 

            just get active connections perfdata
            ./check_nginx_status -H www.example.com -o 

            check for plugin_checktime, error > 10ms (warning) or 50ms (error) and output
            only perfdata for that values
            ./check_nginx_status -H www.example.com -u /status  -w 10 -c 50 -o

            check for active connections, alert on > 500/2000 active connections
            ./check_nginx_status -H www.example.com -u /status -t active_conn -w 500 -c 2000

            Check for accepts_errors
            ./check_nginx_status -H www.example.com -t accepts_err -w 1 -c 50

    Performancedata:

        NginxStatus.Check OK | ac=1;acc=64; han=64; req=64; err=0; rpc=1; read=0; writ=1; wait=0; ct=6ms;

            ac      -> active connections
            acc     -> totally accepted connections
            han     -> totally handled connections
            req     -> total requests
            rpc     -> requests per connection (req/han) 
            rps     -> requests per second (calculated) from last checkrun to this
            cps     -> connections per (calculated) from last checkrun to this
            dreq    -> request-delta from last checkrun to this 
            dcon    -> accepted-connection-delta from last checkrun to this 
            err     -> diff between acc - han, thus errors
            read    -> reading requests from clients
            writ    -> reading request body, processes request, or writes response to a client
            wait    -> keep-alive connections, actually it is ac - (read + writ)
            ct      -> checktime (connection time) for this check

        rpc/rps/dreq/dcon are always set to 0 if -n is used

    Nginx-Config
            be sure to have your nginx compiled with Status-Module
            (--with-http_stub_status_module), you might want to test with
            nginx -V             
            http://wiki.nginx.org/HttpStubStatusModule

        location /nginx_status {
            stub_status on;
            access_log   off;
            allow 127.0.0.1;
            deny all;
        }

    Docs & Download:

            https://bitbucket.org/maresystem/dogtown-nagios-plugins



FUMP - In TestBed with Naxsi

2013.07.08

naxsi-testbed english announcement

In Zusammenarbeit mit der Naxsi-Community stellt MARE system eine Naxsi-Testinstallation bereit, hinter der sich verschiedene, angreifbare WebApps befinden, die eine Vielzahl von Sicherheitslücken aufweisen.

Ziel dieser Testinstallation ist, Naxsi-Schwachstellen und Umgehungsstrategien herauszufinden, und die Ergebnisse in die weitere Entwicklung einfliesen zu lassen.

Link: fump.8ack.de

Naxsi ist eine NGINX-basierte WebApplicationFirewall, deren Entwicklung aktiv von MARE system unterstützt wird.




Got Hacked? Get Help! II

2013.07.02

Im Falle eines möglichen Webseiten- oder Servereinbruchs ist guter Rat teuer und schnelles Handeln absolut notwendig, um weiteren Schaden für Benutzer und das eigene Image abzuwenden, oder finanzielle Einbußen zu vermeiden.

In einem kleinen Artikel wird erklärt, wie man mögliche Hacks erkennt und welche Maßnahmen ggfs notwendig sind, wenn Webseiten gehackt oder in Server eingebrochen wurde.




Brandschutz: Nginx-Artikel im ADMIN-Magazin mit Fokus auf WebApplicationFirewall Naxsi

2013.05.15

Artikel im aktuellen ADMIN-MAGAZIN zum Thema "Nginx als Frontend-Gateway" mit Beispielen und Einsatzszenarien als Loadbalancer, Webcache und ReverseProxy.

Besonderes Augenmerk legt der Artikel auf Naxsi, eine Nginx-basierte WebApplikationFirewall. Neben einer kurzen Einführung werden Live-Reports von WAFs im Einsatz gezeigt, sowie die Doxi-Rules vorgestellt; ein speziell auf Webserver ausgelegtes Ruleset.






iptables --src 188.95.234.6 -j DROP

2013.04.04

Das ISCN SANS informiert über gerade anlaufende, weltweite SSH-Scans von obiger IP; die eigenen Netze kann man per Mail an pki@net.in.tum.de vom Scan ausschliessen lassen, die obige IPTables - Firewallregel tut ein übriges.

Snort-Regeln siehe 3.



Quellen:




Got Hacked? Get Help!

2013.03.14

Google will mit einer neuen Seite Webmastern im Falle eines Hacks helfen, die eigenen Dienste wieder sauber zu bekommen, Blacklisting zu umgehen oder schnellstmöglich aufzuheben.

In einem Blogpost erläutert das Google-Devteam näheres zu dieser Initiative, weitere Infos gibts es in einem Youtube - Video



Neben diesen recht allgemein gehaltenen Vorschlägen und Empfehlungen kann man auf folgenden Seiten Infos, die Hinweise über eine evtl. Kompromittierung der eigenen Webpräsenzen geben:




Naxsi goes OWASP - Stammtisch Hamburg

2013.03.11

Am 14.03. wird die WebApplicationFirewall Naxsi auf dem OWASP - Stammtisch in Hamburg vorgestellt und in einem kleinen Workshop am lebenden Objekt die Vor- und Nachteile aufgezeigt.

Als weiteres Schmankerl wird der Einsatz der Doxi-Rules & Tools am Livebeispiel gezeigt.




Cebit-Vortrag

2013.03.07

Am 08.03. hält Markus Manzke zusammen mit Thibault "bui" Koechlin von NBS System / Paris auf dem Open-Source-Forum der Cebit einen Vortrag zum Thema "NGINX als Frontend-Gateway". T. Koechlin wird dabei Naxsi als WebApplicationFirewall vorstellen und M.Manzke erläutern, wie NGINX in komplexeren Webapplication-Umgebungen eingesetzt werden kann.

Das vom Linux-Magazin veranstaltete Open-Source-Forum findet sich in Halle 6 / Stand F02.



Die Präsentation und durchgeführten Benchmarks werden im Anschluss hier veröffentlicht.






Fundstück der Woche: PHPShell

2013.02.18

Wenn ein Kunde in seinem Docroot eine PHPShell findet, liegt folgender Schluss nahe: <br> <strong>H4X0rZ!!!</strong>



Nach einer näheren Analyse stellte sich heraus:

Trotzdem ein Grund, die WAF-Signaturen upzudaten, um ähnliche Entwickler-Schnitzer zumindest zu entdecken; ohne HTACCESS-Schutz incl. SSL-Verschlüsselung ist der Upload einer solchen Datei ein absolutes NoGo.




DOXI: Naxsi-Rulesets als Open-Source veröffentlicht

2013.02.08

Seit 6 Monaten ist die Nginx-basierte WebApplicationFirewall Naxsi testweise auf einigen Servern im Einsatz, mit bisher sehr interessanten Resultaten.

Aufgrund der Erfahrungen mit Snort-basierten Signaturen und der jahrelangen Mitarbeit in der Emerging-Threats-Community war es ein leichtes, die wichtigsten, Webserver - basierten Signaturen in das Naxsi-Format zu überführen und ein Naxsi-basiertes Regelwerk zusammenzustellen, das fortlaufend mit aktuellen Signaturen beliefert werden kann.

Diese Rulesets stehen jetzt als Git-Repo zur Verfügung. Regelmäßige Updates werden von MARE system eingepflegt.

Zum komfortablen Management der Naxsi-Rollouts stehen die ebenfalls als Open Source veröffentlichten Doxi-Tools bereit, mit denen sich automagische Updates durchführen lassen.

Naxsi & Doxi-Tools in Action:





Nagios-Plugins als Repo auf Bitbucket verfügbar

2013.01.31

Unsere als OpenSource veröffentlichten Nagios-Plugins stehen jetzt als Online-Git-Repo auf Bitbucket zur Verfügung. Updates auf Monitoringexchange wird es nur noch textuell geben, Updates der entsprechenden Downloads-Files dort nicht mehr.




Monitoring-Vortrag auf dem Kieler Webmontag

2013.01.21

Am 21.01.2013 gibt es einen kurzen Vortrag zum Thema Webseitenmonitoring auf dem Kieler Webmontag, basierend auf der Roadshow aus dem Jahre 2011.

Den Vortrag gibt es hier als download.




HSTS-Header ist Internetstandard

2012.11.21

Die Internet Engineering Task Force (IETF) hat HTTP Strict Transport Security (HSTS) als Internetstandard [ RFC 6797 ].

Einen Überblick und Einsatzmöglichkeiten, um via HSTS-Header Webseiten abzusichern, bietet folgender Link




Wir ziehen um!

2012.10.31

Ab dem 1.11. sind wir, zusammen mit MARE multimedia, in der Werftbahnstr 8 in Kiel zu finden.









Am 8.11. laden wir unseren Kunden, Partner und Geschäftsfreunde zu einem kleinen Umtrunk in den neuen Geschäftsräumen ein.







Imperva veröffentlicht "Web Application Attack Report Ed. 3"

2012.08.09

Im aktuellen Web Application Attack Report vom Juli 2012 analysiert Imperva die Summe der täglichen Angriffe auf eine WebApplikation und kommt zu dem Ergebnis, dass bis zu 2700 Angriffe/Tag stattfinden, dass 80% der Einbrüche in Netzwerke über Webapplikationen geschehen und die häufigste Schwachstelle SQL-Injections sind. Diese Werte decken sich mit den Ergebnissen der IDS/IPS - Sensoren, die MARE system betreut (3000 Angriffe je Tag/IP, BruteForce - Scanning, um verwundbare WebApps zu finden)

Aus dem Abstract:
In our previous Web Application Attack Reports (WAAR), we described the intensity of application attacks where websites are probed about once every two minutes, or 27 times per hour. This analysis gave a snapshot of an average application under attack.
In this report, we identify how many attacks a typical application can expect annually as well as the duration. Specifically, we take a deeper look to expose the underlying distribution and gain a more comprehensive understanding of the cyber battlefield. We found that the typical application:



Der Link zum Report ist im Reading-Room zu finden.




Wie eine digitale Existenz in 30 Minuten ausgelöscht werden kann

2012.08.07

Mat Honan ist Editor beim Wired-Magazin, und sein digitales Leben wurde innerhalb von 30 Minuten von Hackern ausradiert:



In einer interessanten Artikelserie erklärt er, wie es dazu kommen konnte und wie einfach die Hacker via Social Engineering und einem Anruf bei AppleCare den Stein ins Rollen bringen konnten.



[ + mehr + ]




Alles nur geCloud

2012.08.01

Seit 2010 beobachten wir technische und auch rechtliche Probleme, die beim Einsatz von Cloud-Computing auftreten können und stellen dies jetzt in einer umfassenden Liste online:




HIGHNOON: Facebook vs Datenschützer

2011.09.05

MARE system veröffentlich eine Zusammenfassung der aktuellen und vergangenen Auseinandersetzungen deutscher Datenschützer vs Facebook mit dem Bezug “Schutz der personenbezogenen Daten”.

Aktuell fordern die Datenschutzbeauftragten der Länder Schleswig-Holsteins und Niedersachsens, die “Like” - Buttons und Firmen/Behörden-Facebookseiten bis Ende September 2011 zu entfernen.

Eine Chronologie der Ereignisse und Meldungen findet sich unter folgendem Link:






Monitoring-Roadshow am 12.05.2011

2011.04.26

MARE system und NetUSE laden ein zur MONITORING ROADSHOW für Entwickler, Admins, Entscheider und Agenturen














Monitoring-Roadshow am 14.04.2011

2011.04.04

  MARE system und NetUSE laden ein zur <br><br>



Weitere Infos: hier




Debian 6.0 Countdown

2011.02.01




neues Nagios-Plugin zum Monitoring von Web-Applikationen

2010.11.18

In der Reihe "Nagios für den Hausgebrauch" veröffentlichen wir ein Plugin zur Integration von Selenium-Tests ins Nagios-Monitoring. Damit ist eine einfache Überwachung von Webapplikationen via Selenium und Nagios möglich, incl Alarmierung und Performance-Werten.

weitere Infos und Download




Website - Malware - Check (BETA)

2010.10.05

Als neues Produkt entwickelt und testet MARE system zur Zeit einen Online-Malware-Check für Webseiten.

Intressierte können sich mit einer Email an malwarecheck@mare-system.de für diesen Service anmelden, während der Testphase bleibt dieser Service kostenfrei.

Mehr Infos




SSH-Blacklists als Snort-Rulesets und neue Blacklist verfügbar

2010.10.05

Zu den vorhandenen Snort-Signaturen aus der Blacklist von sshbl.org steht ab sofort die SSH-Blacklist der Dragonresearchgroup als Ruleset für Snort und IPTables-Script zum Download bereit. Des weiteren werden die Rulesets als oinkmaster-kompatibler rules.tgz - download bereitgestellt.

Weitere Infos und download




Updates auf der Webseite / Notfallkoffer+SIC

2010.05.31

folgende Updates gab es im Mai:

You code … we platform.