Vielleicht ganz interessant für Gentoo Nutzer mit einem dedizierten Server bei 1&1:

Seit kurzem bietet 1&1 einen lokalen rsync-Mirror für Portage sowie einen Mirror für die Distfiles an. Die Nutzung dieses Mirrors hat den Vorteil, dass die Anbindung zum Server ggf. besser als die zu anderen Spiegelservern ist und die offizielle Infrastruktur von Gentoo geschont wird.

Um den Mirror nutzen zu können, muss einfach die /etc/make.conf mit folgenden Einträge ergänzen:

SYNC="rsync://update.onlinehome-server.info/gentoo-portage"
GENTOO_MIRRORS="http://update.onlinehome-server.info/distribution/gentoo/gentoo"

Wenn Paludis genutzt wird, muss der rsync-Mirror im Gentoo Repository (normalerweise /etc/paludis/repositories/gentoo.conf) eingetragen werden:

sync = rsync://update.onlinehome-server.info/gentoo-portage

Der Distfiles-Mirror wird in /etc/paludis/mirrors.conf eingetragen:

* ftp://update.onlinehome-server.info/distribution/gentoo/gentoo/distfiles http://distfiles.gentoo.org/distfiles http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles

Die beiden zusätzlichen Einträge sind dabei Alternative Distfile-Mirrors.

Dass das Akronym PHP ab und zu auch für "Pretty Hard to Protect" stehen kann, ist sicherlich nichts Neues. Eine Sprache die leicht zu erlernen ist und deren Laufzeitumgebung bei jedem Feld, Wald und Wiesenprovider installiert ist, zieht nun einmal auch Leute an, die normalerweise nicht programmieren würden (oder sollten) und sich über Sicherheit nicht den Kopf zerbrechen. Es gibt also jede Menge schlechter PHP-Skripte. Das ist sicherlich nicht die Schuld der PHP-Macher.

Aber manchmal frage ich mich ernsthaft, ob ein Abschied von PHP vielleicht sinnvoll wäre. Die letzten Tage ist mal wieder ein schon etwas älterer Bug von PHP an die Oberfläche des Interwebs gespült worden.

Beim Einsatz als Apache-Modul werden vor dem Aufruf des PHP-Interpreters nicht alle Dateideskriptoren aufgeräumt, die der Apache httpd geöffnet hat. Dadurch kann über ein normales PHP-Skript sowie ein unterstützendes Binary (oder ggf. Skript, wenn der Interpreter die entsprechenden Systemaufrufe unterstützt) der Apache-Prozess verdrängt bzw. ersetzt werden.

Ein bösartiges Skript kann dadurch an Stelle des Apache httpd Daten an Besucher ausliefern und so bspw. Malware verbreiten, Passwörter abgreifen usw.

Man erhält dadurch zwar keine Rootrechte (zumindest nicht trivial), aber die Möglichkeit den Webserver abzuschießen und durch einen eigenen Prozess zu ersetzen ist schlimm genug. Betroffen sind scheinbar alle Versionen von PHP.

Was das ganz noch viel schlimmer macht, ist die Tatsache, dass alle Wohnzimmerhoster (no offense ;), die Plesk und vergleichbare Pakete benutzen, die auf mod_php setzen, von der Problematik betroffen sind, es aber vermutlich nicht wissen und niemals erfahren werden. Irgendwann sind die Server einfach einmal gekapert und liefern munter Malware aus. Zumindest bei Plesk ist die Nutzung von PHP als Apache-Modul obligatorisch. Andere Modi werden nicht unterstützt.

Um das Problem zu umgehen, bieten sich neben den offensichtlichen Vorschlägen PHP zu deinstallieren oder den Apache httpd durch eine Alternative wie lighttpd oder nignx zu ersetzen, folgende Möglichkeiten an, die möglichst kombiniert werden sollten:

1) PHP über die CGI-Schnittstelle, SuPHP oder FastCGI mit SuExec einbinden.
2) Funktionen wie system, passthru usw. mit disable_functions verbieten.
3) open_basedir Restrictions korrekt setzen.
4) Die Partition mit den PHP-Skripten mit dem Parameter noexec mounten.

Verweise:
Bug #20302 Leaked Descriptors
Bug #38915 Apache: system() (and similar) don't cleanup opened handles of Apache
http://hackerdom.ru/~dimmo/phpexpl.c
Hijacking Apache https by mod_php
Apache mit mod_php übernehmen

via Fefe

