Mehr Sicherheit fuer die eigenen Daten – Zertifikate

Dieses ist der dritte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann. Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann. Der dritte Teil hier bezieht sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.

Oft probiere ich eine Software aus, erstelle mir fix eine Subdomain, richte einen vHost ein, und entweder das was ich ausprobiere ist gut und es geht in meinen digitalen Alltag ueber, oder eben nicht. Zurueck bleiben verwaiste Subdomains, deaktivierte vHosts und dann natuerlich Applikationen die ich taeglich nutze, und zu denen ich eine unverschluesselte Verbindung aufbaue, obwohl ich es selbst in der Hand habe die Verschluesselung einzustellen.

Ich habe mich an dieser Stelle bewusst gegen eine eigene CA entschieden. Das ist hinten raus sicherlich praktisch, haette meine Einstiegshuerde aber wieder zu hoch gelegt und ich bin mit frueheren Versuchen daran bisher immer an mir selbst und fehlender Kontinuitaet gescheitert. Schlichte einfache selbst signierte Zertifikate sind fuer mich immer noch am einfachsten.

Was ich jedoch gemacht habe, ist, das ich alle Zertifikate bei CAcert signieren lassen habe. Das hat fuer mich den Vorteil, dass ich ueber alle Zertifikate einen Ueberblick habe, und wenn ich will, kann ich mir auch das CAcert Rootzertifikat importieren und einfach denen vertrauen. Gemacht wie folgt:

  1. Key erzeugen:
    openssl genrsa -out example.org.key 4096
  2. CSR erzeugen:
    openssl req -new -key example.org.key -out example.org.csr

    Bei den Fragen ist nur wichtig, dass der „Common Name“ der Name der Domain oder Subdomain ist, die man sichern moechte. Ein Passwort ist nicht einzugeben.

Bei CACert dann den Inhalt der example.org.csr Datei eingeben und das Zertifikat was man angezeigt und per Email zugesendet bekommt unter example.org.crt abspeichern.

Ein einfacher Apache vHost mit SSL sieht wie folgt aus:

<VirtualHost *:443>
ServerAdmin webmaster@example.org
ServerName example.org
DocumentRoot /var/www/example.org
 
SSLEngine on
SSLCertificateFile /path/to/example.org.crt
SSLCertificateKeyFile /path/to/example.org.key
 
CustomLog /var/log/apache2/example.org-access.log combined
</VirtualHost>

Wenn man auf den Dienst nur ueber https zugreifen moechte und eine einfache Weiterleitung von  HTTP auf HTTPS einrichten moechte, kann man das zum Beispiel mit einem kleinen vHost und einer entsprechenden rewrite Regel machen:

<VirtualHost *:80>
ServerAdmin webmaster@example.org
ServerName example.org
DocumentRoot /var/www/example.org
 
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
 
CustomLog /var/log/apache2/example.org-access.log combined
</VirtualHost>

Wenn man Zugriff auf ein Nagios hat, dann ergibt es Sinn das Ablaufdatum des SSL Zertifikates mit zu Ueberwachen, damit man da nicht irgendwann in Probleme rennt. Das folgende Kommando und der folgende Check warnen einen sobald das Zertifikat nur noch 30 Tage gueltig ist.

Command Definition:

define command{
        command_name    check_ssl_certexpire
        command_line    $USER1$/check_http -H $HOSTNAME$ -p $ARG1$  -C 30
        }

Check:

define service{
        use                             my-service
        host_name                       example.org
        service_description             SSL-Cert root
        check_command                   check_ssl_certexpire!443
        }

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

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";
}
 
?>

Nagios: check Piwik Update Status

Wenn man Software nicht aus den Repositories einer Distribution, sondern von Hand installiert, muss man immer im Blick haben, ob fuer die Software nicht ein Update zur Verfuegung steht

Um sich dieses fuer Piwik zu vereinfachen habe ich dafuer ein sehr simples Nagios Plugin, check_piwik.sh, geschrieben:

#!/bin/bash
 
#####
#
# Simple Skript that checks if Piwik version from given URL is up to date
# 
# Usage: ./check_piwik.php http://example.net/piwik/ MYTOKEN
#
#####
 
