Autorenarchiv: Jörg Kastning

Der eigene Mailserver – Start der Artikelreihe

12 Antworten

Wie man den eigenen Mailserver mit eigener Domain möglichst sicher im Internet betreibt wird Gegenstand einer kleinen Artikelreihe sein.

Die Idee dazu kam mir, nachdem ich eine englischsprachige Artikelreihe zum Thema auf ars technica gelesen habe.[1. Hutchinson, Lee (17.02.2014). How to run your own e-mail server with your own domain, part 1: Gmail? Apple? The cloud? Forget ‚em all—in this series, we take your e-mail back.] Ich werde nach dem Muster von Lee einen Linux Mailserver aufsetzen und zur Nutzung mit einer eigenen Domain konfigurieren. Die dazu erforderlichen Schritte werde ich in den kommenden Artikeln festhalten. Sie sollen mir als Dokumentation und euch als Leitfaden dienen. Fangen wir an.

Ein paar Worte vorweg

Einen Mailserver im Internet zu betreiben ist eine verantwortungsvolle Aufgabe. Arbeitet man hier nicht sorgfältig, schafft man leicht ein sogenanntes Open Relay, welches sehr schnell als Spamschleuder missbraucht werden wird. Um genau dies zu verhindern, muss man bei jedem Arbeitsschritt die Sicherheit des Systems im Hinterkopf behalten und die eigene Konfiguration permanent auf mögliche Schwachstellen hin überprüfen.

Mit der Installation und Konfiguration ist es nicht getan. Der dauerhafte Betrieb eines Mailservers bringt einige wiederkehrende Aufgaben mit sich. Der Server ist regelmäßig zu warten. Sicherheitsupdates müssen installiert werden, die verwendeten Dienste sollten stets auf die aktuellste Version aktualisiert werden und von Zeit zu Zeit sollte man die Logdateien auf ungewöhnliche Vorkommnisse hin überprüfen.

Diese Artikelreihe wird keine Schritt-für-Schritt Anleitung. Grundlegende Kenntnisse in Linux, der Arbeit in einem Terminal, der Nutzung eines Texteditors und der Umgang mit der Paketverwaltung werden vorausgesetzt. Auch solltet ihr in der Lage sein, euch eure eigene Domain zu shoppen. ;-)

Wer auf all dies keine Lust hat, hört am besten hier zu lesen auf. Allen anderen wünsche ich viel Spaß und Erfolg auf dem Weg zum eigenen Mailserver.

Wie ist diese Reihe aufgebaut?

Dieser Artikel gibt eine Einführung in die E-Mail Terminologie. Anschließend gehe ich auf das verwendete Betriebssystem und die Dienste ein, welche zur Realisierung des Mailservers zum Einsatz kommen.

Die Links im Text führen euch auf Seiten, die weiterführende Informationen zum verwendeten Begriff bieten. Die für diese Artikelreihe verwendeten Quellen werden als Fußnoten am Ende des jeweiligen Artikels aufgeführt. Benötigt ihr zur Durchführung einzelner Schritte weitere Informationen, so helfen euch diese Quellen weiter.

Die folgenden Artikel führen durch die Tiefen der Konfiguration, der hier vorgestellten Rollen und Dienste und beschreiben, wie man sein System härtet, um es so gut wie möglich vor Missbrauch zu schützen.

Die Terminologie

Ein Mailserver ist kein einzelner Dienst. Vielmehr setzt sich ein Mailsystem aus unterschiedlichen Komponenten zusammen, die nicht einmal auf demselben Rechner laufen müssen (und es bei größeren Installationen meist auch nicht tun).[2. Mailserver-Einführung]

Diese Artikelreihe orientiert sich an der Terminologie aus der Mailserver-Einführung im Wiki von ubuntuusers.de. Die wichtigsten Begriffe möchte ich hier wiedergeben.

  • MTA (Mail Transfer Agent)/SMTP-Server: zuständig für den Transport der Mail von einem System zum anderen (mehr zu MTA und SMTP)
  • MDA (Mail Delivery Agent): stellt die Post auf dem lokalen System zu (mehr zu MDA)
  • MRA (Mail Retrieval Agent): holt Post von einem entfernten Server ab (mehr zu MRA)
  • IMAP-/POP3-Server: hält die Post für den Endbenutzer bereit, damit er sie mit seinem Mailprogramm (MUA – Mail User Agent) abholen und lesen kann (mehr zu IMAP, POP3 und MUA)

Der Server – Das Betriebssystem

Für einen echten E-Mailserver benötigt man einen Server mit einer öffentlichen IP-Adresse, welche im Internet geroutet wird. Hostingprovider, welche diese Server für eine monatliche Gebühr anbieten, findet man mit der Suchmaschine seiner Wahl reichlich im Netz.

Bei der Auswahl eines Hostingproviders kann man sich das erste Mal Gedanken über die Sicherheit machen. Hier empfiehlt es sich auf einen Anbieter setzen, der sich nach dem internationalen Standard ISO 27001 zertifizieren lässt. Diese Norm spezifiziert Anforderungen für die Implementierung geeigneter Sicherheitsmechanismen. So hosten z.B. auch Großbanken ihre Dienste in Rechenzentren, die sich an den Vorgaben der ISO 27001 orientieren.

Wenn man sich einen Root-Server sucht, sollte man außerdem darauf achten, dass der Provider neben der normalen IPv4 Adresse dem Server auch eine IPv6 Adresse spendiert. So stellt man von Anfang an sicher, dass der eigene Mailserver auch über das neue IP-Protokoll erreichbar ist.

Als Betriebssystem für einen Linux Mailserver kann im Prinzip jede beliebige Linux-Distribution dienen, solange die im nächsten Abschnitt genannten Pakete für die gewählte Distribution verfügbar sind.

