Kolab Postfix stellt google mails nicht zu.

Wenn man postfix mit einem Kolab backend betreibt kommt vor dem Zustellen der Mails das Python-Script kolab_smtp_access_policy zum Einsatz.

Dieses prüft ob Sender- oder Empfänger-Adresse im LDAP hinterlegt ist. Das Prüfergebnis wird anschließend gecached. Und hier fängt der Ärger an. Das Script als auch das DB-Design sehen 64 Zeichen für eine E-Mail-Adresse vor. 254 Zeichen dürfen es aber sein. Google verwendet für die Verification Mail nun aber mehr als 90 Zeichen.

Um den Fehler zu beheben muss man zuerst in der kolab-Datenbank die tabelle policy_result bearbeiten. Die Spalten sender und recipient müssen auf 254 erweitert werden.

anschließend muss man das /usr/lib/postfix/kolab_smtp_access_policy bearbeiten. Dort muss man den Eintrag policy_result_table wie folgt anpassen.

kolab_smtp_access_policy exit status 1

Wer einen Kolabserver auf einem Ubuntuserver hochzieht, wird aktuell irgendwann (beim Versand oder Empfang von Mails) auf den Fehler „kolab_smtp_access_policy exit status 1“ stoßen. Alle Maßnahmen das logging aufzudrehen, greifen ins leere und man ist verzweifeln …

In diesem Fall sollte man doch einfach das script per hand aufrufen. Wichtig dabei, postfix verwendet pyhton2.7…

Mit hoher Warscheinlichkeit kann das Module pymysql nicht geladen werden. Einfach das Modul nachinstallieren und schon kann es mit dem Mail-Empfang losgehen.

kolab_smtp_access_policy debugen

Ich betreibe seit ein paar Tagen eine Kolab-Server und bin dabei über die ein oder andere Baustelle gestolpert. Am meisten probleme hat mit die kolab_smtp_access_policy bereitet.

Diese wird vom postfix aufgerufen um zu prüfen ob eine Mail angenommen werden darf. Bei kolab_smtp_access_policy handelt es sich um ein Python Script, das ohne weiteres schwer von der Console aufgerufen werden kann.

Leider logt das Script standartmäßig nichts. Um das Logging zuzuschalten muss man unter /etc/postfix/master.conf dem scritpaufruf parameter mitgeben.

Das „-l debug -d 9“ sorgt dafür, dass das Logfile /var/log/kolab/pykolab.log gefüllt wird. Jetzt kann man mit der Fehlersuche beginnen…

Änderungen bei LVM

Wer wie ich regelmäßig einen Raid 1 (Mirror) mit LVM aufbaut/betreibt, wird seit neusten (zu mindestens wenn er auf den aktuellen Ubuntu LTS setzt) in folgendes Problem laufen. Der bisher gültige Befehl führt nicht mehr zum gewünschten Ergebnis:

Das ganze liegt daran, dass sich die art wie LVM jetzt einen Raid aufbaut wohl geändert haben soll. Ich bin da nicht tiefer hinabgestiegen. Schlussendlich muss man einfach noch den Typ mit angeben, dann klappt es wieder.

ExpireDate von Zertifikat überwachen.

Wer, wie ich, eine eigene (private) CA betreibt, wird irgendwann mal überrascht feststellen, dass auch das Root-Zertifikat ausläuft. Standardmäßig nach 4 Jahren. Wenn plötzlich der Radius keine Clients mehr ins Netz lässt, wenn jede interne HTTPS-Verbindung auf Warnung läuft und man sich plötzlich wieder mit Notfall-Passwörtern anmelden muss, weiß man, dass man vergessen hat, sein Root-Zertifikat rechtzeitig zu erneuern.

Was bei einzelnen Clients noch mit vertretbaren Aufwand zu beheben ist, nervt beim Zwangs erneuern der CA doch ziemlich, besonders wenn man gerade etwas anderes vor hatte.

Für diesen Zweck hab ich mir ein kleines Script gebastelt, das via Munin alle Cert-Restlaufzeiten ermittelt und rechtzeitig Alarm schlägt.

wie immer unter GPL hier zu beziehen: Check Expire Date

OpenVPN – TLS-Server-Check bestehen

