Folgendes Mini HowTo zeigt die Vorgehensweise unter Debian Lenny mit einem selbst signierten Zertifikat

Als erstes sollte – sofern notwendig – “submission” freigeschaltet werden. Dazu müssen folgende Zeilen in der master.cf einkommentiert werden:

/etc/postfix/master.cf

submission inet n       -       -       -       -       smtpd
  -o smtpd_enforce_tls=no
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Danach legen wir einen neuen Ordner für die benötigten Zertifikate an:

mkdir /etc/postfix/ssl
cd /etc/postfix/ssl

Nun können wir einen privaten RSA Key generieren (2048 Bit)

openssl genrsa -out smtp.key 2048

Weiter gehts mit dem CSR (Certificate Signing Request)

openssl req -new -key smtp.key -out smtp.csr

Die entsprechenden Angaben sollten mehr oder weniger seriös ausgefüllt werden. Funktionsbezogen ist allerdings nur der CN (Common Name). Hier muss der Hostname des Mailservers eingetragen werden – oder ein entsprechender Wildcard (z.B. smtp.beispieldomain.ch oder *.beispieldomain.ch).

Nun können wir unser Zertifikat anlegen (In diesem Beispiel 365 Tage gültig)

openssl x509 -req -days 365 -in smtp.csr -out smtp.cert -signkey smtp.key

Nun ergänzen wir noch die main.cf, oder passen die bereits vorhanden Werte an.

/etc/postfix/main.cf

smtpd_tls_auth_only = no
smtpd_enforce_tls = no
smtpd_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtpd_tls_cert_file = /etc/postfix/ssl/smtp.cert
smtpd_tls_key_file = /etc/postfix/ssl/smtp.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

Mit dem Parameter smtpd_tls_security_level kann bestimmt werden, ob auch unverschlüsselte Verbindungen erlaubt sind. In diesem Beispiel überlassen wir die Entscheidung über eine allfällige Verschlüsselung beim Client und setzten den Wert daher auf “may”.

Der Parameter smtpd_tls_auth_only definiert, ob nur noch mittels TLS Authentifiziert werden kann. Dies ist bei allgemeinen Mailservern nicht unbedingt empfehlenswert, da sich sonst massenhaft relay access denied Fehler ansammeln werden durch eine “fehlgeschlagene” Authentifizierung von “dummen” clients.
Sicherheitstechnisch müsste dieser Wert allerdings defenitiv aktiviert sein.

Danach noch Postfix neu initialisieren – und testen.

postfix reload

Ihre Nachricht hat einige oder alle Empfänger nicht erreicht.
      Betreff:  ***** 
      Gesendet am:      dd.mm.yyyy HH:MM
Folgende(r) Empfänger kann/können nicht erreicht werden:
'*****' am dd.mm.yyyy HH:MM
573 573  
Authentifizierte Verbindungen nicht moeglich. Bitte nutzen Sie den Port 587 oder kontaktieren Sie uns unter 0800 800 800. 
Connexions authentifiees pas possible. Veuillez utiliser le port 587 ou nous appeler au 0800 800 800.
Collegamenti autenticati non possibili. Prego voi uso la porta 587 oppure contattare il numero 0800 800 800.
Authenticated connections not possible. Please use port 587 or contact us on 0800 800 800.

Offenbar hat dieser Schritt bei vielen Providern erheblichen Supportaufwand produziert. Zumindest eröffneten Hostpoint und Cyon Statustickets zu dieser Problematik. Ebenfalls wurde auf der Swinog Mailingliste ordentlich darüber diskutiert.

Offiziell will man dadurch das versenden von Spam über Mailserver ohne Authentifizierung/Verschlüsselung unterbinden (z.B. durch Viren). Ob die entsprechenden Mailserver unter Port 587 (Submission) aber sicherer konfiguriert sind bezweifle ich. Zumal auch hier eine Verschlüsselung (TLS) nicht zwingend erforderlich ist.

Dieser Artikel soll konzeptionell aufzeigen wie Serverseitig eine möglichst ideale Umgebung bereitgestellt werden kann. Die Sicherheit innerhalb von PHP Scripts wird hier nicht behandelt.

Setup
PHP kann grundsätzlich auf 2 Arten installiert/betrieben werden.

• Als Modul eigebunden in den Webserver (z.B. Apache). Somit läuft der PHP-Interpreter sammt seinen Modulen persistent und logischerweis unter demselben User wie der Webserver selbst. Dadurch hat PHP grundsätzlich auch dieselben Rechte wie der Webserver auf dem System. Von PHP erstellte Dateien gehören somit danach auch dem “Webserver” – und nicht dem User. Diese können danach möglicherweise per FTP z.B. nicht gelöscht oder geändert werden.
  Ein paar spezifische Manipulationen an der Konfigurationsdatei php.ini sind pro vHost möglich.

  Diese Variante eignet sich primär für einzelne Webprojekte – auf keinen Fall für Shared Hosting.

