Schlagwort-Archive: security

SELinux Booleans

Bei SELinux Booleans handelt es sich um kleine Schalter, mit denen sich das Verhalten der SELinux-Richtlinien beeinflussen lässt. Dieser Artikel knüpft an die „Einführung in das grundlegende Konzept von SELinux“ an und erläutert die Verwendung von SELinux Booleans anhand eines einfachen Beispiels.

Hinweis: Das Beispiel aus diesem Artikel wurde auf einem RHEL/CentOS 7.3 getestet. Unter CentOS 7.2 funktioniert die hier gezeigte Konfiguration nicht. Für Details wird auf das Topic1 im CentOS-Support-Forum verwiesen.

Im Einführungsartikel2 wurde SELinux dazu genutzt, um den Zugriff des Apache auf das DocumentRoot-Verzeichnis /var/www/html zu beschränken. Nun möchte der Webmaster den Benutzern gestatten, Webseiten über ihre HOME-Verzeichnisse zu veröffentlichen und aktiviert dazu die Konfiguration für das Modul Userdir.3 4 5

[root@centos ~]$ cat /etc/httpd/conf.d/userdir.conf

    UserDir enabled
    UserDir public_html



    AllowOverride FileInfo AuthConfig Limit Indexes
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    Require method GET POST OPTIONS


[root@centos ~]#

Nun kann ein Benutzer in seinem HOME-Verzeichnis den Ordner public_html erstellen und eine test.txt-Datei erstellen:

[jkastning@centos ~]$ mkdir public_html
[jkastning@centos ~]$ sudo chmod 711 /home/jkastning/
[jkastning@centos ~]$ sudo chmod 755 public_html/
[jkastning@centos ~]$ vim public_html/test.txt

Hello User

Nach einem Neustart des Dienstes httpd sollte sich nun die Datei index.html aus dem Benutzerverzeichnis abrufen lassen. Statt dessen wird der Zugriff verweigert.

apache_userdir_forbidden

httpd_enable_homdirs –> off

In den Logdateien finden sich Hinweise, die auf SELinux als Ursache hindeuten.

[root@centos ~]# tail /var/log/audit/audit.log|grep AVC
type=AVC msg=audit(1480446615.354:844): avc:  denied  { getattr } for  pid=23150 comm="httpd" path="/home/jkastning/public_html/index.html" dev="sda1" ino=1052157 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file

[root@centos ~]# tail /var/log/messages | grep SELinux
Nov 29 20:10:44 centos setroubleshoot: SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html. For complete SELinux messages. run sealert -l 13419731-cedd-4433-abb7-b2e7715d5636

Um weitere Informationen zu erhalten, führen wir das Kommando aus /var/log/messages aus (Ausgabe gekürzt):

[root@centos ~]# sealert -l 13419731-cedd-4433-abb7-b2e7715d5636
SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html.

*****  Plugin catchall_boolean (24.7 confidence) suggests   ******************

If you want to allow httpd to enable homedirs
Then you must tell SELinux about this by enabling the 'httpd_enable_homedirs' boolean.
You can read 'None' man page for more details.
Do
setsebool -P httpd_enable_homedirs 1

In der obigen Ausgabe wird neben der Ursache auch gleich die Lösung mitgeliefert. Nach der Aktivierung des SELinux Boolean httpd_enable_homedirs kann der Inhalt der Datei index.html im Webbrowser abgerufen werden.

apache_userdir_allowed

httpd_enable_homedirs –> on

Damit wurde eine weitere Funktionalität von SELinux kurz vorgestellt. Für weiterführende Informationen sei auf die Manpages booleans(8)6, getsebool(8)7 und setsebool(8)8 verwiesen.

Einführung in das grundlegende Konzept von SELinux

SELinux1 (Security-Enhanced Linux; engl. „sicherheitsverbessertes Linux“) ist eine Erweiterung des Linux-Kernels, mit der eine zusätzliche Sicherheitsschicht in das Betriebssystem eingezogen wird.

In dieser Einführung wird das zu Grunde liegende Konzept kurz vorgestellt und erläutert, welche Modi SELinux besitzt, wie diese angezeigt und umgeschaltet werden können. An einem einfachen Beispiel mit dem Apache Webserver wird dargestellt, wie SELinux in der Praxis wirkt. Des Weiteren wird mit Hilfe des Beispiels das Vorgehen bei einer Fehleranalyse erläutert.

SELinux ist dazu gedacht, das bestehende Berechtigungskonzept unter Linux zu erweitern, um zu verhindern, dass kompromittierte Dienste auf Daten zugreifen, auf die kein Zugriff erforderlich ist.

Als einfaches Beispiel mag hier der Webserver Apache2 dienen.

Dieser liest die Dateien, welche er ausliefern soll, in der Standardkonfiguration aus dem dem Verzeichnis /var/www/html. Daneben darf der Dienst z.B. auch alle Verzeichnisse und Dateien unterhalb der Verzeichnisse /tmp und /var/tmp lesen.

user@host:~$ ls -ld /tmp
drwxrwxrwt. 5 root root 4096 Nov 27 19:05 /tmp
user@host:~$ ls -ld /var/tmp
drwxrwxrwt. 2 root root 4096 Nov 10 06:34 /var/tmp
user@host:~$

Grundsätzlich hat der Dienst Zugriff auf alle Verzeichnisse und Dateien, welche den Lese- bzw. Schreibzugriff für alle Benutzer erlauben.

SELinux kann nun dazu genutzt werden, um genau diesen Zugriff zu unterbinden. Die folgende Abbildung soll dies verdeutlichen:

selinux-example-apache

Mögliche Zugriffe mit und ohne SELinux am Beispiel des Apache

SELinux stellt einfach gesprochen ein Regelwerk dar, nach welchem bestimmt wird, auf welche Verzeichnisse, Dateien, Prozesse und Ports ein Dienst zugreifen darf. Dazu erhalten diese Objekte ein Label mit einem Security Context. Nur wenn das SELinux-Regelwerk den Zugriff von einer Ressource auf eine weitere Ressource explizit erlaubt, ist der Zugriff gestattet. Andernfalls wird die Interaktion unterbunden. Dabei unterscheidet SELinux die verschiedenen Label nach Kontexten. Diese sind:

  • user
  • role
  • type
  • sensitivity

Im Folgenden wird ausschließlich der Kontext „type“ weiter betrachtet. So besitzt z.B. der Dienst Apache das Label httpd_t, während Dateien unterhalb von /var/www/html das Label httpd_sys_content_t tragen. Da SELinux eine Regel besitzt, welche den Zugriff des Kontext httpd_t auf Dateien und Verzeichnisse mit dem Kontext httpd_sys_content_t gestattet, kann der Apache die Datei index.html aus dem Verzeichnis /var/www/html anzeigen:

output-index-html

Ausgabe der Datei /var/www/html/index.html

Obiger Screenshot enthält neben dem obligatorischen „Hallo Welt“ auch noch die Ausgabe des Verzeichnis-Listings, welches neben den üblichen Angaben wie Berechtigungen, Benutzer und Gruppe auch den SELinux-Kontext mit ausgibt. Wie man SELinux steuert und sich den Kontext von Verzeichnissen, Dateien und Prozessen anzeigen lässt, wird im Folgenden Abschnitt erläutert.

Steuerung von SELinux

SELinux kennt drei Modi:

  • Enforcing
  • Permissive
  • Disabled

In welchem Status sich SELinux befindet, kann mit dem Kommando getenforce abgefragt werden:

[root@centos ~]# getenforce
Enforcing
[root@centos ~]#

