Schlagwort: Plugin

weitere selbstgehostete Dienste: Filez und Poche

prego Ein Kommentar

Vor einiger Zeit hatte ich ueber verschiedene Dienste geschrieben, die man selber hosten kann, damit die Daten nicht bei irgendwelchen Fremdanbietern liegen. In der Zwischenzeit sind bei mir zwei neue Dienste hinzugekommen: Filez und Poche.

Filezfilez-logo

Filez ist ein Webdienst, mit dem man Dateien zum Download zur Verfuegung stellen kann. Diese haben eine kryptische URL und koennen optional mit einem Passwort gesichert werden. Nach einer definierten Zeitperiode verfallen die Daten und sind nicht mehr verfuegbar. Der Dienst ist praktisch um grosse Anhaenge an Emails zu vermeiden. Ausserdem ist er auch von nicht so technisch versierten Nutzern einfach zu bedienen, da Filez komplett ueber ein Webinterface bedient wird. Der Upload von Dateien per SFTP und setzen irgendwelcher Rechte oder aehnliches entfaellt also komplett.

Ich hatte vor einiger Zeit mal aus Spass an der Freude das Projekt file delivery (code) geschrieben, aber Filez ist besser.

 

Pochepoche

Poche ist ein selbst gehosteter „Read-It-Later“ Dienst. Ich stosse im Netz immer wieder auf interessante Inhalte, sei es ein Hinweis auf Twitter, ein zufaelliger Fund beim Surfen oder ein spannender Artikel in meinem RSS-Feedreader. Oft habe ich nicht die Moeglichkeit den Artikel gleich zu lesen und dadurch vergesse ich ihn wieder. Mit einem „Read-It-Later“ Dienst kann man die Inhalte speichern um sie dann spaeter zu lesen.

Poche ist nicht vergleichbar mit grossen Vorbildern wie zum Beispiel Pocket, aber die Grundfunktionen sind schon einmal da. Durch existierende Integrationen in Firefox, Android und meinen RSS-Feedreader TinyTiny RSS kann ich Poche auch bereits sehr gut beliefern. Mir fehlen noch Funktionen wie Offline auf dem Smartphone oder Tablet lesen, im grossen und ganzen bin ich aber sehr zufrieden.

 

HowTo: Zertifikatsdatei .crt direkt mit Nagios ueberwachen

prego Schreib einen Kommentar

Bei einem OpenVPN Server besteht das Problem, das sein Zertifikat nicht aktiv von aussen ueberprueft werden kann. Um es dennoch mit Nagios zu ueberwachen muss die .crt Datei auf dem Server direkt ueberprueft und die Informationen zum Nagios Server gepusht werden.

Ich habe das mit dem Shellskript ssl-cert-check (mirror v. 3.27) von prefetch.net geloest.

Das Skript habe ich unter /usr/local/bin/ abgelegt:

cd /usr/local/bin
wget http://prefetch.net/code/ssl-cert-check

Dann gibt es ein Mini-Skript unter /root/skripte/nagios/check_openvpncert.sh, dass das ssl-cert-check Skript aufruft, und die Rueckgabe per NSCA an den Nagios Server pusht:

#!/bin/bash
send_nsca=/usr/sbin/send_nsca
send_nsca_cfg=/etc/send_nsca.cfg
nagioshost=nagios.example.org
host=$1
service=$2
plugin=/usr/local/bin/ssl-cert-check
output=$($plugin -n -x 30 -c /etc/ssl/certs/openvpn.example.org.crt)
rc=$?
echo -e "$hostt$servicet$rct$output" | $send_nsca -H $nagioshost -to 30 -c $send_nsca_cfg
exit 0

Das Mini-Skript selbst wird regelmaessig mit cron aus der /etc/cron.d/nagios-passive aufgerufen:

LANG=C
#
# Regular cron jobs for nagios passive checks
#
 
HOST=openvpn.example.org
 
*/20 *  * * *   root    /root/skripte/nagios/check_openvpncert.sh ${HOST} SSL-Cert_OpenVPN 1>> /dev/null 2>> /dev/null

Und nach der Einbindung als passive Check in Nagios wird auch das Ablaufdatum eines lokalen Zertifikats ueberprueft:

nagiosovpncert

HowTo: https beim Anmelden an WordPress Blog Backend + Schutz gegen Brutforce

prego Schreib einen Kommentar

Bei meinem Blog hatte ich vor kurzem zwei Dinge die ich Aendern wollte:

  1. Der Blog soll ueber http:// lesbar sein, aber Anmelden soll grundsaetzlich immer https:// sein, damit das Passwort nicht unverschluesselt durch das Netz schwirrt
  2. Der Login Bereich soll gegen Brutforce Attacken abgesichert sein

Anmelden an Blog Backend nur ueber https://