Aufgrund persönlicher Vorlieben habe ich mich für Ubuntu Server 14.04.1 LTS entschieden. Diese Version verfügt über Long Term Support und wird bis April 2019 mit Sicherheitsaktualisierungen versorgt.

Darüber hinaus ist Ubuntu eine sehr beliebte Distribution, die bei fast allen Hostingunternehmen zur Verfügung steht. Ubuntu stellt dabei ein Metapaket bereit, welches es uns ermöglicht, zügig und sicher ein vollständiges Mailsystem aufzusetzen. Doch später mehr dazu.

Hat man seinen Root-Server bestellt und das Betriebssystem installiert, erfolgt der Zugriff darauf meist via SSH. Der SSH-Dienst wird über die Datei /etc/ssh/sshd_config konfiguriert. Bei Ubuntu ist die Standardkonfiguration schon ganz akzeptabel und bei Verwendung eines starken Passworts auch ausreichend sicher. Statt der Authentifizierung über Benutzername und Passwort kann man sich alternativ auch via Pulbic-Key[3. Authentifizierung über Public Keys] authentifizieren. Damit ist man selbst vor dem unwahrscheinlichen Fall geschützt, dass jemand das verwendete Passwort errät.

Darüber hinaus werden noch einige Optionen in der /etc/ssh/sshd_config wie folgt gesetzt (Erklärung siehe Kommentar im Code):

# Niemand kann sich direkt als root einloggen.
PermitRootLogin no
# Nur die hier aufgeführten Benutzer dürfen sich einloggen.
AllowUsers JohnDoe JaneDoe
# Hiermit wird die Anmeldung mit Benutzername und Passwort deaktiviert.
PasswordAuthentication no

Anschließend nicht vergessen, die geänderte Konfiguration neu zu laden.

Auf dem Server läuft außer dem OpenSSH-Server noch kein weiterer Dienst. Ob dies so ist, kann man mit dem Kommando netstat überprüfen, welches folgende Ausgabe liefern sollte:

john@server:~$ sudo netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          150403263   1527/sshd       
tcp6       0      0 :::22                   :::*                    LISTEN      0          150403265   1527/sshd       
john@server:~$

Ok. Damit ist der Root-Server soweit, dass er nur auf SSH-Verbindungen wartet und diese nur akzeptiert, wenn sich ein autorisierter Benutzer mittels publickey authentifiziert.

Der SSH-Dienst ist ein beliebtes Ziel für Brute-Force-Angriffe. Um auch für diese gerüstet zu sein und den Server im Fall einer Attacke etwas zu entlasten, kann man noch zusätzlich das Paket fail2ban[4. Manual Fail2Ban 0.8] installieren. Mit diesem Paket ist es möglich, Brute-Force-Angriffe zu erkennen und die IP-Adresse des oder der Angreifer für eine gewisse Zeit zu blockieren. Hierzu setzt fail2ban automatisch die benötigten iptables-Regeln.

Was wird sonst noch benötigt?

Neben dem Betriebssystem benötigt man noch eine ganze Reihe weiterer Dinge. Da sind

  • Postfix, der MTA zum Senden und Empfangen von E-Mail
  • Dovecot, der MDA, welcher uns das Protokoll IMAP bereitstellen wird
  • SpamAssassin, um unseren Posteingang frei von Spam zu halten
  • ClamAV, um auch etwas gegen die Viren zu tun
  • Sieve, damit konfigurieren wir Filterregeln
  • Roundcube, da ein guter Webmailer in keinem Mailsystem fehlen darf
  • NGINX und PHP-FPM, um Roundcube auch ausliefern zu können

All diese Dienste gilt es zu härten und abzusichern. Die Kommunikationsverbindungen werden mit SSL/TLS gesichert. Für die eigene Maildomain werden DKIM und SPF konfiguriert.

Und ganz am Ende haben wir nicht nur einiges über Linux und die Absicherung von Diensten im Internet gelernt, sondern sind ebenfalls im Besitz unseres eigenen Mailservers.

Bevor es jetzt weitergehen kann, müssen die beiden folgenden Voraussetzungen erfüllt sein:

  1. Root-Server mit öffentlicher IP-Adresse und installierten Betriebssystem steht bereit.
  2. Man ist im Besitz einer eigenen Domain und hat einen DNS-Record gesetzt, welcher auf den eigenen Root-Server zeigt.

Und ab dafür

Hat man sich bei der Wahl des Betriebssystems für Ubuntu entschieden, hat man es jetzt leicht. Denn hier gibt es ein Metapaket, welches postfix und dovecot in einem Rutsch installiert und beide Anwendungen so konfiguriert, dass sie miteinander spielen mögen. Dazu führt man folgenden Befehl aus.

:~$ sudo apt-get install mail-stack-delivery

Nach einem kleinen Augenblick erscheint ein Bildschirm, der dazu auffordert, zu entscheiden, ob man ein selbstsigniertes SSL-Zertifikat für Dovecot nutzen möchte oder nicht.

Konfiguriere dovecot-core: Wollen Sie ein selbstsigniertes SSL-Zertifikat erstellen?

Konfiguriere dovecot-core: Wollen Sie ein selbstsigniertes SSL-Zertifikat erstellen?

Für eine reine Testumgebung reicht ein selbstsigniertes Zertifikat aus. Möchte man den Server mit eigener Domain im Internet betreiben, wählt man hier lieber „No“. In Teil 2 dieser Artikelreihe werde ich noch darauf eingehen, wie man an ein SSL-Zertifikat kommt, dem die gängigen Browser und Betriebssysteme vertrauen.

Einen Moment später erscheint eine Konfigurationsabfrage zu Postfix. Hier wählt man die Option „Internet Site“ aus, um später im Internet E-Mails senden und empfangen zu können.

Postfix Configuration: Internet Site

Postfix Configuration: Internet Site

Der nächste Konfigurationsdialog fordert dazu auf, den Domain-Namen des E-Mailsystems anzugeben. Hier wird der Name der eigenen Domain eingetragen. Möchte man den Server ausschließlich in einer Testumgebung im lokalen LAN betreiben, kann man hier auch so etwas wie testdom.local eintragen.

Postfix Configuration: System-E-Mail-Name

Postfix Configuration: System-E-Mail-Name

Anschließend lässt man die Installation bis zu Ende durchlaufen.

Weiter geht es in Teil 2 dieser Artikelreihe. Dort werde ich beschreiben, wie man ein SSL/TLS Zertifikat bekommt sowie wo und wie die Namen und Kennwörter von E-Mail Benutzern samt der zugehörigen Postfächer gespeichert werden. Am Ende von Teil 2 ist das Mailsystem schon fast voll funktionsfähig. Doch ich bin noch lang nicht fertig.

Denn es fehlt noch an AntiSpam, AntiVirus, Filter-Regeln, DKIM, SPF und unser Webmailer Roundcube. Also bleibt dran, es gibt noch viel zu entdecken.

Jörg Kastning

17. Januar 2015

Heute Morgen musste ich leider feststellen, dass die Kontaktformulare auf My-IT-Brain nicht mehr funktionieren. Die abgesetzten Nachrichten konnten nicht zugestellt werden.

Dies betrifft die Formulare auf den Seiten:

Daher haben mich seit dem 30.12.2014 leider keine Nachrichten mehr erreicht.

Das Problem war die zu restriktive Konfiguration meines neuen Mailservers. Das Problem ist mittlerweile behoben und Nachrichten, welche über die Kontaktformulare versendet werden, erreichen mich wieder.

Falls ihr seit dem 30.12.2014 einen Antrag auf CAcert Assurance gestellt und noch keine Antwort erhalten habt, bitte ich euch eine neue Anfrage zu stellen.

Habt ein schönes Wochenende
John

Automatische Installation von Sicherheitsupdates

3 Antworten

Wie bei jedem Betriebssystem sollten auch bei Ubuntu regelmäßig Updates installiert werden. Dabei handelt es sich um Fehlerkorrekturen, welche die Stabilität des Systems verbessern und insbesondere potenzielle oder erwiesene Sicherheitslücken schließen.[1. Ubuntuusers Wiki: Konfiguration der automatischen Aktualisierung]

Die Installation von Sicherheitsupdates ist eine Aufgabe, die man hervorragend automatisieren kann, um administrativen Aufwand zu sparen. Dazu installiert man unter Ubuntu das folgende Paket:

sudo apt-get install unattended-upgrades

Um die automatischen Updates zu aktivieren, wird die Datei /etc/apt/apt.conf.d/10periodic angelegt bzw. bearbeitet. Diese sollte mindestens die folgenden Einträge enthalten:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";

In der Datei /etc/apt/apt.conf.d/50unattended-upgrades wird festgelegt, welche Art von Updates automatisch installiert werden sollen. Möchte man ausschließlich Sicherheitsupdates automatisch installieren lassen, so ist dies mit der folgenden Konfiguration möglich:

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Damit ist schon alles Nötige getan. Unter /var/log/unattended-upgrades findet man noch ein Log, um überprüfen zu können, welche Änderungen am System durch die automatische Updateinstallation durchgeführt wurden.

Der Unterschied zwischen einem Systembenutzer und einem normalen Benutzer

2 Antworten

Mit den Kommandozeilenwerkzeugen adduser und useradd kann man neben normalen Usern auch sogenannte Systemuser anlegen.

Viele fragen sich hierbei, was eigentlich der Unterschied zwischen diesen beiden Arten von Benutzerkonten ist. Da auch ich mir diese Frage schon ein paar Mal gestellt habe, möchte ich sie mit diesem Artikel endgültig beantworten.

Ich beginne dabei mit ein paar kleinen Auszügen aus der Manpage. Anschließend werde ich für jeden Benutzertyp ein Konto anlegen, um beide direkt miteinander vergleichen zu können.

Die Theorie

In der Manpage von adduser finden sich folgende Einträge:

 Add a normal user
       If  called  with  one  non-option  argument and without the --system or
       --group options, adduser will add a normal user.

       adduser will choose the first available UID from  the  range  specified
       for  normal users in the configuration file.  The UID can be overridden
       with the --uid option.
[...]
 Add a system user
       If called with one non-option argument and the --system option, adduser
       will add a system user. If a user with the same name already exists  in
       the  system uid range (or, if the uid is specified, if a user with that
       uid already exists), adduser will exit with a warning. This warning can
       be suppressed by adding "--quiet".

       adduser  will  choose  the first available UID from the range specified
       for system  users  in  the  configuration  file  (FIRST_SYSTEM_UID  and
       LAST_SYSTEM_UID).  If  you want to have a specific UID, you can specify
       it using the --uid option.

Auf den ersten Blick scheint der Unterschied in der Vergabe von UID und GID zu liegen. Welcher Bereich dabei für die jeweiligen Benutzer gilt, wird in einer Konfigurationsdatei festgelegt. Unter Ubuntu ist dies z.B. die Datei /etc/adduser.conf:

# FIRST_SYSTEM_[GU]ID to LAST_SYSTEM_[GU]ID inclusive is the range for UIDs
# for dynamically allocated administrative and system accounts/groups.
# Please note that system software, such as the users allocated by the base-passwd
# package, may assume that UIDs less than 100 are unallocated.
FIRST_SYSTEM_UID=100
LAST_SYSTEM_UID=999