Obige Ausgabe bedeutet, dass SELinux im Modus „Enforcing“ ausgeführt wird. In diesem Modus verhindert SELinux Zugriffe, welche nicht explizit durch das Regelwerk erlaubt werden. Im Unterschied dazu werden diese Zugriffe im Modus „Permissive“ nicht verhindert, sie werden jedoch protokolliert. Dieser Modus eignet sich daher hervorragend, um das aktuelle Verhalten von Diensten zu analysieren und die Konfiguration ggf. anzupassen. Die Umschaltung zwischen den Modi „Enforcing“ und „Permissive“ kann zur Laufzeit erfolgen:

[root@centos ~]# getenforce
Enforcing
[root@centos ~]# setenforce 0
[root@centos ~]# getenforce
Permissive
[root@centos ~]# setenforce 1
[root@centos ~]# getenforce
Enforcing
[root@centos ~]#

Der Standard-Modus wird in der Datei /etc/selinux/config festgelegt.

Anzeige der SELinux-Kontexte

Der kleine Punkt (im Screenshot rot markiert) hinter den Berechtigungen zeigt an, dass ein SELinux-Kontext für eine Datei bzw. ein Verzeichnis existiert:

Der Punkt zeigt einen vorhandenen SELinux-Kontext an

Der Punkt zeigt einen vorhandenen SELinux-Kontext an

Welchen Kontext eine Datei bzw. ein Prozess besitzt, kann angezeigt werden, indem bekannte Kommandos mit der Option „-Z“ benutzt werden. Das folgende Listing zeigt einige Beispiele:

[root@centos ~]# ps -eZ | grep httpd
system_u:system_r:httpd_t:s0     2876 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2920 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2921 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2922 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2923 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2924 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2925 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     3152 ?        00:00:00 httpd
[root@centos ~]# ls -lisaZ /var/www/html/
total 12
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 .
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 ..
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
[root@centos ~]# ls -lisaZ /var/tmp
total 28
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       .
drwxr-xr-x. root root system_u:object_r:var_t:s0       ..
drwxr-xr-x. abrt abrt system_u:object_r:abrt_var_cache_t:s0 abrt
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-colord.service-MczkBW
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-cups.service-c3Aouq
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-httpd.service-oAqhlb
drwx------. root root system_u:object_r:tmp_t:s0       systemd-private-f844adcb52b14995b675d9aa065e925c-rtkit-daemon.service-xpSsO2
[root@centos ~]# ls -lisaZ /tmp |head -n4
total 96
drwxrwxrwt. root      root      system_u:object_r:tmp_t:s0       .
dr-xr-xr-x. root      root      system_u:object_r:root_t:s0      ..
-rw-r--r--. root      root      system_u:object_r:tmp_t:s0       anaconda.log
[root@centos ~]#

Die Datei index.html hat bei ihrer Erstellung im Verzeichnis /var/www/html automatisch den korrekten Kontext httpd_sys_content_t erhalten und kann daher im Webbrowser angezeigt werden. Wird eine Datei im Verzeichnis /tmp erstellt, erhält diese automatisch den Kontext user_tmp_t:

[root@centos ~]# echo 'TEST' > /tmp/test.txt
[root@centos ~]# ls -lisaZ /tmp/test.txt
-rw-r--r--. root root unconfined_u:object_r:user_tmp_t:s0 /tmp/test.txt
[root@centos ~]#

Was tun, wenn’s klemmt?

Um zu erläutern, wie man einem Fehler auf die Spur kommt, baue ich zuerst einen ein. Dazu verschiebe ich die im vorangegangenen Abschnitt erzeugte Datei in das DocumentRoot des Apache und versuche, diese im Browser aufzurufen.

forbidden

Forbidden

SELinux verhindert den Zugriff des Dienstes „httpd“ auf die Datei „text.txt“, da keine Regel existiert, welche den Zugriff vom Kontext httpd_t auf user_tmp_t explizit erlaubt. Doch wie kann man dies feststellen, wenn man nicht bereits zu Beginn um den falschen Kontext weiß?

Zuerst wirft man einen Blick auf die Dateiberechtigungen, welche aber keinen Fehler erkennen lassen:

[root@centos ~]# ls -lZ /var/www/html/
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
-rw-r--r--. root root unconfined_u:object_r:user_tmp_t:s0 test.txt
[root@centos ~]#

Da die Dateiberechtigungen als Fehlerquelle ausscheiden und in diesem Beispiel keine POSIX-ACL3 verwendet werden, bleibt nur noch SELinux als Fehlerquelle übrig. Daher suchen wir einmal in /var/log/audit/audit.log nach Ereignissen vom Typ „AVC“:

[root@centos ~]# tail /var/log/audit/audit.log | grep AVC
type=AVC msg=audit(1480277043.225:537): avc:  denied  { open } for  pid=2922 comm="httpd" path="/var/www/html/test.txt" dev="sda1" ino=924457 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file

Treffer! Um die Sache weiter zu analysieren, untersuchen wir als nächstes /var/log/messages (Ausgabe gekürzt):

Nov 27 21:29:13 centos setroubleshoot: SELinux is preventing /usr/sbin/httpd from open access on the file /var/www/html/test.txt. For complete SELinux messages. run sealert -l 7a6417b8-06e2-4499-8f0f-ed0bb16f2b2a

Hier findet sich eine Bestätigung, dass SELinux den Zugriff blockiert hat und ein Vorschlag, wie dieser Vorfall genauer analysiert werden kann. Damit lassen sich umfassende Informationen abrufen, welche sogar die Lösung mit ausgeben (Ausgabe gekürzt):

[root@centos ~]$ sealert -l 7a6417b8-06e2-4499-8f0f-ed0bb16f2b2a
SELinux is preventing /usr/sbin/httpd from open access on the file /var/www/html/test.txt.

*****  Plugin restorecon (92.2 confidence) suggests   ************************

If you want to fix the label. 
/var/www/html/test.txt default label should be httpd_sys_content_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/www/html/test.txt

*****

Der Bericht gibt an, wie das Standard-Label für die Datei text.txt gesetzt sein sollte. Darüber hinaus ist dem Bericht der Befehl zu entnehmen, mit dem die Label wieder auf den Standardwert zurückgesetzt werden können. Nachdem dieser Befehl ausgeführt wurde, kann die Datei text.txt im Webbrowser geöffnet werden.

[root@centos ~]# /sbin/restorecon -v /var/www/html/test.txt
/sbin/restorecon reset /var/www/html/test.txt context unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0
[root@centos ~]#
correct-selinux-context

Aufruf von test.txt mit korrektem SELinux-Kontext

Schlusswort

Es wurde in das grundlegende Konzept von SELinux und die möglichen Betriebsmodi eingeführt. Darüber hinaus wurde erläutert, wie man sich die zu einem Objekt gehörenden SELinux-Kontexte anzeigen lassen kann und wie diese auf einen Standard-Kontext zurückgesetzt werden können. Abschließend wurde ein kleiner Einblick in das Vorgehen zur Fehleranalyse gegeben.

Damit bin ich am Ende dieser kleinen Einführung angekommen, wobei das Thema SELinux damit noch lange nicht abschließend behandelt ist. Für weiterführende Informationen sei an dieser Stelle auf die Dokumentation der einzelnen Distributionen verwiesen.4 5 6

Quellen und weiterführende Links

Datenpanne im Internet – Bin ich betroffen?

Sie passieren ständig – Datenpannen1 im Internet. Und die Abstände zwischen ihnen werden gefühlt immer kürzer. In diesem Artikel möchte ich euch einen Weg aufzeigen, wie ihr selbst schnell und einfach feststellen könnt, ob ihr selbst von einer Datenpanne betroffen seid. Im Gegensatz zu vielen anderen Artikeln auf diesem Blog versuche ich dabei auf technische Details so weit wie möglich zu verzichten, um den Artikel allgemeinverständlich zu gestalten.