Viele Menschen lesen diesen Blog oder finden hier hin. Ich bin immer wieder erstaunt darueber. Die Verbindung soll grundsaetzlich unverschluesselt sein, aber das Anmelden wollte ich – egal was ich eingebe – immer auf https:// landen, damit das Passwort nicht unverschluesselt durchs Netz uebertragen wird. Dafuer habe ich im vhost der auf Port 80 lauscht die folgende Rewrite Regel hinzugefuegt:

RewriteEngine On
RewriteCond %{REQUEST_URI}  ^/wp-login.php$
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)$ https://blog.pregos.info/wp-login.php/%1? [R=302,L]

So werde ich immer auf https weitergeleitet ohne das ich darauf achten muss, das was ich eingebe. Es ist wichig mit mod_rewrite zu arbeiten und nicht nur einen Alias zu setzen, da wenn man sich aus dem Backend abmeldet man dann auch auf den Anmeldebildschirm zurueckgeleitet wird. Da haengen GET Parameter dran. Ein Alias wuerde dann nicht mehr greifen, die mod_rewrite Regel oben tut es hingegen.

Schutz gegen ungewollte (Brutforce) Anmeldeversuche am Blog Backend

Nach vielen vielen Jahren den ich diesen Blog nun schon schreibe bin ich auf das Plugin WP fail2ban gestossen. Es loggt fehlgeschlagene Loginversuche ins Backend mit, so das man diese mit fail2ban auswerten und behandeln kann. Ich habe mit ein bisschen schlechten Gewissen das Plugin installiert und mal geschaut was so passiert. Von der Anzahl der Attacken war ich echt ueberrascht. Teilweise Skriptkiddies die ueber Stunden hinweg von der gleichen IP probieren, teilweise aber auch Brutforce Attacken mit ueber 16000 Loginversuchen in ~3h.

Spannend zu sehen was mir vorher alles entgangen ist, aber so richtig gut fuehlt sich das nicht an, dass von tausenden von Hosts probiert wird und die immer erst nach drei Versuchen gesperrt werden. Deswegen ist es am einfachsten, wenn man das Backend mit einem Benutzernamen und Passwort direkt im Apache sichert. Das habe ich auf die folgende Art und Weise im vHost getan:

<Location /wp-admin/>
        AuthName "Wordpress Login"
        AuthType Basic
        AuthUserFile /var/www/pregos.info/htpasswd-blog
        Require valid-user
</Location>

Da die Angreifer einfach per POST Daten an die wp-login.php schicken habe ich die Datei selbst auch noch explizit wie folgt abgesichert:

<FilesMatch "wp-login.php">
        AuthName "Wordpress Login"
        AuthType Basic
        AuthUserFile /var/www/pregos.info/htpasswd-blog
        require valid-user
</FilesMatch>

In wieweit das Passwort ein komplexes Zufallspasswort oder ein einfacher zu merkendes ist, ist jedem selbst ueberlassen. Es hilft aber erstaunlich einfach und effizient gegen die Attacken auf meinen Blog.

Nagios/Icinga plugin to check Joomla Update status (passive check)

prego 5 Kommentare

Wenn man Software von Hand und nicht aus den Repositories installiert, muss man sich auch von Hand um die Updates kuemmern. Da ich kein Plugin gefunden habe, dass mir den Joomla Update Status ueberprueft und in Nagios anzeigt, habe ich fix eines selber geschrieben. Es muss als passive Check aufgerufen werden, da es mit einer lokalen Datei auf dem Server ueberprueft, welche Version installiert ist. Das Plugin hat bei den Updates auf 2.5.7 und 2.5.8 verlaesslich angezeigt das ein Update existiert. Extensions sind nicht mit inbegriffen!

<?php
 
/***
 * Simple and dirty php script to check if the local joomla version
 * is up to date. This script only works on the server, were Joomla
 * is installed. If Nagios is not running on the same server, you 
 * possibly need to run it via NSCA or similar systems.
 *
 * @version: 0.1
 *
 * @author: jan.toenjes@intranda.com
 *
 * @changelog: initial version
 *
 ***/
 
 
/***
 * CONFIGURATION
 *
 * localVersionFile: set the full path to the version.php file from your Joomla installation
 * remoteVersionUrl: set the link to the list.xml file from the Joomla core update server
 ***/
$localVersionFile = "/var/www/joomla/libraries/cms/version/version.php";
$remoteVersionUrl = "http://update.joomla.org/core/list.xml";
 
 
// get local Joomla Version
define('_JEXEC', 1);
require "$localVersionFile";
$jversion = new JVersion;
$localJoomlaVersion = $jversion->getShortVersion();
 
 
// get remote Joomla Version
$xml = simplexml_load_file($remoteVersionUrl);
$remoteJoomlaVersion = $xml->extension['version'];
 
 
// compare and return info
if ($localJoomlaVersion < $remoteJoomlaVersion) {
        echo "A new version is available: $remoteJoomlaVersion";
        exit (2);
}
else {
        echo "Your current Version $localJoomlaVersion is up to date";
}
 
?>