Google hat erstmals Gebrauch von der Möglichkeit gemacht, aus der Ferner auf Android-Smartphones installierte Applikationen zu zugreifen und diese auch zu ändern.

Wie auch bei Apple wird der Android Market von Google überwacht. Dabei kommt es hin und wieder vor, dass Anwendungen gelöscht werden, da diese gegen Richtlinen verstoßen. Diesen Schritt ging Google nun das erste Mal und löschte 2 Apps aus seinem Store. Allerdings dem nicht genug: Google löschte die Anwendungen auch gleich auf den Smartphones auf denen die Apps installiert waren.

Die beiden betreffenden Anwendungen waren von Sicherheitsforschern zu Testzwecken veröffentlicht worden um zu demonstrieren wie einfach sich Schadsoftware über solche Stores verbreiten ließe. Beim Download wurde der Nutzer mit falschen Versprechen zu einem Download weitergeleitet, bei dem dann Schadsoftware lauern könnte. Die Anwendungen selbst richteten keinen Schaden an und wurden von den meisten Benutzern ohnehin wieder entfernt.

Google entschied sich allerdings die Anwendungen über die Fernwartungsfunktion von den Geräten zu entfernen. Diese Möglichkeit ist eine Sicherheitsmaßnahme und dient dazu Anwendungen im Notfall zu entfernen.

Für mich als Nutzer beschleicht sich nun aber das etwas mulmige Gefühl, was Google mit dieser Fernwartungssoftware noch so alles machen kann. Da das Smartphone hauptsächlich zuhause an der WLAN Leitung hängt, würde man es gar nicht erst bemerken, wenn klammheimlich Daten übermittelt werden, die über eine Fernwartung hinausgehen.

Gerade wegen des kürzlichen WLAN Datenskandals bei Google sollte man sich hier doch die ein oder andere Überlegung machen wie man das Gerät in Zukunft besser schützen kann.

Seit kurzem ist die neue Version von PLESK verfügbar; und ich bin richtig erstaunt dass man es bereits in der 5. Version von PLESK 9 geschafft hat endlich Postfix stabil einzubinden. Heureka.

Zusammen mit Amavis und dem ClamAV als Virenfilter hat man nun eine Weboberfläche die sich sehen lassen kann – zumindest für Kunden die Eyecandy mögen.

Unter Debian Lenny hat sich laut Parallels ein Bug in Curl eingeschlichen, so dass das Keyupdate über die PLESK Oberfläche fehlschlägt. Man könnte nun a) curl kompilieren, b) Curl aus Debian Etch installieren oder c) PLESK deinistallieren, die Lizenzkosten in einen ausführlichen Linux Debian Kurs oder in adäquate Bücher investieren und… ach ne c) scheidet ja aus… Nun gut.

Hier also die Lösung dazu

1) Anlegen der Datei “psacurl”

Als erstes legen wir die Datei “psacurl” unter /opt/psa/bin oder dem entsprechenden BIN Verzeichnis von PLESK an und füllen diese mit folgendem Inhalt:

#!/bin/bash
/usr/bin/curl -k --sslv3 $@

Dieser Datei verpassen wir die Rechte 0755, chmod sollte als Programm hier die erwarteten Dienste verrichten.

2) .profile Datei für psaadm

Damit wir nun das von uns erzeigte “psacurl” auch PLESK beibringen bediene ich mich hier einfach einer .profile Datei die einen Alias für den eigentlichen curl Befehl enthält. Inhalt der Datei:

alias curl='/opt/psa/bin/psacurl'

Um die .profile Datei nun auch nutzen zu können ist eine kurze Änderung in der /etc/passwd erforderlich um dem User “psaadm” eine Shell zu verpassen, nach dem Wechsel auf die Userebene führen wir ein simples Befehlchen aus:

. .profile

Bitte beachten: Der Punkt am Anfang muss ebenfalls eingegeben werden, sowie die nachfolgende Leerstelle. Damit wird das Profil neu geladen und absofort ist der Alias aktiv.

Fertig

Bekanntermaßen reicht der Softwarehersteller Parallels für die Linux Variante von PLESK ausschließlich den tollen Dr. Web oder Kaspersky als Anti-Virenmodul. Beide sind kostenpflichtig und nehmen nicht wenig an Gebühren. Bei Dr. Web sind es schon mal 300€, Kaspersky rechnet pro Postfach.

