Arch Linux hat ab dem Kernel 2.6.36 die Sicherheitserweiterung TOMOYO aktiviert (Feature Request), auch Debian Squeeze hat diese Sicherheitserweiterung schon aktiviert.

Ich selbst teste aktuell die ein oder andere Sicherheitserweiterung, bisher ist mir aufgefallen das TOMOYO diejenige ist welche die schlankesten Tools im Userspace benötigt. AppArmor zieht hier viele viele Abhängigkeiten nach sich was ich nicht besonders toll finde. Bei SELinux muss man sehr viel am System anpassen, dafür kann SELinux natürlich auch am meisten.

Ich plane daher für die Zukunft auf meinen Servern wenn möglich immer TOMOYO zu verwenden, natürlich werde ich auch den ein oder anderen Artikel hierüber in mein Blog schreiben.

Oft ist man gezwungen ein unverschlüsseltes Protokoll zwischen 2 Server einzusetzen. Dies ist in einem Firmennetzwerk noch vertretbar, aber über der Internet will man sowas auf gar keinen Fall machen.

Es gibt nun mehrere Möglichkeiten wie man die benötigte Verschlüsselung zwischen 2 Servern realisieren kann:

SSH

Das war früher ein sehr gängiger weg alles mit SSH zu Tunneln und dann AutoSSH & Co zu verwenden. Heute möchte man sowas eigentlich nicht mehr verwenden, es sei den es ist der einzige weg da man z.B. keine zusätzliche Software installieren darf oder man nur eingeschränkte Rechte hat.

OpenVPN

OpenVPN ist eine vor allem im OpenSource Umfeld gerne eingesetzte VPN Software. Der Vorteil von OpenVPN ist das man nur einen TCP oder UDP Port benötigt und man sich damit in der Regel fast überall "durchmogeln" kann. Der Nachteil von OpenVPN ist das jedes IP Paket fröhlich zwischen Kernel und Userspace hin und her geschoben wird, was natürlich auf die Performance geht.

IPSec

IPSec ist schon lange ein Standard wenn es um die Verschlüsselung von IP Traffic geht, der Vorteil ist das so gut wie jedes Betriebssystem irgendwie auch IPSec kann, der Nachteil ist das IPSec ein relativ komplexes Protokoll ist.

Wie der Titel dieses Beitrages schon zeigt habe ich mich für IPSec entschieden. Auf den beiden Servern läuft Arch Linux, wenn man hier und da etwas rumschraubt läuft es aber auf jeder Linux Distribution ähnlich.

Benötigte Pakete

Es muss nur das Paket ipsec-tools installiert werden, leider hat Arch noch kein Script das beim starten automatisch die Security Policy Database initialisiert. Aus diesem Grund habe ich ein Ticket aufgemacht das einen Patch für das Paket bereitstellt. Wenn man sich ipsec-tools aus dem ABS holt kann man das Paket selbst patchen, ich gehe aber davon aus das mein Patch die nächsten Tage in die normalen Repositories aufgenommen wird.

Konfiguration

Ich gehe in meiner Konfiguration davon aus das 10.0.0.1 und 10.0.0.2 die IPs der Server sind. Bei den Konfigurationsdateien muss man natürlich immer die IP Adressen vertauschen, auf beiden Servern ist die Konfiguration aber abgesehen davon identisch.

Die Security Policy Database (SPD) vom Kernel kann mit der Datei /etc/ipsec.conf konfiguriert werden. Die SPD dient dazu dem Kernel beizubringen ob er für ein bestimmtes Ziel IPSec verwenden soll, und wenn ja wie davon die Konfiguration aussieht.

#!/usr/sbin/setkey -f
flush;
spdflush;
spdadd 10.0.0.1 10.0.0.2 any -P out ipsec
        esp/transport//require;
spdadd 10.0.0.2 10.0.0.1 any -P in ipsec
        esp/transport//require;

In diesem Beispiel verwende ich zwischen beiden Servern nur eine Verschlüsselung im Transport Mode, ein vollständiger Tunnel wäre mir hier zu viel Overhead. Gleichzeitig gehen in diesem Beispiel alle IP Daten durch IPSec, d.h. auch ICMP Pakete.