Seit OpenSSH 4.9 unterstützt der SSH-Daemon des OpenBSD Projekts das Einsperren der Benutzer in einem beliebigen Verzeichnis über den chroot(2) Systemaufruf. Zuvor war dies nur mit einem Thirdparty Patch wie chrootssh oder im Fall der Einschränkung auf SFTP/SCP mit speziellen Shells wie scponly oder rssh möglich.

Ebenfalls mit Version 4.9 wurde eine Variante des sftp-server(8) eingeführt, die direkt in sshd(8) gelinkt ist. Das hat den großen Vorteil, dass nicht mehr alle Binaries und Programme, die ein Benutzer ausführen können soll oder muss (z. B. seine Shell oder die SFTP-Bibliothek) sowie die Gerätedateien /dev/null und /dev/urandom innerhalb der chroot-Umgebung vorhanden sein müssen. Das erspart dem Administrator die fehlerträchtige Erstellung einer solchen Umgebung sowie die Redundanz der in den chroot-Umgebungen benötigten Dateien.

Die Einrichtung erfolgt sehr einfach in der sshd_config(5). Zunächst muss das Subsystem "sftp" mit dem intern vorhandenen SFTP-Server ("internal-sftp") geladen werden:

Subsystem sftp internal-sftp

Danach können entweder global alle Benutzer in eine chroot-Umgebung eingesperrt werden (nicht zu empfehlen) oder über einen Match-Block nur einzelne Benutzer, Gruppen oder IP-Adressen bzw. IP-Adressbereiche. Die Festlegung des Verzeichnisses, in dem der Benutzer eingesperrt wird, erfolgt über die Direktive ChrootDirectory. Als Parameter wird das Verzeichnis erwartet, wobei die Zeichenkette einige Variablen enthalten kann:

Variable	Bedeutung
%h	Home-Verzeichnis des Benutzers
%u	Benutzername des Benutzers
%%	'%' Zeichen

Die Direktive ChrootDirectory /srv/www/%u würde den Benutzer "web1" also im Verzeichnis /srv/www/web1 einsperren. Soll der Benutzer zusätzlich wirklich nur via SFTP auf den Server zugreifen können, kann dies mit der Direktive ForceCommand internal-sftp erzwungen werden.

Achtung: Dadurch ist wirklich nur noch ein Zugriff via SFTP möglich. Auch SCP funktioniert dann nicht mehr!

Hier ein paar Beispieleinträge in der sshd_config. Die Match-Blöcke müssen unbedingt am Ende der Datei stehen, da sonst alle folgenden Direktiven, die auch in einem Match-Block stehen könnten, dem letzten Block zugeordnet werden!

# Clients aus dem IP-Adressbereich 10.0.1.0/24 einsperren.
Match Address 10.0.1.*
  ChrootDirectory %h

# Benutzer mit der Gruppe sftp im Homeverzeichnis einsperren und nur SFTP erlauben
Match Group sftp
  ChrootDirectory %h
  ForceCommand internal-sftp

# Benutzer web* (z. B. web1, web42, web123, web4711) in /srv/www/ einsperren und nur SFTP erlauben
Match User web*
  ChrootDirectory /srv/www/%u
  ForceCommand internal-sftp

Sobald ein Benutzer mit dieser sshd-Konfiguration mit `gpasswd -a sftp` der Gruppe "sftp" hinzugefügt wird, kann dieser sich in Zukunft nur noch innerhalb seines zugewiesenen Verzeichnisses bewegen. Ideal zur Absicherung eines Servers mit mehreren nicht vertrauenswürdigen Benutzern.

Quellen:
sshd_config(5)
OpenBSD Journal - Chroot in OpenSSH
Debian Administration - OpenSSH SFTP chroot() with ChrootDirectory

Ein toller Tipp in der FAQ von 1blu:
Wie kann ich die Erreichbarkeit meines 1blu-vServers / 1blu-RootServers auf einem konstanten Level halten?

Zuerst hätte ich einen Fake-Eintrag vermutet, aber der Artikel scheint tatsächlich ernst gemeint zu sein.

Falls noch jemand das gleiche zweifelhafte Vergnügen hat, Exim mit SASL-Unterstützung einzurichten, dem sei gesagt:

Der Service Name ist nicht wie in der Dokumentation behauptet "smtp", sondern "exim".

In der Datei exim-4.6x/src/auths/cyrus_sasl.c wird der Funktion sasl_server_new zwar der richtige Wert übergeben, aber sasl_server_init setzt den Application Name auf "exim", unabhängig davon welcher Wert in der Konfiguration gesetzt wurde. Leider sucht Cyrus SASL die Konfiguration dann unter /etc/sasl2/exim.conf, anstatt /etc/sasl2/smtp.conf.