Zarafa Groupware-Server
Nachdem kürzlich die Meldung durch die Presse ging, dass der Zarafa Groupware-Server unter der Affero GPLv3 als Open Source Projekt veröffentlicht wurde habe ich mich kurzerhand dazu entschieden das doch direkt mal ausprobieren zu wollen.
Für alle die mit der Marke Zarafa garnichts anfangen können will kurz erläutern was das eigentlich ist.
Zarafa ist eine Groupware welche viele vom Exchange-Server bekannte Features bietet. Dazu gehören neben den üblichen Dingen wie E-Mail (zarafa ist KEIN MTA!), Kontakten, Kalendern und Aufgaben auch Dinge wie z.B. öffentliche Ordner oder auch eine sehr gut funktionierende MAPI-Implementierung. Auch Microsoft-ActiveSync PUSH ist mit Hilfe der schon seit längerem aus dem Zarafa-Projekt heraus enstandenen und unter einer Open-Source Lizenz veröffentlichten freien Implementierung z-push schnell und (je nach Client) recht problemlos möglich!
Am Wichtigsten war für mich persönlich jedoch, dass Zafara Webaccess - wie der Name schon ahnen lässt - in seiner Funktionalität und Bedienbarkeit doch sehr stark an Outlook WebAcces aka OWA erinnert.
Man kann ja gegen Microsoft wettern soviel man will aber an OWA kam bisher keine mir bekannte Open-Source Lösung auch nur ansatzweise heran.
Mal im Ernst: Gibt es irgendeinen Menschen auf der Erde der freiwillig und dauerhaft horde einsetzen will? Zumindest mein Drang zur Perversion ist da nicht groß genug!
Nach einer "Previewinstallation" in einem CoLinux mit Debian Etch habe ich mich dann recht schnell entschieden, dass ich diese Groupware in Zukunft gerne für meine Privaten Mails, Termine und Kontakte nutzen will.
Bisher setzte ich beim Mailserver auf Postfix + Postfixadmin mit Maia Mailguard als Spam und Virus Management System und Courier als imap/pop3 Server .
Die Migration auf zarafa gestaltete sich dabei denkbar einfach.
Erstmal alle bisherigen Serverdienste beendet um während der Änderungen keine Mails in ein nach der Installation totes Postfach zu kriegen.
Dann auf der Zarafa Community Seite die Debian Etch zarafa*.debs heruntergeladen und installiert.
Einige Abfragen (mysql user/pw etc) später ist Zarafa dann auch schon vollständig installiert. Kurz noch einen ersten User mit zarafa-admin anlegen und schon kann man sich via webinterface (welches standardmäßig nach /var/www/webaccess installiert kopiert wird) einloggen.
Damit auch die Mails dort landen wo man sie haben will - in der mysql-Datenbank von zarafa und nicht in den bisherigen mailboxen auf dem Filesystem - muss Postfix noch eine neue Config verpasst werden.
Folgende Konfigurationseinträge sind zu machen:
main.cf
mydomain = reichholf.net myhostname = host alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf myorigin = /etc/mailname mydestination = $myhostname, $myhostname.local, localhost, $mydomain mynetworks = 127.0.0.0/8 mailbox_transport = zarafa: zarafa_recipient_limit = 1 inet_interfaces = all
mysql-aliases.cf
# The user name and password to log into the mysql server. user = root password = zarafa hosts = 127.0.0.1 dbname = zarafa # For Postfix 2.2 and later The SQL query template. # See mysql_table(5) for details. query = select value from objectproperty where objectid=(select objectid from objectproperty where value='%s' limit 1) and propname='loginname';
und dann noch der Mailbox Transport zarafa in der master.cf
zarafa unix - n n - 10 pipe
flags= user=vmail argv=/usr/bin/zarafa-dagent ${user}
Das war's schon!
Postfix neustarten, testmail senden - DAD GEEEEEEEEEEEEEEEEEEEEEEEEHT!
Da ich bereits eine Integration für Maia Mailguard in meiner bisherigen Postfix-Installation hatte habe ich diese auch für Zarafa übernommen - nach mittlerweile ca. 125000 trainierten Mails ist die Trefferquote meines Mailguards mittlerweile wirklich gut (~96% Total - Tendenz steigend!)
Die Installation von z-push gestaltet sich ähnlich simpel. Konfigurieren muss man mit Zarafa als Backend auf Seiten von z-push garnichts, lediglich ein Redirect muss auf dem Webserver eingerichtet werden (/Microsoft-Server-ActiveSync => $webroot/z-push/index.php). PDA anwerfen, testen - geht auch!
Das Einzige was jetzt noch zu tun war war die Erstellung diverser self-signed SSL-Certs und schon war der Groupware-Server vollständig installiert.
Gesamtdauer der Installation: ca. 2h
PS:
Da die Übergabe der Mails an Zarafa über den zarafa-dagent erfolgt kann man auch jederzeit völlig problemlos mit fetchmail arbeiten um eventuell Mails aus externen Mailaccounts zu sammeln - ich persönlich bevorzuge es jedoch meinen eigenen MX zu betreiben.
Crypto at its best
Ich wollte eigentlich zu "dem" Thema überhaupt garnicht bloggen aber ich mach es jetzt doch, da ich eine konkrete Sache einfach herrlich amüsant finde.
In einem Zusammenhang den ich hier nicht näher bennen will, gab es kürzlich eine Diskussion bezüglich der Sicherheit von Daten die alleine durch eine Verschlüsselung Verschleierung der URL geschützt werden (also keine Zugriffskontrolle).
Ich stelle dazu einfach mal folgende Aussage in den Raum:
“Die Suche nach einem beliebigen Code, wie beispielsweise Ev4M21/Z3uP7KA-5819, der Zahlen und Buchstaben enthält, viele Millionen Jahre benötigen. Die Kombination des von uns verwendeten Codes ist bedeutend komplexer als die Kombination aus PIN und TAN beim Online Banking”
Dieser "beliebige Code" stellt also den verschlüsselten verschleierten Teil der URL dar. Der eine oder andere aufmerksame Leser mag sich jetzt - wie auch ich - die Frage stellen:
"Dauert es wirklich Millionen Jahre bis eine Bruteforce-Attacke, auf einen 16-Stelligen Code mit (da wir hier eine URL verwenden) ~70 möglichen Zeichen pro Stelle, erfolgreich ist oder kann mein C64-Cluster das eventuell doch schneller schaffen?Und warum zur Hölle ist es schon halb Fünf?!"
Nun, beim ersten Hinblicken mag hier keinem irgendwas auffallen, vor Allem natürlich nicht ohne entsprechende Hintergründe.
Ich will auch garnicht näher auf den konkreten Kontext eingehen, denn dass ist nicht der Hintergrund hinter dem dieser Artikel verfasst wurde!
Nun, wie könnte denn eine bedeutend komplexere Sicherheitsmaßname als der Einsatz von PIN und TAN aussehen?
Also mir fallen da schon ein paar Dinge ein, die mehr oder weniger auf der Hand liegen:
- Riesige Schlüssel (1024 Bit, 2048 Bit)
- Anerkannte und sichere Hash und/oder Verschlüsselungsverfahren wie TripleDES, RSA, MD5 oder
SHA1und was es sonst noch schönes gibt - ...
Solche lustigen Dinge munter fröhlich kombiniert könnten durchaus in URLs resultieren die vermutlich kein Mensch dieser Welt mehr ohne einen Direktlink finden würde.
Andererseits... selbst mit Direktlink könnte einem da u.U. schwindlig werden...
So, jetzt kommt der Teil, in dem wir uns genauer ansehen, wie im oben angepriesenen "Supercode" die URLs verschleiert werden.
Da es ja viel zu viel Last auf dem System verursachen würde, wenn man sehr komplexe und damit rechenaufwändige Methoden einsetzt, hatte man sich erstmal gedacht es könnte sinnvoll sein ASCII-Chars auf Bits zu mappen.
Da heutige PCs ohnehin ständig völlig überlastet sind hat man sich dazu entschieden, dass 5 Bit und somit 32 mögliche Zeichen eigentlich völlig ausreichend sein müssen.
OK, ich gebe zu, es gibt da schon ein Problem: Wir reden von URLs, also fallen Sonderzeichen mehr oder weniger weg.
Wie auch immer, jetzt werden einfach mal willkürlich 32 Buchstaben - groß und klein ganz bunt gemischt - auf besagte 5 Bits verteilt.
Für alle die es gerne bildlich haben, sowas könnte z.B. so aussehen:
00000 = F
00001 = x
00010 = K
...
11111=a
Cool, jetzt haben wir ein tolles Mapping von Bits auf Buchstaben das keinen Sinn ergibt und die URL ist immer noch nicht sicherer wie PIN und TAN!
Also weiter auf dem Weg zur unglaublichen Verschlüsselung Verschleierung.
Jetzt müssen wir ja irgendwie was anfangen mit dem frisch geborenen Mapping, oder?
Natürlich hatte man da direkt eine geniale Idee.
Da Zahlen besonders toll sind nahm man einfach z.B. die Lieblingszahlen der 3 Chefprogrammierer (sei l eine beliebige Zahl für die gilt: 0 <= l < 10 ).
Als Ergebnis kam nach reichlicher Überlegung und Priorisierung der Zahlen nach Wichtigkeit der Personen die magische Zahl 495 heraus (diese Zahl entpsricht absichtlich nicht der aus dem Ursprungsszenario!).
Für alle die sich solch komplexe Dinge nicht so gut merken können fasse ich jetzt nochmal kurz zusammen was wir bis jetzt erarbeitet haben:
- Ein willkürliches Mapping von 32 Buchstaben (case-sensitive) auf 5 Bits
- Die Magische Zahl 495
So, nach diesen Überlegungen sind wir nun bereit den Finalen Schritt zu wagen.
Bevor es hier aber nun die mighty Weltformel gibt, gilt es noch einen Umstand zu klären!
Um die URLs zuverlässig errechnen zu können benötigt man eine Basis, und hey, was könnte dazu besser taugen als eine ohnehin in jeder Datenbank vorhandene numerische BenutzerID!
Um ein schönes bildhaftes Beispiel zu haben nehmen wir an der Benutzer hat die numerische BenuterID 12345.
Nun ist es so weit, ich darf euch präsentieren wie unglaublich unsicher PIN und TAN wohl sein müssen (da folgendes ja weitaus komplexer ist und deshalb viel noch lange nicht sicherer ist):
Zuerst berechnen wir das dezimale Endergebnis durch Multiplikation der numerischen Benutzer ID mit der mighty 495:
12345 * 495 = 6110775
Diese Zahl wandeln wir nun in eine Binärzahl um:
10111010011111000110111
Diese wiederum gliedern wir (wie sich das gehört) von hinten her in 5er Gruppen:
101 11010 01111 10001 10111
Oh mist... das sind ja garnicht alles 5er Gruppen! Alles umsonst? Nein!
Erstmal ärgern wir alle die meinen Sie hätten nen Plan und lesen einfach mal alles von rechts nach Links:
11101 10001 11110 01011 101
Was passiert nun mit den letzten Stellen?
Nun, man kann sie wegfallen lassen oder mit nullen auffüllen, das spielt aber irgendwie nicht wirklich eine Rolle, Hauptsache man macht es konsequent!
11101 10001 11110 01011 10100
Jetzt nehmen wir unser vorher selbst erstelltes Mapping und ersetzen diese Binären 5er Gruppen durch die entsprechenden Buchstaben.
Et viola - wir haben den ersten Teil der URL erfolgreich und hoch effizient verschleiert - oder so...
Na wenn das nichts ist!
PS: Wer Rechtschreib und/oder grammatische Fehler entdeckt darf diese bis auf Weiteres gerne für sich behalten, Danke!
Die Windows Power Shell (final)
könnte ein ganz interessantes Tool für Windows sein.
Mit Support für Pipes und Filter kann man damit eventuel endlich auch mal für Windows recht einfach gute Skripte für administrative Zwecke schreiben.
Für alle die Sie noch nie gesehen haben, so sieht sie aus:
Ohne sie weiter getestet zu haben fiel mir aber direkt eine Sache auf die mich schon an der Command Shell immer gestört hat:
Die maximale Breite ist erneut eingeschränkt...
Ich glaube ich werd mir das Dingens die nächsten Tage trotz dieses Mankos mal etwas genauer ansehen.
Die Links auf der Microsoft Homepage funktionieren momentan zumindest für die deutsche Version noch nicht, aber jeder der will kann sich die deutsche Version der PowerShell über einen Direktlink auf die Downloadseite bei MS herunterladen - klick.