Der nächste Schritt ist es racoon zu konfigurieren, racoon ist der IKE (Internet Key Exchange) Daemon welcher für IPSec nicht zwingend erforderlich ist, doch die ganze Sache ordentlich sicherer macht. Wie man IPSec ohne IKE verwendet werde ich hier nicht erklären, u.a. weil ich nicht viel von sowas halte ;-)

Racoon wird über die Datei /etc/racoon.conf konfiguriert, in welcher Beispielsweise folgender Inhalt sein könnte:

# PSK Path
path pre_shared_key "/etc/ipsec-psk.txt";

remote 10.0.0.2 {
 exchange_mode main;
 proposal {
  encryption_algorithm aes;
  hash_algorithm sha1;
  authentication_method pre_shared_key;
  dh_group modp2048;
 }
}

sainfo address 10.0.0.2 any address 10.0.0.1 any {
 pfs_group modp2048;
 lifetime time 6 hour;
 encryption_algorithm aes;
 authentication_algorithm hmac_sha1;
 compression_algorithm deflate;
}

sainfo address 10.0.0.1 any address 10.0.0.2 any {
 pfs_group modp2048;
 lifetime time 6 hour;
 encryption_algorithm aes;
 authentication_algorithm hmac_sha1;
 compression_algorithm deflate;
}

Kleiner Hinweis noch: Bei remote muss dahinter die IP Adresse vom jeweils anderen Server stehen.

Nun muss man sich nur noch ein Password für die Verschlüsselung ausdenken und dies in die Datei /etc/ipsec-psk.txt schreiben:

10.0.0.2 strenggeheim

Auch hier muss wieder die IP zum jeweils anderen System passen, damit racoon diese Datei akzeptiert muss die Datei dem Benutzer root gehören und darf keine Rechte für andere Benutzer haben:

chown root:root /etc/ipsec-psk.txt
chmod 0600 /etc/ipsec-psk.txt

Start

Hat man dies alles gemacht kann man nun IPSec starten:

/etc/rc.d/racoon start
/etc/rc.d/ipsec start

Ab jetzt wird zwischen den beiden Servern IPSec zur Verschlüsselung verwendet. Wenn alles funktioniert kann man dies natürlich in den Autostart der /etc/rc.conf packen, so dass bei jedem Sytemstart automatisch IPSec aktiviert wird.

Bitte beachtet das dies nur eine mögliche Konfiguration ist, für wirklich wichtige Daten will man statt eines PSK lieber X.509 Zertifikate einsetzen. Auch gehe ich in den Beispiel davon aus das mein Patch wirklich akzeptiert wird.

Aktuell spiele ich mit dem Gedanken aus meinen beiden Hetzner vServern einen HA Cluster zu bauen. Da diese beiden Systeme aktuell nicht für was wichtiges genutzt werden möchte ich dies mit ArchLinux machen, womit meine Pakete immer schön aktuell wären.

Doch dazu später, erstmal muss Arch ja auf den vServer. Hierzu gibt es verschiedene Möglichkeiten, die einfachste wie ich finde ist diese hier, den der vServer von Hetzner bietet eine VNC Konsole womit jedes andere gebastel einfach zu Aufwendig bzw. Zeitintensiv wäre.

Auf gehts...

Man startet das Rescue System (Backup hat man hoffentlich schon vorher gemacht) und partitioniert die Platte wie man möchte, wichtig ist das man eine Partition mehr hat als man später braucht, oder das man eine Partition erstmal frei lässt. Diese dient nur als Datenhalte für das ISO Image der Arch Installations CD, für mehr wird diese nicht gebraucht!

Es ist sinnvoll wenn man sich seine IP Konfiguration wo aufgeschrieben hat, sollte man dies vergessen haben kann man mit dem Paket ipcalc auch die Konfiguration bekommen:

ipcalc ipvomvserver/27

Der Wert hinter HostMin ist das Gateway und für was Broadcast steht kann sich hoffentlich jeder denken ;-)

Alternativ kann man natürlich auch einfach DHCP verwenden, ich selbst vermeide aber unnötige Dienste wann immer es möglich ist.

Bootloader und Installationsimage...

