ScriptBlogger

Für einen Kunden haben wir letzten Monat ein Script installiert. Diesen Monat muss der Kunde unsere Dienste erneut in Anspruch nehmen. Einem unfähigen Webhoster sei Dank.

The Mailer didn't work

the host said that have limited support on php, that's all they can offer in
the mean time,

We purchased a new host,

Wir nörgeln hier im Blog häufiger über diverse Webhoster herum. Andere haben da weniger Probleme, wie zum Beispiel das Lawblog mit Strato. Der Vorfall zeigt, dass es auch Webhoster gibt, die für und nicht gegen ihre Kunden arbeiten. Verträge lassen sich dort unkompliziert, ohne Extrakosten und ohne lange Wartezeiten ändern. Und kulant sind die anscheinend auch noch.

Kam heute eine E-Mail von Domaingo:

Betreff: Missbrauch Ihrer Scripte
Leider mussten wir feststellen, dass Ihre Skripte auf der Domain teenyweenyurl.com von Dritten missbraucht wurden um Malware, bzw. Weiterleitungs-Dateien zu installieren. Diese Dateien werden dann in Spam/Phishingsmails angegeben um den User über eine unbekannte/harmlose Domain auf eine Phishing/Spam-Seite umzuleiten oder diesem einen Trojaner einzuschleusen.

Bitte prüfen Sie, ob und wie Sie die von Ihnen eingesetzten Scripte absichern/aktualisieren können und ergreifen Sie alle notwendigen Maßnahmen, um weitere Probleme zu vermeiden.

Bla bla bla. Domaingo hatte die Domain gleich mal gesperrt. Wie im wilden Westen. Erst schießen und dann die Fragen stellen. Dabei ist das Script nicht mal bei Domaingo gehostet, sondern die Domain zeigt per DNS-Einstellungen auf einen Server von Hosteurope.

Das haben wir denen auch mitgeteilt. Teenyweenyurl.com ist ein Kurz-URL-Dienst wie tinyurl.com. Die beanstandete URL wurde von uns in der Datenbank auf "deaktiviert" gesetzt, so dass keine Weiterleitung mehr auf die eigentliche URL erfolgt, sondern folgender Text angezeigt wird:

URL could not be found. It has probably deleted due to a violation of our terms of use. A violation would be the use of this service for spamming and illegal purposes such as phishing.

Davon mal abgesehen war die Domain zu diesem Zeitpunkt noch nicht ein einziges Mal aufgerufen worden. Es ist also definitiv niemand zu Schaden gekommen.

Antwort von Domaingo:

Da wir in Ihrem Fall leider nicht überprüfen können, ob Sie alle Sicherheitslücken geschlossen haben, benötigen wir von Ihnen vorab eine unterschriebene Erklärung, in der Sie versichern, Ihre Software abgesichert haben und dass Sie sichergestellt haben, dass in Zukunft nicht mehr auf Phishing- oder Spam-Seiten weitergeleitet wird.

Ja genau. Als wenn wir das jemals 100%-ig verhindern könnten. Es liegt nun einmal in der Natur dieser Dienste, dass sie gern missbraucht werden. Teenyweenyurl.com gleicht deshalb jede eingegebene URL mit der SURBL Blacklist ab. Bekannte Spam- oder Phishing-URLs werden also gar nicht erst angenommen oder es wird gar nicht erst weitergeleitet.

Da Domaingo sich nicht dazu bewegen ließ, die Domain zu entsperren, haben wir sie dann zu einem anderen Provider umgezogen. Gleiches machen wir dann mal vorsorglich auch mit der Domain gentleurl.net.

Ein Nutzer möchte die Captcha-Funktion unseres Form-Mail-Scripts nutzen, nur leider fehlt auf dem Server GD2 und Freetype. Er schrieb dann:

Moreover, my webhost [...] has now agreed to upload the GD2 and FreeType on their server; but they have asked me as to which Directory the same ought to be uploaded.

Das sollte man als Anbieter von Webservern doch eigentlich wissen, oder? Mal davon abgesehen, dass beide Komponenten sich nicht durch reines Hochgeladen zum Funktionieren bewegen lassen. :-[]

Immer sind die anderen Schuld. Ein Nutzer unseres Abstimmungs-Scripts schrieb, dass er das Script auf zwei verschiedenen Servern installiert hat. Auf dem Ersten funktionierte es nicht, dafür aber auf dem Zweiten. Leicht frustriert wandte er sich an uns:

The provider [...] isn't a good person, he always [says] that WE ARE THE PROBLEM, or THE SCRIPT, everybody except [him]...

:-[]

GoDaddy ist ein recht großer Webhoster. Aber so groß wie er ist, so schrottig ist er auch. Man muss nur mal einen Blick auf die Liste der abgeschalteten PHP-Funktionen werfen:

• getmyinode
• getopt
• getrusage
• extension_loaded
• dl
• mysql_pconnect
• crack_check
• crack_closedict
• crack_getlastmessage
• crack_opendict
• fsockopen
• pfsockopen
• mysql_list_dbs
• mysql_stat
• ini_get
• ini_get_all
• ini_alter
• ini_set
• get_current_user
• get_defined_constants
• get_include_path
• php_ini_scanned_files
• php_uname
• phpcredits (WTF!)
• restore_include_path
• set_include_path (WTF!)
• set_time_limit
• version_compare
• zend_version (WTF!)
• getmypid
• getmyuid
• getmygid
• assert_options
• assert
• fopen (WTF!)
• fwrite (WTF!)
• fread (WTF!)
• file (WTF!)
• fpassthru
• file (Doppelt?)
• mail (WTF!)
• opendir (WTF!)
• readdir (WTF!)
• closedir (WTF!)

Sehr löbliche Aktion von Domainfactory. Verträge können ab sofort auch online gekündigt werden, ohne eine schriftliche Bestätigung per Fax oder Brief.

Als fairer Partner möchten wir Ihnen nicht nur Bestellungen so einfach machen wie möglich, sondern auch die Kündigung von Domains und Aufträgen. Daher haben wir exklusiv die neue Online-Kündigung entwickelt. Damit ersparen Sie sich jegliche schriftlichen Bestätigungen und können Domainnamen und Tarife bei Bedarf direkt über Ihr Kundenmenü kündigen [...]

Wenn Webspace-Provider PHP einer der wichtigsten Funktionen berauben und erwarten, dass die Kunden das schlucken:

Aus Sicherheitsgründen mussten wir PHP Mail deaktivieren da Kunden und dritte darüber Spam versandt haben. Nutzen Sie bitte ausschliesslich PHP-Formulare die über SMTP die Emails verschicken und nicht über PHP Mail.

Das wäre in etwa so, als würde ein Messerhersteller nur noch stumpfe Klingen ausliefern, weil man sonst jemanden damit verletzen könnte.

Hinweis: Es folgt eine etwas längliche Forums- und Mail-Korrespondenz. :-P

Letztens schrieb ein Kunde folgendes im Support-Forum:

Script Vulnerability!

Today my site, which uses the short URL script, was "hacked" via the script using iframe injection in to a few PHP files, according to my hosting company.

When I went to my site, the main page was not working at all. It displayed a php error for index.php. When I went to that file, I found the following code at the bottom of the file:

Code:
<iframe src="http://example.com
<iframe src="http://example.com/path/file.cgi?parameter" width=125 height=125 style="visibility: hidden"></iframe>

Obviously, I never added this code. When I contacted my hosting company, they said that it was not due to anyone taking over my account, but rather a vulnerability in the short URL script that allows iframe injection.

Der Kunde ließ uns FTP-Zugang, Zugang zum Control Panel des Web-Accounts und die FTP-Logdatei zukommen. Das Ergebnis war, dass es kaum möglich sein konnte, dass unser Script für das Problem verantwortlich war. Für das Ändern der Dateien wurde der FTP-Account des Kunden genutzt. Hätten die Hacker jedoch eine Lücke im Script benutzt, wäre die Aktivität in der Access-Log und nicht in der FTP-Log aufgetaucht. Das schrieben wir auch dem Kunden.

First of all you should change the passwords of all your FTP accounts and run a virus check on your computer. As the log file you've send me clearly states, someone used the FTP username "[gelöscht]" for downloading and uploading those files.

It is interesting that the webhosting people blame the script. The script doesn't know your FTP account. There is no way for anyone to get the script to tell them your FTP account (that I can see).

Even file inclusion - a popular hacking method - is not possible. The input from the form will be stored in the database. No inclusion of any file of the script depends on user input. Besides, if someone used the script to place that code on your server, it wouldn't show in the FTP log file. It would show in the access log file.

I've downloaded the access log files via your control panel. There is no unusual activity with the script around the time your server got hacked.

Also, the hackers didn't know what they were doing. While changing those files, they broke the script. But if they were able to know the script well enough to hack it, they wouldn't have broken it. They would have made sure that it continues to run smoothly so that nobody notices anything wrong. They would have hacked the HTML template files, not the PHP code files.

As far as I can see there are two possibilities here: Firstly, your webhosting company got hacked and someone stole a bunch of FTP accounts. Or secondly, someone installed a trojan horse or a keylogger on your computer and stole the FTP login this way.

I can't dismiss entirely the possibility, that the script got hacked. That wouldn't be the first time one of our scripts had a security hole. We always were able to find the bug and fix it within hours, but I can't see a connection between the hack and the Short URL script other than the script got changed during the hack.

If your webhosting company can provide evidence that our script is indeed the culprit, I'd happily use that evidence to fix the script.

If you have any questions, let me know.

Und hier die Antwort:

I contacted my hosting company again and sent them a copy of your e-mail. After further investigation they stated that your explanations are correct, and that the script is NOT at fault. We're still working out to determine the cause, however it was not the script. They were too quick to judge the script without first properly conducting an investigation in to the FTP logs, and I have made that complaint clear to them. I apologize for this and I thank you very much for your e-mail.

:-)

Ein Kunde ist mit seinem Terminplaner auf einen neuen Server umgezogen und hatte ein paar Probleme. Nachdem wir die gelöst hatten, kam folgende E-Mail.

WONDERFUL! You are amazing!! I cannot thank you enough. (If you only knew how much time I had spent trying to fix it, you would laugh!)

Nö, hätten wir nicht. Die Probleme waren nicht gerade trivial und für jemanden, der nicht täglich mit solchen Dingen zu tun hat, unlösbar. Hinzu kam eine merkwürdige Konfiguration des Servers und eine noch merkwürdigere Art und Weise, die Seite per SSL verschlüsselt aufzurufen. Die URL sah in etwa wie folgt aus, wobei example.com die Domain des Kunden darstellen soll:

https://p2.secure.hostingprod.com/@www.example.com/ssl/appointments/

Yahoo-Hosting eben. :-[]

Nachdem unser Kurz-URL-Script schon mehrere Jahre auf dem Markt ist und noch nie durch Performance-Probleme aufgefallen ist, zickt jetzt ein Webspace-Provider herum.

This script will perform just fine when there is no load on the server, but at average load you script will run poorly.

Unser Kunde wies seinen Provider darauf hin, dass seine Website kaum Besucher hat und er es für unwahrscheinlich hält, dass das Script für die Probleme verantwortlich ist. Der Webhost legt dann mit folgender Erklärung nach:

The server load is not made up only upon your site alone, but there is many sites on the same server. Some receive more hits than others. Even though your site only may receive a few hits a day, other sites my get a 1000 hits or more. The server load is affected by all sites on the server. When the server is on a normal load amount, it seems your site gets slowed down because of the script.

Zur Erinnerung. Wir sprechen hier von einem Script mit zwei Datenbanktabellen. Eine davon mit höchstens ein paar Tausend Datensätzen, die andere mit rund 20. Beim Abruf einer URL wird per ID gesucht, für die ein Index existiert.

Unser Kunde hält die Aussagen der Webspace-Firma für fragwürdig:

There is simply as a condition that is not acceptable on any internet site. I don't believe for one moment that the short URL script is the cause of the slow loading at various times.
Further I will test the site with normal long URL's and see if there is any difference. I have used Hosts for too long to buy your explanation.

Yep, wir ebenso wenig. Es gibt allerdings einen Umstand, der dem Server tatsächlich zusetzen würde und bei unseren eigenen Seiten (flaturl.com, gentleurl.net) auch tatsächlich zu Problemen geführt hat. Wenn nämlich die URLs zu Bilddateien mit Hilfe des Schort URL Script gekürzt und dann in eine Seite eingebaut wurde. In der Vergangenheit wurden diese URLs in chinesischen Foren mit hohem Besucheraufkommen oder in den Kommentaren von MySpace-Profilen eingebaut wurden. Das bedeutet, dass bei jedem Aufruf der MySpace- oder Forums-Seite auch gleichzeitig ein Aufruf zu unserer Seite gemacht wurde. Bei mehreren Requests pro Sekunde über einen längeren Zeitraum fing der Server dann an zu ächzen. Seit wir aber entsprechende Seiten per .httaccess blockieren, ist auch das kein Problem mehr.

Bei unseren Seiten flaturl.com und gentleurl.net sind derzeit zusammen knapp 40.000 URLs in den Datenbanken. Seit Beginn wurden über 10. Mio Aufrufe gezählt und täglich kommen rund 3.000 dazu, mit Spitzen von 8.000 Aufrufen. Das sind sicherlich keine rekordverdächtigen Zahlen, aber genug um zu zeigen, dass eine normale Nutzung des Scripts nicht gleich den gesamten Server aus der Puste bringt.

Jedes Mal, wenn der Managed Server eines Kunden bei 1&1 abschmiert, stimmt die Zuordnung der Subdomain www. auf das ursprünglich zugewiesene Verzeichnis nicht mehr. Passiert ungefähr einmal jährlich. Diesmal wurde versprochen, das Problem ein für alle Mal zu beheben. Ah, ja. Möchte jemand 'ne Wette darauf abschließen? ;-)

Kleiner Tipp noch für alle, die ebenfalls einen Managed Server bei 1&1 haben: Sollte mal was sein, zuerst darum bitten, dass der Server komplett neu gestartet wird. Der Support von 1&1 neigt dazu, erst stundenlang an dem Teil herumzufummeln. Hat einem Kunden schonmal unnötig einen ganzen Tag gekostet. Dabei hatte sich anscheinend nur der MTA aufgehängt. Eine Sache, die in fünf Minuten erledigt gewesen wäre.

Ein Script von uns funktionierte auf dem Server des Kunden nicht ganz korrekt. Es sollte E-Mails versenden, tat es aber nicht. Ein kurzer Blick in die Kristallkugel ergab, das womöglich der safe_mode daran schuld ist. Die Kristallkugel sollte recht behalten.

Seit einer Weile schreiben einige Webspace-Provider vor, dass man bei Scripten die Return-path-Kopfzeile angibt. Das macht man mit Hilfe des fünften Parameters der Funktion mail(). Ist auch nicht weiter wild. Unsere Scripte können damit umgehen.

mail(
    'empfaenger@example.com',
    'Betreff',
    'Nachricht',    
    'From: absender@example.com',
    '-fwebmaster@example.com'
    );

Ist aber der safe_mode aktiviert, ist der fünfte Parameter nicht erlaubt. Ergo werden auch keine E-Mails versendet. Das ist kein Problem, denn das Script verzichtet im safe_mode automatisch auf den fünften Parameter.

Leider hatte der Kunde noch eine Version des Scripts, in der diese Funktion fehlte. Man hätte jetzt ein Update machen können, aber der Kunde entschied kurzerhand, den safe_mode abzuschalten. Um so besser. Leider haben nur die wenigsten Anwender diese Möglichkeit.

Jetzt fing aber die Sache erst an, spannend zu werden. Den Pfad der php.ini hat der Kunde noch relativ zügig herausgefunden. Trotz Änderung und Neustart des Apache blieb jedoch der safe_mode eingeschaltet. Wenig hilfreich war auch die Tatsache, dass es mehrere php.ini an verschiedenen Orten auf dem Server gab.

Schlussendlich ließ sich die Einstellung in der Konfiguration der virtuellen Hosts finden:

/srv/www/vhosts/beispiel-domain/conf/httpd.include

Da wollte anscheinend jemand mit aller Macht sicherstellen, dass auf dem Server der safe_mode aktiviert bleibt. :-P

Letztens haben wir von überängstlichen Webspace-Providern berichtet. Heute hatten haben wir das andere Extrem.

Für eine Kundin sollten wir ein Script installieren und benötigten dafür eine MySQL-Datenbank. Zunächst fehlten die Zugangsdaten, weshalb wir die Kundin baten, sich mit ihrem Webspace-Provider in Verbindung zu setzen. Als Antwort kam eine URL in folgender Art:

http://www.example.com/cpanel/phpmyadmin/

Das wird uns nicht viel nützen, dachten wir uns, denn bei keinem Webhoster kann man über phpMyAdmin Datenbanken erstellen. Das läuft üblicherweise über das Control-Panel des jeweiligen Webspace-Kontos.

Weit gefehlt. Wir hatten tatsächlich root-Zugriff auf den MySQL-Server. Haben wir also das gemacht, was wir schon lange nicht mehr getan haben: Nämlich Datenbank und Benutzer direkt über die Konfigurationsdatenbank von MySQL erstellt. War auch mal wieder schön. ;-)

Letzte Woche haben wir Strato die Schnarchnase des Jahres genannt. Heute haben wir weitere Informationen. Scharchnase ist möglicherweise nicht ganz gerechtfertigt, aber mangels eines anderen Wortes bleiben wir erst mal dabei.

Bei Strato kann man über zehn Jahre alte PHP-Versionen verwenden. PHP 3 ist mit Version 3.0.18 immer noch verfügbar.

Als Standardversion ist nach wie vor 4.1.2 eingestellt. Alternativ kann man sie mit folgender Zeile in einer .htaccess aktivieren:

AddType application/x-httpd-php41 .php

Die letzte PHP-4-Version 4.4.9 lässt sich mit eine der folgenden Zeilen aktivieren:

AddType application/x-httpd-php4 .php
AddType application/x-httpd-php43 .php

Die aktuelle PHP-Version 5.2.8 erhält man mit:

AddType application/x-httpd-php5 .php

Alternativ kann man die PHP-Version für das gewünschte Verzeichnis über die Verwaltungsoberfläche des Web-Accounts auszuwählen. Zur Auswahl steht dann die jeweils aktuelle Version von PHP 4 und PHP 5.
Bei der Änderung wird dann in dem Verzeichnis eine .htaccess geschrieben, die der Datei-Endung .php dann zum Beispiel PHP 5 zuweist. Eine eventuell bestehende .htaccess wird .htaccess.bak umbenannt. Man muss also die Einstellungen aus der alten .htaccess in die neue .htaccess übertragen.

Warum die genaue PHP-Version von Relevanz ist? PHP hat mit Version 5 einiges an Funktionalität hinzubekommen und die Performance drastisch verbessert. PHP 4 wird nicht mehr gepflegt und ist hoffnungslos veraltet - was sowohl die Funktionalität als auch die Sicherheit angeht. Davon ist die letzte veröffentlichte PHP-Version 4.4.9 keine Ausnahme. Dann noch standardmäßig PHP 4.1.2 am Laufen zu haben, kann man einfach nur noch verantwortungslos nennen.