• Als CGI. Wenn ein PHP-Script “interpretiert” werden muss – wird dazu ein neuer Prozess gestartet, der zuerst PHP initialisiert, die Module lädt – und dann erst seine Arbeit startet. Defaultmässig läuft die CGI-Variante auch unter dem User des Webservers.
  Der Resourcenverbrauch gegenüber der Modul-Variante ist natürlich massiv höher – da neben dem Overhead durch das starten des Threads die Module nicht geshared werden können.

Auf den ersten Blick hat somit Variante 2 eigentlich nur Nachteile. ABER: Durch zusätzliche Wrapper können die Threads unter dem eigentlichen User des vHosts ausgeführt werden. Hier gibt es aktuell suExec und suPHP. Ersteres simuliert näherungsweise die Modul Variante – da die Threads noch künstlich am Leben erhalten werden können für allfällige weitere Aufgaben. suPHP startet und beendet dagegen den Thread bei jeder “Interpretation”

Pro vhost kann hier eine komplett eigene php.ini verwendet werden – sowie (wenn erwünscht) eine eigene PHP-Versionen. Von PHP erstelle Files gehören danach vHost-User und können problemlos per FTP mutiert werden.

Somit hätte man also Grundsätzlich die “Sicherheit” durch den Thread sichergestellt – und hat eigentlich bereits ansatzweise eine chroot() Umgebung für PHP.

Als Systemadmin hat man durch diese Variante zudem den grossen Vorteil, das sofort ersichtlich ist wem welche Threads gehören.

Konfiguration
Weiter ist die Konfiguration von PHP vorsichtig zu definieren. Folgende Funktionen sollten wirklich nur bei Bedarf aktiviert werden:

• exec()
• passthru()
• system()
• popen()
• ini_set()
• ini_restore()

–>Einzelne Funktionen können gezielt mittels der php.ini gesperrt werden.

open_basedir
Sehr wichtig ist ausserdem das open_basedir. Leider werden die Sicherheitsmassnahmen nicht selten ganz alleine auf diese Einstellung beschränkt. Man muss sich aber bewusst sein dass das open_basedir lediglich für Filehandles berücksichtigt wird – nicht aber für exec, system etc..

safe_mode?
Der safe_mode war ein etwas unglücklicher Ansatz, die PHP Umgebung abzusichern. In der Praxis sind dadurch mehr Probleme als Lösungen entstanden. Da der safe_mode zukünftig wieder komplett wegfällt – sollten wir diesen nicht weiter berücksichtigen.

Kontrolle
Als Anwender kann das PHP-Setup über ein einfaches phpinfo() jederzeit ermittelt werden.

Der Parameter “Server API” zeigt z.B. auf – wie PHP installiert worden ist.

• Apache-Modul: Apache 2.0 Handler
• CGI: CGI/FastCGI

Fazit
PHP als Modul eignet sich primär für Einzelprojekte. Im Shared Hosting Bereich ist diese Variante nur für den Betreiber interressant, da effizient und somit lukrativ. Als Kunde (Shared Hosting) sollten sie eine solche Dienstleistung auf keinen Fall unterstützen.

Aber wussten sie, dass diese Informationen auch von fremden Webseiten ausgelesen werden können?

Lassen sie sich überraschen:  http://www.whattheinternetknowsaboutyou.com

Mittels einem kleinen Script werden im Browser des “Opfers” diverse URL’s durchgetestet. Dieser Test macht nichts anderes als die Auswertung – in welcher “Farbe” der Link nun dargestellt wird. So kann ermittelt werden ob diese Seite in der lokalen Browserhistorie vorhanden ist, und somit besucht wurde. Möglich ist dies beispielsweise mittels der CSS-Pseudoklasse “visited”.

Weitere informationen zu diesen CSS-Pseudoklassen

Die Thematik mit der lokalen Browserchronik ist eigentlich ein alter Hut. Einen kriminellen Nutzen davon gibt es kaum, viel spannender dürfte sowas allerdings für Werbezwecke sein. Dennoch sind es “ihre” Daten – und sollten es auch bleiben.

Bei Mozilla ist diese Problematik längst bekannt, wie folgende 2 Tickets bestätigen:

Ticket #57351, bzw. Ticket #147777

Für den Firefox gibt es aktuell folgende Gegenmassnahme:

Installieren sie das Add-On “Link Status”

Danach bei den Extras->Add-Ons->Linkstatus:Einstellungen”Bereits besuchte Links nicht stilisieren” markieren und bestätigen:

Das war’s