Nun muss nur noch das Installationsimage auf die freie Partition geladen werden:

wget -O /dev/sda3 http://ftp.uni-kl.de/pub/linux/archlinux/iso/2010.05/archlinux-2010.05-netinstall-x86_64.iso

Dabei ist es natürlich wichtig das man sowohl die URL vom Mirror als auch den Pfad zu Partition anpasst.

Ist dies erledigt fehlt eigentlich nur noch der Bootloader, dieser wird hier im Beispiel auf die Partition /dev/sda1 installiert, beachtet das ich hier auch gleich die Partition mit einem Dateisystem versehe und das mein ISO Image auf sda3 geladen wurde:

mke2fs -L Boot -m 0 /dev/sda1
mount /dev/sda1 /boot
grub-install /dev/sda
cat > /boot/grub/menu.lst << EOF
title Arch Installation
root (hd0,2)
kernel /vmlinuz26 archisolabel=ARCH_201005
initrd /archiso.img
EOF
mkdir /mnt/arch
mount /dev/sda3 /mnt/arch
cp /mnt/arch/boot/vmlinuz26 /boot/
cp /mnt/arch/boot/archiso.img /boot/
umount /mnt/arch
umount /boot

Jetzt ist eigentlich alles fertig und man kann mit reboot in das Installationssystem starten. Spätestens ab hier ist man auf die VNC Konsole von Hetzner angewiesen da die normale Arch Linux Installation keinen SSH Server startet.

Auf die Installation an sich gehe ich nicht ein, den ab jetzt ist es eine ganz normale Arch Linux Installation.

Tja, so schnell kann es gehen. Ich habe ja am Freitag meinen Strato vServer zu kündigen, und mich dann entschieden einen vServer bei Loomes zu mieten.

Leider hat meiner Meinung nach die Produktbeschreibung mehr Versprochen als am Ende dabei rauskam, deshalb wurde nun auch der vServer bei Loomes wieder gekündigt. Hauptsächlich habe ich vom neuen vServer erwartet das ich einen eigenen Kernel installieren kann, so das ich AppArmor, IPSec oder auch TOMOYO verwenden kann. Deswegen habe ich extra vServer auf Basis von Xen oder KVM gesucht, da man dort ja dank Hardwarevirtualisierung dazu in der Lage sein sollte.

In der Werbung von Loomes waren Sachen zu lesen wie "Eigener Kernel", was für mich bedeutet das ich einen selbst gebauten Kernel verwenden kann, und nicht nur das meine VM einen Kernel hat der mit dem Host-Kernel nichts zu tun hat.

Seit heute morgen gibt es auch bei Hetzner vServer auf Basis von KVM. Diese haben für mich einige Vorteile:

Hardwarevirtualisierung

Endlich mein eigener Kernel oder auch ein verschlüsseltes Root Dateisystem.

VNC

Hetzner bietet einem über das Admin Panel einen VNC Zugang zum vServer an. Dies macht es möglich ein System auch dann noch zu flicken wenn man normalerweise eine Lara benötigen würde.

Traffic

Hetzner bietet wie bei den großen Servern auch bei den vServer eine Traffic Flatrate. Bei dem von mir bestellen Server wird nach 2TB die Netzwerkanbindung auf 10MBit gedrosselt.

Preislich gesehen ist das Angebot gut aufgestellt, nicht das billigste aber bei weitem noch nicht das teuerste!

Ich habe mir gleich 2 Stück davon gegönnt (Modell VQ12) und werde damit wohl einen HA-Cluster bauen, nicht weil ich es wirklich bräuchte, sondern allein deswegen weil es möglich ist ;-)

Ich habe mich heute dazu überwunden auch meinen letzten vServer bei der Firma Strato zu kündigen.

Dies habe ich primär deswegen getan weil ich mit der eingesetzten Technik OpenVZ nicht länger arbeiten möchte. Da ich gerne diverse Sicherheitsextensions vom Kernel (TOMOYO, AppArmor) verwende ist dies für mich sehr hinderlich. Auch werden neue Kernel die kritische Updates enthalten nur mit großer Verzögerung eingespielt.

