Exchange 2003/2007, Spam, postfix, Debian, DNS

Seit dem 14.02.2009 ist Debian Lenny offiziell als stable Version verfügbar. Eine Liste aller Änderungen/Neuerungen finden Sie entweder unter Debian.org oder auf wiki.debian.org. Das reizt natürlich auf die aktuelle Version upgraden zu wollen. Dieses Upgrade sollte man jedoch nicht unbedacht tun. Ich habe zum Beispiel um das Upgrade Verfahren nicht sofort an einem Produktiv System zu testen, eine virtuelle Maschine, die 1:1 ein Produktiv System abbildet, mit allen Updates, allen configs etc.. In Dieser Umgebung habe ich dann zuerst das Upgrade getestet. So lassen sich Probleme beim Upgrade mit dem eigenen System evtl. bereits im Voraus erkennen, oder weiß so bereits schon vor dem Upgrade des Live Systems, bei welchen Programmen eine anschließender umfangreichere Anpassung notwendig werden könnte.

Für das eigentliche Upgrade sind relativ wenige Schritte notwendig. Wer übrigens einen VMWare Server unter Debian laufen hat, sollte auch mal einen Blick in den Artikel VMWare Server 1.x/2x unter Debian 5 installieren werfen.

Alle Pakete des Systems aktualisieren

Um Probleme beim Upgrade zu vermeiden, hat es sich als sinnvoll erwiesen, alle Pakete auf den letzten Stand der verwendeten Version zu bringen.

apt-get update && apt-get upgrade

Installation der notwendigen Pakete

Nun sollten Sie sicherstellen, dass alle für das Update notwendigen Pakete installiert sind.

apt-get install apt dpkg aptitude

Anpassen der sources.list

Anschließend müssen in der sources.list alle etch Einträge durch lenny ersetzt werden.

deb http://ftp.de.debian.org/debian/ lenny main non-free contrib
deb-src http://ftp.de.debian.org/debian/ lenny main non-free contrib

deb http://security.debian.org/ lenny/updates main contrib non-free
deb-src http://security.debian.org/ lenny/updates main contrib non-free

Aktualisieren des Systems

Nun können Sie das System aktualisieren. Da ich auf allen Systemen bisher immer apt-get verwendet habe, sind die Befehle hier auch mit apt-get gelistet. Wer aptitude verwendet, sollte apt-get natürlich durch aptitude ersetzten insofern die Befehle nicht unterschiedlich sind.

• Vorteile von aptitude
• bekannter Fehler: Warnung beim Upgrade über Schlüssel 4D270D06F42584E6

apt-get update && apt-get dist-upgrade

oder

aptitude update && aptitude full-upgrade

Sollten Sie mehrere Systeme aktualisieren wollen, verwenden Sie entweder die CDs/DVDs der aktuellen Version oder installieren Sie einen lokalen .deb Cache.

Spamassassin (Nachtrag: 03.02.2009)

Nun habe ich heute ein System mit spamassassin Installation aktualisiert. Eine Überprüfung der Konfiguration ergab folgendes

spamassassin --lint
[26749] warn: plugin: failed to parse plugin (from @INC): Can't locate Mail/DomainKeys/Message.pm
in @INC (@INC contains: lib /usr/share/perl5 /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/..
perl/5.10.0 /usr/lib/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl) at ...
/usr/share/perl5/Mail/SpamAssassin/Plugin/DomainKeys.pm line 83.
[26749] warn: BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Plugin/DomainKeys.pm line 83.
[26749] warn: Compilation failed in require at (eval 77) line 1.
[26749] warn: netset: cannot include 127.0.0.1/32 as it has already been included

Die ersten drei Fehler ließen sich wiefolgt lösen

apt-get install libmail-dkim-perl
cpan -i Mail::DomainKeys

