SysCP

Sicherheitslücke im Zusammenspiel von SysCP, proftpd und Debian Sarge/Etch

von

Im SysCP-Blog war schon im April im Artikel Security warning: Possible remote code injection when using Debian Sarge/Etch von einer Sicherheitslücke zu lesen. In Unkenntnis davon, das es ein SysCP Blog gibt, habe ich davon erst heute erfahren.

Ursache ist der Benutzer ftp bei Debian, der als Passwort das Ausrufezeichen zugewiesen bekommt, was für „Login immer verboten“ steht. Durch einen Fehler in der SysCP Default-Konfiguration für proftp, kann man sich dann mit diesem Passwort am System anmelden. Wenn im Apache mod_userdir aktiviert ist, kann man für den FTP-Benutzer das Verzeichnis public_html anlegen und mit Dateien befüllen. Diese sind dann im Web zugänglich. Als Lösung wird folgendes aufgeführt, was bei mir auch zur Absicherung des Servers führte:

We recommend to add the following line to your /etc/proftpd.conf:
AuthOrder mod_sql.c

Ich würde allen SysCP-Usern empfehlen nach dem Verzeichnis /home/ftp/public_html zu suchen, proftpd ggf. umzukonfigurieren und dann den public_html Ordner zu löschen, wenn sein Inhalt nicht legitim ist.

maildroprc Filter

von

Ich habe schon vor ein paar Tagen versucht einen neuen maildroprc Filter mit ein paar Regeln zu erstellen, weil ich die alte Filterdatei leider gelöscht habe. Der Filter wurde als benutzerdefinierter Filter in einer SysCP-Installation eingebunden. maildrop schien aber immer mit irgendeinem Fehler abzubrechen, sobald er meinen Filter abgearbeitet hat. Der folgende Filter funktionierte dann nach einigem rumprobieren:

if (/^Subject: *\[ADV\]/)
{
  exception {
    MAILDIR = $MAILDIR.Spam/
  }
}

Ich hatte auch schon Varianten mit if (/^Subject: .*\[ADV\]/) oder if (/^Subject: .*\[ADV\]/) { versucht. Irgendwie klappte das aber alles nicht. Ganz verstanden hab ichs nicht. 🙁 Falls jemand ein gutes Howto für maildrop 2.0.2 Filter hat, bitte melden. 🙂

Debian Etch + SysCP + clamscan.sh

von

Heute habe ich eine Lösung für die clamscan.sh Problematik gefunden. Unter Debian Etch scheint das Device /proc/self/fd/0 nur für root zugänglich zu sein. Abhilfe schafft ein cat -, das auch von stdin einliest. clamscan.sh muss also wie folgt angepasst werden:


#start
#MSG=$(cat /proc/self/fd/0) # stdin -> $MSG
MSG=$(cat -) # So klappts unter Etch

Falls man sicher gehen will, dass clamscan.sh auch wirklich lief, kann man noch die folgende Header-Zeile einfügen lassen:

MSG=$(echo "$MSG" | reformail -i"X-Virus-Scanned: by clamscan.sh (Debian)")

Das ganze kann man vor oder nach dem X-Virus-Status: einbauen.

Debian Etch + SysCP + SpamAssassin

von

Die Geschichte nervt mich inzwischen echt. Von der Maildrop 2.0.x + courier-authlib Problematik blieb zuletzt noch das SpamAssassin Problem übrig. Es äußerte sich im mail.log wie folgt:

localhost spamd[19964]: config: not parsing, administrator setting:
                        bayes_path /path/to/bayes
localhost spamd[19964]: config: failed to parse line, skipping:
                        bayes_path /path/to/bayes

Es scheint wohl so zu sein, dass SpamAssassin in neueren Versionen das Setzen dieses Pfades nur noch über die Konfigurationsdateien erlaubt. Nebenbei sei bemerkt, das diese Konfiguration, die ich auf mehreren Servern eingerichtet hatte, inzwischen nirgendwo mehr funktioniert. 🙁 Also bleibt aktuell nur noch der Ausweg eine SQL-Datenbank für die Bayes-Daten zu benutzen. Da sitze ich zur Zeit dran und dann muß ich mir auch nochmal die clamscan.sh Problematik anschauen.

Maildrop 2.0.x + courier-authlib

von

Nach der gestrigen Installation von maildrop 2.0.2 hoffte ich noch, dass es keine Probleme gibt. Aber es kommt immer anders als man denkt. In der SysCP Maildrop INSTALL Dokumentation fehlt nämlich ein sehr wichtiger Hinweis. Via Google habe ich ihn in einem Mailinglisten-Archiv gefunden: Wenn man maildrop mit der courier-authlib benutzt, muss maildrop in der Postfix master.cf mit root-Rechten ausgeführt werden:

maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=root argv=/usr/bin/maildrop -d ${recipient}

Mit user=vmail klappts bei Debian etch nicht mehr. Jetzt kann das Setup weiter gehen. Als nächstes gehts ans Spamassassin trainieren und konfigurieren. Der meldet sich nämlich noch nicht.

Update 01.05.07 Leider weigert sich das Postfix pipe Kommando Befehle mit root-Rechten auszuführen. Diese Weigerung führt dazu, das die Zustellung über den maildrop Transport nicht funktioniert. Ich teste gerade eine andere Möglichkeit wie man maildrop ohne Patch verwenden kann.

Debian + SysCP + maildrop + MySQL = ?

von

Bei meinen letzten SysCP Installationen ergab die Gleichung ein Problem, da maildrop ohne MySQL-Support daher kam. Es war dann immer nötig maildrop selber zu compilieren, bzw. ein „fremd-compiliertes“ maildrop zu verwenden. Ich habe diese Woche einen Server neu aufgesetzt und stellte erfreut fest, das dieses Problem nicht mehr auftritt. Allerdings kommt das maildrop nicht mit MySQL-Support daher, sondern mit der „Courier Authentication Library“:

errol:/etc/courier# maildrop -v
maildrop 2.0.2 Copyright 1998-2005 Double Precision, Inc.
GDBM extensions enabled.
Courier Authentication Library extension enabled.
Maildir quota extension enabled.
This program is distributed under the terms of the GNU General Public
License. See COPYING for additional information.

Bleibt zu hoffen das es hiermit keine Probleme gibt, auf den ersten Blick schaut auf jeden Fall alles gut aus. 🙂