Meinen neuen vServer habe ich bei Loomes angemietet, dieser dient erstmal aber nur als Spielwiese. Meine ganzen Produktiven Sachen liegen eh schon lange bei Hetzner.

Self signed SSL Zertifikate

Viele von uns kennen diese nervigen Meldungen die man bekommt wenn man auf eine Seite geht die sog. Self signed SSL Zertifikate verwendet.

Doch leider wissen die meisten nicht warum man gerade diese eben nicht verwenden sollte! Das möchte ich in diesem Artikel mal etwas erklären, so das man sich in Zukunft darüber etwas mehr Gedanken machen. Ich lege dabei keinen Wert darauf das ich alles bis ins letzte Detail erkläre, dafür gibt es mehr als genug andere Ressourcen im Internet.

CA - Certificate Authority

Das ist die Basis, jedes SSL Zertifikat wird von einer sog. CA unterschrieben. Mit der Unterschrift wird nicht bestätigt das es sich dabei um ein sicheres, gutes oder vertrauenswürdiges Angebot handelt. Es wird nur (mehr oder weniger brauchbar) geprüft ob eine bestimmte Domain einem bestimmten Eigentümer gehört. So soll verhindert werden das ich mir ein Zertifikat für ubuntuusers.de erstellen kann, um damit Unfug zu treiben.

Die CA prüft also nur ob der Eigentümer berechtigt ist für diese Domain ein Zertifikat zu bekomme. In der Regel werden hierzu Mails an den Admin Benutzer von einer Domain gesendet oder der WHOIS überprüft. Wie genau die geprüft wird hängt von der jeweiligen CA ab, jedoch haben die meisten Browser bestimmte Mindestanforderungen an eine CA.

Die sog. Root-Zertifikate (also Hauptzertifikate) dieser CAs sind in dem meisten Browsern bereits vorinstalliert. Das heißt der Anbieter vom Browser (z.b. Microsoft, Mozilla, Apple, ...) traut einem Anbieter soweit das er in der Lage ist zu prüfen wem die Domain gehört. Auch das hat nichts mit dem Angebot an sich zu tun, sondern nur mit der Domain!

Somit legt also der Anbieter von deinem Browser fest welche Seite du ohne Fehlermeldung ansehen kannst, und welche nicht.

Zertifikat

Jeder Server benötigt ein Zertifikat um mit SSL Arbeiten zu können. In diesem Zertifikat stehen viele Informationen drin, wie z.b. wie lange es gültig ist und für welche Domain es genutzt werden kann.

Ein solches Zertifikat wird in der Regel von der CA unterschrieben, somit kann der Browser (oder auch der Mail Client) prüfen ob ein bestimmtes Zertifikat auch wirklich von einer Vertrauenswürdigen CA kommt.

Autogrammstunde

Dieses Zertifikat können auf 3 verschiedene Arten unterschrieben werden:

• Von einer CA die viele Browser kennen
• Von einer CA die man selbst erstellt hat oder die frei ist (z.B. CACert)
• Von einem selbst

Unterschrift durch eine CA die der Browser kennt

Dies ist eine gängige Variante für viele Firmeninternetseiten. Der Vorteil ist das jeder gängige Browser ohne Fehlermeldung einen Zugang zu der Seite ermöglicht. Der Nachteil ist das dies je nach Anbieter sehr viel Geld kostet. Gerade für kleine Projekte ist daher ein kommerzielles SSL Zertifikat einfach zu teuer.

Auch ist diese Variante ab und an etwas unflexibel, z.B. wenn man Zertifikate für den internen Firmengebrauch (Intranet) benötigt. Je nachdem für welche kommerzielle CA man sich entschieden hat, gibt es mehr oder weniger Nachteile.

Unterschrift durch eine CA die nicht der Browser kennt

Dies ist eine Variante die ich auch sehr gerne verwendet wird. Der Vorteil ist dabei, das keine Kosten entstehen und man nicht einen Anbieter fördert der ggf. eh nur Unsinn mit dem vielen Geld macht.