OpenVPN liefert gleich eine ganze BuildChain mit um sich Zertifikate zu generieren und zu signieren. Leider hat man meist schon eine Infrastruktur (CA) im Feld mit der man seine Zertifikate signiert und verteilt. Bei mir habe ich das immer über das in Ubuntu mitgelieferte CA.pl Skript gemacht und die so erzeugten Zertifikate funktionieren gerade nicht in OpenVPN. Es kann zwar eine Verbindung aufgebaut werden aber ein TLS-Server-Check schlägt fehl. Um gültige Zertifikate zu erzeugen muss man folgendes machen.

in der /etc/ssl(openssl.cnf muss man eine neue Sektion anlegen. Am besten mit dem Namen „Server“ oder „OpenVPNHost“

anschließend muss man das certifiacte wie folgt erzeugen:

Das so erzeugte Zertifikat besteht auch einen TLS-Server-Check

EdgeMax Router und die eigene DHCP-Server Config

Wer einen EdgeMax Router im Einsatz hat, kann über die Configschnittstelle seinen DHCP Server aufsetzten. Wer aber einen bestehenden DHCP Server migrieren will, wird blöde, alles über dieses Interface einzuhacken. Es geht auch einfacher. Die bestehende dhcpd.conf unter /config ablegen. Man kass es prinzipjell überall hinlegen, aber dort überlebt die Datei ein Firmware-Upgrade.

 

Anschließend die Datei /etc/init.d/dhcpd anpassen und von der automatisch generierten auf die /config/dhcpd.conf umbiegen. Wenn man im Configmenu den DHCP-Server abgeschaltet hat (kein Eintrag unter services) muss man nun noch den DHCP-Server beim Start mit starten lassen:

Schon hat man seinen selbst-konfigurierten DHCP Server am Start.

Zertifikatseigenschaften von FreeRadius prüfen lassen

Ich hab seit einiger Zeit einen FreeRadius-Server um mein WLAN abzusichern und mein VPN Zugang zu regeln. Das System war so konfiguriert, dass der Client ein Zertifikat vorzeigt, einen Tunnel aufbaut und dann via EAP/PAP autorisiert wird. Das Gruppenmanagement übernahm dabei LDAP und die das Passwort wurde via Kerberos geprüft. Alles in allem sehr flexibel aber auch sehr komplex. Vor allem der LDAP Server störte mich doch extrem. Zum einen ist der so ganz anders zu konfigurieren und zu verwalten, als alle anderen Dienst ein meiner Landschaft, zum anderen hab ich ihn nie so richtig verstanden. Kurz der musste weg. Ich wollte aber weiterhin die Option haben, eine Nutzer via VPN auf Subnets „Zugang“ zu lassen aber vom Heimnetz „Sicher“ fern zu halten. Insofern man den aktuellen FreeRadius einsetzt bietet dieser eine sehr elegante Möglichkeit an, dass auf Zertifikatsbasis zu lösen.

Der Grundgedanke: Insofern man der CA wirklich vertraut bzw. die CA selber stellt, kann man davon ausgehen, dass ein Client nur das Zertifikat hat, dass er haben darf. Verlust und Diebstahl wird über eine aktuelle „Revocation Liste“ gelöst. Vertraut man der CA, kann man somit die Zugangsinformationen ins Zertifikat hinterlegen. Zum Beispiel kann man das OU (OrganisationUnit) oder gar das CN Feld nutzen. In meinem Fall, hab ich mich auf das CN Feld bzw den ganzen Zertifikats-Pfad verlassen. Meine Netz ist in verschiedene Bereiche getrennt: Sicher, Gesichert, Offen (Radius entfällt). Alle Clients haben schon jetzt Zertifikate die wie folgt aussehen: hostname.sicher.ca oder bekannter.gesichert.ca. Ich musste den Radius nur noch dazu bekommen, dass ein Client der in das „Sichere“ Netz will auch ein „sicher.ca“-Zertifakt vorweißt.

Umsetzung: Was man vorher braucht, ist ein Radius der TLS beherrscht. Das wird hier beschrieben: Ubuntusers:Wiki – FreeRadius. Läuft der TLS Modus stehen nun eine Reihe von Variablen innerhalb der FreeRadius-Configuraiton zur Verfügung. Eine komplette Liste konnte ich nicht auftreiben aber laut einigen Mailinglisten sind die folgenden Variablen wohl verfügbar:

  • TLS-Cert-Serial
  • TLS-Cert-Expiration
  • TLS-Cert-Issuer
  • TLS-Cert-Subject
  • TLS-Client-Cert-Serial
  • TLS-Client-Cert-Expiration
  • TLS-Client-Cert-Issuer
  • TLS-Client-Cert-Subject

Interessant ist die TLS-Client-Cert-Subject – Variable. Diese stellt das Subject via String zur verfügung. Jetzt muss man nur noch mittels RegExp seine gewünschte Prüfung durchführen. Dass kann dann so aussehen.

Die „Huntgroup“ ist eine Eigenschaft die durch beliebige Regeln vorher gesetzt wird. In meinem Fall sieht die Regel so aus:

Was folgt ist folgende Prüfung. Wenn eine TLS-Verbindung über einen Zugangspunkt mit der IP 10.11.1.2 und NAS-ID (vorher vereinbart) „sicheres-lan“ ankommt muss das CLientZertifikat auf „*.sicher.ca“ ausgestellt sein. Alles andere wird abgeleht. Mann kann da noch weitere else-Zweige einbauen. Aber das Prinzip bleibt das gleiche.

Servergespeicherte Profile mit unison

Da CSync leider nicht meine Erwartungen erfüllt hat bzw. nicht im Ubuntu-Repository versorgt wird musste ich mich vor ein Weile nach Alternativen umschauen.

Dabei bin ich auf Unison gestoßen. Installiert man es auf Client und Server kann man via ssh sehr schnell große Datenmengen in beide Richtungen abgleichen. Man kann sogar eine Konfliktlösungsstrategie angeben, falls es sowohl auf Server als auch Clients zu Änderungen kam.
Mittels Exclude-List kann man gezielt steuern was übertragen werden soll. Sogar via Regex.

Beispielconfig:

Das ganze kann man ohne Probleme über ein Skript beim Start oder Login automatisieren:

Bleibt nur noch das Problem wie man den ssh-Daemon auf der Server-Seite dazu bekommt ohne weitere Passwortabfrage eine Verbindung zuzulassen. Da gibt es verschiedene Varianten wie z.b. das Public-Key-Verfahren (wobei der keyring automatisch aufgemacht werden muss) oder GSSAPI. Letztere ist relativ bequem einzusetzen, wenn man mal einen Kerberos eingerichtet hat. Dann muss man einfach folgende Konfiguration im SSH Daemon vornehmen.

Anschließend akzeptiert der SSH Daemon nach einem Neustart auch Kerberos Tickets anstatt ein Password abzufragen.

IPSec/L2TP VPN mit OpenWRT

Da ich mehrere Android Geräte in Benutzung habe die ich nicht „rooten“ darf und dennoch einen VPN Tunnel in mein Heimnetzwerk brauche, hatte ich das „Vergnügen“ mich mit IPSec/L2TP – Tunneln auseinander zu setzten. Android bietet native aktuell vier VPN-Varianten an: PPP, L2TP, IPSec/L2TP (PSK), IPSec/L2TP (Certificate)

PPTP fällt aus, da der Android-Client nur primitive Authentifizierungen anbietet, welche als leicht angreifbar gelten. L2TP ist nur ein Layer2-Tunnel-Protokoll um darüber wiederum ein PPP-Tunnel aufzubauen. Da L2TP selber nicht Verschlüsselt ist das ganze nur so sicher wie der PPP Tunnel. Bei welchem wieder nur primitive Authentifizierungen angeboten wird. Bleibt als letzte Alternative nur den L2TP-Tunnel via eines IPSec Tunnel zu sichern. Sowohl die PSK (PreSharedKey) als auch zertifikatsbasierte Lösung sollten hinreichend sicher sein.

Damit beginnt aber auch schon der Ärger.  IPSec-Gateways findet man nur in wenigen SOHO Geräten vorkonfiguriert (z.b. einigen Fritzboxen) und das aus gutem Grund. Das Zusammenspiel Clients, Netze, Netzanbieter und IPSec läuft nicht so reibungslos wie es sollte. Dazu gleich mehr.

OpenWRT bietet gleich mehrere IPSec und L2TP Dienste an. Ich hab mich für den StrongSwan4 – Daemon als IPSec Dienst entschieden. Da dieser auch IKEv2 anbietet, in der Hoffnung dass dies vom auf Android eingesetzten Racoon-Daemon auch mal genutzt wird.

Des weiteren komm der xl2tp-Daemon oder der standardmäßig installierte ppp-Daemon zum Einsatz.

Bevor man die Sache angeht sollte man folgendes beachten um sich viel Zeit und Ärger zu ersparen: Das fehleranfälligste an einem IPSec/L2TP-VPN ist der IPSec-Anteil. Man sollte diesen also getrennt testen. Als sinnvoll hat es sich gezeigt, den Zielrouter mal vom Netz ab zu klemmen, die Firewall abzuschalten und plain den xl2tp-Daemon im Zusammenspiel mit dem PPP-Daemon zu testen. Das ganze geht einfach von der Hand und ist robust und stressfrei.

Danach kann man den IPSec Tunnel via PSK hochziehen und im internen Netz testen. Anschließend kann man ggf noch Zertifikate zur Authorisierung nutzen. Erst wenn das alles im internen Netz klappt sollte man Versuchen von „Außen“ auf das VPN zuzugreifen. Es empfiehlt sich an dieser Stelle für die Mobilen Devices einen LogReader zu installieren. Für Android ist das die App aLogcat. Leider gibt der racoon-Daemon nur in die Logfiles aus warum er einen Tunnel wieder zu macht oder warum er erst gar keinen aufbauen will.

Wie eingangs erwähnt gibt es mehrere Stolpersteine. Es war mir z.b. nicht möglich eines meiner Geräte dazu zu bewegen, den IPSec Tunnel aufzubauen. Das lies sich aber zweifelsfrei auf das Netzsegment zurückführen. Eine SIM-Karte des gleichen Netzanbieters aus einem anderen Gerät (anderes Netzsegment) eingewechselt und schon konnte der Tunnel aufgebaut werden. Es scheint Probleme beim Zusammenspiel Racoon – open/strong-Swan zu geben wenn mehrfaches „NAT“ing zum Einsatz kommt.1

Diesen Widrigkeiten zum Trotz kann man das ganze relativ leicht auf OpenWRT oder Ubuntu wie folgt einrichten:

Man benötigt  als Pakete den PPP-Daemon, XL2TP-Daemon und StrongSwan.

Configuration – /etc/ppp/options.xl2tpd

Hinweis ich erzwinge das unsichere PAP weil der IPSec-Tunnel via Zertifikaten gesichert ist (sehr schwer zu brechen, eigene CA) und FreeRadius für alles andere Klartextpasswörter im Zugriff braucht. Das muss man ggf. an seine Anforderungen anpassen!

Configuration xl2tp – Achtung hier verwende ich keine Authentifizierung. Das überlasse ich IPSec und PPPd
/etc/xl2tpd/xl2tpd.conf

Nun zu IPSec

Anschließend sollte man sich noch vor der Dummheit der Nutzer und Clients schützen. Wenn der Racoon unter Andoid die Verbindung abbricht, versucht es der L2TP-Daemon dennoch aufzubauen. Die Verbindungsverwaltung bemerkt das zwar und beendet die Verbindung sofort, dummerweise wurden schon die Authentisierungs-Daten im Klartext gesendet. (Nein auch MS-Chap-v2 zählt als Klartext). Ein Angreifer kann so gezielt (über NAT) ein kurzes Downgrade erzwingen, die Daten abgreifen und dann selber ohne IPSec einen L2TP-Tunnel aufbauen.
Um das zu verhindern muss man IPTables dazu bringen Verbindungen für Port 1701(L2TP) nur dann anzunehmen, wenn diese über IPSec reingekommen sind. Früher war das einfach, da gab es ein ipsec-Device, heute muss man über die mangle-Table rann. Das ganze sieht dann wie folgt aus

Mittels dieser Regel lehnt der Gateway alle L2TP Pakete ab, die nicht über IPSec gesichert wurden.