## check if two parameters are given
if [ "$#" -lt "2" ]; then echo -e "ERROR: You need to give two parameter, first option is URL and second option Token . Aborting." >&2 exit 1; fi
PIWIKURL="$1"
TOKEN="$2"
 
## check if needed programs are installed
type -P curl &> /dev/null || { echo "ERROR: curl is required but seems not to be installed.  Aborting." >&2 exit 1; }
type -P sed &> /dev/null || { echo "ERROR: sed is required but seems not to be installed.  Aborting." >&2 exit 1; }
 
## get latest piwik version from piwik api
LATESTVERSION=$(curl -s http://api.piwik.org/1.0/getLatestVersion/)
 
## get piwik version from given url
LOCALURL="$PIWIKURL/index.php?module=API&method=API.getPiwikVersion&format=xml&token_auth=$TOKEN"
LOCALVERSION=$(curl -s $LOCALURL | sed -n -e 's/.*<result>\(.*\)<\/result>.*/\1/p')
 
## compare both strings
if [ "$LATESTVERSION" != "$LOCALVERSION" ]; then
  echo "A new version is available: $LOCALVERSION -> $LATESTVERSION"
  exit 2
else 
  echo "Your current version $LOCALVERSION is up to date"
fi

Es erwartet zwei Parameter, eine URL zu dem Piwik das ueberprueft werden soll, und den API Token fuer diese Installation. Dementsprechend muss in der command.cfg der Check wie folgt definiert werden:

define command {
        command_name    check_piwik
        command_line    $USER1$/check_piwik.sh $ARG1$ $ARG2$
}

Der Check selbst wird dann wie folgt in die entsprechende Konfigurationsdatei eingetragen:

define service {
        use                             my-service
        host_name                       example.net
        service_description             Piwik
        check_command                   check_piwik!http://example.net/piwik!abcdefghijklmnopqrstuvwxyz123
        }

Fertig eingerichtet bekommt man dann von seinem Nagios Auskunft ueber den Updatestatus der entsprechenden Installation:

Nagios: Check if IP is SPAM-Blacklisted

Wenn man fuer mehr als nur eine feste IP-Adresse verantwortlich ist, und sicherstellen moechte, dass diese IPs nicht wegen irgendwelcher Sachen auf irgendwelchen SPAM-Blacklists eingetragen sind, dann ist es schoen das Schweizer-Taschenmesser eines Systemadministrators „Nagios“ um entsprechende Checks zu erweitern. Ich habe hierfuer check_bl gewaehlt.
Dafuer habe ich das Plugin selbst nach /usr/lib/nagios/plugins/ gelegt und in der /etc/nagios3/commands.cfg das folgende check command definiert:

define command{
        command_name    check_bl
        command_line    $USER1$/check_bl -H $HOSTADDRESS$ -B zen.spamhaus.org bl.spamcop.net dnsbl.ahbl.org dnsbl.njabl.org dnsbl.sorbs.net virbl.dnsbl.bit.nl rbl.efnet.org phishing.rbl.msrbl.net 0spam.fusionzero.com list.dsbl.org multihop.dsbl.org unconfirmed.dsbl.org blacklist.spambag.org blackholes.brainerd.net blackholes.uceb.org spamsources.dnsbl.info map.spam-rbl.com ns1.unsubscore.com psbl.surriel.com l2.spews.dnsbl.sorbs.net bl.csma.biz sbl.csma.biz dynablock.njabl.org no-more-funn.moensted.dk  ubl.unsubscore.com dnsbl-1.uceprotect.net dnsbl-2.uceprotect.net dnsbl-3.uceprotect.net spamguard.leadmon.net opm.blitzed.org bl.spamcannibal.org rbl.schulte.org dnsbl.ahbl.org virbl.dnsbl.bit.nl combined.rbl.msrbl.net
}

Anschliessend konnte ich fuer die vorhandene Hostgroup die alle Server beinhaltet die ich pruefen moechte, den check einrichten:

define service {
        hostgroup_name                  myserver-hostgroup
        service_description             BLACKLIST
        check_command                   check_bl
        use                             intranda-service
        notification_interval           0
}

Nagios neustarten, laeuft!