roothausen

  • Impressum
  • Administration
  • Kontaktformular
  • Jabber
  • Tagcloud
  • Twitter
  • Soup
  • Github

Entries tagged as security

Entries tagged as security

Related tags

bad world blog blogging browser captcha changes computer dns firefox fun google hardware html life lighttpd linux&unix media misc murphy networking opensource politics privacy programming s9y server software spam stuff tail -f /var/log/life tv video web webdesign webwide zeitgeist code contentmanagement free markup rss ruby tool wordpress javascript linux shortys android apple cheatsheet comic css datamining documentation eigenfaces encryption feedreader gui howto http im ios iphone jabber java mail mobile newsbeuter picture podcast presentation psi rant realtime regular expression rest scala screenshot sdk subnetting swing test truecrypt unix websockets windows xml xslt perl coffee conference dslr nikon photography science codec vp8 forum unb 1 2

Securityday 2008

16:41

Friday, April 18. 2008

An meiner Hochschule findet nun am 25. April 2008 der erste "Security Day" im Jahr 2008 statt.
Wie bisher gibt es interessante Vortraege von Studenten und Menschen, die sich beruflich mit dem Thema befassen. Reinschauen lohnt sich.

Posted by admin in computer | Comments (0) | Trackbacks (0)
Defined tags for this entry: security, software

Admin Zen

10:26

Tuesday, April 15. 2008

Fuer alle Admins und solche die es werden wollen:

  • Admin Zen als PNG
  • Admin Zen als PDF

Zum Ausdrucken an die Wand haengen etc. ;-)

[via]

Posted by admin in web | Comments (0) | Trackbacks (0)
Defined tags for this entry: security, webwide

Vielen Dank an die Leute in Karlsruhe

00:39

Thursday, February 28. 2008

Sie haben entschieden:

§ 5 Abs. 2 Nr. 11 Satz 1 Alt. 2 VSG, der den heimlichen Zugriff auf informationstechnische Systeme regelt ("Online-Durchsuchung"), verletzt das allgemeine Persönlichkeitsrecht in seiner besonderen Ausprägung als Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme und ist nichtig.


Der Bundestrojaner wurde zwar nicht komplett verboten aber zum Glueck stark eingeschraenkt. Hier mal ein Zitat von SpOn:

Es sind Hürden, die weit höher liegen als die bei Eingriffen in das Post- und Fernmeldegeheimnis oder gar die allgemeine Handlungsfreiheit - und die mehr den strengen Kautelen ähneln, die für den Schutz der Unverletztlichkeit der Wohnung gelten wie beim Großen Lauschangriff.
Posted by admin in zeitgeist | Comment (1) | Trackbacks (0)
Defined tags for this entry: bad world, privacy, security

Video Empfehlungen

00:30

Thursday, February 28. 2008

Quarks & Co: Die Waffen der Terror-Fahnder
Quarks & Co: Einkaufen - Wie wir uns manipulieren lassen
Kuckt es euch mal an. Es lohnt sich. :-)

Posted by admin in web, zeitgeist | Comments (0) | Trackbacks (0)
Defined tags for this entry: bad world, privacy, security, webwide

Neue StudiVZ Sicherheitsluecke

01:03

Monday, February 4. 2008

Doener berichtet ueber einen brandheissen Bug in StudiVZ der dadurch entsteht, dass beim Verlinken von Bildern User-IDs nicht ueberprueft werden:

Es geht um folgendes: Im StudiVZ kann jeder ihm bekannte Personen auf Fotos verlinken. Von dieser Möglichkeit wird auch reger Gebrauch gemacht. Wie ein Freund von mir nun feststellte, ist es möglich mittels des Firefox-Plugins Web Developer, den Wert, wer ein bestimmtes Foto mit wem verlinkt hat, beim Setzen des Links zu manipulieren. Mit Hilfe des Web Developer-Tools ist es also möglich, Fotos zu verlinken und dabei so zu tun, als hätte jemand anderes das entsprechende Foto mit einer bestimmten Person verlinkt.