Aber: Es gibt Abhilfe. Dank Amavis, Postfix und Clamav kann man sich so ganz einfach einen kostenfreien Anti-Virenscanner schaffen.

Wie immer vorne weg: Wer keine Ahnung von Linux hat, nicht weiss was eine Shell ist und bei der Frage nach dem Texteditor unter Linux Notepad empfiehlt, sollte sich gleich von jemanden der sich mit dem Ganzen auskennt helfen lassen. Hier gibt es dazu Hilfe.

Voraussetzungen:
PLESK unter Linux, Clamav Daemon und Freshclam, Amavis installiert.

1) Konfiguration Amavis

Die Grundkonfiguration von Amavis sollte bereits erledigt sein, soll heißen ich erkläre hier nicht weiter wie man Clamav und Amavis verbindet, es gibt unzählige Anleitungen. Neu ist allerdings, dass wir Amavis nicht wie üblich auf Port 10024 laufen lassen, sondern wir müssen ihm einen neuen Port zuweisen, da in den Regionen 10020 – 10030 PLESK mit den ganzen Mailhandlern arbeitet. Ich vergebe daher die Ports 6000 und 6001. Unter Debian nutzen wir dabei 2 Dateien:

50-user.conf

$forward_method = ‘smtp:[127.0.0.1]:6001′;
$notify_method = ‘smtp:[127.0.0.1]:6001′;

In der Hauptkonfigurationsdatei stellen wir ebenfalls den Port um:

20-debian-defaults.conf

$inet_socket_port = 6000;

Damit sind die ersten Schritte schon erledigt. Der forward und notify Port muss übrigens angegeben werden. Wird er das nicht gibt es folgenden Fehler:

(!) WARN: sending SMTP QUIT command failed: 000

2) Postfix main.cf

Die beiden folgenden Einstellungen in der main.cf und master.cf von Postfix müssen im Übrigen vor Veränderungen geschützt werden. PLESK hat die Angewohnheit die Dateien bei jeder Änderung um Maileinstellungsbereich sowie auch bei Updates von PLESK komplett zu überschreiben. Jegliche Versuche PLESK zu erklären, dass nicht zu machen sind gescheitert. Ein chattr hilft hier auf jeden Fall weiter, sofern man EXT3/4 hat und nicht reiserfs.

Fangen wir also mit der main.cf an. Dort muss nur ein kleiner Eintrag eingefügt werden, da das meiste in der master.cf passiert.

main.cf

content_filter = smtp-amavis:[127.0.0.1]:6000

Nachdem dieser Eintrag an das Ende der Datei gesetzt wurde, sind wir hier auch schon fertig. Als nächstes folgt nun die master.cf:

master.cf

plesk_virtual unix – n n – - pipe flags=DORhu user=popuser:popuser argv=/usr/lib/plesk-9.0/postfix-local -f ${sender} -d ${recipient} -p /var/qmail/mailnames
127.0.0.1:10025 inet n n n – - spawn user=mhandlers-user argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue
127.0.0.1:10026 inet n – - – - smtpd -o smtpd_client_restrictions=  -o smtpd_helo_restrictions=  -o smtpd_sender_restrictions=  -o smtpd_recipient_restrictions=permit_mynetworks,reject  -o smtpd_data_restrictions=  -o receive_override_options=no_unknown_recipient_checks
127.0.0.1:10027 inet n n n – - spawn user=mhandlers-user argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote
plesk_saslauthd unix y y y – 1 plesk_saslauthd status=5 listen=6 dbpath=/plesk/passwd.db

submission inet n – - – - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_proxy_filter=127.0.0.1:10025

smtps inet n – - – - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 -o smtpd_tls_wrappermode=yes

smtp-amavis unix -      -       n       -       2       smtp -o smtp_data_done_timeout=1200 -o disable_dns_lookups=yes -o smtp_send_xforward_command=yes
127.0.0.1:6001 inet n  -       n       -       -       smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes

Das sind die kompletten Einträge die gesetzt werden müssen. Es werden vermutlich einige schon vorhanden sein. Ich empfehle einfach alles ab “plesk_virtual” rauszuwerfen und gleich neu einzusetzen, das erspart die Sucharbeit. Nachdem wir auch diesen Eintrag erledigt haben, sichern wir die beiden Dateien gegen Veränderung, starten Postfix neu und fertig

Vorher sollte aber jeder in PLESK selbst den Virenfilter auf “keinen” umgestellt haben, damit nicht doch noch Dr. Web im Hintergrund weiterläuft.

Wer seinen Spamassassin nicht nur in der Standardkonfiguration betreiben möchte, sondern darüber hinaus noch weitaus mehr Tests zum Erkennen von Spam nutzen. Hierfür hatte man früher über die Seite exit0.us ein Bash Script zur Verfügung gestellt bekommen, welches die Sare Checks herunterläd. Durch die Neuerungen in Spamassassin ist dieses Script überflüssig geworden, da man nun sa-update als nützliches Werkzeug an die Hand bekommt. Nur ich vermute, dass die wenigsten wissen werden wie man dies korrekt konfiguriert.

Und genau deswegen heute dieses HowTo. Man nehme einen handelsüblichen Server auf dem ein Spamassassin bereits vorinstalliert ist und auch funktioniert. Alles weitere wird nun beschrieben.

Inhalt

1. Vorbereiten der Verzeichnisse
2. Import der notwendigen GnuPG Keys
3. Erzeugen der Konfigurationsdateien
4. sa-update das erste Mal ausführen
5. Optional: Cronjob einrichten

Und schon geht’s los…

1.) Vorbereiten der Verzeichnisse

Damit sa-update arbeiten kann benötigt es ein Verzeichnis in dem die GnuPG Keys und andere Daten abgelegt werden: sa-update-keys. Das Verzeichnis muss, sofern es nicht vorhanden ist erstellt werden. Ich traue nun mal jedem zu, dass er weiß wie ein Verzeichnis angelegt wird. Um später keinen Rechtefehler beim sa-update zu erhalten, geben wir dem Verzeichnis die Rechte 0600 für die User:Gruppe root:root. Im Endergebnis schaut dann alles so aus:


drwx------ 2 root root 4096 2009-03-30 06:46 sa-update-keys


Das war ja nun noch leicht Daher ziehen wir ohne Warten direkt zum nächsten Punkt weiter

2.) Import der notwendigen GPG Keys

Um sicherzustellen, dass die heruntergeladenen Regeldateien auch vom Entwickler stammen und nicht von bösen Buben, ist es notwendig dass wir die GnuPG Keys herunterladen und diese unserem lokalen Keyring hinzufügen. Nun laden wir erst einmal herunter:


wget http://spamassassin.apache.org/updates/GPG.KEY -O GPG-sa.KEY
wget http://daryl.dostech.ca/sa-update/sare/GPG.KEY -O GPG-dostech.KEY


Und schon haben wir die Keyfiles der beiden Channels. Da beide Dateien gleich lauten habe ich eine Output Anweisung bei wget angegeben, die uns 2 verschiedene Dateien anlegt. Nun müssen diese Keys in den Keyring importiert werden:


gpg --import GPG-sa.KEY
gpg --import GPG-dostech.KEY


Spamassassin bzw. sa-update hat aber noch einmal einen eigenen Keycache dem wir ebenfalls die Dateien zuführen müssen:


sa-update --import GPG-sa.KEY
sa-update --import GPG-dostech.KEY


Das wäre geschafft. Damit sind wir nun gerüstet die Channel und GPGKey Dateien anzulegen.

3.) Erzeugen der Konfigrationsdateien

sa-update bietet die Möglichkeit mehrere Regelsätze direkt herunterzuladen. Dazu legt man einfach eine Datei an in welcher die verschiedenen Regeln eingetragen werden. Bei einem Update übergibt man diese einfach zusammen mit der GnuPG Datei und schon werden die Regel automatisch heruntergeladen. Die notwendigen Inhalte folgen nun:


updates.spamassassin.org
70_sare_stocks.cf.sare.sa-update.dostech.net
70_sare_adult.cf.sare.sa-update.dostech.net
70_sare_spoof.cf.sare.sa-update.dostech.net
70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
70_sare_genlsubj_x30.cf.sare.sa-update.dostech.net
70_sare_oem.cf.sare.sa-update.dostech.net
70_sare_random.cf.sare.sa-update.dostech.net
70_sare_specific.cf.sare.sa-update.dostech.net
70_zmi_german.cf.zmi.sare.sa-update.dostech.net
70_sare_evilnum0.cf.sare.sa-update.dostech.net
70_sare_highrisk.cf.sare.sa-update.dostech.net
70_sare_header0.cf.sare.sa-update.dostech.net
70_sare_html0.cf.sare.sa-update.dostech.net
70_sare_obfu0.cf.sare.sa-update.dostech.net
70_sare_stocks.cf.sare.sa-update.dostech.net
70_sare_unsub.cf.sare.sa-update.dostech.net
70_sare_uri0.cf.sare.sa-update.dostech.net
70_sare_uri1.cf.sare.sa-update.dostech.net
70_sare_uri3.cf.sare.sa-update.dostech.net
70_sc_top200.cf.sare.sa-update.dostech.net
72_sare_bml_post25x.cf.sare.sa-update.dostech.net
99_sare_fraud_post25x.cf.sare.sa-update.dostech.net
88_FVGT_Bayes_Poison.cf.sare.sa-update.dostech.net
88_FVGT_Tripwire.cf.sare.sa-update.dostech.net
88_FVGT_rawbody.cf.sare.sa-update.dostech.net
88_FVGT_subject.cf.sare.sa-update.dostech.net
chickenpox.cf.sare.sa-update.dostech.net


Übrigens genau genommen sind dies nicht die direkten Regeln sondern sog. Channels in welchen die Regeln verwaltet werden (nur falls ein Schlaumeier wieder meint man müsse gleich mit Wissen prahlen). Die oben stehenden Zeilen dann einfach in eine Datei kopieren und wie folgt benennen: sare-sa-update-channels.chan

Als nächstes legen wir eine Datei für die beiden GnuPG Keys an. Man könnte diese auch direkt über die Option –gpgkey übergeben, da man sich aber die Zahlen-/Buchstabenkombinationen eher schlecht merken kann, nutzen wir dazu ebenfalls eine Datei:


856AA88A
5244EC45


Diese Zeilen kopieren wir nun ebenfalls in eine Datei und benennen diese: sare-sa-update-keys.chan. Fertig sind unsere beiden Konfigurationsdateien die wir nun im nächsten Schritt an sa-update übergeben.

4.) sa-update das erste Mal ausführen

Nachdem wir nun alle notwendigen Maßnahmen ergriffen haben, können wir das Update nun das erste Mal durchführen und die Regeldateien herunterladen. Ich empfehle beim beim ersten Update die Debug Option “-D” mit zu aktivieren, damit man auf Fehler aufmerksam wird.


sa-update --channelfile sare-sa-update-channels.chan --gpgkeyfile sare-sa-update-keys.chan -D


Es huschen nun eine ganze Menge Zeilen und Ausgaben über die Shell. Wie gesagt, solange keine Fehlermeldung erscheint ist alles normal. Spamassassin selbst kennt die Regeln nach dem Update aber noch nicht und muss daher mit der Option “–lint” aufgerufen werden. Auch hier kann man die Debug Option “-D” nutzen um weitere Fehler zu lokalisieren:


spamassassin --lint -D


Fertig Und nun darf der Spam gerne kommen.

5.) Optional: Cronjob zum automatischen Update anlegen

Sobald man Spamassassin installiert hat, wird auch (zumindest bei Debian) ein Cronjob angelegt der tägliche Updates des Spamfilters durchführt. Daher würde ich als erstes im Verzeichnis “/etc/cron.daily” nachsehen ob dort eine Datei namens “spamassassin” liegt. Wenn ja, dann diese mit einem Editor deiner Wahl öffnen und folgendes ersetzen:


# Update
umask 022
sa-update --channelfile /etc/mail/spamassassin/sare-sa-update-channels.chan --gpgkeyfile /etc/mail/spamassassin/sare-sa-update-keys.chan || exit 0


Bitte vorher nachsehen ob eine ähnliche Zeile bereits im Script vorhanden ist und diese dann durch die og. ersetzen. Nun kann der Crond jeden Tag die Updates herunter holen und in den Spamassassin laden. Mehr ist nicht zu tun