Datenpannen sind Verstöße, gegen die Datensicherheit und den Datenschutz, bei denen Staatsgeheimnisse, Betriebsgeheimnisse oder personenbezogene Daten Unberechtigten vermutlich oder erwiesenermaßen bekannt geworden sind. – Quelle: Deutschsprachige Wikipedia: Datenpanne

Und Datenpannen können überall passieren. Im Online-Shop, dem Online-Auktionsportal, im Online-Banking, in Tauschbörsen, in sozialen Netzwerken und auch im Cloud-Speicher-Dienst, dem wir unsere Dateien anvertrauen. Wikipedia listet einige bedeutende Vorfälle2, die in den vergangenen Jahren bekannt wurden.

Doch wie kann man nun überprüfen, ob man selbst von einer solchen Panne betroffen ist? Eine erfreulich einfache Möglichkeit bietet die Webseite https://haveibeenpwned.com/.3 4

https://haveibeenpwned.com

https://haveibeenpwned.com – Prüfe, ob einer deiner Accounts durch eine Datenpanne kompromittiert wurde.

Die Bedienung der Seite ist, wie bereits erwähnt, erfreulich einfach. Man trägt den zu überprüfenden Benutzernamen bzw. E-Mail-Adresse in das Suchfeld ein und startet die Suche. Das Ergebnis gibt Auskunft darüber, ob der Benutzername bzw. die E-Mail-Adresse von einer Datenpanne betroffen ist und bei welchem Dienst die Informationen stammen. Die folgenden beiden Screenshots zeigen zwei Beispiele. Das erste Beispiel zeigt einen Fall, bei dem die Kompromittierung eines Benutzernamens bis heute nicht bekannt geworden ist. Das zweite Beispiel zeigt die Abfrage einer E-Mail-Adresse, die mit anderen Daten bei einem Datenleck beim Cloud-Speicheranbieter Dropbox abgegriffen wurden.

username-not-compromised

Keine Kompromittierung des Benutzernamens bekannt

compromised-mailaddress

Die kompromittierte E-Mail-Adresse stammt aus einem Datenleck bei Dropbox

Neben der manuellen Überprüfung bietet die Webseite auch die Möglichkeit, eine E-Mail-Adresse zu hinterlegen. Taucht diese E-Mail-Adresse in einem öffentlich bekannt gewordenen Datenbestand auf, erhält man hierüber eine Nachricht an die hinterlegte E-Mail-Adresse.

Was tun, wenn ich betroffen bin?

Stellt man nun fest, dass die geprüften Benutzerdaten kompromittiert sind, sollte man umgehend handeln. Es ist dringend empfohlen, in diesem Fall

  1. die Zugangsdaten (Benutzername, E-Mail-Adressse, Passwort) beim betroffenen Dienst zu ändern.
  2. die Zugangsdaten (Benutzername, E-Mail-Adressse, Passwort) bei allen sonstigen Diensten zu ändern, bei denen die gleichen Zugangsdaten verwendet wurden.

Mit dem zweiten Schritt soll sichergestellt werden, dass mit den kompromittierten Benutzerinformationen noch weitere Benutzerkonten bei anderen Online-Diensten gekapert werden können.

Um den Umgang und die Verwaltung von Benutzernamen und Passwörtern so komfortabel wie möglich zu gestalten, empfehle ich die Verwendung eines Passwortmanagers wie z.B. KeePass.5 6 7

Der eigene Mailserver – Teil 3

Es ist Zeit für Teil 3 dieser kleinen Artikelreihe. In diesem Teil wird der Server einsatzbereit gemacht. Dazu sind im Wesentlichen die folgenden sechs Aufgaben zu erledigen.

Es gibt wieder viel zu tun. Also legen wir los.

Haben wir nicht was vergessen?

Wie ist es denn um den Update-Status des eigenen Servers bestellt? Evtl. ist jetzt eine gute Gelegenheit das System auf Updates zu prüfen und diese einzuspielen. Doch muss dies nicht manuell passieren.

In „Automatische Installation von Sicherheitsupdates“ erkläre ich, wie man die Update-Installation unter Ubuntu automatisieren kann. Exkurs Ende.

OpenDKIM

OpenDKIM soll Mailservern dabei helfen die Authentizität und die Integrität von eingehenden E-Mails zu überprüfen.

Versendet ein Mailserver eine E-Mail mit OpenDKIM, so bildet der Server einen Hashwert über den Inhalt der E-Mail. Dieser Hashwert wird mit einem privaten Schlüssel verschlüsselt und im Header der E-Mail gespeichert. Der empfangende Mailserver fragt über DNS einen speziellen TXT-Record ab, welcher das öffentliche Gegenstück zum privaten Schlüssel enthält, mit welchem der Hash verschlüsselt wurde. Der empfangende Mailserver nutzt diesen öffentlichen Schlüssel, um den Hashwert der Nachricht zu entschlüsseln. Abschließend bildet der Mailserver selbst den Hashwert der empfangenen E-Mail und vergleicht ihn mit dem soeben entschlüsselten Hashwert aus dem Mailheader. Stimmen beide Hashwerte überein, kann man mit hinreichender Sicherheit davon ausgehen, dass die E-Mail von einem autorisierten Absender stammt und unterwegs nicht verändert wurde.

Für die einzelnen Schritte in diesem Teil werden wieder root-Rechte benötigt. Entweder man öffnet eine root-Shell oder stellt den folgenden Befehlen ein sudo voran.

Als erstes wird das Paket OpenDKIM installiert.

:~$ sudo apt-get install opendkim opendkim-tools

Das OpenDKIM Paket richtet bei der Installation automatisch die benötigten Benutzerkonten und Upstart Jobs ein. Es muss nur noch ein Verzeichnis erstellt werden, in dem die Konfigurationsdateien und der private Schlüssel gespeichert werden. Der Zugriff auf dieses Verzeichnis wird auf den Benutzer und die Gruppe von opendkim beschränkt.

mkdir /etc/opendkim
chown opendkim:opendkim /etc/opendkim

Im nächsten Schritt wird im soeben erstellen Verzeichnis ein DKIM Schlüsselpaar erstellt.

cd /etc/opendkim
opendkim-genkey -r -h sha256 -d domainname.tld -s mail

Mit dem Parameter -r schränkt man das erstellte Schlüsselpaar in der Art ein, dass es nur zur Signatur von E-Mails verwendet werden kann. Die Angabe des Hash-Algorithmus sollte selbsterklärend sein. Der Parameter -d spezifiziert die Domain und -s gibt den Selektor an.4 Das Kommando gibt die beiden Dateien mail.private und mail.txt aus. Letztere enthält den öffentlichen Schlüssel in Form eines DNS TXT Records. Dies macht es einfach, den benötigten DNS Eintrag auf dem DNS Server hinzuzufügen. Ich komme in Kürze darauf zurück.

Die Datei mail.private wird in mail umbenannt. Anschließend wird festgelegt, welche Dienste den Schlüssel zur Signatur von Mails nutzen dürfen. Aber ein Schritt nach dem Anderen.

Zuerst wird die Datei umbenannt:

mv mail.private mail

Anschließend wird die Datei /etc/opendkim/KeyTable angelegt und mit Inhalt nach folgendem Muster befüllt:

domainname.tld domainname.tld:mail:/etc/opendkim/mail

Hier wird domainname.tld mit dem privaten Schlüssel für diese Domain verknüpft. Hat man mehrere Domains und Schlüssel, werden diese nach dem gleichen Muster hier eingetragen.

Als nächstes wird die Datei /etc/opendkim/SigningTable erstellt und mit folgendem Inhalt gefüllt:

*@domainname.tld domainname.tld

Dieser Eintrag weist OpenDKIM an, alle E-Mails von allen Adressen, die auf @domainname.tld enden, mit der Signatur von mail.domainname.tld zu versehen. Auch hier lassen sich ganz einfach weitere Domains hinzufügen.

Als letzte Datei wird die Datei /etc/opendkim/TrustedHosts erstellt, welche lediglich eine lokale IP-Adresse enthält:

127.0.0.1
::1

Diese Datei gibt an, welche Server Mails signieren dürfen und welche Server signierte Mails versenden dürfen, ohne Benutzeranmeldedaten zu übermitteln.

Damit nur OpenDKIM auf die Dateien unterhalb von /etc/opendkim zugreifen kann, wird der Zugriff noch entsprechend eingeschränkt:

chown -R opendkim:opendkim /etc/opendkim

Jetzt kann es der Konfigurationsdatei /etc/opendkim.conf an den Kragen gehen. An das Ende der Datei wird der folgende Inhalt angehängt:

## Benutzerspezifische OpenDKIM Konfiguration
Canonicalization        relaxed/relaxed
ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts
KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable
LogWhy                  Yes
PidFile                 /var/run/opendkim/opendkim.pid
Socket                  local:/var/spool/postfix/opendkim/opendkim.sock
SyslogSuccess           Yes
TemporaryDirectory      /var/tmp
UserID                  opendkim:opendkim

Da das Verzeichnis für den Socket noch nicht existiert, wird es jetzt angelegt und mit den entsprechenden Berechtigungen versehen.

mkdir /var/spool/postfix/opendkim
chown opendkim:root /var/spool/postfix/opendkim

Damit die Konfiguration wirksam wird, muss der Dienst einmal neugestartet werden:

service opendkim restart

Damit Postfix über den Socket mit OpenDKIM kommunizieren kann, fügt man den Benutzer Postfix der OpenDKIM Gruppe hinzu.

usermod -G opendkim postfix

Damit ist die erste Aufgabe für diesen Teil erledigt. Bevor wir OpenDKIM endgültig mit Postfix verbinden, wenden wir uns einem anderen Schlachtfeld zu.

Der ewige Kampf gegen den Spam…

…beginnt an dieser Stelle mit der Installation des milters und der Pakete, die benötigt werden, damit Spamassassin mit den DKIM Headers zusammenarbeitet.

sudo apt-get install spamass-milter pyzor razor libmail-dkim-perl

Es gibt mehrere Wege, SpamAssassin zu konfigurieren und zu nutzen. Der einfachste wäre alle Dienstfunktionalitäten zu ignorieren und Postfix die Mails einfach an SpamAssassin weiterleiten zu lassen, bevor diese an Dovecot geleitet werden. Doch dieser Weg führt zur dunklen Seite der Macht.

Ich möchte, dass Postfix die E-Mails über einen Unix-Socket an spamd zur Überprüfung gibt. spamd läuft im Hintergrund und wartet auf die Mails von Postfix. Dies ist schneller und ressourcenschonender. Denn es muss nicht für jede eintreffende E-Mail ein SpamAssassin Prozess gestartet werden.

In der Standardkonfiguration legt spamass-milter für jedes Postfach eine eigene AntiSpam-Datenbank an. Ob man dies möchte, hängt vom Einsatzzweck des jeweiligen Servers ab. Ich persönlich plane den Server für meine eigenen Domains und meine eigenen Postfächer zu nutzen. Daher werde ich es mit einer globalen Konfiguration versuchen, die für alle Postfächer gilt.

Benutzerkonten und Konfigurationsdateien

Bevor die Betriebsbereitschaft hergestellt werden kann, muss noch ein System-Benutzer für den Dienst spamd erzeugt und der Benutzer spamass-milter der spamd Benutzergruppe hinzugefügt werden.

addgroup --system spamd
adduser --system --home /var/lib/spamassassin --ingroup spamd spamd
usermod -a -G spamd spamass-milter

Fertig, nun werden erstmal ein paar Konfigurationsdateien gehackt.

Zu Beginn ist /etc/default/spamassassin dran. Nach der Bearbeitung sollte die Datei wie folgt aussehen:

SAHOME="/var/lib/spamassassin"
SAGLOBALCFGPATH="/etc/spamassassin"
 
# Change to one to enable spamd
ENABLED=1
 
# Options
# See man spamd for possible options. The -d option is automatically added.
OPTIONS="-x --max-children 5 --helper-home-dir ${SAHOME} -u spamd -g spamd --siteconfigpath ${SAGLOBALCFGPATH} --socketpath=/var/spool/postfix/spamassassin/spamd.sock --socketowner=spamd --socketgroup=spamd --socketmode=0660"
 
# Pid file
# Where should spamd write its PID to file? If you use the -u or
# --username option above, this needs to be writable by that user.
# Otherwise, the init script will not be able to shut spamd down.
PIDFILE="/var/run/spamd.pid"
 
# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin's rules on a nightly basis
CRON=1

Die ersten beiden Zeilen enthalten Variablen, die das SpamAssassin Home-Verzeichnis und das Verzeichnis mit der globalen Konfiguration beinhalten. Als nächstes wird der spamd Daemon aktiviert. OPTIONS enthält einen ganzen Blumenstrauß an Parametern. Hier wird festgelegt, dass nur eine Konfigurationsdatei für alle Benutzer verwendet wird. Die UID und GID, unter denen SpamAssassin ausgeführt werden soll, werden festgelegt. Der Pfad zur globalen Konfigurationsdatei wird angegeben, usw. usf. Am Ende wird noch das automatische Policyupdate aktiviert. Für weitere Erläuterungen dieser Datei verweise ich auf die Projektseite2, welche unter den Quellen verlinkt ist.

Das Verzeichnis für den Socket wird manuell erstellt und die entsprechenden Benutzerrechte vergeben:

mkdir /var/spool/postfix/spamassassin
chown spamd:root /var/spool/postfix/spamassassin/

Speichern und schließen! Jetzt geht es mit /etc/default/spamass-milter weiter. Diese Datei enthält nur eine einzige Zeile, die nach der Bearbeitung wie folgt aussehen sollte.

OPTIONS="-u spamass-milter -i 127.0.0.1 -m -I -- --socket=/var/spool/postfix/spamassassin/spamd.sock"

Die Option „-u“ definiert, unter welchem Benutzerkontext der Milter ausgeführt wird. „-i“ gibt die Quell-IPs der Systeme an, deren Mails der Milter ignorieren soll. „-I“ ignoriert E-Mails von authentifizierten SMTP-Sendern. „-m“ hält SpamAssassin davon ab, sich zu sehr mit den Mail-Headern zu beschäftigen. Der Rest der Zeile gibt an, wohin der Milter die Mails zum Scannen leiten soll. Hier wird der Socket angegeben, der im letzten Schritt erstellt wurde.

Speichern, schließen, nächster!

An die Datei /etc/spamassassin/init.pre werden die beiden folgenden Zeilen angefügt:

## Add TextCat to assist enable language-based filtering
loadplugin Mail::SpamAssassin::Plugin::TextCat

Die beiden Zeilen bewirken, dass das TextCat-Plugin geladen wird, welches wir in der folgenden Konfigurationsdatei verwenden.

In der Datei /etc/spamassassin/local.cf wird direkt unterhalb des ersten Kommentars der folgende Code eingefügt:

## Force global Bayesian databases instead of per-user
bayes_path /var/lib/spamassassin/.spamassassin/bayes
bayes_file_mode 0777
 
## Ensure non-English and non-German e-mails are treated as spam
ok_languages en de
ok_locales en
 
## Set Pyzor and Razor config file paths
razor_config /etc/razor/razor-agent.conf
pyzor_options --homedir /var/lib/spamassassin/.pyzor

Zu Beginn wird festgelegt, wo die Datenbank für den Bayesian-Filter liegt.

Die nächsten beiden Optionen geben an, in welcher Sprache und welchem Zeichensatz eine E-Mail entsprechen muss, um nicht als Spam aussortiert zu werden. Die aktuelle Einstellung erlaubt E-Mails in englischer so wie deutscher Sprache und westlichem Zeichensatz. Eine vollständige Liste der untestützten Sprachen gibt es in der TextCat Dokumentation6, die verfügbaren Zeichensätze sind in der SpamAssassin Dokumentation für Konfigurationsdateien7 zu finden.

Auf die letzten beiden Zeilen werde ich in Kürze noch eingehen.

Wann immer man an den Konfigurationsdateien von SpamAssassin herumgemacht hat, ist es eine gute Idee, die Konfiguration mit folgendem Befehl auf Fehler zu überprüfen.

spamassassin --lint

Liefert das Kommando keine Ausgabe zurück, ist alles in Ordnung.

Zum Start werden einmal die aktuellen SpamAssassin-Regeln mit dem Kommando sa-update abgerufen. In Zukunft passiert dies automatisch.

sa-update
chown -R spamd:spamd /var/lib/spamassassin

Nun werden noch das Verzeichnis für den Socket angelegt, die Benutzerrechte korrigiert und die beiden Dienste neugestartet. Anschließend kann es schon zum nächsten Schritt weitergehen.

chown spamd:spamd /var/lib/spamassassin/.spamassassin
service spamassassin restart
service spamass-milter restart

Razor2 und Pyzor

Razor2 und Pyzor sind zwei Add-Ons für SpamAssassin. Sie erweitern die Fähigkeit Spam auszusortieren, indem auf zwei AntiSpam-Datenbanken zurückgegriffen wird, die ständig erweitert werden. Einmal eingerichtet, muss man sich nicht weiter um die beiden kümmern.

Zuerst werden die benötigten Verzeichnisse angelegt:

mkdir /var/lib/spamassassin/.razor
mkdir /var/lib/spamassassin/.pyzor

Laut der Dokumentation8 braucht es nur ein Kommando, um Pyzor in Gefechtsbereitschaft zu versetzen.

pyzor --homedir /var/lib/spamassassin/.pyzor discover

Um Razor in Gefechtsbereitschaft zu versetzen, bedarf es nur weniger Kommandos mehr:

razor-admin -home=/var/lib/spamassassin/.razor -register
razor-admin -home=/var/lib/spamassassin/.razor -create
razor-admin -home=/var/lib/spamassassin/.razor -discover

Der Datei /var/lib/spamassassin/.razor/razor-agent.conf ist folgende Zeile hinzuzufügen:

razorhome = /var/lib/spamassassin/.razor

Das wars…fast…noch zwei Kommandos und SpamAssassin ist klar zum Gefecht.

chown -R spamd:spamd /var/lib/spamassassin
service spamassassin restart
service spamass-milter restart

Training für SpamAssassin

Die Filter von SpamAssassin lernen selbstständig. Doch kann man den Lernprozess durch aktives Training unterstützen. Dazu lässt man eine gewisse Menge an E-Mails durch das Hilfsprogramm sa-learn analysieren.

Hat man z.B. nur solche E-Mails im Posteingang, bei denen es sich ganz sicher nicht um Spam handelt, kann man SpamAssassin wie folgt darauf trainieren, dass es sich dabei nicht um Spam handelt:

sa-learn --ham /path/to/your/inbox/on/the/server --progress

Genau so gut funktioniert das andersherum. Hat man einen Ordner, der ausschließlich Spam-Mails enthält, kann man den Filter wie folgt trainieren:

sa-learn --spam /path/to/directory/of/spam --progress

Der Trainingsprozess ist am effektivsten, wenn man ca. je 1.000 Nachrichten Spam und echte E-Mail hat. Der Filter wird sogar erst dann aktiv genutzt, wenn sich mindestens 200 Spam-Mails in der Datenbank befinden. Das Training kann man beschleunigen, indem man Mails aus seinem Google-Postfach mit Hilfe von Google exportiert, in ein Verzeichnis auf dem Server entpackt und das Trainingsprogramm auf dieses Verzeichnis anwendet.9 Führt man das Lernprogramm als root aus, muss man anschließend sicherstellen, dass alle Dateien in /var/lib/spamassassin/.spamassassin dem Benutzer spamd gehören.

Falls man SpamAssassin versehentlich mal falsch angelernt hat, kann man dies auch wieder rückgängig machen, in dem man das oben genannte Kommando mit der Option –forget auf die betroffene Menge Nachrichten anwendet.

ClamAV

Mit ClamAV wird ein Virenscanner in Stellung gebracht, der E-Mails und Anhänge auf Schädlingsbefall hin untersucht. Damit ClamAV die die E-Mail-Anhänge auch auf Virusbefall untersuchen kann, werden neben dem Milter auch noch eine ganze Reihe an Dekomprimierungsprogrammen installiert.

apt-get install clamav-milter arj bzip2 cabextract cpio file gzip lha lzop nomarch p7zip pax rar rpm unrar unzip zip zoo

Nach der Installation sind Änderungen an der Konfigurationsdatei /etc/clamav/clamav-milter.conf vorzunehmen. Die folgenden Zeilen sind auszukommentieren und durch die Zeilen im zweiten Codeblock zu ersetzen.

MilterSocket /var/run/clamav/clamav-milter.ctl
...
OnInfected Quarantine 
...
LogFacility LOG_LOCAL6
MilterSocket /var/spool/postfix/clamav/clamav-milter.ctl
...
OnInfected Accept 
...
LogFacility LOG_MAIL

Die erste Option gibt an, wo der Socket erstellt wird, der auf E-Mails von Postfix wartet. Da wie bei allen anderen Miltern auch der Socket innerhalb des Postfix chroot jail liegen muss, legt man das Verzeichnis für den Socket wie folgt an und setzt die Benutzerrechte entsprechend.

mkdir /var/spool/postfix/clamav
chown clamav:root /var/spool/postfix/clamav/

Die nächste Option erlaubt es, Nachrichten mit infiziertem Inhalt weiterzuleiten, statt sie in Postfix Warteschlange zu belassen. Denn um diese soll sich später Sieve kümmern. Zum Schluss wird ClamAV angewiesen, das Log von Postfix zu verwenden, um bei Problemen nur an einer Stelle suchen zu müssen.

Nun wird noch die Zeile

SOCKET_RWGROUP=postfix

in der Datei /etc/default/clamav-milter einkommentiert. Jetzt ist es Zeit für einen Neustart.

service clamav-daemon restart
service clamav-milter restart

ClamAV beinhaltet freshclam, um automatisch die Virusdefinitionen zu aktualisieren. Zum Abschluss sollte man sich vergewissern, dass der Updatemechanismus korrekt funktioniert. In der Logdatei /var/log/clamav/freshclam.log sollte in etwa folgende Ausgabe zu finden sein:

--------------------------------------
freshclam daemon 0.97.8 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
ClamAV update process started at Sun Mar 16 18:32:49 2014
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.97.8 Recommended version: 0.98.1
DON'T PANIC! Read http://www.clamav.net/support/faq
Downloading main.cvd [100%]
main.cvd updated (version: 55, sigs: 2424225, f-level: 60, builder: neo)
Downloading daily.cvd [100%]
daily.cvd updated (version: 18609, sigs: 824724, f-level: 63, builder: neo)
Downloading bytecode.cvd [100%]
bytecode.cvd updated (version: 236, sigs: 43, f-level: 63, builder: dgoddard)
Database updated (3248992 signatures) from db.local.clamav.net (IP: 207.57.106.31)
--------------------------------------

Nach der Konfiguration der ganzen Milter ist es jetzt noch nötig, diese in Postfix zu aktivieren. Dazu sind folgende Zeilen in der Datei /etc/postfix/main.cf einzukommentieren und die Konfiguration neu zu laden.

milter_default_action = accept
milter_connect_macros = j {daemon_name} v {if_name} _
non_smtpd_milters = $smtpd_milters
smtpd_milters = unix:/spamass/spamass.sock unix:/clamav/clamav-milter.ctl unix:/opendkim/opendkim.sock
service postfix reload

DNS Konfiguration

Ohne DNS funktioniert kein E-Mailsystem. Damit der Mailserver erreichbar ist, muss im DNS-Manager des eigenen Domainproviders ein MX-Record angelegt werden, welcher auf die öffentliche IP-Adresse oder einen A-Record des eigenen Mailservers zeigt.

Wie genau man einen DNS-Eintrag für die eigene Domain erstellt, ist von Anbieter zu Anbieter unterschiedlich. Zieht dazu am besten die Anleitung bzw. Hilfe eures Anbieters zu Rate. Ich werde am Ende dieses Abschnitts beispielhaft noch ein Bild meines DNS-Providers einfügen.

Als Nächstes wird noch ein TXT-Eintrag benötigt, welcher den öffentlichen DKIM Schlüssel beinhaltet. Dazu kann der Inhalt der Datei /etc/opendkim/mail.txt verwendet werden. Bitte zieht im Zweifel auch hierbei die Hilfe eures DNS-Anbieters zu Rate. Dort sollte beschrieben werden, wie ihr diesen Eintrag am besten erstellt.

Es folgt noch der Eintrag für die Funktionalität des SPF.

dns configuration

Beispielhafte DNS-Konfiguration im Interface von Goneo.

Im obigen Bild sind insgesamt 5 DNS Einträge zu sehen. Bei den ersten beiden Einträgen handelt es sich um einen A-Record für IPv4 und einen AAAA-Record für IPv6. Mit diesen Einträgen wird den IP-Adressen ein Name zugeordnet. Diese beiden Einträge sind nicht zwingend notwendig, man kann sich einen Namen jedoch leichter merken als eine IP-Adresse. In der dritten Zeile sieht man den MX-Record. Dieser gibt Auskunft darüber, welcher Server für die E-Mails einer Domain zuständig ist. Existiert für die Domain kein A-Record, muss hier eine IP-Adresse angegeben werden. Andernfalls kann man, wie in diesem Beispiel, auch einen Namen verwenden.

In Zeile 4 steht der TXT-Eintrag für das Sender Policy Framework (SPF)10 Hier wird festgelegt, welche Server E-Mails für die genannte Domain versenden dürfen.

Und in der letzten Tabellenzeile steht der Eintrag, welcher den öffentlichen DKIM-Schlüssel enthält. Der Name des Eintrags wird dabei nach dem Muster <selector>._domainkey.<domainname.tld> gebildet. Als Wert wird der öffentliche Schlüssel verwendet. Damit kann ein fremder Mailserver die Signatur der E-Mails überprüfen, die von dem eigenen Mailserver versendet werden.

Ein sehr wichtiger Schritt in der DNS Konfiguration fehlt jedoch noch. Es sollte unbedingt noch ein passender PTR-Record konfiguriert werden, welcher ein Reverse-Lookup der IP-Adresse des Servers erlaubt. Fast alle E-Mail-Server versuchen, mit einem Reverse-Lookup die IP-Adresse eines Servers in einen DNS Namen aufzulösen. Entspricht der aufgelöste Name nicht dem Namen aus dem Forward-Lookup, werden die meisten Mailserver die eingehende E-Mail abweisen. Dies ist eine übliche Vorgehensweise, um den Versand von Spam einzudämmen. Denn Spam wird oft von gekaperten Maschinen versendet, oder von Servern, wo sich der Spammer nicht die Mühe macht, den PTR korrekt zu konfigurieren.

dns-reverse

PTR-Einträge für IPv4 und IPv6

Der Screenshot zeigt einen Ausschnitt aus dem DNS-Konfigurationstool von Strato. Es zeigt zwei PTR-Einträge. Jeweils einen für IPv4 und einen für IPv6.

Konsultiert die Hilfe oder den Support eures Anbieters, wenn sich das Menü mit den entsprechenden Konfigurationsmöglichkeiten nicht auf Anhieb finden lässt.

Angeblich gibt es auch noch Hosting-Provider, die ihren Kunden das Recht vorenthalten, einen PTR-Eintrag zu setzen. In diesem Fall kann man sich entweder damit abfinden, dass es mit dem eigenen E-Mailserver nichts mehr wird, oder man wechselt den Hosting-Provider.

Mit E-Mail Filtern gegen Spam

Wir sind nun im letzten Abschnitt von Teil 3 dieser Artikelreihe angelangt. Zum Abschluss kommt die Konfiguration von Sieve, welcher zwei Dinge erledigen soll:

  1. E-Mails filtern, die von SpamAssassin als Spam markiert wurden.
  2. E-Mails filtern, die von ClamAV als virusinfiziert markiert wurden.

Sieve Filter finden sich an mehreren Stellen. Jeder virtuelle Benutzer kann eigene Filter im virtuellen E-Mail Home-Verzeichnis haben (das ist /var/mail/vmail/domainname/Benutzername/sieve). Global definierte Filter befinden sich in /var/mail/vmail/sieve-before und /var/mail/vmail/sive-after. Die Filterregeln in sieve-before werden vor den benutzerdefinierten Filtern angewendet, die in sieve-after nach diesen.

Ich erstelle einen ersten Filter im Verzeichnis /var/mail/vmail/sieve-before, indem ich die Datei masterfilter.sieve erstelle und mit folgendem Inhalt fülle:

# cat masterfilter.sieve 
require ["envelope", "fileinto", "imap4flags", "regex"];
 
# I don't even want to see spam higher than level 10
if header :contains "X-Spam-Level" "**********" {
    discard;
    stop;
}
 
# Twitter? Die in a fire.
if anyof (envelope "From" "bounce@tweet.twitter.com",
          envelope :contains "From" "@bounce.twitter.com") {
    discard;
    stop;
}
 
# Trash messages with improperly formed message IDs
if not header :regex "message-id" ".*@.*\\." {
    discard;
    stop;
}
 
# File low-level spam in spam bucket, and viruses in Infected folder
if anyof (header :contains "X-Spam-Level" "*****",
          header :contains "X-Virus-Status" "Infected") {
    if header :contains "X-Spam-Level" "*****" {
        fileinto "Junk";
        setflag "\\Seen";
    }
    else {
        fileinto "Infected";
    }
}

Sieve wendet die Filter sequentiell von oben nach unten an. Es spielt daher eine große Rolle, an welcher Stelle eine Filterregel erstellt wird.

Der erste Filter wertet das Spam-Scoring aus, welches von SpamAssassin durchgeführt und in den Header der E-Mails eingefügt wird. Dazu prüft der Filter das Feld „X-Spam-Level“ im Header einer E-Mail. Finden sich hier wenigstens zehn „*“, lässt Sieve die E-Mail verschwinden. Die Aktion wird in /var/log/mail.log protokolliert, doch nirgendwo sonst wird man etwas von dieser E-Mail zu Gesicht bekommen. Die Option stop sorgt dafür, dass die übrigen Mailfilter nicht mehr ausgewertet werden.

Der nächste Filter sortiert Twitter-Werbung aus. E-Mails zum Zurücksetzen des Passworts werden von diesem Filter nicht erfasst, da sie von einer anderen Absenderadresse kommen.

Darunter werden E-Mails abgefangen, die über keine gültige Message-ID verfügen. Dieser Filter nutzt reguläre Ausdrücke. In Sieve können reguläre Ausdrücke verwendet werden, die dem RFC 5228 entsprechen.11

Der letzte Filter funktioniert wie folgt. Er prüft, ob ein E-Mail Header entweder ein X-Spam-Level von 5 oder die Markierung „Infected“ enthält und verschiebt sie in den „Junk“-Ordner. E-Mails, die sowohl als Spam klassifiziert sind, als auch einen Virus enthalten, werden in den „Junk“-Ordner verschoben. Nur Mails, die nur einen Virus enthalten, aber nicht als Spam markiert sind, landen im Ordner „Infected“.

Sieve Filter sind extrem komplex. Es würde den Umfang dieser Artikelreihe sprengen, wenn ich versuche, sie allumfassend zu behandeln. Zum tieferen Verständnis empfehle ich die Quellen 1212, 1313 und 1414.

Die Datei masterfile.sieve wandeln wir in eine Binärdatei um. Dabei wird auch gleich eine Syntaxüberprüfung durchgeführt.

sievec masterfilter.sieve

Wird dieses Kommando als root ausgeführt, müssen die Besitzrechte wieder korrigiert werden.

chown vmail:vmail *.svbin

In Teil 4 dieser Artikelreihe werde ich noch darauf eingehen, wie man Sieve-Filter über das Webinterface von Roundcube erstellen kann, ohne sich in die Tiefen der RegEx-Syntax einarbeiten zu müssen.

Einrichtung eines E-Mail Clients (MUA)

Mit dem Ende dieses Artikels ist der Webserver bereits voll einsatzbereit und kann mit einem Mail User Agent genutzt werden. Dies ist ein guter Zeitpunkt, um ein Konto z.B. in Mozilla Thunderbird15 einzurichten, um die Konfiguration zu testen. Die folgenden Screenshots zeigen exemplarisch, wie ein Konto in Thunderbird hinzugefügt wird.

Wer an dieser Stelle bereits die Nase voll hat von den doch recht langen Artikeln, kann sich bereits entspannt zurücklehnen. Denn er betreibt einen für das Internet gewappneten MTA, MDA und MUA mit Anti-Spam und Anti-Virus Modulen.

Ich werde in Teil 4 noch weitergehen und Webmail einrichten, um die konfigurierten Postfächer auch über einen Webbrowser nutzen zu können. Teil 4 wird sich außerdem mit der Möglichkeit beschäftigen, eine zertifikatsbasierte Anmeldung zu konfigurieren.

Wenn ihr ebenfalls noch weitermachen möchtet, sehen wir uns in einer Woche. 😉

Auf dem Weg zur DE-Mail Adresse

Vor noch nicht allzu langer Zeit habe ich die De-Mail und den ePostbrief an dieser Stelle
als Rohrkrepierer bezeichnet. Doch habe ich die beiden Angebote nicht
aus den Augen verloren und beobachte gespannt die weitere Entwicklung.

Bisher habe ich in Erfahrung gebracht, dass der ePostbrief weiterhin kein Angebot bietet, welches dem De-Mail Gesetz entspricht. Via Twitter teilte mir die verantwortliche Stelle der Post jedoch mit, dass ein entsprechendes Angebot in Vorbereitung ist, welches sich aktuell in der Auditierungs- und Akkreditierungsphase befindet. Ich bleibe hier am Ball und warte wann der De-Mail Service der Post an den Start geht.

Etwas weiter bin ich bei der De-Mail. Hier habe ich heute die Identitätsprüfung für den De-Mail Dienst der Deutschen Telekom abgeschlossen. Ein kurzer Besuch im Telekom Shop genügte. Hier wurde das Ident-Formular ausgefüllt und mit einem gültigen Lichtbildausweis die Identität des Antragstellers verifiziert. Besitzt man schon den neuen Personalausweis kann die Registrierung und Identifizierung komplett online erfolgen.

Doch wofür braucht man die De-Mail nochmal? Die Antwort ist eigentlich ganz einfach. Die klassische E-Mail kann mit einer Postkarte verglichen werden. Jeder der sie in die Hände bekommt kann sie lesen. Auf das Internet übertragen bedeutet dies, dass jeder Server, den die Mail auf dem Weg zum Empfänger durchläuft, den Inhalt der Mail lesen und auch verändern kann. Bei der De-Mail hingegen soll dies durch den Einsatz einer Transportverschlüsselleung (TLS) verhindert werden. Damit soll die De-Mail so sicher sein wie ein klassischer Brief, dessen Integrität durch das Briefgeheimnis sichergestellt wird.

Nun halten einige die De-Mail für überflüssig. Schließlich gibt es bereits seit Jahren Verfahren zur E-Mail Verschlüsselung, die eine sichere und vertrauliche Kommunikation auch via E-Mail sicherstellen. Doch jeder, der bereits versucht hat die E-Mail Verschlüsselung der Generation unserer Eltern näher zu bringen wird zugeben, dass dies alles andere als leicht ist. Denken doch die meisten Menschen, wenn sie GnuPG hören, eher an eine neue Tierart aus Afrika, als an den GNU Privacy Guard. Die Usability ist furchtbar und nur IT-Spezialisten und echte Nerds greifen darauf zurück. Daher konnte sich die E-Mail Verschlüsselung bisher auch nur in Bereichen durchsetzen, wo die vertrauliche Kommunikation zwingend erforderlich ist.

De-Mail bietet hier eine echte Chance die sichere, rechtsverbindliche und vertrauliche Kommunikation über das Internet massentauglich zu machen.

Auch preislich ist der Dienst nicht unattraktiv. Bei der Telekom kostet die
Standard De-Mail nach der Ausschöpfung des Freikontingents nur 0,39€
brutto. Im Vergleich zum Porto von 0,58 € für einen Standardbrief schon
eine deutliche Ersparnis.

Ich bin jetzt jedenfalls für die De-Mail
gerüstet und hoffe, dass im Laufe des Jahres möglichst viele
öffentliche Einrichtungen und Unternehmen der Privatwirtschaft ebenfalls
die Möglichkeit schaffen, die Kommunikation via De-Mail abzuwickeln.
Denn nur wenn diese Institutionen mitziehen wird sich die De-Mail
durchsetzen können und einen echten Mehrwert bieten. Und so werde ich
skeptisch und gespannt die weitere Entwicklung der De-Mail beobachten.

Gesunder Menschenverstand vs. Bankingtrojaner 1:0

Zwar gelten die aktuell im Online-Banking eingesetzten TAN-Verfahren als hinreichend sicher, doch hält dies kriminelle Betrüger nicht davon ab einen neuen Versuch zu starten, um uns um unser Geld zu betrügen.

Ein neuer Trojaner namens Tatange fordert den Benutzer, eines infizierten Systems, beim Besuch einer Bankingwebsite auf, sich durch Eingabe einer mTAN zu authentifizieren. Bereits jetzt sollte man als Nutzer misstrauisch werden. Der Besuch und die bloße Betrachtung einer Webseite ist grundsätzlich möglich, ohne das man sich dazu anmelden muss.

Solltet ihr also eine solche Aufforderung auf eurer Online-Banking Seite erhalten, ist dies ein Indiz dass euer System evtl. mit Maleware versucht ist. In diesem Fall solltet ihr euer System mit einer aktualisierten Antivirussoftware überprüfen.

Die mTAN an sich erhält der Anwender, wie gewohnt per SMS. Die SMS enthält wie üblich Details zur Überweisung. Der Trojaner behauptet mit einer Meldung, dass es sich dabei um „experimentelle Daten“ handelt, die man ignorieren soll. Spätestens jetzt sollte der gesunde Menschenverstand Alarm schlagen. Von der Eingabe dieser mTAN sollte unbedingt abgesehen werden. Banken und Sparkassen fragen niemals nach einer TAN, ausser es soll eine Transaktion des Online-Bankings damit autorisiert werden.

In diesem Fall ist der Betrugsversuch so offensichtlich, dass ich mich Frage wie jemand auf diese Masche hereinfallen kann. Leider konnte ich noch keine Informationen recherchieren ob und wie viele Betrugsopfer es bisher in Deutschland gegeben hat.

Für mich ist klar, gegen diesen Trojaner schützt der gesunde Menschenverstand besser als jedes Antivirus Programm. Also bleibt wachsam. 😉

Studie – Sicherheitsmängel bei Cloud-Speicherdiensten

Gestern habe ich in einem Artikel auf Golem von einer Studie der Fraunhofer-Gesellschaft zu Sicherheitsmängeln bei Cloud-Speicherdiensten erfahren. Die Studie untersuchte die Cloud-Speicherdienste CloudMe, CrashPlan, Dropbox, Mozy, TeamDrive, Ubuntu One und Wuala.

Die Forscher betrachten die genannten Dienste dabei aus der Nutzer-, rechtlicher und technischer Sicht.

Wie schon im Artikel auf Golem zu lesen stellt keiner der betrachteten Dienste eine Out-of-the-Box Lösung dar. Wer seine Daten in der Cloud speichern möchte, sollte sich also vorher genau seine Anforderungen überlegen und danach einen entsprechenden Dienst auswählen.

Mögliche Kriterien können sein, ob die Daten verschlüsselt abgelegt werden, oder wo sie gespeichert werden. Werden Daten auf Servern in den USA gespeichert, so kann auf diese Daten im Rahmen des Patriot Act zugegriffen werden. Dies ist auch dann der Fall wenn es sich beim Diensteanbieter um ein US Unternehmen oder eine Tochter einer US Firma handelt. Auch in diesem Fall kann ein Zugriff auf die Daten erfolgen, selbst wenn diese ausschließlich auf Servern in der EU oder innerhalb Deutschlands gespeichert sind.

Die Studie gibt für jeden der oben genannten Dienste einen Überblick, der sich wie folgt gliedert. Es wird aufgeführt für welche Betriebssysteme der Dienst zur Verfügung steht und über welche Schnittstellen (Webinterface, API) darauf zugegriffen wird. Gefolgt wird dieses Kapitel von Informationen über Lizenz- und Preisinformationen, sowie der Informationen nach welchen Sicherheits-Standards ein Dienst zertifiziert wurde. Das sich anschließende Unterkapitel widmet sich den Features, welche pro Dienst beschrieben und zu den anderen betrachteten Diensten abgegrenzt werden. Abschließend wird pro Dienst die Sicherheit betrachtet. Hier wurden folgende Aspekte untersucht.

  • Registrierung und Login
  • Verschlüsselung
  • Übermittlung zwischen Client und Server
  • Sharing mit Teammitgliedern und Dritten
  • Update der Software

Insgesamt bietet die Studie einen detaillierten Blick auf die betrachteten Dienste. Darüber hinaus nennt sie generelle Anforderungen an Cloud-Speicherdienste und bietet Informationen, die bei der Auswahl eines Anbieters beachtet werden sollten.

Aus meiner Sicht sollte jeder Administrator, Projektleiter oder Geschäftsführer, welcher den Einsatz von Cloud-Speicherdiensten für sein Unternehmen oder seine Kunden in Erwägung zieht, diese Studie zur Kenntnis nehmen.

Die Studie kann auf der Seite sit.fraunhofer.de, in verschiedenen Formaten, heruntergeladen werden. Da sich der Link zur Studie in der Vergangenheit schon einmal geändert hat, habe ich die Studie am Ende dieses Artikels zum Download angehängt.

Wirklich jedem möchte ich anraten die Bedingungen eines Cloud-Speicheranbieters genau zu studieren, bevor er sich für einen Dienst entscheidet. Nur so lässt sich beurteilen, ob ein Dienst wirklich für den geplanten Einsatzzweck in Frage kommt. Hier stehen wichtige Details häufig erst auf der zweiten oder dritten Seite, oder sind tief in den FAQs versteckt.

Dateien zum Download

Den Computer einfach Schützen

Wieviel Aufwand zum Schutz den privaten PCs betrieben werden muss hängt natürlich immer von den persönlichen Anforderungen ab. Es gibt jedoch Schutzmaßnahmen, die jeder treffen sollte.

Dieser Artikel nennt die 10 wichtigsten Tipps, die man für ungetrübtes Surfvergnügen beherzigen sollte.

  1. Installieren Sie ein Virenschutzprogramm und ein Anti-Spyware Programm und halten Sie diese Programme immer auf dem aktuellen Stand.
  2. InstallierenSie für ihr Betriebssystem verfügbare Updates. Halten Sie auch die installierte Software immer auf dem neusten Stand. Häufig gelangt Schadsoftware durch Sicherheitslücken im Betriebssystem und in Programmen auf den PC, die noch nicht gepatched wurden.
  3. Wenn möglich arbeiten Sie nicht als Administrator oder mit administrativen Rechten. Schadsoftware wird meist mit den Rechten des angemeldeten Benutzers ausgeführt und kann so noch mehr Schaden anrichten. Verwenden sie zwei Benutzerkonten oder lassen sie z.B. bei Windows Vista und Windows 7 die Benutzerkontensteuerung (UAC) aktiviert.
  4. Gehen Sie sorgfältig mit Ihren Zugangsdaten um. Bewahren Sie diese sicher auf und speichern Sie sie nicht unverschlüsselt auf der Festplatte ihres PCs. Zum verwalten von Kennwörtern und Zugangsdaten auf dem PC eignen sich sogenannte Passwort-Safes wie z.B. KeePass.
  5. Seien Sie vorsichtig beim Öffnen von E-Mail Anhängen. Öffnen Sie diese nur wenn Sie den Absender kennen. Fragen Sie im Zweifel beim Absender nach.
  6. Seien Sie vorsichtig bei Downloads von Dateien aus dem Internet. Vergewissern Sie sich vorher, dass ihr Virenschutzprogramm aktuell ist und die Dateien aus einer vertrauenswürdigen Quelle stammen.
  7. Seien Sie zurückhaltend mit der Weitergabe persönlicher Daten. Je weniger Daten sie weitergeben, desto weniger Daten können von Betrügern missbraucht werden.
  8. Fertigen Sie regelmäßig Sicherungskopien Ihrer wichtigen Daten an. Sollten ihre Daten einmal durch Schädlingsbefall oder Hardwaredefekt verloren gehen, können Sie diese aus einer Sicherung wiederherstellen.
  9. Wird Ihr PC von mehreren Personen benutzt, so richten Sie jedem Benutzer ein eigenen Benutzerkonto ein. Sperren Sie ihre Arbeitsoberfläche, wenn sie den PC verlassen. So verhindern Sie die missbräuchliche Verwendung ihrer Benutzerkennung.
  10. And last but not least. Lassen Sie bei allem Tun und Handeln den gesunden Menschenverstand walten. 😉

Im Gegensatz zu vielen anderen Ratgebern und Tipp-Sammlungen empfehle ich nicht den Einsatz einer Personal Firewall. Der Grund dafür ist ganz einfach. Die meisten Anwender sind nicht in der Lage eine Firewall richtig zu konfigurieren. Und falsch konfiguriert stellt eine Software-Firewall unter Umständen ein Sicherheitsrisiko für ihren Computer dar.

Die meisten Privathaushalte verwenden heute einen Router für den Zugriff auf das Internet. Moderne DSL-Router sind mit einer NAT-Firewall ausgestattet und blocken Angriffsversuche von aussen sicher ab. In diesem Fall ist eine zusätzliche Personal Firewall obsolet.

Sollten Sie sich jedoch direkt per Modem, ISDN oder UMTS mit dem Internet verbinden, kann der Einsatz einer solchen Firewall durchaus sinnvoll sein. Doch scheuen Sie in diesem Fall nicht den Aufwand sich mit der Software vertraut zu machen. Denn nur sinnvoll konfiguriert, kann Sie die Firwall schützen ohne ihren Arbeitsablauf zu blockieren.