Ihr findet dort auch eine Anleitung wie man das mit der Webdeveloper-Erweiterung fuer Firefox realisiert. Da ich StudiVZ selbst nicht nutze, kann ich das leider nicht ausprobieren. Ich waere aber interessiert an weiteren Berichten.

Posted by admin in web, zeitgeist | Comments (2) | Trackbacks (0)
Defined tags for this entry: bad world, privacy, security, webwide

Schnellere Auszaehlung und so

13:05

Monday, January 28. 2008

Wer immer noch glaubt, dass durch Wahlcomputer die Wahlen schneller ausgezaehlt werden koennten, sollte sich ma das hier ankucken. Da ist durch den Einsatz von Wahlcomputern die Wahlbeteiligung von 60% auf 7% gesunken. Das Ergebnis wurde dann zurueck gezogen und neu gewaehlt. Das Ergebnis spricht fuer sich.
Wann lernen die Leute endlich, dass man so etwas wichtiges wie eine Wahl nicht einem leicht manipulierbaren Geraet wie einem Computer anvertrauen will?

Posted by admin in zeitgeist | Comments (0) | Trackbacks (0)
Defined tags for this entry: bad world, privacy, security

Wahlcomputer i++

12:42

Monday, January 28. 2008

Dieses Mal ganz boeses Foul bei den Hessen.

Neben massiver Behinderung der Wahlbeobachtung in mehreren Gemeinden kam es zu einer Reihe von Vorfällen, welche die Behauptungen des hessischen Innenministeriums über die Sicherheit und Zuverlässigkeit der Wahlcomputer klar widerlegen. In mindestens einer Gemeinde wurden die Computer über Nacht in den Privatwohnungen von Parteimitgliedern gelagert. Dies sei "gängige Praxis", bestätigten Mitarbeiter des Ordnungsamtes den Wahlbeobachtern. Alle neun Wahlcomputer der Gemeinde Niedernhausen seien privat gelagert worden.


Na dann hoffen wir mal, dass die die Wahl nun nochmal und zwar auf Papier durchfuehren muessen.

Posted by admin in zeitgeist | Comments (2) | Trackbacks (0)
Defined tags for this entry: bad world, privacy, security

Spamhasser

23:06

Saturday, January 26. 2008

Ich musste gerade > 20 Spam-Trackbacks loeschen, die im letzten Tag hier aufgetroffen sind. Das geht zwar schnell und schmerzlos, aber als bekennender Spamhasser muss ich da wohl noch weitere Massnahmen ergreifen um diesem unwuerdigen Abschaum keine Angriffsflaeche zu bieten. narf
Zur Entspannung:


Und hier der Direktlink.

Posted by admin in computer | Comments (2) | Trackbacks (0)
Defined tags for this entry: bad world, security, software

Ein Blick in die Kristallkugel ...

17:07

Monday, January 7. 2008

.. liefert Heise Security. Mit verdammt realistischen Vorraussagen.

Posted by admin in web, zeitgeist | Comments (0) | Trackbacks (0)
Defined tags for this entry: bad world, privacy, security, webwide

PHP bashing

19:21

Saturday, November 3. 2007

Hier findet man mal ein paar einleuchtende Argumente gegen PHP als Programmiersprache der Wahl.
Bei dieser Gelegenheit koennte ich mal laut darueber nachdenken auf ein Blog-System wie Typo oder Mephisto umzusteigen. Beide sind, im Gegensatz zu Wordpress, in Ruby on Rails geschrieben.

Posted by admin in computer, web | Comments (3) | Trackbacks (0)
Defined tags for this entry: bad world, security, software, webwide

Lighttpd

17:42

Saturday, November 3. 2007

Leider hatte mein Server in letzter Zeit seltsame Performanceprobleme. Der Apache hat mir staendig meinen Swapspace voll gemacht und wollte dann nicht mehr. Das war mehr als unbefriedigend.
Da ich schon lange mal den schicken und schnellen lighty ausprobieren wollte, habe ich nun komplett auf lighty umgestellt. Zusammen mit xcache laeuft das Setup, im Vergleich, verdammt schnell. Ein gutes Howto wie man php mit lighty sicher aufsetzt findet man hier.
Probleme gab es nur bei den Rewrite-Regeln fuer Wordpress. Hier haben folgende Anweisungen das Problem geloest:

 url.rewrite-once = (
        "^/(.*)?/?files/$" => "index.php",
        "^/(.*)?/?files/(.*)" => "wp-content/blogs.php?file=$2",
        "^/(wp-.*)$" => "$1",
        "^/([_0-9a-zA-Z-]+/)?(wp-.*)" => "$2",
        "^/([_0-9a-zA-Z-]+/)?(.*\.php)$" => "$2"
    )
    server.error-handler-404  = "/index.php"


Das mit dem "server.error-handler" ist zwar nicht besonders schoen aber funktioniert.
roothausende-load-day.png

Posted by admin in computer, misc | Comments (0) | Trackbacks (0)
Defined tags for this entry: changes, computer, linux&unix, misc, security, shortys, software

Verschluesselte Backup-Platte revisited

19:07

Friday, July 20. 2007

Vorwort:

Vielen werden grosse Teiles dieses Howtos wohl bekannt vorkommen. Mittlerweile sind schon ein paar Monate vergangen, seit ich das letzte cryptsetup-LUKS Howto geschrieben habe. Ich habe mir hier beim Ueberarbeiten auch mehr Zeit genommen als beim eigentlichen Howto.
Eigentlich war noch ein Howto zum Verschluesseln aller Partitionen geplant, aber ich habe nun erstmal beschlossen das bestehende zu erweitern. Dieses hatte noch ein paar Macken und daher bin ich der Meinung, dass es sich lohnt es nochmals zu ueberarbeiten und neue Erkenntnisse einfliessen zu lassen. Ein paar Rechtschreibfehler wurden nebenbei auch korrigiert.
Ausserdem war, je nach System, auf technischer Seite zu viel Handarbeit beim Backup notwendig. Ich habe mir Gedanken gemacht, wie man die Vorgaenge der Verschluesselung moeglichst einfach automatisieren koennte und zum Entschluss gekommen, dass udev-Regeln, ein Eintrag in der /etc/fstab und die Arbeit mit zusaetzlichen Keyfiles das Ganze weitgehend optimieren und automatisieren koennen.

Das Howto:

Das Backup wichtig ist und die vorhandenen Daten auf einem Computer prinzipiell immer den Wert einer zusaetzlichen Festplatte uebersteigen, sollte wohl den meisten klar sein. Wer mit seinem PC arbeitet und damit vielleicht sogar sein Geld verdient kann sicherlich bestaetigen von was ich rede. Auch bei privaten Daten bin ich der Meinung, dass sich eine Sicherung lohnt.
Allerdings ist eine externe Festplatte auch ein Sicherheitsrisiko: Prinzipiell koennte jeder die Festplatte an seinen PC anschliessen und haette Zugriff auf alle gespeicherten Daten. Dieses Problem laesst sich mit der Verschluesselug der betroffenen Daten loesen - wenn man bereit ist einen etwas geringeren Datendurchsatz in Kauf zu nehmen. Doch ganz ehrlich: Wer legt bei einer Sicherungsfestplatte schon einen hoeheren Wert auf ein paar MB/s mehr Datendurchsatz wenn die Daten dafuer nicht gegen unbefugten Zugriff geschuetzt sind?

Vorbereitung

Zuerst muss im Kernel dm_mod und dm_cypt sowie aktiviert sein. Dies ist bei den meisten Distributionen sowieso der Fall. Bei einem selbst gebauten Kernel benoetigt man folgende Optionen:

Device Drivers  --->
Multi-device support (RAID and LVM)  --->
    [*] Multiple devices driver support (RAID and LVM)
    <>   RAID support
    <M>   Device mapper support
    <M>    Crypt target support
Cryptographic options  --->
  --- Cryptographic API
   <M>   SHA256 digest algorithm
   <M>   Blowfish cipher algorithm
   <M>   AES cipher algorithms (i586)

