Archiv für Februar 2012

Montagabend, kurz vor 23 Uhr

Aus der E-Mail eines neuen Managed Server Kunden:

Ihr Support ist grandios aber nun machen Sie doch endlich Feierabend 🙂

  • Kommentare deaktiviert für Montagabend, kurz vor 23 Uhr

PIN für Telefonsupport ab 1. März

Bisher haben wir bei telefonischen Anfragen den Anrufer anhand der Kundennummer und einiger persönlicher Daten verifiziert.

Da dies einerseits zeitaufwendig ist (besonders dann wenn ein beauftragter Mitarbeiter oder Administrator anruft und die Daten gerade nicht zur Hand hat) und anderseits auch eine gewisse Anfälligkeit gegenüber Social Engineering birgt, wird ab 1. März neben der Kundennummer eine eindeutige PIN zur Identifizierung herangezogen werden.

Alle Kunden haben heute bereits eine E-Mail mit Ihrer persönlichen PIN erhalten.

Zum 1. März wird übrigens auch unsere Telefonanlage entsprechend angepasst. So wird beispielsweise bei Anrufen außerhalb der Geschäftszeiten für den Notfallsupport noch vor der Weiterleitung die Kundennummer und PIN abgefragt, und diese Informationen dem zuständigen Techniker direkt auf das Telefon übermittelt und angezeigt.

  • Kommentare deaktiviert für PIN für Telefonsupport ab 1. März

PECL Cairo mit PHP 5.3

Schon seltsam, dass selbst 2 Jahre nach Erscheinen von PHP5.3 es für Cairo noch kein Update gibt.

Ein pecl install channel://pecl.php.net/cairo-0.3.0 schlägt mit einem compile error fehl.

Hier der diff, um es zum Laufen zu bekommen:

128c128
< object_init_ex(return_value, cairo_ce_cairosubsurface); --- > /*object_init_ex(return_value, cairo_ce_cairosubsurface);*/
690c690
< #ifdef CAIRO_HAS_PS_SURFACE --- > #ifdef CAIRO_HAS_RECORDING_SURFACE
711c711,712
< #if CAIRO_VERSION >= CAIRO_VERSION_ENCODE(1, 10, 0)

> /*
> #ifdef CAIRO_VERSION >= CAIRO_VERSION_ENCODE(1, 10, 0)
716c717
< --- > */

Update: Mittlerweile wurde Version 0.3.1 mit entsprechenden Anpassungen für PHP 5.3 veröffentlicht.

  • Kommentare deaktiviert für PECL Cairo mit PHP 5.3

Kritische Sicherheitslücke in Plesk

Heute hat Parallels über eine kritische Sicherheitslücke in Plesk informiert. Es soll eine SQL-Injection möglich sein, über Details schweigt Parallels bislang. Allerdings wird allen Nutzern empfohlen, so schnell wie möglich zu aktualisieren.

Hier der Originaltext:

Plesk – Critical Security Vulnerability – Patch REQUIRED

Dear Parallels Plesk Panel User:

Please read this message in its entirety and take the recommended actions.

Parallels has been informed of a SQL injection security vulnerability in some older versions of Plesk. This vulnerability is considered critical in nature and customers are advised take action quickly.

A patch has been released to resolve this vulnerability. Based on the version and operating system of Plesk you use, please follow the instructions below.

Linux

Plesk 10 – Update to Plesk 10.3.1 MicroUpdate #6 or later.
Update Instructions: here
If possible, it is recommended to update all the way to Plesk 10.4.4 to provide the most stable user experience.

Plesk 9 – Update to Plesk 9.5.4 MicroUpdate #11 or later
Update Instructions: here

Plesk 8 – Update to Plesk 8.6.0 MicroUpdate #2 or later
Update Instructions: here

Windows

Plesk 10 – Update to Plesk 10.3.1 MicroUpdate #6 or later.
Update Instructions: here
If possible, it is recommended to update all the way to Plesk 10.4.4 to provide the most stable user experience.

Plesk 9 – Apply Fix from Parallels Knowledge Base
Update Instructions: here

Plesk 8 – Apply Fix from Parallels Knowledge Base
Update Instructions: here

If you are already at or above the Version and MicroUpdate levels indicated above – you are already protected from this vulnerability.

Parallels takes the security of our customers very seriously and urges you to act quickly by applying these patches.

Thanks,

– The Parallels Plesk Panel Team

Die notwendigen Microupdates lassen sich am einfachsten mit folgendem Befehl in der Commandline installieren:

# /opt/psa/admin/sbin/autoinstaller –select-product-id plesk –select-release-current –reinstall-patch –install-component base

Unsere Managed Server sind nicht betroffen (gewesen), da wir seit Dezember überall Version 10.3.1 MU >=16 als bevorzugtes Release einsetzen.

Dass Plesk 10.4.4 stabiler sein soll als 10.3.1 können wir unterdessen nicht bestätigen. 😈

  • Kommentare deaktiviert für Kritische Sicherheitslücke in Plesk

Den Test, den Zscaler unter zulu.zscaler.com zur Risikoanalyse von Webseiten anbietet, ist ja im Prinzip ganz nett gemacht. Besonders, dass auf Phishingangriffen und attackierenden Javascripts geprüft wird, ist lobenswert. Gut, das macht Google ebenfalls und warnt praktischerweise auch gleich beim Aufruf von schädelichen Seiten.
Wohl um sich etwas abzuheben bietet Zulu noch ein paar Extrachecks an.

Zum Beispiel die Überprüfung des Domainnamens.  Dass diverse, absolut seriöse, deutsche Domains allerdings als verdächtige Domainnamen mit mittlerem oder gar hohem Risiko bewertet werden, liegt wohl daran, dass der Test in erster Linie auf englische Domains ausgelegt ist.

Was aber wirklich überrascht, ist die Abteilung Host checks.
Dort wird die AS-Nummer (also im Prinzip das Netz des Providers), der Standort und die Größe des Subnetze ermittelt und bewertet.

Ein kurzer Test ergab bei zahlreichen bekannten Hostern ein erhöhtes Risiko aufgrund deren AS-Nummer. Nur sind diese Hoster alle dafür bekannt, dass sie rechtlich einwandfrei handeln und auch Abuse Meldungen ersnt nehmen. Also hängt der Score eines AS vermutlich davon ab, wieviele problematische Seiten Zscaler in diesem Netz entdeckt oder entdeckt hat. Leider wird nirgendwo erwähnt, auf Basis welcher Werte der Score berechnet wird. Es fällt bei einem kurzen Test mit einigen Domainnamen nur auf, dass die AS von großen Provider überwiegend als Risiko eingestuft werden, während die AS von einigen relativ kleinen Anbieter, darunter auch solche, die bekannt dafür sind, dass sie es mit Abuse nicht so genau nehmen, keinen Score verpasst bekommen. Das lässt darauf schließen, dass Zscaler nicht über ausreichend Daten verfügt, um einen Wert für kleinere AS zu ermitteln oder dass absolute Daten ohne Gewichtung verwendet werden. So oder so, der Check ist nicht sehr aussagekräftig.

Über die generelle Abwertung einer Webseite aufgrund des Serverstandortes kann man auch lange und viel diskutieren, in meinen Augen macht das noch weniger Sinn als die Bewertung der AS-Nummer.

Was aber wirklich verwundert, ist der Netblock size risk Check. Je kleiner der Netzblock, desto schlechter die Bewertung, resp. höher das angezeigte Risiko! Dabei werden kleine Subnetze doch gerade aus Sicherheitsgründen verwendet.

Interessanterweise wird bei den Host checks die IP-Adresse selbst nicht getestet. Das wäre das einzige Kriterium, das ein wenig Sinn machen würde. Wenn eine Domain bereits als böse erkannt wurde, könnte man von einem Gefahrenpotential für alle anderen Domains auf dem gleichen Server ausgehen, da solche Seiten ja meist erst durch Sicherheitslücken auf einen Server gelangen.

  • Kommentare deaktiviert für Zulu: Domain in schlechter Nachbarschaft?