FIRST_SYSTEM_GID=100
LAST_SYSTEM_GID=999

# FIRST_[GU]ID to LAST_[GU]ID inclusive is the range of UIDs of dynamically
# allocated user accounts/groups.
FIRST_UID=1000
LAST_UID=29999

FIRST_GID=1000
LAST_GID=29999

So liegen die UID und GID von Systembenutzern in diesem Fall zwischen 100 und 999 und die der normalen Benutzer zwischen 1000 und 29999.

Des Weiteren wird laut Manpage für normale Benutzer eine Gruppe mit gleichem Namen wie das Benutzerkonto angelegt. System-Benutzer werden hingegen standardmäßig in die Gruppe nogroup einsortiert.

Die Praxis

Nach der Theorie kommt bekanntlich die Praxis. Diese beginnt mit der Erstellung eines normalen Test-Benutzers.

:~$ sudo adduser test
Adding user `test' ...
Adding new group `test' (1004) ...
Adding new user `test' (1003) with group `test' ...
Creating home directory `/home/test' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for test
Enter the new value, or press ENTER for the default
        Full Name []: Vorname Nachname
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] Y
:~$

Der neue Benutzer test wird automatisch einer Gruppe mit dem gleichen Namen zugewiesen. Der User bekommt dabei die UID 1003, während die Gruppe die GID 1004 erhält. Es wird ein Home-Verzeichnis erstellt und die Standardkonfigurationsdateien werden aus dem Verzeichnis /etc/skel in das Home-Verzeichnis kopiert. Anschließend werden noch ein paar allgemeine Informationen zum Benutzer abgefragt, bevor dieser endgültig erstellt wird.

Wird ein System-Benutzer angelegt, sieht das ganze wie folgt aus:

:~$ sudo adduser --system test2
Adding system user `test2' (UID 114) ...
Adding new user `test2' (UID 114) with group `nogroup' ...
Creating home directory `/home/test2' ...
:~$

Oh Wunder, die Manpage hat recht behalten. Der Benutzer test2 wird mit der UID 114 angelegt und der Gruppe nogroup zugewiesen. Anschließend wird noch das Home-Verzeichnis erstellt und schon ist Schluss. Ach ja, es wurde gar kein Passwort vergeben. Warum eigentlich nicht?

System-Benutzer werden meist von Programmen und Diensten für ihre Ausführung benötigt. Da es sich dabei um keine echten Benutzer handelt, wird auf die Abfrage des vollständigen Namen etc. verzichtet. Auf ein Passwort wird ebenfalls verzichtet. Denn es wäre sehr unpraktisch, dieses jedes Mal eingeben zu müssen, wenn ein Dienst auf eine Datei zugreifen möchte. Und bevor man das Passwort im Klartext in einer Textdatei speichert, vergibt man besser erst gar keins. ;-) Doch ob dies die einzigen Unterschiede sind, wird sich gleich noch zeigen.

Mit der Anlage eines Benutzers werden Einträge in /etc/passwd und /etc/groups hinzugefügt. Die beiden soeben erstellten Test-Benutzer haben dort folgende Einträge:

:~$ cat /etc/passwd | grep test
test:x:1003:1004:Vorname Nachname,,,:/home/test:/bin/bash
test2:x:114:65534::/home/test2:/bin/false

:~$ cat /etc/group | grep test
test:x:1004:
:~$

Der Blick in die Datei /etc/passwd offenbart, dass der normale Benutzer test über eine Login-Shell (/bin/bash) verfügt. Dieser Benutzer ist also in der Lage, sich interaktiv an einem Terminal oder einer SSH-Sitzung anzumelden. Dem System-Benutzer hingegen wurde keine Login-Shell zugewiesen (/bin/false). Dieser ist daher im Gegensatz zum normalen Benutzer nicht in der Lage, sich an einem Terminal oder über SSH am System anzumelden.

Ein Blick in die Gruppe /etc/group offenbart, dass die Gruppe test mit der GID 1004 erstellt wurde, während es für test2 keine Gruppe gibt.

Fazit

Normale Benutzerkonten werden in der Regel für echte Benutzer eines Systems erstellt. Mit Ihnen kann man sich am System anmelden und in einer Shell oder grafischen Oberfläche arbeiten.

System-Benutzer hingegen werden in der Regel für Programme und Dienste angelegt, welche sich nicht interaktiv am System anmelden müssen. Daher besitzen sie weder eine Login-Shell noch ein Passwort.

Sonst unterscheiden sich die beiden Benutzertypen nur darin, aus welchem Bereich ihre UIDs und GIDs stammen. An diesen kann man auch recht einfach erkennen, ob es sich bei einem Benutzer um einen normalen oder System-Benutzer handelt.

ThinkPad Nvidia Bug selbst reparieren

Schreibe eine Antwort

In diesem Artikel möchte ich festhalten, wie ich mein ThinkPad von den Toten zurückgeholt habe. Es ist keine vollständige Anleitung, sondern ein Verweis auf die Quellen, die ich zur Reparatur benötigt habe.

Der sogenannte Nvidia Bug hat mein 8 Jahre altes ThinkPad R61 vor wenigen Tagen in den vorzeitigen Ruhestand geschickt. Doch zum Glück lässt sich der Ruhestand mit dieser Reparaturanleitung aus dem ThinkWiki Forum noch etwas hinauszögern.

Die Arbeitsschritte kurz zusammengefasst:

  1. ThinkPad komplett zerlegen, um Mainboard zu entfernen.
  2. Alle Mainboardaufbauten und die CPU entfernen.
  3. Folien und alte Wärmeleitpaste vom Nvidia Chip entfernen.
  4. Den Nvidia Chip mit einem Heißluftgebläse für 2 Minuten bei ca. 195°-205°C erhitzen
  5. Das Mainboard abkühlen lassen.
  6. Alles in umgekehrter Reihenfolge wieder zusammensetzen.
  7. Sich mit ein wenig Glück über ein funktionierendes ThinkPad freuen. ;-)

Ich habe mich an die im Forum beschriebene Vorgehensweise gehalten. Beim Zerlegen und Zusammensetzen des Notebooks ist das ThinkPad_R61_Hardware_Maintenance_Manual eine echte Hilfe.

Haftungsausschluss: Jeder, der versucht, mit dieser Anleitung sein ThinkPad wiederzubeleben, tut dies auf eigene Gefahr. Es besteht die Möglichkeit, die Hardware endgültig zu zerstören. Diese Reparatur wird auch nicht von Dauer sein. Ihr könnt das Ende damit lediglich hinaus zögern.

Kontakte vom iPhone in die OwnCloud migrieren

1 Antwort

Dieser Artikel beschreibt, wie mann die Kontakte von einem iPhone in die Kontakte App seiner OwnCloud migriert, ohne zusätzliche Software kaufen zu müssen.

Dazu möchte ich zuerst die Ausgangssituation beschreiben. Ich habe auf meinem iPhone ca. 90 Kontakte gespeichert. Zukünftige möchte ich diese Kontakte gern in meiner OwnCloud verwalten. Die Kontakte aus der OwnCloud auf das iPhone zu bekommen ist dabei gut dokumentiert nicht schwer. Doch um meine Kontakte überhaupt erstmal in die Cloud zu bekommen, bin ich wie folgt vorgegangen:

  1. iPhone Kontakte via iTunes mit den Windows Kontakten synchronisieren.
  2. Windows Kontakte mit dem Windows Explorer in das VCF-Format exportieren.
  3. Die einzelnen VCF-Dateien in einer Eingabeaufforderung mit dem Befehl 
    copy /a *.vcf kontakte.vcf

    zu einer einzigen VCF-Datei zusammenfügen.

  4. Die soeben erstellte VCF-Datei in die OwnCloud App für Kontakte importieren.
  5. Alle Windows Kontakte löschen.
  6. Die Kontakte nochmals via iTunes mit dem iPhone synchronisieren. Dabei ist der Haken „Kontakte auf dem Gerät ersetzen“ auszuwählen.

Damit hat man die Kontakte in der OwnCloud und kann sie von dort auf das iPhone und weitere Geräte synchronisieren.

Diese Anleitung ist bewusst knapp gehalten. Solltet ihr damit nicht in der Lage sein, die Kontakte von eurem iPhone bzw. den Windows Kontakten in eure OwnCloud zu importieren, nutzt bitte die Kommentarfunktion. Ich werde versuchen euch weiterzuhelfen.

Viele Grüße

JohnDoe

Den Pi nach Update Fehler wiederbeleben

Schreibe eine Antwort

Nach einem routinemäßigen

sudo apt-get update && sudo apt-get upgrade

hatte es sich zunächst „ausgepied“. Bis auf die rote LED zeigte mein Pi nach dem Reboot keine Lebenszeichen mehr.

In diesem Artikel beschreibe ich kurz und dreckig, wie ich meinen Raspberry Pi nach missglücktem Update wiederbelebt habe, ohne ihn komplett neu installieren zu müssen.

Das Problem
Das Problem trat auf, als ich meinem Pi nach einem Routine-Update neugestartet habe. Ein Blick in die Datei /var/log/apt/term.log zeigt die letzte Update-Ausgabe:

Vorbereitung zum Ersetzen von gnupg 1.4.12-7+deb7u3 (durch .../gnupg_1.4.12-7+deb7u4_armhf.deb) ...
Ersatz für gnupg wird entpackt ...
Trigger für man-db werden verarbeitet ...
Trigger für install-info werden verarbeitet ...
gnupg (1.4.12-7+deb7u4) wird eingerichtet ...
raspberrypi-bootloader (1.20140618-1) wird eingerichtet ...
Memory split is now set in /boot/config.txt.
You may want to use raspi-config to set it
Keine Umleitung »Umleitung von /boot/bootcode.bin durch rpikernelhack«, keine entfernt.
Keine Umleitung »Umleitung von /boot/fixup.dat durch rpikernelhack«, keine entfernt.
Keine Umleitung »Umleitung von /boot/fixup_cd.dat durch rpikernelhack«, keine entfernt.
Keine Umleitung »Umleitung von /boot/fixup_x.dat durch rpikernelhack«, keine entfernt.
»Umleitung von /boot/kernel.img zu /usr/share/rpikernelhack/kernel.img durch rpikernelhack« wird entfernt
»Umleitung von /boot/kernel_cutdown.img zu /usr/share/rpikernelhack/kernel_cutdown.img durch rpikernelhack« wird entfernt
»Umleitung von /boot/kernel_emergency.img zu /usr/share/rpikernelhack/kernel_emergency.img durch rpikernelhack« wird entfernt
»Umleitung von /boot/start.elf zu /usr/share/rpikernelhack/start.elf durch rpikernelhack« wird entfernt
»Umleitung von /boot/start_cd.elf zu /usr/share/rpikernelhack/start_cd.elf durch rpikernelhack« wird entfernt
»Umleitung von /boot/start_x.elf zu /usr/share/rpikernelhack/start_x.elf durch rpikernelhack« wird entfernt
libraspberrypi0 (1.20140618-1) wird eingerichtet ...
libraspberrypi-bin (1.20140618-1) wird eingerichtet ...
libraspberrypi-dev (1.20140618-1) wird eingerichtet ...
libraspberrypi-doc (1.20140618-1) wird eingerichtet ...
Log ended: 2014-06-26  21:00:56

Leider hat mir diese Ausgabe nicht wirklich geholfen, die Fehlerursache genau zu identifizieren. Da der Pi jedoch den Bootvorgang verweigerte, musste der Fehler irgendwo in der Partition /boot liegen.

Meine Lösung
Diese Lösung mag nicht die Beste sein. Jedoch hat sie funktioniert. ;-) Ich benötigt dafür ein Ubuntu-System mit Cardreader. (Ein anderes Linux wird es sicherlich auch tun.)

  1. Aktuelles Raspbian Image von www.raspberrypi.org herunterladen.
  2. Zip-Archiv entpacken und das enthaltene Image im Ubuntu Filesystem einhängen.
  3. SD-Karte des Raspberry Pi einlegen und die enthaltenen Partitionen ebenfalls einhängen.
  4. Nun vergleichen wir den Inhalt der beiden /boot-Partitionen.

Bei dem Vergleich fiel mir auf, dass die folgenden vier Dateien in der /boot Partition meiner SD-Karte fehlten:

-rwxr-xr-x 1 root root   17824 Jun 19 21:59 bootcode.bin
-rwxr-xr-x 1 root root    2090 Jun 19 21:59 fixup_cd.dat
-rwxr-xr-x 1 root root    5845 Jun 19 21:59 fixup.dat
-rwxr-xr-x 1 root root    8822 Jun 19 21:59 fixup_x.dat

Diese habe ich dann einfach aus dem gemounteten Image auf die /boot-Partition der SD-Karte kopiert, die SD-Karte wieder in meinen Raspi gesteckt, ihn eingeschaltet und mich gefreut. Der Pi bootet wieder. Meine Daten und installierten Dienste funktionieren alle noch wie gewohnt. Mission accomplished. :-)

Synology RAID Volume mit größeren Festplatten erweitern

11 Antworten

Diese Anleitung beschreibt, wie man die Speicherkapazität des RAID Volume einer Synology Diskstation durch Einsatz größerer Festplatten erweitern kann. Sie basiert auf der englischsprachigen Anleitung aus dem Synology Wiki.[1. Replace Drives to Expand Storage Capacity]

In meinem Beispiel wird die Kapazität eines Synology Hybrid RAID erweitert. Die Anleitung funktioniert jedoch analog auch für:

  • RAID-1
  • RAID-5
  • RAID-5+Hot-Spare
  • RAID-6
  • Synology Hybrid RAID

Die Anleitung wurde mit der Firmware DSM 5.0-4493 Update 1 erstellt.

Vorsicht!
Bevor irgendwelche Arbeiten an der RAID-Konfiguration durchgeführt werden, sollte eine Datensicherung der Dateien durchgeführt werden, die aktuell auf der Diskstation gespeichert sind. So kann einem Datenverlust in Folge eines Fehlers vorgebeugt werden.

Beginn der Arbeiten

systemstatus

Systemzustand der DS213air

Zuerst werfen wir noch einen kleinen Blick in den Systemstatus, um zu prüfen, dass unsere Diskstation und unser RAID Volume in Ordnung sind. Ist alles in Ordnung, können wir wie im Folgenden beschrieben, die erste Festplatte gegen ein größeres Laufwerk ersetzen.

Ich selbst besitze eine DS213air. Da bei diesem Modell die Festplatten nicht im laufenden Betrieb gewechselt werden können, muss die Diskstation zuerst heruntergefahren werden.

Schritt 1
Nachdem die Diskstation vom Strom getrennt wurde, öffnet ihr das Gehäuse. Nun könnt ihr eine der Festplatten gegen eine größere Festplatte austauschen. Mit welcher Festplatte ihr dabei beginnt, ist egal. Dies bleibt euch überlassen.

Schritt 2

ds213air_open2

Offenes Gehäuse der DS213air

Die Diskstation wird wieder an den Strom angeschlossen und eingeschaltet. Ich habe das Gehäuse für diesen Schritt offen gelassen, da ich später ja auch noch die zweite Festplatte ersetzten möchte.

Nach dem Hochfahren ertönt ein Signalton. Dieser weist darauf hin, dass das RAID Volume beschädigt ist.

Schritt 3
Wir melden uns an der Diskstation an und deaktivieren in der geöffneten Systemsteuerung zuerst den Signalton.

Schritt 4
Wechselt in den Speicher-Manager. Hier wird euch das fehlerhafte Volume angezeigt. Mit einem Klick auf „Verwalten“ startet ihr den Volume Manager Assistent. Klickt euch durch den Assistenten und startet damit die Reparatur eures Volumes.

Die Reparatur kann je nach Größe eures Volumes mehrere Stunden dauern. Mit dem nächsten Schritt darf erst fortgefahren werden, wenn die Reparatur erfolgreich beendet wurde.

Schritt 5
Zeigt der Speicher-Manager für euer Volume wieder den Status Normal, könnt ihr die Schritte 1-4 für die zweite Festplatte wiederholen.

Ende der Erweiterung
Nach der erneuten Reparatur des Volumes wird der Speicherplatz des Synology Hybrid RAID automatisch erweitert und steht euch zur Nutzung zur Verfügung. Ein Blick in den Speicher-Manager bestätigt das Ergebnis.

storagemanager

Überblick Speicher-Manager

Fazit: So einfach ist es, den Speicherplatz für eure Fotos, Videos und die Musiksammlung zu erweitern. Ich hoffe, dass diese Anleitung euch bei der Vergrößerung eurer Volumes unterstützt. Habt ihr Verbesserungsvorschläge, Kommentare oder konstruktive Kritik, so benutzt bitte die Kommentarfunktion zum Beitrag. Ich werde dann versuchen, eure Anmerkungen in den Beitrag einzuarbeiten.

Google will Ende-zu-Ende-Verschlüsselung in den Browser bringen

Schreibe eine Antwort

Beim Stöbern im Internet bin ich über mehrere Artikel gestolpert, die von Googles Plänen berichten, eine Ende-zu-Ende-Verschlüsselung für den Chrome Browser zu entwickeln.

So bin ich auch auf einen Artikel in Googles Security Blog gestoßen. Google schildert in diesem Blog die Absicht, eine „End-to-End“ Erweiterung für den Chrome Browser zu entwickeln, um die Benutzung von sicherer Ende-zu-Ende-Verschlüsselung für den Anwender zu vereinfachen.[1. Making end-to-end encryption easier to use (englisch)]

Die Chrome Erweiterung ist jedoch noch nicht erhältlich. Google hat in einem ersten Schritt den Quellcode der Erweiterung veröffentlicht, um ein Code-Review durch die Internet Community zu ermöglichen. Mit dieser Maßnahme möchte Google das Risiko von Fehlern und Schwachstellen im Quellcode minimieren und das Vertrauen in die Erweiterung stärken.

Auf jeden Fall ist dies ein Schritt in die richtige Richtung. Sind die heute verfügbaren Tools wie PGP oder GnuPG doch den meisten Anwendern zu kompliziert in der Anwendung.[2. Der steinige Weg zu Verschlüsselter Kommunikation]

Doch wird Google wohl auch noch einige Zweifel ausräumen müssen. Als US-Konzern unterliegt Google auch der US-Gerichtsbarkeit. Ich frage mich, ob die US-Behörden nicht etwas dagegen haben, wenn Google seinen Kunden eine sichere Kommunikationsverschlüsselung anbietet, welche den Inhalt von E-Mails auch vor den Augen neugieriger NSA-Agenten schützt.

Musste doch im vergangenen Jahr der E-Mail Anbieter Lavabit seinen Betrieb einstellen, da ihn US-Behörden mutmaßlich zur Entschlüsselung und Herausgabe von Kundendaten aufforderten. Warum sollte Google nicht ähnlicher Druck drohen, wenn sie nicht eine Hintertür für die Behörden offen lassen?[3. Heise Artikel zum Ende von Lavabit]

Google hat neben dem Blogpost auch eine Projektseite geschaltet, welche neben dem Quellcode auch einige FAQs bereit hält.[4. Google End-to-End (englisch)] Diesen ist zu entnehmen, dass die Erweiterung auf OpenPGP basiert, welches einen offenen und sicheren Standard darstellt. Nur ein einziger Abschnitt trübt die aufkommende optimistische Stimmung:

Are the private key(s) kept in memory, are they always purged after every operation, or is there a passphrase cache?

The private keys are kept in memory unencrypted. We recommend making sure your keyring has a passphrase so that private keys are stored encrypted in localStorage.

How safe are private keys in memory?

In memory, the private key is sandboxed by Chrome from other things. When private keys are in localStorage they’re not protected by Chrome’s sandbox, which is why we encrypt them there.

Please note that enabling Chrome’s „Automatically send usage statistics and crash reports to Google“ means that, in the event of a crash, parts of memory containing private key material might be sent to Google.

Auf Deutsch, öffnet man den Schlüsselbund durch Eingabe seiner Passphrase, wird der private Schlüssel in den Arbeitsspeicher geladen. Hat man in seinem Chrome Browser die Funktion aktiviert, automatisch Nutzungsstatistiken und Fehlerberichte an Google zu senden, könnte im Falle eines Browserabsturzes der private Schlüssel mit an Google übertragen werden. Wenn das passiert, bleibt nur das genutzte Schlüsselpaar zu sperren und sich ein Neues zu erstellen. Oder man schaltet von vornherein die Funktion zur Übermittlung von Nutzungsstatistiken und Fehlerberichten an Google ab.

Ob im Quellcode der End-to-End Erweiterung eine Funktion versteckt ist, um den privaten Schlüssel an Google oder einen dritten zu übermitteln, kann ein Code-Review durch die Community zeigen. Ob eine entsprechende Version im Chrome Browser selbst versteckt ist, wird hingegen nicht so schnell festzustellen sein, da der Quelltext nicht komplett offen liegt.

Ehrlich gesagt würde ich mich sicherer fühlen, wenn eine solche Funktion von einem Unternehmen entwickelt würde, das an deutsche Gesetze gebunden ist. Darum bin ich umso mehr gespannt, was die Community und Security-Experten zur neuen Erweiterung sagen. Ich bleib auf jeden Fall dran und halte euch auf dem Laufenden.

smsTAN vs. pushTAN vs. chipTAN

13 Antworten

So ziemlich jede Bank oder Sparkasse bietet ihren Kunden heute mehrere TAN-Verfahren für mehr oder weniger sicheres Online-Banking an. In diesem Artikel möchte ich die drei Verfahren smsTAN, pushTAN und chipTAN kurz allgemeinverständlich beschreiben und auf ihre Vor- und Nachteile eingehen.

smsTAN

smsTAN oder auch mTAN[1. Wikipedia: Mobile TAN] ist ein sehr weit verbreitetes Online-Banking Verfahren. Hierbei werden die Auftragsdetails und die Transaktionsnummer (TAN) an eine Mobilfunknummer gesendet. Als Kunde kann man so prüfen, ob Summe und Empfänger einer Überweisung korrekt sind und anschließend die übermittelte TAN zur Bestätigung eingeben.

Dieses Verfahren galt lange Zeit als sicher, solange man für das Online-Banking und den Empfang der smsTAN nicht ein und dasselbe Geräte nutzt.

Durch die große Verbreitung dieses Verfahrens haben Kriminelle in letzter Zeit jedoch eine Vielzahl möglicher Angriffe gegen dieses Verfahren entwickelt.[2. Wikipedia: Mögliche Angriffe auf mTAN] So berichtete heise Security bereits im August 2013 über zwei gelungene Angriffe auf das mTAN Verfahren.[3. heise: Angriffe auf mit mTAN geschützte Konten] Und nach aktuellen Berichten nehmen diese Angriffe weiter zu. Deutschland gehört dabei nach einem Bericht des Antivirus-Herstellers Kaspersky zu den Top-Angriffszielen in Europa.[4. Online-Banking: Verstärkte Angriffe auf das mTAN-Verfahren]

Dies verwundert nicht, rücken Smartphones durch ihre große Verbreitung doch immer stärker in den Fokus von Betrügern, Crackern und anderen Kriminellen. Für mich bedeutet das, dass es an der Zeit ist, mir ein neues TAN Verfahren auszusuchen.

pushTAN

Ein Verfahren, welches ich bisher noch nicht kannte, nennt sich pushTAN. Laut der Sparkassen Website ist dieses Verfahren besonders für Smartphones und Tablets geeignet, da hierbei TAN-Empfang und Transaktion auf einem Gerät erfolgen können.[5. Sparkasse: Vorteile pushTAN] Bei dieser Aussage sträuben sich mir jedoch die Nackenhaare.

Transaktion und TAN-Empfang auf ein und demselben Gerät? Dies ist in meinen Augen vielleicht bequem aber keinesfalls sicher. Zwar schreibt die Sparkasse, dass die TAN in einem TÜV-zertifizierten und passwortgeschützten Bereich einer S-pushTAN-App angezeigt werden, doch befindet sich alles, was man zum Abräumen des Kontos braucht, auf einem Gerät. Geschützt nur durch Benutzername und Passwort. Doch gerade auf diese Daten haben es Kriminelle abgesehen. Sie versuchen diese Daten mittels Phishing und Trojanern zu erbeuten. Diese Angriffe sind bereits in Sozialen Netzwerken und auf PCs und Notebooks sehr erfolgreich und werden aktuell und in Zukunft auch auf mobile Geräte übergreifen.

Daher lautet mein persönliches Fazit: pushTAN ist viel zu bequem, um noch wirklich sicher zu sein. Daher lautet mein Rat: Hände weg!

Update vom 25.10.2015: App-TANs der Sparkasse demontiert

Was ich bereits im Mai vergangenen Jahres am PushTAN-Verfahren kritisierte, wurde nun von Forschern der Uni Erlangen bestätigt. heiseSecurity berichtet[6. Forscher demontieren App-TANs der Sparkasse], dass es den Forschern gelungen ist, eine in Auftrag gegebene Überweisung abzufangen und zu verändern. Zitat:

Durch gezielte Manipulationen im Betrieb der Sparkassen-App fängt ihr Schadcode eine vom Nutzer in Auftrag gegebene Überweisung ab und verändert diese. Die vom Anwender tatsächlich durchgeführte Überweisung sendet dann einen deutlich höheren Betrag an ein anderes Konto. Der Anwender hat dabei keine Chance die Manipulation zu erkennen, da „die angezeigten Daten zu jeder Zeit des Transaktionsprozesses den eingegeben Werten entsprechen“.

Der schriftliche Bericht von Vincent Haupert und Tilo Müller sowie ein Presseartikel in deutscher und englischer Sprache sind über die Webseite (In)Security of App-based TAN Methods in Online Banking abrufbar.

Für jene, denen Sicherheit beim Online-Banking wichtig ist, wiederhole ich meinen Rat: Hände weg von PushTAN! Jetzt erst recht!

chipTAN

Bleibt als letztes Verfahren aus unserem Trio noch das chipTAN Verfahren.[7. Beschreibung chipTAN] Hierbei kommt ein sogenannter TAN-Generator[8. Wikipedia: TAN-Generator] zum Einsatz, welcher die zur Autorisierung einer Transaktion notwendige TAN generiert.

Um nun eine Überweisung zu tätigen, meldet ihr euch wie gewohnt im Online-Banking an und bereitet eure Überweisung vor. Sendet ihr den Auftrag ab, erscheint eine kleine Grafik auf dem Bildschirm. Nun steckt ihr eure EC-Karte in den TAN-Generator und haltet diesen vor die kleine Grafik. Die Transaktionsdaten werden nun vom TAN-Generator eingelesen und auf diesem nochmals angezeigt. Stimmen alle Daten mit denen auf dem PC überein, könnt ihr eine TAN für diesen Auftrag generieren und die Überweisung autorisieren.

Die Medien, welche zur Auftragsausführung benötigt werden, teilen sich hierbei auf Computer/Tablet, TAN-Generator und EC-Karte auf. Da die TAN beim Kunden generiert wird und nicht erst zu diesem transportiert werden muss, kann sie auch nicht per Phishing oder Trojaner abgefangen werden.[9. Sparkasse: chipTAN Details]

Es ist nicht ausgeschlossen, dass Kriminelle auch Angriffe gegen dieses TAN-Verfahren entwickeln und in Zukunft damit erfolgreich sein könnten. Doch stellt es zum aktuellen Zeitpunkt in meinen Augen das sicherste TAN-Verfahren dar. Ich werde mein TAN-Verfahren gleich zum Beginn kommender Woche auf chipTAN umstellen. Und falls ihr es nicht bereits nutzt, solltet ihr zumindest darüber nachdenken, ob ihr euer TAN-Verfahren nicht auch umstellen solltet.