Zusaetzlich benoetigt man noch cryptsetup-LUKS. Dieses wird wird bei den meisten Distributionen ueber das Paketmanagement installiert werden koennen. Im Fall von Arch Linux waere das mit pacman moeglich:

pacman -S cryptsetup

Bei anderen Distributionen heisst das Paket entweder auch cryptsetup oder cryptsetup-luks. Dieses laesst sich dann mit apt, yum, portage etc. problemlos nachinstallieren. Wichtig ist nur, dass die notwendigen Kernelmodule vorhanden sind.

Ist cryptsetup-luks installiert, sollte man die Daten auf der zu verwendeten Festplatte zerstoeren. Also nicht nur loeschen oder die Festplatte neu formatieren, denn da besteht immer noch die Moeglichkeit, dass sich die Daten teilweise wiederherstellen lassen. Einen guten Artikel zum Loeschen von Daten findet man bei pro-linux.

Wird eine neue, ungebrauchte Festplatte verwendet, kann dieser Schritt uebersprungen werden.

Fuer die meisten duerfte hier dd das Tool der wahl sein. /dev/sdc1 ist in diesem Fall das Device ueber das ich meine Backupplatte anspreche. Welches das ist, sollte man genau (!!) wissen, da es sonst zu boesen Ueberraschungen in Verbindung mit den folgenden Aufrufen kommen koennte. Wer also kein Lust hat aus Versehen die falsche Platte zu loeschen, sollte hier lieber mehrfach pruefen.

Mit dd kann man die Festplatte sowohl mit Zufallswerten wie im ersten Aufruf oder mit Nullen wie im zweiten Aufruf ueberschreiben. Letzteres ist schneller aber dafuer unsicherer.

dd if=/dev/urandom of=/dev/sdc1

dd if=/dev/zero of=/dev/sdc1

dev/sdc1 ist hierbei das Device der verwendeten Festplatte. Ich empfehle hierzu die Manpage von DD. Alternativ kann man auch mit dem Befehl shred arbeiten. Hier gibt "-n" die Anzahl der Vorgaenge an. In diesem Fall wird die Platte 10x ueberschrieben:

shred -fv -n 10 /dev/sdc1

Verschluesseln:

Ist die Festplatte sauber, kann man mit sie cryptsetup formatieren:

cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/sdc1

Hiermit wird eine AES-Verschluesselung, SHA256 Hashes, ESSIV in Verbindung mit einem 256-Bit Schluessel verwendet.
Die Option "-s" gibt die Laenge des Schluessels an und die Option "-y" fordert den User auf eine Passphrase zu waehlen. Alternativ kann man mit "-d" auch ein Keyfile statt der Passphrase verwenden.
Weitere Optionen findet man in der Manpage.

Nun legt man sein Crypto-Device an:

cryptsetup luksOpen /dev/sdc1 backup

An dieser Stelle wird man nach der Passphrase gefragt, die man beim Formatieren eingegeben hat. Verwendet man ein Keyfile, muss man dieses ebenfalls mit "--key-file" angeben.
Der Befehl legt ein neues Device unter /dev/mapper an. In unserem Fall /dev/mapper/backup. Dieses kann man nun wie ein normales Blockdevice formatieren, mounten und beschreiben. Die Ver- und Entschluesselung laeuft transparent im Hintergrund ab.

Formatieren:

mkfs.ext3 /dev/mapper/backup

Mounten:

mount -t ext3 /dev/mapper/backup /mnt/tmp

Alle Daten die man in /mnt/tmp speichert, landen nun verschluesselt auf der Platte.
Will man die Platte wieder abhaengen geht man folgernder massen vor:

Festplatte unmounten:

umount /mnt/tmp

Un danach Crypto-Device schliessen:

cryptsetup luksClose /dev/mapper/backup

Jeder der jetzt auf die Daten der Festplatte zugreifen will, braucht die Passphrase bzw. das Keyfile.

Automation

Um diese komplette Prozedur nicht jedes mal aufs neue ausfuehren zu muessen, kann man das ganze auch automatisieren. Waere ja Unsinn, wenn man die ganzen Sachen von Hand ausfuehren muesste, wenn man die Moeglichkeiten hat dies mit ein paar Kniffen weitgehend zu automatisieren.

Vorerst lege ich noch einen Eintrag in der /etc/fstab fuer das Backupsystem an:

/dev/mapper/backup   /backup        ext3  noatime,noauto,noexec         0  0

Dann lege ich ebenfalls mit dd ein 256Bit grosses Keyfile an. Da bei mir das root-Filesystem verschluesselt ist, kann ich den Schluessel, der fuer die Backup-Festplatte gebraucht wird, auf diesem ablegen. Ist dies nicht der Fall, sollte aus Sicherheitsgruenden eher weiter mit einer Passphrase gearbeitet werden. Eine Alternative waere es, das Keyfile zu erstellen und nun mit GPG zu ver/entschluesseln. Darauf moechte ich allerdings nicht weiter eingehen. Also wird das Keyfile nun erstmal erstellt:

dd if=/dev/urandom of=/etc/crypto/backuphdd.key bs=256 count=1

Nun muss cryptsetup-luks noch Bescheid wissen, dass sowohl die Passphrase als auch das Keyfile verwendet werden kann:

cryptsetup luksAddKey /dev/sdc1 /etc/crypto/backuphdd.key

War dies Erfolgreich schaut das ganze etwa so aus:

Enter any LUKS passphrase:                    
key slot 0 unlocked.
Command successful.

Jetzt kann mal testweise auf die Platte zugegriffen werden:

cryptsetup luksOpen /dev/sdb1 backup --key-file /etc/crypto/backuphdd.key

Und siehe da: "key slot 1 unlocked.". Es musste also keine Passphrase eingegeben werden. Somit ist schonmal der erste Schritt der Automation vollstaendig. Nun kann das Crypto-Device wieder ausgehaengt werden:

cryptsetup luksClose backup

Allerdings steht man nun vor einem Problem: Wechselnde Device-Nodes. Bei USB-Datentraegern unterscheiden sich, je nach Reihenfolge in der sie eingesteckt werden, die Devices ueber die man die Platte ansprechen kann. Zudem ist ja erwuenscht, dass beim Einstecken der Festplatte automatisch mit dem Keyfile das crypto-Device erstellt wird. Danach soll die Platte, ebenfalls automatisch, gemountet werden. Somit hat man nichts weiter zu tun als die Platte einzustecken und man kann sofort darauf zugreifen, obwohl sie komplett verschluesselt ist.

Alles was dazu gebraucht wird ist udev und eine Regel.

Also brauche ich, wie beim vorherigen Udev-Howto beschrieben, erstmal ein Identifikationsmerkmal mit dem ich die Festplatte von anderen unterscheiden kann:

udevinfo -a -p `udevinfo -q path -n /dev/sdc` | grep ATTRS{serial}
    ATTRS{serial}=="1234567898253894C400000123456789"
    ATTRS{serial}=="0000:00:1d.7"

Nun wird mit diesen Infos eine Udev-Regel erstellt. In meinem Fall lege ich dazu die Datei /etc/udev/rules.d/00.rules an.

ACTION=="add", BUS=="usb", ATTRS{serial}=="1234567898253894C400000123456789", KERNEL=="sd?1", NAME="%k", SYMLINK+="ext/backup", GROUP="storage", RUN+="/etc/crypto/scripts/backuphdd", ENV{ACTION}="add"

Mit diesen Regeln wird ein Symlink fuer die Festplatte auf /dev/ext/backup erstellt. Da man die Festplatte beim Einstecken im Normalfall einhaengen moechte, wird das Script /etc/crypto/scripts/backuphdd beim Einstecken gestartet. Dieses Script schaut folgendermassen aus:

#!/bin/bash
# check action
if [ $ACTION = "add" ];
then
   #pause
   /bin/sleep 2
   # create cryptodevice
   /usr/sbin/cryptsetup -c aes-cbc-essiv:sha256 --key-file /etc/crypto/backuphdd.key -h sha256 luksOpen /dev/ext/backup backup
   # and mount it
   /bin/mount /backup
fi
exit 0

Dieses Script pausiert kurz, legt dann das mit Hilfe des Keyfiles das Cryptodevice an und haengt die Platte am richtigen Punkt ein. Somit wird die Festplatte nun sofort beim Anstecken automatisiert eingehaengt. An diesem Punkt ist es auch kein Problem weitere Aktionen ins Script einzubinden. So koennte zum Beispiel nach dem Mounten auch automatisch ein Backup loslaufen.

Backupsystem

Fuer die eigentlichen Backups kommt bei mir rsnaphot zum Einsatz. Dies ist ein Perl-Script welches auf rsync basiert und in der Lage ist sowohl Vollbackups als auch inkrementelle Sicherungen auf Festplatten oder entfernte Rechner durchzufuehren. Zudem laesst es sich vernuenftig konfigurieren.

rsnapshot is a filesystem snapshot utility for making backups of local and remote systems. Using rsync and hard links, it is possible to keep multiple, full backups instantly available. The disk space required is just a little more than the space of one full backup, plus incrementals.

Installieren kann man das Ganze unter Arch Linux mit "pacman -S rsnapshot".

Ein ausfuehrliches Howto findet man auf der offiziellen Seite. Ich moechte hier eher auf die Automation in Verbindung mit der verschluesselten Festplatte eingehen. Hier werden die Optionen in der /etc/rsnapshot.conf festgelegt:

# Specify the path to a script (and any optional arguments) to run right
# before rsnapshot syncs files
#
# cmd_preexec
# Specify the path to a script (and any optional arguments) to run right
# after rsnapshot syncs files
#
cmd_postexec   /bin/umount /backup &&amp; /bin/sleep 1 &&amp; /bin/cryptsetup luksClose backup

Hier muessen zwischen cmd_[pre|post]exec und dem eigentlichen Befehl TABs und keine Leerzeichen stehen, da rsnapshot seinen Dienst verweigert wenn letztere eingesetzt wurden. Im beschriebenen Fall wurde die Festplatte schon automatisch eingehaengt. Also kann man das preexec-Kommando auslassen. Im postexec-Kommando muss das Cryptodevice zuerst ausgehaengt und dann wieder geschlossen werden, vorrausgesetzt man will die Festplatte nach dem erfolgreichen Backup einfach wieder abziehen.

Nun ein finaler Testlauf:

[root@wopr:~]# rsnapshot hourly
Enter LUKS passphrase: 
key slot 0 unlocked.
Command successful.

Nachdem das Backup also moeglichst automatisiert und sicher vonstatten geht, kann man nun seine wichtigen Daten regelmaessig sichern und ist in der Lage boesem Datenverlust vorzubeugen. Wer nun immer noch der Meinung ist, dass er kein Backup braucht, ist selbst schuld.

Weiterfuehrende Links:

  • DM-Crypt im Gentoo-Wiki
  • DM-Crypt im Ubuntuusers-Wiki
  • Luks Website
  • weiteres DM-Crypt Howto
  • LUKS encrypted Root im Archwiki
  • Erstellen der udev-Regeln
  • rsnapshot howto

Wichtig:

Ich uebernehme keine Verantwortung fuer Datenverlust oder sonstige Verluste. Ihr solltet euch beim Durchfuehren dieses Howtos, insbesondere beim Loeschen und Formatieren absolut sicher sein was ihr tut. Vor allem solltet ihr genau pruefen, dass ihr das richtige Device verwendet und sich auf der Platte keine wichtigen Daten befinden!

Hilfestellung:

Ich habe das beschriebene Setup bei mir am Laufen und soweit funtioniert es auch. Einziges Manko: Wenn das Script ueber den Udev-Event aufgerufen wird, dauert es ca. 5min bis die Platte eingehaengt ist. Ruft man das Script von Hand auf, dauert es ein paar Sekunden. Vielleicht kann mir ja hier einer der Leser beim Debuggen helfen.

Posted by admin in computer | Comments (3) | Trackbacks (2)
Defined tags for this entry: computer, howto, linux&unix, security, software

Sicheres FTP Backup

18:12

Saturday, July 14. 2007

Ich bin gerade durch Zufall auf diesen Artikel bei heise security gestossen. Dazu gibt es auch dieses Howto.
Ich habe das Ganze mal getestet und muss sagen: Funktioniert prima :-)

Posted by admin in computer | Comments (0) | Trackbacks (0)
Defined tags for this entry: linux&unix, security, shortys, software

SSL erwuenscht?

21:52

Monday, April 16. 2007

Fuer diejenigen, die daran interesse haben: Dieses Blog gibts nun auch SSL-gesichert ueber HTTPS. Wer den Feed z.B. nun per HTTPS abonnieren will, kann dies tun.
Die Standard-URL ist daher nun auch blog.roothausen.de, da es sonst Probleme mit dem Zertifat gibt.
Wichtige Sachen wie z.B. Logins etc. hab ich mit Redirects auf HTTPS umgebogen. Der Rest bleibt wie gehabt. Sowohl der Feed als auch der Rest der Seite ist erreichbar wie sonst auch.
Zum Testen: https://blog.roothausen.de

Posted by admin in computer, misc | Comments (6) | Trackbacks (0)
Defined tags for this entry: changes, security, software

Dovecot

21:46

Sunday, April 15. 2007

Dovecot ist ein kleiner und schneller IMAP/POP3-Server. Zusaetzlich wird Wert auf Sicherheit gelegt. Wikipedia meint dazu folgendes:

Das Hauptaugenmerk bei der Programmierung wird auf die Sicherheit gelegt. Der Server kann mit den Formaten maildir und mbox umgehen und ist dazu vollständig kompatibel zum Courier-Server und UW-IMAP. Dovecot unterstützt u. a. folgende Merkmale:
  • IMAP4rev1
  • THREAD- und SORT-Erweiterung
  • TLS / SSL
  • IPv6


Dank diesem Post und dem beschriebenen Script und dem Eintrag im dovecot-Wiki war die Migration relativ einfach.
Die Konfigurationsdateien sind zumindest bei Debian recht ausfuehrlich kommentiert und so funktioniert auch die Datenbankanbindung fuer die virtuellen User, die Integration des VMail-Verzeichnisses und die Anzeige der User-Quota im Client.
Alles in allem ist das Teil wirklich schneller als Courier und verbraucht dabei weniger Ressourcen. In Sachen Features fehlt mir nichts. Also eine klare Empfehlung :-)

Posted by admin in computer, misc | Comments (0) | Trackbacks (0)
Defined tags for this entry: changes, linux&unix, opensource, security, shortys, software
« previous page   (Page 2 of 5, totaling 67 entries)   next page »

JavaScript String .fromCharCode

Calendar

« May '12 »
Mo Tu We Th Fr Sa Su
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Quicksearch

Kategorien

  • XML computer
  • XML misc
  • XML web
  • XML zeitgeist


All categories

Archiv

  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • Recent...
  • Older...

Feeds

  • XML RSS 2.0 feed
  • ATOM/XML ATOM 1.0 feed
  • XML RSS 2.0 Comments

Links

Retinacast
Shackspace
Yaxim
Radio Tux
Kais Blog
Blumen Pfleiderer
Alk
paxos
filzo
Marc Seeger
polzifer
Moritz Haarmann

Tags

android bad world blog blogging browser changes code comic computer contentmanagement encryption feedreader firefox free fun google gui hardware howto html im jabber java life lighttpd linux linux&unix markup media misc mobile murphy networking newsbeuter opensource picture politics presentation privacy programming regular expression rss ruby s9y scala screenshot sdk security server shortys software stuff tail -f /var/log/life test tool tv unix video web webdesign webwide windows xml zeitgeist

Lizenz

Creative Commons License - Some Rights Reserved