Der Nachteil ist das ein Browser natürlich die eigene CA oder die CA von z.B. CACert nicht im Zertifikatsmanager hat. Dadurch bekommt man auch diese nervigen Fehlermeldungen. Allerdings hat man einen großen Vorteil: Man muss nur ein Root-Cert in die Browser importieren und schon kann man alle Dienste dieser CA verwenden. Z.b. kann sich eine Firma eine eigene CA bauen die für die Mitarbeiterdienste verwendet wird. Die Mitarbeiter können dieses Root-Cert importieren und somit alle Dienste ohne Fehlermeldungen sicher verwenden.

Auch wird dieses Verfahren gerne bei OpenVPN verwendet. Dort traut dann OpenVPN allen Zertifikaten die von dieser CA unterschrieben worden sind. So spart man sich viel Arbeit mit Pre-Shared-Keys usw...

Unterschrift von einem selbst

Dies ist die einfachste, aber schlechteste Möglichkeit. Den jeder Benutzer bekommt mindestens beim ersten Aufruf des Dienstes eine nervige Fehlermeldung das etwas mit der Verschlüsselung nicht stimmt.

Viele Leute haben hier die Faustregel "Das Spiel muss weitergehen!", und sorgen dafür das der Browser mit dem Jammern aufhört. D.h. der Benutzer importiert das Zertifikat in seinen Browser und stuft es als Vertrauenswürdig ein.

Hierbei gibt es aber ein ganz wichtiges Problem: Woher weiß der Benutzer das dieses Zertifikat wirklich von dem Server kommt auf den er gerade zugreift? Es gibt nämlich mehr als genug Hackertools die ein Zertifikat sehr gut fälschen können.

Der Benutzer bestätigt somit also ein Zertifikat als Vertrauenswürdig das es überhaupt nicht ist. So kommt der böse Hacker aus dem McDonals z.B. ganz leicht an dein PayPal Passwort oder deinen eBay Account.

Das Problem ist nämlich nicht das Zertifikat an sich, sondern das ein durchschnittlicher User einfach nicht in der Lage ist ein Zertifikat zu prüfen. Den folgende Daten sollten bei einem Zertifikat passen und müssen vom Anwender überprüft werden wenn es nicht von einer bekannten CA kommt:

• Fingerabdruck vom Zertifikat
• Name / Domain vom Zertifikat
• Ablaufdatum des Zertifikates
• Fingerabdruck der CA
• Name / Aussteller der CA
• Ist das Zertifikat auf einer Widerrufsliste der CA

Ich denke die meisten Anwender werden keine dieser Daten aus dem Kopf kennen, daher sollte man davon abraten vertrauliche Daten wie Passwort, Adressen, Bankverbindung über eine solche Verbindung anzugeben. Auch sollte man ein selbst signiertes Zertifikat nie ohne guten Grund dauerhaft in den Browser importieren.

Fazit

Mit wenigen Schritten kommt ein Hacker auch bei einer verschlüsselten Verbindung an deine Daten, wenn man einfach mal ohne sich groß Gedanken zu machen eine Fehlermeldung vom Browser weg klickt. Es ist daher ratsam zumindest eine CA wie z.b. CAcert zu verwenden so das der Endanwender sich relativ leicht gegen solche Angriffe absichern kann. Wünschenswert für die Anwender wäre es natürlich das CAcert direkt in den großen Browsern vertreten wäre, doch daran wird natürlich schon gearbeitet!

Gleichzeitig hat eine verschlüsselte Verbindung überhaupt nichts mit der Vertrauenswürdigkeit der Anbieter zu tun, auch wenn immer wieder mit 128 Bit SSL Verschlüsselung geworben wird. Dies ist ein reines Sicherungsmerkmal für die Datenübertragung, was der Anbieter mit den Daten macht ist wieder was komplett anderes und würde den Rahmen dieses Artikels sprengen.

Dirk hat ja auch schon darauf verlinkt, dass es ein Ranking der OpenSource Blogs gibt.

Bei mir hat es (bis jetzt!!!) nur für Platz 53 gereicht, was für mich ein Indikator ist das ich da noch einiges dran arbeiten muss. Vermutlich liegt das aber einfach nur daran, dass ich vergesse, viele Sachen die ich täglich mache zu bloggen :-/

Auf der anderen Seite wäre natürlich auch interessant zu Wissen was ihr hier eigentlich lesen wollt!