2010 Juni | ROOT ON FIRE

30Jun/102

Icinga 1.0.2 & Web 1.0.1 veröffentlicht

Das Icinga Team hat die Icinga Version 1.0.2 und das optionale Web Frontend in der Version 1.0.1 freigegeben. In der aktuellen Version wurden nicht nur einige Fehler ausgebessert sondern auch Wert auf Performance Steigerung und Stabilität gelegt. Die Dokumentationen wurden auch aktualisiert.

Neuigkeiten:

Icinga Core:

Erweiterungen:

core: Scheduled Downtimes für Host und alle Services arbeiten nun wie gewünscht
core: Scheduling für Servicechecks mit ausgenommenen Timezones funktionieren nun wie erwartet
core: Geschwindigkeitsverbesserungen beim Einlesen der retention.dat
core: Bessere Installation unter Solaris
core: Verbesserungen beim Logging nach Syslog
core: Implementierung verschiedenster Patches von Mailinglist und Tracker
core: Fehlermeldung beim Fehlen der service_description in der Servicedefinition
core: Überarbeitetes Init-Skript, Ausgabe von Konfigurationsfehlern
cgis: Mehrere URLs bei notes und action URLs möglich im Classic UI
cgis: Anzeige von display_name in host/service-Definition im Classic UI
idoutils: Performanceverbesserungen von SQL queries und objects hash list

Fixes:

core: Fehler bei der Erzeugung von Benachrichtigungen
core: Implementierung verschiedenster Patches von Mailinglist und Tracker
idoutils: Fehlerbehebungen und massive Geschwindigkeitsverbesserungen in den IDOUtils

Icinga Web:

Neue, schnellere Cronk Liste inkl. Kategorien
Umstellung Doppelklick auf Einfachklick
Modularer Aufbau von Code und Konfiguration
Implementierung Framework für Agavi/Icinga-web Module
Verbessertes Berechtigungsmodell
Unterstützung für mehrere Icinga Instanzen im Webinterface
Verbesserte Filter auf Ajax Basis
REST/Json Schnittstelle für die IcingaApi
Implementierung des neuen, schnelleren Dashboard Cronk
Mehrsprachige Benutzeroberfläche (unvollständig)

Icinga Docs:

Aktualisierung der Schnellstart-Anleitungen
Aktualisierung der Upgrade-Anleitung von Icinga und IDOUtils
Aktualisierung der Anleitung für die Installation des Webinterfaces
Neue erweiterte Dokumentation zu den IDOUtils (Kapitel 11)
Aktualisierung der Anleitung zur Icinga Api
Aktualisierung der Objektdefinitionen
Neues Dokument zu Running icinga - "Diagnostics"

Tags: Icinga, monitoring 2 Kommentare

20Jun/102

Eigener WebProxy mit PHProxy und Lighttpd

WebProxy Server erfreuen sich immer größerer Beliebtheit, da man als User ohne Konfiguration z.B. anonym surfen (IP-Adresse wird verborgen), andere Proxy / Web Sperren umgehen und den HTTP-Verkehr verschlüsseln kann. Zusätzlich wird der URL / Browser Verlauf verschleiert, da nur die Adresse des WebProxy Server gespeichert wird. Einige WebProxy Server bietet zusätzliche Security Features wie z.B. Cookie Filtering, OS & Browser Shielding, Script Blocking, Referrer Blocking. Kostenlose öffentliche WebProxys finanzieren sich leider sehr oft durch sehr viel (zu viel) Werbung, was beim Surfen erheblich stört. Ein weiterer negativer Punkt bei öffentlichen Proxy Servern ist, dass zu bestimmten Tageszeiten eine sehr hohe Auslastung der Bandbreite zu beobachten ist und deshalb das Surfen extrem langsam ist. Zusätzlich sollte man bedenken, dass man nie genau weiß welche Daten der Betreiber des WebProxy Servers sammelt bzw. auswertet. Aus diesen Gründen habe ich beschlossen einen eigenen privaten WebProxy zu installieren und zu betreiben. Eine Rücksprache mit meinem Webspace Anbieter hat ergeben, dass es nicht erwünscht es auf deren Webspace einen Proxy wie z.B. PHProxy zu betreiben.
Deshahlb habe ich hier eine Anleitung geschrieben, wie man mit Lighttpd und PHProxy einen eigenen WebProxy installiert & konfiguriert.

I. Installation
Lighttpd kann bei den meißten Distributionen über die Paketverwaltung installiert werden. Zusätzlich werden bei Debian folgende PHP Pakete benötigt: php5-common & php5-cgi

r-o-f:/# aptitude install lighttpd lighttpd-doc php5-common php5-cgi

PHProxy kann direkt bei SourceForge heruntergeladen werden und anschließend mit z.B. unzip entpackt werden.

r-o-f:/# wget http://downloads.sourceforge.net/project/poxy/PHProxy/0.5%20beta%202/poxy-0.5b2.zip
....
r-o-f:/# unzip poxy-0.5b2.zip

II. Lighttpd Konfiguration
In der Konfigurationsdatei (etc/lighttpd/lihgttpd.conf) muss bei den Server Modulen das fastcgi Modul aktiviert werden:

server.modules = (
.....
"mod_fastcgi",
....

Am Ende der Konfig Datei muss man dann noch folgende Zeilen eintragen und anschließend den Lighttpd Server neustarten

fastcgi.server = ( ".php" => ((
"bin-path" => "/usr/bin/php5-cgi",
"socket" => "/tmp/php.socket"
)))

III. PHProxy einrichten
Die Dateien index.php, index.inc.php & style.css in das WWW-Verzeichnis kopieren, unter Debian ist das standardmäßig /var/www

Das Standardverzeichnis für Lighttpd wird mit folgender Zeile definiert:

server.document-root = "/var/www/"

IV. Letzte Schritte
In der mitgelieferten README Datei stehen einige Optionen und Variablen, die man sich aus Sicherheitsgründen anschauen sollte. Desweiteren macht es Sinn den Zugriff auf den WebProxy mittels Passwort zu schützen, wenn man nicht will dass Unbefugte darauf Zugriff haben. Wie man das macht, habe ich hier beschrieben: Lighttpd – HowTo: Passwort geschütze Verzeichnisse
Man sollte bedenken dass mal als Betreiber des Proxy verantwortlich ist, wenn illegale Sachen darüber gemacht werden.

Anschließend kann der PHProxy einfach aufgerufen werden:

Liste mit kostenlosen WebProxy Servern: http://www.root-on-fire.com/web-proxy-liste/

Tags: Proxy, Tools, www 2 Kommentare

18Jun/100

HTTPS Everywhere – automatischer SSL Aufruf

HTTPS Everywhere ist ein Plugin für Firefox, dass beim Aufruf einer Webseite automatisch überprüft ob es möglich ist, die Seite über eine SSL-Verbindung aufzurufen und wenn möglich, den User automatisch auf die verschlüsselte Verbindung umleitet. Das Plugin überprüft vorher ob der verschlüsselte Aufruf, den selben Inhalt wie die unverschlüsselte Verbindung zurückliefert. Das von der Electronic Frontier Foundation und dem Tor Project gemeinsam entwickelte Plugin befindet sich noch in Beta-Phase und unterstützt derzeit u.a. folgende Seiten:

Google.com
Wikipedia
Twitter
Facebook
The New York Times
The Washington Post
Paypal
Electronic Frontier Foundation
Tor
Ixquick

Zusätzlich kann man neben den Standardregeln eigene Regeln definieren, z.B.:

Eine ausführliche Anleitung und eine genaue Erklärung der Syntax findet man hier: HTTPS Everywhere Rulesets

Bei den "Add-ons" Einstellungen kann man definieren, welche Seiten verschlüsselt aufgerufen werden sollen:

Tags: Firefox, Security keine Kommentare

17Jun/100

Lighttpd – HowTo: Passwort geschütze Verzeichnisse

Lighttpd unterstützt verschiedene Authentifizierungsmethoden, bei diesem HowTo werde ich auf die einfachste eingehen. Dabei werden Benutzername und Passwort als Klartext gespeichert. Es ist auf alle Fälle ratsam, die Verbindung mit SSL zu verschlüsseln, da sonst das Passwort sehr einfach mitgelesen werden kann.

I. Modul aktivieren
In der Konfigdatei /etc/lighttpd/lighttpd.conf muss zunächst das Modul mod_auth aktiviert werden.

server.modules = (
"mod_access",
"mod_alias",
"mod_accesslog",
"mod_compress",
"mod_auth",
)

II. Authentifizierungs Backend und Logging definieren
Folgende Zeilen müssen am Ende der /etc/lighttpd/lighttpd.conf stehen.

auth.debug = 2
auth.backend = "plain"
auth.backend.plain.userfile = "/home/root-on-fire/pass"

Erklärung:

auth.debug = 2: Debug Level 2 loggt alle (gültige & ungültige) Login Versuche mit (/var/log/lighttpd/access.log & error.log)
auth.backend = "plain":Definiert das Authentifizierungsbackend = Plaintext
auth.backend.plain.userfile = "/home/root-on-fire/pass" :Pfad zur Passwortdatei

III. Passwort geschütztes Verzeichniss definieren
In diesem Beispiel wird die Authentifizierung für den Unterordner dokumente konfiguriert. Wenn man nichts zwischen die beiden Anführungszeichen schreibt, ist die komplette Domain bzw. Webseite mit einer Passwortabfrage geschützt.

auth.require = ( "/dokumente/" =>
(
"method" => "basic",
"realm" => "Password protected area",
"require" => "user=root-on-fire"
)
)

Mit "require" => "user=root-on-fire" wird definiert, dass sich nur der Benutzer root-on-fire einloggen darf.
"realm" => "Password protected area" wird bei der Passwortabfrage ausgegeben, siehe unten.

IV. Benutzer und Passwort definieren

Der Benutzer unter dem Lighttpd läuft (bei debian standardmäßig www-data) muss Leseberechtigung auf das Passwortfile haben:

r-o-f:# chown www-data.www-data /home/root-on-fire/pass

Die Syntax ist einfach: Benutzername:Passwort, z.B.:

root-on-fire:876543210

V. Konfiguration überprüfen