Der letzte Fehler war ein selbst gebauter. Ich hatte in der local.cf unter trusted_networks auch noch die 127.0.0.1 eingebaut was ja eigentlich doppelt kemoppelt ist. Die alten Spamassasin Versionen haben sich daran jedoch nie gestört.

Desweiteren produzierte der amavisd-new-cronjob folgende Fehlermeldung

Jan  7 15:20:52 hostname spamd[6499]: Argument "M-HM-HM-H" isn't numeric in
umask at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/Locker/UnixNFSSafe.pm
line 75.

Dieser Bug (Bug 5771) ist bekannt und mehr oder weniger “nur” ein Berechtigungsproblem.

weitere interessante Links

• Namensstreit zwischen Debian und Mozilla

Der Exchange ADAccess Dienst prüft beim starten bzw. in regelmäßigen Abständen, welche Server mit welchen Rollen vorhanden sind (DC/GC) und auch ob diese Verfügbarkeit sind. Werden mehrere Server gefunden, verwendet Exchange die Server die in der eigenen site vorhanden sind. Die Auswertung der Server wird im Eventlog mit der ID 2080 protokolliert.

In einem Fall trat jedoch die Tage das Phänomen auf, dass Exchange aller Server mit der DC/GC Rolle fand, jedoch die in der eigenen site nicht akzeptierte. Das Problem ließ sich über die EventID 2080 lokalisieren. Auf den In-Site Servern fehlte die SACL Berechtigung

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=xxxx). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
 (Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 0 1 7 1
xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 0 1 7 1
 Out-of-site:
xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 1 1 7 1
xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 1 1 7 1
xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 1 1 7 1
xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 1 1 7 1

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Aufgefallen ist dies, nachdem versucht wurde die Exchange Server über den Befehl Set-ExchangeServer an die In-Site DomainController bzw. GCs zu binden und die Server anschließend beim reboot hängen blieben. Nach dem setzten der Werte ergab das auslesen dieser, dass angeblich keine Server für StaticDomainControllers und StaticGlobalCatalogs gesetzt wurde. Der Reboot bestätigte jedoch, dass sie dennoch gesetzt worden sind. Angeblich sind die Werte nur über “| format-list” sichtbar, was ich im nach hinen nicht mehr prüfen kann.

Die Lösung des Problems war auf  jeden Fall, das setzten der Leseberechtigung auf den nTSecurityDescriptor für die Gruppe der Exchange Servers über ADSIEdit (Windows 2003 Support Tools x32, x64) sowie das anschließende ausführen des Setups mit dem Parameter /PrepareDomain.

setup.com /PrepareDomain

Dies kann entweder für einzelne Server (grün) oder für die OU (rot) der DomainController erfolgen.

Anschließend sollten die entsprechenden Domaincontroller neu gestartet werden. Ein Neustart der Exchange Server ist nicht notwendig gewesen, da der ADAccess Dienst diese Änderung selbstständig erkennt. Es kann jedoch etwas dauern, bis diese Änderung der Berechtigung sich auf die Exchange Server auswirkt. In meinem Fall haben die ersten Systeme nach 15-20 Minuten diese Änderungen bemerkt. Der letzte Server hat dies nach 1 1/2 Stunden mitbekommen.

Gruppenmitgliedschaft prüfen

Sollte dies nicht geholfen haben, prüfen Sie ob die Exchange Server Mitglied der Gruppe “Exchange Servers” sind.

Default Domain Controllers Policy

Der nächste Schritt wäre die “Default Domain Controllers Policy” zu kontrollieren. Unter folgendem Pfad gibt es die Richtlinie “Manage auditing and security log“. In dieser muss die Gruppe der Exchange Server auftauchen.

Nachdem dies nun sichergestellt ist, prüfen Sie bitte noch ob die DomainController auch die richtige Policy anwenden. Führen Sie dazu auf einem der CDs rsop.msc aus und navigieren zu erneut zur Policy “Manage auditing and security log“. Hier sollte nun zu erkennen sein, dass der DC die Richtlinien der “Default Domain Controllers Policy” anwendet. Ist dies nicht der Fall, kontrollieren Sie bitte über gpmc.msc die Berechtigungen für die Policy. Die Gruppe “Authenticated Users” muss read & apply permissions für die “Default Domain Controllers Policy” besitzen.

Links

• http://msdn.microsoft.com/en-us/library/aa379321(VS.85).aspx
• http://forums.msexchange.org/m_1800452907/printable.htm

Auf Sanesecurity.com dürfte der ein oder andere ja bereits aufmerksam geworden sein. Wie in meinem Artikel “ClamAV zur Spambekämpung? Ja…” beschrieben, werden seit längerem auf sanesecurity.com Clamav Signatur Dateien angeboten, mithilfe derer man Spam eMails identifizieren kann. Das Prinzip ist identisch mit der Erkennung von Viren.

Beim erstellen wird aus einer Spam eMail ein Teil herausgesucht, der diese eMail möglichst eindeutig identifiziert. Für diese Phrase wird dann eine Checksumme errechnet die dann in einer Virendatei abgespeichert wird. Findet clamav nun eine Datei, die genau die gleiche Checksumme beinhaltet gilt dies als Treffer und die Datei – in unserem Falle die eMail wird als Virus/Spam identifiziert.

Unter dem Link http://www.sanesecurity.com/method.pdf ist bereits eine Anleitung zu finden, wie man sich eine eigene Signaturdatei erstellt, jedoch hatte ich damit irgendwie meine Probleme, dies mag unter anderem daran liegen, dass in dem PDF Dokument nicht beschrieben ist, dass von der errechnete Checksumme (siehe unten) die letzten beiden Nullen entfernt werden müssen. Nun aber weiter nach Plan…

Wir haben nun also eMail die wir eindeutig als Spam identifiziert haben und nun durch clamav filtern lassen wollen. Dies kann bei einer Massiven Spam Welle mit mehrere eMails des gleichen Inhaltes sinnvoll sein, wenn die eMail vom Spamfilter nicht erkannt wird… Wir suchen uns nun also einen Teil innerhalb der eMail der eindeutig für diese eMail ist.

In unserem Fall enthält die eMail den Text

Spezialangebot: ViAA 10 Tab + Ci 10 Tab – 56.15 Euro

Achten Sie beim aussuchen der Textstelle darauf, dass beim HTML Format evtl. noch Formatierungstags diese Stelle umschließen bzw. unterbrechen können. In diesem Fall sollten sie den Quelltext der eMail verwenden um die Passage inkl. Formatierungstags zu verwenden. Auf der Seite http://nickciske.com/tools/hex.php können Sie sich nun einen Hex-Wert für diese Textstelle erstellen lassen. Achten Sie darauf, dass sie die beiden letzten 00 anschließend entfernen müssen.

Nun haben Sie den Hex-Wert und schreiben diesen in folgendem Format in *.ndb Datei im Clamav Verzeichnis (/var/lib/clamav/).

o-o-s.de.090124001:3:*:5370657A69616C616E6765626F743A....

• o-o-s.de.090124001 – Dieser Teil gibt an, als was die Datei identifiziert wird. Geben Sie hier einen eindeutigen Namen an.
• :3: – steht für den Typ HTML. Mögliche Werte können bei Clamav im Dokument für die Signaturerstellung im Abschnitt Extended signature format nachgelesen werden
• 5370657A69616C616E6765626F74… Der Hex-Wert der Textpassage

Nach einem reload der Clamav-DB sollten nun eMails mit der verwendeten Textpassage erkannt werden.

Wer nun den Betreff eine eMail verwenden möchte um diese zu identifizieren, kann dies auch tun.

o-o-s.de.090124002:4:*:5375626a6563743a{-30}54776F20676F….

• 5375626a6563743a – steht in dem Fall für Subject: