Yet another Web Blog

Wer seinen Plesk Server mittels dem Migration Manager Software seitig umzieht, muss sich darüber keine Gedanken machen - aber was tun wenn ein Server Hardwaretechnisch umgezogen wird und eine andere IP erhält? Diese Frage möchte ich hier beantworten.

Wichtig ist das die neue IP Adresse vorher nicht im Adminbereich von Plesk hinzugefügt wird, da der Vorgang sonst nicht funktioniert, da das reconfigure Programm alles automatisch machen möchte!

Vorgehensweise:

1. Wechsel des Ordners

cd /opt/psa/bin

2. Anlegen einer Mapping Datei

 ./reconfigurator.pl map.txt

3. Ändern der IP Adressen bzw. der Mapping Datei mittels Editor

nano map.txt
eth0:-ip-vorher- 255.255.255.0 > eth0:-neue-ip- 255.255.255.0
usw.

4. Einspielen des neuen IP-Adressen Mappings

 ./reconfigurator.pl map.txt

Reconfigure läuft jetzt systematisch alle Anpassungen durch und ändert folgende Dinge:

- Anpassen der Apache2 Konfiguration
- Anpassen der Zonefiles in Bind
- Anlegen der neuen IP im System und in Plesk
- Zuordnung der Kunden und der Hostings auf die neue IP

Sollte dieser Vorgang scheitern weil die neue IP Adresse bereits im Admin Menü von Plesk angelegt ist, muss man ggf. einen Workaround mittels einer 3ten IP Adresse gehen (mappen, zurückmappen und dann wieder löschen) oder sich eine andere Lösung suchen.

Viel Glück an alle Pleskgeschädigten.

Viele Administratoren kämpfen mit Ausläufern von unsicheren PHP Scripten die es einem Angreifer ermöglichen in das System einzudringen, Spam zu versenden oder die Funktion des Servers anderweitig nach den Wünschen des Angreifers zu gestalten.

Dies ist nicht nur ärgerlich sondern zieht meist auch Konsequenzen nach sich, welchen hier keine weitere Erläuterung geschenkt werden soll.

Den Server dahingehend zu schützen oder absichern zu können ist ein schmaler Grad zwischen “geht” und “geht nicht” - gemeint sind hier diese diversen PHP Scripte.

Die wohl wichtigsten PHP Direktiven für Administratoren, die erreichen können eine relativ sichere Umgebung zu ermöglichen sind die Folgenden:

allow_url_fopen = off 
 
register_globals = off 
 
open_basedir = "/pfad/zum/user/homedir:/pfad/zu/pear:/pfad/zum/tmpdir:/pfad/zum/uploadir" 
 
disable_functions = dl, exec, shell_exec, system, passthru, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, escapeshellcmd, escapeshellarg, set_time_limit, show_source

Erst wenn diese Einstellungen so oder so ähnlich aussehen, würde meiner einer von wenigstens in Grundzügen sicheren Hosting Umgebung sprechen.

Wem das nicht genug ist, dem ist zu raten mittels mod_security die mit POST (oder anderweitig) zum Apache gesendeten Daten zu durchleuchten.

Die User danken es einem?

Wir viele User zu bedienen hat und damit viel PHP Software, wird schnell merken dass einige PHP Scripte mit den o.g. Einschränkungen nur teilweise oder im schlimmsten Fall gar nicht laufen, daher sollte man sein System einige Zeit nach einer solchen Änderung im Auge behalten => denn Schuld ist immer der Administrator auch wenn er seine User nur happy machen möchte.

Seitdem ich spamassassin auf einem Server vom Debian Volatile Projekt in Version 3.2.3 installiert habe, quittiert das Anti Spam Tool pyzor welches mittels “use_pazor 1″ in die local.cf von spamassassin eingebunden ist mit einem internal error den Dienst.

Vor diesem Update in den Volatile Zweig (und das damit verbundene Update von Version 3.1.7-deb) funktionierte pyzor einwandfrei.

Ein Update wird hier folgen sobald ich eine Lösung gefunden habe, außer dem reinstallierten der guten alten spamassassin Version aus dem Debian main Zweig.